From barryleiba@gmail.com Mon Aug 1 06:33: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 0376511E8089 for ; Mon, 1 Aug 2011 06:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.061 X-Spam-Level: X-Spam-Status: No, score=-103.061 tagged_above=-999 required=5 tests=[AWL=-0.084, 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 jrj56hPBmM2M for ; Mon, 1 Aug 2011 06:33:10 -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 E6E7B11E809B for ; Mon, 1 Aug 2011 06:33:09 -0700 (PDT) Received: by gyd5 with SMTP id 5so4113590gyd.31 for ; Mon, 01 Aug 2011 06:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=MIsLnzKyIWiqzrBkm02gNfvtCmSQZjgpaUbOMO8RP6Y=; b=aLAy1KZiVHWrkqErzfDYXg/4ObI4+HrkcTbpiV6nf2Wde6jtJ2+F4vc5sf+0nmC/Dk SwVCByVl4LKuvRbBL0Tb0jwo1BnhzlASypjJAjwybtkVgwyqDmceM8ZjxicKiQZzxXZU s3Mh8stKcahtbAnqnwJ7QgJaSjoLsp4tdBq1U= MIME-Version: 1.0 Received: by 10.236.197.66 with SMTP id s42mr2205415yhn.213.1312205595806; Mon, 01 Aug 2011 06:33:15 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.207.132 with HTTP; Mon, 1 Aug 2011 06:33:15 -0700 (PDT) Date: Mon, 1 Aug 2011 09:33:15 -0400 X-Google-Sender-Auth: enB7eQhm7Yv1vfZ3duheqUAEIz0 Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] AppsAWG status, and communicating with the chairs 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 13:33:11 -0000 We'll soon have minutes posted for the IETF 81 App Area Working Group session (and App Area general session), and when they're up we'll stick a pointer here. Meanwhile, we reckon that there are seven documents that this working group will soon take on. So, confirming this from the meeting, there was no objection to handling the following documents in the working group: The 'about' URI scheme http://tools.ietf.org/html/draft-holsten-about-uri-scheme A JSON Media Type for Describing the Structure and Meaning of JSON Documents http://tools.ietf.org/html/draft-zyp-json-schema Best Current Practices for Handling of Malformed Messages [This has already been approved as a working group item:] http://tools.ietf.org/html/draft-ietf-appsawg-malformed-mail Updating multipart/report http://tools.ietf.org/id/draft-kucherawy-rfc3462bis Update to MIME regarding Charset Parameter Handling in Textual Media Types http://tools.ietf.org/html/draft-melnikov-mime-default-charset Use of the "X-" Prefix in Application Protocols http://tools.ietf.org/html/draft-saintandre-xdash Media Type Specifications and Registration Procedures http://tools.ietf.org/html/draft-freed-media-type-regs ------------------- Please post any objections to this list here. Assuming none, we'll start work on them as soon as we can. The chairs need to decide which of us is shepherding which document, and we'll present them to the working group two or three at a time for concentrated discussion. Discussion of all of them is welcome at any time, though, even if we're not concentrating on it just then. The chairs are subscribed to the mailing list, so there's no need to copy the chairs on anything posted to the list. But if you want to communicate with the chairs off list, please include all of us by using the tools alias, . If you just pick one or two of us to address, the one(s) who aren't included miss that part of the conversation. Even though I might be the only one active in a conversation about a document I'm shepherding, it's useful to have the other chairs kept up on the situation. Similarly, you can address the Area Directors with , and that also avoids errors or omissions when you need to communicate with them off list. We'll try to get the work divvied up and start active work on the documents above within the next week or two. Barry, appsawg chair From derhoermi@gmx.net Mon Aug 1 06:48: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 B69B511E809D for ; Mon, 1 Aug 2011 06:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=-0.946, 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 jb3ThURuEQdm for ; Mon, 1 Aug 2011 06:48:01 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9B53411E8075 for ; Mon, 1 Aug 2011 06:48:00 -0700 (PDT) Received: (qmail invoked by alias); 01 Aug 2011 13:48:01 -0000 Received: from dslb-094-223-181-014.pools.arcor-ip.net (EHLO HIVE) [94.223.181.14] by mail.gmx.net (mp054) with SMTP; 01 Aug 2011 15:48:01 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+tOOw5ZBCt2PlYL1NujikuJ+PTd0qtodMeuIxFiG 5Nef+j3fxyt2Jk From: Bjoern Hoehrmann To: Barry Leiba Date: Mon, 01 Aug 2011 15:48:08 +0200 Message-ID: <6ebd37h4okaio9cbs7m160e6q1i2tgqdph@hive.bjoern.hoehrmann.de> References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: Apps Discuss Subject: Re: [apps-discuss] AppsAWG status, and communicating with the chairs 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 13:48:02 -0000 * Barry Leiba wrote: >Use of the "X-" Prefix in Application Protocols > http://tools.ietf.org/html/draft-saintandre-xdash Why should this be a standalone document instead of having the ideas there in or some other document that explains issues around extensibility within a broader context than how a "X-" convention can be problematic? -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From barryleiba@gmail.com Mon Aug 1 06:50: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 5A85311E8075 for ; Mon, 1 Aug 2011 06:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.06 X-Spam-Level: X-Spam-Status: No, score=-103.06 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 9B4dRns+jvBj for ; Mon, 1 Aug 2011 06:50:35 -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 D2D5411E809B for ; Mon, 1 Aug 2011 06:50:23 -0700 (PDT) Received: by ywm21 with SMTP id 21so839111ywm.31 for ; Mon, 01 Aug 2011 06:50: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:content-type :content-transfer-encoding; bh=EbxMC16HachshXyJ6J8basj4U0It6L/6BneXsWi/3t8=; b=Rji+2cOheG4R7NHFrLhHL+bk9myD+/NVLpwGtvaCWq2fHEXZP+7H4cha6tR/NJASMH fmOsoTx6CDbmIhsxmyCamOSkSzi3nwcAIO+XmnhgDRpOjfftnaaUiRdb/6sxkALk7JPs wo2hh/hze2DNMDwOqIpkMjYnAjMs89DUIaO44= MIME-Version: 1.0 Received: by 10.236.201.193 with SMTP id b41mr2361673yho.481.1312206629267; Mon, 01 Aug 2011 06:50:29 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.207.132 with HTTP; Mon, 1 Aug 2011 06:50:29 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Aug 2011 09:50:29 -0400 X-Google-Sender-Auth: yNmJaSscj56ysGR_nxCzDr2xZ7Q Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] AppsAWG status, and communicating with the chairs 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 13:50:36 -0000 > Please post any objections to this list here. =A0Assuming none, we'll > start work on them as soon as we can. =A0The chairs need to decide which > of us is shepherding which document, and we'll present them to the > working group two or three at a time for concentrated discussion. > Discussion of all of them is welcome at any time, though, even if > we're not concentrating on it just then. Oh, and I should have said: Post objections to this discussion thread (leave the subject line intact). But for discussions of a particular document, please start a new thread, with the document name in the subject line. Thanks. Barry From vesely@tana.it Mon Aug 1 07:23: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 C202C21F8E68 for ; Mon, 1 Aug 2011 07:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[AWL=0.019, 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 EOLAF1Ceed0h for ; Mon, 1 Aug 2011 07:23:43 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C5F0821F8E53 for ; Mon, 1 Aug 2011 07:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1312208621; bh=d7N1mvS6ql8nCoQ7gY3CE2z5ylwWb4DF+j8whUUHdKQ=; l=911; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=K2OeNsJFTGRC14Y2sDJWe4W4DV5oPAvOx+SxVJRTGzRGWxmDRI295L7KMLPnF6DAq q7FAhNcXb2cE2jwzVkqMNha0Zw/vpxnHLGU0aDI+UFaoRw8tgW29jQ40BYzkweZkLt yDph8SWsb5PSsjgdF8373OT6UCrUA/sY4SgXhSIM= 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; Mon, 01 Aug 2011 16:23:41 +0200 id 00000000005DC033.000000004E36B6ED.0000626A Message-ID: <4E36B6EC.4000900@tana.it> Date: Mon, 01 Aug 2011 16:23:40 +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> <4E33DF7D.6040109@tana.it> In-Reply-To: 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: Mon, 01 Aug 2011 14:23:44 -0000 On 31/Jul/11 06:22, Murray S. Kucherawy wrote: > 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 DSN as well. Yep, also on ARF. > This would satisfy MARF's needs. Possibly, I don't know what MIME container is being planned. But to remove the restriction on wrapped multipart/report entities is not the same as to permit wrapped reports: one won't be able to say that a wrapped entity /is/ a report, if a report has to be at top-level by definition. (Thus, this path doesn't also solve the futile question of how to forward a DSN, say.) For an unrelated nit, please remove the phrases like Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports As we have two more report types already, they look unsightly. jm2c From mnot@mnot.net Mon Aug 1 08:36: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 E24E421F8B42 for ; Mon, 1 Aug 2011 08:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.562 X-Spam-Level: X-Spam-Status: No, score=-105.562 tagged_above=-999 required=5 tests=[AWL=-2.962, 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 xsXoXHIolt3E for ; Mon, 1 Aug 2011 08:36:38 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 17F3921F8B3C for ; Mon, 1 Aug 2011 08:36:38 -0700 (PDT) Received: from [10.10.1.109] (unknown [67.111.52.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C58CD22E257; Mon, 1 Aug 2011 11:36:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <6ebd37h4okaio9cbs7m160e6q1i2tgqdph@hive.bjoern.hoehrmann.de> Date: Mon, 1 Aug 2011 08:36:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6ebd37h4okaio9cbs7m160e6q1i2tgqdph@hive.bjoern.hoehrmann.de> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1084) Cc: Barry Leiba , Apps Discuss Subject: Re: [apps-discuss] AppsAWG status, and communicating with the chairs 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 15:36:39 -0000 On 01/08/2011, at 6:48 AM, Bjoern Hoehrmann wrote: > * Barry Leiba wrote: >> Use of the "X-" Prefix in Application Protocols >> http://tools.ietf.org/html/draft-saintandre-xdash >=20 > Why should this be a standalone document instead of having the ideas > there in or > some other document that explains issues around extensibility within > a broader context than how a "X-" convention can be problematic? Because the people who need to read the document would be even less = likely to do so if it were hidden there. Cheers, -- Mark Nottingham http://www.mnot.net/ From evnikita2@gmail.com Mon Aug 1 10:07: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 8F1CF11E80FF for ; Mon, 1 Aug 2011 10:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 LXm073GdR-He for ; Mon, 1 Aug 2011 10:07:05 -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 B36B011E8077 for ; Mon, 1 Aug 2011 10:07:04 -0700 (PDT) Received: by fxe6 with SMTP id 6so5521435fxe.31 for ; Mon, 01 Aug 2011 10:07:10 -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=RxHPbld5zmCVIgR1hHUKBieQ78+0F9DAaDTfoLF/ybE=; b=u3mLm/l4xd+/28WSRdKN/mp8Ac9f1NRLquTaeCMfERT/W8JPvwr3t0GnRJO8f/Nclu 7keSf61VdMdGN/pw/R4zh2XzSU3hhnFM6nN+DRwK+j+oDwoOEXXTqax2V1cvDjPQ+GnO Hu9qQh/oC+odj1r6srBnp4Xr7qmbLUbXcEMVs= Received: by 10.223.32.19 with SMTP id a19mr6670691fad.22.1312218430868; Mon, 01 Aug 2011 10:07:10 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id d5sm544922fak.40.2011.08.01.10.07.09 (version=SSLv3 cipher=OTHER); Mon, 01 Aug 2011 10:07:09 -0700 (PDT) Message-ID: <4E36DD64.2040602@gmail.com> Date: Mon, 01 Aug 2011 20:07:48 +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 , draft-holsten-about-uri-scheme@tools.ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] 'about' URI scheme draft and AppsAWG 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 17:07:05 -0000 Dear all, Today AppsAWG chairs announced that based on discussions on IETF meeting the EG is going to adopt draft-holsten-about-uri-scheme as WG item. Previously I volunteered to become an additional author, and both current authors, AD and doc. shepherd agreed on this. I suppose the authors didn't change their mind, and WG won't object to this. Now I'd like to present my view on what basic changes should be made prior to publishing the draft as AppsAWG document. First, the semantics should be amended as follows. I propose to mention that (1) broadly speaking, the meaning if the particular 'about' URI is denoted by the token in its , but (2) any application which handles the URI is free to resolve it to any resource; ie. handle it solely (well, almost solely; see bullet 3) internally. (3) A special range of 'about' URI tokens is defined to be "special-purpose", (3a) they are to be registered with IANA and (3b) must be used only and only for the defined reason. The corresponding IANA registry (see below) should be lightweight enough, as the "special-purpose token" should be used as the last resort only. (I understand that many won't agree with me, but) the Specification Required may be sufficient for such purpose. FCFS isn't appropriate because the MUST requirement is a very string regulation and some formal review is necessary; the discussion mailing list is also an option, but Spec. Required alone should also be OK (see justification below). Next, (4) the registration of the token should have clear regulations regarding the use of the corresponding 'about' URI, eg. "The 'about' URI with "legacy-compat" token MUST only be used in HTML ". For the purpose of the documentation clarity, the Specification Required policy is an ideal way, but for the purpose of being lightweight Expert Review is more appropriate. I'll let the WG to decide, but please consider that Specification Required is what I *personally* prefer. (5) the categorization regarding resolvable/unresolvable should be dropped. I suppose (2) fully covers handling of those URIs which can be defined to be "unresolvable" (I mean the situation when an app resolves eg. to the web page saying this URI may not be resolved elsewhere). (6) The categorization regarding reserved/unreserved should be dropped in favor of (3). (7) Encoding considerations are defined to be application-specific; (7a) 'about' IRIs should be disallowed. (8) The requirement for mandatory support of "about:blank" is unreasonable and should be dropped. I suppose AppsAWG participants will express their opinion with respect to these issues prior to publishing AppsAWG draft. Thanks, Mykyta Yevstifeyev From barryleiba.mailing.lists@gmail.com Mon Aug 1 12:27: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 72DF011E813F for ; Mon, 1 Aug 2011 12:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.059 X-Spam-Level: X-Spam-Status: No, score=-103.059 tagged_above=-999 required=5 tests=[AWL=-0.082, 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 khBi00nlA6rZ for ; Mon, 1 Aug 2011 12:27:05 -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 EBBBE11E8137 for ; Mon, 1 Aug 2011 12:27:04 -0700 (PDT) Received: by gyd5 with SMTP id 5so4368106gyd.31 for ; Mon, 01 Aug 2011 12:27:11 -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=UYicfHpcPvH40TWnJl/lGhfdsJKxG5DW/aWSmhX5/nU=; b=vrISMWXXnwiWNbDWu9cJpByLee5yO4Nuj8Lt4sj0A8fqmNHe3mp++oFOA14BAgNIMt SGWAGHsuRj5v6Wv9jyhB2DrLgHS+MihJoV1ohq4aoTT96nJmTFqZxixhZNYyjc1DaOSe qbFmWrMw9ptWhMuMbLfRpHwN2V4rQPSQ/m7k8= MIME-Version: 1.0 Received: by 10.236.144.200 with SMTP id n48mr1836956yhj.348.1312226831589; Mon, 01 Aug 2011 12:27:11 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.38.7 with HTTP; Mon, 1 Aug 2011 12:27:11 -0700 (PDT) In-Reply-To: <4E36DD64.2040602@gmail.com> References: <4E36DD64.2040602@gmail.com> Date: Mon, 1 Aug 2011 15:27:11 -0400 X-Google-Sender-Auth: TYbBerIul5AyP1pLqgSTaMJUp1M Message-ID: From: Barry Leiba To: Mykyta Yevstifeyev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-holsten-about-uri-scheme@tools.ietf.org, Apps-discuss list Subject: Re: [apps-discuss] 'about' URI scheme draft and AppsAWG 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 19:27:05 -0000 > I volunteered to become an additional author, and both current authors, A= D > and doc. shepherd agreed on this. =A0I suppose the authors didn't change = their > mind, and WG won't object to this. The editorship of the document will be decided upon by the chairs, as always -- most likely by the chair who winds up being the document shepherd. Assume nothing until we get there. Meanwhile, Mykyta, thanks for starting the discussion. Carry on, all. Barry, as chair From barryleiba@gmail.com Tue Aug 2 14:11: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 400B821F850C for ; Tue, 2 Aug 2011 14:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.055 X-Spam-Level: X-Spam-Status: No, score=-103.055 tagged_above=-999 required=5 tests=[AWL=-0.078, 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 vn-IL4nuJy7j for ; Tue, 2 Aug 2011 14:11:10 -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 AAD0E21F84F5 for ; Tue, 2 Aug 2011 14:11:10 -0700 (PDT) Received: by ywm21 with SMTP id 21so127902ywm.31 for ; Tue, 02 Aug 2011 14:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=7ODxlqQIlEK5/E5y6pRGlF5vsxzGGfdPzktgO7XP3fo=; b=iF2DuJDcmK/UWB2Jm6jt/pgsXVL9OajbjOXX7MMlnmfY5pDqolqVlktAg93eU9mqVq RKN5zLRHAjA86oziZ0LekEvhE3OqTmofqn4VsTBsLNHHVABOipIN8OKSJbBsZIGm8Xj7 xYmI4hbH0C+A7N7E97I7icmeTgLEO6mvEtmVM= MIME-Version: 1.0 Received: by 10.236.72.167 with SMTP id t27mr2648513yhd.79.1312319479424; Tue, 02 Aug 2011 14:11:19 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.207.132 with HTTP; Tue, 2 Aug 2011 14:11:19 -0700 (PDT) Date: Tue, 2 Aug 2011 17:11:19 -0400 X-Google-Sender-Auth: YIXil9woEL0RIiMYZFMwvr2ZXmU Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] AppsAWG and Apps Area General Session minutes from IETF 81 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, 02 Aug 2011 21:11:11 -0000 Minutes have been uploaded here: http://www.ietf.org/proceedings/81/minutes/appsawg.txt Please post corrections here. Barry, appsawg chair From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Thu Aug 4 00:20: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 2918621F8B6B for ; Thu, 4 Aug 2011 00:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.02 X-Spam-Level: X-Spam-Status: No, score=-103.02 tagged_above=-999 required=5 tests=[AWL=0.079, 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 yVnD4qvl0RLi for ; Thu, 4 Aug 2011 00:20:07 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4824521F8B66 for ; Thu, 4 Aug 2011 00:20:07 -0700 (PDT) Received: by pzk33 with SMTP id 33so4258795pzk.18 for ; Thu, 04 Aug 2011 00:20:21 -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=N0mdVWmXCbo5ks3kLQRiHLefP/Y8xjvcjFdRucKhU6g=; b=oV1V9cXm7sAqTvd+uCjsAcwU4gXmVrdlDreujCIvYU6OiWSEblbULBzI9Qh4+YUJ0b TzPyVjIWID+ScSsplMkRtyjU0hXT+4RFOKDAbZc6fXG8xO6MJupbuieswKn5CUaoOp45 rCNTYGD9lsR7brz7MslBbNhYCU4466gu1MBBo= Received: by 10.142.55.2 with SMTP id d2mr448355wfa.276.1312442421176; Thu, 04 Aug 2011 00:20:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.157.2 with HTTP; Thu, 4 Aug 2011 00:20:01 -0700 (PDT) In-Reply-To: <4E34DC83.30504@gmail.com> References: <4E34DC83.30504@gmail.com> From: Frank Ellermann Date: Thu, 4 Aug 2011 09:20:01 +0200 Message-ID: To: Apps-discuss list Content-Type: text/plain; charset=ISO-8859-1 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: Thu, 04 Aug 2011 07:20:08 -0000 On 31 July 2011 06:39, Mykyta Yevstifeyev wrote: > http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme At some point in time the IETF servers should offer these URLs on the IETF tools servers, a nice diff with only two clicks is just too good to ignore it. Some editorial nits because you are anyway working on version 06. Please add articles, e.g., s/FTP spec/the FTP spec/, and s/- pre-Standard Track RFC/- a pre-Standard Track RFC/ (intro). s/retain on Standard Track/retain it on standards track/ and s/if RFC 1738 is moved/when RFC 1738 will be moved/ ("ibidem", as flagged by John Cowan :-) My "DEnglish" is very suspicious, therefore I won't list more, and because John Klensin prefers to fix editorial nits in AUTH48 (or at least not on a mailing list). IMHO you can skip RFC 3305 in the FTP URI history, it is not more relevant after STD 66 was published. You could also get rid of the RFC 5538 zoo with all its brothers and sisters in the intro, or limit it to the first standards track RFC 4248 by Paul Hoffman in this series. In "Bruce Lily style" only the used BCP 14 keywords are noted in what you have as section 2.1, that's of course a matter of taste, keep it "as is" if you like it. However, OPTIONAL in ABNF is not something you have to talk about, because ABNF as in STD 68 has syntactical means to indicate optional elements, e.g., ABNF [] vs. ABNF . The discussion of ASCII in RFC 0959 is rather complex, saying that it is in essence RFC 0020 could be misleading. Don't get into protocol details for an URI scheme, let RFC 0959 and its successor(s) handle the protocol. There is no such thing as a " part" in RFC 3986, please use STD 66 terminology where possible, proposal: D ftp-hier-part = "//" [ user-pass "@" ] host-port [ ftp-path ] I ftp-hier-part = "//" authority [ ftp-path ] I authority = [ userinfo "@" ] host [ ":" port ] I userinfo = user [ ":" pass ] D user-pass = user [ ":" pass ] D user = 1*usp-char D pass = *usp-char D usp-char = unreserved / pct-encoded / sub-delims I user = *( unreserved / pct-encoded / sub-delims ) I pass = *( unreserved / pct-encoded / sub-delims / ":") D host-port = host [ ":" port ] I host = I port = D = delete I = insert Rationale: Your ABNF requires a non-empty , I can't say if that is as it should be for STD 9 (FTP), but for STD 66 it is not required. Add 1 to if you really want it, and explain all differences from RFC 3986 somewhere in the prose. Your ABNF forbids a colon in the , and that can't be a good idea without an explanation. Is an empty allowed? At the moment your ABNF does allow this, and I'd assume that FTP URIs ftp://user@host/etc are different from ftp://user:@host/etc Talking about "randomly generated" or "non-existing" addresses is guaranteed to infuriate the anti-spam community starting with me, the "non-existence" MUST be certain, e.g., suggest TLD .invalid for this purpose (.localhost or equivalent domain literals are no good idea). Typecode "u" means "Net-Unicode" (in essence UTF-8 with details explained in RFC 5198), not generally "Unicode" (which could be UTF-7, BOCU-1, my UTF-4, or worse). The typecode "d" business could need more details, e.g., why is ftp://foo/bar/ for directories vs. ftp://foo/bar for files not good enough, is "d" perhaps never really needed? Please strike the paragraph "Since a number of clients" in the new fragment section, all details how clients might ignore any fragments in URIs have nothing to do with the FTP URI scheme. IMO URIs must not contain any non-ASCII in , that would be IRIs. A is specified in 3986, an in 3987 or its successor. If we can agree on that it's not necessary to talk about it for FTP URIs, because they follow the same rules for and like all other URIs and IRIs. There is an in RFC 3987, and your theory that the cannot be internationalized appears to be wrong, or is that something specified in 959bis? Simply don't talk about it, let RFC 3987 handle any , and let 959bis tackle the consequences. -Frank From evnikita2@gmail.com Thu Aug 4 02:18: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 DAACB21F8B31 for ; Thu, 4 Aug 2011 02:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 YF804vZQaDpD for ; Thu, 4 Aug 2011 02:18:14 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 26D9A21F8B24 for ; Thu, 4 Aug 2011 02:18:13 -0700 (PDT) Received: by ewy19 with SMTP id 19so852134ewy.31 for ; Thu, 04 Aug 2011 02:18: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:content-transfer-encoding; bh=i1faIJ1zNWdMIm37/GEEo2PnsA0hP8i3fWH6lBfcefs=; b=uxsx9HLVSr3tgQiOkyz+RVcVJH0vsx1XMdGI6kGteFhI5tOxR3mHsUkq2smwVz5KR3 WqgbSmExS88baaC1lESzRW4CwjQt6MPNv8sox0Qyk8pg45XhaYRYAjA7c1cjv/coUzee bI/gD78Tje/KCfL3FsITFXeFPjCUKoZXfHG5A= Received: by 10.204.131.149 with SMTP id x21mr169225bks.307.1312449507577; Thu, 04 Aug 2011 02:18:27 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id p24sm475166bkw.41.2011.08.04.02.18.25 (version=SSLv3 cipher=OTHER); Thu, 04 Aug 2011 02:18:26 -0700 (PDT) Message-ID: <4E3A6408.30603@gmail.com> Date: Thu, 04 Aug 2011 12:19: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: Barry Leiba References: <4E36DD64.2040602@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-holsten-about-uri-scheme@tools.ietf.org, Apps-discuss list Subject: Re: [apps-discuss] 'about' URI scheme draft and AppsAWG 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, 04 Aug 2011 09:18:15 -0000 Please see https://docs.google.com/leaf?id=0B1y9iULaT86CZTQ0ZmFlNDctNGQ3NS00YWU4LWIzYmYtMzNmNDU0MDJhYjdl&hl=en_US for the concept of what I think should be the WG item. Mykyta 01.08.2011 22:27, Barry Leiba wrote: >> I volunteered to become an additional author, and both current authors, AD >> and doc. shepherd agreed on this. I suppose the authors didn't change their >> mind, and WG won't object to this. > The editorship of the document will be decided upon by the chairs, as > always -- most likely by the chair who winds up being the document > shepherd. Assume nothing until we get there. > > Meanwhile, Mykyta, thanks for starting the discussion. Carry on, all. > > Barry, as chair > From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Thu Aug 4 05:01: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 37FED21F8B80 for ; Thu, 4 Aug 2011 05:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.024 X-Spam-Level: X-Spam-Status: No, score=-93.024 tagged_above=-999 required=5 tests=[AWL=-9.925, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 G9BtB3s2sRPM for ; Thu, 4 Aug 2011 05:01:22 -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 30AC821F8B6D for ; Thu, 4 Aug 2011 05:01:22 -0700 (PDT) Received: by gxk19 with SMTP id 19so1141612gxk.31 for ; Thu, 04 Aug 2011 05:01:36 -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=W93wb2TiK+ortxxAYZ6SuvK+gqHQx1qqjbp0C7q7s/0=; b=ahQ6fegAmLUAvZCsxLFxmm8CWP3p834NfyKbdqflFjQU3oVQcu0TNhjsBAol0VhVRF SFjPtC2i1ThqXfxWao6ESYuPAS7i8iqDN1356by14rCbRo0hnIj42iywJe+C2PcwLHZz htwhW+sYd5G06xTecvz8pDarw4KFVH2Iw26b0= Received: by 10.142.4.11 with SMTP id 11mr730775wfd.390.1312459296107; Thu, 04 Aug 2011 05:01:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.157.2 with HTTP; Thu, 4 Aug 2011 05:01:16 -0700 (PDT) In-Reply-To: <4E3A52BF.2000302@gmail.com> References: <4E34DC83.30504@gmail.com> <4E3A52BF.2000302@gmail.com> From: Frank Ellermann Date: Thu, 4 Aug 2011 14:01:16 +0200 Message-ID: To: Mykyta Yevstifeyev 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-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: Thu, 04 Aug 2011 12:01:23 -0000 On 4 August 2011 10:05, Mykyta Yevstifeyev wrote: [intro] > This is copying similar statement from your RFC 5538 :-) If you like it I won't insist on minimizing this part ;-) [terms] >> OPTIONAL in ABNF is not something you have to talk >> about, because ABNF as in STD 68 has syntactical means >> to indicate optional elements, e.g., ABNF [] vs. >> ABNF . > That's clear that they are used "to clarify syntactical > requirements". Mentioning this in the text is for the > sake of clearance. Maybe it is only me, but when I see an "explanation" of OPTIONAL in ABNF I start to wonder what is different from the BCP or even the STD, and why it is different. If it turns out to be not different at all I'm happy again, but would not say that it is now "clearer" - YMMV, obviously. [ASCII] > I may remove reference to RFC 20; but in context of RFC > 3986 reference to ANSI standard is necessary. Sure, the RFC 20 reference is fine, but the statement... | definition of "ASCII" found in RFC 959 [RFC0959] may be | considered to be equivalent. ...is misleading, RFC 20 does not cover all those historic ASCII encodings mentioned in RFC 959. RFC 5198 Appendix A and B are a summary for "network ASCII", and that might be "considered to be equivalent" (to the RFC 959 ASCII ideas). [syntax] > Here I should note that there are some reasons for not > doing as you propose. First. doesn't have > clear syntactical requirement for "user:pass" format; it > also allows empty userinfo. Yes, I only suggested to keep the name as in RFC 3886, not the syntax, you clearly need to split it in user [":" pass] And I mainly do not want you to replace host [":" port] by a new " part" without a compelling reason. If you want "non-empty" for it is okay, you are still free to use RFC 3986 names in the syntax: authority =3D [ userinfo "@" ] host [ ":" port ] userinfo =3D user [ ":" pass ] user =3D 1*( unreserved / pct-encoded / sub-delims ) pass =3D *( unreserved / pct-encoded / sub-delims / ":") Translations to IRIs are simpler if the stuff matching any can be found as , here: , , and . > Thus, if is present, it must contain username > at least. Okay, reflected above. And that derivation from RFC 3986 needs no extra prose, I have no idea why RFC 3986 permitted an empty . The authors of full internet standards use water to brew coffee like everybody else. > The ":" is disallowed on order not to make confusion with > ":" as delimiter. In this case what username and password > in the URI ? When you say it's the first colon it will be the first colon. When you say it's the one and only colon it would break any existing RFC 1738 passwords containing a colon. I don't see a good reason for the second choice. >> Is an empty =A0allowed? =A0At the moment your ABNF does >> allow this, and I'd assume that FTP URIs >> ftp://user@host/etc are different from ftp://user:@host/etc > No, in both of them there is no pass; they'll be handled in > the same way. If you want to be non-empty add the missing "1" in your syntax: 1*usp-char instead of *usp-char Ditto in my variant: pass =3D 1*( unreserved / pct-encoded / sub-delims / ":") [abuse] >> "randomly generated" or "non-existing" addresses is >> guaranteed to infuriate the anti-spam community starting >> with me, the "non-existence" MUST be certain, e.g., suggest >> TLD .invalid for this purpose [...] > This is solely up to the client to decide. =A0Everything we can > do is "SHOULD use randomly-generated or non-existence", which > I am not planning to remove. "Randomly generated" addresses are net abuse, because it ends up as spam in the inbox of some "random address owner" victim, or causes traffic to the MX of "random domains". Addresses in TLD .invalid are guaranteed to be invalid, as the name says. TLD .example and its IDNA variants would be already less clear. > I don't see strong reasons to mandate use of .invalid domain > for this purpose. If mustard is too strong pick SHOULD. Above all do not mention "randomly generated" if all you actually want is "non-existing". [typecode "d"] > This issue is quite fishy from RFC 1738/1630. =A0Suppose there > is a directory named "file.txt", and we want it's listing. > The URI will lead the > client to RETR file.txt in 95% cases, if not more, overlooking > step (4a), which says "CWD each segment until there is a slash > or non-slash-ended segment", and then lamenting that there is > no such file like file.txt. Okay, if it helps slightly broken clients to get what they want. An interesting case is a file system permitting a subdirectory "file.txt" and a file "file.txt" in the same directory - this is fortunately not the case in any file system I care about. [host vs. ihost] > I see no reason to disallow UCS chars, even pct-encoded, in > URIs. =A0One isn't necessarily obliged to make the 'ftp' URI > with IDN an 'ftp' IRI. As far as I'm concerned percent-encoded legacy charsets in any URI are fine as long as client and host agree on what they are trying to do, and do not claim that it is an "IRI". But the is the and should match RFC 3986, because that is already bad enough with its construct. And an is an as specified in 3987 and IDNA, we'd need no specifications on "the road to nowhere". > what is 959bis; I've never heard of such draft Nor me, I used it as nickname for the "ftpext2" set of drafts. -Frank From alexey.melnikov@isode.com Fri Aug 5 05:29: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 8ED0821F8B79 for ; Fri, 5 Aug 2011 05:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 JGS8ZmKWarQv for ; Fri, 5 Aug 2011 05:29:44 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 03FA921F8AFD for ; Fri, 5 Aug 2011 05:29:44 -0700 (PDT) Received: from [188.29.136.119] (188.29.136.119.threembb.co.uk [188.29.136.119]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 5 Aug 2011 13:29:28 +0100 Message-ID: <4E3BE22D.9030709@isode.com> Date: Fri, 05 Aug 2011 08:29:33 -0400 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: Lisa Dusseault References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, ifette+ietf@google.com, Peter Saint-Andre , Gabriel Montenegro , Pete Resnick Subject: Re: [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: Fri, 05 Aug 2011 12:29:48 -0000 Hi Lisa, Thank for your review. Lisa Dusseault wrote: > 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. > > 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. Right. Several people asked about that. > 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. I don't think they are used in the document, but I am wondering if they are used in the W3C's API draft. Ian? > 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. My understanding is that cookies are truly optional. I will update the draft to clarify that. > 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? Good catch. I've added missing text to section 7.1.7 > 4. Dropping with extreme prejudice > > >From 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 agree with you. Here is the latest proposed text: 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 MAY drop the TCP connection. If the invalid data received after a successful WebSocket handshake, the server SHOULD send a Close frame with an appropriate status code before proceeding to Close the WebSocket Connection. Use of a Close frame with an appropriate status code can help in diagnosing the problem. If the invalid data is sent during the WebSocket handshake the server SHOULD return an appropriate HTTP status code. Do you think this addresses your concern? I didn't specify any particular HTTP error code, because several might be applicable. > 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". I think I've convinced Ian that you are right :-). We will work on reducing the number of error code ranges. Best Regards, Alexey From msk@cloudmark.com Mon Aug 8 11:22: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 4631321F8B04 for ; Mon, 8 Aug 2011 11:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.11 X-Spam-Level: X-Spam-Status: No, score=-103.11 tagged_above=-999 required=5 tests=[AWL=-0.512, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eI5q+ItC0gzF for ; Mon, 8 Aug 2011 11:22: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 269D521F86C1 for ; Mon, 8 Aug 2011 11:22:22 -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, 8 Aug 2011 11:22:48 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Mon, 8 Aug 2011 11:22:47 -0700 Thread-Topic: Updating the status of SPF Thread-Index: AcxV+CxT9WxP2wTLTNWpQ3LXOor+nw== 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_F5833273385BB34F99288B3648C4F06F13512DF606EXCHC2corpclo_" MIME-Version: 1.0 Subject: [apps-discuss] Updating the status of SPF 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, 08 Aug 2011 18:22:23 -0000 --_000_F5833273385BB34F99288B3648C4F06F13512DF606EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, apps folk. A participant in another WG has expressed interest in republishing SPF (RFC= 4408) on the standards track. This clearly and historically falls into the= APPS realm. The work is probably in need of a WG home, and with YAM leani= ng toward spinning down, this is the next best place to ask. I have some d= oubts it would be accepted as sponsored individual submission nor is it app= ropriate for the ISE, but I could be wrong. I doubt this warrants its own working group, but I could be wrong about tha= t too. So far as I'm aware the only changes needed from that document are = the creation of an extensions registry, some minor editorial stuff, and som= e kind of resolution of the IESG Statement that was added to it to address = the collision with Sender ID (RFC4406/7). I socialized this with a few of you outside of the meeting in Quebec City a= nd there wasn't any resistance to the idea; in fact one person who's typica= lly not a fan of SPF even said it's something we should really do because i= t's still in widespread use. Comments? -MSK --_000_F5833273385BB34F99288B3648C4F06F13512DF606EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, apps folk.

 

A participant in another WG has expressed interest in republishing SPF (RF= C4408) on the standards track.  This clearly and historically falls in= to the APPS realm.  The work is probably in need of a WG home, and wit= h YAM leaning toward spinning down, this is the next best place to ask.&nbs= p; I have some doubts it would be accepted as sponsored individual submissi= on nor is it appropriate for the ISE, but I could be wrong.

<= p class=3DMsoNormal> 

I doubt this = warrants its own working group, but I could be wrong about that too.  = So far as I’m aware the only changes needed from that document are th= e creation of an extensions registry, some minor editorial stuff, and some = kind of resolution of the IESG Statement that was added to it to address th= e collision with Sender ID (RFC4406/7).

=  

I socialized this with a few of y= ou outside of the meeting in Quebec City and there wasn’t any resista= nce to the idea; in fact one person who’s typically not a fan of SPF = even said it’s something we should really do because it’s still= in widespread use.

 

Comments?

&nb= sp;

-MSK

<= o:p> 

= --_000_F5833273385BB34F99288B3648C4F06F13512DF606EXCHC2corpclo_-- From barryleiba.mailing.lists@gmail.com Mon Aug 8 13:02: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 364E121F8C0C for ; Mon, 8 Aug 2011 13:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.048 X-Spam-Level: X-Spam-Status: No, score=-103.048 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENkAUn3nv7oA for ; Mon, 8 Aug 2011 13:02:22 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A329821F8BE7 for ; Mon, 8 Aug 2011 13:02:22 -0700 (PDT) Received: by vws12 with SMTP id 12so3974691vws.31 for ; Mon, 08 Aug 2011 13:02:49 -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=bNmFnxXNNH69qUcG0uBxxJa3yWOXYqqG7Qf0vUPp9HA=; b=LKlvSUEvaIMZC8xVRgvF+iWr+rH1Gl5UnM0CeKcFDZXslziZWjIDKpGxhGLZuLJosd +RUWOJZ8hlnxf3Aam3fs8tENOuICwoG6366pFXb9HEqmCmBH5tQicezFWCJxzTvjM+cs 4Vtr4p2MP2z06ljJhTPAMiqBkuZFZDplkpMqw= MIME-Version: 1.0 Received: by 10.52.176.97 with SMTP id ch1mr6093730vdc.297.1312833769129; Mon, 08 Aug 2011 13:02:49 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.52.185.42 with HTTP; Mon, 8 Aug 2011 13:02:49 -0700 (PDT) In-Reply-To: References: Date: Mon, 8 Aug 2011 16:02:49 -0400 X-Google-Sender-Auth: p0PcygRKCik8JNCebFkPbeTkMfM Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Updating the status of SPF 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, 08 Aug 2011 20:02:23 -0000 > A participant in another WG has expressed interest in republishing SPF > (RFC4408) on the standards track.=A0 This clearly and historically falls = into > the APPS realm.=A0 The work is probably in need of a WG home, and with YA= M > leaning toward spinning down, this is the next best place to ask.=A0 I ha= ve > some doubts it would be accepted as sponsored individual submission nor i= s > it appropriate for the ISE, but I could be wrong. It absolutely can not be done in the Independent Stream -- that stream can't do Standards Tack documents. > I doubt this warrants its own working group, but I could be wrong about t= hat > too.=A0 So far as I=92m aware the only changes needed from that document = are the > creation of an extensions registry, some minor editorial stuff, and some > kind of resolution of the IESG Statement that was added to it to address = the > collision with Sender ID (RFC4406/7). I believe this absolutely needs its own WG, and the proponents should work on a draft charter. The charter should be clear that it's aiming to move SPF to Standards Track, that it is specifically NOT addressing Sender-ID, and that any merging of Sender-ID into SPF is out of scope. The charter should have explanatory text about the experiment having been done, the results being clear, and deployment being widespread. The WG wants, it should say, to document the experimental results and shift SPF onto Standards Track. Hatless Barry From jdfalk-lists@cybernothing.org Mon Aug 8 17:39: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 1ED8621F8B6F for ; Mon, 8 Aug 2011 17:39:39 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onvyzeRAl2S4 for ; Mon, 8 Aug 2011 17:39:38 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1A821F8B67 for ; Mon, 8 Aug 2011 17:39:38 -0700 (PDT) Received: from [192.168.11.32] (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 p790e2LR017938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 8 Aug 2011 17:40:04 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p790e2LR017938 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=fudge; t=1312850405; bh=y9H6zlKapjUpVXaChMv6tnLCiSM8xp6vZW56kgE82 cU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=SY6S1fM4CGma m0h6RM0zS9uss/l9OE9bnGz/54lKeZGt75hODuZagg4a7tWUkR5XdtAA86XhZCA0Uq4 CJAq3wlGH0PUnU+nGpXtCeAMnxohBzdzip924TRNgy6bDj2VRs6M2ezYTW56KXwonL5 EUlt2p9HlyERXkOjXB1FYJlBc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: Date: Mon, 8 Aug 2011 17:40:02 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: "apps-discuss@ietf.org Discuss" X-Mailer: Apple Mail (2.1084) Subject: Re: [apps-discuss] Updating the status of SPF 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, 09 Aug 2011 00:39:39 -0000 On Aug 8, 2011, at 1:02 PM, Barry Leiba wrote: > I believe this absolutely needs its own WG, and the proponents should > work on a draft charter. The charter should be clear that it's aiming > to move SPF to Standards Track, that it is specifically NOT addressing > Sender-ID, and that any merging of Sender-ID into SPF is out of scope. > The charter should have explanatory text about the experiment having > been done, the results being clear, and deployment being widespread. > The WG wants, it should say, to document the experimental results and > shift SPF onto Standards Track. +1, particularly regarding documenting the results. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From ned.freed@mrochek.com Mon Aug 8 18:28: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 C789D21F8757 for ; Mon, 8 Aug 2011 18:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZeMijLLF2IA for ; Mon, 8 Aug 2011 18:28:28 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 352ED21F8752 for ; Mon, 8 Aug 2011 18:28:28 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4M8BZ61XC00RKOY@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 8 Aug 2011 18:27:54 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4CJSMR6GG00VHKR@mauve.mrochek.com>; Mon, 8 Aug 2011 18:27:48 -0700 (PDT) Message-id: <01O4M8BVFLTI00VHKR@mauve.mrochek.com> Date: Mon, 08 Aug 2011 18:27:26 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 08 Aug 2011 17:40:02 -0700" MIME-version: 1.0 Content-type: TEXT/PLAIN References: To: "J.D. Falk" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1312853194; bh=Bvv2JClRS/Mia7T9ZKHpeqmsSWEGLpaYsam2PCZkhDc=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=Z+EanoVN3k5he3dbNJ1TqVIby4o4LvY899m/7i/TsIguAsjMXf4WRWio+97ZMkl/S MX/AjZlgvED8Gleqh6GqZ9etw4oG3QWDrisatE+LMatqzma7WyGLDwHlfI01k7KVTw izKVFcjmJTaUQghGPFjov5W67V4navcnJ1XzOJNE= Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Updating the status of SPF 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, 09 Aug 2011 01:28:28 -0000 > On Aug 8, 2011, at 1:02 PM, Barry Leiba wrote: > > I believe this absolutely needs its own WG, and the proponents should > > work on a draft charter. The charter should be clear that it's aiming > > to move SPF to Standards Track, that it is specifically NOT addressing > > Sender-ID, and that any merging of Sender-ID into SPF is out of scope. > > The charter should have explanatory text about the experiment having > > been done, the results being clear, and deployment being widespread. > > The WG wants, it should say, to document the experimental results and > > shift SPF onto Standards Track. > +1, particularly regarding documenting the results. +1. If this needs doing, this is how to do it. Ned From luyan@zte.com.cn Tue Aug 9 01:11: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 36C5321F8A30 for ; Tue, 9 Aug 2011 01:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.086 X-Spam-Level: X-Spam-Status: No, score=-98.086 tagged_above=-999 required=5 tests=[AWL=-1.651, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_72=0.6, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhW6Rq2rf+8u for ; Tue, 9 Aug 2011 01:11:12 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1F67D21F876A for ; Tue, 9 Aug 2011 01:11:10 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 152361193944097; Tue, 9 Aug 2011 16:08:54 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 78343.3634574820; Tue, 9 Aug 2011 16:11:27 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p798BK17038353; Tue, 9 Aug 2011 16:11:20 +0800 (GMT-8) (envelope-from luyan@zte.com.cn) In-Reply-To: <9031.1311673448.731712@puncture> To: Dave Cridland MIME-Version: 1.0 X-KeepSent: CA86C160:3B9DB75F-482578E7:00127A9E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: luyan@zte.com.cn Date: Tue, 9 Aug 2011 16:11:20 +0800 X-MIMETrack: S/MIME Sign by Notes Client on LuYan029354/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-08-09 16:13:50, Serialize by Notes Client on LuYan029354/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-08-09 16:13:50, Serialize complete at 2011-08-09 16:13:50, S/MIME Sign failed at 2011-08-09 16:13:50: ???????, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-08-09 16:11:22, Serialize complete at 2011-08-09 16:11:22 Content-Type: multipart/alternative; boundary="=_alternative 002D3689482578E7_=" X-MAIL: mse01.zte.com.cn p798BK17038353 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, 09 Aug 2011 08:11:13 -0000 This is a multipart message in MIME format. --=_alternative 002D3689482578E7_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGF2ZSBDcmlkbGFuZCA8ZGF2ZUBjcmlkbGFuZC5uZXQ+IA0KMjAxMS0wNy0yNiAxNzo0NA0KDQrK 1bz+yMsNCiJsdXlhbkB6dGUuY29tLmNuIiA8bHV5YW5AenRlLmNvbS5jbj4sIEdlbmVyYWwgZGlz Y3Vzc2lvbiBvZiANCmFwcGxpY2F0aW9uLWxheWVyIHByb3RvY29scyA8YXBwcy1kaXNjdXNzQGll dGYub3JnPiwgImRpbmcueGluQHp0ZS5jb20uY24iIA0KPGRpbmcueGluQHp0ZS5jb20uY24+LCAi amlheHc5QGNoaW5hdW5pY29tLmNuIiA8amlheHc5QGNoaW5hdW5pY29tLmNuPiwgDQoiU0hJSCwg SkVSUlkgXChBVFRTSVwpIiA8SlM5MDUzQGF0dC5jb20+DQqzrcvNDQoNCtb3zOINClJlOiBSZTog UmU6IFthcHBzLWRpc2N1c3NdIEV4dGVudGlvbnMgb2YgSU1BUDQNCg0KDQoNCg0KDQoNCk9uIFR1 ZSBKdWwgMjYgMDk6MzY6MzUgMjAxMSwgbHV5YW5AenRlLmNvbS5jbiB3cm90ZToNCj4gPiBPbiBG cmkgSnVsIDIyIDA5OjEyOjM1IDIwMTEsIGx1eWFuQHp0ZS5jb20uY24gd3JvdGU6DQo+ID4gPiBb WWFuIExVXSBUaGUgaW50ZW50aW9uIG9mIHRoaXMgZHJhZnQgaXMgdG8gYXNzb2NpYXRlIG11bHRp cGxlDQo+ID4gPiBpZGVudGl0aWVzDQo+ID4gPiBiZWxvbmdpbmcgdG8gb25lIHVzZXIuIFRodXMs IGFmdGVyIGxvZ2dpbmcgaW4sIHRoZSB1c2VyIG1heSANCj4gY2hvb3NlDQo+ID4gPiBvbmUgb2YN Cj4gPiA+IHRoZXNlIGFzc29jaWF0ZWQgaWRlbnRpdGllcywgdW5kZXIgZWFjaCBvZiB3aGljaCB0 aGVyZSBjYW4gYmUgYW4NCj4gPiA+IElOQk9YLCBhDQo+ID4gPiBTRU5UQk9YIGFuZCBvdGhlciBm b2xkZXJzLCBhcyBzaG93biBpbiB0aGUgZm9sbG93aW5nIGZpZ3VyZS4NCj4gPg0KPiA+IE9LLiBJ biB0aGUgU0FTTCBtb2RlbCwgYW4gYXV0aGVudGljYXRpb24gaWRlbnRpZmllciBjYW4gaGF2ZSAN Cj4gYWNjZXNzDQo+ID4gdG8gbWFueSBhdXRob3JpemF0aW9uIGlkZW50aWZpZXJzIGFscmVhZHk7 IHNvIG5vIGNoYW5nZSBpcyBuZWVkZWQNCj4gPiBoZXJlLg0KPiA+DQo+IA0KPiBbWWFuIExVXSBB cyB3ZSBrbm93LCBpbXBsaWNpdCByZWdpc3RyYXRpb24gaGFzIGFscmVhZHkgYmVlbiANCj4gc3Vw cG9ydGVkIGluDQo+IDNHUFAgSU1TLiBIb3dldmVyLHNvIGZhciwgSSBoYXZlbqGvdCBmb3VuZCBh bnkgUkZDcyB3aGVyZSBhbg0KPiBhdXRoZW50aWNhdGlvbiBpZGVudGlmaWVyIGlzIGFsbG93ZWQg dG8gYmUgYm91bmQgd2l0aCBtdWx0aXBsZSANCj4gaWRlbnRpZmllcnMNCj4gLiBDb3VsZCB5b3Ug dGVsbCBtZSB0aGUgc3BlY2lmaWMgZG9jdW1lbnRzPw0KPiANCj4gDQpBbGwgbW9kZXJuIFNBU0wg bWVjaGFuaXNtcyBhbGxvdyB1c2VycyB0byBzdXBwbHkgYW4gb3B0aW9uYWwgDQphdXRob3JpemF0 aW9uIGlkZW50aWZpZXIuDQoNCj4gPiBNb3N0bHkgYmVjYXVzZSB5b3UncmUgbm90IC0geW91J3Jl IGFzc29jaWF0aW5nIGF1dGhvcml6YXRpb24NCj4gPiBpZGVudGl0aWVzIHNlcXVlbnRpYWxseSwg cmF0aGVyIHRoYW4gY29uY3VycmVudGx5Lg0KPiA+DQo+ID4gWW91IGNvdWxkIGJ1aWxkIG9uIG5h bWVzcGFjZXMsIGluY2lkZW50YWxseSwgdG8gYWNoaWV2ZSBtdWNoIHRoZSANCj4gc2FtZQ0KPiA+ IGdvYWwsIGJ5IHNpbXBseSBkZWZpbmluZyBhIHN0YW5kYXJkIG1ldGhvZCBmb3IgbG9jYXRpbmcg b3RoZXINCj4gPiBhdXRob3JpemF0aW9uIGlkZW50aWZpZXJzJyBJTkJPWGVzLg0KPiA+DQo+ID4g QnV0IGFsbG93aW5nIGEgdXNlciB0byBzd2l0Y2ggYXV0aG9yaXphdGlvbiBpZGVudGlmaWVyIG1p ZC1mbG93IA0KPiB3aWxsDQo+ID4gYWxtb3N0IGNlcnRhaW5seSBpbnRyb2R1Y2Ugc29tZSBjb21w bGV4IGVkZ2UtY2FzZXMgd2l0aGluIA0KPiBzZWN1cml0eSAtDQo+ID4gSSd2ZSBhIHN0cm9uZyBm ZWVsaW5nIHRoYXQgdGhpcyBvcGVucyB1cCBwb3NzaWJpbGl0aWVzIGZvciBUT0NUT1UNCj4gPiBl cnJvcnMuDQo+ID4NCj4gDQo+IFtZYW4gTFVdIEFjdHVhbGx5LCB0aGUgaWRlYSBpbiB0aGUgcHJv cG9zZWQgZHJhZnQgaXMgcXVpdGUgc2ltaWxhciANCj4gd2l0aA0KPiBpbXBsaWNpdCByZWdpc3Ry YXRpb24gaW4gM0dQUCwgd2hlcmUgaXQgaGFzIGFscmVhZHkgYmVlbiANCj4gc3RhbmRhcmRpemVk LiBTbywNCj4gd2UgdGhpbmsgaXQgaXMgYmV0dGVyIGZvciB0aGUgSUVURiB0byBzdXBwb3J0IHRo ZSBzYW1lIG1lY2hhbmlzbS4NCj4gDQo+IA0KSnVzdCBiZWNhdXNlIHNvbWVib2R5IGVsc2UgaGFz IGRlY2lkZWQgdG8gc3RhbmRhcmRpemUgaXQgZG9lcyBub3QgDQptZWFuIGl0J3MgYSBnb29kIGlk ZWEuDQoNCkFzIEkgc2F5LCBJIHRoaW5rIHRoYXQgYWxsb3dpbmcgdGhlIGF1dGhvcml6YXRpb24g aWRlbnRpZmllciBib3VuZCB0byANCmEgc2Vzc2lvbiB0byBjaGFuZ2Ugd2lsbCBpbnRyb2R1Y2Ug c2VjdXJpdHkgaXNzdWVzLiBJTUFQLCBhbmQgDQp0aGVyZWZvcmUgSU1BUCBzZXJ2ZXJzLCBhcmUg YnVpbHQgYXJvdW5kIHRoZSBub3Rpb24gdGhhdCB0aGUgDQphdXRob3JpemF0aW9uIGlkZW50aWZp ZXIgaXMgYm91bmQgYXQgYXV0aGVudGljYXRpb24gdGltZSBhbmQgDQp0aGVyZWFmdGVyIGludmFy aWFudC4NCg0KQnJlYWtpbmcgdGhhdCBhc3N1bXB0aW9uIGlzIHRyaXZpYWwgaW4gdGhlb3J5LCBi dXQgaW4gcHJhY3Rpc2Ugd2lsbCANCmhhdmUgcXVpdGUgc2V2ZXIgaW1wYWN0IG9uIHNlcnZlciBj b2RlYmFzZXMsIGFzIHdlbGwgYXMgaW1wYWN0IHRvIA0KdmFyaW91cyBleHRlbnNpb25zLiBGb3Ig ZXhhbXBsZSwgaXQncyBub3QgYXQgYWxsIGNsZWFyIHdoYXQgTk9USUZZIA0Kc2hvdWxkIGRvIHdo ZW4gZmFjZWQgd2l0aCBhbiBhdXRob3JpemF0aW9uIGlkZW50aWZpZXIgY2hhbmdlLg0KDQpTbyBh dCBtaW5pbXVtLCB0aGlzIGRyYWZ0IHdvdWxkIG5lZWQgdG8gYWRkcmVzcyBldmVyeSBleHRhbnQg DQpleHRlbnNpb25zIGZvciBJTUFQIGFuZCBlbnN1cmUgdGhhdCBpdCBkb2VzIG5vdCBpbnRyb2R1 Y2Ugc2VjdXJpdHkgDQppc3N1ZXMgLSBidXQgSSBkb24ndCB0aGluayB0aGlzIGlzIHN1ZmZpY2ll bnQgdG8gZWxpbWluYXRlIHRoZSByYXRoZXIgDQptb3JlIHdvcnJ5aW5nIGlzc3VlIHRoYXQgYXV0 aG9yaXphdGlvbiBpZGVudGlmaWVycyBhcmUgY29uc2lkZXJlZCBhbiANCmludmFyaWFudCBvZiBh IHNlc3Npb24gd2l0aGluIHRoZSBJTUFQIHNlcnZlciBjb2RlYmFzZXMuDQoNCkhvd2V2ZXIsIHRo aXMgaXNuJ3QgYSBwcm9ibGVtLCBhcyB3aGF0IHlvdSBjYW4gZG8gaXMgc3RhbmRhcmRpemUgdGhl IA0KTkFNRVNQQUNFIHVzYWdlIGFuZCBzZXJ2ZXIgbGF5b3V0IHN1Y2ggdGhhdCBpdCdzIHNpbXBs ZSBmb3IgY2xpZW50cyANCnRvIGRpc2NvdmVyIHRoZSBJTkJPWCBhbmQgcGVyc29uYWwgbWFpbGJv eGVzIG9mIG90aGVyIGF1dGhvcml6YXRpb24gDQppZGVudGlmaWVycy4NCg0KW1lhbiBMVV1Tb3Jy eSBmb3IgdGhlIGxhdGUgcmVwbHkgZm9yIHdlIGp1c3QgY2FtZSBiYWNrIGZyb20gYW4gT01BLUVW Vk0gDQppbnRlcmltIG1lZXRpbmcuIER1cmluZyB0aGUgbWVldGluZyB0aGUgdHdvIHByb3Bvc2Vk IGRyYWZ0cyB3ZXJlIGRpc2N1c3NlZCANCmJ5IHRoZSBFVlZNIEdyb3VwLiBUaGUgZ3JvdXAgY29u c2lkZXJlZCBzZXJ2ZXJhbCBwb3NzaWJsZSBzb2x1dGlvbnMsIA0KaW5jbHVkaW5nIHRoZSBvbmVz IHlvdSBtZW50aW9uZWQgaW4geW91ciBlbWFpbHMgKGJ5IHRoZSB3YXksIHRoYW5rcyB2ZXJ5IA0K bXVjaCkuIEhvd2V2ZXIsIHdlIHN0aWxsIHRoaW5rIHRvIGV4dGVuZCBJTUFQNCBpcyBwcm9iYWJs eSBvbmUgb2YgdGhlIGJlc3QgDQpjYW5kaWRhdGVzLg0KDQpZZXMsIGp1c3QgYXMgeW91IHNhaWQs IHdlIG5lZWQgdG8gc3R1ZHkgdGhlIGluZmx1ZW5jZSB0aGlzIGV4dGVudGlvbiBtYXkgDQpoYXZl IG9uIGFsbCBleHRlbnNpb25zIGZvciBJTUFQLiANCg0KV2UgYXJlIHdhaXRpbmcgZm9yIGZ1cnRo ZXIgY29tbWVudHMgZnJvbSBJRVRGLg0KDQoNCkRhdmUuDQotLSANCkRhdmUgQ3JpZGxhbmQgLSBt YWlsdG86ZGF2ZUBjcmlkbGFuZC5uZXQgLSB4bXBwOmR3ZEBkYXZlLmNyaWRsYW5kLm5ldA0KICAt IGFjYXA6Ly9hY2FwLmRhdmUuY3JpZGxhbmQubmV0L2J5b3duZXIvdXNlci9kd2QvYm9va21hcmtz Lw0KICAtIGh0dHA6Ly9kYXZlLmNyaWRsYW5kLm5ldC8NCkluZm90cm9wZSBQb2x5bWVyIC0gQUNB UCwgSU1BUCwgRVNNVFAsIGFuZCBMZW1vbmFkZQ0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24g U2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBp cyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWls IGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFy ZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8g ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpU aGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50 aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3Ig ZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1l c3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0 aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Ig dmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 002D3689482578E7_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkIHdpZHRoPTI4JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+RGF2ZSBDcmlk bGFuZCAmbHQ7ZGF2ZUBjcmlkbGFuZC5uZXQmZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMDctMjYgMTc6NDQ8L2ZvbnQ+DQo8dGQgd2lkdGg9 NzElPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rp dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7bHV5YW5AenRlLmNv bS5jbiZxdW90OyAmbHQ7bHV5YW5AenRlLmNvbS5jbiZndDssDQpHZW5lcmFsIGRpc2N1c3Npb24g b2YgYXBwbGljYXRpb24tbGF5ZXIgcHJvdG9jb2xzICZsdDthcHBzLWRpc2N1c3NAaWV0Zi5vcmcm Z3Q7LA0KJnF1b3Q7ZGluZy54aW5AenRlLmNvbS5jbiZxdW90OyAmbHQ7ZGluZy54aW5AenRlLmNv bS5jbiZndDssICZxdW90O2ppYXh3OUBjaGluYXVuaWNvbS5jbiZxdW90Ow0KJmx0O2ppYXh3OUBj aGluYXVuaWNvbS5jbiZndDssICZxdW90O1NISUgsIEpFUlJZIFwoQVRUU0lcKSZxdW90OyAmbHQ7 SlM5MDUzQGF0dC5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2 Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogUmU6IFJlOiBbYXBwcy1kaXNjdXNzXSBFeHRlbnRpb25z DQpvZiBJTUFQNDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+T24gVHVlIEp1bCAyNiAwOTozNjozNSAyMDExLCBsdXlhbkB6dGUuY29tLmNu IHdyb3RlOjxicj4NCiZndDsgJmd0OyBPbiBGcmkgSnVsIDIyIDA5OjEyOjM1IDIwMTEsIGx1eWFu QHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgW1lhbiBMVV0gVGhlIGludGVu dGlvbiBvZiB0aGlzIGRyYWZ0IGlzIHRvIGFzc29jaWF0ZSBtdWx0aXBsZTxicj4NCiZndDsgJmd0 OyAmZ3Q7IGlkZW50aXRpZXM8YnI+DQomZ3Q7ICZndDsgJmd0OyBiZWxvbmdpbmcgdG8gb25lIHVz ZXIuIFRodXMsIGFmdGVyIGxvZ2dpbmcgaW4sIHRoZSB1c2VyDQptYXkgJm5ic3A7PGJyPg0KJmd0 OyBjaG9vc2U8YnI+DQomZ3Q7ICZndDsgJmd0OyBvbmUgb2Y8YnI+DQomZ3Q7ICZndDsgJmd0OyB0 aGVzZSBhc3NvY2lhdGVkIGlkZW50aXRpZXMsIHVuZGVyIGVhY2ggb2Ygd2hpY2ggdGhlcmUgY2Fu DQpiZSBhbjxicj4NCiZndDsgJmd0OyAmZ3Q7IElOQk9YLCBhPGJyPg0KJmd0OyAmZ3Q7ICZndDsg U0VOVEJPWCBhbmQgb3RoZXIgZm9sZGVycywgYXMgc2hvd24gaW4gdGhlIGZvbGxvd2luZyBmaWd1 cmUuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE9LLiBJbiB0aGUgU0FTTCBtb2RlbCwg YW4gYXV0aGVudGljYXRpb24gaWRlbnRpZmllciBjYW4gaGF2ZQ0KJm5ic3A7PGJyPg0KJmd0OyBh Y2Nlc3M8YnI+DQomZ3Q7ICZndDsgdG8gbWFueSBhdXRob3JpemF0aW9uIGlkZW50aWZpZXJzIGFs cmVhZHk7IHNvIG5vIGNoYW5nZSBpcyBuZWVkZWQ8YnI+DQomZ3Q7ICZndDsgaGVyZS48YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgW1lhbiBMVV0gQXMgd2Uga25vdywgaW1wbGlj aXQgcmVnaXN0cmF0aW9uIGhhcyBhbHJlYWR5IGJlZW4gJm5ic3A7PGJyPg0KJmd0OyBzdXBwb3J0 ZWQgaW48YnI+DQomZ3Q7IDNHUFAgSU1TLiBIb3dldmVyLHNvIGZhciwgSSBoYXZlbqGvdCBmb3Vu ZCBhbnkgUkZDcyB3aGVyZSBhbjxicj4NCiZndDsgYXV0aGVudGljYXRpb24gaWRlbnRpZmllciBp cyBhbGxvd2VkIHRvIGJlIGJvdW5kIHdpdGggbXVsdGlwbGUgJm5ic3A7PGJyPg0KJmd0OyBpZGVu dGlmaWVyczxicj4NCiZndDsgLiBDb3VsZCB5b3UgdGVsbCBtZSB0aGUgc3BlY2lmaWMgZG9jdW1l bnRzPzxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQpBbGwgbW9kZXJuIFNBU0wgbWVjaGFuaXNt cyBhbGxvdyB1c2VycyB0byBzdXBwbHkgYW4gb3B0aW9uYWwgJm5ic3A7PGJyPg0KYXV0aG9yaXph dGlvbiBpZGVudGlmaWVyLjxicj4NCjxicj4NCiZndDsgJmd0OyBNb3N0bHkgYmVjYXVzZSB5b3Un cmUgbm90IC0geW91J3JlIGFzc29jaWF0aW5nIGF1dGhvcml6YXRpb248YnI+DQomZ3Q7ICZndDsg aWRlbnRpdGllcyBzZXF1ZW50aWFsbHksIHJhdGhlciB0aGFuIGNvbmN1cnJlbnRseS48YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgWW91IGNvdWxkIGJ1aWxkIG9uIG5hbWVzcGFjZXMsIGlu Y2lkZW50YWxseSwgdG8gYWNoaWV2ZSBtdWNoDQp0aGUgJm5ic3A7PGJyPg0KJmd0OyBzYW1lPGJy Pg0KJmd0OyAmZ3Q7IGdvYWwsIGJ5IHNpbXBseSBkZWZpbmluZyBhIHN0YW5kYXJkIG1ldGhvZCBm b3IgbG9jYXRpbmcgb3RoZXI8YnI+DQomZ3Q7ICZndDsgYXV0aG9yaXphdGlvbiBpZGVudGlmaWVy cycgSU5CT1hlcy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQnV0IGFsbG93aW5nIGEg dXNlciB0byBzd2l0Y2ggYXV0aG9yaXphdGlvbiBpZGVudGlmaWVyIG1pZC1mbG93DQombmJzcDs8 YnI+DQomZ3Q7IHdpbGw8YnI+DQomZ3Q7ICZndDsgYWxtb3N0IGNlcnRhaW5seSBpbnRyb2R1Y2Ug c29tZSBjb21wbGV4IGVkZ2UtY2FzZXMgd2l0aGluICZuYnNwOzxicj4NCiZndDsgc2VjdXJpdHkg LTxicj4NCiZndDsgJmd0OyBJJ3ZlIGEgc3Ryb25nIGZlZWxpbmcgdGhhdCB0aGlzIG9wZW5zIHVw IHBvc3NpYmlsaXRpZXMgZm9yIFRPQ1RPVTxicj4NCiZndDsgJmd0OyBlcnJvcnMuPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFtZYW4gTFVdIEFjdHVhbGx5LCB0aGUgaWRlYSBp biB0aGUgcHJvcG9zZWQgZHJhZnQgaXMgcXVpdGUgc2ltaWxhcg0KJm5ic3A7PGJyPg0KJmd0OyB3 aXRoPGJyPg0KJmd0OyBpbXBsaWNpdCByZWdpc3RyYXRpb24gaW4gM0dQUCwgd2hlcmUgaXQgaGFz IGFscmVhZHkgYmVlbiAmbmJzcDs8YnI+DQomZ3Q7IHN0YW5kYXJkaXplZC4gU28sPGJyPg0KJmd0 OyB3ZSB0aGluayBpdCBpcyBiZXR0ZXIgZm9yIHRoZSBJRVRGIHRvIHN1cHBvcnQgdGhlIHNhbWUg bWVjaGFuaXNtLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQpKdXN0IGJlY2F1c2Ugc29tZWJv ZHkgZWxzZSBoYXMgZGVjaWRlZCB0byBzdGFuZGFyZGl6ZSBpdCBkb2VzIG5vdCAmbmJzcDs8YnI+ DQptZWFuIGl0J3MgYSBnb29kIGlkZWEuPGJyPg0KPGJyPg0KQXMgSSBzYXksIEkgdGhpbmsgdGhh dCBhbGxvd2luZyB0aGUgYXV0aG9yaXphdGlvbiBpZGVudGlmaWVyIGJvdW5kIHRvICZuYnNwOzxi cj4NCmEgc2Vzc2lvbiB0byBjaGFuZ2Ugd2lsbCBpbnRyb2R1Y2Ugc2VjdXJpdHkgaXNzdWVzLiBJ TUFQLCBhbmQgJm5ic3A7PGJyPg0KdGhlcmVmb3JlIElNQVAgc2VydmVycywgYXJlIGJ1aWx0IGFy b3VuZCB0aGUgbm90aW9uIHRoYXQgdGhlICZuYnNwOzxicj4NCmF1dGhvcml6YXRpb24gaWRlbnRp ZmllciBpcyBib3VuZCBhdCBhdXRoZW50aWNhdGlvbiB0aW1lIGFuZCAmbmJzcDs8YnI+DQp0aGVy ZWFmdGVyIGludmFyaWFudC48YnI+DQo8YnI+DQpCcmVha2luZyB0aGF0IGFzc3VtcHRpb24gaXMg dHJpdmlhbCBpbiB0aGVvcnksIGJ1dCBpbiBwcmFjdGlzZSB3aWxsICZuYnNwOzxicj4NCmhhdmUg cXVpdGUgc2V2ZXIgaW1wYWN0IG9uIHNlcnZlciBjb2RlYmFzZXMsIGFzIHdlbGwgYXMgaW1wYWN0 IHRvICZuYnNwOzxicj4NCnZhcmlvdXMgZXh0ZW5zaW9ucy4gRm9yIGV4YW1wbGUsIGl0J3Mgbm90 IGF0IGFsbCBjbGVhciB3aGF0IE5PVElGWSAmbmJzcDs8YnI+DQpzaG91bGQgZG8gd2hlbiBmYWNl ZCB3aXRoIGFuIGF1dGhvcml6YXRpb24gaWRlbnRpZmllciBjaGFuZ2UuPGJyPg0KPGJyPg0KU28g YXQgbWluaW11bSwgdGhpcyBkcmFmdCB3b3VsZCBuZWVkIHRvIGFkZHJlc3MgZXZlcnkgZXh0YW50 ICZuYnNwOzxicj4NCmV4dGVuc2lvbnMgZm9yIElNQVAgYW5kIGVuc3VyZSB0aGF0IGl0IGRvZXMg bm90IGludHJvZHVjZSBzZWN1cml0eSAmbmJzcDs8YnI+DQppc3N1ZXMgLSBidXQgSSBkb24ndCB0 aGluayB0aGlzIGlzIHN1ZmZpY2llbnQgdG8gZWxpbWluYXRlIHRoZSByYXRoZXIgJm5ic3A7PGJy Pg0KbW9yZSB3b3JyeWluZyBpc3N1ZSB0aGF0IGF1dGhvcml6YXRpb24gaWRlbnRpZmllcnMgYXJl IGNvbnNpZGVyZWQgYW4gJm5ic3A7PGJyPg0KaW52YXJpYW50IG9mIGEgc2Vzc2lvbiB3aXRoaW4g dGhlIElNQVAgc2VydmVyIGNvZGViYXNlcy48YnI+DQo8YnI+DQpIb3dldmVyLCB0aGlzIGlzbid0 IGEgcHJvYmxlbSwgYXMgd2hhdCB5b3UgY2FuIGRvIGlzIHN0YW5kYXJkaXplIHRoZSAmbmJzcDs8 YnI+DQpOQU1FU1BBQ0UgdXNhZ2UgYW5kIHNlcnZlciBsYXlvdXQgc3VjaCB0aGF0IGl0J3Mgc2lt cGxlIGZvciBjbGllbnRzICZuYnNwOzxicj4NCnRvIGRpc2NvdmVyIHRoZSBJTkJPWCBhbmQgcGVy c29uYWwgbWFpbGJveGVzIG9mIG90aGVyIGF1dGhvcml6YXRpb24gJm5ic3A7PGJyPg0KaWRlbnRp ZmllcnMuPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5bWWFuIExVXVNv cnJ5IGZvciB0aGUgbGF0ZSByZXBseSBmb3Igd2UganVzdCBjYW1lDQpiYWNrIGZyb20gYW4gT01B LUVWVk0gaW50ZXJpbSBtZWV0aW5nLiBEdXJpbmcgdGhlIG1lZXRpbmcgdGhlIHR3byBwcm9wb3Nl ZA0KZHJhZnRzIHdlcmUgZGlzY3Vzc2VkIGJ5IHRoZSBFVlZNIEdyb3VwLiBUaGUgZ3JvdXAgY29u c2lkZXJlZCBzZXJ2ZXJhbA0KcG9zc2libGUgc29sdXRpb25zLCBpbmNsdWRpbmcgdGhlIG9uZXMg eW91IG1lbnRpb25lZCBpbiB5b3VyIGVtYWlscyAoYnkNCnRoZSB3YXksIHRoYW5rcyB2ZXJ5IG11 Y2gpLiBIb3dldmVyLCB3ZSBzdGlsbCB0aGluayB0byBleHRlbmQgSU1BUDQgaXMNCnByb2JhYmx5 IG9uZSBvZiB0aGUgYmVzdCBjYW5kaWRhdGVzLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+WWVzLCBqdXN0IGFzIHlvdSBzYWlkLCB3ZSBuZWVkIHRvIHN0dWR5IHRoZSBp bmZsdWVuY2UNCnRoaXMgZXh0ZW50aW9uIG1heSBoYXZlIG9uIGFsbCBleHRlbnNpb25zIGZvciBJ TUFQLiA8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPldlIGFyZSB3YWl0 aW5nIGZvciBmdXJ0aGVyIGNvbW1lbnRzIGZyb20gSUVURi48L2ZvbnQ+PC90dD4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCkRhdmUuPGJyPg0KLS0gPGJyPg0KRGF2ZSBDcmlkbGFu ZCAtIG1haWx0bzpkYXZlQGNyaWRsYW5kLm5ldCAtIHhtcHA6ZHdkQGRhdmUuY3JpZGxhbmQubmV0 PGJyPg0KICZuYnNwOy0gYWNhcDovL2FjYXAuZGF2ZS5jcmlkbGFuZC5uZXQvYnlvd25lci91c2Vy L2R3ZC9ib29rbWFya3MvPGJyPg0KICZuYnNwOy0gaHR0cDovL2RhdmUuY3JpZGxhbmQubmV0Lzxi cj4NCkluZm90cm9wZSBQb2x5bWVyIC0gQUNBUCwgSU1BUCwgRVNNVFAsIGFuZCBMZW1vbmFkZTxi cj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+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 002D3689482578E7_=-- From vesely@tana.it Tue Aug 9 03:57: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 5E50C21F86C4 for ; Tue, 9 Aug 2011 03:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtyCdNNCdyhv for ; Tue, 9 Aug 2011 03:57:36 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9216D21F8B21 for ; Tue, 9 Aug 2011 03:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1312887483; bh=PdmVZMI8IG1twG/Hp0b33kiulnde8EwngUMIxs1DWnI=; l=625; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=gZ7qrEl54ay5ZvpnA64kUHfp9OHh6Jbl4hWknFEdqMlO2XYsTn6wk2LGNS/w3btyn gwmGRc7RLsNB6rUZow+YTgn4/SPMG9l4zvwL918ytjUYGC2+qcb6qVLnBHBdq/Rl9G jr7E9BIuANJgufO/wG3cylLA8T9RqCgiZdav0tek= Received: from [109.113.130.53] ([109.113.130.53]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 09 Aug 2011 12:58:02 +0200 id 00000000005DC033.000000004E4112BA.0000082F Message-ID: <4E4112B4.7000905@tana.it> Date: Tue, 09 Aug 2011 12:57:56 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Updating the status of SPF 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, 09 Aug 2011 10:57:37 -0000 On 08.08.2011 22:02, Barry Leiba wrote: > > I believe this absolutely needs its own WG, and the proponents should > work on a draft charter. The charter should be clear that it's aiming > to move SPF to Standards Track, that it is specifically NOT addressing > Sender-ID, and that any merging of Sender-ID into SPF is out of scope. > The charter should have explanatory text about the experiment having > been done, the results being clear, and deployment being widespread. > The WG wants, it should say, to document the experimental results and > shift SPF onto Standards Track. +1, this is a Good Thing to do! From alexey.melnikov@isode.com Tue Aug 9 04:02: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 98BBB21F8892 for ; Tue, 9 Aug 2011 04:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N37derwAVuEZ for ; Tue, 9 Aug 2011 04:02:43 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id DE69C21F88B6 for ; Tue, 9 Aug 2011 04:02:42 -0700 (PDT) Received: from [188.28.117.11] (188.28.117.11.threembb.co.uk [188.28.117.11]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 9 Aug 2011 12:03:08 +0100 Message-ID: <4E4113F8.6060807@isode.com> Date: Tue, 09 Aug 2011 12:03:20 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: Barry Leiba , "Murray S. Kucherawy" References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Updating the status of SPF 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, 09 Aug 2011 11:02:43 -0000 Barry Leiba wrote: >> A participant in another WG has expressed interest in republishing SPF >> (RFC4408) on the standards track. This clearly and historically falls in= to >> the APPS realm. The work is probably in need of a WG home, and with YAM >> leaning toward spinning down, this is the next best place to ask. I have >> some doubts it would be accepted as sponsored individual submission nor i= s >> it appropriate for the ISE, but I could be wrong. >> =20 > > It absolutely can not be done in the Independent Stream -- that stream > can't do Standards Tack documents. > =20 >> I doubt this warrants its own working group, but I could be wrong about t= hat >> too. So far as I=92m aware the only changes needed from that document ar= e the >> creation of an extensions registry, some minor editorial stuff, and some >> kind of resolution of the IESG Statement that was added to it to address = the >> collision with Sender ID (RFC4406/7). >> =20 > > I believe this absolutely needs its own WG, and the proponents should > work on a draft charter. The charter should be clear that it's aiming > to move SPF to Standards Track, that it is specifically NOT addressing > Sender-ID, and that any merging of Sender-ID into SPF is out of scope. > The charter should have explanatory text about the experiment having > been done, the results being clear, and deployment being widespread. > The WG wants, it should say, to document the experimental results and > shift SPF onto Standards Track. > =20 Considering past history of SPF/Sender-ID, I would advise Apps AD not to=20 take it as an AD-sponsored document. So +1 for the WG, if there is=20 energy to do the work. > Hatless Barry From evnikita2@gmail.com Tue Aug 9 07:31: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 5649321F8748 for ; Tue, 9 Aug 2011 07:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.361 X-Spam-Level: X-Spam-Status: No, score=-3.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbLlcuuAyqU7 for ; Tue, 9 Aug 2011 07:31:46 -0700 (PDT) Received: from mail-ey0-f174.google.com (mail-ey0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9937921F8726 for ; Tue, 9 Aug 2011 07:31:46 -0700 (PDT) Received: by eyx24 with SMTP id 24so59261eyx.19 for ; Tue, 09 Aug 2011 07:32: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=HDSzVsd59HZ6Z+C2iTzukLMp1ml4u0/qWbn8WcVxhxA=; b=CQXvBN7nMgpE65dmJqawYC8nO7ZwYguIM7EiAwKmOBnAjwdNQXpZYf8rOk4Azu8VhZ J90yYnqMzHgjRr9RsCLSJQtUbEOSUCJRLGSasUJLrK6CJkNXY813OfgNERrGx3uS/Usc ZB9kja0+RYFsz/hWGKsSoKvBPcz0pJAmGzr/0= Received: by 10.14.119.80 with SMTP id m56mr1528218eeh.41.1312900334803; Tue, 09 Aug 2011 07:32:14 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id b13sm3085108een.31.2011.08.09.07.32.12 (version=SSLv3 cipher=OTHER); Tue, 09 Aug 2011 07:32:13 -0700 (PDT) Message-ID: <4E414512.5030405@gmail.com> Date: Tue, 09 Aug 2011 17:32:50 +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: <20110726161152.12935.82112.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 09 Aug 2011 14:31:47 -0000 26.07.2011 20:09, Murray S. Kucherawy wrote: >> -----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 >> >> 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. Murray, Should this document describe the situation when the message's line is longer that 998 characters? Also, should it describe the situation when the headers part contains one or more line breaks, e.g. > Header: value > Header1: value1 > Header2: value2 > > Header3: value3 > > Body Mykyta Yevstifeyev > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From cowan@ccil.org Mon Aug 8 18:13: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 82BC721F8BCD; Mon, 8 Aug 2011 18:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6OB9kvQxeNr; Mon, 8 Aug 2011 18:13:16 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id BD6C521F8BA8; Mon, 8 Aug 2011 18:13:16 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.69) (envelope-from ) id 1Qqat4-0006kQ-A8; Mon, 08 Aug 2011 21:13:42 -0400 Date: Mon, 8 Aug 2011 21:13:42 -0400 From: John Cowan To: John C Klensin Message-ID: <20110809011342.GA24628@mercury.ccil.org> References: <4E34DC83.30504@gmail.com> <20110731083853.GB30568@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: John Cowan X-Mailman-Approved-At: Tue, 09 Aug 2011 08:06:35 -0700 Cc: ftpext@ietf.org, Apps-discuss list 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: Tue, 09 Aug 2011 01:13:17 -0000 John C Klensin scripsit: > 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. The third possibility is to describe what actually works on the browsers and other URI-basec clients that are actually in use, which I believe is what is being done. > Between those two points, there isn't a lot other than slippery > slope. A slippery slope is where people actually live. -- One Word to write them all, John Cowan One Access to find them, http://www.ccil.org/~cowan One Excel to count them all, And thus to Windows bind them. --Mike Champion From msk@cloudmark.com Tue Aug 9 10:18: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 9B0B221F8CD5 for ; Tue, 9 Aug 2011 10:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.106 X-Spam-Level: X-Spam-Status: No, score=-103.106 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3NNflf3XY6R for ; Tue, 9 Aug 2011 10:18:44 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id CE85021F8CC4 for ; Tue, 9 Aug 2011 10:18:44 -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, 9 Aug 2011 10:19:13 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Tue, 9 Aug 2011 10:19:12 -0700 Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-00.txt Thread-Index: AcxWoSSjeJD0WDDsToONlWpvm7ixjQAFzTog Message-ID: References: <20110726161152.12935.82112.idtracker@ietfa.amsl.com> <4E414512.5030405@gmail.com> In-Reply-To: <4E414512.5030405@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="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, 09 Aug 2011 17:18:45 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Mykyta Yevstifeyev > Sent: Tuesday, August 09, 2011 7:33 AM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail= -00.txt >=20 > Should this document describe the situation when the message's line is > longer that 998 characters? Also, should it describe the situation when > the headers part contains one or more line breaks, e.g. >=20 > > Header: value > > Header1: value1 > > Header2: value2 > > > > Header3: value3 > > > > Body Sure, we could cover those cases if there's consensus to do so. I'd suppor= t discussion of both. From msk@cloudmark.com Tue Aug 9 10:19: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 2FD9211E80BD for ; Tue, 9 Aug 2011 10:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.602 X-Spam-Level: X-Spam-Status: No, score=-103.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-fxIeN3qFtq for ; Tue, 9 Aug 2011 10:19: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 C51D411E80B3 for ; Tue, 9 Aug 2011 10:19: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; Tue, 9 Aug 2011 10:20:00 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Tue, 9 Aug 2011 10:19:58 -0700 Thread-Topic: [apps-discuss] Updating the status of SPF Thread-Index: AcxWgzylYDfv6cCmSLSzWjWWoFVb9QANUFxw Message-ID: References: <4E4112B4.7000905@tana.it> In-Reply-To: <4E4112B4.7000905@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] Updating the status of SPF 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, 09 Aug 2011 17:19:31 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Alessandro Vesely > Sent: Tuesday, August 09, 2011 3:58 AM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Updating the status of SPF >=20 > +1, this is a Good Thing to do! Does that mean you (all) are volunteering to review stuff and comment, and = possibly co-chair? From jdfalk-lists@cybernothing.org Tue Aug 9 10:28: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 B2B5821F8B6F for ; Tue, 9 Aug 2011 10:28:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-pWBOjt2yR1 for ; Tue, 9 Aug 2011 10:28:08 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id E630E21F8B6B for ; Tue, 9 Aug 2011 10:28:07 -0700 (PDT) Received: from [10.9.8.140] ([12.180.99.220]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p79HSXK7000375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 9 Aug 2011 10:28:36 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p79HSXK7000375 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=fudge; t=1312910916; bh=BrUGqBhjwXV5wq3E7wCWjejSbvc91WCW08yNEPREb oQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=c6Kqlmae46wh +0nfFt8xAI7f40jkrdI7lB9l2RyR2tQMDwLVcGvvImG5nz00lzfsTvP8UlPVz5B3Rhl sob5gdIfjh4nryNFZSxZ4coEYMvWiCOmvycK6sJfEweiqm63nhTiLhZu3oPdRAKUO/7 dUxebcD+pi9L3y6ULXMSHBxTA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: Date: Tue, 9 Aug 2011 10:28:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <10FFF1EC-B1E0-4305-9BA5-8B9D05551D32@cybernothing.org> References: <4E4112B4.7000905@tana.it> To: "apps-discuss@ietf.org Discuss" X-Mailer: Apple Mail (2.1084) Subject: Re: [apps-discuss] Updating the status of SPF 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, 09 Aug 2011 17:28:08 -0000 On Aug 9, 2011, at 10:19 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Alessandro Vesely >> Sent: Tuesday, August 09, 2011 3:58 AM >> To: apps-discuss@ietf.org >> Subject: Re: [apps-discuss] Updating the status of SPF >>=20 >> +1, this is a Good Thing to do! >=20 > Does that mean you (all) are volunteering to review stuff and comment, = and possibly co-chair? Sure, I'll review and comment. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From barryleiba.mailing.lists@gmail.com Tue Aug 9 11:51: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 29CD011E80BE; Tue, 9 Aug 2011 11:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.881 X-Spam-Level: X-Spam-Status: No, score=-102.881 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YggvyH1YIt9i; Tue, 9 Aug 2011 11:51:38 -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 6E46911E80A4; Tue, 9 Aug 2011 11:51:38 -0700 (PDT) Received: by gwb20 with SMTP id 20so232055gwb.31 for ; Tue, 09 Aug 2011 11:52:07 -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=BjukpvIBi1IqkTd79W97aCE7eAG9hfMDEynrW/5m7FI=; b=g2KN92toUusfRq2oY3BWMet7MppYDqxpoXz6/l/zOTOzL1/ptOE/RN0oTmSY76kTsi ltcOMgwU+k8OTjanPrZxSR7ZfSiPXhlU5v9GglArNJcvIwib0yHGM5HUt9ra/68VdoWA xcxkCJX5YfT6t2SXDZiUuWp/5zOm+cx5oJL+8= MIME-Version: 1.0 Received: by 10.236.135.129 with SMTP id u1mr3768767yhi.246.1312915927525; Tue, 09 Aug 2011 11:52:07 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.181.13 with HTTP; Tue, 9 Aug 2011 11:52:07 -0700 (PDT) In-Reply-To: <4E34DC83.30504@gmail.com> References: <4E34DC83.30504@gmail.com> Date: Tue, 9 Aug 2011 14:52:07 -0400 X-Google-Sender-Auth: U7MXy8AiQIdzWs1-sJp10q6wsfk Message-ID: From: Barry Leiba To: Apps-discuss list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Tue, 09 Aug 2011 18:51:39 -0000 It's been a week and a half since the original message was posted, but I had to discuss this with the other appsawg chairs, the ftpext2 chairs, and the Applications ADs. On Sun, Jul 31, 2011 at 12:39 AM, Mykyta Yevstifeyev wrote: > Sorry for cross-posting to 6 addresses :-); please send all your comments= to > apps-discuss@ietf.org. No, please do not. This document is NOT to be discussed on apps-discuss. 1. It will not be processed in the appsawg. 2. The ftpext2 chairs have told me that it will not be processed in ftpext2. It is not in their charter, and the WG is not interested in rechartering to add it. 3. The Apps ADs have told me that they will not sponsor it as an individual submission. In other words, as an IETF document, this is dead. There is insufficient energy and interest in the IETF to hash this document out. Please do not continue work on this document. In any case, please do not discuss it on the apps-discuss mailing list. Barry Leiba, appsawg chair >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : The'ftp' URI Scheme >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Mykyta Yevstifeyev >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-yevstifeyev-ftp-uri-schem= e-05.txt >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 29 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-07-24 >> >> =A0 =A0This document specifies the'ftp' Uniform Resource Identif= ier >> (URI) >> =A0 =A0scheme, which is used to refer to resources accessible via File >> =A0 =A0Transfer Protocol (FTP). =A0It 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 From johnl@iecc.com Tue Aug 9 15:54: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 A539221F8BD5 for ; Tue, 9 Aug 2011 15:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vB2x5ddT93v for ; Tue, 9 Aug 2011 15:54:08 -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 1703921F8BC5 for ; Tue, 9 Aug 2011 15:54:07 -0700 (PDT) Received: (qmail 94643 invoked from network); 9 Aug 2011 22:54:37 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 9 Aug 2011 22:54:37 -0000 Received: (qmail 31695 invoked from network); 9 Aug 2011 22:54:37 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 9 Aug 2011 22:54:37 -0000 Date: 9 Aug 2011 22:54:15 -0000 Message-ID: <20110809225415.89118.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 Subject: Re: [apps-discuss] Updating the status of SPF 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, 09 Aug 2011 22:54:08 -0000 >> +1, this is a Good Thing to do! >Does that mean you (all) are volunteering to review stuff and comment, and possibly co-chair? I'll review stuff, but someone who thinks SPF is important needs to step up and offer to chair. R's, John From dhc@dcrocker.net Tue Aug 9 17:11: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 4582D21F8C29 for ; Tue, 9 Aug 2011 17:11:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcGaljf6ugDa for ; Tue, 9 Aug 2011 17:11:07 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 95F7121F8C1D for ; Tue, 9 Aug 2011 17:11:07 -0700 (PDT) Received: from [192.168.1.3] (cpe-76-93-128-131.san.res.rr.com [76.93.128.131]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p7A0BUGU006114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Aug 2011 17:11:37 -0700 Message-ID: <4E41CCB2.9040402@dcrocker.net> Date: Tue, 09 Aug 2011 17:11:30 -0700 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: "Murray S. Kucherawy" References: <4E4112B4.7000905@tana.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 09 Aug 2011 17:11:37 -0700 (PDT) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Updating the status of SPF 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, 10 Aug 2011 00:11:08 -0000 On 8/9/2011 10:19 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Alessandro Vesely >> Sent: Tuesday, August 09, 2011 3:58 AM >> To: apps-discuss@ietf.org >> Subject: Re: [apps-discuss] Updating the status of SPF >> >> +1, this is a Good Thing to do! > > Does that mean you (all) are volunteering to review stuff and comment, and possibly co-chair? I'll offer to co-chair. There's some history to this effort, going back to MAAWG, where I was one of 3 folk raising their hands to pursue this. Somehow things wandered through a circuitous route and I got decoupled from it. Historically and vocally, I'm not a fan of SPF. However I am /always/ a fan of good documentation for existing practice and I don't believe in using documentation processes to exercise religious preference. An effort to produce tight, pragmatic SPF documentation should be accurate and usable. I offered to assist the effort both to navigate the politics and to press for clean workable documentation. I'll suggest, however, that there is good reason for concern about any expectation that this will be a simple and/or easy effort. It will be wonderful for that to happen, but SPF invites the contrary. A few tidbits as examples: * It uses TXT without an underscore, thereby inviting the classic scaling argument against using TXT. This invites pushback from the DNS folk. * It is based on an implied semantic of SMTP Mail From that correlates with actual use, but not formal semantics of the field. This invites pushback from (some) email folk. * It is used for anti-abuse. This invites pushback from anyone who thinks they are an expert in anti-abuse and has any sort of agenda, releant or not, and we've already seem plenty of that over the last 7-9 years. While this probably does need a working group, it most definitely needs a collaborative, core design team that shares a coherent and constrained set of goals for the effort and that can work together. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From scott@kitterman.com Tue Aug 9 20:37: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 A7B43228012 for ; Tue, 9 Aug 2011 20:37:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNoQPyB88HDQ for ; Tue, 9 Aug 2011 20:37:11 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 11A1B228011 for ; Tue, 9 Aug 2011 20:37:10 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 6025B38C12D; Tue, 9 Aug 2011 23:37:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1312947460; bh=x/dfmrnlnx3fYd6iP4Y7j58Kbgxhej8EjiXwObMlhpk=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=aYrNDcSGhmQwusSJa/3H2d2IJvQLLlviK0I2kAz8mZIhPBHDeXROX0p/tscn8cZXF +IwK5eq78FvtDVttichtGKrqyfKLIVFMquczLYgPR6HQKsKUiyTll6H1FpzzOFdeGI lgD7kVSOiOaHGfW1/2HxFmtkFwZ/zWK7bKqnSJI4= From: Scott Kitterman To: apps-discuss@ietf.org Date: Tue, 9 Aug 2011 23:37:39 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic-pae; KDE/4.6.2; i686; ; ) References: <4E4112B4.7000905@tana.it> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108092337.39408.scott@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] Updating the status of SPF 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, 10 Aug 2011 03:37:11 -0000 On Tuesday, August 09, 2011 01:19:58 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org > > [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Alessandro Vesely > > Sent: Tuesday, August 09, 2011 3:58 AM > > To: apps-discuss@ietf.org > > Subject: Re: [apps-discuss] Updating the status of SPF > > > > +1, this is a Good Thing to do! > > Does that mean you (all) are volunteering to review stuff and comment, and > possibly co-chair? I've already started locally looking at what changes need to be made in RFC and updating the draft. There are a few errata, but I doubt there is a lot to do. If a full working group is needed, I'm willing to work in any role (in addition to co-authoring) if the group is suitably chartered. I've also had informal discussions with one of the RFC 4408 co-authors that is willing to also work on 4408bis. Scott K From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Tue Aug 9 22:49: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 18E7721F861A for ; Tue, 9 Aug 2011 22:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdztl1d4jIwG for ; Tue, 9 Aug 2011 22:49:45 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9434321F85F7 for ; Tue, 9 Aug 2011 22:49:45 -0700 (PDT) Received: by pzk33 with SMTP id 33so2459834pzk.18 for ; Tue, 09 Aug 2011 22:50:16 -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=4yjlIUeTZqZdXUryaPKPxGyWsLeD7iDKfaFUckVjYf0=; b=DGXnQp+kuNsNQGUZgv5ac5NwAmbNM91036cL2FZKdP8X20UgJ32Q3vnCGn8lqGoJRD hV9McmURBM2jg2GOrRXk69hDFTKIfhbOT6n+H0AwsdCO05pz/AFK/ZU/yrvk27uyA65A /7ZnqfH0vIp+dt0uKKQkxp1d7nLl4NBXCZ1IM= Received: by 10.143.21.4 with SMTP id y4mr2750366wfi.48.1312955416136; Tue, 09 Aug 2011 22:50:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.157.2 with HTTP; Tue, 9 Aug 2011 22:49:56 -0700 (PDT) In-Reply-To: References: <20110726161152.12935.82112.idtracker@ietfa.amsl.com> <4E414512.5030405@gmail.com> From: Frank Ellermann Date: Wed, 10 Aug 2011 07:49:56 +0200 Message-ID: To: "Murray S. Kucherawy" 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-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: Wed, 10 Aug 2011 05:49:46 -0000 On 9 August 2011 19:19, Murray S. Kucherawy wrote: > we could cover those cases if there's consensus to do so. =A0I'd support > discussion of both. Just in case, I think "line too long" can only happen in (if at all), otherwise this could be considered as "malformed wrt RFC 5322". Strange foldings are covered by in RFC 5322, so if you dare say that this is "malformed" I'll need lots of popcorn while watching what happens. -Frank From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Aug 10 05:21: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 3F9D821F8506 for ; Wed, 10 Aug 2011 05:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.607 X-Spam-Level: X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCaNsEU5nsHR for ; Wed, 10 Aug 2011 05:21:56 -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 79CC621F87C5 for ; Wed, 10 Aug 2011 05:21:56 -0700 (PDT) Received: by ywm21 with SMTP id 21so667079ywm.31 for ; Wed, 10 Aug 2011 05:22:27 -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=6uWQ+2i5Ct280f3MdTOir4C1lRMFXPn71EF8bLkzDTk=; b=DZhha8j3seFkx8PP25LcoUIoQ4al/CB2s/t7mYQ1EsCkqam4Amzj9+Zzq4L4HgcOXR EBndFmqOadHauYbfTcHhH2rS71cGGA2vd5MZAFZwa/yisZdGyBAZnmzsLgKBuQWgbofU PIYl0pNXUqsXo0xe1E/3GT8AKbv4YdTQkkvaw= Received: by 10.142.149.18 with SMTP id w18mr7504785wfd.162.1312978947112; Wed, 10 Aug 2011 05:22:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.157.2 with HTTP; Wed, 10 Aug 2011 05:22:07 -0700 (PDT) In-Reply-To: References: From: Frank Ellermann Date: Wed, 10 Aug 2011 14:22:07 +0200 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Updating the status of SPF 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, 10 Aug 2011 12:21:57 -0000 On 8 August 2011 20:22, Murray S. Kucherawy wrote: > So far as I=92m aware the only changes needed from that document are the > creation of an extensions registry, some minor editorial stuff, and > some kind of resolution of the IESG Statement that was added to it to > address the collision with Sender ID (RFC4406/7). Yes, the IESG review of the "errata hosted elsewhere" (=3D openspf.org) resulted in "submit new RFC"; only HTTP got away with the slightly odd approach of "hosting errata elsewhere". Of course it was not odd when the HTTP folks did it, but admittedly it is not more state of the art. A new RFC can adopt the collected errata, and report various results of the experiment, e.g., the test suite, a reference implementation, and the missing EAI followup (=3D expired I-D unrelated to new EAI work). IMHO 0.01% SenderID vs. 16% SPF in a DNS survey published 2010 is now a not completely irrelevant result -- that SPF started earlier will never change, and at some point in time adoption has to mean something. DKIM started after SenderID, and it is already far beyond this level in the same study. It's not something that should be mentioned in an RFC, but it is a motivation to work on a refresh version covering all errata, and with updated references, e.g., RFC 5321/2 instead of RFC 2821/2. The SPF modifier registry could be also started in a MARF RFC, starting a registry as soon as it *might* be used can be too early if it is in fact never updated later, starting it as soon as there is more than one RFC needing values in the same namespace could be a good plan. But for the SPF modifiers it would be clearer to start the registry in 4408bis, if that is possible, because the MARF use case are "special modifiers", not the place where readers would expect details of a general concept. -Frank From msk@cloudmark.com Wed Aug 10 08:14: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 7526B21F899F for ; Wed, 10 Aug 2011 08:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.596 X-Spam-Level: X-Spam-Status: No, score=-103.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWgeymZ1LX-T for ; Wed, 10 Aug 2011 08:14:26 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id DE4A921F876A for ; Wed, 10 Aug 2011 08:13:40 -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, 10 Aug 2011 08:14:12 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Wed, 10 Aug 2011 08:14:10 -0700 Thread-Topic: [apps-discuss] Updating the status of SPF Thread-Index: AcxXWCvLUkIFij2tR4ydL23FvLLosQAF79ig Message-ID: References: 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] Updating the status of SPF 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, 10 Aug 2011 15:14:26 -0000 > -----Original Message----- > From: Frank Ellermann [mailto:hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com] > Sent: Wednesday, August 10, 2011 5:22 AM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Updating the status of SPF >=20 > IMHO 0.01% SenderID vs. 16% SPF in a DNS survey published 2010 is now a > not completely irrelevant result -- that SPF started earlier will never > change, and at some point in time adoption has to mean something. >=20 > DKIM started after SenderID, and it is already far beyond this level in > the same study. It's not something that should be mentioned in an RFC, > but it is a motivation to work on a refresh version covering all errata, > and with updated references, e.g., RFC 5321/2 instead of RFC 2821/2. Given the history, maybe this is a case where an implementation report, nor= mally used to promote something to Draft Standard, would be especially help= ful? > The SPF modifier registry could be also started in a MARF RFC, starting > a registry as soon as it *might* be used can be too early if it is in > fact never updated later, starting it as soon as there is more than > one RFC needing values in the same namespace could be a good plan. But fo= r > the SPF modifiers it would be clearer to start the registry in 4408bis, > if that is possible, because the MARF use case are "special modifiers", > not the place where readers would expect details of a general concept. I think it would best appear here, but I don't have a problem doing it in t= he MARF extensions draft to which you are referring. From stpeter@stpeter.im Wed Aug 10 08:16: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 BD86821F84B6 for ; Wed, 10 Aug 2011 08:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSPSulnkMNds for ; Wed, 10 Aug 2011 08:16:56 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5BF21F876A for ; Wed, 10 Aug 2011 08:16:53 -0700 (PDT) Received: from squire.local (unknown [216.17.251.17]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5735041463; Wed, 10 Aug 2011 09:19:04 -0600 (MDT) Message-ID: <4E42A0F4.7010603@stpeter.im> Date: Wed, 10 Aug 2011 09:17:08 -0600 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: "Murray S. Kucherawy" References: 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: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Updating the status of SPF 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, 10 Aug 2011 15:16:56 -0000 On 8/10/11 9:14 AM, Murray S. Kucherawy wrote: >> -----Original Message----- From: Frank Ellermann >> [mailto:hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com] Sent: Wednesday, >> August 10, 2011 5:22 AM To: Murray S. Kucherawy Cc: >> apps-discuss@ietf.org Subject: Re: [apps-discuss] Updating the >> status of SPF >> >> IMHO 0.01% SenderID vs. 16% SPF in a DNS survey published 2010 is >> now a not completely irrelevant result -- that SPF started earlier >> will never change, and at some point in time adoption has to mean >> something. >> >> DKIM started after SenderID, and it is already far beyond this >> level in the same study. It's not something that should be >> mentioned in an RFC, but it is a motivation to work on a refresh >> version covering all errata, and with updated references, e.g., RFC >> 5321/2 instead of RFC 2821/2. > > Given the history, maybe this is a case where an implementation > report, normally used to promote something to Draft Standard, would > be especially helpful? Given that the SPF spec is Experimental, I agree that a report on the experiment would be useful. Peter -- Peter Saint-Andre https://stpeter.im/ From msk@cloudmark.com Wed Aug 10 09:10: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 08B2621F8ACC for ; Wed, 10 Aug 2011 09:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.595 X-Spam-Level: X-Spam-Status: No, score=-103.595 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1D-2tCjuQLZa for ; Wed, 10 Aug 2011 09:10:09 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id EF0E421F8AA8 for ; Wed, 10 Aug 2011 09:10:09 -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, 10 Aug 2011 09:10:40 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Wed, 10 Aug 2011 09:10:38 -0700 Thread-Topic: Status of the malformed mail BCP Thread-Index: AcxXeAuZBDXoyiqiRienbiEFwcxu0w== 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_F5833273385BB34F99288B3648C4F06F13512DF694EXCHC2corpclo_" MIME-Version: 1.0 Subject: [apps-discuss] Status of the malformed mail BCP 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, 10 Aug 2011 16:10:15 -0000 --_000_F5833273385BB34F99288B3648C4F06F13512DF694EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Based on the list discussion about this draft, Barry and I approached IANA = in Quebec City to talk about our options. Someone had suggested the idea o= f doing a registry of malformations and their corresponding handling advice= rather than updating an RFC whenever the list changes. IANA says they can indeed handle such a thing. We would need to do the usu= al registry creation procedures including specifying what the fields are an= d the rules for making changes, and then give them some guidance about how = we'd like it to be presented. So I think my next step is to convert the existing document into exactly th= at. Since the main objection to doing it as an RFC is the idea that it mig= ht need to be changed often, perhaps we should go with Expert Review instea= d of one of the rules that says a specification has to exist. Any comments= on that point? -MSK --_000_F5833273385BB34F99288B3648C4F06F13512DF694EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Based = on the list discussion about this draft, Barry and I approached IANA in Que= bec City to talk about our options.  Someone had suggested the idea of= doing a registry of malformations and their corresponding handling advice = rather than updating an RFC whenever the list changes.


IANA says they can indeed handle such a thing.  We = would need to do the usual registry creation procedures including specifyin= g what the fields are and the rules for making changes, and then give them = some guidance about how we’d like it to be presented.

<= p class=3DMsoNormal> 

So I think my= next step is to convert the existing document into exactly that.  Sin= ce the main objection to doing it as an RFC is the idea that it might need = to be changed often, perhaps we should go with Expert Review instead of one= of the rules that says a specification has to exist.  Any comments on= that point?

 

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F13512DF694EXCHC2corpclo_-- From julian@mehnle.net Wed Aug 10 09:15: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 3251621F8AFE for ; Wed, 10 Aug 2011 09:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecizb4Y8C8ED for ; Wed, 10 Aug 2011 09:15:38 -0700 (PDT) Received: from io.link-m.de (io.link-m.de [82.135.8.34]) by ietfa.amsl.com (Postfix) with ESMTP id A00DA21F8AFC for ; Wed, 10 Aug 2011 09:15:38 -0700 (PDT) Received: from [10.0.2.15] (static-72-81-252-21.bltmmd.fios.verizon.net [::ffff:72.81.252.21]) (AUTH: CRAM-MD5 julian@mehnle.net, TLS: TLSv1/SSLv3, 256bits, AES256-SHA) by io.link-m.de with esmtp; Wed, 10 Aug 2011 16:16:04 +0000 id 00000000306E12A9.000000004E42AEC5.00001DCE From: Julian Mehnle To: apps-discuss@ietf.org Date: Wed, 10 Aug 2011 16:16:03 +0000 User-Agent: KMail/1.9.9 References: <201108092337.39408.scott@kitterman.com> In-Reply-To: <201108092337.39408.scott@kitterman.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3269304.66Rl6rIYj9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201108101616.03559.julian@mehnle.net> Subject: Re: [apps-discuss] Updating the status of SPF 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, 10 Aug 2011 16:15:39 -0000 --nextPart3269304.66Rl6rIYj9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, I'm willing to contribute to this effort to whatever reasonable extent=20 necessary to make it happen. =2DJulian --nextPart3269304.66Rl6rIYj9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAk5CrsMACgkQwL7PKlBZWju/EwCgsNXvRzDr3hDTqVJUp0QkKXmp oTQAoPGgLi8J+ZaG97UuV79ne8yZmRGB =q14K -----END PGP SIGNATURE----- --nextPart3269304.66Rl6rIYj9-- From vesely@tana.it Wed Aug 10 10:21: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 741BA21F8880 for ; Wed, 10 Aug 2011 10:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFqzFjIBZiA4 for ; Wed, 10 Aug 2011 10:21:13 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 725CC21F87DA for ; Wed, 10 Aug 2011 10:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1312996898; bh=MKTTeyG7S+iw5Nbj0vJcHzBPpkLCxRjT1XUtE6egMwY=; l=225; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=hTTJCIcljm5Bt2g8rEkQM05Sbv81/5tmPKbO1XYAfIPZQP2t8Uay1QIUed0KtTA9Y 8iKyd4Sgw3y3Ug24rYdYhm9l77n5hRQ2oR5J9WUTqhd373jCnpTEa6gDncylLTxDK9 Y+fX7lpaPv6ESUt/fl+YRUTSZOpwlsSizRYXg1U0= Received: from [109.113.198.243] ([109.113.198.243]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 10 Aug 2011 19:21:37 +0200 id 00000000005DC035.000000004E42BE22.00005E72 Message-ID: <4E42BE19.9090609@tana.it> Date: Wed, 10 Aug 2011 19:21:29 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20110809225415.89118.qmail@joyce.lan> In-Reply-To: <20110809225415.89118.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Updating the status of SPF 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, 10 Aug 2011 17:21:14 -0000 On 10.08.2011 00:54, John Levine wrote: > > I'll review stuff, but someone who thinks SPF is important needs to > step up and offer to chair. So will I, and I thank the members of the SPF council who offered to chair. From sm@resistor.net Wed Aug 10 14:48: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 75D2B11E80AA for ; Wed, 10 Aug 2011 14:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqxMzzrT5bry for ; Wed, 10 Aug 2011 14:48: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 23AB611E807E for ; Wed, 10 Aug 2011 14:48: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 p7ALmWK7011252; Wed, 10 Aug 2011 14:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1313012917; bh=2c7kJzNiRHVG6xlIicnSjYaHnJqcLreRX6dOoN8vItY=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=0x26Vq+Wgy5k2xT+C6T3TESX1+uxTId90nX9FJpgwGWZS4plJBHrVEbtmZ6bD5cuS fY7lYUbhGtuySu6Uybp8eEaaWyyaeoddXQp3Si2zM1uJPsIW2bM7eGvkwxe22KKQh5 MhgZ2zLP7DdTcIZrmwlcm33PamKoAkq3elHam4n0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1313012917; bh=2c7kJzNiRHVG6xlIicnSjYaHnJqcLreRX6dOoN8vItY=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=IRtoj+Re9MkkTcwM+H42yTz362oie4s6HgSP3jDf+YEB7apPoUw63C8oERtXJEniT JoEg8n+8IzY5KybtrDxSHjX4RPtvM9GgEVQfs16dcixyi753vGoCGuWstk1J+xr7kR KQyKPwXa3144zQGBWry9fP4ivRUb9PKlhiix5Yw0= Message-Id: <6.2.5.6.2.20110810143624.0a2c2b78@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 10 Aug 2011 14:48:24 -0700 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Status of the malformed mail BCP 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, 10 Aug 2011 21:48:18 -0000 Hi Murray, At 09:10 10-08-2011, Murray S. Kucherawy wrote: >Based on the list discussion about this draft, Barry and I >approached IANA in Quebec City to talk about our options. Someone >had suggested the idea of doing a registry of malformations and >their corresponding handling advice rather than updating an RFC >whenever the list changes. IANA makes unique assignments and maintains registries for the currently assigned values. A malformation does not require such an assignment. Regards, -sm From msk@cloudmark.com Wed Aug 10 14:55: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 6430221F8B58 for ; Wed, 10 Aug 2011 14:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.096 X-Spam-Level: X-Spam-Status: No, score=-103.096 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWEjFACIm+sM for ; Wed, 10 Aug 2011 14:55:24 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id F234C21F8B57 for ; Wed, 10 Aug 2011 14:55:23 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 10 Aug 2011 14:55:55 -0700 From: "Murray S. Kucherawy" To: SM Date: Wed, 10 Aug 2011 14:55:55 -0700 Thread-Topic: [apps-discuss] Status of the malformed mail BCP Thread-Index: AcxXp0sWwMS2/gYjTCqcpdN7xXHH4QAAN74g Message-ID: References: <6.2.5.6.2.20110810143624.0a2c2b78@resistor.net> In-Reply-To: <6.2.5.6.2.20110810143624.0a2c2b78@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] Status of the malformed mail BCP 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, 10 Aug 2011 21:55:24 -0000 > -----Original Message----- > From: SM [mailto:sm@resistor.net] > Sent: Wednesday, August 10, 2011 2:48 PM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Status of the malformed mail BCP >=20 > IANA makes unique assignments and maintains registries for the > currently assigned values. A malformation does not require such an > assignment. On the contrary, it seems IANA was willing to create this kind of registry = for us. I suppose you could think of it as advice (values) assigned to malformation= s (keys). From simon.perreault@viagenie.ca Thu Aug 11 05:07: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 C207C21F89BE for ; Thu, 11 Aug 2011 05:07:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhOQa+j0QxJ4 for ; Thu, 11 Aug 2011 05:07:52 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 3A99021F85FF for ; Thu, 11 Aug 2011 05:07:52 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 359F521C75 for ; Thu, 11 Aug 2011 08:08:26 -0400 (EDT) Message-ID: <4E43C639.6000206@viagenie.ca> Date: Thu, 11 Aug 2011 08:08:25 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <6.2.5.6.2.20110810143624.0a2c2b78@resistor.net> In-Reply-To: X-Enigmail-Version: 1.2.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Status of the malformed mail BCP 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, 11 Aug 2011 12:07:52 -0000 On 2011-08-10 17:55, Murray S. Kucherawy wrote: >> IANA makes unique assignments and maintains registries for the >> currently assigned values. A malformation does not require such an >> assignment. > > On the contrary, it seems IANA was willing to create this kind of registry for us. Of course it is "willing": IANA's job is to execute the IETF consensus. It still does not mean that such a registry would be a good idea. Personally I would see a wiki as more appropriate. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Thu Aug 11 06: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 7807321F8764 for ; Thu, 11 Aug 2011 06:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.627 X-Spam-Level: X-Spam-Status: No, score=-102.627 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4KaZakygsoa for ; Thu, 11 Aug 2011 06:13:39 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 055F621F85DE for ; Thu, 11 Aug 2011 06:13:38 -0700 (PDT) Received: by pzk33 with SMTP id 33so7574570pzk.18 for ; Thu, 11 Aug 2011 06:14:13 -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=RKeJ4ObiO8jwEGvcJK7gI9SMBD5S7q04UdJBGXKMB9M=; b=v8ON3fSRESfFWAJlKSGCl2voFxLA4Le2fn8g+kvJSYLL6ew1isuWafiQ/o3Yba0p0P QMtgrZGek0KH1fqHFesKqUF4ZLUo3ECcIZR4Uiy7j2Yl31GB61E8SCNwc60rlMgWayzP wKtUZ2iueWqVYoeKci401AZwZzKvlpGEY1oRo= Received: by 10.142.166.5 with SMTP id o5mr959672wfe.390.1313068453174; Thu, 11 Aug 2011 06:14:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.157.2 with HTTP; Thu, 11 Aug 2011 06:13:53 -0700 (PDT) In-Reply-To: <4E43C639.6000206@viagenie.ca> References: <6.2.5.6.2.20110810143624.0a2c2b78@resistor.net> <4E43C639.6000206@viagenie.ca> From: Frank Ellermann Date: Thu, 11 Aug 2011 15:13:53 +0200 Message-ID: To: Simon Perreault Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Status of the malformed mail BCP 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, 11 Aug 2011 13:13:39 -0000 On 11 August 2011 14:08, Simon Perreault wrote: > IANA's job is to execute the IETF consensus. It still does not mean > that such a registry would be a good idea. Personally I would see > a wiki as more appropriate. An "expert review wiki" can be a very good idea, I'd love to test it for some topic (if it is MediaWiki, otherwise I'm not sure). And it could be hosted by IANA with an apparently "official" URI if they are still willing: MediaWiki administration requires some special skills, mainly the "willingness" to update the installation at least once per year, and to care about its i18n features with templates, extensions, and other technical details. For a "malformed mail" registry (or Wiki) "apparently official" and "simple to understand" are both important, when mail administrators are forced to prove their point in a discussion about legal issues. -Frank From peter@denic.de Thu Aug 11 06:37: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 0555C21F8596 for ; Thu, 11 Aug 2011 06:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sspi5p31UbKG for ; Thu, 11 Aug 2011 06:37:50 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 7225521F856A for ; Thu, 11 Aug 2011 06:37:50 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1QrVSp-00075t-Hg; Thu, 11 Aug 2011 15:38:23 +0200 Received: from localhost by x27.adm.denic.de with local id 1QrVSp-0003av-DF; Thu, 11 Aug 2011 15:38:23 +0200 Date: Thu, 11 Aug 2011 15:38:23 +0200 From: Peter Koch To: apps-discuss@ietf.org Message-ID: <20110811133823.GR23694@x27.adm.denic.de> Mail-Followup-To: apps-discuss@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [apps-discuss] Status of the malformed mail BCP 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, 11 Aug 2011 13:37:51 -0000 On Wed, Aug 10, 2011 at 09:10:38AM -0700, Murray S. Kucherawy wrote: > IANA says they can indeed handle such a thing. We would need to do the usual registry creation procedures including specifying what the fields are and the rules for making changes, and then give them some guidance about how we'd like it to be presented. that IANA is technically capable or "willing" to do this does not necessarily mean it is in line with IETF processes. A registry is not just "a collection of stuff" but would usually exist for protocol parameters(!) to be uniquely identified. I have a hard time seeing that violations of a protocol spec qualify here. > So I think my next step is to convert the existing document into exactly that. Since the main objection to doing it as an RFC is the idea that it might need to be changed often, perhaps we should go with Expert Review instead of one of the rules that says a specification has to exist. Any comments on that point? This is so much Monty Python that i start to love it. Assume we have Expert Review for this registry. What if a candidate brokenness fails the review process - can the implementor enhance their misimplementation to have it recognized (and eventually registered) as a reviewed protocol violation? -Peter From cyrus@daboo.name Thu Aug 11 06:47: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 2270921F8784 for ; Thu, 11 Aug 2011 06:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hT5erlZ5phml for ; Thu, 11 Aug 2011 06:47:48 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7475421F8586 for ; Thu, 11 Aug 2011 06:47:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 7618318763CF; Thu, 11 Aug 2011 09:48:22 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxeqMARg-J5x; Thu, 11 Aug 2011 09:48:21 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id A8A2518763C2; Thu, 11 Aug 2011 09:48:20 -0400 (EDT) Date: Thu, 11 Aug 2011 09:48:17 -0400 From: Cyrus Daboo To: Frank Ellermann , Simon Perreault Message-ID: <1CA767A597F39B55C51402A9@caldav.corp.apple.com> In-Reply-To: References: <6.2.5.6.2.20110810143624.0a2c2b78@resistor.net> <4E43C639.6000206@viagenie.ca> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1365 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Status of the malformed mail BCP 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, 11 Aug 2011 13:47:49 -0000 Hi Frank, --On August 11, 2011 3:13:53 PM +0200 Frank Ellermann wrote: >> IANA's job is to execute the IETF consensus. It still does not mean >> that such a registry would be a good idea. Personally I would see >> a wiki as more appropriate. > > An "expert review wiki" can be a very good idea, I'd love to test it > for some topic (if it is MediaWiki, otherwise I'm not sure). And it > could be hosted by IANA with an apparently "official" URI if they are > still willing: MediaWiki administration requires some special skills, > mainly the "willingness" to update the installation at least once per > year, and to care about its i18n features with templates, extensions, > and other technical details. > > For a "malformed mail" registry (or Wiki) "apparently official" and > "simple to understand" are both important, when mail administrators > are forced to prove their point in a discussion about legal issues. I've actually thought that every RFC should have an associated (expert review) wiki associated with it. Then implementors could post their own experiences, notes, issues etc there plus it could auto-link to rfc errata and other related stuff. Of course that could mean a lot of work for expert reviewers - maybe there should be two pages - one expert review, the other public? -- Cyrus Daboo From ajs@anvilwalrusden.com Thu Aug 11 07:08: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 A053521F861E for ; Thu, 11 Aug 2011 07:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yplY2rjAtmH for ; Thu, 11 Aug 2011 07:08:38 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id B6EF221F85FE for ; Thu, 11 Aug 2011 07:08:38 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 8BCBA1ECB41D for ; Thu, 11 Aug 2011 14:09:13 +0000 (UTC) Date: Thu, 11 Aug 2011 10:09:10 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20110811140910.GE95640@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] Status of the malformed mail BCP 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, 11 Aug 2011 14:08:39 -0000 On Wed, Aug 10, 2011 at 09:10:38AM -0700, Murray S. Kucherawy wrote: > So I think my next step is to convert the existing document into > exactly that. Since the main objection to doing it as an RFC is the > idea that it might need to be changed often, perhaps we should go > with Expert Review instead of one of the rules that says a > specification has to exist. Any comments on that point? I think this is stretching past the point of pragmatism. The proposal, so far, is a sort of extreme case of being liberal in what one accepts (and what one does thereafter, of course). I have to agree with Peter's detection of slight absurdity here, but I also question whether it would be possible to select an appropriate expert. Who is more expert in not conforming to the existing protocol documents than the person who is so nonconforming? And if there is nobody, then the correct expert to appoint in each case would be the implementer of the nonconforming implementation, who would perform the review and approve the registry entry. Therefore, assigning the registry entry on detection of nonconformance would be correct, and no expert is needed. At that point, of course, the problem becomes that you need a stable reference for the way the nonconformance works, and so you need a specification anyway. So "specification required" is correct, I think. (The entire passage above, however, could as easily be construed as a reductio argument against such a registry at all.) A -- Andrew Sullivan ajs@anvilwalrusden.com From barryleiba.mailing.lists@gmail.com Thu Aug 11 09:09: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 5DF8921F8B7D for ; Thu, 11 Aug 2011 09:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.044 X-Spam-Level: X-Spam-Status: No, score=-103.044 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bK9HlbwFh9ra for ; Thu, 11 Aug 2011 09:09:23 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C7D1E21F8B7C for ; Thu, 11 Aug 2011 09:09:23 -0700 (PDT) Received: by yxp4 with SMTP id 4so1665457yxp.31 for ; Thu, 11 Aug 2011 09:09: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=Rd1f+36udvdH0fgaQvMLH697qszbMM56vvsL20MzVts=; b=TLZFdT8aVd7781uQzpds/9inOwXufI44jRhmD2yUgkTQgV0MeOx9ez+N1oxrV2WhWN PJCzUf8QhDWO+ZYkEfMo95gSx60Y+c+ndWg3aS/ntjohWfaTQzPah7fK39EmKAprAcNa Ek8Czx5oaSzLd7yfBnNScg1I0hfwSqlSwZCpY= MIME-Version: 1.0 Received: by 10.236.170.165 with SMTP id p25mr12659583yhl.143.1313078998119; Thu, 11 Aug 2011 09:09:58 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.181.13 with HTTP; Thu, 11 Aug 2011 09:09:58 -0700 (PDT) In-Reply-To: <4E42BE19.9090609@tana.it> References: <20110809225415.89118.qmail@joyce.lan> <4E42BE19.9090609@tana.it> Date: Thu, 11 Aug 2011 12:09:58 -0400 X-Google-Sender-Auth: JSmykT2zzya44kjIQFlT7Bs8Sj0 Message-ID: From: Barry Leiba To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [apps-discuss] Updating the status of SPF 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, 11 Aug 2011 16:09:24 -0000 OK... so unless my co-chairs or the ADs object, I'm happy with letting initial charter discussion happen here. Who will post a draft charter proposal, and when? Once things get started and a reasonable charter looks like it's coming together, y'all can ask the ADs for a mailing list to take the discussion further, and to get into the details. Note that I suggest you NOT use the existing spf-discuss list, to keep the IETF work on an IETF mailing list. People from spf-discuss that are interested in working on the IETF documentation should be encouraged to come to the IETF lists for that. If you do decide to start the charter discussion here, please keep it to charter stuff, and save details for an SPF mailing list when it's created. Barry, appsawg chair From stpeter@stpeter.im Thu Aug 11 09:32: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 CF94121F8876 for ; Thu, 11 Aug 2011 09:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.624 X-Spam-Level: X-Spam-Status: No, score=-102.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sIHwfueuyjV for ; Thu, 11 Aug 2011 09:32:28 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3F42321F8839 for ; Thu, 11 Aug 2011 09:32:28 -0700 (PDT) Received: from dhcp-64-101-72-239.cisco.com (unknown [64.101.72.239]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 730F841477; Thu, 11 Aug 2011 10:34:45 -0600 (MDT) Message-ID: <4E440434.7070905@stpeter.im> Date: Thu, 11 Aug 2011 10:32:52 -0600 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: Barry Leiba References: <20110809225415.89118.qmail@joyce.lan> <4E42BE19.9090609@tana.it> 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: apps-discuss@ietf.org Subject: Re: [apps-discuss] Updating the status of SPF 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, 11 Aug 2011 16:32:28 -0000 On 8/11/11 10:09 AM, Barry Leiba wrote: > OK... so unless my co-chairs or the ADs object, I'm happy with letting > initial charter discussion happen here. Who will post a draft charter > proposal, and when? Once things get started and a reasonable charter > looks like it's coming together, y'all can ask the ADs for a mailing > list to take the discussion further, and to get into the details. > > Note that I suggest you NOT use the existing spf-discuss list, to keep > the IETF work on an IETF mailing list. People from spf-discuss that > are interested in working on the IETF documentation should be > encouraged to come to the IETF lists for that. > > If you do decide to start the charter discussion here, please keep it > to charter stuff, and save details for an SPF mailing list when it's > created. Barry, that all seems reasonable to me. Peter -- Peter Saint-Andre https://stpeter.im/ From dhc@dcrocker.net Thu Aug 11 09:39: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 2AEAA21F8C74 for ; Thu, 11 Aug 2011 09:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[AWL=1.498, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IEHf1BKEpN5 for ; Thu, 11 Aug 2011 09:39:50 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 97B1921F8C52 for ; Thu, 11 Aug 2011 09:39:50 -0700 (PDT) Received: from [192.168.1.156] (adsl-68-122-69-114.dsl.pltn13.pacbell.net [68.122.69.114]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p7BGeJ3b018458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Aug 2011 09:40:24 -0700 Message-ID: <4E4405F3.90101@dcrocker.net> Date: Thu, 11 Aug 2011 09:40:19 -0700 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: Scott Kitterman References: <4E4112B4.7000905@tana.it> <201108092337.39408.scott@kitterman.com> In-Reply-To: <201108092337.39408.scott@kitterman.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, 11 Aug 2011 09:40:24 -0700 (PDT) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Updating the status of SPF 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, 11 Aug 2011 16:39:51 -0000 On 8/9/2011 8:37 PM, Scott Kitterman wrote: > I've already started locally looking at what changes need to be made in RFC > and updating the draft. There are a few errata, but I doubt there is a lot to > do. Scott, What are the criteria you are using to determine what should be changed? What is the basis for using those criteria? For example, what is the likelihood that others in the community will agree with your choices? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Thu Aug 11 10:10: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 9220D21F8BAE for ; Thu, 11 Aug 2011 10:10:41 -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.454, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNkFGBm-cj-k for ; Thu, 11 Aug 2011 10:10:40 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id C526321F8B8F for ; Thu, 11 Aug 2011 10:10:40 -0700 (PDT) Received: by pzk33 with SMTP id 33so8115609pzk.18 for ; Thu, 11 Aug 2011 10:11:10 -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=zvBon7PA1fVemG8Ix7KzUZWU77fKgDAmZLxl43BXZfY=; b=dMNiCAGHhiXKYKd7ZqFdW3cEDSVbuvKTyLD7BDc4Aue088jCoK5rlyjtBnLUxy6Quz wfTBQXoHDwu0ouy8bdXhQr7qN/rIe3dg0yctTSAKlVW/Aao8URQX/zKatqZxodJCPuvc n3swsLFTTF1o6HPecKFeXEmQVdU+lTc11vbsI= Received: by 10.142.229.18 with SMTP id b18mr676788wfh.333.1313082670151; Thu, 11 Aug 2011 10:11:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.157.2 with HTTP; Thu, 11 Aug 2011 10:10:50 -0700 (PDT) In-Reply-To: References: <20110809225415.89118.qmail@joyce.lan> <4E42BE19.9090609@tana.it> From: Frank Ellermann Date: Thu, 11 Aug 2011 19:10:50 +0200 Message-ID: To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Updating the status of SPF 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, 11 Aug 2011 17:10:41 -0000 On 11 August 2011 18:09, Barry Leiba wrote: > If you do decide to start the charter discussion here, please keep it > to charter stuff, and save details for an SPF mailing list when it's > created. Some hopefully simple and hopefully harmless proposals for a charter: - 4408bis shall create (= define) a IANA registry of SPF modifiers based on the existing MARF draft. Rationale: that is what triggered this discussion. - 4408bis shall fix all 4408 errata listed on the RFC editor page and the corresponding openspf.org errata page (unmodified since 2008-08, same rationale as above). - 4408bis shall address potential abuses of the SPF "mx" mechanism in "security considerations" and/or suggest improved mitigations, if the WG decides that 4408 can be improved wrt DNS attacks. It is no rationale, but I think we can now say that the concerns of Doug Otis were slightly exaggerated (the Internet still exists), but no patent nonsense. - 4408bis may create a registry of DNS TXT and SPF RR "SPF version prefixes", if the WG decides that this would help with other uses of DNS TXT and SPF RRs (notably SenderId). Rationale: Maybe that could help with Dave Crocker's concerns and/or known EDNS0 limitations in practice; at least the WG should be free to tackle it (if desired). - 4408bis shall cover relevant results of the experiment since RFC 4408 was published. Rationale: Pointers to the existing SPF test suite and reference implementation can't be wrong, and EDNS0 observations in a recent "Netalyzr" publication are IMO also relevant. - 4408bis shall be on standards track, and contain any known relevant info for future SPF implementation reports. - 4408bis shall contain "i18n considerations" for the known "exp" URL case (here no news are good news), and its relation to EAI and IDNA. Rationale: Here be dragons. - 4408bis shall recommend the now existing proper mail header field in favour of its own Received-SPF header field. Rationale: It was still cute to create the first new trace header field in decades, or was it even the "first (period)"? Regards, Frank -- From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Thu Aug 11 10:40: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 81DA55E8013 for ; Thu, 11 Aug 2011 10:40:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6nxyQKzaQiD for ; Thu, 11 Aug 2011 10:40:24 -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 C732A5E8011 for ; Thu, 11 Aug 2011 10:40:24 -0700 (PDT) Received: by gwb20 with SMTP id 20so1738883gwb.31 for ; Thu, 11 Aug 2011 10:40:59 -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=7p0r+Ss/gvq1H1XIhey1T9V9zIZcgEZskRxV68rI11w=; b=bvrecV/TEQgujyuhlsFaKPArUct2BZJCiarmJxAXYUiu8BrFxlOttJX+mMy6FDIBu3 tJHs0mPT7CZhmOg83aW0jbvRbvvRGQXxVMiqc7RdGmJUN/vb3LpVO4SqbAuVUfn7gQot HqyeFPDAXxNvN9hlMywavtNdSmwPFkA5fCoA0= Received: by 10.142.196.17 with SMTP id t17mr2199489wff.276.1313084459059; Thu, 11 Aug 2011 10:40:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.157.2 with HTTP; Thu, 11 Aug 2011 10:40:39 -0700 (PDT) In-Reply-To: <4E4405F3.90101@dcrocker.net> References: <4E4112B4.7000905@tana.it> <201108092337.39408.scott@kitterman.com> <4E4405F3.90101@dcrocker.net> From: Frank Ellermann Date: Thu, 11 Aug 2011 19:40:39 +0200 Message-ID: To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Updating the status of SPF 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, 11 Aug 2011 17:40:25 -0000 On 11 August 2011 18:40, Dave CROCKER wrote: > What are the criteria you are using to determine what should be changed? As far as the errata are concerned, that was a process in the OpenSPF.org community reviewed on the mailing list (IIRC it was an "other IETF list" before 2008-08) and in the SPF Council. All results were published on , submitted to the RFC editor, and reviewed by the IESG in 2010-07, who recommended to tackle this in a new RFC: . -Frank From msk@cloudmark.com Thu Aug 11 10:41: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 9853521F86D2 for ; Thu, 11 Aug 2011 10:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.085 X-Spam-Level: X-Spam-Status: No, score=-103.085 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-TFoeI9zTc3 for ; Thu, 11 Aug 2011 10:41:57 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 371EF21F86C0 for ; Thu, 11 Aug 2011 10:41:57 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 11 Aug 2011 10:42:31 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org Discuss" Date: Thu, 11 Aug 2011 10:42:30 -0700 Thread-Topic: [apps-discuss] Updating the status of SPF Thread-Index: AcxYSbaCU1XVMJsHSM+BcOOmdoEoUgABC+sQ Message-ID: References: <20110809225415.89118.qmail@joyce.lan> <4E42BE19.9090609@tana.it> 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] Updating the status of SPF 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, 11 Aug 2011 17:41:57 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Frank Ellermann > Sent: Thursday, August 11, 2011 10:11 AM > To: Barry Leiba > Cc: apps-discuss@ietf.org Discuss > Subject: Re: [apps-discuss] Updating the status of SPF >=20 > - 4408bis shall cover relevant results of the experiment since RFC 4408 > was published. Rationale: Pointers to the existing SPF test suite > and reference implementation can't be wrong, and EDNS0 observations > in a recent "Netalyzr" publication are IMO also relevant. This might be addressed by publishing an implementation report akin to what= we typically produce when promoting something to Draft Standard, focused o= n "the experiment" and its results. From scott@kitterman.com Thu Aug 11 10:51: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 BDCEF21F8C81 for ; Thu, 11 Aug 2011 10:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vA5Wkxc0u49e for ; Thu, 11 Aug 2011 10:51:01 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2053921F8C80 for ; Thu, 11 Aug 2011 10:51:01 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 5E1CE38C131; Thu, 11 Aug 2011 13:51:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1313085095; bh=FtAQ5SfdIY3bKRI81aC0V4lIjS8YjuQUZZfz+C4FFEc=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=C9+AYD0L9C8Zc9PjgtKAe8iBI+bkMteIr6kq4AT4l2+tb+UHL6Ui33Sl+KmMZiwzZ i5NBESl6TL21TFgU8N5RUNF2aEf9LxLcEnvVMDkxD/sxbqBQweeqORWiNAl83mQ+n1 XTcqeYhcijLZ6jgmPYUu1wwYkQqdc7zR+3aFkcSA= From: Scott Kitterman To: apps-discuss@ietf.org Date: Thu, 11 Aug 2011 13:51:33 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic-pae; KDE/4.6.2; i686; ; ) References: <20110809225415.89118.qmail@joyce.lan> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108111351.34118.scott@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] Updating the status of SPF 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, 11 Aug 2011 17:51:01 -0000 On Thursday, August 11, 2011 01:10:50 PM Frank Ellermann wrote: > On 11 August 2011 18:09, Barry Leiba wrote: > > If you do decide to start the charter discussion here, please keep it > > to charter stuff, and save details for an SPF mailing list when it's > > created. > > Some hopefully simple and hopefully harmless proposals for a charter: I think these are all reasonable points for discussion. I am concerned that the charter should give weight to preserving backward compatibility. If there are severe problems that would require breaking backward compatibility, then obviously they can't be ignored, but the protocol has been widely used in production for many, many years and that installed base should not be abandoned lightly. There are some design points that could have been done better in hindsight, but I don't think these issues should be rehashed. I'm not sure in IETF terms what the best way to address this in a charter would be. Suggestions? Scott K From scott@kitterman.com Thu Aug 11 10:51: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 188A011E8078 for ; Thu, 11 Aug 2011 10:51: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+w7CpHFDqd9 for ; Thu, 11 Aug 2011 10:51:45 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5E10321F8C81 for ; Thu, 11 Aug 2011 10:51:35 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 01B7938C131; Thu, 11 Aug 2011 13:52:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1313085130; bh=PIj7wZKroGwJbwk+8T1SILPSQM5oozgJ3cN+S0MrEOQ=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=JtqsP5aAN53y8Xm/Z1tCLNjl7L2OIj0ODT5o0TyFlIZpmJUhhlTIc825gtMfcmJzU g5aUwstuv5DVFYxZX/37YaWo25dmHC7dpdhGto9IoBqLyuxYFXWAxg/ph5oA/QxPM4 LOOL3KkO/zjzFZOBLASzCuigzP9wfh9Va+PC/sGA= From: Scott Kitterman To: apps-discuss@ietf.org Date: Thu, 11 Aug 2011 13:52:08 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic-pae; KDE/4.6.2; i686; ; ) References: <20110809225415.89118.qmail@joyce.lan> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108111352.08909.scott@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] Updating the status of SPF 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, 11 Aug 2011 17:51:46 -0000 On Thursday, August 11, 2011 01:42:30 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org > > [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Frank Ellermann > > Sent: Thursday, August 11, 2011 10:11 AM > > To: Barry Leiba > > Cc: apps-discuss@ietf.org Discuss > > Subject: Re: [apps-discuss] Updating the status of SPF > > > > - 4408bis shall cover relevant results of the experiment since RFC 4408 > > > > was published. Rationale: Pointers to the existing SPF test suite > > and reference implementation can't be wrong, and EDNS0 observations > > in a recent "Netalyzr" publication are IMO also relevant. > > This might be addressed by publishing an implementation report akin to what > we typically produce when promoting something to Draft Standard, focused > on "the experiment" and its results. This is something I can work on. Scott K From msk@cloudmark.com Thu Aug 11 10:52: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 8FB5C21F8B84 for ; Thu, 11 Aug 2011 10:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.078 X-Spam-Level: X-Spam-Status: No, score=-103.078 tagged_above=-999 required=5 tests=[AWL=-0.479, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZASuRvjoH0h for ; Thu, 11 Aug 2011 10:52:49 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 1C76621F8B82 for ; Thu, 11 Aug 2011 10:52:49 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 11 Aug 2011 10:53:23 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Thu, 11 Aug 2011 10:53:22 -0700 Thread-Topic: [apps-discuss] Updating the status of SPF Thread-Index: AcxYT1Jg7Qe+JL5LSPiGW35726ZXOwAABM5w Message-ID: References: <20110809225415.89118.qmail@joyce.lan> <201108111351.34118.scott@kitterman.com> In-Reply-To: <201108111351.34118.scott@kitterman.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] Updating the status of SPF 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, 11 Aug 2011 17:52:49 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Scott Kitterman > Sent: Thursday, August 11, 2011 10:52 AM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Updating the status of SPF >=20 > I'm not sure in IETF terms what the best way to address this in a charter > would be. Suggestions? I would merely add a charter point saying something like "The working group= shall ensure that no changes are made that prevent full backward compatibi= lity with RFC4408 unless such changes are urgently needed." From scott@kitterman.com Thu Aug 11 10:57: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 7E55F21F8BF4 for ; Thu, 11 Aug 2011 10:57:22 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bn+6Hn9KrCK9 for ; Thu, 11 Aug 2011 10:57:21 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id D6AFD21F8BBA for ; Thu, 11 Aug 2011 10:57:21 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 3FE3638C131; Thu, 11 Aug 2011 13:57:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1313085476; bh=BLDQf/xUfymuZv/yr9wSg5Wh+9hrLQD7jolYz6OBASc=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=BDtiiqxg/AjdBTlocQCvTACFMlY7PA9gUdqmU2uv0IWSp4TVPBfYwpDEN7614i4KQ XC4JRTeINGB9X9aZt7/K8MPCqZIRze4zqla6ROREBSGWOGwJB+YFo+OoR0G0awxbx7 ECPevG1F4Fj5kdgSu8p1qT7Vb2NKGGQEDYHwpSoQ= From: Scott Kitterman To: apps-discuss@ietf.org Date: Thu, 11 Aug 2011 13:57:54 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic-pae; KDE/4.6.2; i686; ; ) References: <201108092337.39408.scott@kitterman.com> <4E4405F3.90101@dcrocker.net> In-Reply-To: <4E4405F3.90101@dcrocker.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108111357.54938.scott@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] Updating the status of SPF 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, 11 Aug 2011 17:57:22 -0000 On Thursday, August 11, 2011 12:40:19 PM Dave CROCKER wrote: > On 8/9/2011 8:37 PM, Scott Kitterman wrote: > > I've already started locally looking at what changes need to be made in > > RFC and updating the draft. There are a few errata, but I doubt there > > is a lot to do. > > Scott, > > What are the criteria you are using to determine what should be changed? > What is the basis for using those criteria? For example, what is the > likelihood that others in the community will agree with your choices? So far all I've done is work on getting circa middle of the last decade XML to work with the current xml2rfc and started to gather errata and other issues to consider. So far I haven't made any actual choices (that would be premature). My intent is to have an appendix in the draft (that would be removed before final publication) to describe changes so it's easy to determine what's different from 4408 (and when the time comes, previous revisions). I am, of course, open to feedback on this approach. Scott K From scott@kitterman.com Thu Aug 11 10:58: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 9C25021F8C00 for ; Thu, 11 Aug 2011 10:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAtwgBTXCpY2 for ; Thu, 11 Aug 2011 10:58:18 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3107921F8C07 for ; Thu, 11 Aug 2011 10:58:18 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id CDCBE38C131; Thu, 11 Aug 2011 13:58:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1313085532; bh=AE9GyG++fpKwOkahDSrFuBFCQZRqiN5gz1SSp4J7tXU=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=eWTZYDhW8A9eNNAgtVU5r4GRXm69gioxm3AKzdWAPzYwOaYZMSBd3Dxp/0/uCl8KV QY1t/rIGYmHZckKenFI+9BY5eXMP+Qx5LpYpbhMUE4UWPjmPNXDJXiA82Nsi52qQqG rvakieGarDWojuqsFaMgAcTqE/O1b6KLvKlgw+1o= From: Scott Kitterman To: apps-discuss@ietf.org Date: Thu, 11 Aug 2011 13:58:51 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic-pae; KDE/4.6.2; i686; ; ) References: <20110809225415.89118.qmail@joyce.lan> <201108111351.34118.scott@kitterman.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108111358.51671.scott@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] Updating the status of SPF 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, 11 Aug 2011 17:58:18 -0000 On Thursday, August 11, 2011 01:53:22 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org > > [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Scott Kitterman > > Sent: Thursday, August 11, 2011 10:52 AM > > To: apps-discuss@ietf.org > > Subject: Re: [apps-discuss] Updating the status of SPF > > > > I'm not sure in IETF terms what the best way to address this in a charter > > would be. Suggestions? > > I would merely add a charter point saying something like "The working group > shall ensure that no changes are made that prevent full backward > compatibility with RFC4408 unless such changes are urgently needed." That sounds good to me. Scott K From msk@cloudmark.com Thu Aug 11 10: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 D9AA021F8C00 for ; Thu, 11 Aug 2011 10:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.075 X-Spam-Level: X-Spam-Status: No, score=-103.075 tagged_above=-999 required=5 tests=[AWL=-0.476, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2+GRbWXV-pI for ; Thu, 11 Aug 2011 10:58:57 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC1921F8BF4 for ; Thu, 11 Aug 2011 10:58:57 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 11 Aug 2011 10:59:32 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Thu, 11 Aug 2011 10:59:31 -0700 Thread-Topic: [apps-discuss] Updating the status of SPF Thread-Index: AcxYUDVnyE5J+hIaQoKZLTC5t9uoswAAAz2Q Message-ID: References: <201108092337.39408.scott@kitterman.com> <4E4405F3.90101@dcrocker.net> <201108111357.54938.scott@kitterman.com> In-Reply-To: <201108111357.54938.scott@kitterman.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] Updating the status of SPF 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, 11 Aug 2011 17:58:58 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Scott Kitterman > Sent: Thursday, August 11, 2011 10:58 AM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Updating the status of SPF >=20 > My intent is to have an appendix in the draft (that would be removed befo= re > final publication) to describe changes so it's easy to determine what's > different from 4408 (and when the time comes, previous revisions). That's a BCP for these sorts of things, I've found. For RFC4871bis, a lot = of text changed, but very little was protocol-related. It was important to= have that summary in the document and also to have the output of "rfcdiff"= comparing them available for perusal. > I am, of course, open to feedback on this approach. WFM so far. From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Thu Aug 11 12:10: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 6C3B621F8C3A for ; Thu, 11 Aug 2011 12:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.662 X-Spam-Level: X-Spam-Status: No, score=-102.662 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrsVbqqzLiSl for ; Thu, 11 Aug 2011 12:10:26 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4B421F8C29 for ; Thu, 11 Aug 2011 12:10:25 -0700 (PDT) Received: by pzk33 with SMTP id 33so8376194pzk.18 for ; Thu, 11 Aug 2011 12:11:00 -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=gAppZRm3L1Qk2mQjXV09UxGcP34GlbihrKeqbSkHDkY=; b=uanvMwNV4B1iHA6g2LvpLH1GJ1y49JXYMdtz6AvhhxU5n3jjNOXY5FnHCHZ+53KYR2 QyKuschvouLLVQT2qagNS7NttHpu2jxNMtVGKLzKsY4x8Vwj6stwh+d2utWuXapTVUPb FOKyFFwzD01TjehF7zzMkx17zpzhA53qZaLPk= Received: by 10.142.166.5 with SMTP id o5mr1130515wfe.390.1313089860217; Thu, 11 Aug 2011 12:11:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.157.2 with HTTP; Thu, 11 Aug 2011 12:10:40 -0700 (PDT) In-Reply-To: References: <201108092337.39408.scott@kitterman.com> <4E4405F3.90101@dcrocker.net> <201108111357.54938.scott@kitterman.com> From: Frank Ellermann Date: Thu, 11 Aug 2011 21:10:40 +0200 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Updating the status of SPF 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, 11 Aug 2011 19:10:41 -0000 On 11 August 2011 19:59, Murray S. Kucherawy wrote: > WFM so far. Same here after figuring out that this means "works for me". There used to be a kind of consensus in the OpenSPF community, that any future version (neither v=spf1 nor spf2.0/anything) shall use only DNS SPF RRs (not TXT), and the WG should be free to say so in 4408bis if desired. The WG should be also free to say that spf2.0/anything for "mfrom" is now considered as obsolescete for the purposes of v=spf1, with more details to be determined by the WG as desired. I'd like to have it clear that 4408bis does not require or care about any spf2.0/mfrom records as noted in RFC 4406 section 4.4 clause 3, and that 4408bis shall be interpreted as specified in 4408bis, notably not as in RFC 4406 section 4.4 clause 4. This issue is already covered in the RFC 4408 security considerations, and in its IESG note at the begin, therefore 440bis should have this as clear as possible. An attempt to combine this proposal with Barry's concerns: "The WG shall not try to update other RFCs, notably 4405, 4406, 4407, or 5321/5322, but may address the spf2.0/mfrom or hypothetical spf2.0/helo scopes wrt 4408bis security considerations." -Frank From barryleiba.mailing.lists@gmail.com Thu Aug 11 12:37: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 C33CC21F8B4A for ; Thu, 11 Aug 2011 12:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.043 X-Spam-Level: X-Spam-Status: No, score=-103.043 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eETEuLVK7em9 for ; Thu, 11 Aug 2011 12:37:51 -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 3AD6B21F8B48 for ; Thu, 11 Aug 2011 12:37:51 -0700 (PDT) Received: by yie12 with SMTP id 12so1825238yie.31 for ; Thu, 11 Aug 2011 12:38:26 -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=B+O3QBBRozpHO0DWeIM/FWnC6SmyytFV499yftguGeE=; b=vkCc7bfGgJZAcm2pHcDe1r1gEkFRH3bHHiiMOcDxg0RL7LNxtFwJj6mGnThHfKIrvc NAJF7LXLeUmE7mhZf2m5tnYBdSDAi0dZF5INfLBd1ZW51Ker+yG1uBw0zCdEFKXFyOTF 2vqGEzyjexDQp/odcxtaHOIX0SUtyi0cLpM2w= MIME-Version: 1.0 Received: by 10.146.140.9 with SMTP id n9mr7222yad.39.1313091505469; Thu, 11 Aug 2011 12:38:25 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.181.13 with HTTP; Thu, 11 Aug 2011 12:38:25 -0700 (PDT) In-Reply-To: References: <20110809225415.89118.qmail@joyce.lan> <201108111351.34118.scott@kitterman.com> Date: Thu, 11 Aug 2011 15:38:25 -0400 X-Google-Sender-Auth: VDDJGZNCDL0FPt2HaYII10cqIBg 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] Updating the status of SPF 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, 11 Aug 2011 19:37:51 -0000 > I would merely add a charter point saying something like "The working group > shall ensure that no changes are made that prevent full backward compatibility > with RFC4408 unless such changes are urgently needed." I think the real point here is not just to *say* that, but to explain what's going on. Put it in the context of what the WG *is* and *isn't* doing at this stage. That means that what you want to say is that the working group is, at this charter stage, documenting the *existing*, widely implemented protocol, which has sufficiently broad, interoperable deployment to be on Standards Track. Say that there are suggestions for changes that are not part of the current widespread implementation, some of which are not backward compatible, and that *all* these changes (whether backward compatible or not) could be in scope for a future recharter or new working group, but are not in scope here. Barry, as participant From scott@kitterman.com Thu Aug 11 12:45: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 5271B11E808A for ; Thu, 11 Aug 2011 12:45:35 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuczNbSyniiD for ; Thu, 11 Aug 2011 12:45:34 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8B86F11E807C for ; Thu, 11 Aug 2011 12:45:34 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 4893938C131; Thu, 11 Aug 2011 15:46:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1313091969; bh=dTRqxKwZgyF+dtt2CGd6mYXuJxgmnBSWtPOPAGnn2Pw=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=prs8kMc87LtV9Q3weznwCN2bhEPyxQMPH+ukwhQt69WzBbc86ohRpXM4etqo5bFsS qjA8YFsam3zo1VxB2PvbhZf8fw1G9Liif1aX3X4BFhJ1Zo772jUYsjjICTuG1vN5SI f+NR9Igiyq+DsLfb24aUo1eEQPUeE5FTQu2fsjQE= From: Scott Kitterman To: apps-discuss@ietf.org Date: Thu, 11 Aug 2011 15:46:05 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic-pae; KDE/4.6.2; i686; ; ) References: <201108092337.39408.scott@kitterman.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108111546.05901.scott@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] Updating the status of SPF 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, 11 Aug 2011 19:45:35 -0000 On Thursday, August 11, 2011 03:10:40 PM Frank Ellermann wrote: > On 11 August 2011 19:59, Murray S. Kucherawy wrote: > > WFM so far. > > Same here after figuring out that this means "works for me". There used to > be a kind of consensus in the OpenSPF community, that any future version > (neither v=spf1 nor spf2.0/anything) shall use only DNS SPF RRs (not TXT), > and the WG should be free to say so in 4408bis if desired. I disagree. Type SPF has almost zero deployment, so using only Type SPF is not consistent with preserving the installed base. > The WG should be also free to say that spf2.0/anything for "mfrom" is now > considered as obsolescete for the purposes of v=spf1, with more details > to be determined by the WG as desired. I'd like to have it clear that > 4408bis does not require or care about any spf2.0/mfrom records as noted > in RFC 4406 section 4.4 clause 3, and that 4408bis shall be interpreted > as specified in 4408bis, notably not as in RFC 4406 section 4.4 clause 4. > > This issue is already covered in the RFC 4408 security considerations, and > in its IESG note at the begin, therefore 440bis should have this as clear > as possible. An attempt to combine this proposal with Barry's concerns: > > "The WG shall not try to update other RFCs, notably 4405, 4406, 4407, or > 5321/5322, but may address the spf2.0/mfrom or hypothetical spf2.0/helo > scopes wrt 4408bis security considerations." I don't think the WG should do anything in 4408bis beyond updating 4408. I don't think there's a need for any drafts relative to 4405/6/7 other than the one that declares them historic. We can debate the DNS type issue later on the appropriate list once we have a solid charter. If you feel the need, I think "The WG shall not try to update other RFCs." is sufficient. Scott K From julian@mehnle.net Thu Aug 11 14:09: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 F043D21F8AE6 for ; Thu, 11 Aug 2011 14:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLW6U6MX14pE for ; Thu, 11 Aug 2011 14:09:37 -0700 (PDT) Received: from io.link-m.de (io.link-m.de [82.135.8.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3989721F884C for ; Thu, 11 Aug 2011 14:09:37 -0700 (PDT) Received: from [10.0.2.15] (static-72-81-252-21.bltmmd.fios.verizon.net [::ffff:72.81.252.21]) (AUTH: CRAM-MD5 julian@mehnle.net, TLS: TLSv1/SSLv3, 256bits, AES256-SHA) by io.link-m.de with esmtp; Thu, 11 Aug 2011 21:10:09 +0000 id 000000000014901B.000000004E444531.00007498 From: Julian Mehnle To: apps-discuss@ietf.org Date: Thu, 11 Aug 2011 21:10:03 +0000 User-Agent: KMail/1.9.9 References: <201108092337.39408.scott@kitterman.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2055963.Rcxim0pWXc"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201108112110.07285.julian@mehnle.net> Subject: Re: [apps-discuss] Updating the status of SPF 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, 11 Aug 2011 21:09:38 -0000 --nextPart2055963.Rcxim0pWXc Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =46rank Ellermann wrote: > The WG should be also free to say that spf2.0/anything for "mfrom" is > now considered as obsolescete for the purposes of v=3Dspf1, with more > details to be determined by the WG as desired. I'd like to have it > clear that 4408bis does not require or care about any spf2.0/mfrom > records as noted in RFC 4406 section 4.4 clause 3, and that 4408bis > shall be interpreted as specified in 4408bis, notably not as in RFC > 4406 section 4.4 clause 4. > > This issue is already covered in the RFC 4408 security considerations, > and in its IESG note at the begin, therefore 440bis should have this as > clear as possible. [...] Whereas the note in the security considerations could be expanded or=20 supported with whatever relevant evidence exists, I don't think 4408bis=20 should even mention "spf2.0" or any of the 440{5,6,7} RFCs. It never=20 has, and I don't see a need for it to start doing so now. =2DJulian --nextPart2055963.Rcxim0pWXc Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAk5ERSwACgkQwL7PKlBZWjuifQCffPPYrwnKvIv6wLyOLS8GiA0D LV4An3ouKLxQeGM5AYCrEgYaw2BOIR5B =q74j -----END PGP SIGNATURE----- --nextPart2055963.Rcxim0pWXc-- From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Thu Aug 11 14: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 77D0621F8B4A for ; Thu, 11 Aug 2011 14:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.678 X-Spam-Level: X-Spam-Status: No, score=-102.678 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrGNeCBNoMYl for ; Thu, 11 Aug 2011 14:18:51 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id DB24E21F8B51 for ; Thu, 11 Aug 2011 14:18:50 -0700 (PDT) Received: by pzk33 with SMTP id 33so6484pzk.18 for ; Thu, 11 Aug 2011 14:19:26 -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=Nx+K7Puxic/zxdkUR3nMVqNygtuVHjzdh78THPYr5Oo=; b=hX6xEhCUxRFTXFFl+xOS6HM5a+46vwhVwISYawdMQlejrZUC37XqbfPuooalCV6Alb U2YzQTRK1EMQMMYxZ03cgQYpE+iOWC90btxtzJxjEfsrBlFbFYXOMX8qYBoiLVJRs1A1 7SlUh/EU+xLAaTIVR+JiPk+cdulxLx+SymJ6g= Received: by 10.142.229.18 with SMTP id b18mr47596wfh.333.1313097566101; Thu, 11 Aug 2011 14:19:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.157.2 with HTTP; Thu, 11 Aug 2011 14:19:06 -0700 (PDT) In-Reply-To: <201108111546.05901.scott@kitterman.com> References: <201108092337.39408.scott@kitterman.com> <201108111546.05901.scott@kitterman.com> From: Frank Ellermann Date: Thu, 11 Aug 2011 23:19:06 +0200 Message-ID: To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Updating the status of SPF 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, 11 Aug 2011 21:18:51 -0000 On 11 August 2011 21:46, Scott Kitterman wrote: > I disagree. Are you sure? I wasn't talking about what works and is installed, but about any future versions. The IETF can certainly say what it intends to do with the SPF RR, and it could even conclude that this was one of the things that turned out to be bad ideas in both experiment(s). But I'd still say that "let's just (ab)use TXT" is not more necessary for any "SPF 3" or "SenderID 3" as long as the SPF RR exists. If you insist on it the WG should IMHO still be free to say whatever it likes to say about the type 99 DNS SPF RR; maybe kill it for good. > Type SPF has almost zero deployment, so using only Type SPF is not > consistent with preserving the installed base. We certainly don't disagree here, and this should be documented in a 4408bis. Willing or not, in that case the SenderID experiment would be forced to follow suit, because it is one of the points where it is based on RFC 4408. If the OpenSPF community arrived at new conclusions about the SPF RR after the end of 2008 I missed it, please correct anything I write where that might be the case. >=A0I don't think there's a need for any drafts relative to 4405/6/7 other > than the one that declares them historic. That would obviously solve the historic incompatibility between 4406 and 4408; and I'd be happy with any solution for 4408bis. Above all nobody should be forced to explain how the IETF managed to start two subtly incompatible experiments after a new 4408bis is published. > If you feel the need, I think "The WG shall not try to update other > RFCs." is sufficient. I feel the need to get rid of the incompatibility, and don't care how this is done, as long as it is "thorough" :-) -Frank From ajs@anvilwalrusden.com Thu Aug 11 14:35: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 3DF2F21F8B7F for ; Thu, 11 Aug 2011 14:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0USlwc0QKM2 for ; Thu, 11 Aug 2011 14:35:54 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 1816F21F8B7B for ; Thu, 11 Aug 2011 14:35:54 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id B154C1ECB41D for ; Thu, 11 Aug 2011 21:36:29 +0000 (UTC) Date: Thu, 11 Aug 2011 17:36:26 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20110811213626.GU95640@shinkuro.com> References: <201108092337.39408.scott@kitterman.com> <201108111546.05901.scott@kitterman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] Updating the status of SPF 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, 11 Aug 2011 21:35:55 -0000 On Thu, Aug 11, 2011 at 11:19:06PM +0200, Frank Ellermann wrote: > > If you insist on it the WG should IMHO still be free to say whatever > it likes to say about the type 99 DNS SPF RR; maybe kill it for good. The plain fact is that once a DNS RRTYPE is allocated, it can't be "killed". You can deprecate its use and tell new software not to look it up. But the code point will remain assigned, I predict, until we stop using the DNS (which, at the rate we are adding lard to spackle to baling-wire, might be any day now, but that's a digression for another list). For the little it us no doubt worth, it is the "TXT is now used everywhere, and so we're not going to deprecate that even in new versions of the protocol, pppptttthhht" argument that annoys people who see the problems with TXT records whenever they're overloaded in yet another protocol. In effect, once you adopt TXT, you're going to use it forever. This same attitude is why we still have A-record MX fallback all these years later. But I do agree that, if people are wedded to using their bad idea forever, one isn't going to change their mind, and it is silly to have two mechanisms for achieving the same goal one of which is never used (particularly if it causes additional DNS load). A -- Andrew Sullivan ajs@anvilwalrusden.com From msk@cloudmark.com Thu Aug 11 14:40: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 1C78111E8081 for ; Thu, 11 Aug 2011 14:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYKxU5KoL7Ef for ; Thu, 11 Aug 2011 14:40:27 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA5311E8080 for ; Thu, 11 Aug 2011 14:40:27 -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, 11 Aug 2011 14:41:02 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Thu, 11 Aug 2011 14:41:01 -0700 Thread-Topic: [apps-discuss] Updating the status of SPF Thread-Index: AcxYbr1GpxWkEhFZR/C/pybU32EaRQAACh9g Message-ID: References: <201108092337.39408.scott@kitterman.com> <201108111546.05901.scott@kitterman.com> <20110811213626.GU95640@shinkuro.com> In-Reply-To: <20110811213626.GU95640@shinkuro.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] Updating the status of SPF 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, 11 Aug 2011 21:40:28 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Andrew Sullivan > Sent: Thursday, August 11, 2011 2:36 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Updating the status of SPF >=20 > This same attitude is why we still have A-record MX > fallback all these years later. This is the first time I've heard someone lament that old RFC974 provision.= I'll have to ask you to elaborate someday. > But I do agree that, if people are wedded to using their bad idea > forever, one isn't going to change their mind, and it is silly to have > two mechanisms for achieving the same goal one of which is never used > (particularly if it causes additional DNS load). I'm viewing this more and more as something we should handle the same as a = PS-DS promotion; do an interoperability report (in this case, about "the ex= periment"), remove unused stuff, generally tidy up, resolve errata, and all= ow nothing else. That SPF used TXT the way it did may be unfortunate, but as you said, we're= not going to change it. We should document the discussion and the results= of years of deployment, hold our noses and live with it. I'd also be fine= with including verbose admonitions to future protocol designers NOT to use= this as an example of possible TXT use in future protocols. From scott@kitterman.com Thu Aug 11 15:06: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 B1A3E11E8091 for ; Thu, 11 Aug 2011 15:06:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrDgkAMx3S6t for ; Thu, 11 Aug 2011 15:06:33 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id C63C011E808E for ; Thu, 11 Aug 2011 15:06:33 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 7F44C38C131; Thu, 11 Aug 2011 18:07:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1313100427; bh=WnOpvXEAChduYENOfIGWzObnA0fens3No8BSJ32vgwo=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=SyHtHOTZLWwIgn9NzN4/HKfhhOwfZtGlecFdVPdZb1WorSFtmoCLhUdoLEywnc1eV FBf6A1wl34Rlmkqah5YxPO9N2Q47wmXgWpWO3mIs804lVgSiA2dak8OYODjeE1z9dr EqwrxF7GzZvCUQV/Bz7HZ0o27EK9JYZgCZyIy2sM= From: Scott Kitterman To: apps-discuss@ietf.org Date: Thu, 11 Aug 2011 18:07:04 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic-pae; KDE/4.6.2; i686; ; ) References: <201108092337.39408.scott@kitterman.com> <20110811213626.GU95640@shinkuro.com> In-Reply-To: <20110811213626.GU95640@shinkuro.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108111807.05405.scott@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] Updating the status of SPF 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, 11 Aug 2011 22:06:34 -0000 On Thursday, August 11, 2011 05:36:26 PM Andrew Sullivan wrote: > On Thu, Aug 11, 2011 at 11:19:06PM +0200, Frank Ellermann wrote: > > If you insist on it the WG should IMHO still be free to say whatever > > it likes to say about the type 99 DNS SPF RR; maybe kill it for good. > > The plain fact is that once a DNS RRTYPE is allocated, it can't be > "killed". You can deprecate its use and tell new software not to look > it up. But the code point will remain assigned, I predict, until we > stop using the DNS (which, at the rate we are adding lard to spackle > to baling-wire, might be any day now, but that's a digression for > another list). > > For the little it us no doubt worth, it is the "TXT is now used > everywhere, and so we're not going to deprecate that even in new > versions of the protocol, pppptttthhht" argument that annoys people > who see the problems with TXT records whenever they're overloaded in > yet another protocol. In effect, once you adopt TXT, you're going to > use it forever. This same attitude is why we still have A-record MX > fallback all these years later. > > But I do agree that, if people are wedded to using their bad idea > forever, one isn't going to change their mind, and it is silly to have > two mechanisms for achieving the same goal one of which is never used > (particularly if it causes additional DNS load). I feel strongly that the 4408bis effort we are discussing now should be a minimal/backwards compatible_unless_it_is_impossible update. Once that is complete there is a backlog of incompatible design ideas for simplifying and improving SPF. In that context I think moving to Type SPF only makes a lot of sense and should be considered. I don't want to get that mixed in with the current effort. I, for one, am certainly not wedded to the idea of using TXT forever. Scott K From jdfalk-lists@cybernothing.org Thu Aug 11 15:39: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 0E4DB11E808E for ; Thu, 11 Aug 2011 15:39:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6hHSiFj-rFg for ; Thu, 11 Aug 2011 15:39:48 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD9F11E8080 for ; Thu, 11 Aug 2011 15:39:48 -0700 (PDT) Received: from [192.168.11.39] (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 p7BMeL9M010066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 11 Aug 2011 15:40:23 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p7BMeL9M010066 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=fudge; t=1313102423; bh=ChFTnVkJ2SnR9SAj4n26Og7+ETl75rb/M1PJf5dk9 hc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=MZNfK3CZkdOk tmUxUFIooUtreiNbrekKtmMNSdx7UXDktaF0pn6zXBdduplZ4Vm5IQN5jlg3+o1NGAt u3UKl4zfNyQLulWbAFrZg5gD+9euUPpo5q3h2ccuh09DSEYh2hzeYQYMgiQJjoKE4uA YWEcd5ETqZ/cIuelTI6SSHT9Y= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: Date: Thu, 11 Aug 2011 15:40:20 -0700 Content-Transfer-Encoding: 7bit Message-Id: <7FEA5F1D-9E0B-4F81-9425-75585B39239B@cybernothing.org> References: <20110809225415.89118.qmail@joyce.lan> <201108111351.34118.scott@kitterman.com> To: "apps-discuss@ietf.org Discuss" X-Mailer: Apple Mail (2.1084) Subject: Re: [apps-discuss] Updating the status of SPF 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, 11 Aug 2011 22:39:49 -0000 On Aug 11, 2011, at 12:38 PM, Barry Leiba wrote: > That means that what you want to say is that the working group is, at > this charter stage, documenting the *existing*, widely implemented > protocol, which has sufficiently broad, interoperable deployment to be > on Standards Track. Say that there are suggestions for changes that > are not part of the current widespread implementation, some of which > are not backward compatible, and that *all* these changes (whether > backward compatible or not) could be in scope for a future recharter > or new working group, but are not in scope here. +1 Otherwise, this WG will be little more than a big drawn-out argument. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Thu Aug 11 16:52: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 0591811E80B4 for ; Thu, 11 Aug 2011 16:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.692 X-Spam-Level: X-Spam-Status: No, score=-102.692 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9+mMYHUgy85 for ; Thu, 11 Aug 2011 16:52:12 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 856E811E809B for ; Thu, 11 Aug 2011 16:52:12 -0700 (PDT) Received: by pzk33 with SMTP id 33so333268pzk.18 for ; Thu, 11 Aug 2011 16:52:48 -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 :content-transfer-encoding; bh=XIHj85EAPhptDA+E1AeNLW9LdQAKoCYsmVaevYWHCOE=; b=Dm1ddwDyGKqR3ZD59tK+oeYX5TLFeM/MXEMt4zy924ENkFx/tTl2PQbDt5DnuTHJaM 0i0OfwFen94sYmifiwxbkUrpHa9WeK0v4CL4hYoT7uBoAef7VgY9NYW2ONp+RdV3z9p9 gpWS84L/88nbCLTRHREpZ3Km617yDPMnUoKgw= Received: by 10.142.229.18 with SMTP id b18mr121927wfh.333.1313106768145; Thu, 11 Aug 2011 16:52:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.157.2 with HTTP; Thu, 11 Aug 2011 16:52:28 -0700 (PDT) From: Frank Ellermann Date: Fri, 12 Aug 2011 01:52:28 +0200 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] AAAA and other creatures (was: Updating the status of SPF) 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, 11 Aug 2011 23:52:13 -0000 On 11 August 2011 23:41, Murray S. Kucherawy wrote: > This is the first time I've heard someone lament that old RFC974 > provision. =A0I'll have to ask you to elaborate someday. During the work on RFC 5321 folks suggested to limit the A fallback to IPv4, and not use an AAAA fallback for IPv6. Anything potentially in conflict with the plan to get new STDs for SMTP and the message format did not make it into 5321/2, and I was rather surprised that 5321/2 are nevertheless no STDs. > I'm viewing this more and more as something we should handle the same > as a PS-DS promotion; do an interoperability report (in this case, > about "the experiment"), remove unused stuff, generally tidy up, > resolve errata, and allow nothing else. > That SPF used TXT the way it did may be unfortunate, but as you said, > we're not going to change it. =A0We should document the discussion and > the results of years of deployment, hold our noses and live with it. >=A0I'd also be fine with including verbose admonitions to future protocol > designers NOT to use this as an example of possible TXT use in future > protocols. Let the WG at least adopt your RFC 5451 and deprecate "Received-SPF". IIRC there were SPF Council resolutions supporting the I-Ds now known as RFC 5451. Disclaimer, if there is anything wrong with that idea I missed it. -Frank From julian@mehnle.net Thu Aug 11 20:04: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 9993D21F8B04 for ; Thu, 11 Aug 2011 20:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmNFjF386saY for ; Thu, 11 Aug 2011 20:04:30 -0700 (PDT) Received: from io.link-m.de (io.link-m.de [82.135.8.34]) by ietfa.amsl.com (Postfix) with ESMTP id 11AE421F8506 for ; Thu, 11 Aug 2011 20:04:29 -0700 (PDT) Received: from [10.0.2.15] (static-72-81-252-21.bltmmd.fios.verizon.net [::ffff:72.81.252.21]) (AUTH: CRAM-MD5 julian@mehnle.net, TLS: TLSv1/SSLv3, 256bits, AES256-SHA) by io.link-m.de with esmtp; Fri, 12 Aug 2011 03:04:38 +0000 id 000000003044874B.000000004E449847.00001740 From: Julian Mehnle To: apps-discuss@ietf.org Date: Fri, 12 Aug 2011 03:04:36 +0000 User-Agent: KMail/1.9.9 References: <20110809225415.89118.qmail@joyce.lan> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1444594.v2kV22PSei"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201108120304.36309.julian@mehnle.net> Subject: Re: [apps-discuss] Updating the status of SPF 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, 12 Aug 2011 03:04:30 -0000 --nextPart1444594.v2kV22PSei Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Barry Leiba wrote: > That means that what you want to say is that the working group is, at > this charter stage, documenting the *existing*, widely implemented > protocol, which has sufficiently broad, interoperable deployment to be > on Standards Track. Say that there are suggestions for changes that > are not part of the current widespread implementation, some of which > are not backward compatible, and that *all* these changes (whether > backward compatible or not) could be in scope for a future recharter > or new working group, but are not in scope here. Yes, *please* let's avoid any slippery slopes, lest this effort goes down=20 the drain. =2DJulian --nextPart1444594.v2kV22PSei Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAk5EmEQACgkQwL7PKlBZWju3vwCgos5z9uaC5/mLtk0AXY43wK9U xsYAn308C4OZT2W8ek8MOUD/M5ibVq8x =rVr6 -----END PGP SIGNATURE----- --nextPart1444594.v2kV22PSei-- From evnikita2@gmail.com Thu Aug 11 20:35: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 6B31521F86B9; Thu, 11 Aug 2011 20:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.365 X-Spam-Level: X-Spam-Status: No, score=-3.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvuIM5U4hjss; Thu, 11 Aug 2011 20:35:20 -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 44A6E21F8686; Thu, 11 Aug 2011 20:35:20 -0700 (PDT) Received: by fxe6 with SMTP id 6so2311960fxe.31 for ; Thu, 11 Aug 2011 20:35:55 -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=30weRZ82ideR9RCpOHC6AAarjkBJ0ZDjSgMqOcbIJiU=; b=Fd91rDicXHxcF5UX1ENQVyoC/3hJeNx+gHx5LsSjTnCH3eHstAI/ruhRHB9bcYT9FT MI0mtCxkP/9hva3U3x/dNNJJX6nEB2IEPffNbPqTwpSUM1CnAxRLtOFl+omUD/Xg6X+z xxYV0b9YQa8VvtVRtGb66HnPmgbvHrYjIH/Yo= Received: by 10.223.156.80 with SMTP id v16mr589771faw.11.1313120155471; Thu, 11 Aug 2011 20:35:55 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id f27sm2065051fak.31.2011.08.11.20.35.53 (version=SSLv3 cipher=OTHER); Thu, 11 Aug 2011 20:35:54 -0700 (PDT) Message-ID: <4E449FBF.8050807@gmail.com> Date: Fri, 12 Aug 2011 06:36: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: Barry Leiba References: <4E34DC83.30504@gmail.com> In-Reply-To: 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] [Uri-review] 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: Fri, 12 Aug 2011 03:35:21 -0000 09.08.2011 21:52, Barry Leiba wrote: > It's been a week and a half since the original message was posted, but > I had to discuss this with the other appsawg chairs, the ftpext2 > chairs, and the Applications ADs. > > On Sun, Jul 31, 2011 at 12:39 AM, Mykyta Yevstifeyev > wrote: >> Sorry for cross-posting to 6 addresses :-); please send all your comments to >> apps-discuss@ietf.org. > No, please do not. This document is NOT to be discussed on apps-discuss. > 1. It will not be processed in the appsawg. > 2. The ftpext2 chairs have told me that it will not be processed in > ftpext2. It is not in their charter, and the WG is not interested in > rechartering to add it. > 3. The Apps ADs have told me that they will not sponsor it as an > individual submission. > > In other words, as an IETF document, this is dead. There is > insufficient energy and interest in the IETF to hash this document > out. Please do not continue work on this document. In any case, > please do not discuss it on the apps-discuss mailing list. Barry, I'm very unlikely to stop working on the document. Anyway, nothing in your message disallows me to wait for better times, when the situation changes. Mykyta > > Barry Leiba, appsawg chair > >>> 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 > _______________________________________________ > Uri-review mailing list > Uri-review@ietf.org > https://www.ietf.org/mailman/listinfo/uri-review > From msk@cloudmark.com Thu Aug 11 20: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 BB1A821F8581 for ; Thu, 11 Aug 2011 20:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trHbKJ88H+bw for ; Thu, 11 Aug 2011 20:49:52 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3EF21F857E for ; Thu, 11 Aug 2011 20:49:52 -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, 11 Aug 2011 20:50:28 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Thu, 11 Aug 2011 20:50:26 -0700 Thread-Topic: AAAA and other creatures (was: Updating the status of SPF) Thread-Index: AcxYgcxynATqIXx8QxOsh0OkBrdieQAIK7Zw Message-ID: References: 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] AAAA and other creatures (was: Updating the status of SPF) 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, 12 Aug 2011 03:49:52 -0000 > -----Original Message----- > From: Frank Ellermann [mailto:hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com] > Sent: Thursday, August 11, 2011 4:52 PM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org > Subject: AAAA and other creatures (was: Updating the status of SPF) >=20 > Let the WG at least adopt your RFC 5451 and deprecate "Received-SPF". > IIRC there were SPF Council resolutions supporting the I-Ds now known > as RFC 5451. Disclaimer, if there is anything wrong with that idea I > missed it. If there's an interoperability report produced that shows that the industry= in general has dropped Received-SPF in favor of Authentication-Results, th= en I can't imagine this change would meet with much resistance. -MSK From evnikita2@gmail.com Thu Aug 11 21:08: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 180DA21F859F for ; Thu, 11 Aug 2011 21:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZjVbWZIpUAm for ; Thu, 11 Aug 2011 21:08:15 -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 0D81221F859C for ; Thu, 11 Aug 2011 21:08:14 -0700 (PDT) Received: by fxe6 with SMTP id 6so2322099fxe.31 for ; Thu, 11 Aug 2011 21:08:50 -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=+u1tvaFgdXS48Lq0O30451VjOVqP//PAZrCZyMEBdXQ=; b=TSQf58ZujBuOL3rDMcWhR+nbSSPt/JhP2kt6wRG4lA9Oj6CIbYnzZs3mG8dSbRULN0 rNXmJD3t74s0QMLbMI6OMZJ6OYSCDmBjUQ7A8J7SAD/GUbbzcQCnB4yqiWuRm+IatbCK n4/JmD3/rpXD9OZcUAnP1/4VhM6L1jZddrZ2M= Received: by 10.223.55.209 with SMTP id v17mr583258fag.77.1313122130487; Thu, 11 Aug 2011 21:08:50 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id y15sm2079293fah.35.2011.08.11.21.08.48 (version=SSLv3 cipher=OTHER); Thu, 11 Aug 2011 21:08:49 -0700 (PDT) Message-ID: <4E44A777.3000902@gmail.com> Date: Fri, 12 Aug 2011 07:09: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: apps-discuss@ietf.org References: <20110726125042.1180.12955.idtracker@ietfa.amsl.com> <4E2EBA34.5090604@stpeter.im> In-Reply-To: <4E2EBA34.5090604@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 12 Aug 2011 04:08:16 -0000 Peter, I think your document should be clear whether it affects the "vnd." construction, used, eg., as I remember, in MIME media types and elsewhere. With respect to existing IANA policies regarding assignment and registration values beginning in "X-". I suppose IANA should continue to follow those policies which were set by the corresponding documents, in order not to create the influx of registrations of "X-" values. However, when the "X-" convention is deprecated, new protocols will not need to set such policy; so no changes for IANA are necessary now. Mykyta Yevstifeyev 26.07.2011 15:59, Peter Saint-Andre wrote: > 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 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From vesely@tana.it Fri Aug 12 03:51: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 63BA521F875E for ; Fri, 12 Aug 2011 03:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOR24UfDmNeA for ; Fri, 12 Aug 2011 03:51:27 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5B18D21F8757 for ; Fri, 12 Aug 2011 03:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1313146321; bh=BBDW1Gl2ddByVpEgVWlXds5DBQJ6I18gdYN2KMxDbfM=; l=1927; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=duRA+zDb+EBcJtBDB0B19w7pSCSoCe3ouFWL0/63pOAahzttILxs7DB+apWWZsBnY WLmXStZZSvVAcz51mpHaeOEfwqrDUlGSExXfecoZ35iO068r9OnwAl//b3wyL7cK93 VU75o2cy6AnJENApYdmvYAWxH0W4O7fqKPzX04NA= Received: from [109.113.156.103] (softdnserr [109.113.156.103]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 12 Aug 2011 12:51:59 +0200 id 00000000005DC039.000000004E4505CF.000037E0 Message-ID: <4E450590.7010809@tana.it> Date: Fri, 12 Aug 2011 12:50:56 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <201108092337.39408.scott@kitterman.com> <201108111546.05901.scott@kitterman.com> <20110811213626.GU95640@shinkuro.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Updating the status of SPF 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, 12 Aug 2011 10:51:28 -0000 On 11.08.2011 23:41, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Andrew Sullivan >> But I do agree that, if people are wedded to using their bad idea >> forever, one isn't going to change their mind, and it is silly to have >> two mechanisms for achieving the same goal one of which is never used >> (particularly if it causes additional DNS load). > > That SPF used TXT the way it did may be unfortunate, but as you said, > we're not going to change it. We should document the discussion and the > results of years of deployment, hold our noses and live with it. I'd also > be fine with including verbose admonitions to future protocol designers > NOT to use this as an example of possible TXT use in future protocols. Actually, SPF has already paved the way for a number of other protocols. To quote John Levine: We in the DKIM community were lucky that the SPFers already had those arrows in their backs. http://www.ietf.org/mail-archive/web/domainrep/current/msg00378.html The discussion was quite thorough, and, if I haven't misread it, the conclusion was that TXT records are the best option for this kind of use, although such specs formally pollute a non-controlled namespace --somewhat mitigated by leading underscores. How about this? The working group shall document the existing, widely implemented protocol, which has sufficiently broad, interoperable deployment to be on Standards Track. Capitalizing on the experience gained in the experiment, and taking advantage from newly established protocols, the working group may propose alternatives to the existing practices, or deprecate some of them, provided that all introduced changes are fully backward compatible with RFC 4408. The working group shall not try to update other RFCs, although interoperability problems may be discussed, especially if they concern security considerations. jm2c From ajs@anvilwalrusden.com Fri Aug 12 06:14: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 C4EA121F8A51 for ; Fri, 12 Aug 2011 06:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-4fgym1qtmY for ; Fri, 12 Aug 2011 06:14:26 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 48DFE21F8A4D for ; Fri, 12 Aug 2011 06:14:26 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id CF3CA1ECB41D for ; Fri, 12 Aug 2011 13:14:59 +0000 (UTC) Date: Fri, 12 Aug 2011 09:14:57 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20110812131456.GB3724@shinkuro.com> References: <201108092337.39408.scott@kitterman.com> <20110811213626.GU95640@shinkuro.com> <201108111807.05405.scott@kitterman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201108111807.05405.scott@kitterman.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] Updating the status of SPF 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, 12 Aug 2011 13:14:26 -0000 On Thu, Aug 11, 2011 at 06:07:04PM -0400, Scott Kitterman wrote: > > I feel strongly that the 4408bis effort we are discussing now should be a > minimal/backwards compatible_unless_it_is_impossible update. Once that is > complete there is a backlog of incompatible design ideas for simplifying and > improving SPF. In that context I think moving to Type SPF only makes a lot of > sense and should be considered. I don't want to get that mixed in with the > current effort. I don't have a strong feeling about this, but why is that a better strategy? If the goal is to move SPF off the EXPERIMENTAL track, then surely the time to make changes to the protocol is when you move it and determine the extent to which the experiment worked or didn't? Cf. the current effort in the EAI WG. A -- Andrew Sullivan ajs@anvilwalrusden.com From scott@kitterman.com Fri Aug 12 07:00: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 5056521F8834 for ; Fri, 12 Aug 2011 07:00:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j48EBB7RgowD for ; Fri, 12 Aug 2011 07:00:16 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id A44F721F881C for ; Fri, 12 Aug 2011 07:00:16 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 96B6638C12D; Fri, 12 Aug 2011 10:00:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1313157651; bh=wx/BkCE5xa2HoaFc1nOX+fqyBcu94WV+rrrMdGitW8w=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=ECfPdVbFRYBg1PeFrtIteelF/ucVT8CmcQbFPzFYP1DKWpVazGke3X3dqDjwNrIwr TvWqPPiiUXkM/Qo0GVmiTShs3vYNt72aHdqGCro/giPGk/RH9xoASluWmT2lf8ONph tbTY+hF4wFKwI19w1Y8hMiBPfeTHyupckKxUiyZU= From: Scott Kitterman To: apps-discuss@ietf.org Date: Fri, 12 Aug 2011 10:00:48 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic-pae; KDE/4.6.2; i686; ; ) References: <201108092337.39408.scott@kitterman.com> <201108111807.05405.scott@kitterman.com> <20110812131456.GB3724@shinkuro.com> In-Reply-To: <20110812131456.GB3724@shinkuro.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108121000.49202.scott@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] Updating the status of SPF 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, 12 Aug 2011 14:00:17 -0000 On Friday, August 12, 2011 09:14:57 AM Andrew Sullivan wrote: > On Thu, Aug 11, 2011 at 06:07:04PM -0400, Scott Kitterman wrote: > > I feel strongly that the 4408bis effort we are discussing now should be a > > minimal/backwards compatible_unless_it_is_impossible update. Once that > > is complete there is a backlog of incompatible design ideas for > > simplifying and improving SPF. In that context I think moving to Type > > SPF only makes a lot of sense and should be considered. I don't want to > > get that mixed in with the current effort. > > I don't have a strong feeling about this, but why is that a better > strategy? If the goal is to move SPF off the EXPERIMENTAL track, then > surely the time to make changes to the protocol is when you move it > and determine the extent to which the experiment worked or didn't? > Cf. the current effort in the EAI WG. It's in wide scale use. The goal of the current effort is to document that use. Scott K From ajs@anvilwalrusden.com Fri Aug 12 07:20: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 D363521F8AB9 for ; Fri, 12 Aug 2011 07:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtxY6BO2ZWMK for ; Fri, 12 Aug 2011 07:20:35 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 502F95E8001 for ; Fri, 12 Aug 2011 07:20:35 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D1E531ECB41D for ; Fri, 12 Aug 2011 14:21:12 +0000 (UTC) Date: Fri, 12 Aug 2011 10:21:10 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20110812142109.GD3724@shinkuro.com> References: <201108092337.39408.scott@kitterman.com> <201108111807.05405.scott@kitterman.com> <20110812131456.GB3724@shinkuro.com> <201108121000.49202.scott@kitterman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201108121000.49202.scott@kitterman.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] Updating the status of SPF 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, 12 Aug 2011 14:20:36 -0000 On Fri, Aug 12, 2011 at 10:00:48AM -0400, Scott Kitterman wrote: > > It's in wide scale use. The goal of the current effort is to document that > use. I don't know why a WG is necessary for that. There are three possibilities here. One is that SPF as specified is in wide scale use, in which case there is no real protocol work that is needed. All that is needed is a report (maybe as an RFC) saying, "This thing was widely deployed. The experiment worked." If, however, the experiment did not work, or bits and pieces of the RFC are not actually implemented or are implemented differently or are implemented diffrently by different people, then the new effort can do one of two things. One is to move the experimental protocol to the standards track. But that automatically requires that one make some determination about which pieces are going to change, and as Dave Crocker said somewhere in this thread that is going to attract all manner of disagreements. The other is simply to document exactly what is out there and how things do and do not deviate from the experimental protocol. The latter is surely an exercise in research that delivers an informational document but does not move the protocol onto the standards track. In my view, if the goal is to move the protocol to the standards track, then addressing issues in the protocol as already documented (and as actually deployed) has to be an open possibility. If that's not the goal, then I have no objection. I don't see what the value would be in moving something to the standards track without being willing to undertake standards work on it. A -- Andrew Sullivan ajs@anvilwalrusden.com From scott@kitterman.com Fri Aug 12 08:38: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 F389B21F85C4 for ; Fri, 12 Aug 2011 08:38:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNkNzycqvS2Y for ; Fri, 12 Aug 2011 08:38:23 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 415FC21F859F for ; Fri, 12 Aug 2011 08:38:23 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 1BCB538C12D; Fri, 12 Aug 2011 11:39:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1313163540; bh=1PCBWVQHHxpK2BNX2bs3c9xhIHKmiIMQRnHa1jlnu2o=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=QmRSOs9Fx/X/QsHHJrbv2y1F25Znr8L4ZQDS2d+gsPNZ8bVX5MDlXx9idBp31Yj5h dYslNrInLz3g0UCPJ1+96xb60hV5IsPTw2MhANT6t1me1upPPX2n9VVrs8/A+TAljm hyRKU1tsXlvmd/rG7ULdm0EhgPUor5IGAA6K2XbE= From: Scott Kitterman To: apps-discuss@ietf.org Date: Fri, 12 Aug 2011 11:38:57 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic-pae; KDE/4.6.2; i686; ; ) References: <201108092337.39408.scott@kitterman.com> <201108121000.49202.scott@kitterman.com> <20110812142109.GD3724@shinkuro.com> In-Reply-To: <20110812142109.GD3724@shinkuro.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108121138.57806.scott@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] Updating the status of SPF 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, 12 Aug 2011 15:38:24 -0000 On Friday, August 12, 2011 10:21:10 AM Andrew Sullivan wrote: > On Fri, Aug 12, 2011 at 10:00:48AM -0400, Scott Kitterman wrote: > > It's in wide scale use. The goal of the current effort is to document > > that use. > > I don't know why a WG is necessary for that. There are three > possibilities here. > > One is that SPF as specified is in wide scale use, in which case there > is no real protocol work that is needed. All that is needed is a > report (maybe as an RFC) saying, "This thing was widely deployed. The > experiment worked." > > If, however, the experiment did not work, or bits and pieces of the > RFC are not actually implemented or are implemented differently or are > implemented diffrently by different people, then the new effort can do > one of two things. One is to move the experimental protocol to the > standards track. But that automatically requires that one make some > determination about which pieces are going to change, and as Dave > Crocker said somewhere in this thread that is going to attract all > manner of disagreements. The other is simply to document exactly what > is out there and how things do and do not deviate from the > experimental protocol. The latter is surely an exercise in research > that delivers an informational document but does not move the protocol > onto the standards track. > > In my view, if the goal is to move the protocol to the standards > track, then addressing issues in the protocol as already documented > (and as actually deployed) has to be an open possibility. If that's > not the goal, then I have no objection. I don't see what the value > would be in moving something to the standards track without being > willing to undertake standards work on it. I can understand that view. On the other hand, in the absence of data documenting deficiencies in the experimental protocol I think it would be imprudent to abandon the benefits of years of experience with running code. My view is that the experiment was largely successful and only minor changes based on this experience are necessary. It may be that during the work of the group other information will come to light that will cause me to change that view. I'm not saying don't deviate, but give due weight to the experience with the current design and running code and don't deviate other than to fix significant issues. Scott K From ajs@anvilwalrusden.com Fri Aug 12 09:18: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 7AFAE21F86BE for ; Fri, 12 Aug 2011 09:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zO+unUFfA58K for ; Fri, 12 Aug 2011 09:18:27 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id DAD1721F86AF for ; Fri, 12 Aug 2011 09:18:27 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D09E71ECB41D for ; Fri, 12 Aug 2011 16:19:05 +0000 (UTC) Date: Fri, 12 Aug 2011 12:19:03 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20110812161902.GH3724@shinkuro.com> References: <201108092337.39408.scott@kitterman.com> <201108121000.49202.scott@kitterman.com> <20110812142109.GD3724@shinkuro.com> <201108121138.57806.scott@kitterman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201108121138.57806.scott@kitterman.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] Updating the status of SPF 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, 12 Aug 2011 16:18:28 -0000 On Fri, Aug 12, 2011 at 11:38:57AM -0400, Scott Kitterman wrote: > My view is that the experiment was largely successful and only minor changes > based on this experience are necessary. This is the problem I'm focussed on, however: once you say, "My changes are minor, $someone's are not in scope," you basically open up the protocol by having to debate the values of "my" and "minor" (and, too often I find, "changes"). I really don't have a dog in this race: I don't care about SPF, and the TXT battle was lost a long time ago. I'm just saying that, if the goal really is supposed to be, "Just document what's happened," you don't need a WG and you don't need to move tracks. You need a document that outlines what happened, period. That will more readily achieve the goal of documenting actual existing practice and getting the document out in a reasonable time frame. Everything else effectively means that you have to deal with all the issues Dave Crocker correctly identified. At the same time, I am strongly opposed, on process grounds, to a WG whose task it is to move a protocol from the experimental track to the standards track without facing any of the questions about whether the experiment worked, the extent of that working, and the trade-offs that might have been acceptable in an experiment but that are not acceptable for anything we might call a standard. If there is to be any distinction at all between these tracks, then those questions must be acceptable when changing. Otherwise, we get an experimental track that is just a new level in the 3 (soon to be (3-n)) level standards track we already have. A -- Andrew Sullivan ajs@anvilwalrusden.com From dhc@dcrocker.net Fri Aug 12 11:01: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 D3A9521F8747 for ; Fri, 12 Aug 2011 11:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.601 X-Spam-Level: X-Spam-Status: No, score=-5.601 tagged_above=-999 required=5 tests=[AWL=0.998, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynCZ-6QUG-eP for ; Fri, 12 Aug 2011 11:01:15 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 167A221F8745 for ; Fri, 12 Aug 2011 11:01:15 -0700 (PDT) Received: from [192.168.1.156] (adsl-68-122-69-114.dsl.pltn13.pacbell.net [68.122.69.114]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p7CI1ldh023338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Aug 2011 11:01:52 -0700 Message-ID: <4E456A8A.3050802@dcrocker.net> Date: Fri, 12 Aug 2011 11:01:46 -0700 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: Scott Kitterman References: <20110809225415.89118.qmail@joyce.lan> <201108111351.34118.scott@kitterman.com> In-Reply-To: <201108111351.34118.scott@kitterman.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]); Fri, 12 Aug 2011 11:01:52 -0700 (PDT) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Updating the status of SPF 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: Fri, 12 Aug 2011 18:01:15 -0000 Scott, I have some questions about the current draft of the charter. For the moment, I'm merely trying to get a better understanding of what is intended: > Determining the trustworthiness of content on the Internet remains a What is meant by "trustworthiness of content"? Two examples are that it might mean that it really was created by the purported author. Or it might mean that its contents are "valid" (which might invite some discussion about "validity", of course.) There are other possibilities. > (RFC4871). However, legitimate and illegitimate users alike can What is an "illegitimate user"? > take advantage of these schemes. What is also required is a > meaningful assessment of the trustworthiness of the identifier's > owner. This in turn permits making a meaningful choice about what > to do with the associated content. Is the work of the group intended to cover "what to do with the associated content"? > The advent of the requirement described above creates a need to have > reputation data providers make available to consumers data about Does "consumers" mean end-users, operators of receiving services, or some other group? If it means end-users, how are they expected to employ this information within the current context of the tools end-users have? > An existing, standardized reputation query mechanism is > Vouch-by-Reference (RFC5518), which provides a simple Boolean > response concerning the acceptability of different types of mail. > Other application spaces -- such as Web interactions -- could > benefit from common reputation query mechanisms, especially those > for which replies need to be more elaborate. Given the existence of VBR, why is an additional reputation query mechanism needed? What will be different in the the mechanism and why is the difference important? Perhaps the new mechanism will be identical to VBR, but merely will have the meaning of the response be more general than just email? > This working group will produce a set of documents defining and > illustrating the requirement and defining mechanisms to satisfy it. > Two mechanisms are proposed: > > * simple -- a reputation is expressed in a simple manner such as > an integer > > * extended -- a response can contain more complex information > useful to an assessor Who is going to use each of these mechanisms and why? Are they participating in the discussions so far? Have they expressed interest in implementing the output of the working group? > > The mechanisms will be designed to be application-independent, and > portable between reputation providers. For this topic, what does 'application-independent' mean? What does portable between providers mean? > The group will also produce specifications for reporting reputation > data from end-points (usually end users, such as someone clicking > a "report spam" button in response to unwanted email, or a > "thumbs-up" button in an online rating system) to reputation > data aggregators for use in computing updated reputations. Reporting to whom? What will be the basis for choosing among the different possible and existing models for reporting spam? The language appears to equate reporting by end-users with some other forms of reporting. Is there really a basis for conflating these? > Reputation systems such as Realtime Block Lists (RBLs, RFC5782) > can be problematic when not operated properly. For example, an > RBL that lists a specific source without justification can do harm By 'source' I assume the meaning is of an listed problem domain, rather than the source of the report that the domain is a problem? > to a legitimate business, provoking damages and possible litigation. > This important topic will need to be discussed in the informational > portions of the work produced here, in terms of advice both to What is meant by "informational portions of the work"? What output does that refer to? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From scott@kitterman.com Fri Aug 12 11:14: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 0624521F8779 for ; Fri, 12 Aug 2011 11:14: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbAAqAkc8NEk for ; Fri, 12 Aug 2011 11:14:05 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 083FF21F8751 for ; Fri, 12 Aug 2011 11:14:05 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id E7E4738C12D; Fri, 12 Aug 2011 14:14:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1313172881; bh=aXbKPBMRN/X//4vNwG5PljjtpGuNOWFJGy2q7J53Zr0=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=QYY7G7/MbMbtILc8y6dbYuper0NvaS7cKavNlFPd5hffgTkc0mycK9gFDSRI8ifLr k1h8eUmi9VoE8cvMm7FfXDZkOIX6JcRUaq2f7dNOxoYeQdUabKu3VOZd73hNFyghky cUjOKFQpN4bRBtdKPsRbaBmKa4fQ3GTetmDULNmU= From: Scott Kitterman To: apps-discuss@ietf.org Date: Fri, 12 Aug 2011 14:14:39 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic-pae; KDE/4.6.2; i686; ; ) References: <20110809225415.89118.qmail@joyce.lan> <201108111351.34118.scott@kitterman.com> <4E456A8A.3050802@dcrocker.net> In-Reply-To: <4E456A8A.3050802@dcrocker.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108121414.39555.scott@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] Updating the status of SPF 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, 12 Aug 2011 18:14:06 -0000 On Friday, August 12, 2011 02:01:46 PM Dave CROCKER wrote: > Scott, > > I have some questions about the current draft of the charter. For the > moment, > > I'm merely trying to get a better understanding of what is intended: > > Determining the trustworthiness of content on the Internet remains > > a > > What is meant by "trustworthiness of content"? > > Two examples are that it might mean that it really was created by the > purported author. Or it might mean that its contents are "valid" (which > might invite some discussion about "validity", of course.) There are other > possibilities. > > > (RFC4871). However, legitimate and illegitimate users alike can > > What is an "illegitimate user"? > > > take advantage of these schemes. What is also required is a > > meaningful assessment of the trustworthiness of the identifier's > > owner. This in turn permits making a meaningful choice about what > > to do with the associated content. > > Is the work of the group intended to cover "what to do with the associated > content"? > > > The advent of the requirement described above creates a need to have > > reputation data providers make available to consumers data about > > Does "consumers" mean end-users, operators of receiving services, or some > other group? > > If it means end-users, how are they expected to employ this information > within the current context of the tools end-users have? > > > An existing, standardized reputation query mechanism is > > Vouch-by-Reference (RFC5518), which provides a simple Boolean > > response concerning the acceptability of different types of mail. > > Other application spaces -- such as Web interactions -- could > > benefit from common reputation query mechanisms, especially those > > for which replies need to be more elaborate. > > Given the existence of VBR, why is an additional reputation query mechanism > needed? What will be different in the the mechanism and why is the > difference important? > > Perhaps the new mechanism will be identical to VBR, but merely will have > the meaning of the response be more general than just email? > > > This working group will produce a set of documents defining and > > illustrating the requirement and defining mechanisms to satisfy it. > > Two mechanisms are proposed: > > > > * simple -- a reputation is expressed in a simple manner such as > > > > an integer > > > > * extended -- a response can contain more complex information > > > > useful to an assessor > > Who is going to use each of these mechanisms and why? Are they > participating in the discussions so far? Have they expressed interest in > implementing the output of the working group? > > > The mechanisms will be designed to be application-independent, and > > portable between reputation providers. > > For this topic, what does 'application-independent' mean? > > What does portable between providers mean? > > > The group will also produce specifications for reporting reputation > > data from end-points (usually end users, such as someone clicking > > a "report spam" button in response to unwanted email, or a > > "thumbs-up" button in an online rating system) to reputation > > data aggregators for use in computing updated reputations. > > Reporting to whom? > > What will be the basis for choosing among the different possible and > existing models for reporting spam? > > The language appears to equate reporting by end-users with some other forms > of reporting. Is there really a basis for conflating these? > > > Reputation systems such as Realtime Block Lists (RBLs, RFC5782) > > can be problematic when not operated properly. For example, an > > RBL that lists a specific source without justification can do harm > > By 'source' I assume the meaning is of an listed problem domain, rather > than the source of the report that the domain is a problem? > > > to a legitimate business, provoking damages and possible litigation. > > This important topic will need to be discussed in the informational > > portions of the work produced here, in terms of advice both to > > What is meant by "informational portions of the work"? What output does > that refer to? Several people have made suggestions re: a charter to investigate updating RFC 4408. I am working on a draft that integrates these comments and distils them down a bit. From you comments though, I think you may have mistaken the DOMAINREP charter that Murray pointed to as an example for a draft charter for this new proposed work. It's not. Please clarify? Scott K From dhc@dcrocker.net Fri Aug 12 11:23: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 0C48511E808B for ; Fri, 12 Aug 2011 11:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.85 X-Spam-Level: X-Spam-Status: No, score=-5.85 tagged_above=-999 required=5 tests=[AWL=0.749, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XXE98wMEj1D for ; Fri, 12 Aug 2011 11:23:54 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 917FE11E8087 for ; Fri, 12 Aug 2011 11:23:54 -0700 (PDT) Received: from [192.168.1.156] (adsl-68-122-69-114.dsl.pltn13.pacbell.net [68.122.69.114]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p7CIOQcC023683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Aug 2011 11:24:32 -0700 Message-ID: <4E456FD9.3050202@dcrocker.net> Date: Fri, 12 Aug 2011 11:24:25 -0700 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: <20110809225415.89118.qmail@joyce.lan> <201108111351.34118.scott@kitterman.com> <4E456A8A.3050802@dcrocker.net> <201108121414.39555.scott@kitterman.com> In-Reply-To: <201108121414.39555.scott@kitterman.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]); Fri, 12 Aug 2011 11:24:32 -0700 (PDT) Subject: Re: [apps-discuss] Updating the status of SPF 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: Fri, 12 Aug 2011 18:23:55 -0000 oh boy. sorry. completely misposted. sigh. d/ On 8/12/2011 11:14 AM, Scott Kitterman wrote: > Several people have made suggestions re: a charter to investigate updating RFC > 4408. I am working on a draft that integrates these comments and distils them > down a bit. From you comments though, I think you may have mistaken the > DOMAINREP charter that Murray pointed to as an example for a draft charter for > this new proposed work. It's not. > > Please clarify? > > Scott K > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Dave Crocker Brandenburg InternetWorking bbiw.net From nsb@guppylake.com Fri Aug 12 12:15: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 265AE21F8761 for ; Fri, 12 Aug 2011 12:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4iLBuoKyLiU for ; Fri, 12 Aug 2011 12:15:03 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id 4659E21F8751 for ; Fri, 12 Aug 2011 12:15:03 -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=np/Ok0DL1yLiNBSM4ZBi6zSITBjSTvSpBd5TXf0fSPlREgJUqVMAeYtmIVh9pk91N0hyYs02k5xS71XAOvjiWJABj1Ylaonw/bpeaTtvVARwH0p628NJCpgMrFa0I2BY; Received: from [108.98.177.27] (helo=[192.168.0.197]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1QrxCd-0008G2-UP; Fri, 12 Aug 2011 15:15:33 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-96--138123778 From: Nathaniel Borenstein In-Reply-To: <1CA767A597F39B55C51402A9@caldav.corp.apple.com> Date: Fri, 12 Aug 2011 15:15:25 -0400 Message-Id: References: <6.2.5.6.2.20110810143624.0a2c2b78@resistor.net> <4E43C639.6000206@viagenie.ca> <1CA767A597F39B55C51402A9@caldav.corp.apple.com> To: Cyrus Daboo 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] Status of the malformed mail BCP 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, 12 Aug 2011 19:15:04 -0000 --Apple-Mail-96--138123778 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Two comments: On Aug 10, 2011, at 1:49 AM, Frank Ellermann wrote: > Just in case, I think "line too long" can only happen in = (if > at all), otherwise this could be considered as "malformed wrt RFC = 5322". I think you used "can" where "should" is more accurate. Mimecast = recently received an email message with over 7 megabytes in the = Message-ID header field. We decided not to deliver it, suspecting that = it would only cause problems downstream as well. But perhaps we should = have replaced or eliminated the Message-ID and then passed it on? There = is no received wisdom here. On Aug 11, 2011, at 9:48 AM, Cyrus Daboo wrote: > I've actually thought that every RFC should have an associated (expert = review) wiki associated with it. Then implementors could post their own = experiences, notes, issues etc there plus it could auto-link to rfc = errata and other related stuff. Of course that could mean a lot of work = for expert reviewers - maybe there should be two pages - one expert = review, the other public? I really like this idea. If this were in place, we wouldn't be = discussing a malformed mail BCP, we'd just be updating the wiki entries = for RFCs 5321/5322. =20= --Apple-Mail-96--138123778 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Just in case, I think "line too long" can only happen = in <obs-body> (if
at all), otherwise this could be considered = as "malformed wrt RFC 5322".

I = think you used "can" where "should" is more accurate.  Mimecast = recently received an email message with over 7 megabytes in the = Message-ID header field.  We decided not to deliver it, suspecting = that it would only cause problems downstream as well.  But perhaps = we should have replaced or eliminated the Message-ID and then passed it = on?  There is no received wisdom = here.

On Aug 11, 2011, at 9:48 = AM, Cyrus Daboo wrote:

I've actually = thought that every RFC should have an associated (expert review) wiki = associated with it. Then implementors could post their own experiences, = notes, issues etc there plus it could auto-link to rfc errata and other = related stuff. Of course that could mean a lot of work for expert = reviewers - maybe there should be two pages - one expert review, the = other public?

I really like this idea. =  If this were in place, we wouldn't be discussing a malformed mail = BCP, we'd just be updating the wiki entries for RFCs 5321/5322. =  
= --Apple-Mail-96--138123778-- From scott@kitterman.com Fri Aug 12 14:28: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 9619F21F889F for ; Fri, 12 Aug 2011 14:28:35 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWlE6EkeuBMo for ; Fri, 12 Aug 2011 14:28:34 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 89FE321F8891 for ; Fri, 12 Aug 2011 14:28:34 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id B80CE38C12D; Fri, 12 Aug 2011 17:29:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1313184552; bh=aBD1ENb52oNAuV3IjWg8wS41gfbi4UBRY7UyuA4Nh1E=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=BZ9la7O61/G0lE31Q19EngwEhuu3TJHyOWJR/Du9QqwULQRshiDDiy32EGfUfbOph VqqZ1dUZgxqBL4ZS3N4FtJdX2FM55yHRAmjM5I4DgpcLOBxWF/J5WAPn9N/cYGNdKO PSmLJHfXZGmx/CS24xKFJJE8LWCFqlRPv96kC1RU= From: Scott Kitterman To: apps-discuss@ietf.org Date: Fri, 12 Aug 2011 17:29:09 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic-pae; KDE/4.6.2; i686; ; ) References: <201108092337.39408.scott@kitterman.com> <201108121138.57806.scott@kitterman.com> <20110812161902.GH3724@shinkuro.com> In-Reply-To: <20110812161902.GH3724@shinkuro.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108121729.09648.scott@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] Updating the status of SPF 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, 12 Aug 2011 21:28:35 -0000 On Friday, August 12, 2011 12:19:03 PM Andrew Sullivan wrote: > On Fri, Aug 12, 2011 at 11:38:57AM -0400, Scott Kitterman wrote: > > My view is that the experiment was largely successful and only minor > > changes based on this experience are necessary. > > This is the problem I'm focussed on, however: once you say, "My > changes are minor, $someone's are not in scope," you basically open up > the protocol by having to debate the values of "my" and "minor" (and, > too often I find, "changes"). > > I really don't have a dog in this race: I don't care about SPF, and > the TXT battle was lost a long time ago. I'm just saying that, if the > goal really is supposed to be, "Just document what's happened," you > don't need a WG and you don't need to move tracks. You need a > document that outlines what happened, period. That will more readily > achieve the goal of documenting actual existing practice and getting > the document out in a reasonable time frame. Everything else > effectively means that you have to deal with all the issues Dave > Crocker correctly identified. > > At the same time, I am strongly opposed, on process grounds, to a WG > whose task it is to move a protocol from the experimental track to the > standards track without facing any of the questions about whether the > experiment worked, the extent of that working, and the trade-offs that > might have been acceptable in an experiment but that are not > acceptable for anything we might call a standard. If there is to be > any distinction at all between these tracks, then those questions must > be acceptable when changing. Otherwise, we get an experimental track > that is just a new level in the 3 (soon to be (3-n)) level standards > track we already have. I see three possible conclusions a working group might reach: 1. The experiment was successful and with minor adjustments the protocol is suitable for standards track. 2. The experiment had some good points, but identified significant issues that require substantial change, but we can make them and move on to the standards track. 3. The experiment is not yet mature and after revision we need to repeat the experiment some more as an update experimental protocoal. The evidence I'm aware of points to number one as the most likely result of doing this work. I would prefer an initial charter that is oriented on this path to minimize the amount of time that needs to be spent on bikeshed discussions. That does not mean that I think the WG should be blind to data that points to outcomes two or three. If that's where the rough consensus goes, then that's where it goes. In the interests of being efficient about the most likely path I'd rather come back and recharter for that type of work if it proves to be necessary. Scott K From ajs@anvilwalrusden.com Fri Aug 12 15:24: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 9254921F86AB for ; Fri, 12 Aug 2011 15:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbZXZ9WkVQXq for ; Fri, 12 Aug 2011 15:24:03 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id CEC8821F867A for ; Fri, 12 Aug 2011 15:24:03 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 143FC1ECB41D for ; Fri, 12 Aug 2011 22:24:42 +0000 (UTC) Date: Fri, 12 Aug 2011 18:24:39 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20110812222438.GL2625@shinkuro.com> References: <201108092337.39408.scott@kitterman.com> <201108121138.57806.scott@kitterman.com> <20110812161902.GH3724@shinkuro.com> <201108121729.09648.scott@kitterman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201108121729.09648.scott@kitterman.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] Updating the status of SPF 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, 12 Aug 2011 22:24:04 -0000 On Fri, Aug 12, 2011 at 05:29:09PM -0400, Scott Kitterman wrote: > The evidence I'm aware of points to number one as the most likely result of > doing this work. Fully agree. > I would prefer an initial charter that is oriented on this > path to minimize the amount of time that needs to be spent on bikeshed > discussions. No. This is exactly the process objection I have. If SPF is supposed to jump tracks, then everybody's live issues get to come out, or nobody's do. I made an analogy with EAI before, and one reason I did was because their focus on mostly modest changes has been enabled exactly by the short duration of the experiment. A so-called experiment that has run as long as SPF (it was published five years ago) should not be moved to the standards track without the opportunity for everyone who thinks there's a problem to have hits. Those people can be ruled out by the WG as unrealistic given the deployed base, but they ought not to be ruled out by administrative fiat (which is what keeping the charter so narrow entails). This isn't to say I think that a standards-track SPF that is 4408bis, with only niggling changes, is wrong. I'm just opposed to making that a rule for a WG that is also moving SPF to the standards track. If we make such a rule, we are in effect making the experimental track step 0 of the standards track (if you count from 1, else s/0/-1/). In this age where we are dying to get rid of standards levels, I think adding experimental to the front is a bad idea. A -- Andrew Sullivan ajs@anvilwalrusden.com From ned.freed@mrochek.com Sat Aug 13 08:57: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 C9AE721F85B5 for ; Sat, 13 Aug 2011 08:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHbKcpNqoDZR for ; Sat, 13 Aug 2011 08:57:26 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2019121F863A for ; Sat, 13 Aug 2011 08:57:26 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4SNU0LYOW00ZU4U@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 13 Aug 2011 08:57:04 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4CJSMR6GG00VHKR@mauve.mrochek.com>; Sat, 13 Aug 2011 08:57:02 -0700 (PDT) Message-id: <01O4SNTZFJZ200VHKR@mauve.mrochek.com> Date: Sat, 13 Aug 2011 08:52:53 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 12 Aug 2011 07:09:27 +0300" <4E44A777.3000902@gmail.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <20110726125042.1180.12955.idtracker@ietfa.amsl.com> <4E2EBA34.5090604@stpeter.im> <4E44A777.3000902@gmail.com> To: Mykyta Yevstifeyev DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1313250927; bh=EVuaZD7dnotRliSm19wsTgjGTzgqDDgzwsdy+27JWIU=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=IRFnFV8kFrCCZU5fI/1QY4U0FggL4aeJNk2lNHVfV/PKwvl6hpJw4H2FEHHFdXJm/ 95uS+ZvMdeVlPDdOHgUkXIQQ27oaytDndAx7g+ie6bykUNZyMM24ZpMexmQtf5M6Zb 0b16WA7wL/iJbIzQXqYzXIJ5zKNy6c2z6yQAp05A= 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: Sat, 13 Aug 2011 15:57:26 -0000 > I think your document should be clear whether it affects the "vnd." > construction, used, eg., as I remember, in MIME media types and elsewhere. The answer to that is "no", by definition. The unregistered (x-/x.) tree is 100% disjoint from the vendor, personal, and standard trees. > With respect to existing IANA policies regarding assignment and > registration values beginning in "X-". I suppose IANA should continue > to follow those policies which were set by the corresponding documents, > in order not to create the influx of registrations of "X-" values. Actually, there has been some sentiment that we should actually allow and encourage such registrations. > However, when the "X-" convention is deprecated, new protocols will not > need to set such policy; so no changes for IANA are necessary now. Given that the media types registration procedures document is currently being revised, any changes to x-/x. in that context should be dealt with in that update. Putting it in a separate general document would be both confusing and inappropriate. Ned From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Sat Aug 13 10:36: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 2FD3521F8563 for ; Sat, 13 Aug 2011 10:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.718 X-Spam-Level: X-Spam-Status: No, score=-102.718 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guMUI3UvzN8q for ; Sat, 13 Aug 2011 10:36:10 -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 4816A21F854D for ; Sat, 13 Aug 2011 10:36:10 -0700 (PDT) Received: by ywm21 with SMTP id 21so2835899ywm.31 for ; Sat, 13 Aug 2011 10:36:48 -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=wIIi+nFatDnhhLu3hw90K1ouPdnbmbvDyjattwkPFU0=; b=Bf3hPo9CyqkqDbGEuP3mdDLYVuMs7eZU/P6/LChiVe2ksRV8RYbCXNCLGYh8yULUY8 vqxA6hKQFWajoxq5fb5DudqiTkkBPCbGdCnW/RQ26lN9frVzkG+sfsLmU7o6+uvWhgPE elS2V5AwBInZTmNE7RuJThYSKT3z8aks4gNzc= Received: by 10.143.20.12 with SMTP id x12mr971134wfi.105.1313257006338; Sat, 13 Aug 2011 10:36:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.157.2 with HTTP; Sat, 13 Aug 2011 10:36:26 -0700 (PDT) In-Reply-To: <20110812222438.GL2625@shinkuro.com> References: <201108092337.39408.scott@kitterman.com> <201108121138.57806.scott@kitterman.com> <20110812161902.GH3724@shinkuro.com> <201108121729.09648.scott@kitterman.com> <20110812222438.GL2625@shinkuro.com> From: Frank Ellermann Date: Sat, 13 Aug 2011 19:36:26 +0200 Message-ID: To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Updating the status of SPF 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, 13 Aug 2011 17:36:11 -0000 On 13 August 2011 00:24, Andrew Sullivan wrote: > This is exactly the process objection I have. Hi, I'm not sure how obvious this is for others, but SPF is completely unsuited as an "example" or "precedence" in more general two vs. three steps procedural discussions. When RFC 4408 was published as an "IETF experiment" SPF was already widely deployed, and the RFC was in fact the result of experiments based on earlier Internet drafts, and submitted as a "proposed standard". For let's say "non-technical reasons" it ended up as an experimental RFC, and anybody interested in the details can dig through old MARID and spf-discuss mail archives, or try to reconstruct the SPF history from footnotes in the appeal to the IAB -- NOT RECOMMENDED unless you have a grim sense of humour. In other words, SPF is not really the first incarnation of a new "four steps" procedure, but there are certainly errata justifying a 4408bis, and I'd be interested to work on that if it is for "standard tracks". Otherwise I'd say that implementors should find the errata page on openspf.org, its URL is not affected by the "status" of erratum 994. -Frank From evnikita2@gmail.com Sun Aug 14 03:35: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 C35FC21F8A64 for ; Sun, 14 Aug 2011 03:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.401 X-Spam-Level: X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tMKA5Yp8kUC for ; Sun, 14 Aug 2011 03:35:30 -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 0658621F8A66 for ; Sun, 14 Aug 2011 03:35:29 -0700 (PDT) Received: by fxe6 with SMTP id 6so3423433fxe.31 for ; Sun, 14 Aug 2011 03:36:11 -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=vMAvDKLvMkNYBZrKg8wE3/t9dIptQoyohZM+wU5Dg/Q=; b=v1YMuOthFTO1OUEcRcK/wlXJvLZc9vjM7n/BPd7eXjt2SvF2vgJ0Ts2L0iJihs2giI 52N2SQYiebYn6fBpv9ql/WGoBHSEeyFakTrlFtSONQAZrVF7z8VN20/1PCSf894mpCG0 RzEW/wQ957K0tRTpjKLgZ5ggeHnHEwoveYiGI= Received: by 10.223.161.80 with SMTP id q16mr3827846fax.113.1313318171875; Sun, 14 Aug 2011 03:36:11 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id b14sm4038201fab.19.2011.08.14.03.36.10 (version=SSLv3 cipher=OTHER); Sun, 14 Aug 2011 03:36:11 -0700 (PDT) Message-ID: <4E47A540.6020901@gmail.com> Date: Sun, 14 Aug 2011 13:36:48 +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 Subject: [apps-discuss] HTML and 'about' URIs (again) 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, 14 Aug 2011 10:35:30 -0000 Hello, Just now, I have received the "Editor's Response" on the issue regarding HTML5 and 'about' URIs (pleas see http://dev.w3.org/html5/decision-policy/decision-policy.html on how the issues are processed; http://www.w3.org/Bugs/Public/show_bug.cgi?id=13719 for the issue itself). Currently HTML5 draft is making reference to draft-holsten-about-uri-scheme; we did agree to accept it as APPSAWG document. FYI, the final response was: > Status: Rejected > Change Description: no spec change > Rationale: That is busy work. Please reopen when the IETF is done with its work > on the about URL scheme and then we'll make the relevant changes. W3C is planning to advance HTML5 to Recommendation in 2014, as far as I know, but nonetheless we should decide at least on the concepts of the document to let W3C know what they should fit HTML5 (with this respect) to. I proposed to remove any reference to 'about' scheme spec from HTML5 saying that such spec will do all necessary assignments, but the proposal was rejected. So, taking the situation into account, I think it's time for WG chairs to act now and set the direction of the work. Mykyta Yevstifeyev From evnikita2@gmail.com Wed Aug 17 07:40: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 1A28121F8B79 for ; Wed, 17 Aug 2011 07:40:47 -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=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrzEe5VxmH1B for ; Wed, 17 Aug 2011 07:40:45 -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 5771221F8B5F for ; Wed, 17 Aug 2011 07:40:45 -0700 (PDT) Received: by bkar4 with SMTP id r4so900085bka.31 for ; Wed, 17 Aug 2011 07:41: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=zgAM4Yag82c1FBMaqvdTu22HCs+9fF7CWO8pUy/1UmA=; b=nTlpa+etpTsr1HR//RyzclZmdWAJJwozOATbO+fzAKszhAZBGdQg44NPK4BFOHM3xu FDV604dhDKJs0T92bO1b5L13KptnIHhmnb53RhrsDisbia2LqAPpZDqiDBrzdPnRkzuX C+RusF++CWQV+ceLw7QqlqV0dPWSSY1sO+KH8= Received: by 10.204.164.2 with SMTP id c2mr455009bky.76.1313592096014; Wed, 17 Aug 2011 07:41:36 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id e21sm419165bkw.56.2011.08.17.07.41.29 (version=SSLv3 cipher=OTHER); Wed, 17 Aug 2011 07:41:30 -0700 (PDT) Message-ID: <4E4BD33E.6050002@gmail.com> Date: Wed, 17 Aug 2011 17:42:06 +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: Ned Freed References: <20110726125042.1180.12955.idtracker@ietfa.amsl.com> <4E2EBA34.5090604@stpeter.im> <4E44A777.3000902@gmail.com> <01O4SNTZFJZ200VHKR@mauve.mrochek.com> In-Reply-To: <01O4SNTZFJZ200VHKR@mauve.mrochek.com> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 17 Aug 2011 14:40:47 -0000 13.08.2011 18:52, Ned Freed wrote: >> I think your document should be clear whether it affects the "vnd." >> construction, used, eg., as I remember, in MIME media types and >> elsewhere. > > The answer to that is "no", by definition. The unregistered (x-/x.) tree > is 100% disjoint from the vendor, personal, and standard trees. So this could and should be mentioned in the document. > >> With respect to existing IANA policies regarding assignment and >> registration values beginning in "X-". I suppose IANA should continue >> to follow those policies which were set by the corresponding documents, >> in order not to create the influx of registrations of "X-" values. > > Actually, there has been some sentiment that we should actually allow > and encourage such registrations. As previously "x-" parameters weren't allowed to be registered, interoperability problems may arise when such parameter has several real-life usages and only one is registered. I suspected the document not to have a retroactivity. > >> However, when the "X-" convention is deprecated, new protocols will not >> need to set such policy; so no changes for IANA are necessary now. > > Given that the media types registration procedures document is currently > being revised, any changes to x-/x. in that context should be dealt > with in that update. Putting it in a separate general document would > be both confusing and inappropriate. Your I-D which I found and which positions itself as 4288bis (http://tools.ietf.org/html/draft-freed-media-type-regs-00) does contain provisions regarding non-registered x. media types and prohibition of their registration. The I-D was uploaded on 13 June, and even if such restriction is going to disappear, the new version of I-D should point to draft-saintandre-xdash to reflect x. being are deprecated; it also has to deal with existing-and-unregistered x. media types. I believe that deprecation should only concern new protocols and have no retroaticity; so those registries which don't currently allow x. or x- registrations, should continue doing so; those which are only being created, should take the discussed doc into account. Mykyta > > Ned > From ned.freed@mrochek.com Wed Aug 17 08:21: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 77DA221F8AE1 for ; Wed, 17 Aug 2011 08:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxtHpYondgpL for ; Wed, 17 Aug 2011 08:21:45 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9941121F8AD8 for ; Wed, 17 Aug 2011 08:21:45 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4Y7R95K0000NQMS@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 17 Aug 2011 08:21:28 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4CJSMR6GG00VHKR@mauve.mrochek.com>; Wed, 17 Aug 2011 08:21:25 -0700 (PDT) Message-id: <01O4Y7R78O5000VHKR@mauve.mrochek.com> Date: Wed, 17 Aug 2011 07:53:33 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 17 Aug 2011 17:42:06 +0300" <4E4BD33E.6050002@gmail.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <20110726125042.1180.12955.idtracker@ietfa.amsl.com> <4E2EBA34.5090604@stpeter.im> <4E44A777.3000902@gmail.com> <01O4SNTZFJZ200VHKR@mauve.mrochek.com> <4E4BD33E.6050002@gmail.com> To: Mykyta Yevstifeyev DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1313594550; bh=s/QkR6drDNocdzHDCaawXXUF2GnVIQbA7GDTlYVofF8=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=CO7Bnr3n49JbK+Wsu/BlVTI+7OEXL0vaUJq3kRKq37tDmW9i/3lpX+JoYJoJxfpsv ouO+nm3BssKcKCSaxTt/O1bVU3KLVlSbf+EbLM0LHp5tHfRn2lJJFe9dRm7kO1y+hu pgdoeleYUxnLKbUzbHnSwyn0LYEu+IfWrWyLBZ7c= Cc: Ned Freed , 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: Wed, 17 Aug 2011 15:21:46 -0000 > 13.08.2011 18:52, Ned Freed wrote: > >> I think your document should be clear whether it affects the "vnd." > >> construction, used, eg., as I remember, in MIME media types and > >> elsewhere. > > > > The answer to that is "no", by definition. The unregistered (x-/x.) tree > > is 100% disjoint from the vendor, personal, and standard trees. > So this could and should be mentioned in the document. Not sure I see why. Listing all the extant things the document doesn't apply to is going to be a long list. That said, I actually object to what this document currently says about media types: It is flatly incorrect to characterize the vnd. tree as being for "local or implementation-specific extensions". On the contrary, vnd. exists so that vendors can define formats with some degree of interoperability and some understanding of the security considerations, but without having to fully standardize them. As such, they aren't local, they aren't implementation-specific, and they aren't extensions. > >> With respect to existing IANA policies regarding assignment and > >> registration values beginning in "X-". I suppose IANA should continue > >> to follow those policies which were set by the corresponding documents, > >> in order not to create the influx of registrations of "X-" values. > > > > Actually, there has been some sentiment that we should actually allow > > and encourage such registrations. > As previously "x-" parameters weren't allowed to be registered, > interoperability problems may arise when such parameter has several > real-life usages and only one is registered. I suspected the document > not to have a retroactivity. First of all, nobody has suggested or even implied that such registrations would be unconditionally allowed. It goes without saying that only x- types that are unambiguously associated with a single format would be eligible for registration. Second, I rather suspect that a significant fraction of the x- media types in use have essentially only one real-life usage. And it is usually pretty easy to tell when this is the case. But it remains to be seen whether or not we decide to do something about this or not. The present draft doesn't contain any changes in this area and there is nothing resembling a consensus to make such a change at this time. > > > >> However, when the "X-" convention is deprecated, new protocols will not > >> need to set such policy; so no changes for IANA are necessary now. > > > > Given that the media types registration procedures document is currently > > being revised, any changes to x-/x. in that context should be dealt > > with in that update. Putting it in a separate general document would > > be both confusing and inappropriate. > Your I-D which I found and which positions itself as 4288bis > (http://tools.ietf.org/html/draft-freed-media-type-regs-00) does contain > provisions regarding non-registered x. media types and prohibition of > their registration. Yes, that's the current state of affairs. > The I-D was uploaded on 13 June, and even if such > restriction is going to disappear, the new version of I-D should point > to draft-saintandre-xdash to reflect x. being are deprecated; it also > has to deal with existing-and-unregistered x. media types. If and when we decide to change the semantics associated with x- in some way, it may become appropriate to reference this I-D. Or not - it's difficult to predict whether or not it makes sense to include such a reference until the specifics of the change are known. > I believe that deprecation should only concern new protocols and have no > retroaticity; so those registries which don't currently allow x. or x- > registrations, should continue doing so; those which are only being > created, should take the discussed doc into account. Exactly - this specifiction is focused on *new* parameters. How we handle extant registries is out of scope and necessarily will be determined on a case-by-case basis. Ned From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Aug 17 09:26: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 3DE1921F8B6A for ; Wed, 17 Aug 2011 09:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.725 X-Spam-Level: X-Spam-Status: No, score=-102.725 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nPd9CUUdCzI for ; Wed, 17 Aug 2011 09:26:14 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id C168621F84EC for ; Wed, 17 Aug 2011 09:26:14 -0700 (PDT) Received: by pzk33 with SMTP id 33so2238451pzk.18 for ; Wed, 17 Aug 2011 09:27:06 -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=C7h8tlpLqfIoG+vryTkgLUscJg5zyjK4szubCourbkM=; b=GZvoKkRsgOqtIdxbdfS9epY3WT3R7ebfurK0TPMth7vlc7TNIR+M2oaQpQSnQQ3Ao/ iSZmRltIYgqdraCSkQmJYgtlpJyLkLudwdq5qEk5GaVKximeKpOiDvCsvibQQ7q253S0 k0nrf07fwonVrxQYzV28UIhZtH0oYnoz+t9yg= Received: by 10.143.69.12 with SMTP id w12mr568998wfk.298.1313598426113; Wed, 17 Aug 2011 09:27:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.98.5 with HTTP; Wed, 17 Aug 2011 09:26:46 -0700 (PDT) In-Reply-To: <01O4Y7R78O5000VHKR@mauve.mrochek.com> References: <20110726125042.1180.12955.idtracker@ietfa.amsl.com> <4E2EBA34.5090604@stpeter.im> <4E44A777.3000902@gmail.com> <01O4SNTZFJZ200VHKR@mauve.mrochek.com> <4E4BD33E.6050002@gmail.com> <01O4Y7R78O5000VHKR@mauve.mrochek.com> From: Frank Ellermann Date: Wed, 17 Aug 2011 18:26:46 +0200 Message-ID: To: Ned Freed 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: Wed, 17 Aug 2011 16:26:15 -0000 Apropos xdash-03, checking various things I missed in 2009 and 2010 I stumbled over draft-yevstifeyev-ion-report, from there I found the new home page of the [PROCDOCS] -- BTW, it is very good that [TAObis] and [PROCDOCS] are still updated, no matter what happens with FYIs or IONs as a series -- and somehow eventually arrived at draft-iab-extension-recs section 3.1, or rather the predecessor of this I-D (= draft-carpenter-extension-recs). IOW, there is some "prior art" for X-issues by Brian Carpenter not yet mentioned in the xdash draft, and if the IAB still works on the extension-recs I hope that their conclusions match saintandre-xdash when both are finished. -Frank From evnikita2@gmail.com Wed Aug 17 22:58: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 CAF4B21F85EC for ; Wed, 17 Aug 2011 22:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ie41vCFe6zpp for ; Wed, 17 Aug 2011 22:58:14 -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 9B8C221F85E3 for ; Wed, 17 Aug 2011 22:58:13 -0700 (PDT) Received: by fxe6 with SMTP id 6so1185348fxe.31 for ; Wed, 17 Aug 2011 22:59:06 -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=0+U0Sj1fxVLuAeLkd6MiaQ6lOg1HLrfSTlsU++fidcg=; b=GFl6AF2Kx41iPnXCN3HdRTQqB2z3ksgf4Ipuuwzl5YKzcescvWZWqFUcuF8vLW9C7w FZX8V92wfCsfl8E8be3as6ixWE5mwdjv4oLVWVUoOS+lVns6Y9U2VwCaP/L+hEOUgbNa ARw/zgvkThufjDSMOMkIZTLH5AKxmjCAaeIfQ= Received: by 10.223.64.206 with SMTP id f14mr525046fai.124.1313647146140; Wed, 17 Aug 2011 22:59:06 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id 22sm1459590fat.41.2011.08.17.22.59.03 (version=SSLv3 cipher=OTHER); Wed, 17 Aug 2011 22:59:04 -0700 (PDT) Message-ID: <4E4CAA4B.6070100@gmail.com> Date: Thu, 18 Aug 2011 08:59:39 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Ned Freed References: <20110726125042.1180.12955.idtracker@ietfa.amsl.com> <4E2EBA34.5090604@stpeter.im> <4E44A777.3000902@gmail.com> <01O4SNTZFJZ200VHKR@mauve.mrochek.com> <4E4BD33E.6050002@gmail.com> <01O4Y7R78O5000VHKR@mauve.mrochek.com> In-Reply-To: <01O4Y7R78O5000VHKR@mauve.mrochek.com> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 18 Aug 2011 05:58:14 -0000 17.08.2011 17:53, Ned Freed wrote: >> 13.08.2011 18:52, Ned Freed wrote: >> >> I think your document should be clear whether it affects the "vnd." >> >> construction, used, eg., as I remember, in MIME media types and >> >> elsewhere. >> > >> > The answer to that is "no", by definition. The unregistered (x-/x.) >> tree >> > is 100% disjoint from the vendor, personal, and standard trees. > >> So this could and should be mentioned in the document. > > Not sure I see why. Listing all the extant things the document doesn't > apply to > is going to be a long list. But x. convention and vnd. convention are quite contiguous; they both imply that the parameter has a limited use as an experimental/vendor specific; herewith the first often covers the latter - I mean that x. parameters are used in the meaning of vendor-specific. So I think, for the sake of clarity, this should be mentioned. > > That said, I actually object to what this document currently says > about media > types: It is flatly incorrect to characterize the vnd. tree as being for > "local or implementation-specific extensions". On the contrary, vnd. > exists so > that vendors can define formats with some degree of interoperability > and some > understanding of the security considerations, but without having to fully > standardize them. As such, they aren't local, they aren't > implementation-specific, and they aren't extensions. > >> >> With respect to existing IANA policies regarding assignment and >> >> registration values beginning in "X-". I suppose IANA should >> continue >> >> to follow those policies which were set by the corresponding >> documents, >> >> in order not to create the influx of registrations of "X-" values. >> > >> > Actually, there has been some sentiment that we should actually allow >> > and encourage such registrations. > >> As previously "x-" parameters weren't allowed to be registered, >> interoperability problems may arise when such parameter has several >> real-life usages and only one is registered. I suspected the document >> not to have a retroactivity. > > First of all, nobody has suggested or even implied that such > registrations > would be unconditionally allowed. It goes without saying that only x- > types > that are unambiguously associated with a single format would be > eligible for > registration. The essence of x- parameter actually makes this impossible; as they are specially reserved for non-registered use, one cannot claim for sure that a specific parameter isn't used else as compared to "wide-spread use". > > Second, I rather suspect that a significant fraction of the x- media > types in > use have essentially only one real-life usage. And it is usually > pretty easy to > tell when this is the case. If the document really deprecates such thing as x. convention, it should either (1) have no retroactivity, which would mean that the deprecation affect those protocols which are or will be under development, or (2) deprecate actual use of x. parameters, which would mean that those vendors that deploy them will be encouraged to migrate to non-x; the latter will create interoperability problems, though. In the first case IANA won't be allowed to assign x- if such restriction takes place; neither should such registrations be allowed in the second case. > > But it remains to be seen whether or not we decide to do something > about this > or not. The present draft doesn't contain any changes in this area and > there is > nothing resembling a consensus to make such a change at this time. > >> > >> >> However, when the "X-" convention is deprecated, new protocols >> will not >> >> need to set such policy; so no changes for IANA are necessary now. >> > >> > Given that the media types registration procedures document is >> currently >> > being revised, any changes to x-/x. in that context should be dealt >> > with in that update. Putting it in a separate general document would >> > be both confusing and inappropriate. > >> Your I-D which I found and which positions itself as 4288bis >> (http://tools.ietf.org/html/draft-freed-media-type-regs-00) does contain >> provisions regarding non-registered x. media types and prohibition of >> their registration. > > Yes, that's the current state of affairs. > >> The I-D was uploaded on 13 June, and even if such >> restriction is going to disappear, the new version of I-D should point >> to draft-saintandre-xdash to reflect x. being are deprecated; it also >> has to deal with existing-and-unregistered x. media types. > > If and when we decide to change the semantics associated with x- in > some way, > it may become appropriate to reference this I-D. Or not - it's difficult > to predict whether or not it makes sense to include such a reference > until > the specifics of the change are known. > >> I believe that deprecation should only concern new protocols and have no >> retroaticity; so those registries which don't currently allow x. or x- >> registrations, should continue doing so; those which are only being >> created, should take the discussed doc into account. > > Exactly - this specifiction is focused on *new* parameters. How > we handle extant registries is out of scope and necessarily will be > determined > on a case-by-case basis. Well, but some generic principles should be determined, if we want to allow such assignments. But here I agree - let's wait until the document gets some stability of what action it performs. Mykyta > > Ned > From tony@att.com Thu Aug 18 06:11: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 8769321F8A7D for ; Thu, 18 Aug 2011 06:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.139 X-Spam-Level: X-Spam-Status: No, score=-106.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jB0+7bHc9Svq for ; Thu, 18 Aug 2011 06:11:18 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 647C921F8A6F for ; Thu, 18 Aug 2011 06:11:13 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1313673126!21120283!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 3808 invoked from network); 18 Aug 2011 13:12:06 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-2.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Aug 2011 13:12:06 -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 p7IDCVXB026096 for ; Thu, 18 Aug 2011 09:12:31 -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 p7IDCSM7026059 for ; Thu, 18 Aug 2011 09:12:30 -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 p7IDC26E015908 for ; Thu, 18 Aug 2011 09:12:02 -0400 Received: from dns.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 p7IDBu6n015774 for ; Thu, 18 Aug 2011 09:11:59 -0400 Received: from [135.70.175.217] (vpn-135-70-175-217.vpn.mwst.att.com[135.70.175.217]) by maillennium.att.com (mailgw1) with ESMTP id <20110818131156gw100e4lsle> (Authid: tony); Thu, 18 Aug 2011 13:11:56 +0000 X-Originating-IP: [135.70.175.217] Message-ID: <4E4D0F93.3090200@att.com> Date: Thu, 18 Aug 2011 09:11:47 -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: Mykyta Yevstifeyev References: <20110726125042.1180.12955.idtracker@ietfa.amsl.com> <4E2EBA34.5090604@stpeter.im> <4E44A777.3000902@gmail.com> <01O4SNTZFJZ200VHKR@mauve.mrochek.com> <4E4BD33E.6050002@gmail.com> <01O4Y7R78O5000VHKR@mauve.mrochek.com> <4E4CAA4B.6070100@gmail.com> In-Reply-To: <4E4CAA4B.6070100@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ned Freed , 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: Thu, 18 Aug 2011 13:11:18 -0000 On 8/18/2011 1:59 AM, Mykyta Yevstifeyev wrote: > 17.08.2011 17:53, Ned Freed wrote: >> Not sure I see why. Listing all the extant things the document >> doesn't apply to >> is going to be a long list. > > But x. convention and vnd. convention are quite contiguous; they both > imply that the parameter has a limited use as an experimental/vendor > specific; herewith the first often covers the latter - I mean that x. > parameters are used in the meaning of vendor-specific. So I think, > for the sake of clarity, this should be mentioned. There are some vnd types that are extremely widely used. vnd has never implied limited use. It has a well defined meaning that is extremely dissimilar to x-. Trying to equate or draw analogies between experimental use and vendor-specific is simply erroneous. I'm with Ned here. Tony Hansen From ned.freed@mrochek.com Thu Aug 18 08:53: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 D819821F8B33 for ; Thu, 18 Aug 2011 08:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEnr069w2ZYy for ; Thu, 18 Aug 2011 08:53:39 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id B1EBE21F8B32 for ; Thu, 18 Aug 2011 08:53:39 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4ZN680YKW00VBX7@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 18 Aug 2011 08:53:26 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O4Y5R28EY800RCTX@mauve.mrochek.com>; Thu, 18 Aug 2011 08:53:24 -0700 (PDT) Message-id: <01O4ZN66MODE00RCTX@mauve.mrochek.com> Date: Thu, 18 Aug 2011 08:36:29 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 18 Aug 2011 08:59:39 +0300" <4E4CAA4B.6070100@gmail.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <20110726125042.1180.12955.idtracker@ietfa.amsl.com> <4E2EBA34.5090604@stpeter.im> <4E44A777.3000902@gmail.com> <01O4SNTZFJZ200VHKR@mauve.mrochek.com> <4E4BD33E.6050002@gmail.com> <01O4Y7R78O5000VHKR@mauve.mrochek.com> <4E4CAA4B.6070100@gmail.com> To: Mykyta Yevstifeyev DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1313682865; bh=jQk7iIP7hfYkvNgeOkQicEkcfo3Ad/xUqVRUZa5eDco=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=mI0JMJJ76EP4ZQaRwJxL0Wc3Nz0Z0dhneF209Dg0hm2B3S3vVExxAijMMgbcNk8M4 c8XSGg5ejwJ5v75mfC7bk+Hm/CZbkF5pXw0vfa21MeGSyDLEGiIEnX+VGMxUAj/sTb RfOCOTe1ZaZM5YQiBwiDvxD0X7vPlNkQx3FUbx7s= Cc: Ned Freed , 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: Thu, 18 Aug 2011 15:53:41 -0000 > 17.08.2011 17:53, Ned Freed wrote: > >> 13.08.2011 18:52, Ned Freed wrote: > >> >> I think your document should be clear whether it affects the "vnd." > >> >> construction, used, eg., as I remember, in MIME media types and > >> >> elsewhere. > >> > > >> > The answer to that is "no", by definition. The unregistered (x-/x.) > >> tree > >> > is 100% disjoint from the vendor, personal, and standard trees. > > > >> So this could and should be mentioned in the document. > > > > Not sure I see why. Listing all the extant things the document doesn't > > apply to > > is going to be a long list. > But x. convention and vnd. convention are quite contiguous; I don't know what this is suppposed to mean. These are separate namespaces, each with it's own rules. They are adjacent in some ways, opposites in some ways, and disjoint in some ways. > they both > imply that the parameter has a limited use as an experimental/vendor > specific; They imply no such thing. x./x- currently means the type is unregistered; nothing more. vnd. means it's registered according to a certain set of rules that are intended for vendor use. Nothing more. The fact that vnd. types (a) Includes many types far more widely and interoperably used that most standards tree types and (b) Each vnd type has a usage field that doesn't always have value "limited" (in fact most do not) shows what you're saying here is just plain wrong. > herewith the first often covers the latter - I mean that x. > parameters are used in the meaning of vendor-specific. Except that they aren't. > So I think, for > the sake of clarity, this should be mentioned. I disagree. Again, what this draft says is incorrect and it needs to be changed. This is demonstrable. > > > > That said, I actually object to what this document currently says > > about media > > types: It is flatly incorrect to characterize the vnd. tree as being for > > "local or implementation-specific extensions". On the contrary, vnd. > > exists so > > that vendors can define formats with some degree of interoperability > > and some > > understanding of the security considerations, but without having to fully > > standardize them. As such, they aren't local, they aren't > > implementation-specific, and they aren't extensions. > > > >> >> With respect to existing IANA policies regarding assignment and > >> >> registration values beginning in "X-". I suppose IANA should > >> continue > >> >> to follow those policies which were set by the corresponding > >> documents, > >> >> in order not to create the influx of registrations of "X-" values. > >> > > >> > Actually, there has been some sentiment that we should actually allow > >> > and encourage such registrations. > > > >> As previously "x-" parameters weren't allowed to be registered, > >> interoperability problems may arise when such parameter has several > >> real-life usages and only one is registered. I suspected the document > >> not to have a retroactivity. > > > > First of all, nobody has suggested or even implied that such > > registrations > > would be unconditionally allowed. It goes without saying that only x- > > types > > that are unambiguously associated with a single format would be > > eligible for > > registration. > The essence of x- parameter actually makes this impossible; It does no such thing. Hint: Exceptions can and have been made. > as they are > specially reserved for non-registered use, one cannot claim for sure > that a specific parameter isn't used else as compared to "wide-spread use". I have no idea what you mean by this. > > Second, I rather suspect that a significant fraction of the x- media > > types in > > use have essentially only one real-life usage. And it is usually > > pretty easy to > > tell when this is the case. > If the document really deprecates such thing as x. convention, it should > either (1) have no retroactivity, which would mean that the deprecation > affect those protocols which are or will be under development, or (2) > deprecate actual use of x. parameters, which would mean that those > vendors that deploy them will be encouraged to migrate to non-x; the > latter will create interoperability problems, though. In the first case > IANA won't be allowed to assign x- if such restriction takes place; > neither should such registrations be allowed in the second case. There are plenty of alternatives besides what you describe here. But since (a) This is not an appropriate time and place to discuss those alternatives and (b) You seem to have multiple, fundamental misunderstandings of how media type registrations work and how they can be handled, I see no point in discussing this further. Ned From dhc@dcrocker.net Fri Aug 19 14:11: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 61A0C21F8B4F for ; Fri, 19 Aug 2011 14:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siCcZnz7l8uq for ; Fri, 19 Aug 2011 14:11:02 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8F23921F8B53 for ; Fri, 19 Aug 2011 14:11:02 -0700 (PDT) Received: from [192.168.1.156] (adsl-68-122-69-114.dsl.pltn13.pacbell.net [68.122.69.114]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p7JLBsvU028940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 19 Aug 2011 14:11:59 -0700 Message-ID: <4E4ED197.9080008@dcrocker.net> Date: Fri, 19 Aug 2011 14:11:51 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20110726125042.1180.12955.idtracker@ietfa.amsl.com> <4E2EBA34.5090604@stpeter.im> <4E44A777.3000902@gmail.com> <01O4SNTZFJZ200VHKR@mauve.mrochek.com> <4E4BD33E.6050002@gmail.com> <01O4Y7R78O5000VHKR@mauve.mrochek.com> <4E4CAA4B.6070100@gmail.com> <01O4ZN66MODE00RCTX@mauve.mrochek.com> In-Reply-To: <01O4ZN66MODE00RCTX@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]); Fri, 19 Aug 2011 14:11:59 -0700 (PDT) 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 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: Fri, 19 Aug 2011 21:11:03 -0000 On 8/18/2011 8:36 AM, Ned Freed wrote: >> But x. convention and vnd. convention are quite contiguous; > > I don't know what this is suppposed to mean. These are separate namespaces, > each with it's own rules. They are adjacent in some ways, opposites in some > ways, and disjoint in some ways. This specification covers X- usage. It covers nothing else. That includes not covering its "neighbors". In the most literal sense, those are out of scope. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From evnikita2@gmail.com Fri Aug 19 22:08: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 33BBB21F8B47 for ; Fri, 19 Aug 2011 22:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paqbTBFs2oB2 for ; Fri, 19 Aug 2011 22:08:52 -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 70D2821F8B45 for ; Fri, 19 Aug 2011 22:08:52 -0700 (PDT) Received: by fxe6 with SMTP id 6so2543383fxe.31 for ; Fri, 19 Aug 2011 22:09:50 -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=PZBaiGzCKmIjt0H7TsfxigWYzWFVrynUwNvNffxTZVI=; b=UJENGnGR3ex6nI0QpLZzOBS/Ap0SHk5K2PEkbo/hL2uVuzyBXlbtsHDpN9Gy6imGV6 Zg+icy+uC2SYtj1voOvJHnVPVv7PBru/N1Ta+LrzZuEQ93IjrxoYCprD++0Rz0J6ghFu cc8Js2x6V186qsJIyKq21Nui7zenCxPZfJun0= Received: by 10.223.76.202 with SMTP id d10mr288718fak.106.1313816990560; Fri, 19 Aug 2011 22:09:50 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id d1sm3095554fai.28.2011.08.19.22.09.48 (version=SSLv3 cipher=OTHER); Fri, 19 Aug 2011 22:09:49 -0700 (PDT) Message-ID: <4E4F41C0.9040901@gmail.com> Date: Sat, 20 Aug 2011 08:10:24 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20110726125042.1180.12955.idtracker@ietfa.amsl.com> <4E2EBA34.5090604@stpeter.im> <4E44A777.3000902@gmail.com> <01O4SNTZFJZ200VHKR@mauve.mrochek.com> <4E4BD33E.6050002@gmail.com> <01O4Y7R78O5000VHKR@mauve.mrochek.com> <4E4CAA4B.6070100@gmail.com> <01O4ZN66MODE00RCTX@mauve.mrochek.com> <4E4ED197.9080008@dcrocker.net> In-Reply-To: <4E4ED197.9080008@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Sat, 20 Aug 2011 05:08:53 -0000 20.08.2011 0:11, Dave CROCKER wrote: > > > On 8/18/2011 8:36 AM, Ned Freed wrote: >>> But x. convention and vnd. convention are quite contiguous; >> >> I don't know what this is suppposed to mean. These are separate >> namespaces, >> each with it's own rules. They are adjacent in some ways, opposites >> in some >> ways, and disjoint in some ways. > > > This specification covers X- usage. It covers nothing else. That > includes not covering its "neighbors". > > In the most literal sense, those are out of scope. OK, after all, I don't insist. Mykyta > > d/ > From evnikita2@gmail.com Sun Aug 21 02:37: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 EC52821F8ABB for ; Sun, 21 Aug 2011 02:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhCFrPSuRBUh for ; Sun, 21 Aug 2011 02:37:03 -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 D413C21F8AAC for ; Sun, 21 Aug 2011 02:37:02 -0700 (PDT) Received: by fxe6 with SMTP id 6so3013150fxe.31 for ; Sun, 21 Aug 2011 02:38:02 -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=UWS9cJHjs/+clOredrNyK6Mp/e5RjOgI1y48A4ZmTik=; b=PqbiW0+Qh4REAZX1BcdCyD7a7htk7pZg8MhPBJ37fkbaSnN1D8WvPxyty0okMoimVu YOTK5/X2tO+ihIR7CWRpweGzr19Nz/ThySE5PMgkJvaddjw9Hbj0E9YgwAUeNGqXg55R mbRA5hhBIG9TklzJ/5O2wEhuYU6EOEFWCgwXo= Received: by 10.223.55.205 with SMTP id v13mr1897601fag.88.1313919482406; Sun, 21 Aug 2011 02:38:02 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id d1sm4103065fai.4.2011.08.21.02.37.59 (version=SSLv3 cipher=OTHER); Sun, 21 Aug 2011 02:38:01 -0700 (PDT) Message-ID: <4E50D21B.1070500@gmail.com> Date: Sun, 21 Aug 2011 12:38:35 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Apps-discuss list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Missing IANA Considerations for TFTP 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, 21 Aug 2011 09:37:04 -0000 Hello all, Trivial File Transfer Protocol (TFTP), which is defined in RFC 1350 (that is currently at Full Standard level, BTW), makes use of several values which are to be tracked by IANA. They include: OpCode values, transfer modes, error codes, and option numbers (see RFC 2347 for description of the latter). However, currently IANA doesn't maintain any registries related to TFTP, neither can I find any in RFC 1700, the last of "Assigned Numbers" series. Correspondingly, the question: Is it useful to write and publish the document defining IANA considerations for TFTP? Mykyta Yevstifeyev From presnick@qualcomm.com Sun Aug 21 10:25: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 950F921F852E for ; Sun, 21 Aug 2011 10:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.506 X-Spam-Level: X-Spam-Status: No, score=-106.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HEoWAAuT0pr for ; Sun, 21 Aug 2011 10:25:53 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 0A95D21F852C for ; Sun, 21 Aug 2011 10:25: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=1313947615; x=1345483615; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4E513FDB.7090000@qualcomm.com>|Date:=20Su n,=2021=20Aug=202011=2012:26:51=20-0500|From:=20Pete=20Re snick=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:=20Apps=20Discuss=20|Subject:=20draft-yevstifeyev-pop-wrong-state |Content-Type:=20text/plain=3B=20charset=3D"ISO-8859-1" =3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-Originating-IP:=20[172.30.39.5]; bh=7H86k5AdaOcFPURwxfiysPQQw0SnRtzJ2yo1sUYLo/s=; b=rwZd3YHlv0kKAlyoCTmKu2YqSuogJTR1ppsdo9JMjrp+QX2jrtYghdN8 7Kdfk5l6hmS1u+q4qkgTO3vOQTa6vj7gl1A/HLwN7UYTj/uzgZJx607qC 7OC3xTrSDddXWX3dNVdQSCh5bdFrs2eN+E3I+2glSlOQ2g3+HB2mPVLtO g=; X-IronPort-AV: E=McAfee;i="5400,1158,6445"; a="111868107" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 21 Aug 2011 10:26:54 -0700 X-IronPort-AV: E=Sophos;i="4.68,258,1312182000"; d="scan'208";a="101055094" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 21 Aug 2011 10:26:54 -0700 Received: from Macintosh-4.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 21 Aug 2011 10:26:54 -0700 Message-ID: <4E513FDB.7090000@qualcomm.com> Date: Sun, 21 Aug 2011 12:26:51 -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: Apps Discuss Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Subject: [apps-discuss] draft-yevstifeyev-pop-wrong-state 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, 21 Aug 2011 17:25:53 -0000 Greetings all, [Non-WG item] The ISE received draft-yevstifeyev-pop-wrong-state to publish as an Experimental document in the Independent RFC submission stream and has asked me to check on its suitability. Two questions for the list: 1. Is there significant interest in implementing this POP response code extension? I ask because, if there is, it might be more appropriate to bring this into some Applications working group. 2. If there isn't widespread interest, does anyone see any harm in this being published as Experimental in the Independent stream? It seems to me a very simple extension with little significant impact. Thoughts welcome. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Sun Aug 21 10:48: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 60F8021F8A58 for ; Sun, 21 Aug 2011 10:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.783 X-Spam-Level: X-Spam-Status: No, score=-102.783 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kcd2TBK2pq+1 for ; Sun, 21 Aug 2011 10:48:21 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id E5EF721F84FA for ; Sun, 21 Aug 2011 10:48:20 -0700 (PDT) Received: by pzk33 with SMTP id 33so14283207pzk.18 for ; Sun, 21 Aug 2011 10:49: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; bh=qn4prtAHyocAXMntCDygxobV2L3ab6HhGefpDOKIbro=; b=DcCcxR0UVDJ70F3Q0lCoeJq27ps6C1gdEWarVKMoX6p5jjVrP449W4a1dqnWcK72m3 g79g540hLqVg4vu5yElSDhr+2Uhh+Lue2khrvAABk2oddwxyAAaz4klD7TNtZqam2NJY ZOa2iJQwt9Z11jc9NFaTOQD+L0O/7M3i2EXy8= Received: by 10.143.69.12 with SMTP id w12mr1091110wfk.298.1313948963256; Sun, 21 Aug 2011 10:49:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.98.5 with HTTP; Sun, 21 Aug 2011 10:49:03 -0700 (PDT) In-Reply-To: <4E50D21B.1070500@gmail.com> References: <4E50D21B.1070500@gmail.com> From: Frank Ellermann Date: Sun, 21 Aug 2011 19:49:03 +0200 Message-ID: To: Mykyta Yevstifeyev Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps-discuss list Subject: Re: [apps-discuss] Missing IANA Considerations for TFTP 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, 21 Aug 2011 17:48:21 -0000 On 21 August 2011 11:38, Mykyta Yevstifeyev wrote: > currently IANA doesn't maintain any registries related to TFTP Arguably "bootp-dhcp-parameters" is related, maybe TFTP assignments could be merged into this existing registry. > Is it useful to write and publish the document defining IANA > considerations for TFTP? The authors of RFCs 2347..2349 apparently decided that it was not necessary to create TFTP registries in 1998. Only a wild guess, "missing" IANA considerations cannot say why they are "missing". Did you look into old mailing list archives? If it is a general IANA registry problem let's discuss it on the "happy IANA" list. The service-names-port-numbers.xml is *huge*, but the TFTP ports, four SUBNTBCST_TFTP variants, tftp-mcast, etftp, and tftps are listed. But this registry doesn't tell me what ETFTP, TFTPS, etc. really was or is. -Frank From mnot@mnot.net Sun Aug 21 20:07: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 E288F21F86AB for ; Sun, 21 Aug 2011 20:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.608 X-Spam-Level: X-Spam-Status: No, score=-105.608 tagged_above=-999 required=5 tests=[AWL=-3.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6GJ-o5i-7Bm for ; Sun, 21 Aug 2011 20:07:09 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3F98221F8581 for ; Sun, 21 Aug 2011 20:07:08 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.37.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5C1F122E1F4; Sun, 21 Aug 2011 23:08:06 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Aug 2011 13:08:02 +1000 Message-Id: <923B73A9-B10B-48AB-A6BA-147D76D7073A@mnot.net> To: Apps Discuss Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Cc: Ned Freed , John C Klensin Subject: [apps-discuss] Organisation of draft-freed-media-type-regs-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, 22 Aug 2011 03:07:10 -0000 Overall, it seems like there's a fair amount of restatement between = section 4 and those that precede it. I think many people will skip = straight to section 4, believing it to be most relevant to them, and = without reference to specific requirements in the rest of the document, = they'll end up confused and sometimes mislead. Furthermore, section 4 isn't clear about the step-by-step procedure = that's appropriate to various cases. For example, 4.12.2 and 4.12.4 both = refer to a review, but it's not clear to a casual reader whether they're = different reviews or the same one.=20 I think that this can be addressed by moving much of the content in = section 4 into the various subsections of section 3, in the form of = concrete, numbered lists of steps to take to register the various kinds = of media types. This might result in some duplication (which in the = worst cases can be solved by references to new shared sections), but = that's preferable to confusing readers. I'm happy to take a stab at this if the authors would like an = illustration of what I mean (and they can provide XML source). Cheers, -- Mark Nottingham http://www.mnot.net/ From evnikita2@gmail.com Sun Aug 21 21:16: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 5CBB721F85FE for ; Sun, 21 Aug 2011 21:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxjGmMD35tUB for ; Sun, 21 Aug 2011 21:16:48 -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 2060C21F85E3 for ; Sun, 21 Aug 2011 21:16:47 -0700 (PDT) Received: by fxe6 with SMTP id 6so3354241fxe.31 for ; Sun, 21 Aug 2011 21:17:51 -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=v5ojfXBiuht0jRJU4bFPlkso4L+YRZy6fS2ssnknUfc=; b=dckE6145NQT1OXnuucLus3YqmWfyH/19MUUU+heX50SqhQuh4hOWanPpQ48aD9bmf4 p3QQqIZxH29CDL/lYLt1d7L1OsYpJPFDtNV6PSvLSo9lGWGWnt4Yp6B4DhvvdCXahk8w 4dmvngejRA3roUHBUFumUhQKGXjUsxqAGOoMo= Received: by 10.223.26.71 with SMTP id d7mr3022849fac.23.1313986671401; Sun, 21 Aug 2011 21:17:51 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id 11sm4781054fav.34.2011.08.21.21.17.49 (version=SSLv3 cipher=OTHER); Sun, 21 Aug 2011 21:17:50 -0700 (PDT) Message-ID: <4E51D891.20609@gmail.com> Date: Mon, 22 Aug 2011 07:18:25 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Frank Ellermann References: <4E50D21B.1070500@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Harald Alvestrand , Apps-discuss list Subject: Re: [apps-discuss] Missing IANA Considerations for TFTP 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, 22 Aug 2011 04:16:49 -0000 21.08.2011 20:49, Frank Ellermann wrote: > On 21 August 2011 11:38, Mykyta Yevstifeyev wrote: > >> currently IANA doesn't maintain any registries related to TFTP > Arguably "bootp-dhcp-parameters" is related, maybe TFTP assignments > could be merged into this existing registry. I had a look at this registry - it isn't related to TFTP in any way other than listing several DHCP options related to TFTP. > >> Is it useful to write and publish the document defining IANA >> considerations for TFTP? > The authors of RFCs 2347..2349 apparently decided that it was not > necessary to create TFTP registries in 1998. Only a wild guess, > "missing" IANA considerations cannot say why they are "missing". > Did you look into old mailing list archives? Well, the only WG ever chartered and related to TFTP is some way is tftpext, which produced RFCs 1782-1784 (http://tools.ietf.org/wg/tftpexts/). IETF site has no archives; neither have some non-IETF archives (I found http://mirrors.fe.up.pt/pub/rfc/concluded-wg-ietf-mail-archive/tftpexts/ and http://ftp.sh.cvut.cz/MIRRORS/ietf/concluded-wg-ietf-mail-archive/tftpexts/). The original mailing list was hosted at hpindsh.cup.hp.com and original archive was placed at onet2.cup.hp.com/pub/dist/tftpexts/tftpexts_archive (see http://webcache.googleusercontent.com/search?q=cache:xueLfMKFuxoJ:ftp://ftp.ietf.org/ietf-online-proceedings/94dec/area.and.wg.reports/app/tftpexts/tftpexts.malkin.slides.ps+Tftpexts+mailing+archive&cd=1&hl=en&ct=clnk&client=firefox&source=www.google.com). However, none of those servers responded to me; so I conclude it is impossible to find tftpext archives. RFCs 2347..2349 were Individual Submissions, and their only purpose, I guess, was to advance tftpext stuff to Draft Standard. IESG "protocol action" message (http://www.ietf.org/mail-archive/web/ietf/current/msg05939.html) doesn't have the "community consensus" section, which would point me to some discussion forum. It mentions, though, that IESG contact person is Harald Alvestrand, whom I'm cc'ing this message to supposing he has some additional info for this topic. So now I have no idea why TFTP IANA considerations are missing. > > If it is a general IANA registry problem let's discuss it on the > "happy IANA" list. The service-names-port-numbers.xml is *huge*, > but the TFTP ports, four SUBNTBCST_TFTP variants, tftp-mcast, > etftp, and tftps are listed. But this registry doesn't tell me > what ETFTP, TFTPS, etc. really was or is. I guess the situation is: tftp - RFC 1350; subntbcast-tftp - have no idea what is stands for; tftps - I suppose this is used with something like an "adaptation of 4217 for TFTP"; tftp-mcast - https://datatracker.ietf.org/doc/draft-koren-tftp-multicast-option/; https://datatracker.ietf.org/doc/draft-rfced-exp-yung/; etftp - RFC 1986; http://www.networksorcery.com/enp/protocol/etftp.htm. Mykyta Yevstifeyev > > -Frank > From harald@alvestrand.no Sun Aug 21 23:01: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 CF56221F8760 for ; Sun, 21 Aug 2011 23:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.113 X-Spam-Level: X-Spam-Status: No, score=-102.113 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zQttymRzrsr for ; Sun, 21 Aug 2011 23:01:22 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 677A021F8661 for ; Sun, 21 Aug 2011 23:01:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AC99039E26C; Mon, 22 Aug 2011 08:01:11 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJXa30HXf7IH; Mon, 22 Aug 2011 08:01:09 +0200 (CEST) Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 5C1E539E24F; Mon, 22 Aug 2011 08:00:10 +0200 (CEST) Message-ID: <4E51F0B4.1020102@alvestrand.no> Date: Mon, 22 Aug 2011 08:01:24 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mykyta Yevstifeyev References: <4E50D21B.1070500@gmail.com> <4E51D891.20609@gmail.com> In-Reply-To: <4E51D891.20609@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps-discuss list Subject: Re: [apps-discuss] Missing IANA Considerations for TFTP 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, 22 Aug 2011 06:01:23 -0000 TFTP is a protocol of ultimate stupidity^^^^naivete, made for a simpler and less paranoid world; why do you want to touch it at all? As to why the protocol action from May 1998 does not mention IANA considerations - this was before the IANA considerations got completely institutionalized - RFC 2434 was still 5 months in the future. My very vague memory of this action was that it was a personal effort from Gary Malkin to promote to Draft the useful parts of the results of the expired TFTP group, hoping eventually to be on the same level (Standard) as the base spec. Note that these are advancement-in-grade RFCs; the Proposed Standard versions were published in 1995. My recommendation: It's been 15 years or more since someone really cared about these non-registries. Let this particular corpse sleep in peace. Harald On 08/22/2011 06:18 AM, Mykyta Yevstifeyev wrote: > 21.08.2011 20:49, Frank Ellermann wrote: >> On 21 August 2011 11:38, Mykyta Yevstifeyev wrote: >> >>> currently IANA doesn't maintain any registries related to TFTP >> Arguably "bootp-dhcp-parameters" is related, maybe TFTP assignments >> could be merged into this existing registry. > > I had a look at this registry - it isn't related to TFTP in any way > other than listing several DHCP options related to TFTP. > >> >>> Is it useful to write and publish the document defining IANA >>> considerations for TFTP? >> The authors of RFCs 2347..2349 apparently decided that it was not >> necessary to create TFTP registries in 1998. Only a wild guess, >> "missing" IANA considerations cannot say why they are "missing". >> Did you look into old mailing list archives? > > Well, the only WG ever chartered and related to TFTP is some way is > tftpext, which produced RFCs 1782-1784 > (http://tools.ietf.org/wg/tftpexts/). IETF site has no archives; > neither have some non-IETF archives (I found > http://mirrors.fe.up.pt/pub/rfc/concluded-wg-ietf-mail-archive/tftpexts/ > and > http://ftp.sh.cvut.cz/MIRRORS/ietf/concluded-wg-ietf-mail-archive/tftpexts/). > The original mailing list was hosted at hpindsh.cup.hp.com and > original archive was placed at > onet2.cup.hp.com/pub/dist/tftpexts/tftpexts_archive (see > http://webcache.googleusercontent.com/search?q=cache:xueLfMKFuxoJ:ftp://ftp.ietf.org/ietf-online-proceedings/94dec/area.and.wg.reports/app/tftpexts/tftpexts.malkin.slides.ps+Tftpexts+mailing+archive&cd=1&hl=en&ct=clnk&client=firefox&source=www.google.com). > However, none of those servers responded to me; so I conclude it is > impossible to find tftpext archives. > > RFCs 2347..2349 were Individual Submissions, and their only purpose, I > guess, was to advance tftpext stuff to Draft Standard. > > IESG "protocol action" message > (http://www.ietf.org/mail-archive/web/ietf/current/msg05939.html) > doesn't have the "community consensus" section, which would point me > to some discussion forum. It mentions, though, that IESG contact > person is Harald Alvestrand, whom I'm cc'ing this message to supposing > he has some additional info for this topic. > > So now I have no idea why TFTP IANA considerations are missing. > >> >> If it is a general IANA registry problem let's discuss it on the >> "happy IANA" list. The service-names-port-numbers.xml is *huge*, >> but the TFTP ports, four SUBNTBCST_TFTP variants, tftp-mcast, >> etftp, and tftps are listed. But this registry doesn't tell me >> what ETFTP, TFTPS, etc. really was or is. > > I guess the situation is: > > tftp - RFC 1350; > subntbcast-tftp - have no idea what is stands for; > tftps - I suppose this is used with something like an "adaptation of > 4217 for TFTP"; > tftp-mcast - > https://datatracker.ietf.org/doc/draft-koren-tftp-multicast-option/; > https://datatracker.ietf.org/doc/draft-rfced-exp-yung/; > etftp - RFC 1986; http://www.networksorcery.com/enp/protocol/etftp.htm. > > Mykyta Yevstifeyev > >> >> -Frank >> > > From john-ietf@jck.com Mon Aug 22 00:26: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 D9B7721F873A for ; Mon, 22 Aug 2011 00:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9lwhE1qDIQg for ; Mon, 22 Aug 2011 00:26:52 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id D6DEB21F86AC for ; Mon, 22 Aug 2011 00:26:51 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QvOvF-000Hcv-6H; Mon, 22 Aug 2011 03:27:49 -0400 X-Vipre-Scanned: 0D0130850028000D0131D2-TDI Date: Mon, 22 Aug 2011 03:27:48 -0400 From: John C Klensin To: Harald Alvestrand , Mykyta Yevstifeyev Message-ID: <2936C17968C3337AA978E4A4@localhost> In-Reply-To: <4E51F0B4.1020102@alvestrand.no> References: <4E50D21B.1070500@gmail.com> <4E51D891.20609@gmail.com> <4E51F0B4.1020102@alvestrand.no> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Apps-discuss list Subject: Re: [apps-discuss] Missing IANA Considerations for TFTP 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, 22 Aug 2011 07:26:53 -0000 --On Monday, August 22, 2011 08:01 +0200 Harald Alvestrand wrote: > TFTP is a protocol of ultimate stupidity^^^^naivete, made for > a simpler and less paranoid world; why do you want to touch it > at all? > > As to why the protocol action from May 1998 does not mention > IANA considerations - this was before the IANA considerations > got completely institutionalized - RFC 2434 was still 5 months > in the future. >... > My recommendation: It's been 15 years or more since someone > really cared about these non-registries. Let this particular > corpse sleep in peace. +1 I would add two things to Harald's comments: -- Historically, we rarely created IANA registries for protocol options unless we expected an ongoing series of added options. As an example, the FTP registry created by RFC 5797 arguably should have been created when a formal extension mechanism was established in RFC 3659, but none was established earlier despite the fact that the authors of RFC 959 could have established such a registry with no external approval action whatsoever. -- Because TFTP lacks even rudimentary, symbolic, security mechanisms, it is unsuited for use on the public Internet. If it is appropriate for any use at all any more, it is for well-protected LANs and walled gardens with really high and effective walls. If someone wanted to put in energy on TFTP today, I think that energy would be better spent in a good security analysis and set of recommendations as to how to use it safely. Such a document would probably be difficult to write unless one took the easy path of a document that, boilerplate and structure aside, would consist of one line: "Just say 'no'". john From ietfc@btconnect.com Mon Aug 22 01:43: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 BABB321F8AD1 for ; Mon, 22 Aug 2011 01:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95HM9zOtVB1y for ; Mon, 22 Aug 2011 01:43:56 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by ietfa.amsl.com (Postfix) with ESMTP id BF0FD21F8ACC for ; Mon, 22 Aug 2011 01:43:55 -0700 (PDT) Received: from host109-153-79-81.range109-153.btcentralplus.com (HELO pc6) ([109.153.79.81]) by c2beaomr10.btconnect.com with SMTP id EAB68997; Mon, 22 Aug 2011 09:44:52 +0100 (BST) Message-ID: <011f01cc609e$e02dd0e0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Mykyta Yevstifeyev" , "Apps-discuss list" References: <4E50D21B.1070500@gmail.com> Date: Mon, 22 Aug 2011 09:41:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E521704.004B, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.8.22.80018:17:7.586, ip=109.153.79.81, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_1000_1099, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0207.4E52170A.00BC,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: Re: [apps-discuss] Missing IANA Considerations for TFTP 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, 22 Aug 2011 08:43:56 -0000 ----- Original Message ----- From: "Mykyta Yevstifeyev" To: "Apps-discuss list" Sent: Sunday, August 21, 2011 11:38 AM > Hello all, > > Trivial File Transfer Protocol (TFTP), which is defined in RFC 1350 > (that is currently at Full Standard level, BTW), makes use of several > values which are to be tracked by IANA. They include: OpCode values, > transfer modes, error codes, and option numbers (see RFC 2347 for > description of the latter). However, currently IANA doesn't maintain > any registries related to TFTP, neither can I find any in RFC 1700, the > last of "Assigned Numbers" series. Correspondingly, the question: Is > it useful to write and publish the document defining IANA considerations > for TFTP? No. Dead protocol in the sense that it is not one that the IETF has worked on for decades. Now an I-D which declared it Historic, for some meaning of Historic, that might be interesting .... Tom Petch > > Mykyta Yevstifeyev From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Mon Aug 22 01: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 8768821F8AD8 for ; Mon, 22 Aug 2011 01:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.79 X-Spam-Level: X-Spam-Status: No, score=-102.79 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MicU2iIa9QgN for ; Mon, 22 Aug 2011 01:52:28 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id D59AB21F8ACC for ; Mon, 22 Aug 2011 01:52:28 -0700 (PDT) Received: by pzk33 with SMTP id 33so16082491pzk.18 for ; Mon, 22 Aug 2011 01:53:33 -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=+YFKNF8lW9vNlnEcDZQTfOP5l2D/J6tH9VsjznLp5j4=; b=YFZX9L3cbb3cRR1qiPkbKsFKXZEQI8jwh6rFOvbF6v1kOvamCcednURJIMerKFVRz1 /maPezZ8LY85TA2a1X9Liz1DqcXYAj7/0XhRabP8hcrWbejfq3RiWBB4CjZ/ya918T28 iZng222yBMaKaUitEzCxxVsF/mcnwjBqiSAOs= Received: by 10.142.44.15 with SMTP id r15mr1515380wfr.127.1314003213139; Mon, 22 Aug 2011 01:53:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.98.5 with HTTP; Mon, 22 Aug 2011 01:53:13 -0700 (PDT) In-Reply-To: <2936C17968C3337AA978E4A4@localhost> References: <4E50D21B.1070500@gmail.com> <4E51D891.20609@gmail.com> <4E51F0B4.1020102@alvestrand.no> <2936C17968C3337AA978E4A4@localhost> From: Frank Ellermann Date: Mon, 22 Aug 2011 10:53:13 +0200 Message-ID: To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Cc: Harald Alvestrand , Apps-discuss list Subject: Re: [apps-discuss] Missing IANA Considerations for TFTP 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, 22 Aug 2011 08:52:29 -0000 On 22 August 2011 09:27, John C Klensin wrote: > Historically, we rarely created IANA registries for protocol > options unless we expected an ongoing series of added options. Good. Creating obscure IANA registries and expert review lists before they are actually needed could be pointless, i.e., as long as all interesting protocol parameters can be found in one RFC. And expert review lists not more working after years when eventually somebody found something to register would be worse. > As an example, the FTP registry created by RFC 5797 arguably > should have been created when a formal extension mechanism was > established in RFC 3659 Only four of five stars, because RFC 5797 does not mention the registry URL. But the RFC 3659 registry is a dubious example: > Because TFTP lacks even rudimentary, symbolic, security > mechanisms, it is unsuited for use on the public Internet. Maybe the TFTPS in the port registry was meant to improve it. When a modern BIOS offers a "net boot" it *is* talking about TFTP, or isn't it? I'm not planning to implement or test it. There is even a registered TFTP URI scheme in RFC 3617, and if I understand RFC 3617 correctly it tried to *deprecate* TFTP without actually doing it using pre STD 66 terminology. But I have an idea what happened, note to self, do not try to update cram-md5 by scram-md5, or rather, don't try this in the IETF. > If someone wanted to put in energy on TFTP today, I think > that energy would be better spent in a good security analysis > and set of recommendations as to how to use it safely. "Security" is some IETF stuff that is deprecated before I begin to grok what it was actually about, I try to avoid it unless it is a nice test case for an MD5 test suite: It can now emulate RFC 2777, did you ever wish to check NomCom random selections for the years before RFC 3797? -Frank From barryleiba.mailing.lists@gmail.com Tue Aug 23 09:59: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 29BC221F8B8A for ; Tue, 23 Aug 2011 09:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.032 X-Spam-Level: X-Spam-Status: No, score=-103.032 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWaSVZPDxRMk for ; Tue, 23 Aug 2011 09:59:21 -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 A384E21F8B7F for ; Tue, 23 Aug 2011 09:59:21 -0700 (PDT) Received: by yie12 with SMTP id 12so290144yie.31 for ; Tue, 23 Aug 2011 10:00: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; bh=5vNGxWc4nGGfBjn19wxlWO/zBTadE4G+AIYgMEWJxNI=; b=LnR0IOizhnmpyzR+5LCMZsiMA+EUtjiCCWxtyyG2UPD2lj+fMkXaR5ApE0I8zjnjzw Y4sNLoG44cJmDX/hEeSnv1uQMrMLzLgE2Uh1yQnPY1pQKDAort0XgjccGeWBWtNuVrSe 07GJfXQoEmY85xtjpni2FmAvmAZHo97ahklj8= MIME-Version: 1.0 Received: by 10.236.72.169 with SMTP id t29mr24593002yhd.110.1314118829711; Tue, 23 Aug 2011 10:00:29 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.181.13 with HTTP; Tue, 23 Aug 2011 10:00:29 -0700 (PDT) In-Reply-To: <4E513FDB.7090000@qualcomm.com> References: <4E513FDB.7090000@qualcomm.com> Date: Tue, 23 Aug 2011 13:00:29 -0400 X-Google-Sender-Auth: JESv_wO81ZHA1M4l_5koHK3k6YY Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps Discuss Subject: Re: [apps-discuss] draft-yevstifeyev-pop-wrong-state 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, 23 Aug 2011 16:59:22 -0000 > 1. Is there significant interest in implementing this POP response code > extension? I ask because, if there is, it might be more appropriate to bring > this into some Applications working group. I can't imagine that there'll be a lot of interest. POP clients and servers have been interoperating well for a good many years without this response code, and I don't see folks lining up to rev their code for something that basically amounts to servers helping new clients debug their bad implementations. > 2. If there isn't widespread interest, does anyone see any harm in this > being published as Experimental in the Independent stream? It seems to me a > very simple extension with little significant impact. It appears to me to be fairly useless, but totally harmless. I think it's a waste of time, but I otherwise have no objection to it. Barry From stpeter@stpeter.im Tue Aug 23 12:17: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 D958D21F8CF7 for ; Tue, 23 Aug 2011 12:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkOmoq5KHxJ4 for ; Tue, 23 Aug 2011 12:17:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4F10E21F8CE3 for ; Tue, 23 Aug 2011 12:17:13 -0700 (PDT) Received: from dhcp-64-101-72-239.cisco.com (unknown [64.101.72.239]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E92A9415A0 for ; Tue, 23 Aug 2011 13:20:36 -0600 (MDT) Message-ID: <4E53FCFC.4030101@stpeter.im> Date: Tue, 23 Aug 2011 13:18:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] my IESG plans 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, 23 Aug 2011 19:17:14 -0000 I will not be seeking re-nomination as Applications Area Director. Although I've enjoyed serving the community and I feel like I've only recently understood how to perform the role with some acceptable level of competence, responsibilities at my day job beckon. If you know of individuals who might want to serve as Apps AD, please nominate them at the NomCom website: https://www.ietf.org/group/nomcom/2011/ If you think you might be interested in serving but you want to know more about what it's like to be an AD, feel free to contact me directly. Peter -- Peter Saint-Andre https://stpeter.im/ From chris.newman@oracle.com Wed Aug 24 10:40: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 2DA0321F8C20 for ; Wed, 24 Aug 2011 10:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.377 X-Spam-Level: X-Spam-Status: No, score=-105.377 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTfKjC7W2Oya for ; Wed, 24 Aug 2011 10:40:06 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3123721F8C15 for ; Wed, 24 Aug 2011 10:40:03 -0700 (PDT) Received: from brmsunmail2-sfbay.uk.sun.com ([10.79.11.101]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id p7OHetCm024298; Wed, 24 Aug 2011 17:41:00 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail2-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p7OHes30038031; Wed, 24 Aug 2011 17:40:55 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LQG00028141TS00@gotmail.us.oracle.com>; Wed, 24 Aug 2011 10:40:54 -0700 (PDT) Date: Tue, 23 Aug 2011 23:25:01 -0700 From: Chris Newman To: Barry Leiba , Pete Resnick Message-id: <3F84B765B8137ED27B0A8891@nifty-silver.local> In-reply-to: References: <4E513FDB.7090000@qualcomm.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) Cc: Apps Discuss Subject: Re: [apps-discuss] draft-yevstifeyev-pop-wrong-state 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, 24 Aug 2011 17:40:07 -0000 --On August 23, 2011 13:00:29 -0400 Barry Leiba wrote: >> 1. Is there significant interest in implementing this POP response code >> extension? I ask because, if there is, it might be more appropriate to >> bring this into some Applications working group. > > I can't imagine that there'll be a lot of interest. POP clients and > servers have been interoperating well for a good many years without > this response code, and I don't see folks lining up to rev their code > for something that basically amounts to servers helping new clients > debug their bad implementations. POP clients do not interoperate well when using TLS client certificate authentication on port 995. This might have been useful if the discussion around draft-melnikov-pop3-over-tls-01.txt had a different outcome, but I do not view it as particularly useful presently. >> 2. If there isn't widespread interest, does anyone see any harm in this >> being published as Experimental in the Independent stream? It seems to >> me a very simple extension with little significant impact. > > It appears to me to be fairly useless, but totally harmless. I think > it's a waste of time, but I otherwise have no objection to it. I'd call it "mostly harmless" :-). If a server implementation tries to be helpful prior to authentication, that might increase the code attack surface albeit by very little. But the draft does not require that behavior. Non-standards track RFCs do end up in RFPs sometimes and this one might fall in the category of "easier to implement than to try to correct a bad RFP". So it could end up wasting implementer time, albeit not very much. I have no objections to going ahead with this. If someone is motivated to do specification work I do not like to discourage them with a hard rejection and it's helpful for them to learn the hard way that publishing an RFC does not result in useful deployment ;-). - Chris From evnikita2@gmail.com Mon Aug 29 08:32: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 A3CF721F8C0B for ; Mon, 29 Aug 2011 08:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5XE6LVBrY+D for ; Mon, 29 Aug 2011 08:32:02 -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 9DC9021F8C08 for ; Mon, 29 Aug 2011 08:32:02 -0700 (PDT) Received: by fxe6 with SMTP id 6so4946043fxe.31 for ; Mon, 29 Aug 2011 08:33:24 -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=uSkW3w9FsxyuZauMvBY3xQ6Ei5hEwaJatqOpuSypbOM=; b=fhqrfebPmLbCykxIJNjWO92ko1Cc3e6a4JfsfAEBqPY14P/7SiwwFwrP1UOBZgxtT4 LA4FWaNZeJ3w1ogTRrhVnDSrjzJ0FAXkAva5EB/OocOOSzcdSh+beKvy6zOxh+p0FaJS +QUah5g6iFbTSkTcLeHvbuDm/qn0O+MTzPhpY= Received: by 10.223.68.136 with SMTP id v8mr7187963fai.54.1314632003999; Mon, 29 Aug 2011 08:33:23 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id b14sm3840905fak.29.2011.08.29.08.33.21 (version=SSLv3 cipher=OTHER); Mon, 29 Aug 2011 08:33:22 -0700 (PDT) Message-ID: <4E5BB162.6010101@gmail.com> Date: Mon, 29 Aug 2011 18:33:54 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20110531062229.28776.82429.idtracker@ietfa.amsl.com> <0CE9268E-5802-4B0A-B643-F580E7F048B5@mnot.net> In-Reply-To: <0CE9268E-5802-4B0A-B643-F580E7F048B5@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-02.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, 29 Aug 2011 15:32:03 -0000 Proposal for a new hint: > 5.8. https > > o Browser Hint Name: https > o Description: When true, this hint indicates the user agent may > use HTTPS and, correspondigly, 'https' URI scheme [RFC2818] with > the specific areas (resources) of the site. > o Value Type: prefixlist > o Contact: /somebody/ Mykyta Yevstifeyev 31.05.2011 9:28, Mark Nottingham wrote: > FYI. Diffs at: > http://tools.ietf.org/rfcdiff?url2=draft-nottingham-http-browser-hints-02 > > Changelog: > - removed Ref header and rearranged referer-based hints > - added 'prefixlist' value type > - changed omit-cookies from list of cookie names to prefixlist > - added caching advice for 404s > > Feedback appreciated, as always. > > > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Date: 31 May 2011 4:22:29 PM AEST >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-nottingham-http-browser-hints-02.txt >> Reply-To: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> Title : HTTP Browser Hints >> Author(s) : Mark Nottingham >> Filename : draft-nottingham-http-browser-hints-02.txt >> Pages : 9 >> Date : 2011-05-30 >> >> Over time, Web browsers have adapted how they use HTTP based upon >> common server configurations and behaviours. While this is necessary >> in the common case, it can be detrimental for performance and >> interoperability. >> >> This document establishes a mechanism whereby origin servers can make >> available hints for browsers about their preferences and >> capabilities, without imposing overhead on their interactions or >> requiring support for them. >> >> This is intended to allow browsers to safely optimise connections to >> servers. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02.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-nottingham-http-browser-hints-02.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 > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From evnikita2@gmail.com Mon Aug 29 08:53: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 56D5D21F8839 for ; Mon, 29 Aug 2011 08:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pE7YDcKoCTOQ for ; Mon, 29 Aug 2011 08:53:22 -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 9764D21F87C5 for ; Mon, 29 Aug 2011 08:53:22 -0700 (PDT) Received: by fxe6 with SMTP id 6so4964082fxe.31 for ; Mon, 29 Aug 2011 08:54: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:subject :content-type:content-transfer-encoding; bh=GcOuNctj6vRBgJJbEvSwxfSdZt8uji/jztgxyhBckDs=; b=f5GRXUGwHZsQcc+TGeyld1JdypZzTm2A637/FUQDC4PqFlIkFZl0+GfbsAOSTrTBH9 7FYmkHc4T1yXlLq1PrrVM4x022fMz0Hqt3ZwaaJKGKyQ7rpk+MYinsF0APh74u7/L7dS x5BFsWJLulnFgLjZbqZhqfhy2wr9FeZkFTXjE= Received: by 10.223.88.193 with SMTP id b1mr7402283fam.40.1314633286917; Mon, 29 Aug 2011 08:54:46 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id c7sm3858005fac.12.2011.08.29.08.54.46 (version=SSLv3 cipher=OTHER); Mon, 29 Aug 2011 08:54:46 -0700 (PDT) Message-ID: <4E5BB666.60903@gmail.com> Date: Mon, 29 Aug 2011 18:55:18 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Apps-discuss list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] 'Base' and 'Content-Base' header fields 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, 29 Aug 2011 15:53:23 -0000 Hello all, RFC 1808 proposed the 'Base' header field to be used in HTTP/mail messages. This header field was intended to be used for establishing the base URI when resolving relative URIs; what RFC 1808 says is: > Messages are considered to be composite documents. The base URL of a > message can be specified within the message headers (or equivalent > tagged metainformation) of the message. For protocols that make use > of message headers like those described in RFC 822 [5], we recommend > that the format of this header be: > > base-header = "Base" ":" "" > > where "Base" is case-insensitive and any whitespace (including that > used for line folding) inside the angle brackets is ignored. However, this disappeared from RFC 2396. RFC 2110, though, introduced 'Content-Base' header field for the similar purpose, but RFC 2557, which obsoleted 2110, said that this header field was removed from the new version of MHTML. Now 'Content-Base' for MIME is listed with reference to RFC 4021, which referred to then-obsoleted RFC 2110. RFC 4229 registered 'Content-Base' for HTTP, referring to RFC 2068. Nevertheless RFC 2616 didn't specify 'Content-Base' header field as well, so the factual spec is obsolete RFC 2068. So, you see, 'Content-Base' is in the rather uncertain state, and no clear definition is available. (This reminds me of 'Link' header field, which was in rather the same state.) So, is there enough support to undertake the effort to define 'Content-Base' field properly? Mykyta Yevstifeyev From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Mon Aug 29 11:23: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 010FF21F8CBC for ; Mon, 29 Aug 2011 11:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.91 X-Spam-Level: X-Spam-Status: No, score=-102.91 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhSZm-XO87Cx for ; Mon, 29 Aug 2011 11:23:35 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0495521F8C77 for ; Mon, 29 Aug 2011 11:23:34 -0700 (PDT) Received: by pzk33 with SMTP id 33so19795775pzk.18 for ; Mon, 29 Aug 2011 11:25:00 -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=bc+mFi17IUtwStEixxhZipGbO6lzghtCou5luAtaQGY=; b=rjbIbUPRRgmbtRtFfD7Ufw3mj5zJrO0lc7f0eeMEyh6s7Pvfwbv+67PBApBCSnkgg+ 1gypZcyfx4yshNY83CjV9uo+cYlW7GGNExAgycnWBAeS/+7UwQcynge1UM7ztNgJVbRY dG0I++ZFAQ8Sxdu5N61e0RmDhmUr6iPyKdopw= Received: by 10.142.158.3 with SMTP id g3mr2629469wfe.127.1314642300141; Mon, 29 Aug 2011 11:25:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.98.5 with HTTP; Mon, 29 Aug 2011 11:24:20 -0700 (PDT) In-Reply-To: <4E5BB666.60903@gmail.com> References: <4E5BB666.60903@gmail.com> From: Frank Ellermann Date: Mon, 29 Aug 2011 20:24:20 +0200 Message-ID: To: Mykyta Yevstifeyev Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps-discuss list Subject: Re: [apps-discuss] 'Base' and 'Content-Base' header fields 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, 29 Aug 2011 18:23:36 -0000 On 29 August 2011 17:55, Mykyta Yevstifeyev wrote: > So, is there enough support to undertake the effort to define > 'Content-Base' field properly? >From my POV all "base URI" concepts do not work as they should, because fragments are interpreted w.r.t. this base, instead of "the document at hand". If fragments in "offline" documents, notably file: URIs, don't work as expected with a http: base in an "offline" state, then a base for online resources (CSS, icons, banners, etc.) doesn't help. I'm not sure that this is also relevant for Content-Base and MIME. Apparently RFC 2557 says that the Content-Base in RFC 2110 is obsolete, and RFC 4021 forgot to mention that detail when the header field registry was established. Let's just fix the IANA registry, Content-Base is a "MUST NOT generate" (RFC 2557 section 12). For the former "Base" header field I sent a review request to ietf-message-headers@ietf, it just has to be registered as obsoleted by RFC 2110. -Frank From msk@cloudmark.com Mon Aug 29 11:43: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 286E721F8CBD for ; Mon, 29 Aug 2011 11:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.539 X-Spam-Level: X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inrg2g+6zLA8 for ; Mon, 29 Aug 2011 11:43:48 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id A8D9C21F8CC0 for ; Mon, 29 Aug 2011 11:43:48 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 29 Aug 2011 11:45:13 -0700 From: "Murray S. Kucherawy" To: Apps-discuss list Date: Mon, 29 Aug 2011 11:45:12 -0700 Thread-Topic: [apps-discuss] 'Base' and 'Content-Base' header fields Thread-Index: AcxmY/xlIngB77p2SteDx5vGUcRnpQAF4WdA Message-ID: References: <4E5BB666.60903@gmail.com> In-Reply-To: <4E5BB666.60903@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] 'Base' and 'Content-Base' header fields 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, 29 Aug 2011 18:43:49 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Mykyta Yevstifeyev > Sent: Monday, August 29, 2011 8:55 AM > To: Apps-discuss list > Subject: [apps-discuss] 'Base' and 'Content-Base' header fields >=20 > So, you see, 'Content-Base' is in the rather uncertain state, and no > clear definition is available. (This reminds me of 'Link' header field, > which was in rather the same state.) So, is there enough support to > undertake the effort to define 'Content-Base' field properly? Does anything actually use this, or is it just something that got dropped i= n the specs along the way? Or perhaps more simply: What problem are you trying to solve? If it's not in widespread use, I imagine there's no pressing need to "fix" = it. -MSK From sm@resistor.net Mon Aug 29 12:02: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 6B1E021F8C07 for ; Mon, 29 Aug 2011 12:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q20Kn+HfIfbW for ; Mon, 29 Aug 2011 12:02:39 -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 1EE4221F8BEE for ; Mon, 29 Aug 2011 12:02:39 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p7TJ3t77026553; Mon, 29 Aug 2011 12:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1314644640; bh=SZpXDcclc/NWNO19o3s4cMalqmW69Wu2rsu8xad1fYA=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=hNBhqaJdpB1f151lPwP+QoP+WR8p+MU321HrErYTfAvpWkKWNGQQBrGGe9tzjwZfD J0XfPYpddUmybHqqwuM/u72c4yZbjOnN0/H3NSAblUgyNqEFrpB5NmyPingCASCLzg gDxX+ghz2mY9bgHHV51v+lvpIP/7UwrgEW+zAGM8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1314644640; bh=SZpXDcclc/NWNO19o3s4cMalqmW69Wu2rsu8xad1fYA=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=jXY+GhNiv8hO3h8aeUBoqSReoLkfpw60Sy8249mVRov06zssz7X+z8O7rqOL2rXzw 41YIt1BqQhi1GNEyPW+qC42qKjsySKpsJkML7UEKUjr2chb3d73Hs3xRKTy2beMTjo wyYok6/NMSNArEfWi/XswI3LjwUUYdsX/rpNEy70= Message-Id: <6.2.5.6.2.20110829115439.096409e0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 29 Aug 2011 11:55:50 -0700 To: Frank Ellermann From: SM In-Reply-To: References: <4E5BB666.60903@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Apps-discuss list Subject: Re: [apps-discuss] 'Base' and 'Content-Base' header fields 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, 29 Aug 2011 19:02:40 -0000 Hi Frank, At 11:24 29-08-2011, Frank Ellermann wrote: >Let's just fix the IANA registry, Content-Base is a "MUST NOT >generate" (RFC 2557 section 12). For the former "Base" header >field I sent a review request to ietf-message-headers@ietf, it >just has to be registered as obsoleted by RFC 2110. It's easier to do that than to have yet another RFC. Regards, -sm From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Mon Aug 29 13:04: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 10C6721F8C67 for ; Mon, 29 Aug 2011 13:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.035 X-Spam-Level: X-Spam-Status: No, score=-103.035 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Rfk4oG6YUiL for ; Mon, 29 Aug 2011 13:04:15 -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 8240521F8C54 for ; Mon, 29 Aug 2011 13:04:15 -0700 (PDT) Received: by gwb20 with SMTP id 20so5967417gwb.31 for ; Mon, 29 Aug 2011 13:05:40 -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=MT0v02shpP/cRbBInlbZRHG4mVHPYPaBJq/MZBPcCpA=; b=jbJMXGyc2mjAr/Nmpz3jMWDTUvM/nd23P0ja8pcsIg1U1BT5f6uSFwvBrAW1USlQT2 YVuQQuziRL5RYBSjaPaBsKmpz26tuWjVNfLlG2EAUNrWO+4OAIxedr3pMAfW3jGfO/1F COsBYLuF5VR5IzC+SL5llmNz/rGTlO6dJR+w0= Received: by 10.142.125.18 with SMTP id x18mr2705528wfc.412.1314648340179; Mon, 29 Aug 2011 13:05:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.98.5 with HTTP; Mon, 29 Aug 2011 13:05:00 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20110829115439.096409e0@resistor.net> References: <4E5BB666.60903@gmail.com> <6.2.5.6.2.20110829115439.096409e0@resistor.net> From: Frank Ellermann Date: Mon, 29 Aug 2011 22:05:00 +0200 Message-ID: To: SM Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps-discuss list Subject: Re: [apps-discuss] 'Base' and 'Content-Base' header fields 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, 29 Aug 2011 20:04:16 -0000 On 29 August 2011 20:55, SM wrote: >> Let's just fix the IANA registry [...] > It's easier to do that than to have yet another RFC. Yes, done, there are now three registration templates (Base: mime, Content-Base: mime, Content-Base: http) for review on the ietf-message-headers@ietf list. If that is not as it should be for the HTTP header field please fix/forward/discuss/... it. -Frank From mnot@mnot.net Mon Aug 29 16:20: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 0B2A821F8BB5 for ; Mon, 29 Aug 2011 16:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.448 X-Spam-Level: X-Spam-Status: No, score=-105.448 tagged_above=-999 required=5 tests=[AWL=-2.849, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Dgl7Z6twxKP for ; Mon, 29 Aug 2011 16:19:59 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6699021F8B4F for ; Mon, 29 Aug 2011 16:19:59 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.37.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 595B122E247; Mon, 29 Aug 2011 19:21:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4E5BB666.60903@gmail.com> Date: Tue, 30 Aug 2011 09:21:15 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <9D754C2A-1127-42FA-BDD7-6613CE4DCC8D@mnot.net> References: <4E5BB666.60903@gmail.com> To: Mykyta Yevstifeyev X-Mailer: Apple Mail (2.1244.3) Cc: Apps-discuss list Subject: Re: [apps-discuss] 'Base' and 'Content-Base' header fields 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, 29 Aug 2011 23:20:00 -0000 On 30/08/2011, at 1:55 AM, Mykyta Yevstifeyev wrote: > So, you see, 'Content-Base' is in the rather uncertain state, and no = clear definition is available. (This reminds me of 'Link' header field, = which was in rather the same state.) So, is there enough support to = undertake the effort to define 'Content-Base' field properly? HTTP doesn't really use Content-Base; we have Content-Location.=20 Clarifying the registry entry seems like the right thing to do... Cheers, -- Mark Nottingham http://www.mnot.net/ From barryleiba@gmail.com Mon Aug 29 17:35: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 95FBC21F8C50 for ; Mon, 29 Aug 2011 17:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.029 X-Spam-Level: X-Spam-Status: No, score=-103.029 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DToLiclRxjas for ; Mon, 29 Aug 2011 17:35:41 -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 6C16421F8C49 for ; Mon, 29 Aug 2011 17:35:40 -0700 (PDT) Received: by gyf3 with SMTP id 3so6161421gyf.31 for ; Mon, 29 Aug 2011 17:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=13jRdJSG+F+C5jip+UcSNgPEAKaBHGWR2f6q/jBNbq0=; b=LV1uHr0NmA1NmEXqf4qgwQ1nmnB9MENcZ8rrwBWTVg0cJxPJ2+oZV0aETrgah9Mnnf F2DAHdafHhJP05yPMv0JzLtYUHEUB1LyBIox2ddUx7vJedCyKX3Ur7mGSEQRHisOFNv7 bjs4gh/HxFOacJlSl1c46osLS5nrkPYwoPr4o= MIME-Version: 1.0 Received: by 10.236.89.70 with SMTP id b46mr1726465yhf.38.1314664626184; Mon, 29 Aug 2011 17:37:06 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.63.175 with HTTP; Mon, 29 Aug 2011 17:37:05 -0700 (PDT) Date: Mon, 29 Aug 2011 20:37:05 -0400 X-Google-Sender-Auth: _ZJfrE9mNKkTGXbJU8JRAI599p8 Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] New appsawg documents 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, 30 Aug 2011 00:35:41 -0000 As noted in the minutes from IETF 81: http://www.ietf.org/proceedings/81/minutes/appsawg.txt ... the Applications Area Working Group is picking up seven new documents. After some post-IETF travel and catch-up, it's time for your friendly neighbourhood chairs to start things moving on those documents, and we've divided up the shepherding work. Let's start with the list of documents, and a call for any objections: Please respond to this message by this Friday, 2 September, if you object to having the working group take on any of these documents: http://tools.ietf.org/html/draft-holsten-about-uri-scheme http://tools.ietf.org/html/draft-zyp-json-schema http://tools.ietf.org/html/draft-kucherawy-mta-malformed http://tools.ietf.org/id/draft-kucherawy-rfc3462bis http://tools.ietf.org/html/draft-melnikov-mime-default-charset http://tools.ietf.org/html/draft-saintandre-xdash http://tools.ietf.org/html/draft-freed-media-type-regs Meanwhile, the first three documents we'd like to focus on are these (with the document's shepherd in parentheses): http://tools.ietf.org/html/draft-holsten-about-uri-scheme (Jiankang) http://tools.ietf.org/id/draft-kucherawy-rfc3462bis (Barry) http://tools.ietf.org/html/draft-saintandre-xdash (Alexey) I am currently pre-approving the following document names, so the document editors can submit new versions under the working group's auspices. The document shepherds will soon be contacting the current authors to discuss document editing within the working group -- note that working group document editors will not necessarily be the same as the original document authors, though we'll usually try to keep continuity. draft-holsten-about-uri-scheme will become draft-ietf-appsawg-about-uri-scheme draft-kucherawy-rfc3462bis will become draft-ietf-appsawg-rfc3462bis draft-saintandre-xdash will become draft-ietf-appsawg-xdash Once the shepherds have gotten in touch with the document editors, the editors should incorporate whatever comments are outstanding, and submit new working-group versions. We'll then start discussing them in earnest, and set up milestones for when we expect to complete them. Barry, appsawg chair From mnot@mnot.net Mon Aug 29 18:02: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 8AC8321F8BAB for ; Mon, 29 Aug 2011 18:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.321 X-Spam-Level: X-Spam-Status: No, score=-105.321 tagged_above=-999 required=5 tests=[AWL=-2.722, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FWIV8u5ZRTw for ; Mon, 29 Aug 2011 18:02:27 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFCA21F8B92 for ; Mon, 29 Aug 2011 18:02:27 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.37.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F163F22E247; Mon, 29 Aug 2011 21:03:46 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4E5BB162.6010101@gmail.com> Date: Tue, 30 Aug 2011 11:03:42 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110531062229.28776.82429.idtracker@ietfa.amsl.com> <0CE9268E-5802-4B0A-B643-F580E7F048B5@mnot.net> <4E5BB162.6010101@gmail.com> To: Mykyta Yevstifeyev X-Mailer: Apple Mail (2.1244.3) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-nottingham-http-browser-hints-02.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, 30 Aug 2011 01:02:28 -0000 I didn't go in this direction because it *seems* to conflict with the = STS effort in websec. Maybe someone from over there could comment? Cheers, s On 30/08/2011, at 1:33 AM, Mykyta Yevstifeyev wrote: > Proposal for a new hint: >=20 >> 5.8. https >>=20 >> o Browser Hint Name: https >> o Description: When true, this hint indicates the user agent may >> use HTTPS and, correspondigly, 'https' URI scheme [RFC2818] = with >> the specific areas (resources) of the site. >> o Value Type: prefixlist >> o Contact: /somebody/ >=20 > Mykyta Yevstifeyev >=20 > 31.05.2011 9:28, Mark Nottingham wrote: >> FYI. Diffs at: >> = http://tools.ietf.org/rfcdiff?url2=3Ddraft-nottingham-http-browser-hints-0= 2 >>=20 >> Changelog: >> - removed Ref header and rearranged referer-based hints >> - added 'prefixlist' value type >> - changed omit-cookies from list of cookie names to prefixlist >> - added caching advice for 404s >>=20 >> Feedback appreciated, as always. >>=20 >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Date: 31 May 2011 4:22:29 PM AEST >>> To: i-d-announce@ietf.org >>> Subject: I-D Action: draft-nottingham-http-browser-hints-02.txt >>> Reply-To: internet-drafts@ietf.org >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>=20 >>> Title : HTTP Browser Hints >>> Author(s) : Mark Nottingham >>> Filename : draft-nottingham-http-browser-hints-02.txt >>> Pages : 9 >>> Date : 2011-05-30 >>>=20 >>> Over time, Web browsers have adapted how they use HTTP based upon >>> common server configurations and behaviours. While this is = necessary >>> in the common case, it can be detrimental for performance and >>> interoperability. >>>=20 >>> This document establishes a mechanism whereby origin servers can = make >>> available hints for browsers about their preferences and >>> capabilities, without imposing overhead on their interactions or >>> requiring support for them. >>>=20 >>> This is intended to allow browsers to safely optimise connections = to >>> servers. >>>=20 >>>=20 >>> A URL for this Internet-Draft is: >>> = http://www.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02= .txt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> This Internet-Draft can be retrieved at: >>> = ftp://ftp.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02.= 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 >> -- >> 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 >>=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From internet-drafts@ietf.org Mon Aug 29 21:18: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 9913C21F8B18; Mon, 29 Aug 2011 21:18: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWUvhtuacSsB; Mon, 29 Aug 2011 21:18:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3285921F8B0E; Mon, 29 Aug 2011 21:18:53 -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.60 Message-ID: <20110830041853.24036.37.idtracker@ietfa.amsl.com> Date: Mon, 29 Aug 2011 21:18:53 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-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, 30 Aug 2011 04:18: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 : The Multipart/Report Media Type for the Reporting of Mai= l System Administrative Messages Author(s) : Murray S. Kucherawy Filename : draft-ietf-appsawg-rfc3462bis-00.txt Pages : 13 Date : 2011-08-29 The multipart/report Multipurpose Internet Mail Extensions (MIME) media type is a general "family" or "container" type= for electronic mail reports of any kind. Although this memo defines only the use of the multipart/report media type with respect to delivery status reports, mail processing programs will benefit if a single media type is used for all kinds of reports. This memo obsoletes RFC3462. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3462bis-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-rfc3462bis-00.txt From evnikita2@gmail.com Tue Aug 30 01:48: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 91A8021F8B6E for ; Tue, 30 Aug 2011 01:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.464 X-Spam-Level: X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQ6RE6S7S7eZ for ; Tue, 30 Aug 2011 01:48:12 -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 C752921F8A1A for ; Tue, 30 Aug 2011 01:48:11 -0700 (PDT) Received: by bkar4 with SMTP id r4so5840171bka.31 for ; Tue, 30 Aug 2011 01:49: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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=qaWPjgQ3QuIJnZTZq+ugG5RJGp4uKYOmK5KFT19xxi4=; b=TP1LWT5B2X9uhw7yZ97WpDaA05/8e8va1gtSjfgiTlw2NrADTV9IWT6VuizK9Rfzn4 LBXB1v+a3ppTM6J3IOIoxJPCBBqhEzllv6OwIUSJQh2fwX5EAiHf/SqpH4c+TO1+8d6N LYH7ip5AJi34bbAovkt1TcC2gQScZXdRjVhV0= Received: by 10.204.153.208 with SMTP id l16mr2734995bkw.6.1314694177883; Tue, 30 Aug 2011 01:49:37 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id q15sm1439333bke.37.2011.08.30.01.49.36 (version=SSLv3 cipher=OTHER); Tue, 30 Aug 2011 01:49:36 -0700 (PDT) Message-ID: <4E5CA43F.1030405@gmail.com> Date: Tue, 30 Aug 2011 11:50:07 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] New appsawg documents 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, 30 Aug 2011 08:48:12 -0000 30.08.2011 3:37, Barry Leiba wrote: > http://tools.ietf.org/html/draft-holsten-about-uri-scheme (Jiankang) Yes, I may seem stubborn and obstinate (and I probably am :-)), but *please* do consider my comments from [1] if this document is approved as AppsAWG doc. We, as a WG, should produce RFCs of high quality, and, with all due respect to the document's authors, the current I-D doesn't seem to be so. Thanks, Mykyta Yevstifeyev [1] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03120.html From barryleiba.mailing.lists@gmail.com Tue Aug 30 07:14: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 E57FB21F8C07 for ; Tue, 30 Aug 2011 07:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.029 X-Spam-Level: X-Spam-Status: No, score=-103.029 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0vpWHyVopQ5 for ; Tue, 30 Aug 2011 07:14:03 -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 5A73621F8B7E for ; Tue, 30 Aug 2011 07:14:03 -0700 (PDT) Received: by gyf3 with SMTP id 3so6661394gyf.31 for ; Tue, 30 Aug 2011 07:15:30 -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=WKJiyJuO/H/Gw7YQ6Ypjw2ULu/B2ryQdpkkknUJmCic=; b=sBWg4xHQmtlrYIIynPmv7SlQDqH/oGcltnkStbQJ4laNQFccMvAJRFTzUKAFMfwCKv FasrCSC444unrhkVbrT6ffe8iPlqxEOw6r6yBg2ra7b3IgtbuRURxhQKyU3W4MvjUhfI iQRqmmgEQTQglV0+uAWFe3e0fCwPWCb8IKL3A= MIME-Version: 1.0 Received: by 10.146.192.28 with SMTP id p28mr5172499yaf.35.1314713728940; Tue, 30 Aug 2011 07:15:28 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.83.8 with HTTP; Tue, 30 Aug 2011 07:15:28 -0700 (PDT) In-Reply-To: <4E5CA43F.1030405@gmail.com> References: <4E5CA43F.1030405@gmail.com> Date: Tue, 30 Aug 2011 10:15:28 -0400 X-Google-Sender-Auth: ThOCtJbNIF8US4lIHZFQRKAVRZE Message-ID: From: Barry Leiba To: Mykyta Yevstifeyev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] New appsawg documents 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, 30 Aug 2011 14:14:04 -0000 >> =A0http://tools.ietf.org/html/draft-holsten-about-uri-scheme (Jiankang) > > Yes, I may seem stubborn and obstinate (and I probably am :-)), but *plea= se* > do consider my comments from [1] if this document is approved as AppsAWG > doc. =A0We, as a WG, should produce RFCs of high quality, and, with all d= ue > respect to the document's authors, the current I-D doesn't seem to be so. ... > [1] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03120.ht= ml Be assured that your input is already being considered. Barry From julian.reschke@gmx.de Tue Aug 30 08:49: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 CFC7321F8CED for ; Tue, 30 Aug 2011 08:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.515 X-Spam-Level: X-Spam-Status: No, score=-104.515 tagged_above=-999 required=5 tests=[AWL=-1.916, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eDvMZZSnOxf for ; Tue, 30 Aug 2011 08:49:39 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id DCA2F21F8CE1 for ; Tue, 30 Aug 2011 08:49:38 -0700 (PDT) Received: (qmail invoked by alias); 30 Aug 2011 15:51:05 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp043) with SMTP; 30 Aug 2011 17:51:05 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+ie95unCaiPwbDw7mX1+jrOBsIbtXb0U0EoP6Sbz NNGCBjy35UkmHA Message-ID: <4E5D06EA.9040205@gmx.de> Date: Tue, 30 Aug 2011 17:51:06 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: IETF Apps Discuss References: <20110829144145.31952.69055.idtracker@ietfa.amsl.com> In-Reply-To: <20110829144145.31952.69055.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20110829144145.31952.69055.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [apps-discuss] Fwd: I-D Action: draft-ohye-canonical-link-relation-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: Tue, 30 Aug 2011 15:49:39 -0000 (FYI) -------- Original Message -------- Subject: I-D Action: draft-ohye-canonical-link-relation-01.txt Date: Mon, 29 Aug 2011 07:41:45 -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 : The Canonical Link Relation Author(s) : Maile Ohye Joachim Kupke Filename : draft-ohye-canonical-link-relation-01.txt Pages : 6 Date : 2011-07-30 The canonical link relation, developed from [RFC5988] which indicates relationships between Internet links, specifies the preferred URI from a set of identical or vastly similar content accessible on multiple URIs. Editorial Note (To be removed by RFC Editor) Distribution of this document is unlimited. Comments should be sent to the IETF Apps-Discuss mailing list (see <https://www.ietf.org/mailman/listinfo/apps-discuss>). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ohye-canonical-link-relation-01.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-ohye-canonical-link-relation-01.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 stpeter@stpeter.im Tue Aug 30 09:19: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 73F5321F8D8E for ; Tue, 30 Aug 2011 09:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.612 X-Spam-Level: X-Spam-Status: No, score=-102.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxoTaIxX8wY4 for ; Tue, 30 Aug 2011 09:19:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B6AA621F8D8D for ; Tue, 30 Aug 2011 09:19:20 -0700 (PDT) Received: from dhcp-64-101-72-178.cisco.com (unknown [64.101.72.178]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 065944174A; Tue, 30 Aug 2011 10:23:21 -0600 (MDT) Message-ID: <4E5D0DDE.3050203@stpeter.im> Date: Tue, 30 Aug 2011 10:20:46 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Ned Freed References: <20110726125042.1180.12955.idtracker@ietfa.amsl.com> <4E2EBA34.5090604@stpeter.im> <4E44A777.3000902@gmail.com> <01O4SNTZFJZ200VHKR@mauve.mrochek.com> <4E4BD33E.6050002@gmail.com> <01O4Y7R78O5000VHKR@mauve.mrochek.com> In-Reply-To: <01O4Y7R78O5000VHKR@mauve.mrochek.com> X-Enigmail-Version: 1.3.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] 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, 30 Aug 2011 16:19:21 -0000 On 8/17/11 8:53 AM, Ned Freed wrote: >> 13.08.2011 18:52, Ned Freed wrote: >> >> I think your document should be clear whether it affects the "vnd." >> >> construction, used, eg., as I remember, in MIME media types and >> >> elsewhere. >> > >> > The answer to that is "no", by definition. The unregistered (x-/x.) >> tree >> > is 100% disjoint from the vendor, personal, and standard trees. > >> So this could and should be mentioned in the document. > > Not sure I see why. Listing all the extant things the document doesn't > apply to > is going to be a long list. Agreed. However, I think a paragraph like this would be appropriate in the IANA Considerations section: This document does not modify registration procedures currently in force for various application protocols. However, such procedures might be updated in the future to incorporate the best practices defined in this document. > That said, I actually object to what this document currently says about > media > types: It is flatly incorrect to characterize the vnd. tree as being for > "local or implementation-specific extensions". On the contrary, vnd. > exists so > that vendors can define formats with some degree of interoperability and > some > understanding of the security considerations, but without having to fully > standardize them. As such, they aren't local, they aren't > implementation-specific, and they aren't extensions. Ned, you are right. I've removed that clause from point 3 in Section 4: SHOULD identify a convention to allow local or implementation- specific extensions, and reserve delimeters as necessary. >> >> With respect to existing IANA policies regarding assignment and >> >> registration values beginning in "X-". I suppose IANA should continue >> >> to follow those policies which were set by the corresponding >> documents, >> >> in order not to create the influx of registrations of "X-" values. >> > >> > Actually, there has been some sentiment that we should actually allow >> > and encourage such registrations. > >> As previously "x-" parameters weren't allowed to be registered, >> interoperability problems may arise when such parameter has several >> real-life usages and only one is registered. I suspected the document >> not to have a retroactivity. > > First of all, nobody has suggested or even implied that such registrations > would be unconditionally allowed. It goes without saying that only x- types > that are unambiguously associated with a single format would be eligible > for > registration. > > Second, I rather suspect that a significant fraction of the x- media > types in > use have essentially only one real-life usage. And it is usually pretty > easy to > tell when this is the case. > > But it remains to be seen whether or not we decide to do something about > this > or not. The present draft doesn't contain any changes in this area and > there is > nothing resembling a consensus to make such a change at this time. Agreed. >> >> However, when the "X-" convention is deprecated, new protocols will >> not >> >> need to set such policy; so no changes for IANA are necessary now. >> > >> > Given that the media types registration procedures document is >> currently >> > being revised, any changes to x-/x. in that context should be dealt >> > with in that update. Putting it in a separate general document would >> > be both confusing and inappropriate. > >> Your I-D which I found and which positions itself as 4288bis >> (http://tools.ietf.org/html/draft-freed-media-type-regs-00) does contain >> provisions regarding non-registered x. media types and prohibition of >> their registration. > > Yes, that's the current state of affairs. > >> The I-D was uploaded on 13 June, and even if such >> restriction is going to disappear, the new version of I-D should point >> to draft-saintandre-xdash to reflect x. being are deprecated; it also >> has to deal with existing-and-unregistered x. media types. > > If and when we decide to change the semantics associated with x- in some > way, > it may become appropriate to reference this I-D. Or not - it's difficult > to predict whether or not it makes sense to include such a reference until > the specifics of the change are known. > >> I believe that deprecation should only concern new protocols and have no >> retroaticity; so those registries which don't currently allow x. or x- >> registrations, should continue doing so; those which are only being >> created, should take the discussed doc into account. > > Exactly - this specifiction is focused on *new* parameters. How > we handle extant registries is out of scope and necessarily will be > determined > on a case-by-case basis. +1. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Aug 30 09:26: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 19D7221F8A64 for ; Tue, 30 Aug 2011 09:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.612 X-Spam-Level: X-Spam-Status: No, score=-102.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpzfBzLYQIe1 for ; Tue, 30 Aug 2011 09:26:43 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E841B21F8561 for ; Tue, 30 Aug 2011 09:26:37 -0700 (PDT) Received: from dhcp-64-101-72-178.cisco.com (unknown [64.101.72.178]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D67DA4174A; Tue, 30 Aug 2011 10:30:39 -0600 (MDT) Message-ID: <4E5D0F94.3000304@stpeter.im> Date: Tue, 30 Aug 2011 10:28:04 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Frank Ellermann References: <20110726125042.1180.12955.idtracker@ietfa.amsl.com> <4E2EBA34.5090604@stpeter.im> <4E44A777.3000902@gmail.com> <01O4SNTZFJZ200VHKR@mauve.mrochek.com> <4E4BD33E.6050002@gmail.com> <01O4Y7R78O5000VHKR@mauve.mrochek.com> In-Reply-To: X-Enigmail-Version: 1.3.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'Bernard Aboba' , Stuart Cheshire , Brian E Carpenter , "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, 30 Aug 2011 16:26:44 -0000 On 8/17/11 10:26 AM, Frank Ellermann wrote: > Apropos xdash-03, checking various things I missed in 2009 and 2010 > I stumbled over draft-yevstifeyev-ion-report, from there I found > the new home page of the [PROCDOCS] -- BTW, it is very good that > [TAObis] and [PROCDOCS] are still updated, no matter what happens > with FYIs or IONs as a series -- and somehow eventually arrived at > draft-iab-extension-recs section 3.1, or rather the predecessor of > this I-D (= draft-carpenter-extension-recs). Do you mean Section 2.3? That's the only section mentioning "X-" at http://tools.ietf.org/id/draft-carpenter-extension-recs-04.txt (as far as I can see). > IOW, there is some "prior art" for X-issues by Brian Carpenter not > yet mentioned in the xdash draft, and if the IAB still works on the > extension-recs I hope that their conclusions match saintandre-xdash > when both are finished. Yes, it would be good to keep these two documents in sync. I'll reach out to the authors of draft-iab-extension-recs in this matter. Peter -- Peter Saint-Andre https://stpeter.im/ From evnikita2@gmail.com Tue Aug 30 09: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 B477721F8DC7 for ; Tue, 30 Aug 2011 09:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBjxBFJA2I4J for ; Tue, 30 Aug 2011 09:49:58 -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 E14D721F8DCB for ; Tue, 30 Aug 2011 09:49:57 -0700 (PDT) Received: by fxe6 with SMTP id 6so6008227fxe.31 for ; Tue, 30 Aug 2011 09:51:25 -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=qrzt9YD+mkX561RVorO1e8KN9Hd664Wl37G1mmYyUds=; b=GbX+S76UUeMIF/D6DNCNYi/s3QGa3YoGgAxZNzC9jMNaRhBN6Sxmly+rZug3J0tKEj rIRfPLliGBgrHQ44grQq9Bj39WGQk2EuCobYCMqz3Y5QyxjXVu5PWVN+E/vvsIXxjMB/ UUWrPJ1nSBeW2pY0a43xD6Z1r748G27XI2bWo= Received: by 10.223.4.133 with SMTP id 5mr9414491far.81.1314723085083; Tue, 30 Aug 2011 09:51:25 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id c5sm4718121fai.20.2011.08.30.09.51.23 (version=SSLv3 cipher=OTHER); Tue, 30 Aug 2011 09:51:24 -0700 (PDT) Message-ID: <4E5D152B.5000802@gmail.com> Date: Tue, 30 Aug 2011 19:51:55 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <20110726125042.1180.12955.idtracker@ietfa.amsl.com> <4E2EBA34.5090604@stpeter.im> <4E44A777.3000902@gmail.com> <01O4SNTZFJZ200VHKR@mauve.mrochek.com> <4E4BD33E.6050002@gmail.com> <01O4Y7R78O5000VHKR@mauve.mrochek.com> <4E5D0DDE.3050203@stpeter.im> In-Reply-To: <4E5D0DDE.3050203@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Ned Freed , 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, 30 Aug 2011 16:49:58 -0000 30.08.2011 19:20, Peter Saint-Andre wrote: > On 8/17/11 8:53 AM, Ned Freed wrote: >>> 13.08.2011 18:52, Ned Freed wrote: >>>>> I think your document should be clear whether it affects the "vnd." >>>>> construction, used, eg., as I remember, in MIME media types and >>>>> elsewhere. >>>> The answer to that is "no", by definition. The unregistered (x-/x.) >>> tree >>>> is 100% disjoint from the vendor, personal, and standard trees. >>> So this could and should be mentioned in the document. >> Not sure I see why. Listing all the extant things the document doesn't >> apply to >> is going to be a long list. > Agreed. However, I think a paragraph like this would be appropriate in > the IANA Considerations section: > > This document does not modify registration procedures currently in > force for various application protocols. However, such procedures > might be updated in the future to incorporate the best practices > defined in this document. I agree with such text. > >> That said, I actually object to what this document currently says about >> media >> types: It is flatly incorrect to characterize the vnd. tree as being for >> "local or implementation-specific extensions". On the contrary, vnd. >> exists so >> that vendors can define formats with some degree of interoperability and >> some >> understanding of the security considerations, but without having to fully >> standardize them. As such, they aren't local, they aren't >> implementation-specific, and they aren't extensions. > Ned, you are right. I've removed that clause from point 3 in Section 4: > > SHOULD identify a convention to allow local or implementation- > specific extensions, and reserve delimeters as necessary. I'm fine with this change as well. > [ . . . ] > Peter From ietfc@btconnect.com Tue Aug 30 11:06: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 B8C4C21F8DF4 for ; Tue, 30 Aug 2011 11:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dL9JeuoQaxO6 for ; Tue, 30 Aug 2011 11:06:29 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr09.btconnect.com [213.123.26.187]) by ietfa.amsl.com (Postfix) with ESMTP id 66D8F21F8DBE for ; Tue, 30 Aug 2011 11:06:28 -0700 (PDT) Received: from host109-153-79-81.range109-153.btcentralplus.com (HELO pc6) ([109.153.79.81]) by c2beaomr09.btconnect.com with SMTP id EEO29932; Tue, 30 Aug 2011 19:07:54 +0100 (BST) Message-ID: <004001cc6736$d4baab40$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Barry Leiba" , "Apps Discuss" References: Date: Tue, 30 Aug 2011 19:04:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4E5D26FA.006A, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.8.30.164814:17:7.586, ip=109.153.79.81, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __CP_URI_IN_BODY, __INT_PROD_COMP, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4E5D26FA.0152,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: Re: [apps-discuss] New appsawg documents 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, 30 Aug 2011 18:06:30 -0000 ----- Original Message ----- From: "Barry Leiba" To: "Apps Discuss" Sent: Tuesday, August 30, 2011 2:37 AM > As noted in the minutes from IETF 81: > http://www.ietf.org/proceedings/81/minutes/appsawg.txt > ... the Applications Area Working Group is picking up seven new > documents. After some post-IETF travel and catch-up, it's time for > your friendly neighbourhood chairs to start things moving on those > documents, and we've divided up the shepherding work. > > Let's start with the list of documents, and a call for any objections: > Please respond to this message by this Friday, 2 September, if you > object to having the working group take on any of these documents: Why? At least two of these seem to be progressing nicely without any adoption by appsawg, so adopting them seems to be a way of making work. Do the authors want them adopted (I have seen no requests)? If not, who does? Tom Petch > http://tools.ietf.org/html/draft-holsten-about-uri-scheme > http://tools.ietf.org/html/draft-zyp-json-schema > http://tools.ietf.org/html/draft-kucherawy-mta-malformed > http://tools.ietf.org/id/draft-kucherawy-rfc3462bis > http://tools.ietf.org/html/draft-melnikov-mime-default-charset > http://tools.ietf.org/html/draft-saintandre-xdash > http://tools.ietf.org/html/draft-freed-media-type-regs > > Meanwhile, the first three documents we'd like to focus on are these > (with the document's shepherd in parentheses): > http://tools.ietf.org/html/draft-holsten-about-uri-scheme (Jiankang) > http://tools.ietf.org/id/draft-kucherawy-rfc3462bis (Barry) > http://tools.ietf.org/html/draft-saintandre-xdash (Alexey) > > I am currently pre-approving the following document names, so the > document editors can submit new versions under the working group's > auspices. The document shepherds will soon be contacting the current > authors to discuss document editing within the working group -- note > that working group document editors will not necessarily be the same > as the original document authors, though we'll usually try to keep > continuity. > > draft-holsten-about-uri-scheme > will become > draft-ietf-appsawg-about-uri-scheme > > draft-kucherawy-rfc3462bis > will become > draft-ietf-appsawg-rfc3462bis > > draft-saintandre-xdash > will become > draft-ietf-appsawg-xdash > > Once the shepherds have gotten in touch with the document editors, the > editors should incorporate whatever comments are outstanding, and > submit new working-group versions. We'll then start discussing them > in earnest, and set up milestones for when we expect to complete them. > > Barry, appsawg chair > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From msk@cloudmark.com Tue Aug 30 11:09: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 376D021F8E1B for ; Tue, 30 Aug 2011 11:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.738 X-Spam-Level: X-Spam-Status: No, score=-102.738 tagged_above=-999 required=5 tests=[AWL=-0.739, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vl5-yXiKW2hz for ; Tue, 30 Aug 2011 11:09:08 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 1B16A21F8DFA for ; Tue, 30 Aug 2011 11:09:08 -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, 30 Aug 2011 11:10:35 -0700 From: "Murray S. Kucherawy" To: Apps Discuss Date: Tue, 30 Aug 2011 11:10:34 -0700 Thread-Topic: [apps-discuss] New appsawg documents Thread-Index: AcxnP8SDTDsWXw4bSZyWO0fLwXt5/wAAA1Nw Message-ID: References: <004001cc6736$d4baab40$4001a8c0@gateway.2wire.net> In-Reply-To: <004001cc6736$d4baab40$4001a8c0@gateway.2wire.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 Subject: Re: [apps-discuss] New appsawg documents 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, 30 Aug 2011 18:09:14 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of t.petch > Sent: Tuesday, August 30, 2011 10:04 AM > To: Barry Leiba; Apps Discuss > Subject: Re: [apps-discuss] New appsawg documents >=20 > Why? >=20 > At least two of these seem to be progressing nicely without any > adoption by appsawg, so adopting them seems to be a way of making > work. >=20 > Do the authors want them adopted (I have seen no requests)? As one of said authors, I do. There are several reasons, not the least of = which are the facts that our ADs are trying to keep AD-sponsored drafts to = a minimum, incorporation into the WG is painless and reduces LC durations, = and the documents (at least my two) are getting good support there. From barryleiba@gmail.com Tue Aug 30 11:11: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 81A2621F8CAE for ; Tue, 30 Aug 2011 11:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.028 X-Spam-Level: X-Spam-Status: No, score=-103.028 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLAZC+S5T0iv for ; Tue, 30 Aug 2011 11:11:35 -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 B26C621F8C8D for ; Tue, 30 Aug 2011 11:11:35 -0700 (PDT) Received: by ywe9 with SMTP id 9so6795375ywe.31 for ; Tue, 30 Aug 2011 11:13:03 -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=+CCi7PR17zDV6rafiqes9XvvWIucRSqZC9fPXdIarj8=; b=IrQyeZT4lHS/rNkHib32xaXBUtrFg8Hzkx8ZiEPIFd8zpRHIoaEdNIHkwdJhvv5CTx Q2mA6V/8PUs3OGLVz/p7XiICGeixhcdF39424ZlAMT6gO2OQfurawRD7ElU4FXpQcWCy BVMXrZH6cZlXuGTr/4SOGjG7vOB2rTTd+0I+M= MIME-Version: 1.0 Received: by 10.236.72.233 with SMTP id t69mr35268927yhd.55.1314727983392; Tue, 30 Aug 2011 11:13:03 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.208.35 with HTTP; Tue, 30 Aug 2011 11:13:03 -0700 (PDT) In-Reply-To: <004001cc6736$d4baab40$4001a8c0@gateway.2wire.net> References: <004001cc6736$d4baab40$4001a8c0@gateway.2wire.net> Date: Tue, 30 Aug 2011 14:13:03 -0400 X-Google-Sender-Auth: koJnv7cZLiXc1FGvBsG1VDd7Lc4 Message-ID: From: Barry Leiba To: "t.petch" Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps Discuss Subject: Re: [apps-discuss] New appsawg documents 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, 30 Aug 2011 18:11:40 -0000 > At least two of these seem to be progressing nicely without any > adoption by appsawg, so adopting them seems to be a way of making > work. > > Do the authors want them adopted (I have seen no requests)? > > If not, who does? The Area Directors, who would otherwise have to decide whether to sponsor them. Remember that Standards Track documents have to go through the IESG, and someone has to manage the process. In part, that's why appsawg exists. Barry From stpeter@stpeter.im Tue Aug 30 11:14: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 4EFC721F8E35 for ; Tue, 30 Aug 2011 11:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.612 X-Spam-Level: X-Spam-Status: No, score=-102.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrBm+Ch7ofYg for ; Tue, 30 Aug 2011 11:14:17 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8232A21F8E33 for ; Tue, 30 Aug 2011 11:14:17 -0700 (PDT) Received: from dhcp-64-101-72-178.cisco.com (unknown [64.101.72.178]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1921B4174A; Tue, 30 Aug 2011 12:18:20 -0600 (MDT) Message-ID: <4E5D28D0.1030905@stpeter.im> Date: Tue, 30 Aug 2011 12:15:44 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Barry Leiba References: <004001cc6736$d4baab40$4001a8c0@gateway.2wire.net> In-Reply-To: X-Enigmail-Version: 1.3.1 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] New appsawg documents 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, 30 Aug 2011 18:14:18 -0000 On 8/30/11 12:13 PM, Barry Leiba wrote: >> At least two of these seem to be progressing nicely without any >> adoption by appsawg, so adopting them seems to be a way of making >> work. >> >> Do the authors want them adopted (I have seen no requests)? >> >> If not, who does? > > The Area Directors, who would otherwise have to decide whether to > sponsor them. Remember that Standards Track documents have to go > through the IESG, and someone has to manage the process. In part, > that's why appsawg exists. It's also easier for us to declare consensus on WG documents than on individual drafts. Peter -- Peter Saint-Andre https://stpeter.im/ From barryleiba@gmail.com Tue Aug 30 11:16: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 1A00021F8CDC for ; Tue, 30 Aug 2011 11:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.028 X-Spam-Level: X-Spam-Status: No, score=-103.028 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvHkZqOXPIsH for ; Tue, 30 Aug 2011 11:16:14 -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 0CC8321F8B50 for ; Tue, 30 Aug 2011 11:16:13 -0700 (PDT) Received: by yie12 with SMTP id 12so5428473yie.31 for ; Tue, 30 Aug 2011 11:17:42 -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=9RAl7EgVr3V0OvDo9nMVpC9lOt/uX1PUQ437bKgZ40g=; b=uHPiMMqvN1CU8MdA8+hn2z9s9Hvbl9K4DjKviChx9PmQkFtVCbtjXI21q4gD+Lj/QA obiynji/bfVvTOSOE2INmPzH6q00km/GDhhyVF9wTJX48rCcu6swyqbR9XF7G7sPwGN1 xEBWPicc6nyEn3A5UzwT+emCdeAfYqGbRVtoQ= MIME-Version: 1.0 Received: by 10.236.195.70 with SMTP id o46mr35952571yhn.21.1314728261915; Tue, 30 Aug 2011 11:17:41 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.208.35 with HTTP; Tue, 30 Aug 2011 11:17:41 -0700 (PDT) In-Reply-To: References: <004001cc6736$d4baab40$4001a8c0@gateway.2wire.net> Date: Tue, 30 Aug 2011 14:17:41 -0400 X-Google-Sender-Auth: cmsqUK2m-svU7N6bnmMLrZCivrc Message-ID: From: Barry Leiba To: "t.petch" Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps Discuss Subject: Re: [apps-discuss] New appsawg documents 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, 30 Aug 2011 18:16:15 -0000 >> At least two of these seem to be progressing nicely without any >> adoption by appsawg, so adopting them seems to be a way of making >> work. I'll add that it's the goal of AppsAWG to help the process, not to make extra work and hinder things. Without it, the document editors have to make sure the document gets sufficient review, convince an Area Director to sponsor it, and deal with a four-week IETF last call. With it, the working group is here to review the document, and the document shepherd (one of the chairs or someone we assign) will assess the quality of review, we already have approval from the Area Directors to go ahead, and there's a two-week last call when we send it up. If the WG is putting undue extra process in the way, we're doing something wrong, and that's something we should discuss. Let's start by seeing how smoothly a few more documents go (the first two went well, I think). Barry From msk@cloudmark.com Tue Aug 30 11:24: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 D073321F8E1A for ; Tue, 30 Aug 2011 11:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.034 X-Spam-Level: X-Spam-Status: No, score=-103.034 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvYDT4tF81KH for ; Tue, 30 Aug 2011 11:24:25 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id BF1E421F8E01 for ; Tue, 30 Aug 2011 11:24:24 -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, 30 Aug 2011 11:25:52 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Tue, 30 Aug 2011 11:25:52 -0700 Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.txt Thread-Index: AcxmzCLQt7ErtqSfR3G31kkH06ZYSAAdfxcg Message-ID: References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> In-Reply-To: <20110830041853.24036.37.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-rfc3462bis-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, 30 Aug 2011 18:24:25 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: Monday, August 29, 2011 9:19 PM > To: i-d-announce@ietf.org > Cc: apps-discuss@ietf.org > Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis- > 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. >=20 > Title : The Multipart/Report Media Type for the Reporting of M= ail System Administrative Messages > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-appsawg-rfc3462bis-00.txt > Pages : 13 > Date : 2011-08-29 This is a straight conversion from the individual submission, which contain= ed what I think was the consensus from the Quebec City meeting plus some li= st discussion afterwards. Review please (especially Ned and Keith!). Thanks, -MSK From barryleiba.mailing.lists@gmail.com Tue Aug 30 11:51: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 10F1021F8E02 for ; Tue, 30 Aug 2011 11:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.027 X-Spam-Level: X-Spam-Status: No, score=-103.027 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Gi-hcg2jgRA for ; Tue, 30 Aug 2011 11:51:32 -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 D0D0C21F8D6E for ; Tue, 30 Aug 2011 11:51:24 -0700 (PDT) Received: by gxk19 with SMTP id 19so6911636gxk.31 for ; Tue, 30 Aug 2011 11:52:52 -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=CaR7hRWzJaxhSFebKQASPmidzz+DU9TXw3vVNnJD748=; b=Jf0tlJ+aDvruZstwMuj9DZr31dzh08vj2/529lr+Ka7z9o5jGAr8eacfC1v+0hOHKl cbBR2Y1GqcrtKVIVxrxFwrAOmhB/8mtSRUCaRS54iQWFn5bENpk4c5rFVSweR+ouH6fs xdxBKlueqOh9Sh06YpVxGI8tlmWVDcSDoHgm8= MIME-Version: 1.0 Received: by 10.236.115.70 with SMTP id d46mr36061928yhh.83.1314730372670; Tue, 30 Aug 2011 11:52:52 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.83.8 with HTTP; Tue, 30 Aug 2011 11:52:52 -0700 (PDT) In-Reply-To: References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2011 14:52:52 -0400 X-Google-Sender-Auth: 7cf00UVG6h6PNT8DF_aGcmonc3Q Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" 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-rfc3462bis-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, 30 Aug 2011 18:51:33 -0000 >> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : The Multipart/Report Media Type = for the Reporting of Mail System Administrative Messages >> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Murray S. Kucherawy >> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-rfc3462bis-00.t= xt >> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 13 >> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-08-29 For convenience, a link to the document is here: http://tools.ietf.org/html/draft-ietf-appsawg-rfc3462bis > This is a straight conversion from the individual submission, which > contained what I think was the consensus from the Quebec City > meeting plus some list discussion afterwards. =A0Review please > (especially Ned and Keith!). Note to all: I have asked the Secretariat to add the following WG milestone= : Sept 2011: Submit draft-ietf-appsawg-rfc3462bis to the IESG Let's see if we can make that date by getting reviews in now. Barry, appsawg chair From maileohye@gmail.com Tue Aug 30 15:20: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 4048B21F8F0D for ; Tue, 30 Aug 2011 15:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCCANnZA9Oep for ; Tue, 30 Aug 2011 15:20:11 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8814121F8CAF for ; Tue, 30 Aug 2011 15:20:11 -0700 (PDT) Received: by iakc1 with SMTP id c1so91087iak.31 for ; Tue, 30 Aug 2011 15:21:36 -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=8W9j3gTxFaIuzDk9uFaNBAigTLs9GVuaPbJxq0G73+w=; b=jAXyxYoGF8xKRcgYOpXGtYsy1jAU56ymHhpe0PPHnJczFvRQJBas89YLFRctH8ofWK QRyP7HIIGzIO6gBA3tAA8pSrOczedtKEghKTrlQnLncTbzZn0rZyw3LwOoQlc7R5/xT4 EHyqrqqe2wd9alPNLL9/4hYd8QFyGAppWDtDc= MIME-Version: 1.0 Received: by 10.42.146.65 with SMTP id i1mr7703220icv.201.1314742896056; Tue, 30 Aug 2011 15:21:36 -0700 (PDT) Received: by 10.42.178.133 with HTTP; Tue, 30 Aug 2011 15:21:36 -0700 (PDT) In-Reply-To: <4E5D06EA.9040205@gmx.de> References: <20110829144145.31952.69055.idtracker@ietfa.amsl.com> <4E5D06EA.9040205@gmx.de> Date: Tue, 30 Aug 2011 15:21:36 -0700 Message-ID: From: Maile Ohye To: Julian Reschke Content-Type: multipart/alternative; boundary=90e6ba6e8dac4a57db04abc06fba Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: I-D Action: draft-ohye-canonical-link-relation-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: Tue, 30 Aug 2011 22:20:12 -0000 --90e6ba6e8dac4a57db04abc06fba Content-Type: text/plain; charset=ISO-8859-1 Hi everyone, please let us know if you have additional feedback. After many rounds of helpful discussion, I think we're nearing submission. :) I hope to submit a publication request on Wednesday, September 7th, 2011. Thanks! Maile -------- Original Message -------- > Subject: I-D Action: draft-ohye-canonical-link-**relation-01.txt > Date: Mon, 29 Aug 2011 07:41:45 -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 : The Canonical Link Relation > Author(s) : Maile Ohye > Joachim Kupke > Filename : draft-ohye-canonical-link-**relation-01.txt > Pages : 6 > Date : 2011-07-30 > > The canonical link relation, developed from [RFC5988] which indicates > relationships between Internet links, specifies the preferred URI > from a set of identical or vastly similar content accessible on > multiple URIs. > > Editorial Note (To be removed by RFC Editor) > > Distribution of this document is unlimited. Comments should be sent > to the IETF Apps-Discuss mailing list (see > <https://www.ietf.org/**mailman/listinfo/apps-discuss&**gt;> > ). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-**drafts/draft-ohye-canonical-** > link-relation-01.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-ohye-canonical-** > link-relation-01.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 > > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > --90e6ba6e8dac4a57db04abc06fba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi everyone, please let us know if you have additional feedback. After= many rounds of helpful discussion, I think we're nearing submission. := )=A0

I hope to submit a publication request on Wed= nesday, September 7th, 2011.

Thanks!
Maile

-------- Original Message --------
Subject: I-D Action: draft-ohye-canonical-link-relation-01.txt
Date: Mon, 29 Aug 2011 07:41:45 -0700
From: interne= t-drafts@ietf.org
Reply-To: int= ernet-drafts@ietf.org
To: i-d-announce= @ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : The Canonical Link Relation
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Maile Ohye
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Joachim Kupke
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ohye-canonical-link-= relation-01.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 6
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-07-30

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

Editorial Note (To be removed by RFC Editor)

=A0 Distribution of this document is unlimited. =A0Comments should be sent=
=A0 to the IETF Apps-Discuss mailing list (see
=A0 &lt;https://www.ietf.org/mailman/listinfo/apps-di= scuss&gt;).


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts= /draft-ohye-canonical-link-relation-01.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/d= raft-ohye-canonical-link-relation-01.txt
_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.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

_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--90e6ba6e8dac4a57db04abc06fba-- From mca@amundsen.com Tue Aug 30 18:16: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 26CC521F8CBC for ; Tue, 30 Aug 2011 18:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.59 X-Spam-Level: X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u86IfdnntgCL for ; Tue, 30 Aug 2011 18:16:39 -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 E41DA21F8CB8 for ; Tue, 30 Aug 2011 18:16:38 -0700 (PDT) Received: by bkar4 with SMTP id r4so254696bka.31 for ; Tue, 30 Aug 2011 18:18:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.44.8 with SMTP id y8mr9841239fae.129.1314753482200; Tue, 30 Aug 2011 18:18:02 -0700 (PDT) Sender: mca@amundsen.com Received: by 10.223.154.199 with HTTP; Tue, 30 Aug 2011 18:18:02 -0700 (PDT) In-Reply-To: References: <20110812223857.24366.15670.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2011 21:18:02 -0400 X-Google-Sender-Auth: TYFu2lSl7Tn8W-zhBfqhQxRgJ6U Message-ID: From: mike amundsen To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=0015174026a84616d604abc2e616 Subject: [apps-discuss] Fwd: New Version Notification for draft-amundsen-item-and-collection-link-relations-02.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, 31 Aug 2011 01:16:40 -0000 --0015174026a84616d604abc2e616 Content-Type: text/plain; charset=ISO-8859-1 All: After some general discussion on the link-relations list [1][2], I am posting my I-D here for comment (see below for draft-amundsen-item-and-collection-link-relations-02.txt). Assuming the I-D eventually passes muster here, I propose to send it the rfc-editor it as an Individual Submission. Looking forward to your feedback. Thanks. Mike Amundsen [1] http://www.ietf.org/mail-archive/web/link-relations/current/msg00267.html [2] http://www.ietf.org/mail-archive/web/link-relations/current/msg00270.html mca http://amundsen.com/blog/ http://twitter.com@mamund http://mamund.com/foaf.rdf#me ---------- Forwarded message ---------- From: Date: Fri, Aug 12, 2011 at 18:38 Subject: New Version Notification for draft-amundsen-item-and-collection-link-relations-02.txt To: mca@amundsen.com Cc: mca@amundsen.com A new version of I-D, draft-amundsen-item-and-collection-link-relations-02.txt has been successfully submitted by Mike Amundsen and posted to the IETF repository. Filename: draft-amundsen-item-and-collection-link-relations Revision: 02 Title: The Item and Collection Link Relations Creation date: 2011-08-12 WG ID: Individual Submission Number of pages: 5 Abstract: RFC 5988 [RFC5988] standardized a means of indicating the relationships between resources on the Web. This specification defines a pair of reciprocal link relation types that may be used to express the relationship between a collection and its members. Editorial Note (To be removed by RFC Editor) Distribution of this document is unlimited. Comments should be sent to the IETF Apps-Discuss mailing list (see <https://www.ietf.org/mailman/listinfo/apps-discuss>> ). The IETF Secretariat --0015174026a84616d604abc2e616 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All:

After some general discu= ssion on the link-relations list [1][2], I am posting my I-D here for comme= nt (see below for=A0draft-amundsen-item-and-collection-link-relations-02.tx= t).

Assuming the I-D eventually passes muster here, I propose to send it the rf= c-editor it as an Individual Submission.=A0

Lookin= g forward to your feedback.

Thanks.
Mike= Amundsen

[2]=A0<= a href=3D"http://www.ietf.org/mail-archive/web/link-relations/current/msg00= 270.html" target=3D"_blank">http://www.ietf.org/mail-archive/web/link-relat= ions/current/msg00270.html

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me=


---------- Forwarded= message ----------
From: <= internet-drafts@ietf.org>
Date: Fri, Aug 12, 2011 at 18:38
Subject: New Version Notification for draft-amundsen-item-and-collection-li= nk-relations-02.txt
To: mca@amundsen.com
Cc: mca@amundsen.com


A new version of I-D, draft= -amundsen-item-and-collection-link-relations-02.txt has been successfully s= ubmitted by Mike Amundsen and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-amundsen-item-and-collection-link-relations<= br> Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 The Item and Collection Link Relations
Creation date: =A0 2011-08-12
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 5

Abstract:
=A0 RFC 5988 [RFC5988] standardized a means of indicating the
=A0 relationships between resources on the Web. This specification
=A0 defines a pair of reciprocal link relation types that may be used to =A0 express the relationship between a collection and its members.

Editorial Note (To be removed by RFC Editor)

=A0 Distribution of this document is unlimited. =A0Comments should be sent=
=A0 to the IETF Apps-Discuss mailing list (see
=A0 &lt;https://www.ietf.org/mailman/listinfo/apps-discuss&a= mp;gt;).




The IETF Secretariat


--0015174026a84616d604abc2e616-- From barryleiba.mailing.lists@gmail.com Tue Aug 30 19:13: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 8730021F8C7F for ; Tue, 30 Aug 2011 19:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.027 X-Spam-Level: X-Spam-Status: No, score=-103.027 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOd8W9k5ttXP for ; Tue, 30 Aug 2011 19:13:43 -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 8CC6A21F8C81 for ; Tue, 30 Aug 2011 19:13:43 -0700 (PDT) Received: by gyf3 with SMTP id 3so230631gyf.31 for ; Tue, 30 Aug 2011 19:15:12 -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=jm9b3DkOKdXtFc6pvP3anuHsFcVPuzprzLXjgpcbStw=; b=mQxQ+v0J9ky6eFhtH2ZF/PLId/zMq/rQIvKIM30hwNBpkqxvS4c4/eWoNPrycB9FFH P2O53zRSEawp3SZTt3B/3ptXogSjtZSTumXIqxkxuXU1Zg6VUiu5Bug0lAqUL7e8O1rj FcyjwX8ESg93wEN8V1kyjfdiQPZKdEGB+N7N8= MIME-Version: 1.0 Received: by 10.150.47.2 with SMTP id u2mr6837673ybu.162.1314756912210; Tue, 30 Aug 2011 19:15:12 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.83.8 with HTTP; Tue, 30 Aug 2011 19:15:12 -0700 (PDT) In-Reply-To: References: <20110812223857.24366.15670.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2011 22:15:12 -0400 X-Google-Sender-Auth: rod7z0YdcGGQ6r3LDQomyHL8nwM Message-ID: From: Barry Leiba To: mike amundsen Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-amundsen-item-and-collection-link-relations-02.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, 31 Aug 2011 02:13:44 -0000 > Assuming the I-D eventually passes muster here, I propose to send it the > rfc-editor it as an Individual Submission. Mike, to clarify process here: You need to either have an Area Director sponsor it as an INDIVIDUAL submission, or send it to the Independent Stream Editor as an INDEPENDENT submission. Your draft doesn't specify a target status: whether you want it to be Standards Track or Informational. For Standards Track, only the former option is available (AD-sponsored as individual submission). For Informational, either option works. Barry From mca@amundsen.com Tue Aug 30 19:23: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 E064721F8D6E for ; Tue, 30 Aug 2011 19:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y27CVDse2YbZ for ; Tue, 30 Aug 2011 19:23:21 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 02F7B21F8CF8 for ; Tue, 30 Aug 2011 19:23:20 -0700 (PDT) Received: by ewy19 with SMTP id 19so112028ewy.31 for ; Tue, 30 Aug 2011 19:24:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.28.89 with SMTP id l25mr6095841fac.34.1314757489098; Tue, 30 Aug 2011 19:24:49 -0700 (PDT) Sender: mca@amundsen.com Received: by 10.223.154.199 with HTTP; Tue, 30 Aug 2011 19:24:49 -0700 (PDT) In-Reply-To: References: <20110812223857.24366.15670.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2011 22:24:49 -0400 X-Google-Sender-Auth: p6gRpSEnn7mIgMtic4ivzT4wdUs Message-ID: From: mike amundsen To: Barry Leiba Content-Type: multipart/alternative; boundary=0015174028e01a804d04abc3d5f9 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-amundsen-item-and-collection-link-relations-02.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, 31 Aug 2011 02:23:22 -0000 --0015174028e01a804d04abc3d5f9 Content-Type: text/plain; charset=ISO-8859-1 Barry: Thanks for the clarification. - Target status is Informational - I plan an Independent Submission to rfc-ise@rfc-editor.org mca http://amundsen.com/blog/ http://twitter.com@mamund http://mamund.com/foaf.rdf#me On Tue, Aug 30, 2011 at 22:15, Barry Leiba wrote: > > Assuming the I-D eventually passes muster here, I propose to send it the > > rfc-editor it as an Individual Submission. > > Mike, to clarify process here: > > You need to either have an Area Director sponsor it as an INDIVIDUAL > submission, or send it to the Independent Stream Editor as an > INDEPENDENT submission. > > Your draft doesn't specify a target status: whether you want it to be > Standards Track or Informational. For Standards Track, only the > former option is available (AD-sponsored as individual submission). > For Informational, either option works. > > Barry > --0015174028e01a804d04abc3d5f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Barry:

Thanks for the clarification.=A0
- Targ= et status is Informational
- I plan an Independent Submission to = rfc-ise@rfc-editor.org
<= div>
mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me


On Tue, Aug 30, 2011 at 22:15, Barry Lei= ba <barryle= iba@computer.org> wrote:
> Assuming the I-D eventually passes muster here, I pr= opose to send it the
> rfc-editor it as an Individual Submission.

Mike, to clarify process here:

You need to either have an Area Director sponsor it as an INDIVIDUAL
submission, or send it to the Independent Stream Editor as an
INDEPENDENT submission.

Your draft doesn't specify a target status: whether you want it to be Standards Track or Informational. =A0For Standards Track, only the
former option is available (AD-sponsored as individual submission).
For Informational, either option works.

Barry

--0015174028e01a804d04abc3d5f9-- From evnikita2@gmail.com Tue Aug 30 20:56: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 9C77E21F8C36 for ; Tue, 30 Aug 2011 20:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2mkjuxR050r for ; Tue, 30 Aug 2011 20:56:56 -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 5797D21F8C35 for ; Tue, 30 Aug 2011 20:56:56 -0700 (PDT) Received: by bkar4 with SMTP id r4so408991bka.31 for ; Tue, 30 Aug 2011 20:58:24 -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=KUR6saVnj6ku+Q1WzNPMGK1w8I3htCAjzw6IyEt9S/s=; b=GnY5JE15tDwW2edPPjkP5DEgc95+hNfrfCvXPEXjoM5TdbDO9F83TIpCeYpZrxkkvq Wes4siR+h7MiGum3KCsQnBxGcLI+sHFEc6SqYX4XH0/BdrLQhexopXUhUYVbF67dJePT DSDLobzlNOWcJfm1RyDkOq1IKHYKWfBNvfaT0= Received: by 10.204.139.3 with SMTP id c3mr595629bku.305.1314763104836; Tue, 30 Aug 2011 20:58:24 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id u14sm189894bkt.62.2011.08.30.20.58.23 (version=SSLv3 cipher=OTHER); Tue, 30 Aug 2011 20:58:23 -0700 (PDT) Message-ID: <4E5DB17F.5090302@gmail.com> Date: Wed, 31 Aug 2011 06:58:55 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-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: Wed, 31 Aug 2011 03:56:57 -0000 A question to clarify: Are you going to advance this to Full Standard? Mykyta 30.08.2011 21:52, Barry Leiba wrote: >>> Title : The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages >>> Author(s) : Murray S. Kucherawy >>> Filename : draft-ietf-appsawg-rfc3462bis-00.txt >>> Pages : 13 >>> Date : 2011-08-29 > For convenience, a link to the document is here: > http://tools.ietf.org/html/draft-ietf-appsawg-rfc3462bis > >> This is a straight conversion from the individual submission, which >> contained what I think was the consensus from the Quebec City >> meeting plus some list discussion afterwards. Review please >> (especially Ned and Keith!). > Note to all: I have asked the Secretariat to add the following WG milestone: > > Sept 2011: Submit draft-ietf-appsawg-rfc3462bis to the IESG > > Let's see if we can make that date by getting reviews in now. > > Barry, appsawg chair > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From evnikita2@gmail.com Tue Aug 30 21:32: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 9988C21F8C30; Tue, 30 Aug 2011 21:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxUS06Pg0zSY; Tue, 30 Aug 2011 21:32:02 -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 D420921F8C31; Tue, 30 Aug 2011 21:32:01 -0700 (PDT) Received: by bkar4 with SMTP id r4so444190bka.31 for ; Tue, 30 Aug 2011 21:33:30 -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=xcYzjLjljBfhrsh2aC3tpqwZuSZCBpOJ1jaj3ebgFwI=; b=bLxf/YuwshfCmeDdCZdXbNJg5RS4v/BlJbUl0tMynq0cBbbq4IVQFH2YGqKOuwBy0g Op9S6XcrJxlctGs1QM3q9vE327OF4k3EVrmrPuulBbdP+WwwKKSLwiXbJsR+byonh2Es kyLYtHYvGIaElquBh0H4UMmQ1x9aYVt+yPz0s= Received: by 10.204.135.73 with SMTP id m9mr603106bkt.340.1314765210388; Tue, 30 Aug 2011 21:33:30 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id f6sm199022bkw.30.2011.08.30.21.33.28 (version=SSLv3 cipher=OTHER); Tue, 30 Aug 2011 21:33:29 -0700 (PDT) Message-ID: <4E5DB9B8.70006@gmail.com> Date: Wed, 31 Aug 2011 07:34:00 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20110829144145.31952.69055.idtracker@ietfa.amsl.com> <4E5D06EA.9040205@gmx.de> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090406090607000400070606" Cc: draft-ohye-canonical-link-relation@tools.ietf.org, "link-relations@ietf.org" Subject: Re: [apps-discuss] Fwd: I-D Action: draft-ohye-canonical-link-relation-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, 31 Aug 2011 04:32:03 -0000 This is a multi-part message in MIME format. --------------090406090607000400070606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Maile and Joachim, I did provide some comments on this draft on link-relations list; but I'd like you processed several new editorial issues/nits prior to submitting publication request. > Abstract > > The canonical link relation, developed from [RFC5988] which indicates > relationships between Internet links, specifies the preferred URI > from a set of identical or vastly similar content accessible on > multiple URIs. This isn't clear enough for abstract. I propose: > Abstract > > RFC 5988 specified a way to define relationships betweeen links on > the Web. This document describes a new type of such relationship, > 'canonical', which desigantes the preferred URI from a set of identical > or vastly similar ones. A similar text should go in the first paragraph of Introduction. In Introduction: > making it possible for references to the context URI to be updated to > reference the designated URI. Maybe you meant "target URI" instead "designated URI" (terminology from RFC 5988). Section 3: > The target/canonical URI MAY: > > o Specify a URI Reference (see [RFC3986] Section 4.1) i.e., an > absolute URI or a relative reference What you mean here? If you wanted to show that canonical URI may be a relative one, you should better write: > The target/canonical URI MAY: > > o Be a relative URI (see [RFC3986], Section 4.2); Ibid: > The target/canonical URI SHOULD NOT designate: > > o The source URI of a permanent redirect (for HTTP, this refers to > Section 10.3.2 of [RFC2616]) or a "300 Multiple Choices" URI > (Section 10.3.1 of [RFC2616]) Here probably a typo happened; so please change to: > The target/canonical URI SHOULD NOT designate: > > o The URI which is a source of a permanent redirect (for HTTP, this > refers to 300 and 301 response codes, defined in Sections > 10.3.1 and 10.3.2 of RFC 2616 [RFC2616]); Ibid: > o A URI that serves a 4xx error code (Section 10.4 of [RFC2616]). Again, HTTP-centric approach. There are many other application-layer protocols, for which URI schemes exist, and they aren't very likely to even have the same req/response model as HTTP has. As this is only available in HTTP, I propose to exclude this bullet, unless you can reformulate it so that it doesn't use HTTP-only feature. > o The first page of a multi-page article or multi-page listing of > items (since the first page is not a duplicate or a superset or > the context URI). For example, page2 and page3 of an article > SHOULD NOT specify page1 as the canonical. Here you may point to Section 6.12 of you reference [REC-html401-19991224], which specifies the 'start' relation (http://www.w3.org/TR/1999/REC-html401-19991224/types.html#idx-link_type), used for this purpose. In Section 5: > 2. Permanent HTTP redirects (Section 10.3.2 of [RFC2616]), the > traditional strong indicator that a URI's content has been > permanently moved, could not be implemented in place of the > canonical link relation. Also too HTTP-centric approach. The same as above applies. References: Why make RFC 2616 and HTML4 spec Normative references? Shouldn't Informative be OK? Thanks, Mykyta Yevstifeyev 31.08.2011 1:21, Maile Ohye wrote: > Hi everyone, please let us know if you have additional feedback. After > many rounds of helpful discussion, I think we're nearing submission. :) > > I hope to submit a publication request on Wednesday, September 7th, 2011. > > Thanks! > Maile > > -------- Original Message -------- > Subject: I-D Action: draft-ohye-canonical-link-relation-01.txt > Date: Mon, 29 Aug 2011 07:41:45 -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 : The Canonical Link Relation > Author(s) : Maile Ohye > Joachim Kupke > Filename : draft-ohye-canonical-link-relation-01.txt > Pages : 6 > Date : 2011-07-30 > > The canonical link relation, developed from [RFC5988] which > indicates > relationships between Internet links, specifies the preferred URI > from a set of identical or vastly similar content accessible on > multiple URIs. > > Editorial Note (To be removed by RFC Editor) > > Distribution of this document is unlimited. Comments should be sent > to the IETF Apps-Discuss mailing list (see > <https://www.ietf.org/mailman/listinfo/apps-discuss> > ). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ohye-canonical-link-relation-01.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-ohye-canonical-link-relation-01.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 > > _______________________________________________ > 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 --------------090406090607000400070606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Maile and Joachim,

I did provide some comments on this draft on link-relations list; but I'd like you processed several new editorial issues/nits prior to submitting publication request.

Abstract

   The canonical link relation, developed from [RFC5988] which indicates
   relationships between Internet links, specifies the preferred URI
   from a set of identical or vastly similar content accessible on
   multiple URIs.

This isn't clear enough for abstract.  I propose:

Abstract

   RFC 5988 specified a way to define relationships betweeen links on
   the Web.  This document describes a new type of such relationship,
   'canonical', which desigantes the preferred URI from a set of identical
   or vastly similar ones.

A similar text should go in the first paragraph of Introduction.

In Introduction:

   making it possible for references to the context URI to be updated to
   reference the designated URI.

Maybe you meant "target URI" instead "designated URI" (terminology from RFC 5988).

Section 3:

   The target/canonical URI MAY:

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

What you mean here?  If you wanted to show that canonical URI may be a relative one, you should better write:

   The target/canonical URI MAY:

   o  Be a relative URI (see [RFC3986], Section 4.2);

Ibid:

   The target/canonical URI SHOULD NOT designate:

   o  The source URI of a permanent redirect (for HTTP, this refers to
      Section 10.3.2 of [RFC2616]) or a "300 Multiple Choices" URI
      (Section 10.3.1 of [RFC2616])

Here probably a typo happened; so please change to:

   The target/canonical URI SHOULD NOT designate:

   o  The URI which is a source of a permanent redirect (for HTTP, this
      refers to 300 and 301 response codes, defined in Sections
      10.3.1 and 10.3.2 of RFC 2616 [RFC2616]);

Ibid:

   o  A URI that serves a 4xx error code (Section 10.4 of [RFC2616]).

Again, HTTP-centric approach.  There are many other application-layer protocols, for which URI schemes exist, and they aren't very likely to even have the same req/response model as HTTP has.  As this is only available in HTTP, I propose to exclude this bullet, unless you can reformulate it so that it doesn't use HTTP-only feature.

   o  The first page of a multi-page article or multi-page listing of
      items (since the first page is not a duplicate or a superset or
      the context URI).  For example, page2 and page3 of an article
      SHOULD NOT specify page1 as the canonical.

Here you may point to Section 6.12 of you reference [REC-html401-19991224], which specifies the 'start' relation (http://www.w3.org/TR/1999/REC-html401-19991224/types.html#idx-link_type), used for this purpose.

In Section 5:

   2.  Permanent HTTP redirects (Section 10.3.2 of [RFC2616]), the
       traditional strong indicator that a URI's content has been
       permanently moved, could not be implemented in place of the
       canonical link relation.

Also too HTTP-centric approach.  The same as above applies.

References:

Why make RFC 2616 and HTML4 spec Normative references?  Shouldn't Informative be OK?

Thanks,
Mykyta Yevstifeyev

31.08.2011 1:21, Maile Ohye wrote:
Hi everyone, please let us know if you have additional feedback. After many rounds of helpful discussion, I think we're nearing submission. :) 

I hope to submit a publication request on Wednesday, September 7th, 2011.

Thanks!
Maile

-------- Original Message --------
Subject: I-D Action: draft-ohye-canonical-link-relation-01.txt
Date: Mon, 29 Aug 2011 07:41:45 -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           : The Canonical Link Relation
       Author(s)       : Maile Ohye
                         Joachim Kupke
       Filename        : draft-ohye-canonical-link-relation-01.txt
       Pages           : 6
       Date            : 2011-07-30

  The canonical link relation, developed from [RFC5988] which indicates
  relationships between Internet links, specifies the preferred URI
  from a set of identical or vastly similar content accessible on
  multiple URIs.

Editorial Note (To be removed by RFC Editor)

  Distribution of this document is unlimited.  Comments should be sent
  to the IETF Apps-Discuss mailing list (see
  &lt;https://www.ietf.org/mailman/listinfo/apps-discuss&gt;).


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ohye-canonical-link-relation-01.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-ohye-canonical-link-relation-01.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

_______________________________________________
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

--------------090406090607000400070606-- From msk@cloudmark.com Tue Aug 30 21:33: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 29D8821F8C36 for ; Tue, 30 Aug 2011 21:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.527 X-Spam-Level: X-Spam-Status: No, score=-103.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CV26JOQSe2lY for ; Tue, 30 Aug 2011 21:33:28 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id AF25321F8C32 for ; Tue, 30 Aug 2011 21:33:28 -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, 30 Aug 2011 21:34:58 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Tue, 30 Aug 2011 21:34:56 -0700 Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.txt Thread-Index: Acxnkj3ay7qWIRt1TGqmx/wGU/x7EwABQINQ Message-ID: References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> <4E5DB17F.5090302@gmail.com> In-Reply-To: <4E5DB17F.5090302@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-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: Wed, 31 Aug 2011 04:33:29 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Mykyta Yevstifeyev > Sent: Tuesday, August 30, 2011 8:59 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.= txt >=20 > A question to clarify: Are you going to advance this to Full Standard? Eventually, yes, it would be eligible. However, it's my understanding that= this change requires it to recycle at Proposed Standard. From julian.reschke@gmx.de Tue Aug 30 23:19: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 6698D21F8C1A for ; Tue, 30 Aug 2011 23:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.164 X-Spam-Level: X-Spam-Status: No, score=-104.164 tagged_above=-999 required=5 tests=[AWL=-1.565, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwesQBoYQEEp for ; Tue, 30 Aug 2011 23:19: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 12AC421F8C14 for ; Tue, 30 Aug 2011 23:19:26 -0700 (PDT) Received: (qmail invoked by alias); 31 Aug 2011 06:20:55 -0000 Received: from p508FA8FA.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.168.250] by mail.gmx.net (mp071) with SMTP; 31 Aug 2011 08:20:55 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19PRVQRklJPYcSr1MN81cFXlnsj3F5ZtBxHbUWkWh 3Sz42fv7m2Zyks Message-ID: <4E5DD2BF.40801@gmx.de> Date: Wed, 31 Aug 2011 08:20:47 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Mykyta Yevstifeyev References: <20110829144145.31952.69055.idtracker@ietfa.amsl.com> <4E5D06EA.9040205@gmx.de> <4E5DB9B8.70006@gmail.com> In-Reply-To: <4E5DB9B8.70006@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: draft-ohye-canonical-link-relation@tools.ietf.org, apps-discuss@ietf.org, "link-relations@ietf.org" Subject: Re: [apps-discuss] Fwd: I-D Action: draft-ohye-canonical-link-relation-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, 31 Aug 2011 06:19:28 -0000 On 2011-08-31 06:34, Mykyta Yevstifeyev wrote: > ... > Section 3: > >> The target/canonical URI MAY: >> >> o Specify a URI Reference (see [RFC3986] Section 4.1) i.e., an >> absolute URI or a relative reference > > What you mean here? If you wanted to show that canonical URI may be a > relative one, you should better write: > >> The target/canonical URI MAY: >> >> o Be a relative URI (see [RFC3986], Section 4.2); The original text seems to be clearer to me. > Ibid: > >> o A URI that serves a 4xx error code (Section 10.4 of [RFC2616]). > > Again, HTTP-centric approach. There are many other application-layer > protocols, for which URI schemes exist, and they aren't very likely to > even have the same req/response model as HTTP has. As this is only > available in HTTP, I propose to exclude this bullet, unless you can > reformulate it so that it doesn't use HTTP-only feature. -1. This is useful information. Just because something is specific doesn't mean it shouldn't be mentioned. >> o The first page of a multi-page article or multi-page listing of >> items (since the first page is not a duplicate or a superset or >> the context URI). For example, page2 and page3 of an article >> SHOULD NOT specify page1 as the canonical. > > Here you may point to Section 6.12 of you reference > [REC-html401-19991224], which specifies the 'start' relation > (http://www.w3.org/TR/1999/REC-html401-19991224/types.html#idx-link_type), > used for this purpose. +-0. > In Section 5: > >> 2. Permanent HTTP redirects (Section 10.3.2 of [RFC2616]), the >> traditional strong indicator that a URI's content has been >> permanently moved, could not be implemented in place of the >> canonical link relation. > > Also too HTTP-centric approach. The same as above applies. -1 > References: > > Why make RFC 2616 and HTML4 spec Normative references? Shouldn't > Informative be OK? For 2616 is makes sense if there are normative constrains specific for HTTP. > ... Best regards, Julian From evnikita2@gmail.com Wed Aug 31 00:38: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 E726F21F8C3E; Wed, 31 Aug 2011 00:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RG6jYPe0671H; Wed, 31 Aug 2011 00:38:43 -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 6C1DE21F8B9D; Wed, 31 Aug 2011 00:38:43 -0700 (PDT) Received: by bkar4 with SMTP id r4so647303bka.31 for ; Wed, 31 Aug 2011 00:40:12 -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=DzR0EZHtIBwLeexM4RT9AJ9R2zDuGbgw+aaFSePpxQo=; b=wfIyn7wBGXN0JyMw5Rj/VqoDQSiM4CuV0o2/PmOf/2LdML7LjRIJAkarHRuBQByXaB zvfZIdMBG/iMWg9EGfoHOMZ/ExaSmrvoZVgWWbm3GSqmSB3pyPKc5Pnh/Yajq/tmp42C WoPGwo5B9hN8GA10s/BHKpVQI1yOzi1KAUjLE= Received: by 10.204.155.85 with SMTP id r21mr76538bkw.64.1314776412254; Wed, 31 Aug 2011 00:40:12 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id b17sm242310bkd.65.2011.08.31.00.40.10 (version=SSLv3 cipher=OTHER); Wed, 31 Aug 2011 00:40:11 -0700 (PDT) Message-ID: <4E5DE57B.8070801@gmail.com> Date: Wed, 31 Aug 2011 10:40:43 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Julian Reschke References: <20110829144145.31952.69055.idtracker@ietfa.amsl.com> <4E5D06EA.9040205@gmx.de> <4E5DB9B8.70006@gmail.com> <4E5DD2BF.40801@gmx.de> In-Reply-To: <4E5DD2BF.40801@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ohye-canonical-link-relation@tools.ietf.org, apps-discuss@ietf.org, "link-relations@ietf.org" Subject: Re: [apps-discuss] Fwd: I-D Action: draft-ohye-canonical-link-relation-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, 31 Aug 2011 07:38:49 -0000 31.08.2011 9:20, Julian Reschke wrote: > On 2011-08-31 06:34, Mykyta Yevstifeyev wrote: >> ... >> Section 3: >> >>> The target/canonical URI MAY: >>> >>> o Specify a URI Reference (see [RFC3986] Section 4.1) i.e., an >>> absolute URI or a relative reference >> >> What you mean here? If you wanted to show that canonical URI may be a >> relative one, you should better write: >> >>> The target/canonical URI MAY: >>> >>> o Be a relative URI (see [RFC3986], Section 4.2); > > The original text seems to be clearer to me. It is already obvious that target URI must conform to RFC 3986 from RFC 5988: > Link = "Link" ":" #link-value > link-value = "<" URI-Reference">" *( ";" link-param ) and, correspondingly, the target URI *is* (rather than *MAY be*) . If the authors want to clarify that target URI may be relative, my proposed text is better. > >> Ibid: >> >>> o A URI that serves a 4xx error code (Section 10.4 of [RFC2616]). >> >> Again, HTTP-centric approach. There are many other application-layer >> protocols, for which URI schemes exist, and they aren't very likely to >> even have the same req/response model as HTTP has. As this is only >> available in HTTP, I propose to exclude this bullet, unless you can >> reformulate it so that it doesn't use HTTP-only feature. > > -1. This is useful information. Just because something is specific > doesn't mean it shouldn't be mentioned. From Section 10.4 of RFC 2616: > The 4xx class of status code is intended for cases in which the > client seems to have erred. So 4xx responses are used when something is wring with HTTP request. I doubt there are alternatives of such definition in *all* protocols for which the URI scheme has been specified. Eg., FTP doesn't alter error conditions caused by client or server; neither does TFTP and many others. We aren't defining the link relation fro 'http' and 'https' URIs only; it is theoretically to allow any scheme, including not yet defined. >> In Section 5: >> >>> 2. Permanent HTTP redirects (Section 10.3.2 of [RFC2616]), the >>> traditional strong indicator that a URI's content has been >>> permanently moved, could not be implemented in place of the >>> canonical link relation. >> >> Also too HTTP-centric approach. The same as above applies. > > -1 See above. > >> References: >> >> Why make RFC 2616 and HTML4 spec Normative references? Shouldn't >> Informative be OK? > > For 2616 is makes sense if there are normative constrains specific for > HTTP. See above as well. Why tie ourselves with HTTP only? Mykyta > > > ... > > Best regards, Julian > From evnikita2@gmail.com Wed Aug 31 06:23: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 8E03921F8AE1 for ; Wed, 31 Aug 2011 06:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.173 X-Spam-Level: X-Spam-Status: No, score=-3.173 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPlST8Ug9d3F for ; Wed, 31 Aug 2011 06:23:11 -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 45A9921F859E for ; Wed, 31 Aug 2011 06:23:11 -0700 (PDT) Received: by bkar4 with SMTP id r4so1027043bka.31 for ; Wed, 31 Aug 2011 06:24:40 -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=4hTrFS6Vz73IDmyAdtHPxXpJVfjlFtz633Pp+hLFFrw=; b=Ax3+T3PwbmzLMgjlqjKVJqOArEmztnUrZOzxHr4/4pTyzE93CE1t50dXmaQ+UXS/Cp 3P6OoMAw7SLoqq24KsaURFDKetY+c4oMR95iagVwOSq6vn/z2xEHYn2sIW/WXlkMWiTV LwzhECkU6wZNZzJaWm0Upkgc3qtDC/1sMtJzU= Received: by 10.204.128.130 with SMTP id k2mr250833bks.322.1314797080848; Wed, 31 Aug 2011 06:24:40 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id f9sm377108bkt.3.2011.08.31.06.24.39 (version=SSLv3 cipher=OTHER); Wed, 31 Aug 2011 06:24:40 -0700 (PDT) Message-ID: <4E5E3637.3040809@gmail.com> Date: Wed, 31 Aug 2011 16:25:11 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Apps-discuss list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-melnikov-pop3-over-tls@tools.ietf.org Subject: [apps-discuss] Fwd: I-D Action: draft-melnikov-pop3-over-tls-02.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, 31 Aug 2011 13:23:12 -0000 FYI: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : POP3 over TLS > Author(s) : Alexey Melnikov > Chris Newman > Mykyta Yevstifeyev > Filename : draft-melnikov-pop3-over-tls-02.txt > Pages : 7 > Date : 2011-08-30 > > This document specifies how the Post Office Protocol, Version 3 > (POP3) may be secured with Transport Layer Security (TLS) protocol, > by establishing TLS connection directly before POP3 transaction. It > updates RFC 2595. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-melnikov-pop3-over-tls-02.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-melnikov-pop3-over-tls-02.txt For convenience, link to HTML version: http://tools.ietf.org/html/draft-melnikov-pop3-over-tls-02. This draft was previously discussed on ietf-pop3ext@imc.org list, and I expect we'll be able to get more feedback here. Please let use know if you have any comments by mailing to draft-melnikov-pop3-over-tls@tools.ietf.org and cc'ing to apps-discuss. Thanks, Mykyta Yevstifeyev From evnikita2@gmail.com Wed Aug 31 07:37: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 5E31A21F8AFC for ; Wed, 31 Aug 2011 07:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJbYTc8oZjnX for ; Wed, 31 Aug 2011 07:37:55 -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 4BEBB21F8AC3 for ; Wed, 31 Aug 2011 07:37:55 -0700 (PDT) Received: by bkar4 with SMTP id r4so1108273bka.31 for ; Wed, 31 Aug 2011 07:39:25 -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=XkjlC1als5JOvtDgL29jhVCZx6Vm3ldL5QW6zeRJ2JY=; b=LcFph9+9PmoaocLmELK5kGSj/kQLB9qGseUwxps7Lql8yFQVro6Bk0PrGkGisNAGRo NnHH3rHHU8EZLzzmi0v8sx1/Mv9u4ZypsBq4/Kq6DpWgXf8SP+ZPz7vi/WzxwPu+iQAv RxzhFEms3XhhxQD0wv1P0YgAgXEeT3bm2vSZ8= Received: by 10.204.143.82 with SMTP id t18mr306699bku.174.1314801564850; Wed, 31 Aug 2011 07:39:24 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id v27sm208029bkt.15.2011.08.31.07.39.22 (version=SSLv3 cipher=OTHER); Wed, 31 Aug 2011 07:39:23 -0700 (PDT) Message-ID: <4E5E47BB.3010403@gmail.com> Date: Wed, 31 Aug 2011 17:39:55 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Mark Nottingham References: <20110531062229.28776.82429.idtracker@ietfa.amsl.com> <0CE9268E-5802-4B0A-B643-F580E7F048B5@mnot.net> <4E5BB162.6010101@gmail.com> 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] I-D Action: draft-nottingham-http-browser-hints-02.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, 31 Aug 2011 14:37:56 -0000 30.08.2011 4:03, Mark Nottingham wrote: > I didn't go in this direction because it *seems* to conflict with the STS effort in websec. Maybe someone from over there could comment? I understand that HSTS is only useful when site declares that HTTPS must be used any time when connecting to it. Specific areas/resources may not be declared to be so (If I'm wrong, correct me). Anyway, an alternative is never a bad thing. Mykyta Yevstifeyev > > Cheers, > > s > On 30/08/2011, at 1:33 AM, Mykyta Yevstifeyev wrote: > >> Proposal for a new hint: >> >>> 5.8. https >>> >>> o Browser Hint Name: https >>> o Description: When true, this hint indicates the user agent may >>> use HTTPS and, correspondigly, 'https' URI scheme [RFC2818] with >>> the specific areas (resources) of the site. >>> o Value Type: prefixlist >>> o Contact: /somebody/ >> Mykyta Yevstifeyev >> >> 31.05.2011 9:28, Mark Nottingham wrote: >>> FYI. Diffs at: >>> http://tools.ietf.org/rfcdiff?url2=draft-nottingham-http-browser-hints-02 >>> >>> Changelog: >>> - removed Ref header and rearranged referer-based hints >>> - added 'prefixlist' value type >>> - changed omit-cookies from list of cookie names to prefixlist >>> - added caching advice for 404s >>> >>> Feedback appreciated, as always. >>> >>> >>> >>> Begin forwarded message: >>> >>>> From: internet-drafts@ietf.org >>>> Date: 31 May 2011 4:22:29 PM AEST >>>> To: i-d-announce@ietf.org >>>> Subject: I-D Action: draft-nottingham-http-browser-hints-02.txt >>>> Reply-To: internet-drafts@ietf.org >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> >>>> Title : HTTP Browser Hints >>>> Author(s) : Mark Nottingham >>>> Filename : draft-nottingham-http-browser-hints-02.txt >>>> Pages : 9 >>>> Date : 2011-05-30 >>>> >>>> Over time, Web browsers have adapted how they use HTTP based upon >>>> common server configurations and behaviours. While this is necessary >>>> in the common case, it can be detrimental for performance and >>>> interoperability. >>>> >>>> This document establishes a mechanism whereby origin servers can make >>>> available hints for browsers about their preferences and >>>> capabilities, without imposing overhead on their interactions or >>>> requiring support for them. >>>> >>>> This is intended to allow browsers to safely optimise connections to >>>> servers. >>>> >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02.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-nottingham-http-browser-hints-02.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 >>> -- >>> Mark Nottingham http://www.mnot.net/ >>> >>> >>> >>> _______________________________________________ >>> 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 > -- > Mark Nottingham http://www.mnot.net/ > > > > From stpeter@stpeter.im Wed Aug 31 07:39: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 F3DAA21F8B4C for ; Wed, 31 Aug 2011 07:39:44 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gNWcrVrf1i4 for ; Wed, 31 Aug 2011 07:39:31 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E842B21F8AC3 for ; Wed, 31 Aug 2011 07:39:30 -0700 (PDT) Received: from leavealone.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CD94B41477; Wed, 31 Aug 2011 08:43:37 -0600 (MDT) Message-ID: <4E5E47FB.9050100@stpeter.im> Date: Wed, 31 Aug 2011 08:40:59 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Mykyta Yevstifeyev References: <20110531062229.28776.82429.idtracker@ietfa.amsl.com> <0CE9268E-5802-4B0A-B643-F580E7F048B5@mnot.net> <4E5BB162.6010101@gmail.com> <4E5E47BB.3010403@gmail.com> In-Reply-To: <4E5E47BB.3010403@gmail.com> X-Enigmail-Version: 1.3.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] I-D Action: draft-nottingham-http-browser-hints-02.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, 31 Aug 2011 14:39:45 -0000 On 8/31/11 8:39 AM, Mykyta Yevstifeyev wrote: > 30.08.2011 4:03, Mark Nottingham wrote: >> I didn't go in this direction because it *seems* to conflict with the >> STS effort in websec. Maybe someone from over there could comment? > > I understand that HSTS is only useful when site declares that HTTPS must > be used any time when connecting to it. Specific areas/resources may > not be declared to be so (If I'm wrong, correct me). What is the use case for that feature? > Anyway, an alternative is never a bad thing. Too many ways to do the same thing can be confusing. Peter -- Peter Saint-Andre https://stpeter.im/ From evnikita2@gmail.com Wed Aug 31 07:46: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 EA5BA21F86DF for ; Wed, 31 Aug 2011 07:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxYREp2RgXxb for ; Wed, 31 Aug 2011 07:46:04 -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 24BA621F852E for ; Wed, 31 Aug 2011 07:46:03 -0700 (PDT) Received: by bkar4 with SMTP id r4so1117435bka.31 for ; Wed, 31 Aug 2011 07:47: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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=AiLFGYFlhV66Kv4lj3GxmWtsMWYbmEKFURtOaTGYLj4=; b=dXLlVWOXF6O3Hikn8t2RAt1jhxy/23HUYU0M+e5gQXpFl/OXb4IARsxIG/H41NER0P 8AlMvvRbpddD5VYw8HKeGnsjttSEq28paO5g9FNCxccHibBWUmCkjo/rcvwCPqO3QMOY tVQis+MRJb+SkzMMwsKeNS4MoqFhvlwBOXDj8= Received: by 10.204.157.16 with SMTP id z16mr298208bkw.162.1314802053913; Wed, 31 Aug 2011 07:47:33 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id o20sm402940bku.43.2011.08.31.07.47.32 (version=SSLv3 cipher=OTHER); Wed, 31 Aug 2011 07:47:33 -0700 (PDT) Message-ID: <4E5E49A5.1020106@gmail.com> Date: Wed, 31 Aug 2011 17:48:05 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <20110531062229.28776.82429.idtracker@ietfa.amsl.com> <0CE9268E-5802-4B0A-B643-F580E7F048B5@mnot.net> <4E5BB162.6010101@gmail.com> <4E5E47BB.3010403@gmail.com> <4E5E47FB.9050100@stpeter.im> In-Reply-To: <4E5E47FB.9050100@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-nottingham-http-browser-hints-02.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, 31 Aug 2011 14:46:05 -0000 31.08.2011 17:40, Peter Saint-Andre wrote: > On 8/31/11 8:39 AM, Mykyta Yevstifeyev wrote: >> 30.08.2011 4:03, Mark Nottingham wrote: >>> I didn't go in this direction because it *seems* to conflict with the >>> STS effort in websec. Maybe someone from over there could comment? >> I understand that HSTS is only useful when site declares that HTTPS must >> be used any time when connecting to it. Specific areas/resources may >> not be declared to be so (If I'm wrong, correct me). > What is the use case for that feature? This provides a way for client which prefers to use secure variant to learn which areas of the site are fine to be accessed so, without attempting to use HTTPS where it isn't possible. From barryleiba.mailing.lists@gmail.com Wed Aug 31 07:51: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 E266C21F8ABD for ; Wed, 31 Aug 2011 07:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.026 X-Spam-Level: X-Spam-Status: No, score=-103.026 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR7Q56mtnaY1 for ; Wed, 31 Aug 2011 07:51:39 -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 6703C21F8AB9 for ; Wed, 31 Aug 2011 07:51:39 -0700 (PDT) Received: by gxk19 with SMTP id 19so751451gxk.31 for ; Wed, 31 Aug 2011 07:53: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:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qm544LRqoxXS2BHgBHvzvhJ4eW91DOm00aMvzNQDXrQ=; b=af+ql9n55Lz7HNubGvZtONX2khbrxouKxayyZnQ2YX9xQ027TAsiZLSKBO5TGEjY0t yCdEePf3MO1OpippThoveNrSQ2PBm2JtG1e1OO1LemlAqLSOS47JibBkfTZn6B2xllML YzW3G7Pf/hpJmclJIRK4xylgNEtXBuGqpoFpQ= MIME-Version: 1.0 Received: by 10.236.183.164 with SMTP id q24mr2508394yhm.117.1314802389697; Wed, 31 Aug 2011 07:53:09 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.40.6 with HTTP; Wed, 31 Aug 2011 07:53:09 -0700 (PDT) In-Reply-To: <4E5E49A5.1020106@gmail.com> References: <20110531062229.28776.82429.idtracker@ietfa.amsl.com> <0CE9268E-5802-4B0A-B643-F580E7F048B5@mnot.net> <4E5BB162.6010101@gmail.com> <4E5E47BB.3010403@gmail.com> <4E5E47FB.9050100@stpeter.im> <4E5E49A5.1020106@gmail.com> Date: Wed, 31 Aug 2011 10:53:09 -0400 X-Google-Sender-Auth: 3lOntk7LVHnrfnEOt91HRW_L1ho Message-ID: From: Barry Leiba To: Mykyta Yevstifeyev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Mark Nottingham , apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-nottingham-http-browser-hints-02.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, 31 Aug 2011 14:51:40 -0000 >>> I understand that HSTS is only useful when site declares that HTTPS mus= t >>> be used any time when connecting to it. =A0Specific areas/resources may >>> not be declared to be so (If I'm wrong, correct me). >> >> What is the use case for that feature? > > This provides a way for client which prefers to use secure variant to lea= rn > which areas of the site are fine to be accessed so, without attempting to > use HTTPS where it isn't possible. Let me see if I understand this correctly: A client that wants to use HTTPS, but isn't sure whether this part of the site supports it, can do it one of two ways: 1. Try HTTPS. If it doesn't work, fall back to HTTP. 2. Use HTTP. If a "hint" is included in the HTTP response that says HTTPS is OK, then switch to HTTP. You're proposing 2. Is that right? Assuming that's right, I'm saying that 1 is better. Barry From evnikita2@gmail.com Wed Aug 31 09:17: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 4968E21F8C43 for ; Wed, 31 Aug 2011 09:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSCZ5ChgQccL for ; Wed, 31 Aug 2011 09:17:45 -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 71BFD21F8C74 for ; Wed, 31 Aug 2011 09:17:45 -0700 (PDT) Received: by mail-bw0-f44.google.com with SMTP id r4so1210121bka.31 for ; Wed, 31 Aug 2011 09:19:16 -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=hX9HHQ7CPi7jquJU4+KLvnZyX3c2l6k4Vgy9CcRBAyE=; b=ane4pze9FDPqAM1rWHSS9WJJxxkwAh56CF+cYxcPFz0rdvg7LNiZIz6d0kojvrAsE1 gOKJ98ylHtI7Q3M00VUl+dwjL76bgUgCFK5KUxugXGak5IBflf/IHNm3D6EnOZIs5bbI gj57Sq+Z+PbIKeiWbVIruV8KdFOZWaYcpYY6Q= Received: by 10.204.131.148 with SMTP id x20mr356233bks.321.1314807555935; Wed, 31 Aug 2011 09:19:15 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id y3sm435211bkw.16.2011.08.31.09.19.14 (version=SSLv3 cipher=OTHER); Wed, 31 Aug 2011 09:19:15 -0700 (PDT) Message-ID: <4E5E5F22.4010407@gmail.com> Date: Wed, 31 Aug 2011 19:19:46 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Barry Leiba References: <20110531062229.28776.82429.idtracker@ietfa.amsl.com> <0CE9268E-5802-4B0A-B643-F580E7F048B5@mnot.net> <4E5BB162.6010101@gmail.com> <4E5E47BB.3010403@gmail.com> <4E5E47FB.9050100@stpeter.im> <4E5E49A5.1020106@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-nottingham-http-browser-hints-02.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, 31 Aug 2011 16:17:46 -0000 31.08.2011 17:53, Barry Leiba wrote: >>>> I understand that HSTS is only useful when site declares that HTTPS must >>>> be used any time when connecting to it. Specific areas/resources may >>>> not be declared to be so (If I'm wrong, correct me). >>> What is the use case for that feature? >> This provides a way for client which prefers to use secure variant to learn >> which areas of the site are fine to be accessed so, without attempting to >> use HTTPS where it isn't possible. > Let me see if I understand this correctly: > > A client that wants to use HTTPS, but isn't sure whether this part of > the site supports it, can do it one of two ways: > > 1. Try HTTPS. If it doesn't work, fall back to HTTP. > > 2. Use HTTP. If a "hint" is included in the HTTP response that says > HTTPS is OK, then switch to HTTP. > > You're proposing 2. Is that right? > > Assuming that's right, I'm saying that 1 is better. You're right. But: a client needs to do 1 for each time it tries to access something whereas 2 would only be required once. 2 is more practical; are there any other considerations which led you to the conclusion that 1 is better? Mykyta > > Barry > From barryleiba@gmail.com Wed Aug 31 09:27: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 A47F821F8CD7 for ; Wed, 31 Aug 2011 09:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.026 X-Spam-Level: X-Spam-Status: No, score=-103.026 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BDvJMD-KHY9 for ; Wed, 31 Aug 2011 09:27:35 -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 0B19F21F8CD2 for ; Wed, 31 Aug 2011 09:27:34 -0700 (PDT) Received: by gxk19 with SMTP id 19so853159gxk.31 for ; Wed, 31 Aug 2011 09:29: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=/GYCXQKO92HDg2W2ggDJUbeJX5Acgt88+YXf3ltBpkE=; b=mxQvHNxpdNiDttEnRFbnMyoWzeMsePBvhmzoce/UzDZPLkjmE8gICKSGSnks6IJnsj jrlOlNziIBOBXZ9DHodjeAjHBfyCaUOIqf/Wz4VwpT/Z754IN4nizdug9fONXTeMfZr+ 3qMKjWBiak+3hqSWwoKO9LStkJiUgG62VHUp0= MIME-Version: 1.0 Received: by 10.236.72.233 with SMTP id t69mr3278175yhd.55.1314808143980; Wed, 31 Aug 2011 09:29:03 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.208.35 with HTTP; Wed, 31 Aug 2011 09:29:03 -0700 (PDT) In-Reply-To: <4E5E5F22.4010407@gmail.com> References: <20110531062229.28776.82429.idtracker@ietfa.amsl.com> <0CE9268E-5802-4B0A-B643-F580E7F048B5@mnot.net> <4E5BB162.6010101@gmail.com> <4E5E47BB.3010403@gmail.com> <4E5E47FB.9050100@stpeter.im> <4E5E49A5.1020106@gmail.com> <4E5E5F22.4010407@gmail.com> Date: Wed, 31 Aug 2011 12:29:03 -0400 X-Google-Sender-Auth: wNevi9Kj2GsLx5t91VxsvgODyno Message-ID: From: Barry Leiba To: Mykyta Yevstifeyev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Mark Nottingham , apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-nottingham-http-browser-hints-02.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, 31 Aug 2011 16:27:35 -0000 >> A client that wants to use HTTPS, but isn't sure whether this part of >> the site supports it, can do it one of two ways: >> >> 1. Try HTTPS. =A0If it doesn't work, fall back to HTTP. >> >> 2. Use HTTP. =A0If a "hint" is included in the HTTP response that says >> HTTPS is OK, then switch to HTTP. >> >> You're proposing 2. =A0Is that right? >> >> Assuming that's right, I'm saying that 1 is better. > > You're right. =A0But: a client needs to do 1 for each time it tries to ac= cess > something whereas 2 would only be required once. =A02 is more practical; = are > there any other considerations which led you to the conclusion that 1 is > better? 2 is not more practical. Very few (probably no) web sites will have HTTPS enabled or disabled item by item. In reality, clients will try HTTPS, it will work, and it will continue to work for most or all of what they're doing at that site. When it fails, they'll fall back to HTTP and continue using it for the section of the site for which HTTPS failed. On the other hand, method 2 requires that they try to figure out when they can safely use the hint they were given before. When, exactly, is it that they cross over into another part of the site, which might not support HTTPS? If they get it wrong, they wind up with method 1 anyway. Apart from that, method 1 ensures that if they can use HTTPS, the entire client session (that is, all interactions between the client and the site in question) is protected by TLS. With method 2, the initial communication is in the open, unprotected, and the client has to switch to protection after getting the hint. That creates a window for snooping. Also, a MitM attacker can remove the HTTPS hints, preventing the client from ever even trying SSL. This looks like a bad solution in search of a problem. Barry From ietfc@btconnect.com Wed Aug 31 10:11: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 A4D3021F8A56 for ; Wed, 31 Aug 2011 10:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6s5bLu+eZSJ for ; Wed, 31 Aug 2011 10:11:17 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by ietfa.amsl.com (Postfix) with ESMTP id 335C321F8A66 for ; Wed, 31 Aug 2011 10:11:16 -0700 (PDT) Received: from host109-153-79-81.range109-153.btcentralplus.com (HELO pc6) ([109.153.79.81]) by c2beaomr06.btconnect.com with SMTP id EJQ77229; Wed, 31 Aug 2011 18:12:35 +0100 (BST) Message-ID: <008301cc67f8$43bb4b00$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Barry Leiba" , , References: <004001cc6736$d4baab40$4001a8c0@gateway.2wire.net> Date: Wed, 31 Aug 2011 18:08:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E5E6B80.0092, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.8.31.154815:17:7.586, ip=109.153.79.81, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, __INT_PROD_COMP, BODY_SIZE_1900_1999, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4E5E6B83.0128,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: Apps Discuss Subject: Re: [apps-discuss] New appsawg documents 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, 31 Aug 2011 17:11:18 -0000 ----- Original Message ----- From: "Barry Leiba" To: "t.petch" Cc: "Apps Discuss" Sent: Tuesday, August 30, 2011 8:17 PM > >> At least two of these seem to be progressing nicely without any > >> adoption by appsawg, so adopting them seems to be a way of making > >> work. > > I'll add that it's the goal of AppsAWG to help the process, not to > make extra work and hinder things. Without it, the document editors > have to make sure the document gets sufficient review, convince an > Area Director to sponsor it, and deal with a four-week IETF last call. > With it, the working group is here to review the document, and the > document shepherd (one of the chairs or someone we assign) will assess > the quality of review, we already have approval from the Area > Directors to go ahead, and there's a two-week last call when we send > it up. > > If the WG is putting undue extra process in the way, we're doing > something wrong, and that's something we should discuss. Let's start > by seeing how smoothly a few more documents go (the first two went > well, I think). Barry, Peter, Murray, Thank you for the explanation. This is sort of my concern, that it makes appsawg sound a bit like a factory for churning out RFC as cheaply as possible, like some far eastern manufacturer of cotton clothing. I want the process of producing an RFC to be challenging, to demonstrate that there is support for this as an RFC and that there has been adequate review. Asking for approval for seven I-Ds in three days does limit the likely review, and indeed, I see that one I-D has already progressed before even those three days are up, but I am not suggesting you extend it. Rather, I shall think again, perhaps at IETF Last Call, about the process and how it has served us. Tom Petch > > Barry From alexey.melnikov@isode.com Wed Aug 31 10:14: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 D999C21F85B5 for ; Wed, 31 Aug 2011 10:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJIgkYPLWVFJ for ; Wed, 31 Aug 2011 10:14:41 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 15A4221F8AF6 for ; Wed, 31 Aug 2011 10:14:41 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 31 Aug 2011 18:16:10 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4E5E6C61.1030503@isode.com> Date: Wed, 31 Aug 2011 18:16:17 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: "t.petch" References: <004001cc6736$d4baab40$4001a8c0@gateway.2wire.net> <008301cc67f8$43bb4b00$4001a8c0@gateway.2wire.net> In-Reply-To: <008301cc67f8$43bb4b00$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] New appsawg documents 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, 31 Aug 2011 17:14:42 -0000 Hi Tom, t.petch wrote: >I want the process of producing an RFC to be challenging, to demonstrate >that there is support for this as an RFC and that there has been adequate >review. Asking for approval for seven I-Ds in three days does limit the >likely review, and indeed, I see that one I-D has already progressed >before even those three days are up, but I am not suggesting you extend it. >Rather, I shall think again, perhaps at IETF Last Call, about the process >and how it has served us. > > The bar for accepting documents as WG documents should be lower than the bar for saying that they are ready for IESG review. Rest assured that APPSAWG chairs are not going to initiate 7 WGLC at the very same moment. From barryleiba@gmail.com Wed Aug 31 10: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 403A721F8DD2 for ; Wed, 31 Aug 2011 10:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.026 X-Spam-Level: X-Spam-Status: No, score=-103.026 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InKvqC2im8wx for ; Wed, 31 Aug 2011 10:25:49 -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 9961221F8DCD for ; Wed, 31 Aug 2011 10:25:49 -0700 (PDT) Received: by yie12 with SMTP id 12so947026yie.31 for ; Wed, 31 Aug 2011 10:27:19 -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=Ufcjv+CbGAC76aIBeBb48Kr7VOH9wrOmTnwbDl1Bevs=; b=s1M/FH9vnn4a4dUkMnlfnkH5aM1G2uvPk78Nfj2AnlYDjO+LBOZm+bCY4volRi04Qo cnkpkL4czsl9H3vslC/po9ch1Pg0l21tEIvqrydqq45EWdvmgvPcOsdD3KA02QJ11u5M WXFytDSQBbv8aSeb/X39AvbEk9qPnN2oab4AI= MIME-Version: 1.0 Received: by 10.236.72.233 with SMTP id t69mr3672517yhd.55.1314811639374; Wed, 31 Aug 2011 10:27:19 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.208.35 with HTTP; Wed, 31 Aug 2011 10:27:19 -0700 (PDT) In-Reply-To: <008301cc67f8$43bb4b00$4001a8c0@gateway.2wire.net> References: <004001cc6736$d4baab40$4001a8c0@gateway.2wire.net> <008301cc67f8$43bb4b00$4001a8c0@gateway.2wire.net> Date: Wed, 31 Aug 2011 13:27:19 -0400 X-Google-Sender-Auth: btXBvlNW17dZ5hQYsM5hPpj034A Message-ID: From: Barry Leiba To: "t.petch" Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps Discuss Subject: Re: [apps-discuss] New appsawg documents 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, 31 Aug 2011 17:25:50 -0000 > I want the process of producing an RFC to be challenging, to demonstrate > that there is support for this as an RFC and that there has been adequate > review. Asking for approval for seven I-Ds in three days does limit the > likely review, and indeed, I see that one I-D has already progressed > before even those three days are up, but I am not suggesting you extend it. Maybe you misunderstand the note that started this. No one has asked for approval for *any* documents. We've asked to hear objections to having the working group *process* the documents. They still all have to get review and go through the same process they would have gone through as individual submissions -- but with *more* oversight and attention. How do you think that will cheapen the process? We're also not handling seven at the same time. My note said that we'd focus on three first, and each of those will progress at its own pace. And be assured that any documents that have insufficient review and support will not make it to the ADs. That some have already "progressed" just means that we've given them working-group names. If the working group decides not to handle any document, either by explicit decision or by neglect and lack of support, that document can still fail. Further, most of these documents have already had significant review, comment, and discussion, some on this list and some elsewhere. I'd really prefer to see effort put into discussion of the documents, rather than into meta-discussion of the working group. If, in the end, someone thinks that a document either got a "free pass" by being handled by the working group, or got mired in process that it would have avoided as an individual submission, we'd all like to hear about it then. If it turns out that this working group isn't helping to do things right, we can and will shut it down. Barry