From julian.reschke@gmx.de Fri Jul 1 06:38:59 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D35E1F0C37 for ; Fri, 1 Jul 2011 06:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.028 X-Spam-Level: X-Spam-Status: No, score=-106.028 tagged_above=-999 required=5 tests=[AWL=-3.429, BAYES_00=-2.599, 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 T4qyu8kVNoSW for ; Fri, 1 Jul 2011 06:38:53 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 351C41F0C35 for ; Fri, 1 Jul 2011 06:38:53 -0700 (PDT) Received: (qmail invoked by alias); 01 Jul 2011 13:38:51 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp022) with SMTP; 01 Jul 2011 15:38:51 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1++aQh2BlO+BSaTreMlNwDTZJt3MRkldmUUhoqaaO VI5Qdg9EMbUgRt Message-ID: <4E0DCDE4.5080903@gmx.de> Date: Fri, 01 Jul 2011 15:38:44 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Frank Ellermann References: <4E083D3F.6030200@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] [link-relations] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 13:38:59 -0000 On 2011-06-30 10:24, Frank Ellermann wrote: >> Title : The Canonical Link Relation >> Author(s) : Maile Ohye >> Filename : draft-ohye-canonical-link-relation-00.txt > > A relative canonical URL can't be a good idea. If there is more than > one "content URL" (in the terminology of the draft) this would result > in more than one canonical URL, defeat the purpose, and worse, this > could make googlebot angry. > > The draft could s/SHOULD NOT/MUST NOT/, I don't see any good reason > to violate a SHOULD NOT, and if that's correct MUST NOT is clearer. I don't understand (yet). What do you mean by "more than one "content URL""? Best regards, Julian From julian.reschke@gmx.de Fri Jul 1 06:47:33 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8121F0C51 for ; Fri, 1 Jul 2011 06:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=-3.000, BAYES_00=-2.599, 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 XY5ob+AfMdDY for ; Fri, 1 Jul 2011 06:47:33 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 83F3E1F0C4C for ; Fri, 1 Jul 2011 06:47:32 -0700 (PDT) Received: (qmail invoked by alias); 01 Jul 2011 13:47:30 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp019) with SMTP; 01 Jul 2011 15:47:30 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+nBJcG+eWnhGl7Q/HXaMejGLHdJ5guNoWARtOaky cNRqktwujtEOLt Message-ID: <4E0DCFEF.20206@gmx.de> Date: Fri, 01 Jul 2011 15:47:27 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mykyta Yevstifeyev References: <4E083D3F.6030200@gmx.de> <4E0D3EA5.7010803@gmail.com> In-Reply-To: <4E0D3EA5.7010803@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Apps Discuss , "link-relations@ietf.org" Subject: Re: [apps-discuss] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 13:47:33 -0000 On 2011-07-01 05:27, Mykyta Yevstifeyev wrote: > Hello Maile, > > Several comments to your draft-ohye-canonical-link-relation-00. > > There is the Intended Status missing in it. I suppose Informational > should be fine. We do not need to decide this now, and I expect the Area Director who's going to sponsor this to have an opinion on it. That being said, "Informational" should be fine (Maile: that would be category="info" on the element). >> 1. Introduction >> >> The canonical link relation specifies the preferred version of a URI > I think some introductory text on linking, probably based on RFC 5988, > should go here. Why? It defines a link relation as defined by RFC 5988, so why repeat text from over there? > Section 2: > >> Presence of the canonical link relation indicates >> to applications, such as search engines, that they MAY: > I wonder why it's MAY; in this case implementations (explicitly, those > apps which interpret Link: headers and corresponding construction in > HTML) will be free to ignore it. I think normative SHOULD should be OK > (sorry for pun). I think this link relation is purely advisory, so a better approach might be to replace "MAY" by "can". > ... >> The value of the target/canonical URI MAY: > I suppose omitting "value of the" should be better, since there is no > such term in RFC 3986. In fact, when referring the URI, we mean its > value, meaning. Yes. >> o Exist on a different protocol: http to https, or vice versa > You probably meant URI scheme here, since https isn't a separate > protocol. As before these points we had "The value of the > target/canonical URI MAY" or, if you consider my comment above, "The > target/canonical URI MAY", this point may be reworded as "Have different > scheme names" (which suits the second variant of a preface to this list > better). Sounds good. > Reading section 3 and 5 of the draft, it seems that is mandates use of > HTTP when referring to canonical URIs. And what is the situation when > target URI is a 'ftp' or 'gopher' URI? Section 3 allows different scheme > names in context/target URIs, if I understand it correctly. Therefore, > unless it is deliberately, I think any mention of HTTP should be > replaced by more generic regulations. Nope; I think the HTTP examples are very useful. But maybe we can have an additional statement that the link relation isn't specific to HTTP. >> 8. Internationalisation Considerations >> >> In designating a canonical URI, please see [RFC3986] for information >> on URI encoding. > URIs themselves are not internationalized, in terms of RFC 3536, which > defined: > >> internationalization >> >> In the IETF, "internationalization" means to add or improve the >> handling of non-ASCII text in a protocol. > IRIs serve for this purpose. I recommend either to rename the section to > Encoding considerations or skip it at all ( I personally like 2nd variant). I believe we'll need this section, and the contents is fine; after all, this is what you have to think of with respect to I18N, no? > ... Best regards, Julian From evnikita2@gmail.com Fri Jul 1 08:39:56 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFF79E8086; Fri, 1 Jul 2011 08:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 0Hk8CqJ2oLyu; Fri, 1 Jul 2011 08:39:55 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3110B9E8083; Fri, 1 Jul 2011 08:39:54 -0700 (PDT) Received: by fxe4 with SMTP id 4so4244312fxe.27 for ; Fri, 01 Jul 2011 08:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qwuOnsQgA9V0qfwIJr82FvuWX5gji9pwEFm3mg+vDns=; b=Ntqld7et1hcl8awsZLAAhlm8rh/tdVs1O9KuURzkG4tXOP7iS6slVle8sxJ7+CGS+s jm/n34ImKLFe/FZp5SuZXeFxKnWfIWsyu9FUapFNGtRQgRyS0q3bA0oWn1f7ch/5qZgS oG8xisxIElHqFYh7Xi0XpmAUGztGps7m8Eqao= Received: by 10.223.7.150 with SMTP id d22mr4928608fad.17.1309534794228; Fri, 01 Jul 2011 08:39:54 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id k26sm2436351fak.24.2011.07.01.08.39.52 (version=SSLv3 cipher=OTHER); Fri, 01 Jul 2011 08:39:53 -0700 (PDT) Message-ID: <4E0DEA77.3050007@gmail.com> Date: Fri, 01 Jul 2011 18:40:39 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Julian Reschke References: <4E083D3F.6030200@gmx.de> <4E0D3EA5.7010803@gmail.com> <4E0DCFEF.20206@gmx.de> In-Reply-To: <4E0DCFEF.20206@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss , "link-relations@ietf.org" Subject: Re: [apps-discuss] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 15:39:56 -0000 01.07.2011 16:47, Julian Reschke wrote: > On 2011-07-01 05:27, Mykyta Yevstifeyev wrote: >> Hello Maile, >> >> Several comments to your draft-ohye-canonical-link-relation-00. >> >> There is the Intended Status missing in it. I suppose Informational >> should be fine. > > We do not need to decide this now, and I expect the Area Director > who's going to sponsor this to have an opinion on it. > > That being said, "Informational" should be fine (Maile: that would be > category="info" on the element). So, we both agree on this. > >>> 1. Introduction >>> >>> The canonical link relation specifies the preferred version of a URI >> I think some introductory text on linking, probably based on RFC 5988, >> should go here. > > Why? It defines a link relation as defined by RFC 5988, so why repeat > text from over there? It should be mentioned (1) what is link relation at all and (2) that RFC 5988 is a specification of that technology which this document depends on. RFC 5988 is first mentioned in Examples. > >> Section 2: >> >>> Presence of the canonical link relation indicates >>> to applications, such as search engines, that they MAY: >> I wonder why it's MAY; in this case implementations (explicitly, those >> apps which interpret Link: headers and corresponding construction in >> HTML) will be free to ignore it. I think normative SHOULD should be OK >> (sorry for pun). > > I think this link relation is purely advisory, so a better approach > might be to replace "MAY" by "can". Yes, advisory, which suits RFC 2119 definition for SHOULD: > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. and natural meaning of should - advice/recommendation. > >> ... >>> The value of the target/canonical URI MAY: >> I suppose omitting "value of the" should be better, since there is no >> such term in RFC 3986. In fact, when referring the URI, we mean its >> value, meaning. > > Yes. > >>> o Exist on a different protocol: http to https, or vice versa >> You probably meant URI scheme here, since https isn't a separate >> protocol. As before these points we had "The value of the >> target/canonical URI MAY" or, if you consider my comment above, "The >> target/canonical URI MAY", this point may be reworded as "Have different >> scheme names" (which suits the second variant of a preface to this list >> better). > > Sounds good. I didn't mentioned it also applies to (Section 3, last list): > The value of the target/canonical URI SHOULD NOT designate: > >> Reading section 3 and 5 of the draft, it seems that is mandates use of >> HTTP when referring to canonical URIs. And what is the situation when >> target URI is a 'ftp' or 'gopher' URI? Section 3 allows different scheme >> names in context/target URIs, if I understand it correctly. Therefore, >> unless it is deliberately, I think any mention of HTTP should be >> replaced by more generic regulations. > > Nope; I think the HTTP examples are very useful. But maybe we can have > an additional statement that the link relation isn't specific to HTTP. Currently we have normative reference to RFC 2616 and normative requirements with respect to HTTP. HTTP examples are OK; but it's redundant in Section 3. I suppose in Section 3 we may replace HTTP-related stuff with something in the way like: Old: > o The source URI of a "300 Multiple Choices" URI (Section 10.3.1 of > [RFC2616]) or a permanent redirect (Section 10.3.2 of [RFC2616]). New: > o The source URI, which defines a resource which provides choice > in different represntations of a given resource, ientified by > the context URI, or is a link which has been permanently replaced > by an other one. etc. > >>> 8. Internationalisation Considerations >>> >>> In designating a canonical URI, please see [RFC3986] for information >>> on URI encoding. >> URIs themselves are not internationalized, in terms of RFC 3536, which >> defined: >> >>> internationalization >>> >>> In the IETF, "internationalization" means to add or improve the >>> handling of non-ASCII text in a protocol. >> IRIs serve for this purpose. I recommend either to rename the section to >> Encoding considerations or skip it at all ( I personally like 2nd >> variant). > > I believe we'll need this section, and the contents is fine; after > all, this is what you have to think of with respect to I18N, no? RFC 5988 allows target and context URIs to be IRIs. Current draft has no provisions regarding this. However, the actual and current text matches encoding considerations better. Mykyta Yevstifeyev > >> ... > > Best regards, Julian > From julian.reschke@gmx.de Fri Jul 1 08:49:52 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA97A11E80E0 for ; Fri, 1 Jul 2011 08:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.399 X-Spam-Level: X-Spam-Status: No, score=-105.399 tagged_above=-999 required=5 tests=[AWL=-2.800, BAYES_00=-2.599, 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 jIZNSYlZ8MBn for ; Fri, 1 Jul 2011 08:49:52 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id CAE3111E80EC for ; Fri, 1 Jul 2011 08:49:51 -0700 (PDT) Received: (qmail invoked by alias); 01 Jul 2011 15:49:50 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp025) with SMTP; 01 Jul 2011 17:49:50 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/Gla8jlXvGmSgZceys2tghPsRNZiErTOdntfCcW/ QtCx5E+ZJFjALy Message-ID: <4E0DEC9C.3050004@gmx.de> Date: Fri, 01 Jul 2011 17:49:48 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mykyta Yevstifeyev References: <4E083D3F.6030200@gmx.de> <4E0D3EA5.7010803@gmail.com> <4E0DCFEF.20206@gmx.de> <4E0DEA77.3050007@gmail.com> In-Reply-To: <4E0DEA77.3050007@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Apps Discuss , "link-relations@ietf.org" Subject: Re: [apps-discuss] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 15:49:52 -0000 On 2011-07-01 17:40, Mykyta Yevstifeyev wrote: > ... >> I believe we'll need this section, and the contents is fine; after >> all, this is what you have to think of with respect to I18N, no? > RFC 5988 allows target and context URIs to be IRIs. Current draft has no > provisions regarding this. However, the actual and current text matches > encoding considerations better. > ... Actually, there's nothing special about the I18N for this link relation; so I believe the text should just state that there's nothing to say in addition to RFC 5988, Section 8. Best regards, Julian From evnikita2@gmail.com Fri Jul 1 08:53:45 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD1111E8121; Fri, 1 Jul 2011 08:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 vPhEMyRD+o7a; Fri, 1 Jul 2011 08:53:44 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1AB11E80FD; Fri, 1 Jul 2011 08:53:44 -0700 (PDT) Received: by fxe4 with SMTP id 4so4259635fxe.27 for ; Fri, 01 Jul 2011 08:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=9QFGGYjIP9xzcz3spwUKDP5MYXZlgyIepeUQXAiNMsY=; b=k8K2xk+lP78uG9DVl9y5Jsk/vZ372da9MMfMjJtKHbL5GDfQGFrWTXvTEqdYdrl3pW 8TGQVBq7Q9GiPzP9idN+/9bnh/wu47hSEVAz4Bwpv9MKrhbzNrMCaf8jFHLW5XLFwKTq OlO+b/uHPrRKiymMPJ+J5F2OBj36o3roM881E= Received: by 10.223.44.86 with SMTP id z22mr1371744fae.3.1309535616911; Fri, 01 Jul 2011 08:53:36 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id h28sm2448465faj.5.2011.07.01.08.53.35 (version=SSLv3 cipher=OTHER); Fri, 01 Jul 2011 08:53:36 -0700 (PDT) Message-ID: <4E0DEDAE.80609@gmail.com> Date: Fri, 01 Jul 2011 18:54:22 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Julian Reschke References: <4E083D3F.6030200@gmx.de> <4E0D3EA5.7010803@gmail.com> <4E0DCFEF.20206@gmx.de> <4E0DEA77.3050007@gmail.com> <4E0DEC9C.3050004@gmx.de> In-Reply-To: <4E0DEC9C.3050004@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss , "link-relations@ietf.org" Subject: Re: [apps-discuss] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 15:53:45 -0000 01.07.2011 18:49, Julian Reschke wrote: > On 2011-07-01 17:40, Mykyta Yevstifeyev wrote: >> ... >>> I believe we'll need this section, and the contents is fine; after >>> all, this is what you have to think of with respect to I18N, no? >> RFC 5988 allows target and context URIs to be IRIs. Current draft has no >> provisions regarding this. However, the actual and current text matches >> encoding considerations better. >> ... > > Actually, there's nothing special about the I18N for this link > relation; so I believe the text should just state that there's nothing > to say in addition to RFC 5988, Section 8. Probably such approach is OK. Mykyta > > Best regards, Julian > From ajs@anvilwalrusden.com Fri Jul 1 09:24:24 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279851F0C88 for ; Fri, 1 Jul 2011 09:24:24 -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 FpEL2C2vQzqK for ; Fri, 1 Jul 2011 09:24:23 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id A8F5F1F0C79 for ; Fri, 1 Jul 2011 09:24:23 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 046F11ECB422 for ; Fri, 1 Jul 2011 16:24:20 +0000 (UTC) Date: Fri, 1 Jul 2011 12:24:17 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20110701162416.GB24564@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [apps-discuss] Review of draft-ietf-appsawg-rfc3536bis-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 16:24:24 -0000 Dear colleagues, As usual, a day late and a dollar short, but I have reviewed draft-ietf-appsawg-rfc3536bis-04. I support its publication. I have some items that might conceivably be addressed, but I don't think any of them is a show-stopper. I sent nits I observed directly to the WG draft editors. First, in section 1.1, we have this: The definitions here should be used by IETF standards that want to use them. IETF standards that explicitly want to create different definitions for the terms defined here can do so, but the terms here should be considered the default for IETF standards after the time of publication of this document. Obviously, the draft can't constrain what other documents might do. But it would be nice to encourage other documents, if they're going to come up with different definitions, to use different words. If someone decided to re-define SHOULD at the beginning of their standards document, we would quite justifiably complain, & I think the same goes here. I suggest the following additional sentence: IETF standards that want different definitions are encouraged, for clarity's sake, to find terms different to the ones defined here. Second, why isn't "LDH label" in section 7 instead of section 6, especially since LDH is also mentioned at the beginning of section 7? The last sentence of the first paragraph of section 8 says, "It is likely that additional terms will be added as this document matures." Presumably, if the draft is published that sentence should be removed. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From paul.hoffman@vpnc.org Fri Jul 1 12:29:03 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA419E8014 for ; Fri, 1 Jul 2011 12:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, 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 fIzGUIDt6KII for ; Fri, 1 Jul 2011 12:29:02 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC229E800C for ; Fri, 1 Jul 2011 12:29:02 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p61JSra2060812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Jul 2011 12:28:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20110701162416.GB24564@shinkuro.com> Date: Fri, 1 Jul 2011 12:28:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110701162416.GB24564@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1084) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-rfc3536bis-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 19:29:03 -0000 Answering one of the questions (the others seemed fine). On Jul 1, 2011, at 9:24 AM, Andrew Sullivan wrote: > Second, why isn't "LDH label" in section 7 instead of section 6, > especially since LDH is also mentioned at the beginning of section 7? Because the definition of LDH label in section 6 is the pre-IDNA = definition, not tied to IDNA. It seemed appropriate there because other = protocols also think in terms of "what characters are seen in host = names". --Paul Hoffman From john-ietf@jck.com Fri Jul 1 13:00:10 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A949E805F for ; Fri, 1 Jul 2011 13:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 z4LH+h5jSu-a for ; Fri, 1 Jul 2011 13:00:09 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 871E69E8050 for ; Fri, 1 Jul 2011 13:00:09 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Qcjsm-0006Nc-75; Fri, 01 Jul 2011 16:00:08 -0400 Date: Fri, 01 Jul 2011 16:00:07 -0400 From: John C Klensin To: Andrew Sullivan , apps-discuss@ietf.org Message-ID: <148089D7A073E8A4A9F54B64@PST.JCK.COM> In-Reply-To: <20110701162416.GB24564@shinkuro.com> References: <20110701162416.GB24564@shinkuro.com> 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: Re: [apps-discuss] Review of draft-ietf-appsawg-rfc3536bis-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 20:00:10 -0000 --On Friday, July 01, 2011 12:24 -0400 Andrew Sullivan wrote: > Dear colleagues, > > As usual, a day late and a dollar short, but I have reviewed > draft-ietf-appsawg-rfc3536bis-04. I support its publication. > I have some items that might conceivably be addressed, but I > don't think any of them is a show-stopper. I sent nits I > observed directly to the WG draft editors. Thanks for the nits. A few comments on your comments below, with the understanding that we are waiting for detailed feedback from the IESG at this stage (and that Paul has the pen on this cycle). > First, in section 1.1, we have this: > The definitions here should be used by IETF standards that > want to use them. IETF standards that explicitly want to > create different definitions for the terms defined here can > do so, but the terms here should be considered the default > for IETF standards after the time of publication of this > document. > > Obviously, the draft can't constrain what other documents > might do. But it would be nice to encourage other documents, > if they're going to come up with different definitions, to use > different words. If someone decided to re-define SHOULD at > the beginning of their standards document, we would quite > justifiably complain, & I think the same goes here. I suggest > the following additional sentence: > IETF standards that want different definitions are > encouraged, for clarity's sake, to find terms different to > the ones defined here. In drafts of this document up this stage, we have tried to preserve the informative/ descriptive/ persuasive tone of RFC 3536 while pushing in the direction I think you are encouraging. Some IESG members have pointed out that the document doesn't sound normative enough to be a BCP. In retrospect, trying to circle around the issue (for which I am more to blame than Paul) was probably unwise. Depending on what the IESG has to say (i.e., what Pete tells us), we are contemplating rewriting that explanation into RFC 2119 language and simply saying that these definitions SHOULD be used in IETF documents and that, if people choose to not use them, they MUST define the terms they are using exactly and preferably use terminology that does not overlap. Your thoughts on whether that is a good strategy would be welcome. > Second, why isn't "LDH label" in section 7 instead of section > 6, especially since LDH is also mentioned at the beginning of > section 7? Sort of a judgment call. Remember that "LDH label" and its variants have been used pretty extensively in non-IDN DNS terminology to describe labels that meet the "preferred name syntax" criteria of RFC 1034, i.e., to distinguish those preferred-syntax strings from binary labels and ASCII labels that contain spaces, symbols, or C0 characters. The term was invented when it became clear that "hostname" was sometimes used as a synonym for the preferred name syntax, sometimes to refer to the first label component of an FQDN, and sometimes to refer to an FQDN that was associated with certain RR types. "LDH label" is at least clear about which of those cases is intended. Speaking personally (I haven't consulted Paul), my preference for this term and a few others would be to take the definition out of this document entirely, instead referring to a document that provide normative definitions for terminology used with the DNS. If such a document existed, those terms in this document could be reduced to a list and a reference, much like the list in Section 7.1. I can only offer my condolences on the state of that document, but holding 3536bis (or anything else) up waiting for it seems unwise. > The last sentence of the first paragraph of section 8 says, > "It is likely that additional terms will be added as this > document matures." Presumably, if the draft is published that > sentence should be removed. Although it could be read as anticipating further revisions to this document over the long term, I agree that it is confusing at best. best, john From presnick@qualcomm.com Fri Jul 1 19:30:53 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1BBD21F8D51 for ; Fri, 1 Jul 2011 19:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.239 X-Spam-Level: X-Spam-Status: No, score=-106.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 qUMbJP6tvkmX for ; Fri, 1 Jul 2011 19:30:53 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id DF0A321F8D50 for ; Fri, 1 Jul 2011 19:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1309573852; x=1341109852; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4E0E82D0.6040003@qualcomm.com>|Date:=20Fr i,=201=20Jul=202011=2021:30:40=20-0500|From:=20Pete=20Res nick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20John=20C=20Klensin=20|CC:=20Andrew=20Sullivan=20,=20,=20Paul=0D=0A=20Hoffman =20|Subject:=20Re:=20[apps-discuss]=20R eview=20of=20draft-ietf-appsawg-rfc3536bis-04|References: =20<20110701162416.GB24564@shinkuro.com>=20<148089D7A073E 8A4A9F54B64@PST.JCK.COM>|In-Reply-To:=20<148089D7A073E8A4 A9F54B64@PST.JCK.COM>|Content-Type:=20text/plain=3B=20cha rset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.48.1]; bh=SUB4iw2COcsX1ansbGuf/i98qTSLZVwRe4sXKrZCaoA=; b=OTqsldgW4ACaL/bS7bkEQLglaI7ht+xkU/JOx+l1NmP/OF+Tbp8WmKNx 7mds3Ov7pLjkX2A98Wecnz5Nr3iXieZjgWxHRvQbr9ZR1nF0wWEo93pI6 XrqinGDPuRMeXk70Rfd1C1a1pCWxAHbI2htO2ept0HPnGfEYlxwAEW21d 8=; X-IronPort-AV: E=McAfee;i="5400,1158,6394"; a="101259448" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 01 Jul 2011 19:30:52 -0700 X-IronPort-AV: E=Sophos;i="4.65,461,1304319600"; d="scan'208";a="153156606" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 01 Jul 2011 19:30:52 -0700 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 1 Jul 2011 19:30:43 -0700 Message-ID: <4E0E82D0.6040003@qualcomm.com> Date: Fri, 1 Jul 2011 21:30:40 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: John C Klensin References: <20110701162416.GB24564@shinkuro.com> <148089D7A073E8A4A9F54B64@PST.JCK.COM> In-Reply-To: <148089D7A073E8A4A9F54B64@PST.JCK.COM> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: Paul Hoffman , apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-rfc3536bis-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 02:30:53 -0000 On 7/1/11 3:00 PM, John C Klensin wrote: > --On Friday, July 01, 2011 12:24 -0400 Andrew Sullivan > wrote: > > >> Obviously, the draft can't constrain what other documents >> might do. But it would be nice to encourage other documents, >> if they're going to come up with different definitions, to use >> different words. If someone decided to re-define SHOULD at >> the beginning of their standards document, we would quite >> justifiably complain,& I think the same goes here. I suggest >> the following additional sentence: >> >> IETF standards that want different definitions are >> encouraged, for clarity's sake, to find terms different to >> the ones defined here. >> > In drafts of this document up this stage, we have tried to > preserve the informative/ descriptive/ persuasive tone of RFC > 3536 while pushing in the direction I think you are encouraging. > Some IESG members have pointed out that the document doesn't > sound normative enough to be a BCP. In retrospect, trying to > circle around the issue (for which I am more to blame than Paul) > was probably unwise. Depending on what the IESG has to say > (i.e., what Pete tells us), we are contemplating rewriting that > explanation into RFC 2119 language and simply saying that these > definitions SHOULD be used in IETF documents and that, if people > choose to not use them, they MUST define the terms they are > using exactly and preferably use terminology that does not > overlap. > As I have mentioned to Paul offline, there was some pretty stiff pushback on this being BCP. Some of it was of the form, "You haven't said it strongly enough" (like Dan's DISCUSS comment, where he and others would *prefer* this document to be a BCP), and I think with some changes, those folks are right on board. There are other ADs (nominally Russ, though there are others who support his position) who felt that in no event was a glossary the appropriate sort of thing for BCP status; it is replacing an existing Informational document, and it isn't clear that glossaries are appropriate for BCPs. RFC 2026 is not at all precise on this; the only category of BCP this could really fall under is if this is meant to "document the operation of the IETF itself", which means to me that it is a "documentation procedure" (i.e., "we shall use these definitions"). The IETF has a perfectly mixed record on whether glossaries are BCP Informational, so precedents are unclear, the extremes being RFC 2119 (a BCP that defined several terms for use in IETF documents as normative protocol interoperability statements) and RFC 2828 (an Informational document that has a nice list of security terms and their definitions, but their use is strictly informational). As I suggested, Paul has already written to the IESG some explanation of why this document ought to be a BCP. I encourage the document editors to continue that discussion. Important to the discussion is why you think it is necessary and justified that this document to be a BCP instead of an Informational RFC. This document will at the very least be published as Informational. But I have put it back on the next IESG telechat to continue the conversation. On 14 July, we're going to make a call one way or the other. Please complete your discussion before then. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From evnikita2@gmail.com Fri Jul 1 21:06:07 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D6421F8535; Fri, 1 Jul 2011 21:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 r+5rg8r9oVTZ; Fri, 1 Jul 2011 21:06:07 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id A8CE411E8070; Fri, 1 Jul 2011 21:06:06 -0700 (PDT) Received: by fxe4 with SMTP id 4so4692721fxe.27 for ; Fri, 01 Jul 2011 21:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=A8YLEkQbL4qleIbh8VbpVN+jWEQ/O/NpZ25EuzOVV1o=; b=q2QtK2J9G0zrgVILP6f87WOCTsQ8yOulm3/QaUbdXFPtM9abhiFl1kV2UlnrduUzJT l7VUrtsOeSxZQfHTAmV7rlxEHzJcAcwyD0VV51nccoJiiWi1BC4pVIgbobGkyHq7blWf F+vQW9nOujbURGRCebitAQ5vUwG7/eM9e5WO4= Received: by 10.223.69.65 with SMTP id y1mr5939296fai.60.1309579565624; Fri, 01 Jul 2011 21:06:05 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id m26sm2793357fab.34.2011.07.01.21.06.03 (version=SSLv3 cipher=OTHER); Fri, 01 Jul 2011 21:06:04 -0700 (PDT) Message-ID: <4E0E995A.7060800@gmail.com> Date: Sat, 02 Jul 2011 07:06:50 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Bjartur Thorlacius References: <4E083D3F.6030200@gmx.de> <4E0D3EA5.7010803@gmail.com> <4E0DCFEF.20206@gmx.de> <4E0DEA77.3050007@gmail.com> <4E0E0E76.2080007@gmail.com> In-Reply-To: <4E0E0E76.2080007@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF Apps Discuss , "link-relations@ietf.org" Subject: Re: [apps-discuss] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 04:06:07 -0000 01.07.2011 21:14, Bjartur Thorlacius wrote: > ann fs 1.jl 2011 15:40, skrifai Mykyta Yevstifeyev: >> Old: >>> o The source URI of a "300 Multiple Choices" URI (Section 10.3.1 of >>> [RFC2616]) or a permanent redirect (Section 10.3.2 of [RFC2616]). >> New: >>> o The source URI, which defines a resource which provides choice >>> in different represntations of a given resource, ientified by >>> the context URI, or is a link which has been permanently replaced >>> by an other one. >> etc. > Your wording seems overly confusing. Which is the resource that > "provides choice in different represntations of a given resource?" A > standard could be assigned the URI . An HTTP > GET /spec might be responded with an HTTP/1.1 300 choice, and an > entity linking to /spec.node.html, /spec.html, /spec.pdf, and > /spec.txt. The resource (the standard, that is) would in no way > provide this choice. The HTTP server simply offered multiple > representations. First, this was an example only. Next, my point was that the document makes HTTP/'http' scheme mandatory in context/target URIs, which I don't think is appropriate, since canonical URI may refer to a resource accessible via other protocol. Even though HTTP is going to be the most often use case of canonical link relation, we shouldn't exclude other protocols. Mykyta From sm@resistor.net Sat Jul 2 01:15:01 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0735A21F8844 for ; Sat, 2 Jul 2011 01:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 xfdXqElbQcp3 for ; Sat, 2 Jul 2011 01:14:58 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C66621F8842 for ; Sat, 2 Jul 2011 01:14:58 -0700 (PDT) Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p628EnMp027147; Sat, 2 Jul 2011 01:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1309594495; bh=unSLzvD9upX+mjh5TW/S95Jb33lcfN8At+hO2JuJpYs=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=aonXLeRL9e4HnXL3OkidUTci3d8UKM7ls2SjBu5qQ6FyH4z8/aLNuzaKJTIxmvjT0 iWpA6d3KjVGASE7ojbVdbq3RSVAIlJJbAQJg8PbSnN/4f0kWuYA6Co4OttVOrxIzbB 2xoijdZYTuLCfxj98+9Tb9OfEg4OLf8aNZNVO4C8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1309594495; bh=unSLzvD9upX+mjh5TW/S95Jb33lcfN8At+hO2JuJpYs=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=T2zd008e1li8uVtKg41lmok1LABdUye8NTFxNh28cqpIASv0XfqhhQPFX1hFG/aif m7sK4NG6bUL1KBMG93UgNqvkHsRUvxQY34e93/SBfcqJYHxKQCnzGCB2DcEgOf17Sv rFE+svZ5K7qTc3FOZAXya2hwxUrZB4HpHGUbkN94= Message-Id: <6.2.5.6.2.20110701233438.0272df28@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 02 Jul 2011 01:10:24 -0700 To: apps-discuss@ietf.org From: SM In-Reply-To: <4E0E82D0.6040003@qualcomm.com> References: <20110701162416.GB24564@shinkuro.com> <148089D7A073E8A4A9F54B64@PST.JCK.COM> <4E0E82D0.6040003@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Paul Hoffman Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-rfc3536bis-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 08:15:01 -0000 At 19:30 01-07-2011, Pete Resnick wrote: >As I have mentioned to Paul offline, there was some pretty stiff >pushback on this being BCP. Some of it was of the form, "You haven't >said it strongly enough" (like Dan's DISCUSS comment, where he and >others would *prefer* this document to be a BCP), and I think with >some changes, those folks are right on board. There are other ADs >(nominally Russ, though there are others who support his position) >who felt that in no event was a glossary the appropriate sort of >thing for BCP status; it is replacing an existing Informational >document, and it isn't clear that glossaries are appropriate for >BCPs. RFC 2026 is not at all precise on this; the only category of >BCP this could really fall under is if this is meant to "document >the operation of the IETF itself", which means to me that it is a >"documentation procedure" (i.e., "we shall use these definitions"). >The IETF has a perfectly mixed record on whether glossaries are BCP >Informational, so precedents are unclear, the extremes being RFC >2119 (a BCP that defined several terms for use in IETF documents as >normative protocol interoperability statements) and RFC 2828 (an >Informational document that has a nice list of security terms and >their definitions, but their use is strictly informational). Section 1.1 mentions the following as one of the purposes of the document: "The definitions here should be used by IETF standards that want to use them. IETF standards that explicitly want to create different definitions for the terms defined here can do so, but the terms here should be considered the default for IETF standards after the time of publication of this document. Some of the definitions in this document come from many earlier IETF documents and books." Would rewriting the above as: "The definitions here SHOULD be used by IETF standards that want to use them. IETF standards that explicitly want to create different definitions for the terms defined here can do so, but the terms here MUST be considered the default for IETF standards after the time of publication of this document. Some of the definitions in this document come from many earlier IETF documents and books." make this BCP material? The purpose of BCP 161 is to provide a definition of a term for use in all future IETF documents that refer to the term. The difference between that BCP and this draft is that the title does not say "Guidelines". BCP are meant to express community consensus. In other words, it can be view as "these are the terms that have been used in discussions about internationalization; and the IETF agrees that these terms are the default as from the date of publication of this draft. If a test was required to determine whether the draft should qualify as BCP, I suggest the following: Is there disagreement in the IETF community on the definitions used? Is there a sense of rough agreement in the internationalization community on the definitions used? The last question is to avoid a disconnect between the IETF and reality. The DISCUSS raised by Dan Romascanu could be addressed by having Section 1.1 cover what has changed since RFC 3536. BTW, "IETF members" (Section 6) should be changed to "IETF participants". As it (the draft) stands, I don't see a strong case for a fight about the intended status. Regards, -sm From john-ietf@jck.com Sat Jul 2 01:34:02 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D4E21F88C8 for ; Sat, 2 Jul 2011 01:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 LOBAg-rWp7Q5 for ; Sat, 2 Jul 2011 01:34:01 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id A900B21F88C7 for ; Sat, 2 Jul 2011 01:34:00 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QcveB-000GsV-Sy; Sat, 02 Jul 2011 04:33:52 -0400 Date: Sat, 02 Jul 2011 04:33:50 -0400 From: John C Klensin To: Pete Resnick Message-ID: <9DF5D6721C7098CB2DE51B0B@PST.JCK.COM> In-Reply-To: <4E0E82D0.6040003@qualcomm.com> References: <20110701162416.GB24564@shinkuro.com> <148089D7A073E8A4A9F54B64@PST.JCK.COM> <4E0E82D0.6040003@qualcomm.com> 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 , apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-rfc3536bis-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 08:34:02 -0000 Pete, Having been somewhat involved as a member of the Editorial Board, one bit of clarification, which might be relevant to the IESG's considerations, followed by a review of the situation from my perspective. --On Friday, July 01, 2011 21:30 -0500 Pete Resnick wrote: >... > As I have mentioned to Paul offline, there was some pretty > stiff pushback on this being BCP. Some of it was of the form, > "You haven't said it strongly enough" (like Dan's DISCUSS > comment, where he and others would *prefer* this document to > be a BCP), and I think with some changes, those folks are > right on board. There are other ADs (nominally Russ, though > there are others who support his position) who felt that in no > event was a glossary the appropriate sort of thing for BCP > status; it is replacing an existing Informational document, > and it isn't clear that glossaries are appropriate for BCPs. > RFC 2026 is not at all precise on this; the only category of > BCP this could really fall under is if this is meant to > "document the operation of the IETF itself", which means to me > that it is a "documentation procedure" (i.e., "we shall use > these definitions"). > The IETF has a perfectly mixed record on > whether glossaries are BCP Informational, so precedents are > unclear, the extremes being RFC 2119 (a BCP that defined > several terms for use in IETF documents as normative protocol > interoperability statements) and RFC 2828 (an Informational > document that has a nice list of security terms and their > definitions, but their use is strictly informational). The use of 2828 as an example takes "odd" to a new level. My recollection was that it was very contentious at the time and that it was published as Informational (rather than as a BCP or Standards Track), not because of some philosophical understanding of the difference among those categories but because it was clear that consensus on the definitions could not be achieved for Standards Track (or BCP) publication. Perhaps more important, 2828 is identified as "Obsoleted by RFC4949". Under normal circumstances, the IETF does not look to obsolescent documents for precedents. When Rob decided to expand and replace 2828 a few years later -- my recollection is that the revision and review process took a long time, probably several years -- the IESG concluded that it should be handled through what we now call the Independent Stream, precisely to avoid a review process in the IETF that would not only be contentious but that would have the characteristic that no one, including Rob, would support all of the definitions. Even as an Independent Submission, it was clear that 4949 was going to be contentious enough that it carries, in its "RFC Editor Note", what I believe is the strongest disclaimer used by the RFC Editor on an Independent Submission prior to RFC 5741. I also note that, while it was published as an Independent Submission, the IESG decided to classify it as FYI 36. Probably the FYI series actually was the right place to publish glossaries, but the IESG has, in its wisdom, eliminated that series. Some portion of the reason why 3536 was published as Informational was a little bit similar to the consensus problem that occurred with 2828 and then with 4949. Some of these definitions are, IMO, detestable (the circularity in the definition of "glyph" is a good example). Large fractions of the linguistic and typographic communities considered the use of "Latin" to include characters that neither the Romans of the late Republic nor medieval scribes had ever seen to be a contemptible exhibition of ignorance. Some members of the community (myself included) felt quite strongly that the usage of those terms had not stabilized enough that the IETF should attach strong and formal approval to them. Eight years later, the use of these terms has stabilized sufficiently --become routine and common practice in the community-- that Paul and I were able to collaborate fairly painlessly on the current draft. There are still terms I don't like, and presumably terms he doesn't like, but we have no trouble agreeing on the state of current practice. Questions about the competence of definitions that originated in other standards bodies and that are very widely used notwithstanding, these definitions do have relatively strong consensus (not just in theory but in use) within the community in the IETF that is actively working on internationalization issues. Oddly, that is precisely the reason why this revision is important at this time and that it is important that it be treated as a normative part of how the IETF does business and writes documents. Within the portion of the community who actively work in i18n, there is substantially no disagreement about terminology and the educated but often intuitive definitions of terms are harmonious if not identical. But the number of development efforts (WG and non-WG) that will find themselves dealing with i18n issues is on the rise and will continue to rise. Efforts to reinvent and rediscover this terminology, especially by people who are not familiar with the relevant literature (comments like "just tell me what to do, don't expect me to read that 5.5 cm thick Unicode thing" remain very prevalent) are a waste of time at best and, at worst, may lead to more confusion in the future. This is the time for the IETF to take a strong position on the terminology and its applicability, precisely to avoid ending up in the situations that motivated the Informational status of 2828 and the ability to handle 4949 only as an Independent Submission. > As I suggested, Paul has already written to the IESG some > explanation of why this document ought to be a BCP. I > encourage the document editors to continue that discussion. > Important to the discussion is why you think it is necessary > and justified that this document to be a BCP instead of an > Informational RFC. Obviously, feel free to circulate all or parts of this note if you think that would be useful. best, john From evnikita2@gmail.com Sat Jul 2 06:17:35 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5058621F860F; Sat, 2 Jul 2011 06:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 uYz8v4zBxSI7; Sat, 2 Jul 2011 06:17:34 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 761EE21F85E0; Sat, 2 Jul 2011 06:17:34 -0700 (PDT) Received: by fxe4 with SMTP id 4so4945393fxe.27 for ; Sat, 02 Jul 2011 06:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ebmIVJG1PZiNupQrVBmhMmxUszakiD7UEotJ6mfsMzs=; b=MoDYOrAk9eF1EL3CKSY7u8SsPVlT/rwMN9aHGWA6Bo6wtlESW3VF43bRQds/te6Kir /QCvE22muN74xqBTXX1mRMaKOyBs3PET9GaBMVU7qUuBbljm6J6RLLUCSdr8SWuknCFh BNXFJfiiQTyMD8rHgpko02YBYEQ/6ISmRm/Po= Received: by 10.223.36.89 with SMTP id s25mr6502898fad.9.1309612649047; Sat, 02 Jul 2011 06:17:29 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id g12sm3080608fai.8.2011.07.02.06.17.27 (version=SSLv3 cipher=OTHER); Sat, 02 Jul 2011 06:17:27 -0700 (PDT) Message-ID: <4E0F1A95.2030701@gmail.com> Date: Sat, 02 Jul 2011 16:18:13 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Bjartur Thorlacius References: <4E083D3F.6030200@gmx.de> <4E0D3EA5.7010803@gmail.com> <4E0DCFEF.20206@gmx.de> <4E0DEA77.3050007@gmail.com> <4E0E0E76.2080007@gmail.com> <4E0E995A.7060800@gmail.com> <4E0F1058.3050201@gmail.com> In-Reply-To: <4E0F1058.3050201@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF Apps Discuss , "link-relations@ietf.org" Subject: Re: [apps-discuss] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 13:17:35 -0000 02.07.2011 15:34, Bjartur Thorlacius wrote: > ann lau 2.jl 2011 04:06, skrifai Mykyta Yevstifeyev: >> First, this was an example only. Next, my point was that the document >> makes HTTP/'http' scheme mandatory in context/target URIs, which I don't >> think is appropriate, since canonical URI may refer to a resource >> accessible via other protocol. Even though HTTP is going to be the most >> often use case of canonical link relation, we shouldn't exclude other >> protocols. > I agree. However, I don't understand the need for forbidding canonical > links to resources with multiple representations. Are there not to be > canonical links from representations of a resource to the resource > (i.e. from /spec.html and /spec.txt to /spec)? Probably such restriction is set because multiple representation choice may ultimately refer the user to a resource which is not canonical. A _definite_ canonical resource is necessary and required. From evnikita2@gmail.com Sat Jul 2 06:37:10 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACA411E8074; Sat, 2 Jul 2011 06:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 uUj1EVfFhwzK; Sat, 2 Jul 2011 06:37:10 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 80F3011E8089; Sat, 2 Jul 2011 06:37:09 -0700 (PDT) Received: by fxe4 with SMTP id 4so4955579fxe.27 for ; Sat, 02 Jul 2011 06:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xryWNOQSE2KSpCLyF4cRZ/6WlL3Mtfm2s5PP3Toq4EM=; b=JDyKMz+Y2bfduI1avSPJa09ucgtImsfP3LpyntB/HWRKAgCMbzlPTwPlNHbao45Rl5 FVPC4ACsdBXcbPcAD82ttYnR2aGkMu9ku5Laid3uLtSmechAJ3Wf4DFUqSJECdI1CjXs cdzqoIzp4xZdetNeTV0ioMZvCXOhofybqAVH0= Received: by 10.223.143.17 with SMTP id s17mr6502993fau.34.1309613826349; Sat, 02 Jul 2011 06:37:06 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id r10sm3088455fah.26.2011.07.02.06.37.04 (version=SSLv3 cipher=OTHER); Sat, 02 Jul 2011 06:37:05 -0700 (PDT) Message-ID: <4E0F1F2F.8020504@gmail.com> Date: Sat, 02 Jul 2011 16:37:51 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Justin Cormack References: <4E083D3F.6030200@gmx.de> <4E0D3EA5.7010803@gmail.com> <4E0DCFEF.20206@gmx.de> <4E0DEA77.3050007@gmail.com> <4E0E0E76.2080007@gmail.com> <4E0E995A.7060800@gmail.com> <4E0F1058.3050201@gmail.com> <1309613470.2807.17.camel@mackerel> In-Reply-To: <1309613470.2807.17.camel@mackerel> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Bjartur Thorlacius , IETF Apps Discuss , "link-relations@ietf.org" Subject: Re: [apps-discuss] [link-relations] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 13:37:10 -0000 02.07.2011 16:31, Justin Cormack wrote: > There does seem to not be a discussion of what is similar though in > terms of media types - is /spec.txt similar enough that /spec.html could > be a canonical link? I personally think it is possible. For example, authoritative RFC source is .txt file on RFC Editor's site, while we have a number of other sources for RFCs, not in .txt, such as "tools.ietf.org/html/rfcXXXX" in HTML. Designating a "canonical" link to "http://www.rfc-editor.org/rfc/rfcXXXX.txt" seems to be OK. So I think we have no problem here. Mykyta > One could certainly have a PNG version of an SVG > image with a canonical link I would presume. > > Justin > From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Sat Jul 2 11:58:33 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086E81F0C51 for ; Sat, 2 Jul 2011 11:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 fX9LkbbpsWAW for ; Sat, 2 Jul 2011 11:58:32 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 804941F0C59 for ; Sat, 2 Jul 2011 11:58:32 -0700 (PDT) Received: by pvh18 with SMTP id 18so5013922pvh.31 for ; Sat, 02 Jul 2011 11:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=trTr+CqEQJ2WNL3L2aZh8Oq4MbR3qV2JhxLFsz1QbIE=; b=oT9pDq2he+vkgXM87jm3+eLyEM1qMIBiQFUqsD0VOoN6JlnaUYX9SRLW02ZClBlMwZ JP3mmVlKCpIDMMznb4P4OlilhACe36OIVz5SBeP9R4bvzMP9i66elunuUl9puUEtQa6/ a3WizO50dwWqvl24jAa0NdqsTUXeDjNQgqrbI= Received: by 10.142.186.18 with SMTP id j18mr360697wff.406.1309633112145; Sat, 02 Jul 2011 11:58:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.89.6 with HTTP; Sat, 2 Jul 2011 11:58:12 -0700 (PDT) In-Reply-To: <4E0DCDE4.5080903@gmx.de> References: <4E083D3F.6030200@gmx.de> <4E0DCDE4.5080903@gmx.de> From: Frank Ellermann Date: Sat, 2 Jul 2011 20:58:12 +0200 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF Apps Discuss Subject: Re: [apps-discuss] [link-relations] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 18:58:33 -0000 On 1 July 2011 15:38, Julian Reschke wrote: >> A relative canonical URL can't be a good idea. =A0If there is more than >> one "content URL" (in the terminology of the draft) this would result >> in more than one canonical URL, defeat the purpose, and worse, this >> could make googlebot angry. [...] > I don't understand (yet). > What do you mean by "more than one "content URL""? The rel=3D"canonical" business is for in essence identical content available at more than one URL. Simple example, resource xyzzy.html at http://example.com/xyzzy.hmtl and http://example.org/xyzzy.html With a relative rel=3D"canonical" URI in xyzzy.html I'd end up with two different canonical URLs, but then I shouldn't use rel=3D"canonical" in the first place. The idea is to get one canonical URL for all (here: both) incarnations of xyzyy.html. Well, that's what I meant. But now I see that relative can be perfectly fine if and only if all incarnations exist on the same server, e.g., http://example/xyzzy.html?any-query could get a relative canonical URL xyzzy.html?default or similar. A better example in the draft explaining when a relative canonical URL is okay could help. -Frank From svartman95@gmail.com Fri Jul 1 11:15:34 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137521F0CA1; Fri, 1 Jul 2011 11:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 2QRwiz9lzapr; Fri, 1 Jul 2011 11:15:33 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2053D1F0CB7; Fri, 1 Jul 2011 11:14:20 -0700 (PDT) Received: by wwe5 with SMTP id 5so2347373wwe.13 for ; Fri, 01 Jul 2011 11:14:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2wlEuiJbZ1eYxdFktYTwek7QjJuh3vcME7TbUCV0NP8=; b=iAFUcJj74ozBdAhtS1wvsjNT4FFQz/bgS5TDkCksQd88Pswmmg/TdiC00vSe8uVXka CQjXLv6EVY1UYwfoiM1d9TvRXQxQkylFaumbHezss8OspX3sPA1LtfRmOf880n/S9qVd 9M+yf/ZOQtZJeu+z3ili3KL1dYW+ebmOBBwIg= Received: by 10.227.13.146 with SMTP id c18mr3213171wba.5.1309544059954; Fri, 01 Jul 2011 11:14:19 -0700 (PDT) Received: from [192.168.1.64] (85-220-65-176.dsl.dynamic.simnet.is [85.220.65.176]) by mx.google.com with ESMTPS id gb1sm2518087wbb.54.2011.07.01.11.14.16 (version=SSLv3 cipher=OTHER); Fri, 01 Jul 2011 11:14:17 -0700 (PDT) Message-ID: <4E0E0E76.2080007@gmail.com> Date: Fri, 01 Jul 2011 18:14:14 +0000 From: Bjartur Thorlacius User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mykyta Yevstifeyev References: <4E083D3F.6030200@gmx.de> <4E0D3EA5.7010803@gmail.com> <4E0DCFEF.20206@gmx.de> <4E0DEA77.3050007@gmail.com> In-Reply-To: <4E0DEA77.3050007@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 02 Jul 2011 13:29:59 -0700 Cc: IETF Apps Discuss , "link-relations@ietf.org" Subject: Re: [apps-discuss] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 18:15:34 -0000 ann fs 1.jl 2011 15:40, skrifai Mykyta Yevstifeyev: > Old: >> o The source URI of a "300 Multiple Choices" URI (Section 10.3.1 of >> [RFC2616]) or a permanent redirect (Section 10.3.2 of [RFC2616]). > New: >> o The source URI, which defines a resource which provides choice >> in different represntations of a given resource, ientified by >> the context URI, or is a link which has been permanently replaced >> by an other one. > etc. Your wording seems overly confusing. Which is the resource that "provides choice in different represntations of a given resource?" A standard could be assigned the URI . An HTTP GET /spec might be responded with an HTTP/1.1 300 choice, and an entity linking to /spec.node.html, /spec.html, /spec.pdf, and /spec.txt. The resource (the standard, that is) would in no way provide this choice. The HTTP server simply offered multiple representations. From svartman95@gmail.com Sat Jul 2 05:34:37 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F84711E834E; Sat, 2 Jul 2011 05:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 piCgcswhJ88Z; Sat, 2 Jul 2011 05:34:37 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9B911E832D; Sat, 2 Jul 2011 05:34:36 -0700 (PDT) Received: by wyj26 with SMTP id 26so3078265wyj.31 for ; Sat, 02 Jul 2011 05:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8uW+OB7f37A2KU+4mJAXxPFU7QuDjsEyvnrxbd+iaOU=; b=OJ1duNBI1LrNMqrTI7nsLPUfQreRH52xtB5BTpOoYEOX8eED0MRiM5ph7CytLEiSsk 2LwwZk6nS8QuuZsZRnQohroiA/BuAi3zN80nintCttMiuO3tKCTvotcs81pKf3GAiDV4 j4VGYf0yg+aVYZ3uzBGbQo9XZT4VHjrXXzMTE= Received: by 10.227.183.143 with SMTP id cg15mr3835885wbb.24.1309610075622; Sat, 02 Jul 2011 05:34:35 -0700 (PDT) Received: from [192.168.1.64] (85-220-65-176.dsl.dynamic.simnet.is [85.220.65.176]) by mx.google.com with ESMTPS id et5sm2983334wbb.50.2011.07.02.05.34.33 (version=SSLv3 cipher=OTHER); Sat, 02 Jul 2011 05:34:34 -0700 (PDT) Message-ID: <4E0F1058.3050201@gmail.com> Date: Sat, 02 Jul 2011 12:34:32 +0000 From: Bjartur Thorlacius User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Julian Reschke References: <4E083D3F.6030200@gmx.de> <4E0D3EA5.7010803@gmail.com> <4E0DCFEF.20206@gmx.de> <4E0DEA77.3050007@gmail.com> <4E0E0E76.2080007@gmail.com> <4E0E995A.7060800@gmail.com> In-Reply-To: <4E0E995A.7060800@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 02 Jul 2011 13:29:59 -0700 Cc: IETF Apps Discuss , "link-relations@ietf.org" Subject: Re: [apps-discuss] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 12:35:20 -0000 ann lau 2.jl 2011 04:06, skrifai Mykyta Yevstifeyev: > First, this was an example only. Next, my point was that the document > makes HTTP/'http' scheme mandatory in context/target URIs, which I don't > think is appropriate, since canonical URI may refer to a resource > accessible via other protocol. Even though HTTP is going to be the most > often use case of canonical link relation, we shouldn't exclude other > protocols. I agree. However, I don't understand the need for forbidding canonical links to resources with multiple representations. Are there not to be canonical links from representations of a resource to the resource (i.e. from /spec.html and /spec.txt to /spec)? From justin@specialbusservice.com Sat Jul 2 06:31:15 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7238F21F8626; Sat, 2 Jul 2011 06:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Vl-5MgIAsY-N; Sat, 2 Jul 2011 06:31:12 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B08221F860F; Sat, 2 Jul 2011 06:31:11 -0700 (PDT) Received: by wwe5 with SMTP id 5so2663242wwe.13 for ; Sat, 02 Jul 2011 06:31:10 -0700 (PDT) Received: by 10.227.24.75 with SMTP id u11mr530555wbb.10.1309613470495; Sat, 02 Jul 2011 06:31:10 -0700 (PDT) Received: from [192.168.1.77] (188-220-243-64.zone11.bethere.co.uk [188.220.243.64]) by mx.google.com with ESMTPS id fi5sm3014026wbb.22.2011.07.02.06.31.08 (version=SSLv3 cipher=OTHER); Sat, 02 Jul 2011 06:31:09 -0700 (PDT) From: Justin Cormack To: Bjartur Thorlacius In-Reply-To: <4E0F1058.3050201@gmail.com> References: <4E083D3F.6030200@gmx.de> <4E0D3EA5.7010803@gmail.com> <4E0DCFEF.20206@gmx.de> <4E0DEA77.3050007@gmail.com> <4E0E0E76.2080007@gmail.com> <4E0E995A.7060800@gmail.com> <4E0F1058.3050201@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Sat, 02 Jul 2011 14:31:10 +0100 Message-ID: <1309613470.2807.17.camel@mackerel> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 02 Jul 2011 13:29:59 -0700 Cc: IETF Apps Discuss , "link-relations@ietf.org" Subject: Re: [apps-discuss] [link-relations] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 13:31:15 -0000 On Sat, 2011-07-02 at 12:34 +0000, Bjartur Thorlacius wrote: > Þann lau 2.júl 2011 04:06, skrifaði Mykyta Yevstifeyev: > I agree. However, I don't understand the need for forbidding canonical > links to resources with multiple representations. Are there not to be > canonical links from representations of a resource to the resource (i.e. > from /spec.html and /spec.txt to /spec)? I think this relation (which is useful) need to be called something else, as it is performing a different function to canonical, which is about relations between representations of resources, rather than between representations of resources and a the resource itself like /spec. There does seem to not be a discussion of what is similar though in terms of media types - is /spec.txt similar enough that /spec.html could be a canonical link? One could certainly have a PNG version of an SVG image with a canonical link I would presume. Justin From evnikita2@gmail.com Sat Jul 2 21:33:31 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5466211E808A; Sat, 2 Jul 2011 21:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 TwzuZwlZDtPw; Sat, 2 Jul 2011 21:33:29 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6295F11E8078; Sat, 2 Jul 2011 21:33:28 -0700 (PDT) Received: by fxe4 with SMTP id 4so5308512fxe.27 for ; Sat, 02 Jul 2011 21:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=GY4zPNRBXds6NeRYTvcFTZFhi3qGEbHUB9oM7R6RQTs=; b=mbMv/to7I33B46+OoVuEpAW+pvBf4hZyMsXp1jhpgHOh2DXFwviCFRQ7CkyYzkHvAK wTYJqN3kqt0Uz8peJlCHuLkuZFU4t+ywU93XPD6HmlQi4yBfzVyRn8eHmzUSqSe5zDiK 8oMiVv0SCwHR6GWpETdRFTec0HcvJjqibBfc4= Received: by 10.223.86.76 with SMTP id r12mr5046405fal.80.1309667607107; Sat, 02 Jul 2011 21:33:27 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id q14sm3529997faa.3.2011.07.02.21.33.24 (version=SSLv3 cipher=OTHER); Sat, 02 Jul 2011 21:33:25 -0700 (PDT) Message-ID: <4E0FF142.1010201@gmail.com> Date: Sun, 03 Jul 2011 07:34:10 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Maile Ohye References: <4E083D3F.6030200@gmx.de> <4E0D3EA5.7010803@gmail.com> <4E0DCFEF.20206@gmx.de> <4E0DEA77.3050007@gmail.com> <4E0E0E76.2080007@gmail.com> <4E0E995A.7060800@gmail.com> <4E0F1058.3050201@gmail.com> <1309613470.2807.17.camel@mackerel> <4E0F1F2F.8020504@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090803090709020501040906" Cc: Bjartur Thorlacius , Justin Cormack , joachim@kupke.za.net, IETF Apps Discuss , "link-relations@ietf.org" Subject: Re: [apps-discuss] [link-relations] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 04:33:31 -0000 This is a multi-part message in MIME format. --------------090803090709020501040906 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hello Maile, all, Let me response to my issues only. 03.07.2011 4:23, Maile Ohye wrote: > 3. CLOSED. M. Yevstifeyev: > There is the Intended Status missing in it. I suppose Informational > should be fine. > --seconded by J. Reschke > --added to draft by M. Ohye Thanks for this clarification. > > 4. OPEN. M. Yevstifeyev: > > The canonical link relation specifies the preferred version of a URI > I think some introductory text on linking, probably based on RFC 5988, > should go here. > --response by J. Reschke "Why? It defines a link relation as defined > by RFC 5988, so why repeat text from over there?" > --response by M. Yevstifeyev "It should be mentioned (1) what is link > relation at all and (2) that RFC 5988 is a specification of that > technology which this document depends on. RFC 5988 is first > mentioned in Examples." > --response by M. Ohye. We could modify to: > The canonical link relation (Link Relation Types reference target="RFC5988"/>) specifies the preferred version of a URI... I proposed to add something like: /"RFC 5988 [RFC5988] specified the mechanism which is used to indicate relationships between the links on the Internet. This document defined a new type of such relationships - canonical link relation."/ in Section 1 as 1st para; other paragraphs retain in this case. > > 5. OPEN. M. Yevstifeyev: > > Presence of the canonical link relation indicates to applications, > such as search engines, that they MAY: > I wonder why it's MAY; in this case implementations (explicitly, those > apps which interpret Link: headers and corresponding construction in > HTML) will be free to ignore it. I think normative SHOULD should be > OK (sorry for pun). > --response by J. Reschke "I think this link relation is purely > advisory, so a better approach might be to replace "MAY" by "can"." > --response by M. Yevstifeyev "Yes, advisory, which suits RFC 2119 > definition for SHOULD: 'SHOULD This word, or the adjective > "RECOMMENDED", mean that there may exist valid reasons in particular > circumstances to ignore a particular item, but the full implications > must be understood and carefully weighed before choosing a different > course.' > and natural meaning of should - advice/recommendation." > --response by M. Ohye: Thanks, in discussion with Joachim Kupke. Please notify on the list when this issue is resolved. > > 6. CLOSED. M. Yevstifeyev: > I suppose omitting "value of the" should be better, since there is no > such term in RFC 3986. In fact, when referring the URI, we mean its > value, meaning. > --agreed by J. Reschke > --updated in draft by M. Ohye (in two instances) Thanks for this. > > 7. OPEN. M. Yevstifeyev: > o Exist on a different protocol: http to https, or vice versa > You probably meant URI scheme here, since https isn't a separate > protocol. As before these points we had "The value of the > target/canonical URI MAY" or, if you consider my comment above, "The > target/canonical URI MAY", this point may be reworded as "Have > different scheme names" (which suits the second variant of a preface > to this list better). > --agreed by J. Reschke > --response by M. Ohye/J. Kupke: Good catch, Mykyta. Were fine to > change the draft to scheme: ... And for this correction :-) > Have different scheme names: such as http to https, or vice versa > Do we now need to expand the draft for ftp:// and gopher:// URIs? For > example, ftp:// and gopher:// URIs > 1) Do not come with the equivalent of RFC 5988, so a non-HTML document > available at any such URI won't be available to make use of rel="canonical">. > 2) Have corresponding GOPHER error code (item type 3) or an FTP error > 550, which like HTTP 404, is forbidden from being served for the > target of a . I don't think we should make such changes. If we consider ftp and gopher URIs, we should also consider all other. I proposed to add generic statements which would be applicable to almost all application protocols, not only HTTP, as in current version of the draft. > > 8. OPEN. M. Yevstifeyev: > Reading section 3 and 5 of the draft, it seems that is mandates use of > HTTP when referring to canonical URIs. And what is the situation when > target URI is a 'ftp' or 'gopher' URI? Section 3 allows different > scheme names in context/target URIs, if I understand it correctly. > Therefore, unless it is deliberately, I think any mention of HTTP > should be replaced by more generic regulations. > --response by J. Reschke "Nope; I think the HTTP examples are very > useful. But maybe we can have an additional statement that the link > relation isn't specific to HTTP." > --response by M. Yevstifeyev"Currently we have normative reference to > RFC 2616 and normative requirements with respect to HTTP. HTTP > examples are OK; but it's redundant in Section 3. I suppose in > Section 3 we may replace HTTP-related stuff with something in the way > like: > > Old: > o The source URI of a "300 Multiple Choices" URI (Section 10.3.1 of > [RFC2616]) or a permanent redirect (Section 10.3.2 of [RFC2616]). > New: > o The source URI, which defines a resource which provides choice > in different represntations of a given resource, ientified by > the context URI, or is a link which has been permanently replaced > by an other one. > etc." > --response by B. Thorlacius: Your wording seems overly confusing. > Which is the resource that "provides choice in different > represntations of a given resource?" A standard could be assigned the > URI . An HTTP GET /spec might be responded > with an HTTP/1.1 300 choice, and an entity linking to /spec.node.html, > /spec.html, /spec.pdf, and /spec.txt. The resource (the standard, that > is) would in no way provide this choice. The HTTP server simply > offered multiple representations. > --response by M. Yevstifeyev: First, this was an example only. Next, > my point was that the document makes HTTP/'http' scheme mandatory in > context/target URIs, which I don't think is appropriate, since > canonical URI may refer to a resource accessible via other protocol. > Even though HTTP is going to be the most often use case of canonical > link relation, we shouldn't exclude other protocols. > --response by B. Thorlacius: I agree. However, I don't understand the > need for forbidding canonical links to resources with multiple > representations. Are there not to be canonical links from > representations of a resource to the resource (i.e. from /spec.html > and /spec.txt to /spec)? > --response by M. Yevstifeyev: Probably such restriction is set > because multiple representation choice may ultimately refer the user > to a resource which is not canonical. A _definite_ canonical resource > is necessary and required. > > ----response by J. Cormack: I think this relation (which is useful) > need to be called something > > else, as it is performing a different function to canonical, which is > > about relations between representations of resources, rather than > > between representations of resources and a the resource itself > > like /spec. > > > There does seem to not be a discussion of what is similar though in > > terms of media types - is /spec.txt similar enough that /spec.html could > > be a canonical link? One could certainly have a PNG version of an SVG > > image with a canonical link I would presume. > > ------response by M. Yevstifeyev: I personally think it is possible. > For example, authoritative RFC source is .txt file on RFC Editor's > site, while we have a number of other sources for RFCs, not in .txt, > such as "tools.ietf.org/html/rfcXXXX > " in HTML. Designating a > "canonical" link to "http://www.rfc-editor.org/rfc/rfcXXXX.txt" seems > to be OK. So I think we have no problem here. > > --response by M. Ohye: We can change the draft to include > corresponding GOPHER or FTP error codes to demonstrate non-favortism > to HTTP. I don't think it would be useful (see above). It's better, as I've already mentioned in my response to (7), to provide rules which would be fine for almost any application protocol and which would be equivalent to those provided for HTTP now. For example: OLD: /"Be the source URI of a 302, 303, or 307 redirect (Sections 10.3.3, 10.3.4, and 10.3.8, respectively, of [RFC2616])."/ NEW: /"Provide a redirect to the other resource because it is temporarily unavailable."/ This is what HTTP 302 and 307 responses stand for. 303 response is used in HTTP only and here is no equivalent to it in other protocols. > > 9. OPEN. M. Yevstifeyev: > > 8. Internationalisation Considerations > In designating a canonical URI, please see [RFC3986] for information > on URI encoding. > > IRIs serve for this purpose. I recommend either to rename the section > to Encoding considerations or skip it at all ( I personally like 2nd > variant). > --response by J. Reschke "I believe we'll need this section, and the > contents is fine; after all, this is what you have to think of with > respect to I18N, no?" > --response by M. Yevstifeyev: "RFC 5988 allows target and context URIs > to be IRIs. Current draft has no provisions regarding this. However, > the actual and current text matches encoding considerations better." > --response by J. Reschke: "Actually, there's nothing special about the > I18N for this link relation; so I believe the text should just state > that there's nothing to say in addition to RFC 5988, Section 8." > --response by M. Yevstifeyev: "Probably such approach is OK." > --response by M. Ohye, Julian, would you like us to restate the > current text to explicitly mention there is nothing beyond RFC 5988, > or leave as-is? So let's wait for Julian's response. Mykyta Yevstifeyev > > > On Sat, Jul 2, 2011 at 6:37 AM, Mykyta Yevstifeyev > > wrote: > > 02.07.2011 16:31, Justin Cormack wrote: > >> > >> There does seem to not be a discussion of what is similar though in > >> terms of media types - is /spec.txt similar enough that /spec.html > could > >> be a canonical link? > > > > I personally think it is possible. For example, authoritative RFC > source is > > .txt file on RFC Editor's site, while we have a number of other > sources for > > RFCs, not in .txt, such as "tools.ietf.org/html/rfcXXXX > " in HTML. > > Designating a "canonical" link to > > "http://www.rfc-editor.org/rfc/rfcXXXX.txt" seems to be OK. So I > think we > > have no problem here. > > > > Mykyta > >> > >> One could certainly have a PNG version of an SVG > >> image with a canonical link I would presume. > >> > >> Justin > >> > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > --------------090803090709020501040906 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hello Maile, all,

Let me response to my issues only.

03.07.2011 4:23, Maile Ohye wrote:
3. CLOSED. M. Yevstifeyev:
There is the Intended Status missing in it. I suppose Informational should be fine.
--seconded by J. Reschke
--added to draft by M. Ohye
Thanks for this clarification.

4. OPEN. M. Yevstifeyev:
> The canonical link relation specifies the preferred version of a URI
I think some introductory text on linking, probably based on RFC 5988, should go here.
--response by J. Reschke "Why? It defines a link relation as defined by RFC 5988, so why repeat text from over there?"
--response by M. Yevstifeyev "It should be mentioned (1) what is link relation at all and (2) that RFC 5988 is a specification of that technology which this document depends on. RFC 5988 is first mentioned in Examples."
--response by M. Ohye. We could modify to:
The canonical link relation (Link Relation Types reference <xref target="RFC5988"/>) specifies the preferred version of a URI...
I proposed to add something like:
"RFC 5988 [RFC5988] specified the mechanism which is used to indicate relationships between the links on the Internet. This document defined a new type of such relationships - canonical link relation."
in Section 1 as 1st para; other paragraphs retain in this case.

5. OPEN. M. Yevstifeyev:
> Presence of the canonical link relation indicates to applications, such as search engines, that they MAY:
I wonder why it's MAY; in this case implementations (explicitly, those apps which interpret Link: headers and corresponding construction in HTML) will be free to ignore it. I think normative SHOULD should be OK (sorry for pun).
--response by J. Reschke "I think this link relation is purely advisory, so a better approach might be to replace "MAY" by "can"."
--response by M. Yevstifeyev "Yes, advisory, which suits RFC 2119 definition for SHOULD: 'SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.'
and natural meaning of should - advice/recommendation."
--response by M. Ohye: Thanks, in discussion with Joachim Kupke.
Please notify on the list when this issue is resolved.

6. CLOSED. M. Yevstifeyev:
I suppose omitting "value of the" should be better, since there is no such term in RFC 3986. In fact, when referring the URI, we mean its value, meaning.
--agreed by J. Reschke
--updated in draft by M. Ohye (in two instances)
Thanks for this.

7. OPEN. M. Yevstifeyev:
o Exist on a different protocol: http to https, or vice versa
You probably meant URI scheme here, since https isn't a separate protocol. As before these points we had "The value of the target/canonical URI MAY" or, if you consider my comment above, "The target/canonical URI MAY", this point may be reworded as "Have different scheme names" (which suits the second variant of a preface to this list better).
--agreed by J. Reschke
--response by M. Ohye/J. Kupke: Good catch, Mykyta. Were fine to change the draft to scheme:
... And for this correction :-)
Have different scheme names: such as http to https, or vice versa
Do we now need to expand the draft for ftp:// and gopher:// URIs? For example, ftp:// and gopher:// URIs
1) Do not come with the equivalent of RFC 5988, so a non-HTML document available at any such URI won't be available to make use of <link rel="canonical">.
2) Have corresponding GOPHER error code (item type 3) or an FTP error 550, which like HTTP 404, is forbidden from being served for the target of a <link rel="canonical">.
I don't think we should make such changes. If we consider ftp and gopher URIs, we should also consider all other. I proposed to add generic statements which would be applicable to almost all application protocols, not only HTTP, as in current version of the draft.

8. OPEN. M. Yevstifeyev:
Reading section 3 and 5 of the draft, it seems that is mandates use of HTTP when referring to canonical URIs. And what is the situation when target URI is a 'ftp' or 'gopher' URI? Section 3 allows different scheme names in context/target URIs, if I understand it correctly. Therefore, unless it is deliberately, I think any mention of HTTP should be replaced by more generic regulations.
--response by J. Reschke "Nope; I think the HTTP examples are very useful. But maybe we can have an additional statement that the link relation isn't specific to HTTP."
--response by M. Yevstifeyev"Currently we have normative reference to RFC 2616 and normative requirements with respect to HTTP. HTTP examples are OK; but it's redundant in Section 3. I suppose in Section 3 we may replace HTTP-related stuff with something in the way like:

Old:
o The source URI of a "300 Multiple Choices" URI (Section 10.3.1 of
[RFC2616]) or a permanent redirect (Section 10.3.2 of [RFC2616]).
New:
o The source URI, which defines a resource which provides choice
in different represntations of a given resource, ientified by
the context URI, or is a link which has been permanently replaced
by an other one.
etc."
--response by B. Thorlacius: Your wording seems overly confusing. Which is the resource that "provides choice in different represntations of a given resource?" A standard could be assigned the URI <http://example.org/spec>. An HTTP GET /spec might be responded with an HTTP/1.1 300 choice, and an entity linking to /spec.node.html, /spec.html, /spec.pdf, and /spec.txt. The resource (the standard, that is) would in no way provide this choice. The HTTP server simply offered multiple representations.
--response by M. Yevstifeyev: First, this was an example only. Next, my point was that the document makes HTTP/'http' scheme mandatory in context/target URIs, which I don't think is appropriate, since canonical URI may refer to a resource accessible via other protocol. Even though HTTP is going to be the most often use case of canonical link relation, we shouldn't exclude other protocols.
--response by B. Thorlacius: I agree. However, I don't understand the need for forbidding canonical links to resources with multiple representations. Are there not to be canonical links from representations of a resource to the resource (i.e. from /spec.html and /spec.txt to /spec)?
--response by M. Yevstifeyev: Probably such restriction is set because multiple representation choice may ultimately refer the user to a resource which is not canonical. A _definite_ canonical resource is necessary and required.

----response by J. Cormack: I think this relation (which is useful) need to be called something

else, as it is performing a different function to canonical, which is

about relations between representations of resources, rather than

between representations of resources and a the resource itself

like /spec.


There does seem to not be a discussion of what is similar though in

terms of media types - is /spec.txt similar enough that /spec.html could

be a canonical link? One could certainly have a PNG version of an SVG

image with a canonical link I would presume.

------response by M. Yevstifeyev: I personally think it is possible. For example, authoritative RFC source is .txt file on RFC Editor's site, while we have a number of other sources for RFCs, not in .txt, such as "tools.ietf.org/html/rfcXXXX" in HTML. Designating a "canonical" link to "http://www.rfc-editor.org/rfc/rfcXXXX.txt" seems to be OK. So I think we have no problem here.

--response by M. Ohye: We can change the draft to include corresponding GOPHER or FTP error codes to demonstrate non-favortism to HTTP.
I don't think it would be useful (see above). It's better, as I've already mentioned in my response to (7), to provide rules which would be fine for almost any application protocol and which would be equivalent to those provided for HTTP now. For example:
OLD: "Be the source URI of a 302, 303, or 307 redirect (Sections 10.3.3, 10.3.4, and 10.3.8, respectively, of [RFC2616])." NEW: "Provide a redirect to the other resource because it is temporarily unavailable." This is what HTTP 302 and 307 responses stand for. 303 response is used in HTTP only and here is no equivalent to it in other protocols.

9. OPEN. M. Yevstifeyev:
> 8. Internationalisation Considerations
In designating a canonical URI, please see [RFC3986] for information on URI encoding.

IRIs serve for this purpose. I recommend either to rename the section to Encoding considerations or skip it at all ( I personally like 2nd variant).
--response by J. Reschke "I believe we'll need this section, and the contents is fine; after all, this is what you have to think of with respect to I18N, no?"
--response by M. Yevstifeyev: "RFC 5988 allows target and context URIs to be IRIs. Current draft has no provisions regarding this. However, the actual and current text matches encoding considerations better."
--response by J. Reschke: "Actually, there's nothing special about the I18N for this link relation; so I believe the text should just state that there's nothing to say in addition to RFC 5988, Section 8."
--response by M. Yevstifeyev: "Probably such approach is OK."
--response by M. Ohye, Julian, would you like us to restate the current text to explicitly mention there is nothing beyond RFC 5988, or leave as-is?
So let's wait for Julian's response.

Mykyta Yevstifeyev


On Sat, Jul 2, 2011 at 6:37 AM, Mykyta Yevstifeyev <evnikita2@gmail.com> wrote:
> 02.07.2011 16:31, Justin Cormack wrote:
>>
>> There does seem to not be a discussion of what is similar though in
>> terms of media types - is /spec.txt similar enough that /spec.html could
>> be a canonical link?
>
> I personally think it is possible. For example, authoritative RFC source is
> .txt file on RFC Editor's site, while we have a number of other sources for
> RFCs, not in .txt, such as "tools.ietf.org/html/rfcXXXX" in HTML.
> Designating a "canonical" link to
> "http://www.rfc-editor.org/rfc/rfcXXXX.txt" seems to be OK. So I think we
> have no problem here.
>
> Mykyta
>>
>> One could certainly have a PNG version of an SVG
>> image with a canonical link I would presume.
>>
>> Justin
>>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>



--------------090803090709020501040906-- From julian.reschke@gmx.de Sun Jul 3 00:56:13 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB4621F86F1 for ; Sun, 3 Jul 2011 00:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, 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 eYdFbLtTYLTa for ; Sun, 3 Jul 2011 00:56:12 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 6BB1721F86EE for ; Sun, 3 Jul 2011 00:56:12 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2011 07:56:07 -0000 Received: from p508FBCDC.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.188.220] by mail.gmx.net (mp056) with SMTP; 03 Jul 2011 09:56:07 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18VimYpohYVGr3N4AfhWVBKp77MfZ6W0nMzTY/G2j 0Fy2I1UYwUPICt Message-ID: <4E10208C.6090209@gmx.de> Date: Sun, 03 Jul 2011 09:55:56 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Maile Ohye References: <4E083D3F.6030200@gmx.de> <4E0D3EA5.7010803@gmail.com> <4E0DCFEF.20206@gmx.de> <4E0DEA77.3050007@gmail.com> <4E0E0E76.2080007@gmail.com> <4E0E995A.7060800@gmail.com> <4E0F1058.3050201@gmail.com> <1309613470.2807.17.camel@mackerel> <4E0F1F2F.8020504@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "link-relations@ietf.org" , joachim@kupke.za.net, IETF Apps Discuss , Bjartur Thorlacius Subject: Re: [apps-discuss] [link-relations] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 07:56:13 -0000 On 2011-07-03 03:23, Maile Ohye wrote: > 1. OPEN. F. Ellermann: > A relative canonical URL can't be a good idea. If there is more thanone > "content URL" (in the terminology of the draft) this would resultin more > than one canonical URL, defeat the purpose, and worse, thiscould make > googlebot angry. > --response by F. Ellermann: ... But now I see that relativecan be > perfectly fine if and only if all incarnations exist on the sameserver, > e.g., http://example/xyzzy.html?any-querycould get a relativecanonical > URL xyzzy.html?default or similar. A better example in thedraft > explaining when a relative canonical URL is okay could help. > --response by M. Ohye: We could add a relative URL in the Examples section: > Then duplicate content URIs such as: > http://www.example.com/page.php?item=purse&category=bags > > http://www.example.com/page.php?item=purse&category=bags&sid=1234 > > may designate the canonical link relation in HTML as specified in > [RFC5988]: > href="http://www.example.com/page.php?item=purse" /> > or > or alternatively, in the HTTP Header... +1 > 2. OPEN. F. Ellermann: > The draft could s/SHOULD NOT/MUST NOT/, I don't see any good reasonto > violate a SHOULD NOT, and if that's correct MUST NOT is clearer. > --seconded by M. Yevstifeyev > --response by M. Ohye and J. Kupke: We prefer SHOULD NOT for a few > reasons. 1) If we outlawed multiple canonicals using MUST NOT, we would > effectively call the HTML invalid. In reality, the HTML will still be > processed, though its likely that search engines will ignore both/all > rel=canonicals. 2) Worse, for the cases where somebody might > rel=canonical to a 404, etc., if we use MUST NOT, it would place a huge > (and entirely unrealistic) burden on the site owner to ensure that > search engines recrawl pages in such an order that all rel=canonical > sources are updated before a page may become a 404. I'm not sure I understand the response. Is there a use case where an author would legitimately add multiple instances of the link relation? > ... > 4. OPEN. M. Yevstifeyev: >> The canonical link relation specifies the preferred version of a URI > I think some introductory text on linking, probably based on RFC 5988, > should go here. > --response by J. Reschke "Why? It defines a link relation as defined by > RFC 5988, so why repeat text from over there?" > --response by M. Yevstifeyev "It should be mentioned (1) what is link > relation at all and (2) that RFC 5988 is a specification of that > technology which this document depends on. RFC 5988 is first mentioned > in Examples." > --response by M. Ohye. We could modify to: > The canonical link relation (Link Relation Types reference target="RFC5988"/>) specifies the preferred version of a URI... +1 > 5. OPEN. M. Yevstifeyev: >> Presence of the canonical link relation indicates to applications, > such as search engines, that they MAY: > I wonder why it's MAY; in this case implementations (explicitly, those > apps which interpret Link: headers and corresponding construction in > HTML) will be free to ignore it. I think normative SHOULD should be OK > (sorry for pun). > --response by J. Reschke "I think this link relation is purely advisory, > so a better approach might be to replace "MAY" by "can"." > --response by M. Yevstifeyev "Yes, advisory, which suits RFC 2119 > definition for SHOULD: 'SHOULD This word, or the adjective > "RECOMMENDED", mean that there may exist valid reasons in particular > circumstances to ignore a particular item, but the full implications > must be understood and carefully weighed before choosing a different > course.' > and natural meaning of should - advice/recommendation." > --response by M. Ohye: Thanks, in discussion with Joachim Kupke. No, it's really not a SHOULD. > ... > 7. OPEN. M. Yevstifeyev: > o Exist on a different protocol: http to https, or vice versa > You probably meant URI scheme here, since https isn't a separate > protocol. As before these points we had "The value of the > target/canonical URI MAY" or, if you consider my comment above, "The > target/canonical URI MAY", this point may be reworded as "Have different > scheme names" (which suits the second variant of a preface to this list > better). > --agreed by J. Reschke > --response by M. Ohye/J. Kupke: Good catch, Mykyta. Were fine to > change the draft to scheme: > Have different scheme names: such as http to https, or vice versa > Do we now need to expand the draft for ftp:// and gopher:// URIs? For > example, ftp:// and gopher:// URIs > 1) Do not come with the equivalent of RFC 5988, so a non-HTML document > available at any such URI won't be available to make use of rel="canonical">. > 2) Have corresponding GOPHER error code (item type 3) or an FTP error > 550, which like HTTP 404, is forbidden from being served for the target > of a . a) A non-HTML document at a non-HTTP(s) URI may not be able to specify the link relation, but it could be the target of a link, relation, right? (that could be an example) b) Future protocols might have other means to specify a link relation, btw. > 8. OPEN. M. Yevstifeyev: > Reading section 3 and 5 of the draft, it seems that is mandates use of > HTTP when referring to canonical URIs. And what is the situation when > target URI is a 'ftp' or 'gopher' URI? Section 3 allows different > scheme names in context/target URIs, if I understand it correctly. > Therefore, unless it is deliberately, I think any mention of HTTP > should be replaced by more generic regulations. > --response by J. Reschke "Nope; I think the HTTP examples are very > useful. But maybe we can have an additional statement that the link > relation isn't specific to HTTP." > --response by M. Yevstifeyev"Currently we have normative reference to > RFC 2616 and normative requirements with respect to HTTP. HTTP examples > are OK; but it's redundant in Section 3. I suppose in Section 3 we may > replace HTTP-related stuff with something in the way like: > > Old: > o The source URI of a "300 Multiple Choices" URI (Section 10.3.1 of > [RFC2616]) or a permanent redirect (Section 10.3.2 of [RFC2616]). > New: > o The source URI, which defines a resource which provides choice > in different represntations of a given resource, ientified by > the context URI, or is a link which has been permanently replaced > by an other one. > etc." > --response by B. Thorlacius: Your wording seems overly confusing. Which > is the resource that "provides choice in different represntations of a > given resource?" A standard could be assigned the URI > . An HTTP GET /spec might be responded with an > HTTP/1.1 300 choice, and an entity linking to /spec.node.html, > /spec.html, /spec.pdf, and /spec.txt. The resource (the standard, that > is) would in no way provide this choice. The HTTP server simply offered > multiple representations. > --response by M. Yevstifeyev: First, this was an example only. Next, > my point was that the document makes HTTP/'http' scheme mandatory in > context/target URIs, which I don't think is appropriate, since canonical > URI may refer to a resource accessible via other protocol. Even though > HTTP is going to be the most often use case of canonical link relation, > we shouldn't exclude other protocols. > --response by B. Thorlacius: I agree. However, I don't understand the > need for forbidding canonical links to resources with multiple > representations. Are there not to be canonical links from > representations of a resource to the resource (i.e. from /spec.html and > /spec.txt to /spec)? > --response by M. Yevstifeyev: Probably such restriction is set because > multiple representation choice may ultimately refer the user to a > resource which is not canonical. A _definite_ canonical resource is > necessary and required. > ... ...my general feeling here is that having specific HTTP examples is good, as long as the spec doesn't make the reader think it's the only protocol that qualifies. Best regards, Julian From julian.reschke@gmx.de Sun Jul 3 04:29:32 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9491621F8729 for ; Sun, 3 Jul 2011 04:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 fb6JLedA7uHc for ; Sun, 3 Jul 2011 04:29:32 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id A93D321F8730 for ; Sun, 3 Jul 2011 04:29:31 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2011 11:29:29 -0000 Received: from unknown (EHLO [10.158.136.94]) [89.204.153.94] by mail.gmx.net (mp015) with SMTP; 03 Jul 2011 13:29:29 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/rQTQXDOrrqbIzQnEy6bxCjPIhyfYopKvIGpP5hf FuLUfjJerBgTyn Message-ID: <4E105296.3060001@gmx.de> Date: Sun, 03 Jul 2011 13:29:26 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "link-relations@ietf.org" , IETF Apps Discuss , Maile Ohye References: <4E083D3F.6030200@gmx.de> In-Reply-To: <4E083D3F.6030200@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: [apps-discuss] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 11:29:32 -0000 Hi, below a set of mostly editorial comments... Best regards, Julian Abstract This specification defines the canonical link relation -- an element which designates the preferred version of content/URI from a set of duplicate or near duplicate pages. Maybe put "canonical" in double quotes? (similar in other places) 1. Introduction The canonical link relation specifies the preferred version of a URI from a set of identical or vastly similar content that may be maybe just "preferred URI"? The canonical (target URI) MUST contain content that duplicates, is "canonical (target) URI MUST identify content" (it's not the content of the URI, it's the content of the identified resource) extremely similar, or is a superset of the content in the context s/in/at/ The value of the target/canonical URI MAY: o Be self-referential (context URI identical to target URI) o Specify a relative or absolute URI "Specify a URI Reference (see [RFC3986], Section 4.1), i.e., a full URI or a relative reference" o Be the source URI of a 302, 303, or 307 redirect (Sections 10.3.3, 10.3.4, and 10.3.8, respectively, of [RFC2616]). Maybe "Be the source URI of a temporary redirect, such as..."? may designate the canonical link relation in HTML as specified in [RFC5988]: Why do we cite RFC 5988 here? Should this ref HTML? or alternatively, in the HTTP Header as specified in Section 5 of [RFC5988]: s/Header/header field/ Link: ; rel="canonical" 5. Recommendations Before implementing the canonical link relation, verification of the Maybe s/implementing/adding/? From eburger@standardstrack.com Sun Jul 3 09:15:18 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF6221F8616 for ; Sun, 3 Jul 2011 09:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.346 X-Spam-Level: X-Spam-Status: No, score=-102.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, 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 TQVeop5Ymwyf for ; Sun, 3 Jul 2011 09:15:17 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id 22E9F21F8615 for ; Sun, 3 Jul 2011 09:15:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=n0tW0rFUQK5vCDr1OiNszWvKhL95fGs7wTYMQQGrSbKzMvCgZakHq3J0p8iHRHj7UXRqQFkLb9ljKcnz9yHAIFbBrehkGpk7liOUjRtINpeeBoR8lYQUdfPIpnSWOHay; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.126]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QdPKF-0004zj-Iq; Sun, 03 Jul 2011 09:15:15 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-137-690031576; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: Date: Sun, 3 Jul 2011 12:15:13 -0400 Message-Id: <9B604239-6A7D-4669-9F34-839A3DECC4FA@standardstrack.com> References: <4E08CDCB.70902@stpeter.im> To: Dirk Pranke X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: General application-layer protocols discussion of Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 16:15:18 -0000 --Apple-Mail-137-690031576 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On the one hand, we often DO have binary codes for protocol parameters, = cf. IP as an example. Is it easier to read ASCII text? Sure. It is easier to understand English text, if you can read English? Sure. It is a requirement a protocol be in ASCII and in English? Absolutely = not. That is the difference between a protocol parameter and the DNS. No one = will sue you for creating an amex parameter. On Jun 30, 2011, at 2:45 PM, Dirk Pranke wrote: > If we wanted protocol parameters to be arbitrary strings, we'd just > use huffman-encoded binary data or something similar. We don't, and it > is well acknowledged that having protocols composed of human-readable > text has a lot of advantages. In addition, since the protocol *is* > text and not always hidden behind an API, the protocol *is* the API, > and a well-designed API is easier to use. >=20 > -- Dirk >=20 > On Thu, Jun 30, 2011 at 4:22 AM, Eric Burger = wrote: >> The difference between protocol parameters and domain names is domain = names are meant for human consumption, while protocol parameters are = arbitrary strings of ASCII or UTF-8 text. A protocol might use the = string "kritisch" to mean "something critical." Great -- people building = user interfaces will read the RFC, know that parameter is "kritisch" and = will display "critical," "crucial," "krytyczny," or whatever is = appropriate for the user. For that matter, one could really use the = string "foobar" to mean "something criticial" or even the number 42. The = protocol will work just fine, and users (who do NOT read what is on the = wire) can have a great experience. >>=20 >> The point is *this* name space is huge and fungible, whereas the DNS = is large and NOT fungible. >>=20 >> On Jun 29, 2011, at 6:05 PM, Dirk Pranke wrote: >>=20 >>> Your draft has: >>>=20 >>>> In some situations, segregating the name space of parameters used = in >>>> a given application protocol can be justified: >>>> ... >>>> 2. When parameter names might have significant meaning. This = case >>>> is rare, since implementers can almost always find a synonym >>>> (e.g., "urgency" instead of "priority") or simply invent a new >>>> name. >>>=20 >>> It seems to me that a primary benefit of the "X-" convention is that >>> it makes unprefixed parameter names less socially acceptable; i.e., >>> there's a pretty clear rule of thumb that if the name isn't X- >>> prefixed, it probably has seen a pass through a committee and hence = it >>> stands at least a chance of having the same meaning in multiple >>> implementations. >>>=20 >>> I am concerned that if you abandon the X- practice, you will lose = this >>> benefit and finding untainted, available parameter names might = become >>> harder. Sure, you can often find a synonym, but it is not usually as >>> good as the original choice. I would hate to see things move to a >>> namespace land-grab like we have seen in DNS. >>>=20 >>> Has this been raised as an issue before? >>>=20 >>> -- Dirk >>>=20 >>>=20 >>> On Mon, Jun 27, 2011 at 11:36 AM, Peter Saint-Andre = wrote: >>>> Based on comments received to date, I've published a = heavily-revised >>>> version of the "X-" proposal: >>>>=20 >>>> http://www.ietf.org/id/draft-saintandre-xdash-00.txt >>>>=20 >>>> Further feedback is welcome! >>>>=20 >>>> Peter >>>>=20 >>>> -- >>>> Peter Saint-Andre >>>> https://stpeter.im/ >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> apps-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>=20 >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >>=20 --Apple-Mail-137-690031576 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA3MDMxNjE1MTNaMCMGCSqGSIb3DQEJ BDEWBBS1SrwlfOSf1lXIr4EYD9MxYTrajDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBAILK7lLuLkCscmR2wP+mfkDZaEv1u+Xz1c/gvw1FlZp2NbzZ yUnAlc7aIQ0gz/W0zPI1lUbyEbgA3Wt1Qz+mvrEGZkW5s4SmkCGIi8dxLx8Gu5a75eVl0Pt8GMyV U9zHismAWxQVjqVimJ4r3G7s+U5tK+m1e0kQoshUPdQ3fJe9khPrynI0CbuYAdJ3yJh5P9rwUetp lYQDVtE1UmXo2iuqivGIiS5o5fYVUZH27i49hj0aIANmB9CnXdCggaLHdVa+dnTVhfWOe3Cnl1Fz fT7hEUlKSTudBoFOPH9d18QDMFxpu0pkpaWrE4qdWGXzWwtu2sFJOgVV1tCk0gvEjrQAAAAAAAA= --Apple-Mail-137-690031576-- From dzonatas@gmail.com Sun Jul 3 09:35:00 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4693A11E807A for ; Sun, 3 Jul 2011 09:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.829 X-Spam-Level: X-Spam-Status: No, score=-4.829 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Y6M6ENBawoqV for ; Sun, 3 Jul 2011 09:34:59 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9A511E807E for ; Sun, 3 Jul 2011 09:34:59 -0700 (PDT) Received: by pvh18 with SMTP id 18so5749738pvh.31 for ; Sun, 03 Jul 2011 09:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=85Pehc+LOp5jd+yGsy4usQbYGS+/ezqw1y3ZApbpSnY=; b=HLWerQRvDaPsKXU1oZu5LhJ2gU9l2RqWR9i+KY3AKlck3Pq+NorzhDWrrydM3bGpxg nbRHcv28pB7d377J4tYa0Oey+LRC5nJCpjuF1qGzwIGDBgw8286FzWveHU0tnCgszIoV vMqM8zlkukSQCfQSKtPPLZao4LKN6s6084HZA= Received: by 10.68.17.5 with SMTP id k5mr5897218pbd.92.1309710898762; Sun, 03 Jul 2011 09:34:58 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id p7sm1525287pbn.17.2011.07.03.09.34.57 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Jul 2011 09:34:57 -0700 (PDT) Message-ID: <4E109A17.1010502@gmail.com> Date: Sun, 03 Jul 2011 09:34:31 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4E08CDCB.70902@stpeter.im> <9B604239-6A7D-4669-9F34-839A3DECC4FA@standardstrack.com> In-Reply-To: <9B604239-6A7D-4669-9F34-839A3DECC4FA@standardstrack.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 16:35:00 -0000 On 07/03/2011 09:15 AM, Eric Burger wrote: > On the one hand, we often DO have binary codes for protocol parameters, cf. IP as an example. > > Is it easier to read ASCII text? Sure. > It is easier to understand English text, if you can read English? Sure. > > It is a requirement a protocol be in ASCII and in English? Absolutely not. > ASCII is a protocol with-in itself, so there is no question about "a protocol be in ascii". > That is the difference between a protocol parameter and the DNS. No one will sue you for creating an amex parameter. > > On Jun 30, 2011, at 2:45 PM, Dirk Pranke wrote: > > >> If we wanted protocol parameters to be arbitrary strings, we'd just >> use huffman-encoded binary data or something similar. We don't, and it >> is well acknowledged that having protocols composed of human-readable >> text has a lot of advantages. In addition, since the protocol *is* >> text and not always hidden behind an API, the protocol *is* the API, >> and a well-designed API is easier to use. >> >> -- Dirk >> >> On Thu, Jun 30, 2011 at 4:22 AM, Eric Burger wrote: >> >>> The difference between protocol parameters and domain names is domain names are meant for human consumption, while protocol parameters are arbitrary strings of ASCII or UTF-8 text. A protocol might use the string "kritisch" to mean "something critical." Great -- people building user interfaces will read the RFC, know that parameter is "kritisch" and will display "critical," "crucial," "krytyczny," or whatever is appropriate for the user. For that matter, one could really use the string "foobar" to mean "something criticial" or even the number 42. The protocol will work just fine, and users (who do NOT read what is on the wire) can have a great experience. >>> >>> The point is *this* name space is huge and fungible, whereas the DNS is large and NOT fungible. >>> >>> On Jun 29, 2011, at 6:05 PM, Dirk Pranke wrote: >>> >>> >>>> Your draft has: >>>> >>>> >>>>> In some situations, segregating the name space of parameters used in >>>>> a given application protocol can be justified: >>>>> ... >>>>> 2. When parameter names might have significant meaning. This case >>>>> is rare, since implementers can almost always find a synonym >>>>> (e.g., "urgency" instead of "priority") or simply invent a new >>>>> name. >>>>> >>>> It seems to me that a primary benefit of the "X-" convention is that >>>> it makes unprefixed parameter names less socially acceptable; i.e., >>>> there's a pretty clear rule of thumb that if the name isn't X- >>>> prefixed, it probably has seen a pass through a committee and hence it >>>> stands at least a chance of having the same meaning in multiple >>>> implementations. >>>> >>>> I am concerned that if you abandon the X- practice, you will lose this >>>> benefit and finding untainted, available parameter names might become >>>> harder. Sure, you can often find a synonym, but it is not usually as >>>> good as the original choice. I would hate to see things move to a >>>> namespace land-grab like we have seen in DNS. >>>> >>>> Has this been raised as an issue before? >>>> >>>> -- Dirk >>>> >>>> >>>> On Mon, Jun 27, 2011 at 11:36 AM, Peter Saint-Andre wrote: >>>> >>>>> Based on comments received to date, I've published a heavily-revised >>>>> version of the "X-" proposal: >>>>> >>>>> http://www.ietf.org/id/draft-saintandre-xdash-00.txt >>>>> >>>>> Further feedback is welcome! >>>>> >>>>> Peter >>>>> >>>>> -- >>>>> Peter Saint-Andre >>>>> https://stpeter.im/ >>>>> >>>>> >>>>> _______________________________________________ >>>>> apps-discuss mailing list >>>>> apps-discuss@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>> >>>>> >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> apps-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>> >>> >>> > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From ajs@anvilwalrusden.com Sun Jul 3 23:09:06 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2720D21F8648 for ; Sun, 3 Jul 2011 23:09:06 -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 O7WlzYop-rOB for ; Sun, 3 Jul 2011 23:09:05 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 9A35621F8636 for ; Sun, 3 Jul 2011 23:09:05 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id DA2CD1ECB41C; Mon, 4 Jul 2011 06:09:02 +0000 (UTC) Date: Mon, 4 Jul 2011 02:08:58 -0400 From: Andrew Sullivan To: John C Klensin Message-ID: <20110704060858.GG24564@shinkuro.com> References: <20110701162416.GB24564@shinkuro.com> <148089D7A073E8A4A9F54B64@PST.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <148089D7A073E8A4A9F54B64@PST.JCK.COM> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Paul Hoffman , apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-rfc3536bis-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 06:09:06 -0000 On Fri, Jul 01, 2011 at 04:00:07PM -0400, John C Klensin wrote: > was probably unwise. Depending on what the IESG has to say > (i.e., what Pete tells us), we are contemplating rewriting that > explanation into RFC 2119 language and simply saying that these > definitions SHOULD be used in IETF documents and that, if people > choose to not use them, they MUST define the terms they are > using exactly and preferably use terminology that does not > overlap. > > Your thoughts on whether that is a good strategy would be > welcome. Either that, or (failing it) adding something the sentence I suggested (which is just intended to say, "Hey, play nice!"), would be a good idea, in my opinion. > that provide normative definitions for terminology used with the > DNS. If such a document existed I'm sure we'd all rejoice were such a document to be written and to achieve consensus. But I understand the reasoning. A -- Andrew Sullivan ajs@anvilwalrusden.com From john-ietf@jck.com Mon Jul 4 05:17:44 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A2F21F8670 for ; Mon, 4 Jul 2011 05:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 UN-jA4YY1RyY for ; Mon, 4 Jul 2011 05:17:43 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 51E3F21F866D for ; Mon, 4 Jul 2011 05:17:43 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Qdi5p-0008BB-1l; Mon, 04 Jul 2011 08:17:37 -0400 X-Vipre-Scanned: 0749C4C70026270749C614-TDI Date: Mon, 04 Jul 2011 08:17:36 -0400 From: John C Klensin To: Behnam Esfahbod 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: apps-discuss Subject: Re: [apps-discuss] CONTEXTJ in TLD DNS-Labels (draft-liman-tld-names-05) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 12:17:44 -0000 --On Thursday, June 30, 2011 16:56 -0400 Behnam Esfahbod wrote: > Hello, > > The restriction rules of the latest draft for "Top Level > Domain Name Specification", section 4 [1], is unfortunately > very restrictive for some languages, including Persian > language (in Arabic script). >... > Hereby, I would like to request reconsidering the restriction > rules of TLD DNS-Labels and to allow characters with CONTEXTJ > derived property value in the labels. (Of course the IDNA2008 > contextual restrictions for CONTEXTJ characters must apply.) Behnam, (personal opinion only; not wearing any present or past "hats") ICANN makes up their own rules about this sort of thing, maybe with emphasis on "makes up". They have fairly consistently told IETF participants that IETF opinions are relevant only if they impose clear technical restrictions (and maybe not then). The degree of attention paid in ICANN to the arguments of either RFC 3675 or RFC 4185 are perhaps indicative. IDNA2008 imposes no special requirements on top level IDNs -- if a string is valid at any other level of the tree, it does not violate the protocol to use it at the top level. So, from an IETF standpoint, there is nothing to reconsider in order to permit ZWNJ to be used in domain names. That said, let me provide a different perspective on the problem. This perspective may be reflected in both current ICANN policy and in draft-liman-tld-names-05. It certainly influenced the recommendations I made about the latter document. First of all, while various folks around ICANN seem to forget it regularly, there has never been an entitlement to use names or words in the DNS. There are many words in English that cannot be written using the traditional "preferred name syntax" (often called "LDH") rules. There are also many family names, business names, and so on that cannot be used. While IDNs permit use of many characters that are not part of the basic Latin-derived alphabet, they don't change the fundamental principle that something being a valid word or phrase in a language does not create an automatic "right" to have it as a domain name. Instead, almost every decision as to what strings should be permitted to be used as labels within a given zone represents a tradeoff (either globally across zones or within a particular zone) because the desire to use a particular string as a mnemonic label and the risks that string might create when used for Internet references. The characters listed as CONTEXTJ and CONTEXTO are inherently tricky. Used in the wrong context, they produce labels that don't compare equal but that have exactly the same appearance. To avoid those and other problems, the 2003 version of IDNA excluded them entirely from IDNs using the "map to nothing" technique that we now recognize as creating dangerous ambiguities. While we decided to permit them in appropriate contexts in IDOA2008, the reality is that the contextual rules themselves aren't adequate without additional restrictions that go beyond anything we can do as a DNS or IDNA technical matter. If one were using, e.g., Persian strings in a domain whose use is largely limited to mnemonics derived from Persian and almost certain to be treated as Persian writing style and rendered with Persian-specific rendering engines, then there should be little problem using ZWJ and ZWNJ. That situation would exist, or at least be manageable, in .IR and any Arabic script (and Persian-language-derived) variation on that name. But the root zone (and hence TLD names) are inherently problematic because it has to available for labels in all scripts and because neither languages nor writing style can be encoded reliably in the DNS (at least without causing lots of other problems). However, if a Persian string containing ZWNJ were rendered either by a rendering engine designed for the Arabic language (or one that was simply naive about Arabic script), the resulting situation would be an invitation to phishing, to fraudulent certificates, and so on. So, while permitting ZWNJ (and ZWJ) in top-level domain names seems attractive, it is not safe -- much less safe than permitting the PVALID characters that are always displayed. Striking the balance between safety and the desire to be able to include all mnemonics based on any language in the world will always be a difficult choice and, ultimately, a policy one, but, as long as the community believes that security, stability, and predictable behavior take precedence over the use of any given character in any given script, decisions that exclude problematic characters from the root will continue to be justified. best regards, john From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Mon Jul 4 14:58:38 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DA821F87D7 for ; Mon, 4 Jul 2011 14:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-1, 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 0DEDW0q1QYbq for ; Mon, 4 Jul 2011 14:58:37 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 93F4921F87D4 for ; Mon, 4 Jul 2011 14:58:37 -0700 (PDT) Received: by pzk5 with SMTP id 5so1347712pzk.31 for ; Mon, 04 Jul 2011 14:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ElE9sYzGtrTkVhYfplPlXvUZHdbJvTC+oSD2og5m8jU=; b=TZB2Gl+UgZqjyvilPAKWYiXQnLdpmeTvz1GpOV/N46JIvOVC7KFXPj7VRnrUSPLjIt cu/8APMUofKjIysqPkConL/ANwP79T+zXDnUxzX6xp8WCC6nG0RJQu591GWYceVx/7OC vPwZc6S7+0c9C6QmRwtZwRGlss1EyzymgaBR8= Received: by 10.142.165.13 with SMTP id n13mr3202966wfe.123.1309816717122; Mon, 04 Jul 2011 14:58:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.88.9 with HTTP; Mon, 4 Jul 2011 14:58:17 -0700 (PDT) In-Reply-To: References: <4E083D3F.6030200@gmx.de> <4E0D3EA5.7010803@gmail.com> <4E0DCFEF.20206@gmx.de> <4E0DEA77.3050007@gmail.com> <4E0E0E76.2080007@gmail.com> <4E0E995A.7060800@gmail.com> <4E0F1058.3050201@gmail.com> <1309613470.2807.17.camel@mackerel> <4E0F1F2F.8020504@gmail.com> From: Frank Ellermann Date: Mon, 4 Jul 2011 23:58:17 +0200 Message-ID: To: Maile Ohye Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: joachim@kupke.za.net, IETF Apps Discuss Subject: Re: [apps-discuss] [link-relations] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 21:58:38 -0000 On 3 July 2011 03:23, Maile Ohye wrote: Hi, I've stripped the "link relations expert review list" from the CC: keeping only the IETF apps list. > In case this email displays as plain text Sadly it didn't... About "relative canonical URLs": > We could add a relative URL in the Examples section Good, thanks. About "SHOULD vs. MUST": > We prefer SHOULD NOT for a few reasons. > 1) If we outlawed multiple canonicals using MUST NOT, we > would effectively call the HTML invalid. In reality, the > HTML will still be processed, though it=92s likely that > search engines will ignore both/all rel=3Dcanonicals. If you are very sure that violations of the SHOULD NOT are only *ignored* I'm fine with it. But search engines could also treat violations as some kind of "link farming" and punish authors for their intended or unintended violations. In that case authors would be better off with a MUST NOT clearly indicating that it is their own fault if they get rel=3D"canonical" wrong -- after all they are not forced to use rel=3D"canonical". IOW, if you have "only" a SHOULD NOT for publishers you might need a corresponding "MUST ignore violations" for web crawlers. > Worse, for the cases where somebody might rel=3Dcanonical > to a 404, etc. Ugh. A typical use case is a simple site with a mirror, in that case a 404 should be temporary: New pages on the mirror(s) not yet available under their canonical URL, or old pages deleted under their canonical URL still found on the mirror(s). You are right, a MUST NOT does not fly for this scenario. -Frank From y.oiwa@aist.go.jp Tue Jul 5 07:10:42 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2808221F8575; Tue, 5 Jul 2011 07:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 P0eoV0qEBJGZ; Tue, 5 Jul 2011 07:10:38 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by ietfa.amsl.com (Postfix) with ESMTP id B4FB721F8579; Tue, 5 Jul 2011 07:10:36 -0700 (PDT) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id p65EAXhe028839; Tue, 5 Jul 2011 23:10:33 +0900 (JST) env-from (y.oiwa@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1309875034; bh=lWQopefAxXp1v8Gj10NThaRecdYPKaMpSBH//1Hj9CY=; h=From:Date:Message-ID; b=cv2SwYkrx+yiZFi+986DQbzMET2zsmeWCM1veVLdoZ0hQDC6fnA3RvDfipROq3SJo aVQ0QOPv/7n1Hz2EWGohSmuXFC2qcaEq/l1Jzn507NhTBbw3BSk3NRnvOTJ5ISn8UQ tFyQxXMK/khr8pqF/NHcxf2kbc6AI6aw45Y3KAJ8= Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id p65EAXhS002618; Tue, 5 Jul 2011 23:10:33 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp3.aist.go.jp with ESMTP id p65EAWg1014010; Tue, 5 Jul 2011 23:10:32 +0900 (JST) env-from (y.oiwa@aist.go.jp) To: IETF HTTP-auth Mailing List From: Yutaka OIWA Date: Tue, 05 Jul 2011 23:10:32 +0900 Message-ID: <87box824yv.fsf@bluewind.rcis.aist.go.jp> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: saag , apps-discuss Subject: [apps-discuss] http-auth problem statement draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: IETF HTTP-auth Mailing List List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 14:10:42 -0000 Dear all, I have just reformatted the problem statement document (previously put on IETF Wiki) to the I-D format. The draft is now available from: http://tools.ietf.org/html/draft-oiwa-http-auth-problem-statement-00 I've added categorization of use-cases to three groups (Section 4). I also added several references and other minor improvements. I'd like to add more topics and use cases here. Yutaka -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From y.oiwa@aist.go.jp Tue Jul 5 07:17:53 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5392911E80AB; Tue, 5 Jul 2011 07:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 wiwgka5xyqtU; Tue, 5 Jul 2011 07:17:52 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by ietfa.amsl.com (Postfix) with ESMTP id 44BA221F858D; Tue, 5 Jul 2011 07:17:52 -0700 (PDT) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id p65EHowH000254; Tue, 5 Jul 2011 23:17:50 +0900 (JST) env-from (y.oiwa@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1309875470; bh=oGEyCnG3lyoDz1cydQMKppf/N7+0bxcT6RXYlSRAlQk=; h=From:Date:Message-ID; b=RZV9ehmEFqApeDSxnRRKhyH4XdahyyF6mXUzo2rRB24GHFmOsz0I8noEZ+WMIEUZ+ UEBwNBPs1qIIph+O5uOVGxNeWJ+kkh3p9f4+e3mmqwKhe3IKu6f0W0nSzgnZHDiskw cxmgqZMMKZphXqNB2LtM0nE3M1I+mpbD/sVYSqoE= Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id p65EHoYa003048; Tue, 5 Jul 2011 23:17:50 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp3.aist.go.jp with ESMTP id p65EHnVF015625; Tue, 5 Jul 2011 23:17:49 +0900 (JST) env-from (y.oiwa@aist.go.jp) To: IETF HTTP-auth Mailing List From: Yutaka OIWA Date: Tue, 05 Jul 2011 23:17:49 +0900 Message-ID: <877h7w24mq.fsf@bluewind.rcis.aist.go.jp> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: saag , apps-discuss Subject: [apps-discuss] Updated HTTP Mutual authentication draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: IETF HTTP-auth Mailing List List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 14:17:53 -0000 I've updated the http Mutual authentication proposal draft. As suggested at Prague Bar-BoF, now I split out the cryptography part from the core protocol part. Current status of separation is a bit technical and sloppy, I will improve some non-technical sections such as introduction to make it more natural in the future. In the next stage I'd also like to re-examine the http-auth extension (optional auth and detailed auth control) part and separate it to another draft, possibly after Quebec. The drafts are now available at http://tools.ietf.org/html/draft-oiwa-http-mutualauth-09 http://tools.ietf.org/html/draft-oiwa-http-mutualauth-algo-00 Yutaka -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From alexey.melnikov@isode.com Tue Jul 5 12:30:53 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E9B21F8930 for ; Tue, 5 Jul 2011 12:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 djjLxcpcuPr3 for ; Tue, 5 Jul 2011 12:30:53 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF9421F8861 for ; Tue, 5 Jul 2011 12:30:53 -0700 (PDT) Received: from [188.28.25.241] (188.28.25.241.threembb.co.uk [188.28.25.241]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 5 Jul 2011 20:30:52 +0100 Message-ID: <4E136647.4030008@isode.com> Date: Tue, 05 Jul 2011 20:30:15 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Mykyta Yevstifeyev References: <4DAF5256.2040303@isode.com> <4E0D3FA5.8060504@gmail.com> In-Reply-To: <4E0D3FA5.8060504@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Call for adoption of draft-kucherawy-mta-malformed-00.txt as an APPSAWG document X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 19:30:54 -0000 Mykyta Yevstifeyev wrote: > Is it going to result in something? Yes, this is still on my to do list. I am being slow. > Mykyta > > 21.04.2011 0:38, Alexey Melnikov wrote: > >> Dear APPSAWG participants, >> There has been an active discussion about the document this week. >> Given that, I would like to ask the following questions: >> >> 1). Who is willing to review and post comments on the document if the >> WG accepts this document as a WG document? >> >> 2). Are there any objections to accepting this document as a WG >> document? >> >> If you have an objection, please be explicit about the nature of the >> objection (for example, if you think the document is harmful and >> shouldn't be worked on). Note that just saying that you don't like >> the document is not a good enough reason without further explanation. >> >> Explicit statements in favor of accepting are welcomed as well. But >> please also respond if you find objections by others to be >> objectionable ;-). >> >> You can send both objections and your statements of support directly >> to me (if you wish) or to the mailing list. >> >> Please send your responses by the end of April 29th. >> >> Alexey, >> as an APPSAWG co-chair >> > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Internet Messaging Team Lead, JID: same as my email address twitter: aamelnikov From stpeter@stpeter.im Tue Jul 5 15:52:47 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A934721F88FA for ; Tue, 5 Jul 2011 15:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, 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 q5bbGHk9H69y for ; Tue, 5 Jul 2011 15:52:47 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0A19921F88F3 for ; Tue, 5 Jul 2011 15:52:47 -0700 (PDT) Received: from dhcp-64-101-72-207.cisco.com (unknown [64.101.72.207]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 33D7540327 for ; Tue, 5 Jul 2011 16:52:49 -0600 (MDT) Message-ID: <4E1395BD.4080405@stpeter.im> Date: Tue, 05 Jul 2011 16:52:45 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] AppsArea topics for IETF81 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 22:52:47 -0000 Folks, your area directors and the APPSAWG chairs are working on an agenda for IETF81. It appears that we have some free time in our 2-hour slot, so if you have a topic you would like to discuss, please post to this list or contact the ADs and APPSAWG chairs off-list. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ From ajs@anvilwalrusden.com Tue Jul 5 17:00:43 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA08521F887C for ; Tue, 5 Jul 2011 17:00:43 -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 q51EsfJT1irI for ; Tue, 5 Jul 2011 17:00:43 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 28D1E21F8867 for ; Tue, 5 Jul 2011 17:00:43 -0700 (PDT) Received: from shinkuro.com (unknown [206.47.22.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id CC9911ECB41F for ; Wed, 6 Jul 2011 00:00:40 +0000 (UTC) Date: Tue, 5 Jul 2011 20:00:40 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20110706000039.GB52262@shinkuro.com> References: <4E1395BD.4080405@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E1395BD.4080405@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] AppsArea topics for IETF81 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 00:00:43 -0000 If there's time, one of the draft authors or I would like a short slot to talk about the weirds list and drafts, and what we're aiming to do. A On Tue, Jul 05, 2011 at 04:52:45PM -0600, Peter Saint-Andre wrote: > Folks, your area directors and the APPSAWG chairs are working on an > agenda for IETF81. It appears that we have some free time in our 2-hour > slot, so if you have a topic you would like to discuss, please post to > this list or contact the ADs and APPSAWG chairs off-list. > > Thanks! > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Andrew Sullivan ajs@anvilwalrusden.com From msk@cloudmark.com Tue Jul 5 19:53:54 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8228D21F8818 for ; Tue, 5 Jul 2011 19:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.162 X-Spam-Level: X-Spam-Status: No, score=-103.162 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_00=-2.599, 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 i7aHmEZfsBw5 for ; Tue, 5 Jul 2011 19:53:54 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 1BED721F87D7 for ; Tue, 5 Jul 2011 19:53:54 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 5 Jul 2011 19:53:53 -0700 From: "Murray S. Kucherawy" To: Peter Saint-Andre , "apps-discuss@ietf.org" Date: Tue, 5 Jul 2011 19:53:54 -0700 Thread-Topic: [apps-discuss] AppsArea topics for IETF81 Thread-Index: Acw7ZkSUVKRppYgVQ3WlKu4W8wkh5wAIaLuw Message-ID: References: <4E1395BD.4080405@stpeter.im> In-Reply-To: <4E1395BD.4080405@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] AppsArea topics for IETF81 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 02:53:54 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Peter Saint-Andre > Sent: Tuesday, July 05, 2011 3:53 PM > To: apps-discuss@ietf.org > Subject: [apps-discuss] AppsArea topics for IETF81 >=20 > Folks, your area directors and the APPSAWG chairs are working on an > agenda for IETF81. It appears that we have some free time in our 2-hour > slot, so if you have a topic you would like to discuss, please post to > this list or contact the ADs and APPSAWG chairs off-list. So that I don't make a duplicate request, what do you have on there so far? From stpeter@stpeter.im Tue Jul 5 20:53:08 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B68A21F8849 for ; Tue, 5 Jul 2011 20:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.382 X-Spam-Level: X-Spam-Status: No, score=-104.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, GB_I_LETTER=-2, 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 v1NWLCuhD1TQ for ; Tue, 5 Jul 2011 20:53:03 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6268C21F8863 for ; Tue, 5 Jul 2011 20:53:03 -0700 (PDT) Received: from squire.local (unknown [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E86BA40327 for ; Tue, 5 Jul 2011 21:53:05 -0600 (MDT) Message-ID: <4E13DC15.2080302@stpeter.im> Date: Tue, 05 Jul 2011 21:52:53 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <4E08CDCB.70902@stpeter.im> In-Reply-To: <4E08CDCB.70902@stpeter.im> X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 03:53:08 -0000 On 6/27/11 12:36 PM, Peter Saint-Andre wrote: > Based on comments received to date, I've published a heavily-revised > version of the "X-" proposal: > > http://www.ietf.org/id/draft-saintandre-xdash-00.txt Based on list feedback, I've submitted a further revision (including much more specific recommendations for spec authors and implementers): http://www.ietf.org/id/draft-saintandre-xdash-01.txt Keep those cards and letters coming! ;-) Peter -- Peter Saint-Andre https://stpeter.im/ From randy@qualcomm.com Tue Jul 5 21:29:50 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30ED321F87F8 for ; Tue, 5 Jul 2011 21:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 8V+BNMw96bru for ; Tue, 5 Jul 2011 21:29:49 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 91FB321F8747 for ; Tue, 5 Jul 2011 21:29:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1309926589; x=1341462589; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; z=Message-ID:=20 |In-Reply-To:=20<4E136647.4030008@isode.com>|References: =20<4DAF5256.2040303@isode.com>=20<4E0D3FA5.8060504@gmail .com>=0D=0A=20<4E136647.4030008@isode.com>|X-Mailer:=20Eu dora=20for=20Mac=20OS=20X|Date:=20Tue,=205=20Jul=202011 =2021:25:04=20-0700|To:=20Alexey=20Melnikov=20,=20Mykyta=20Yevstifeyev=0D=0A=09,=20Murray=20S=20Kucherawy=20|From:=20Randall=20Gellens=20 |Subject:=20Re:=20[apps-discuss]=20Call=20for=20adoption =20of=20=0D=0A=20draft-kucherawy-mta-malformed-00.txt=20a s=20an=20APPSAWG=20document|CC:=20 |MIME-Version:=201.0|Content-Type:=20text/plain=3B=20char set=3D"us-ascii"=3B=20format=3Dflowed|X-Random-Sig-Tag: =201.0b28|X-Originating-IP:=20[172.30.39.5]; bh=LRqVbFvZQZyM+dKIxB2msKp28V/ipyZWdrOJJvxM6nA=; b=TKfJG+Jr+HIC8kN4rGYrYsnINBGO9mAb+emys7iNMg6xg6/FqVrJCEn6 AtlYtQV95+uKludhU6ek2BH5VDBlk1ZkggG3p6XutYSRepLEUhNT/byyW sQt+hvin7KIS0QfAwElsuAIQ0dwsqvBO6oHeWaa+yUoLJmFQsi2l+qRYE c=; X-IronPort-AV: E=McAfee;i="5400,1158,6398"; a="101825747" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 05 Jul 2011 21:29:48 -0700 X-IronPort-AV: E=Sophos;i="4.65,482,1304319600"; d="scan'208";a="154994091" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 05 Jul 2011 21:29:45 -0700 Received: from loud.pensive.org (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.323.0; Tue, 5 Jul 2011 21:29:44 -0700 Message-ID: In-Reply-To: <4E136647.4030008@isode.com> References: <4DAF5256.2040303@isode.com> <4E0D3FA5.8060504@gmail.com> <4E136647.4030008@isode.com> X-Mailer: Eudora for Mac OS X Date: Tue, 5 Jul 2011 21:25:04 -0700 To: Alexey Melnikov , Mykyta Yevstifeyev , Murray S Kucherawy From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Call for adoption of draft-kucherawy-mta-malformed-00.txt as an APPSAWG document X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 04:29:50 -0000 This is a nice, short, clearly written draft. In Section 1.1., the draft says: The history of email standards, going back to [RFC822] and beyond, contains a fairly rigid evolution of specifications. But implementations within that culture have also long had an undercurrent known formally as the robustness principle, but also known informally as Postel's Law: "Be conservative in what you do, be liberal in what you accept from others." In general, this served the email ecosystem well by allowing a few errors in implementations without obstructing participation in the game. The proverbial bar was set low. However, as we have evolved into the current era, some of these lenient stances have begun to expose opportunities that can be exploited by malefactors. Various email-based applications rely on strong application of these standards for simple security checks, while the very basic building blocks of that infrastructure, intending to be robust, fail utterly to assert those standards. The robustness principle has had some controversy over the years. If I recall correctly, there was a draft some years back called "Be Liberal Considered Harmful" because deployed servers that accepted non-compliant messages were responsible for widespread deployment of broken clients. This resulted in "standards creep" where new servers were forced to accept common but erroneous messages and protocol, and made it harder to develop extensions. It might be worthwhile to mention some of this immediately following the quoted text. Also, it might be worthwhile to suggest that it's good for MSAs fix or reject stuff that is broken (obviously this draft can't mandate this). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- (If you can't hear me, it's because I'm in parentheses) From johnl@iecc.com Tue Jul 5 22:23:13 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129F621F85DE for ; Tue, 5 Jul 2011 22:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.009 X-Spam-Level: X-Spam-Status: No, score=-110.009 tagged_above=-999 required=5 tests=[AWL=1.190, 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 DIGjW2LUyAzt for ; Tue, 5 Jul 2011 22:23:12 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 504DD21F85D8 for ; Tue, 5 Jul 2011 22:23:11 -0700 (PDT) Received: (qmail 41458 invoked from network); 6 Jul 2011 05:23:09 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 6 Jul 2011 05:23:09 -0000 Received: (qmail 91263 invoked from network); 6 Jul 2011 05:23:09 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 6 Jul 2011 05:23:09 -0000 Date: 6 Jul 2011 05:22:47 -0000 Message-ID: <20110706052247.16131.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: randy@qualcomm.com Subject: Re: [apps-discuss] Call for adoption of draft-kucherawy-mta-malformed-00.txt as an APPSAWG document X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 05:23:13 -0000 >It might be worthwhile to mention some of this immediately following >the quoted text. Also, it might be worthwhile to suggest that it's >good for MSAs fix or reject stuff that is broken (obviously this >draft can't mandate this). This draft can't mandate it, but since MSAs are only supposed to submit valid RFC 5322 (or 2822) messages, I'd think it would be OK to point out that existing standards already mandate it. R's, John From williamstw@gmail.com Wed Jul 6 04:02:26 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0F421F86CE for ; Wed, 6 Jul 2011 04:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] 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 I5UYPDClaURc for ; Wed, 6 Jul 2011 04:02:25 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7907921F86D2 for ; Wed, 6 Jul 2011 04:02:25 -0700 (PDT) Received: by pvh18 with SMTP id 18so9143648pvh.31 for ; Wed, 06 Jul 2011 04:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FQYRwAxeIUtTfT787IGl32dcM3/+7huXH5IC/ld+ZCE=; b=meC9gm+Fke96C9RDZRKLH0I7g3HXRGxuD+O8kEbztWeFdAJEk0F1b9SI+otcG9xrG1 aaxaw3tH0T8LAPmkYcDyoJw0KxGwXhIzp6egX0HDcBlG6BK8fMGcDZo5DMkOohjKVe21 KqE7gk/V7sLhGE+3JBWsG6AR0RglfyyEOGkMg= MIME-Version: 1.0 Received: by 10.68.13.228 with SMTP id k4mr10351324pbc.40.1309950144826; Wed, 06 Jul 2011 04:02:24 -0700 (PDT) Received: by 10.68.46.104 with HTTP; Wed, 6 Jul 2011 04:02:24 -0700 (PDT) In-Reply-To: <4E13DC15.2080302@stpeter.im> References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im> Date: Wed, 6 Jul 2011 07:02:24 -0400 Message-ID: From: Tim Williams To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 11:02:26 -0000 On Tue, Jul 5, 2011 at 11:52 PM, Peter Saint-Andre wrote: > On 6/27/11 12:36 PM, Peter Saint-Andre wrote: >> Based on comments received to date, I've published a heavily-revised >> version of the "X-" proposal: >> >> http://www.ietf.org/id/draft-saintandre-xdash-00.txt > > Based on list feedback, I've submitted a further revision (including > much more specific recommendations for spec authors and implementers): > > http://www.ietf.org/id/draft-saintandre-xdash-01.txt > > Keep those cards and letters coming! ;-) Hi Peter, I'm interested in the "Recommendations" section and two things appear curious: "4. Implementers wishing to experiment with parameters that are unlikely to be standardized are encouraged to generate meaningless names such as UUIDs or the output of a hash function." Why? It's not clear to me why names with obfuscated meaning is better or worse than an X- prefix (or any other name) - when they are clearly not intended for standardization? Can you share more about *why* that's encouraged? 5. Implementers wishing to create parameters for use in implementation-specific applications or on private networks are encouraged to mint URIs or generate names that incorporate the relevant organization's name or primary domain name. Not sure if this is atypical for a spec like this but an example or two would help for #5. Is the intent something like: urn:com:example:headers:myheader or http://example.com/headers/myheader or headers:example.com/myheader or, it just doesn't matter? FWIW, I'd also suggest substituting "subclass" or somesuch in the following in the place of "ghetto": " Therefore it appears that segregating non-standard parameters into an "X-" ghetto has few if any benefits, and has at least one significant cost in terms of interoperability." Thanks, --tim From stpeter@stpeter.im Wed Jul 6 08:11:54 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B589C21F84F4 for ; Wed, 6 Jul 2011 08:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.882 X-Spam-Level: X-Spam-Status: No, score=-103.882 tagged_above=-999 required=5 tests=[AWL=0.717, BAYES_00=-2.599, GB_I_LETTER=-2, 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 T0ck+BLiRLL1 for ; Wed, 6 Jul 2011 08:11:46 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2191621F8426 for ; Wed, 6 Jul 2011 08:11:10 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6FF8840327; Wed, 6 Jul 2011 09:11:14 -0600 (MDT) Message-ID: <4E147B0C.2060008@stpeter.im> Date: Wed, 06 Jul 2011 09:11:08 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Tim Williams References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 15:11:54 -0000 On 7/6/11 5:02 AM, Tim Williams wrote: > On Tue, Jul 5, 2011 at 11:52 PM, Peter Saint-Andre wrote: >> On 6/27/11 12:36 PM, Peter Saint-Andre wrote: >>> Based on comments received to date, I've published a heavily-revised >>> version of the "X-" proposal: >>> >>> http://www.ietf.org/id/draft-saintandre-xdash-00.txt >> >> Based on list feedback, I've submitted a further revision (including >> much more specific recommendations for spec authors and implementers): >> >> http://www.ietf.org/id/draft-saintandre-xdash-01.txt >> >> Keep those cards and letters coming! ;-) > > Hi Peter, > I'm interested in the "Recommendations" section and two things appear curious: > > "4. Implementers wishing to experiment with parameters that are > unlikely to be standardized are encouraged to generate > meaningless names such as UUIDs or the output of a hash function." > > Why? It's not clear to me why names with obfuscated meaning is better > or worse than an X- prefix (or any other name) - when they are clearly > not intended for standardization? Can you share more about *why* > that's encouraged? I don't know if they're obfuscated, instead I see them as truly "wild" experiments to see if an idea is worth exploring in a more serious manner. Someone could just as well come up with a nonsense word if they please. > 5. Implementers wishing to create parameters for use in > implementation-specific applications or on private networks are > encouraged to mint URIs or generate names that incorporate the > relevant organization's name or primary domain name. > > Not sure if this is atypical for a spec like this but an example or > two would help for #5. Is the intent something like: > urn:com:example:headers:myheader > or > http://example.com/headers/myheader > or > headers:example.com/myheader > > or, it just doesn't matter? There are examples earlier in the document. I'm happy to add examples for each of the recommendations in that section so that people can just read the recommendations without all the background. :) > FWIW, I'd also suggest substituting "subclass" or somesuch in the > following in the place of "ghetto": > > " Therefore it appears that segregating non-standard parameters into an > "X-" ghetto has few if any benefits, and has at least one significant > cost in terms of interoperability." Yes, that's better. I'll push out a revised I-D before the Monday cutoff, incorporating whatever other feedback people provide. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ From barryleiba.mailing.lists@gmail.com Wed Jul 6 09:00:40 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3FB21F86CE for ; Wed, 6 Jul 2011 09:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_BAYES_7x5=0.8, 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 AZUcp8DLNNGi for ; Wed, 6 Jul 2011 09:00:39 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A5B5521F86A0 for ; Wed, 6 Jul 2011 09:00:39 -0700 (PDT) Received: by gwb20 with SMTP id 20so38357gwb.31 for ; Wed, 06 Jul 2011 09:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=D5aeuHc/quVUTudGUajKpPqKZjMEyXPODew2wZjyUMQ=; b=GMsenbC0TZ0BSFhMnt8WjA87RXBP+w0RvIyVrd/gae3pxZ+cUWPn1HK2khFOo9oIMS WV8ILiuhKmr2Lt7rI137gLjtDGdqFzGmvMXCl+LKvNbo/gYrmBs0z++fKRsaLKIB4urL lOKyvUU6sFrVXIVxanFVRuPcvaePR0mLbskCo= MIME-Version: 1.0 Received: by 10.236.180.98 with SMTP id i62mr10072497yhm.403.1309968039096; Wed, 06 Jul 2011 09:00:39 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.41.12 with HTTP; Wed, 6 Jul 2011 09:00:39 -0700 (PDT) In-Reply-To: References: <4E1395BD.4080405@stpeter.im> Date: Wed, 6 Jul 2011 12:00:39 -0400 X-Google-Sender-Auth: Dm-qm6KGLzzFW5vyAvsN5krxwcA Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] AppsArea topics for IETF81 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 16:00:40 -0000 >> Folks, your area directors and the APPSAWG chairs are working on an >> agenda for IETF81. It appears that we have some free time in our 2-hour >> slot, so if you have a topic you would like to discuss, please post to >> this list or contact the ADs and APPSAWG chairs off-list. > > So that I don't make a duplicate request, what do you have on there so far? Here (below) is a very tentative agenda, subject to responses from all the presenters and allocation of time. It looks like we'll have a nicely full agenda I think. I'll post this to the meeting materials as soon as things are a little more firm. Barry, appsawg chair -------------------------------------------------------- AppsAWG meeting agenda for IETF 81 *** DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT *** Presenters MUST send presentation slides to the chairs by end of day on Saturday, 23 July 2011. Send PDF (preferred) or PPT to 1. Agenda Bashing, and WG Status 2. Best Current Practices for Handling of Malformed Messages (Murray Kucherawy) http://tools.ietf.org/html/draft-kucherawy-mta-malformed 3. The 'about' URI scheme (Joseph Holsten, Lachlan Hunt) ?? http://tools.ietf.org/html/draft-holsten-about-uri-scheme 4. Update to MIME regarding Charset Parameter Handling in Textual Media Types (Alexey) http://tools.ietf.org/html/draft-melnikov-mime-default-charset 5. A JSON Media Type for Describing the Structure and Meaning of JSON Documents (Kris Zyp) http://tools.ietf.org/html/draft-zyp-json-schema 6. Top Level Domain Name Specification (Joe Abley) http://tools.ietf.org/html/draft-liman-tld-names 7. Use of the "X-" Prefix in Application Protocols (Peter StAndre) http://tools.ietf.org/html/draft-saintandre-xdash 8. Discussion of other documents for AppsAWG. -- Transition to Applications Area Open Meeting -- 9. Overview of VDI (Virtual Desktop Infrastructure) work (Liang Liang) Drafts: http://tools.ietf.org/html/draft-wang-appsawg-vdi-problem-statement http://tools.ietf.org/html/draft-ma-appsawg-vdi-survey 10. WEIRDS work -- next-generation WHOIS technology (Andrew Sullivan) Mailing list: https://www.ietf.org/mailman/listinfo/weirds 11. Any other business / open mic -------------------------------------------------------- From stpeter@stpeter.im Wed Jul 6 09:05:41 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB5A21F8678 for ; Wed, 6 Jul 2011 09:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.862 X-Spam-Level: X-Spam-Status: No, score=-102.862 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, 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 z47f1pZk3-NV for ; Wed, 6 Jul 2011 09:05:40 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 063F821F863F for ; Wed, 6 Jul 2011 09:05:40 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B107A40F84; Wed, 6 Jul 2011 10:05:43 -0600 (MDT) Message-ID: <4E1487D1.5090809@stpeter.im> Date: Wed, 06 Jul 2011 10:05:37 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Barry Leiba References: <4E1395BD.4080405@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] AppsArea topics for IETF81 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 16:05:41 -0000 On 7/6/11 10:00 AM, Barry Leiba wrote: > 5. A JSON Media Type for Describing the Structure and Meaning of JSON > Documents (Kris Zyp) > http://tools.ietf.org/html/draft-zyp-json-schema Unless his plans have changed, Kris won't be at IETF 81, so we'll need to work with him and his co-author to find someone else to present. Peter -- Peter Saint-Andre https://stpeter.im/ From barryleiba@gmail.com Wed Jul 6 09:19:46 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B030521F87A3 for ; Wed, 6 Jul 2011 09:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.169 X-Spam-Level: X-Spam-Status: No, score=-103.169 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 Qews-mi3j5yd for ; Wed, 6 Jul 2011 09:19:46 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 332D121F86B1 for ; Wed, 6 Jul 2011 09:19:46 -0700 (PDT) Received: by yie30 with SMTP id 30so53763yie.31 for ; Wed, 06 Jul 2011 09:19:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/bRDN81ab+wlmcSc34nDWxHF9vM71HtHbbSJVMJn+C0=; b=OJNhYiBdkvqLrmSYn0oOtzMjTO6SW6q0geZm3VTjym3z4ri75ZX+gulDWQv82lUMkv h3SBhrJ4neC5FykJmdL44tIyDUIGnlrwmuJPbvS7HOdN9OmK7DBbpqGXOGE4Xx2ukamk pqlaNeqqPlESzf67/MwlDSkZP02gx9XZNO2UY= MIME-Version: 1.0 Received: by 10.236.180.69 with SMTP id i45mr9737480yhm.362.1309969184247; Wed, 06 Jul 2011 09:19:44 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.106.2 with HTTP; Wed, 6 Jul 2011 09:19:44 -0700 (PDT) In-Reply-To: <4E1487D1.5090809@stpeter.im> References: <4E1395BD.4080405@stpeter.im> <4E1487D1.5090809@stpeter.im> Date: Wed, 6 Jul 2011 12:19:44 -0400 X-Google-Sender-Auth: qVKFWZgmoDE96U8i0BAvnyZC660 Message-ID: From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] AppsArea topics for IETF81 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 16:19:46 -0000 > Unless his plans have changed, Kris won't be at IETF 81, so we'll need > to work with him and his co-author to find someone else to present. Kris can present through Skype -- we can put a mic on a laptop. I've already had an exchange with him about it. Barry From internet-drafts@ietf.org Wed Jul 6 09:31:34 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7BA21F866A; Wed, 6 Jul 2011 09:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, 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 IxLSvs6pBRjF; Wed, 6 Jul 2011 09:31:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A3321F8645; Wed, 6 Jul 2011 09:31:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110706163134.31942.24863.idtracker@ietfa.amsl.com> Date: Wed, 06 Jul 2011 09:31:34 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 16:31:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Terminology Used in Internationalization in the IETF Author(s) : Paul Hoffman John C Klensin Filename : draft-ietf-appsawg-rfc3536bis-05.txt Pages : 46 Date : 2011-07-06 This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3536bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3536bis-05.txt From dhc@dcrocker.net Wed Jul 6 11:02:39 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8C221F8865 for ; Wed, 6 Jul 2011 11:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 PSIdllCt8KPc for ; Wed, 6 Jul 2011 11:02:38 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7C59721F8863 for ; Wed, 6 Jul 2011 11:02:38 -0700 (PDT) Received: from [192.168.1.156] (adsl-67-124-149-98.dsl.pltn13.pacbell.net [67.124.149.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p66I2WVV005846 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 6 Jul 2011 11:02:37 -0700 Message-ID: <4E14A334.60500@dcrocker.net> Date: Wed, 06 Jul 2011 11:02:28 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im> In-Reply-To: <4E13DC15.2080302@stpeter.im> 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, 06 Jul 2011 11:02:38 -0700 (PDT) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 18:02:39 -0000 On 7/5/2011 8:52 PM, Peter Saint-Andre wrote: > On 6/27/11 12:36 PM, Peter Saint-Andre wrote: >> Based on comments received to date, I've published a heavily-revised >> version of the "X-" proposal: >> >> http://www.ietf.org/id/draft-saintandre-xdash-00.txt > > Based on list feedback, I've submitted a further revision (including > much more specific recommendations for spec authors and implementers): > > http://www.ietf.org/id/draft-saintandre-xdash-01.txt > > Keep those cards and letters coming! ;-) > > Peter > > Use of the "X-" Prefix in Application Protocols That title is neutral, but this document is not. I suggest the title communicate the goal. Something like: Deprecating use of the "X-" Prefix in Application Protocols Hmmm. There were various messages that criticized the document for being a warning rather than a constructive directive. The current draft offers some specific advice (which I recommend be phrase normatively.) Perhaps this document also should cite specific changes for specific protocols that currently call for x-? (Email already fixed this, going from RFC822 to RFC2822, though that's probably worth citing.) Generically, it might cite the known cases of use and simply direct not using them, instead giving examples of what to do for each case. The most general form of the directive would be "Make the assumption that the use will become popular and eventually attain standards status. What name is preferred in this case? Normally it would be the same as is chosen with the X- preface, but without that preface. In some cases, a different string might be preferred. > Abstract ... > although it can be > appropriate in certain circumstances. although it can still be appropriate to use in certain circumstances. > 1. Background ... > Although this usage is purely conventional and is not mandated by the > Internet Standards Process [BCP9] or IANA registration rules [BCP26], > some implementers, and even some RFCs, have interpreted the > convention in a more normative way (e.g., [RFC5451] states that > "result codes not beginning with 'x-' MUST be registered with the > Internet Assigned Numbers Authority (IANA) and published in an RFC"). The approach to this text seems odd to me. It's also a bit misleading to say 'purely conventional' for something that has been, in fact, formally standardized. (RFC822 was a standard and specified this formally.) So, perhaps: Use of this naming convention is not mandated by the Internet Standards Process [BCP9] or basic IANA registration rules [BCP26]. Rather it is an individual choice by each specification that defines it or administrative process that chooses to use it. For example, [RFC5451] states that "result codes not beginning with 'x-' MUST be registered with the Internet Assigned Numbers Authority (IANA) and published in an RFC"). > Parameters prefaced with the "X-" string are currently used in > application protocols for two different purposes: Given the line of concern of this document, I suggest that the emphasis be about intent rather than effect or "use". So... Parameters prefaced with the "X-" string are currently motivated by two different goals: > 2. Analysis ... Looking at the pattern of the numbered items, pro and con, the template is a very terse (partial sentence) statement of the pro, followed by some sentences discussing the con. What's missing is a clear and complete explanation of the pro view, in each case. As a consequence, I didn't understand the opening point a number of times... > In some situations, segregating the name space of parameters used in > a given application protocol can be justified: > > 1. When it is extremely unlikely that some parameters will ever be > standardized. The problem, here, is predicting the future. It never works and is, in fact, the underlying problem with the X- construct. Perhaps this #1 really intends to cover the case in which is considered to be /undesirable/ to have the parameter standardized? > 2. When parameter names might have significant meaning. I don't understand what this one means. From the rest of its text, perhaps it means that the x- name includes an string that is already standardized by some other spec? > 3. When parameter names need to be very short I've no idea how this requirement can justify an x- name. (A minor point, but note that x- adds two bytes to the length of the name...) > There are two primary objections to deprecating the "X-" Meta-issue: Since the preceding sequence was numbered and this following section parallels it, it should be numbered, too. > Implementers are easily confused. I don't understand how using or not using x- creates or alleviates confusion in implementers. > Collisions are undesirable. I think that the premise to this statement is that dropping x- will increase the likelihood of collisions. That should be stated explicitly. It was, after all, the motivating concern for justifying the x- convention. I think the question is how realistic the concern really is, especially given the ability to make registration much easier than it used to be. > Furthermore, the existence of [BCP82] In formatting terms, I think this should be another item in the list of objections (#3). > 3. Recommendations ... > 1. Authors of application protocol specifications are discouraged > from imputing special meaning to parameters with the "X-" prefix. The goal is to change normative behavior, so let's use normative language (and I suggest changes to the ordering): 1. Implementers wishing to experiment with parameters that have any potential to be standardized SHOULD generate names without the "X-" prefix. 2. Authors of application protocol specifications SHOULD NOT mandate that all parameters without the "X-" prefix need to be registered with the IANA. (#2 seems odd. I don't really understand why it is needed or what it does that's significant, given the recommendation of not using x- parameters ever. Is there a way of stating what is desired affirmatively?) 3. Authors of application protocol specifications are discouraged from imputing special meaning to parameters with the "X-" prefix. 4. Implementers wishing to experiment with parameters that are intended not to be standardized SHOULD generate meaningless names such as UUIDs or the output of a hash function. 5. Implementers wishing to create parameters for use in implementation-specific applications or on private networks SHOULD mint URIs or generate names that incorporate the relevant organization's name or primary domain name. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Jul 6 12:05:52 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24ECC21F8AB4 for ; Wed, 6 Jul 2011 12:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 wn8heqPGHHZa for ; Wed, 6 Jul 2011 12:05:51 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B16F421F8AA7 for ; Wed, 6 Jul 2011 12:05:51 -0700 (PDT) Received: by pwj5 with SMTP id 5so167474pwj.31 for ; Wed, 06 Jul 2011 12:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=93Op6qjvAIcIyGPxxwntHNiRs8QpiRiMpA3VpB7umxI=; b=NYqGmoP2lqgkhaRsCYzeIOe2bKEFhsfb86udIwPoqyygvB8gX+6Me5vijxwJYXi0o1 KP87pteHbH+pu4irxZ5WF172H1nfwcn1iyeGCEviPuF0eF+Xm5+/0+hRuSKBZmi+xB64 oA7MfElNAByQ4b3apYahYE0ai8E1G0d2NVW7Y= Received: by 10.142.120.39 with SMTP id s39mr4298508wfc.237.1309979151165; Wed, 06 Jul 2011 12:05:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.88.9 with HTTP; Wed, 6 Jul 2011 12:05:31 -0700 (PDT) In-Reply-To: <20110706163134.31942.24863.idtracker@ietfa.amsl.com> References: <20110706163134.31942.24863.idtracker@ietfa.amsl.com> From: Frank Ellermann Date: Wed, 6 Jul 2011 21:05:31 +0200 Message-ID: To: john+ietf@jck.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 19:05:52 -0000 On 6 July 2011 18:31, wrote: >=A0Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-rfc3536bis-05.txt So that's the "mustardized" version for BCP status, moving RFC 2047 to normative, good. You could also list RFC 2119 as normative as part of this "mustardization", and trim section 1.3 to "SHOULD" because it's the only term needed, but that's a matter of taste. For "stringprep" you replaced by . That could be a typo if you actually mean , or more likely no <...> at all at the end of this paragraph. You've refined "glyph code", did you ever consider to add "glyph list"? The "windows glyph list 4" was famous, and I guess the concept is still relevant where full Unicode support is no option. -Frank From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Jul 6 12:34:12 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC6021F8B24 for ; Wed, 6 Jul 2011 12:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.979 X-Spam-Level: X-Spam-Status: No, score=-102.979 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 aozsmzrBsSU4 for ; Wed, 6 Jul 2011 12:34:11 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 89D2921F8B21 for ; Wed, 6 Jul 2011 12:34:11 -0700 (PDT) Received: by pzk5 with SMTP id 5so309585pzk.31 for ; Wed, 06 Jul 2011 12:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=OpRBRCFS/EOMKjUE0LFC6fDyVEXK2C85y4blp+bO85I=; b=GLZN5L+gFpiGcGWT2Y1KEJEbpiUkQ4U2NekpiJThZHBYVfgKFNd9wBlwo3n5ZZV/CS qlKiYu0LYqT9skyop2w0sLdhcUAMYMCh2TnvKJA9Qb2g/Bmcbuci4f7cPaSc6d7hWspn y2Jira8TkwxQoMkHyd/6Vs2UC1I7FUFXld7rw= Received: by 10.142.120.39 with SMTP id s39mr4308973wfc.237.1309980851123; Wed, 06 Jul 2011 12:34:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.88.9 with HTTP; Wed, 6 Jul 2011 12:33:50 -0700 (PDT) From: Frank Ellermann Date: Wed, 6 Jul 2011 21:33:50 +0200 Message-ID: To: alexey.melnikov@isode.com Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: [apps-discuss] OT: robustness (was: Call for adoption of draft-kucherawy-mta-malformed-00) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 19:34:12 -0000 Please support (or bug 652715 for IE9). That feature request uses as an example. From sm@resistor.net Wed Jul 6 12:50:38 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1987D21F8B54 for ; Wed, 6 Jul 2011 12:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 BO0zfBaTMmeA for ; Wed, 6 Jul 2011 12:50:34 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2455621F8B74 for ; Wed, 6 Jul 2011 12:50:31 -0700 (PDT) Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p66Jo9k8006629; Wed, 6 Jul 2011 12:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1309981818; bh=VKGvP4XrLd7CB8QKlu8A72qGjXrfPBiCoK3XwViYHCo=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=fQ6qKE8uLJPmcp9J0c697idojL5tV02IsAcCmZ1q11cuIHlJP5T6k1eWEc8S4Q+qI HLMB2BajmdS784b1MFqpuk/DB86+xFcX40zKFTPRI7iEQ05URbXWW+wDVQuyxSGa6g E0WwxcA/Zw79NxPrC6GbyN3dfRUZ4UvDD6ua5+MU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1309981818; bh=VKGvP4XrLd7CB8QKlu8A72qGjXrfPBiCoK3XwViYHCo=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=hZiEBgiA5gQdPd6KkCAGpd44gdCd1sjzNSBjkx8ZLEcS94CmzmbZ5YrNyPVsQZkIX 0kXa15uz+HVVADg/xJT5zNl4P/bgR0GJQAvSdNuisY8pDmCMUhTgEOPOZoBgKdn9Rv k/2ViASn4+yqXAJWQW4QzTb5SBM2mlalwbH5T02c= Message-Id: <6.2.5.6.2.20110706121726.04f54f90@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 06 Jul 2011 12:49:27 -0700 To: dcrocker@bbiw.net From: SM In-Reply-To: <4E14A334.60500@dcrocker.net> References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im> <4E14A334.60500@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 19:50:38 -0000 Hi Dave, At 11:02 06-07-2011, Dave CROCKER wrote: >The goal is to change normative behavior, so let's use normative >language (and I suggest changes to the ordering): > > 1. Implementers wishing to experiment with parameters that have any > potential to be standardized SHOULD generate names without the > "X-" prefix. > > 2. Authors of application protocol specifications SHOULD NOT > mandate that all parameters without the "X-" prefix need > to be registered with the IANA. > >(#2 seems odd. I don't really understand why it is needed or what >it does that's significant, given the recommendation of not using x- >parameters ever. Is there a way of stating what is desired affirmatively?) This is more of an open question; is it about standardizing the parameter or using the parameter over the Internet? If an implementer wishes to use a parameter over the Internet, generate an I-D and ask for a provisional registration. The problem with (2) is that it takes us back to the X- debate where "X-" was a way to have a parameter without IANA registration. If the goal is to explain that X- has more cost than benefits, I am fine with what the document says. For anything else, RFC 4122 derived parameters or one derived from the domain name might do. The issue with the latter can be addressed by getting a IANA registration. Regards, -sm From stpeter@stpeter.im Wed Jul 6 13:05:21 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD0621F8B3C for ; Wed, 6 Jul 2011 13:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.69 X-Spam-Level: X-Spam-Status: No, score=-103.69 tagged_above=-999 required=5 tests=[AWL=0.909, BAYES_00=-2.599, GB_I_LETTER=-2, 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 tP2tcGQY3Dlv for ; Wed, 6 Jul 2011 13:05:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C9F2421F8AE4 for ; Wed, 6 Jul 2011 13:05:20 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1025F40F84; Wed, 6 Jul 2011 14:05:23 -0600 (MDT) Message-ID: <4E14BFFC.5070504@stpeter.im> Date: Wed, 06 Jul 2011 14:05:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im> <4E14A334.60500@dcrocker.net> In-Reply-To: <4E14A334.60500@dcrocker.net> X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 20:05:21 -0000 On 7/6/11 12:02 PM, Dave CROCKER wrote: > > > On 7/5/2011 8:52 PM, Peter Saint-Andre wrote: >> On 6/27/11 12:36 PM, Peter Saint-Andre wrote: >>> Based on comments received to date, I've published a heavily-revised >>> version of the "X-" proposal: >>> >>> http://www.ietf.org/id/draft-saintandre-xdash-00.txt >> >> Based on list feedback, I've submitted a further revision (including >> much more specific recommendations for spec authors and implementers): >> >> http://www.ietf.org/id/draft-saintandre-xdash-01.txt >> >> Keep those cards and letters coming! ;-) >> >> Peter >> > >> Use of the "X-" Prefix in Application Protocols > > That title is neutral, but this document is not. I suggest the title > communicate the goal. Something like: > > Deprecating use of the "X-" Prefix in Application Protocols Done in my working copy. > Hmmm. There were various messages that criticized the document for > being a warning rather than a constructive directive. The current draft > offers some specific advice (which I recommend be phrase normatively.) > > Perhaps this document also should cite specific changes for specific > protocols that currently call for x-? (Email already fixed this, going > from RFC822 to RFC2822, though that's probably worth citing.) Done. > Generically, it might cite the known cases of use and simply direct not > using them, instead giving examples of what to do for each case. People like examples. :) > The most general form of the directive would be "Make the assumption > that the use will become popular and eventually attain standards > status. What name is preferred in this case? Normally it would be the > same as is chosen with the X- preface, but without that preface. In > some cases, a different string might be preferred. Seems right. >> Abstract > ... >> although it can be >> appropriate in certain circumstances. > > although it can still be appropriate to use in certain circumstances. > > >> 1. Background > ... >> Although this usage is purely conventional and is not mandated by the >> Internet Standards Process [BCP9] or IANA registration rules [BCP26], >> some implementers, and even some RFCs, have interpreted the >> convention in a more normative way (e.g., [RFC5451] states that >> "result codes not beginning with 'x-' MUST be registered with the >> Internet Assigned Numbers Authority (IANA) and published in an RFC"). > > The approach to this text seems odd to me. It's also a bit misleading > to say 'purely conventional' for something that has been, in fact, > formally standardized. (RFC822 was a standard and specified this > formally.) > > So, perhaps: > > Use of this naming convention is not mandated by the Internet > Standards Process [BCP9] or basic IANA registration rules [BCP26]. > Rather it is an individual choice by each specification that defines it > or administrative process that chooses to use it. For example, > [RFC5451] states that "result codes not beginning with 'x-' MUST be > registered with the Internet Assigned Numbers Authority (IANA) and > published in an RFC"). Better. I think we can just reference RFC 822 and RFC 5451 here, without going into specifics. >> Parameters prefaced with the "X-" string are currently used in >> application protocols for two different purposes: > > Given the line of concern of this document, I suggest that the emphasis > be about intent rather than effect or "use". So... > > Parameters prefaced with the "X-" string are currently motivated by > two different goals: I've incorporated something along those lines, thanks. >> 2. Analysis > ... > > Looking at the pattern of the numbered items, pro and con, the template > is a very terse (partial sentence) statement of the pro, followed by > some sentences discussing the con. What's missing is a clear and > complete explanation of the pro view, in each case. As a consequence, I > didn't understand the opening point a number of times... Yes, a more complete description would be helpful. >> In some situations, segregating the name space of parameters used in >> a given application protocol can be justified: >> >> 1. When it is extremely unlikely that some parameters will ever be >> standardized. > > The problem, here, is predicting the future. It never works and is, in > fact, the underlying problem with the X- construct. > > Perhaps this #1 really intends to cover the case in which is considered > to be /undesirable/ to have the parameter standardized? > > >> 2. When parameter names might have significant meaning. > > I don't understand what this one means. I don't fully understand it either. :) I pulled it from previous list discussion but didn't ask the person who posted it for clarification. > From the rest of its text, > perhaps it means that the x- name includes an string that is already > standardized by some other spec? That's my sense. >> 3. When parameter names need to be very short > > I've no idea how this requirement can justify an x- name. (A minor > point, but note that x- adds two bytes to the length of the name...) Well, "x-foo" is shorter than "VND.BrandenburgInternetWorking.foo". >> There are two primary objections to deprecating the "X-" > > Meta-issue: Since the preceding sequence was numbered and this > following section parallels it, it should be numbered, too. Done. >> Implementers are easily confused. > > I don't understand how using or not using x- creates or alleviates > confusion in implementers. I don't either, but that was one of the objections. >> Collisions are undesirable. > > I think that the premise to this statement is that dropping x- will > increase the likelihood of collisions. That should be stated > explicitly. It was, after all, the motivating concern for justifying > the x- convention. I think the question is how realistic the concern > really is, especially given the ability to make registration much easier > than it used to be. > > >> Furthermore, the existence of [BCP82] > > In formatting terms, I think this should be another item in the list of > objections (#3). Done. >> 3. Recommendations > ... >> 1. Authors of application protocol specifications are discouraged >> from imputing special meaning to parameters with the "X-" prefix. > > The goal is to change normative behavior, so let's use normative > language WFM. > (and I suggest changes to the ordering): > > 1. Implementers wishing to experiment with parameters that have any > potential to be standardized SHOULD generate names without the > "X-" prefix. > > 2. Authors of application protocol specifications SHOULD NOT > mandate that all parameters without the "X-" prefix need > to be registered with the IANA. > > (#2 seems odd. I don't really understand why it is needed or what it > does that's significant, given the recommendation of not using x- > parameters ever. Is there a way of stating what is desired affirmatively?) The point is directed at the kind of thing we find in RFC 5451, which says that x- params MUST NOT be registered and non-x- params MUST be registered. That seems wrongheaded to me. > 3. Authors of application protocol specifications are discouraged > from imputing special meaning to parameters with the "X-" prefix. > > 4. Implementers wishing to experiment with parameters that are > intended not to be standardized SHOULD generate meaningless > names such as UUIDs or the output of a hash function. > > 5. Implementers wishing to create parameters for use in > implementation-specific applications or on private networks SHOULD > mint URIs or generate names that incorporate the relevant > organization's name or primary domain name. Yep, and I have some more changes and examples in the recommendations section now, too. Dave, I'll push out a new version with you and Mark Nottingham as co-authors and we can fight over who presents on the topic in Quebec City. Peter -- Peter Saint-Andre https://stpeter.im/ From dhc@dcrocker.net Wed Jul 6 13:54:10 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA4E21F8C08 for ; Wed, 6 Jul 2011 13:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.932 X-Spam-Level: X-Spam-Status: No, score=-6.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 cPL-mU4jKEJl for ; Wed, 6 Jul 2011 13:54:05 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B162D21F8C07 for ; Wed, 6 Jul 2011 13:54:05 -0700 (PDT) Received: from [192.168.1.156] (adsl-67-124-149-98.dsl.pltn13.pacbell.net [67.124.149.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p66KrxFZ011846 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 6 Jul 2011 13:54:04 -0700 Message-ID: <4E14CB64.2090403@dcrocker.net> Date: Wed, 06 Jul 2011 13:53:56 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im> <4E14A334.60500@dcrocker.net> <4E14BFFC.5070504@stpeter.im> In-Reply-To: <4E14BFFC.5070504@stpeter.im> 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, 06 Jul 2011 13:54:05 -0700 (PDT) Cc: dcrocker@bbiw.net, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 20:54:10 -0000 On 7/6/2011 1:05 PM, Peter Saint-Andre wrote: >>> 3. When parameter names need to be very short >> >> I've no idea how this requirement can justify an x- name. (A minor >> point, but note that x- adds two bytes to the length of the name...) > > Well, "x-foo" is shorter than "VND.BrandenburgInternetWorking.foo". Mumble. This issue seems like one that is going to take vastly more effort than it ought, but that's probably true for the entire topic. (Entire topic: X- was a good idea to avoid collisions with standards, but turns out to be a much worse idea for uses that become standards. So, don't use X-".) Anyhow... "X-foo" is longer than "foo". And I believe the real comparision to VND should be "X-BrandenburgInternetWorking.foo"... >>> Implementers are easily confused. >> >> I don't understand how using or not using x- creates or alleviates >> confusion in implementers. > > I don't either, but that was one of the objections. OK, but whoever was/is objecting needs to explain their concerns, of course. >> 2. Authors of application protocol specifications SHOULD NOT >> mandate that all parameters without the "X-" prefix need >> to be registered with the IANA. >> >> (#2 seems odd. I don't really understand why it is needed or what it >> does that's significant, given the recommendation of not using x- >> parameters ever. Is there a way of stating what is desired affirmatively?) > > The point is directed at the kind of thing we find in RFC 5451, which > says that x- params MUST NOT be registered and non-x- params MUST be > registered. That seems wrongheaded to me. OK. I think this reduces to a new phrasing along the lines of: Authors of application protocol specifications SHOULD provide extensible registries for all parameters and SHOULD mandate use of the registries, for all values of the parameters, independent of the form of the parameter names. (The absence of any reference to X- is intentional.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From stpeter@stpeter.im Wed Jul 6 13:54:35 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B93221F8C07 for ; Wed, 6 Jul 2011 13:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, 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 fVM6ZNp-3Aft for ; Wed, 6 Jul 2011 13:54:32 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B029621F8B2F for ; Wed, 6 Jul 2011 13:54:32 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1792240F84; Wed, 6 Jul 2011 14:54:36 -0600 (MDT) Message-ID: <4E14CB86.7030706@stpeter.im> Date: Wed, 06 Jul 2011 14:54:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] apps schedule changes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 20:54:35 -0000 Folks, to accomodate a large number of late constraints, I've asked the Secretariat to adjust the scheduling of various apps-area WG and BoF sessions. This wasn't desirable, but the arrangement I came up with is the best I could work out on short notice (the paper schedules need to go to the printer today). The Secretariat should be updating the online agenda before too long, but the *changed* sessions were as follows: 1. move APPSAWG from MON 09:00-11:30 to THU 15:20-17:20 (vs. tictoc, siprec, hokey, pce, tls, ospf, v6ops) 2. move HTTPBIS from MON 13:00-15:00 to TUE 09:00-11:30 (vs. eai, xmpp, tcpm, p2prg, geopriv, ccamp, v6ops) 3. move HTTPAUTH from TUE 09:00-11:30 to MON 09:00-11:30 (vs. nfsv4, radext, multimob, ippm, dtnrg, mpls, dispatch) 4. move PRECIS from WED 13:00-15:00 to THU 13:00-15:00 (vs. dime, bmwg, netext, rtgwg, ccamp, rtcweb) 5. move WEBSEC from THU 13:00-15:00 to MON 13:00-15:00 (vs. netconf, pkix, list, ppsp, ecrit, trill, multrans) 6. move HYBI from THU 15:20-17:20 to THU 17:40-19:40 (vs. samrg, kitten, eman, mif, codec, cdni, rtgarea) 7. move CORE (second session) from THU 17:40-19:40 to WED 13:00-15:00 (vs. nea, ipfix, cuss, homenet, karp, mpls, conex) No, this is not ideal. The schedule never is. Please accept my apologies for any remaining overlaps and conflicts. See you in Quebec City! Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Jul 6 14:01:59 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B7121F85C7 for ; Wed, 6 Jul 2011 14:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.742 X-Spam-Level: X-Spam-Status: No, score=-102.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, 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 9lu+a1iMXbPR for ; Wed, 6 Jul 2011 14:01:58 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5925121F85C4 for ; Wed, 6 Jul 2011 14:01:56 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B2B7540F84; Wed, 6 Jul 2011 15:02:00 -0600 (MDT) Message-ID: <4E14CD42.2010800@stpeter.im> Date: Wed, 06 Jul 2011 15:01:54 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im> <4E14A334.60500@dcrocker.net> <4E14BFFC.5070504@stpeter.im> <4E14CB64.2090403@dcrocker.net> In-Reply-To: <4E14CB64.2090403@dcrocker.net> X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 21:01:59 -0000 On 7/6/11 2:53 PM, Dave CROCKER wrote: > > > On 7/6/2011 1:05 PM, Peter Saint-Andre wrote: >>>> 3. When parameter names need to be very short >>> >>> I've no idea how this requirement can justify an x- name. (A minor >>> point, but note that x- adds two bytes to the length of the name...) >> >> Well, "x-foo" is shorter than "VND.BrandenburgInternetWorking.foo". > > Mumble. This issue seems like one that is going to take vastly more > effort than it ought, but that's probably true for the entire topic. > (Entire topic: X- was a good idea to avoid collisions with standards, > but turns out to be a much worse idea for uses that become standards. > So, don't use X-".) > > Anyhow... > > "X-foo" is longer than "foo". > > And I believe the real comparision to VND should be > "X-BrandenburgInternetWorking.foo"... > > >>>> Implementers are easily confused. >>> >>> I don't understand how using or not using x- creates or alleviates >>> confusion in implementers. >> >> I don't either, but that was one of the objections. > > OK, but whoever was/is objecting needs to explain their concerns, of > course. > > >>> 2. Authors of application protocol specifications SHOULD NOT >>> mandate that all parameters without the "X-" prefix need >>> to be registered with the IANA. >>> >>> (#2 seems odd. I don't really understand why it is needed or what it >>> does that's significant, given the recommendation of not using x- >>> parameters ever. Is there a way of stating what is desired >>> affirmatively?) >> >> The point is directed at the kind of thing we find in RFC 5451, which >> says that x- params MUST NOT be registered and non-x- params MUST be >> registered. That seems wrongheaded to me. > > OK. I think this reduces to a new phrasing along the lines of: > > Authors of application protocol specifications SHOULD provide > extensible registries for all parameters and SHOULD mandate use of the > registries, for all values of the parameters, independent of the form of > the parameter names. The second SHOULD strikes me as somewhat controversial. :) The first SHOULD is fine by me, although I'm not sure what an extensible registry is -- did you mean "both permanent and provisional registries"? Peter -- Peter Saint-Andre https://stpeter.im/ From paul.hoffman@vpnc.org Wed Jul 6 14:25:54 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6808821F8ACC for ; Wed, 6 Jul 2011 14:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, 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 yclSNrsmqGIA for ; Wed, 6 Jul 2011 14:25:54 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 88A2321F8AC2 for ; Wed, 6 Jul 2011 14:25:51 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p66LPWwL045567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Jul 2011 14:25:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4E14CD42.2010800@stpeter.im> Date: Wed, 6 Jul 2011 14:25:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7B0B0248-DD76-4CF9-9108-9BB5F74F1900@vpnc.org> References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im> <4E14A334.60500@dcrocker.net> <4E14BFFC.5070504@stpeter.im> <4E14CB64.2090403@dcrocker.net> <4E14CD42.2010800@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1084) Cc: dcrocker@bbiw.net, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 21:25:54 -0000 On Jul 6, 2011, at 2:01 PM, Peter Saint-Andre wrote: > On 7/6/11 2:53 PM, Dave CROCKER wrote: >> Authors of application protocol specifications SHOULD provide >> extensible registries for all parameters and SHOULD mandate use of = the >> registries, for all values of the parameters, independent of the form = of >> the parameter names. >=20 > The second SHOULD strikes me as somewhat controversial. :) Not much more controversial than the whole topic. I can quickly name = many protocols for which "some values are reserved for experimental use" = have had horrible problems in practice, either where an experimental = value ended up being baked into shipping products or two vendors used = the same experimental use value for different things. Maybe the Apps Area is not as familiar with "values 250 through 255 are = reserved for experimental use" than the rest of the IETF, but the topic = is quite germane to this draft. Dave's proposed wording is hard to = swallow, but probably best for the real-world long-lived Internet. > The first SHOULD is fine by me, although I'm not sure what an = extensible > registry is -- did you mean "both permanent and provisional = registries"? And extensible registry is one where there is a registration procedure = so that today's registry might be larger tomorrow. --Paul Hoffman From dhc@dcrocker.net Wed Jul 6 14:50:33 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838AC21F8BE2 for ; Wed, 6 Jul 2011 14:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.849 X-Spam-Level: X-Spam-Status: No, score=-6.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 3NN877oFK1mz for ; Wed, 6 Jul 2011 14:50:33 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1728021F8BE1 for ; Wed, 6 Jul 2011 14:50:33 -0700 (PDT) Received: from [192.168.1.156] (adsl-67-124-149-98.dsl.pltn13.pacbell.net [67.124.149.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p66LoRJO013420 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 6 Jul 2011 14:50:32 -0700 Message-ID: <4E14D8A0.8090409@dcrocker.net> Date: Wed, 06 Jul 2011 14:50:24 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im> <4E14A334.60500@dcrocker.net> <4E14BFFC.5070504@stpeter.im> <4E14CB64.2090403@dcrocker.net> <4E14CD42.2010800@stpeter.im> In-Reply-To: <4E14CD42.2010800@stpeter.im> 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, 06 Jul 2011 14:50:32 -0700 (PDT) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 21:50:33 -0000 On 7/6/2011 2:01 PM, Peter Saint-Andre wrote: >> Authors of application protocol specifications SHOULD provide >> extensible registries for all parameters and SHOULD mandate use of the >> registries, for all values of the parameters, independent of the form of >> the parameter names. > > The second SHOULD strikes me as somewhat controversial. :) Yup. But I figured, in for a penny... > The first SHOULD is fine by me, although I'm not sure what an extensible > registry is -- did you mean "both permanent and provisional registries"? That was a tad cryptic, wasn't it. To be extensible, I meant that it needs to be listed with IANA, with procedures for making additions. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From stpeter@stpeter.im Wed Jul 6 18:43:50 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EE121F8A5B for ; Wed, 6 Jul 2011 18:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.312 X-Spam-Level: X-Spam-Status: No, score=-103.312 tagged_above=-999 required=5 tests=[AWL=-0.712, BAYES_00=-2.599, 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 ODbvdi9Ku+Oe for ; Wed, 6 Jul 2011 18:43:49 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B7D0721F8A58 for ; Wed, 6 Jul 2011 18:43:49 -0700 (PDT) Received: from squire.local (unknown [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6481E40F84; Wed, 6 Jul 2011 19:43:54 -0600 (MDT) Message-ID: <4E150F53.5090100@stpeter.im> Date: Wed, 06 Jul 2011 19:43:47 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im> <4E14A334.60500@dcrocker.net> <4E14BFFC.5070504@stpeter.im> <4E14CB64.2090403@dcrocker.net> <4E14CD42.2010800@stpeter.im> <4E14D8A0.8090409@dcrocker.net> In-Reply-To: <4E14D8A0.8090409@dcrocker.net> X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 01:43:50 -0000 On 7/6/11 3:50 PM, Dave CROCKER wrote: > > > On 7/6/2011 2:01 PM, Peter Saint-Andre wrote: >>> Authors of application protocol specifications SHOULD provide >>> extensible registries for all parameters and SHOULD mandate use of the >>> registries, for all values of the parameters, independent of the form of >>> the parameter names. >> >> The second SHOULD strikes me as somewhat controversial. :) > > Yup. But I figured, in for a penny... > > >> The first SHOULD is fine by me, although I'm not sure what an extensible >> registry is -- did you mean "both permanent and provisional registries"? > > That was a tad cryptic, wasn't it. > > To be extensible, I meant that it needs to be listed with IANA, with > procedures for making additions. Got it. Tweaked in my working copy to: 2. Specification authors SHOULD provide unlimited registries with well-defined registration procedures and SHOULD mandate registration of all parameters, independent of the form of the parameter names. Peter -- Peter Saint-Andre https://stpeter.im/ From dcrocker@bbiw.net Wed Jul 6 18:46:07 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C823D21F878F for ; Wed, 6 Jul 2011 18:46:07 -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 ojphwTt34DBI for ; Wed, 6 Jul 2011 18:46:07 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1F55C21F8A61 for ; Wed, 6 Jul 2011 18:46:07 -0700 (PDT) Received: from [192.168.1.4] (adsl-67-124-149-98.dsl.pltn13.pacbell.net [67.124.149.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p671k0g5017720 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 6 Jul 2011 18:46:06 -0700 References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im> <4E14A334.60500@dcrocker.net> <4E14BFFC.5070504@stpeter.im> <4E14CB64.2090403@dcrocker.net> <4E14CD42.2010800@stpeter.im> <4E14D8A0.8090409@dcrocker.net> <4E150F53.5090100@stpeter.im> User-Agent: K-9 Mail for Android In-Reply-To: <4E150F53.5090100@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Dave Crocker Date: Wed, 06 Jul 2011 18:45:58 -0700 To: Peter Saint-Andre Message-ID: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 06 Jul 2011 18:46:06 -0700 (PDT) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 01:46:07 -0000 Peter Saint-Andre wrote: >On 7/6/11 3:50 PM, Dave CROCKER wro >Got it. Tweaked in my working copy to: > > 2. Specification authors SHOULD provide unlimited registries with > well-defined registration procedures and SHOULD mandate > registration of all parameters, independent of the form of the > parameter wfm. d/ -- Dave Crocker bbiw.net From stpeter@stpeter.im Wed Jul 6 19:25:01 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F8021F8A6D for ; Wed, 6 Jul 2011 19:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.232 X-Spam-Level: X-Spam-Status: No, score=-103.232 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, 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 y3b8QBu986R9 for ; Wed, 6 Jul 2011 19:25:01 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C40B221F8A6C for ; Wed, 6 Jul 2011 19:25:00 -0700 (PDT) Received: from squire.local (unknown [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9FE0A40F84; Wed, 6 Jul 2011 20:25:05 -0600 (MDT) Message-ID: <4E1518F2.6000403@stpeter.im> Date: Wed, 06 Jul 2011 20:24:50 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Dirk Pranke References: <4E08CDCB.70902@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 02:25:01 -0000 On 6/29/11 4:05 PM, Dirk Pranke wrote: > Your draft has: > >> In some situations, segregating the name space of parameters used in >> a given application protocol can be justified: >> ... >> 2. When parameter names might have significant meaning. This case >> is rare, since implementers can almost always find a synonym >> (e.g., "urgency" instead of "priority") or simply invent a new >> name. > > It seems to me that a primary benefit of the "X-" convention is that > it makes unprefixed parameter names less socially acceptable; That's tautological -- the "X-" convention attempts to segregate the parameter space by dividing it into the standard area (a good, clean, safe, respectable place to be) and the non-standard area (a bad, dirty, unsafe, slightly scandalous place to be). Naturally it's less socially acceptable to be in the non-standard part of town. > i.e., > there's a pretty clear rule of thumb that if the name isn't X- > prefixed, it probably has seen a pass through a committee and hence it > stands at least a chance of having the same meaning in multiple > implementations. The fact of leakage from the non-standard area into the standard area shows that it's quite possible for one of those raffish parameters starting with "X-" to have the same meaning in multiple implementations. And I'll not that passing through a committee does not necessarily guarantee that a parameter will have the same meaning in multiple implementations, or be a better parameter for the experience. Is your argument that we want to encourage folks to cross the tracks into the more respectable part of the parameter space by publishing Internet-Drafts and gaining consensus on their proposals? That seems to be a good thing no matter what the form of the parameter name. Shedding the mark of the "X-" strikes me as a rather insignificant benefit of standardization. > I am concerned that if you abandon the X- practice, you will lose this > benefit and finding untainted, available parameter names might become > harder. Sure, you can often find a synonym, but it is not usually as > good as the original choice. I would hate to see things move to a > namespace land-grab like we have seen in DNS. As Eric Burger noted, there's not much danger of a land grab here. Although it's nice for protocol parameter names to be readable to developers (for debugging and the like), they're not intended to be shown to end users, so there's not much need or incentive to reserve the cool names before some parameter shark gets to them. Is there some kind of attack lurking here that we're not aware of? Parameter phishing or somesuch? Peter -- Peter Saint-Andre https://stpeter.im/ From dpranke@google.com Wed Jul 6 20:31:22 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDA021F888D for ; Wed, 6 Jul 2011 20:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 JZFs-Ez+qsmX for ; Wed, 6 Jul 2011 20:31:21 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3D09521F888A for ; Wed, 6 Jul 2011 20:31:20 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p673VJT3005188 for ; Wed, 6 Jul 2011 20:31:19 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310009479; bh=r/wiYoJ87U6ELpjsecgd2FLkkEU=; h=MIME-Version:Sender:In-Reply-To:References:From:Date:Message-ID: Subject:To:Cc:Content-Type; b=SxIum7Y/IOexYxmCxZuWf2xP3t1NqaBokOfT7XsndmUTPhtViBjwEqRh4js2dSiBR SP3gP7E0I6JyeBLGkz0Lw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:sender:in-reply-to:references:from: date:x-google-sender-auth:message-id:subject:to:cc:content-type:x-system-of-record; b=iDt0BOP8WCr8/XJh5Hl2AgorBy94IsCbHGHyvhdF6+kaElD3jWCRcpJD81whrYION PhLKLmfvaJ2ltkr+U9WcA== Received: from pwj9 (pwj9.prod.google.com [10.241.219.73]) by kpbe18.cbf.corp.google.com with ESMTP id p673VHXl021350 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 6 Jul 2011 20:31:17 -0700 Received: by pwj9 with SMTP id 9so471934pwj.7 for ; Wed, 06 Jul 2011 20:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=zHhrsawgEvPMok6ubU2VKIoWJfDsI1PipC4veceF/Y8=; b=ZRzSl87I83F5hpL5Xl0zSYVecR5iSfAw4d1sRtfwTh9YZbW0DM6CAHjYOU9sd9nAIT SKxsnMuMaVxILH+8u5yg== Received: by 10.142.225.17 with SMTP id x17mr163695wfg.227.1310009477138; Wed, 06 Jul 2011 20:31:17 -0700 (PDT) MIME-Version: 1.0 Sender: dpranke@google.com Received: by 10.142.193.2 with HTTP; Wed, 6 Jul 2011 20:30:57 -0700 (PDT) In-Reply-To: <4E1518F2.6000403@stpeter.im> References: <4E08CDCB.70902@stpeter.im> <4E1518F2.6000403@stpeter.im> From: Dirk Pranke Date: Wed, 6 Jul 2011 20:30:57 -0700 X-Google-Sender-Auth: d3ew8eNYPXxjWmiJD-3YpdQZP3s Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 03:31:22 -0000 On Wed, Jul 6, 2011 at 7:24 PM, Peter Saint-Andre wrote: > > Is there some kind of attack lurking here that we're not aware of? > Parameter phishing or somesuch? > No, that was not my concern. I am mostly trying to map your arguments onto the way we're currently evolving the HTML APIs, which follow a similar convention to X- (the vendor prefixes). -- Dirk From stpeter@stpeter.im Wed Jul 6 20:54:41 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D9321F87C6 for ; Wed, 6 Jul 2011 20:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.117 X-Spam-Level: X-Spam-Status: No, score=-103.117 tagged_above=-999 required=5 tests=[AWL=-0.518, BAYES_00=-2.599, 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 uApoJtgPx-dR for ; Wed, 6 Jul 2011 20:54:40 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9705821F8621 for ; Wed, 6 Jul 2011 20:54:40 -0700 (PDT) Received: from squire.local (unknown [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F235E40F84; Wed, 6 Jul 2011 21:54:45 -0600 (MDT) Message-ID: <4E152DFE.8080804@stpeter.im> Date: Wed, 06 Jul 2011 21:54:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Dirk Pranke References: <4E08CDCB.70902@stpeter.im> <4E1518F2.6000403@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 03:54:41 -0000 On 7/6/11 9:30 PM, Dirk Pranke wrote: > On Wed, Jul 6, 2011 at 7:24 PM, Peter Saint-Andre wrote: >> >> Is there some kind of attack lurking here that we're not aware of? >> Parameter phishing or somesuch? >> > > No, that was not my concern. I am mostly trying to map your arguments > onto the way we're currently evolving the HTML APIs, which follow a > similar convention to X- (the vendor prefixes). Can you provide a pointer for this work? Peter From evnikita2@gmail.com Thu Jul 7 03:14:15 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34D821F869A for ; Thu, 7 Jul 2011 03:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.526 X-Spam-Level: X-Spam-Status: No, score=-3.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 5-Kk5wsNpkQl for ; Thu, 7 Jul 2011 03:14:14 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 289C321F84AC for ; Thu, 7 Jul 2011 03:14:13 -0700 (PDT) Received: by bwb17 with SMTP id 17so857577bwb.31 for ; Thu, 07 Jul 2011 03:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=5yxFGqg2kZk5ymS1uVaKsjt45aJvYkQyGdq93bAcyPc=; b=iGwfVfwLEUKvgukBQdYcUgxsm8blbEiJ1Op5A41Ndb4x9ij8yPjESk7+a3w/WkE6dj +qF8dyVglRjh2GMkpnjplxWQxJUh1ddSyinf+nsarIdOWR2Ec8rClHGTwu6OElNkMov7 VOG6I8I9OVLIhn7AHZgtASwvvWGlpJSK/y3RQ= Received: by 10.205.33.130 with SMTP id so2mr536340bkb.129.1310033652953; Thu, 07 Jul 2011 03:14:12 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id t9sm8380478bkn.20.2011.07.07.03.14.11 (version=SSLv3 cipher=OTHER); Thu, 07 Jul 2011 03:14:11 -0700 (PDT) Message-ID: <4E158722.60101@gmail.com> Date: Thu, 07 Jul 2011 13:14:58 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Apps-discuss list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Designating SUPDUP-related RFCs as Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 10:14:15 -0000 Hello, RFC 734 specifies the SUPDUP protocol. However, currently, RFC 734 is moved to Historic. And, when moving it to Historic, a number of RFCs related to SUPDUP weren't. They include RFC 736, 749, which are Standards Track (PSs), and 746 and 747, which are Unknown. The first two are PSs and depend on Historic RFC, which I personally think it is inappropriate. Therefore I'd like to ask whether there could be a consensus in moving all SUPDUP-related RFCs to Historic. Thanks, Mykyta Yevstifeyev From sm@resistor.net Thu Jul 7 03:31:51 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A03121F8792 for ; Thu, 7 Jul 2011 03:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 s8h47fQ0WwRE for ; Thu, 7 Jul 2011 03:31:49 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C92AE21F8787 for ; Thu, 7 Jul 2011 03:31:48 -0700 (PDT) Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p67AVb3k026660; Thu, 7 Jul 2011 03:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1310034702; bh=FXLXfqoEi+tyZYn4XNE08bGzNT6p2rEJrI713Q5EFlE=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=FPgU7/yPH4cjRTFuUsghAZuAJdT8Gkm1dGMVyCC20z6jNbG2/2H4SS6NTyJ5ebVl0 hdE7lsDQupefG4DypOhvabzvabYiyROR8q/8sOu/vUMJ7pe0Pi5FBvYNHuW+Xi2xEO P0uJJbxNmkDySfqc5pcd2240j8NY2/d4oIN1Qd6g= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1310034702; bh=FXLXfqoEi+tyZYn4XNE08bGzNT6p2rEJrI713Q5EFlE=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=h273f87x06YXmVKxy+SIqWMqb4Cp0VxEJwrVMhA4iBzXobh6+QFlprskyTkqn3wsk nhZ3wKJ2eQ0KaXQF/9Q7DSXNxBDncxcqt03XQrElEtLO68YqQaHbXp8r7Do/a63Z/r +cbdd2l1YbB+cVuE1qXjM8S7v8filqqmpyRBP8hc= Message-Id: <6.2.5.6.2.20110707031904.04dcc150@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 07 Jul 2011 03:29:57 -0700 To: Mykyta Yevstifeyev From: SM In-Reply-To: <4E158722.60101@gmail.com> References: <4E158722.60101@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Designating SUPDUP-related RFCs as Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 10:31:51 -0000 Hi Mykyta, At 03:14 07-07-2011, Mykyta Yevstifeyev wrote: >RFC 734 specifies the SUPDUP protocol. However, currently, RFC 734 >is moved to Historic. And, when moving it to Historic, a number of >RFCs related to SUPDUP weren't. According to the datatracker, you currently have three drafts about reclassification of RFCs. As you are putting some effort in moving some RFCs to Historic, may I suggest that you use the approach documented in RFC 4450? Regards, -sm From evnikita2@gmail.com Thu Jul 7 04:12:07 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB99621F8793 for ; Thu, 7 Jul 2011 04:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 BG+UWMKJ7cJb for ; Thu, 7 Jul 2011 04:12:07 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0537A21F878F for ; Thu, 7 Jul 2011 04:12:06 -0700 (PDT) Received: by bwb17 with SMTP id 17so897776bwb.31 for ; Thu, 07 Jul 2011 04:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xN6wGmZOfWPZ1Mr1jmWpupl52D+7lfSDo+cklkHYnFU=; b=ba+qOpM4UgRvOowsmweGI4KJbAhzyVxZrSgzoekjEhcht+TpNcXjOAggGRHdEHcTRD GosvtDpaIs4sRLShZya8X2cq7mSO9CjtRgMJQ93+5snSZdtEjXhg9+KGxGijumX4Jtc1 H/Z364c4PFpTRa2AIGf+Kjn5uF/BK+TRveDWY= Received: by 10.204.7.134 with SMTP id d6mr537794bkd.206.1310037125580; Thu, 07 Jul 2011 04:12:05 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id lb15sm2273520bkb.1.2011.07.07.04.12.04 (version=SSLv3 cipher=OTHER); Thu, 07 Jul 2011 04:12:04 -0700 (PDT) Message-ID: <4E1594B2.9060409@gmail.com> Date: Thu, 07 Jul 2011 14:12:50 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: SM References: <4E158722.60101@gmail.com> <6.2.5.6.2.20110707031904.04dcc150@resistor.net> In-Reply-To: <6.2.5.6.2.20110707031904.04dcc150@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Designating SUPDUP-related RFCs as Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 11:12:07 -0000 07.07.2011 13:29, SM wrote: > Hi Mykyta, > At 03:14 07-07-2011, Mykyta Yevstifeyev wrote: >> RFC 734 specifies the SUPDUP protocol. However, currently, RFC 734 >> is moved to Historic. And, when moving it to Historic, a number of >> RFCs related to SUPDUP weren't. > > According to the datatracker, you currently have three drafts about > reclassification of RFCs. As you are putting some effort in moving > some RFCs to Historic, may I suggest that you use the approach > documented in RFC 4450? RFC 4450 was an effort of bulk reclassification, as mentioned there. My proposal is to historicize 4 RFCs. It is caused by a simple omission when moving RFC 734 to Historic. Moreover, RFC 4450 was a result to suit the requirement of RFC 2026 for annual review of PSs, which will be eliminated by RFC-housley-two-maturity-levels. Mykyta Yevstifeyev > > Regards, > -sm > From evnikita2@gmail.com Thu Jul 7 07:53:30 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DB921F8759; Thu, 7 Jul 2011 07:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 y5Jj6n5cA9-e; Thu, 7 Jul 2011 07:53:29 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2305621F8751; Thu, 7 Jul 2011 07:53:28 -0700 (PDT) Received: by bwb17 with SMTP id 17so1082502bwb.31 for ; Thu, 07 Jul 2011 07:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=FCiAl4+tB6tIqO19supqHKDVppYOyXVVzIU1KJsiC5U=; b=oLmrpu00E6oLmINS/Jtr/zZXpsM2SuKtMWIoUXE7/K5dcPG/QqXJYKfa3CCV7jUgu8 OL6nzOTYri5SJZliBWs7g0+x0AX11m9JXtPb2KM0vtpuhKWnhcfYAo1XS6LuzgLGKBPI IuCx3qvBOMNzah8jPdNkr9snLvz97gSBwHqoA= Received: by 10.204.37.141 with SMTP id x13mr807313bkd.116.1310050408128; Thu, 07 Jul 2011 07:53:28 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id k5sm8610455bka.17.2011.07.07.07.53.26 (version=SSLv3 cipher=OTHER); Thu, 07 Jul 2011 07:53:27 -0700 (PDT) Message-ID: <4E15C895.6020701@gmail.com> Date: Thu, 07 Jul 2011 17:54:13 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "ftpext@ietf.org" , "uri-review@ietf.org" , URI , Apps-discuss list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 14:53:30 -0000 I've just uploaded a new version of draft-yevstifeyev-ftp-uri-scheme. Any further comments are welcome. Mykyta > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : The'ftp' URI Scheme > Author(s) : Mykyta Yevstifeyev > Filename : draft-yevstifeyev-ftp-uri-scheme-04.txt > Pages : 22 > Date : 2011-07-07 > > This document specifies the'ftp' Uniform Resource Identifier (URI) > scheme, which is used to refer to resources accessible via File > Transfer Protocol (FTP). It updates RFC 959 and RFC 1738. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-yevstifeyev-ftp-uri-scheme-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-yevstifeyev-ftp-uri-scheme-04.txt From sm@resistor.net Thu Jul 7 09:23:57 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BE321F874A for ; Thu, 7 Jul 2011 09:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 C83YjUwcGCwM for ; Thu, 7 Jul 2011 09:23:56 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4735721F8745 for ; Thu, 7 Jul 2011 09:23:56 -0700 (PDT) Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p67GNi5m003484; Thu, 7 Jul 2011 09:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1310055831; bh=mCbDu0bc/LjW23qbB16n3TknpBTqer8d3QvcBJLpRS0=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=hU2H0FmtniFbfYBhFLgL1V0wJ06CyjHjWQc0NxDGpmKwM++MqKrU6Ywe5npS3tEpY ZuduT+GXbZc7gSsOw8s5+Z6I0PPaoEQDRYi9Ifcown3UeQ7BXec+66QVk+yzYj1Ku1 ztpkvvPvucoYp864OIk8II7/O6rJY/oqzAmUU7Uk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1310055831; bh=mCbDu0bc/LjW23qbB16n3TknpBTqer8d3QvcBJLpRS0=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=sIq48O1T2xvvEGdFtK48JX6gFg7o8ShydsE2mjKta1nZyNho7YcIZBtRJECWC4E3g 5akOQrL9iIEp6fS96bxzerHn+z0/4u3p4eOFmxg2z0DQDka+v+hwKyU88sa7vT9p5g L4zY9xpezLMtsufXDz1VGS4qhZc++ROjJm86hA7g= Message-Id: <6.2.5.6.2.20110707072837.055b9700@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 07 Jul 2011 08:39:15 -0700 To: Mykyta Yevstifeyev From: SM In-Reply-To: <4E1594B2.9060409@gmail.com> References: <4E158722.60101@gmail.com> <6.2.5.6.2.20110707031904.04dcc150@resistor.net> <4E1594B2.9060409@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: [apps-discuss] Designating Apps Area related RFCs as Historic (was: Designating SUPDUP-related RFCs as Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 16:23:57 -0000 Hi Mykyta, At 04:12 07-07-2011, Mykyta Yevstifeyev wrote: >RFC 4450 was an effort of bulk reclassification, as mentioned >there. My proposal is to historicize 4 RFCs. It is caused by a >simple omission when moving RFC 734 to Historic. The following drafts are about a reclassification to Historic: draft-yevstifeyev-tsvwg-irtp-to-historic-01 draft-yevstifeyev-foobar-to-historic-00 Starting with the message at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02214.html , the topic of reclassification to Historic came up regularly since the beginning of the year. As you seem interested in doing the work, I suggest that: (i) You post an Internet-Draft with a list of (Apps Area) RFCs that you would like to see reclassified (ii) Ask the Apps Area ADs to present the I-D at a meeting so that anyone interested is aware of the reclassification work (iii) Follow up on the Apps-discuss mailing list (iv) Extended Last Call The other alternative is: (i) Post a message every few months about reclassifying some Apps Area specification (ii) Post an I-D (iii) Last Call (iv) Go back to step (i) I'll quote a point [1] that has been raised previously: "If there are others who feel that Mykyta's efforts are worth our time, by all means speak up and I'm happy to back down here." Regards, -sm 1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02224.html From msk@cloudmark.com Thu Jul 7 09:27:30 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856BE1F0C3F for ; Thu, 7 Jul 2011 09:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.749 X-Spam-Level: X-Spam-Status: No, score=-103.749 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 GA+zH4TsXWxr for ; Thu, 7 Jul 2011 09:27:30 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 091501F0C3E for ; Thu, 7 Jul 2011 09:27:30 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 7 Jul 2011 09:27:29 -0700 From: "Murray S. Kucherawy" To: SM , Mykyta Yevstifeyev Date: Thu, 7 Jul 2011 09:27:28 -0700 Thread-Topic: [apps-discuss] Designating Apps Area related RFCs as Historic (was: Designating SUPDUP-related RFCs as Historic Thread-Index: Acw8wkrqjqyewUdjT7il/oXpnP6vWQAAC/JQ Message-ID: References: <4E158722.60101@gmail.com> <6.2.5.6.2.20110707031904.04dcc150@resistor.net> <4E1594B2.9060409@gmail.com> <6.2.5.6.2.20110707072837.055b9700@resistor.net> In-Reply-To: <6.2.5.6.2.20110707072837.055b9700@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Designating Apps Area related RFCs as Historic (was: Designating SUPDUP-related RFCs as Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 16:27:30 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of SM > Sent: Thursday, July 07, 2011 8:39 AM > To: Mykyta Yevstifeyev > Cc: apps-discuss@ietf.org > Subject: [apps-discuss] Designating Apps Area related RFCs as Historic (w= as: Designating SUPDUP-related RFCs as Historic >=20 > I suggest that: >=20 > (i) You post an Internet-Draft with a list of (Apps Area) RFCs that y= ou > would like to see reclassified >=20 > (ii) Ask the Apps Area ADs to present the I-D at a meeting so that > anyone interested is aware of the reclassification work >=20 > (iii) Follow up on the Apps-discuss mailing list >=20 > (iv) Extended Last Call +1; please prepare an omnibus action to do all the cleanup you want to do r= ather than doing them all as tiny batches or one-offs. The time savings wi= ll be enormous. And a belated +1 to Paul's sentiment (which you cited): > 1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02224.htm= l -MSK From dpranke@google.com Thu Jul 7 14:12:30 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7314721F88DF for ; Thu, 7 Jul 2011 14:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 49kHovcBH2Sx for ; Thu, 7 Jul 2011 14:12:29 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2946321F88DC for ; Thu, 7 Jul 2011 14:12:29 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p67LCSZd021784 for ; Thu, 7 Jul 2011 14:12:28 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310073148; bh=gsm9gEZFaNH9Sq4w+rIbIi3Kojo=; h=MIME-Version:Sender:In-Reply-To:References:From:Date:Message-ID: Subject:To:Cc:Content-Type; b=VR5npjt5unKA11VVSeMLHAqheC1/iGb5qXIxBHG3l50PedACFcnv4xwF+QhWt22i+ lcgeQ7xNe/i3do5aF0bUA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:sender:in-reply-to:references:from: date:x-google-sender-auth:message-id:subject:to:cc:content-type:x-system-of-record; b=yo2AdHOnD4OE/FZDreZFExh7yi4eMxjCq0+gq1ctKtW8Lvm8mY6LN3oxbun1ZVD2C /XNOU2HpER3DtzN/2hsBQ== Received: from pwi15 (pwi15.prod.google.com [10.241.219.15]) by kpbe14.cbf.corp.google.com with ESMTP id p67LCQeV024424 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 7 Jul 2011 14:12:27 -0700 Received: by pwi15 with SMTP id 15so1265615pwi.39 for ; Thu, 07 Jul 2011 14:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=N07GygkfwkxuY97wy/PMi7SdVT9j+ZUHa6uwNapUB3I=; b=hegnWWY+4UK62ZO8gjuJsmR9jehfGKcnWoZzos3F9n2gqzfYVriK6R4s8dXgHsD3lU otJ5TWVYh/BSVG5PQ5yA== Received: by 10.142.172.11 with SMTP id u11mr457048wfe.113.1310073146285; Thu, 07 Jul 2011 14:12:26 -0700 (PDT) MIME-Version: 1.0 Sender: dpranke@google.com Received: by 10.142.193.2 with HTTP; Thu, 7 Jul 2011 14:12:06 -0700 (PDT) In-Reply-To: <4E152DFE.8080804@stpeter.im> References: <4E08CDCB.70902@stpeter.im> <4E1518F2.6000403@stpeter.im> <4E152DFE.8080804@stpeter.im> From: Dirk Pranke Date: Thu, 7 Jul 2011 14:12:06 -0700 X-Google-Sender-Auth: ewALxoUQFJVwpQaGFjhlEfwSkvw Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 21:12:30 -0000 On Wed, Jul 6, 2011 at 8:54 PM, Peter Saint-Andre wrote: > On 7/6/11 9:30 PM, Dirk Pranke wrote: >> On Wed, Jul 6, 2011 at 7:24 PM, Peter Saint-Andre wrote: >>> >>> Is there some kind of attack lurking here that we're not aware of? >>> Parameter phishing or somesuch? >>> >> >> No, that was not my concern. I am mostly trying to map your arguments >> onto the way we're currently evolving the HTML APIs, which follow a >> similar convention to X- (the vendor prefixes). > > Can you provide a pointer for this work? > Here are a few links culled from few minutes of searching my email and the internet. I wouldn't claim that they are the best sources, necessarily ... http://wiki.csswg.org/spec/vendor-prefixes - conventions for prefixing new features in CSS. This probably has the most real-world experience. The convention that the major browsers seem to be adopting is that proposed features are prefixed by a vendor-specific token until a specification reaches the stage of Candidate Recommendation (i.e., pretty frozen and the semantics should be pretty well agreed). http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#extensibility - similar, but less battle-tested examples for HTML attributes and DOM interfaces http://lists.w3.org/Archives/Public/www-style/2011Apr/0794.html - one particular mail thread in the CSS working group on this topic; there are many others http://blogs.msdn.com/b/ie/archive/2010/11/15/ie9-vendor-prefixes-and-developers.aspx - a statement from Microsoft on their attitude towards vendor prefixes; you can probably find similar statements from most of the other vendors. http://www.alistapart.com/articles/prefix-or-posthack/ - an independent article and discussion from Eric Meyer, a well-known name in the CSS and HTML community describing the virtues of this approach. I will note that the vendor prefix convention certainly has its detractors as well, but they don't seem to be winning at the moment. I am also well aware that the constraints on web pages are not directly comparable to the constraints on newtork-level protocols, so these arguments don't carry over 100%. -- Dirk From derhoermi@gmx.net Thu Jul 7 17:12:56 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5B921F8839 for ; Thu, 7 Jul 2011 17:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.769 X-Spam-Level: X-Spam-Status: No, score=-3.769 tagged_above=-999 required=5 tests=[AWL=-1.170, 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 DnqvDg4HWO8C for ; Thu, 7 Jul 2011 17:12:54 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 0F6F121F8837 for ; Thu, 7 Jul 2011 17:12:53 -0700 (PDT) Received: (qmail invoked by alias); 08 Jul 2011 00:12:52 -0000 Received: from dslb-094-223-185-199.pools.arcor-ip.net (EHLO HIVE) [94.223.185.199] by mail.gmx.net (mp003) with SMTP; 08 Jul 2011 02:12:52 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+w24dpM3ywGxdQyPYSe4D91NxgFIbh1Y6cK1s+cv Q8+9woWnqZXk+q From: Bjoern Hoehrmann To: Peter Saint-Andre Date: Fri, 08 Jul 2011 02:13:03 +0200 Message-ID: References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im> In-Reply-To: <4E13DC15.2080302@stpeter.im> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 00:12:56 -0000 * Peter Saint-Andre wrote: >http://www.ietf.org/id/draft-saintandre-xdash-01.txt The mechanism here allows to encumber public infrastructure that's been developed with attention to consensus and decent documentation with uni- lateral and usually poorly documented extensions. If the mechanism sur- faces too often, everybody should feel annoyed and desire changes so it stays in its confined place. You writing this draft tells me that it is actually working good. Overdoses are supposed to cause problems. With extension schemes there are things we want to have, things we want to avoid, there are social and other dynamics, and they vary among pro- tocols. I would expect an argument against `X-` to establish a context in this sense, and then show how `X-` is unfit, possibly by showing how some other mechanism is proved to be better. Your document does not do that, so I find it rather unconvincing. I would more generally think extensibility is hard and there is no one approach suitable for all situations. You recommend for instance that implementation-specific feature names should include reference to the implementation. This is done with Cascading Style Sheets, after vendors have been bitten sufficiently many times that not doing that would have social repercussions in addition to the technical ones. That leads to a situation where authors complain they have to specify `-opera-feature`, `-mozilla-feature`, and so on in order to use certain features, as the feature in principle is not implementation-specific, but experimental implementations of it are. That's largely a social de- fect of course, vendors put more effort into their implementations than they do with respect to the standardization process; with the argument above, the complaints are a good thing. But that's rather contentious, and people regularily ask for a "-wd-" or "-w3c-" or "-x-" prefix. For them, `-X-` would actually be an improvement (until their stuff breaks). There is a migration point where implementers move from these prefixes to the standard name. We largely call that making progress in standar- dization of the feature, I find it a bit odd that you cite this as the primary problem with the mechanism here. You actually argue both that changing the name is a problem, and that the standard name may imply a different behavior, which is also a problem. I would think the opposite, standardization allows for corrective actions, so the standardization is a good thing (you don't say it's bad, but you get close). With people adding to public infrastructure, I care about avoiding the issues that very typically arise when documentation is poor or absent and when those making the additions do not consult with interested but otherwise independent parties. Whether "X-" is good or bad does not play a large role in that; I do think a document detailing what we want to have with extensibility mechanisms, what we want to avoid, what problems individual approaches have, would be valuable; a document arguing contra "X-" without the larger discussion, not so much. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From evnikita2@gmail.com Thu Jul 7 20:18:40 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAF321F8802 for ; Thu, 7 Jul 2011 20:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.52 X-Spam-Level: X-Spam-Status: No, score=-3.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 YbpuTOXqjXEA for ; Thu, 7 Jul 2011 20:18:40 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id B5C2621F8801 for ; Thu, 7 Jul 2011 20:18:39 -0700 (PDT) Received: by fxe4 with SMTP id 4so2130592fxe.27 for ; Thu, 07 Jul 2011 20:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ls5tXHi6Ia0vHe2gO+Id62ESr1fuR/zGuKozLztsxsk=; b=aILvN5XhJJ58nqofVURBii3Bve31R0AOsrd3Bbz0G0IsBBdjZLgUfti8je5d7JCti8 rFoQQTIeKGiuEO2kTp3NQV71ao5ZDVF7nDrTMOl7+G7MLVBp3i2mvlZph4u4co/Lnb46 5mh11/H5OA83DNiT6P8rpFZRf2HmS+xaoT478= Received: by 10.223.6.198 with SMTP id a6mr2286832faa.128.1310095118844; Thu, 07 Jul 2011 20:18:38 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id 21sm6959172fay.21.2011.07.07.20.18.37 (version=SSLv3 cipher=OTHER); Thu, 07 Jul 2011 20:18:37 -0700 (PDT) Message-ID: <4E16773C.8010005@gmail.com> Date: Fri, 08 Jul 2011 06:19:24 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: SM References: <4E158722.60101@gmail.com> <6.2.5.6.2.20110707031904.04dcc150@resistor.net> <4E1594B2.9060409@gmail.com> <6.2.5.6.2.20110707072837.055b9700@resistor.net> In-Reply-To: <6.2.5.6.2.20110707072837.055b9700@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Designating Apps Area related RFCs as Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 03:18:40 -0000 07.07.2011 18:39, SM wrote: > Hi Mykyta, > At 04:12 07-07-2011, Mykyta Yevstifeyev wrote: >> RFC 4450 was an effort of bulk reclassification, as mentioned there. >> My proposal is to historicize 4 RFCs. It is caused by a simple >> omission when moving RFC 734 to Historic. While I understand that you encourage me to perform the bulk deprecation of Apps-related RFCs, I personally don't think I am technically knowledgeable enough to perform such work. Deciding on deprecating the RFC required its careful reading and deep technical understanding of its current use and/or its relationships with other RFCs. My expertise is mostly narrowly-skoped, and I am afraid such work will be impossible for me. When I face some RFC which is obviously obsolete, I propose its reclassifying to Historic. That's what with SUPDUP. This is an obvious omission when historicizing RFC 734. But I don't think I'll be able to propose something worthwhile if I undertake checking up and revising all published PSs. Thanks, Mykyta Yevstifeyev From nsb@guppylake.com Fri Jul 8 03:10:21 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACCF21F8993 for ; Fri, 8 Jul 2011 03:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, 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 oWHtIR-1pEgT for ; Fri, 8 Jul 2011 03:10:20 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id EC9F421F86D7 for ; Fri, 8 Jul 2011 03:10:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=guppylake.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=swviyCSDuD4vXvYh6vtXb4+3FTx/Ivw7zex/7yAlRv6/lZBtgWyv5E3fnvx01k8YbFg1wanTOKFT8uF52IJyL5gkQhjr7/ZjEy/fLjBMjlGjSsiGrKhcwqiJZi3RfxXf; Received: from [195.153.194.242] (helo=[192.168.55.182]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qf80l-0002ZV-8M; Fri, 08 Jul 2011 06:10:15 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: <20110706052247.16131.qmail@joyce.lan> Date: Fri, 8 Jul 2011 11:10:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110706052247.16131.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server1.netnutz.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - guppylake.com Cc: randy@qualcomm.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Call for adoption of draft-kucherawy-mta-malformed-00.txt as an APPSAWG document X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 10:10:21 -0000 On Jul 6, 2011, at 6:22 AM, John Levine wrote: >> It might be worthwhile to mention some of this immediately following=20= >> the quoted text. Also, it might be worthwhile to suggest that it's=20= >> good for MSAs fix or reject stuff that is broken (obviously this=20 >> draft can't mandate this). >=20 > This draft can't mandate it, but since MSAs are only supposed to > submit valid RFC 5322 (or 2822) messages, I'd think it would be OK to > point out that existing standards already mandate it. This is perhaps ok for MSAs, because the rejection happens close to the = sender, who will typically get feedback. It's a different story on the = receiving end. The existing standards mandate the *submission* of valid = messages, but say little about what to do when you receive invalid = messages. It has been our experience that when we reject invalid incoming messages = that are "nearly valid," our users tend to complain that their previous = provider/software let such messages through, and they conclude that our = system is broken for blocking mail that previously reached them. They = pressure us to "fix" our system with the threat that they'll seek = alternative providers. =20 You may not like it -- I certainly don't! -- but the market exerts = strong pressures on us to accept malformed messages if we can possibly = make sense of them. I, for one, would love to see a third alternative = besides "accept" and "reject" -- perhaps accepting the message for = delivery but also sending a warning to the sender. Of course, there are = lots of problems with that, too. -- Nathaniel From sm@resistor.net Fri Jul 8 03:58:34 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76EE21F8739 for ; Fri, 8 Jul 2011 03:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 KaJRcIp5shYQ for ; Fri, 8 Jul 2011 03:58:32 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38AEC21F87AF for ; Fri, 8 Jul 2011 03:58:31 -0700 (PDT) Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p68AwKjF026891; Fri, 8 Jul 2011 03:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1310122705; bh=D/BQfGxqUhoGN47vIl3Q15fz5aKjcP/X7fW9WS0PpCw=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=NwJ8hy1T4yZ5yZdfzej28IIoM97/mrLXYhW/uWhZNsdl8HRtpyW/jQtC/LXRENeYj 5unBfRblWNUXROhPCAeO8pwVU5abdVahtKMAPF48wJx4yJQRqR33JJhBWmMczlTULA Jtz0usk3W20lv4x15crP3r/2nZdHWZlo8HsMAT3k= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1310122705; bh=D/BQfGxqUhoGN47vIl3Q15fz5aKjcP/X7fW9WS0PpCw=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=Wee1tBo6XpF+tx8vVus4n1W6POxUHahiGK0Fz2f1csPD5Ud8wrV5u8LM/XIEX3bsG 9mvdsNOLxbyK4Bv9KlJuJZWGDe8WyV0muiuvJVTedcX6UqeMLaDBDDiGKpurSUELS5 wIaYcm3FiFiNMas5n3uZzyVvCZ4+sjz0vTJpNCNs= Message-Id: <6.2.5.6.2.20110708014010.04dc7618@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 08 Jul 2011 03:54:57 -0700 To: Mykyta Yevstifeyev From: SM In-Reply-To: <4E16773C.8010005@gmail.com> References: <4E158722.60101@gmail.com> <6.2.5.6.2.20110707031904.04dcc150@resistor.net> <4E1594B2.9060409@gmail.com> <6.2.5.6.2.20110707072837.055b9700@resistor.net> <4E16773C.8010005@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Designating Apps Area related RFCs as Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 10:58:34 -0000 Hi Mykyta, At 20:19 07-07-2011, Mykyta Yevstifeyev wrote: >While I understand that you encourage me to perform the bulk >deprecation of Apps-related RFCs, I personally don't think I am >technically knowledgeable enough to perform such work. Deciding on >deprecating the RFC required its careful reading and deep technical >understanding of its current use and/or its relationships with other >RFCs. My expertise is mostly narrowly-skoped, and I am afraid such >work will be impossible for me. I am saying that you could add the RFCs you would like to see reclassified to a list. Pick a long duration, not every few months, before posting the list and asking for feedback. I am not encouraging you to do that. I would discourage you from performing the bulk deprecation (going through all PS) of Apps-related RFCs as people will oppose that. As you mentioned, the work requires careful reading and deep technical understanding of the work. That entails getting the expertise of other participants. Based on the comments that have been posted to this list, it doesn't seem that it is viewed as a worthwhile effort. >When I face some RFC which is obviously obsolete, I propose its >reclassifying to Historic. That's what with SUPDUP. This is an >obvious omission when historicizing RFC 734. But I don't think I'll >be able to propose something worthwhile if I undertake checking up >and revising all published PSs. Yes. But it has been mentioned that it is book-keeping work. You don't want to have that on your track record. Regards, -sm From johnl@taugh.com Fri Jul 8 07:24:24 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7159B21F86E0 for ; Fri, 8 Jul 2011 07:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 EMP2dtTTvUx2 for ; Fri, 8 Jul 2011 07:24:24 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id BAD7321F86DD for ; Fri, 8 Jul 2011 07:24:23 -0700 (PDT) Received: (qmail 3788 invoked from network); 8 Jul 2011 14:24:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=ecb.4e171316.k1107; bh=+5w6Mn6mqnUw9P5N7ai9mDf6XxHnGSMpqDdvrOgB0M0=; b=r1GY6wKonIvMqdY/c1Gk/ehhEKHXJEqtcpK1vGANNPQm16fer0Pkk23bRSrC4+jE/Ut2El8nN8tX1R7qz8iuBU0og5GLspaZKxKRpmcL6Y2hVGqJfTUj3Vg6ylV4aGdPFC0AOE2KV7Q3kH4S228Wd3YZgiJmDYqw+2oJxjAp7c4= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=ecb.4e171316.k1107; bh=+5w6Mn6mqnUw9P5N7ai9mDf6XxHnGSMpqDdvrOgB0M0=; b=Rksa4smImoikPhIPWu9pm/71EhXKa09blN2FVDFv13xEb0sMzUNZ7/SzH3nMYVecdMhiOPbqpSZRz/ORf8in30q5vHlldb+MCjCnDR+S+WMviBbDmhbdFJSfPAv+PGyfX1ga1tgTYl4Nn0XlRgyaN0yn7ozcmEwt6vSu4ZUq8q0= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Jul 2011 14:24:00 -0000 Date: 8 Jul 2011 10:24:21 -0400 Message-ID: From: "John R Levine" To: "Nathaniel Borenstein" In-Reply-To: References: <20110706052247.16131.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Call for adoption of draft-kucherawy-mta-malformed-00.txt as an APPSAWG document X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 14:24:24 -0000 >> This draft can't mandate it, but since MSAs are only supposed to >> submit valid RFC 5322 (or 2822) messages, I'd think it would be OK to >> point out that existing standards already mandate it. > > This is perhaps ok for MSAs, because the rejection happens close to the sender, who will typically get feedback. It's a different story on the receiving end. The existing standards mandate the *submission* of valid messages, but say little about what to do when you receive invalid messages. Well, I did carefully say MSAs in that sentence. You're right, picky enforcement of RFC 5322 and its predecessors on mail from strangers tends to lose more sloppy legit mail than unwanted mail. I think it'd be worth noting that MSAs can and should be stricter about what they accept than relay MTAs are. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From msk@cloudmark.com Fri Jul 8 07:27:42 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D992E21F8902 for ; Fri, 8 Jul 2011 07:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.371 X-Spam-Level: X-Spam-Status: No, score=-103.371 tagged_above=-999 required=5 tests=[AWL=-0.772, BAYES_00=-2.599, 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 X0E-a-eA+SPD for ; Fri, 8 Jul 2011 07:27:42 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 718F921F88C0 for ; Fri, 8 Jul 2011 07:27:42 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 8 Jul 2011 07:27:42 -0700 From: "Murray S. Kucherawy" To: John R Levine , Nathaniel Borenstein Date: Fri, 8 Jul 2011 07:27:41 -0700 Thread-Topic: [apps-discuss] Call for adoption of draft-kucherawy-mta-malformed-00.txt as an APPSAWG document Thread-Index: Acw9esEOxKjd4aE5S9mLm+K1S1xqbAAAGPPQ Message-ID: References: <20110706052247.16131.qmail@joyce.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Call for adoption of draft-kucherawy-mta-malformed-00.txt as an APPSAWG document X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 14:27:43 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of John R Levine > Sent: Friday, July 08, 2011 7:24 AM > To: Nathaniel Borenstein > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Call for adoption of draft-kucherawy-mta-malf= ormed-00.txt as an APPSAWG document >=20 > Well, I did carefully say MSAs in that sentence. You're right, picky > enforcement of RFC 5322 and its predecessors on mail from strangers tends > to lose more sloppy legit mail than unwanted mail. >=20 > I think it'd be worth noting that MSAs can and should be stricter about > what they accept than relay MTAs are. I'd be fine with that. From jdfalk-lists@cybernothing.org Fri Jul 8 07:37:40 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C55E21F8ACF for ; Fri, 8 Jul 2011 07:37:40 -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=[AWL=0.000, 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 LUVQHL9rQRXJ for ; Fri, 8 Jul 2011 07:37:39 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id ADE1021F8ACB for ; Fri, 8 Jul 2011 07:37:39 -0700 (PDT) Received: from [192.168.11.36] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p68EbaJY030771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 8 Jul 2011 07:37:38 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: Date: Fri, 8 Jul 2011 07:37:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110706052247.16131.qmail@joyce.lan> To: "apps-discuss@ietf.org Discuss" X-Mailer: Apple Mail (2.1084) Subject: Re: [apps-discuss] Call for adoption of draft-kucherawy-mta-malformed-00.txt as an APPSAWG document X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 14:37:40 -0000 On Jul 8, 2011, at 7:27 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John R Levine >> Sent: Friday, July 08, 2011 7:24 AM >> To: Nathaniel Borenstein >> Cc: apps-discuss@ietf.org >> Subject: Re: [apps-discuss] Call for adoption of = draft-kucherawy-mta-malformed-00.txt as an APPSAWG document >>=20 >> Well, I did carefully say MSAs in that sentence. You're right, picky >> enforcement of RFC 5322 and its predecessors on mail from strangers = tends >> to lose more sloppy legit mail than unwanted mail. >>=20 >> I think it'd be worth noting that MSAs can and should be stricter = about >> what they accept than relay MTAs are. >=20 > I'd be fine with that. +1, so long as we explain that this is most often due to end user = preferences rather than technical concerns. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From johnl@taugh.com Fri Jul 8 07:41:33 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71EB421F8906 for ; Fri, 8 Jul 2011 07:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 N+VdB-BHoRoi for ; Fri, 8 Jul 2011 07:41:32 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A029C21F85D2 for ; Fri, 8 Jul 2011 07:41:32 -0700 (PDT) Received: (qmail 3903 invoked from network); 8 Jul 2011 14:41:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=f3e.4e17171b.k1107; bh=WJz81Bu+bdizc89z3V8cBaTgrvEu8fzyZOAcCQExjO4=; b=X/cxTyfSrELB2eOpJqYsl5LKpIH3WjsUjKcTybEAJWqCzM/vA0LcJ93VTIy0IwqH1hbZUcjw+8R3L51E8FbqdaRmZHQvlyfNBFDYPOmmZ62x1+FiM6ZwIKzVRJZers5i7KCVR20i55DFMjcv9V3DEFwZURDAF8otRyVuuUQgAbI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=f3e.4e17171b.k1107; bh=WJz81Bu+bdizc89z3V8cBaTgrvEu8fzyZOAcCQExjO4=; b=DIAW7uJfLjvko70S3zv98le7BqRK+JTanlDP+Zmul23T4lpeTnDZnAO22y5LATh0DBdl0cr7GL73lCSpDt3f3r5/pkA8RgjlbaUNNI0IzpCtQjjxEewrbG9uBUbrkqbN98GFeICSeeVSvv5EnAHI+FkL5NhEuItouwA+jhpvOUY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Jul 2011 14:41:09 -0000 Date: 8 Jul 2011 10:41:30 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20110706052247.16131.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Call for adoption of draft-kucherawy-mta-malformed-00.txt as an APPSAWG document X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 14:41:33 -0000 >> I think it'd be worth noting that MSAs can and should be stricter about >> what they accept than relay MTAs are. > > I'd be fine with that. If I may revise and extend my remarks, an MSA, unlike an MTA, can reasonably fix a lot of flaws that an MTA would have to either tolerate or reject, since it typically has metadata like a sender (whoever AUTHed) and a date (now). And as others have noted, the costs of rejection are typically a lot less, just bumping the message back to the author to fix. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From barryleiba.mailing.lists@gmail.com Fri Jul 8 09:59:15 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CEB21F8BEC for ; Fri, 8 Jul 2011 09:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.17 X-Spam-Level: X-Spam-Status: No, score=-103.17 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 vLHbh52bTA0A for ; Fri, 8 Jul 2011 09:59:15 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 140E621F8942 for ; Fri, 8 Jul 2011 09:59:15 -0700 (PDT) Received: by gyd5 with SMTP id 5so1011908gyd.31 for ; Fri, 08 Jul 2011 09:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=W1yx/OJEXFPrYAAJgqdPGuOLCJWP1GxZNc41+qqFelE=; b=mB9xHIn5fJZbBWrn0p8tcKgjAx58mVCJc0Aq9jgw/jzOkxAvhEyAp7udRbYPNkCcfT ro8XrsN9fbmHaerQW7tJFW+4Z0h2bKNgIRQ/gWHIqOm39JW6qhKcWw0eKwO3bcC+QLEu CWNME21SiNGWDlP8ylxkIQaTPeFh8TfU8VprM= MIME-Version: 1.0 Received: by 10.236.180.98 with SMTP id i62mr2674530yhm.403.1310144354559; Fri, 08 Jul 2011 09:59:14 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.41.12 with HTTP; Fri, 8 Jul 2011 09:59:14 -0700 (PDT) In-Reply-To: References: <20110706052247.16131.qmail@joyce.lan> Date: Fri, 8 Jul 2011 12:59:14 -0400 X-Google-Sender-Auth: Fr0zj5DsoH8WOZapVq8tbvjDYS4 Message-ID: From: Barry Leiba To: John R Levine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Call for adoption of draft-kucherawy-mta-malformed-00.txt as an APPSAWG document X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 16:59:15 -0000 > If I may revise and extend my remarks, an MSA, unlike an MTA, can reasona= bly > fix a lot of flaws that an MTA would have to either tolerate or reject, > since it typically has metadata like a sender (whoever AUTHed) and a date > (now). =A0And as others have noted, the costs of rejection are typically = a lot > less, just bumping the message back to the author to fix. Beware, though: you quickly run into the infamous BMP -- "Barry's Mother" Problem. The "author" isn't going to fix it. The MUA is. If the author is using a broken MUA, which generates the malformed message, bumping it back to the author amounts to telling the author to use a different (or newer version) MUA. If the author is my mother, that simply won't work. It also won't work in the case of, say, a company with 20,000 copies of PoodleMail, when the company just switched to you as their service provider. "Oh," they will say, "That was a mistake. I'd better switch back to my old service provider, because PoodleMail worked fine with them!" They certainly aren't likely to have all 20,000 of their employees switch to a different mail program in order to accommodate *you* (as they see it). Barry From johnl@taugh.com Fri Jul 8 10:19:34 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD82121F8C1D for ; Fri, 8 Jul 2011 10:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 wtC6ydoEZYFF for ; Fri, 8 Jul 2011 10:19:34 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 0968921F8C02 for ; Fri, 8 Jul 2011 10:19:33 -0700 (PDT) Received: (qmail 5177 invoked from network); 8 Jul 2011 17:19:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=1438.4e173c25.k1107; bh=f0nr9qXLNRjxi6dy3Y0P5lx0+4mto0QVLQYav6GespQ=; b=VgkB7GIRSQH8OsufqaPE00Mpx1umNfanHjH5KaxL3NgcpL1O90LFXTdLQ5stRw5fAPXxA/hMimnTcBLjHDVF0mRH7mWXLLlYlJ51aOAigqpk98AoMZEZ7Nyrw7uNTxDcIrUo/o+zIrlFM74y1lylWSd3krk511J+a72R8c+YqXo= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=1438.4e173c25.k1107; bh=f0nr9qXLNRjxi6dy3Y0P5lx0+4mto0QVLQYav6GespQ=; b=cWHl9srxRnabvkwNp2HblchVzVg3g+ftrm1RKwlpx6661BWkBuDu0LrHZWfaW0/OQUR9N3H3e1ajv+0D/1lT7wJoSi13/RAPKk3EZulDGxdUvqeQw6B64j8+jm8ZDrSYroxBcSDzqDH6v5VRx7LRPgINT/2w9BwXr5zX7PtDA38= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Jul 2011 17:19:10 -0000 Date: 8 Jul 2011 13:19:32 -0400 Message-ID: From: "John R Levine" To: "Barry Leiba" In-Reply-To: References: <20110706052247.16131.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Call for adoption of draft-kucherawy-mta-malformed-00.txt as an APPSAWG document X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 17:19:34 -0000 > Beware, though: you quickly run into the infamous BMP -- "Barry's > Mother" Problem. It certainly depends on the context, and the problem. If the problem is that the subject line is missing, Mom might fix it. If it's that the message-id has two @ signs, probably not. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From barryleiba.mailing.lists@gmail.com Fri Jul 8 10:24:36 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A8221F8C34 for ; Fri, 8 Jul 2011 10:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.15 X-Spam-Level: X-Spam-Status: No, score=-103.15 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 L-8mD8L7pWBb for ; Fri, 8 Jul 2011 10:24:35 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D745921F8C30 for ; Fri, 8 Jul 2011 10:24:34 -0700 (PDT) Received: by gyd5 with SMTP id 5so1022878gyd.31 for ; Fri, 08 Jul 2011 10:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=s+R5jnrttT7aJ9ORtSnRp/RbMDci/V4bl7iYb+1SSWE=; b=VpbVuIyys/TiLoSFcmRBO/+OlCd6i/b8aLLZzgrsviYFOOBO1OQxF7GkFGU2/2/zAR gN/nkuKO8SsT35XrkuAtAOfJHa03JbhBgjOJt+mdaGKh4De+Q/cdkz+O+T99qLwm/WnT Da8/oqMmPZWTBBG9Lt0JdURp/VvMs/X4NflhM= MIME-Version: 1.0 Received: by 10.236.75.136 with SMTP id z8mr2964467yhd.269.1310145874448; Fri, 08 Jul 2011 10:24:34 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.41.12 with HTTP; Fri, 8 Jul 2011 10:24:34 -0700 (PDT) In-Reply-To: References: <20110706052247.16131.qmail@joyce.lan> Date: Fri, 8 Jul 2011 13:24:34 -0400 X-Google-Sender-Auth: VOEPDYmxB0UsAz6VboVuFWYqd3o Message-ID: From: Barry Leiba To: John R Levine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Call for adoption of draft-kucherawy-mta-malformed-00.txt as an APPSAWG document X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 17:24:36 -0000 > It certainly depends on the context, and the problem. =A0If the problem i= s > that the subject line is missing, Mom might fix it. =A0If it's that the > message-id has two @ signs, probably not. Usually, the problem is that the body of the message contains a stupid joke that everyone has seen 17,000 times. Mom certainly won't fix that. In that case, I think the right work-around is to silently discard it. b From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Fri Jul 8 10:37:41 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6A821F8B88 for ; Fri, 8 Jul 2011 10:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1, 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 rKWaTbbVveym for ; Fri, 8 Jul 2011 10:37:40 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEFB21F85E5 for ; Fri, 8 Jul 2011 10:37:40 -0700 (PDT) Received: by pzk5 with SMTP id 5so2215536pzk.31 for ; Fri, 08 Jul 2011 10:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CsJfnjFtJ4/+hu2B5+xHu0wCV4YnpP3XiNCqMGGjZNw=; b=Clgp56uw/bW9LhgzGrxqVRFmRm888v8TpI5FN9J+E/Kxlw05OTPQO8qLWSVmDPnlOj Rmpu7OotlURFbq2U93a7yz8W3alv9b1jGQsn5wk8a90m5elDciqQHjd+9ZpDfAesIyHP xp2cTQ43S7C4fdmRLxtH8WakZy7I/JyylfApQ= Received: by 10.142.214.8 with SMTP id m8mr422814wfg.351.1310146658259; Fri, 08 Jul 2011 10:37:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.88.9 with HTTP; Fri, 8 Jul 2011 10:37:18 -0700 (PDT) In-Reply-To: <4E15C895.6020701@gmail.com> References: <4E15C895.6020701@gmail.com> From: Frank Ellermann Date: Fri, 8 Jul 2011 19:37:18 +0200 Message-ID: To: Mykyta Yevstifeyev Content-Type: text/plain; charset=ISO-8859-1 Cc: URI , Apps-discuss list Subject: Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 17:37:41 -0000 On 7 July 2011 16:54, Mykyta Yevstifeyev wrote: >> draft-yevstifeyev-ftp-uri-scheme-04.txt Hi, this draft is apparently very near to ready. Hopefully that is also the case for the normative reference to an FTP extension, otherwise a published FTP URI RFC would be better than a blocked I-D waiting for the extension. The "motd" example in RFC 1738 is very instructive, please adopt it in this draft. In the security considerations please note again and explicitly that user:pass (for user != anonymous) is not more state of the art. The anonymous:mail construct is also not more state of the art for privacy reasons, unless it is a mail address in TLD invalid or similar. In section 2.3 you apparently want IRIs, that would be RFC 3987 instead of 3986. Somewhere you should explain that FTP URIs have no query part. Any "?" or "#" meant to be used in the path has to be encoded. OTOH FTP URIs do have fragments, an unencoded "#" starts the fragment and is interpreted (or ignored) by clients depending on the document. Just repeating what RFC 3986 already says might be boring, but you could offer examples (encoded "?", encoded "#", fragment "#" - if you like RFC 5147 use it in a fragment example). JFTR, I can confirm that Mykta tried the arguably required good faith effort to post to the very obscure uri.arpa list. Maybe the IESG could subscribe an "archive account" to get a public archive of this obscure IANA list. -Frank From john-ietf@jck.com Fri Jul 8 10:46:39 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB1721F8C44 for ; Fri, 8 Jul 2011 10:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, 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 ALCY7bVKLDrx for ; Fri, 8 Jul 2011 10:46:38 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 7F60421F8BF3 for ; Fri, 8 Jul 2011 10:46:38 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QfF8L-000JHf-24; Fri, 08 Jul 2011 13:46:33 -0400 Date: Fri, 08 Jul 2011 13:46:32 -0400 From: John C Klensin To: Frank Ellermann , Mykyta Yevstifeyev Message-ID: In-Reply-To: References: <4E15C895.6020701@gmail.com> 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: URI , Apps-discuss list Subject: Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 17:46:39 -0000 --On Friday, July 08, 2011 19:37 +0200 Frank Ellermann wrote: > On 7 July 2011 16:54, Mykyta Yevstifeyev wrote: > >>> draft-yevstifeyev-ftp-uri-scheme-04.txt >... > The anonymous:mail construct is also not more state of the art > for privacy reasons, unless it is a mail address in TLD invalid > or similar. Disagree. If I'm an FTP repository provider, I can ask you to give up your email address in return for service if I want to. Whether I trust the address you give me is another matter, but that isn't a privacy issue. >... I've already expressed my concerns about a number of other components of this scheme. john From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Fri Jul 8 11:30:47 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3676521F8C17 for ; Fri, 8 Jul 2011 11:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.024 X-Spam-Level: X-Spam-Status: No, score=-103.024 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 9TJeHxt4lnL4 for ; Fri, 8 Jul 2011 11:30:46 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id AE3D921F8C11 for ; Fri, 8 Jul 2011 11:30:46 -0700 (PDT) Received: by pvh18 with SMTP id 18so1810108pvh.31 for ; Fri, 08 Jul 2011 11:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=qOhEpeKUF7K18uyGBGV4HLiEGs9taa5Er6SyDx8rVzM=; b=Za57j5zagVeztCNItf6ho0lWXK1eJUHkO9Ec5cWim4ZMFZjQLDexjo+98x4EPrY/C6 eBHatnf4OxaoQlzwaH35XRzRsszpMzF7A+UtDyOdOzGy1zH0Jlz65OarPSeHkzPfl6A3 8oLmejbf0Us0zKYUYf9MZG/KxFsXP1MgRodOc= Received: by 10.142.214.8 with SMTP id m8mr448516wfg.351.1310149846169; Fri, 08 Jul 2011 11:30:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.88.9 with HTTP; Fri, 8 Jul 2011 11:30:26 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20110708014010.04dc7618@resistor.net> References: <4E158722.60101@gmail.com> <6.2.5.6.2.20110707031904.04dcc150@resistor.net> <4E1594B2.9060409@gmail.com> <6.2.5.6.2.20110707072837.055b9700@resistor.net> <4E16773C.8010005@gmail.com> <6.2.5.6.2.20110708014010.04dc7618@resistor.net> From: Frank Ellermann Date: Fri, 8 Jul 2011 20:30:26 +0200 Message-ID: To: SM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Designating Apps Area related RFCs as Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 18:30:47 -0000 On 8 July 2011 12:54, SM wrote: >=A0But it has been mentioned that it is book-keeping work. >=A0You don't want to have that on your track record. IBTD, cleaning up the mess left by others is very important work, e.g., the FTP URI draft is AFAIK the last missing piece to finally get rid of RFC 1783 references in other documents. The "bulk deprecation" some years ago was brilliant, on the same level as "ABNF to STD". I certainly hope that the SMTP + message format authors will soon do the bookkeeping work to fix the minor errata in their documents and publish them as STDs, you know what the "current" STDs still are. I have not the faintest idea what "SUPDUP" is or was, and I won't check it -- the risk that I like it and/or waste time with it is too high. But if somebody has the time to clean up "SUPDUP" for hopefully sound reasons I would not wish to stand in the way claiming that work done by others wastes my time. -Frank From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Fri Jul 8 12:29:26 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2042F21F8CD8 for ; Fri, 8 Jul 2011 12:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.039 X-Spam-Level: X-Spam-Status: No, score=-103.039 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 EyWjoPKsMcav for ; Fri, 8 Jul 2011 12:29:25 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 953DC21F8CC5 for ; Fri, 8 Jul 2011 12:29:25 -0700 (PDT) Received: by pvh18 with SMTP id 18so1847352pvh.31 for ; Fri, 08 Jul 2011 12:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=jGs0qRDyh/ncTLBGgsmRqwAvFnXyq3iWCTKdL7mqX3c=; b=FWX/QBwL6ZugcHBus6k3t236AJuUpdA7PhFN7vG2o0z2DAlyZvkAGFH6acKaZt7PVM vfzAjMf3lkeB6MXBaG8QdaZ+kMDK/BVgDLA22Ct6nx5Zx/ConQPM8smHf3KhAe6Gkspy 6lbwKB0IGTIwZFLzzbIRN/Cg/i7DhbxadvqMA= Received: by 10.142.120.39 with SMTP id s39mr476267wfc.237.1310153365113; Fri, 08 Jul 2011 12:29:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.88.9 with HTTP; Fri, 8 Jul 2011 12:29:05 -0700 (PDT) In-Reply-To: References: <4E15C895.6020701@gmail.com> From: Frank Ellermann Date: Fri, 8 Jul 2011 21:29:05 +0200 Message-ID: To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: URI , Apps-discuss list Subject: Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 19:29:26 -0000 On 8 July 2011 19:46, John C Klensin wrote: >> The anonymous:mail construct is also not more state of the art >> for privacy reasons, unless it is a mail address in TLD invalid >> or similar. > Disagree. =A0If I'm an FTP repository provider, I can ask you to > give up your email address in return for service if I want to. > Whether I trust the address you give me is another matter, but > that isn't a privacy issue. Your server, your rules. Nevertheless user agents such as web browsers MUST NOT use valuable email accounts in anonymous FTP connections without explicit consent of the user. I don't think that address harvesting by spammers on anonymous FTP servers is a serious threat, but "anonymous" should be what the name says, as long as the user didn't explicitly set something else. If your FTP server does not accept anonymous:me@privacy.invalid it is fine, I'd know how to use another FTP client where I can add one of the addresses you know. But exactly these addresses should not be used in anonymous connections with arbitrary FTP servers, unless I explicitly confirmed it for a given server. -Frank From sm@resistor.net Fri Jul 8 12:31:21 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20DF21F8CF4 for ; Fri, 8 Jul 2011 12:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 D3e0Jot5DyT4 for ; Fri, 8 Jul 2011 12:31:16 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A8121F8CED for ; Fri, 8 Jul 2011 12:31:16 -0700 (PDT) Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p68JV1T1019077; Fri, 8 Jul 2011 12:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1310153470; bh=IjWV/Ck2NRLMl2sI77r/JtHsX7oHKOV7l5+SStHmuFc=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=sH3ARkcPSOQUYgaccXR92ZI8Cy2nXr91gvz1GlMAgxZqfrOdksqwhkeK71vj2E1rU UNGJwmlWjvrQvKNgjSafDfhvX/FFRfkrirL0pFmW/zRRx+KeOPtMzxLl4npeCDymbX 9XmHNr7PQJBgZFOrcfQwCDlb1+v5pDOQ2AgDrQ+0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1310153470; bh=IjWV/Ck2NRLMl2sI77r/JtHsX7oHKOV7l5+SStHmuFc=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=4mEA5t4n3oPcv4ry9j9elvdzFSaTXCet9Be3hLJhmytNKg62zqfylCXK4j/u+wBtZ aObupXoGqt3wvlirACr0iOpImSbG1HtQotuwkGVqfyduzJJDAhTomewqLl9TCkP01r xYY67rzQDxQbfeJB7b//h/Ofbt9jVqI5hZa+uGwk= Message-Id: <6.2.5.6.2.20110708105100.02fa9298@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 08 Jul 2011 10:57:06 -0700 To: Frank Ellermann From: SM In-Reply-To: References: <4E15C895.6020701@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: URI , Apps-discuss list Subject: Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 19:31:21 -0000 Hi Frank, At 10:37 08-07-2011, Frank Ellermann wrote: >The anonymous:mail construct is also not more state of the art >for privacy reasons, unless it is a mail address in TLD invalid >or similar. 'Anonymous FTP is a means by which archive sites allow general access to their archives of information. These sites create a special account called "anonymous".' 'Providing an e-mail address is a courtesy that allows archive site operators to get some idea of who is using their services.' That's from FYI 24. Regards, -sm From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Fri Jul 8 13:05:15 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527F021F8CE1 for ; Fri, 8 Jul 2011 13:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 7hL-s-T04PYE for ; Fri, 8 Jul 2011 13:05:14 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id D9FC421F8CDD for ; Fri, 8 Jul 2011 13:05:14 -0700 (PDT) Received: by pzk5 with SMTP id 5so2307734pzk.31 for ; Fri, 08 Jul 2011 13:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DsaJidRRBWuxwKRy5mjYr6ltsD5gvoOHtVGwdz70gA4=; b=LxRGJ6I2Z2C04IfyYEaZUnuO3+4Jqv/+qkz1Tvn+6GLpZN8hBocXV+gatgnkzpDGcE cI1FZVKfPjyNYQ+S3yAVPCgWAJDmZcbUg2kPG+OiQ2JBc4HmDWFTvBe8JBSkuju7sUkP P0vwUeh9AWSX1Y628jg7VsEVDHEtOfzOJN7BE= Received: by 10.142.120.39 with SMTP id s39mr492097wfc.237.1310155514484; Fri, 08 Jul 2011 13:05:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.88.9 with HTTP; Fri, 8 Jul 2011 13:04:54 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20110708105100.02fa9298@resistor.net> References: <4E15C895.6020701@gmail.com> <6.2.5.6.2.20110708105100.02fa9298@resistor.net> From: Frank Ellermann Date: Fri, 8 Jul 2011 22:04:54 +0200 Message-ID: To: SM Content-Type: text/plain; charset=ISO-8859-1 Cc: URI , Apps-discuss list Subject: Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 20:05:15 -0000 On 8 July 2011 19:57, SM wrote: >| Providing an e-mail address is a courtesy that allows archive >| site operators to get some idea of who is using their services. > That's from FYI 24. RFC 1635, vintage 1994. Apparently something that should go the way of the Dodo together with the long obsolete "netiquette RFC". In this millennium security and privacy and i18n are IMO not optional, it is not more the same internet as in 1994 (when I was still mostly using FidoNet and Videotex, or rarely NetNews). I vaguely recall that "privacy considerations" (in addition to the existing "IANA" / "i18n" / "security" considerations) were proposed, or was that a "privacy directorate"? I'd like to have "privacy considerations" in all future I-Ds - it could be merged with the "security considerations" or even omitted as beside the point depending on the final RFC, but an indication in I-Ds that the authors "considered privacy" like "security" or "i18n" or "IANA" would be good. If authors then decide that this is bureaucratic nonsense to be ignored for their purposes it worked as designed: At least they spent the milliseconds to think about it. -Frank From evnikita2@gmail.com Fri Jul 8 20:33:38 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A75911E8090 for ; Fri, 8 Jul 2011 20:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] 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 LGGT+FOZsXcF for ; Fri, 8 Jul 2011 20:33:37 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 48AC411E8089 for ; Fri, 8 Jul 2011 20:33:37 -0700 (PDT) Received: by fxe4 with SMTP id 4so3275229fxe.27 for ; Fri, 08 Jul 2011 20:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=TdRC1WngBCInOiE8lDJ780IXOKdg0TJSBVvFX5+HV8E=; b=gswLuunbURk4n9T+xYXYqrUXO19FbbnXpHdQ6sa1yWyIt5HCZ3bA89XEjS/ks+h3EY 5MHI1upjPDP0zhp+QFaLfUrqQhNa0kLBhWlByFqs+G4UvUb0u89hZl/x5L0Sf756EeF5 +cIoOZlKLbHHTabd91iLcuG8+Ubz38bC+je0Y= Received: by 10.223.16.131 with SMTP id o3mr4078286faa.53.1310182416313; Fri, 08 Jul 2011 20:33:36 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id b3sm7742357fao.44.2011.07.08.20.33.34 (version=SSLv3 cipher=OTHER); Fri, 08 Jul 2011 20:33:34 -0700 (PDT) Message-ID: <4E17CC3C.8080308@gmail.com> Date: Sat, 09 Jul 2011 06:34:20 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Frank Ellermann References: <4E15C895.6020701@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: URI , Apps-discuss list Subject: Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 03:33:38 -0000 08.07.2011 20:37, Frank Ellermann wrote: > On 7 July 2011 16:54, Mykyta Yevstifeyev wrote: > >>> draft-yevstifeyev-ftp-uri-scheme-04.txt Frank, Thanks for your comments. My responses are in-line. > Hi, this draft is apparently very near to ready. Hopefully that > is also the case for the normative reference to an FTP extension, > otherwise a published FTP URI RFC would be better than a blocked > I-D waiting for the extension. > > The "motd" example in RFC 1738 is very instructive, please adopt > it in this draft. I'll mention this. > In the security considerations please note > again and explicitly that user:pass (for user != anonymous) is > not more state of the art. I've mentioned this. The following new paragraph was added: Because of some concerns RFC 3986 did deprecate the use of "user:pass" format of , as stated in Section 2.1; it only applies to 'ftp' URIs because of historical reasons. Obviously, those URIs which contain the password "in the clear" should be kept and transmitted securely (for example, using Transport Layer Security (TLS) [RFC5246]). > The anonymous:mail construct is also not more state of the art > for privacy reasons, unless it is a mail address in TLD invalid > or similar. OK. The following paragraph was added: The "anonymous FTP" [RFC1635] has a number of security implications, too. When transmitting the email address as a password, if it is required by the server, there is a risk of email address harvesting by "middle-boxes" (man-in-the-middle attacks) and the ultimate server. As servers usually do not pay attention to such passwords, clients are encouraged to transmit email addresses with the domain names which are those described in RFC 2606 [RFC2606]. > In section 2.3 you apparently want IRIs, that would be RFC 3987 > instead of 3986. To address this comment, I've replaced the 1st paragraph with: The parts of 'ftp' URIs may contain characters from ASCII character set which are allowed in the corresponding parts. Those characters which are excluded from the allowed characters for a particular part SHALL be encoded within this part. A valid 'ftp' IRI [RFC3987] may contain characters from Universal Character Set (UCS) [UCS], first encoded using UTF-8 [RFC3629]. In order such characters may be present in 'ftp' URIs, a valid 'ftp' IRI should be mapped to the URI as described in Section 3.1 of RFC 3987. > Somewhere you should explain that FTP URIs have no query part. > Any "?" or "#" meant to be used in the path has to be encoded. I'll add a section on queries and fragments in the 'ftp' URIs. > OTOH FTP URIs do have fragments, an unencoded "#" starts the > fragment and is interpreted (or ignored) by clients depending > on the document. Just repeating what RFC 3986 already says > might be boring, but you could offer examples (encoded "?", > encoded "#", fragment "#" - if you like RFC 5147 use it in a fragment example). This will also be included in the draft. Mykyta Yevstifeyev > JFTR, I can confirm that Mykta tried the arguably required > good faith effort to post to the very obscure uri.arpa list. > Maybe the IESG could subscribe an "archive account" to get a > public archive of this obscure IANA list. > -Frank > From evnikita2@gmail.com Fri Jul 8 21:18:16 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9267D21F8A3C for ; Fri, 8 Jul 2011 21:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 bwx3o2B-Pb2b for ; Fri, 8 Jul 2011 21:18:16 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id D3F8721F8A36 for ; Fri, 8 Jul 2011 21:18:15 -0700 (PDT) Received: by fxe4 with SMTP id 4so3291202fxe.27 for ; Fri, 08 Jul 2011 21:18:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=hRYmHes/6hLq2RZp9iVyqboF9dnAwJBdMBU37fZhhQ4=; b=O6CNDcvg5c8SjgOw5NFzs0qNftRVLFV+brn+fHf23p92C9uOPZhDlDqCQTC6VcGUvl sKjOPfi9NXVJQ1HTHpkE3NKHM+BhjRnlX6O5P6SxaenbERwBlA51V4keRF3N/NmvoYEp pd6Kst8zRswXGa5zoupUXEnlY6N+bf1Ownubs= Received: by 10.223.7.150 with SMTP id d22mr4067744fad.17.1310185094997; Fri, 08 Jul 2011 21:18:14 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id q28sm173008fag.10.2011.07.08.21.18.13 (version=SSLv3 cipher=OTHER); Fri, 08 Jul 2011 21:18:14 -0700 (PDT) Message-ID: <4E17D6B3.7090909@gmail.com> Date: Sat, 09 Jul 2011 07:18:59 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4E158722.60101@gmail.com> <6.2.5.6.2.20110707031904.04dcc150@resistor.net> <4E1594B2.9060409@gmail.com> <6.2.5.6.2.20110707072837.055b9700@resistor.net> <4E16773C.8010005@gmail.com> <6.2.5.6.2.20110708014010.04dc7618@resistor.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Designating Apps Area related RFCs as Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 04:18:16 -0000 08.07.2011 21:30, Frank Ellermann wrote: > IBTD, cleaning up the mess left by others is very important > work, e.g., the FTP URI draft is AFAIK the last missing > piece to finally get rid of RFC 1783 references in other > documents. There is a 'file' URI scheme specified in RFC 1738, which isn't separately specified yet. From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Sat Jul 9 00:11:10 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4506321F8680 for ; Sat, 9 Jul 2011 00:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.99 X-Spam-Level: X-Spam-Status: No, score=-102.99 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 sho0Lz--LG-l for ; Sat, 9 Jul 2011 00:11:07 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id E156421F867E for ; Sat, 9 Jul 2011 00:11:03 -0700 (PDT) Received: by pzk5 with SMTP id 5so2617834pzk.31 for ; Sat, 09 Jul 2011 00:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Z7H3W3rHELiXRs0FoxRZ7Ui7XSuSVxeZJfR+fuCcCBo=; b=Ziu4hdOgkuNyR2UgyG4SqmWQV907Yp6VGRd5oszNEmkm9AsfxD+eFSyZXwHVSg8fVa f7UTAhWWVk9I/8QLiPpPMvPAuWBiDibYBUWwND8rnLkaoSJFmkCSHmQi04VBlm/sczhi m3wObeLcx/P/c9qykfLuVQrAHZmqodiJr5mug= Received: by 10.142.165.13 with SMTP id n13mr781201wfe.123.1310195463077; Sat, 09 Jul 2011 00:11:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.88.9 with HTTP; Sat, 9 Jul 2011 00:10:43 -0700 (PDT) In-Reply-To: <4E17D6B3.7090909@gmail.com> References: <4E158722.60101@gmail.com> <6.2.5.6.2.20110707031904.04dcc150@resistor.net> <4E1594B2.9060409@gmail.com> <6.2.5.6.2.20110707072837.055b9700@resistor.net> <4E16773C.8010005@gmail.com> <6.2.5.6.2.20110708014010.04dc7618@resistor.net> <4E17D6B3.7090909@gmail.com> From: Frank Ellermann Date: Sat, 9 Jul 2011 09:10:43 +0200 Message-ID: To: Mykyta Yevstifeyev Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Designating Apps Area related RFCs as Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 07:11:10 -0000 On 9 July 2011 06:18, Mykyta Yevstifeyev wrote: > There is a 'file' URI scheme specified in RFC 1738, which isn't > separately specified yet. ACK, noted on . From julian.reschke@gmx.de Sat Jul 9 02:00:54 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C0021F86AD for ; Sat, 9 Jul 2011 02:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.856 X-Spam-Level: X-Spam-Status: No, score=-104.856 tagged_above=-999 required=5 tests=[AWL=-2.257, BAYES_00=-2.599, 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 ufVnTEld8UqS for ; Sat, 9 Jul 2011 02:00:53 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id D460721F86AA for ; Sat, 9 Jul 2011 02:00:52 -0700 (PDT) Received: (qmail invoked by alias); 09 Jul 2011 09:00:50 -0000 Received: from p508FA64C.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.166.76] by mail.gmx.net (mp015) with SMTP; 09 Jul 2011 11:00:50 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/2mpV9CSH2pndSylH0uvV176u0VSQiOo2Y/3FVKI QnELehDFQ10Z4x Message-ID: <4E1818B9.8030804@gmx.de> Date: Sat, 09 Jul 2011 11:00:41 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Joachim Kupke References: <4E083D3F.6030200@gmx.de> <4E0D3EA5.7010803@gmail.com> <4E0DCFEF.20206@gmx.de> <4E0DEA77.3050007@gmail.com> <4E0E0E76.2080007@gmail.com> <4E0E995A.7060800@gmail.com> <4E0F1058.3050201@gmail.com> <1309613470.2807.17.camel@mackerel> <4E0F1F2F.8020504@gmail.com> <4E10208C.6090209@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "link-relations@ietf.org" , IETF Apps Discuss , Maile Ohye , Bjartur Thorlacius Subject: Re: [apps-discuss] [link-relations] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 09:00:54 -0000 On 2011-07-09 04:44, Joachim Kupke wrote: > ... >>> 5. OPEN. M. Yevstifeyev: >>>> >>>> Presence of the canonical link relation indicates to applications, >>> >>> such as search engines, that they MAY: >>> I wonder why it's MAY; in this case implementations (explicitly, those >>> apps which interpret Link: headers and corresponding construction in >>> HTML) will be free to ignore it. I think normative SHOULD should be OK >>> (sorry for pun). >>> --response by J. Reschke "I think this link relation is purely advisory, >>> so a better approach might be to replace "MAY" by "can"." > > Reading paragraph 5 of RFC 2119, I don't see anything wrong with > "MAY." How is "can" better? > ... See RFC 2119, Section 6: > 6. Guidance in the use of these Imperatives > > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for > interoperability. So my recommendation is NOT to use these kinds of keywords unless when needed as described above (but I realize that many people disagree with me...) > ... >> b) Future protocols might have other means to specify a link relation, btw. > > Is there terminology that reasonably unifies errors across protocols > (HTTP response code 4xx, GOPHER item type 3, FTP response code 5xx)? > ... I don't think so... Best regards, Julian From sm@resistor.net Sat Jul 9 02:22:47 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5F321F86C7 for ; Sat, 9 Jul 2011 02:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 SQKA5cSyc+2v for ; Sat, 9 Jul 2011 02:22:45 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68FB221F86C3 for ; Sat, 9 Jul 2011 02:22:45 -0700 (PDT) Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p699MYan010466; Sat, 9 Jul 2011 02:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1310203359; bh=pwQH+JcVKdhVvEwfem5l/a9yY7uPwisuYyLpx9ZYGyI=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=icYVIgm/tm3hzq1O+Bb9J+88bDXiP1OhaGRtyAKrI+2wXP0b99N7PNPDic2kVW1D4 hQ9mp/m3s3efE7TPuGk8slkmqJl9jOirL/JMesb+PCTEIlj1HPDJ3uAEVlJtcVFMRq yUeoE35VKxiVQRvn4ObHYZnUoR4CPb3LAt+Rnu7o= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1310203359; bh=pwQH+JcVKdhVvEwfem5l/a9yY7uPwisuYyLpx9ZYGyI=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=UO3HH2isyutd09+0r7qlYfucR74pdzbUdnUCyrAYUrdoZgg5SxD78ArbSnwUAFbLG 09IJibaxl93L6s2fzt0yzydxQvyE2/ULdO90fCzkB+wjTL2adntYgn4BDgt9hgpchv YSz71FVOSb+agqLJo4Rg9+rBYEzUO6wjRMOeQamg= Message-Id: <6.2.5.6.2.20110708223727.03006708@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 09 Jul 2011 02:15:31 -0700 To: Frank Ellermann From: SM In-Reply-To: References: <4E15C895.6020701@gmail.com> <6.2.5.6.2.20110708105100.02fa9298@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Apps-discuss list Subject: Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 09:22:48 -0000 Hi Frank, It's nice to see you back. At 13:04 08-07-2011, Frank Ellermann wrote: >I vaguely recall that "privacy considerations" (in addition to >the existing "IANA" / "i18n" / "security" considerations) were >proposed, or was that a "privacy directorate"? There is a privacy directorate. Regards, -sm From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Sat Jul 9 03:58:30 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFD821F8767 for ; Sat, 9 Jul 2011 03:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 1n-nchuVDnXN for ; Sat, 9 Jul 2011 03:58:29 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8739121F86BC for ; Sat, 9 Jul 2011 03:58:29 -0700 (PDT) Received: by pzk5 with SMTP id 5so2707108pzk.31 for ; Sat, 09 Jul 2011 03:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5xfsPQxzTkxuk9xzCDtHTKPXBVRChmETRJbYp4X5sew=; b=ovZENZFbrIzqmvGBw151aQUenAJfNy4O9WusFE/7hrD/YrJUSfYnLi208BLN6N7oSo UButH2ejPaoC9mERx+oMiTbnpG+lQ1TZLa/m/CRt8YzLVaEpk77Q2RLa1kVDPpA2jCaI sKaeZ+G/8h9ScsTaenEH/e70y17wLySI3+n1s= Received: by 10.142.135.13 with SMTP id i13mr827193wfd.408.1310209109149; Sat, 09 Jul 2011 03:58:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.88.9 with HTTP; Sat, 9 Jul 2011 03:58:09 -0700 (PDT) In-Reply-To: <4E17CC3C.8080308@gmail.com> References: <4E15C895.6020701@gmail.com> <4E17CC3C.8080308@gmail.com> From: Frank Ellermann Date: Sat, 9 Jul 2011 12:58:09 +0200 Message-ID: To: Mykyta Yevstifeyev Content-Type: text/plain; charset=ISO-8859-1 Cc: URI , Apps-discuss list Subject: Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 10:58:30 -0000 On 9 July 2011 05:34, Mykyta Yevstifeyev wrote: Skipping the i18n and security considerations until I see a new I-D one quick addition: >> an unencoded "#" starts the fragment and is interpreted >> (or ignored) by clients depending on the document. [...] > This will also be included in the draft. Thanks. My comment almost missed the point, the fragment depends on the document type, it does not depend on the URI scheme . In the times of "hashbang URIs" it might be necessary to be as clear as possible about this: Fragments are one of the subtle differences between STD 66 and its predecessors (incl. RFC 1738). For my privacy concerns pick something that does not upset John or SM -- I'm almost sure that we want the same thing from different points of view (server admin vs. FTP user, with "popular" browsers hiding or not offering any choice). From nsb@guppylake.com Sat Jul 9 05:37:39 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BD921F8752 for ; Sat, 9 Jul 2011 05:37:39 -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 YrNkn+5mOpYR for ; Sat, 9 Jul 2011 05:37:38 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id BBD2F21F8582 for ; Sat, 9 Jul 2011 05:37:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=guppylake.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=Ctf7S/H//j4Zca/n6G2inKHfjro/cUM2IJaNPLTReQ5VyDShIHX6VVjf0gzrYfmxChDFYzfNEo9DAgjpwXRSd7W0LlyLoFjuN/MeQ0o64LKQGRz9JWqSoX4KfVWC03dQ; Received: from host-39-196-68-109.spectrum1.uk.sharedband.net ([109.68.196.39] helo=[10.1.0.202]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1QfWmu-0005bx-6u; Sat, 09 Jul 2011 08:37:36 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: Date: Sat, 9 Jul 2011 13:37:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6D5DBBA9-06AC-42BC-8C1B-DA7C538D8C11@guppylake.com> References: <20110706052247.16131.qmail@joyce.lan> To: J.D. Falk X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server1.netnutz.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - guppylake.com Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Call for adoption of draft-kucherawy-mta-malformed-00.txt as an APPSAWG document X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 12:37:40 -0000 +1 On Jul 8, 2011, at 3:37 PM, J.D. Falk wrote: > On Jul 8, 2011, at 7:27 AM, Murray S. Kucherawy wrote: >=20 >>> -----Original Message----- >>> From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John R Levine >>> Sent: Friday, July 08, 2011 7:24 AM >>> To: Nathaniel Borenstein >>> Cc: apps-discuss@ietf.org >>> Subject: Re: [apps-discuss] Call for adoption of = draft-kucherawy-mta-malformed-00.txt as an APPSAWG document >>>=20 >>> Well, I did carefully say MSAs in that sentence. You're right, = picky >>> enforcement of RFC 5322 and its predecessors on mail from strangers = tends >>> to lose more sloppy legit mail than unwanted mail. >>>=20 >>> I think it'd be worth noting that MSAs can and should be stricter = about >>> what they accept than relay MTAs are. >>=20 >> I'd be fine with that. >=20 > +1, so long as we explain that this is most often due to end user = preferences rather than technical concerns. >=20 > -- > J.D. Falk > the leading purveyor of industry counter-rhetoric solutions >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From john@jck.com Sat Jul 9 07:12:01 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C710121F864F for ; Sat, 9 Jul 2011 07:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 OJFaYZ+xT1o8 for ; Sat, 9 Jul 2011 07:12:01 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 620C621F864B for ; Sat, 9 Jul 2011 07:12:00 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QfYGA-000BJs-4Z; Sat, 09 Jul 2011 10:11:54 -0400 Date: Sat, 09 Jul 2011 10:11:53 -0400 From: John C Klensin To: Peter Saint-Andre Message-ID: <60B61428BA7C86CBCF4D236D@PST.JCK.COM> In-Reply-To: <4E13DC15.2080302@stpeter.im> References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im> 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: apps-discuss@ietf.org Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 14:12:01 -0000 --On Tuesday, July 05, 2011 21:52 -0600 Peter Saint-Andre wrote: > On 6/27/11 12:36 PM, Peter Saint-Andre wrote: >... > Based on list feedback, I've submitted a further revision > (including much more specific recommendations for spec authors > and implementers): > > http://www.ietf.org/id/draft-saintandre-xdash-01.txt > > Keep those cards and letters coming! ;-) Peter, With the disclaimer that I'm still a fan of "x-" under very limited circumstances, a few observations that I think are complementary to some of those already made in this thread. First, while you can reasonably argue that most applications for "X-" that are either "experimental" or even "extension" are bogus and can be handled in other ways, there are private-use cases that, IMO, remain legitimate. Those private-use cases are, IMO, legitimate. They are very similar to RFC 1918 addresses: if something reaches you that contains an X- parameter, and the sender and receiver don't have a clear private agreement about what it means, then the correct action is to discard it or treat it is gibberish. Those private agreements may require some degree of authentication, but that is a separate issue. Note that "private use" really does imply "private": suggesting or requiring an IANA registration, no matter how lightweight, is out of line if only because it identifies the registrant. Your document implicitly assumes that the world consists of public stuff that is intended to be standardized, public stuff that is experimental and not likely to be standardized, and things for which embedding organization names in the parameter (see below) are satisfactory. I don't believe it. Second, remember that the motivation that took us down this path (see Dave's notes), and a motivation for IANA registration on parameters and the IANA itself, was to prevent two parties from accidentally using the same parameter value for different purposes and thereby causing serious interoperability problems. As Dave indirectly points out, we could have mandated arrangements like "X-BrandenburgInternetWorking.foo" or, more likely, "X-BrandenburgInternetWorking--foo". But we didn't and, unless the DNS is used (which has its own set of problems, especially in the world ICANN is creating) it would just require the creation of another registry that would have to be managed and that might be controversial among intellectual property folks ("X-BrandenburgInternetWorking.foo" and "X-Klensin.foo" are probably fine, but "X-JoesPizza.foo" is the introduction to a nightmare). To discourage a mandate for parameters to be registered with IANA is to encourage those interoperability problems. At a minimum, if you are going to make that recommendation, its implications need to be explicitly discussed in Security Considerations. I think it is a bad recommendation, even if some people will certainly ignore it. Making it a useful recommendation, however, requires that the IETF get completely over its self-proclaimed role as an arbiter of taste in identifier names and descriptions. Similarly, if "you better know who sent this to you and what they think it means" is a "special meaning to parameters with the 'X-' prefix", then I think you are looking for other problems. FWIW, "X-JoesPizza.foo" (or just "JoesPizza.foo") involves the imputation of a special meaning by parsing the parameter string and isolating the "relevant organization's name or primary domain name". Interestingly, from the way you write that recommendation, "foo.JoesPizza" is equally legitimate, after which it becomes really easy to fall back into the trap of conflicting names and interoperability problems. Recommendation: There is too much history and you can't get this right without causing even more interoperability issues than we have today. Private-use cases are legitimate and it is appropriate to provide some syntax that will identify them and shift the burden of figuring out what they mean to private agreements (and authentication of the parties to those agreements that is appropriate to the protocol in question). Encouraging more protocols to organize their parameters as trees, allow for vendor and personal trees, and define sufficient syntax and registries to actually make those trees work is actually a fine idea, but it may still not eliminate the need for private-use parameters. Finally, two asides/nits: (1) If you want to talk about "X-", your reference should be to RFC 5322 and its predecessors, not 5321, or you need more text. RFC 5321 (and its predecessors) use "X" (no hyphen") for private-use commands (and calls them that, not extensions or experiments, see Section 4.1.5). "X-" is used only in passing and in an example discussing gateways in Section 3.7.1. FWIW, my guess is that the leading "X" idea started with FTP and migrated, in "X-" form, to 822, but I don't remember (if I ever knew), so it is really just a guess. (2) While provisional URI schemes keep coming up as examples of how one might do these special extensions instead (as in your Section 2), I think a careful understanding of the history of "X-" to which people most object (and that RFC 1123 discusses in the context of experimental FTP commands, providing an example in its Section 4.1.3.1 that may be better than the two you cite and that is certainly earlier) suggests that the only thing "provisional" about a provisional registration is tolerance for rotten or missing documentation. Just like a command or parameter starting in "X-" or "X", once the name associated with a provisional registration is used and incorporated into protocols, it is "used up": if the definition is changed, or even clarified in a way that eliminates some interpretations, it is usually better to select a new parameter string than to pretend that the new definition applies retroactively to the old parameter name. Even if you disagree with that, I think it deserves some discussion in the document if you are going to recommend provisional registrations as an option. best, john From eran@hueniverse.com Sat Jul 9 08:17:31 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCA321F87BC for ; Sat, 9 Jul 2011 08:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 hnAjzX9sGf8t for ; Sat, 9 Jul 2011 08:17:30 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id AF1E521F87B4 for ; Sat, 9 Jul 2011 08:17:30 -0700 (PDT) Received: (qmail 28557 invoked from network); 9 Jul 2011 15:17:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 Jul 2011 15:17:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sat, 9 Jul 2011 08:17:25 -0700 From: Eran Hammer-Lahav To: "apps-discuss@ietf.org" Date: Sat, 9 Jul 2011 08:17:20 -0700 Thread-Topic: URI for OAuth SAML assertion grant type Thread-Index: Acw+SvrbRVrfupquSIaLgHqeJqAqkw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0143@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234501D4A0143P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: [apps-discuss] URI for OAuth SAML assertion grant type X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 15:17:31 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234501D4A0143P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The OAuth WG is looking for assistance from the application area community. OAuth 2.0 [1] defines a URI-namespaced method for defining extension grant = types[2]. The first specification to use this method needs to pick a URI id= entifier for using SAML assertions [3]. Options proposed: urn:oasis:names:tc:SAML:2.0:assertion urn:ietf:wg:oauth:2.0:grant_type:saml:2.0:bearer http://oauth.net/grant_type/saml/2.0/bearer Is there a BCP established for this? We need to pick a value quickly and mo= ve on. EHL [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-18 [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-18#section-8.3 [3] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04 --_000_90C41DD21FB7C64BB94121FBBC2E7234501D4A0143P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The OAuth WG is = looking for assistance from the application area community.

<= p class=3DMsoNormal> 

OAuth 2.0 [1]= defines a URI-namespaced method for defining extension grant types[2]. The= first specification to use this method needs to pick a URI identifier for = using SAML assertions [3]. Options proposed:

 

urn:oasis:names:tc:SAML:2.0:= assertion

urn:ietf:wg:oauth:2.0:grant_ty= pe:saml:2.0:bearer

http://oauth.net/grant_type/saml/2.0/bearer

 

Is t= here a BCP established for this? We need to pick a value quickly and move o= n.

 

EHL

 

[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-18

[2] http://tools.ietf.org/html/draft-ietf-oauth-v2-18#sect= ion-8.3

[3] http://tools.ietf.org/html/= draft-ietf-oauth-saml2-bearer-04

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234501D4A0143P3PW5EX1MB01E_-- From joe.kupke@gmail.com Fri Jul 8 19:44:06 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EF921F8AEE; Fri, 8 Jul 2011 19:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 gJQVpzImNaKR; Fri, 8 Jul 2011 19:44:05 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C10E21F8AEA; Fri, 8 Jul 2011 19:44:05 -0700 (PDT) Received: by pzk5 with SMTP id 5so2501192pzk.31 for ; Fri, 08 Jul 2011 19:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6+rwG4PkTHj3IKyJ2dJTgRpE027ZdlmJ7DWDySYQhAc=; b=j+FC7dj9VIhWj2bF6PZnPe7OMCrSh7DsxvxVsodtppMHIFSdn90LXVVGChSoClA72+ H9mPr5LidjCU4vzLjtfIfxaD5S/k7fY4wXGNTSLx3SzhO9lDFulX2IRot0k+ghayM2ML Mo3JyHNRItbQyXPuiDw9n0reet6IqwaGhhbvM= MIME-Version: 1.0 Received: by 10.68.49.234 with SMTP id x10mr3728454pbn.424.1310179444813; Fri, 08 Jul 2011 19:44:04 -0700 (PDT) Sender: joe.kupke@gmail.com Received: by 10.68.62.200 with HTTP; Fri, 8 Jul 2011 19:44:04 -0700 (PDT) In-Reply-To: <4E10208C.6090209@gmx.de> References: <4E083D3F.6030200@gmx.de> <4E0D3EA5.7010803@gmail.com> <4E0DCFEF.20206@gmx.de> <4E0DEA77.3050007@gmail.com> <4E0E0E76.2080007@gmail.com> <4E0E995A.7060800@gmail.com> <4E0F1058.3050201@gmail.com> <1309613470.2807.17.camel@mackerel> <4E0F1F2F.8020504@gmail.com> <4E10208C.6090209@gmx.de> Date: Fri, 8 Jul 2011 19:44:04 -0700 X-Google-Sender-Auth: aGVrj6uA2qd7kxyd_OPPV1IYUzU Message-ID: From: Joachim Kupke To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 09 Jul 2011 09:13:27 -0700 Cc: "link-relations@ietf.org" , IETF Apps Discuss , Maile Ohye , Bjartur Thorlacius Subject: Re: [apps-discuss] [link-relations] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 02:44:38 -0000 On Sun, Jul 3, 2011 at 12:55 AM, Julian Reschke wro= te: > On 2011-07-03 03:23, Maile Ohye wrote: >> 2. OPEN. F. Ellermann: [...] > I'm not sure I understand the response. Is there a use case where an auth= or > would legitimately add multiple instances of the link relation? It is quite conceivable that an author might want to designate multiple instances of the relation with different attributes, e.g.: It is recommended not to do that because it would foist additional complexity on implementations, and---without being presumptuous---it appears that encoding attributes such as media into the URI itself can do more harm than good. This recommendation might become less valid over time. For example, it has become rather common to encode the language (or country) of a resource into the URI when there would have been other means of their designation as well (such as, the Accept-Language HTTP header). >> 5. OPEN. M. Yevstifeyev: >>> >>> =C2=A0Presence of the canonical link relation indicates to applications= , >> >> such as search engines, that they MAY: >> I wonder why it's MAY; in this case implementations (explicitly, those >> apps which interpret Link: headers and corresponding construction in >> HTML) will be free to ignore it. =C2=A0I think normative SHOULD should b= e OK >> (sorry for pun). >> --response by J. Reschke "I think this link relation is purely advisory, >> so a better approach might be to replace "MAY" by "can"." Reading paragraph 5 of RFC 2119, I don't see anything wrong with "MAY." How is "can" better? It's indeed not a "SHOULD" since a typical implementation, say in a search engine, will want to go to some length to find evidence for misguided usage of the relationship and in the presence of such evidence decide to ignore it. The point of "MAY" is to make clear that in the absence of such evidence, the responsibility not to advertise an erroneous "canonical" relationship lies with the author of the context URI. >> 7. OPEN. M. Yevstifeyev: [...] > a) A non-HTML document at a non-HTTP(s) URI may not be able to specify th= e > link relation, but it could be the target of a link, relation, right? Correct. > b) Future protocols might have other means to specify a link relation, bt= w. Is there terminology that reasonably unifies errors across protocols (HTTP response code 4xx, GOPHER item type 3, FTP response code 5xx)? --Joachim From hannes.tschofenig@gmx.net Sat Jul 9 09:40:41 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A674321F87BC for ; Sat, 9 Jul 2011 09:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, 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 a3TFiRx3-Uuk for ; Sat, 9 Jul 2011 09:40:41 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 79D3621F8677 for ; Sat, 9 Jul 2011 09:40:40 -0700 (PDT) Received: (qmail invoked by alias); 09 Jul 2011 16:40:38 -0000 Received: from letku101.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.101] by mail.gmx.net (mp037) with SMTP; 09 Jul 2011 18:40:38 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18avVFnnUIalc/2aQfUF+E/um4qNTswoZ7ViNqgK1 IQSEBpKdxqfxGP Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0143@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sat, 9 Jul 2011 19:40:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0143@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: OAuth WG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] URI for OAuth SAML assertion grant type X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 16:40:41 -0000 Hi Eran,=20 http://oauth.net/grant_type/saml/2.0/bearer is definitely not a good = idea since a lookup would not return anything useful (most likely it = will just fail).=20 Whenever there is something that can be looked up, it will be looked up = .=20 I would create an IETF URN Sub-namespace, as documented in RFC 3553. An = example of such a sub-namespace is xml and described in RFC 3688.=20 So, one could define a new 'oauth' sub-namespace. This would then look = like urn:ietf:params:oauth. Then, OAuth relevant parameters would be = established underneath it.=20 To get this done three things are needed:=20 1) Text that requests the oauth sub-namespace text This text has to go into draft-ietf-oauth-v2. 2) Text that defines how values are added to this new registry This text has to go into draft-ietf-oauth-v2. 3) Text that registers already defined values.=20 This text would go into draft-ietf-oauth-saml2-bearer following the = template created with (2).=20 Regarding (1), example text could look like: --------- IETF URN Sub-namespace Registration urn:ietf:params:oauth Per [RFC3553], IANA is requested to establish the following registry. = New entries to the registry are Specification Required. Registry name: urn:ietf:params:oauth Specification: Section X of this document contains the registry = specification. Repository: To be assigned according to the guidelines found above. Index value: The class name --------- Regarding (2), example text could look like:=20 =20 --------- Section X: Registration Template for Sub-Namspace Registration of = urn:ietf:params:oauth =20 If the registrant wishes to have a URI assigned, then a URN of the form urn:ietf:params:oauth:: will be assigned where is the category of the parameters = being registered. is a unique id generated by the IANA based on any means the IANA deems necessary to maintain uniqueness and persistence. NOTE: in order for a URN of this type to be assigned, the item being registered MUST be documented in a RFC. The RFC 3553 [RFC3553] URN registration template is found in the IANA consideration section of this document. =20 The registration procedure for new entries to the requires a request = in the form of the following template: URN: The token URI that identifies the registerd component. If the registrant is requesting that the IANA assign a URI then this field should be specified as "please assign". =20 Common Name:=20 The name by which the functionality being registered is generally = referred. =20 Registrant Contact: The individual/organization that is the registration contact for the component being registered. Ideally, this will be the name and pertinent physical and network contact information. In the case of IETF developed standards, the Registrant will be the IESG. Description: Information about the registered functionality. =20 =20 --------- Regarding (3), example text could look like:=20 =20 --------- Sub-Namspace Registration of = urn:ietf:params:oauth:grant-type:saml2-bearer This is a request to IANA to please register the value = grant-type:saml2-bearer in the registry urn:ietf:params:oauth = established in [draft-ietf-oauth-v2].=20 URN: urn:ietf:params:oauth:grant-type:saml2-bearer Common Name: SAML 2.0 Bearer Assertion Grant Type Profile for OAuth = 2.0 =20 Registrant Contact: IESG =20 Description: [[this document]] =20 --------- Other grant types would then go in = urn:ietf:params:oauth:grant-type:saml2-holder-of-the-key Other OAuth related parameters then go under = urn:ietf:params:oauth:foobar Ciao Hannes On Jul 9, 2011, at 6:17 PM, Eran Hammer-Lahav wrote: > The OAuth WG is looking for assistance from the application area = community. > =20 > OAuth 2.0 [1] defines a URI-namespaced method for defining extension = grant types[2]. The first specification to use this method needs to pick = a URI identifier for using SAML assertions [3]. Options proposed: > =20 > urn:oasis:names:tc:SAML:2.0:assertion > urn:ietf:wg:oauth:2.0:grant_type:saml:2.0:bearer > http://oauth.net/grant_type/saml/2.0/bearer > =20 > Is there a BCP established for this? We need to pick a value quickly = and move on. > =20 > EHL > =20 > [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-18 > [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-18#section-8.3 > [3] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Sat Jul 9 10:04:12 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A6921F87B4 for ; Sat, 9 Jul 2011 10:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, 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 yk7WFeQKMrR3 for ; Sat, 9 Jul 2011 10:04:12 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9F0CD21F868D for ; Sat, 9 Jul 2011 10:04:11 -0700 (PDT) Received: (qmail invoked by alias); 09 Jul 2011 17:04:10 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp036) with SMTP; 09 Jul 2011 19:04:10 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+fKuUD8RifSmUm6rNaJ2rNfJuaKyabkkVW0iDjyC G2ZaMcUuoTRYz1 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Sat, 9 Jul 2011 20:04:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0143@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" , OAuth WG Subject: Re: [apps-discuss] [OAUTH-WG] URI for OAuth SAML assertion grant type X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 17:04:12 -0000 On Jul 9, 2011, at 7:40 PM, Hannes Tschofenig wrote: > Other grant types would then go in = urn:ietf:params:oauth:grant-type:saml2-holder-of-the-key This sentence from my earlier mail could be misunderstood. To pick = Mike's example for the JWT assertion profile we would then register = something like:=20 urn:ietf:params:oauth:grant-type:jwt1.0-bearer From sm@resistor.net Sat Jul 9 10:10:58 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8C721F877B; Sat, 9 Jul 2011 10:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 mkj1BR9ygdib; Sat, 9 Jul 2011 10:10:56 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B74121F8888; Sat, 9 Jul 2011 10:10:55 -0700 (PDT) Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p69HAgxm012813; Sat, 9 Jul 2011 10:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1310231450; bh=Wsl/ozWYRdNRZgVNAHoFvdsnYwXjHvUlC/LFF1lwLdg=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=Wh/TOWWo7zyVHPEcYZmyJPpPX8Bk0GEbgxqmPSe62yQrOw8d2nj9mipgyVWc7k5Zv /R1CI8MPQo28cXdvmIvlgH+CJJ5LgCYGFCnsl5dwwxHPQrlEtIaLJMphM5z52tgqeS RzPNRepw9PITaSP40g7Fye+EGwRpUBwIlGQmEFuc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1310231450; bh=Wsl/ozWYRdNRZgVNAHoFvdsnYwXjHvUlC/LFF1lwLdg=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=PcLOYYdTsd7+yx62SxbW34ebfFQBqaRCjFMe/xKS8fp0WbLttBqsq/j0br6G9IIxB dguRWLKAmrgGyME48+uB1VxpDn2W9cj9AgmdGZ4Ufv9FSJ7pUIEc1oWwa9QnE04wgA mHHe01/LZVPQoxuaaV4S34v6M4+FjeMQ4Z1dycUM= Message-Id: <6.2.5.6.2.20110709074757.04899d20@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 09 Jul 2011 10:09:09 -0700 To: Frank Ellermann From: SM In-Reply-To: References: <4E15C895.6020701@gmail.com> <6.2.5.6.2.20110708105100.02fa9298@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf-privacy@ietf.org, Apps-discuss list Subject: [apps-discuss] Privacy Considerations for Internet Protocols (was: Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 17:10:58 -0000 Hi Frank, I added a Cc to the ietf-privacy mailing list. I suggest using that mailing list for further discussion. At 13:04 08-07-2011, Frank Ellermann wrote: >I'd like to have "privacy considerations" in all future I-Ds - >it could be merged with the "security considerations" or even >omitted as beside the point depending on the final RFC, but an >indication in I-Ds that the authors "considered privacy" like >"security" or "i18n" or "IANA" would be good. If authors then >decide that this is bureaucratic nonsense to be ignored for >their purposes it worked as designed: At least they spent the >milliseconds to think about it. draft-morris-policy-cons-00 discusses about Policy Considerations for Internet Protocols. There is another I-D, draft-morris-privacy-considerations-03, that discusses about Privacy Considerations for Internet Protocols. The term "Network Access Identifier" is used in RFC 4282; it is the user identity submitted by the client during network access authentication. A common identifier which is picked for user authentication is an email address as it offers uniqueness and it is easy for the user to remember. That has privacy implications. Disallowing "anonymous" (FTP) as the user name and the email address as the password does not solve the problem as credentials are required to access a protected resource. Reality check, some users will: (i) provide their email address (ii) use guest@example.com (iii) pick a random email address which does not belong to them The is ongoing work in the OAUTH WG on access to a protected resource using an intermediary which provides the access token. That's one way to deal with the question of providing credentials to an unknown party. draft-mayer-do-not-track-00 discusses about a HTTP header-based mechanism for users to express their preferences about tracking. draft-vandergaast-edns-client-ip defines an EDNS0 extension to carry relevant (client) network range information. If you do not provide information within the layer, the information will be gleaned from other layers. There are times when user consent is an explicit decision about the information to provide (see reality check) and there are times when it is an implicit decision; e.g. the terms of service that the user did not read. If you would like to have "privacy considerations" in all future I-Ds, the above could get you started. Regards, -sm From evnikita2@gmail.com Sat Jul 9 11:02:19 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B010921F85DB for ; Sat, 9 Jul 2011 11:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 hrToJRRjmjNB for ; Sat, 9 Jul 2011 11:02:19 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id EE68521F85DA for ; Sat, 9 Jul 2011 11:02:18 -0700 (PDT) Received: by fxe4 with SMTP id 4so3684170fxe.27 for ; Sat, 09 Jul 2011 11:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zs3I02uGgRhkcO3xWm5Af4V6IwQlc22iz9MYfbRgJgY=; b=jUmD5n24xbHy0KcxOhQnXq9F/kNhtcwt7v9aj/QMFAKg6S7zgGqhRy8JCLjy7GeOgk aTQO5HsSL19beNg/7kyBuUAHXrloq57Xqf1jOpKb01/2p0MvDbFgjJcvOEX4kKfNxwvP FBiyWJjtvWKXb/EOY3IrPqjZ2ME8RBgA8I16g= Received: by 10.223.76.16 with SMTP id a16mr4875615fak.47.1310234537967; Sat, 09 Jul 2011 11:02:17 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id b13sm8153382fab.36.2011.07.09.11.02.16 (version=SSLv3 cipher=OTHER); Sat, 09 Jul 2011 11:02:17 -0700 (PDT) Message-ID: <4E1897D7.9030300@gmail.com> Date: Sat, 09 Jul 2011 21:03:03 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Frank Ellermann References: <4E15C895.6020701@gmail.com> <4E17CC3C.8080308@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: URI , Apps-discuss list Subject: Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 18:02:19 -0000 09.07.2011 13:58, Frank Ellermann wrote: > On 9 July 2011 05:34, Mykyta Yevstifeyev wrote: > > Skipping the i18n and security considerations until I see > a new I-D one quick addition: > >>> an unencoded "#" starts the fragment and is interpreted >>> (or ignored) by clients depending on the document. > [...] >> This will also be included in the draft. > Thanks. My comment almost missed the point, the fragment > depends on the document type, it does not depend on > the URI scheme. In the times of "hashbang URIs" it > might be necessary to be as clear as possible about this: > > Fragments are one of the subtle differences between STD 66 > and its predecessors (incl. RFC 1738). OK, this will be clarified. > > For my privacy concerns pick something that does not upset > John or SM -- I'm almost sure that we want the same thing > from different points of view (server admin vs. FTP user, > with "popular" browsers hiding or not offering any choice). I think I'll find corresponding approach to address these concerns in -05. Thanks, Mykyta Yevstifeyev > From internet-drafts@ietf.org Sat Jul 9 12:17:29 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD7921F89D1; Sat, 9 Jul 2011 12:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, 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 y+fihraq5LUx; Sat, 9 Jul 2011 12:17:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52AA21F891F; Sat, 9 Jul 2011 12:17:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110709191728.24369.57888.idtracker@ietfa.amsl.com> Date: Sat, 09 Jul 2011 12:17:28 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 19:17:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Terminology Used in Internationalization in the IETF Author(s) : Paul Hoffman John C Klensin Filename : draft-ietf-appsawg-rfc3536bis-06.txt Pages : 46 Date : 2011-07-09 This document provides a list of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3536bis-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3536bis-06.txt From evnikita2@gmail.com Sun Jul 10 03:20:22 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683F721F86FC for ; Sun, 10 Jul 2011 03:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] 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 0ftbMn1sXP51 for ; Sun, 10 Jul 2011 03:20:21 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4C15021F86E0 for ; Sun, 10 Jul 2011 03:20:21 -0700 (PDT) Received: by fxe4 with SMTP id 4so4036927fxe.27 for ; Sun, 10 Jul 2011 03:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=GOe7XFFJHEe5WKOYots0KE6SmxAvWV8hjhTFXL1kLsY=; b=b7pqCuPANspjayEmSN4Y3XMXiQimAjVgnJI0xmiXhfG3xRck005JtANzDQfvQBk32j XASth3uaOhXEOyGrurVCp27MEgn7/8elvSJKAP86PACJVM79CsTOiFxfitghyIo6GRpX DRvsB9OFWJZCPCajQmjnEZQDYjF725QSRXlQM= Received: by 10.223.40.198 with SMTP id l6mr5785705fae.14.1310293220351; Sun, 10 Jul 2011 03:20:20 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id q14sm1999143faa.27.2011.07.10.03.20.18 (version=SSLv3 cipher=OTHER); Sun, 10 Jul 2011 03:20:19 -0700 (PDT) Message-ID: <4E197D10.1070202@gmail.com> Date: Sun, 10 Jul 2011 13:21:04 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Apps-discuss list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: michael@refactored-networks.com Subject: [apps-discuss] RFC 3405 needs revising X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 10:20:22 -0000 Hello, RFC 3405 is a fifth of the document series defined Dynamic Delegation Discovery System (DDDS), produced by IETF URN WG in 2002. The entire series is specified in RFC 3401; RFC 3405 specified the rules for assignments in IANA-maintained uri.arpa. and urn.arpa. zones, used with DDDS Application for resolving URIs (including URNs). However, I've identified a number of issues with current procedures which make any registration almost impossible. The two main of them follow. First, Section 3.1.1 of RFC 3405 sets that only URI schemes registered in IETF Tree may be approved in uri.arpa. Registration trees for URI schemes, introduced by RFC 2717, were eliminated by RFC 4395. The second problem is probably with Section 5, which is the procedures description itself. The most notable is the register@uri.arpa/urn.arpa lists, which, as Frank already mentioned are quite obscure. Here are some observations with respect to these lists. RFC 3405 implied these lists' archives will serve as persistent records for registrations; there are actually only 7 messages in the uri.arpa archive and 9 - in urn.arpa. I tried to ask IANA where are all assignments for uri.arpa/urn.arpa domains listed; the response was received that RFC 3405 didn't request to have a place where they are listed. The only information I managed to get is 3 registrations for 'ftp', 'http' and 'mailto' schemes (see http://www.iana.org/protocols/archives/register-uri/) and even more obscure assignment to 'urn.arpa' (http://www.iana.org/protocols/archives/register-urn - messages here are actually absent). With respect to the last, it is the "pin" URN NID (RFC 3043) entered in urn.arpa; I didn't get an access to the messages registering it. After trying to manually query pin.urn.arpa for NAPTR RRs I was pointed to pin.verisignlabs.com, which doesn't seem to have any NAPTR records. No other messages were found in these archives, which are indeed the only place where I might have found any information about uri.arpa and urn.arpa assignments; so this attempt returned FAIL :-). Such approach actually doesn't fit in anything described in RFC 5226; I suppose it was intended to be 'expert review'. This may be deduced from Section 3 of RFC 3405. Actually it implies "(1) posting to list->(2) (a) no objections: success/(b) objections: resolve issues and return to (1)". Correspondingly, new assignments are not formally approved by some party (whereas it's interesting that changes of assignments require approval of 'Authority' (Section 6.2)). There also are a number of minor and editorial omissions in the RFC, a part of which were reported as errata (http://www.rfc-editor.org/errata_search.php?rfc=3405). One is my erratum, which was rejected per corresponding IESG statement, as "community consensus required for substantial changes". This, at all, caused me to write this message. Taking everything into account, I propose to undertake an effort to revise the RFC 3405 in order to align it with the reality and current situation. I'm glad to hear what others think. Mykyta Yevstifeyev From bcampbell@pingidentity.com Sat Jul 9 12:28:38 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D462E21F89BC; Sat, 9 Jul 2011 12:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.941 X-Spam-Level: X-Spam-Status: No, score=-5.941 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 UwfTwQiCbyv2; Sat, 9 Jul 2011 12:28:37 -0700 (PDT) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFF421F899D; Sat, 9 Jul 2011 12:28:37 -0700 (PDT) Received: from mail-qy0-f180.google.com ([209.85.216.180]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKThir5AEPuZTpXMzU+Ezv6gP48tXhWs5V@postini.com; Sat, 09 Jul 2011 12:28:37 PDT Received: by mail-qy0-f180.google.com with SMTP id 30so2374839qyk.18 for ; Sat, 09 Jul 2011 12:28:36 -0700 (PDT) Received: by 10.224.198.201 with SMTP id ep9mr2414806qab.126.1310239716231; Sat, 09 Jul 2011 12:28:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.201 with HTTP; Sat, 9 Jul 2011 12:28:06 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0143@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Sat, 9 Jul 2011 13:28:06 -0600 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 10 Jul 2011 13:07:48 -0700 Cc: "apps-discuss@ietf.org" , OAuth WG Subject: Re: [apps-discuss] [OAUTH-WG] URI for OAuth SAML assertion grant type X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 19:28:39 -0000 Thank you for taking the initiate to post this, Eran. And thank you, Hannes, for the detailed and actionable reply. If Eran is willing/able to do #1 & #2, I'd be more than happy to do #3. On Sat, Jul 9, 2011 at 10:40 AM, Hannes Tschofenig wrote: > Hi Eran, > > http://oauth.net/grant_type/saml/2.0/bearer is definitely not a good idea= since a lookup would not return anything useful (most likely it will just = fail). > Whenever there is something that can be looked up, it will be looked up . > > I would create an IETF URN Sub-namespace, as documented in RFC 3553. An e= xample of such a sub-namespace is xml and described in RFC 3688. > So, one could define a new 'oauth' sub-namespace. This would then look li= ke urn:ietf:params:oauth. Then, OAuth relevant parameters would be establis= hed underneath it. > > To get this done three things are needed: > > 1) Text that requests the oauth sub-namespace text > This text has to go into draft-ietf-oauth-v2. > > 2) Text that defines how values are added to this new registry > This text has to go into draft-ietf-oauth-v2. > > 3) Text that registers already defined values. > This text would go into draft-ietf-oauth-saml2-bearer following the templ= ate created with (2). > > Regarding (1), example text could look like: > > --------- > > IETF URN Sub-namespace Registration urn:ietf:params:oauth > > =A0 Per [RFC3553], IANA is requested to establish the following registry.= =A0New entries > =A0 to the registry are Specification Required. > > =A0 Registry name: urn:ietf:params:oauth > > =A0 Specification: =A0Section X of this document contains the registry sp= ecification. > > =A0 Repository: To be assigned according to the guidelines found above. > > =A0 Index value: The class name > > --------- > > Regarding (2), example text could look like: > > --------- > > Section X: Registration Template for Sub-Namspace Registration of urn:iet= f:params:oauth > > =A0 If the registrant wishes to > =A0 have a URI assigned, then a URN of the form > > =A0 =A0 =A0urn:ietf:params:oauth:: > > =A0 will be assigned where is the category of the parameters bein= g registered. =A0 is a unique id generated by the IANA > =A0 based on any means the IANA deems necessary to maintain uniqueness > =A0 and persistence. =A0NOTE: in order for a URN of this type to be > =A0 assigned, the item being registered MUST be documented > =A0 in a RFC. =A0The RFC 3553 [RFC3553] URN registration template is foun= d > =A0 in the IANA consideration section of this document. > > =A0 The registration procedure for new entries to the requires a request = in the form of the following template: > > =A0 URN: > =A0 =A0 =A0The token URI that identifies the registerd component. If > =A0 =A0 =A0the registrant is requesting that the IANA assign a URI then t= his > =A0 =A0 =A0field should be specified as "please assign". > > =A0 Common Name: > =A0 =A0 =A0The name by which the functionality being registered is genera= lly referred. > > =A0 Registrant Contact: > =A0 =A0 =A0The individual/organization that is the registration contact f= or > =A0 =A0 =A0the component being registered. =A0Ideally, this will be the n= ame > =A0 =A0 =A0and pertinent physical and network contact information. =A0In = the > =A0 =A0 =A0case of IETF developed standards, the Registrant will be the I= ESG. > > =A0 Description: > =A0 =A0 =A0Information about the registered functionality. > > > --------- > > Regarding (3), example text could look like: > > --------- > > Sub-Namspace Registration of urn:ietf:params:oauth:grant-type:saml2-beare= r > > This is a request to IANA to please register the value grant-type:saml2-b= earer in the registry urn:ietf:params:oauth established in [draft-ietf-oaut= h-v2]. > > =A0 URN: urn:ietf:params:oauth:grant-type:saml2-bearer > > =A0 Common Name: SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2= .0 > > =A0 Registrant Contact: IESG > > =A0 Description: [[this document]] > > --------- > > Other grant types would then go in urn:ietf:params:oauth:grant-type:saml2= -holder-of-the-key > Other OAuth related parameters then go under urn:ietf:params:oauth:foobar > > Ciao > Hannes > > > On Jul 9, 2011, at 6:17 PM, Eran Hammer-Lahav wrote: > >> The OAuth WG is looking for assistance from the application area communi= ty. >> >> OAuth 2.0 [1] defines a URI-namespaced method for defining extension gra= nt types[2]. The first specification to use this method needs to pick a URI= identifier for using SAML assertions [3]. Options proposed: >> >> urn:oasis:names:tc:SAML:2.0:assertion >> urn:ietf:wg:oauth:2.0:grant_type:saml:2.0:bearer >> http://oauth.net/grant_type/saml/2.0/bearer >> >> Is there a BCP established for this? We need to pick a value quickly and= move on. >> >> EHL >> >> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-18 >> [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-18#section-8.3 >> [3] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04 >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From mnot@mnot.net Sun Jul 10 18:18:39 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC50D21F863D for ; Sun, 10 Jul 2011 18:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.291 X-Spam-Level: X-Spam-Status: No, score=-106.291 tagged_above=-999 required=5 tests=[AWL=-3.692, BAYES_00=-2.599, 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 o8eDU1ETNsWI for ; Sun, 10 Jul 2011 18:18:39 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 14A8B21F8637 for ; Sun, 10 Jul 2011 18:18:38 -0700 (PDT) Received: from host9027e4f94482.mnot.net (unknown [118.209.88.245]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7A110509D9; Sun, 10 Jul 2011 21:18:31 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Mon, 11 Jul 2011 11:18:28 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <463EE211-0C59-4865-98CB-F65A2549B273@mnot.net> References: <4E08CDCB.70902@stpeter.im> <4E1518F2.6000403@stpeter.im> To: Dirk Pranke X-Mailer: Apple Mail (2.1084) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 01:18:39 -0000 On 07/07/2011, at 1:30 PM, Dirk Pranke wrote: > On Wed, Jul 6, 2011 at 7:24 PM, Peter Saint-Andre = wrote: >>=20 >> Is there some kind of attack lurking here that we're not aware of? >> Parameter phishing or somesuch? >>=20 >=20 > No, that was not my concern. I am mostly trying to map your arguments > onto the way we're currently evolving the HTML APIs, which follow a > similar convention to X- (the vendor prefixes). I think the difference there is that the number of implementations is = relatively small. Cheers, -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Sun Jul 10 18:18:51 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7D821F869E for ; Sun, 10 Jul 2011 18:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.155 X-Spam-Level: X-Spam-Status: No, score=-106.155 tagged_above=-999 required=5 tests=[AWL=-3.556, BAYES_00=-2.599, 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 8dB+lIptFDfj for ; Sun, 10 Jul 2011 18:18:51 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id B826D21F8637 for ; Sun, 10 Jul 2011 18:18:50 -0700 (PDT) Received: from host9027e4f94482.mnot.net (unknown [118.209.88.245]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5733D509E2; Sun, 10 Jul 2011 21:18:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4E14CB64.2090403@dcrocker.net> Date: Mon, 11 Jul 2011 11:18:48 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <0F800CD8-5E3D-4FC4-8F85-B42903BBA5FD@mnot.net> References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im> <4E14A334.60500@dcrocker.net> <4E14BFFC.5070504@stpeter.im> <4E14CB64.2090403@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1084) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 01:18:51 -0000 On 07/07/2011, at 6:53 AM, Dave CROCKER wrote: > (Entire topic: X- was a good idea to avoid collisions with standards, = but turns out to be a much worse idea for uses that become standards. = So, don't use X-".) Can we get this into the abstract... or make it the abstract? Cheers, -- Mark Nottingham http://www.mnot.net/ From stpeter@stpeter.im Mon Jul 11 07:00:36 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734C721F887C for ; Mon, 11 Jul 2011 07:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.963 X-Spam-Level: X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, 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 UYyJpj2H4WbK for ; Mon, 11 Jul 2011 07:00:36 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 04E3F21F8700 for ; Mon, 11 Jul 2011 07:00:36 -0700 (PDT) Received: from squire.local (unknown [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0B3EE40FFF; Mon, 11 Jul 2011 08:00:52 -0600 (MDT) Message-ID: <4E1B0201.4050907@stpeter.im> Date: Mon, 11 Jul 2011 08:00:33 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mark Nottingham References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im> <4E14A334.60500@dcrocker.net> <4E14BFFC.5070504@stpeter.im> <4E14CB64.2090403@dcrocker.net> <0F800CD8-5E3D-4FC4-8F85-B42903BBA5FD@mnot.net> In-Reply-To: <0F800CD8-5E3D-4FC4-8F85-B42903BBA5FD@mnot.net> X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: dcrocker@bbiw.net, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 14:00:36 -0000 On 7/10/11 7:18 PM, Mark Nottingham wrote: > > On 07/07/2011, at 6:53 AM, Dave CROCKER wrote: > >> (Entire topic: X- was a good idea to avoid collisions with standards, but turns out to be a much worse idea for uses that become standards. So, don't use X-".) > > Can we get this into the abstract... or make it the abstract? Wordsmithed in my working copy to: Many application protocols use named parameters to identify data (media types, header fields in Internet mail messages and HTTP requests, etc.). Historically, protocol designers and implementers have often distinguished between "standard" and "non-standard" parameters by prefixing the latter with the string "X-" or similar constructions (e.g., "x."), where the "X" is commonly understood to stand for "eXperimental" or "eXtension". Although in theory the "X-" convention was a good way to avoid collisions between standard parameters and non-standard parameters, in practice the costs associated with leakage of non-standard parameters into the standards space outweigh the benefits. Therefore this document deprecates the "X-" convention for most application protocols. I'll push out a revised I-D today, then we can discuss it further on the list and in Quebec City. /psa From stpeter@stpeter.im Mon Jul 11 07:35:38 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADCA21F8C60 for ; Mon, 11 Jul 2011 07:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.939 X-Spam-Level: X-Spam-Status: No, score=-103.939 tagged_above=-999 required=5 tests=[AWL=0.660, BAYES_00=-2.599, GB_I_LETTER=-2, 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 PZsm2gFm37CO for ; Mon, 11 Jul 2011 07:35:37 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 43B4A21F8C68 for ; Mon, 11 Jul 2011 07:35:33 -0700 (PDT) Received: from squire.local (unknown [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3912140FFF; Mon, 11 Jul 2011 08:35:50 -0600 (MDT) Message-ID: <4E1B0A22.7080209@stpeter.im> Date: Mon, 11 Jul 2011 08:35:14 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: John C Klensin References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im> <60B61428BA7C86CBCF4D236D@PST.JCK.COM> In-Reply-To: <60B61428BA7C86CBCF4D236D@PST.JCK.COM> X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 14:35:38 -0000 On 7/9/11 8:11 AM, John C Klensin wrote: > > > --On Tuesday, July 05, 2011 21:52 -0600 Peter Saint-Andre > wrote: > >> On 6/27/11 12:36 PM, Peter Saint-Andre wrote: >> ... >> Based on list feedback, I've submitted a further revision >> (including much more specific recommendations for spec authors >> and implementers): >> >> http://www.ietf.org/id/draft-saintandre-xdash-01.txt >> >> Keep those cards and letters coming! ;-) > > > Peter, > > With the disclaimer that I'm still a fan of "x-" under very > limited circumstances, a few observations that I think are > complementary to some of those already made in this thread. > > First, while you can reasonably argue that most applications for > "X-" that are either "experimental" or even "extension" are > bogus and can be handled in other ways, there are private-use > cases that, IMO, remain legitimate. Those private-use cases > are, IMO, legitimate. They are very similar to RFC 1918 > addresses: if something reaches you that contains an X- > parameter, and the sender and receiver don't have a clear > private agreement about what it means, then the correct action > is to discard it or treat it is gibberish. Those private > agreements may require some degree of authentication, but that > is a separate issue. Note that "private use" really does imply > "private": suggesting or requiring an IANA registration, no > matter how lightweight, is out of line if only because it > identifies the registrant. I agree that mandating registration of private parameters or extensions is wrong. > Your document implicitly assumes I think it would be helpful to make the assumptions explicit. > that the world consists of > public stuff that is intended to be standardized, public stuff > that is experimental and not likely to be standardized, and > things for which embedding organization names in the parameter > (see below) are satisfactory. I don't believe it. You don't think those buckets exist, or you think that there are additional buckets? The document does mention private stuff, and I agree that private stuff needs to be handled differently. > Second, remember that the motivation that took us down this path > (see Dave's notes), and a motivation for IANA registration on > parameters and the IANA itself, was to prevent two parties from > accidentally using the same parameter value for different > purposes and thereby causing serious interoperability problems. > As Dave indirectly points out, we could have mandated > arrangements like "X-BrandenburgInternetWorking.foo" or, more > likely, "X-BrandenburgInternetWorking--foo". But we didn't and, > unless the DNS is used (which has its own set of problems, > especially in the world ICANN is creating) it would just require > the creation of another registry that would have to be managed > and that might be controversial among intellectual property > folks ("X-BrandenburgInternetWorking.foo" and "X-Klensin.foo" > are probably fine, but "X-JoesPizza.foo" is the introduction to > a nightmare). > > To discourage a mandate for parameters to be registered with > IANA is to encourage those interoperability problems. At a > minimum, if you are going to make that recommendation, its > implications need to be explicitly discussed in Security > Considerations. I think it is a bad recommendation, even if > some people will certainly ignore it. Making it a useful > recommendation, however, requires that the IETF get completely > over its self-proclaimed role as an arbiter of taste in > identifier names and descriptions. I'm comfortable with saying that all parameters should be registered, with a carve-out for truly private parameters. As you say, it appears that many implementers will simply ignore the mandate. > Similarly, if "you better know who sent this to you and what > they think it means" is a "special meaning to parameters with > the 'X-' prefix", then I think you are looking for other > problems. By "special meaning" I was trying to capture only the assumption that any parameter with the "X-" prefix is non-standard (and that any parameter without the "X-" prefix is standard). Given the fact of leakage from the non-standard space into the standard space, such an assumption is unwarranted. I'll make this clearer in -02. > FWIW, "X-JoesPizza.foo" (or just "JoesPizza.foo") > involves the imputation of a special meaning by parsing the > parameter string and isolating the "relevant organization's name > or primary domain name". Interestingly, from the way you write > that recommendation, "foo.JoesPizza" is equally legitimate, > after which it becomes really easy to fall back into the trap of > conflicting names and interoperability problems. You're right that humans tend to impute other meaning to strings by parsing them into patterns that make sense. I see no solution to that problem. > Recommendation: There is too much history and you can't get this > right without causing even more interoperability issues than we > have today. Private-use cases are legitimate and it is > appropriate to provide some syntax that will identify them and > shift the burden of figuring out what they mean to private > agreements (and authentication of the parties to those > agreements that is appropriate to the protocol in question). > > Encouraging more protocols to organize their parameters as > trees, allow for vendor and personal trees, and define > sufficient syntax and registries to actually make those trees > work is actually a fine idea, but it may still not eliminate the > need for private-use parameters. What prevents an implementer with a truly private-use parameter from assigning a UUID, a hash, or some other unmeaningful string of characters? > Finally, two asides/nits: > > (1) If you want to talk about "X-", your reference should be to > RFC 5322 and its predecessors, not 5321, Yes, I'd already caught that bug in -01, it's fixed in -02. > or you need more text. > RFC 5321 (and its predecessors) use "X" (no hyphen") for > private-use commands (and calls them that, not extensions or > experiments, see Section 4.1.5). "X-" is used only in passing > and in an example discussing gateways in Section 3.7.1. FWIW, > my guess is that the leading "X" idea started with FTP and > migrated, in "X-" form, to 822, but I don't remember (if I ever > knew), so it is really just a guess. Interesting. I just found the following in RFC 691: Thus, FTP servers which care about the distinction between Telnet print and non-print could implement SRVR N and SRVR T. Ideally the SRVR parameters should be registered with Jon Postel to avoid conflicts, although it is not a disaster if two sites use the same parameter for different things. I suggest that parameters be allowed to be more than one letter, and that an initial letter X be used for really local idiosyncracies. This convention appears to have been used in some early FTP RFCs, such as 737, 743, and 775 (mentioned in RFC 1123, as you point out). > (2) While provisional URI schemes keep coming up as examples of > how one might do these special extensions instead (as in your > Section 2), I think a careful understanding of the history of > "X-" to which people most object (and that RFC 1123 discusses in > the context of experimental FTP commands, providing an example > in its Section 4.1.3.1 that may be better than the two you cite > and that is certainly earlier) suggests that the only thing > "provisional" about a provisional registration is tolerance for > rotten or missing documentation. Just like a command or > parameter starting in "X-" or "X", once the name associated with > a provisional registration is used and incorporated into > protocols, it is "used up": if the definition is changed, or > even clarified in a way that eliminates some interpretations, it > is usually better to select a new parameter string than to > pretend that the new definition applies retroactively to the old > parameter name. Yes. > Even if you disagree with that, I think it > deserves some discussion in the document if you are going to > recommend provisional registrations as an option. Agreed. I'm not sure I'll have time to work these matters into -02 of the document given time constraints today, but if not we'll do so in -03. Peter -- Peter Saint-Andre https://stpeter.im/ From dhc@dcrocker.net Mon Jul 11 07:41:46 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC87821F8C88 for ; Mon, 11 Jul 2011 07:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.621 X-Spam-Level: X-Spam-Status: No, score=-6.621 tagged_above=-999 required=5 tests=[AWL=-0.022, 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 v8dz58P671zU for ; Mon, 11 Jul 2011 07:41:46 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 376B121F8C87 for ; Mon, 11 Jul 2011 07:41:46 -0700 (PDT) Received: from [192.168.1.156] (adsl-67-124-149-98.dsl.pltn13.pacbell.net [67.124.149.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p6BEfeY4023233 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 11 Jul 2011 07:41:45 -0700 Message-ID: <4E1B0B99.7030502@dcrocker.net> Date: Mon, 11 Jul 2011 07:41:29 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im> <4E14A334.60500@dcrocker.net> <4E14BFFC.5070504@stpeter.im> <4E14CB64.2090403@dcrocker.net> <0F800CD8-5E3D-4FC4-8F85-B42903BBA5FD@mnot.net> <4E1B0201.4050907@stpeter.im> In-Reply-To: <4E1B0201.4050907@stpeter.im> 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, 11 Jul 2011 07:41:45 -0700 (PDT) Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 14:41:47 -0000 On 7/11/2011 7:00 AM, Peter Saint-Andre wrote: > On 7/10/11 7:18 PM, Mark Nottingham wrote: >> >> On 07/07/2011, at 6:53 AM, Dave CROCKER wrote: >> >>> (Entire topic: X- was a good idea to avoid collisions with standards, but turns out to be a much worse idea for uses that become standards. So, don't use X-".) >> >> Can we get this into the abstract... or make it the abstract? > > Wordsmithed in my working copy to: > > Many application protocols use named parameters to identify data > (media types, header fields in Internet mail messages and HTTP > requests, etc.). Historically, protocol designers and implementers > have often distinguished between "standard" and "non-standard" > parameters by prefixing the latter with the string "X-" or similar > constructions (e.g., "x."), where the "X" is commonly understood to > stand for "eXperimental" or "eXtension". Although in theory the "X-" > convention was a good way to avoid collisions between standard > parameters and non-standard parameters, in practice the costs > associated with leakage of non-standard parameters into the standards > space outweigh the benefits. Therefore this document deprecates the > "X-" convention for most application protocols. I like the paragraph. The specific re-casting of my terse "entire topic" statement is in the sentence: > Although in theory the "X-" >> convention was a good way to avoid collisions between standard >> parameters and non-standard parameters, in practice the costs >> associated with leakage of non-standard parameters into the standards >> space outweigh the benefits. That looks fine, except that and I'd suggest saying evolution or movement, rather than leakage. Whether the standardization is intentional or not, it's viewed as a Good Thing, whereas "leakage" is typically taken as a negative. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From stpeter@stpeter.im Mon Jul 11 08:50:42 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6BB21F8E43 for ; Mon, 11 Jul 2011 08:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.732 X-Spam-Level: X-Spam-Status: No, score=-102.732 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, 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 Er+wxWQrhUlW for ; Mon, 11 Jul 2011 08:50:41 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B317E21F8D7D for ; Mon, 11 Jul 2011 08:50:41 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8B9EB40FFF; Mon, 11 Jul 2011 09:50:57 -0600 (MDT) Message-ID: <4E1B1BCC.2010704@stpeter.im> Date: Mon, 11 Jul 2011 09:50:36 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im> <4E14A334.60500@dcrocker.net> <4E14BFFC.5070504@stpeter.im> <4E14CB64.2090403@dcrocker.net> <0F800CD8-5E3D-4FC4-8F85-B42903BBA5FD@mnot.net> <4E1B0201.4050907@stpeter.im> <4E1B0B99.7030502@dcrocker.net> In-Reply-To: <4E1B0B99.7030502@dcrocker.net> X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 15:50:42 -0000 On 7/11/11 8:41 AM, Dave CROCKER wrote: > > > On 7/11/2011 7:00 AM, Peter Saint-Andre wrote: >> On 7/10/11 7:18 PM, Mark Nottingham wrote: >>> >>> On 07/07/2011, at 6:53 AM, Dave CROCKER wrote: >>> >>>> (Entire topic: X- was a good idea to avoid collisions with >>>> standards, but turns out to be a much worse idea for uses that >>>> become standards. So, don't use X-".) >>> >>> Can we get this into the abstract... or make it the abstract? >> >> Wordsmithed in my working copy to: >> >> Many application protocols use named parameters to identify data >> (media types, header fields in Internet mail messages and HTTP >> requests, etc.). Historically, protocol designers and implementers >> have often distinguished between "standard" and "non-standard" >> parameters by prefixing the latter with the string "X-" or similar >> constructions (e.g., "x."), where the "X" is commonly understood to >> stand for "eXperimental" or "eXtension". Although in theory the "X-" >> convention was a good way to avoid collisions between standard >> parameters and non-standard parameters, in practice the costs >> associated with leakage of non-standard parameters into the standards >> space outweigh the benefits. Therefore this document deprecates the >> "X-" convention for most application protocols. > > I like the paragraph. > > The specific re-casting of my terse "entire topic" statement is in the > sentence: > >> Although in theory the "X-" >>> convention was a good way to avoid collisions between standard >>> parameters and non-standard parameters, in practice the costs >>> associated with leakage of non-standard parameters into the >>> standards >>> space outweigh the benefits. > > That looks fine, except that and I'd suggest saying evolution or > movement, rather than leakage. > > Whether the standardization is intentional or not, it's viewed as a Good > Thing, whereas "leakage" is typically taken as a negative. True. I've changed all instances of "leak[age]" to "advance[ment]". I think of the "X-" area as the wrong side of the tracks, and advancement into the non-"X-" area as moving up in the world. :) I'll submit -02 shortly and look forward to making -03 after IETF 81. Peter -- Peter Saint-Andre https://stpeter.im/ From evnikita2@gmail.com Mon Jul 11 10:26:30 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F9921F8E4D for ; Mon, 11 Jul 2011 10:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 4NmK4XitvsKO for ; Mon, 11 Jul 2011 10:26:29 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0E621F86C1 for ; Mon, 11 Jul 2011 10:26:29 -0700 (PDT) Received: by bwb17 with SMTP id 17so3994260bwb.31 for ; Mon, 11 Jul 2011 10:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=bs/u5fo0GI/J1HWhIz6PCbdG47MBhN3ftZlw9IHD0fk=; b=rteEZuFGgp0bbcN9wnZ+bpmPBKGZzUp9icjG52r0eN+se9hBotzpPgTXCoB07qxEJh CBDlZwTJmzR6heGrARLa5govpvTNS68xgCQRrTmr12GDOnbdXtSiJC+s5zlajxaGxepP PHKYohlknzGYi8n9+QC3HkyNMzSo4svB5i25c= Received: by 10.204.35.202 with SMTP id q10mr1775723bkd.401.1310405188284; Mon, 11 Jul 2011 10:26:28 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id af13sm1125129bkc.40.2011.07.11.10.26.26 (version=SSLv3 cipher=OTHER); Mon, 11 Jul 2011 10:26:27 -0700 (PDT) Message-ID: <4E1B3270.40601@gmail.com> Date: Mon, 11 Jul 2011 20:27:12 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Apps-discuss list References: <4E15C895.6020701@gmail.com> In-Reply-To: <4E15C895.6020701@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 17:26:30 -0000 Hello, You should have noticed the Appendix A of this document regarding use of DDDS with 'ftp' URIs. After some discussions on regsiter@uri.arpa list, which I managed to arrange (which can be confirmed by Frank Ellermann as messages are not archived there), we have reached a consensus (at least no-one objected) to change the substitutions expression in NAPTR record for ftp.uri.arpa domain from > !^ftp://([^:/?#]*).*$!\\1!i to > !^ftp://(.*@)?([^:/?#]*).*$!\\2!i This message is to notify folks on apps-discuss (the number of which I believe is much more numerous) about this "consensus". However, any further comments are welcome. Mykyta Yevstifeyev 07.07.2011 17:54, Mykyta Yevstifeyev wrote: > I've just uploaded a new version of draft-yevstifeyev-ftp-uri-scheme. > Any further comments are welcome. Mykyta >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : The'ftp' URI Scheme >> Author(s) : Mykyta Yevstifeyev >> Filename : draft-yevstifeyev-ftp-uri-scheme-04.txt >> Pages : 22 >> Date : 2011-07-07 >> >> From dpranke@google.com Mon Jul 11 11:38:02 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D2B11E814F for ; Mon, 11 Jul 2011 11:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 A8788LpzmxoV for ; Mon, 11 Jul 2011 11:38:01 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7E35611E80A8 for ; Mon, 11 Jul 2011 11:37:59 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p6BIbw7E029643 for ; Mon, 11 Jul 2011 11:37:58 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310409478; bh=6QaiRm5KROxE/e86qdfau5rXr9U=; h=MIME-Version:Sender:In-Reply-To:References:From:Date:Message-ID: Subject:To:Cc:Content-Type; b=k3+8xl+dN+1MQz1CIQF09naYhTuiZWrS/kWohRT/YSG9Z+oIKWd6D8WMhrDwo7Lec 4YDTKYWmGbqXEsnq0NjIw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:sender:in-reply-to:references:from: date:x-google-sender-auth:message-id:subject:to:cc:content-type:x-system-of-record; b=isJFYC8WWFZwWgVjPr+wwwQz1wuHE5y5ETgme8MlpMYlext1vQDhKjCu3/f9A+RJB 6LZuTRiBwMiNu06wmm2dA== Received: from pvg12 (pvg12.prod.google.com [10.241.210.140]) by hpaq14.eem.corp.google.com with ESMTP id p6BIbtSs019745 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 11 Jul 2011 11:37:57 -0700 Received: by pvg12 with SMTP id 12so3075815pvg.19 for ; Mon, 11 Jul 2011 11:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=6faRfaT08NRNVBVJE+RZFoqaeYuvMKktqzRvFbVIlEE=; b=Ghv3AhgEc3iOIUr8Iq5zZ3zl8YV3t41yQO1FMraem46TknqavnJ6Wdih1vka3TfkvU RMaFygWFfzD6ra95DQZA== Received: by 10.68.60.170 with SMTP id i10mr7777519pbr.83.1310409475146; Mon, 11 Jul 2011 11:37:55 -0700 (PDT) MIME-Version: 1.0 Sender: dpranke@google.com Received: by 10.142.193.2 with HTTP; Mon, 11 Jul 2011 11:37:35 -0700 (PDT) In-Reply-To: <463EE211-0C59-4865-98CB-F65A2549B273@mnot.net> References: <4E08CDCB.70902@stpeter.im> <4E1518F2.6000403@stpeter.im> <463EE211-0C59-4865-98CB-F65A2549B273@mnot.net> From: Dirk Pranke Date: Mon, 11 Jul 2011 11:37:35 -0700 X-Google-Sender-Auth: -uTqNWdbtAFGbT0bk957r3i1sE8 Message-ID: To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 18:38:02 -0000 On Sun, Jul 10, 2011 at 6:18 PM, Mark Nottingham wrote: > > On 07/07/2011, at 1:30 PM, Dirk Pranke wrote: > >> On Wed, Jul 6, 2011 at 7:24 PM, Peter Saint-Andre wrote: >>> >>> Is there some kind of attack lurking here that we're not aware of? >>> Parameter phishing or somesuch? >>> >> >> No, that was not my concern. I am mostly trying to map your arguments >> onto the way we're currently evolving the HTML APIs, which follow a >> similar convention to X- (the vendor prefixes). > > > I think the difference there is that the number of implementations is relatively small. > Hmm. I agree that the number of browser implementations with significant market share is fairly small, but I don't know that this is unusual. I'd be hard pressed to think of a significant application or transport-layer protocol that has had more than a half dozen major (read: others have to adopt their extensions) implementations either. -- Dirk From mnot@mnot.net Mon Jul 11 17:17:25 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DF811E817F for ; Mon, 11 Jul 2011 17:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.87 X-Spam-Level: X-Spam-Status: No, score=-105.87 tagged_above=-999 required=5 tests=[AWL=-3.586, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, 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 zT-C9fPMwLUD for ; Mon, 11 Jul 2011 17:17:24 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id A852111E813A for ; Mon, 11 Jul 2011 17:17:24 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.88.245]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 379D1509B3; Mon, 11 Jul 2011 20:17:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Tue, 12 Jul 2011 10:17:14 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E08CDCB.70902@stpeter.im> <4E1518F2.6000403@stpeter.im> <463EE211-0C59-4865-98CB-F65A2549B273@mnot.net> To: Dirk Pranke X-Mailer: Apple Mail (2.1084) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 00:17:25 -0000 On 12/07/2011, at 4:37 AM, Dirk Pranke wrote: > On Sun, Jul 10, 2011 at 6:18 PM, Mark Nottingham = wrote: >>=20 >> On 07/07/2011, at 1:30 PM, Dirk Pranke wrote: >>=20 >>> On Wed, Jul 6, 2011 at 7:24 PM, Peter Saint-Andre = wrote: >>>>=20 >>>> Is there some kind of attack lurking here that we're not aware of? >>>> Parameter phishing or somesuch? >>>>=20 >>>=20 >>> No, that was not my concern. I am mostly trying to map your = arguments >>> onto the way we're currently evolving the HTML APIs, which follow a >>> similar convention to X- (the vendor prefixes). >>=20 >>=20 >> I think the difference there is that the number of implementations is = relatively small. >>=20 >=20 > Hmm. I agree that the number of browser implementations with > significant market share is fairly small, but I don't know that this > is unusual. I'd be hard pressed to think of a significant application > or transport-layer protocol that has had more than a half dozen major > (read: others have to adopt their extensions) implementations either. Right, but think of HTTP headers; any random person can (and does) add = them, all of the time, and then they're in use.=20 This is where "implementation" breaks down, because it's the "server" + = frameworks + site-specific code. While there are a few handful* of HTTP = server implementations, there are hundreds of frameworks, and millions = of sites with their own code. Then there are conventions that people = layer over top, for interop between sites / frameworks (e.g., Atompub). Cheers, * =46rom what I can see, the number of HTTP server implementations is = exploding as well, over the last few years.=20 Mark Nottingham http://www.mnot.net/ From masinter@adobe.com Mon Jul 11 18:26:45 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B8C11E8213 for ; Mon, 11 Jul 2011 18:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Mog+Gi0Z1Y2l for ; Mon, 11 Jul 2011 18:26:45 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id DA8C311E80D2 for ; Mon, 11 Jul 2011 18:26:44 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKThuiyZriHtnoi4FrX3mFTZMPykO9NdNt@postini.com; Mon, 11 Jul 2011 18:26:44 PDT Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p6C1PIES003768; Mon, 11 Jul 2011 18:25:19 -0700 (PDT) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id p6C1QTMT008372; Mon, 11 Jul 2011 18:26:30 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Mon, 11 Jul 2011 18:26:29 -0700 From: Larry Masinter To: Peter Saint-Andre , John C Klensin Date: Mon, 11 Jul 2011 18:26:09 -0700 Thread-Topic: [apps-discuss] "X-" revisited Thread-Index: Acw/1+CoNID7GPQtQiSfg5ajuhEQZAAWbS/w Message-ID: References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im> <60B61428BA7C86CBCF4D236D@PST.JCK.COM> <4E1B0A22.7080209@stpeter.im> In-Reply-To: <4E1B0A22.7080209@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 01:26:46 -0000 Don't the considerations around "x-" also apply to "vnd." in media types? vendor-specific media types become standards. standard media types get vend= or-specific extensions. The additional "information" that we imagine is associated with "x-" or "vn= d." is=20 * not testable * can evolve over time with no transition method, plan, policy in place * has no cost associated with mis-use (calling something x- or vnd. when i= t isn't, or not using x- or vnd. when proscribed). In the general area of registry values, any lexical convention for registry= values must have some actual implementation consequences for most of the c= ommunity to take the restrictions seriously.=20 Larry -- http://larry.masinter.net From mnot@mnot.net Tue Jul 12 16:54:03 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC1E11E80AF for ; Tue, 12 Jul 2011 16:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.927 X-Spam-Level: X-Spam-Status: No, score=-105.927 tagged_above=-999 required=5 tests=[AWL=-3.328, BAYES_00=-2.599, 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 8Ppo+It9JUhX for ; Tue, 12 Jul 2011 16:53:59 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 323F411E80AE for ; Tue, 12 Jul 2011 16:53:59 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.151.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 959D2509EF; Tue, 12 Jul 2011 19:53:51 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Wed, 13 Jul 2011 09:53:48 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <0F91F701-62FC-4E33-A2B9-EB13F676C27F@mnot.net> References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im> <60B61428BA7C86CBCF4D236D@PST.JCK.COM> <4E1B0A22.7080209@stpeter.im> To: Larry Masinter X-Mailer: Apple Mail (2.1084) Cc: John C Klensin , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 23:54:03 -0000 On 12/07/2011, at 11:26 AM, Larry Masinter wrote: > Don't the considerations around "x-" also apply to "vnd." in media = types? >=20 > vendor-specific media types become standards. standard media types get = vendor-specific extensions. It's a somewhat different path, I think. A vendor who uses a vnd and = then later standardises the format has demonstrated a willingness to do = the right thing, and the incremental effort for them is small. Contrast that with the common case for X-; IME it's usually started by = someone who has an incomplete understanding of the standards process, = and doesn't want to put much effort in. X- has become a sort of cargo = cult whereby it's OK to do anything if you just put X- in front of it, = so that's what people do -- even for things that end up getting widely = used.=20 We basically need a leaflet that we can drop on that island of cargo = culters, to gently clue them in. Except that the island is really the = rest of the world. But you get the idea. Cheers, P.S. A vnd that later gets standardised is likely to have differences = between the versions, so a different identifier is necessary anyway. >=20 > The additional "information" that we imagine is associated with "x-" = or "vnd." is=20 > * not testable > * can evolve over time with no transition method, plan, policy in = place > * has no cost associated with mis-use (calling something x- or vnd. = when it isn't, or not using x- or vnd. when proscribed). >=20 > In the general area of registry values, any lexical convention for = registry values must have some actual implementation consequences for = most of the community to take the restrictions seriously.=20 >=20 > Larry > -- > http://larry.masinter.net > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From dpranke@google.com Tue Jul 12 18:15:15 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4CC21F8B84 for ; Tue, 12 Jul 2011 18:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.82 X-Spam-Level: X-Spam-Status: No, score=-105.82 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, 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 f0+5Tokcf01e for ; Tue, 12 Jul 2011 18:15:10 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7A28021F8AF0 for ; Tue, 12 Jul 2011 18:15:10 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p6D1F8Ag008623 for ; Tue, 12 Jul 2011 18:15:08 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310519709; bh=b7gP4nfEQwSyQsZmqOKs4JfPFgw=; h=MIME-Version:Sender:In-Reply-To:References:From:Date:Message-ID: Subject:To:Cc:Content-Type:Content-Transfer-Encoding; b=KLWkfZFtG4keqxrg8VgP57twkA2CBJD1mZGbRBYERrgqPouc9HgWdK1sb5rV79N9H JCgSOqqYbwBJRjonyUMAg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:sender:in-reply-to:references:from: date:x-google-sender-auth:message-id:subject:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=I/8/P40vkp34O4ZdAqMErZCaUL4ptjuTjLB+4+I1RsoqxQzfgd5C3LZNX2NLnYYuh UnalbOTD29lXTUh91L4zQ== Received: from pvg11 (pvg11.prod.google.com [10.241.210.139]) by kpbe14.cbf.corp.google.com with ESMTP id p6D1DSus014559 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 12 Jul 2011 18:15:06 -0700 Received: by pvg11 with SMTP id 11so6770854pvg.27 for ; Tue, 12 Jul 2011 18:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=sSdFEuBJuzHlUaUumNqlzEol46b86WQIdTbj4CKiR8I=; b=UYtXfrobq1iGk31gJ2rnc/YxyS+bBAtrrHsZsLlDeZV8aFxk7pBauZMgy45x6N5P3w LtDl13G08BV7kKn9bC5w== Received: by 10.143.43.17 with SMTP id v17mr238139wfj.56.1310519701121; Tue, 12 Jul 2011 18:15:01 -0700 (PDT) MIME-Version: 1.0 Sender: dpranke@google.com Received: by 10.142.193.2 with HTTP; Tue, 12 Jul 2011 18:14:41 -0700 (PDT) In-Reply-To: References: <4E08CDCB.70902@stpeter.im> <4E1518F2.6000403@stpeter.im> <463EE211-0C59-4865-98CB-F65A2549B273@mnot.net> From: Dirk Pranke Date: Tue, 12 Jul 2011 18:14:41 -0700 X-Google-Sender-Auth: BwnO4r1CX9CL5Jy1SxAxnKYB8C0 Message-ID: To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "X-" revisited X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 01:15:15 -0000 On Mon, Jul 11, 2011 at 5:17 PM, Mark Nottingham wrote: > On 12/07/2011, at 4:37 AM, Dirk Pranke wrote: > >> On Sun, Jul 10, 2011 at 6:18 PM, Mark Nottingham wrote: >>> >>> On 07/07/2011, at 1:30 PM, Dirk Pranke wrote: >>> >>>> On Wed, Jul 6, 2011 at 7:24 PM, Peter Saint-Andre = wrote: >>>>> >>>>> Is there some kind of attack lurking here that we're not aware of? >>>>> Parameter phishing or somesuch? >>>>> >>>> >>>> No, that was not my concern. I am mostly trying to map your arguments >>>> onto the way we're currently evolving the HTML APIs, which follow a >>>> similar convention to X- (the vendor prefixes). >>> >>> >>> I think the difference there is that the number of implementations is r= elatively small. >>> >> >> Hmm. I agree that the number of browser implementations with >> significant market share is fairly small, but I don't know that this >> is unusual. I'd be hard pressed to think of a significant application >> or transport-layer protocol that has had more than a half dozen major >> (read: others have to adopt their extensions) implementations either. > > Right, but think of HTTP headers; any random person can (and does) add th= em, all of the time, and then they're in use. > > This is where "implementation" breaks down, because it's the "server" + f= rameworks + site-specific code. While there are a few handful* of HTTP serv= er implementations, there are hundreds of frameworks, and millions of sites= with their own code. Then there are conventions that people layer over top= , for interop between sites / frameworks (e.g., Atompub). > I think I did not make myself clear. Just because some implementation uses a header named 'X' does not mean that everyone else cares. We ignore headers we don't recognize. We usually only care about header X when a significant percentage of our traffic starts using it. On the other hand, your point about there being a lot of frameworks is valid, and I agree that there's a lot more than six of them :) Then again, frameworks rarely create new headers in my (admittedly limited) experience. -- Dirk > Cheers, > > > * From what I can see, the number of HTTP server implementations is explo= ding as well, over the last few years. > > > Mark Nottingham =C2=A0 http://www.mnot.net/ > > > > From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Jul 13 18:48:55 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DD921F8766 for ; Wed, 13 Jul 2011 18:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.756 X-Spam-Level: X-Spam-Status: No, score=-102.756 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1, 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 el7DcsTq4zdM for ; Wed, 13 Jul 2011 18:48:55 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0427121F872E for ; Wed, 13 Jul 2011 18:48:54 -0700 (PDT) Received: by pvh18 with SMTP id 18so7392780pvh.31 for ; Wed, 13 Jul 2011 18:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Ru4OVrkLCyAPf88m8LUtNBT+QRo1wDrOYhyQpczqhmY=; b=axVZlAaIM6XsyL7O6nMl/0hVNvwBhZ/VRiEqFBokOZpSgofK+mwu2arqPzenfzcEQO vQue6ie/wtlokLOYf57N4mMbOIgiMd9lLdX9LCv1bWDPD8gfuw/1p1yNUfb8acahUPdb pDcRJDNflw4EvBEHh6fdarnjp/j9kokpOyI9I= Received: by 10.142.44.5 with SMTP id r5mr781364wfr.66.1310608133239; Wed, 13 Jul 2011 18:48:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.88.9 with HTTP; Wed, 13 Jul 2011 18:48:33 -0700 (PDT) In-Reply-To: <4E1B3270.40601@gmail.com> References: <4E15C895.6020701@gmail.com> <4E1B3270.40601@gmail.com> From: Frank Ellermann Date: Thu, 14 Jul 2011 03:48:33 +0200 Message-ID: To: Mykyta Yevstifeyev Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps-discuss list Subject: Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 01:48:56 -0000 On 11 July 2011 19:27, Mykyta Yevstifeyev wrote: >> !^ftp://(.*@)?([^:/?#]*).*$!\\2!i Sorry, I sent my comment to the uri.arpa list before I saw your summary here. Here's my proposal based on the discussion there: !^ftp://([^@/?#]*@)?([^:/?#]*).*$!\\2!i -Frank From evnikita2@gmail.com Wed Jul 13 20:29:10 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE0711E80D5 for ; Wed, 13 Jul 2011 20:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.925 X-Spam-Level: X-Spam-Status: No, score=-2.925 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] 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 1bk-vC0HdNkp for ; Wed, 13 Jul 2011 20:29:06 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id F06D311E80C5 for ; Wed, 13 Jul 2011 20:29:04 -0700 (PDT) Received: by fxe4 with SMTP id 4so358011fxe.27 for ; Wed, 13 Jul 2011 20:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=xfTQ7KlngpZInDqGAsd6d5vwA4unYPrn9aiOOBjrOCA=; b=Xun9VSuPN2BnSySe2ifRaVmNv3veQwCuKejnUVgL9Go7285AnKQog2o4Y/WyT2DJKy yAShexyMABms1Wp7jV59WiGx1V77gW9wshUwF44P1lF/Xpl9ZEXapI4st4+sbtgOos8a 8XYk/qOHg14u/L+1R6OCkxeaWFL5Nv5RF2vIQ= Received: by 10.223.158.72 with SMTP id e8mr2473195fax.39.1310614144127; Wed, 13 Jul 2011 20:29:04 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id y21sm4207189fad.15.2011.07.13.20.29.02 (version=SSLv3 cipher=OTHER); Wed, 13 Jul 2011 20:29:03 -0700 (PDT) Message-ID: <4E1E62AB.2070608@gmail.com> Date: Thu, 14 Jul 2011 06:29:47 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Frank Ellermann References: <4E15C895.6020701@gmail.com> <4E1B3270.40601@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060502080607080701050404" Cc: Apps-discuss list Subject: Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 03:29:10 -0000 This is a multi-part message in MIME format. --------------060502080607080701050404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Frank, I think I'll move the discussion here. The following is your posting to register@uri.arpa: > 2011/7/10 Mykyta Yevstifeyev: > >>> That can be simplified to: >>> !^ftp://([^@]*@)?([^:/?#]*).*$!\\2!i >> I agree with you here. Yet, actually this may be simplified >> far to >>> !^ftp://(.*@)?([^:/?#]*).*$!\\2!i I don't agree with such expression. See justification below. > Is "anything ending with '@'" (in your version) the same as > "any non-'@' ending with the first '@'" (in JimC's version)? > For clarity I'd prefer the first version, but maybe we are > not yet ready: > >> "@" chars are not generally allowed in in without >> percent encoding, as well as in other parts of the URI. > As soon as you are behind the in an > it is not more necessary to percent-encode '@'. I'm too lazy > to check it, but I guess that '@' is an ordinary, and > also allowed in query parts and fragments. "@" is in , so we can safely assume that it won't apper anywhere else except the authority non-percent-encoded. As "@"s aren't allowed in as by RFC 3986 and my document, it is also assumed that there will be no "@" chars before the "@" delimiting userinfo from host (if, we can they assume that the second "@" is a part of , which isn't allowed as well). So, "@" will normally occur only 1 time, and won't occur in the itself, query or fragment identifier. > > After all mailto: and news: URLs use '@' for their purposes > outside of. > > Therefore we might need something in the direction of... > !^ftp://([^@/?#]*@)?([^:/?#]*).*$!\\2!i > ...matching '@' only before any path or query or fragment. > [^@/?#]* should match the colon in a user:pass. This would make sense if "@" was in . See above. So as a summary: The expression > !^ftp://([^@]*@)?([^:/?#]*).*$!\\2!i is sufficient enough to match RFC 3986 and this particular URI scheme. Mykyta > > -Frank > 14.07.2011 4:48, Frank Ellermann wrote: > On 11 July 2011 19:27, Mykyta Yevstifeyev wrote: > >>> !^ftp://(.*@)?([^:/?#]*).*$!\\2!i > Sorry, I sent my comment to the uri.arpa list before I saw your > summary here. Here's my proposal based on the discussion there: > > !^ftp://([^@/?#]*@)?([^:/?#]*).*$!\\2!i > > -Frank > --------------060502080607080701050404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Frank,

I think I'll move the discussion here.  The following is your posting to register@uri.arpa:

2011/7/10 Mykyta Yevstifeyev:


That can be simplified to:
  !^ftp://([^@]*@)?([^:/?#]*).*$!\\2!i

I agree with you here.  Yet, actually this may be simplified
far to

  !^ftp://(.*@)?([^:/?#]*).*$!\\2!i

I don't agree with such expression.  See justification below.


          

        

        
Is "anything ending with '@'" (in your version) the same as
"any non-'@' ending with the first '@'" (in JimC's version)?
For clarity I'd prefer the first version, but maybe we are
not yet ready:



        

          
"@" chars are not generally allowed in in <userinfo> without
percent encoding, as well as in other parts of the URI.


        

        
As soon as you are behind the <userinfo> in an <authority>
it is not more necessary to percent-encode '@'.  I'm too lazy
to check it, but I guess that '@' is an ordinary <pchar>, and
also allowed in query parts and fragments.

      

    

    

    "@" is in <gen-delims>, so we can safely assume that it won't
    apper anywhere else except the authority non-percent-encoded.  As
    "@"s aren't allowed in <userinfo> as by RFC 3986 and my
    document, it is also assumed that there will be no "@" chars before
    the "@" delimiting userinfo from host (if, we can they assume that
    the second "@" is a part of <host>, which isn't allowed as
    well).  So, "@" will normally occur only 1 time, and won't occur in
    the <userinfo> itself, query or fragment identifier.

    

    

      

        

After all mailto: and news: URLs use '@' for their purposes
outside of <userinfo>.

Therefore we might need something in the direction of...
!^ftp://([^@/?#]*@)?([^:/?#]*).*$!\\2!i
...matching '@' only before any path or query or fragment.
[^@/?#]* should match the colon in a user:pass <userinfo>.

      

    

    

    This would make sense if "@" was in <sub-delims>.  See above.

    

    So as a summary: The expression 

    

    

      
!^ftp://([^@]*@)?([^:/?#]*).*$!\\2!i

    

    

    is sufficient enough to match RFC 3986 and this particular URI
    scheme.

    

    Mykyta

    

    

      

        

-Frank



      

    

    

    14.07.2011 4:48, Frank Ellermann wrote:
    

      
On 11 July 2011 19:27, Mykyta Yevstifeyev wrote:



      

        

          
!^ftp://(.*@)?([^:/?#]*).*$!\\2!i


        

      

      
Sorry, I sent my comment to the uri.arpa list before I saw your
summary here.  Here's my proposal based on the discussion there:

   !^ftp://([^@/?#]*@)?([^:/?#]*).*$!\\2!i

-Frank



    

    

  


--------------060502080607080701050404--

From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com  Thu Jul 14 16:44:58 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E6621F86DF for ; Thu, 14 Jul 2011 16:44:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.007
X-Spam-Level: 
X-Spam-Status: No, score=-103.007 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 wXnvcqVgCSiV for ; Thu, 14 Jul 2011 16:44:57 -0700 (PDT)
Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by ietfa.amsl.com (Postfix) with ESMTP id AC31621F86DE for ; Thu, 14 Jul 2011 16:44:57 -0700 (PDT)
Received: by pzd13 with SMTP id 13so1034210pzd.39 for ; Thu, 14 Jul 2011 16:44:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=I3mE8pwH9sqBBQKimMhqnJ2NAI+VHS1PLLKQc3dG7AU=; b=NCRmAW+uyWKsPHu+E7SUAvHL3QzEHR5SaUEZ7ZbnAh+3JCqXHE4OEJY5BTmS6rOapC LkrMi10avy5HZqChlJrs4Ny6cWlceR3iYzPAS9wUjtWwx4CqLCxByytbhmIeX91ZqL6R ni2T2q0CfJ7FStb9vM6B5UjjK+oGLRJcJ5S4M=
Received: by 10.142.250.13 with SMTP id x13mr1247124wfh.9.1310687097291; Thu, 14 Jul 2011 16:44:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.88.9 with HTTP; Thu, 14 Jul 2011 16:44:37 -0700 (PDT)
In-Reply-To: <4E1E62AB.2070608@gmail.com>
References: <4E15C895.6020701@gmail.com> <4E1B3270.40601@gmail.com>  <4E1E62AB.2070608@gmail.com>
From: Frank Ellermann 
Date: Fri, 15 Jul 2011 01:44:37 +0200
Message-ID: 
To: Mykyta Yevstifeyev 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Apps-discuss list 
Subject: Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2011 23:44:58 -0000

On 14 July 2011 05:29, Mykyta Yevstifeyev wrote:

> "@" is in , so we can safely assume that it won't
> apper anywhere else except the authority non-percent-encoded.

Quoting RFC 3986 section 3.3, page 23:

 segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
                   ; non-zero-length segment without any colon ":"

 pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"


That allows an unencoded '@' in the , not the '@' you are
interested in while trying to skip any @.

 query         = *( pchar / "/" / "?" )

Ditto, unencoded '@' in the  (section 3.4, page 24).

  fragment     = *( pchar / "/" / "?" )

Ditto, unencoded '@' in the  (section 3.5, page 24).


> it is also assumed that there will be no "@" chars before the
> "@" delimiting userinfo from host

ACK, all parts of the  including odd beasts such as
a  or  do not permit unencoded '@' (apart
from the @ case).

> So, "@" will normally occur only 1 time, and won't occur in
> the  itself, query or fragment identifier.

See above wrt , , and .  I recall that
it took me more than a year to grok the fine print in STD 66.

-Frank

From evnikita2@gmail.com  Thu Jul 14 20:43:48 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D11321F8753 for ; Thu, 14 Jul 2011 20:43:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.496
X-Spam-Level: 
X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.103,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 8PlAlm-MImFB for ; Thu, 14 Jul 2011 20:43:48 -0700 (PDT)
Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id CD91321F873D for ; Thu, 14 Jul 2011 20:43:47 -0700 (PDT)
Received: by fxe4 with SMTP id 4so2452519fxe.27 for ; Thu, 14 Jul 2011 20:43:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7iAXBzho2zNk6NoL6JbQc8XL/5pwVJUlCNDGVlj2YnU=; b=mNsjSAae9xvIcVIknAv6/PkZWsFRThtURD4XOHhRZhK+fg5VlSA/EC+A+7M5oc4NRo 44XMG+PrVzl0Ns0INi2KNPzTJgWT/MIw6vbGpFv6fS3AWqa/GfZ2Q1ZUtV9yvtq2bBKH PnuX5Q8f1S57vfT4Zt4nGT8B7LAsUUZXNwcNQ=
Received: by 10.223.57.5 with SMTP id a5mr4649652fah.90.1310701426992; Thu, 14 Jul 2011 20:43:46 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id q14sm504534faa.20.2011.07.14.20.43.45 (version=SSLv3 cipher=OTHER); Thu, 14 Jul 2011 20:43:46 -0700 (PDT)
Message-ID: <4E1FB79D.1020603@gmail.com>
Date: Fri, 15 Jul 2011 06:44:29 +0300
From: Mykyta Yevstifeyev 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Frank Ellermann 
References: <4E15C895.6020701@gmail.com> <4E1B3270.40601@gmail.com>  <4E1E62AB.2070608@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Apps-discuss list 
Subject: Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2011 03:43:48 -0000

15.07.2011 2:44, Frank Ellermann wrote:
> On 14 July 2011 05:29, Mykyta Yevstifeyev wrote:
>
>> "@" is in, so we can safely assume that it won't
>> apper anywhere else except the authority non-percent-encoded.
> Quoting RFC 3986 section 3.3, page 23:
>
>   segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
>                     ; non-zero-length segment without any colon ":"
>
>   pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
>
>
> That allows an unencoded '@' in the, not the '@' you are
> interested in while trying to skip any@.
>
>   query         = *( pchar / "/" / "?" )
>
> Ditto, unencoded '@' in the  (section 3.4, page 24).
>
>    fragment     = *( pchar / "/" / "?" )
>
> Ditto, unencoded '@' in the  (section 3.5, page 24).
I see what you mean.  I'll correct the expression as you proposed.  
However, I actually don't understand why "@" is either in , 
which is in  and doesn't allow it to be present in queries and 
fragments, and in , which is OK with this?
> [ . . . ]
> See above wrt,, and.  I recall that
> it took me more than a year to grok the fine print in STD 66.
Mykyta Yevstifeyev
>
> -Frank
>


From duerst@it.aoyama.ac.jp  Thu Jul 14 21:03:04 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84EC011E8070 for ; Thu, 14 Jul 2011 21:03:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.73
X-Spam-Level: 
X-Spam-Status: No, score=-99.73 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.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 ryRxlgrdGjF7 for ; Thu, 14 Jul 2011 21:03:04 -0700 (PDT)
Received: from acintmta02.acbb.aoyama.ac.jp (acintmta02.acbb.aoyama.ac.jp [133.2.20.34]) by ietfa.amsl.com (Postfix) with ESMTP id C1AE011E8077 for ; Thu, 14 Jul 2011 21:03:03 -0700 (PDT)
Received: from acmse01.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta02.acbb.aoyama.ac.jp (secret/secret) with SMTP id p6F42r2w004221 for ; Fri, 15 Jul 2011 13:02:53 +0900
Received: from (unknown [133.2.206.133]) by acmse01.acbb.aoyama.ac.jp with smtp id 23c5_2580_50497820_ae97_11e0_9574_001d096c5b62; Fri, 15 Jul 2011 13:02:53 +0900
Received: from [IPv6:::1] ([133.2.210.5]:39685) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Fri, 15 Jul 2011 13:02:56 +0900
Message-ID: <4E1FBBC2.4070303@it.aoyama.ac.jp>
Date: Fri, 15 Jul 2011 13:02:10 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Mykyta Yevstifeyev 
References: <4E15C895.6020701@gmail.com> <4E1B3270.40601@gmail.com>		<4E1E62AB.2070608@gmail.com>	 <4E1FB79D.1020603@gmail.com>
In-Reply-To: <4E1FB79D.1020603@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Apps-discuss list 
Subject: Re: [apps-discuss] Fwd: I-D Action:	draft-yevstifeyev-ftp-uri-scheme-04.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2011 04:03:04 -0000

Hello Mykyta,

On 2011/07/15 12:44, Mykyta Yevstifeyev wrote:
> 15.07.2011 2:44, Frank Ellermann wrote:

>> That allows an unencoded '@' in the, not the '@' you are
>> interested in while trying to skip any@.
>>
>> query = *( pchar / "/" / "?" )
>>
>> Ditto, unencoded '@' in the (section 3.4, page 24).
>>
>> fragment = *( pchar / "/" / "?" )
>>
>> Ditto, unencoded '@' in the (section 3.5, page 24).

> I see what you mean. I'll correct the expression as you proposed.
> However, I actually don't understand why "@" is either in ,
> which is in  and doesn't allow it to be present in queries and
> fragments, and in , which is OK with this?

It has to do with the fact that some software components processing URIs 
and their componests have no scheme-specific knowledge, whereas others 
do. Please read the text after the
     reserved    = gen-delims / sub-delims
ABNF rule in RFC 3986.

Regards,    Martin.

From evnikita2@gmail.com  Thu Jul 14 21:26:22 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD5C11E8077 for ; Thu, 14 Jul 2011 21:26:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.499
X-Spam-Level: 
X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 Nl8i9OPPzH-A for ; Thu, 14 Jul 2011 21:26:21 -0700 (PDT)
Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9A46822800E for ; Thu, 14 Jul 2011 21:26:21 -0700 (PDT)
Received: by fxe4 with SMTP id 4so2498500fxe.27 for ; Thu, 14 Jul 2011 21:26:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=8j5WahsempEaRIdBK2Y4EDyRQcoOBRvATvfFPH7F0eU=; b=GkqCMM75/GdHc/8V3IIySAi9FKbm0XcoDG9C9TN/z+qo+eTFBBLTBRBSKPqGHQDyH0 aYT/u9n2k4xQm1j765IobbTtYTo9pyM0qJRpwMJ7RTAEshnmgN2AOVUPF9QjGf9wcGSu 44C6CUrz8uihqpSo3zwD+rOnqWJr07V+RM7Bo=
Received: by 10.223.144.140 with SMTP id z12mr4671380fau.147.1310703971666; Thu, 14 Jul 2011 21:26:11 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id a18sm530968faa.6.2011.07.14.21.26.10 (version=SSLv3 cipher=OTHER); Thu, 14 Jul 2011 21:26:11 -0700 (PDT)
Message-ID: <4E1FC18F.7070500@gmail.com>
Date: Fri, 15 Jul 2011 07:26:55 +0300
From: Mykyta Yevstifeyev 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: iri@ietf.org
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Apps-discuss list 
Subject: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-iri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: iri@ietf.org
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2011 04:26:22 -0000

Hello,

I have uploaded the separate draft regarding i18n of 'ftp' URIs:

http://tools.ietf.org/html/draft-yevstifeyev-ftp-iri-00

It is a supplement to my other draft concerning 'ftp' URI scheme, and it 
intends to update it.  I'd like to ask people to comment the document.  
Please send your comments to iri@ietf.org.

Mykyta Yevstifeyev

P.S. If somebody if confused that I managed to upload the draft after 
cut-off date, I've already sent a message to tools-discuss list :-)  Mykyta

From evnikita2@gmail.com  Thu Jul 14 21:29:09 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FD1228011 for ; Thu, 14 Jul 2011 21:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.5
X-Spam-Level: 
X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 IS3Gr5DtdKIN for ; Thu, 14 Jul 2011 21:29:08 -0700 (PDT)
Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id A026E22800E for ; Thu, 14 Jul 2011 21:29:08 -0700 (PDT)
Received: by fxe4 with SMTP id 4so2501330fxe.27 for ; Thu, 14 Jul 2011 21:29:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=bRr2kM6zWtyvYarsBKXZXligz1sL5Ztz93Y0oKUJCDw=; b=vVzC12x0wekLnmwA4dPKiba23ZI3YHrzsYTIVdfNJmQGeXQS+yLa6Fj4bOR2cV4q3G tZaaBULeDMHkxwNY9WGeIoOfkZR7iiVTVs36WAkpBZDJX/CUS42B1w6BGcK222XtDiQC yxGFj8B80oIVUzjlIFsNEnLFsK7gwkc8JQq1Q=
Received: by 10.223.27.71 with SMTP id h7mr4658927fac.142.1310704147778; Thu, 14 Jul 2011 21:29:07 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id l12sm531003fam.32.2011.07.14.21.29.06 (version=SSLv3 cipher=OTHER); Thu, 14 Jul 2011 21:29:07 -0700 (PDT)
Message-ID: <4E1FC23F.3090302@gmail.com>
Date: Fri, 15 Jul 2011 07:29:51 +0300
From: Mykyta Yevstifeyev 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Apps-discuss list 
References: <4E1FC18F.7070500@gmail.com>
In-Reply-To: <4E1FC18F.7070500@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-iri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2011 04:29:09 -0000

15.07.2011 7:26, Mykyta Yevstifeyev wrote:
> Please send your comments to iri@ietf.org.
Sorry, public-iri@w3c.org.

Mykyta

From julian.reschke@gmx.de  Fri Jul 15 00:46:34 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D657121F872F for ; Fri, 15 Jul 2011 00:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.045
X-Spam-Level: 
X-Spam-Status: No, score=-104.045 tagged_above=-999 required=5 tests=[AWL=-1.446, BAYES_00=-2.599, 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 iENq-Fo6-cmK for ; Fri, 15 Jul 2011 00:46:30 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 48E8B21F8681 for ; Fri, 15 Jul 2011 00:46:30 -0700 (PDT)
Received: (qmail invoked by alias); 15 Jul 2011 07:46:26 -0000
Received: from p508FD5EC.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.213.236] by mail.gmx.net (mp020) with SMTP; 15 Jul 2011 09:46:26 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18fqOUD2UkfsNYw1gAky/UrQF3Z2lIjkfjFwpaGTf mnpi+wdDSmH9N2
Message-ID: <4E1FF039.20801@gmx.de>
Date: Fri, 15 Jul 2011 09:46:01 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Maile Ohye 
References: <4E083D3F.6030200@gmx.de> <4E0D3EA5.7010803@gmail.com> <4E0DCFEF.20206@gmx.de> <4E0DEA77.3050007@gmail.com> <4E0E0E76.2080007@gmail.com> <4E0E995A.7060800@gmail.com> <4E0F1058.3050201@gmail.com> <1309613470.2807.17.camel@mackerel> <4E0F1F2F.8020504@gmail.com>  <4E10208C.6090209@gmx.de>  <4E1818B9.8030804@gmx.de> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: "link-relations@ietf.org" , Joachim Kupke , IETF Apps Discuss , Bjartur Thorlacius 
Subject: Re: [apps-discuss] [link-relations] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2011 07:46:34 -0000

On 2011-07-15 09:29, Maile Ohye wrote:
> Hi everyone, thanks again for the feedback!
>
> Julian, MAY :) we submit a new draft with the changes discussed in this
> thread?

Hi Maile,

it's your draft, so it's your decision.

Internet Draft submission in theory is closed until 10 days from now - 
in practice it still seems to work.

> ...
> 15. OPEN. J. Reschke:
> o  Be the source URI of a 302, 303, or 307 redirect (Sections 10.3.3,
>      10.3.4, and 10.3.8, respectively, of [RFC2616]).
>
> Maybe "Be the source URI of a temporary redirect, such as..."?
> --response by M. Ohye Changed to
> Be the source URI of a temporary redirect. Using HTTP, this refers to
> status codes 302, 303, or 307 (Sections 10.3.3, 10.3.4, and 10.3.8,
> respectively, of ).
> Julian, please let me know if youd like this phased differently.
> ...

Sounds good.

> 16. OPEN. J. Reschke:
> may designate the canonical link relation in HTML as specified in [RFC5988]
> Why do we cite RFC 5988 here? Should this ref HTML?
> --response by M. Ohye Changed to:
> may designate the canonical link relation in HTML as specified in  target="RFC1866"/>
> I created this reference, but I couldnt find an organization or email
> address for Dan Connolly.
> 
> 
> Hypertext Markup Language - 2.0
> 
> MIT/W3C
> 
timbl@w3.org 

> 
> 
> 
> 
> 
> 
> 
> Julian, should I have done anything differently?
> ...

No, you need to cite W3C's HTML specs nowadays.

Either


   
     HTML 4.01 Specification
     
     
     
     
   
   
   
     Latest version available at
     .
   


for HTML4 or


   
     HTML5
     
     
   
   
   
     Latest version available at
     .
   


for the latest HTML5 Working Draft (see 
).

(I recommend HTML 4.01 because it's stable and the differences to HTML5 
do not matter here).


 > ...

Best regards, Julian

From evnikita2@gmail.com  Fri Jul 15 01:49:48 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFD621F87C9; Fri, 15 Jul 2011 01:49:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.501
X-Spam-Level: 
X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=0.097,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 n8g6iyn-DMh5; Fri, 15 Jul 2011 01:49:48 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id E452D21F87C7; Fri, 15 Jul 2011 01:49:46 -0700 (PDT)
Received: by eye13 with SMTP id 13so618724eye.31 for ; Fri, 15 Jul 2011 01:49:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=NZlexOgjUMN3z/fk6//b6fDo/WFW9Gr+fnzUqwiAD9o=; b=SB342UFIjhjqEfPg6pT+YZ+6Kp7JfLorhkoBRZwtqsP5jAem34Op4ncFZ6xJRqR66n gql1SwxWX4CBaUu9bN4zuNYqRKqcX05cSvOrdfxNHrK+OjicYKv9FMrcVko7xpYjMFnE baGM5YAaYiUqUzzFRxuZYaJIPLyjUso7vpbKI=
Received: by 10.213.17.210 with SMTP id t18mr116343eba.121.1310719785734; Fri, 15 Jul 2011 01:49:45 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id x3sm586673eem.66.2011.07.15.01.49.43 (version=SSLv3 cipher=OTHER); Fri, 15 Jul 2011 01:49:44 -0700 (PDT)
Message-ID: <4E1FFF53.2010108@gmail.com>
Date: Fri, 15 Jul 2011 11:50:27 +0300
From: Mykyta Yevstifeyev 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Maile Ohye 
References: <4E083D3F.6030200@gmx.de> <4E0D3EA5.7010803@gmail.com> <4E0DCFEF.20206@gmx.de> <4E0DEA77.3050007@gmail.com> <4E0E0E76.2080007@gmail.com> <4E0E995A.7060800@gmail.com> <4E0F1058.3050201@gmail.com> <1309613470.2807.17.camel@mackerel> <4E0F1F2F.8020504@gmail.com>  <4E10208C.6090209@gmx.de>  <4E1818B9.8030804@gmx.de> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080309000109020204090506"
Cc: Bjartur Thorlacius , Joachim Kupke , IETF Apps Discuss , "link-relations@ietf.org" 
Subject: Re: [apps-discuss] [link-relations] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2011 08:49:49 -0000

This is a multi-part message in MIME format.
--------------080309000109020204090506
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

15.07.2011 10:29, Maile Ohye wrote:
> Hi everyone, thanks again for the feedback!
>
> Julian, MAY :) we submit a new draft with the changes discussed in 
> this thread?
>
> Our comments to the open items are listed below (highlighted in 
> yellow). All comments for draft-00 are tracked in this doc:
> https://docs.google.com/document/d/1SkGEFKILZKTD6r9D2Oz76LwxuXbbqtRnWB7y2NTaDt8/edit?hl=en_US
>
> Thanks again,
> Maile
>
> [ . . . ]
>
> 4. OPEN. M. Yevstifeyev:
> > The canonical link relation specifies the preferred version of a URI
> [ . . . ]
> RFC 5988 [RFC5988] specified the mechanism which is used to indicate 
> relationships between the links on the Internet.  This document 
> defined a new type of such relationships - canonical link relation.
> in Section 1 as 1st para; other paragraphs retain in this case.
> --response by M. Ohye We researched other RFCs and it seems best to 
> start the abstract with the main subject, such as for DC1:
> The Dublin Core [DC1] is a small set of metadata elements for 
> describing information resources.
> or for HTML:
> The Hypertext Markup Language (HTML) is a simple markup language used...
> so wed prefer to start with a mention of the canonical link relation 
> and reference RFC5988 following the initial mention.
> The canonical link relation, developed from  
> which indicates relationships between Internet links, specifies the 
> preferred URI from a set of identical or vastly similar content 
> accessible on multiple URIs.
I don't strongly insist on any of such text, but I personally think what 
I proposed is better.  Yet, please feel free to include what you 
personally want.
>
> Then, similar to the first paragraph of Section 10.3.2 of RFC 2616:
>
> This designation MAY be used for future references to this resource, 
> and clients with link editing capabilities MAY automatically re-link 
> references to the context URI to the designated URI."
>
> 5. CLOSED. M. Yevstifeyev:
> > Presence of the canonical link relation indicates to applications, 
> such as search engines, that they MAY:
> [ . . . ]
> --response by M. Ohye Left as MAY in the draft, but further debate 
> welcomed.
I'd better use non-normative "should" or "can" here rather than RFC 2119 
language, as proposed by Julian.
>
> 7. OPEN. M. Yevstifeyev:
>   o Exist on a different protocol: http to https, or vice versa
> [ . . . ]
> --response by M. Ohye Changed the draft to:
> The target/canonical URI MAY:
> * Have different scheme names: such as HTTP to HTTPS, or gopher to FTP
This is an editorial comment.  RFC 3986 recommends that scheme names are 
present in lowercase.  Moreover, it would be better to enclose the 
scheme names in the quotes, to distinguish them from other text.
>
> 8. OPEN. M. Yevstifeyev:
> Reading section 3 and 5 of the draft, it seems that is mandates use of 
> HTTP when referring to canonical URIs.  And what is the situation when 
> target URI is a 'ftp' or 'gopher' URI?
>
> [ . . . ]
>
> --response by M. Ohye Given Julians comments in #15 below, and M. 
> Yevstifeyevs original concern of being too HTTP specific, this now reads:
> Be the source URI of a temporary redirect. For HTTP, this refers to 
> status codes 302, 303, or 307 (Sections 10.3.3, 10.3.4, and 10.3.8, 
> respectively, of ).
This looks reasonable.
>
> [ . . .]
>
> 16. OPEN. J. Reschke:
> may designate the canonical link relation in HTML as specified in 
> [RFC5988]
> [ . . . ]
> Julian, should I have done anything differently?
+1 to Julian's response to this.  RFC 1866 (and all other HTML-related 
stuff) was removed from Standards Track and is now Historic (except RFC 
2854).

Mykyta
>
> [ . . . ]


--------------080309000109020204090506
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    15.07.2011 10:29, Maile Ohye wrote:
    
Hi everyone, thanks again for the feedback!
      


      

      
Julian, MAY :) we submit a new draft with the changes
        discussed in this thread?
        


        

        
Our comments to the open items are listed below
          (highlighted in yellow). All comments for draft-00 are tracked
          in this doc:

        
        


        

        
Thanks again,

        
Maile

        


        

        

          
          

                
                

                  [ . . . ]

              

        

        

            

              

              

            

                
                

                  4. OPEN. M. Yevstifeyev:

                  > The canonical link relation
                    specifies the preferred version of a URI

                  [ . . . ]

                  RFC 5988 [RFC5988]
                    specified the mechanism which is used to indicate
                    relationships between the links on the Internet.
                    This document defined a new type of such
                    relationships - canonical link relation.

                  in Section 1 as 1st para;
                    other paragraphs retain in this case.

                  --response by M. Ohye We
                    researched other RFCs and it seems best to start the
                    abstract with the main subject, such as for DC1:

                  The Dublin Core [DC1] is a
                    small set of metadata elements for describing
                    information resources.

                  or for HTML:

                  The Hypertext Markup
                    Language (HTML) is a simple markup language used...

                  so wed prefer to start
                    with a mention of the canonical link relation and
                    reference RFC5988 following the initial mention.

                  The canonical link
                    relation, developed from <xref
                    target="RFC5988"/> which indicates relationships
                    between Internet links, specifies the preferred URI
                    from a set of identical or vastly similar content
                    accessible on multiple URIs.

                

              

          

      

    

    I don't strongly insist on any of such text, but I personally think
    what I proposed is better. Yet, please feel free to include what
    you personally want.

    

      

        

            

                

                  

                  Then, similar to the first
                    paragraph of Section 10.3.2 of RFC 2616:

                  

                  This designation MAY be
                    used for future references to this resource, and
                    clients with link editing capabilities MAY
                    automatically re-link references to the context URI
                    to the designated URI."

              

          

        


          

        

          
          
5.
              CLOSED. M. Yevstifeyev:

            >
            Presence
              of the canonical link relation indicates to applications,
              such as search engines, that they MAY:

            [
              . . . ]

            --response
              by M. Ohye Left as MAY in the draft, but further debate
              welcomed.

        

      

    

    I'd better use non-normative "should" or "can" here rather than RFC
    2119 language, as proposed by Julian.

    

      

        

          


          

          

            
            
7. OPEN. M. Yevstifeyev:

               o Exist on a different protocol:
                http to https, or vice versa

              [ . . . ]

              --response by M. Ohye Changed
                the draft to:

              The target/canonical URI MAY:

              * Have different scheme names:
                such as HTTP to HTTPS, or gopher to FTP

          

        

      

    

    This is an editorial comment. RFC 3986 recommends that scheme names
    are present in lowercase. Moreover, it would be better to enclose
    the scheme names in the quotes, to distinguish them from other text.

    

      

        

          

          

          


          

          
          

                
                

                  8. OPEN. M. Yevstifeyev:

                  Reading section 3 and 5 of
                    the draft, it seems that is mandates use of HTTP
                    when referring to canonical URIs. And what is the
                    situation when target URI is a 'ftp' or 'gopher'
                    URI? 

                    

                    [ . . . ]

                  

                  --response by M. Ohye
                    Given Julians comments in #15 below, and M.
                    Yevstifeyevs original concern of being too HTTP
                    specific, this now reads:

                  Be the source URI of a
                    temporary redirect. For HTTP, this refers to status
                    codes 302, 303, or 307 (Sections 10.3.3, 10.3.4, and
                    10.3.8, respectively, of <xref
                    target="RFC2616"/>).

              

        

      

    

    This looks reasonable.

    

      

        

          

              

          

              

                

                

              

                  
                  

                    [ . . .]

                    

                    16. OPEN. J. Reschke:

                    may designate the
                      canonical link relation in HTML as specified in
                      [RFC5988]

                    [ . . . ]

                    Julian,
                      should I have done anything differently?

                  

                

            

        

      

    

    +1 to Julian's response to this. RFC 1866 (and all other
    HTML-related stuff) was removed from Standards Track and is now
    Historic (except RFC 2854). 

    

    Mykyta

    

      

        

          

              

                  

                    

                    [ . . . ]

                    

                

            

        

      

    

    

  


--------------080309000109020204090506--

From barryleiba.mailing.lists@gmail.com  Fri Jul 15 05:28:59 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F7B21F86E9 for ; Fri, 15 Jul 2011 05:28:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.113
X-Spam-Level: 
X-Spam-Status: No, score=-103.113 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 UystrBANB+GX for ; Fri, 15 Jul 2011 05:28:59 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E047221F862E for ; Fri, 15 Jul 2011 05:28:58 -0700 (PDT)
Received: by gyd5 with SMTP id 5so574263gyd.31 for ; Fri, 15 Jul 2011 05:28:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=HveE6A3IKk/zFLLEUyzrvOOCmDJEP8vPCrFnBAPP60Q=; b=OtWbssO4MLvxCmZghG5AOKA5XM6ATwzqnfnlNscJjj6HxhbEk8uo35rckb4ozhmEe6 shcXgT5RsQknxEB656QIHJiBz3yj2eIJQGWc/sHTK4VzuVT8GggnlBtWPtBOH4m2m66o rd5VNKB17IPNyzTPRjjx7RMiCm0x3MGAT3MSM=
MIME-Version: 1.0
Received: by 10.150.31.20 with SMTP id e20mr3330041ybe.62.1310732936796; Fri, 15 Jul 2011 05:28:56 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.172.10 with HTTP; Fri, 15 Jul 2011 05:28:56 -0700 (PDT)
In-Reply-To: 
References: <4E1395BD.4080405@stpeter.im>  
Date: Fri, 15 Jul 2011 08:28:56 -0400
X-Google-Sender-Auth: 5C6TQzdBR6qoiVnm8NKLmZxq4nA
Message-ID: 
From: Barry Leiba 
To: "apps-discuss@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [apps-discuss] AppsArea topics for IETF81
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2011 12:28:59 -0000

We now have a final agenda for the AppsAWG/AppsArea meeting.  Note
that because of scheduling issues, the meeting will be on Thursday
afternoon from 1520 to 1720 EDT -- not in the usual Monday morning
slot.  That also means it's 2 hours, rather than the original 2:30.
The agenda:

   http://www.ietf.org/proceedings/81/agenda/appsawg.txt

...is very full, and agenda time is tight.  We absolutely need all
presentation slides by the deadline (end of day on Saturday, 23 July;
see the agenda), and we'll be doing tight time management.  If we
don't have slides from you (or a confirmation that you won't be using
slides), we'll remove the item from the agenda and give the time back
to items we've had to shorten.  Please keep your slides and your
presentations brief and to the point, and let's have the time to have
the necessary discussions.

Because of the short time, we'll only be able to give the briefest
overviews of the documents under discussion.  Please read them in
advance -- there are links in the agenda.  Again, the priority is on
discussion, not presentation.

Barry, appsawg chair

From maileko@gmail.com  Fri Jul 15 00:29:55 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51ACB21F85E8; Fri, 15 Jul 2011 00:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.974
X-Spam-Level: 
X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=0.024,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-1]
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 qaWmK03By8zO; Fri, 15 Jul 2011 00:29:50 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6224421F85B9; Fri, 15 Jul 2011 00:29:50 -0700 (PDT)
Received: by pvh18 with SMTP id 18so1302499pvh.31 for ; Fri, 15 Jul 2011 00:29:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9BZN4b/ss2Z9WfeDLASDucidfoNypnIfWpvKYStLo30=; b=IQ+NZNuVzXyC7RuJr3tPjvZ93jzk8Yo6+UVDrJJknEPihtdyewijyoYf7OoF6cJ+fa Dvn0YCuv6DztNjBVp5ausITKVdwmn5FhFnJ1//7mt5VGTbDRz/2XM1SIsrKLbPLMZHcZ 2WDsOcUY270v7bEchWFx9ilPTX5tXpnagsbBk=
MIME-Version: 1.0
Received: by 10.68.66.130 with SMTP id f2mr3586040pbt.521.1310714989612; Fri, 15 Jul 2011 00:29:49 -0700 (PDT)
Received: by 10.68.47.70 with HTTP; Fri, 15 Jul 2011 00:29:49 -0700 (PDT)
In-Reply-To: <4E1818B9.8030804@gmx.de>
References: <4E083D3F.6030200@gmx.de> <4E0D3EA5.7010803@gmail.com> <4E0DCFEF.20206@gmx.de> <4E0DEA77.3050007@gmail.com> <4E0E0E76.2080007@gmail.com> <4E0E995A.7060800@gmail.com> <4E0F1058.3050201@gmail.com> <1309613470.2807.17.camel@mackerel> <4E0F1F2F.8020504@gmail.com>  <4E10208C.6090209@gmx.de>  <4E1818B9.8030804@gmx.de>
Date: Fri, 15 Jul 2011 00:29:49 -0700
Message-ID: 
From: Maile Ohye 
To: Julian Reschke 
Content-Type: multipart/alternative; boundary=bcaec544eee65b906c04a8169db0
X-Mailman-Approved-At: Fri, 15 Jul 2011 08:02:19 -0700
Cc: "link-relations@ietf.org" , Joachim Kupke , IETF Apps Discuss , Bjartur Thorlacius 
Subject: Re: [apps-discuss] [link-relations] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2011 07:29:55 -0000

--bcaec544eee65b906c04a8169db0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi everyone, thanks again for the feedback!

Julian, MAY :) we submit a new draft with the changes discussed in this
thread?

Our comments to the open items are listed below (highlighted in yellow). Al=
l
comments for draft-00 are tracked in this doc:
https://docs.google.com/document/d/1SkGEFKILZKTD6r9D2Oz76LwxuXbbqtRnWB7y2NT=
aDt8/edit?hl=3Den_US

Thanks again,
Maile

2. OPEN. F. Ellermann:
The draft could s/SHOULD NOT/MUST NOT/, I don't see any good reason
to violate a SHOULD NOT, and if that's correct MUST NOT is clearer.
--seconded by M. Yevstifeyev
--response by M. Ohye and J. Kupke: =93We prefer SHOULD NOT for a few reaso=
ns.
1) If we outlawed multiple canonicals using MUST NOT, we would effectively
call the HTML invalid. In reality, the HTML will still be processed, though
it=92s likely that search engines will ignore both/all rel=3Dcanonicals. 2)
Worse, for the cases where somebody might rel=3Dcanonical to a 404, etc., i=
f
we use MUST NOT, it would place a huge (and entirely unrealistic) burden on
the site owner to ensure that search engines recrawl pages in such an order
that all rel=3Dcanonical sources are updated before a page may become a 404=
.=94
--response by J. Reschke =93I'm not sure I understand the response. Is ther=
e a
use case where an author would legitimately add multiple instances of the
link relation?=94
--response by J. Kupke =93It is quite conceivable that an author might want=
 to
designate
multiple instances of the relation with different attributes, e.g.:


It is recommended not to do that because it would foist additional
complexity on implementations, and---without being presumptuous---it appear=
s
that encoding attributes such as media into the URI itself can do more harm
than good.
This recommendation might become less valid over time.  For example, it has
become rather common to encode the language (or country) of a resource into
the URI when there would have been other means of their designation as well
(such as, the Accept-Language HTTP header).=94
--response by F. Ellermann =93If you are very sure that violations of the
SHOULD NOT are only *ignored* I'm fine with it.  But search engines could
also treat violations as some kind of "link farming" and punish authors for
their intended or unintended violations.

In that case authors would be better off with a MUST NOT clearly indicating
that it is their own fault if they get rel=3D"canonical" wrong -- after all
they are not forced to use rel=3D"canonical".

IOW, if you have "only" a SHOULD NOT for publishers you might need a
corresponding "MUST ignore violations" for web crawlers.=94
--response by M. Ohye =93In the new introduction, we=92d like to state:
The canonical link relation specifies the preferred URI from a set of
identical or vastly similar content accessible on multiple URIs. This
designation MAY be used for future references to this resource, and clients
with link editing capabilities MAY automatically re-link references to the
context URI to the designated URI...

As we=92re using =93MAY=94 in the introduction, to later dictate search eng=
ine
behavior with =93you MUST ignore violations,=94 seems like it would be very
strong language.
--response by F. Ellermann with regard to M. Ohye=92s [Worse, for the cases
where somebody might rel=3Dcanonical to a 404, etc., if we use MUST NOT, it
would place a huge (and entirely unrealistic) burden on the site owner to
ensure that search engines recrawl pages in such an order that all
rel=3Dcanonical sources are updated before a page may become a 404.]

=93Ugh.  A typical use case is a simple site with a mirror, in that case a =
404
should be temporary:  New pages on the mirror(s) not yet available under
their canonical URL, or old pages deleted under their canonical URL still
found on the mirror(s).
You are right, a MUST NOT does not fly for this scenario.=94
--response by M. Ohye =93We=92d like to leave this as SHOULD NOT.=94 Please=
 let us
know if you have further arguments.

4. OPEN. M. Yevstifeyev:
> The canonical link relation specifies the preferred version of a URI
I think some introductory text on linking, probably based on RFC 5988,
should go here.
--response by J. Reschke "Why? It defines a link relation as defined by RFC
5988, so why repeat text from over there?"
--response by M. Yevstifeyev "It should be mentioned (1) what is link
relation at all and (2) that RFC 5988 is a specification of that technology
which this document depends on.  RFC 5988 is first mentioned in Examples."
--response by M. Ohye. =93We could modify to:
=93The canonical link relation (Link Relation Types reference ) specifies the preferred version of a URI...=94
--response by J. Reschke =93+1=94
--response by M. Yevstifeyev =93I proposed to add something like:
RFC 5988 [RFC5988] specified the mechanism which is used to indicate
relationships between the links on the Internet.  This document defined a
new type of such relationships - canonical link relation.
in Section 1 as 1st para; other paragraphs retain in this case.=94
--response by M. Ohye =93We researched other RFCs and it seems best to star=
t
the abstract with the main subject, such as for DC1:
=91The Dublin Core [DC1] is a small set of metadata elements for describing
information resources.=92
or for HTML:
=91The Hypertext Markup Language (HTML) is a simple markup language used...=
=94
so we=92d prefer to start with a mention of the canonical link relation and
reference RFC5988 following the initial mention.
The canonical link relation, developed from  whic=
h
indicates relationships between Internet links, specifies the preferred URI
from a set of identical or vastly similar content accessible on multiple
URIs.

Then, similar to the first paragraph of Section 10.3.2 of RFC 2616:

This designation MAY be used for future references to this resource, and
clients with link editing capabilities MAY automatically re-link references
to the context URI to the designated URI."

5. CLOSED. M. Yevstifeyev:
> Presence of the canonical link relation indicates to applications, such a=
s
search engines, that they MAY:
I wonder why it's MAY; in this case implementations (explicitly, those apps
which interpret Link: headers and corresponding construction in HTML) will
be free to ignore it.  I think normative SHOULD should be OK (sorry for
pun).
--response by J. Reschke "I think this link relation is purely advisory, so
a better approach might be to replace "MAY" by "can"."
--response by M. Yevstifeyev "Yes, advisory, which suits RFC 2119 definitio=
n
for SHOULD: 'SHOULD   This word, or the adjective "RECOMMENDED", mean that
there may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and carefully
weighed before choosing a different course.'
and natural meaning of should - advice/recommendation."
--response by M. Ohye =93Thanks, in discussion with Joachim Kupke.=94
--response by J. Reschke =93No, it's really not a SHOULD.=94
--response by J. Kupke =93Reading paragraph 5 of RFC 2119, I don't see
anything wrong with
=91MAY.=92  How is =91can=92 better? It's indeed not a =91SHOULD=92 since a=
 typical
implementation, say in a search engine, will want to go to some length to
find evidence for misguided usage of the relationship and in the presence o=
f
such evidence decide to ignore it.  The point of =91MAY=92 is to make clear=
 that
in the absence of such evidence, the responsibility not to advertise an
erroneous =91canonical=92 relationship lies with the author of the context =
URI.=94
--response by J. Reschke =93See RFC 2119, Section 6:

6. Guidance in the use of these Imperatives

 Imperatives of the type defined in this memo must be used with care

 and sparingly.  In particular, they MUST only be used where it is

 actually required for interoperation or to limit behavior which has

 potential for causing harm (e.g., limiting retransmisssions)  For

 example, they must not be used to try to impose a particular method

 on implementors where the method is not required for

 interoperability.

So my recommendation is NOT to use these kinds of keywords unless when
needed as described above (but I realize that many people disagree with
me...)
--response by M. Ohye =93Left as =91MAY=92 in the draft, but further debate
welcomed.=94

7. OPEN. M. Yevstifeyev:
  o  Exist on a different protocol: http to https, or vice versa
You probably meant URI scheme here, since https isn't a separate protocol.
 As before these points we had "The value of the target/canonical URI MAY"
or, if you consider my comment above, "The target/canonical URI MAY", this
point may be reworded as "Have different scheme names" (which suits the
second variant of a preface to this list better).
--agreed by J. Reschke
--response by M. Ohye/J. Kupke: =93Good catch, Mykyta. We=92re fine to chan=
ge
the draft to =93scheme=94:
Have different scheme names: such as http to https, or vice versa
Do we now need to expand the draft for ftp:// and gopher:// URIs? For
example, ftp:// and gopher:// URIs=94
1) Do not come with the equivalent of RFC 5988, so a non-HTML document
available at any such URI won't be available to make use of .
2) Have corresponding GOPHER error code (item type 3) or an FTP error 550,
which like HTTP 404, is forbidden from being served for the target of a
.
--response by M. Yevstifeyev =93I don't think we should make such changes. =
 If
we consider ftp and gopher URIs, we should also consider all other.  I
proposed to add generic statements which would be applicable to almost all
application protocols, not only HTTP, as in current version of the draft.=
=94
--response by J. Reschke =93a) A non-HTML document at a non-HTTP(s) URI may
not be able to specify the link relation, but it could be the target of a
link, relation, right? (that could be an example)
--response by J. Kupke =93Correct.=94
b) Future protocols might have other means to specify a link relation, btw.=
=94

--response by J. Kupke =93Is there terminology that reasonably unifies erro=
rs
across protocols (HTTP response code 4xx, GOPHER item type 3, FTP response
code 5xx)?=94

--response by J. Reschke =93I don't think so...=94
--response by M. Ohye =93Changed the draft to:
The target/canonical URI MAY:
* Have different scheme names: such as HTTP to HTTPS, or gopher to FTP

8. OPEN. M. Yevstifeyev:
Reading section 3 and 5 of the draft, it seems that is mandates use of HTTP
when referring to canonical URIs.  And what is the situation when target UR=
I
is a 'ftp' or 'gopher' URI?  Section 3 allows different scheme names in
context/target URIs, if I understand it correctly.  Therefore, unless it is
deliberately, I think any mention of HTTP should be replaced by more generi=
c
regulations.
--response by J. Reschke "Nope; I think the HTTP examples are very useful.
But maybe we can have an additional statement that the link relation isn't
specific to HTTP."
--response by M. Yevstifeyev "Currently we have normative reference to RFC
2616 and normative requirements with respect to HTTP.  HTTP examples are OK=
;
but it's redundant in Section 3.  I suppose in Section 3 we may replace
HTTP-related stuff with something in the way like:

Old:
  o  The source URI of a "300 Multiple Choices" URI (Section 10.3.1 of
     [RFC2616]) or a permanent redirect (Section 10.3.2 of [RFC2616]).
New:
  o  The source URI, which defines a resource which provides choice
     in different represntations of a given resource, ientified by
     the context URI, or is a link which has been permanently replaced
     by an other one.
etc."
--response by B. Thorlacius: =93Your wording seems overly confusing. Which =
is
the resource that "provides choice in different represntations of a given
resource?" A standard could be assigned the URI .
An HTTP GET /spec might be responded with an HTTP/1.1 300 choice, and an
entity linking to /spec.node.html, /spec.html, /spec.pdf, and /spec.txt. Th=
e
resource (the standard, that is) would in no way provide this choice. The
HTTP server simply offered multiple representations.=94
--response by M. Yevstifeyev: =93First, this was an example only.  Next, my
point was that the document makes HTTP/'http' scheme mandatory in
context/target URIs, which I don't think is appropriate, since canonical UR=
I
may refer to a resource accessible via other protocol.  Even though HTTP is
going to be the most often use case of canonical link relation, we shouldn'=
t
exclude other protocols.=94
--response by B. Thorlacius: =93I agree. However, I don't understand the ne=
ed
for forbidding canonical links to resources with multiple representations.
Are there not to be canonical links from representations of a resource to
the resource (i.e. from /spec.html and /spec.txt to /spec)?=94
--response by M. Yevstifeyev: =93Probably such restriction is set because
multiple representation choice may ultimately refer the user to a resource
which is not canonical.  A _definite_ canonical resource is necessary and
required.=94

----response by  J. Cormack: =93I think this relation (which is useful) nee=
d
to be called something

else, as it is performing a different function to canonical, which is

about relations between representations of resources, rather than

between representations of resources and a the resource itself

like /spec.

There does seem to not be a discussion of what is similar though in

terms of media types - is /spec.txt similar enough that /spec.html could

be a canonical link? One could certainly have a PNG version of an SVG

image with a canonical link I would presume.=94

------response by  M. Yevstifeyev: =93I personally think it is possible.  F=
or
example, authoritative RFC source is .txt file on RFC Editor's site, while
we have a number of other sources for RFCs, not in .txt, such as "
tools.ietf.org/html/rfcXXXX" in HTML.  Designating a "canonical" link to "
http://www.rfc-editor.org/rfc/rfcXXXX.txt" seems to be OK.  So I think we
have no problem here.=94
--response by M. Ohye: =93We can change the draft to include corresponding
GOPHER or FTP error codes to demonstrate non-favortism to HTTP.=94
--response by M. Yevstifeyev =93I don't think it would be useful (see above=
).
 It's better, as I've already mentioned in my response to (7), to provide
rules which would be fine for almost any application protocol and which
would be equivalent to those provided for HTTP now.  For example:

OLD: =93Be the source URI of a 302, 303, or 307 redirect (Sections 10.3.3,
10.3.4, and 10.3.8, respectively, of [RFC2616])."
NEW: "Provide a redirect to the other resource because it is temporarily
unavailable."

This is what HTTP 302 and 307 responses stand for.  303 response is used in
HTTP only and here is no equivalent to it in other protocols.=94
--response by J. Reschke =93...my general feeling here is that having speci=
fic
HTTP examples is good, as long as the spec doesn't make the reader think
it's the only protocol that qualifies.=94
--response by M. Ohye =93Given Julian=92s comments in #15 below, and M.
Yevstifeyev=92s original concern of being too HTTP specific, this now reads=
:
Be the source URI of a temporary redirect. For HTTP, this refers to status
codes 302, 303, or 307 (Sections 10.3.3, 10.3.4, and 10.3.8, respectively,
of ).

10. OPEN. J. Reschke:
This specification defines the canonical link relation -- an element which
designates the preferred version of content/URI from a set of duplicate or
near duplicate pages.
Maybe put "canonical" in double quotes? (similar in other places)
--response by M. Ohye =93How adamant are you about double quoting =93canoni=
cal=94
in =93canonical link relation=94 throughout the draft? That=92s a lot of do=
uble
quotes (18 of them :). I think these double quotes would be more distractin=
g
than helpful, but if that=92s how other RFCs are written, we=92ll certainly
reconsider.=94

11. CLOSED. J. Reschke:
The canonical link relation specifies the preferred version of a URI from a
set of identical or vastly similar content that may be
maybe just "preferred URI"?
--response by M. Ohye =93Changed. Here=92s the new abstract:
The canonical link relation, developed from  whic=
h
indicates relationships between Internet links, specifies the preferred URI
from a set of identical or vastly similar content accessible on multiple
URIs.

12. CLOSED. J. Reschke:
The canonical (target URI) MUST contain content that duplicates
"canonical (target) URI MUST identify content" (it's not the content of the
URI, it's the content of the identified resource)
--response by M. Ohye =93Updated in draft.=94

13. CLOSED. J. Reschke
extremely similar, or is a superset of the content in the context
s/in/at/:
--response by M. Ohye =93Updated in draft.=94

14. OPEN. J. Reschke:
The value of the target/canonical URI MAY:

 o  Be self-referential (context URI identical to target URI)

 o  Specify a relative or absolute URI

"Specify a URI Reference (see [RFC3986], Section 4.1), i.e., a full URI or =
a
relative reference=94
--response by M. Ohye =93How about the edit below?
Specify a URI Reference (see [RFC3986], Section 4.1), i.e., an absolute URI
or a relative reference

15. OPEN. J. Reschke:
o  Be the source URI of a 302, 303, or 307 redirect (Sections 10.3.3,
    10.3.4, and 10.3.8, respectively, of [RFC2616]).

Maybe "Be the source URI of a temporary redirect, such as..."?
--response by M. Ohye =93Changed to
Be the source URI of a temporary redirect. Using HTTP, this refers to statu=
s
codes 302, 303, or 307 (Sections 10.3.3, 10.3.4, and 10.3.8, respectively,
of ).
Julian, please let me know if you=92d like this phased differently.

16. OPEN. J. Reschke:
may designate the canonical link relation in HTML as specified in [RFC5988]
Why do we cite RFC 5988 here? Should this ref HTML?
--response by M. Ohye =93Changed to:
may designate the canonical link relation in HTML as specified in 
I created this reference, but I couldn=92t find an organization or email
address for Dan Connolly.

 
   Hypertext Markup Language - 2.0
   
     MIT/W3C
     
timbl@w3.org

   
   
   
   
 
 

Julian, should I have done anything differently?

17. CLOSED. J. Reschke:

 or alternatively, in the HTTP Header as specified in Section 5 of
 [RFC5988]:
s/Header/header field/
--response by M. Ohye =93Updated in the draft.=94

18. CLOSED. J. Reschke:
Recommendations
Before implementing the canonical link relation, verification of the

Maybe s/implementing/adding/?
--response by M. Ohye =93Updated in the draft.=94


On Sat, Jul 9, 2011 at 2:00 AM, Julian Reschke 
wrote:
> On 2011-07-09 04:44, Joachim Kupke wrote:
>>
>> ...
>>>>
>>>> 5. OPEN. M. Yevstifeyev:
>>>>>
>>>>>  Presence of the canonical link relation indicates to applications,
>>>>
>>>> such as search engines, that they MAY:
>>>> I wonder why it's MAY; in this case implementations (explicitly, those
>>>> apps which interpret Link: headers and corresponding construction in
>>>> HTML) will be free to ignore it.  I think normative SHOULD should be O=
K
>>>> (sorry for pun).
>>>> --response by J. Reschke "I think this link relation is purely
advisory,
>>>> so a better approach might be to replace "MAY" by "can"."
>>
>> Reading paragraph 5 of RFC 2119, I don't see anything wrong with
>> "MAY."  How is "can" better?
>> ...
>
> See RFC 2119, Section 6:
>
>> 6. Guidance in the use of these Imperatives
>>
>>   Imperatives of the type defined in this memo must be used with care
>>   and sparingly.  In particular, they MUST only be used where it is
>>   actually required for interoperation or to limit behavior which has
>>   potential for causing harm (e.g., limiting retransmisssions)  For
>>   example, they must not be used to try to impose a particular method
>>   on implementors where the method is not required for
>>   interoperability.
>
> So my recommendation is NOT to use these kinds of keywords unless when
> needed as described above (but I realize that many people disagree with
> me...)
>
>> ...
>>>
>>> b) Future protocols might have other means to specify a link relation,
>>> btw.
>>
>> Is there terminology that reasonably unifies errors across protocols
>> (HTTP response code 4xx, GOPHER item type 3, FTP response code 5xx)?
>> ...
>
> I don't think so...
>
> Best regards, Julian
>

--bcaec544eee65b906c04a8169db0
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi everyone, thanks again for the feedback!=A0

Julian, M=
AY :) we submit a new draft with the changes discussed in this thread?
=

Our comments to the open items are listed below (highlighted=
 in yellow). All comments for draft-00 are tracked in this doc:




Thanks again,
Maile


2. OPEN. F. Ellermann:

T=
he draft could s/SHOULD NOT/MUST NOT/, I don't see any good reason

t=
o violate a SHOULD NOT, and if that's correct MUST NOT is clearer.

-=
-seconded by M. Yevstifeyev

-=
-response by M. Ohye and J. Kupke: =93We prefer SHOULD NOT for a few reason=
s. 1) If we outlawed multiple canonicals using MUST NOT, we would effective=
ly call the HTML invalid. In reality, the HTML will still be processed, tho=
ugh it=92s likely that search engines will ignore both/all rel=3Dcanonicals=
. 2) Worse, for the cases where somebody might rel=3Dcanonical to a 404, et=
c., if we use MUST NOT, it would place a huge (and entirely unrealistic) bu=
rden on the site owner to ensure that search engines recrawl pages in such =
an order that all rel=3Dcanonical sources are updated before a page may bec=
ome a 404.=94

-=
-response by J. Reschke =93I'm not sure I understand the response. Is t=
here a use case where an author would legitimately add multiple instances o=
f the link relation?=94

-=
-response by J. Kupke =93It is quite conceivable that an author might want =
to designate

m=
ultiple instances of the relation with different attributes, e.g.:
&=
lt;link rel=3D"canonical" href=3D"http://en.wikipedia.org/wiki/Random=
ness" media=3D"screen"/>

&=
lt;link rel=3D"canonical" href=3D"http://en.m.wikipedia.org/wiki/Ra=
ndomness" media=3D"handheld"/>

I=
t is recommended not to do that because it would foist additional complexit=
y on implementations, and---without being presumptuous---it appears that en=
coding attributes such as media into the URI itself can do more harm than g=
ood.

T=
his recommendation might become less valid over time. =A0For example, it ha=
s become rather common to encode the language (or country) of a resource in=
to the URI when there would have been other means of their designation as w=
ell (such as, the Accept-Language HTTP header).=94

-=
-response by F. Ellermann =93If you are very sure that violations of the SH=
OULD NOT are only *ignored* I'm fine with it. =A0But search engines cou=
ld also treat violations as some kind of "link farming" and punis=
h authors for their intended or unintended violations.

<=
/span>

I=
n that case authors would be better off with a MUST NOT clearly indicating =
that it is their own fault if they get rel=3D"canonical" wrong --=
 after all they are not forced to use rel=3D"canonical".
<=
/span>

I=
OW, if you have "only" a SHOULD NOT for publishers you might need=
 a corresponding "MUST ignore violations" for web crawlers.=94

--response by M. Ohye =93In the new introduction, we=92d like to stat=
e:

The canonical link relation specifies the preferred URI from a set of=
 identical or vastly similar content accessible on multiple URIs. This desi=
gnation MAY be used for future references to this resource, and clients wit=
h link editing capabilities MAY automatically re-link references to the con=
text URI to the designated URI...



As we=92re using =93MAY=94 in the introduction, to later dictate sear=
ch engine behavior with =93you MUST ignore violations,=94 seems like it wou=
ld be very strong language.

-=
-response by F. Ellermann with regard to M. Ohye=92s [Worse, for the cases =
where somebody might rel=3Dcanonical to a 404, etc., if we use MUST NOT, it=
 would place a huge (and entirely unrealistic) burden on the site owner to =
ensure that search engines recrawl pages in such an order that all rel=3Dca=
nonical sources are updated before a page may become a 404.]

<=
/span>

=
=93Ugh. =A0A typical use case is a simple site with a mirror, in that case =
a 404 should be temporary: =A0New pages on the mirror(s) not yet available =
under their canonical URL, or old pages deleted under their canonical URL s=
till found on the mirror(s).

Y=
ou are right, a MUST NOT does not fly for this scenario.=94

--response by M. Ohye =93We=92d like to leave this as SHOULD NOT.=94 =
Please let us know if you have further arguments.







4. OPEN. M. Yevstifeyev:

&=
gt; The canonical link relation specifies the preferred version of a =
URI

I=
 think some introductory text on linking, probably based on RFC 5988, shoul=
d go here.

-=
-response by J. Reschke "Why? It defines a link relation as defined by=
 RFC 5988, so why repeat text from over there?"

-=
-response by M. Yevstifeyev "It should be mentioned (1) what is link r=
elation at all and (2) that RFC 5988 is a specification of that technology =
which this document depends on. =A0RFC 5988 is first mentioned in Examples.=
"

-=
-response by M. Ohye. =93We could modify to:

=
=93The canonical link relation (Link Relation Types reference <xref targ=
et=3D"RFC5988"/>) specifies the preferred version of a URI...=
=94

<=
span class=3D"Apple-tab-span" style=3D"white-space: pre; ">	--=
response by J. Reschke =93+1=94

-=
-response by M. Yevstifeyev =93I proposed to add something like:

R=
FC 5988 [RFC5988] specified the mechanism which is used to indicate relatio=
nships between the links on the Internet. =A0This document defined a new ty=
pe of such relationships - canonical link relation.

i=
n Section 1 as 1st para; other paragraphs retain in this case.=94
--response by M. Ohye =93We researched other RFCs and it seems best t=
o start the abstract with the main subject, such as for DC1:

=91The Dublin Core [DC1] is a small set of metadata elements for desc=
ribing information resources.=92

or for HTML:

=91The Hypertext Markup Language (HTML) is a simple markup language u=
sed...=94

so we=92d prefer to start with a mention of the canonical link relati=
on and reference RFC5988 following the initial mention.

The canonical link relation, developed from <xref target=3D"R=
FC5988"/> which indicates relationships between Internet links, spe=
cifies the preferred URI from a set of identical or vastly similar content =
accessible on multiple URIs.



Then, similar to the first paragraph of Section 10.3.2 of RFC 2616:



This designation MAY be used for future references to this resource, =
and clients with link editing capabilities MAY automatically re-link refere=
nces to the context URI to the designated URI."





5. CLOSED. M. Yevstifeyev:

&=
gt; Presence of the canonical link relation indicates to applications=
, such as search engines, that they MAY:

I=
 wonder why it's MAY; in this case implementations (explicitly, those a=
pps which interpret Link: headers and corresponding construction in HTML) w=
ill be free to ignore it. =A0I think normative SHOULD should be OK (sorry f=
or pun).

-=
-response by J. Reschke "I think this link relation is purely advisory=
, so a better approach might be to replace "MAY" by "can&quo=
t;."

-=
-response by M. Yevstifeyev "Yes, advisory, which suits RFC 2119 defin=
ition for SHOULD: 'SHOULD =A0=A0This word, or the adjective "RECOM=
MENDED", mean that there may exist valid reasons in particular circums=
tances to ignore a particular item, but the full implications must be under=
stood and carefully weighed before choosing a different course.'=


a=
nd natural meaning of should - advice/recommendation."

-=
-response by M. Ohye =93Thanks, in discussion with Joachim Kupke.=94=


-=
-response by J. Reschke =93No, it's really not a SHOULD.=94

-=
-response by J. Kupke =93Reading paragraph 5 of RFC 2119, I don't see a=
nything wrong with

=
=91MAY.=92 =A0How is =91can=92 better? It's indeed not a =91SHOULD=92 s=
ince a typical implementation, say in a search engine, will want to go to s=
ome length to find evidence for misguided usage of the relationship and in =
the presence of such evidence decide to ignore it. =A0The point of =91MAY=
=92 is to make clear that in the absence of such evidence, the responsibili=
ty not to advertise an erroneous =91canonical=92 relationship lies with the=
 author of the context URI.=94

-=
-response by J. Reschke =93See RFC 2119, Section 6:

<=
/span>


6. Guidance in the use of these Imperatives

<=
/span>


 =A0Imperatives of the type defined in this memo must be used with car=
e


 =A0and sparingly. =A0In particular, they MUST only be used where it i=
s


 =A0actually required for interoperation or to limit behavior which ha=
s


 =A0potential for causing harm (e.g., limiting retransmisssions) =A0Fo=
r


 =A0example, they must not be used to try to impose a particular metho=
d


 =A0on implementors where the method is not required for


 =A0interoperability.

<=
/span>

S=
o my recommendation is NOT to use these kinds of keywords unless when neede=
d as described above (but I realize that many people disagree with me...)

--response by M. Ohye =93Left as =91MAY=92 in the draft, but further =
debate welcomed.=94



7. OPEN. M. Yevstifeyev:

 =
=A0=A0o =A0Exist on a different protocol: http to https, or vice vers=
a

Y=
ou probably meant URI scheme here, since https isn't a separate protoco=
l. =A0As before these points we had "The value of the target/canonical=
 URI MAY" or, if you consider my comment above, "The target/canon=
ical URI MAY", this point may be reworded as "Have different sche=
me names" (which suits the second variant of a preface to this list be=
tter).

-=
-agreed by J. Reschke

-=
-response by M. Ohye/J. Kupke: =93Good catch, Mykyta. We=92re fine to chang=
e the draft to =93scheme=94:

H=
ave different scheme names: such as http to https, or vice versa

D=
o we now need to expand the draft for ftp:// and gopher:// URIs? For exampl=
e, ftp:// and gopher:// URIs=94

1=
) Do not come with the equivalent of RFC 5988, so a non-HTML document avail=
able at any such URI won't be available to make use of <link rel=3D&=
quot;canonical">.

2=
) Have corresponding GOPHER error code (item type 3) or an FTP error 550, w=
hich like HTTP 404, is forbidden from being served for the target of a <=
link rel=3D"canonical">.

-=
-response by M. Yevstifeyev =93I don't think we should make such change=
s. =A0If we consider ftp and gopher URIs, we should also consider all other=
. =A0I proposed to add generic statements which would be applicable to almo=
st all application protocols, not only HTTP, as in current version of the d=
raft.=94

-=
-response by J. Reschke =93a) A non-HTML document at a non-HTTP(s) URI may =
not be able to specify the link relation, but it could be the target of a l=
ink, relation, right? (that could be an example)

<=
span class=3D"Apple-tab-span" style=3D"white-space: pre; ">	--respon=
se by J. Kupke =93Correct.=94

b=
) Future protocols might have other means to specify a link relation, btw.=
=94


--response by J. Kupke =93Is there terminology that reasonably unifie=
s errors across protocols (HTTP response code 4xx, GOPHER item type 3, FTP =
response code 5xx)?=94


--response by J. Reschke =93I don't think so...=94

--response by M. Ohye =93Changed the draft to:

The target/canonical URI MAY:

* Have different scheme names: such as HTTP to HTTPS, or gopher to FT=
P




8. OPEN. M. Yevstifeyev:

R=
eading section 3 and 5 of the draft, it seems that is mandates use of HTTP =
when referring to canonical URIs. =A0And what is the situation when target =
URI is a 'ftp' or 'gopher' URI? =A0Section 3 allows differe=
nt scheme names in context/target URIs, if I understand it correctly. =A0Th=
erefore, unless it is deliberately, I think any mention of HTTP should be r=
eplaced by more generic regulations.

-=
-response by J. Reschke "Nope; I think the HTTP examples are very usef=
ul. But maybe we can have an additional statement that the link relation is=
n't specific to HTTP."

-=
-response by M. Yevstifeyev "Currently we have normative reference to =
RFC 2616 and normative requirements with respect to HTTP. =A0HTTP examples =
are OK; but it's redundant in Section 3. =A0I suppose in Section 3 we m=
ay replace HTTP-related stuff with something in the way like:

<=
/span>

O=
ld:

 =
=A0=A0o =A0The source URI of a "300 Multiple Choices" URI (Sectio=
n 10.3.1 of

 =
=A0=A0=A0=A0=A0[RFC2616]) or a permanent redirect (Section 10.3.2 of [RFC26=
16]).

N=
ew:

 =
=A0=A0o =A0The source URI, which defines a resource which provides choice

 =
=A0=A0=A0=A0=A0in different represntations of a given resource, ientified b=
y

 =
=A0=A0=A0=A0=A0the context URI, or is a link which has been permanently rep=
laced

 =
=A0=A0=A0=A0=A0by an other one.

e=
tc."

-=
-response by B. Thorlacius: =93Your wording seems overly confusing. Which i=
s the resource that "provides choice in different represntations of a =
given resource?" A standard could be assigned the URI <http://example.org/spec>=
. An HTTP GET /spec might be responded with an HTTP/1.1 300 choice, and an =
entity linking to /spec.node.html, /spec.html, /spec.pdf, and /spec.txt. Th=
e resource (the standard, that is) would in no way provide this choice. The=
 HTTP server simply offered multiple representations.=94

-=
-response by M. Yevstifeyev: =93First, this was an example only. =A0Next, m=
y point was that the document makes HTTP/'http' scheme mandatory in=
 context/target URIs, which I don't think is appropriate, since canonic=
al URI may refer to a resource accessible via other protocol. =A0Even thoug=
h HTTP is going to be the most often use case of canonical link relation, w=
e shouldn't exclude other protocols.=94

-=
-response by B. Thorlacius: =93I agree. However, I don't understand the=
 need for forbidding canonical links to resources with multiple representat=
ions. Are there not to be canonical links from representations of a resourc=
e to the resource (i.e. from /spec.html and /spec.txt to /spec)?=94<=
br>
-=
-response by M. Yevstifeyev: =93Probably such restriction is set because mu=
ltiple representation choice may ultimately refer the user to a resource wh=
ich is not canonical. =A0A _definite_ canonical resource is necessary and r=
equired.=94

<=
/span>


----response by =A0J. Cormack: =93I think this relation (which is use=
ful) need to be called something


else, as it is performing a different function to canonical, which is=



about relations between representations of resources, rather than


between representations of resources and a the resource itself=



like /spec.

<=
/span>


There does seem to not be a discussion of what is similar though in


terms of media types - is /spec.txt similar enough that /spec.html co=
uld


be a canonical link? One could certainly have a PNG version of an SVG=



image with a canonical link I would presume.=94


------response by =A0M. Yevstifeyev: =93I personally think it is poss=
ible. =A0For example, authoritative RFC source is .txt file on RFC Editor&#=
39;s site, while we have a number of other sources for RFCs, not in .txt, s=
uch as "t=
ools.ietf.org/html/rfcXXXX" in HTML. =A0Designating a "=
canonical" link to "http://www.rfc-editor.org/rfc/rfcXXXX.txt=
&=
quot; seems to be OK. =A0So I think we have no problem here.=94

-=
-response by M. Ohye: =93We can change the draft to include corresponding G=
OPHER or FTP error codes to demonstrate non-favortism to HTTP.=94
-=
-response by M. Yevstifeyev =93I don't think it would be useful (see ab=
ove). =A0It's better, as I've already mentioned in my response to (=
7), to provide rules which would be fine for almost any application protoco=
l and which would be equivalent to those provided for HTTP now. =A0For exam=
ple:

<=
/span>

O=
LD: =93Be the source URI of a 302, 303, or 307 redirect (Sections 10.=
3.3, 10.3.4, and 10.3.8, respectively, of [RFC2616])." 
N=
EW: "Provide a redirect to the other resource because it is temp=
orarily unavailable." 

<=
/span>

T=
his is what HTTP 302 and 307 responses stand for. =A0303 response is used i=
n HTTP only and here is no equivalent to it in other protocols.=94
-=
-response by J. Reschke =93...my general feeling here is that having specif=
ic HTTP examples is good, as long as the spec doesn't make the reader t=
hink it's the only protocol that qualifies.=94

--response by M. Ohye =93Given Julian=92s comments in #15 below, and =
M. Yevstifeyev=92s original concern of being too HTTP specific, this now re=
ads:

Be the source URI of a temporary redirect. For HTTP, this refers to s=
tatus codes 302, 303, or 307 (Sections 10.3.3, 10.3.4, and 10.3.8, respecti=
vely, of <xref target=3D"RFC2616"/>).







10. OPEN. J. Reschke:

T=
his specification defines the canonical link relation -- an element which d=
esignates the preferred version of content/URI from a set of duplicate or n=
ear duplicate pages.

M=
aybe put "canonical" in double quotes? (similar in other places)<=
/span>

--response by M. Ohye =93How adamant are you about double quoting =93=
canonical=94 in =93canonical link relation=94 throughout the draft? That=92=
s a lot of double quotes (18 of them :). I think these double quotes would =
be more distracting than helpful, but if that=92s how other RFCs are writte=
n, we=92ll certainly reconsider.=94

<=
/span>

1=
1. CLOSED. J. Reschke:

T=
he canonical link relation specifies the preferred version of a URI from a =
set of identical or vastly similar content that may be

m=
aybe just "preferred URI"?

--response by M. Ohye =93Changed. Here=92s the new abstract:
The canonical link relation, developed from <xref target=3D"R=
FC5988"/> which indicates relationships between Internet links, spe=
cifies the preferred URI from a set of identical or vastly similar content =
accessible on multiple URIs.

<=
/span>

1=
2. CLOSED. J. Reschke:

T=
he canonical (target URI) MUST contain content that duplicates=


&=
quot;canonical (target) URI MUST identify content" (it's not the c=
ontent of the URI, it's the content of the identified resource)<=
br>
--response by M. Ohye =93Updated in draft.=94

<=
/span>

1=
3. CLOSED. J. Reschke

e=
xtremely similar, or is a superset of the content in the context

s=
/in/at/:

--response by M. Ohye =93Updated in draft.=94

<=
/span>

1=
4. OPEN. J. Reschke:

 =
The value of the target/canonical URI MAY:

<=
/span>

 =
=A0o =A0Be self-referential (context URI identical to target URI)
<=
/span>

 =
=A0o =A0Specify a relative or absolute URI

<=
/span>

&=
quot;Specify a URI Reference (see [RFC3986], Section 4.1), i.e., a full URI=
 or a relative reference=94

--response by M. Ohye =93How about the edit below?

Specify a URI Reference (see [RFC3986], Section 4.1), i.e., an absolu=
te URI or a relative reference

<=
/span>

1=
5. OPEN. J. Reschke:

 o =A0Be the source URI of a 302, 303, or 307 redirect (Sections 10.=
3.3,

 =
=A0=A0=A0=A010.3.4, and 10.3.8, respectively, of [RFC2616]).



M=
aybe "Be the source URI of a temporary redirect, such as..."?

--response by M. Ohye =93Changed to

Be the source URI of a temporary redirect. Using HTTP, this refers to=
 status codes 302, 303, or 307 (Sections 10.3.3, 10.3.4, and 10.3.8, respec=
tively, of <xref target=3D"RFC2616"/>).

Julian, please let me know if you=92d like this phased differently.

<=
/span>

1=
6. OPEN. J. Reschke:

m=
ay designate the canonical link relation in HTML as specified in [RFC5988]<=
/span>

W=
hy do we cite RFC 5988 here? Should this ref HTML?

--response by M. Ohye =93Changed to:

may designate the canonical link relation in HTML as specified in <=
;xref target=3D"RFC1866"/>

I created this reference, but I couldn=92t find an organization or em=
ail address for Dan Connolly.

<reference anchor=3D"RFC1866">

 =A0<front>

 =A0=A0=A0<title>Hypertext Markup Language - 2.0</title><=
/span>

 =A0=A0=A0<author initials=3D"T." surname=3D"Berner=
s-Lee" fullname=3D"T. Berners-Lee">

 =A0=A0=A0=A0=A0<organization>MIT/W3C</organization>

 =A0=A0=A0=A0=A0<address><email>timbl@w3.org</email></address>

 =A0=A0=A0</author>

 =A0=A0=A0<author initials=3D"D." surname=3D"Connol=
ly" fullname=3D"Dan Connolly">

 =A0=A0=A0</author>

 =A0=A0=A0<date month=3D"November" year=3D"1995&quo=
t;/>

 =A0</front>

 =A0<seriesInfo name=3D"RFC" value=3D"1866"/&g=
t;

</reference>

Julian, should I have done anything differently?

<=
/span>

1=
7. CLOSED. J. Reschke:

 =
<link rel=3D"canonical" href=3D"http://www.example.com/page.php?=
item=3Dpurse" />

 =
=A0or alternatively, in the HTTP Header as specified in Section 5 of=


 =
=A0[RFC5988]:

s=
/Header/header field/

--response by M. Ohye =93Updated in the draft.=94

<=
/span>

1=
8. CLOSED. J. Reschke:

R=
ecommendations

B=
efore implementing the canonical link relation, verification of the<=
br>
<=
/span>

M=
aybe s/implementing/adding/?

--response by M. Ohye =93Updated in the draft.=94


<=
br>




On Sat, Jul 9, 2011 at 2:00 AM, Juli=
an Reschke <julian.reschke@gmx.=
de> wrote:
> On 2011-07-09 04:44, Joachim Kupke wrote:
>=
>

>> ...
>>>>
>>>> 5. OPEN. M. Yevstifeye=
v:
>>>>>
>>>>> =A0Presence of the canon=
ical link relation indicates to applications,
>>>>
>&g=
t;>> such as search engines, that they MAY:

>>>> I wonder why it's MAY; in this case implementations (e=
xplicitly, those
>>>> apps which interpret Link: headers and=
 corresponding construction in
>>>> HTML) will be free to ig=
nore it. =A0I think normative SHOULD should be OK

>>>> (sorry for pun).
>>>> --response by J. Resc=
hke "I think this link relation is purely advisory,
>>>>=
; so a better approach might be to replace "MAY" by "can&quo=
t;."

>>
>> Reading paragraph 5 of RFC 2119, I don't see anyth=
ing wrong with
>> "MAY." =A0How is "can" bette=
r?
>> ...
>
> See RFC 2119, Section 6:
>
>=
> 6. Guidance in the use of these Imperatives

>>
>> =A0 Imperatives of the type defined in this memo must =
be used with care
>> =A0 and sparingly. =A0In particular, they MUS=
T only be used where it is
>> =A0 actually required for interopera=
tion or to limit behavior which has

>> =A0 potential for causing harm (e.g., limiting retransmisssions) =
=A0For
>> =A0 example, they must not be used to try to impose a pa=
rticular method
>> =A0 on implementors where the method is not req=
uired for

>> =A0 interoperability.
>
> So my recommendation is NOT =
to use these kinds of keywords unless when
> needed as described abov=
e (but I realize that many people disagree with
> me...)
>

>> ...
>>>
>>> b) Future protocols might have=
 other means to specify a link relation,
>>> btw.
>>>> Is there terminology that reasonably unifies errors across proto=
cols

>> (HTTP response code 4xx, GOPHER item type 3, FTP response code 5xx=
)?
>> ...
>
> I don't think so...
>
> =
Best regards, Julian
>



--bcaec544eee65b906c04a8169db0--

From msk@cloudmark.com  Fri Jul 15 11:15:34 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8959721F8AE6 for ; Fri, 15 Jul 2011 11:15:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.932
X-Spam-Level: 
X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 cxtPE2lDZbWQ for ; Fri, 15 Jul 2011 11:15:33 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7184C21F8AE4 for ; Fri, 15 Jul 2011 11:15:33 -0700 (PDT)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 15 Jul 2011 11:15:33 -0700
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" 
Date: Fri, 15 Jul 2011 11:15:31 -0700
Thread-Topic: Updating multipart/report
Thread-Index: AcxDGy8Iw7sUUYQXQIu4yfLZB3vvgw==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F134EBC4D26EXCHC2corpclo_"
MIME-Version: 1.0
Subject: [apps-discuss] Updating multipart/report
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2011 18:15:34 -0000

--_000_F5833273385BB34F99288B3648C4F06F134EBC4D26EXCHC2corpclo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Resurrecting an old topic...

The MARF working group has a requirement to be able to produce messages tha=
t contain abuse reports.  It currently uses multipart/report to do this.  H=
owever, multipart/report has a limitation that it has to be the outermost m=
edia type in a message.  This prevents MARF from being compatible with anot=
her system that can contain multiple reports per message.

I introduced this topic some months ago on apps-discuss, and a draft that i=
s almost verbatim the same as RFC3462 minus the above limitation.  I rememb=
er Keith dissenting and Ned supporting, on the grounds that the limitation =
hasn't served any useful purpose. The topic died off after that, but I'd li=
ke to reintroduce it.

We could try to do this from within MARF but it seems to me that modifying =
a general-purpose email RFC in a working group with a specific application =
is probably a little sketchy.  I think it should either live here or in YAM=
.  I've posted a similar message to YAM just now to see if they want it, su=
bject to the results of their rechartering.

If they don't want it, could we introduce it as an APPSAWG work item?

-MSK


--_000_F5833273385BB34F99288B3648C4F06F134EBC4D26EXCHC2corpclo_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Resurrecting an =
old topic…
 
The MARF working group has a requirement to be able to p=
roduce messages that contain abuse reports.  It currently uses multipa=
rt/report to do this.  However, multipart/report has a limitation that=
 it has to be the outermost media type in a message.  This prevents MA=
RF from being compatible with another system that can contain multiple repo=
rts per message.

I introduced this t=
opic some months ago on apps-discuss, and a draft that is almost verbatim t=
he same as RFC3462 minus the above limitation.  I remember Keith disse=
nting and Ned supporting, on the grounds that the limitation hasn’t s=
erved any useful purpose. The topic died off after that, but I’d like=
 to reintroduce it.

We could try to =
do this from within MARF but it seems to me that modifying a general-purpos=
e email RFC in a working group with a specific application is probably a li=
ttle sketchy.  I think it should either live here or in YAM.  I&#=
8217;ve posted a similar message to YAM just now to see if they want it, su=
bject to the results of their rechartering.
 
If they don’t want it, =
could we introduce it as an APPSAWG work item?

-MSK
 
=

--_000_F5833273385BB34F99288B3648C4F06F134EBC4D26EXCHC2corpclo_--

From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com  Fri Jul 15 18:25:16 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B8D21F8783 for ; Fri, 15 Jul 2011 18:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.863
X-Spam-Level: 
X-Spam-Status: No, score=-102.863 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, 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 V8jUmSEV775G for ; Fri, 15 Jul 2011 18:25:15 -0700 (PDT)
Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7E421F8781 for ; Fri, 15 Jul 2011 18:25:15 -0700 (PDT)
Received: by pzd13 with SMTP id 13so2427554pzd.39 for ; Fri, 15 Jul 2011 18:25:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=yjbe5Joto2/3V7ItnLw/xAS8p75wB459pqcxXcLfB78=; b=k9UVWkcJX5Qkerg4OEtUbvoPe8PpdQXs98BLmyWZK/7ClfakQ6LfpXm9vDgzhNJ+V0 B+wPHmMcxBPE7QLuUXzaJFjDasKgIu7qEo5Ou97ENzoxJp1U7Q+lytQZuAVeLqfJPgw2 Z1Em7LxwyzU1Iu0CjpemXRstUQFv6t5veVBPA=
Received: by 10.142.214.8 with SMTP id m8mr1905596wfg.351.1310779515095; Fri, 15 Jul 2011 18:25:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.88.9 with HTTP; Fri, 15 Jul 2011 18:24:55 -0700 (PDT)
In-Reply-To: <4E1FBBC2.4070303@it.aoyama.ac.jp>
References: <4E15C895.6020701@gmail.com> <4E1B3270.40601@gmail.com>  <4E1E62AB.2070608@gmail.com>  <4E1FB79D.1020603@gmail.com> <4E1FBBC2.4070303@it.aoyama.ac.jp>
From: Frank Ellermann 
Date: Sat, 16 Jul 2011 03:24:55 +0200
Message-ID: 
To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Apps-discuss list 
Subject: Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jul 2011 01:25:16 -0000

On 15 July 2011 06:02, "Martin J. D=FCrst" wrote:

> Please read the text after the
> =A0 =A0reserved =A0 =A0=3D gen-delims / sub-delims
> ABNF rule in RFC 3986.

Okay, but it doesn't explain the "lost"  in RFC 1738:
 national =3D "{" | "}" | "|" | "\" | "^" | "~" | "[" | "]" | "`"
This "forbidden" set was later reduced to  in RFC 2396:
 unwise   =3D "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"

Skipping RFC 2732 introducing IPv6 literals using "[" and "]"
RFC 3986 does not explain that some unencoded US-ASCII char.s
are never permitted in URIs: "{" | "}" | "|" | "\" | "^" | "`"

And the "new" unencoded  "[" / "]" are only allowed
for "IPvNot4" literals in the  part of the ,
no matter what any specific URI schemes such as RFC 6068 or
specific fragment specifications such as RFC 5147 might wish.

Unrelated, it is rather annoying that the IE and Chrome folks
have not yet implemented RFC 5147, this nice feature should
take the proverbial "five minutes" for a developer.

-Frank

From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com  Fri Jul 15 18:57:23 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170AA21F86EB for ; Fri, 15 Jul 2011 18:57:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.024
X-Spam-Level: 
X-Spam-Status: No, score=-103.024 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 ez6CrRuPgjmT for ; Fri, 15 Jul 2011 18:57:22 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E62021F86E5 for ; Fri, 15 Jul 2011 18:57:22 -0700 (PDT)
Received: by pvh18 with SMTP id 18so2274018pvh.31 for ; Fri, 15 Jul 2011 18:57:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dLqO9DrS9i/w5aoCykiB11cOEq0h002j0Begjz48mRM=; b=P1wj15gk5hx5pQl9oNQe4bmTodRdZWwhoPQ7u9vNa6ef+pV4EhjqnxwVC7fAgOgh/P TDnRA+f7D9uiFCe3HvpqPYvfdJVr/Gbm5qGlDXLiqTSI4NG67B2cJfX7ylg7Rj2zZA5a TUaCMT5ObV5bbR3++K94ZWVqau9RHfPU2HeHo=
Received: by 10.142.250.13 with SMTP id x13mr1848196wfh.9.1310781440113; Fri, 15 Jul 2011 18:57:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.88.9 with HTTP; Fri, 15 Jul 2011 18:57:00 -0700 (PDT)
In-Reply-To: <4E1FC18F.7070500@gmail.com>
References: <4E1FC18F.7070500@gmail.com>
From: Frank Ellermann 
Date: Sat, 16 Jul 2011 03:57:00 +0200
Message-ID: 
To: iri@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Cc: Apps-discuss list 
Subject: Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-iri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jul 2011 01:57:23 -0000

On 15 July 2011 06:26, Mykyta Yevstifeyev wrote:

> http://tools.ietf.org/html/draft-yevstifeyev-ftp-iri-00

That makes no sense.  There should be "i18n considerations"
in your FTP URI draft as mandated by the IETF charset policy
(BCP 18).

This section can mainly consist of a pointer to RFC 3987,
because copying stuff for FTP IRIs already explained for
any IRIs is either redundant, or in the worst case it could
introduce incompatibilities or bugs.

It is good that your IRI draft has a reference to RFC 5198,
but you can get the same effect in i18n considerations of
your URI draft - and as far as I'm concerned that should be
be normative, not only informative.

If you seriously wish to discuss "FTP IRIs" in these i18n
considerations you'd be forced to admit that many legacy FTP
servers use only legacy charsets, and therefore legacy URIs
for resources on such servers are certainly no IRIs.  Worse,
equivalent FTP IRIs would not work with legacy FTP servers.

The more you talk about "FTP IRIs", the worse this gets, so
just don't, and let RFC 3987 (and 3987bis) clean up the mess
for *all* URI schemes (not only FTP).

-Frank

From duerst@it.aoyama.ac.jp  Sat Jul 16 00:58:19 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB0921F8606 for ; Sat, 16 Jul 2011 00:58:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.753
X-Spam-Level: 
X-Spam-Status: No, score=-99.753 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.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 z1TGEjQg-mwA for ; Sat, 16 Jul 2011 00:58:18 -0700 (PDT)
Received: from acintmta01.acbb.aoyama.ac.jp (acintmta01.acbb.aoyama.ac.jp [133.2.20.33]) by ietfa.amsl.com (Postfix) with ESMTP id 58CDF21F85FF for ; Sat, 16 Jul 2011 00:58:17 -0700 (PDT)
Received: from acmse01.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta01.acbb.aoyama.ac.jp (secret/secret) with SMTP id p6G7w9Ci009462 for ; Sat, 16 Jul 2011 16:58:09 +0900
Received: from (unknown [133.2.206.133]) by acmse01.acbb.aoyama.ac.jp with smtp id 5ed6_bb39_58bbe570_af81_11e0_a569_001d096c5b62; Sat, 16 Jul 2011 16:58:09 +0900
Received: from [IPv6:::1] ([133.2.210.5]:33730) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Sat, 16 Jul 2011 16:58:11 +0900
Message-ID: <4E214464.7060208@it.aoyama.ac.jp>
Date: Sat, 16 Jul 2011 16:57:24 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Frank Ellermann 
References: <4E15C895.6020701@gmail.com> <4E1B3270.40601@gmail.com>  <4E1E62AB.2070608@gmail.com>  <4E1FB79D.1020603@gmail.com> <4E1FBBC2.4070303@it.aoyama.ac.jp> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Apps-discuss list 
Subject: Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jul 2011 07:58:19 -0000

On 2011/07/16 10:24, Frank Ellermann wrote:
> On 15 July 2011 06:02, "Martin J. Drst" wrote:
>
>> Please read the text after the
>>     reserved    = gen-delims / sub-delims
>> ABNF rule in RFC 3986.
>
> Okay, but it doesn't explain the "lost"  in RFC 1738:
>   national = "{" | "}" | "|" | "\" | "^" | "~" | "[" | "]" | "`"

At that time, various versions of ISO 646 were still in use (or at least 
feared to still be in use) which would have meant that these codepoints 
would have shown up as different glyphs in some environments (e.g. 
 in the German version of ISO 646). As time moved on, this kind 
of concern grew smaller and smaller.


> This "forbidden" set was later reduced to  in RFC 2396:
>   unwise   = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"
>
> Skipping RFC 2732 introducing IPv6 literals using "[" and "]"
> RFC 3986 does not explain that some unencoded US-ASCII char.s
> are never permitted in URIs: "{" | "}" | "|" | "\" | "^" | "`"

Well, yes, it's the spec for URIs, not for "what's not allowed in URIs".


> And the "new" unencoded  "[" / "]" are only allowed
> for "IPvNot4" literals in the  part of the,
> no matter what any specific URI schemes such as RFC 6068 or
> specific fragment specifications such as RFC 5147 might wish.

That "[" / "]" can only be used for IPv6 addresses and the like is 
definitely somewhat inconsistent. If there ever were an update of RFC 
3986, I can imagine that to be changed (but that's only a guess).

> Unrelated, it is rather annoying that the IE and Chrome folks
> have not yet implemented RFC 5147, this nice feature should
> take the proverbial "five minutes" for a developer.

Does that mean that it's implemented in Firefox and Opera? That would be 
great to hear. For Chrome, you could submit a bug or patch to webkit, I 
guess.

Regards,    Martin.

From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com  Sat Jul 16 01:50:24 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D96721F85E5 for ; Sat, 16 Jul 2011 01:50:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.882
X-Spam-Level: 
X-Spam-Status: No, score=-102.882 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, 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 b-6Q1BF55sER for ; Sat, 16 Jul 2011 01:50:23 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id A498721F85AA for ; Sat, 16 Jul 2011 01:50:23 -0700 (PDT)
Received: by pvh18 with SMTP id 18so2539715pvh.31 for ; Sat, 16 Jul 2011 01:50:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=SQaap4TMFxZEGcUQ7osytq+FIV35ZPLocUoRHTa33pI=; b=EtdGRrEpUOkPUlMTq5t/ZTTZ89NsXqP1/JsjOpJMhCTrwNxRTaPzMG+kxdW0kPF/ye 6GAh8YDG7tyD/dd4ji1xeVu7ZLdSaeVhZ5Bl7PfArgM41ScBXN592aVHH6xTb5sdMpzr LMyvbcWBDCJXBoLcbTiv7T+zAVL4krYfHx2y4=
Received: by 10.142.234.8 with SMTP id g8mr2118536wfh.180.1310806223196; Sat, 16 Jul 2011 01:50:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.88.9 with HTTP; Sat, 16 Jul 2011 01:50:03 -0700 (PDT)
In-Reply-To: <4E214464.7060208@it.aoyama.ac.jp>
References: <4E15C895.6020701@gmail.com> <4E1B3270.40601@gmail.com>  <4E1E62AB.2070608@gmail.com>  <4E1FB79D.1020603@gmail.com> <4E1FBBC2.4070303@it.aoyama.ac.jp>  <4E214464.7060208@it.aoyama.ac.jp>
From: Frank Ellermann 
Date: Sat, 16 Jul 2011 10:50:03 +0200
Message-ID: 
To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Apps-discuss list 
Subject: Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jul 2011 08:50:24 -0000

On 16 July 2011 09:57, "Martin J. D=FCrst" wrote:

>> RFC 3986 does not explain that some unencoded US-ASCII char.s
>> are never permitted in URIs: "{" | "}" | "|" | "\" | "^" | "`"

> Well, yes, it's the spec for URIs, not for "what's not allowed
> in URIs".

Okay - but not very helpful for folks trying to "upgrade" older
spec.s based on RFC 1738 to something based on RFC 3986/3987, or for
developers trying to filter completely bogus URIs.

The older RFCs had a nice  rule for this purpose.  My list
above was incomplete, I forgot (at least) "<" / ">" / SP / DQUOTE

> That "[" / "]" can only be used for IPv6 addresses and the like
> is definitely somewhat inconsistent. If there ever were an
> update of RFC 3986, I can imagine that to be changed (but that's
> only a guess).

For the pseudo- in news://server/message-ID URIs that was
an obstacle.  But now I'm curious, there is no  in mailto:,
and that could allow square brackets in mailto: IPv6 literals...

Yes, RFC 6068 explicitly allows "[" ... "]" in a , good.

 [about RFC 5147]
> Does that mean that it's implemented in Firefox and Opera?

FF5 test with 

No, sorry.  No opera on my box, that will be my last resort if I'm
ever annoyed with IE + Chrome + FF at the same time.  But I read
AvK's blog, just in case.

> For Chrome, you could submit a bug or patch to webkit, I guess.

Chromium issue 77024, waiting for "confirmation" since March.  For
IE9 a very complete issue report was closed as "not reproducible",
and I concluded that the IE9+ developers are not too interested
in contributions from IE9+ users.

-Frank

From evnikita2@gmail.com  Sat Jul 16 02:12:40 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281E321F85E1 for ; Sat, 16 Jul 2011 02:12:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.504
X-Spam-Level: 
X-Spam-Status: No, score=-3.504 tagged_above=-999 required=5 tests=[AWL=0.095,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 qtc3omcPR7Tz for ; Sat, 16 Jul 2011 02:12:36 -0700 (PDT)
Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id A42B621F854E for ; Sat, 16 Jul 2011 02:12:35 -0700 (PDT)
Received: by fxe4 with SMTP id 4so4668948fxe.27 for ; Sat, 16 Jul 2011 02:12:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ii86NrQJsm0XFMn3bgUmDNYqDbNMNBP/3MDUp6tvAbs=; b=R94u9olWbkVYApzqarkZsTXLMqcyZN7YpifOcHGlWi2+/5AvD8WwZP/DYT3UZWqgXb Ypz90h4zaKRkEuIESBRyqIZg9/SeGMRVhMV5d0oa4IVniuhUX7p7Pbc+zXof5KNqkHBN qONBmTjS8JwwgtTJL31Ki1Vor21cUdKIN7Xpw=
Received: by 10.223.158.72 with SMTP id e8mr6382472fax.39.1310807554704; Sat, 16 Jul 2011 02:12:34 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id 5sm1339551fas.40.2011.07.16.02.12.32 (version=SSLv3 cipher=OTHER); Sat, 16 Jul 2011 02:12:33 -0700 (PDT)
Message-ID: <4E21562D.4020308@gmail.com>
Date: Sat, 16 Jul 2011 12:13:17 +0300
From: Mykyta Yevstifeyev 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <4E15C895.6020701@gmail.com> <4E1B3270.40601@gmail.com>  <4E1E62AB.2070608@gmail.com>  <4E1FB79D.1020603@gmail.com> <4E1FBBC2.4070303@it.aoyama.ac.jp>  <4E214464.7060208@it.aoyama.ac.jp> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] RFC 5147 implementations (was: Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jul 2011 09:12:40 -0000

Frank, all,

I've tested with Opera 11.5 - it doesn't seem to work.  Nor does Safari 
3.2.1 for Windows.

Regarding FF - I submitted Bug 662583 
(https://bugzilla.mozilla.org/show_bug.cgi?id=660583) a while ago 
reporting this issue.  I don't know whether and when it is going to be 
processed.

Mykyta

16.07.2011 11:50, Frank Ellermann wrote:
> [about RFC 5147]
>> Does that mean that it's implemented in Firefox and Opera?
> FF5 test with
>
> No, sorry.  No opera on my box, that will be my last resort if I'm
> ever annoyed with IE + Chrome + FF at the same time.  But I read
> AvK's blog, just in case.
>
>> For Chrome, you could submit a bug or patch to webkit, I guess.
> Chromium issue 77024, waiting for "confirmation" since March.  For
> IE9 a very complete issue report was closed as "not reproducible",
> and I concluded that the IE9+ developers are not too interested
> in contributions from IE9+ users.
>
> -Frank
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>


From evnikita2@gmail.com  Sat Jul 16 02:22:05 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FBA21F85A8 for ; Sat, 16 Jul 2011 02:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.506
X-Spam-Level: 
X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 R2wyuP0p0lxG for ; Sat, 16 Jul 2011 02:22:04 -0700 (PDT)
Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 532F621F85A0 for ; Sat, 16 Jul 2011 02:22:04 -0700 (PDT)
Received: by fxe4 with SMTP id 4so4677301fxe.27 for ; Sat, 16 Jul 2011 02:22:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=XeYlelL/wMfzG31VE7U5K1G9NelLTUA3XtmlN4zj/iQ=; b=muj7ZmMZmWX0YCS6RDba3SeGbrQYy+/RnB3NmKiGUBUb1xQCg7i5w3BQdI2dlRVYW4 QbbS7Q35kMso8H/UmbMJaAi8fJY/zMjJDTBLhkUMAwiMLK6PgFf1yqHi9X4bthyiox87 0l15gnrSCVMX5AXwXmK/duaeQAI+azNN/M/OA=
Received: by 10.223.36.89 with SMTP id s25mr6749859fad.9.1310808123525; Sat, 16 Jul 2011 02:22:03 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id w15sm1366193faj.47.2011.07.16.02.22.01 (version=SSLv3 cipher=OTHER); Sat, 16 Jul 2011 02:22:02 -0700 (PDT)
Message-ID: <4E215866.4030809@gmail.com>
Date: Sat, 16 Jul 2011 12:22:46 +0300
From: Mykyta Yevstifeyev 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <4E15C895.6020701@gmail.com> <4E1B3270.40601@gmail.com>  <4E1E62AB.2070608@gmail.com>  <4E1FB79D.1020603@gmail.com> <4E1FBBC2.4070303@it.aoyama.ac.jp>  <4E214464.7060208@it.aoyama.ac.jp>
In-Reply-To: <4E214464.7060208@it.aoyama.ac.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jul 2011 09:22:05 -0000

16.07.2011 10:57, "Martin J. Drst" wrote:
> On 2011/07/16 10:24, Frank Ellermann wrote:
>> On 15 July 2011 06:02, "Martin J. Drst" wrote:
>>
>>> Please read the text after the
>>>     reserved    = gen-delims / sub-delims
>>> ABNF rule in RFC 3986.
>>
>> Okay, but it doesn't explain the "lost"  in RFC 1738:
>>   national = "{" | "}" | "|" | "\" | "^" | "~" | "[" | "]" | "`"
>
> At that time, various versions of ISO 646 were still in use (or at 
> least feared to still be in use) which would have meant that these 
> codepoints would have shown up as different glyphs in some 
> environments (e.g.  in the German version of ISO 646). As time 
> moved on, this kind of concern grew smaller and smaller.
BTW, I also recall something like this in RFC 20, eg.:

>     5/13        ]           Closing Bracket [3]
> [etc.]
> [...]
>     ------
>        3 These characters should not be used in international interchange
>     without determining that there is agreement between sender and
>     recipient.
Mykyta Yevstifeyev

From julian.reschke@gmx.de  Sat Jul 16 02:30:28 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E249921F84E7 for ; Sat, 16 Jul 2011 02:30:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.973
X-Spam-Level: 
X-Spam-Status: No, score=-103.973 tagged_above=-999 required=5 tests=[AWL=-1.374, BAYES_00=-2.599, 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 9hHH1V0Toztz for ; Sat, 16 Jul 2011 02:30:27 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1E30B21F84CC for ; Sat, 16 Jul 2011 02:30:26 -0700 (PDT)
Received: (qmail invoked by alias); 16 Jul 2011 09:30:25 -0000
Received: from p508FDB03.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.219.3] by mail.gmx.net (mp071) with SMTP; 16 Jul 2011 11:30:25 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/BNEMJhOjB7OFlH/DtMdopnuZS+x9rbHItmS48bW IOLv/gEisWTEat
Message-ID: <4E215A2C.5010108@gmx.de>
Date: Sat, 16 Jul 2011 11:30:20 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Mykyta Yevstifeyev 
References: <4E15C895.6020701@gmail.com> <4E1B3270.40601@gmail.com>  <4E1E62AB.2070608@gmail.com>  <4E1FB79D.1020603@gmail.com> <4E1FBBC2.4070303@it.aoyama.ac.jp>  <4E214464.7060208@it.aoyama.ac.jp>  <4E21562D.4020308@gmail.com>
In-Reply-To: <4E21562D.4020308@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] RFC 5147 implementations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jul 2011 09:30:29 -0000

On 2011-07-16 11:13, Mykyta Yevstifeyev wrote:
> Frank, all,
>
> I've tested with Opera 11.5 - it doesn't seem to work. Nor does Safari
> 3.2.1 for Windows.
>
> Regarding FF - I submitted Bug 662583
> (https://bugzilla.mozilla.org/show_bug.cgi?id=660583) a while ago
> reporting this issue. I don't know whether and when it is going to be
> processed.
>
> Mykyta

"Patches welcome"?

From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com  Sat Jul 16 02:30:47 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A9021F85F6 for ; Sat, 16 Jul 2011 02:30:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.024
X-Spam-Level: 
X-Spam-Status: No, score=-103.024 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 BZczKSVOmqac for ; Sat, 16 Jul 2011 02:30:47 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6DED121F84CC for ; Sat, 16 Jul 2011 02:30:47 -0700 (PDT)
Received: by pvh18 with SMTP id 18so2565205pvh.31 for ; Sat, 16 Jul 2011 02:30:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=sC23HV6YRq8Ws4XOnG6Mpd5re9XrYiIq9OVB4i4OYuc=; b=u3CTF6XfRDg1wRaQEUtaETCFkZlUvwufnxV0XXlUUbjuiufaEej7t26RYNvADjjP+r y26NSTI94GFCFDHswEpUe9PgmmRUUD56hXOIyolCMS5Ev33JPR7X94pjxXzJCtTV6Euc romXGWqojA3H64PEBmDGDoSa1LrbtHcVPa5rI=
Received: by 10.142.250.36 with SMTP id x36mr1363609wfh.123.1310808647135; Sat, 16 Jul 2011 02:30:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.88.9 with HTTP; Sat, 16 Jul 2011 02:30:27 -0700 (PDT)
From: Frank Ellermann 
Date: Sat, 16 Jul 2011 11:30:27 +0200
Message-ID: 
To: Mykyta Yevstifeyev 
Content-Type: text/plain; charset=ISO-8859-1
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] RFC 5147 implementations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jul 2011 09:30:47 -0000

On 16 July 2011 11:13, Mykyta Yevstifeyev wrote:

> (https://bugzilla.mozilla.org/show_bug.cgi?id=660583)

Thanks, I added cross references and (FWIW) my "vote".

From behnam@gmail.com  Mon Jul 18 18:02:42 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03EFE21F8754 for ; Mon, 18 Jul 2011 18:02:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Level: 
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[AWL=1.368,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1]
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 1kRa-X53MFmc for ; Mon, 18 Jul 2011 18:02:36 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B16A921F874C for ; Mon, 18 Jul 2011 18:02:36 -0700 (PDT)
Received: by iwn39 with SMTP id 39so3884830iwn.31 for ; Mon, 18 Jul 2011 18:02:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=6O/rhKc2iI6wgDI/t8wXkTNYrGh+6K9xEvFk+r7stWc=; b=iNCDS7pbOVtZMiOAI9yjJ/U67g4hlpcWML5FR+WOay2XBvdH2DaU6sXi+ZAOBSbfBA zBJ8XIzkQoyfL7NYorSjDFhZKHLxXh+KrDRcXP5se76582h9yGfmIokUcUNcortLYtXF s6xTXQfkyLXcwq8EFwCFGJv0TqUpho0+qGKks=
Received: by 10.231.128.199 with SMTP id l7mr6092294ibs.150.1311037356269; Mon, 18 Jul 2011 18:02:36 -0700 (PDT)
MIME-Version: 1.0
Sender: behnam@gmail.com
Received: by 10.231.3.146 with HTTP; Mon, 18 Jul 2011 18:01:56 -0700 (PDT)
In-Reply-To: 
References: 
From: Behnam Esfahbod 
Date: Mon, 18 Jul 2011 21:01:56 -0400
X-Google-Sender-Auth: J2kTH1pj3VcYfGkdWAWAWmiIjb8
Message-ID: 
To: John C Klensin 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: apps-discuss 
Subject: Re: [apps-discuss] CONTEXTJ in TLD DNS-Labels (draft-liman-tld-names-05)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2011 01:02:42 -0000

Hi John,

I think it is time to stop general pronouncements that have been repeated a=
nd
repeated so many times over these past years and get down to specifics.  He=
re
are two very concrete points you should note:

1. ZWNJ is not a special quirk of Persian language, it is not a mnemonic to=
ol,
   nor is it an optional writing-style device.  ZWNJ is used in the writing=
 of
   MOST languages using Arabic script. ZWNJ is a necessity for this script =
the
   same way that contextual joining is in the first place.

2. If ZWNJ is claimed to cause confusion and phishing problems beyond what =
is
   normally acceptable for other symbols, it is up to the claimants to
   demonstrate this claim.

3. Many security issues with Arabic PVALID characters have been identified =
by
   ICANN VIP Arabic team and many of them are more serious than the possibl=
e
   cases for ZWNJ.  If you decide to remove every character that "might" be
   confused with another one in some "defected font" or "small type size", =
you
   will end up with less than a dozen of characters for Arabic script, maki=
ng
   it useless for all the users.

Let us stop talking about misleading generalities.

Thanks,
-Behnam



On Mon, Jul 4, 2011 at 8:17 AM, John C Klensin  wrote:
>
>
> --On Thursday, June 30, 2011 16:56 -0400 Behnam Esfahbod
>  wrote:
>
>> Hello,
>>
>> The restriction rules of the latest draft for "Top Level
>> Domain Name Specification", section 4 [1], is unfortunately
>> very restrictive for some languages, including Persian
>> language (in Arabic script).
>>...
>> Hereby, I would like to request reconsidering the restriction
>> rules of TLD DNS-Labels and to allow characters with CONTEXTJ
>> derived property value in the labels. (Of course the IDNA2008
>> contextual restrictions for CONTEXTJ characters must apply.)
>
>
> Behnam,
>
> (personal opinion only; not wearing any present or past "hats")
>
> ICANN makes up their own rules about this sort of thing, maybe
> with emphasis on "makes up". =C2=A0They have fairly consistently told
> IETF participants that IETF opinions are relevant only if they
> impose clear technical restrictions (and maybe not then). =C2=A0 The
> degree of attention paid in ICANN to the arguments of either RFC
> 3675 or RFC 4185 are perhaps indicative.
>
> IDNA2008 imposes no special requirements on top level IDNs -- if
> a string is valid at any other level of the tree, it does not
> violate the protocol to use it at the top level. =C2=A0So, from an
> IETF standpoint, there is nothing to reconsider in order to
> permit ZWNJ to be used in domain names.
>
> That said, let me provide a different perspective on the
> problem. =C2=A0This perspective may be reflected in both current
> ICANN policy and in draft-liman-tld-names-05. =C2=A0 It certainly
> influenced the recommendations I made about the latter document.
>
> First of all, while various folks around ICANN seem to forget it
> regularly, there has never been an entitlement to use names or
> words in the DNS. =C2=A0There are many words in English that cannot
> be written using the traditional "preferred name syntax" (often
> called "LDH") rules. =C2=A0There are also many family names, business
> names, and so on that cannot be used. =C2=A0While IDNs permit use of
> many characters that are not part of the basic Latin-derived
> alphabet, they don't change the fundamental principle that
> something being a valid word or phrase in a language does not
> create an automatic "right" to have it as a domain name.
> Instead, almost every decision as to what strings should be
> permitted to be used as labels within a given zone represents a
> tradeoff (either globally across zones or within a particular
> zone) because the desire to use a particular string as a
> mnemonic label and the risks that string might create when used
> for Internet references.
>
> The characters listed as CONTEXTJ and CONTEXTO are inherently
> tricky. =C2=A0Used in the wrong context, they produce labels that
> don't compare equal but that have exactly the same appearance.
> To avoid those and other problems, the 2003 version of IDNA
> excluded them entirely from IDNs using the "map to nothing"
> technique that we now recognize as creating dangerous
> ambiguities. =C2=A0While we decided to permit them in appropriate
> contexts in IDOA2008, the reality is that the contextual rules
> themselves aren't adequate without additional restrictions that
> go beyond anything we can do as a DNS or IDNA technical matter.
>
> If one were using, e.g., Persian strings in a domain whose use
> is largely limited to mnemonics derived from Persian and almost
> certain to be treated as Persian writing style and rendered with
> Persian-specific rendering engines, then there should be little
> problem using ZWJ and ZWNJ. =C2=A0That situation would exist, or at
> least be manageable, in .IR and any Arabic script (and
> Persian-language-derived) variation on that name. =C2=A0 But the root
> zone (and hence TLD names) are inherently problematic because it
> has to available for labels in all scripts and because neither
> languages nor writing style can be encoded reliably in the DNS
> (at least without causing lots of other problems). =C2=A0However, if
> a Persian string containing ZWNJ were rendered either by a
> rendering engine designed for the Arabic language (or one that
> was simply naive about Arabic script), the resulting situation
> would be an invitation to phishing, to fraudulent certificates,
> and so on.
>
> So, while permitting ZWNJ (and ZWJ) in top-level domain names
> seems attractive, it is not safe -- much less safe than
> permitting the PVALID characters that are always displayed.
> Striking the balance between safety and the desire to be able to
> include all mnemonics based on any language in the world will
> always be a difficult choice and, ultimately, a policy one, but,
> as long as the community believes that security, stability, and
> predictable behavior take precedence over the use of any given
> character in any given script, decisions that exclude
> problematic characters from the root will continue to be
> justified.
>
> best regards,
> =C2=A0 john
>
>
>
>
>
>
>
>



--=20
=C2=A0=C2=A0 =C2=A0'=C2=A0 =C2=A0=C2=A0 =D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8=
=A7=D8=B3=D9=81=D9=87=D8=A8=D8=AF
=C2=A0 =C2=A0 '=C2=A0 =C2=A0=C2=A0 Behnam Esfahbod
=C2=A0=C2=A0 '=C2=A0 =C2=A0 =C2=A0 http://behnam.esfahbod.info
=C2=A0 *=C2=A0 ..=C2=A0=C2=A0 http://zwnj.org/
=C2=A0*=C2=A0 `=C2=A0 *=C2=A0 http://persian-computing.ir
=C2=A0 * o *=C2=A0=C2=A0 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B

From patrik@frobbit.se  Mon Jul 18 22:25:50 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E3821F85EE for ; Mon, 18 Jul 2011 22:25:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level: 
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.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 qZHYNAGvJx0U for ; Mon, 18 Jul 2011 22:25:49 -0700 (PDT)
Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 7198E21F85F6 for ; Mon, 18 Jul 2011 22:25:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 4AEA61184B931; Tue, 19 Jul 2011 07:25:46 +0200 (CEST)
X-Virus-Scanned: amavisd-new at frobbit.se
Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWIcN45H6xpB; Tue, 19 Jul 2011 07:25:46 +0200 (CEST)
Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 12A0F1184B92E; Tue, 19 Jul 2011 07:25:46 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
In-Reply-To: 
Date: Tue, 19 Jul 2011 07:25:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5AC1318B-A219-4056-BD14-C90BEE85669E@frobbit.se>
References:  
To: Behnam Esfahbod 
X-Mailer: Apple Mail (2.1084)
Cc: apps-discuss 
Subject: Re: [apps-discuss] CONTEXTJ in TLD DNS-Labels (draft-liman-tld-names-05)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2011 05:25:50 -0000

On 19 jul 2011, at 03.01, Behnam Esfahbod wrote:

> 2. If ZWNJ is claimed to cause confusion and phishing problems beyond =
what is
>   normally acceptable for other symbols, it is up to the claimants to
>   demonstrate this claim.

Actually, no.

When discussing security and stability of the Internet as a whole, it is =
the other way around. The first general principle is to ensure you do no =
harm. Then one can discuss whether the change is actually valuable.

So the burden of convincing the community is on the ones that do think a =
character like ZWNJ is to be allowed or not that the need for the =
character is greater than the potential harm in _any_ context it might =
be used in.

Yes, I am chair of ICANN Security and Stability Advisory Committee, and =
this I say is just a hint of what kind of statement and question will be =
asked when/if a proposal about the use of ZWNJ will actually reach ICANN =
pdp. This statement of mine does not of course preclude any kind of =
potential SSAC statement. Just a hint of what questions SSAC might ask.

For the rest of your points, including how difficult this discussion has =
ended up being -- I agree with you.

   Patrik


From john-ietf@jck.com  Tue Jul 19 06:24:07 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2873E21F87A4 for ; Tue, 19 Jul 2011 06:24:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.634
X-Spam-Level: 
X-Spam-Status: No, score=-102.634 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, 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 X1A2WFgxGszA for ; Tue, 19 Jul 2011 06:24:06 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 5194521F85A7 for ; Tue, 19 Jul 2011 06:24:06 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QjAHM-000Ans-Uu; Tue, 19 Jul 2011 09:24:05 -0400
Date: Tue, 19 Jul 2011 09:24:04 -0400
From: John C Klensin 
To: Behnam Esfahbod 
Message-ID: <85FB14D637D54FBC5A95D68E@PST.JCK.COM>
In-Reply-To: 
References:  
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: apps-discuss 
Subject: Re: [apps-discuss] CONTEXTJ in TLD DNS-Labels (draft-liman-tld-names-05)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2011 13:24:07 -0000

Behnam,

I'm sorry I was not clear.   Let me try again, first by
reference to Patrik's comment: independent of how ICANN has
formulated the variant investigation, the question remains "what
is safe across all scripts" and not "what does a particular
language need".  The ASCII ("English") examples were not
intended to justify the situation, only to point out that
restrictions have been with us for a very long time and that one
of those restrictions is that a string being a valid word in
some language does not create an entitlement to use that string
as a DNS label... and never has.  In retrospect, the terms
"domain name system", and the earlier "hostname" are misleading.
Precision would have called for substituting something like
"mneumonic" for "name".

Second, while your detailed explanation is appreciated, we fully
understand the importance of ZWNJ to writing Persian (and most
non-Arabic language use of Arabic script) and, although the use
is a little different, the importance of ZWNJ and ZWJ in writing
most Indic scripts.  CONTEXTJ was not included in IDNA2008 by
some magical accident: we (including both Patrik and myself)
fought to include it in the standard precisely to facilitate
those uses.

But, examples, explanations, and language requirements aside,
the issue remains one of whether those characters are safe in
the root.  With the understanding that this is just my opinion,
part of that safety evaluation is that the root zone almost
certainly should have a clear and simple set of rules, rules
that are easily checked and enforced by the various types of
(language-independent) software that call on the DNS.  While one
could imagine a large collection of rules based on a model of
"determine the script, guess at the language, and then interpret
and render accordingly", it is almost certainly not feasible
even if ICANN agrees to use self-discipline about single-script
labels.  First, the DNS and IDNA do not support explicit
language information and heuristics to determine language that
work well with moderate or large blocks of text are not reliable
when strings are only a few characters long.  Second, and
equally important, we know that complex procedures based on
layers of tables are rarely implemented correctly.

So, again returning to one of the implications of Patrik's note:
please assume that we understand the importance of this
character to most of the languages that use Arabic script (and
to most of the languages that use several of the Indic scripts)
and that, in case knowing this is helpful, we understood it long
before ICANN created the VIP program.  We also understand its
importance regardless of how (or whether) "variants" (whatever
that means in the general case) are supported.  The question is
whether the use of characters that, among other things, become
invisible if the wrong rendering engine is chosen, is safe in a
root context or can be made safe by a plausible, understandable,
and, if appropriate, enforceable set of rules.

regards,
   john




--On Monday, July 18, 2011 21:01 -0400 Behnam Esfahbod
 wrote:

> Hi John,
> 
> I think it is time to stop general pronouncements that have
> been repeated and repeated so many times over these past years
> and get down to specifics.  Here are two very concrete points
> you should note:
> 
> 1. ZWNJ is not a special quirk of Persian language, it is not
> a mnemonic tool,    nor is it an optional writing-style
> device.  ZWNJ is used in the writing of    MOST languages
>...


From paul.hoffman@vpnc.org  Tue Jul 19 07:56:08 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9825D21F889D for ; Tue, 19 Jul 2011 07:56:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.494
X-Spam-Level: 
X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, MIME_8BIT_HEADER=0.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 YuIN1YOVT5sD for ; Tue, 19 Jul 2011 07:56:08 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9343C21F873D for ; Tue, 19 Jul 2011 07:56:03 -0700 (PDT)
Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6JEtVvO023893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Jul 2011 07:55:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Paul Hoffman 
In-Reply-To: <5AC1318B-A219-4056-BD14-C90BEE85669E@frobbit.se>
Date: Tue, 19 Jul 2011 07:55:44 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <8159C20D-BF2B-42CB-9529-C870A2AD1572@vpnc.org>
References:   <5AC1318B-A219-4056-BD14-C90BEE85669E@frobbit.se>
To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
X-Mailer: Apple Mail (2.1084)
Cc: apps-discuss 
Subject: Re: [apps-discuss] CONTEXTJ in TLD DNS-Labels (draft-liman-tld-names-05)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2011 14:56:08 -0000

On Jul 18, 2011, at 10:25 PM, Patrik F=E4ltstr=F6m wrote:

> On 19 jul 2011, at 03.01, Behnam Esfahbod wrote:
>=20
>> 2. If ZWNJ is claimed to cause confusion and phishing problems beyond =
what is
>>  normally acceptable for other symbols, it is up to the claimants to
>>  demonstrate this claim.
>=20
> Actually, no.
>=20
> When discussing security and stability of the Internet as a whole, it =
is the other way around. The first general principle is to ensure you do =
no harm. Then one can discuss whether the change is actually valuable.
>=20
> So the burden of convincing the community is on the ones that do think =
a character like ZWNJ is to be allowed or not that the need for the =
character is greater than the potential harm in _any_ context it might =
be used in.

I am going to push back here, hard. The draft is about names used in =
exactly one zone, and that zone has exactly one administrator. Your =
statement about "_any_ context" is inappropriate for this draft.

As a zone administrator considers what it can safely put in its zone, it =
follows policies. Most zone administrators in the world have no policies =
whatsoever, and thus the IETF should make it less likely that they will =
do something dangerous. However, that is not a concern for this zone =
administrator. They have policies up the wazoo and literally hundreds =
(probably thousands) of people helping make those policies and being =
sure they are implemented.

So, for this draft, restrictions that are being made because that one =
administrator might make an unnoticed mistake are harmful. It is fine to =
give advice about security and stability; in fact, Patrik is already =
doing this in his role on SSAC. This draft, however, is exactly the =
wrong place to make statements that apply to any zone other than the one =
in the title.

Bullet points 2 and 3 in section 4 should be removed.

--Paul Hoffman


From john-ietf@jck.com  Tue Jul 19 10:53:54 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A75121F87C2 for ; Tue, 19 Jul 2011 10:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.481
X-Spam-Level: 
X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, MIME_8BIT_HEADER=0.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 6Qb4cPG1jDrU for ; Tue, 19 Jul 2011 10:53:54 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id B978421F87C5 for ; Tue, 19 Jul 2011 10:53:53 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QjEUL-000EkJ-8g; Tue, 19 Jul 2011 13:53:45 -0400
Date: Tue, 19 Jul 2011 13:53:44 -0400
From: John C Klensin 
To: Paul Hoffman , =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= 
Message-ID: <2E21B740FDAB4C150B4BB2FE@PST.JCK.COM>
In-Reply-To: <8159C20D-BF2B-42CB-9529-C870A2AD1572@vpnc.org>
References:   <5AC1318B-A219-4056-BD14-C90BEE85669E@frobbit.se> <8159C20D-BF2B-42CB-9529-C870A2AD1572@vpnc.org>
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: apps-discuss 
Subject: Re: [apps-discuss] CONTEXTJ in TLD DNS-Labels	(draft-liman-tld-names-05)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2011 17:53:54 -0000

--On Tuesday, July 19, 2011 07:55 -0700 Paul Hoffman
 wrote:

>...
>>> 2. If ZWNJ is claimed to cause confusion and phishing
>>> problems beyond what is normally acceptable for other
>>>  symbols, it is up to the claimants to demonstrate this
>>>  claim.
>> 
>> Actually, no.
>...

> I am going to push back here, hard. The draft is about names
> used in exactly one zone, and that zone has exactly one
> administrator. Your statement about "_any_ context" is
> inappropriate for this draft.

That zone is also the root.   While asking narrow questions
about the "can you put something in and get it back out"
performance of the DNS produces a different answer, any
considerations of actually being able to use the DNS to navigate
the Internet do make the root particularly important and
different.  In particular, while one can imagine blacklisting an
entire TLD because of bad policies or bad behavior, the only way
to do that to the root is to find, organize, or configure an
alternate root.

> As a zone administrator considers what it can safely put in
> its zone, it follows policies. Most zone administrators in the
> world have no policies whatsoever, and thus the IETF should
> make it less likely that they will do something dangerous.
> However, that is not a concern for this zone administrator.
> They have policies up the wazoo and literally hundreds
> (probably thousands) of people helping make those policies and
> being sure they are implemented.

Hmm.  I don't know if you have been following the activities of
that particular zone administrator, but, its policies are
rarely, if ever, enforced.  In particular, top-level domains
(root entries) that have been created with restrictions on use
who have then decided to eliminate those restrictions have, as
far as I know without exception, been permitted to make those
changes.   The problem is especially severe with any TLD that
can claim linkage to a government because claims are made of
national sovereignty and the impossibility of applying or
enforcing any policy the zone administration doesn't like.

> So, for this draft, restrictions that are being made because
> that one administrator might make an unnoticed mistake are
> harmful. It is fine to give advice about security and
> stability; in fact, Patrik is already doing this in his role
> on SSAC. This draft, however, is exactly the wrong place to
> make statements that apply to any zone other than the one in
> the title.

Just to keep this in context, note that these restrictions are
not new or unique to the current zone adminstrator.  They are
relaxations of restrictions that go back well over 20 years.

     john



From patrik@frobbit.se  Tue Jul 19 11:04:17 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A65B11E807F for ; Tue, 19 Jul 2011 11:04:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level: 
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.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 Yd4iF2AP7D8p for ; Tue, 19 Jul 2011 11:04:17 -0700 (PDT)
Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 87E9111E807A for ; Tue, 19 Jul 2011 11:04:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 9DF4C1185CD7C; Tue, 19 Jul 2011 20:04:15 +0200 (CEST)
X-Virus-Scanned: amavisd-new at frobbit.se
Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3YzWG8GRfBn; Tue, 19 Jul 2011 20:04:15 +0200 (CEST)
Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 1DF791185BF34; Tue, 19 Jul 2011 19:26:49 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
In-Reply-To: <8159C20D-BF2B-42CB-9529-C870A2AD1572@vpnc.org>
Date: Tue, 19 Jul 2011 19:26:48 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <5AC1318B-A219-4056-BD14-C90BEE85669E@frobbit.se> <8159C20D-BF2B-42CB-9529-C870A2AD1572@vpnc.org>
To: Paul Hoffman 
X-Mailer: Apple Mail (2.1084)
Cc: apps-discuss 
Subject: Re: [apps-discuss] CONTEXTJ in TLD DNS-Labels (draft-liman-tld-names-05)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2011 18:04:17 -0000

On 19 jul 2011, at 16.55, Paul Hoffman wrote:

>> So the burden of convincing the community is on the ones that do =
think a character like ZWNJ is to be allowed or not that the need for =
the character is greater than the potential harm in _any_ context it =
might be used in.
>=20
> I am going to push back here, hard. The draft is about names used in =
exactly one zone, and that zone has exactly one administrator. Your =
statement about "_any_ context" is inappropriate for this draft.

We just misunderstand each other.

Yes, this is about only this zone, so what I meant with "_any_ context" =
was still "within this single, very special zone".

So not really "_any_".

But, as John wrote, together with any character, regardless of language, =
etc...that was what I intended to mean by "_any_ context".

Still in THIS zone, the root zone.

   Patrik


From stpeter@stpeter.im  Tue Jul 19 11:48:46 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE2621F8507 for ; Tue, 19 Jul 2011 11:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.752
X-Spam-Level: 
X-Spam-Status: No, score=-102.752 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, 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 HlvwoLTh35er for ; Tue, 19 Jul 2011 11:48:42 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 33A1C21F850E for ; Tue, 19 Jul 2011 11:48:42 -0700 (PDT)
Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E301B4005A for ; Tue, 19 Jul 2011 12:49:20 -0600 (MDT)
Message-ID: <4E25D187.7010901@stpeter.im>
Date: Tue, 19 Jul 2011 12:48:39 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2011 18:48:46 -0000

You might have noticed a curious item on the agenda at 14:00 on Sunday: 
"Apps Area Preparatory Meeting for Internationalization Working Groups".

At that time, I will present an introduction to internationalization, 
assisted by Pete Resnick (who will correct me where I go wrong). The 
intent of this session is to help apps-area folks learn more about 
internationalization, especially in preparation for the PRECIS WG 
meeting on Thursday. The room we've been assigned (2103) holds up to 60 
people so we should have plenty of space, and there is no need to sign 
up if you want to attend.

If this session goes well, Pete and I might offer a more general 
tutorial at a future IETF meeting. Consider Sunday's session a dry run.

See you in Quebec City!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From stpeter@stpeter.im  Tue Jul 19 12:20:59 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A80221F8581 for ; Tue, 19 Jul 2011 12:20:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.724
X-Spam-Level: 
X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, 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 gg4KD4dKYU7I for ; Tue, 19 Jul 2011 12:20:31 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id ADD2521F8563 for ; Tue, 19 Jul 2011 12:20:31 -0700 (PDT)
Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9E5024005A for ; Tue, 19 Jul 2011 13:21:11 -0600 (MDT)
Message-ID: <4E25D8FE.9030402@stpeter.im>
Date: Tue, 19 Jul 2011 13:20:30 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <4E25D187.7010901@stpeter.im>
In-Reply-To: <4E25D187.7010901@stpeter.im>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2011 19:20:59 -0000

On 7/19/11 12:48 PM, Peter Saint-Andre wrote:
> You might have noticed a curious item on the agenda at 14:00 on Sunday:
> "Apps Area Preparatory Meeting for Internationalization Working Groups".
>
> At that time, I will present an introduction to internationalization,
> assisted by Pete Resnick (who will correct me where I go wrong). The
> intent of this session is to help apps-area folks learn more about
> internationalization, especially in preparation for the PRECIS WG
> meeting on Thursday. The room we've been assigned (2103) holds up to 60
> people so we should have plenty of space, and there is no need to sign
> up if you want to attend.
>
> If this session goes well, Pete and I might offer a more general
> tutorial at a future IETF meeting. Consider Sunday's session a dry run.

Sorry, I neglected to provide a pointer to my slides:

http://www.saint-andre.com/ietf/i18n-intro.pdf

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From paul.hoffman@vpnc.org  Tue Jul 19 12:46:42 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDECF21F8784 for ; Tue, 19 Jul 2011 12:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.639
X-Spam-Level: 
X-Spam-Status: No, score=-102.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, 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 gwZlXvG4a+JL for ; Tue, 19 Jul 2011 12:46:42 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C3A6521F8786 for ; Tue, 19 Jul 2011 12:46:41 -0700 (PDT)
Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6JJkMup038651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Jul 2011 12:46:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman 
In-Reply-To: <2E21B740FDAB4C150B4BB2FE@PST.JCK.COM>
Date: Tue, 19 Jul 2011 12:46:35 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <5AC1318B-A219-4056-BD14-C90BEE85669E@frobbit.se> <8159C20D-BF2B-42CB-9529-C870A2AD1572@vpnc.org> <2E21B740FDAB4C150B4BB2FE@PST.JCK.COM>
To: John C Klensin 
X-Mailer: Apple Mail (2.1084)
Cc: apps-discuss 
Subject: Re: [apps-discuss] CONTEXTJ in TLD DNS-Labels	(draft-liman-tld-names-05)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2011 19:46:43 -0000

On Jul 19, 2011, at 10:53 AM, John C Klensin wrote:

> --On Tuesday, July 19, 2011 07:55 -0700 Paul Hoffman
>  wrote:
>> I am going to push back here, hard. The draft is about names
>> used in exactly one zone, and that zone has exactly one
>> administrator. Your statement about "_any_ context" is
>> inappropriate for this draft.
>=20
> That zone is also the root.   While asking narrow questions
> about the "can you put something in and get it back out"
> performance of the DNS produces a different answer, any
> considerations of actually being able to use the DNS to navigate
> the Internet do make the root particularly important and
> different. =20

True, and completely irrelevant to *this* discussion.  We are discussing =
restricting some characters from an encoded form. How does that affect =
"actually being able to use the DNS"?

> In particular, while one can imagine blacklisting an
> entire TLD because of bad policies or bad behavior, the only way
> to do that to the root is to find, organize, or configure an
> alternate root.

And, as you say below, you truly don't like the way ICANN makes and =
enforces policies. The rest of live with them, usually with less =
complaining.

>=20
>> As a zone administrator considers what it can safely put in
>> its zone, it follows policies. Most zone administrators in the
>> world have no policies whatsoever, and thus the IETF should
>> make it less likely that they will do something dangerous.
>> However, that is not a concern for this zone administrator.
>> They have policies up the wazoo and literally hundreds
>> (probably thousands) of people helping make those policies and
>> being sure they are implemented.
>=20
> Hmm.  I don't know if you have been following the activities of
> that particular zone administrator, but, its policies are
> rarely, if ever, enforced. =20

Stating a policy and not enforcing it is making another policy. Again, =
it is irrelevant to this discussion.

> In particular, top-level domains
> (root entries) that have been created with restrictions on use
> who have then decided to eliminate those restrictions have, as
> far as I know without exception, been permitted to make those
> changes.   The problem is especially severe with any TLD that
> can claim linkage to a government because claims are made of
> national sovereignty and the impossibility of applying or
> enforcing any policy the zone administration doesn't like.

That can't be your whole list of things that have nothing to do with =
this draft that you dislike about ICANN. Please go on. :-(

>> So, for this draft, restrictions that are being made because
>> that one administrator might make an unnoticed mistake are
>> harmful. It is fine to give advice about security and
>> stability; in fact, Patrik is already doing this in his role
>> on SSAC. This draft, however, is exactly the wrong place to
>> make statements that apply to any zone other than the one in
>> the title.
>=20
> Just to keep this in context, note that these restrictions are
> not new or unique to the current zone adminstrator.  They are
> relaxations of restrictions that go back well over 20 years.

Hogwash. Those restrictions have *never* been part of the DNS protocol. =
Nothing in those two restrictions affect the DNS at all, only the way =
that some people interpret some DNS strings in applications. The design =
of both IDNA2003 and IDNA2008 insulate the DNS from this.

To be more blunt, the restrictions in this draft imply that the protocol =
of which you are co-author sucks badly: you either left out of the =
protocol "these characters are unsafe" or you left out "there are =
special rules that apply to the root zone".

I don't believe either is true. The protocol we all worked on is just =
fine. You, and we, didn't leave anything out. Trying to jam this into =
the DNS after the fact is just wrong. It's fine if ICANN wants to make =
its own policy on this; it is wrong for the IETF to pretend that this is =
our policy that we forgot to put in IDNA2008.

--Paul Hoffman


From paul.hoffman@vpnc.org  Tue Jul 19 12:49:20 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A400821F87A4 for ; Tue, 19 Jul 2011 12:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.488
X-Spam-Level: 
X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, MIME_8BIT_HEADER=0.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 Fi4PwO+3cGf6 for ; Tue, 19 Jul 2011 12:49:20 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D66A421F8786 for ; Tue, 19 Jul 2011 12:49:19 -0700 (PDT)
Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6JJn37d038789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Jul 2011 12:49:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Paul Hoffman 
In-Reply-To: 
Date: Tue, 19 Jul 2011 12:49:15 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <5AC1318B-A219-4056-BD14-C90BEE85669E@frobbit.se> <8159C20D-BF2B-42CB-9529-C870A2AD1572@vpnc.org> 
To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
X-Mailer: Apple Mail (2.1084)
Cc: apps-discuss 
Subject: Re: [apps-discuss] CONTEXTJ in TLD DNS-Labels (draft-liman-tld-names-05)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2011 19:49:20 -0000

On Jul 19, 2011, at 10:26 AM, Patrik F=E4ltstr=F6m wrote:

>=20
> On 19 jul 2011, at 16.55, Paul Hoffman wrote:
>=20
>>> So the burden of convincing the community is on the ones that do =
think a character like ZWNJ is to be allowed or not that the need for =
the character is greater than the potential harm in _any_ context it =
might be used in.
>>=20
>> I am going to push back here, hard. The draft is about names used in =
exactly one zone, and that zone has exactly one administrator. Your =
statement about "_any_ context" is inappropriate for this draft.
>=20
> We just misunderstand each other.
>=20
> Yes, this is about only this zone, so what I meant with "_any_ =
context" was still "within this single, very special zone".
>=20
> So not really "_any_".

Ah, good.

> But, as John wrote, together with any character, regardless of =
language, etc...that was what I intended to mean by "_any_ context".
>=20
> Still in THIS zone, the root zone.


We have already seen the perceived need for these characters in the root =
zone, and we have not seen any statement of how they can cause harm *in =
the root zone*. "Phishing" in the root zone, given the horrendous weight =
of the process for getting new names put in the root zone, is not a =
threat. Which others do you believe that need to be weighed against the =
value of the characters?

--Paul Hoffman


From john-ietf@jck.com  Tue Jul 19 13:00:54 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDB921F87C2 for ; Tue, 19 Jul 2011 13:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.625
X-Spam-Level: 
X-Spam-Status: No, score=-102.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, 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 c4cwjPoFCSpZ for ; Tue, 19 Jul 2011 13:00:49 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 6566721F87A4 for ; Tue, 19 Jul 2011 13:00:49 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QjGTI-000Gka-Hy; Tue, 19 Jul 2011 16:00:48 -0400
Date: Tue, 19 Jul 2011 16:00:47 -0400
From: John C Klensin 
To: Peter Saint-Andre , apps-discuss@ietf.org
Message-ID: 
In-Reply-To: <4E25D8FE.9030402@stpeter.im>
References: <4E25D187.7010901@stpeter.im> <4E25D8FE.9030402@stpeter.im>
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: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2011 20:00:54 -0000

--On Tuesday, July 19, 2011 13:20 -0600 Peter Saint-Andre
 wrote:

> On 7/19/11 12:48 PM, Peter Saint-Andre wrote:
>> You might have noticed a curious item on the agenda at 14:00
>> on Sunday: "Apps Area Preparatory Meeting for
>> Internationalization Working Groups".
>...
> Sorry, I neglected to provide a pointer to my slides:
> 
> http://www.saint-andre.com/ietf/i18n-intro.pdf

197 slides?  YMBK.

And, by the way, in the beginning, depending on where you start
counting, there were BCD, BAUDOT, and a few other things,
including, arguably, Morse Code.  In a different vocabulary
consider ITU Recommendation T.50, aka International Alphabet 5
(IA5 or IRA5), whose original version corresponded to ISO 646,
whose IRV is essentially ASCII.  It wasn't designated as IA5
because "5" was a nice number -- there were four predecessors
including Recommendation S.1 for ITA2.  :-)

More follows offlist...

   john






From stpeter@stpeter.im  Tue Jul 19 13:33:44 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2811E21F8B30 for ; Tue, 19 Jul 2011 13:33:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.72
X-Spam-Level: 
X-Spam-Status: No, score=-102.72 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, 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 ryuvrqd3dc46 for ; Tue, 19 Jul 2011 13:33:39 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8309B21F8B2C for ; Tue, 19 Jul 2011 13:33:39 -0700 (PDT)
Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 70BED4005A; Tue, 19 Jul 2011 14:34:19 -0600 (MDT)
Message-ID: <4E25EA21.9090207@stpeter.im>
Date: Tue, 19 Jul 2011 14:33:37 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: John C Klensin 
References: <4E25D187.7010901@stpeter.im> <4E25D8FE.9030402@stpeter.im> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2011 20:33:44 -0000

On 7/19/11 2:00 PM, John C Klensin wrote:
>
>
> --On Tuesday, July 19, 2011 13:20 -0600 Peter Saint-Andre
>   wrote:
>
>> On 7/19/11 12:48 PM, Peter Saint-Andre wrote:
>>> You might have noticed a curious item on the agenda at 14:00
>>> on Sunday: "Apps Area Preparatory Meeting for
>>> Internationalization Working Groups".
>> ...
>> Sorry, I neglected to provide a pointer to my slides:
>>
>> http://www.saint-andre.com/ietf/i18n-intro.pdf
>
> 197 slides?  YMBK.

Why must I be kidding? I presented much the same slides at the XMPP WG 
interim meeting back in February, and we had a productive session.

> And, by the way, in the beginning, depending on where you start
> counting, there were BCD, BAUDOT, and a few other things,
> including, arguably, Morse Code.  In a different vocabulary
> consider ITU Recommendation T.50, aka International Alphabet 5
> (IA5 or IRA5), whose original version corresponded to ISO 646,
> whose IRV is essentially ASCII.  It wasn't designated as IA5
> because "5" was a nice number -- there were four predecessors
> including Recommendation S.1 for ITA2.  :-)

These slides are not meant to be comprehensive, just a friendly 
introduction to some key topics.

> More follows offlist...

As always, feedback is welcome.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From patrik@frobbit.se  Tue Jul 19 23:34:08 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7896721F8B2F for ; Tue, 19 Jul 2011 23:34:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level: 
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.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 mwSCXDkExGIP for ; Tue, 19 Jul 2011 23:34:08 -0700 (PDT)
Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id B694F21F8B2E for ; Tue, 19 Jul 2011 23:34:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 9C8871186AA56; Wed, 20 Jul 2011 08:34:05 +0200 (CEST)
X-Virus-Scanned: amavisd-new at frobbit.se
Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Di2WpdEicbKT; Wed, 20 Jul 2011 08:34:05 +0200 (CEST)
Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 2559A1186AA53; Wed, 20 Jul 2011 08:34:05 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
In-Reply-To: 
Date: Wed, 20 Jul 2011 08:34:04 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <640EE2B8-AB0B-40E5-9815-4A6A5E20FA79@frobbit.se>
References:   <5AC1318B-A219-4056-BD14-C90BEE85669E@frobbit.se> <8159C20D-BF2B-42CB-9529-C870A2AD1572@vpnc.org>  
To: Paul Hoffman 
X-Mailer: Apple Mail (2.1084)
Cc: apps-discuss 
Subject: Re: [apps-discuss] CONTEXTJ in TLD DNS-Labels (draft-liman-tld-names-05)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2011 06:34:08 -0000

On 19 jul 2011, at 21.49, Paul Hoffman wrote:

> We have already seen the perceived need for these characters in the =
root zone, and we have not seen any statement of how they can cause harm =
*in the root zone*. "Phishing" in the root zone, given the horrendous =
weight of the process for getting new names put in the root zone, is not =
a threat. Which others do you believe that need to be weighed against =
the value of the characters?

Yes, phishing in the root zone. People putting URLs on web pages that =
you click on.

It is tons of code easier in various applications to "know" that a code =
point is either allowed or not allowed in the TLD than having context =
dependent rules that otherwise is the option.

So the question is whether security software can filter out URLs with =
ZWNJ in the TLD as dangerous or not.

   Patrik


From duerst@it.aoyama.ac.jp  Wed Jul 20 00:42:04 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7F021F8A56 for ; Wed, 20 Jul 2011 00:42:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.751
X-Spam-Level: 
X-Spam-Status: No, score=-99.751 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.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 NzFCJ8DALWh3 for ; Wed, 20 Jul 2011 00:42:00 -0700 (PDT)
Received: from acintmta01.acbb.aoyama.ac.jp (acintmta01.acbb.aoyama.ac.jp [133.2.20.33]) by ietfa.amsl.com (Postfix) with ESMTP id 80A2821F889F for ; Wed, 20 Jul 2011 00:41:53 -0700 (PDT)
Received: from acmse01.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta01.acbb.aoyama.ac.jp (secret/secret) with SMTP id p6K7fiZw020396 for ; Wed, 20 Jul 2011 16:41:45 +0900
Received: from (unknown [133.2.206.133]) by acmse01.acbb.aoyama.ac.jp with smtp id 5574_3839_b788208a_b2a3_11e0_a54d_001d096c5b62; Wed, 20 Jul 2011 16:41:44 +0900
Received: from [IPv6:::1] ([133.2.210.5]:55352) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Wed, 20 Jul 2011 16:41:44 +0900
Message-ID: <4E268688.9040209@it.aoyama.ac.jp>
Date: Wed, 20 Jul 2011 16:40:56 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= 
References: 		<5AC1318B-A219-4056-BD14-C90BEE85669E@frobbit.se>	<8159C20D-BF2B-42CB-9529-C870A2AD1572@vpnc.org>		 <640EE2B8-AB0B-40E5-9815-4A6A5E20FA79@frobbit.se>
In-Reply-To: <640EE2B8-AB0B-40E5-9815-4A6A5E20FA79@frobbit.se>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Paul Hoffman , apps-discuss 
Subject: Re: [apps-discuss] CONTEXTJ in TLD DNS-Labels (draft-liman-tld-names-05)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2011 07:42:04 -0000

On 2011/07/20 15:34, Patrik Fältström wrote:
>
> On 19 jul 2011, at 21.49, Paul Hoffman wrote:
>
>> We have already seen the perceived need for these characters in the root zone, and we have not seen any statement of how they can cause harm *in the root zone*. "Phishing" in the root zone, given the horrendous weight of the process for getting new names put in the root zone, is not a threat. Which others do you believe that need to be weighed against the value of the characters?
>
> Yes, phishing in the root zone. People putting URLs on web pages that you click on.
>
> It is tons of code easier in various applications to "know" that a code point is either allowed or not allowed in the TLD than having context dependent rules that otherwise is the option.
>
> So the question is whether security software can filter out URLs with ZWNJ in the TLD as dangerous or not.

I'm with Paul on this here. The root zone is really special. Look at .py 
(Paraguay) vs. .ру (Cyrillic, .ru when transliterated to Latin, probably 
the first candidate everybody was thinking about for Russia) and .рф 
(Cyrillic again, .rf when transliterated, standing for 'Russian 
Federation').

Phishing wasn't avoided by any specific rule except "check 
manually/visually if there's a potential for confusion, and if there is, 
try something else".

Labels in a TLD postition that contain a ZWNJ are either existing in the 
root zone, or they are not. If they are not actually existing in the 
root zone, then there is no danger of phishing. If they are actually 
existing, then they either have been checked using the rule in the 
previous paragraph, or they haven't been checked. If they have been 
checked, then they can't be used for phishing (*). If they haven't been 
checked, then there's a potential for phishing, but that's because due 
diligence was neglected, completely independent of ZWNJ.

The draft in question basically says: "We had this implicit rule that 
TLDs don't contain digits or hyphens. For IDNs, we need to relax it on 
the A-Label level, but introduce it on the U-Label level." It then goes 
and translates that into "general category { Ll, Lo, Lm, Mn }". This 
essentially means that virtually nobody in the IETF or ICANN (and very 
few people on the Unicode side) can understand that, or can judge the 
consequences. Also, while I don't think there is any need whatsoever to 
have TLDs with digits in them, I don't really see any technical need to 
prohibit those (except for all-digit TLDs, which would be a really bad 
idea).

Regards,   Martin.


(*) There's also the case that people confuse totally different things 
by accident and get phished that way. An example would be somebody 
spamming www.aoyama.ac.jp with www.aoyama.ac.ja (jp vs. ja). But this 
kind of stuff is already possible now, and excluding ZWNJ doesn't make 
it better.

From nsb@guppylake.com  Wed Jul 20 00:50:25 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A053721F881C for ; Wed, 20 Jul 2011 00:50:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.291
X-Spam-Level: 
X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.307,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 wZlaDAVtoyXG for ; Wed, 20 Jul 2011 00:50:21 -0700 (PDT)
Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id EEE7821F872F for ; Wed, 20 Jul 2011 00:50:20 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=guppylake.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer; b=tDHFtKKKb/Mmz6bSF9i6Dmk2S1A7vcX3rTJQ5r7TH1EfdvwOktSf4fSBKGevRlfuAWGGS9j2N8iNKUz82AQ2950QSLHgbRbVl6k40CmWotMw/ns+Ttvk2JoDQwS7HMjs;
Received: from host-39-196-68-109.spectrum1.uk.sharedband.net ([109.68.196.39] helo=[10.1.0.227]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1QjRXq-0004kf-0s; Wed, 20 Jul 2011 03:50:16 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-741--18954789
From: Nathaniel Borenstein 
In-Reply-To: 
Date: Wed, 20 Jul 2011 08:50:10 +0100
Message-Id: 
References: <4E25D187.7010901@stpeter.im> <4E25D8FE.9030402@stpeter.im> 
To: John C Klensin 
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server1.netnutz.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - guppylake.com
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2011 07:50:25 -0000

--Apple-Mail-741--18954789
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Jul 19, 2011, at 9:00 PM, John C Klensin wrote:

>> http://www.saint-andre.com/ietf/i18n-intro.pdf
>=20
> 197 slides?  YMBK.

Yes, this is clearly far too complex an area to cover in only 197 =
slides, but perhaps as a simplified introduction.....

And no, I'm not joking (for once).

I for one am very grateful that you (Pete*) are doing this, and look =
forward to finally achieving internationalization enlightenment.  -- =
Nathaniel=

--Apple-Mail-741--18954789
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


http://www.saint-a=
ndre.com/ietf/i18n-intro.pdf

197 slides? =
 YMBK.

Yes, this is clearly far =
too complex an area to cover in only 197 slides, but perhaps as a =
simplified introduction.....

And no, I'm not =
joking (for once).

I for one am very grateful =
that you (Pete*) are doing this, and look forward to finally achieving =
internationalization enlightenment.  -- =
Nathaniel
=

--Apple-Mail-741--18954789--

From mnot@mnot.net  Wed Jul 20 03:35:29 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9B221F86D7; Wed, 20 Jul 2011 03:35:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.767
X-Spam-Level: 
X-Spam-Status: No, score=-105.767 tagged_above=-999 required=5 tests=[AWL=-3.168, BAYES_00=-2.599, 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 nRT4e3BI8Lca; Wed, 20 Jul 2011 03:35:28 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id AF2EA21F86E0; Wed, 20 Jul 2011 03:35:28 -0700 (PDT)
Received: from chancetrain-lm.mnot.net (unknown [118.209.98.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3388C509DB; Wed, 20 Jul 2011 06:35:21 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: Mark Nottingham 
Date: Wed, 20 Jul 2011 20:35:18 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <5FA6AD59-7570-4A85-B6D1-3DC8E42688F1@mnot.net>
To: http-auth@ietf.org, Alexey Melnikov 
X-Mailer: Apple Mail (2.1084)
Cc: "apps-discuss@ietf.org Discuss" 
Subject: [apps-discuss] HTTP-Auth BoF in Quebec City Postponed
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: http-auth@ietf.org
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2011 10:35:29 -0000

The BoF chairs, in consultation with Peter (the responsible AD), have =
decided that it's best NOT to hold a BoF for HTTP authentication in =
Quebec City, because the scope is still ill-defined, and the timing =
prevents several stakeholders from participating.=20

Our hope is to be able to facilitate a BoF at an upcoming meeting, after =
there has been more preparation and coordination, so as to enhance its =
chance of success (i.e., identifying useful work for the IETF to do, in =
coordination with implementers as well as other efforts).

We encourage participants to continue discussing the various aspects of =
the problems as well as potential solutions, both on the list and in =
Quebec City (perhaps at an informal meeting).

--
Mark Nottingham and Alexey Melnikov



From john-ietf@jck.com  Wed Jul 20 05:19:07 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB73121F876A for ; Wed, 20 Jul 2011 05:19:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.474
X-Spam-Level: 
X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, MIME_8BIT_HEADER=0.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 PEjmwj5r6McU for ; Wed, 20 Jul 2011 05:19:07 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id E91A421F875C for ; Wed, 20 Jul 2011 05:19:06 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QjVju-00034f-NQ; Wed, 20 Jul 2011 08:18:58 -0400
Date: Wed, 20 Jul 2011 08:18:57 -0400
From: John C Klensin 
To: Paul Hoffman , =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= 
Message-ID: 
In-Reply-To: 
References:   <5AC1318B-A219-4056-BD14-C90BEE85669E@frobbit.se> <8159C20D-BF2B-42CB-9529-C870A2AD1572@vpnc.org>  
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: apps-discuss 
Subject: Re: [apps-discuss] CONTEXTJ in TLD DNS-Labels	(draft-liman-tld-names-05)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2011 12:19:08 -0000

Paul,

I think we are going to need to agree to disagree about several
aspects of this, including especially your apparent impression
of my attitude toward ICANN and the degree to which you
apparently believe that is driving my conclusions.  While I find
many aspects of how ICANN does business extremely frustrating, I
simply do not believe your characterization of my attitude is
correct.

However, one of your comments may deserve some calibration...


--On Tuesday, July 19, 2011 12:49 -0700 Paul Hoffman
 wrote:

>...
> "Phishing" in the root
> zone, given the horrendous weight of the process for getting
> new names put in the root zone, is not a threat. Which others
> do you believe that need to be weighed against the value of
> the characters?

ICANN has agreed to change the process for getting new names put
in the root zone.  The new (and approved) model for obtaining a
TLD as of next year is essentially "pay your application fee
and, unless a very narrow range of objections occurs, you get
the name".  All, or substantially all, of the requirements for
staff or third-party review that carried, in your words,
"horrendous weight", have been eliminated.  The proposed
application fee (USD 180000) is high enough to discourage some
types of applicants, but that does not make the process
"horrendous" -- one can either decide the TLD is important
enough pay it or not.

    john






From paul.hoffman@vpnc.org  Wed Jul 20 07:07:41 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5E021F86C0 for ; Wed, 20 Jul 2011 07:07:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.473
X-Spam-Level: 
X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, MIME_8BIT_HEADER=0.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 Py4ujQ4bhRTk for ; Wed, 20 Jul 2011 07:07:41 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B19A621F86BE for ; Wed, 20 Jul 2011 07:07:40 -0700 (PDT)
Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6KE7MSE083149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Jul 2011 07:07:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Paul Hoffman 
In-Reply-To: <640EE2B8-AB0B-40E5-9815-4A6A5E20FA79@frobbit.se>
Date: Wed, 20 Jul 2011 07:07:34 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <5AC1318B-A219-4056-BD14-C90BEE85669E@frobbit.se> <8159C20D-BF2B-42CB-9529-C870A2AD1572@vpnc.org>   <640EE2B8-AB0B-40E5-9815-4A6A5E20FA79@frobbit.se>
To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
X-Mailer: Apple Mail (2.1084)
Cc: apps-discuss 
Subject: Re: [apps-discuss] CONTEXTJ in TLD DNS-Labels (draft-liman-tld-names-05)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2011 14:07:41 -0000

On Jul 19, 2011, at 11:34 PM, Patrik F=E4ltstr=F6m wrote:

> On 19 jul 2011, at 21.49, Paul Hoffman wrote:
>=20
>> We have already seen the perceived need for these characters in the =
root zone, and we have not seen any statement of how they can cause harm =
*in the root zone*. "Phishing" in the root zone, given the horrendous =
weight of the process for getting new names put in the root zone, is not =
a threat. Which others do you believe that need to be weighed against =
the value of the characters?
>=20
> Yes, phishing in the root zone. People putting URLs on web pages that =
you click on.

This is an argument about disallowing labels with non-PVALID at any =
level, not just in the root. Prohibiting non-PVALID in the root will do =
nothing to prevent those attacks; an attacker just puts the phishing =
label in a different part of the domain name.

> It is tons of code easier in various applications to "know" that a =
code point is either allowed or not allowed in the TLD than having =
context dependent rules that otherwise is the option.

Such a rule just begs for various applications to "know" that non-PVALID =
codepoints are illegal anywhere. This was discussed in the INDAbis WG, =
and the WG decided that the root zone was not special.

> So the question is whether security software can filter out URLs with =
ZWNJ in the TLD as dangerous or not.


This truly sounds like a re-assessment of non-PVALID in IDNA2008. I'm =
willing to have that discussion if you are, but trying to say that it =
somehow applies only to the root seems misguided.

--Paul Hoffman


From paul.hoffman@vpnc.org  Wed Jul 20 07:16:42 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730F321F858C for ; Wed, 20 Jul 2011 07:16:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.621
X-Spam-Level: 
X-Spam-Status: No, score=-102.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, 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 rkta6sEus3m8 for ; Wed, 20 Jul 2011 07:16:42 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 65BCB21F84EE for ; Wed, 20 Jul 2011 07:16:10 -0700 (PDT)
Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6KEFtSi083577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Jul 2011 07:15:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman 
In-Reply-To: 
Date: Wed, 20 Jul 2011 07:16:08 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <5AC1318B-A219-4056-BD14-C90BEE85669E@frobbit.se> <8159C20D-BF2B-42CB-9529-C870A2AD1572@vpnc.org>   
To: John C Klensin 
X-Mailer: Apple Mail (2.1084)
Cc: apps-discuss Discuss 
Subject: Re: [apps-discuss] CONTEXTJ in TLD DNS-Labels	(draft-liman-tld-names-05)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2011 14:16:42 -0000

On Jul 20, 2011, at 5:18 AM, John C Klensin wrote:

> --On Tuesday, July 19, 2011 12:49 -0700 Paul Hoffman
>  wrote:
>=20
>> ...
>> "Phishing" in the root
>> zone, given the horrendous weight of the process for getting
>> new names put in the root zone, is not a threat. Which others
>> do you believe that need to be weighed against the value of
>> the characters?
>=20
> ICANN has agreed to change the process for getting new names put
> in the root zone.  The new (and approved) model for obtaining a
> TLD as of next year is essentially "pay your application fee
> and, unless a very narrow range of objections occurs, you get
> the name".  All, or substantially all, of the requirements for
> staff or third-party review that carried, in your words,
> "horrendous weight", have been eliminated.  The proposed
> application fee (USD 180000) is high enough to discourage some
> types of applicants, but that does not make the process
> "horrendous" -- one can either decide the TLD is important
> enough pay it or not.


How does buying a domain name for a large amount of money, using a =
stable corporate address, and doing the hosting using well-known servers =
constitute phishing? The argument you give here suggests that =
draft-liman-tld-names should add a new prohibition on TLDs that could be =
considered confusing; I hope you don't mean that.

--Paul Hoffman


From john-ietf@jck.com  Wed Jul 20 09:11:06 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6EB21F8AFA for ; Wed, 20 Jul 2011 09:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.619
X-Spam-Level: 
X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, 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 1EKs0b6daoUf for ; Wed, 20 Jul 2011 09:11:06 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id EE80021F8AF5 for ; Wed, 20 Jul 2011 09:11:05 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QjZMS-00066G-3z; Wed, 20 Jul 2011 12:11:00 -0400
Date: Wed, 20 Jul 2011 12:10:59 -0400
From: John C Klensin 
To: Paul Hoffman 
Message-ID: 
In-Reply-To: 
References:   <5AC1318B-A219-4056-BD14-C90BEE85669E@frobbit.se> <8159C20D-BF2B-42CB-9529-C870A2AD1572@vpnc.org>    
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: apps-discuss Discuss 
Subject: Re: [apps-discuss] CONTEXTJ in TLD DNS-Labels	(draft-liman-tld-names-05)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2011 16:11:06 -0000

--On Wednesday, July 20, 2011 07:16 -0700 Paul Hoffman
 wrote:

>> ICANN has agreed to change the process for getting new names
>> put in the root zone.  The new (and approved) model for
>> obtaining a TLD as of next year is essentially "pay your
>> application fee and, unless a very narrow range of objections
>> occurs, you get the name".  All, or substantially all, of the
>> requirements for staff or third-party review that carried, in
>> your words, "horrendous weight", have been eliminated.  The
>> proposed application fee (USD 180000) is high enough to
>> discourage some types of applicants, but that does not make
>> the process "horrendous" -- one can either decide the TLD is
>> important enough pay it or not.

> How does buying a domain name for a large amount of money,
> using a stable corporate address, and doing the hosting using
> well-known servers constitute phishing? The argument you give
> here suggests that draft-liman-tld-names should add a new
> prohibition on TLDs that could be considered confusing; I hope
> you don't mean that.

Paul, all I said, and all I meant, is that one cannot assume
that the process of obtaining a TLD involves the complex review
for appropriateness (of the name, the operator, or the planned
use) that was ICANN's norm in the first or second rounds of TLD
applications.  That is simply no longer the case: to a very
large extent, the new model is "pay your money, get your name,
do what you like with it".  My note deliberately did not comment
on whether I thought that was good or bad, much less about
whether it "consistute phishing" or anything else.

   john


From msk@cloudmark.com  Wed Jul 20 10:22:50 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6945921F8AF0 for ; Wed, 20 Jul 2011 10:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.885
X-Spam-Level: 
X-Spam-Status: No, score=-103.885 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 z9zdh+E1GunQ for ; Wed, 20 Jul 2011 10:22:46 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1306A21F8AE4 for ; Wed, 20 Jul 2011 10:22:46 -0700 (PDT)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 20 Jul 2011 10:22:45 -0700
From: "Murray S. Kucherawy" 
To: Nathaniel Borenstein , John C Klensin 
Date: Wed, 20 Jul 2011 10:22:26 -0700
Thread-Topic: [apps-discuss] i18n intro, Sunday 14:00-16:00
Thread-Index: AcxGsb9QN13/jO2eQGitHIQQAJVWxgAT8dEQ
Message-ID: 
References: <4E25D187.7010901@stpeter.im> <4E25D8FE.9030402@stpeter.im>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F134EBC4DE9EXCHC2corpclo_"
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2011 17:22:50 -0000

--_000_F5833273385BB34F99288B3648C4F06F134EBC4DE9EXCHC2corpclo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

+1.  See you there.

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of Nathaniel Borenstein
Sent: Wednesday, July 20, 2011 12:50 AM
To: John C Klensin
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00

On Jul 19, 2011, at 9:00 PM, John C Klensin wrote:


http://www.saint-andre.com/ietf/i18n-intro.pdf

197 slides?  YMBK.

Yes, this is clearly far too complex an area to cover in only 197 slides, b=
ut perhaps as a simplified introduction.....

And no, I'm not joking (for once).

I for one am very grateful that you (Pete*) are doing this, and look forwar=
d to finally achieving internationalization enlightenment.  -- Nathaniel

--_000_F5833273385BB34F99288B3648C4F06F134EBC4DE9EXCHC2corpclo_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


+1.  See you there.
 
=
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.or=
g] On Behalf Of Nathaniel Borenstein
Sent: Wednesday, July=
 20, 2011 12:50 AM
To: John C Klensin
Cc: apps-discuss@=
ietf.org
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:=
00
 <=
/p>
On Jul 19, 2011, at 9:00 PM, John C Klens=
in wrote:


<=
blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>
<=
a href=3D"http://www.saint-andre.com/ietf/i18n-intro.pdf">http://www.saint-=
andre.com/ietf/i18n-intro.pdf

197 slides?  YMBK.<=
/span>
 
<=
p class=3DMsoNormal>Yes, this is clearly far too complex an area to cover i=
n only 197 slides, but perhaps as a simplified introduction.....=

 
And no, I'm not joking (for once).
<=
p class=3DMsoNormal> 
I =
for one am very grateful that you (Pete*) are doing this, and look forward =
to finally achieving internationalization enlightenment.  -- Nathaniel=

=

--_000_F5833273385BB34F99288B3648C4F06F134EBC4DE9EXCHC2corpclo_--

From behnam@gmail.com  Wed Jul 20 10:42:14 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF87F21F8549 for ; Wed, 20 Jul 2011 10:42:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.951
X-Spam-Level: 
X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[AWL=1.026,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1]
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 XMK5st9l5vEs for ; Wed, 20 Jul 2011 10:42:09 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A313621F8538 for ; Wed, 20 Jul 2011 10:42:09 -0700 (PDT)
Received: by iwn39 with SMTP id 39so449777iwn.31 for ; Wed, 20 Jul 2011 10:42:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ZkM+H/IsT+ovDekBZ4zx7hr/PPHouCvyxF7tWg4hHKk=; b=TPSX+IVhcLDugsVXZLA4YS+b6uPTZNgeTpIyvQ32H0aeb3RiM2anoSGRQiXbmGEspT o4by5ZyF0wNNN8VXKIYTHPWzUEeDTIfDuizo0dipF0+Qc+IBNuunNm7gjjQyYCxbdZJs Mv4W+IfNx8dUCxbfkLoIpJCMHWSuhZfOwGfKE=
Received: by 10.231.21.10 with SMTP id h10mr8194681ibb.50.1311183729131; Wed, 20 Jul 2011 10:42:09 -0700 (PDT)
MIME-Version: 1.0
Sender: behnam@gmail.com
Received: by 10.231.3.146 with HTTP; Wed, 20 Jul 2011 10:41:29 -0700 (PDT)
In-Reply-To: <85FB14D637D54FBC5A95D68E@PST.JCK.COM>
References:   <85FB14D637D54FBC5A95D68E@PST.JCK.COM>
From: Behnam Esfahbod 
Date: Wed, 20 Jul 2011 13:41:29 -0400
X-Google-Sender-Auth: vpcT5lEUCxXaw_6ouX7SmQfLIqM
Message-ID: 
To: John C Klensin 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Siavash Shahshahani , apps-discuss 
Subject: Re: [apps-discuss] CONTEXTJ in TLD DNS-Labels (draft-liman-tld-names-05)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2011 17:42:15 -0000

Dear John,

I trust you understand the fact that Persian language and Arabic
script has already faced much more problems than other major scripts
(left-to-right ones) because of it's nature, being a bidirectional
script and it's contextual joining property.  I believe we have
sacrificed enough and there should be a good reason for further
limitations on these script and language.

We greatly appreciate the work that has been done by you all in
IDNA2008, but let's not forget that IDNA2003 *were broken* for many
languages and IDNA2008 was *fixing* it.  I think IDNA2003 was broken
because it was not challenged enough.  In fact, this is a very good
example to see that RFCs should not "simply" (or "blindly") ignoring
characters in each level of protocols and standards.

The other issue is that, in IDNA2003, at least there was the
possibility to have users write a word that included ZWNJ (like
[ARABIC BEH, ZWNJ, ARABIC ALEF]) as a label and ZWNJ was "removed"
before the label was resolved. Yes, the final label would not be the
same as the one entered, but users "could" use words with ZWNJ in URLs
or browsers' address-bar.

Now let me explain why I believe there is no "good reason" to not have
ZWNJ in the TLD labels:

1. We know that in many parts of the DNS technology, TLD labels are
"used" (evaluated, cached, etc) in A-label forms. I think we all agree
that there is no different between PVALID and CONTEXTJ characters in
A-label forms, thus there is no problem with ZWNJ in A-labels.

2. TLD labels are evaluated and delegated in both A-label and U-label
forms. We should note that we don't expect everybody responsible in
these processes (evaluation, deligation, root-zone management, etc) be
able to understand all the languages that will be used in Internet
TLDs ever, and that's why A-labels are very important in Root-Zone.

3. Now let's consider the cases that Arabic TLDs will be "used" in
U-label forms.

3.1. User's understanding of Arabic script:
3.1.1. If the user understands Arabic script, then there wouldn't be
any problem, as IDNA2008 rules for ZWNJ makes sure that ZWNJ is
"visible", thus user can "read" the label correctly.
3.1.2. If the user does not understand Arabic script, still the shape
of the letters would be different (thanks to IDNA2008's rules for
ZWNJ), thus the result would still be "visible".

3.2. Suitable font and rendering engine:
3.2.1. If there is no suitable font with Arabic support, or the
rendering engine does not support Arabic, user would have problems
with any Arabic IDN, no matter if it includes ZWNJ or not.
3.2.2. If there is a suitable font and the rendering engine
impolements the Arabic Contextual Joining algorithm, then there would
not be any problem with ZWNJ and it would be "visible" to user.

4. And finally, as I mentioned in the other thread (sharing with
VIP-Arabic team), there are much more possible security risks using
only PVALID Arabic characters.  So, why do you start with CONTEXTO
(ZWNJ and ZWJ) and stop right there?
4.1. If this RFC is required to make sure TLD labels are secure "all
the way", there is still a lot of work to be done and we should extend
it to cross-script issue, (like the case for .py) as well.
4.2. If we agree that it is not possible to take care of all the
security risks of the characters of all major scripts/languages in
some RFCs, why ZWNJ is different from the other characters?

I hope these make it clear that why there is no good reason to
"disallowed" CONTEXTO characters (specially ZWNJ) in TLD labels in
general, and security risks should be considered in a case-by-case
manner, like what would happen for many of PVALID characters (in
Arabic script, and most probably every other script).

Thanks all for the comments and supports,
-Behnam




On Tue, Jul 19, 2011 at 9:24 AM, John C Klensin  wrote:
> Behnam,
>
> I'm sorry I was not clear. =C2=A0 Let me try again, first by
> reference to Patrik's comment: independent of how ICANN has
> formulated the variant investigation, the question remains "what
> is safe across all scripts" and not "what does a particular
> language need". =C2=A0The ASCII ("English") examples were not
> intended to justify the situation, only to point out that
> restrictions have been with us for a very long time and that one
> of those restrictions is that a string being a valid word in
> some language does not create an entitlement to use that string
> as a DNS label... and never has. =C2=A0In retrospect, the terms
> "domain name system", and the earlier "hostname" are misleading.
> Precision would have called for substituting something like
> "mneumonic" for "name".
>
> Second, while your detailed explanation is appreciated, we fully
> understand the importance of ZWNJ to writing Persian (and most
> non-Arabic language use of Arabic script) and, although the use
> is a little different, the importance of ZWNJ and ZWJ in writing
> most Indic scripts. =C2=A0CONTEXTJ was not included in IDNA2008 by
> some magical accident: we (including both Patrik and myself)
> fought to include it in the standard precisely to facilitate
> those uses.
>
> But, examples, explanations, and language requirements aside,
> the issue remains one of whether those characters are safe in
> the root. =C2=A0With the understanding that this is just my opinion,
> part of that safety evaluation is that the root zone almost
> certainly should have a clear and simple set of rules, rules
> that are easily checked and enforced by the various types of
> (language-independent) software that call on the DNS. =C2=A0While one
> could imagine a large collection of rules based on a model of
> "determine the script, guess at the language, and then interpret
> and render accordingly", it is almost certainly not feasible
> even if ICANN agrees to use self-discipline about single-script
> labels. =C2=A0First, the DNS and IDNA do not support explicit
> language information and heuristics to determine language that
> work well with moderate or large blocks of text are not reliable
> when strings are only a few characters long. =C2=A0Second, and
> equally important, we know that complex procedures based on
> layers of tables are rarely implemented correctly.
>
> So, again returning to one of the implications of Patrik's note:
> please assume that we understand the importance of this
> character to most of the languages that use Arabic script (and
> to most of the languages that use several of the Indic scripts)
> and that, in case knowing this is helpful, we understood it long
> before ICANN created the VIP program. =C2=A0We also understand its
> importance regardless of how (or whether) "variants" (whatever
> that means in the general case) are supported. =C2=A0The question is
> whether the use of characters that, among other things, become
> invisible if the wrong rendering engine is chosen, is safe in a
> root context or can be made safe by a plausible, understandable,
> and, if appropriate, enforceable set of rules.
>
> regards,
> =C2=A0 john
>
>
>
>
> --On Monday, July 18, 2011 21:01 -0400 Behnam Esfahbod
>  wrote:
>
>> Hi John,
>>
>> I think it is time to stop general pronouncements that have
>> been repeated and repeated so many times over these past years
>> and get down to specifics. =C2=A0Here are two very concrete points
>> you should note:
>>
>> 1. ZWNJ is not a special quirk of Persian language, it is not
>> a mnemonic tool, =C2=A0 =C2=A0nor is it an optional writing-style
>> device. =C2=A0ZWNJ is used in the writing of =C2=A0 =C2=A0MOST languages
>>...
>
>



--=20
=C2=A0=C2=A0 =C2=A0'=C2=A0 =C2=A0=C2=A0 =D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8=
=A7=D8=B3=D9=81=D9=87=D8=A8=D8=AF
=C2=A0 =C2=A0 '=C2=A0 =C2=A0=C2=A0 Behnam Esfahbod
=C2=A0=C2=A0 '=C2=A0 =C2=A0 =C2=A0 http://behnam.esfahbod.info
=C2=A0 *=C2=A0 ..=C2=A0=C2=A0 http://zwnj.org/
=C2=A0*=C2=A0 `=C2=A0 *=C2=A0 http://persian-computing.ir
=C2=A0 * o *=C2=A0=C2=A0 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B

From stpeter@stpeter.im  Wed Jul 20 11:16:41 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF5821F8B06 for ; Wed, 20 Jul 2011 11:16:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 yFL2w8Lh0KqT for ; Wed, 20 Jul 2011 11:16:37 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5B53521F8AFD for ; Wed, 20 Jul 2011 11:16:37 -0700 (PDT)
Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E41204005A for ; Wed, 20 Jul 2011 12:17:19 -0600 (MDT)
Message-ID: <4E271B84.7070605@stpeter.im>
Date: Wed, 20 Jul 2011 12:16:36 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] moving APPSAREA/APPSAWG to Monday morning
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2011 18:16:41 -0000

Cancelling the HTTP-AUTH BoF has freed up the customary Monday morning 
slot for the APPSAREA/APPSAWG session, thus giving us an extra 30 
minutes. I have asked the Secretariat to make this change, so please 
expect that session to happen Monday 09:00-11:30. Sorry about the late 
notice.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From john-ietf@jck.com  Wed Jul 20 11:44:59 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235C021F8AF0 for ; Wed, 20 Jul 2011 11:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.645
X-Spam-Level: 
X-Spam-Status: No, score=-102.645 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, 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 xM4sPy6Mb1NQ for ; Wed, 20 Jul 2011 11:44:55 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDE821F8A71 for ; Wed, 20 Jul 2011 11:44:55 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QjblI-0008G4-IT; Wed, 20 Jul 2011 14:44:48 -0400
Date: Wed, 20 Jul 2011 14:44:47 -0400
From: John C Klensin 
To: Nathaniel Borenstein 
Message-ID: <22D8F54611F565A4C39C4754@PST.JCK.COM>
In-Reply-To: 
References: <4E25D187.7010901@stpeter.im> <4E25D8FE.9030402@stpeter.im>  
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: apps-discuss@ietf.org
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2011 18:44:59 -0000

--On Wednesday, July 20, 2011 08:50 +0100 Nathaniel Borenstein
 wrote:

> On Jul 19, 2011, at 9:00 PM, John C Klensin wrote:
> 
>>> http://www.saint-andre.com/ietf/i18n-intro.pdf
>> 
>> 197 slides?  YMBK.
> 
> Yes, this is clearly far too complex an area to cover in only
> 197 slides, but perhaps as a simplified introduction.....

Indeed.   Sadly, I had not looked at the slides and made an
incorrect assumption about the relationship between that many
slides and the presumed time slot.

> And no, I'm not joking (for once).

> I for one am very grateful that you (Pete*) are doing this,
> and look forward to finally achieving internationalization
> enlightenment.  -- Nathaniel

I have yet to achieve i18n enlightenment, despite looking at
probably thousands of slides over the years (and making several
hundred).  But, like other journeys, this one probably starts
with a single step... or 197 slides.  I, too, look forward to
the presentation.

    john





From dhc@dcrocker.net  Wed Jul 20 11:52:29 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F79621F8AA8 for ; Wed, 20 Jul 2011 11:52:29 -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 oWBFxRHyRve6 for ; Wed, 20 Jul 2011 11:52:25 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF7521F8ABE for ; Wed, 20 Jul 2011 11:52:25 -0700 (PDT)
Received: from [128.237.113.156] (CMU-466665.WV.CC.CMU.EDU [128.237.113.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p6KIqIHI013054 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jul 2011 11:52:25 -0700
Message-ID: <4E2723DD.6090408@dcrocker.net>
Date: Wed, 20 Jul 2011 14:52:13 -0400
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <4E25D187.7010901@stpeter.im> <4E25D8FE.9030402@stpeter.im>	 <4E25EA21.9090207@stpeter.im>
In-Reply-To: <4E25EA21.9090207@stpeter.im>
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, 20 Jul 2011 11:52:25 -0700 (PDT)
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2011 18:52:29 -0000

On 7/19/2011 4:33 PM, Peter Saint-Andre wrote:
>> 197 slides? YMBK.
>
> Why must I be kidding? I presented much the same slides at the XMPP WG interim
> meeting back in February, and we had a productive session.


Animation is a powerful enhancements for slides, so this actually, that sounds 
pretty short, given 24 slides per second...

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From stpeter@stpeter.im  Wed Jul 20 12:01:07 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACEB21F8438 for ; Wed, 20 Jul 2011 12:01:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 cTcbzlTF2brc for ; Wed, 20 Jul 2011 12:01:07 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BDF4921F8B80 for ; Wed, 20 Jul 2011 12:00:32 -0700 (PDT)
Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1763A4005A; Wed, 20 Jul 2011 13:01:14 -0600 (MDT)
Message-ID: <4E2725CE.8020800@stpeter.im>
Date: Wed, 20 Jul 2011 13:00:30 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: dcrocker@bbiw.net
References: <4E25D187.7010901@stpeter.im>	<4E25D8FE.9030402@stpeter.im>		<4E25EA21.9090207@stpeter.im> <4E2723DD.6090408@dcrocker.net>
In-Reply-To: <4E2723DD.6090408@dcrocker.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2011 19:01:08 -0000

On 7/20/11 12:52 PM, Dave CROCKER wrote:
>
>
> On 7/19/2011 4:33 PM, Peter Saint-Andre wrote:
>>> 197 slides? YMBK.
>>
>> Why must I be kidding? I presented much the same slides at the XMPP WG
>> interim
>> meeting back in February, and we had a productive session.
>
>
> Animation is a powerful enhancements for slides, so this actually, that
> sounds pretty short, given 24 slides per second...

In fact I've presented ~100 slides in 8-10 minutes before, so this one 
will be in slow motion because we've got 2 hours. :)

/psa


From dhc@dcrocker.net  Wed Jul 20 12:04:28 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D4321F8A64 for ; Wed, 20 Jul 2011 12:04:28 -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 YF65e8F2eV3z for ; Wed, 20 Jul 2011 12:04:27 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B9E4221F8A7D for ; Wed, 20 Jul 2011 12:03:48 -0700 (PDT)
Received: from [128.237.113.156] (CMU-466665.WV.CC.CMU.EDU [128.237.113.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p6KJ3fBA013288 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 20 Jul 2011 12:03:48 -0700
Message-ID: <4E272688.1080608@dcrocker.net>
Date: Wed, 20 Jul 2011 15:03:36 -0400
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Peter Saint-Andre 
References: <4E25D187.7010901@stpeter.im>	<4E25D8FE.9030402@stpeter.im>		<4E25EA21.9090207@stpeter.im> <4E2723DD.6090408@dcrocker.net> <4E2725CE.8020800@stpeter.im>
In-Reply-To: <4E2725CE.8020800@stpeter.im>
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, 20 Jul 2011 12:03:48 -0700 (PDT)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2011 19:04:28 -0000

On 7/20/2011 3:00 PM, Peter Saint-Andre wrote:
>> Animation is a powerful enhancements for slides, so this actually, that
>> sounds pretty short, given 24 slides per second...
>
> In fact I've presented ~100 slides in 8-10 minutes before, so this one will be
> in slow motion because we've got 2 hours. :)


actually, I'm impressed at what this means about how little ego you have in 
doing a presentation, since folks will (have to) devote all their attention to 
the flashing screen rather than pay attention to you...

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From barryleiba.mailing.lists@gmail.com  Wed Jul 20 13:27:33 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE9921F8A6F for ; Wed, 20 Jul 2011 13:27:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.095
X-Spam-Level: 
X-Spam-Status: No, score=-103.095 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 AnQ+bHS4bj2k for ; Wed, 20 Jul 2011 13:27:32 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id A182C21F8A64 for ; Wed, 20 Jul 2011 13:27:32 -0700 (PDT)
Received: by yie30 with SMTP id 30so312310yie.31 for ; Wed, 20 Jul 2011 13:27:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=IQKy+m1pl0/D6zYl+anIxgzyVTzMY/nAR3R4qLb3BCk=; b=hXrts+brFJesm9zk+sFYYhgd4Abbgr2E/Pl1W61cbi/EvyfK4Q4WmhJcZyFvgkqfNv jld/uTS15CnZWJu5oD72ACBl6nPRW/QNh2ZEvYyWosDGY4ArXxvX3dKiTs9q00uvIl3m F7NcqrivU4Bs8VYOjwsulZgNM+qnQOTe4iNhM=
MIME-Version: 1.0
Received: by 10.147.13.12 with SMTP id q12mr8440873yai.11.1311193651795; Wed, 20 Jul 2011 13:27:31 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.172.10 with HTTP; Wed, 20 Jul 2011 13:27:31 -0700 (PDT)
In-Reply-To: <4E271B84.7070605@stpeter.im>
References: <4E271B84.7070605@stpeter.im>
Date: Wed, 20 Jul 2011 16:27:31 -0400
X-Google-Sender-Auth: RvrWlHR8LuyDEQ0afHlptVUBDqk
Message-ID: 
From: Barry Leiba 
To: "apps-discuss@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [apps-discuss] moving APPSAREA/APPSAWG to Monday morning
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2011 20:27:33 -0000

> Cancelling the HTTP-AUTH BoF has freed up the customary Monday morning slot
> for the APPSAREA/APPSAWG session, thus giving us an extra 30 minutes. I have
> asked the Secretariat to make this change, so please expect that session to
> happen Monday 09:00-11:30. Sorry about the late notice.

And your chairs have promptly filled up the allotted space with stuff
we'd had to decline for the shorter time slot.  The new agenda is on
the meeting materials page.

Materials page: https://datatracker.ietf.org/meeting/81/materials.html
Apps Area agenda: http://www.ietf.org/proceedings/81/agenda/appsawg.txt

The agenda has links for all the documents, and everyone should please
review them before the meeting, so we're better prepared to use the
time for discussion.

All presenters, please send your presentation slides to
 by Saturday.  And thanks go to those
who've already sent them!

Barry, appsawg chair

From duerst@it.aoyama.ac.jp  Wed Jul 20 18:25:34 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B9A11E8073 for ; Wed, 20 Jul 2011 18:25:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.754
X-Spam-Level: 
X-Spam-Status: No, score=-99.754 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.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 Yv8lpFuooHua for ; Wed, 20 Jul 2011 18:25:33 -0700 (PDT)
Received: from acintmta01.acbb.aoyama.ac.jp (acintmta01.acbb.aoyama.ac.jp [133.2.20.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9681511E8070 for ; Wed, 20 Jul 2011 18:25:32 -0700 (PDT)
Received: from acmse01.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta01.acbb.aoyama.ac.jp (secret/secret) with SMTP id p6L1PPak023278 for ; Thu, 21 Jul 2011 10:25:25 +0900
Received: from (unknown [133.2.206.133]) by acmse01.acbb.aoyama.ac.jp with smtp id 1262_54a9_4f9a5624_b338_11e0_8ad4_001d096c5b62; Thu, 21 Jul 2011 10:25:25 +0900
Received: from [IPv6:::1] ([133.2.210.5]:33097) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Thu, 21 Jul 2011 10:25:27 +0900
Message-ID: <4E277FC3.5090102@it.aoyama.ac.jp>
Date: Thu, 21 Jul 2011 10:24:19 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Behnam Esfahbod 
References: 		<85FB14D637D54FBC5A95D68E@PST.JCK.COM> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss , Siavash Shahshahani 
Subject: Re: [apps-discuss] CONTEXTJ in TLD DNS-Labels	(draft-liman-tld-names-05)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2011 01:25:34 -0000

On 2011/07/21 2:41, Behnam Esfahbod wrote:

> 4. And finally, as I mentioned in the other thread (sharing with
> VIP-Arabic team), there are much more possible security risks using
> only PVALID Arabic characters.  So, why do you start with CONTEXTO
> (ZWNJ and ZWJ) and stop right there?
> 4.1. If this RFC is required to make sure TLD labels are secure "all
> the way", there is still a lot of work to be done and we should extend
> it to cross-script issue, (like the case for .py) as well.
> 4.2. If we agree that it is not possible to take care of all the
> security risks of the characters of all major scripts/languages in
> some RFCs, why ZWNJ is different from the other characters?

I fully agree with Behnam here. Disallowing ZWNJ is just scratching the 
surface of the actual problem, but on the other hand is damaging in 
cases where it the character is needed. Pretending to solve a problem by 
finding a scapegoat is never a good solution.

Regards,   Martin.

From lisa.dusseault@gmail.com  Wed Jul 20 22:10:10 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9E521F8B00 for ; Wed, 20 Jul 2011 22:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 vPZLc3Exrqct for ; Wed, 20 Jul 2011 22:09:32 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id F26FC21F8AFA for ; Wed, 20 Jul 2011 22:09:26 -0700 (PDT)
Received: by ywp31 with SMTP id 31so502492ywp.31 for ; Wed, 20 Jul 2011 22:09:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer; bh=YbC8GR8fiGM0m2M2mUjXcQmtkMpqZwQCNSPbN8cpnvA=; b=aUIuhTA018dyM7Xye0U4QAvHc+x9Ck07xLWv89KkI4pLSANWEXtuozoh5gJL8uioFh xYM9cE9qWDcj0Xr3feZdIZXnAeIR0N+hF4gzsvtDakwJ1ufwSpo94ZxDOxQjk9S/Wcxs czL0sc3rv7jJCBbM7C9slzGLeADE4btyyNVpU=
Received: by 10.150.72.30 with SMTP id u30mr154027yba.120.1311224966127; Wed, 20 Jul 2011 22:09:26 -0700 (PDT)
Received: from [192.168.1.105] (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by mx.google.com with ESMTPS id h6sm1329160icy.1.2011.07.20.22.09.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jul 2011 22:09:24 -0700 (PDT)
From: Lisa Dusseault 
Content-Type: multipart/alternative; boundary=Apple-Mail-9-57797879
Date: Wed, 20 Jul 2011 22:09:23 -0700
Message-Id: 
To: apps-discuss@ietf.org, Alexey Melnikov , ifette+ietf@google.com, Pete Resnick , Peter Saint-Andre 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [apps-discuss] Review of draft-ietf-hybi-thewebsocketprotocol for apps-review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2011 05:10:10 -0000

--Apple-Mail-9-57797879
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


I have been selected as the Applications Area Review Team reviewer for =
this draft (for background on apps-review, please see =
http://www.apps.ietf.org/content/applications-area-review-team).
Please resolve these comments along with any other Last Call comments =
you may receive. Please wait for direction from your document shepherd =
or AD before posting a new version of the draft.

Document: draft-ietf-hybi-thewebsocketprotocol (reviewed -10)
Title: The WebSocket protocol
Reviewer: Lisa Dusseault
Review Date: July 20, 2011

Readiness Summary: This draft is almost ready for publication on the =
Standards Track, but it has a few issues that should be fixed or thought =
about before publication.

Document Summary: The Websocket protocol defines a HTTP handshake to =
transition from a Web context to a bi-directional connection.  It also =
defines framing and masking for use in the bi-directional context.  It =
addresses a number of security concerns involving untrusted application =
code running in browsers, but assumes that browsers are trusted and =
servers hosting Websockets are trusted to a greater extent.=20

Major Issues

1.  Masking

It would be good to state what the purpose of masking is.  The sentence =
is "Frames sent from the client to the server are masked to avoid =
confusing network intermediaries", but I didn't upon reading this, or =
looking at the specification text for masking, understand why network =
intermediaries would be confused.  A citation or further explanation =
would be good.  I see later there's an explanation in page 50, so a =
forward reference would also work.

2.  Cookie handling

Section 5.1,=20
 The request MAY include headers associated with sending cookies,
    as defined by the appropriate specifications [RFC6265].  These
    headers are referred to as _Headers to Send Appropriate
    Cookies_.

    and

 "Additionally, if any headers in the
  server's handshake indicate that cookies should be set (as defined by
  [RFC6265]), these cookies are referred to as _Cookies Set During the
  Server's Opening Handshake_."

 and=20

Section 5.2.1, point 8
 	8.  Optionally, other headers, such as those used to send =
cookies to
     a server.  Unknown headers MUST be ignored.

First, a nit:   these important underlined terms are referred to where?  =
I didn't see anywhere where these terms are used other than where they =
are defined here.

The more substantive issue: I'm left unclear as to whether cookies are =
really expected to be used, or how the client might know that it needs =
to use cookies or else the application will not work.  In many Web =
sites, the site will not work if cookies are not used by the client, and =
this is sufficiently rare that it's OK.  Is that OK for a Websockets =
app?  How will the user know how to fix the problem?  Since Websockets =
can't as easily reply with a Web page to explain how to enable cookies, =
it would be good to be more clear on this. =20

3.  Failing a WebSocket Connection

Section 7.1.7 is supposed to describe how to _Fail the WebSocket =
Connection_.  It explains how the client does so.  However, there's at =
least one case in section 9.1 where the server receiving a malformed =
Sec-WebSocket-Extensions header must _Fail the WebSocket Connection_.  =
How does the server do this?=20

4.  Dropping with extreme prejudice

=46rom the Security Considerations:=20

"If at any time a server is faced with data that it does not
understand, or that violates some criteria by which the server
determines safety of input, or when the server sees an opening
handshake that does not correspond to the values the server is
expecting (e.g. incorrect path or origin), the server SHOULD just
disconnect.  It is always safe to disconnect."

This seems pretty excessive.  When the server just disconnects, the =
client can't tell much about what went wrong, and whether an automated =
retry would be any use at all.  This is bad for deployed use, and even =
worse for development/debugging.  Yet we're recommending servers be that =
unhelpful?  Wouldn't it be better to recommend that the server reply =
with an error response (some HTTP status codes defined here, too) that =
can help the client diagnose an incorrect origin?  An error like that is =
often going to be a mis-configuration on one side or the other, rather =
than an attack.

I'd also like to know what the websockets server implementations =
currently do.


Minor Issues

The reservation of different ranges of error codes for use by =
extensions, libraries and frameworks, and application code, seems to be =
intended to avoid conflicts between those kinds of use.  I don't think =
it will work very well.  I don't understand where a library ends and =
application code begins, even in code I write where I write an =
error_handler to be called by the library I'm using (which might be a =
"library" only for convenience sake or might be a library that dozens of =
other software programs use). =20

The border between code and "extensions" is not even very clear; if =
somebody writes an extension intending to publish an internet-draft but =
never gets around to it, they may have ended up using the wrong range =
with the right intentions.

The border between extensions and "this protocol" is not very clear; if =
I submit a internet-draft with a feature proposed to be a requirement =
for websockets, I might prefer to use a 1000-1999 range error code but =
if the feature is relegated to an optional draft it should change to =
2000-2999 range.=20

This kind of ambiguity leads to arguments at best, unnecessary changes =
to code (when specs are changed late after such arguments) at worst.  =
I'm not sure what to recommend; perhaps only one range reserved for  =
"this protocol and extensions published within the IETF process", and =
another range for "libraries, frameworks and application code".


Thanks,
Lisa Dusseault=

--Apple-Mail-9-57797879
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


I =
have been selected as the Applications Area Review Team reviewer for =
this draft (for background on apps-review, please see ht=
tp://www.apps.ietf.org/content/applications-area-review-team).
Plea=
se resolve these comments along with any other Last Call comments you =
may receive. Please wait for direction from your document shepherd or AD =
before posting a new version of the draft.

Document: =
draft-ietf-hybi-thewebsocketprotocol (reviewed -10)
Title: The =
WebSocket protocol
Reviewer: Lisa Dusseault
Review Date: July 20, =
2011

Readiness Summary: This draft is almost ready for =
publication on the Standards Track, but it has a few issues that should =
be fixed or thought about before =
publication.

Document Summary: The Websocket =
protocol defines a HTTP handshake to transition from a Web context to a =
bi-directional connection.  It also defines framing and masking for =
use in the bi-directional context.  It addresses a number of =
security concerns involving untrusted application code running in =
browsers, but assumes that browsers are trusted and servers hosting =
Websockets are trusted to a greater extent. 

Major =
Issues

1.  Masking

It would be good to state what the =
purpose of masking is.  The sentence is "Frames sent from the =
client to the server are masked to avoid confusing network =
intermediaries", but I didn't upon reading this, or looking at the =
specification text for masking, understand why network intermediaries =
would be confused.  A citation or further explanation would be =
good.  I see later there's an explanation in page 50, so a forward =
reference would also work.

2.  Cookie =
handling

Section 5.1, 
 The request MAY include =
headers associated with sending cookies,
    as =
defined by the appropriate specifications [RFC6265]. =
 These
    headers are referred to as =
_Headers to Send =
Appropriate
    Cookies_.

   =
 and

 "Additionally, if any headers in =
the
  server's handshake indicate that cookies should be =
set (as defined by
  [RFC6265]), these cookies are referred =
to as _Cookies Set During the
  Server's Opening =
Handshake_."

 and 

Section 5.2.1, point =
8
 	=
8.  Optionally, other headers, such as those used to send =
cookies to
     a server.  Unknown =
headers MUST be ignored.

First, a =
nit:   these important underlined terms are referred to =
where?  I didn't see anywhere where these terms are used other than =
where they are defined here.

The more substantive =
issue: I'm left unclear as to whether cookies are really expected to be =
used, or how the client might know that it needs to use cookies or else =
the application will not work.  In many Web sites, the site will =
not work if cookies are not used by the client, and this is sufficiently =
rare that it's OK.  Is that OK for a Websockets app?  How will =
the user know how to fix the problem?  Since Websockets can't as =
easily reply with a Web page to explain how to enable cookies, it would =
be good to be more clear on this.  

3.  Failing a =
WebSocket Connection

Section 7.1.7 is supposed to describe how to =
_Fail the WebSocket Connection_.  It explains how the client does =
so.  However, there's at least one case in section 9.1 where the =
server receiving a malformed Sec-WebSocket-Extensions header must _Fail =
the WebSocket Connection_.  How does the server do =
this? 

4.  Dropping with extreme prejudice

=46rom =
the Security Considerations: 

"If at any time a server is =
faced with data that it does not
understand, or that violates some =
criteria by which the server
determines safety of input, or when the =
server sees an opening
handshake that does not correspond to the =
values the server is
expecting (e.g. incorrect path or origin), the =
server SHOULD just
disconnect.  It is always safe to =
disconnect."

This seems pretty excessive.  When the server =
just disconnects, the client can't tell much about what went wrong, and =
whether an automated retry would be any use at all.  This is bad =
for deployed use, and even worse for development/debugging.  Yet =
we're recommending servers be that unhelpful?  Wouldn't it be =
better to recommend that the server reply with an error response (some =
HTTP status codes defined here, too) that can help the client diagnose =
an incorrect origin?  An error like that is often going to be a =
mis-configuration on one side or the other, rather than an =
attack.

I'd also like to know what the =
websockets server implementations currently do.


Minor =
Issues

The reservation of different ranges of error codes for use =
by extensions, libraries and frameworks, and application code, seems to =
be intended to avoid conflicts between those kinds of use.  I don't =
think it will work very well.  I don't understand where a library =
ends and application code begins, even in code I write where I write an =
error_handler to be called by the library I'm using (which might be a =
"library" only for convenience sake or might be a library that dozens of =
other software programs use).  

The border between code and =
"extensions" is not even very clear; if somebody writes an extension =
intending to publish an internet-draft but never gets around to it, they =
may have ended up using the wrong range with the right =
intentions.

The border between extensions and "this protocol" is =
not very clear; if I submit a internet-draft with a feature proposed to =
be a requirement for websockets, I might prefer to use a 1000-1999 range =
error code but if the feature is relegated to an optional draft it =
should change to 2000-2999 range. 

This kind of ambiguity =
leads to arguments at best, unnecessary changes to code (when specs are =
changed late after such arguments) at worst.  I'm not sure what to =
recommend; perhaps only one range reserved for  "this protocol and =
extensions published within the IETF process", and another range for =
"libraries, frameworks and application =
code".


Thanks,
Lisa =
Dusseault
=

--Apple-Mail-9-57797879--

From luyan@zte.com.cn  Thu Jul 21 02:53:14 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF7021F858D for ; Thu, 21 Jul 2011 02:53:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.838
X-Spam-Level: 
X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76,  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 duocSUcl2Hk6 for ; Thu, 21 Jul 2011 02:53:14 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id C3F5F21F85B9 for ; Thu, 21 Jul 2011 02:53:13 -0700 (PDT)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48641193944097; Thu, 21 Jul 2011 17:51:21 +0800 (CST)
Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 13796.2981150508; Thu, 21 Jul 2011 17:40:37 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6L9eSak022372; Thu, 21 Jul 2011 17:40:28 +0800 (GMT-8) (envelope-from luyan@zte.com.cn)
To: apps-discuss@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: luyan@zte.com.cn
Date: Thu, 21 Jul 2011 17:40:25 +0800
X-MIMETrack: S/MIME Sign by Notes Client on LuYan029354/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-21 17:42:54, Serialize by Notes Client on LuYan029354/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-21 17:42:54, Serialize complete at 2011-07-21 17:42:54, S/MIME Sign failed at 2011-07-21 17:42:54: ???????, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-21 17:40:29, Serialize complete at 2011-07-21 17:40:29
Content-Type: multipart/alternative; boundary="=_alternative 00355DBA482578D4_="
X-MAIL: mse01.zte.com.cn p6L9eSak022372
Cc: jiaxw9@chinaunicom.cn, "SHIH, JERRY \(ATTSI\)" , ding.xin@zte.com.cn
Subject: [apps-discuss] Extentions of IMAP4
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2011 09:53:15 -0000

This is a multipart message in MIME format.
--=_alternative 00355DBA482578D4_=
Content-Type: text/plain; charset="US-ASCII"

Dear All,

We (ZTE, AT&T and China Unicom) are currently working on the 
standardization of the Enhanced Visual Voice-Mail (EVVM) service for the 
Open Mobile Alliance (OMA). Similar to Email services, EVVM is also based 
on the IMAP protocol. According to our research, some requirements (e.g., 
server-initiated service deactivation, multi-account authentication and 
management) proposed for EVVM can be fulfilled easily if we're able to 
make some extensions for the IMAP protocol correspondingly. Thus, we 
prepared 3 internet-drafts and have submitted them to IETF lately. Those 
drafts are expected to serve as the IMAP extensions, and can be accessed 
at:

https://datatracker.ietf.org/doc/draft-jia-imap-multiaccount-authentication/
https://datatracker.ietf.org/doc/draft-lu-imap-multi-account/
https://datatracker.ietf.org/doc/draft-shih-imap-server-logout/


We hope these drafts can be discussed as soon as possible to meet the 
timeline of OMA-EVVM. 

Please feel free to let us know if you have any comments or questions 
regarding those drafts.

Thank you,

Yan LU

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

--=_alternative 00355DBA482578D4_=
Content-Type: text/html; charset="US-ASCII"



Dear All,



We (ZTE, AT&T and China Unicom)
are currently working on the standardization of the Enhanced Visual Voice-Mail
(EVVM) service for the Open Mobile Alliance (OMA). Similar to Email services,
EVVM is also based on the IMAP protocol. According to our research, some
requirements (e.g., server-initiated service deactivation, multi-account
authentication and management) proposed for EVVM can be fulfilled easily
if we're able to make some extensions for the IMAP protocol correspondingly.
Thus, we prepared 3 internet-drafts and have submitted them to IETF lately.
Those drafts are expected to serve as the IMAP extensions, and can be accessed
at:



https://datatracker.ietf.org/doc/draft-jia-imap-multiaccount-authentication/

https://datatracker.ietf.org/doc/draft-lu-imap-multi-account/

https://datatracker.ietf.org/doc/draft-shih-imap-server-logout/





We hope these drafts can be discussed
as soon as possible to meet the timeline of OMA-EVVM. 



Please feel free to let us know if you
have any comments or questions regarding those drafts.



Thank you,



Yan LU
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.


--=_alternative 00355DBA482578D4_=--


From dave@cridland.net  Thu Jul 21 03:20:04 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C098C21F88B7 for ; Thu, 21 Jul 2011 03:20:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level: 
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038,  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 0l6KH+HY4Sj8 for ; Thu, 21 Jul 2011 03:20:00 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 63CCF21F86DF for ; Thu, 21 Jul 2011 03:20:00 -0700 (PDT)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id F145D1168087; Thu, 21 Jul 2011 11:19:57 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1N4iCUZPY3LS; Thu, 21 Jul 2011 11:19:41 +0100 (BST)
Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 452D61168067; Thu, 21 Jul 2011 11:19:41 +0100 (BST)
References: 
In-Reply-To: 
MIME-Version: 1.0
Message-Id: <9031.1311243581.256116@puncture>
Date: Thu, 21 Jul 2011 11:19:41 +0100
From: Dave Cridland 
To: "luyan@zte.com.cn" , "jiaxw9@chinaunicom.cn" , "SHIH, JERRY \(ATTSI\)" , "ding.xin@zte.com.cn" , General discussion of application-layer protocols 
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Subject: Re: [apps-discuss] Extentions of IMAP4
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2011 10:20:04 -0000

On Thu Jul 21 10:40:25 2011, luyan@zte.com.cn wrote:
> https://datatracker.ietf.org/doc/draft-jia-imap-multiaccount-authentication/

This one is distinctly hand-wavey, to the extent I have no clear idea  
what it means.

I *think* it means to say that multiple authzids may be associated  
with a single authentication identifier, and these may be active  
concurrently - what this in turn means in terms of, for example, what  
"INBOX" now means is beyond me, though.


> https://datatracker.ietf.org/doc/draft-lu-imap-multi-account/

This one appears to build on the above, except it, too, confuses  
authentication and authorization.

I'm reasonably convinced that the first draft is entirely redundant,  
and this one's utility is limited. In particular, it's not clear to  
me why you'd want this instead of just using multiple authentication  
identifers and multiple connections, and no rationale is given in the  
document.


> https://datatracker.ietf.org/doc/draft-shih-imap-server-logout/

IMAP4rev1 already allows servers to unilaterally terminate the  
session with a * BYE. Introducing server-initiated commands is far,  
far beyond a simple draft like this.

A sensible alternative would be to have servers issue a different  
untagged response (* TERMINATE, perhaps?) in order to encourage  
clients into logging out quickly, if we want to have a more graceful  
termination of client sessions. This would need to be signalled with  
an ENABLE, though.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From duerst@it.aoyama.ac.jp  Thu Jul 21 06:30:53 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0C721F8B2D for ; Thu, 21 Jul 2011 06:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.815
X-Spam-Level: 
X-Spam-Status: No, score=-100.815 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.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 hZSVoBngHr4T for ; Thu, 21 Jul 2011 06:30:49 -0700 (PDT)
Received: from acspool01.acbb.aoyama.ac.jp (acspool01.acbb.aoyama.ac.jp [133.2.20.162]) by ietfa.amsl.com (Postfix) with ESMTP id EED9921F8B12 for ; Thu, 21 Jul 2011 06:30:48 -0700 (PDT)
Received: from acintmta01.acbb.aoyama.ac.jp ([133.2.20.226]) by acspool01.acbb.aoyama.ac.jp (secret/secret) with ESMTP id p6L743mL012791 for ; Thu, 21 Jul 2011 16:04:03 +0900
Received: from acmse01.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta01.acbb.aoyama.ac.jp (secret/secret) with SMTP id p6L742CY014521 for ; Thu, 21 Jul 2011 16:04:02 +0900
Received: from (unknown [133.2.206.133]) by acmse01.acbb.aoyama.ac.jp with smtp id 1262_ba8a_9d22be0c_b367_11e0_8ad4_001d096c5b62; Thu, 21 Jul 2011 16:04:02 +0900
Received: from [IPv6:::1] ([133.2.210.5]:52960) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Thu, 21 Jul 2011 16:04:04 +0900
Message-ID: <4E27CF30.5050205@it.aoyama.ac.jp>
Date: Thu, 21 Jul 2011 16:03:12 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Peter Saint-Andre 
References: <4E25D187.7010901@stpeter.im> <4E25D8FE.9030402@stpeter.im>
In-Reply-To: <4E25D8FE.9030402@stpeter.im>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2011 13:30:53 -0000

Some comments:

Slide 7: there are thousands of languages and scripts:
Thousands of languages: yes; thousands of scripts: no
(http://www.unicode.org/Public/UNIDATA/Scripts.txt currently has 95 
(including 'Common'), so "well over a hundred" would me much more 
appropriate).

Slide 10: we need to encode more than [A-Z][a-z]:
This should probably be: [A-Za-z]

Slide 22: Why not UPPER vs. lower vs. Title ?

Slide 24: You could do ｆｕｌｌ, half

Slide 55: There actually is U+1E9E LATIN CAPITAL LETTER SHARP S. But 
case conversion only goes downwards, not upwards.

Slide 113: There is no such thing as Compat Recomp!

Slide 114: "Fastest processing": That depends on various assumptions, in 
particular on the assumption that you actually implement processing as 
in slide 113 (which typically is not done).

Slide 117: "Compared to NFKC: Produces more false positives during
comparison operations": This is confusing/wrong. If matches are 
positive, then NFKC will match more than NFC, and if some of these 
matches are considered false, then NFKC will produce more false positives.

Slides 114-118: Some of the arguments given for a single NF apply to a 
certain aspect of NFs, e.g. C or D or K.

Slide 123: Good to see that. By the way, I seem to remember both John 
and me begging you for an explanation of why Jabber wants to use NFD a 
few months ago, and I'm not sure I have seen an answer. Now might be a 
good time (if you already sent one, a pointer would be appreciated).

Slide 131: "UTF-8 is the preferred IETF encoding (RFC 3629)":
RFC 3629 is the reference for UTF-8 per se, the IETF preference is 
expressed in RFC 2277. So the text should say
"UTF-8 (RFC 3629) is the preferred IETF encoding (RFC 2277)"
(or some such), and add RFC 2277 to the references.

Slide 132: integers -> bytes (or octets)
(we are really now on a lower, somewhat more physical level, and 
byte/octet is completely adequate here (indeed anything else would be 
needlessly confusing).

Slide 135: This should come close to normalization. I'd move the part on 
encoding earlier, but maybe that's just me.

Slide 168: Fussball vs. Fußball isn't a normalization issue (not even 
NFKC). Of the two HenryIV, IDNA only allows one (2008) or maps to one 
(2003).

Slide 184, middle bullet: I'd add 'occasionally' to put that issue in 
perspective

I remember having seen this talk before, but I don't know where. I 
thought it was very good. I'd be a bit worried if I'd have to spend 2h 
to present it, it's written for a fast pace.

Regards,   Martin.


On 2011/07/20 4:20, Peter Saint-Andre wrote:
> On 7/19/11 12:48 PM, Peter Saint-Andre wrote:
>> You might have noticed a curious item on the agenda at 14:00 on Sunday:
>> "Apps Area Preparatory Meeting for Internationalization Working Groups".
>>
>> At that time, I will present an introduction to internationalization,
>> assisted by Pete Resnick (who will correct me where I go wrong). The
>> intent of this session is to help apps-area folks learn more about
>> internationalization, especially in preparation for the PRECIS WG
>> meeting on Thursday. The room we've been assigned (2103) holds up to 60
>> people so we should have plenty of space, and there is no need to sign
>> up if you want to attend.
>>
>> If this session goes well, Pete and I might offer a more general
>> tutorial at a future IETF meeting. Consider Sunday's session a dry run.
>
> Sorry, I neglected to provide a pointer to my slides:
>
> http://www.saint-andre.com/ietf/i18n-intro.pdf
>
> Peter
>

From dave@cridland.net  Thu Jul 21 07:20:52 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2C721F8834 for ; Thu, 21 Jul 2011 07:20:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.416
X-Spam-Level: 
X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 LALPG5wDlygl for ; Thu, 21 Jul 2011 07:20:41 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id B863E21F87C6 for ; Thu, 21 Jul 2011 07:20:40 -0700 (PDT)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 34FDC1168087; Thu, 21 Jul 2011 15:20:34 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x52eG-qdyoWL; Thu, 21 Jul 2011 15:20:27 +0100 (BST)
Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 1EA361168067; Thu, 21 Jul 2011 15:20:27 +0100 (BST)
References: <4E25D187.7010901@stpeter.im> <4E25D8FE.9030402@stpeter.im> <4E27CF30.5050205@it.aoyama.ac.jp>
In-Reply-To: <4E27CF30.5050205@it.aoyama.ac.jp>
MIME-Version: 1.0
Message-Id: <9031.1311258027.106439@puncture>
Date: Thu, 21 Jul 2011 15:20:27 +0100
From: Dave Cridland 
To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , General discussion of application-layer protocols ,  Peter Saint-Andre 
Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: 8Bit
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2011 14:20:52 -0000

On Thu Jul 21 08:03:12 2011, "Martin J. Drst" wrote:
> I remember having seen this talk before, but I don't know where. I  
> thought it was very good. I'd be a bit worried if I'd have to spend  
> 2h to present it, it's written for a fast pace.

Peter is often used as a benchmark for powerpoint's framerate; he'll  
get through it, I'm sure.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From dhc@dcrocker.net  Thu Jul 21 07:46:13 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4968021F8505 for ; Thu, 21 Jul 2011 07:46:13 -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 yRlfNe0nTWrH for ; Thu, 21 Jul 2011 07:46:09 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 233D221F8500 for ; Thu, 21 Jul 2011 07:46:09 -0700 (PDT)
Received: from [128.237.113.156] (CMU-466665.WV.CC.CMU.EDU [128.237.113.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p6LEjrnV015147 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 21 Jul 2011 07:46:08 -0700
Message-ID: <4E283B9A.20407@dcrocker.net>
Date: Thu, 21 Jul 2011 10:45:46 -0400
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <4E25D187.7010901@stpeter.im> <4E25D8FE.9030402@stpeter.im>	<4E27CF30.5050205@it.aoyama.ac.jp> <9031.1311258027.106439@puncture>
In-Reply-To: <9031.1311258027.106439@puncture>
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]); Thu, 21 Jul 2011 07:46:08 -0700 (PDT)
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2011 14:46:13 -0000

On 7/21/2011 10:20 AM, Dave Cridland wrote:
> Peter is often used as a benchmark for powerpoint's framerate; he'll get through
> it, I'm sure.


yeah, but will the audience?

d

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From dave@cridland.net  Thu Jul 21 07:48:04 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466E421F8B0E for ; Thu, 21 Jul 2011 07:48:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.554
X-Spam-Level: 
X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045,  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 SXYvN+3VPc5C for ; Thu, 21 Jul 2011 07:47:59 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id DB94F21F86A6 for ; Thu, 21 Jul 2011 07:47:58 -0700 (PDT)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id B76F61168087; Thu, 21 Jul 2011 15:47:57 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBPJylpiCHME; Thu, 21 Jul 2011 15:47:51 +0100 (BST)
Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 5B6031168067; Thu, 21 Jul 2011 15:47:51 +0100 (BST)
References: <4E25D187.7010901@stpeter.im> <4E25D8FE.9030402@stpeter.im> <4E27CF30.5050205@it.aoyama.ac.jp> <9031.1311258027.106439@puncture> <4E283B9A.20407@dcrocker.net>
In-Reply-To: <4E283B9A.20407@dcrocker.net>
MIME-Version: 1.0
Message-Id: <9031.1311259671.373175@puncture>
Date: Thu, 21 Jul 2011 15:47:51 +0100
From: Dave Cridland 
To: Dave CROCKER , General discussion of application-layer protocols 
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2011 14:48:04 -0000

On Thu Jul 21 15:45:46 2011, Dave CROCKER wrote:
> 
> 
> On 7/21/2011 10:20 AM, Dave Cridland wrote:
>> Peter is often used as a benchmark for powerpoint's framerate;  
>> he'll get through
>> it, I'm sure.
> 
> 
> yeah, but will the audience?

I can't think what you mean; Peter is an entertaining and engaging  
speaker, especially if you have a sweepstake on the average  
slides/second.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From dhc@dcrocker.net  Thu Jul 21 07:52:31 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D950D21F8B3D for ; Thu, 21 Jul 2011 07:52:31 -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 WmqF9VWynhvU for ; Thu, 21 Jul 2011 07:52:27 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C8F9921F87C5 for ; Thu, 21 Jul 2011 07:52:27 -0700 (PDT)
Received: from [128.237.113.156] (CMU-466665.WV.CC.CMU.EDU [128.237.113.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p6LEqIuc015604 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2011 07:52:25 -0700
Message-ID: <4E283D1C.10705@dcrocker.net>
Date: Thu, 21 Jul 2011 10:52:12 -0400
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Dave Cridland 
References: <4E25D187.7010901@stpeter.im> <4E25D8FE.9030402@stpeter.im> <4E27CF30.5050205@it.aoyama.ac.jp> <9031.1311258027.106439@puncture> <4E283B9A.20407@dcrocker.net> <9031.1311259671.373175@puncture>
In-Reply-To: <9031.1311259671.373175@puncture>
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]); Thu, 21 Jul 2011 07:52:25 -0700 (PDT)
Cc: General discussion of application-layer protocols 
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2011 14:52:32 -0000

On 7/21/2011 10:47 AM, Dave Cridland wrote:
> especially if you have a sweepstake on the average slides/second.


well, yes, that's probably a good way to ensure that folks focus on the content...

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From john@jck.com  Thu Jul 21 08:22:32 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B7E21F89BA for ; Thu, 21 Jul 2011 08:22:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.589
X-Spam-Level: 
X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, MIME_8BIT_HEADER=0.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 fEpChVMlzSj4 for ; Thu, 21 Jul 2011 08:22:28 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 5001C21F877D for ; Thu, 21 Jul 2011 08:22:28 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Qjv4x-000Mue-Qs; Thu, 21 Jul 2011 11:22:24 -0400
Date: Thu, 21 Jul 2011 11:22:22 -0400
From: John C Klensin 
To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , Peter Saint-Andre 
Message-ID: <215FF088D6A2C5D95D969DFF@PST.JCK.COM>
In-Reply-To: <4E27CF30.5050205@it.aoyama.ac.jp>
References: <4E25D187.7010901@stpeter.im> <4E25D8FE.9030402@stpeter.im> <4E27CF30.5050205@it.aoyama.ac.jp>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2011 15:22:32 -0000

--On Thursday, July 21, 2011 16:03 +0900 "\"Martin J. =
D=C3=BCrst\""
 wrote:

> Some comments:
>

I already sent Peter a rather long list of comments, many of
which overlap these, privately (I will forward them to you,
Martin, or others if you are interested).  I have remarks on a
few of these...


> Slide 7: there are thousands of languages and scripts:
> Thousands of languages: yes; thousands of scripts: no
> (http://www.unicode.org/Public/UNIDATA/Scripts.txt currently
> has 95 (including 'Common'), so "well over a hundred" would me
> much more appropriate).

Agreed, although I read that as measuring a language-script
product, which would certainly be in the thousands.  It is
always hard to know how much detail a presentation like this
should go into but, if one wanted to push further, it might be
worth noting that the Unicode script list as found at that URL
is controversial -- some would claim that Unicode joins things
together as a single script that should be separated and
identifies things as separate scripts that are mostly
typographical variations plus a few added characters.

>...
> Slide 131: "UTF-8 is the preferred IETF encoding (RFC 3629)":
> RFC 3629 is the reference for UTF-8 per se, the IETF
> preference is expressed in RFC 2277. So the text should say
> "UTF-8 (RFC 3629) is the preferred IETF encoding (RFC 2277)"
> (or some such), and add RFC 2277 to the references.

2277 and 5198 in both cases.  5198 is already in the references.

> Slide 132: integers -> bytes (or octets)
> (we are really now on a lower, somewhat more physical level,
> and byte/octet is completely adequate here (indeed anything
> else would be needlessly confusing).

I assumed Peter was trying to make the distinction between
abstract integer code points and their instantiation in an
encoding.  Given that distinction raised issues in EAI and in
3536bis, it is probably worth trying to keep.  Whether the hint
of using "integer" is sufficient for that purpose probably
depends on what Peter says as the slides are flying by.
Conversely, I don't know whether it is worth trying to preserve
the distinction in a talk at this level.

>...
> Slide 168: Fussball vs. Fu=C3=9Fball isn't a normalization =
issue
> (not even NFKC).

Agreed.  But it is an issue with the use of toCaseFold.  One of
the suggestions I made to Peter is that it may be useful to
differentiate between the level of aggressiveness (i.e.,
vunerability to controversy) of lower-casing (or upper-casing)
and applying case folding.

> Of the two HenryIV, IDNA only allows one (2008) or maps to one
(2003).

True of several others of the examples the slides use or hint =
at.

>...

best,
   john


From joe.kupke@gmail.com  Wed Jul 20 20:48:30 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD9821F8554; Wed, 20 Jul 2011 20:48:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.48
X-Spam-Level: 
X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=-0.103,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-1]
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 OsuYMYoyI0rZ; Wed, 20 Jul 2011 20:48:29 -0700 (PDT)
Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id C60C521F8552; Wed, 20 Jul 2011 20:48:29 -0700 (PDT)
Received: by pzk6 with SMTP id 6so1201356pzk.26 for ; Wed, 20 Jul 2011 20:48:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qXEApSuCWHz3zEeHMXb/NxG79j8+TwFCtTedYz/NTx4=; b=iplVuioPmxE56I/GIm337HM5SWZYtcumA5JIVUtqzpYT+dY8W3Y5gRbHqqOBE6W2t/ UrIL1agjlQtlToTlSrgIsSqjW+aqOKQ+lLXvyb5C+bYycdqlF6RIYpssIN49WytB9fPf v6bsmZkT3kIFz3dxJH2uJcVQhkIpqzBF5h1Zg=
MIME-Version: 1.0
Received: by 10.68.19.230 with SMTP id i6mr2581809pbe.271.1311220109472; Wed, 20 Jul 2011 20:48:29 -0700 (PDT)
Sender: joe.kupke@gmail.com
Received: by 10.68.59.197 with HTTP; Wed, 20 Jul 2011 20:48:29 -0700 (PDT)
In-Reply-To: 
References: <4E083D3F.6030200@gmx.de> <4E0D3EA5.7010803@gmail.com> <4E0DCFEF.20206@gmx.de> <4E0DEA77.3050007@gmail.com> <4E0E0E76.2080007@gmail.com> <4E0E995A.7060800@gmail.com> <4E0F1058.3050201@gmail.com> <1309613470.2807.17.camel@mackerel> <4E0F1F2F.8020504@gmail.com>  <4E10208C.6090209@gmx.de>  <4E1818B9.8030804@gmx.de> 
Date: Wed, 20 Jul 2011 20:48:29 -0700
X-Google-Sender-Auth: KtuXYO3lSZQuJWQuQ3hEC3v8Ock
Message-ID: 
From: Joachim Kupke 
To: Maile Ohye 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 21 Jul 2011 09:26:34 -0700
Cc: "link-relations@ietf.org" , IETF Apps Discuss , Bjartur Thorlacius 
Subject: Re: [apps-discuss] [link-relations] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2011 03:48:30 -0000

Julian Reschke  wrote:
> Joachim Kupke  wrote:
>> Reading paragraph 5 of RFC 2119, I don't see
>> anything wrong with
>> =E2=80=98MAY.=E2=80=99 =C2=A0How is =E2=80=98can=E2=80=99 better? It's i=
ndeed not a =E2=80=98SHOULD=E2=80=99 since a typical
>> implementation, say in a search engine, will want to go to some length t=
o
>> find evidence for misguided usage of the relationship and in the presenc=
e of
>> such evidence decide to ignore it. =C2=A0The point of =E2=80=98MAY=E2=80=
=99 is to make clear that
>> in the absence of such evidence, the responsibility not to advertise an
>> erroneous =E2=80=98canonical=E2=80=99 relationship lies with the author =
of the context URI.=E2=80=9D
>
> See RFC 2119, Section 6:
[...]

It's true that the imperatives of RFC 2119 (including
"MAY"/"OPTIONAL") are supposed to pertain to the format of data that
is exchanged (e.g., this and that field MAY be omitted, or this and
that proxy MAY have rewritten something), but interoperability goes
beyond that; hence the desire to give the two points where MAY is used
in the draft some more formal meaning.

Specifically, a  supposedly gives carte blanche
to, say, an application to organize bookmarks, to rewrite a bookmarked
URI to its rel=3Dcanonical variant, if any (and non-self-referential).
Or, say, Wikipedia could crawl its external links and automatically
update those that now have a "canonical" relationship with another URI
(or, for that matter, have become an HTTP 301 redirect).  In order not
to break such applications, it is fairly important for implementations
of rel=3D"canonical" not to designate URIs that are meaningless
substitutions for links to the context URI.

Speaking of HTTP redirects, RFC 2616 uses the wording that "[c]lients
with link editing capabilities *ought to* automatically re-link
references" to URIs that have become 301 redirects; and for a 300
"multiple choices" URI, "user agents *MAY* use the Location field
value for automatic redirection" (both emphases added).  It appears
the latter point is no more required for interoperability than what
the occurrences of "MAY" in this draft allude to.

With that said, it's closer in spirit to the provisions of 301
redirects, so I'd be happy to see the draft changed as follows:

diff before after
index 5f01f55..4ed47b8 100644
--- before
+++ after
@@ -66,10 +66,9 @@ Internet-Draft         The Canonical Link Relation
 1.  Introduction

    The canonical link relation specifies the preferred URI from a set of
-   identical or vastly similar content accessible on multiple URIs.
-   This designation MAY be used for future references to this resource,
-   and clients with link editing capabilities MAY automatically re-link
-   references to the context URI to the designated URI.
+   identical or vastly similar content accessible on multiple URIs, to
+   make it possible for references to the context URI to be updated to
+   reference the designated URI.

    The most common application of the canonical link relation includes
    specifying the preferred version of a URI from duplicate content
@@ -86,8 +85,8 @@ Internet-Draft         The Canonical Link Relation

    The canonical (target) URI MUST identify content that duplicates, is
    extremely similar, or is a superset of the content at the context
-   (referring) URI.  Presence of the canonical link relation indicates
-   to applications, such as search engines, that they MAY:
+   (referring) URI.  Authors who declare the canonical link relation
+   ought to anticipate that applications such as search engines can:

    o  Index content only from the canonical target (i.e. content from
       the context URIs will be likely disregarded as duplicative).

--Joachim

From Joe.Hildebrand@webex.com  Thu Jul 21 09:29:02 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E9421F86BE; Thu, 21 Jul 2011 09:29:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.082
X-Spam-Level: 
X-Spam-Status: No, score=-104.082 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, 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 iPTjcFG3MUSS; Thu, 21 Jul 2011 09:29:02 -0700 (PDT)
Received: from gw1.webex.com (gw1.webex.com [64.68.122.208]) by ietfa.amsl.com (Postfix) with SMTP id 68DA721F858C; Thu, 21 Jul 2011 09:29:02 -0700 (PDT)
Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw1.webex.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 21 Jul 2011 09:29:01 -0700
Received: from 64.101.74.200 ([64.101.74.200]) by SRV-EXSC03.webex.local ([192.168.252.200]) with Microsoft Exchange Server HTTP-DAV ;  Thu, 21 Jul 2011 16:29:01 +0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Thu, 21 Jul 2011 10:28:59 -0600
From: Joe Hildebrand 
To: "Martin J. =?ISO-8859-1?B?RPxyc3Q=?=" , Peter Saint-Andre 
Message-ID: 
Thread-Topic: [apps-discuss] i18n intro, Sunday 14:00-16:00
Thread-Index: AcxHw0sJitjZtEfii0GYJg2U1Dy4Bw==
In-Reply-To: <4E27CF30.5050205@it.aoyama.ac.jp>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-OriginalArrivalTime: 21 Jul 2011 16:29:01.0589 (UTC) FILETIME=[4C946450:01CC47C3]
Cc: xmpp@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2011 16:29:03 -0000

On 7/21/11 1:03 AM, "Martin J. D=FCrst"  wrote:

> Slide 123: Good to see that. By the way, I seem to remember both John 
and me
> begging you for an explanation of why Jabber wants to use NFD a 
few months
> ago, and I'm not sure I have seen an answer. Now might be a 
good time (if you
> already sent one, a pointer would be appreciated).


Let me try.  First some assumptions:
- Stringprep is currently one of the performance hotspots of some XMPP
servers.
- XMPP does not guarantee that the original form of the address that is
entered by the user or sent on the first hop is transmitted without
modification to other hops in the system.
- As such, many XMPP servers optimize by performing canonicalization at the
edges of their system and even store the canonical version for future
comparison.
- If the spec is written that clients SHOULD perform canonicalization, many
in our community will, particularly if they know that they will get better
performance from the server.

The property of NFK?D that we like is that if you have a string of
codepoints that is already in NFK?D, you can check that the string is in th=
e
correct normalization form without having to allocate memory.  With NFK?C,
you'll have to decompose (allocating memory), recompose (at some finite CPU
cost), then recompose (possibly allocating *again*) just to check if you
have already done the normalization.

For the K portion, I have found John's argument compelling that codepoints
with compatibility decompositions should just be prohibited in our
localparts.  In our resourceparts, I'm of the opinion that we don't need to
compatibility map -- it's fine for all of those codepoints to stay distinct=
.

The idea is that clients SHOULD normalize, servers double-check inputs from
non-trusted sources (like clients and other servers), then always store and
forward the normalized version.

--=20
Joe Hildebrand


From derhoermi@gmx.net  Thu Jul 21 09:56:40 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CF421F8743 for ; Thu, 21 Jul 2011 09:56:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.458
X-Spam-Level: 
X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=-1.459, BAYES_00=-2.599, J_CHICKENPOX_31=0.6]
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 wEgRQERpzvED for ; Thu, 21 Jul 2011 09:56:37 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 40E6621F8663 for ; Thu, 21 Jul 2011 09:56:37 -0700 (PDT)
Received: (qmail invoked by alias); 21 Jul 2011 16:56:35 -0000
Received: from dslb-094-223-187-169.pools.arcor-ip.net (EHLO HIVE) [94.223.187.169] by mail.gmx.net (mp046) with SMTP; 21 Jul 2011 18:56:35 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1+MbhRYPi2MHqepkUvc+ojR4LsbnjjORBRWxQhKlR X/GRP6jgps6aeT
From: Bjoern Hoehrmann 
To: Joe Hildebrand 
Date: Thu, 21 Jul 2011 18:57:02 +0200
Message-ID: 
References: <4E27CF30.5050205@it.aoyama.ac.jp> 
In-Reply-To: 
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: apps-discuss@ietf.org, xmpp@ietf.org
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2011 16:56:40 -0000

* Joe Hildebrand wrote:
>The property of NFK?D that we like is that if you have a string of
>codepoints that is already in NFK?D, you can check that the string is in the
>correct normalization form without having to allocate memory.  With NFK?C,
>you'll have to decompose (allocating memory), recompose (at some finite CPU
>cost), then recompose (possibly allocating *again*) just to check if you
>have already done the normalization.

The set of strings that is in Normalization Form C is a regular language
see ,
so recognizing NFC strings is just as easy as recognizing NFD strings if
ignore that automata for NFC are bigger and harder to make than for NFD.
It's easier to use the simple heuristic in the specification and then do
what you suggest above for complicated strings, but it's not necessary.
-- 
Bjrn Hhrmann  mailto:bjoern@hoehrmann.de  http://bjoern.hoehrmann.de
Am Badedeich 7  Telefon: +49(0)160/4415681  http://www.bjoernsworld.de
25899 Dagebll  PGP Pub. KeyID: 0xA4357E78  http://www.websitedev.de/ 

From stpeter@stpeter.im  Thu Jul 21 21:00:52 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C5611E808C for ; Thu, 21 Jul 2011 21:00:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.641
X-Spam-Level: 
X-Spam-Status: No, score=-102.641 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, 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 gxDrmVJ9+XdA for ; Thu, 21 Jul 2011 21:00:52 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 84DDD11E8079 for ; Thu, 21 Jul 2011 21:00:52 -0700 (PDT)
Received: from squire.local (unknown [216.17.175.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 754154005A for ; Thu, 21 Jul 2011 22:01:38 -0600 (MDT)
Message-ID: <4E28F5F2.5080901@stpeter.im>
Date: Thu, 21 Jul 2011 22:00:50 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
References: <4E25D187.7010901@stpeter.im>
In-Reply-To: <4E25D187.7010901@stpeter.im>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jul 2011 04:00:53 -0000

Folks, thanks for all the feedback. I won't have time to reply 
individually, but I will work to adjust the slides before I present them 
on Sunday.

On 7/19/11 12:48 PM, Peter Saint-Andre wrote:
> You might have noticed a curious item on the agenda at 14:00 on Sunday:
> "Apps Area Preparatory Meeting for Internationalization Working Groups".
>
> At that time, I will present an introduction to internationalization,
> assisted by Pete Resnick (who will correct me where I go wrong). The
> intent of this session is to help apps-area folks learn more about
> internationalization, especially in preparation for the PRECIS WG
> meeting on Thursday. The room we've been assigned (2103) holds up to 60
> people so we should have plenty of space, and there is no need to sign
> up if you want to attend.
>
> If this session goes well, Pete and I might offer a more general
> tutorial at a future IETF meeting. Consider Sunday's session a dry run.
>
> See you in Quebec City!
>
> Peter
>

From duerst@it.aoyama.ac.jp  Thu Jul 21 23:06:38 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B1921F85B9 for ; Thu, 21 Jul 2011 23:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.861
X-Spam-Level: 
X-Spam-Status: No, score=-99.861 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.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 7LyjRjBJGCUO for ; Thu, 21 Jul 2011 23:06:37 -0700 (PDT)
Received: from acintmta01.acbb.aoyama.ac.jp (acintmta01.acbb.aoyama.ac.jp [133.2.20.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0CC21F8515 for ; Thu, 21 Jul 2011 23:06:19 -0700 (PDT)
Received: from acmse02.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta01.acbb.aoyama.ac.jp (secret/secret) with SMTP id p6M66EKr030375 for ; Fri, 22 Jul 2011 15:06:14 +0900
Received: from (unknown [133.2.206.133]) by acmse02.acbb.aoyama.ac.jp with smtp id 713b_ffa1_b4a71a8e_b428_11e0_a359_001d0969ab06; Fri, 22 Jul 2011 15:06:14 +0900
Received: from [IPv6:::1] ([133.2.210.5]:45908) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Fri, 22 Jul 2011 15:06:17 +0900
Message-ID: <4E291324.8080203@it.aoyama.ac.jp>
Date: Fri, 22 Jul 2011 15:05:24 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Dave Cridland 
References: <4E25D187.7010901@stpeter.im> <4E25D8FE.9030402@stpeter.im> <4E27CF30.5050205@it.aoyama.ac.jp> <9031.1311258027.106439@puncture>
In-Reply-To: <9031.1311258027.106439@puncture>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: General discussion of application-layer protocols 
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jul 2011 06:06:38 -0000

On 2011/07/21 23:20, Dave Cridland wrote:
> On Thu Jul 21 08:03:12 2011, "Martin J. Drst" wrote:
>> I remember having seen this talk before, but I don't know where. I
>> thought it was very good. I'd be a bit worried if I'd have to spend 2h
>> to present it, it's written for a fast pace.
>
> Peter is often used as a benchmark for powerpoint's framerate; he'll get
> through it, I'm sure.

Sorry, I meant it the other way round. It's designed to go through at a 
fast pace, so I'm affraid 2h is much too much time.

Regards,   Martin.

From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com  Thu Jul 21 23:08:47 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBEA21F86EA for ; Thu, 21 Jul 2011 23:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.015
X-Spam-Level: 
X-Spam-Status: No, score=-103.015 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 tNU7anunko5j for ; Thu, 21 Jul 2011 23:08:46 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7521C21F86D9 for ; Thu, 21 Jul 2011 23:08:46 -0700 (PDT)
Received: by gyd5 with SMTP id 5so1127879gyd.31 for ; Thu, 21 Jul 2011 23:08:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2qc5DA5QHDzhKnBgdjBmAuHfADXjxphqUt8SLpxduZs=; b=emZZHnwXzzSr65aa8TstathGmb7mk1Zo9UvYYj6v4PpJ8nQP49UEYFL9L+DKoPHIqT Kr31sUNP85N2PMKvJ4nRQra+H8KEJYpD0CObsGTA/mCqRpvvAjmYe0gBn6u2iUFA/kXo 5hG8vDHMLmcCFySbxcJtbe2HRtSI3ScufeYeI=
Received: by 10.142.178.21 with SMTP id a21mr607149wff.445.1311314925258; Thu, 21 Jul 2011 23:08:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.77.18 with HTTP; Thu, 21 Jul 2011 23:08:25 -0700 (PDT)
In-Reply-To: <4E2725CE.8020800@stpeter.im>
References: <4E25D187.7010901@stpeter.im> <4E25D8FE.9030402@stpeter.im>  <4E25EA21.9090207@stpeter.im> <4E2723DD.6090408@dcrocker.net> <4E2725CE.8020800@stpeter.im>
From: Frank Ellermann 
Date: Fri, 22 Jul 2011 08:08:25 +0200
Message-ID: 
To: Peter Saint-Andre 
Content-Type: text/plain; charset=ISO-8859-1
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jul 2011 06:08:47 -0000

On 20 July 2011 21:00, Peter Saint-Andre wrote:

> In fact I've presented ~100 slides in 8-10
> minutes before, so this one will be in slow
> motion because we've got 2 hours. :)

Thanks - almost all points covered.  Maybe JohnK
or Martin could add a slide why using UTF-8 (or
even UTF-6) was no option for IDNA2003, but okay
for EAI.  The "EAI history" in JohnL's blog is
also very good.

-Frank
 

From duerst@it.aoyama.ac.jp  Thu Jul 21 23:55:23 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A62821F85C0 for ; Thu, 21 Jul 2011 23:55:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.858
X-Spam-Level: 
X-Spam-Status: No, score=-99.858 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.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 pi5GFDzw+NUE for ; Thu, 21 Jul 2011 23:55:22 -0700 (PDT)
Received: from acintmta02.acbb.aoyama.ac.jp (acintmta02.acbb.aoyama.ac.jp [133.2.20.34]) by ietfa.amsl.com (Postfix) with ESMTP id 99CC321F85C6 for ; Thu, 21 Jul 2011 23:55:22 -0700 (PDT)
Received: from acmse02.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta02.acbb.aoyama.ac.jp (secret/secret) with SMTP id p6M6tHRA010030 for ; Fri, 22 Jul 2011 15:55:17 +0900
Received: from (unknown [133.2.206.133]) by acmse02.acbb.aoyama.ac.jp with smtp id 713f_0fcf_8e9ac8f2_b42f_11e0_a358_001d0969ab06; Fri, 22 Jul 2011 15:55:17 +0900
Received: from [IPv6:::1] ([133.2.210.5]:44342) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Fri, 22 Jul 2011 15:55:19 +0900
Message-ID: <4E291EA2.6010500@it.aoyama.ac.jp>
Date: Fri, 22 Jul 2011 15:54:26 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: John C Klensin 
References: <4E25D187.7010901@stpeter.im> <4E25D8FE.9030402@stpeter.im> <4E27CF30.5050205@it.aoyama.ac.jp> <215FF088D6A2C5D95D969DFF@PST.JCK.COM>
In-Reply-To: <215FF088D6A2C5D95D969DFF@PST.JCK.COM>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jul 2011 06:55:23 -0000

Hello John,

On 2011/07/22 0:22, John C Klensin wrote:
>
>
> --On Thursday, July 21, 2011 16:03 +0900 "\"Martin J. Dürst\""
>   wrote:
>
>> Some comments:
>>
>
> I already sent Peter a rather long list of comments, many of
> which overlap these, privately (I will forward them to you,
> Martin, or others if you are interested).

Yes interested, please send.

> I have remarks on a
> few of these...
>
>
>> Slide 7: there are thousands of languages and scripts:
>> Thousands of languages: yes; thousands of scripts: no
>> (http://www.unicode.org/Public/UNIDATA/Scripts.txt currently
>> has 95 (including 'Common'), so "well over a hundred" would me
>> much more appropriate).
>
> Agreed, although I read that as measuring a language-script
> product, which would certainly be in the thousands.

In that case, it would be fine.

> It is
> always hard to know how much detail a presentation like this
> should go into but, if one wanted to push further,

I didn't.

> it might be
> worth noting that the Unicode script list as found at that URL
> is controversial -- some would claim that Unicode joins things
> together as a single script that should be separated and
> identifies things as separate scripts that are mostly
> typographical variations plus a few added characters.

I think "controversial" is too strong, because it suggests that there 
are great fights going on. Not the only way to count scripts, yes 
indeed. But I only counted that to give a rough start value, and I don't 
think there is a reasonable way to define scripts that results in thousands.

>> ...
>> Slide 131: "UTF-8 is the preferred IETF encoding (RFC 3629)":
>> RFC 3629 is the reference for UTF-8 per se, the IETF
>> preference is expressed in RFC 2277. So the text should say
>> "UTF-8 (RFC 3629) is the preferred IETF encoding (RFC 2277)"
>> (or some such), and add RFC 2277 to the references.
>
> 2277 and 5198 in both cases.  5198 is already in the references.

I'd guess then this should be:

"UTF-8 (RFC 3629, RFC 5198) is the preferred IETF encoding (RFC 2277)"


>> Slide 132: integers ->  bytes (or octets)
>> (we are really now on a lower, somewhat more physical level,
>> and byte/octet is completely adequate here (indeed anything
>> else would be needlessly confusing).
>
> I assumed Peter was trying to make the distinction between
> abstract integer code points and their instantiation in an
> encoding.

That would make a lot of sense. But exactly for that reason, it has to 
be bytes. "UTF-8 encodes each codepoint as a squence of 1 to 4 integers" 
just doesn't make sense.

Regards,   Martin.

> Given that distinction raised issues in EAI and in
> 3536bis, it is probably worth trying to keep.  Whether the hint
> of using "integer" is sufficient for that purpose probably
> depends on what Peter says as the slides are flying by.
> Conversely, I don't know whether it is worth trying to preserve
> the distinction in a talk at this level.
>
>> ...
>> Slide 168: Fussball vs. Fußball isn't a normalization issue
>> (not even NFKC).
>
> Agreed.  But it is an issue with the use of toCaseFold.  One of
> the suggestions I made to Peter is that it may be useful to
> differentiate between the level of aggressiveness (i.e.,
> vunerability to controversy) of lower-casing (or upper-casing)
> and applying case folding.
>
>> Of the two HenryIV, IDNA only allows one (2008) or maps to one
> (2003).
>
> True of several others of the examples the slides use or hint at.
>
>> ...
>
> best,
>     john
>
>

From duerst@it.aoyama.ac.jp  Fri Jul 22 00:51:40 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B119D21F865E for ; Fri, 22 Jul 2011 00:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.555
X-Spam-Level: 
X-Spam-Status: No, score=-99.555 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.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 bHdIgs+oQvtZ for ; Fri, 22 Jul 2011 00:51:40 -0700 (PDT)
Received: from acintmta02.acbb.aoyama.ac.jp (acintmta02.acbb.aoyama.ac.jp [133.2.20.34]) by ietfa.amsl.com (Postfix) with ESMTP id E67E321F865D for ; Fri, 22 Jul 2011 00:51:39 -0700 (PDT)
Received: from acmse02.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta02.acbb.aoyama.ac.jp (secret/secret) with SMTP id p6M7pXjF021980 for ; Fri, 22 Jul 2011 16:51:33 +0900
Received: from (unknown [133.2.206.133]) by acmse02.acbb.aoyama.ac.jp with smtp id 713b_3376_6b316d78_b437_11e0_a359_001d0969ab06; Fri, 22 Jul 2011 16:51:33 +0900
Received: from [IPv6:::1] ([133.2.210.5]:55854) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Fri, 22 Jul 2011 16:51:36 +0900
Message-ID: <4E292BC3.30301@it.aoyama.ac.jp>
Date: Fri, 22 Jul 2011 16:50:27 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Joe Hildebrand 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: xmpp@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jul 2011 07:51:40 -0000

Hello Joe,

On 2011/07/22 1:28, Joe Hildebrand wrote:
> On 7/21/11 1:03 AM, "Martin J. Drst"  wrote:
>
>> Slide 123: Good to see that. By the way, I seem to remember both John
> and me
>> begging you for an explanation of why Jabber wants to use NFD a
> few months
>> ago, and I'm not sure I have seen an answer. Now might be a
> good time (if you
>> already sent one, a pointer would be appreciated).
>
>
> Let me try.

Glad to start talking.

> First some assumptions:
> - Stringprep is currently one of the performance hotspots of some XMPP
> servers.

Is that an assumption backed by facts or a wild guess?

> - XMPP does not guarantee that the original form of the address that is
> entered by the user or sent on the first hop is transmitted without
> modification to other hops in the system.
> - As such, many XMPP servers optimize by performing canonicalization at the
> edges of their system and even store the canonical version for future
> comparison.

Makes sense.

> - If the spec is written that clients SHOULD perform canonicalization, many
> in our community will, particularly if they know that they will get better
> performance from the server.

That's the same for NFC and NFD, isn't it? The advantage of NFC is that 
it's designed to more-or-less match what's out there, so you get the 
advantage that there is more stuff that's already canonicalized even if 
if a client doesn't do anything. That gets reinforced by both the IETF 
and the W3C telling everybody to use NFC.

> The property of NFK?D that we like is that if you have a string of
> codepoints that is already in NFK?D, you can check that the string is in the
> correct normalization form without having to allocate memory.  With NFK?C,
> you'll have to decompose (allocating memory), recompose (at some finite CPU
> cost), then recompose (possibly allocating *again*) just to check if you
> have already done the normalization.

Nope. That's just how the algorithm was defined, because the 
decomposition component was already around, and NFD was what defined 
canonical equivalence.

As an example, http://www.w3.org/2003/06/xml1.1test/Overview.html has 
some code (both UTF-8 and UTF-16) for compact (memory footprint) and 
reasonably fast NFC check. Please ignore the "XML 1.1" in the title. 
Also please note that this is proof of concept code, and may need 
additional testing and of course upgrade to the newest version of 
Unicode. I don't have any open bug reports, but that may be for other 
reasons than that there are no bugs.

Also, there are various ways to trade off speed against memory (see also 
Bjrn's mail), but the memory here is just the footprint of the sharable 
data, there's no need for lots of memory per conversion.


> For the K portion, I have found John's argument compelling that codepoints
> with compatibility decompositions should just be prohibited in our
> localparts.

Probably just fine for most cases. Potentially a problem for wide/narrow 
in places like Japan.

> In our resourceparts, I'm of the opinion that we don't need to
> compatibility map -- it's fine for all of those codepoints to stay distinct.

Yes indeed.

> The idea is that clients SHOULD normalize, servers double-check inputs from
> non-trusted sources (like clients and other servers), then always store and
> forward the normalized version.

That's fine. But it doesn't explain the choice of NFD (vs. NFC).

Regards,   Martin.

From duerst@it.aoyama.ac.jp  Fri Jul 22 01:25:54 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B9221F8508 for ; Fri, 22 Jul 2011 01:25:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.826
X-Spam-Level: 
X-Spam-Status: No, score=-99.826 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.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 O74gVJm9TNgf for ; Fri, 22 Jul 2011 01:25:54 -0700 (PDT)
Received: from acintmta02.acbb.aoyama.ac.jp (acintmta02.acbb.aoyama.ac.jp [133.2.20.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA2021F8504 for ; Fri, 22 Jul 2011 01:25:53 -0700 (PDT)
Received: from acmse02.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta02.acbb.aoyama.ac.jp (secret/secret) with SMTP id p6M8PkHc018533 for ; Fri, 22 Jul 2011 17:25:46 +0900
Received: from (unknown [133.2.206.133]) by acmse02.acbb.aoyama.ac.jp with smtp id 713b_4f00_32cdb87e_b43c_11e0_a359_001d0969ab06; Fri, 22 Jul 2011 17:25:46 +0900
Received: from [IPv6:::1] ([133.2.210.5]:57892) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Fri, 22 Jul 2011 17:25:49 +0900
Message-ID: <4E2933D7.7010404@it.aoyama.ac.jp>
Date: Fri, 22 Jul 2011 17:24:55 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Frank Ellermann 
References: <4E25D187.7010901@stpeter.im> <4E25D8FE.9030402@stpeter.im>	 <4E25EA21.9090207@stpeter.im>	<4E2723DD.6090408@dcrocker.net> <4E2725CE.8020800@stpeter.im> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jul 2011 08:25:55 -0000

On 2011/07/22 15:08, Frank Ellermann wrote:
> On 20 July 2011 21:00, Peter Saint-Andre wrote:
>
>> In fact I've presented ~100 slides in 8-10
>> minutes before, so this one will be in slow
>> motion because we've got 2 hours. :)
>
> Thanks - almost all points covered.  Maybe JohnK
> or Martin could add a slide why using UTF-8 (or
> even UTF-6) was no option for IDNA2003, but okay
> for EAI.

I'll defer to John here. I was pushing strongly for UTF-8 for IDNA2003, 
but thought that pure UTF-8 could never happen for email, because I was 
told so for over 10 years from all sides.

Regards,   Martin.

> The "EAI history" in JohnL's blog is
> also very good.
>
> -Frank
>   
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From luyan@zte.com.cn  Fri Jul 22 01:27:20 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9291C21F85B8 for ; Fri, 22 Jul 2011 01:27:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.736
X-Spam-Level: 
X-Spam-Status: No, score=-99.736 tagged_above=-999 required=5 tests=[AWL=-2.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 UoI0bLTv-r7b for ; Fri, 22 Jul 2011 01:27:19 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E46B221F8540 for ; Fri, 22 Jul 2011 01:27:18 -0700 (PDT)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48641193944097; Fri, 22 Jul 2011 16:25:29 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 13796.3634574820; Fri, 22 Jul 2011 16:12:39 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p6M8CXIU009648; Fri, 22 Jul 2011 16:12:33 +0800 (GMT-8) (envelope-from luyan@zte.com.cn)
In-Reply-To: <9031.1311243581.256116@puncture>
To: Dave Cridland 
MIME-Version: 1.0
X-KeepSent: C24805BE:30C38C8A-482578D5:002C72D9; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: luyan@zte.com.cn
Date: Fri, 22 Jul 2011 16:12:35 +0800
X-MIMETrack: S/MIME Sign by Notes Client on LuYan029354/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-22 16:15:03, Serialize by Notes Client on LuYan029354/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-22 16:15:03, Serialize complete at 2011-07-22 16:15:03, S/MIME Sign failed at 2011-07-22 16:15:04: ???????, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-22 16:12:36, Serialize complete at 2011-07-22 16:12:36
Content-Type: multipart/alternative; boundary="=_alternative 002D530F482578D5_="
X-MAIL: mse02.zte.com.cn p6M8CXIU009648
Cc: "SHIH, JERRY \(ATTSI\)" , "jiaxw9@chinaunicom.cn" , "ding.xin@zte.com.cn" , General discussion of application-layer protocols 
Subject: Re: [apps-discuss] Extentions of IMAP4
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jul 2011 08:27:20 -0000

This is a multipart message in MIME format.
--=_alternative 002D530F482578D5_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

RGVhciBEYXZlIENyaWRsYW5kLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuIFBsZWFz
ZSBzZWUgb3VyIHJlcGx5IGluLWxpbmUuDQoNClJlZ2FyZHMsDQoNCllhbiBMVQ0KDQpEYXZlIENy
aWRsYW5kIDxkYXZlQGNyaWRsYW5kLm5ldD4g0LTT2iAyMDExLTA3LTIxIDE4OjE5OjQxOg0KDQo+
IE9uIFRodSBKdWwgMjEgMTA6NDA6MjUgMjAxMSwgbHV5YW5AenRlLmNvbS5jbiB3cm90ZToNCj4g
PiANCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWppYS1pbWFwLW11bHRp
YWNjb3VudC1hdXRoZW50aWNhdGlvbi8NCj4gDQo+IFRoaXMgb25lIGlzIGRpc3RpbmN0bHkgaGFu
ZC13YXZleSwgdG8gdGhlIGV4dGVudCBJIGhhdmUgbm8gY2xlYXIgaWRlYSANCj4gd2hhdCBpdCBt
ZWFucy4NCj4gDQo+IEkgKnRoaW5rKiBpdCBtZWFucyB0byBzYXkgdGhhdCBtdWx0aXBsZSBhdXRo
emlkcyBtYXkgYmUgYXNzb2NpYXRlZCANCj4gd2l0aCBhIHNpbmdsZSBhdXRoZW50aWNhdGlvbiBp
ZGVudGlmaWVyLCBhbmQgdGhlc2UgbWF5IGJlIGFjdGl2ZSANCj4gY29uY3VycmVudGx5IC0gd2hh
dCB0aGlzIGluIHR1cm4gbWVhbnMgaW4gdGVybXMgb2YsIGZvciBleGFtcGxlLCB3aGF0IA0KPiAi
SU5CT1giIG5vdyBtZWFucyBpcyBiZXlvbmQgbWUsIHRob3VnaC4NCj4gDQoNCltZYW4gTFVdIFRo
ZSBpbnRlbnRpb24gb2YgdGhpcyBkcmFmdCBpcyB0byBhc3NvY2lhdGUgbXVsdGlwbGUgaWRlbnRp
dGllcyANCmJlbG9uZ2luZyB0byBvbmUgdXNlci4gVGh1cywgYWZ0ZXIgbG9nZ2luZyBpbiwgdGhl
IHVzZXIgbWF5IGNob29zZSBvbmUgb2YgDQp0aGVzZSBhc3NvY2lhdGVkIGlkZW50aXRpZXMsIHVu
ZGVyIGVhY2ggb2Ygd2hpY2ggdGhlcmUgY2FuIGJlIGFuIElOQk9YLCBhIA0KU0VOVEJPWCBhbmQg
b3RoZXIgZm9sZGVycywgYXMgc2hvd24gaW4gdGhlIGZvbGxvd2luZyBmaWd1cmUuDQoNClVzZXIt
LSstLUlkZW50aXR5MS0tLSstLS1JTkJPWA0KICAgICAgfCAgICAgICAgIHwgDQogICAgICB8ICAg
ICAgICAgKy0tLSBTRU5UQk9YDQogICAgICB8ICAgICAgICAgICAgICAgIHwNCiAgICAgIHwgICAg
ICAgICArLS0tIE9USEVSIEZPTERFUlMNCiAgICAgIHwgDQogICAgICB8IA0KICAgICAgKy0tSWRl
bnRpdHkyLS0tKy0tLUlOQk9YDQogICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICAg
ICAgICAgICAgICAgICstLS0gU0VOVEJPWA0KICAgICAgICAgICAgICAgICAgICAgICB8DQogICAg
ICAgICAgICAgICAgICAgICAgICstLS0gT1RIRVIgRk9MREVSUw0KDQoNCj4gPiBodHRwczovL2Rh
dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sdS1pbWFwLW11bHRpLWFjY291bnQvDQo+IA0K
PiBUaGlzIG9uZSBhcHBlYXJzIHRvIGJ1aWxkIG9uIHRoZSBhYm92ZSwgZXhjZXB0IGl0LCB0b28s
IGNvbmZ1c2VzIA0KPiBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbi4NCj4gDQo+IEkn
bSByZWFzb25hYmx5IGNvbnZpbmNlZCB0aGF0IHRoZSBmaXJzdCBkcmFmdCBpcyBlbnRpcmVseSBy
ZWR1bmRhbnQsIA0KPiBhbmQgdGhpcyBvbmUncyB1dGlsaXR5IGlzIGxpbWl0ZWQuIEluIHBhcnRp
Y3VsYXIsIGl0J3Mgbm90IGNsZWFyIHRvIA0KPiBtZSB3aHkgeW91J2Qgd2FudCB0aGlzIGluc3Rl
YWQgb2YganVzdCB1c2luZyBtdWx0aXBsZSBhdXRoZW50aWNhdGlvbiANCj4gaWRlbnRpZmVycyBh
bmQgbXVsdGlwbGUgY29ubmVjdGlvbnMsIGFuZCBubyByYXRpb25hbGUgaXMgZ2l2ZW4gaW4gdGhl
IA0KPiBkb2N1bWVudC4NCj4gDQo+IA0KDQpbWWFuIExVXSBUaGUgcmVhc29uIHdoeSB3ZSBzdWJt
aXR0ZWQgdGhlc2UgdHdvIGRyYWZ0cyBzZXBhcmF0ZWx5IGlzIHRoYXQgDQp0aGUgZmlyc3Qgb25l
IGNhbiB0YWtlIGVmZmVjdCBldmVuIHdpdGhvdXQgaW1wbGVtZW50aW5nIHRoZSBzZWNvbmQgb25l
LiBBcyANCnlvdSBtZW50aW9uZWQsIGZvciB0aGUgc2Vjb25kIG9uZSwgdGhlIGlzc3VlIGNhbiBi
ZSBpbXBsZW1lbnRlZCB3aXRoIA0KbXVsdGlwbGUgY29ubmVjdGlvbnMuIEJ1dCBmcm9tIHRoZSBw
ZXJzcGVjdGl2ZSBvZiB0aGUgdXNlciwgaXQgd2lsbCANCmltcHJvdmUgdGhlIHVzZXIgZXhwZXJp
ZW5jZSBpZiB0aGUgdXNlciBkb2VzIG5vdCBoYXZlIHRvIGxvZyBpbiBmb3IgDQpzZXZlcmFsIHRp
bWVzLg0KDQpMZXQgdXMgZm9jdXMgb24gdGhlIG11bHRpcGxlLWNvbm5lY3Rpb24gc29sdXRpb24u
IEZpcnN0IG9mIGFsbCwgaXQgd2lsbCANCmluY3JlYXNlIHRoZSBidXJkZW4gb2YgdGhlIG5ldHdv
cmsuIFNlY29uZGx5LCB3aXRob3V0IHRoZSBmaXJzdCBkcmFmdCwgdGhlIA0KdXNlciBoYXMgdG8g
bG9nIGluIGZvciBtdWx0aXBsZSB0aW1lcyB0byBlc3RhYmxpc2ggYWxsIHRoZSBjb25uZWN0aW9u
cywgDQp3aGljaCBJIGRvbid0IHRoaW5rIGlzIGEgZ29vZCBpZGVhLiBXaXRoIHRoZSBmaXJzdCBk
cmFmdCwgd2h5IG5vdCBqdXN0IA0KZXN0YWJsaXNoIG9uZSBjb25uZWN0aW9uIGZvciBhbGwgYXNz
b2NpYXRlZCBpZGVudGl0aWVzPw0KDQoNCj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn
L2RvYy9kcmFmdC1zaGloLWltYXAtc2VydmVyLWxvZ291dC8NCj4gDQo+IElNQVA0cmV2MSBhbHJl
YWR5IGFsbG93cyBzZXJ2ZXJzIHRvIHVuaWxhdGVyYWxseSB0ZXJtaW5hdGUgdGhlIA0KPiBzZXNz
aW9uIHdpdGggYSAqIEJZRS4gSW50cm9kdWNpbmcgc2VydmVyLWluaXRpYXRlZCBjb21tYW5kcyBp
cyBmYXIsIA0KPiBmYXIgYmV5b25kIGEgc2ltcGxlIGRyYWZ0IGxpa2UgdGhpcy4NCj4gDQo+IEEg
c2Vuc2libGUgYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gaGF2ZSBzZXJ2ZXJzIGlzc3VlIGEgZGlm
ZmVyZW50IA0KPiB1bnRhZ2dlZCByZXNwb25zZSAoKiBURVJNSU5BVEUsIHBlcmhhcHM/KSBpbiBv
cmRlciB0byBlbmNvdXJhZ2UgDQo+IGNsaWVudHMgaW50byBsb2dnaW5nIG91dCBxdWlja2x5LCBp
ZiB3ZSB3YW50IHRvIGhhdmUgYSBtb3JlIGdyYWNlZnVsIA0KPiB0ZXJtaW5hdGlvbiBvZiBjbGll
bnQgc2Vzc2lvbnMuIFRoaXMgd291bGQgbmVlZCB0byBiZSBzaWduYWxsZWQgd2l0aCANCj4gYW4g
RU5BQkxFLCB0aG91Z2guDQo+IA0KDQpbWWFuIExVXSBJIGFncmVlIHdpdGggeW91IHRoYXQgc2Vy
dmVyLWluaXRpYXRlZCBjb21tYW5kcyBjYW4gYmUgDQpjb21wbGljYXRlZC4gVGhlIGludGVudGlv
biBvZiB0aGlzIGRyYWZ0IGlzIHRvIHRyeSB0byBmaW5kIGEgd2F5IGZvciB0aGUgDQpzZXJ2ZXIg
dG8gdGVybWluYXRlIHNlc3Npb24gYWN0aXZlbHkuIEkgYW0gd29uZGVyaW5nIGlmIHRoZSBCWUUg
cmVzcG9uc2UgDQpjYW4gYmUgc2VudCBvdXQgd2l0aG91dCBjb3JyZXNwb25kaW5nIHRvIGFueSBw
cmV2aW91cyBjb21tYW5kIGZyb20gYSANCmNsaWVudC4gQ291bGQgeW91IHByb3ZpZGUgbW9yZSBk
ZXRhaWxzPw0KDQo+IERhdmUuDQo+IC0tIA0KPiBEYXZlIENyaWRsYW5kIC0gbWFpbHRvOmRhdmVA
Y3JpZGxhbmQubmV0IC0geG1wcDpkd2RAZGF2ZS5jcmlkbGFuZC5uZXQNCj4gICAtIGFjYXA6Ly9h
Y2FwLmRhdmUuY3JpZGxhbmQubmV0L2J5b3duZXIvdXNlci9kd2QvYm9va21hcmtzLw0KPiAgIC0g
aHR0cDovL2RhdmUuY3JpZGxhbmQubmV0Lw0KPiBJbmZvdHJvcGUgUG9seW1lciAtIEFDQVAsIElN
QVAsIEVTTVRQLCBhbmQgTGVtb25hZGUNCj4gDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2Vj
dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBz
b2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNv
bW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBv
YmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlz
Y2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlz
IGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFs
IGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50
aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz
IGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3Nh
Z2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUg
aW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Igdmly
dXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg==
--=_alternative 002D530F482578D5_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkRlYXIgPC9mb250Pjx0dD48Zm9u
dCBzaXplPTI+RGF2ZSBDcmlkbGFuZDwvZm9udD48L3R0Pjxmb250IHNpemU9MiBmYWNlPSJzYW5z
LXNlcmlmIj4sPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm
Ij5UaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuIFBsZWFzZQ0Kc2VlIG91ciByZXBseSBpbi1s
aW5lLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+UmVn
YXJkcyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPllh
biBMVTwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkRhdmUgQ3JpZGxhbmQgJmx0
O2RhdmVAY3JpZGxhbmQubmV0Jmd0OyDQtNPaIDIwMTEtMDctMjENCjE4OjE5OjQxOjxicj4NCjxi
cj4NCiZndDsgT24gVGh1IEp1bCAyMSAxMDo0MDoyNSAyMDExLCBsdXlhbkB6dGUuY29tLmNuIHdy
b3RlOjxicj4NCiZndDsgJmd0OyBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm
dC1qaWEtaW1hcC1tdWx0aWFjY291bnQtYXV0aGVudGljYXRpb24vPGJyPg0KJmd0OyA8YnI+DQom
Z3Q7IFRoaXMgb25lIGlzIGRpc3RpbmN0bHkgaGFuZC13YXZleSwgdG8gdGhlIGV4dGVudCBJIGhh
dmUgbm8gY2xlYXIgaWRlYQ0KJm5ic3A7PGJyPg0KJmd0OyB3aGF0IGl0IG1lYW5zLjxicj4NCiZn
dDsgPGJyPg0KJmd0OyBJICp0aGluayogaXQgbWVhbnMgdG8gc2F5IHRoYXQgbXVsdGlwbGUgYXV0
aHppZHMgbWF5IGJlIGFzc29jaWF0ZWQNCiZuYnNwOzxicj4NCiZndDsgd2l0aCBhIHNpbmdsZSBh
dXRoZW50aWNhdGlvbiBpZGVudGlmaWVyLCBhbmQgdGhlc2UgbWF5IGJlIGFjdGl2ZSAmbmJzcDs8
YnI+DQomZ3Q7IGNvbmN1cnJlbnRseSAtIHdoYXQgdGhpcyBpbiB0dXJuIG1lYW5zIGluIHRlcm1z
IG9mLCBmb3IgZXhhbXBsZSwgd2hhdA0KJm5ic3A7PGJyPg0KJmd0OyAmcXVvdDtJTkJPWCZxdW90
OyBub3cgbWVhbnMgaXMgYmV5b25kIG1lLCB0aG91Z2guPGJyPg0KJmd0OyA8L2ZvbnQ+PC90dD4N
Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwvZm9udD48L3R0Pjxmb250IHNpemU9Mj5bWWFu
IExVXSBUaGUgaW50ZW50aW9uIG9mIHRoaXMgZHJhZnQgaXMgdG8gYXNzb2NpYXRlDQptdWx0aXBs
ZSBpZGVudGl0aWVzIGJlbG9uZ2luZyB0byBvbmUgdXNlci4gVGh1cywgYWZ0ZXIgbG9nZ2luZyBp
biwgdGhlDQp1c2VyIG1heSBjaG9vc2Ugb25lIG9mIHRoZXNlIGFzc29jaWF0ZWQgaWRlbnRpdGll
cywgdW5kZXIgZWFjaCBvZiB3aGljaA0KdGhlcmUgY2FuIGJlIGFuIElOQk9YLCBhIFNFTlRCT1gg
YW5kIG90aGVyIGZvbGRlcnMsIGFzIHNob3duIGluIHRoZSBmb2xsb3dpbmcNCmZpZ3VyZS48L2Zv
bnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5Vc2VyLS0rLS1JZGVudGl0eTEtLS0rLS0t
SU5CT1g8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJzcDsgJm5i
c3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48
Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOystLS0gU0VOVEJPWDwvZm9udD48L3R0
Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PC9mb250Pjwv
dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ky0tLSBPVEhF
UiBGT0xERVJTPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7
ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KPC9mb250PjwvdHQ+DQo8YnI+
PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+
PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7ICZuYnNwOyArLS1JZGVudGl0eTItLS0rLS0t
SU5CT1g8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu
YnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ky0tLSBTRU5UQk9YPC9mb250PjwvdHQ+DQo8
YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PC9mb250Pjwv
dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsrLS0tIE9USEVSIEZPTERFUlM8L2ZvbnQ+PC90dD4NCjxicj4NCjxi
cj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgJmd0OyBodHRwczovL2RhdGF0cmFja2VyLmll
dGYub3JnL2RvYy9kcmFmdC1sdS1pbWFwLW11bHRpLWFjY291bnQvPGJyPg0KJmd0OyA8YnI+DQom
Z3Q7IFRoaXMgb25lIGFwcGVhcnMgdG8gYnVpbGQgb24gdGhlIGFib3ZlLCBleGNlcHQgaXQsIHRv
bywgY29uZnVzZXMgJm5ic3A7PGJyPg0KJmd0OyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXph
dGlvbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgSSdtIHJlYXNvbmFibHkgY29udmluY2VkIHRoYXQg
dGhlIGZpcnN0IGRyYWZ0IGlzIGVudGlyZWx5IHJlZHVuZGFudCwNCiZuYnNwOzxicj4NCiZndDsg
YW5kIHRoaXMgb25lJ3MgdXRpbGl0eSBpcyBsaW1pdGVkLiBJbiBwYXJ0aWN1bGFyLCBpdCdzIG5v
dCBjbGVhciB0bw0KJm5ic3A7PGJyPg0KJmd0OyBtZSB3aHkgeW91J2Qgd2FudCB0aGlzIGluc3Rl
YWQgb2YganVzdCB1c2luZyBtdWx0aXBsZSBhdXRoZW50aWNhdGlvbg0KJm5ic3A7PGJyPg0KJmd0
OyBpZGVudGlmZXJzIGFuZCBtdWx0aXBsZSBjb25uZWN0aW9ucywgYW5kIG5vIHJhdGlvbmFsZSBp
cyBnaXZlbiBpbg0KdGhlICZuYnNwOzxicj4NCiZndDsgZG9jdW1lbnQuPGJyPg0KJmd0OyA8YnI+
DQomZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj5bWWFuIExVXSBUaGUg
cmVhc29uIHdoeSB3ZSBzdWJtaXR0ZWQgdGhlc2UgdHdvIGRyYWZ0cw0Kc2VwYXJhdGVseSBpcyB0
aGF0IHRoZSBmaXJzdCBvbmUgY2FuIHRha2UgZWZmZWN0IGV2ZW4gd2l0aG91dCBpbXBsZW1lbnRp
bmcNCnRoZSBzZWNvbmQgb25lLiBBcyB5b3UgbWVudGlvbmVkLCBmb3IgdGhlIHNlY29uZCBvbmUs
IHRoZSBpc3N1ZSBjYW4gYmUNCmltcGxlbWVudGVkIHdpdGggbXVsdGlwbGUgY29ubmVjdGlvbnMu
IEJ1dCBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUNCnVzZXIsIGl0IHdpbGwgaW1wcm92ZSB0
aGUgdXNlciBleHBlcmllbmNlIGlmIHRoZSB1c2VyIGRvZXMgbm90IGhhdmUgdG8NCmxvZyBpbiBm
b3Igc2V2ZXJhbCB0aW1lcy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPkxldCB1cyBm
b2N1cyBvbiB0aGUgbXVsdGlwbGUtY29ubmVjdGlvbiBzb2x1dGlvbi4gRmlyc3QNCm9mIGFsbCwg
aXQgd2lsbCBpbmNyZWFzZSB0aGUgYnVyZGVuIG9mIHRoZSBuZXR3b3JrLiBTZWNvbmRseSwgd2l0
aG91dCB0aGUNCmZpcnN0IGRyYWZ0LCB0aGUgdXNlciBoYXMgdG8gbG9nIGluIGZvciBtdWx0aXBs
ZSB0aW1lcyB0byBlc3RhYmxpc2ggYWxsDQp0aGUgY29ubmVjdGlvbnMsIHdoaWNoIEkgZG9uJ3Qg
dGhpbmsgaXMgYSBnb29kIGlkZWEuIFdpdGggdGhlIGZpcnN0IGRyYWZ0LA0Kd2h5IG5vdCBqdXN0
IGVzdGFibGlzaCBvbmUgY29ubmVjdGlvbiBmb3IgYWxsIGFzc29jaWF0ZWQgaWRlbnRpdGllcz88
L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7ICZndDsgaHR0cHM6
Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2hpaC1pbWFwLXNlcnZlci1sb2dvdXQv
PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElNQVA0cmV2MSBhbHJlYWR5IGFsbG93cyBzZXJ2ZXJzIHRv
IHVuaWxhdGVyYWxseSB0ZXJtaW5hdGUgdGhlICZuYnNwOzxicj4NCiZndDsgc2Vzc2lvbiB3aXRo
IGEgKiBCWUUuIEludHJvZHVjaW5nIHNlcnZlci1pbml0aWF0ZWQgY29tbWFuZHMgaXMgZmFyLA0K
Jm5ic3A7PGJyPg0KJmd0OyBmYXIgYmV5b25kIGEgc2ltcGxlIGRyYWZ0IGxpa2UgdGhpcy48YnI+
DQomZ3Q7IDxicj4NCiZndDsgQSBzZW5zaWJsZSBhbHRlcm5hdGl2ZSB3b3VsZCBiZSB0byBoYXZl
IHNlcnZlcnMgaXNzdWUgYSBkaWZmZXJlbnQNCiZuYnNwOzxicj4NCiZndDsgdW50YWdnZWQgcmVz
cG9uc2UgKCogVEVSTUlOQVRFLCBwZXJoYXBzPykgaW4gb3JkZXIgdG8gZW5jb3VyYWdlICZuYnNw
Ozxicj4NCiZndDsgY2xpZW50cyBpbnRvIGxvZ2dpbmcgb3V0IHF1aWNrbHksIGlmIHdlIHdhbnQg
dG8gaGF2ZSBhIG1vcmUgZ3JhY2VmdWwNCiZuYnNwOzxicj4NCiZndDsgdGVybWluYXRpb24gb2Yg
Y2xpZW50IHNlc3Npb25zLiBUaGlzIHdvdWxkIG5lZWQgdG8gYmUgc2lnbmFsbGVkIHdpdGgNCiZu
YnNwOzxicj4NCiZndDsgYW4gRU5BQkxFLCB0aG91Z2guPGJyPg0KJmd0OyA8L2ZvbnQ+PC90dD4N
Cjxicj4NCjxicj48Zm9udCBzaXplPTI+W1lhbiBMVV0gSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHNl
cnZlci1pbml0aWF0ZWQgY29tbWFuZHMNCmNhbiBiZSBjb21wbGljYXRlZC4gVGhlIGludGVudGlv
biBvZiB0aGlzIGRyYWZ0IGlzIHRvIHRyeSB0byBmaW5kIGEgd2F5DQpmb3IgdGhlIHNlcnZlciB0
byB0ZXJtaW5hdGUgc2Vzc2lvbiBhY3RpdmVseS4gSSBhbSB3b25kZXJpbmcgaWYgdGhlIEJZRQ0K
cmVzcG9uc2UgY2FuIGJlIHNlbnQgb3V0IHdpdGhvdXQgY29ycmVzcG9uZGluZyB0byBhbnkgcHJl
dmlvdXMgY29tbWFuZA0KZnJvbSBhIGNsaWVudC4gQ291bGQgeW91IHByb3ZpZGUgbW9yZSBkZXRh
aWxzPzwvZm9udD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgRGF2ZS48YnI+DQom
Z3Q7IC0tIDxicj4NCiZndDsgRGF2ZSBDcmlkbGFuZCAtIG1haWx0bzpkYXZlQGNyaWRsYW5kLm5l
dCAtIHhtcHA6ZHdkQGRhdmUuY3JpZGxhbmQubmV0PGJyPg0KJmd0OyAmbmJzcDsgLSBhY2FwOi8v
YWNhcC5kYXZlLmNyaWRsYW5kLm5ldC9ieW93bmVyL3VzZXIvZHdkL2Jvb2ttYXJrcy88YnI+DQom
Z3Q7ICZuYnNwOyAtIGh0dHA6Ly9kYXZlLmNyaWRsYW5kLm5ldC88YnI+DQomZ3Q7IEluZm90cm9w
ZSBQb2x5bWVyIC0gQUNBUCwgSU1BUCwgRVNNVFAsIGFuZCBMZW1vbmFkZTxicj4NCiZndDsgPGJy
Pg0KPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZu
YnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7
Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5
Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5p
emF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5i
c3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5i
c3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3km
bmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rp
c2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21t
dW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQm
bmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5i
c3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xl
bHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2
aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJz
cDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVj
ZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNl
Jm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5i
c3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5i
c3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhl
Jm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFz
Jm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5i
c3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9w
cmU+
--=_alternative 002D530F482578D5_=--


From dave@cridland.net  Fri Jul 22 03:16:25 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E04321F8509 for ; Fri, 22 Jul 2011 03:16:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.544
X-Spam-Level: 
X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055,  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 uygIWs74fP0u for ; Fri, 22 Jul 2011 03:16:24 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 60D8F21F84DD for ; Fri, 22 Jul 2011 03:16:15 -0700 (PDT)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 5D8001168067; Fri, 22 Jul 2011 11:16:14 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCNffpzShip2; Fri, 22 Jul 2011 11:16:10 +0100 (BST)
Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 207C11168087; Fri, 22 Jul 2011 11:16:10 +0100 (BST)
References: 
In-Reply-To: 
MIME-Version: 1.0
Message-Id: <9031.1311329770.120161@puncture>
Date: Fri, 22 Jul 2011 11:16:10 +0100
From: Dave Cridland 
To: "luyan@zte.com.cn" , General discussion of application-layer protocols ,  "ding.xin@zte.com.cn" , "jiaxw9@chinaunicom.cn" , "SHIH, JERRY \(ATTSI\)" 
Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: 8Bit
Subject: Re: [apps-discuss] Extentions of IMAP4
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jul 2011 10:16:25 -0000

On Fri Jul 22 09:12:35 2011, luyan@zte.com.cn wrote:
> [Yan LU] The intention of this draft is to associate multiple  
> identities
> belonging to one user. Thus, after logging in, the user may choose  
> one of
> these associated identities, under each of which there can be an  
> INBOX, a
> SENTBOX and other folders, as shown in the following figure.

OK. In the SASL model, an authentication identifier can have access  
to many authorization identifiers already; so no change is needed  
here.

> > > https://datatracker.ietf.org/doc/draft-lu-imap-multi-account/
> >
> > This one appears to build on the above, except it, too, confuses
> > authentication and authorization.
> >
> > I'm reasonably convinced that the first draft is entirely  
> redundant,
> > and this one's utility is limited. In particular, it's not clear  
> to
> > me why you'd want this instead of just using multiple  
> authentication
> > identifers and multiple connections, and no rationale is given in  
> the
> > document.
> >
> >
> 
> [Yan LU] The reason why we submitted these two drafts separately is  
> that
> the first one can take effect even without implementing the second  
> one. As
> you mentioned, for the second one, the issue can be implemented with
> multiple connections. But from the perspective of the user, it will
> improve the user experience if the user does not have to log in for
> several times.
> 
> Let us focus on the multiple-connection solution. First of all, it  
> will
> increase the burden of the network. Secondly, without the first  
> draft, the
> user has to log in for multiple times to establish all the  
> connections,
> which I don't think is a good idea. With the first draft, why not  
> just
> establish one connection for all associated identities?
> 
> 
Mostly because you're not - you're associating authorization  
identities sequentially, rather than concurrently.

You could build on namespaces, incidentally, to achieve much the same  
goal, by simply defining a standard method for locating other  
authorization identifiers' INBOXes.

But allowing a user to switch authorization identifier mid-flow will  
almost certainly introduce some complex edge-cases within security -  
I've a strong feeling that this opens up possibilities for TOCTOU  
errors.

> [Yan LU] I agree with you that server-initiated commands can be
> complicated. The intention of this draft is to try to find a way  
> for the
> server to terminate session actively. I am wondering if the BYE  
> response
> can be sent out without corresponding to any previous command from a
> client. Could you provide more details?

Technically, you are able to send almost any response at any time.

Use of BYE in this way is discussed in RFC 3501 7.1.5, and RFC 3501  
3.4 discusses servers unilaterally closing connections.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From john-ietf@jck.com  Fri Jul 22 05:35:18 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EE321F8586 for ; Fri, 22 Jul 2011 05:35:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.639
X-Spam-Level: 
X-Spam-Status: No, score=-102.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, 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 lUlSOacANu4V for ; Fri, 22 Jul 2011 05:35:17 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 28C6321F855C for ; Fri, 22 Jul 2011 05:35:17 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QkEwb-000Bzz-Qe; Fri, 22 Jul 2011 08:35:06 -0400
Date: Fri, 22 Jul 2011 08:35:04 -0400
From: John C Klensin 
To: Dave Cridland , luyan@zte.com.cn, General discussion of application-layer protocols , ding.xin@zte.com.cn, jiaxw9@chinaunicom.cn,  "SHIH, JERRY \\(ATTSI\\)" 
Message-ID: 
In-Reply-To: <9031.1311329770.120161@puncture>
References:  <9031.1311329770.120161@puncture>
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: Re: [apps-discuss] Extentions of IMAP4
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jul 2011 12:35:18 -0000

--On Friday, July 22, 2011 11:16 +0100 Dave Cridland
 wrote:

> On Fri Jul 22 09:12:35 2011, luyan@zte.com.cn wrote:
>> [Yan LU] The intention of this draft is to associate multiple
>>  identities
>> belonging to one user. Thus, after logging in, the user may
>> choose   one of
>> these associated identities, under each of which there can be
>> an   INBOX, a
>> SENTBOX and other folders, as shown in the following figure.
> 
> OK. In the SASL model, an authentication identifier can have
> access to many authorization identifiers already; so no change
> is needed here.

Let me add one much more general observation to Dave's specific
ones:

IMO, IMAP is arguably already much too big and too complicated,
at least partially due to the addition of features that provide
different ways to do the same thing.  In principle, adding more
optional features should not be a problem, but they make it very
hard for a user to predict what will be available from different
combinations of clients and servers.  That situation, in turn,
makes easy movement among clients on multiple devices less
likely and more difficult.

The LEMOMADE effort was supposed to improve on that situation.
As far as I can call, it did not succeed in that particular
goal; some would claim it made things worse.

To me, the best evidence for "much too big and too complicated"
is the very small number of available, well-designed, IMAP
clients that are fully-conformant to the protocol and up-to-date
on the majority of current features and extensions.  Some years
ago, an important contributor and developer of IMAP and other
email protocols observed that "all IMAP clients suck, 
sucks less than the others" (name omitted to avoid a distracting
side discussion).   If one adds the criterion that they be
tracking the efforts in the EAI WG that will require
modifications for, e.g.,  non-ASCII addresses, the number goes
down even further.

So, for whatever it is worth, I think the community should be
looking only at additional IMAP changes and extensions for which
there is a compelling need for a large number of users -- a need
that is compelling enough that we can assume that a large
fraction of client and server implementers will actually support
the proposed feature.   I believe the EAI i18n changes meet that
criterion.  These two proposals do not, not just for the reasons
Dave mentions, but because we haven't seen much evidence a huge
number of such users, because there are other ways around the
issue in IMAP (as Dave notes), and because a slightly different
organization of mailboxes and folders on the server (and a
competent client) can accomplish almost exactly the same thing
without any protocol changes at all.   I have some evidence for
the latter: I've been doing things that way, with standard IMAP
(and without a requirement for any of the very recent
extensions), for 15 years or so now.

    john


From Joe.Hildebrand@webex.com  Fri Jul 22 08:26:20 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AE321F8511; Fri, 22 Jul 2011 08:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.932
X-Spam-Level: 
X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, 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 XfwfaMKjsDGM; Fri, 22 Jul 2011 08:26:19 -0700 (PDT)
Received: from gw2.webex.com (gw2.webex.com [64.68.122.209]) by ietfa.amsl.com (Postfix) with SMTP id 8C17521F8510; Fri, 22 Jul 2011 08:26:19 -0700 (PDT)
Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw2.webex.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 22 Jul 2011 08:26:18 -0700
Received: from 64.101.74.200 ([64.101.74.200]) by SRV-EXSC03.webex.local ([192.168.252.200]) with Microsoft Exchange Server HTTP-DAV ;  Fri, 22 Jul 2011 15:26:18 +0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Fri, 22 Jul 2011 09:26:17 -0600
From: Joe Hildebrand 
To: "Martin J. =?ISO-8859-1?B?RPxyc3Q=?=" 
Message-ID: 
Thread-Topic: [xmpp] [apps-discuss] i18n intro, Sunday 14:00-16:00
Thread-Index: AcxIg7MfGf6kV+3Dnk+rFdfkWLCijw==
In-Reply-To: <4E292BC3.30301@it.aoyama.ac.jp>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-OriginalArrivalTime: 22 Jul 2011 15:26:18.0175 (UTC) FILETIME=[B3D2BCF0:01CC4883]
Cc: apps-discuss@ietf.org, xmpp@ietf.org
Subject: Re: [apps-discuss] [xmpp]  i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jul 2011 15:26:20 -0000

On 7/22/11 1:50 AM, "Martin J. D=FCrst"  wrote:

>> First some assumptions:
>> - Stringprep is currently one of the performance hotspots of some XMPP
>> servers.
>=20
> Is that an assumption backed by facts or a wild guess?

I can only talk definitively about one server, but yes, I've got data to
back up that assumption for that one server.

>> - If the spec is written that clients SHOULD perform canonicalization, m=
any
>> in our community will, particularly if they know that they will get bett=
er
>> performance from the server.
>=20
> That's the same for NFC and NFD, isn't it? The advantage of NFC is that
> it's designed to more-or-less match what's out there, so you get the
> advantage that there is more stuff that's already canonicalized even if
> if a client doesn't do anything. That gets reinforced by both the IETF
> and the W3C telling everybody to use NFC.

Absolutely.  However, my point is that our client community, unlike the MUA
community (for example) is more likely to adopt change.

>> The property of NFK?D that we like is that if you have a string of
>> codepoints that is already in NFK?D, you can check that the string is in=
 the
>> correct normalization form without having to allocate memory.  With NFK?=
C,
>> you'll have to decompose (allocating memory), recompose (at some finite =
CPU
>> cost), then recompose (possibly allocating *again*) just to check if you
>> have already done the normalization.
>=20
> Nope. That's just how the algorithm was defined, because the
> decomposition component was already around, and NFD was what defined
> canonical equivalence.
>=20
> As an example, http://www.w3.org/2003/06/xml1.1test/Overview.html has
> some code (both UTF-8 and UTF-16) for compact (memory footprint) and
> reasonably fast NFC check. Please ignore the "XML 1.1" in the title.
> Also please note that this is proof of concept code, and may need
> additional testing and of course upgrade to the newest version of
> Unicode. I don't have any open bug reports, but that may be for other
> reasons than that there are no bugs.

Am I correct that the key bit of your algorithm is:

"""Check for potential combination with starter. The list of recombinations
is calculated so that any combining character that would lead to a change
(full combination, recombination so that the combining character gets
combined in but another combining character is separated, complete
decomposition,...) is listed. 2176 such pairs have been found."""

Can you talk more about that?  Do we expect that future versions of Unicode
will change that set of pairs?

> Probably just fine for most cases. Potentially a problem for wide/narrow
> in places like Japan.

Yup.  That's why the wide/narrow stuff is still on the list of questions to
be addressed with this approach.  I also fully expect that there are N othe=
r
codepoints that are marked as having compatibility decomposition but are
actually in widespread use, and someone's going to complain about them one
day.

>> The idea is that clients SHOULD normalize, servers double-check inputs f=
rom
>> non-trusted sources (like clients and other servers), then always store =
and
>> forward the normalized version.
>=20
> That's fine. But it doesn't explain the choice of NFD (vs. NFC).

One other point, the re-composition stuff in the C forms *is* objectively
more difficult to implement, and will *always* take more CPU.  If it's not
required, it should be avoided.  And I haven't seen any compelling argument=
s
as to why C should be preferred.  What I've seen so far:

- That's the way we've always done it.  Not compelling to me if we're going
to switch away from NFKC in any way.
- Saves a few bytes on the wire.  Not compelling in a world with
compression.  (see: http://xmpp.org/extensions/xep-0138.html)
- More likely to render correctly.  Not with today's font renderers.

Are there any others I'm missing?

--=20
Joe Hildebrand


From dave@cridland.net  Fri Jul 22 08:44:41 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBB321F8B33; Fri, 22 Jul 2011 08:44:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.397
X-Spam-Level: 
X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 puzmNQdbtw+N; Fri, 22 Jul 2011 08:44:41 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id AFCC921F8B32; Fri, 22 Jul 2011 08:44:40 -0700 (PDT)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id BB19E1168087; Fri, 22 Jul 2011 16:44:39 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZUmzvipEKQ2; Fri, 22 Jul 2011 16:44:36 +0100 (BST)
Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id A683E1168067; Fri, 22 Jul 2011 16:44:35 +0100 (BST)
References: 
In-Reply-To: 
MIME-Version: 1.0
Message-Id: <9031.1311349475.663904@puncture>
Date: Fri, 22 Jul 2011 16:44:35 +0100
From: Dave Cridland 
To: Joe Hildebrand , General discussion of application-layer protocols ,  XMPP Working Group , =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: 8Bit
Subject: Re: [apps-discuss] [xmpp]  i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jul 2011 15:44:41 -0000

On Fri Jul 22 16:26:17 2011, Joe Hildebrand wrote:
> On 7/22/11 1:50 AM, "Martin J. Drst"   
> wrote:
> 
> >> First some assumptions:
> >> - Stringprep is currently one of the performance hotspots of  
> some XMPP
> >> servers.
> >
> > Is that an assumption backed by facts or a wild guess?
> 
> I can only talk definitively about one server, but yes, I've got  
> data to
> back up that assumption for that one server.

I have no opinion on NFC versus NFD, but on this specific point it is  
true for our server as well, and I'm aware of at least one other  
server for which stringprep is a key area of CPU usage (Not Joe's).

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From stpeter@stpeter.im  Sun Jul 24 06:39:29 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EB621F8891 for ; Sun, 24 Jul 2011 06:39:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 JOuZPhImNcJx for ; Sun, 24 Jul 2011 06:39:29 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E56D721F855F for ; Sun, 24 Jul 2011 06:39:28 -0700 (PDT)
Received: from squire.local (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E3FCD411CC for ; Sun, 24 Jul 2011 07:40:21 -0600 (MDT)
Message-ID: <4E2C208F.6060405@stpeter.im>
Date: Sun, 24 Jul 2011 09:39:27 -0400
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
References: <4E25D187.7010901@stpeter.im> <4E28F5F2.5080901@stpeter.im>
In-Reply-To: <4E28F5F2.5080901@stpeter.im>
X-Enigmail-Version: 1.2
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Jul 2011 13:39:29 -0000

FYI, I updated my slides on the plane yesterday:

http://www.saint-andre.com/ietf/i18n-intro.pdf

Undoubtedly, errors remain. Appropriate disclaimers will be expressed.

On 7/22/11 12:00 AM, Peter Saint-Andre wrote:
> Folks, thanks for all the feedback. I won't have time to reply
> individually, but I will work to adjust the slides before I present them
> on Sunday.
> 
> On 7/19/11 12:48 PM, Peter Saint-Andre wrote:
>> You might have noticed a curious item on the agenda at 14:00 on Sunday:
>> "Apps Area Preparatory Meeting for Internationalization Working Groups".
>>
>> At that time, I will present an introduction to internationalization,
>> assisted by Pete Resnick (who will correct me where I go wrong). The
>> intent of this session is to help apps-area folks learn more about
>> internationalization, especially in preparation for the PRECIS WG
>> meeting on Thursday. The room we've been assigned (2103) holds up to 60
>> people so we should have plenty of space, and there is no need to sign
>> up if you want to attend.
>>
>> If this session goes well, Pete and I might offer a more general
>> tutorial at a future IETF meeting. Consider Sunday's session a dry run.
>>
>> See you in Quebec City!
>>
>> Peter
>>

From nico@cryptonector.com  Sun Jul 24 12:37:31 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E5A21F86EC; Sun, 24 Jul 2011 12:37:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.856
X-Spam-Level: 
X-Spam-Status: No, score=-2.856 tagged_above=-999 required=5 tests=[AWL=-0.879, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 a58GCl58PEXa; Sun, 24 Jul 2011 12:37:31 -0700 (PDT)
Received: from homiemail-a72.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 457B821F84CE; Sun, 24 Jul 2011 12:37:31 -0700 (PDT)
Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 1A1FC6B0070; Sun, 24 Jul 2011 12:37:31 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=JJXrOsCKbSwPcTFyGQ+Bi lIubNSPdlfaZpqhuL/ECQuA49x249IOwkkJu4Xt/ABrXqUBGOAZkPygnIKeRZNG4 OGtriJJYNZ8rFnpIrDWdnOoUJXkQ5IlGrVbcmqWi2smfDco6tobcuSAN3GVwucS4 gtHwrWBRiKVrszPdjCqJpw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=6K6jxXGkbBcrfFfzhMpi RdtGGJQ=; b=yhCyCljSsXhoCdjiy4lLVB2EqWO6StKli7FJv6Ev1ab920ZdUfGr GcEN3gTYPxd05bkCI0YB5fTaP32zDiJ8KhF3Evj9d88hxHdMAoi4psqAkm0S6nac ZxJM2fwfnLZ+v7y9hAtPwDp2rPBmSCdy48eSKU2bJAOhsRz1XAfPhD4=
Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 026AE6B0014;  Sun, 24 Jul 2011 12:37:30 -0700 (PDT)
Received: by pzk6 with SMTP id 6so6872398pzk.26 for ; Sun, 24 Jul 2011 12:37:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.41.167 with SMTP id g7mr6502420pbl.173.1311536250672; Sun, 24 Jul 2011 12:37:30 -0700 (PDT)
Received: by 10.68.48.74 with HTTP; Sun, 24 Jul 2011 12:37:30 -0700 (PDT)
In-Reply-To: <234F16BC-9875-474B-95B3-D61E8BE5A6E0@checkpoint.com>
References: <5FA6AD59-7570-4A85-B6D1-3DC8E42688F1@mnot.net> <234F16BC-9875-474B-95B3-D61E8BE5A6E0@checkpoint.com>
Date: Sun, 24 Jul 2011 14:37:30 -0500
Message-ID: 
From: Nico Williams 
To: Yoav Nir 
Content-Type: text/plain; charset=UTF-8
Cc: "http-auth@ietf.org" , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] [http-auth] HTTP-Auth BoF in Quebec City Postponed
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Jul 2011 19:37:31 -0000

Sadly I cannot attend.  I planned my travel schedule for this week
around the original BoF, and so I depart Quebec in the afternoon.  I
look forward to the notes from any bar BoF :)

Nico
--

From stpeter@stpeter.im  Sun Jul 24 15:54:13 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9674921F877F; Sun, 24 Jul 2011 15:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 SXicsWNRUKDl; Sun, 24 Jul 2011 15:54:13 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABCB21F877D; Sun, 24 Jul 2011 15:54:13 -0700 (PDT)
Received: from dhcp-13ac.meeting.ietf.org (unknown [130.129.19.172]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E831D4120F; Sun, 24 Jul 2011 16:55:06 -0600 (MDT)
Message-ID: <4E2CA293.70603@stpeter.im>
Date: Sun, 24 Jul 2011 18:54:11 -0400
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Nico Williams 
References: <5FA6AD59-7570-4A85-B6D1-3DC8E42688F1@mnot.net> <234F16BC-9875-474B-95B3-D61E8BE5A6E0@checkpoint.com> 
In-Reply-To: 
X-Enigmail-Version: 1.2
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "http-auth@ietf.org" , Yoav Nir , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] [http-auth] HTTP-Auth BoF in Quebec City Postponed
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Jul 2011 22:54:13 -0000

On 7/24/11 3:37 PM, Nico Williams wrote:
> Sadly I cannot attend.  I planned my travel schedule for this week
> around the original BoF, and so I depart Quebec in the afternoon.  I
> look forward to the notes from any bar BoF :)

A few of us got together just now in a side room to chat informally.
We'll post further about some actions sometime soon. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From duerst@it.aoyama.ac.jp  Sun Jul 24 22:38:38 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B4021F85C0 for ; Sun, 24 Jul 2011 22:38:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.549
X-Spam-Level: 
X-Spam-Status: No, score=-100.549 tagged_above=-999 required=5 tests=[AWL=0.641, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.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 pQOWN2AgpQdd for ; Sun, 24 Jul 2011 22:38:38 -0700 (PDT)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD6521F8891 for ; Sun, 24 Jul 2011 22:38:37 -0700 (PDT)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p6P5cXVg028103 for ; Mon, 25 Jul 2011 14:38:33 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 0835_6ae1_561a51ca_b680_11e0_b526_001d096c5782; Mon, 25 Jul 2011 14:38:33 +0900
Received: from [IPv6:::1] ([133.2.210.5]:59236) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Mon, 25 Jul 2011 14:38:32 +0900
Message-ID: <4E2D0124.9040602@it.aoyama.ac.jp>
Date: Mon, 25 Jul 2011 14:37:40 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Joe Hildebrand 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: apps-discuss@ietf.org, xmpp@ietf.org
Subject: Re: [apps-discuss] [xmpp]  i18n intro, Sunday 14:00-16:00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jul 2011 05:38:38 -0000

Hello Joe,


On 2011/07/23 0:26, Joe Hildebrand wrote:
> On 7/22/11 1:50 AM, "Martin J. Drst"  wrote:
>
>>> First some assumptions:
>>> - Stringprep is currently one of the performance hotspots of some XMPP
>>> servers.
>>
>> Is that an assumption backed by facts or a wild guess?
>
> I can only talk definitively about one server, but yes, I've got data to
> back up that assumption for that one server.

Okay, thanks for the confirmation.

>>> - If the spec is written that clients SHOULD perform canonicalization, many
>>> in our community will, particularly if they know that they will get better
>>> performance from the server.
>>
>> That's the same for NFC and NFD, isn't it? The advantage of NFC is that
>> it's designed to more-or-less match what's out there, so you get the
>> advantage that there is more stuff that's already canonicalized even if
>> if a client doesn't do anything. That gets reinforced by both the IETF
>> and the W3C telling everybody to use NFC.
>
> Absolutely.  However, my point is that our client community, unlike the MUA
> community (for example) is more likely to adopt change.

Yes, but there's no need to adopt change without a really good reason. 
And there should be no need for XMPP to differ from the rest of the IETF.

BTW, can you tell us what programming language the server is written in? 
Are you using any kinds of libraries for character-related business?


>>> The property of NFK?D that we like is that if you have a string of
>>> codepoints that is already in NFK?D, you can check that the string is in the
>>> correct normalization form without having to allocate memory.  With NFK?C,
>>> you'll have to decompose (allocating memory), recompose (at some finite CPU
>>> cost), then recompose (possibly allocating *again*) just to check if you
>>> have already done the normalization.
>>
>> Nope. That's just how the algorithm was defined, because the
>> decomposition component was already around, and NFD was what defined
>> canonical equivalence.
>>
>> As an example, http://www.w3.org/2003/06/xml1.1test/Overview.html has
>> some code (both UTF-8 and UTF-16) for compact (memory footprint) and
>> reasonably fast NFC check. Please ignore the "XML 1.1" in the title.
>> Also please note that this is proof of concept code, and may need
>> additional testing and of course upgrade to the newest version of
>> Unicode. I don't have any open bug reports, but that may be for other
>> reasons than that there are no bugs.
>
> Am I correct that the key bit of your algorithm is:

In some way, yes.

> """Check for potential combination with starter. The list of recombinations
> is calculated so that any combining character that would lead to a change
> (full combination, recombination so that the combining character gets
> combined in but another combining character is separated, complete
> decomposition,...) is listed. 2176 such pairs have been found."""
>
> Can you talk more about that?

The actual list is in
http://dev.w3.org/cvsweb/~checkout~/charlint/xml1.1test/nf16data.c?content-type=text/plain, 
in the array 'recombiners'.

The first entry is {0x003C, 0x0338}, which is a '<' and a COMBINING LONG 
SOLIDUS OVERLAY. It's here because there is U+226E, NOT LESS-THAN, which 
is canonically equivalent, and therefore the sequence U+003C, U+0338 (or 
any sequence  U+003C, [other combining characters], U+0338 ) isn't in NFC.

Let's look at another entry: {0x00FC, 0x0300}. This is LATIN SMALL 
LETTER U WITH DIAERESIS () followed by COMBINING GRAVE ACCENT. This is 
not in NFC because there is U+01DC, LATIN SMALL LETTER U WITH DIAERESIS 
AND GRAVE.

Another, somewhat more involved example: {0x1EC5, 0x0323}. This is LATIN 
SMALL LETTER E WITH CIRCUMFLEX AND TILDE and COMBINING DOT BELOW. This 
is not in NFC because there is U+1EC7, LATIN SMALL LETTER E WITH 
CIRCUMFLEX AND DOT BELOW, and NFC is U+1EC7 + U+0303 (COMBINING TILDE) 
because combining characters below have a lower combining class and 
therefore are preferred when recombining.

> Do we expect that future versions of Unicode
> will change that set of pairs?

This is at least in theory possible. The data is from 2003. With input 
from the W3C, the Unicode Consortium created a fairly strong stability 
policies regarding normalization (please see 
http://www.unicode.org/policies/stability_policy.html, under 
"Normalization Stability"). As a result, for new precomposed characters, 
they had to be included in the combining exclusions. That meant that the 
benefit of proposing them as precomposed characters was lost, and there 
were virtually no such characters that made it all the way. It's still 
possible to propose a new script with some precomposed/decomposed 
alternatives, but I wouldn't know about a case where this has been done.

Please note that such additions would also affect decomposition, so a 
software (table) update would be needed independent of whether you go 
for NFC or NFD.

>> Probably just fine for most cases. Potentially a problem for wide/narrow
>> in places like Japan.
>
> Yup.  That's why the wide/narrow stuff is still on the list of questions to
> be addressed with this approach.  I also fully expect that there are N other
> codepoints that are marked as having compatibility decomposition but are
> actually in widespread use, and someone's going to complain about them one
> day.
>
>>> The idea is that clients SHOULD normalize, servers double-check inputs from
>>> non-trusted sources (like clients and other servers), then always store and
>>> forward the normalized version.
>>
>> That's fine. But it doesn't explain the choice of NFD (vs. NFC).
>
> One other point, the re-composition stuff in the C forms *is* objectively
> more difficult to implement,

Yes, but usually, you'd just use a library, and be done with it.

> and will *always* take more CPU.

Not if most of your data is already in NFC, and you can check that quickly.

I do not have actual statistics, but I don't know any major language or 
script where data would from the start be in NFD. On the other hand, 
there are examples such as Korean where essentially everything is in 
NFC, and NFD expands the number of characters by a factor of between 2 
and 3, affecting every single character. For other big languages such as 
Spanish, Portuguese, French, German, Italian, Polish, Japanese,... data 
is also essentially in NFC, although the characters that would be 
decomposed are less frequent than the 100% for Korean.

> If it's not required, it should be avoided.

That's similar to the argument about saving bytes on the wire. It's not 
compelling in a world with efficient libraries and faster and faster 
processors.

Also, please note that the code at 
http://www.w3.org/2003/06/xml1.1test/Overview.html isn't really the only 
way to optimize, and it's just a proof of concept, not really optimized 
based on actual benchmarks. My guess is that there are things that are 
"overoptimized" (i.e. too complicated without a corresponding speed 
gain) and some spots that could still be further optimized. In many 
cases, checking for all-ASCII first can shave off quite a bit of time. 
Also, doing a lookup of the string (which I guess has to happen sooner 
or later anyway) before checking for normalization may speed up things.

> And I haven't seen any compelling arguments
> as to why C should be preferred.  What I've seen so far:
>
> - That's the way we've always done it.  Not compelling to me if we're going
> to switch away from NFKC in any way.

That may not be compelling on the level of XMPP, but on the level of the 
IETF or the Internet, it's a different issue.

Also, under the assumption that actual characters where NFKC makes a 
difference are few and far between, NFKC and NFC are quite close. A 
change from NFKC to NFC may be much smoother than a change from NFKC to NFD.

> - Saves a few bytes on the wire.  Not compelling in a world with
> compression.  (see: http://xmpp.org/extensions/xep-0138.html)

Agreed.

> - More likely to render correctly.  Not with today's font renderers.

Depends on the exact characters in question. Can go either way.

> Are there any others I'm missing?

See above (libraries, frequency of data in NFC vs. NFD,...).


Regards,   Martin.

From msk@cloudmark.com  Mon Jul 25 09:11:23 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A39C11E80B4 for ; Mon, 25 Jul 2011 09:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.297
X-Spam-Level: 
X-Spam-Status: No, score=-103.297 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 B6jBodTrlMIJ for ; Mon, 25 Jul 2011 09:11:22 -0700 (PDT)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 9748521F8C3B for ; Mon, 25 Jul 2011 07:35:01 -0700 (PDT)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 25 Jul 2011 07:35:01 -0700
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" 
Date: Mon, 25 Jul 2011 07:34:59 -0700
Thread-Topic: Malformed messages draft
Thread-Index: AcxK2AgY7Dds4Gl+QLG9O09FqWrUZw==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F13512DF3F6EXCHC2corpclo_"
MIME-Version: 1.0
Subject: [apps-discuss] Malformed messages draft
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jul 2011 16:11:23 -0000

--_000_F5833273385BB34F99288B3648C4F06F13512DF3F6EXCHC2corpclo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

As I recall, these are the changes people suggested today for evolution of =
this document as it transitions into APPSAWG:


-          Remove RFC2119 language, (and thus, I think, make it Information=
al).

-          Apart from the admonition/reminder to make MSAs strict about mes=
sage format, make it clear that the main point that the advice in the draft=
 would be applied is at the MTA/MDA that is providing ingress to the ADMD.

This is apart from the exploration of doing something other than publishing=
 it as an RFC that would need to be updated from time to time.

As I'm preparing a new version to become the first version as a working gro=
up document, please let me know if I left out something important.

Thanks,

-MSK


--_000_F5833273385BB34F99288B3648C4F06F13512DF3F6EXCHC2corpclo_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi all,
 
As I r=
ecall, these are the changes people suggested today for evolution of this d=
ocument as it transitions into APPSAWG:
=
 
-    =
      Remove RFC2119 langu=
age, (and thus, I think, make it Informational).
-          Apart from the admonition/reminder to make MSAs stric=
t about message format, make it clear that the main point that the advice i=
n the draft would be applied is at the MTA/MDA that is providing ingress to=
 the ADMD.

This is apart from the ex=
ploration of doing something other than publishing it as an RFC that would =
need to be updated from time to time.
 
As I’m preparing a new versio=
n to become the first version as a working group document, please let me kn=
ow if I left out something important.
 
Thanks,
 
-MSK
 
=

--_000_F5833273385BB34F99288B3648C4F06F13512DF3F6EXCHC2corpclo_--

From mnot@mnot.net  Mon Jul 25 09:12:34 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9169E21F84EC for ; Mon, 25 Jul 2011 09:12:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.799
X-Spam-Level: 
X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=-3.200, BAYES_00=-2.599, 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 lvjPkiTGDdae for ; Mon, 25 Jul 2011 09:12:32 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAA721F8C9E for ; Mon, 25 Jul 2011 07:55:08 -0700 (PDT)
Received: from dhcp-1790.meeting.ietf.org (unknown [130.129.23.144]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 74D2D22E254 for ; Mon, 25 Jul 2011 10:55:07 -0400 (EDT)
From: Mark Nottingham 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 25 Jul 2011 10:55:06 -0400
References: <1311600852.1459.740.camel@chacal>
To: "apps-discuss@ietf.org Discuss" 
Message-Id: 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [apps-discuss] Fwd: Willful violation of RFC in HTML5
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jul 2011 16:12:34 -0000

FYI.

Begin forwarded message:

> From: Philippe Le Hegaret 
> Date: 25 July 2011 9:34:12 AM EDT
> To: Mark Nottingham 
> Cc: Thomas Roessler 
> Subject: Willful violation of RFC in HTML5
> organization: World Wide Web Consortium
>=20
> Hi Mark,
>=20
> here are links to the willful violation of RFCs in HTML5. if you =
prefer
> this email to be archived somewhere, let me know.
>=20
> [[
> This step is a willful violation of RFC 3986, which would require base
> URL processing here. This violation is motivated by a desire for
> compatibility with legacy content. [RFC3986]
> ]]
> =
http://www.w3.org/TR/html5/association-of-controls-and-forms.html#form-sub=
mission-algorithm
>=20
> [[
> This is a willful violation of RFC 2046, which requires all text/* =
types
> to only allow CRLF line breaks. This requirement, however, is =
outdated;
> the use of CR, LF, and CRLF line breaks is commonly supported and =
indeed
> sometimes CRLF is not supported by text editors. [RFC2046]
> ]]
> http://www.w3.org/TR/html5/offline.html#writing-cache-manifests
>=20
> [[
> This algorithm is a willful violation of the HTTP specification, which
> requires that the encoding be assumed to be ISO-8859-1 in the absence =
of
> a character encoding declaration to the contrary, and of RFC 2046, =
which
> requires that the encoding be assumed to be US-ASCII in the absence of =
a
> character encoding declaration to the contrary. This specification's
> third approach is motivated by a desire to be maximally compatible =
with
> legacy content. [HTTP] [RFC2046]
> ]]
> =
http://www.w3.org/TR/html5/parsing.html#determining-the-character-encoding=

>=20
> [[
> The requirement to default UTF-16 to LE rather than BE is a willful
> violation of RFC 2781, motivated by a desire for compatibility with
> legacy content. [RFC2781]
> ]]
> http://www.w3.org/TR/html5/parsing.html#character-encodings-0
>=20
> [[
> This requirement is a willful violation of RFC 5322, which defines a
> syntax for e-mail addresses that is simultaneously too strict (before
> the "@" character), too vague (after the "@" character), and too lax
> (allowing comments, white space characters, and quoted strings in
> manners unfamiliar to most users) to be of practical use here.
> ]]
> =
http://www.w3.org/TR/html5/states-of-the-type-attribute.html#e-mail-state
>=20
> [[
> The term "URL" in this specification is used in a manner distinct from
> the precise technical meaning it is given in RFC 3986. Readers =
familiar
> with that RFC will find it easier to read this specification if they
> pretend the term "URL" as used herein is really called something else
> altogether. This is a willful violation of RFC 3986. [RFC3986]
> ]]
> http://www.w3.org/TR/html5/urls.html#urls
>=20
> [[
> These parsing rules are a willful violation of RFC 3986 and RFC 3987
> (which do not define error handling), motivated by a desire to handle
> legacy content. [RFC3986] [RFC3987]
> ]]
> http://www.w3.org/TR/html5/urls.html#parsing-urls
>=20
> Philippe
>=20
>=20
>=20

--
Mark Nottingham   http://www.mnot.net/




From dave@cridland.net  Mon Jul 25 09:58:57 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A222521F874F for ; Mon, 25 Jul 2011 09:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.534
X-Spam-Level: 
X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065,  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 XLY8sv3PSBZf for ; Mon, 25 Jul 2011 09:58:57 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id BAA5921F87AF for ; Mon, 25 Jul 2011 09:58:53 -0700 (PDT)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 7BF1B1168087; Mon, 25 Jul 2011 17:58:31 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Wda96-Rl1zL; Mon, 25 Jul 2011 17:58:28 +0100 (BST)
Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 2E52F1168067; Mon, 25 Jul 2011 17:58:28 +0100 (BST)
References: <1311600852.1459.740.camel@chacal> 
In-Reply-To: 
MIME-Version: 1.0
Message-Id: <9031.1311613108.174237@puncture>
Date: Mon, 25 Jul 2011 17:58:28 +0100
From: Dave Cridland 
To: Mark Nottingham , General discussion of application-layer protocols 
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Subject: Re: [apps-discuss] Fwd: Willful violation of RFC in HTML5
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jul 2011 16:58:57 -0000

On Mon Jul 25 15:55:06 2011, Mark Nottingham wrote:
> > [[
> > This requirement is a willful violation of RFC 5322, which  
> defines a
> > syntax for e-mail addresses that is simultaneously too strict  
> (before
> > the "@" character), too vague (after the "@" character), and too  
> lax
> > (allowing comments, white space characters, and quoted strings in
> > manners unfamiliar to most users) to be of practical use here.
> > ]]
> >  
> http://www.w3.org/TR/html5/states-of-the-type-attribute.html#e-mail-state
> >

As an observation, addresses using whitescape and quoted strings are  
still commonplace in MIXER environments, and while I have no view on  
how common X.400 MIXER-mapped addresses might be in HTML5  
applications, it would appear that this would be difficult.

Also, the ABNF specified in the document not only fails to allow all  
email addresses, but also does allow invalid email addresses. A  
better choice would be to make the local-part be dot-atom-text.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From ynir@checkpoint.com  Sun Jul 24 12:28:33 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63EF921F8AEA; Sun, 24 Jul 2011 12:28:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.438
X-Spam-Level: 
X-Spam-Status: No, score=-10.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 1xn-2g7raZCS; Sun, 24 Jul 2011 12:28:32 -0700 (PDT)
Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB6E21F8AEC; Sun, 24 Jul 2011 12:28:30 -0700 (PDT)
X-CheckPoint: {4E2C7FF6-7-1B221DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p6OJSS1Q019872;  Sun, 24 Jul 2011 22:28:28 +0300
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 24 Jul 2011 22:28:28 +0300
From: Yoav Nir 
To: "http-auth@ietf.org" 
Date: Sun, 24 Jul 2011 22:28:26 +0300
Thread-Topic: [http-auth] HTTP-Auth BoF in Quebec City Postponed
Thread-Index: AcxKN91vdUxZLA9RQZ2riV+CEgkXsw==
Message-ID: <234F16BC-9875-474B-95B3-D61E8BE5A6E0@checkpoint.com>
References: <5FA6AD59-7570-4A85-B6D1-3DC8E42688F1@mnot.net>
In-Reply-To: <5FA6AD59-7570-4A85-B6D1-3DC8E42688F1@mnot.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail-4-368541076"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 25 Jul 2011 10:09:30 -0700
Cc: "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] [http-auth] HTTP-Auth BoF in Quebec City Postponed
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Jul 2011 19:28:33 -0000

--Apple-Mail-4-368541076
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi.

Would the people interested in http-auth like to hold an informal =
meeting sometime during the week?

If we don't want to have future BoFs canceled again, we should have a =
more clear definition of what problem we are trying to solve.

The first thing is to define what is bad in the current situation. I =
think we've seen two claims about this:
- Authentication to a web site means sending a password in the clear to =
some web site that may or may not be the correct site.
- A website that requires log-ins has to either store passwords or =
password verifiers. A compromise of that database is disastrous, because =
users re-use passwords for other sites.

After deciding which issue we would like to address, we can decide if =
the direction we would like to take is a more secure password protocol, =
or whether we would like to go to some solution that does away with =
passwords altogether.  I think there has been some meaningful discussion =
on the mailing list, but I don't see those discussions converging.

Do you think meeting face-to-face can help us move forward?

Yoav


=20=

--Apple-Mail-4-368541076
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPKjCCBN0w
ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR
Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w
NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx
FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx
ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz
dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx
B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8
om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG
TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl
yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j
BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59
MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr
BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j
b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu
Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw
DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8
NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s
APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK
N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU
TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD
AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG
A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU
IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO
LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw
MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD
VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9
VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD
jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS
TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy
fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B
AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU
ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw
EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0
LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG
AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy
dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN
BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu
PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i
kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq
szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L
SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBScwggQPoAMC
AQICEBW9tBlVg9WZf9zHij2h3zMwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E
TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT
ZWN1cmUgRW1haWwgQ0EwHhcNMTEwNzIxMDAwMDAwWhcNMTIwNzIwMjM1OTU5WjAkMSIwIAYJKoZI
hvcNAQkBFhN5bmlyQGNoZWNrcG9pbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAxha8w2xboHPbsj9HBz/1LdG2kwp++sXC5I0izECjJRravnWdnlDqTSRx7outPOk4zkfP/jtO
ZiFl35/W/ZgiVilKNrCAcIk4J4VYdbhUItos2Z1ydt1JcY6F24faWNNns2hV/cF6pNELNTxPYIsY
HrVy7Cq7/oywfHQimKbL4cVZvUF34P57gZKrxKBEkw3cUAzch7bQ8pTtewjvFW+cjpDqPaFSZyGJ
VfbBtAg3RBjlOolfp2VlTmLGW3gRxg9hi7XAxjJf417I9b1hz0NpTnhSr7n38zMEyUdhqr2Wb37b
yFNmhF+dWeBUX/RzgdIeqO/whtI1+gH8ZNuzpAV1UQIDAQABo4IB4zCCAd8wHwYDVR0jBBgwFoAU
ehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFPzBjRi9Qe40hv+WSad/Om18V8HmMA4GA1Ud
DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF
AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEF
BQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0
cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVF
bWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9k
b2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG
CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETeW5pckBjaGVj
a3BvaW50LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAkLgfz4ztXKON97ZHaqFhBfxO3QGPhx76iB1U
9LevFF/AsfS0ap2IWzGDocGJze17FZTjM41vCpRORCKCAdek+u+6RO95zx8VQaZybicBNCGBb4LP
1h8GvtmrT/+JpdtETJp9i1KIEwn8hn9Q4aMdkk8S2QkemBmhzGXdcQ5nCxyCQHk1hcRSDhC1qfME
DPGlKMxqDpMHrFmiI6vdCVBhufX7xECsGXOJDqMWMPg7YE0fubg50T8ehNHJ2Mvm8JpYIGwTIC3v
V9egV4ghYxHXm6u1zbXZUD+3pV9cNKbboB1FjuVqzKIiuNnzsZ3StcasZRYaxlwaHAU4uAuNyzbN
3jGCA6swggOnAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz
dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UE
AxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAVvbQZ
VYPVmX/cx4o9od8zMAkGBSsOAwIaBQCgggHXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTExMDcyNDE5MjgyNlowIwYJKoZIhvcNAQkEMRYEFLbubqHxZHSID5vnBEbk
hR+HZur8MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh
dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p
dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEBW9tBlVg9WZf9zHij2h3zMwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQswCQYDVQQG
EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD
VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh
dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAVvbQZVYPVmX/cx4o9od8zMA0GCSqGSIb3DQEBAQUA
BIIBAMMK0ogZ0eShZRqPk0Dbs6uQkW4sPVM28sH3cwBrU8uluIgBTciwiqtuPZrH5sJSOxDruYeG
0iH3M4/vmjx55+WER2WhZksledzCd8Ip35eYZ+YrRedH2j5RFYLSncyQE5abPTUOmwYJ980hNT75
00ailRTX0+zaC2nvKUk/HscDPvpXt2x8l5lOrqChlkdg4UooDvLijXV4W/BlT4/99ckO67m0GLSB
1TUwYJBJyZt1p36A9r7U0XcbkKxb0Qimtfjkiq+io0jIV2dnkEHbsJpdoY3fbbwwGdyFw6TwJk9D
emelA/Jpa6qA2XLYlnUIk9qJRbhaHY1KOoU/vuyYoEQAAAAAAAA=

--Apple-Mail-4-368541076--

From eburger@standardstrack.com  Mon Jul 25 17:12:10 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC3321F8A7A for ; Mon, 25 Jul 2011 17:12:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.984
X-Spam-Level: 
X-Spam-Status: No, score=-101.984 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, 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 P+LUxZGzs5b1 for ; Mon, 25 Jul 2011 17:12:09 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6690F21F8588 for ; Mon, 25 Jul 2011 17:12:06 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com;  h=Received:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=Mw16yxOFlvWEh9k9zJTOr1ZY6twERqsu2a0k6nR7QN3Nb42t8l8ICU8eOaOI2B24Emxrufe6ODHTM+raeVTDXIYMe1+DvH61WGXOap6neSo1/taUJpZt0+jcGymiDD3m;
Received: from modemcable058.242-23-96.mc.videotron.ca ([96.23.242.58] helo=[192.168.2.111]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QlVFj-00012j-VY for apps-discuss@ietf.org; Mon, 25 Jul 2011 17:12:04 -0700
From: Eric Burger 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-64-471956786; protocol="application/pkcs7-signature"; micalg=sha1
Date: Mon, 25 Jul 2011 20:12:02 -0400
In-Reply-To: 
To: "apps-discuss@ietf.org Discuss" 
References: <1311600852.1459.740.camel@chacal> 
Message-Id: <333B1766-D49F-444D-9627-6BA2782DCBDF@standardstrack.com>
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Subject: Re: [apps-discuss] Fwd: Willful violation of RFC in HTML5
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 00:12:10 -0000

--Apple-Mail-64-471956786
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Does a willful violation result in twice as much jail time?

On Jul 25, 2011, at 10:55 AM, Mark Nottingham wrote:

> FYI.
>=20
> Begin forwarded message:
>=20
>> From: Philippe Le Hegaret 
>> Date: 25 July 2011 9:34:12 AM EDT
>> To: Mark Nottingham 
>> Cc: Thomas Roessler 
>> Subject: Willful violation of RFC in HTML5
>> organization: World Wide Web Consortium
>>=20
>> Hi Mark,
>>=20
>> here are links to the willful violation of RFCs in HTML5. if you =
prefer
>> this email to be archived somewhere, let me know.
>>=20
>> [[
>> This step is a willful violation of RFC 3986, which would require =
base
>> URL processing here. This violation is motivated by a desire for
>> compatibility with legacy content. [RFC3986]
>> ]]
>> =
http://www.w3.org/TR/html5/association-of-controls-and-forms.html#form-sub=
mission-algorithm
>>=20
>> [[
>> This is a willful violation of RFC 2046, which requires all text/* =
types
>> to only allow CRLF line breaks. This requirement, however, is =
outdated;
>> the use of CR, LF, and CRLF line breaks is commonly supported and =
indeed
>> sometimes CRLF is not supported by text editors. [RFC2046]
>> ]]
>> http://www.w3.org/TR/html5/offline.html#writing-cache-manifests
>>=20
>> [[
>> This algorithm is a willful violation of the HTTP specification, =
which
>> requires that the encoding be assumed to be ISO-8859-1 in the absence =
of
>> a character encoding declaration to the contrary, and of RFC 2046, =
which
>> requires that the encoding be assumed to be US-ASCII in the absence =
of a
>> character encoding declaration to the contrary. This specification's
>> third approach is motivated by a desire to be maximally compatible =
with
>> legacy content. [HTTP] [RFC2046]
>> ]]
>> =
http://www.w3.org/TR/html5/parsing.html#determining-the-character-encoding=

>>=20
>> [[
>> The requirement to default UTF-16 to LE rather than BE is a willful
>> violation of RFC 2781, motivated by a desire for compatibility with
>> legacy content. [RFC2781]
>> ]]
>> http://www.w3.org/TR/html5/parsing.html#character-encodings-0
>>=20
>> [[
>> This requirement is a willful violation of RFC 5322, which defines a
>> syntax for e-mail addresses that is simultaneously too strict (before
>> the "@" character), too vague (after the "@" character), and too lax
>> (allowing comments, white space characters, and quoted strings in
>> manners unfamiliar to most users) to be of practical use here.
>> ]]
>> =
http://www.w3.org/TR/html5/states-of-the-type-attribute.html#e-mail-state
>>=20
>> [[
>> The term "URL" in this specification is used in a manner distinct =
from
>> the precise technical meaning it is given in RFC 3986. Readers =
familiar
>> with that RFC will find it easier to read this specification if they
>> pretend the term "URL" as used herein is really called something else
>> altogether. This is a willful violation of RFC 3986. [RFC3986]
>> ]]
>> http://www.w3.org/TR/html5/urls.html#urls
>>=20
>> [[
>> These parsing rules are a willful violation of RFC 3986 and RFC 3987
>> (which do not define error handling), motivated by a desire to handle
>> legacy content. [RFC3986] [RFC3987]
>> ]]
>> http://www.w3.org/TR/html5/urls.html#parsing-urls
>>=20
>> Philippe
>>=20
>>=20
>>=20
>=20
> --
> Mark Nottingham   http://www.mnot.net/
>=20
>=20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


--Apple-Mail-64-471956786
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w
ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR
Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w
NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx
FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx
ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz
dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx
B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8
om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG
TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl
yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j
BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59
MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr
BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j
b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu
Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw
DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8
NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s
APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK
N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU
TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD
AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ
BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT
VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU
Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw
MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF
UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl
OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v
ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA
c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq
5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT
7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ
MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ
Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4
wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA
S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF
oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB
hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0
cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny
bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls
LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0
aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw
Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6
Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv
bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3
2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx
kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/
RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl
awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7
AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD
aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu
dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp
b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B
CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA3MjYwMDEyMDJaMCMGCSqGSIb3DQEJ
BDEWBBTWyquHkDNCSIlrzNDc2cMM1HR9KjCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG
EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg
VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG
A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7
lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD
VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg
TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t
VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6
wbrGMA0GCSqGSIb3DQEBAQUABIIBAIRC1S9Hj9uk1hme+gI56AprsUnwqbSMsSNNhTxNPX6GH7xA
o6bWDq3dZdGMkda2OIllp3YxopYfgVUOeB0vhJJ3uoWf72E9QM5emBD/DzQv1WGgCunXq538oRlk
jsS0xjFgbvbnfavzoLxIE8a3s9I1NKfbKyNrIUSez2u/j6t/ByyatUgh8szOrxEj1WOrhmx3PIWV
GMbhXaElv7gb6KpOdYGLLuxviUncdD00zLIL0L5G4WdF8OVjf7iGtKPV7Q7Qviqq6O0yGYx0pjZZ
WhyCsVwGHUX4DAPtGma7UWYRNlrhlEcxFxUz7jx+VAGWRXtsmaoIIPK2/K3m8LpDHDsAAAAAAAA=

--Apple-Mail-64-471956786--

From luyan@zte.com.cn  Tue Jul 26 02:29:22 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED4021F8C19 for ; Tue, 26 Jul 2011 02:29:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.538
X-Spam-Level: 
X-Spam-Status: No, score=-101.538 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, 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 N-94VprP1lLF for ; Tue, 26 Jul 2011 02:29:21 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFC121F8C16 for ; Tue, 26 Jul 2011 02:29:20 -0700 (PDT)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 131321193944097; Tue, 26 Jul 2011 17:20:29 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 13796.3634574820; Tue, 26 Jul 2011 16:36:39 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p6Q8aVSF043542; Tue, 26 Jul 2011 16:36:31 +0800 (GMT-8) (envelope-from luyan@zte.com.cn)
In-Reply-To: <9031.1311329770.120161@puncture>
To: Dave Cridland 
MIME-Version: 1.0
X-KeepSent: 39FC2C3F:DFBBB156-482578D9:002E6203; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: luyan@zte.com.cn
Date: Tue, 26 Jul 2011 16:36:35 +0800
X-MIMETrack: S/MIME Sign by Notes Client on LuYan029354/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-26 16:39:02, Serialize by Notes Client on LuYan029354/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-26 16:39:02, Serialize complete at 2011-07-26 16:39:02, S/MIME Sign failed at 2011-07-26 16:39:02: ???????, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-26 16:36:33, Serialize complete at 2011-07-26 16:36:33
Content-Type: multipart/alternative; boundary="=_alternative 002F850C482578D9_="
X-MAIL: mse02.zte.com.cn p6Q8aVSF043542
Cc: "SHIH, JERRY \(ATTSI\)" , "jiaxw9@chinaunicom.cn" , "ding.xin@zte.com.cn" , General discussion of application-layer protocols 
Subject: Re: [apps-discuss] Extentions of IMAP4
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 09:29:22 -0000

This is a multipart message in MIME format.
--=_alternative 002F850C482578D9_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

PiBPbiBGcmkgSnVsIDIyIDA5OjEyOjM1IDIwMTEsIGx1eWFuQHp0ZS5jb20uY24gd3JvdGU6DQo+
ID4gW1lhbiBMVV0gVGhlIGludGVudGlvbiBvZiB0aGlzIGRyYWZ0IGlzIHRvIGFzc29jaWF0ZSBt
dWx0aXBsZSANCj4gPiBpZGVudGl0aWVzDQo+ID4gYmVsb25naW5nIHRvIG9uZSB1c2VyLiBUaHVz
LCBhZnRlciBsb2dnaW5nIGluLCB0aGUgdXNlciBtYXkgY2hvb3NlIA0KPiA+IG9uZSBvZg0KPiA+
IHRoZXNlIGFzc29jaWF0ZWQgaWRlbnRpdGllcywgdW5kZXIgZWFjaCBvZiB3aGljaCB0aGVyZSBj
YW4gYmUgYW4gDQo+ID4gSU5CT1gsIGENCj4gPiBTRU5UQk9YIGFuZCBvdGhlciBmb2xkZXJzLCBh
cyBzaG93biBpbiB0aGUgZm9sbG93aW5nIGZpZ3VyZS4NCj4gDQo+IE9LLiBJbiB0aGUgU0FTTCBt
b2RlbCwgYW4gYXV0aGVudGljYXRpb24gaWRlbnRpZmllciBjYW4gaGF2ZSBhY2Nlc3MgDQo+IHRv
IG1hbnkgYXV0aG9yaXphdGlvbiBpZGVudGlmaWVycyBhbHJlYWR5OyBzbyBubyBjaGFuZ2UgaXMg
bmVlZGVkIA0KPiBoZXJlLg0KPiANCg0KW1lhbiBMVV0gQXMgd2Uga25vdywgaW1wbGljaXQgcmVn
aXN0cmF0aW9uIGhhcyBhbHJlYWR5IGJlZW4gc3VwcG9ydGVkIGluIA0KM0dQUCBJTVMuIEhvd2V2
ZXIsc28gZmFyLCBJIGhhdmVu4oCZdCBmb3VuZCBhbnkgUkZDcyB3aGVyZSBhbiANCmF1dGhlbnRp
Y2F0aW9uIGlkZW50aWZpZXIgaXMgYWxsb3dlZCB0byBiZSBib3VuZCB3aXRoIG11bHRpcGxlIGlk
ZW50aWZpZXJzDQouIENvdWxkIHlvdSB0ZWxsIG1lIHRoZSBzcGVjaWZpYyBkb2N1bWVudHM/DQoN
Cj4gPiA+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbHUtaW1hcC1t
dWx0aS1hY2NvdW50Lw0KPiA+ID4NCj4gPiA+IFRoaXMgb25lIGFwcGVhcnMgdG8gYnVpbGQgb24g
dGhlIGFib3ZlLCBleGNlcHQgaXQsIHRvbywgY29uZnVzZXMNCj4gPiA+IGF1dGhlbnRpY2F0aW9u
IGFuZCBhdXRob3JpemF0aW9uLg0KPiA+ID4NCj4gPiA+IEknbSByZWFzb25hYmx5IGNvbnZpbmNl
ZCB0aGF0IHRoZSBmaXJzdCBkcmFmdCBpcyBlbnRpcmVseSANCj4gPiByZWR1bmRhbnQsDQo+ID4g
PiBhbmQgdGhpcyBvbmUncyB1dGlsaXR5IGlzIGxpbWl0ZWQuIEluIHBhcnRpY3VsYXIsIGl0J3Mg
bm90IGNsZWFyIA0KPiA+IHRvDQo+ID4gPiBtZSB3aHkgeW91J2Qgd2FudCB0aGlzIGluc3RlYWQg
b2YganVzdCB1c2luZyBtdWx0aXBsZSANCj4gPiBhdXRoZW50aWNhdGlvbg0KPiA+ID4gaWRlbnRp
ZmVycyBhbmQgbXVsdGlwbGUgY29ubmVjdGlvbnMsIGFuZCBubyByYXRpb25hbGUgaXMgZ2l2ZW4g
aW4gDQo+ID4gdGhlDQo+ID4gPiBkb2N1bWVudC4NCj4gPiA+DQo+ID4gPg0KPiA+IA0KPiA+IFtZ
YW4gTFVdIFRoZSByZWFzb24gd2h5IHdlIHN1Ym1pdHRlZCB0aGVzZSB0d28gZHJhZnRzIHNlcGFy
YXRlbHkgaXMgDQo+ID4gdGhhdA0KPiA+IHRoZSBmaXJzdCBvbmUgY2FuIHRha2UgZWZmZWN0IGV2
ZW4gd2l0aG91dCBpbXBsZW1lbnRpbmcgdGhlIHNlY29uZCANCj4gPiBvbmUuIEFzDQo+ID4geW91
IG1lbnRpb25lZCwgZm9yIHRoZSBzZWNvbmQgb25lLCB0aGUgaXNzdWUgY2FuIGJlIGltcGxlbWVu
dGVkIHdpdGgNCj4gPiBtdWx0aXBsZSBjb25uZWN0aW9ucy4gQnV0IGZyb20gdGhlIHBlcnNwZWN0
aXZlIG9mIHRoZSB1c2VyLCBpdCB3aWxsDQo+ID4gaW1wcm92ZSB0aGUgdXNlciBleHBlcmllbmNl
IGlmIHRoZSB1c2VyIGRvZXMgbm90IGhhdmUgdG8gbG9nIGluIGZvcg0KPiA+IHNldmVyYWwgdGlt
ZXMuDQo+ID4gDQo+ID4gTGV0IHVzIGZvY3VzIG9uIHRoZSBtdWx0aXBsZS1jb25uZWN0aW9uIHNv
bHV0aW9uLiBGaXJzdCBvZiBhbGwsIGl0IA0KPiA+IHdpbGwNCj4gPiBpbmNyZWFzZSB0aGUgYnVy
ZGVuIG9mIHRoZSBuZXR3b3JrLiBTZWNvbmRseSwgd2l0aG91dCB0aGUgZmlyc3QgDQo+ID4gZHJh
ZnQsIHRoZQ0KPiA+IHVzZXIgaGFzIHRvIGxvZyBpbiBmb3IgbXVsdGlwbGUgdGltZXMgdG8gZXN0
YWJsaXNoIGFsbCB0aGUgDQo+ID4gY29ubmVjdGlvbnMsDQo+ID4gd2hpY2ggSSBkb24ndCB0aGlu
ayBpcyBhIGdvb2QgaWRlYS4gV2l0aCB0aGUgZmlyc3QgZHJhZnQsIHdoeSBub3QgDQo+ID4ganVz
dA0KPiA+IGVzdGFibGlzaCBvbmUgY29ubmVjdGlvbiBmb3IgYWxsIGFzc29jaWF0ZWQgaWRlbnRp
dGllcz8NCj4gPiANCj4gPiANCj4gTW9zdGx5IGJlY2F1c2UgeW91J3JlIG5vdCAtIHlvdSdyZSBh
c3NvY2lhdGluZyBhdXRob3JpemF0aW9uIA0KPiBpZGVudGl0aWVzIHNlcXVlbnRpYWxseSwgcmF0
aGVyIHRoYW4gY29uY3VycmVudGx5Lg0KPiANCj4gWW91IGNvdWxkIGJ1aWxkIG9uIG5hbWVzcGFj
ZXMsIGluY2lkZW50YWxseSwgdG8gYWNoaWV2ZSBtdWNoIHRoZSBzYW1lIA0KPiBnb2FsLCBieSBz
aW1wbHkgZGVmaW5pbmcgYSBzdGFuZGFyZCBtZXRob2QgZm9yIGxvY2F0aW5nIG90aGVyIA0KPiBh
dXRob3JpemF0aW9uIGlkZW50aWZpZXJzJyBJTkJPWGVzLg0KPiANCj4gQnV0IGFsbG93aW5nIGEg
dXNlciB0byBzd2l0Y2ggYXV0aG9yaXphdGlvbiBpZGVudGlmaWVyIG1pZC1mbG93IHdpbGwgDQo+
IGFsbW9zdCBjZXJ0YWlubHkgaW50cm9kdWNlIHNvbWUgY29tcGxleCBlZGdlLWNhc2VzIHdpdGhp
biBzZWN1cml0eSAtIA0KPiBJJ3ZlIGEgc3Ryb25nIGZlZWxpbmcgdGhhdCB0aGlzIG9wZW5zIHVw
IHBvc3NpYmlsaXRpZXMgZm9yIFRPQ1RPVSANCj4gZXJyb3JzLg0KPg0KIA0KW1lhbiBMVV0gQWN0
dWFsbHksIHRoZSBpZGVhIGluIHRoZSBwcm9wb3NlZCBkcmFmdCBpcyBxdWl0ZSBzaW1pbGFyIHdp
dGggDQppbXBsaWNpdCByZWdpc3RyYXRpb24gaW4gM0dQUCwgd2hlcmUgaXQgaGFzIGFscmVhZHkg
YmVlbiBzdGFuZGFyZGl6ZWQuIFNvLCANCndlIHRoaW5rIGl0IGlzIGJldHRlciBmb3IgdGhlIElF
VEYgdG8gc3VwcG9ydCB0aGUgc2FtZSBtZWNoYW5pc20uDQoNCg0KPiA+IFtZYW4gTFVdIEkgYWdy
ZWUgd2l0aCB5b3UgdGhhdCBzZXJ2ZXItaW5pdGlhdGVkIGNvbW1hbmRzIGNhbiBiZQ0KPiA+IGNv
bXBsaWNhdGVkLiBUaGUgaW50ZW50aW9uIG9mIHRoaXMgZHJhZnQgaXMgdG8gdHJ5IHRvIGZpbmQg
YSB3YXkgDQo+ID4gZm9yIHRoZQ0KPiA+IHNlcnZlciB0byB0ZXJtaW5hdGUgc2Vzc2lvbiBhY3Rp
dmVseS4gSSBhbSB3b25kZXJpbmcgaWYgdGhlIEJZRSANCj4gPiByZXNwb25zZQ0KPiA+IGNhbiBi
ZSBzZW50IG91dCB3aXRob3V0IGNvcnJlc3BvbmRpbmcgdG8gYW55IHByZXZpb3VzIGNvbW1hbmQg
ZnJvbSBhDQo+ID4gY2xpZW50LiBDb3VsZCB5b3UgcHJvdmlkZSBtb3JlIGRldGFpbHM/DQo+IA0K
PiBUZWNobmljYWxseSwgeW91IGFyZSBhYmxlIHRvIHNlbmQgYWxtb3N0IGFueSByZXNwb25zZSBh
dCBhbnkgdGltZS4NCj4gDQo+IFVzZSBvZiBCWUUgaW4gdGhpcyB3YXkgaXMgZGlzY3Vzc2VkIGlu
IFJGQyAzNTAxIMKnNy4xLjUsIGFuZCBSRkMgMzUwMSANCj4gwqczLjQgZGlzY3Vzc2VzIHNlcnZl
cnMgdW5pbGF0ZXJhbGx5IGNsb3NpbmcgY29ubmVjdGlvbnMuDQo+IA0KW1lhbiBMVV0gSSBoYXZl
IHRvIGFkbWl0IEkgbmVnbGVjdGVkIHRoZXNlIGRlc2NyaXB0aW9ucy4gSSBiZWxpZXZlIEJZRSBj
YW4gDQptZWV0IG91ciByZXF1aXJlbWVudC4gVGhhbmtzIGZvciB0aGUgaW5mb3JtYXRpb24uDQoN
Cj4gRGF2ZS4NCj4gLS0gDQo+IERhdmUgQ3JpZGxhbmQgLSBtYWlsdG86ZGF2ZUBjcmlkbGFuZC5u
ZXQgLSB4bXBwOmR3ZEBkYXZlLmNyaWRsYW5kLm5ldA0KPiAgIC0gYWNhcDovL2FjYXAuZGF2ZS5j
cmlkbGFuZC5uZXQvYnlvd25lci91c2VyL2R3ZC9ib29rbWFya3MvDQo+ICAgLSBodHRwOi8vZGF2
ZS5jcmlkbGFuZC5uZXQvDQo+IEluZm90cm9wZSBQb2x5bWVyIC0gQUNBUCwgSU1BUCwgRVNNVFAs
IGFuZCBMZW1vbmFkZQ0KPiANCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTog
VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5
IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlz
IGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1h
aW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250
ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55
IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQg
c29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRo
ZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv
ciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3Mg
ZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2Vu
ZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0g
YnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo=
--=_alternative 002F850C482578D9_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IE9uIEZyaSBKdWwgMjIgMDk6MTI6MzUg
MjAxMSwgbHV5YW5AenRlLmNvbS5jbiB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgW1lhbiBMVV0gVGhl
IGludGVudGlvbiBvZiB0aGlzIGRyYWZ0IGlzIHRvIGFzc29jaWF0ZSBtdWx0aXBsZQ0KJm5ic3A7
PGJyPg0KJmd0OyAmZ3Q7IGlkZW50aXRpZXM8YnI+DQomZ3Q7ICZndDsgYmVsb25naW5nIHRvIG9u
ZSB1c2VyLiBUaHVzLCBhZnRlciBsb2dnaW5nIGluLCB0aGUgdXNlciBtYXkgY2hvb3NlDQombmJz
cDs8YnI+DQomZ3Q7ICZndDsgb25lIG9mPGJyPg0KJmd0OyAmZ3Q7IHRoZXNlIGFzc29jaWF0ZWQg
aWRlbnRpdGllcywgdW5kZXIgZWFjaCBvZiB3aGljaCB0aGVyZSBjYW4gYmUNCmFuICZuYnNwOzxi
cj4NCiZndDsgJmd0OyBJTkJPWCwgYTxicj4NCiZndDsgJmd0OyBTRU5UQk9YIGFuZCBvdGhlciBm
b2xkZXJzLCBhcyBzaG93biBpbiB0aGUgZm9sbG93aW5nIGZpZ3VyZS48YnI+DQomZ3Q7IDxicj4N
CiZndDsgT0suIEluIHRoZSBTQVNMIG1vZGVsLCBhbiBhdXRoZW50aWNhdGlvbiBpZGVudGlmaWVy
IGNhbiBoYXZlIGFjY2Vzcw0KJm5ic3A7PGJyPg0KJmd0OyB0byBtYW55IGF1dGhvcml6YXRpb24g
aWRlbnRpZmllcnMgYWxyZWFkeTsgc28gbm8gY2hhbmdlIGlzIG5lZWRlZA0KJm5ic3A7PGJyPg0K
Jmd0OyBoZXJlLjxicj4NCiZndDsgPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y
PltZYW4gTFVdIEFzIHdlIGtub3csIGltcGxpY2l0IHJlZ2lzdHJhdGlvbiBoYXMgYWxyZWFkeQ0K
YmVlbiBzdXBwb3J0ZWQgaW4gM0dQUCBJTVMuIEhvd2V2ZXIsc28gZmFyLCBJIGhhdmVuPC9mb250
Pjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPuKAmTwvZm9udD48Zm9udCBzaXpl
PTI+dA0KZm91bmQgYW55IFJGQ3Mgd2hlcmUgYW4gYXV0aGVudGljYXRpb24gaWRlbnRpZmllciBp
cyBhbGxvd2VkIHRvIGJlIGJvdW5kDQp3aXRoIG11bHRpcGxlIGlkZW50aWZpZXJzPC9mb250Pjxm
b250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPi48L2ZvbnQ+PGZvbnQgc2l6ZT0yPg0K
Q291bGQgeW91IHRlbGwgbWUgdGhlIHNwZWNpZmljIGRvY3VtZW50cz88L2ZvbnQ+DQo8YnI+PHR0
Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGh0dHBzOi8vZGF0YXRyYWNr
ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWx1LWltYXAtbXVsdGktYWNjb3VudC88YnI+DQomZ3Q7ICZn
dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoaXMgb25lIGFwcGVhcnMgdG8gYnVpbGQgb24g
dGhlIGFib3ZlLCBleGNlcHQgaXQsIHRvbywNCmNvbmZ1c2VzPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
YXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24uPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+
DQomZ3Q7ICZndDsgJmd0OyBJJ20gcmVhc29uYWJseSBjb252aW5jZWQgdGhhdCB0aGUgZmlyc3Qg
ZHJhZnQgaXMgZW50aXJlbHkNCiZuYnNwOzxicj4NCiZndDsgJmd0OyByZWR1bmRhbnQsPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgYW5kIHRoaXMgb25lJ3MgdXRpbGl0eSBpcyBsaW1pdGVkLiBJbiBwYXJ0
aWN1bGFyLCBpdCdzIG5vdA0KY2xlYXIgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7IHRvPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgbWUgd2h5IHlvdSdkIHdhbnQgdGhpcyBpbnN0ZWFkIG9mIGp1c3QgdXNpbmcg
bXVsdGlwbGUgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7IGF1dGhlbnRpY2F0aW9uPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgaWRlbnRpZmVycyBhbmQgbXVsdGlwbGUgY29ubmVjdGlvbnMsIGFuZCBubyByYXRp
b25hbGUgaXMNCmdpdmVuIGluICZuYnNwOzxicj4NCiZndDsgJmd0OyB0aGU8YnI+DQomZ3Q7ICZn
dDsgJmd0OyBkb2N1bWVudC48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7
PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBbWWFuIExVXSBUaGUgcmVhc29uIHdoeSB3
ZSBzdWJtaXR0ZWQgdGhlc2UgdHdvIGRyYWZ0cyBzZXBhcmF0ZWx5DQppcyAmbmJzcDs8YnI+DQom
Z3Q7ICZndDsgdGhhdDxicj4NCiZndDsgJmd0OyB0aGUgZmlyc3Qgb25lIGNhbiB0YWtlIGVmZmVj
dCBldmVuIHdpdGhvdXQgaW1wbGVtZW50aW5nIHRoZSBzZWNvbmQNCiZuYnNwOzxicj4NCiZndDsg
Jmd0OyBvbmUuIEFzPGJyPg0KJmd0OyAmZ3Q7IHlvdSBtZW50aW9uZWQsIGZvciB0aGUgc2Vjb25k
IG9uZSwgdGhlIGlzc3VlIGNhbiBiZSBpbXBsZW1lbnRlZA0Kd2l0aDxicj4NCiZndDsgJmd0OyBt
dWx0aXBsZSBjb25uZWN0aW9ucy4gQnV0IGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSB1c2Vy
LCBpdA0Kd2lsbDxicj4NCiZndDsgJmd0OyBpbXByb3ZlIHRoZSB1c2VyIGV4cGVyaWVuY2UgaWYg
dGhlIHVzZXIgZG9lcyBub3QgaGF2ZSB0byBsb2cNCmluIGZvcjxicj4NCiZndDsgJmd0OyBzZXZl
cmFsIHRpbWVzLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTGV0IHVzIGZvY3VzIG9u
IHRoZSBtdWx0aXBsZS1jb25uZWN0aW9uIHNvbHV0aW9uLiBGaXJzdCBvZiBhbGwsDQppdCAmbmJz
cDs8YnI+DQomZ3Q7ICZndDsgd2lsbDxicj4NCiZndDsgJmd0OyBpbmNyZWFzZSB0aGUgYnVyZGVu
IG9mIHRoZSBuZXR3b3JrLiBTZWNvbmRseSwgd2l0aG91dCB0aGUgZmlyc3QNCiZuYnNwOzxicj4N
CiZndDsgJmd0OyBkcmFmdCwgdGhlPGJyPg0KJmd0OyAmZ3Q7IHVzZXIgaGFzIHRvIGxvZyBpbiBm
b3IgbXVsdGlwbGUgdGltZXMgdG8gZXN0YWJsaXNoIGFsbCB0aGUgJm5ic3A7PGJyPg0KJmd0OyAm
Z3Q7IGNvbm5lY3Rpb25zLDxicj4NCiZndDsgJmd0OyB3aGljaCBJIGRvbid0IHRoaW5rIGlzIGEg
Z29vZCBpZGVhLiBXaXRoIHRoZSBmaXJzdCBkcmFmdCwgd2h5DQpub3QgJm5ic3A7PGJyPg0KJmd0
OyAmZ3Q7IGp1c3Q8YnI+DQomZ3Q7ICZndDsgZXN0YWJsaXNoIG9uZSBjb25uZWN0aW9uIGZvciBh
bGwgYXNzb2NpYXRlZCBpZGVudGl0aWVzPzxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg
PGJyPg0KJmd0OyBNb3N0bHkgYmVjYXVzZSB5b3UncmUgbm90IC0geW91J3JlIGFzc29jaWF0aW5n
IGF1dGhvcml6YXRpb24gJm5ic3A7PGJyPg0KJmd0OyBpZGVudGl0aWVzIHNlcXVlbnRpYWxseSwg
cmF0aGVyIHRoYW4gY29uY3VycmVudGx5Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBZb3UgY291bGQg
YnVpbGQgb24gbmFtZXNwYWNlcywgaW5jaWRlbnRhbGx5LCB0byBhY2hpZXZlIG11Y2ggdGhlIHNh
bWUNCiZuYnNwOzxicj4NCiZndDsgZ29hbCwgYnkgc2ltcGx5IGRlZmluaW5nIGEgc3RhbmRhcmQg
bWV0aG9kIGZvciBsb2NhdGluZyBvdGhlciAmbmJzcDs8YnI+DQomZ3Q7IGF1dGhvcml6YXRpb24g
aWRlbnRpZmllcnMnIElOQk9YZXMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJ1dCBhbGxvd2luZyBh
IHVzZXIgdG8gc3dpdGNoIGF1dGhvcml6YXRpb24gaWRlbnRpZmllciBtaWQtZmxvdyB3aWxsDQom
bmJzcDs8YnI+DQomZ3Q7IGFsbW9zdCBjZXJ0YWlubHkgaW50cm9kdWNlIHNvbWUgY29tcGxleCBl
ZGdlLWNhc2VzIHdpdGhpbiBzZWN1cml0eQ0KLSAmbmJzcDs8YnI+DQomZ3Q7IEkndmUgYSBzdHJv
bmcgZmVlbGluZyB0aGF0IHRoaXMgb3BlbnMgdXAgcG9zc2liaWxpdGllcyBmb3IgVE9DVE9VDQom
bmJzcDs8YnI+DQomZ3Q7IGVycm9ycy48YnI+DQomZ3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm
b250IHNpemU9Mj4mbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48Zm9udCBzaXplPTI+W1lhbiBMVV0g
QWN0dWFsbHksIHRoZSBpZGVhIGluIHRoZSBwcm9wb3NlZCBkcmFmdCBpcyBxdWl0ZQ0Kc2ltaWxh
ciB3aXRoIGltcGxpY2l0IHJlZ2lzdHJhdGlvbiBpbiAzR1BQLCB3aGVyZSBpdCBoYXMgYWxyZWFk
eSBiZWVuIHN0YW5kYXJkaXplZC48L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj4NClNvLCB3ZSB0aGlu
ayBpdCBpcyBiZXR0ZXIgZm9yIHRoZSBJRVRGIHRvIHN1cHBvcnQgdGhlIHNhbWUgbWVjaGFuaXNt
LjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyAmZ3Q7
IFtZYW4gTFVdIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCBzZXJ2ZXItaW5pdGlhdGVkIGNvbW1hbmRz
IGNhbg0KYmU8YnI+DQomZ3Q7ICZndDsgY29tcGxpY2F0ZWQuIFRoZSBpbnRlbnRpb24gb2YgdGhp
cyBkcmFmdCBpcyB0byB0cnkgdG8gZmluZCBhDQp3YXkgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7IGZv
ciB0aGU8YnI+DQomZ3Q7ICZndDsgc2VydmVyIHRvIHRlcm1pbmF0ZSBzZXNzaW9uIGFjdGl2ZWx5
LiBJIGFtIHdvbmRlcmluZyBpZiB0aGUgQllFDQombmJzcDs8YnI+DQomZ3Q7ICZndDsgcmVzcG9u
c2U8YnI+DQomZ3Q7ICZndDsgY2FuIGJlIHNlbnQgb3V0IHdpdGhvdXQgY29ycmVzcG9uZGluZyB0
byBhbnkgcHJldmlvdXMgY29tbWFuZA0KZnJvbSBhPGJyPg0KJmd0OyAmZ3Q7IGNsaWVudC4gQ291
bGQgeW91IHByb3ZpZGUgbW9yZSBkZXRhaWxzPzxicj4NCiZndDsgPGJyPg0KJmd0OyBUZWNobmlj
YWxseSwgeW91IGFyZSBhYmxlIHRvIHNlbmQgYWxtb3N0IGFueSByZXNwb25zZSBhdCBhbnkgdGlt
ZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgVXNlIG9mIEJZRSBpbiB0aGlzIHdheSBpcyBkaXNjdXNz
ZWQgaW4gUkZDIDM1MDEgwqc3LjEuNSwgYW5kIFJGQyAzNTAxDQombmJzcDs8YnI+DQomZ3Q7IMKn
My40IGRpc2N1c3NlcyBzZXJ2ZXJzIHVuaWxhdGVyYWxseSBjbG9zaW5nIGNvbm5lY3Rpb25zLjxi
cj4NCiZndDsgPGJyPg0KPC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0yPltZYW4gTFVdIEkgaGF2ZSB0
byBhZG1pdCBJIG5lZ2xlY3RlZCB0aGVzZSBkZXNjcmlwdGlvbnMuDQpJIGJlbGlldmUgQllFIGNh
biBtZWV0IG91ciByZXF1aXJlbWVudC4gVGhhbmtzIGZvciB0aGUgaW5mb3JtYXRpb24uPC9mb250
Pjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj4mZ3Q7IERhdmUuPGJyPg0KJmd0OyAtLSA8YnI+DQomZ3Q7IERhdmUgQ3JpZGxhbmQgLSBtYWls
dG86ZGF2ZUBjcmlkbGFuZC5uZXQgLSB4bXBwOmR3ZEBkYXZlLmNyaWRsYW5kLm5ldDxicj4NCiZn
dDsgJm5ic3A7IC0gYWNhcDovL2FjYXAuZGF2ZS5jcmlkbGFuZC5uZXQvYnlvd25lci91c2VyL2R3
ZC9ib29rbWFya3MvPGJyPg0KJmd0OyAmbmJzcDsgLSBodHRwOi8vZGF2ZS5jcmlkbGFuZC5uZXQv
PGJyPg0KJmd0OyBJbmZvdHJvcGUgUG9seW1lciAtIEFDQVAsIElNQVAsIEVTTVRQLCBhbmQgTGVt
b25hZGU8YnI+DQomZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3Jt
YXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlv
biZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNw
O3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNw
O29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJz
cDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDth
Ym92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtz
ZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8m
bmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5i
c3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5i
c3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJz
cDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5i
c3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJz
cDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0
aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZu
YnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNw
O3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNw
O3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJz
cDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZu
YnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZu
YnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNw
O2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3Rl
bS4NCjwvcHJlPg==
--=_alternative 002F850C482578D9_=--


From dave@cridland.net  Tue Jul 26 02:44:16 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2B921F8B6B for ; Tue, 26 Jul 2011 02:44:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.241
X-Spam-Level: 
X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, J_CHICKENPOX_72=0.6]
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 q-w2VCCgAzfP for ; Tue, 26 Jul 2011 02:44:16 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 812CC21F8B9F for ; Tue, 26 Jul 2011 02:44:15 -0700 (PDT)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 1E64B1168087; Tue, 26 Jul 2011 10:44:13 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CwQeccOQBUI; Tue, 26 Jul 2011 10:44:09 +0100 (BST)
Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id B299B1168067; Tue, 26 Jul 2011 10:44:08 +0100 (BST)
References: 
In-Reply-To: 
MIME-Version: 1.0
Message-Id: <9031.1311673448.731712@puncture>
Date: Tue, 26 Jul 2011 10:44:08 +0100
From: Dave Cridland 
To: "luyan@zte.com.cn" , General discussion of application-layer protocols ,  "ding.xin@zte.com.cn" , "jiaxw9@chinaunicom.cn" , "SHIH, JERRY \(ATTSI\)" 
Content-Type: text/plain; delsp="yes"; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8Bit
Subject: Re: [apps-discuss] Extentions of IMAP4
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 09:44:16 -0000

On Tue Jul 26 09:36:35 2011, luyan@zte.com.cn wrote:
> > On Fri Jul 22 09:12:35 2011, luyan@zte.com.cn wrote:
> > > [Yan LU] The intention of this draft is to associate multiple
> > > identities
> > > belonging to one user. Thus, after logging in, the user may  
> choose
> > > one of
> > > these associated identities, under each of which there can be an
> > > INBOX, a
> > > SENTBOX and other folders, as shown in the following figure.
> >
> > OK. In the SASL model, an authentication identifier can have  
> access
> > to many authorization identifiers already; so no change is needed
> > here.
> >
> 
> [Yan LU] As we know, implicit registration has already been  
> supported in
> 3GPP IMS. However,so far, I haven’t found any RFCs where an
> authentication identifier is allowed to be bound with multiple  
> identifiers
> . Could you tell me the specific documents?
> 
> 
All modern SASL mechanisms allow users to supply an optional  
authorization identifier.

> > Mostly because you're not - you're associating authorization
> > identities sequentially, rather than concurrently.
> >
> > You could build on namespaces, incidentally, to achieve much the  
> same
> > goal, by simply defining a standard method for locating other
> > authorization identifiers' INBOXes.
> >
> > But allowing a user to switch authorization identifier mid-flow  
> will
> > almost certainly introduce some complex edge-cases within  
> security -
> > I've a strong feeling that this opens up possibilities for TOCTOU
> > errors.
> >
> 
> [Yan LU] Actually, the idea in the proposed draft is quite similar  
> with
> implicit registration in 3GPP, where it has already been  
> standardized. So,
> we think it is better for the IETF to support the same mechanism.
> 
> 
Just because somebody else has decided to standardize it does not  
mean it's a good idea.

As I say, I think that allowing the authorization identifier bound to  
a session to change will introduce security issues. IMAP, and  
therefore IMAP servers, are built around the notion that the  
authorization identifier is bound at authentication time and  
thereafter invariant.

Breaking that assumption is trivial in theory, but in practise will  
have quite sever impact on server codebases, as well as impact to  
various extensions. For example, it's not at all clear what NOTIFY  
should do when faced with an authorization identifier change.

So at minimum, this draft would need to address every extant  
extensions for IMAP and ensure that it does not introduce security  
issues - but I don't think this is sufficient to eliminate the rather  
more worrying issue that authorization identifiers are considered an  
invariant of a session within the IMAP server codebases.

However, this isn't a problem, as what you can do is standardize the  
NAMESPACE usage and server layout such that it's simple for clients  
to discover the INBOX and personal mailboxes of other authorization  
identifiers.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From luyan@zte.com.cn  Tue Jul 26 02:58:38 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3930A21F8C00 for ; Tue, 26 Jul 2011 02:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -91.088
X-Spam-Level: 
X-Spam-Status: No, score=-91.088 tagged_above=-999 required=5 tests=[AWL=-10.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_34=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, URIBL_BLACK=20, 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 q8bmxd76Sw-M for ; Tue, 26 Jul 2011 02:58:37 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 75BD021F8BD3 for ; Tue, 26 Jul 2011 02:58:36 -0700 (PDT)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 131321193944097; Tue, 26 Jul 2011 17:50:23 +0800 (CST)
Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 93739.4016671279; Tue, 26 Jul 2011 17:58:26 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6Q9wMZO085237; Tue, 26 Jul 2011 17:58:22 +0800 (GMT-8) (envelope-from luyan@zte.com.cn)
In-Reply-To: 
To: John C Klensin 
MIME-Version: 1.0
X-KeepSent: B3FECD8C:206556B2-482578D9:0035D015; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: luyan@zte.com.cn
Date: Tue, 26 Jul 2011 17:58:26 +0800
X-MIMETrack: S/MIME Sign by Notes Client on LuYan029354/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-26 18:00:53, Serialize by Notes Client on LuYan029354/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-26 18:00:53, Serialize complete at 2011-07-26 18:00:53, S/MIME Sign failed at 2011-07-26 18:00:53: ???????, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-26 17:58:24, Serialize complete at 2011-07-26 17:58:24
Content-Type: multipart/alternative; boundary="=_alternative 00370359482578D9_="
X-MAIL: mse01.zte.com.cn p6Q9wMZO085237
Cc: "SHIH, JERRY \\\(ATTSI\\\)" , jiaxw9@chinaunicom.cn, ding.xin@zte.com.cn, General discussion of application-layer protocols 
Subject: Re: [apps-discuss] Extentions of IMAP4
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 09:58:38 -0000

This is a multipart message in MIME format.
--=_alternative 00370359482578D9_=
Content-Type: text/plain; charset="US-ASCII"

> 
> --On Friday, July 22, 2011 11:16 +0100 Dave Cridland
>  wrote:
> 
> > On Fri Jul 22 09:12:35 2011, luyan@zte.com.cn wrote:
> >> [Yan LU] The intention of this draft is to associate multiple
> >>  identities
> >> belonging to one user. Thus, after logging in, the user may
> >> choose   one of
> >> these associated identities, under each of which there can be
> >> an   INBOX, a
> >> SENTBOX and other folders, as shown in the following figure.
> > 
> > OK. In the SASL model, an authentication identifier can have
> > access to many authorization identifiers already; so no change
> > is needed here.
> 
> Let me add one much more general observation to Dave's specific
> ones:
> 
> IMO, IMAP is arguably already much too big and too complicated,
> at least partially due to the addition of features that provide
> different ways to do the same thing.  In principle, adding more
> optional features should not be a problem, but they make it very
> hard for a user to predict what will be available from different
> combinations of clients and servers.  That situation, in turn,
> makes easy movement among clients on multiple devices less
> likely and more difficult.
> 
> The LEMOMADE effort was supposed to improve on that situation.
> As far as I can call, it did not succeed in that particular
> goal; some would claim it made things worse.
> 
> To me, the best evidence for "much too big and too complicated"
> is the very small number of available, well-designed, IMAP
> clients that are fully-conformant to the protocol and up-to-date
> on the majority of current features and extensions.  Some years
> ago, an important contributor and developer of IMAP and other
> email protocols observed that "all IMAP clients suck, 
> sucks less than the others" (name omitted to avoid a distracting
> side discussion).   If one adds the criterion that they be
> tracking the efforts in the EAI WG that will require
> modifications for, e.g.,  non-ASCII addresses, the number goes
> down even further.
> 
> So, for whatever it is worth, I think the community should be
> looking only at additional IMAP changes and extensions for which
> there is a compelling need for a large number of users -- a need
> that is compelling enough that we can assume that a large
> fraction of client and server implementers will actually support
> the proposed feature.   I believe the EAI i18n changes meet that
> criterion.  These two proposals do not, not just for the reasons
> Dave mentions, but because we haven't seen much evidence a huge
> number of such users, because there are other ways around the
> issue in IMAP (as Dave notes), and because a slightly different
> organization of mailboxes and folders on the server (and a
> competent client) can accomplish almost exactly the same thing
> without any protocol changes at all.   I have some evidence for
> the latter: I've been doing things that way, with standard IMAP
> (and without a requirement for any of the very recent
> extensions), for 15 years or so now.
> 

[Yan LU]Well, as the members of OMA, we are focusing on services provided 
for the normal users. Market needs are driving us to propose these drafts. 
Furthermore, we have encountered issues since this feature has not been 
supported by IETF yet. I can provide some examples.
1)According to OMA CPM (Converged IP Messaging) specifications, a CPM 
client consists of a SIP client and a IMAP4 client, and a CPM user will 
use SIP client to realize communications of various forms, e.g. instant 
message, multimedia call or file transfer; a CPM user will also use IMAP4 
client to manage conversation history recorded during the communications. 
The CPM Group introduced 3GPP implicit registration into CPM,that is to 
say, when a user is registered, he/she only has to be registered once for 
his multiple identifiers. After registration, he can choose and use any of 
these identifiers freely. Unfortunately, the user has to log in for 
several times when he/she accesses his storage server. To make it even 
worse, although a user can switch his multiple identifiers when he/she 
communicates with others (using SIP ), he can only use one identifier to 
manage the stored conversation history (using IMAP4). We hope we can 
provide the same user experience in these two procedures.
2)Now we meet the same problem in OMA EVVM. 
3)This feature can be used in some kind of converged email services.It is 
quite possible that one user can have multiple internet email addresses. 
As far as I know, China Telecom has already released their enterprise 
standard in which a mobile user with a IMAP4 client can connect with a 
IMAP4 proxy to access multiple email accounts.

>     john
> 
> 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

--=_alternative 00370359482578D9_=
Content-Type: text/html; charset="US-ASCII"





> 

> --On Friday, July 22, 2011 11:16 +0100 Dave Cridland

> <dave@cridland.net> wrote:

> 

> > On Fri Jul 22 09:12:35 2011, luyan@zte.com.cn wrote:

> >> [Yan LU] The intention of this draft is to associate multiple

> >>  identities

> >> belonging to one user. Thus, after logging in, the user may

> >> choose   one of

> >> these associated identities, under each of which there can
be

> >> an   INBOX, a

> >> SENTBOX and other folders, as shown in the following figure.

> > 

> > OK. In the SASL model, an authentication identifier can have

> > access to many authorization identifiers already; so no change

> > is needed here.

> 

> Let me add one much more general observation to Dave's specific

> ones:

> 

> IMO, IMAP is arguably already much too big and too complicated,

> at least partially due to the addition of features that provide

> different ways to do the same thing.  In principle, adding more

> optional features should not be a problem, but they make it very

> hard for a user to predict what will be available from different

> combinations of clients and servers.  That situation, in turn,

> makes easy movement among clients on multiple devices less

> likely and more difficult.

> 

> The LEMOMADE effort was supposed to improve on that situation.

> As far as I can call, it did not succeed in that particular

> goal; some would claim it made things worse.

> 

> To me, the best evidence for "much too big and too complicated"

> is the very small number of available, well-designed, IMAP

> clients that are fully-conformant to the protocol and up-to-date

> on the majority of current features and extensions.  Some years

> ago, an important contributor and developer of IMAP and other

> email protocols observed that "all IMAP clients suck, <xxx>

> sucks less than the others" (name omitted to avoid a distracting

> side discussion).   If one adds the criterion that they be

> tracking the efforts in the EAI WG that will require

> modifications for, e.g.,  non-ASCII addresses, the number goes

> down even further.

> 

> So, for whatever it is worth, I think the community should be

> looking only at additional IMAP changes and extensions for which

> there is a compelling need for a large number of users -- a need

> that is compelling enough that we can assume that a large

> fraction of client and server implementers will actually support

> the proposed feature.   I believe the EAI i18n changes meet that

> criterion.  These two proposals do not, not just for the reasons

> Dave mentions, but because we haven't seen much evidence a huge

> number of such users, because there are other ways around the

> issue in IMAP (as Dave notes), and because a slightly different

> organization of mailboxes and folders on the server (and a

> competent client) can accomplish almost exactly the same thing

> without any protocol changes at all.   I have some evidence for

> the latter: I've been doing things that way, with standard IMAP

> (and without a requirement for any of the very recent

> extensions), for 15 years or so now.

> 



[Yan LU]Well, as the members
of OMA, we are focusing on services provided for the normal users. Market
needs are driving us to propose these drafts. Furthermore, we have encountered
issues since this feature has not been supported by IETF yet. I can provide
some examples.

1)According to OMA CPM (Converged IP Messaging) specifications,
a CPM client consists of a SIP client and a IMAP4 client, and a CPM user
will use SIP client to realize communications of various forms, e.g. instant
message, multimedia call or file transfer; a CPM user will also use IMAP4
client to manage conversation history recorded during the communications.
The CPM Group introduced 3GPP implicit registration into CPM,that is to
say, when a user is registered, he/she only has to be registered once for
his multiple identifiers. After registration, he can choose and use any
of these identifiers freely. Unfortunately, the user has to log in for
several times when he/she accesses his storage server. To make it even
worse, although a user can switch his multiple identifiers when he/she
communicates with others (using SIP ), he can only use one identifier to
manage the stored conversation history (using IMAP4). We hope we can provide
the same user experience in these two procedures.

2)Now we meet the same problem in OMA EVVM.


3)This feature can be used in some kind of converged email
services.It is quite possible that one user can have multiple internet
email addresses. As far as I know, China Telecom has already released their
enterprise standard in which a mobile user with a IMAP4 client can connect
with a IMAP4 proxy to access multiple email accounts.



>     john

> 

> 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.


--=_alternative 00370359482578D9_=--


From wmaton@ryouko.imsb.nrc.ca  Tue Jul 26 03:03:54 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5D421F8A70 for ; Tue, 26 Jul 2011 03:03:54 -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 fbRooi-w0RCx for ; Tue, 26 Jul 2011 03:03:53 -0700 (PDT)
Received: from ryouko.imsb.nrc.ca (ryouko.imsb.nrc.ca [IPv6:2604:8400:0:127::10]) by ietfa.amsl.com (Postfix) with ESMTP id 2B10421F8A69 for ; Tue, 26 Jul 2011 03:03:53 -0700 (PDT)
Received: from ryouko.imsb.nrc.ca (localhost [127.0.0.1]) by ryouko.imsb.nrc.ca (8.14.4/8.14.4) with ESMTP id p6QA3kV8009508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 06:03:52 -0400
Received: from localhost (wmaton@localhost) by ryouko.imsb.nrc.ca (8.14.4/8.14.4/Submit) with ESMTP id p6QA3jHX009504; Tue, 26 Jul 2011 06:03:45 -0400
Date: Tue, 26 Jul 2011 06:03:45 -0400 (EDT)
From: "William F. Maton Sotomayor" 
To: Eric Burger 
In-Reply-To: <333B1766-D49F-444D-9627-6BA2782DCBDF@standardstrack.com>
Message-ID: 
References: <1311600852.1459.740.camel@chacal>  <333B1766-D49F-444D-9627-6BA2782DCBDF@standardstrack.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] Fwd: Willful violation of RFC in HTML5
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: wmaton@ryouko.imsb.nrc.ca
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 10:03:54 -0000

Just many more cookies for everyone.

:)

On Mon, 25 Jul 2011, Eric Burger wrote:

> Does a willful violation result in twice as much jail time?
>
> On Jul 25, 2011, at 10:55 AM, Mark Nottingham wrote:
>
>> FYI.
>>
>> Begin forwarded message:
>>
>>> From: Philippe Le Hegaret 
>>> Date: 25 July 2011 9:34:12 AM EDT
>>> To: Mark Nottingham 
>>> Cc: Thomas Roessler 
>>> Subject: Willful violation of RFC in HTML5
>>> organization: World Wide Web Consortium
>>>
>>> Hi Mark,
>>>
>>> here are links to the willful violation of RFCs in HTML5. if you prefer
>>> this email to be archived somewhere, let me know.
>>>
>>> [[
>>> This step is a willful violation of RFC 3986, which would require base
>>> URL processing here. This violation is motivated by a desire for
>>> compatibility with legacy content. [RFC3986]
>>> ]]
>>> http://www.w3.org/TR/html5/association-of-controls-and-forms.html#form-submission-algorithm
>>>
>>> [[
>>> This is a willful violation of RFC 2046, which requires all text/* types
>>> to only allow CRLF line breaks. This requirement, however, is outdated;
>>> the use of CR, LF, and CRLF line breaks is commonly supported and indeed
>>> sometimes CRLF is not supported by text editors. [RFC2046]
>>> ]]
>>> http://www.w3.org/TR/html5/offline.html#writing-cache-manifests
>>>
>>> [[
>>> This algorithm is a willful violation of the HTTP specification, which
>>> requires that the encoding be assumed to be ISO-8859-1 in the absence of
>>> a character encoding declaration to the contrary, and of RFC 2046, which
>>> requires that the encoding be assumed to be US-ASCII in the absence of a
>>> character encoding declaration to the contrary. This specification's
>>> third approach is motivated by a desire to be maximally compatible with
>>> legacy content. [HTTP] [RFC2046]
>>> ]]
>>> http://www.w3.org/TR/html5/parsing.html#determining-the-character-encoding
>>>
>>> [[
>>> The requirement to default UTF-16 to LE rather than BE is a willful
>>> violation of RFC 2781, motivated by a desire for compatibility with
>>> legacy content. [RFC2781]
>>> ]]
>>> http://www.w3.org/TR/html5/parsing.html#character-encodings-0
>>>
>>> [[
>>> This requirement is a willful violation of RFC 5322, which defines a
>>> syntax for e-mail addresses that is simultaneously too strict (before
>>> the "@" character), too vague (after the "@" character), and too lax
>>> (allowing comments, white space characters, and quoted strings in
>>> manners unfamiliar to most users) to be of practical use here.
>>> ]]
>>> http://www.w3.org/TR/html5/states-of-the-type-attribute.html#e-mail-state
>>>
>>> [[
>>> The term "URL" in this specification is used in a manner distinct from
>>> the precise technical meaning it is given in RFC 3986. Readers familiar
>>> with that RFC will find it easier to read this specification if they
>>> pretend the term "URL" as used herein is really called something else
>>> altogether. This is a willful violation of RFC 3986. [RFC3986]
>>> ]]
>>> http://www.w3.org/TR/html5/urls.html#urls
>>>
>>> [[
>>> These parsing rules are a willful violation of RFC 3986 and RFC 3987
>>> (which do not define error handling), motivated by a desire to handle
>>> legacy content. [RFC3986] [RFC3987]
>>> ]]
>>> http://www.w3.org/TR/html5/urls.html#parsing-urls
>>>
>>> Philippe
>>>
>>>
>>>
>>
>> --
>> Mark Nottingham   http://www.mnot.net/
>>
>>
>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>


wfms

From stpeter@stpeter.im  Tue Jul 26 05:59:34 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8992121F8AEA for ; Tue, 26 Jul 2011 05:59:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.528
X-Spam-Level: 
X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, 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 zC26tCK4n0EB for ; Tue, 26 Jul 2011 05:59:33 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DA19621F8ABE for ; Tue, 26 Jul 2011 05:59:33 -0700 (PDT)
Received: from squire.local (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E0B40411C7 for ; Tue, 26 Jul 2011 07:00:31 -0600 (MDT)
Message-ID: <4E2EBA34.5090604@stpeter.im>
Date: Tue, 26 Jul 2011 08:59:32 -0400
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
References: <20110726125042.1180.12955.idtracker@ietfa.amsl.com>
In-Reply-To: <20110726125042.1180.12955.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.2
OpenPGP: url=https://stpeter.im/stpeter.asc
X-Forwarded-Message-Id: <20110726125042.1180.12955.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] Fwd: I-D Action: draft-saintandre-xdash-03.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 12:59:34 -0000

FYI. The authors have yet to incorporate any of the feedback from the
APPSAWG meeting yesterday.

-------- Original Message --------
Subject: I-D Action: draft-saintandre-xdash-03.txt
Date: Tue, 26 Jul 2011 05:50:42 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Deprecating Use of the "X-" Prefix in
Application Protocols
	Author(s)       : Peter Saint-Andre
                          D. Crocker
                          Mark Nottingham
	Filename        : draft-saintandre-xdash-03.txt
	Pages           : 12
	Date            : 2011-07-26

   Historically, there has often been a perceived distinction between
   "standard" and "non-standard" parameters (such as
media types and
   header fields), by prefixing the latter with the string "X-" or
   similar constructions (e.g., "x.").

   In practice, this convention causes more problems than it solves.
   Therefore, this document deprecates the "X-" convention for
most
   application protocol parameters.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-saintandre-xdash-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-saintandre-xdash-03.txt
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

From barryleiba.mailing.lists@gmail.com  Tue Jul 26 07:43:40 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE7321F8CD0 for ; Tue, 26 Jul 2011 07:43:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.069
X-Spam-Level: 
X-Spam-Status: No, score=-103.069 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 lAugCwh3h+dH for ; Tue, 26 Jul 2011 07:43:40 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACDD21F8CCF for ; Tue, 26 Jul 2011 07:43:40 -0700 (PDT)
Received: by yie30 with SMTP id 30so368618yie.31 for ; Tue, 26 Jul 2011 07:43:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1++ZmSVs+EW5xSX1Yz3EeJlgDyzxfc0dOZso30fMZBs=; b=Ue2ylJcTYmyuKyM/EPXL2cgfQujO7pAhifm0p6///RsrikHuRUGXm35eyUSQkf0xR8 fk9FZ/Et5wEH6oHFW8HC0j21Ny1IG5Lw6kCwW58WXyS2nSKhcUoZ32QFltwDGMURzX7w DknpqAKMvUWBARYMyJ7xIn0Cd8VHq+X10nKRs=
MIME-Version: 1.0
Received: by 10.146.160.32 with SMTP id i32mr5201135yae.18.1311691419626; Tue, 26 Jul 2011 07:43:39 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.99.7 with HTTP; Tue, 26 Jul 2011 07:43:39 -0700 (PDT)
In-Reply-To: <4E2EBA34.5090604@stpeter.im>
References: <20110726125042.1180.12955.idtracker@ietfa.amsl.com> <4E2EBA34.5090604@stpeter.im>
Date: Tue, 26 Jul 2011 10:43:39 -0400
X-Google-Sender-Auth: zQIiL3R_kgTc1ZnNQFOmPvqmqSo
Message-ID: 
From: Barry Leiba 
To: Peter Saint-Andre 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Fwd: I-D Action: draft-saintandre-xdash-03.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 14:43:40 -0000

> FYI. The authors have yet to incorporate any of the feedback from the
> APPSAWG meeting yesterday.

When the authors have incorporated said feedback, they are encouraged
to submit the result as "draft-ietf-appsawg-xdash-00", which has been
pre-approved.

Barry, appsawg chair

From internet-drafts@ietf.org  Tue Jul 26 09:11:53 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CB921F8B3D; Tue, 26 Jul 2011 09:11:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.578
X-Spam-Level: 
X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, 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 SC8+9qq7bh0l; Tue, 26 Jul 2011 09:11:52 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF68621F8B31; Tue, 26 Jul 2011 09:11:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.56
Message-ID: <20110726161152.12935.82112.idtracker@ietfa.amsl.com>
Date: Tue, 26 Jul 2011 09:11:52 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 16:11:53 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Applications Area Working Group Worki=
ng Group of the IETF.

	Title           : Best Current Practices for Handling of Malformed Messages
	Author(s)       : Murray S. Kucherawy
	Filename        : draft-ietf-appsawg-malformed-mail-00.txt
	Pages           : 9
	Date            : 2011-07-26

   The email ecosystem has long had a very permissive set of common
   processing rules in place, despite increasingly rigid standards
   governing its components, ostensibly to improve the user experience.
   The handling of these come at some cost, and various components are
   faced with decisions about whether or not to permit non-conforming
   messages to continue toward their destinations unaltered, adjust them
   to conform (possibly at the cost of losing some of the original
   message), or outright rejecting them.

   This memo includes a collection of the best current practices in a
   variety of such situations, to be used as implementation guidance.
   It must be emphasized, however, that the intent of this memo is not
   to standardize malformations or otherwise encourage their
   proliferation.  The messages that are the subject of this memo are
   manifestly malformed, and the code and culture that generates them
   needs to be fixed.  Nevertheless, many malformed messages from
   otherwise legitimate senders are in circulation and will be for some
   time and, unfortunately, commercial reality shows that we cannot
   simply reject or discard them.  Accordingly, this memo presents
   recommendations for dealing with them in ways that seem to do the
   least additional harm until the infrastructure is tightened up to
   match the standards.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-malformed-mail-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-malformed-mail-00.txt

From msk@cloudmark.com  Tue Jul 26 10:10:00 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7522E21F889D for ; Tue, 26 Jul 2011 10:10:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.787
X-Spam-Level: 
X-Spam-Status: No, score=-103.787 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 mX2MHkqMOgGk for ; Tue, 26 Jul 2011 10:10:00 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id C36E721F8890 for ; Tue, 26 Jul 2011 10:09:59 -0700 (PDT)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 26 Jul 2011 10:09:57 -0700
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" 
Date: Tue, 26 Jul 2011 10:09:56 -0700
Thread-Topic: I-D Action: draft-ietf-appsawg-malformed-mail-00.txt
Thread-Index: AcxLrsEms4qeGT3tTduyt4CXIGSBPQAB+/DA
Message-ID: 
References: <20110726161152.12935.82112.idtracker@ietfa.amsl.com>
In-Reply-To: <20110726161152.12935.82112.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 17:10:00 -0000

> -----Original Message-----
> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org=
] On Behalf Of internet-drafts@ietf.org
> Sent: Tuesday, July 26, 2011 9:12 AM
> To: i-d-announce@ietf.org
> Cc: apps-discuss@ietf.org
> Subject: I-D Action: draft-ietf-appsawg-malformed-mail-00.txt
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Applications Area Working
> Group Working Group of the IETF.
> [...]

No changes here other than the transition to being a WG document.

Barry and I talked to IANA about a possible path forward with them.  We'll =
report about that soon.

From julian.reschke@gmx.de  Tue Jul 26 10:52:44 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A0311E811E for ; Tue, 26 Jul 2011 10:52:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.71
X-Spam-Level: 
X-Spam-Status: No, score=-105.71 tagged_above=-999 required=5 tests=[AWL=-3.111, BAYES_00=-2.599, 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 O3Je2Y81TgAv for ; Tue, 26 Jul 2011 10:52:44 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id DEE5B21F8AB8 for ; Tue, 26 Jul 2011 10:52:42 -0700 (PDT)
Received: (qmail invoked by alias); 26 Jul 2011 17:52:41 -0000
Received: from unknown (EHLO [130.129.20.227]) [130.129.20.227] by mail.gmx.net (mp037) with SMTP; 26 Jul 2011 19:52:41 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX182sT9OnH42aYl0RXtfosPGY6sUa9gn5lN3lQjq6y hS4/8KYiNvkZI0
Message-ID: <4E2EFEE6.2020009@gmx.de>
Date: Tue, 26 Jul 2011 19:52:38 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Eric Burger 
References: <1311600852.1459.740.camel@chacal>  <333B1766-D49F-444D-9627-6BA2782DCBDF@standardstrack.com>
In-Reply-To: <333B1766-D49F-444D-9627-6BA2782DCBDF@standardstrack.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] Fwd: Willful violation of RFC in HTML5
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 17:52:44 -0000

On 2011-07-26 02:12, Eric Burger wrote:
> Does a willful violation result in twice as much jail time?

Sure it does.

From dhc@dcrocker.net  Tue Jul 26 11:03:03 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B714011E8122 for ; Tue, 26 Jul 2011 11:03:03 -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 MGXzalESkFrj for ; Tue, 26 Jul 2011 11:03:03 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 16DCE11E810E for ; Tue, 26 Jul 2011 11:03:03 -0700 (PDT)
Received: from [130.129.85.251] ([130.129.85.251]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p6QI2tW9011560 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 26 Jul 2011 11:03:02 -0700
Message-ID: <4E2F014E.3060605@dcrocker.net>
Date: Tue, 26 Jul 2011 14:02:54 -0400
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <1311600852.1459.740.camel@chacal>		<333B1766-D49F-444D-9627-6BA2782DCBDF@standardstrack.com> <4E2EFEE6.2020009@gmx.de>
In-Reply-To: <4E2EFEE6.2020009@gmx.de>
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, 26 Jul 2011 11:03:02 -0700 (PDT)
Subject: Re: [apps-discuss] Fwd: Willful violation of RFC in HTML5
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 18:03:03 -0000

On 7/26/2011 1:52 PM, Julian Reschke wrote:
> On 2011-07-26 02:12, Eric Burger wrote:
>> Does a willful violation result in twice as much jail time?
>
> Sure it does.


It merely makes it /seem/ longer, since you are be forced to constantly read 
distracting postings...

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From oritl@microsoft.com  Tue Jul 26 11:55:01 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B0721F8B7A for ; Tue, 26 Jul 2011 11:55:01 -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 ipoT6TMQpSQp for ; Tue, 26 Jul 2011 11:55:00 -0700 (PDT)
Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id B350521F8663 for ; Tue, 26 Jul 2011 11:55:00 -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, 26 Jul 2011 11:55:00 -0700
Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.97]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0323.002; Tue, 26 Jul 2011 11:55:00 -0700
From: Orit Levin 
To: "apps-discuss@ietf.org" 
Thread-Topic: Following up on the VDI discussion on Monday
Thread-Index: AcxLxYOfGn5lHQrPRCCB3BYbrwTMHQ==
Date: Tue, 26 Jul 2011 18:54:58 +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.32]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [apps-discuss] Following up on the VDI discussion on Monday
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2011 18:55:01 -0000

Microsoft RDP protocol is publicly available as [MS-RDPBCGR] Open Specifica=
tion document at http://download.microsoft.com/download/9/5/e/95ef66af-9026=
-4bb0-a41d-a4f81802d92c/%5BMS-RDPBCGR%5D.pdf . As I mentioned on Monday, bo=
th Windows and non-Windows, both commercial and reference implementations o=
f RDP clients and RDP Servers exist from Microsoft and multiple partners.

Thanks,
Orit.

From vesely@tana.it  Wed Jul 27 06:34:03 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F7B21F8B43 for ; Wed, 27 Jul 2011 06:34:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.465
X-Spam-Level: 
X-Spam-Status: No, score=-4.465 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_48=0.6, 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 ce1Q7OryoN2s for ; Wed, 27 Jul 2011 06:34:02 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5FA21F8AF0 for ; Wed, 27 Jul 2011 06:34:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1311773641; bh=SIwE0mKNifuzRc9JikLQ0pXCvz2wWy+HN7DqWsG+AdU=; l=1753; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=FGvXhCd89BWvaGiG8urjefqfZP1T0DKxoAu2CEF2gKorM/qpcPaCoumvHcRaAb2Lp PmMO93WzAfH4IyfMqy4u9oZ4I92h703lQCOX8K/CwYSzk6XbXV9pNaDj37wys9TMFs LZDPQY2TmRck+PZMcRElNmzGuHMxHMZs5/kMw2Cs=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 27 Jul 2011 15:34:01 +0200 id 00000000005DC033.000000004E3013C9.0000268D
Message-ID: <4E3013C8.7060203@tana.it>
Date: Wed, 27 Jul 2011 15:34:00 +0200
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: "Murray S. Kucherawy" 
References: <20110727052622.18893.75906.idtracker@ietfa.amsl.com>
In-Reply-To: <20110727052622.18893.75906.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: apps-discuss 
Subject: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 13:34:03 -0000

On 27/Jul/11 07:26, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 	Filename        : draft-kucherawy-rfc3462bis-01.txt

The new paragraph tries to explain a difficult concept:

 User agents and gateways need to be able to determine automatically
 that a message is a mail system report and need to be processed as
 such.  Placing the multipart/report as the outermost content provides
 a mechanism whereby an auto-processor can detect through parsing the
 message header that the message is a report.  Therefore, when used to
 generate a report, the multipart/report content-type MUST be the top-
 level MIME content type for any report message.  However, when
 forwarding or otherwise packaging a previously-generated report, this
 constraint is not in effect.

I'm puzzled about the "and gateways" part.  Is it correct?  IMHO, it
is just the MUA, or possibly the MDA, who may want to relate a DSN to
the message that triggered it.

In general, there is a relationship between the address that a report
is being delivered to and and its "active" status, expressed by having
multipart/report as the topmost MIME entity.  In order to process
reports, an agent must assume that the delivered-to address is the one
featured in smtp.mailfrom (for DSN) or in some FBLs/abuse-mailboxes
(for ARF).  To avoid fooling agents, reports should be wrapped inside
some other MIME entity when they are sent to other addresses (Ned said
"Indeed, I would actually like to require such
things NOT be sent at top level.")

Question: in case an ARF processor forwards an abuse (mis)report to
the original author, is it correct to keep multipart/report as the top
Content-Type?

jm2c

From msk@cloudmark.com  Wed Jul 27 06:47:31 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C1F11E807A for ; Wed, 27 Jul 2011 06:47:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.784
X-Spam-Level: 
X-Spam-Status: No, score=-103.784 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 86Lc6bUsU0sZ for ; Wed, 27 Jul 2011 06:47:30 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6944211E8086 for ; Wed, 27 Jul 2011 06:47:30 -0700 (PDT)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 27 Jul 2011 06:47:30 -0700
From: "Murray S. Kucherawy" 
To: Alessandro Vesely 
Date: Wed, 27 Jul 2011 06:47:27 -0700
Thread-Topic: Multipart/report, draft-kucherawy-rfc3462bis-01.txt
Thread-Index: AcxMYdn6bTHBhHEgQcCnqjJRiSEOkQAAGNvQ
Message-ID: 
References: <20110727052622.18893.75906.idtracker@ietfa.amsl.com> <4E3013C8.7060203@tana.it>
In-Reply-To: <4E3013C8.7060203@tana.it>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: apps-discuss 
Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 13:47:31 -0000

> -----Original Message-----
> From: Alessandro Vesely [mailto:vesely@tana.it]
> Sent: Wednesday, July 27, 2011 6:34 AM
> To: Murray S. Kucherawy
> Cc: apps-discuss
> Subject: Multipart/report, draft-kucherawy-rfc3462bis-01.txt
>=20
> The new paragraph tries to explain a difficult concept:
>=20
>  User agents and gateways need to be able to determine automatically
>  that a message is a mail system report and need to be processed as
>  such.  Placing the multipart/report as the outermost content provides
>  a mechanism whereby an auto-processor can detect through parsing the
>  message header that the message is a report.  Therefore, when used to
>  generate a report, the multipart/report content-type MUST be the top-
>  level MIME content type for any report message.  However, when
>  forwarding or otherwise packaging a previously-generated report, this
>  constraint is not in effect.
>=20
> I'm puzzled about the "and gateways" part.  Is it correct?  IMHO, it
> is just the MUA, or possibly the MDA, who may want to relate a DSN to
> the message that triggered it.

"User agents and gateways" is copied from the existing RFC.  It's not part =
of what I'm seeking to change here.  I can change it if there's consensus t=
o do so, of course.

> Question: in case an ARF processor forwards an abuse (mis)report to
> the original author, is it correct to keep multipart/report as the top
> Content-Type?

That's exactly what this change is attempting to address.  The old text dis=
allows forwarding of multipart/report altogether, other than re-injecting i=
t into the mail stream with exactly the same MIME structure it had original=
ly; that is, it can't be wrapped inside multipart/anything or message/rfc82=
2.  It's that restriction that's being removed.

However, this morning I realized that, in the procedural shuffle in the las=
t few days, this change has lost sight of the original goal which is to ena=
ble the origination of multipart/reports without the restriction altogether=
.  The MARF working group is seeking to converge OMA's SpamRep specificatio=
n (which has its own media type that can contain many reports) with its own=
, the latter of which uses multipart/report.  Therefore, this change is a s=
tep in the right direction but it doesn't get all the way there.

It's my understanding that Keith would like the text that's in this draft o=
r something close to it, Ned would be satisfied with either outcome, but MA=
RF needs to go further.  So that's where we are now.

I guess then I'd like Keith to comment on this idea: What about changing th=
e MUST in that paragraph to a SHOULD?

-MSK


From stephen.farrell@cs.tcd.ie  Wed Jul 27 08:49:58 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484A021F857E for ; Wed, 27 Jul 2011 08:49:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 kFRIHe+qwLmt for ; Wed, 27 Jul 2011 08:49:57 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD8121F8591 for ; Wed, 27 Jul 2011 08:49:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 05C15171CD3 for ; Wed, 27 Jul 2011 16:49:49 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1311781788; bh=pKAQg+m6/CFE7KeBGEzG/+bv F7nyKNkYSnxrjS0zMQU=; b=dGIlNLoCcHpB6R/RCCU1vw3i0KZ+0Uv3GD6faPDB epIvPD5Ojx3qtnTdOxDbji+3ySAu+NRYB0so+bOVNC3lwAkHFiIKPO3ZQ1G2Di6H KS1sdPDJ73/Kqk4lxayCN+KK5Lswacn5FkEh/K9jqWeVLcO8R1bRjsasYT+bZCrb g+MYf6a1korRmuBdDmx9lKfE4HKD0LgmmLUN/fbEbOuzbkZT3ebDNDvLq91AQAoF 0VsMKTH+mpTXEfj5Cs3Dt3V2vthDO+xCvmgXgX5I1YrrDPf/zxehLGTEECXIqaMz izBggXvq0f9DFUMZ7CoAvtn2xCjruFE2xwFWsJT6BONjsw==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id cwtphzdm-Dsj for ; Wed, 27 Jul 2011 16:49:48 +0100 (IST)
Received: from [130.129.39.94] (dhcp-275e.meeting.ietf.org [130.129.39.94]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6A5C3171C1D for ; Wed, 27 Jul 2011 16:49:48 +0100 (IST)
Message-ID: <4E303386.70001@cs.tcd.ie>
Date: Wed, 27 Jul 2011 16:49:26 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: Apps Discuss 
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] proposing draft-farrell-ni as an appsarea wg item
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 15:49:58 -0000

Hi,

Yesterday, I presented a draft [1] on a URI scheme for naming
stuff to the decade WG. There's interest in that there but
the idea behind this is really broader than just decade so
if there's interest here, doing this work in the appsarea WG
would I think be much better.

The scheme is basically like HTTP URIs with one additional
thing, which is that it specifies a way to include a hash
function output in the name (and the related input, in case
you want to verify something later) which seems to me to be
a generally useful thing that various protocols could use
in various ways. Hence the idea of bringing it here.

So, comments appreciated,

Thanks,
Stephen.

[1] http://tools.ietf.org/html/draft-farrell-ni


From tianlinyi@huawei.com  Wed Jul 27 12:25:39 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A4C21F86EA for ; Wed, 27 Jul 2011 12:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.704
X-Spam-Level: 
X-Spam-Status: No, score=-3.704 tagged_above=-999 required=5 tests=[AWL=-1.224, BAYES_00=-2.599, DATE_IN_FUTURE_03_06=0.274, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396, 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 GAoVHRdu7Brl for ; Wed, 27 Jul 2011 12:25:39 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id BE1C921F86DE for ; Wed, 27 Jul 2011 12:25:38 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP000IXUBAOSU@szxga05-in.huawei.com> for apps-discuss@ietf.org; Thu, 28 Jul 2011 03:25:36 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP000FBDBANBU@szxga05-in.huawei.com> for apps-discuss@ietf.org; Thu, 28 Jul 2011 03:25:36 +0800 (CST)
Received: from [130.129.86.170] (dhcp-56aa.meeting.ietf.org [130.129.86.170]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPA id <0LP00088WBAKXV@szxml12-in.huawei.com>; Thu, 28 Jul 2011 03:25:35 +0800 (CST)
Date: Wed, 27 Jul 2011 21:25:30 -0400
From: Linyi Tian 01 
In-reply-to: <4E303386.70001@cs.tcd.ie>
To: Stephen Farrell , Apps Discuss 
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=GB2312
Content-transfer-encoding: quoted-printable
Thread-topic: [apps-discuss] proposing draft-farrell-ni as an appsarea wg item
User-Agent: Microsoft-MacOutlook/14.0.0.100825
Subject: Re: [apps-discuss] proposing draft-farrell-ni as an appsarea wg item
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 19:25:39 -0000

On 11-7-27 =C9=CF=CE=E711:49, "Stephen Farrell"  wrote:

>
>Hi,
>
>Yesterday, I presented a draft [1] on a URI scheme for naming
>stuff to the decade WG. There's interest in that there but
>the idea behind this is really broader than just decade so
>if there's interest here, doing this work in the appsarea WG
>would I think be much better.
>
>The scheme is basically like HTTP URIs with one additional
>thing, which is that it specifies a way to include a hash
>function output in the name (and the related input, in case
>you want to verify something later) which seems to me to be
>a generally useful thing that various protocols could use
>in various ways. Hence the idea of bringing it here.

I am wondering how this would be used. Will it be used together with HTTP
URIs? Is there any real life use case how I can use this URI.

>
>So, comments appreciated,
>
>Thanks,
>Stephen.
>
>[1] http://tools.ietf.org/html/draft-farrell-ni
>
>_______________________________________________
>apps-discuss mailing list
>apps-discuss@ietf.org
>https://www.ietf.org/mailman/listinfo/apps-discuss



From ned.freed@mrochek.com  Wed Jul 27 16:20:46 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E6511E8084 for ; Wed, 27 Jul 2011 16:20:46 -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 2t-rYZ8R4aZY for ; Wed, 27 Jul 2011 16:20:45 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 86B8D11E80A2 for ; Wed, 27 Jul 2011 16:20:45 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O45CD55FPS00XGWU@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 27 Jul 2011 16:19:54 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O45BBSQ2A800RCTX@mauve.mrochek.com>; Wed, 27 Jul 2011 16:19:48 -0700 (PDT)
Message-id: <01O45CD1RC5O00RCTX@mauve.mrochek.com>
Date: Wed, 27 Jul 2011 15:55:55 -0700 (PDT)
From: ned+apps-discuss@mrochek.com
In-reply-to: "Your message dated Wed, 27 Jul 2011 06:47:27 -0700" 
Sender: Ned Freed 
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <20110727052622.18893.75906.idtracker@ietfa.amsl.com> <4E3013C8.7060203@tana.it> 
To: "Murray S. Kucherawy" 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1311808754; bh=WFP5Hi1qKXUohR4J22mnlC5qcrEgaiczC8BJC9rTNw8=; h=Cc:Message-id:Date:From:Subject:In-reply-to:Sender:MIME-version: Content-type:References:To; b=cZteabMCkZ2/8Cmh3JetwRJFo6rBLy9YbWBSRKbPZx76jiI+kLdOr3Oa+kqLqUti0 dVjdj/RLbIChj9lIcyjXgcNRhj0FgwwMbZe3y0Usps/Qe4m2aDBSu8dInkdkWZFRGD u3fZ7RdhKpgk+m7qaxufi7IMI7rxprXE9wsIHwAc=
Cc: apps-discuss , Alessandro Vesely 
Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2011 23:20:46 -0000

> > -----Original Message-----
> > From: Alessandro Vesely [mailto:vesely@tana.it]
> > Sent: Wednesday, July 27, 2011 6:34 AM
> > To: Murray S. Kucherawy
> > Cc: apps-discuss
> > Subject: Multipart/report, draft-kucherawy-rfc3462bis-01.txt
> >
> > The new paragraph tries to explain a difficult concept:
> >
> >  User agents and gateways need to be able to determine automatically
> >  that a message is a mail system report and need to be processed as
> >  such.  Placing the multipart/report as the outermost content provides
> >  a mechanism whereby an auto-processor can detect through parsing the
> >  message header that the message is a report.  Therefore, when used to
> >  generate a report, the multipart/report content-type MUST be the top-
> >  level MIME content type for any report message.  However, when
> >  forwarding or otherwise packaging a previously-generated report, this
> >  constraint is not in effect.

This is not acceptable as far as I'm concerned. For one thing, it uses
various new terms like "mail system report" and "report message" that
AFAIK aren't well defined. And even if I assume definitions for these terms
I think the author probably meant, the result still isn't what I'd like to see.

Multipart/report is, or should be, a very general construct used to report
pretty much anything relating to messages or perhaps even more general MIME
content.

The restriction that generated DSNs and MDNs (two specific types of report)
need to be placed at the top-level is what's needed here. Nothing more. We
should not attempt to guess at possible future uses of the report framework.
This sort of anticipatory restriction is what gets us into trouble with great
regularity, and we need to stop doing it.

In fact the best way to handle this would be to put the restriction into the
DSN and MDN specifications that build on the multipart/report framework, and
say something like, "Uses of the multipart/report container format MAY restrict
the contexts in which a particular report type can appear."

> > I'm puzzled about the "and gateways" part.  Is it correct?

Yes. A proper gateway to X.400, for example, will turn a top-level DSN into an
X.400 delivery report and vice versa. (It would nice if the same applied to
MDNs and X.400 read receipts, but the semantics are so dissimilar that
conversion is infeasible.)

> > IMHO, it
> > is just the MUA, or possibly the MDA, who may want to relate a DSN to
> > the message that triggered it.

Sure, but not all user agents operate in the Internet email world. This way
X.400 user agents (and like it or not, these still exist) get the report in a
format they can actually process.

> "User agents and gateways" is copied from the existing RFC.  It's not part of
> what I'm seeking to change here.  I can change it if there's consensus to do
> so, of course.

> > Question: in case an ARF processor forwards an abuse (mis)report to
> > the original author, is it correct to keep multipart/report as the top
> > Content-Type?

> That's exactly what this change is attempting to address.  The old text
> disallows forwarding of multipart/report altogether, other than re-injecting it
> into the mail stream with exactly the same MIME structure it had originally;
> that is, it can't be wrapped inside multipart/anything or message/rfc822.  It's
> that restriction that's being removed.

It's a little more subtle than that. See above.

> However, this morning I realized that, in the procedural shuffle in the last
> few days, this change has lost sight of the original goal which is to enable
> the origination of multipart/reports without the restriction altogether.  The
> MARF working group is seeking to converge OMA's SpamRep specification (which
> has its own media type that can contain many reports) with its own, the latter
> of which uses multipart/report.  Therefore, this change is a step in the right
> direction but it doesn't get all the way there.

I'm not seeing a problem with MARF and the change I'm proposing.

> It's my understanding that Keith would like the text that's in this draft or
> something close to it, Ned would be satisfied with either outcome, but MARF
> needs to go further.  So that's where we are now.

> I guess then I'd like Keith to comment on this idea: What about changing the
> MUST in that paragraph to a SHOULD?

I'm entirely against that. It would relax the conditions on generating
DSNs and MDNs and I do not think we should be doing that.

				Ned

From tony@att.com  Wed Jul 27 21:27:37 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABD421F8BA6 for ; Wed, 27 Jul 2011 21:27:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.905
X-Spam-Level: 
X-Spam-Status: No, score=-105.905 tagged_above=-999 required=5 tests=[AWL=0.694, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 dqwsktSaMSjy for ; Wed, 27 Jul 2011 21:27:37 -0700 (PDT)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id EE17521F8BA4 for ; Wed, 27 Jul 2011 21:27:36 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: tony@att.com
X-Msg-Ref: server-8.tower-120.messagelabs.com!1311827255!11272614!1
X-StarScan-Version: 6.2.17; banners=-,-,-
X-Originating-IP: [144.160.20.145]
Received: (qmail 3108 invoked from network); 28 Jul 2011 04:27:36 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-8.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Jul 2011 04:27:36 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p6S4S1sU011793 for ; Thu, 28 Jul 2011 00:28:01 -0400
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p6S4RrLP011762 for ; Thu, 28 Jul 2011 00:27:54 -0400
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p6S4RSE1006081 for ; Thu, 28 Jul 2011 00:27:28 -0400
Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p6S4RNZ7006033 for ; Thu, 28 Jul 2011 00:27:24 -0400
Received: from [135.70.82.230] (vpn-135-70-82-230.vpn.swst.att.com[135.70.82.230]) by maillennium.att.com (mailgw1) with ESMTP id <20110728042723gw100e4leme> (Authid: tony); Thu, 28 Jul 2011 04:27:23 +0000
X-Originating-IP: [135.70.82.230]
Message-ID: <4E30E528.2030407@att.com>
Date: Thu, 28 Jul 2011 00:27:20 -0400
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Alessandro Vesely 
References: <20110727052622.18893.75906.idtracker@ietfa.amsl.com> <4E3013C8.7060203@tana.it>
In-Reply-To: <4E3013C8.7060203@tana.it>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss 
Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 04:27:37 -0000

On 7/27/2011 9:34 AM, Alessandro Vesely wrote:
> The new paragraph tries to explain a difficult concept:
>
>   User agents and gateways need to be able to determine ...
>
> I'm puzzled about the "and gateways" part.  Is it correct?  IMHO, it
> is just the MUA, or possibly the MDA, who may want to relate a DSN to
> the message that triggered it.

Gateways are odd beasts: they often act like both MUAs and MDAs.

     Tony Hansen
     tony@att.com

From msk@cloudmark.com  Wed Jul 27 21:32:59 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC80B5E8008 for ; Wed, 27 Jul 2011 21:32:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.778
X-Spam-Level: 
X-Spam-Status: No, score=-103.778 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 xv0bBeYvNeeC for ; Wed, 27 Jul 2011 21:32:58 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id ADD125E8002 for ; Wed, 27 Jul 2011 21:32:58 -0700 (PDT)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 27 Jul 2011 21:32:58 -0700
From: "Murray S. Kucherawy" 
To: "ned+apps-discuss@mrochek.com" 
Date: Wed, 27 Jul 2011 21:32:56 -0700
Thread-Topic: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
Thread-Index: AcxMs9DOD8oBrs2iQq+incMwBHl5rgAKuY/w
Message-ID: 
References: <20110727052622.18893.75906.idtracker@ietfa.amsl.com> <4E3013C8.7060203@tana.it>  <01O45CD1RC5O00RCTX@mauve.mrochek.com>
In-Reply-To: <01O45CD1RC5O00RCTX@mauve.mrochek.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: apps-discuss 
Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 04:32:59 -0000

> -----Original Message-----
> From: Ned Freed [mailto:ned.freed@mrochek.com] On Behalf Of ned+apps- dis=
cuss@mrochek.com
> Sent: Wednesday, July 27, 2011 3:56 PM
> To: Murray S. Kucherawy
> Cc: Alessandro Vesely; apps-discuss
> Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-=
01.txt
>=20
> This is not acceptable as far as I'm concerned. For one thing, it uses
> various new terms like "mail system report" and "report message" that
> AFAIK aren't well defined. And even if I assume definitions for these ter=
ms
> I think the author probably meant, the result still isn't what I'd like
> to see.

You might be right that they're not well defined, but they're not new.  The=
y're copied directly from RFC3462.

> In fact the best way to handle this would be to put the restriction into =
the
> DSN and MDN specifications that build on the multipart/report framework, =
and
> say something like, "Uses of the multipart/report container format MAY re=
strict
> the contexts in which a particular report type can appear."

I'm happy to take those on as well as individual submissions in support of =
the MARF work, assuming such work is limited to these small changes doesn't=
 become a kitchen sink for a massive collection of updates to these three R=
FCs.  If it becomes a bigger update project, I think we're talking about so=
mething YAM-like, or at least something that should land in APPSAWG.

And to Barry and/or the ADs: The RFCs we're talking about are all Draft Sta=
ndard.  Could these changes be considered clarifications and not require re=
cycles at Proposed Standard, or do we doom them to that by making these cha=
nges?

-MSK

From evnikita2@gmail.com  Wed Jul 27 22:13:39 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F84421F8C0E for ; Wed, 27 Jul 2011 22:13:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.284
X-Spam-Level: 
X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=-1.135, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1]
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 Pbgh+0rvwhip for ; Wed, 27 Jul 2011 22:13:38 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 88C7121F8C0C for ; Wed, 27 Jul 2011 22:13:38 -0700 (PDT)
Received: by fxe6 with SMTP id 6so976644fxe.31 for ; Wed, 27 Jul 2011 22:13:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=PoBwSVIq1wUWADEGc/G0cS0K1o8Bbm4f3jd8mbtNxGs=; b=l7W6BsCoRLdayLV4jIpj+7+aAKwLCJRMEN4OV9bC8FwweVmzHpFDFssKx1avjiPmYP Pac5NR9aLuZfPInG8HMrBZtklVb+GUVXEZO+XanuqfHHnI1DyDKKDzABSc+Qo+yYQN5z Rf9lE1wwZ02zfBphMRt4Af0Lop/FcFiqy/hQM=
Received: by 10.223.17.151 with SMTP id s23mr771969faa.13.1311830017561; Wed, 27 Jul 2011 22:13:37 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id q5sm242525fah.30.2011.07.27.22.13.35 (version=SSLv3 cipher=OTHER); Wed, 27 Jul 2011 22:13:36 -0700 (PDT)
Message-ID: <4E30F028.2080408@gmail.com>
Date: Thu, 28 Jul 2011 08:14:16 +0300
From: Mykyta Yevstifeyev 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit
Subject: Re: [apps-discuss] proposing draft-farrell-ni as an appsarea wg item
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 05:13:39 -0000

28.07.2011 4:25, Linyi Tian 01 wrote:
>
> On 11-7-27 11:49, "Stephen Farrell"  wrote:
>
>> Hi,
>>
>> Yesterday, I presented a draft [1] on a URI scheme for naming
>> stuff to the decade WG. There's interest in that there but
>> the idea behind this is really broader than just decade so
>> if there's interest here, doing this work in the appsarea WG
>> would I think be much better.
>>
>> The scheme is basically like HTTP URIs with one additional
>> thing, which is that it specifies a way to include a hash
>> function output in the name (and the related input, in case
>> you want to verify something later) which seems to me to be
>> a generally useful thing that various protocols could use
>> in various ways. Hence the idea of bringing it here.
> I am wondering how this would be used. Will it be used together with HTTP
> URIs? Is there any real life use case how I can use this URI.
+1. I think APPSAWG shouldn't accept this as WG item; I wouldn't also
recommend it for publication of it as AD-sponsored Individual submission
or in any other way as RFC.

There is no clear explanation of operations for new URI scheme. What
should the application do when resolving the 'ni' URI? What protocol
should be used? Also,  includes  and , which
I don't how to be applied to 'ni' URI operations. I think that 'tag'
URIs, which only identify the resource (RFC 4151), are suitable for the
purposes of proposed 'ni' URI scheme.

Mykyta Yevstifeyev
>
>> So, comments appreciated,
>>
>> Thanks,
>> Stephen.
>>
>> [1] http://tools.ietf.org/html/draft-farrell-ni
>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From masinter@adobe.com  Thu Jul 28 05:56:10 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D4C21F8C5B for ; Thu, 28 Jul 2011 05:56:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 5RTXLMIUBaeG for ; Thu, 28 Jul 2011 05:56:09 -0700 (PDT)
Received: from exprod6og114.obsmtp.com (exprod6og114.obsmtp.com [64.18.1.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7C51621F8C3F for ; Thu, 28 Jul 2011 05:56:08 -0700 (PDT)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKTjFcZj6uTIiKCwK3L0wP7BGhOCIWrNKs@postini.com; Thu, 28 Jul 2011 05:56:08 PDT
Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p6SCu5I6010172; Thu, 28 Jul 2011 05:56:05 -0700 (PDT)
Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id p6SCtxMT011072; Thu, 28 Jul 2011 05:56:04 -0700 (PDT)
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Thu, 28 Jul 2011 05:55:59 -0700
From: Larry Masinter 
To: Mykyta Yevstifeyev , "apps-discuss@ietf.org" 
Date: Thu, 28 Jul 2011 05:55:57 -0700
Thread-Topic: [apps-discuss] proposing draft-farrell-ni as an appsarea wg item
Thread-Index: AcxM5TVB7DMuKl3IQt+FQ6BMHByawAAPbuq6
Message-ID: 
References: ,<4E30F028.2080408@gmail.com>
In-Reply-To: <4E30F028.2080408@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] proposing draft-farrell-ni as an appsarea wg item
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 12:56:10 -0000

perhaps IETF should consider adopting (or adapting) as IETF BCP some or all=
 of


http://www.w3.org/TR/webarch/ "Architecture of the World Wide Web" (W3C rec=
ommendation)

http://www.w3.org/2001/tag/doc/SchemeProtocols.html URI Schemes and Web Pro=
tocols  (editor draft W3C TAG finding)

http://www.w3.org/2001/tag/doc/whenToUseGet.html URIs, Addressability, and =
the use of HTTP GET and POST  (approved W3C TAG finding)


as they read on the advisability of inventing new URI schemes. =20

While 4395bis is a work item of the IRI working group, the issues seem out =
of scope for the current working group, which IMHO should focus on the inte=
rnationalization issues of 3987bis.


Larry
--
http://larry.masinter.net



________________________________________
From: apps-discuss-bounces@ietf.org [apps-discuss-bounces@ietf.org] On Beha=
lf Of Mykyta Yevstifeyev [evnikita2@gmail.com]
Sent: Wednesday, July 27, 2011 10:14 PM
To: apps-discuss@ietf.org
Subject: Re: [apps-discuss] proposing draft-farrell-ni as an appsarea wg it=
em

28.07.2011 4:25, Linyi Tian 01 wrote:
>
> On 11-7-27 =1B$B>e8a=1B(B11:49, "Stephen Farrell"  wrote:
>
>> Hi,
>>
>> Yesterday, I presented a draft [1] on a URI scheme for naming
>> stuff to the decade WG. There's interest in that there but
>> the idea behind this is really broader than just decade so
>> if there's interest here, doing this work in the appsarea WG
>> would I think be much better.
>>
>> The scheme is basically like HTTP URIs with one additional
>> thing, which is that it specifies a way to include a hash
>> function output in the name (and the related input, in case
>> you want to verify something later) which seems to me to be
>> a generally useful thing that various protocols could use
>> in various ways. Hence the idea of bringing it here.
> I am wondering how this would be used. Will it be used together with HTTP
> URIs? Is there any real life use case how I can use this URI.
+1. I think APPSAWG shouldn't accept this as WG item; I wouldn't also
recommend it for publication of it as AD-sponsored Individual submission
or in any other way as RFC.

There is no clear explanation of operations for new URI scheme. What
should the application do when resolving the 'ni' URI? What protocol
should be used? Also,  includes  and , which
I don't how to be applied to 'ni' URI operations. I think that 'tag'
URIs, which only identify the resource (RFC 4151), are suitable for the
purposes of proposed 'ni' URI scheme.

Mykyta Yevstifeyev
>
>> So, comments appreciated,
>>
>> Thanks,
>> Stephen.
>>
>> [1] http://tools.ietf.org/html/draft-farrell-ni
>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

From stephen.farrell@cs.tcd.ie  Thu Jul 28 06:41:30 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8188D21F8799 for ; Thu, 28 Jul 2011 06:41:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 tku5uA1uOJwy for ; Thu, 28 Jul 2011 06:41:29 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 61B9D21F8640 for ; Thu, 28 Jul 2011 06:41:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 41F55171C58; Thu, 28 Jul 2011 14:41:15 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1311860474; bh=WhFqBW2XkRS9WS JVMHF5vjXTpNCByXI4xZLR1jsWozQ=; b=am7d6oKbuZ12dIJK2ijtsD12M3Pl1O Zkwz1TyqPom7oou8vhCb3/afXdxItvR8eq8Y5e+oRT8dGfz7amUIZsuiJCLCb4Bk XDjobh+zAeV0jinuyBi2slRj4G1HUWvw8JGgVqdYtGaHi2kqVaClvycWKOPPDk6T aqRynOdISx0+vHy9Lkhj+nE2MQvdqrsSjC1Zgxbr5V0O3601DKdBc3ta3bxTNBvJ r0WPatszlT2s+wQ04PV0Xed6dEXR1XrzsYs5ANil1/MxVTJufRL/jUaO7aIg69rV ZbMVh1CcUVOSw5kAvBig79pLUQu7xd4ugKjoyUnY57xxljeHb2TFip3g==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id kwu0CBJ9Y+mh; Thu, 28 Jul 2011 14:41:14 +0100 (IST)
Received: from [130.129.17.184] (dhcp-11b8.meeting.ietf.org [130.129.17.184]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 58CDF171C59; Thu, 28 Jul 2011 14:41:08 +0100 (IST)
Message-ID: <4E3166F2.4020104@cs.tcd.ie>
Date: Thu, 28 Jul 2011 14:41:06 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: Linyi Tian 01 
References: 
In-Reply-To: 
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: Apps Discuss 
Subject: Re: [apps-discuss] proposing draft-farrell-ni as an appsarea wg item
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 13:41:30 -0000

On 28/07/11 02:25, Linyi Tian 01 wrote:
> 
> 
> On 11-7-27 上午11:49, "Stephen Farrell"  wrote:
> 
>>
>> Hi,
>>
>> Yesterday, I presented a draft [1] on a URI scheme for naming
>> stuff to the decade WG. There's interest in that there but
>> the idea behind this is really broader than just decade so
>> if there's interest here, doing this work in the appsarea WG
>> would I think be much better.
>>
>> The scheme is basically like HTTP URIs with one additional
>> thing, which is that it specifies a way to include a hash
>> function output in the name (and the related input, in case
>> you want to verify something later) which seems to me to be
>> a generally useful thing that various protocols could use
>> in various ways. Hence the idea of bringing it here.
> 
> I am wondering how this would be used. Will it be used together with HTTP
> URIs? Is there any real life use case how I can use this URI.

There are two ways in which this could be used I think, one is
where a protocol carries a URI and then the new scheme could be
used. For HTTP URLs one could use the hash-string construct
within the pathname I guess and that might be useful to document
as an option.

As I said the decade wg are thinking about this for their protocol
work. There are also many HTTP URLs that contain hashes, the extent
to which it'd be useful for someone to be able to know what was input
to the hash is hard to tell. I suspect it'd be useful sometimes
though.

S.

> 
>>
>> So, comments appreciated,
>>
>> Thanks,
>> Stephen.
>>
>> [1] http://tools.ietf.org/html/draft-farrell-ni
>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
> 
> 
> 

From msk@cloudmark.com  Thu Jul 28 08:26:22 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3051921F886A for ; Thu, 28 Jul 2011 08:26:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.776
X-Spam-Level: 
X-Spam-Status: No, score=-103.776 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 tjp4NvOqYnm3 for ; Thu, 28 Jul 2011 08:26:21 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id D03F421F8853 for ; Thu, 28 Jul 2011 08:26:21 -0700 (PDT)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 28 Jul 2011 08:26:21 -0700
From: "Murray S. Kucherawy" 
To: apps-discuss 
Date: Thu, 28 Jul 2011 08:26:19 -0700
Thread-Topic: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
Thread-Index: AcxMs9DOD8oBrs2iQq+incMwBHl5rgAKuY/wABbj/GA=
Message-ID: 
References: <20110727052622.18893.75906.idtracker@ietfa.amsl.com> <4E3013C8.7060203@tana.it>  <01O45CD1RC5O00RCTX@mauve.mrochek.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 15:26:22 -0000

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org=
] On Behalf Of Murray S. Kucherawy
> Sent: Wednesday, July 27, 2011 9:33 PM
> To: ned+apps-discuss@mrochek.com
> Cc: apps-discuss
> Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-=
01.txt
>=20
> And to Barry and/or the ADs: The RFCs we're talking about are all Draft
> Standard.  Could these changes be considered clarifications and not
> require recycles at Proposed Standard, or do we doom them to that by
> making these changes?

...and RFC3464 is showing updated by two other documents.  I imagine we'd h=
ave to sort out how to resolve all of that, so maybe this is a more heavywe=
ight change than I'd hoped.


From msk@cloudmark.com  Thu Jul 28 11:01:34 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81EE121F865E for ; Thu, 28 Jul 2011 11:01:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.767
X-Spam-Level: 
X-Spam-Status: No, score=-103.767 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 HPRfnzmJpOTt for ; Thu, 28 Jul 2011 11:01:34 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id B42A021F863C for ; Thu, 28 Jul 2011 11:01:29 -0700 (PDT)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 28 Jul 2011 11:01:29 -0700
From: "Murray S. Kucherawy" 
To: apps-discuss 
Date: Thu, 28 Jul 2011 11:01:27 -0700
Thread-Topic: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
Thread-Index: AcxMs9DOD8oBrs2iQq+incMwBHl5rgAKuY/wABw1ThA=
Message-ID: 
References: <20110727052622.18893.75906.idtracker@ietfa.amsl.com> <4E3013C8.7060203@tana.it>  <01O45CD1RC5O00RCTX@mauve.mrochek.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 18:01:34 -0000

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org=
] On Behalf Of Murray S. Kucherawy
> Sent: Wednesday, July 27, 2011 9:33 PM
> To: ned+apps-discuss@mrochek.com
> Cc: apps-discuss
> Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-=
01.txt
>=20
> I'm happy to take those on as well as individual submissions in support
> of the MARF work, assuming such work is limited to these small changes
> doesn't become a kitchen sink for a massive collection of updates to
> these three RFCs.  If it becomes a bigger update project, I think we're
> talking about something YAM-like, or at least something that should
> land in APPSAWG.

Well, I started down this road and was delighted to find this sort of text =
in both the DSN and MDN documents:

3.  Format of a Message Disposition Notification

   A message disposition notification is a MIME message with a top-level
   content-type of multipart/report (defined in [RFC-REPORT]).  When
   multipart/report content is used to transmit an MDN: ...

So it seems removing the restriction entirely from RFC3462 is fine, because=
 it's basically repeated here.  Hopefully that can just proceed then, and e=
nables progress for MARF.

The remaining issue, I think, is what Keith wants to see, which is an asser=
tion that at generation time the above is required, but not when an existin=
g one is forwarded inside a multipart.  I believe that will require only a =
slight wording change to DSN and MDN text shown above, but will also thus r=
equire publishing an update (clarification?) to two Draft Standards, one of=
 which has updates from other documents.


From ned.freed@mrochek.com  Thu Jul 28 11:13:58 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C74811E8123 for ; Thu, 28 Jul 2011 11:13:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.514
X-Spam-Level: 
X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085,  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 ArTSJSmbkxUF for ; Thu, 28 Jul 2011 11:13:57 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 94F6711E8119 for ; Thu, 28 Jul 2011 11:13:57 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O46FWVUGXC00VEN3@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 28 Jul 2011 11:12:54 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O466URZ2A800VHKR@mauve.mrochek.com>; Thu, 28 Jul 2011 11:12:50 -0700 (PDT)
Message-id: <01O46FWTC6N600VHKR@mauve.mrochek.com>
Date: Thu, 28 Jul 2011 11:10:02 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Thu, 28 Jul 2011 08:26:19 -0700" 
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <20110727052622.18893.75906.idtracker@ietfa.amsl.com> <4E3013C8.7060203@tana.it>  <01O45CD1RC5O00RCTX@mauve.mrochek.com>  
To: "Murray S. Kucherawy" 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1311876731; bh=lZ2oRc3bBHVZsQTmfzbmcnwxMKnmK0oaOnozFOQJ0UU=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=NXyBluxao04IeVcHFcZ/XoJ3TifvsnotKSWkhtaKBWY4sxMO14PltgawIiUxXZMhY JwOPfoTgWW48rrnt+tzsNmuaNSDIiwEibrmsd/UzuoLLqJrr57ZDgkaqKaFytu2bQ/ AOjq+PQthXaIi66djxlwwfWANdRDTGyet+euYhYI=
Cc: apps-discuss 
Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 18:13:58 -0000

> > -----Original Message-----
> > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
> > Sent: Wednesday, July 27, 2011 9:33 PM
> > To: ned+apps-discuss@mrochek.com
> > Cc: apps-discuss
> > Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
> >
> > And to Barry and/or the ADs: The RFCs we're talking about are all Draft
> > Standard.  Could these changes be considered clarifications and not
> > require recycles at Proposed Standard, or do we doom them to that by
> > making these changes?

> ...and RFC3464 is showing updated by two other documents.  I imagine we'd
> have to sort out how to resolve all of that, so maybe this is a more
> heavyweight change than I'd hoped.

I have to ask: So what? So let's say we have to do a 3462bis that resets
things to proposed.

Why is this a big deal? We do it, six months later we advance the
specification back to draft - this should be easy since we only need
to review the consequences, if any, of the change we're making.

				Ned

P.S. It would be a little more difficult if revisions to the DSN and MDN
specs were needed, but that does not appear to be the case.

From msk@cloudmark.com  Thu Jul 28 11:18:56 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD1911E812B for ; Thu, 28 Jul 2011 11:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.765
X-Spam-Level: 
X-Spam-Status: No, score=-103.765 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 M1doA7zACHDZ for ; Thu, 28 Jul 2011 11:18:55 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id CD69911E8121 for ; Thu, 28 Jul 2011 11:18:55 -0700 (PDT)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 28 Jul 2011 11:18:55 -0700
From: "Murray S. Kucherawy" 
To: apps-discuss 
Date: Thu, 28 Jul 2011 11:18:53 -0700
Thread-Topic: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
Thread-Index: AcxNUhvSvA/Mple+T/CFynda8+cYGwAAGgiQ
Message-ID: 
References: <20110727052622.18893.75906.idtracker@ietfa.amsl.com> <4E3013C8.7060203@tana.it>  <01O45CD1RC5O00RCTX@mauve.mrochek.com>   <01O46FWTC6N600VHKR@mauve.mrochek.com>
In-Reply-To: <01O46FWTC6N600VHKR@mauve.mrochek.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 18:18:56 -0000

> -----Original Message-----
> From: Ned Freed [mailto:ned.freed@mrochek.com]
> Sent: Thursday, July 28, 2011 11:10 AM
> To: Murray S. Kucherawy
> Cc: apps-discuss
> Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-=
01.txt
>=20
> > ...and RFC3464 is showing updated by two other documents.  I imagine we=
'd
> > have to sort out how to resolve all of that, so maybe this is a more
> > heavyweight change than I'd hoped.
>=20
> I have to ask: So what? So let's say we have to do a 3462bis that resets
> things to proposed.
>=20
> Why is this a big deal? We do it, six months later we advance the
> specification back to draft - this should be easy since we only need
> to review the consequences, if any, of the change we're making.

Maybe my impression that recycling is something we prefer to avoid is more =
inflated than it should be.  If that's the case, then it looks like this is=
 the path forward, at least for 3462.

If we think the DSN and MDN specs are fine as-is and don't need stronger la=
nguage about the format used at generation time, then I guess we're close t=
o done other than initiating publication.


From dhc@dcrocker.net  Thu Jul 28 11:22:59 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B2411E8078 for ; Thu, 28 Jul 2011 11:22:59 -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 ZwLwGUjYhlMH for ; Thu, 28 Jul 2011 11:22:58 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6382C11E80F0 for ; Thu, 28 Jul 2011 11:22:57 -0700 (PDT)
Received: from [130.129.85.251] (dhcp-55fb.meeting.ietf.org [130.129.85.251]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p6SIMndE014316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Jul 2011 11:22:56 -0700
Message-ID: <4E31A8F6.6060304@dcrocker.net>
Date: Thu, 28 Jul 2011 14:22:46 -0400
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20110727052622.18893.75906.idtracker@ietfa.amsl.com> <4E3013C8.7060203@tana.it>  <01O45CD1RC5O00RCTX@mauve.mrochek.com>   <01O46FWTC6N600VHKR@mauve.mrochek.com>
In-Reply-To: <01O46FWTC6N600VHKR@mauve.mrochek.com>
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]); Thu, 28 Jul 2011 11:22:57 -0700 (PDT)
Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 18:22:59 -0000

On 7/28/2011 2:10 PM, Ned Freed wrote:
>> ...and RFC3464 is showing updated by two other documents.  I imagine we'd
>> have to sort out how to resolve all of that, so maybe this is a more
>> heavyweight change than I'd hoped.
>
> I have to ask: So what? So let's say we have to do a 3462bis that resets
> things to proposed.
>
> Why is this a big deal? We do it, six months later we advance the
> specification back to draft - this should be easy since we only need
> to review the consequences, if any, of the change we're making.


The transaction cost of having an additional process through the IETF/IESG is 
never trivial.

I know you know this; I don't know why you think it's a small deal.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From vesely@tana.it  Thu Jul 28 12:19:39 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACD91F0C3C for ; Thu, 28 Jul 2011 12:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.752
X-Spam-Level: 
X-Spam-Status: No, score=-4.752 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 0UXcGuTk6zoM for ; Thu, 28 Jul 2011 12:19:39 -0700 (PDT)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id F02C31F0C39 for ; Thu, 28 Jul 2011 12:19:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1311880777; bh=IP80awngvSb8786VqjGQCz7gTKCXPfClYbBp7OfQu/Q=; l=2798; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=hBGTRJTw9yXgW9cEeKvelYwMYfaRfKLc9RIyfq4mXtp7IcLFAWkoTp37XNfpDvCO9 ydFVzFqcex37yk2HbVZHUPwC0UmKWkzsgzl5eM4cZ51/+LroEs6Z+TzZhCjblSvvuq QbudyMXQpeu140idZHy5yP2yBSei+j5lG1lx8jwE=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 28 Jul 2011 21:19:37 +0200 id 00000000005DC039.000000004E31B649.00005D24
Message-ID: <4E31B648.2020802@tana.it>
Date: Thu, 28 Jul 2011 21:19:36 +0200
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20110727052622.18893.75906.idtracker@ietfa.amsl.com>	<4E3013C8.7060203@tana.it>	 <01O45CD1RC5O00RCTX@mauve.mrochek.com>
In-Reply-To: <01O45CD1RC5O00RCTX@mauve.mrochek.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 19:19:40 -0000

On 28/Jul/11 00:55, ned+apps-discuss@mrochek.com wrote:
> Multipart/report is, or should be, a very general construct used to report
> pretty much anything relating to messages or perhaps even more general MIME
> content.
> 
> The restriction that generated DSNs and MDNs (two specific types of report)
> need to be placed at the top-level is what's needed here. Nothing more.

IMHO "generated" is not very clear here.  I roughly understand it as
referring to the act of issuing a report, automatically or not.

BTW, ARF reports, as currently used, probably have to be at top level
as well.

> In fact the best way to handle this would be to put the restriction into the
> DSN and MDN specifications that build on the multipart/report framework, and
> say something like, "Uses of the multipart/report container format MAY restrict
> the contexts in which a particular report type can appear."

Does that mean top-level implies "active"?

> [moved] We should not attempt to guess at possible future uses of
> the report framework. This sort of anticipatory restriction is what
> gets us into trouble with great regularity, and we need to stop
> doing it.

In general, I agree.  But here we are introducing a split, or
categorization, to distinguish "active", "generated", or "top-level"
from other kinds of report transmission.  How can we do so without
affecting future report types as well?

>>> I'm puzzled about the "and gateways" part.  Is it correct?
> 
> Yes. A proper gateway to X.400, for example, will turn a top-level DSN into an
> X.400 delivery report and vice versa. (It would nice if the same applied to
> MDNs and X.400 read receipts, but the semantics are so dissimilar that
> conversion is infeasible.)

I'm not familiar with X.400, but this turns out to be a clarifying
element.  Top-level reports may be converted.  In pseudo-code

  if (/^Content-Type: *multipart\/report.*report-type=([:value:]+)/ih)
  // assume h stands for header only, and :value: catches token or
  // quoted-string appropriately
  {
    switch ($1)
    {
      case "delivery-status":
      // convert
      // ...
    }
  }

The task of preserving gateway functionality allows to define the
behavior without shredding much more light on the semantics of
"top-level" vs. "wrapped".

>>> Question: in case an ARF processor forwards an abuse (mis)report to
>>> the original author, is it correct to keep multipart/report as the top
>>> Content-Type?

I'm sorry I badly expressed this point.  Consider that the original
author probably has a copy of the reported message in her "Sent"
folder.  In this particular case, an agent could do some meaningful
work with reports.  Would it make sense to send the report as
"active", so as to trigger any agent that may process it?

jm2c

From Martin.Thomson@commscope.com  Thu Jul 28 13:44:07 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227AD5E800E for ; Thu, 28 Jul 2011 13:44:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.579
X-Spam-Level: 
X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020,  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 dCMCXrVyX86z for ; Thu, 28 Jul 2011 13:44:06 -0700 (PDT)
Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 6548B5E8014 for ; Thu, 28 Jul 2011 13:44:06 -0700 (PDT)
X-AuditID: 0a0404e8-b7c24ae000002adb-fe-4e31ca22c13f
Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id B3.04.10971.22AC13E4; Thu, 28 Jul 2011 15:44:18 -0500 (CDT)
Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 28 Jul 2011 15:44:04 -0500
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 29 Jul 2011 04:44:01 +0800
From: "Thomson, Martin" 
To: "apps-discuss@ietf.org" , "draft-zyp-json-schema@tools.ietf.org" 
Date: Fri, 29 Jul 2011 04:44:00 +0800
Thread-Topic: Feedback on draft-zyp-json-schema-03
Thread-Index: AcxNZbY9SgSmDFKXS1+wIODcDsUXTA==
Message-ID: <8B0A9FCBB9832F43971E38010638454F040D2C392C@SISPE7MB1.commscope.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: [apps-discuss] Feedback on draft-zyp-json-schema-03
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 20:44:07 -0000

Wow.

There is way too much stuff in this document.  It includes far more than I =
expected to find.  Some of that is pretty cool and I'd encourage you to fin=
d a way to submit a draft on each of:

 - the link relation type (this shouldn't just be constrained to JSON schem=
as)

 - the grammar for identifying parts of a JSON document

For that reason, I did not review Sections 4 and 6.

You'll notice that I don't have a lot of criticisms on the core schema stuf=
f.  Despite these criticisms, the core of the specification is looking pret=
ty strong.

Criticisms:

The simple type constraints (or facets) in XML schema are quite good, widel=
y understood and fairly simple.  I'd encourage you to borrow these wholesal=
e - semantics, names and all.

Complex types cannot be defined outside of the context where they are used.=
  For more complicated schema documents, the ability to define a set of pro=
perties, assign them an identity and include this set by reference would be=
 a powerful tool.

The extension mechanism is a tough one to get right.  Such things are a roy=
al pain in XML schemas and only marginally better in RelaxNG.  By addressin=
g the above, this feature might not be necessary.

I really don't like the way that arrays can have different types at each po=
sition in the array.  I appreciate that JSON can do this, but there is no n=
eed to condone that sort of behaviour.

I really like the idea that the default mode is for objects to be extensibl=
e by default.  The idea that you might identify a specific schema (in addit=
ionalProperties/additionalItems) that is valid for extension, I like a whol=
e lot less.  And why is it just one schema?  I don't see a strong case for =
this sort of feature.

I didn't get dependencies, but I didn't try that hard.  The description was=
 confusing and it smells pretty bad.

Section 7 made little sense to me.

Questions:

Can default have an object value?  I assume yes.

Does the default have to be valid according to the grammar?

Why do $ref and $schema have the '$'?  Since you've no risk of collision, w=
hy not just drop it?

--Martin

From stpeter@stpeter.im  Thu Jul 28 13:51:34 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8D621F8B20 for ; Thu, 28 Jul 2011 13:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.561
X-Spam-Level: 
X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, 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 zVykpU3+Goix for ; Thu, 28 Jul 2011 13:51:33 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C7CB021F8B1B for ; Thu, 28 Jul 2011 13:51:33 -0700 (PDT)
Received: from dhcp-13ac.meeting.ietf.org (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 26787410E8; Thu, 28 Jul 2011 14:52:37 -0600 (MDT)
Message-ID: <4E31CBD3.8040200@stpeter.im>
Date: Thu, 28 Jul 2011 16:51:31 -0400
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Stephen Farrell 
References:  <4E3166F2.4020104@cs.tcd.ie>
In-Reply-To: <4E3166F2.4020104@cs.tcd.ie>
X-Enigmail-Version: 1.2
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: Apps Discuss 
Subject: Re: [apps-discuss] proposing draft-farrell-ni as an appsarea wg item
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 20:51:34 -0000

On 7/28/11 9:41 AM, Stephen Farrell wrote:
> 
> 
> On 28/07/11 02:25, Linyi Tian 01 wrote:
>>
>>
>> On 11-7-27 上午11:49, "Stephen Farrell"  wrote:
>>
>>>
>>> Hi,
>>>
>>> Yesterday, I presented a draft [1] on a URI scheme for naming
>>> stuff to the decade WG. There's interest in that there but
>>> the idea behind this is really broader than just decade so
>>> if there's interest here, doing this work in the appsarea WG
>>> would I think be much better.
>>>
>>> The scheme is basically like HTTP URIs with one additional
>>> thing, which is that it specifies a way to include a hash
>>> function output in the name (and the related input, in case
>>> you want to verify something later) which seems to me to be
>>> a generally useful thing that various protocols could use
>>> in various ways. Hence the idea of bringing it here.
>>
>> I am wondering how this would be used. Will it be used together with HTTP
>> URIs? Is there any real life use case how I can use this URI.
> 
> There are two ways in which this could be used I think, one is
> where a protocol carries a URI and then the new scheme could be
> used. For HTTP URLs one could use the hash-string construct
> within the pathname I guess and that might be useful to document
> as an option.
> 
> As I said the decade wg are thinking about this for their protocol
> work. There are also many HTTP URLs that contain hashes, the extent
> to which it'd be useful for someone to be able to know what was input
> to the hash is hard to tell. I suspect it'd be useful sometimes
> though.

I've heard about other folks who are interested in a very simple method
for either a URN or a URI for identifying the output of a hash function.

Possible examples of URNs and URIs:

urn:hash:sha256:NDc0NzgyMGVmOGQ3OGU0...

sha256:NDc0NzgyMGVmOGQ3OGU0...

I don't think this should be a URN, because a URN namespace is managed.
(In this sense RFC 4122 is misguided and deserves to be deprecated.)

I don't see the need for an authority component, but maybe I'm missing
something in the use cases.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From ned.freed@mrochek.com  Thu Jul 28 14:54:14 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8B411E812A for ; Thu, 28 Jul 2011 14:54:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.522
X-Spam-Level: 
X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077,  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 AGDmZ27m+cag for ; Thu, 28 Jul 2011 14:54:13 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 99B6811E80AC for ; Thu, 28 Jul 2011 14:54:13 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O46NM6OGWG010DO6@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 28 Jul 2011 14:53:20 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O46LRD9W9C00RCTX@mauve.mrochek.com>; Thu, 28 Jul 2011 14:53:16 -0700 (PDT)
Message-id: <01O46NM4E0WS00RCTX@mauve.mrochek.com>
Date: Thu, 28 Jul 2011 14:40:56 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Thu, 28 Jul 2011 14:22:46 -0400" <4E31A8F6.6060304@dcrocker.net>
MIME-version: 1.0
Content-type: TEXT/PLAIN; Format=flowed
References: <20110727052622.18893.75906.idtracker@ietfa.amsl.com> <4E3013C8.7060203@tana.it>  <01O45CD1RC5O00RCTX@mauve.mrochek.com>   <01O46FWTC6N600VHKR@mauve.mrochek.com> <4E31A8F6.6060304@dcrocker.net>
To: Dave CROCKER 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1311889957; bh=0sHigJ2cYQ9PzWEDX0H5DV7ncnXi2n/n4R5CB+EW3/U=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=VAt44qA+8kcMu92CUgKGp8dXKz1M0f4tnCfn1u01xdogDjWf3PoHyzVycRRYe+/y9 hZ7k5t4ZEpzwC7Tmi3qCRxydrCipQe/ms/BXTdm4gKjDxIZKBtozfkFj6tzVPqc5MH 5JSTeYMGplNNTZbuUcInIrYopvGtRf4HN+KyqxzI=
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 21:54:14 -0000

> On 7/28/2011 2:10 PM, Ned Freed wrote:
> >> ...and RFC3464 is showing updated by two other documents.  I imagine we'd
> >> have to sort out how to resolve all of that, so maybe this is a more
> >> heavyweight change than I'd hoped.
> >
> > I have to ask: So what? So let's say we have to do a 3462bis that resets
> > things to proposed.
> >
> > Why is this a big deal? We do it, six months later we advance the
> > specification back to draft - this should be easy since we only need
> > to review the consequences, if any, of the change we're making.


> The transaction cost of having an additional process through the IETF/IESG is
> never trivial.

Actually, I can point at any number of cases where it was pretty painless. In
particular, small revisions to existing widely deployed standards seem to fare
pretty well. Of course there are exceptions, like the revision to the Sieve
base spec, where someone gets a hair up their butt and files a totally
inappropriate DISCUSS, but one things for sure: Doing nothing guarantees
nothing will be done.

> I know you know this; I don't know why you think it's a small deal.

Perhaps because it *should* be a small deal. And to the extent it isn't, I'm
not sure I see the value in trying to accomodate brokenness.

				Ned

From barryleiba.mailing.lists@gmail.com  Thu Jul 28 15:01:49 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3501A11E8081 for ; Thu, 28 Jul 2011 15:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.056
X-Spam-Level: 
X-Spam-Status: No, score=-103.056 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 3ht7zR7E9Yt8 for ; Thu, 28 Jul 2011 15:01:48 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id B61AA11E807E for ; Thu, 28 Jul 2011 15:01:48 -0700 (PDT)
Received: by yie30 with SMTP id 30so2638451yie.31 for ; Thu, 28 Jul 2011 15:01:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=M685+qtOD4Wg9pB6pPhRhU/tAgx79vtduUOgrIBj0I0=; b=o1dCZfkyUnIWZ0f5jyw0EjQiHHqjz2CGDv6O21PXSh7ceFDAiV6fXEYhRKULxZH0nN py3vLGATvh+9b/bW1YOW03Au64jBz/QqGpdoRzymEaCSQiMprf9Hc1Tv4/trvY1JkIvv i6NzS+3I+3o1D6aFkMhVnu1TzpFjk7y3lShGE=
MIME-Version: 1.0
Received: by 10.236.144.200 with SMTP id n48mr193828yhj.348.1311890506741; Thu, 28 Jul 2011 15:01:46 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.32.15 with HTTP; Thu, 28 Jul 2011 15:01:46 -0700 (PDT)
In-Reply-To: <01O46NM4E0WS00RCTX@mauve.mrochek.com>
References: <20110727052622.18893.75906.idtracker@ietfa.amsl.com> <4E3013C8.7060203@tana.it>  <01O45CD1RC5O00RCTX@mauve.mrochek.com>   <01O46FWTC6N600VHKR@mauve.mrochek.com> <4E31A8F6.6060304@dcrocker.net> <01O46NM4E0WS00RCTX@mauve.mrochek.com>
Date: Thu, 28 Jul 2011 18:01:46 -0400
X-Google-Sender-Auth: wlBE_NCPmZSwxDoVcOR8C_LbuJA
Message-ID: 
From: Barry Leiba 
To: Ned Freed 
Content-Type: text/plain; charset=ISO-8859-1
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 22:01:49 -0000

>> I know you know this; I don't know why you think it's a small deal.
>
> Perhaps because it *should* be a small deal. And to the extent it isn't, I'm
> not sure I see the value in trying to accomodate brokenness.

At least part of Dave's point, setting aside issues related to
complaints and over-tweaking and DISCUSS ballots, is that there's a
*real* cost to getting any document through that involves:

-- Someone taking on the task of editing the document and making the
case for it.
-- A document shepherd and reviewers to make sure it's ready to go.
-- An AD's time to manage the process.
-- An IETF-wide last call.
-- Usually, several directorate reviews; at least GenART and SecDir
for everything.
-- IESG review, which requires ballots (and, therefore, presumably,
review) from at least ten ADs.
-- Time on a telechat, even if it's only a minute or two.
-- Review by IANA, and communication with the authors.
-- RFC Editor processing, which is never insignificant.

I might have missed something, but I think I got most of it.  Even the
most lightweight version of all that is more expensive than most of us
think about.

Barry

From ned.freed@mrochek.com  Thu Jul 28 15:17:54 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2858A21F885C for ; Thu, 28 Jul 2011 15:17:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.529
X-Spam-Level: 
X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070,  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 h+F8sK0t83j4 for ; Thu, 28 Jul 2011 15:17:53 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB7E21F87BC for ; Thu, 28 Jul 2011 15:17:53 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O46OGI0EEO0115FE@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 28 Jul 2011 15:17:00 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O46LRD9W9C00RCTX@mauve.mrochek.com>; Thu, 28 Jul 2011 15:16:54 -0700 (PDT)
Message-id: <01O46OGEP5II00RCTX@mauve.mrochek.com>
Date: Thu, 28 Jul 2011 15:05:32 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Thu, 28 Jul 2011 18:01:46 -0400" 
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <20110727052622.18893.75906.idtracker@ietfa.amsl.com> <4E3013C8.7060203@tana.it>  <01O45CD1RC5O00RCTX@mauve.mrochek.com>   <01O46FWTC6N600VHKR@mauve.mrochek.com> <4E31A8F6.6060304@dcrocker.net> <01O46NM4E0WS00RCTX@mauve.mrochek.com> 
To: Barry Leiba 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1311891377; bh=cWJd76ogTDUyL2RLZIg/XaUDI4yAcrK7PYHLT3ftvGg=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=hlkPRN82AGfUGx4CFgib1wxODAY02Kbw6nZHQ5nHCwJ0/8pYRWxo59TAsHPgmp3k1 Eg/zhQIm5nCoKSgf1An90hkTM09DonRWiWDdgW5BeirL2GGgX4bbquNL2Fn0Suvi2o 4o81JOS/f7Pxr9n/7zPUeza+lG0tN1BU+1kBqaEE=
Cc: Ned Freed , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 22:17:54 -0000

> >> I know you know this; I don't know why you think it's a small deal.
> >
> > Perhaps because it *should* be a small deal. And to the extent it isn't, I'm
> > not sure I see the value in trying to accomodate brokenness.

> At least part of Dave's point, setting aside issues related to
> complaints and over-tweaking and DISCUSS ballots, is that there's a
> *real* cost to getting any document through that involves:

> -- Someone taking on the task of editing the document and making the
> case for it.

> -- A document shepherd and reviewers to make sure it's ready to go.
> -- An AD's time to manage the process.
> -- An IETF-wide last call.
> -- Usually, several directorate reviews; at least GenART and SecDir
> for everything.
> -- IESG review, which requires ballots (and, therefore, presumably,
> review) from at least ten ADs.
> -- Time on a telechat, even if it's only a minute or two.
> -- Review by IANA, and communication with the authors.
> -- RFC Editor processing, which is never insignificant.

> I might have missed something, but I think I got most of it.  Even the
> most lightweight version of all that is more expensive than most of us
> think about.

No, it's exactly as expensive as I assumed it would be.

But given that this is a draft standard and the rules say removing a
restriction means recycle at proposed, what alternative would you suggest?
Creating a new document that removes the restriction, getting that approved at
proposed, then moving that to draft, then revising at  draft is actually more
steps and more work. Or perhaps you would prefer to make a nice big mess by
creating a new subtype like, say,
multipart/report-without-restriction-because-IETF-processes-are-too-heavy-to-fix-stuff?

I'm sorry, but tying ourselves into knots trying to avoid doing the right
thing is expensive in its own right - vastly more expensive IMNSHO than
the process you're trying to avoid.

				Ned

From tony@att.com  Thu Jul 28 15:41:31 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE9821F8BB4 for ; Thu, 28 Jul 2011 15:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.97
X-Spam-Level: 
X-Spam-Status: No, score=-105.97 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 xcZQntzaQvgj for ; Thu, 28 Jul 2011 15:41:30 -0700 (PDT)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id A851721F8BAE for ; Thu, 28 Jul 2011 15:41:30 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: tony@att.com
X-Msg-Ref: server-15.tower-119.messagelabs.com!1311892889!22783001!1
X-StarScan-Version: 6.2.17; banners=-,-,-
X-Originating-IP: [144.160.20.145]
Received: (qmail 31179 invoked from network); 28 Jul 2011 22:41:29 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-15.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Jul 2011 22:41:29 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p6SMftZA005240 for ; Thu, 28 Jul 2011 18:41:55 -0400
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p6SMfomE005153 for ; Thu, 28 Jul 2011 18:41:51 -0400
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p6SMfPVq029244 for ; Thu, 28 Jul 2011 18:41:25 -0400
Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p6SMfKZZ029091 for ; Thu, 28 Jul 2011 18:41:20 -0400
Received: from [135.70.29.27] (vpn-135-70-29-27.vpn.west.att.com[135.70.29.27]) by maillennium.att.com (mailgw1) with ESMTP id <20110728224119gw100e4lhke> (Authid: tony); Thu, 28 Jul 2011 22:41:19 +0000
X-Originating-IP: [135.70.29.27]
Message-ID: <4E31E583.9030608@att.com>
Date: Thu, 28 Jul 2011 18:41:07 -0400
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: "Murray S. Kucherawy" 
References: <20110727052622.18893.75906.idtracker@ietfa.amsl.com> <4E3013C8.7060203@tana.it>  <01O45CD1RC5O00RCTX@mauve.mrochek.com>  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss 
Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 22:41:32 -0000

The MDN spec needs an update for other reasons. Now that YAM is dead, I 
might be persuaded to crack it open.

     Tony

On 7/28/2011 2:01 PM, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
>> Sent: Wednesday, July 27, 2011 9:33 PM
>> To: ned+apps-discuss@mrochek.com
>> Cc: apps-discuss
>> Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
>>
>> I'm happy to take those on as well as individual submissions in support
>> of the MARF work, assuming such work is limited to these small changes
>> doesn't become a kitchen sink for a massive collection of updates to
>> these three RFCs.  If it becomes a bigger update project, I think we're
>> talking about something YAM-like, or at least something that should
>> land in APPSAWG.
> Well, I started down this road and was delighted to find this sort of text in both the DSN and MDN documents:
>
> 3.  Format of a Message Disposition Notification
>
>     A message disposition notification is a MIME message with a top-level
>     content-type of multipart/report (defined in [RFC-REPORT]).  When
>     multipart/report content is used to transmit an MDN: ...
>
> So it seems removing the restriction entirely from RFC3462 is fine, because it's basically repeated here.  Hopefully that can just proceed then, and enables progress for MARF.
>
> The remaining issue, I think, is what Keith wants to see, which is an assertion that at generation time the above is required, but not when an existing one is forwarded inside a multipart.  I believe that will require only a slight wording change to DSN and MDN text shown above, but will also thus require publishing an update (clarification?) to two Draft Standards, one of which has updates from other documents.
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

From ned.freed@mrochek.com  Thu Jul 28 15:47:57 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7768311E80CB for ; Thu, 28 Jul 2011 15:47:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.535
X-Spam-Level: 
X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064,  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 QV9fZaB-oMQX for ; Thu, 28 Jul 2011 15:47:56 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id B5B6611E80B5 for ; Thu, 28 Jul 2011 15:47:56 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O46PHRABKW00Y35V@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 28 Jul 2011 15:47:03 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O46LRD9W9C00RCTX@mauve.mrochek.com>; Thu, 28 Jul 2011 15:46:58 -0700 (PDT)
Message-id: <01O46PHOZA6E00RCTX@mauve.mrochek.com>
Date: Thu, 28 Jul 2011 15:41:04 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Thu, 28 Jul 2011 21:19:36 +0200" <4E31B648.2020802@tana.it>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <20110727052622.18893.75906.idtracker@ietfa.amsl.com> <4E3013C8.7060203@tana.it>  <01O45CD1RC5O00RCTX@mauve.mrochek.com> <4E31B648.2020802@tana.it>
To: Alessandro Vesely 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1311893180; bh=HkNzqHvXmwuXtUOhTFI+yCysJEL+cM38XCvVhUB+7Ds=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=kEjEclFNNO11M//VoEIJwHAZ0rRJbWryLNz+Uw9dcQuvPrSgWtCjpQRb9ar4Z0TLX F1Xiir+cSfj23ir4MFpA1rft37BHDtJ001bPPtWE9/TpDccipqxhDT8Q+OF6hqCrDs 4XIQyURV+4+5SqRnNMm36lSD0YTuSlYJIccfYYGc=
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 22:47:57 -0000

> On 28/Jul/11 00:55, ned+apps-discuss@mrochek.com wrote:
> > Multipart/report is, or should be, a very general construct used to report
> > pretty much anything relating to messages or perhaps even more general MIME
> > content.
> >
> > The restriction that generated DSNs and MDNs (two specific types of report)
> > need to be placed at the top-level is what's needed here. Nothing more.

> IMHO "generated" is not very clear here.  I roughly understand it as
> referring to the act of issuing a report, automatically or not.

> BTW, ARF reports, as currently used, probably have to be at top level
> as well.

> > In fact the best way to handle this would be to put the restriction into the
> > DSN and MDN specifications that build on the multipart/report framework, and
> > say something like, "Uses of the multipart/report container format MAY restrict
> > the contexts in which a particular report type can appear."

> Does that mean top-level implies "active"?

You know, I was thinking about that as well. It's clear than active DSNs and
MDNs have to be top-level but that doesn't mean the converse is necessarily
true.

Operationally at least, I think the answer is something along the lines of,
"it's active if it correlates with a message you sent, otherwise not". 

I'm not sure if this warrants mention in the spec or not.

> > [moved] We should not attempt to guess at possible future uses of
> > the report framework. This sort of anticipatory restriction is what
> > gets us into trouble with great regularity, and we need to stop
> > doing it.

> In general, I agree.  But here we are introducing a split, or
> categorization, to distinguish "active", "generated", or "top-level"
> from other kinds of report transmission.  How can we do so without
> affecting future report types as well?

Well, the obvious thing is to say that all report types need to specify
the contexts in which they can appear and what they mean in those contexts.

> >>> I'm puzzled about the "and gateways" part.  Is it correct?
> >
> > Yes. A proper gateway to X.400, for example, will turn a top-level DSN into an
> > X.400 delivery report and vice versa. (It would nice if the same applied to
> > MDNs and X.400 read receipts, but the semantics are so dissimilar that
> > conversion is infeasible.)

> I'm not familiar with X.400,

Consider yourself fortunate in that regard.

> but this turns out to be a clarifying
> element.  Top-level reports may be converted.  In pseudo-code

>   if (/^Content-Type: *multipart\/report.*report-type=([:value:]+)/ih)
>   // assume h stands for header only, and :value: catches token or
>   // quoted-string appropriately
>   {
>     switch ($1)
>     {
>       case "delivery-status":
>       // convert
>       // ...
>     }
>   }

Yep, that look about right. It also has to be outermost level because in X.400
a delivery report is not, properly speaking, a message, so you cannot include
other message-ish stuff in it.

> The task of preserving gateway functionality allows to define the
> behavior without shredding much more light on the semantics of
> "top-level" vs. "wrapped".

> >>> Question: in case an ARF processor forwards an abuse (mis)report to
> >>> the original author, is it correct to keep multipart/report as the top
> >>> Content-Type?

> I'm sorry I badly expressed this point.  Consider that the original
> author probably has a copy of the reported message in her "Sent"
> folder.  In this particular case, an agent could do some meaningful
> work with reports.  Would it make sense to send the report as
> "active", so as to trigger any agent that may process it?

I don't see why not, but then again I'm not entirely clear on all the ins
and outs of ARF usage.

				Ned

From stephen.farrell@cs.tcd.ie  Thu Jul 28 16:06:17 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3B011E809B for ; Thu, 28 Jul 2011 16:06:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 GZrMZ9qaB5xw for ; Thu, 28 Jul 2011 16:06:17 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 303EC11E8082 for ; Thu, 28 Jul 2011 16:06:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 14349171C1A; Fri, 29 Jul 2011 00:06:13 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1311894372; bh=6Hluh+aYyukaMi jUFXKG1IWe5HVmXXjiahx2au08VAM=; b=qkBwdDFry/F5BZf84zONpraZIjxwqc mpn2jRivadFebrAvbKvgEC7uokxNnzHvNoLjV8afZ2s3YtpWaCPXKaqRMLY0uJ0r bjfDCBFIEoumpsvvOBEb+0lEun6vxwcqPCG7m0yWBaO1NxJgc6/VBSuXCgzkp4Ff yuSN2hFWIfBKDNL95RTk4tMIWPlnJZE5aohyIkI/Ip5cm2tTXJcsMaj9NYAhZy1t NlgEEVqvMbP0Cpyd0g0dKJmbeH/ntcfc1bDbilQWSiivHf103MDIO7Qh6KJH3Eo+ 6iqJiQbJgHBeQkb6cW3/ntYTgyQwtD3XofX0v3qgPfHg3ZFdBS1lnEeA==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id bej9GHlvx8dn; Fri, 29 Jul 2011 00:06:12 +0100 (IST)
Received: from [130.129.17.184] (dhcp-11b8.meeting.ietf.org [130.129.17.184]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id E59FE171C18; Fri, 29 Jul 2011 00:06:01 +0100 (IST)
Message-ID: <4E31EB51.5010408@cs.tcd.ie>
Date: Fri, 29 Jul 2011 00:05:53 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: Peter Saint-Andre 
References:  <4E3166F2.4020104@cs.tcd.ie> <4E31CBD3.8040200@stpeter.im>
In-Reply-To: <4E31CBD3.8040200@stpeter.im>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Apps Discuss 
Subject: Re: [apps-discuss] proposing draft-farrell-ni as an appsarea wg item
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2011 23:06:17 -0000

On 28/07/11 21:51, Peter Saint-Andre wrote:

> I've heard about other folks who are interested in a very simple method
> for either a URN or a URI for identifying the output of a hash function.
> 
> Possible examples of URNs and URIs:
> 
> urn:hash:sha256:NDc0NzgyMGVmOGQ3OGU0...
> 
> sha256:NDc0NzgyMGVmOGQ3OGU0...
> 
> I don't think this should be a URN, because a URN namespace is managed.
> (In this sense RFC 4122 is misguided and deserves to be deprecated.)

I think that's useful input - thanks.

> 
> I don't see the need for an authority component, but maybe I'm missing
> something in the use cases.

Within the information centric kind of stuff we do (as research, not
ready for IETF prime time by any means) we have a need for a DNS or
DNS-like authority. We also have use-cases for no authority part at
all in that same space.

I basically just allowed the hash-string for authority since it seemed
like fun:-) That is, I have no concrete use case for that now.

S.


> 
> Peter
> 

From stpeter@stpeter.im  Thu Jul 28 17:34:10 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16B821F88A6 for ; Thu, 28 Jul 2011 17:34:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 tMkvFcVf+mTv for ; Thu, 28 Jul 2011 17:34:10 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 17E6621F88A5 for ; Thu, 28 Jul 2011 17:34:09 -0700 (PDT)
Received: from dhcp-13ac.meeting.ietf.org (unknown [130.129.19.172]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9C746410E8; Thu, 28 Jul 2011 18:35:14 -0600 (MDT)
Message-ID: <4E320000.7060909@stpeter.im>
Date: Thu, 28 Jul 2011 20:34:08 -0400
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Stephen Farrell 
References:  <4E3166F2.4020104@cs.tcd.ie> <4E31CBD3.8040200@stpeter.im> <4E31EB51.5010408@cs.tcd.ie>
In-Reply-To: <4E31EB51.5010408@cs.tcd.ie>
X-Enigmail-Version: 1.2
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Apps Discuss 
Subject: Re: [apps-discuss] proposing draft-farrell-ni as an appsarea wg item
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jul 2011 00:34:10 -0000

On 7/28/11 7:05 PM, Stephen Farrell wrote:
> 
> 
> On 28/07/11 21:51, Peter Saint-Andre wrote:
> 
>>
>> I don't see the need for an authority component, but maybe I'm missing
>> something in the use cases.
> 
> Within the information centric kind of stuff we do (as research, not
> ready for IETF prime time by any means) we have a need for a DNS or
> DNS-like authority. We also have use-cases for no authority part at
> all in that same space.
> 
> I basically just allowed the hash-string for authority since it seemed
> like fun:-) That is, I have no concrete use case for that now.

It would be good to get an idea of the use cases people have. I've heard
about various folks who might want a hash URI scheme, but I haven't
heard about specific use cases they've got.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From stephen.farrell@cs.tcd.ie  Fri Jul 29 04:45:28 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E94E21F8B75 for ; Fri, 29 Jul 2011 04:45:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Za4U652z5m0l for ; Fri, 29 Jul 2011 04:45:27 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF9221F8B79 for ; Fri, 29 Jul 2011 04:45:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5DD6B171C6C; Fri, 29 Jul 2011 12:45:22 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1311939922; bh=tjAfEqr9AlKfJX dCi0p9hjb91O3oLCwPq0H0EOJSCBQ=; b=igx9J5FlL9VOt941UM4Ve9ruLOVe5M uQw/HPl+XvGJsGuninNfseMJ10uv24S98bUh/cTg45zZ/zgFm/HAcRzQ+of1jF1f +vponawVWFUVSMDbZxUClq7wI4J3VGcXBElI6VbsL3umSJ7tnnQ75kKHyyJ10kKJ CNiecN022eApswTJuhzxDswxBq9trMFyWo4f9qyCvK7iWTXUp944WdYoJ4hRIELp rCdPTMYIEfsWuNfOD2jY9mNADg+soaHUVaCW5uPC7VwYT3FeruUW4jEI194Nrg4i xYIunBhZ0bTjOGpKYtNTDP7RkZzcG35UsvBBgFbQTGY0dnlBiEwBkJKw==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id SC9rHK3Q6-wX; Fri, 29 Jul 2011 12:45:22 +0100 (IST)
Received: from [130.129.17.184] (dhcp-11b8.meeting.ietf.org [130.129.17.184]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id CC2AD171C55; Fri, 29 Jul 2011 12:45:13 +0100 (IST)
Message-ID: <4E329D48.3010509@cs.tcd.ie>
Date: Fri, 29 Jul 2011 12:45:12 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: Peter Saint-Andre 
References:  <4E3166F2.4020104@cs.tcd.ie> <4E31CBD3.8040200@stpeter.im> <4E31EB51.5010408@cs.tcd.ie> <4E320000.7060909@stpeter.im>
In-Reply-To: <4E320000.7060909@stpeter.im>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Apps Discuss 
Subject: Re: [apps-discuss] proposing draft-farrell-ni as an appsarea wg item
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jul 2011 11:45:28 -0000

On 29/07/11 01:34, Peter Saint-Andre wrote:
> On 7/28/11 7:05 PM, Stephen Farrell wrote:
>>
>>
>> On 28/07/11 21:51, Peter Saint-Andre wrote:
>>
>>>
>>> I don't see the need for an authority component, but maybe I'm missing
>>> something in the use cases.
>>
>> Within the information centric kind of stuff we do (as research, not
>> ready for IETF prime time by any means) we have a need for a DNS or
>> DNS-like authority. We also have use-cases for no authority part at
>> all in that same space.
>>
>> I basically just allowed the hash-string for authority since it seemed
>> like fun:-) That is, I have no concrete use case for that now.
> 
> It would be good to get an idea of the use cases people have. I've heard
> about various folks who might want a hash URI scheme, but I haven't
> heard about specific use cases they've got.

Good plan. It'd be great to hear what similar requirements/use-cases
exist,

S.



> 
> Peter
> 

From tianlinyi@huawei.com  Fri Jul 29 09:48:53 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B9D21F8B01 for ; Fri, 29 Jul 2011 09:48:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.228
X-Spam-Level: 
X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396, 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 anO7bFqM+A8Z for ; Fri, 29 Jul 2011 09:48:53 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id CB95521F8AFF for ; Fri, 29 Jul 2011 09:48:52 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP3003GOTDGKR@szxga04-in.huawei.com> for apps-discuss@ietf.org; Sat, 30 Jul 2011 00:48:52 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP300MG9TDGRK@szxga04-in.huawei.com> for apps-discuss@ietf.org; Sat, 30 Jul 2011 00:48:52 +0800 (CST)
Received: from [130.129.86.170] (dhcp-56aa.meeting.ietf.org [130.129.86.170]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPA id <0LP300A08TDCLT@szxml11-in.huawei.com>; Sat, 30 Jul 2011 00:48:51 +0800 (CST)
Date: Fri, 29 Jul 2011 18:48:46 +0200
From: Linyi Tian 01 
In-reply-to: <4E329D48.3010509@cs.tcd.ie>
To: Stephen Farrell , Peter Saint-Andre 
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=GB2312
Content-transfer-encoding: quoted-printable
Thread-topic: [apps-discuss] proposing draft-farrell-ni as an appsarea wg item
User-Agent: Microsoft-MacOutlook/14.0.0.100825
Cc: Apps Discuss 
Subject: Re: [apps-discuss] proposing draft-farrell-ni as an appsarea wg item
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jul 2011 16:48:53 -0000

On 11-7-29 =CF=C2=CE=E71:45, "Stephen Farrell"  wrote:

>
>
>On 29/07/11 01:34, Peter Saint-Andre wrote:
>> On 7/28/11 7:05 PM, Stephen Farrell wrote:
>>>
>>>
>>> On 28/07/11 21:51, Peter Saint-Andre wrote:
>>>
>>>>
>>>> I don't see the need for an authority component, but maybe I'm missing
>>>> something in the use cases.
>>>
>>> Within the information centric kind of stuff we do (as research, not
>>> ready for IETF prime time by any means) we have a need for a DNS or
>>> DNS-like authority. We also have use-cases for no authority part at
>>> all in that same space.
>>>
>>> I basically just allowed the hash-string for authority since it seemed
>>> like fun:-) That is, I have no concrete use case for that now.
>>=20
>> It would be good to get an idea of the use cases people have. I've heard
>> about various folks who might want a hash URI scheme, but I haven't
>> heard about specific use cases they've got.
>
>Good plan. It'd be great to hear what similar requirements/use-cases
>exist,
>
>S.
>

Use cases are really important in this case. It is simply because we need
to understand in which environment it will be used in the correct way. If
no use cases why bother to do the technical work?

So I am looking forward to seeing use case and requirements too.

For urn based design, the URN may be too long since SHA256 will have 256
bytes hash value. Right?
urn:hash:sha256:NDc0NzgyMGVmOGQ3OGU0...

>
>
>>=20
>> Peter
>>=20



From barryleiba.mailing.lists@gmail.com  Fri Jul 29 09:54:11 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B735E8022 for ; Fri, 29 Jul 2011 09:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.053
X-Spam-Level: 
X-Spam-Status: No, score=-103.053 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 4pPc6dMBpSHC for ; Fri, 29 Jul 2011 09:54:11 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 37D9B5E8010 for ; Fri, 29 Jul 2011 09:54:11 -0700 (PDT)
Received: by gxk19 with SMTP id 19so3205208gxk.31 for ; Fri, 29 Jul 2011 09:54:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=MK1Tr5BLdFZ9L++QPDvfyTozQFWoibw48O7a2r3NgbU=; b=d2y+4myHn2Jm1BlnVmSK5uNDuFm4RlWtSJ2b7Pf/dvqoHZnMew8d1wihd0S2KOt8Sm vERWzHUNjgYz+dmTAcarjQBACgnoRweDS/MXWtk1F77NFi96HHIcIKa8zMaGB5UY0PdD vAUnRN8NfIgirymgNdh7Yu2rGDifUk80YAvbU=
MIME-Version: 1.0
Received: by 10.146.105.16 with SMTP id d16mr1298276yac.13.1311958450605; Fri, 29 Jul 2011 09:54:10 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.32.15 with HTTP; Fri, 29 Jul 2011 09:54:10 -0700 (PDT)
In-Reply-To: 
References: <4E329D48.3010509@cs.tcd.ie> 
Date: Fri, 29 Jul 2011 12:54:10 -0400
X-Google-Sender-Auth: izzhDrR8n0U2jxU-yFV9GwKLLcc
Message-ID: 
From: Barry Leiba 
To: Linyi Tian 01 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Apps Discuss 
Subject: Re: [apps-discuss] proposing draft-farrell-ni as an appsarea wg item
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jul 2011 16:54:11 -0000

> For urn based design, the URN may be too long since SHA256 will have 256
> bytes hash value. Right?
> urn:hash:sha256:NDc0NzgyMGVmOGQ3OGU0...

256 *bits*, so only 32 bytes.  Slightly longer when you base64-encode
it, but it's not too bad.

Barry

From tianlinyi@huawei.com  Fri Jul 29 10:10:17 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5E421F8B29 for ; Fri, 29 Jul 2011 10:10:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.768
X-Spam-Level: 
X-Spam-Status: No, score=-3.768 tagged_above=-999 required=5 tests=[AWL=0.381,  BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, 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 TXfxT0h25NM2 for ; Fri, 29 Jul 2011 10:10:16 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1B821F8B22 for ; Fri, 29 Jul 2011 10:10:16 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP3005MSUCX17@szxga03-in.huawei.com> for apps-discuss@ietf.org; Sat, 30 Jul 2011 01:10:09 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP3005HKUCXYQ@szxga03-in.huawei.com> for apps-discuss@ietf.org; Sat, 30 Jul 2011 01:10:09 +0800 (CST)
Received: from [130.129.86.170] (dhcp-56aa.meeting.ietf.org [130.129.86.170]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPA id <0LP300AVCUCSLT@szxml11-in.huawei.com>; Sat, 30 Jul 2011 01:10:09 +0800 (CST)
Date: Fri, 29 Jul 2011 19:10:02 +0200
From: Linyi Tian 01 
In-reply-to: 
To: Barry Leiba 
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=GB2312
Content-transfer-encoding: quoted-printable
Thread-topic: [apps-discuss] proposing draft-farrell-ni as an appsarea wg item
User-Agent: Microsoft-MacOutlook/14.0.0.100825
Cc: Apps Discuss 
Subject: Re: [apps-discuss] proposing draft-farrell-ni as an appsarea wg item
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jul 2011 17:10:17 -0000

On 11-7-29 =CF=C2=CE=E76:54, "Barry Leiba"  wrote:

>> For urn based design, the URN may be too long since SHA256 will have 256
>> bytes hash value. Right?
>> urn:hash:sha256:NDc0NzgyMGVmOGQ3OGU0...
>
>256 *bits*, so only 32 bytes.  Slightly longer when you base64-encode
>it, but it's not too bad.

Yes, I meant for 256 bits:) Thanks for the correction.

>
>Barry



From vesely@tana.it  Sat Jul 30 03:39:58 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D1921F8745 for ; Sat, 30 Jul 2011 03:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.699
X-Spam-Level: 
X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[AWL=0.020,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 eWMSiTkmthQN for ; Sat, 30 Jul 2011 03:39:58 -0700 (PDT)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 08F6221F86C0 for ; Sat, 30 Jul 2011 03:39:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1312022397; bh=czQ4J16kJpoKHcWNSdkKDXUR8L95k6Wp4BIDcq8PFYw=; l=1925; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=QQn+GGkct00pTNhalo/ndb8QGU9QHMDx5EaQmqACQRQRG1BtR7ly8H6oO3pM93Nmd FDgASxDq9cCpF+XsT6oNpKib/TT5BzI370yDJVNX/0fDe8cDaazBaBJwuoW5v2Ee8t gPdEZTZ+UDWPI36FhhibyjmG7t0QLcHxsWesGYhA=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 30 Jul 2011 12:39:57 +0200 id 00000000005DC039.000000004E33DF7D.0000168C
Message-ID: <4E33DF7D.6040109@tana.it>
Date: Sat, 30 Jul 2011 12:39:57 +0200
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20110727052622.18893.75906.idtracker@ietfa.amsl.com>	<4E3013C8.7060203@tana.it>		<01O45CD1RC5O00RCTX@mauve.mrochek.com> <4E31B648.2020802@tana.it> <01O46PHOZA6E00RCTX@mauve.mrochek.com>
In-Reply-To: <01O46PHOZA6E00RCTX@mauve.mrochek.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Jul 2011 10:39:58 -0000

On 29/Jul/11 00:41, Ned Freed wrote:
>>> In fact the best way to handle this would be to put the restriction into the
>>> DSN and MDN specifications that build on the multipart/report framework, and
>>> say something like, "Uses of the multipart/report container format MAY restrict
>>> the contexts in which a particular report type can appear."
> 
>> Does that mean top-level implies "active"?
> 
> You know, I was thinking about that as well. It's clear than active DSNs and
> MDNs have to be top-level but that doesn't mean the converse is necessarily
> true.

Plus: it would allow an ABNF-like definition of "active",
minus: inactive messages would then have to be wrapped.

> Operationally at least, I think the answer is something along the lines of,
> "it's active if it correlates with a message you sent, otherwise not". 

+1, it clarifies what reporting is all about, linking the active
status with the destination address (and is quite complaisant to data
protection principles in this respect.)  Let me try to reword the
first paragraph of Section 3:

   The multipart/report MIME media type is a general "family" or
   "container" type for electronic mail reports of any kind.  A mail
   report presents an account of events occurred to another mail
   message, which is called the original message, returned message, or
   reported message.  A report message, i.e. a message carrying a mail
   report, is considered "active" when it is destined to an entity
   who actively contributed to the sending of the original message,
   including authors, relays, gateways, delivery agents, and link
   operators.  Mail processing programs can benefit of using a single
   media type for all kinds of reports, and detect active reports
   correlated with sent messages.

> I'm not sure if this warrants mention in the spec or not.

Nor I.  It may ease the wording of the top-level requirement, though.

jm2c

From msk@cloudmark.com  Sat Jul 30 21:22:25 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C1011E8074 for ; Sat, 30 Jul 2011 21:22:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.744
X-Spam-Level: 
X-Spam-Status: No, score=-103.744 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 72AnXU39tq+r for ; Sat, 30 Jul 2011 21:22:24 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id A65BD11E8073 for ; Sat, 30 Jul 2011 21:22:21 -0700 (PDT)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 30 Jul 2011 21:22:23 -0700
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" 
Date: Sat, 30 Jul 2011 21:22:22 -0700
Thread-Topic: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
Thread-Index: AcxOpQyeoGT2k8fIS4KZrM7OgtCBrQAk+1mw
Message-ID: 
References: <20110727052622.18893.75906.idtracker@ietfa.amsl.com> <4E3013C8.7060203@tana.it>  <01O45CD1RC5O00RCTX@mauve.mrochek.com>	<4E31B648.2020802@tana.it> <01O46PHOZA6E00RCTX@mauve.mrochek.com> <4E33DF7D.6040109@tana.it>
In-Reply-To: <4E33DF7D.6040109@tana.it>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Jul 2011 04:22:25 -0000

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org=
] On Behalf Of Alessandro Vesely
> Sent: Saturday, July 30, 2011 3:40 AM
> To: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-=
01.txt
>=20
> >> Does that mean top-level implies "active"?
> >
> > You know, I was thinking about that as well. It's clear than active DSN=
s and
> > MDNs have to be top-level but that doesn't mean the converse is necessa=
rily
> > true.
>=20
> Plus: it would allow an ABNF-like definition of "active",
> minus: inactive messages would then have to be wrapped.
> [...]

I think this is better stated in the DSN and MDN updates we're now consider=
ing, and maybe in ARF if we decide to update it.  It's not clear that all u=
ses of multipart/report forever and ever will need to make this distinction=
, and we're talking about removing the top-level restriction from it entire=
ly now anyway.

It sounds like the path forward is to remove the restriction from multipart=
/report altogether, which is safe because it's already stated on MDN and DS=
N as well.  This would satisfy MARF's needs.  We can then look at clarifyin=
g DSN and MDN if/when we feel doing that would be useful.


From evnikita2@gmail.com  Sat Jul 30 21:38:54 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD88621F861A; Sat, 30 Jul 2011 21:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.51
X-Spam-Level: 
X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.089,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 DRes7EH+kYIR; Sat, 30 Jul 2011 21:38:54 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id A9A1021F85B9; Sat, 30 Jul 2011 21:38:50 -0700 (PDT)
Received: by fxe6 with SMTP id 6so4041893fxe.31 for ; Sat, 30 Jul 2011 21:38:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=nSZQgMPHe58jhKShor9BGF+/srrXnMvgb8+Mk3YCKSI=; b=UB2tp81g+rT6ZiA5Oy94RPcmZbFnTADpo6KnJUZ7L7xP7O4RZ6w/csGUwvNHrGJMOR EuvJpCTttK+LLjb025yWFXnRiaDVaGsM8fTxBE2/2VCNZi1uyJdyFHqS1xiaWy/pFBp3 Hnhit5CiXCfQB8GEd2FutPTl9HpHDu9WKBOOU=
Received: by 10.223.76.17 with SMTP id a17mr4334247fak.32.1312087132413; Sat, 30 Jul 2011 21:38:52 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id w11sm2054748faj.14.2011.07.30.21.38.50 (version=SSLv3 cipher=OTHER); Sat, 30 Jul 2011 21:38:51 -0700 (PDT)
Message-ID: <4E34DC83.30504@gmail.com>
Date: Sun, 31 Jul 2011 07:39:31 +0300
From: Mykyta Yevstifeyev 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Apps-discuss list ,  "uri-review@ietf.org" , URI , "ftpext@ietf.org" ,  register@uri.arpa, "public-iri@w3.org" 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] FWD: I-D Action: draft-yevstifeyev-ftp-uri-scheme-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Apps-discuss list 
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Jul 2011 04:38:54 -0000

Hello,

Sorry for cross-posting to 6 addresses :-); please send all your 
comments to apps-discuss@ietf.org.  Note to public-iri subscribers: 
please have a look at Section 6.  Note to register@uri.arpa subscribers: 
please comment Appendix A of the document.  (The link to HTML version: 
http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme.)

Thanks,
Mykyta Yevstifeyev

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : The'ftp' URI Scheme
> 	Author(s)       : Mykyta Yevstifeyev
> 	Filename        : draft-yevstifeyev-ftp-uri-scheme-05.txt
> 	Pages           : 29
> 	Date            : 2011-07-24
>
>     This document specifies the'ftp' Uniform Resource Identifier (URI)
>     scheme, which is used to refer to resources accessible via File
>     Transfer Protocol (FTP).  It updates RFC 959 and RFC 1738.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-yevstifeyev-ftp-uri-scheme-05.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-yevstifeyev-ftp-uri-scheme-05.txt


From evnikita2@gmail.com  Sun Jul 31 02:58:44 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2F321F87C5; Sun, 31 Jul 2011 02:58:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.548
X-Spam-Level: 
X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.051,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 fVQfTp4Nd7pI; Sun, 31 Jul 2011 02:58:43 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3380E21F87BD; Sun, 31 Jul 2011 02:58:43 -0700 (PDT)
Received: by fxe6 with SMTP id 6so4192090fxe.31 for ; Sun, 31 Jul 2011 02:58:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=L3KBKDYqbgh++YjmziDNDA0Z6aFTB4oQCV+hyiylaMI=; b=WyuwlGqmyrT6kxpUPNOcwCw0LNNs5ojL0qQi4SOI9wZqCMYog+Atp/HsgVTUkjp9Fs 7r8ziRPlJCSoOVcCuq4DIKlIsAHZARB373q5QmDBKbbp7+cPwx61IloTlw1TOtlfwv8b VxztHdLyU+tFNtaK8iPtzeLp7AAycYfJ7fxY0=
Received: by 10.223.14.24 with SMTP id e24mr4645514faa.15.1312106325443; Sun, 31 Jul 2011 02:58:45 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id w11sm2176317faj.14.2011.07.31.02.58.43 (version=SSLv3 cipher=OTHER); Sun, 31 Jul 2011 02:58:44 -0700 (PDT)
Message-ID: <4E35277B.5010708@gmail.com>
Date: Sun, 31 Jul 2011 12:59:23 +0300
From: Mykyta Yevstifeyev 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: John Cowan 
References: <4E34DC83.30504@gmail.com> <20110731083853.GB30568@mercury.ccil.org>
In-Reply-To: <20110731083853.GB30568@mercury.ccil.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: register@uri.arpa, Apps-discuss list , "ftpext@ietf.org" , URI , "public-iri@w3.org" , "uri-review@ietf.org" 
Subject: Re: [apps-discuss] FWD: I-D Action: draft-yevstifeyev-ftp-uri-scheme-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Jul 2011 09:58:44 -0000

31.07.2011 11:38, John Cowan wrote:
> Mykyta Yevstifeyev scripsit:
>
>> Sorry for cross-posting to 6 addresses :-); please send
>> all your comments to apps-discuss@ietf.org.  Note to
>> public-iri subscribers: please have a look at Section
>> 6.  Note to register@uri.arpa subscribers: please comment
>> Appendix A of the document.  (The link to HTML version:
>> http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme.)
> It's inappropriate to say that the client SHALL request a password
> from the user if none is supplied and the server demands one (and
> likewise for accounts).  The client must be free to fail under such
> circumstances, as it may be a robot or otherwise not have a user
> available.  Likewise with SHALL notify the user, etc.  These should be
> changed to MAYs or SHOULDs.

I think such occurrences of SHALL will be replaced with SHOULD or 
non-normative "should".  (I don't think 'ftp' URIs will be used with 
applications that have no UI; so I don't see reasons to assume they will 
be used in such way.  But, anyway, your comment regarding SHALL is 
reasonable).

>
> Editorial notes:  Lots of people don't know what "ibidem" means, or even
> its standard abbreviation "ibid".  I suggest changing the first instance
> to "in RFC 959", the second instance to "below", and the third instance
> to "in the".

I'll make the following corrections: 1st instance - "in RFC 959" (as 
currently), 2nd one - "in the same document", 3rd one (I guess this is 
regarding ASCII) - "in RFC 959".

>
> Note error "internalization" for "internationalization", "internalized"
> for "internationalized", etc.

Fixed now.

>
> Note persistent typo "exmaple.com" for "example.com".

ACK.  Thanks for reading the document.  Mykyta

>


From cowan@ccil.org  Sun Jul 31 01:38:53 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639DB21F8802; Sun, 31 Jul 2011 01:38:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.487
X-Spam-Level: 
X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113,  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 8aJiAou+g8wd; Sun, 31 Jul 2011 01:38:52 -0700 (PDT)
Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3B09221F87C3; Sun, 31 Jul 2011 01:38:52 -0700 (PDT)
Received: from cowan by earth.ccil.org with local (Exim 4.69) (envelope-from ) id 1QnRXx-0006My-5K; Sun, 31 Jul 2011 04:38:53 -0400
Date: Sun, 31 Jul 2011 04:38:53 -0400
From: John Cowan 
To: Apps-discuss list 
Message-ID: <20110731083853.GB30568@mercury.ccil.org>
References: <4E34DC83.30504@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4E34DC83.30504@gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: John Cowan 
X-Mailman-Approved-At: Sun, 31 Jul 2011 08:34:01 -0700
Cc: register@uri.arpa, "public-iri@w3.org" , "uri-review@ietf.org" , URI , "ftpext@ietf.org" 
Subject: Re: [apps-discuss] FWD: I-D Action: draft-yevstifeyev-ftp-uri-scheme-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Jul 2011 08:38:53 -0000

Mykyta Yevstifeyev scripsit:

> Sorry for cross-posting to 6 addresses :-); please send
> all your comments to apps-discuss@ietf.org.  Note to
> public-iri subscribers: please have a look at Section
> 6.  Note to register@uri.arpa subscribers: please comment
> Appendix A of the document.  (The link to HTML version:
> http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme.)

It's inappropriate to say that the client SHALL request a password
from the user if none is supplied and the server demands one (and
likewise for accounts).  The client must be free to fail under such
circumstances, as it may be a robot or otherwise not have a user
available.  Likewise with SHALL notify the user, etc.  These should be
changed to MAYs or SHOULDs.

Editorial notes:  Lots of people don't know what "ibidem" means, or even
its standard abbreviation "ibid".  I suggest changing the first instance
to "in RFC 959", the second instance to "below", and the third instance
to "in the ".

Note error "internalization" for "internationalization", "internalized"
for "internationalized", etc.

Note persistent typo "exmaple.com" for "example.com".

-- 
Do what you will,                       John Cowan
   this Life's a Fiction                cowan@ccil.org
And is made up of                       http://www.ccil.org/~cowan
   Contradiction.  --William Blake

From john-ietf@jck.com  Sun Jul 31 12:42:19 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4629821F88A0; Sun, 31 Jul 2011 12:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.634
X-Spam-Level: 
X-Spam-Status: No, score=-102.634 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, 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 EYoD5IQxMqbM; Sun, 31 Jul 2011 12:42:18 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE9921F889D; Sun, 31 Jul 2011 12:42:18 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Qnbu1-0002yH-OR; Sun, 31 Jul 2011 15:42:22 -0400
Date: Sun, 31 Jul 2011 15:42:20 -0400
From: John C Klensin 
To: John Cowan , Apps-discuss list 
Message-ID: 
In-Reply-To: <20110731083853.GB30568@mercury.ccil.org>
References: <4E34DC83.30504@gmail.com> <20110731083853.GB30568@mercury.ccil.org>
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: ftpext@ietf.org
Subject: Re: [apps-discuss] [ftpext] FWD: I-D Action:	draft-yevstifeyev-ftp-uri-scheme-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Jul 2011 19:42:19 -0000

--On Sunday, July 31, 2011 04:38 -0400 John Cowan
 wrote:

> Mykyta Yevstifeyev scripsit:
> 
>> Sorry for cross-posting to 6 addresses :-); please send
>> all your comments to apps-discuss@ietf.org.  Note to
>> public-iri subscribers: please have a look at Section
>> 6.  Note to register@uri.arpa subscribers: please comment
>> Appendix A of the document.  (The link to HTML version:
>> http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme.)
 
> It's inappropriate to say that the client SHALL request a
> password from the user if none is supplied and the server
> demands one (and likewise for accounts).  The client must be
> free to fail under such circumstances, as it may be a robot or
> otherwise not have a user available.  Likewise with SHALL
> notify the user, etc.  These should be changed to MAYs or
> SHOULDs.

In principle, this sort of thing could be addressed in the spec
by adopting the model described in RFC 5321 for SMTP.  That spec
basically says that, independent of any other rules, the the
client may abort the session at any time for any reason
whatsoever.  Then it defines what "abort" means.  If one wanted
to state the above that way, it would be, e.g., "if no password
is supplied and the server demands one, then the client MUST
either find a password and send it and send a QUIT to abort the
session".

However, this identifies two other issues:

(1) FTP really is designed as an interactive protocol.  If it
had been designed for single-command-line or URI
implementations, several things might be different.   The IETF
has rarely taken on UI designs directly and has a history of
doing poorly when it does try.  If the client hasn't
spontaneously supplied a password but the server demands one,
there are lots of ways (depending on the client and its
operational environment) to obtain something password-like and
respond to the request.  Constraining those choices to "ask the
user" when the client does not decide to just abort doesn't
reflect either reality or reasonable design.  Hence "must
respond and send it" above, with the implication that the client
MAY do anything it considers reasonable to satisfy that request.

(2) More broadly, this is one of many special cases of why I
continue to object to doing this as a URI without a lot of
careful consideration.

It seems to me that there are two logical possibilities for an
FTP URI:

(a) Do something absolutely minimal that satisfies a large
number of cases.  This is probably anonymous login only, stream
and image transfer only, probably PASV only these days, maybe
even a restriction to an ASCII command stream.  If an email
address is needed for login, a provision for picking that up
from an environment variable rather than having it incorporated
into the URI, would be important.

(b) Fully-reflect the protocol and all of its standardized
options.  This would get fairly complex for a URI because one
would not only want to supply a lot of information but might
want to supply it conditionally.

Between those two points, there isn't a lot other than slippery
slope.

   john




From svartman95@gmail.com  Sun Jul 31 17:14:35 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1BF21F873A for ; Sun, 31 Jul 2011 17:14:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.653
X-Spam-Level: **
X-Spam-Status: No, score=2.653 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FUZZY_CREDIT=1.238, MANGLED_MILFS=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 XSaaDAbroXHO for ; Sun, 31 Jul 2011 17:14:35 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D3B7921F857D for ; Sun, 31 Jul 2011 17:14:34 -0700 (PDT)
Received: by wyj26 with SMTP id 26so964750wyj.31 for ; Sun, 31 Jul 2011 17:14:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Xwck3KtHA3I8q/rP+npFOV+RLXehrff1gbF5RHFguxs=; b=DZWvBH9n6RY+gr+m8Vj3zg65x2LWMWNtS4MpWlTWZYa9KnRUIzbs99NEZ6+9cidNzu LKBJCWE9+8lVYdtoQY2N7F3v58KBtKvsSOYBNB6G1whE1m58v5uSoZxYom5tqxcapTpp QeTpsNa1NhqyssaFNnNxPBO3OxqWHBSVlJ/tc=
Received: by 10.216.162.211 with SMTP id y61mr122495wek.19.1312157678984; Sun, 31 Jul 2011 17:14:38 -0700 (PDT)
Received: from [192.168.1.101] (dsl-ls-104-143.du.vortex.is [213.190.104.143]) by mx.google.com with ESMTPS id fp3sm3715800wbb.64.2011.07.31.17.14.37 (version=SSLv3 cipher=OTHER); Sun, 31 Jul 2011 17:14:38 -0700 (PDT)
Message-ID: <4E35EA34.3000102@gmail.com>
Date: Sun, 31 Jul 2011 23:50:12 +0000
From: Bjartur Thorlacius 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10
MIME-Version: 1.0
To: emax@emax.is, IETF Apps Discuss 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: [apps-discuss] =?iso-8859-1?q?WiFi/802=2E11_nettenging_til_Glj=FA?= =?iso-8859-1?q?fur=E1r?=
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2011 00:14:35 -0000

  Gleilega Verslunarmannahelgi!
Vi tlum a dveljast  sumrarhsi okkar a Gljfur  Borgarbygg, 
nstu jr vi Svignaskar, nsta mnu, en vantar netsamband - og  
helst tlvupstsamband. Vi urfum ekki endilega stuga tengingu.
  Okkur skilst a ar getum vi tengst neti ykkar rlaust um IEEE 
802.11 gegn kreditkortanmeri og heimild. Vi hfum hinsvegar ekki 
kreditkort undir hndum, og urfum v a borga me millifrslu. Geti 
i sent okkur verskr og greisluupplsingar, hvort heldur reikning 
til a leggja inn ea sent reikning  lok mnaar?

g bj  Svarfhli  Svnadal  Hvalfjararsveit  runum 2006-2010 og 
var   gtum viskiptum vi ykkur.

Kveja,

Einar rn Thorlacius fyrrv.sveitarstjri
Grundarstg, Rvk
Kennitala; 180658-6889