From johnl@iecc.com Thu Sep 1 07:29: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 4947C21F9B7C for ; Thu, 1 Sep 2011 07:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.117 X-Spam-Level: X-Spam-Status: No, score=-111.117 tagged_above=-999 required=5 tests=[AWL=0.082, 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 Xc8Eg+Vsoaxx for ; Thu, 1 Sep 2011 07:29:55 -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 A44E921F9B57 for ; Thu, 1 Sep 2011 07:29:54 -0700 (PDT) Received: (qmail 69348 invoked from network); 1 Sep 2011 14:31:27 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 1 Sep 2011 14:31:27 -0000 Received: (qmail 31155 invoked from network); 1 Sep 2011 14:31:27 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 1 Sep 2011 14:31:27 -0000 Date: 1 Sep 2011 14:31:04 -0000 Message-ID: <20110901143104.11470.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] 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: Thu, 01 Sep 2011 14:29:56 -0000 Assuming we all agree that the rule requiring multipart/report at the top level of a DSN goes in in other places, it looks fine to me. R's, John From raphael.bossek@googlemail.com Thu Sep 1 06:24:42 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A59F21F9B7D for ; Thu, 1 Sep 2011 06:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.977 X-Spam-Level: X-Spam-Status: No, score=-4.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, 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 DPmQ8v1E3yCY for ; Thu, 1 Sep 2011 06:24:41 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0373E21F9B7B for ; Thu, 1 Sep 2011 06:24:40 -0700 (PDT) Received: by vxi29 with SMTP id 29so1617600vxi.31 for ; Thu, 01 Sep 2011 06:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=i1m5iQcAsWjypQyXoGIPYmRrr7dLDu3NzgtRgQvGeok=; b=fHzo/gFBeUkutjGg2DVetLp8U0+eAvYmQVC93wwiMlaKbtRnMC+o4N89CQrRFA3r7L 194gc2TrefMobNV83Q44OExYaOuuTE99d2MNw3K9iTI5HCS3TAk6kG/VkplPgkLYzymc 0tGYgBN0jLisxNZj6cOt0Dtu2c4tle7m6a5Ig= MIME-Version: 1.0 Received: by 10.52.24.129 with SMTP id u1mr240881vdf.175.1314883573756; Thu, 01 Sep 2011 06:26:13 -0700 (PDT) Received: by 10.220.180.129 with HTTP; Thu, 1 Sep 2011 06:26:13 -0700 (PDT) Date: Thu, 1 Sep 2011 15:26:13 +0200 Message-ID: From: Raphael Bossek To: apps-discuss@ietf.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Thu, 01 Sep 2011 08:52:05 -0700 Subject: [apps-discuss] RFC3023: Is note about HTTP Accept header wrong X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2011 13:25:53 -0000 Need your help, Study the RFC 3023 found the following note that seams to be incorrect for me. Here the note at page 17 (http://tools.ietf.org/html/rfc3023#page-17): NOTE: Section 14.1 of HTTP[RFC2616] does not support Accept headers of the form "Accept: */*+xml" and so this header MUST NOT be used in this way. In RFC 2616 section 14.1 Accept at page 100 (http://tools.ietf.org/html/rfc2616#section-14.1) the BNF says: Accept = "Accept" ":" #( media-range [ accept-params ] ) media-range = ( "*/*" | ( type "/" "*" ) | ( type "/" subtype ) ) *( ";" parameter ) accept-params = ";" "q" "=" qvalue *( accept-extension ) accept-extension = ";" token [ "=" ( token | quoted-string ) ] Let us focus on the definition of `subtype` in section 3.7 Media types (http://tools.ietf.org/html/rfc2616#section-3.7): media-type = type "/" subtype *( ";" parameter ) type = token subtype = token We have now to find the definition of `token` in section 2.2 Basic rules at page 17 (http://tools.ietf.org/html/rfc2616#page-17): token = 1* separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT CTL and seperator does not define a + (plus) char too. In other word + (plus) is allowed. Please refer to section 2.2 Basic rules at page 17 (http://tools.ietf.org/html/rfc2616#page-16): OCTET = CHAR = UPALPHA = LOALPHA = ALPHA = UPALPHA | LOALPHA DIGIT = CTL = CR = LF = SP = HT = <"> = Where is my mistake? Raphael From derhoermi@gmx.net Thu Sep 1 09:02: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 EC01921F986C for ; Thu, 1 Sep 2011 09:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=-0.689, 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 LUHEUHjC+2md for ; Thu, 1 Sep 2011 09:02:21 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id C81EF21F972C for ; Thu, 1 Sep 2011 09:02:20 -0700 (PDT) Received: (qmail invoked by alias); 01 Sep 2011 16:03:53 -0000 Received: from dslb-094-223-186-089.pools.arcor-ip.net (EHLO HIVE) [94.223.186.89] by mail.gmx.net (mp054) with SMTP; 01 Sep 2011 18:03:53 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19pQRIqnIRpQez0RQ//1Iy6IfBz8SEBBCSUOgxMVR kNXzyiwchwe2qp From: Bjoern Hoehrmann To: Raphael Bossek Date: Thu, 01 Sep 2011 18:03:54 +0200 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] RFC3023: Is note about HTTP Accept header wrong X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2011 16:02:22 -0000 * Raphael Bossek wrote: >Study the RFC 3023 found the following note that seams to be incorrect >for me. Here the note at page 17 >(http://tools.ietf.org/html/rfc3023#page-17): > >NOTE: Section 14.1 of HTTP[RFC2616] does not support Accept >headers of the form "Accept: */*+xml" and so this header MUST NOT >be used in this way. >Where is my mistake? The assumption is that the second `*` above would be treated as a wild- card rather than as part of the type name. That is not the case with RFC 2616, so `*+xml` refers to one subtype and not many. -- 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 msk@cloudmark.com Thu Sep 1 10:54:59 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B8221F9625 for ; Thu, 1 Sep 2011 10:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.022 X-Spam-Level: X-Spam-Status: No, score=-103.022 tagged_above=-999 required=5 tests=[AWL=-0.423, 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 PKf35x19a0GT for ; Thu, 1 Sep 2011 10:54:59 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id E4BA121F9621 for ; Thu, 1 Sep 2011 10:54:58 -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, 1 Sep 2011 10:56:31 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Thu, 1 Sep 2011 10:56:29 -0700 Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.txt Thread-Index: Acxos9b2mOInydVyT/CEXxoRNFZNvgAHIarw Message-ID: References: <20110901143104.11470.qmail@joyce.lan> In-Reply-To: <20110901143104.11470.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: Thu, 01 Sep 2011 17:54:59 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQHRhdWdoLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAwMSwgMjAxMSA3 OjMxIEFNDQo+IFRvOiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcNCj4gQ2M6IE11cnJheSBTLiBLdWNo ZXJhd3kNCj4gU3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3NdIEktRCBBY3Rpb246IGRyYWZ0LWll dGYtYXBwc2F3Zy1yZmMzNDYyYmlzLTAwLnR4dA0KPiANCj4gQXNzdW1pbmcgd2UgYWxsIGFncmVl IHRoYXQgdGhlIHJ1bGUgcmVxdWlyaW5nIG11bHRpcGFydC9yZXBvcnQgYXQNCj4gdGhlIHRvcCBs ZXZlbCBvZiBhIERTTiBnb2VzIGluIGluIG90aGVyIHBsYWNlcywgaXQgbG9va3MgZmluZSB0byBt ZS4NCg0KUmlnaHQsIGFuZCBJIHRoaW5rIFRvbnkgc2FpZCBoZSdkIGNyYWNrIG9wZW4gRFNOIGFu ZCBORE4gaWYgdGhleSBuZWVkZWQgdG8gYmUgdXBkYXRlZCB0byByZWZsZWN0IHRoaXMuICAoQnV0 IHRoZW4gSSBzZWVtIHRvIHJlY2FsbCBsb29raW5nIGF0IHRoZW0gYW5kLCB0byBteSBzdXJwcmlz ZSwgZmluZGluZyB0aGF0IHRoZXkgYWxyZWFkeSBzYWlkIHdoYXQncyBuZWVkZWQuKQ0K From ietfc@btconnect.com Thu Sep 1 11: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 CF37D21F989D for ; Thu, 1 Sep 2011 11:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 gaQMWtlZUa9c for ; Thu, 1 Sep 2011 11:38:48 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by ietfa.amsl.com (Postfix) with ESMTP id CFF1621F989A for ; Thu, 1 Sep 2011 11:38:47 -0700 (PDT) Received: from host109-153-79-81.range109-153.btcentralplus.com (HELO pc6) ([109.153.79.81]) by c2beaomr08.btconnect.com with SMTP id EDM73753; Thu, 01 Sep 2011 19:40:11 +0100 (BST) Message-ID: <01f501cc68cd$aab0ce40$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Barry Leiba" References: <004001cc6736$d4baab40$4001a8c0@gateway.2wire.net><008301cc67f8$43bb4b00$4001a8c0@gateway.2wire.net> Date: Thu, 1 Sep 2011 19:36:18 +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.4E5FD18B.0025, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.9.1.175115:17:7.944, ip=109.153.79.81, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __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, 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, MULTIPLE_RCPTS X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4E5FD18B.018F,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: Thu, 01 Sep 2011 18:38:48 -0000 ----- Original Message ----- From: "Barry Leiba" To: "t.petch" Cc: ; ; "Apps Discuss" Sent: Wednesday, August 31, 2011 7:27 PM > > 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? Yes I understand your note perfectly; giving the WG three days to express an opinion on the adoption by the WG of 7 I-Ds is not exactly a lot of oversight. And as you say, making them WG I-Ds reduces the work of the AD and chairs. But you need to know that there will be WG members willing to step up and review instead and that may or may not happen. I have seen in other WGs a determined author push an I-D through as a WG item to RFC and have been left thinking that it never really got reviewed. So, as I said, I will watch with interest how much review these get. (So far, I haven't exactly seen many people saying 'yes, good idea - or even any idea) Tom Petch > > 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 From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Thu Sep 1 12:44: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 09D5A21F96AB for ; Thu, 1 Sep 2011 12:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.929 X-Spam-Level: X-Spam-Status: No, score=-102.929 tagged_above=-999 required=5 tests=[AWL=0.170, 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 iz+0zxizd9Xt for ; Thu, 1 Sep 2011 12:44:23 -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 71A8221F96A8 for ; Thu, 1 Sep 2011 12:44:23 -0700 (PDT) Received: by pzk33 with SMTP id 33so6112024pzk.18 for ; Thu, 01 Sep 2011 12:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=AvoA4MZKABhGuHgCcwppPQ/0BblklNy5NqIoaKTwvr0=; b=Y/q7mE0VLq6DMaa+qAPOyWBf/1c/fkIyaBZEPrSTUc2YuOAHDv67JJkTfxo3ezez5g ZY4XxlwroScDftTv11EcUmBiamF0E1ANKLFG+xPZPGVO89CdWem57oJ4Bf7gp2J1KBgU KLTu+RCUsVosXGfBsbfGoO0bd+1+VxfMVPbak= Received: by 10.68.28.167 with SMTP id c7mr547082pbh.358.1314906357071; Thu, 01 Sep 2011 12:45:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.98.5 with HTTP; Thu, 1 Sep 2011 12:45:17 -0700 (PDT) In-Reply-To: References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> From: Frank Ellermann Date: Thu, 1 Sep 2011 21:45:17 +0200 Message-ID: To: Barry Leiba 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: Thu, 01 Sep 2011 19:44:24 -0000 On 30 August 2011 20:52, Barry Leiba wrote: > For convenience, a link to the document is here: > =A0 http://tools.ietf.org/html/draft-ietf-appsawg-rfc3462bis Thanks. IMO the announce bot should be updated to offer this popular link in addition to the official link. What would it take to arrange this? > Let's see if we can make that date by getting reviews in now. Editorial nit section 2: s/BCP 14/RFC 2119/, a new BCP 14 could be different, and RFC 2119 suggests to write RFC 2119. I like the original "content-type" better than the perfectly correct "media type", because it indicates the Content-Type header field. The draft follows the philosophy that any "may" (etc.) MUST be either upgraded to MAY or replaced by "might" (or similar). While I consider this line of thinking as patent nonsense, in this draft the outcome is fine. Because I don't believe in this odd philosophy I won't tell you where I saw a surviving lower case "should" ;-) Maybe s/return path/return-path/ in the last paragraph of section 3. This could also go to a new "i18n considerations" with a pointer to the EAI work: The assumption that at least the header is 7-bit clean is not more strictly true. EAI is out of scope, but nevertheless the 7-bit header assumption is now far less clear than in 2003. Section 4: s/this memo/rfcxxxx/ I forgot the xml2rfc magic word for "this RFC", but if "this memo" ends up literally in an IANA registry it makes no sense. I do not trust that the RFC editor or the IANA get such subtle details right. Ditto in section 3. Section 4 encoding: Do you really want "mail headers" here, or should this be "mail header fields"? Please replace "the header contains all header fields" by "the header consists of header fields", and add a reference to [MAIL] (RFC 5322) section 3.5. Notably "the first blank line" does not always terminate the header, if readers think that "blank" includes WSP* CRLF. It's a terminology question, maybe s/blank/empty/ would be clearer. References: Nothing in [OLD-REPORT] is normative, because the draft will replace and obsolete it. In [OLD-REPORT] [DSN] and [DRPT] were normative, I fail to see why these references are demoted: Please move both [DSN-FORMAT] and [DSN-SMTP] back to normative. Please add a section explaining the differences from RFC 3462 intended to be kept in the full Internet Standard. I guess that the existing document history is not intended to be kept, Please add the required "downref" warning for all references on standards track, same idea as for YAM 4409bis. And please inform the document shepherd that a publication as Internet Standard is hereby "requested", or something :-) -Frank From msk@cloudmark.com Thu Sep 1 14:50: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 E514821F989A for ; Thu, 1 Sep 2011 14:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.017 X-Spam-Level: X-Spam-Status: No, score=-103.017 tagged_above=-999 required=5 tests=[AWL=-0.418, 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 3YUTkz9aJcae for ; Thu, 1 Sep 2011 14:50:23 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 5985821F988C for ; Thu, 1 Sep 2011 14:50: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; Thu, 1 Sep 2011 14:51:57 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Thu, 1 Sep 2011 14:51:55 -0700 Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.txt Thread-Index: Acxo38iAus/UrIE2RTiaJOdy1E+twQAD/5WA Message-ID: References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] 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: Thu, 01 Sep 2011 21:50:24 -0000 Hi Frank, > -----Original Message----- > From: Frank Ellermann [mailto:hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com] > Sent: Thursday, September 01, 2011 12:45 PM > To: Barry Leiba > Cc: Murray S. Kucherawy; apps-discuss@ietf.org > Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.= txt >=20 > Editorial nit section 2: s/BCP 14/RFC 2119/, a new BCP 14 > could be different, and RFC 2119 suggests to write RFC 2119. The RFC Editor will update the references if they change between now and wh= en this actually gets published. This is pretty standard boilerplate. > The draft follows the philosophy that any "may" (etc.) MUST > be either upgraded to MAY or replaced by "might" (or similar). > While I consider this line of thinking as patent nonsense, in > this draft the outcome is fine. Because I don't believe in > this odd philosophy I won't tell you where I saw a surviving > lower case "should" ;-) There are two, actually. I changed one to "needs to" and left the other. > Maybe s/return path/return-path/ in the last paragraph of > section 3. This could also go to a new "i18n considerations" > with a pointer to the EAI work: The assumption that at least > the header is 7-bit clean is not more strictly true. EAI is > out of scope, but nevertheless the 7-bit header assumption is > now far less clear than in 2003. I'm not really sure we need to say more than what's already there. This te= xt looks fine with or without EAI being applied. Does anyone else with goo= d EAI fu have a comment here? > Section 4: s/this memo/rfcxxxx/ I forgot the xml2rfc magic > word for "this RFC", but if "this memo" ends up literally in > an IANA registry it makes no sense. I do not trust that the > RFC editor or the IANA get such subtle details right. Ditto > in section 3. The RFC Editor typically makes that change during the run-up to AUTH48. I'= ve used both the [RFCXXXX] and [this memo] notation before, so I'll change = it to the latter. > Section 4 encoding: Do you really want "mail headers" here, > or should this be "mail header fields"? I think it's correct as-is (and unchanged since RFC3462). > Please replace "the header contains all header fields" by > "the header consists of header fields", and add a reference > to [MAIL] (RFC 5322) section 3.5. Notably "the first blank > line" does not always terminate the header, if readers think > that "blank" includes WSP* CRLF. It's a terminology question, > maybe s/blank/empty/ would be clearer. This text is copied verbatim from RFC3462 and there's been no complaint tha= t this is unclear and no errata posted. What do others think? > References: Nothing in [OLD-REPORT] is normative, because the > draft will replace and obsolete it. In [OLD-REPORT] [DSN] and > [DRPT] were normative, I fail to see why these references are > demoted: Please move both [DSN-FORMAT] and [DSN-SMTP] back to > normative. I disagree. You don't need to read and understand DSN-FORMAT and DSN-SMTP t= o implement this specification. Thus, they're not normative here. > Please add a section explaining the differences from RFC 3462 > intended to be kept in the full Internet Standard. I guess > that the existing document history is not intended to be kept, Such sections are typically deleted before publication anyway. The current Introduction section spells out the differences. Really, there= 's only one. > Please add the required "downref" warning for all references > on standards track, same idea as for YAM 4409bis. And please > inform the document shepherd that a publication as Internet > Standard is hereby "requested", or something :-) Such warnings typically go in the PROTO writeup, not in the document itself= , as I understand it. -MSK From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Thu Sep 1 16:48: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 ED30221F97A9 for ; Thu, 1 Sep 2011 16:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.942 X-Spam-Level: X-Spam-Status: No, score=-102.942 tagged_above=-999 required=5 tests=[AWL=0.157, 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 uOEw+v+hh8MC for ; Thu, 1 Sep 2011 16:48:24 -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 44E6321F97A8 for ; Thu, 1 Sep 2011 16:48:24 -0700 (PDT) Received: by pzk33 with SMTP id 33so6613382pzk.18 for ; Thu, 01 Sep 2011 16:49:56 -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=2ZOwVy3euh7K/Iaj9paEo5AedmdwTjwvIZvI6FKF+Kc=; b=MzkFjK5/tJVQfT0Rdvher5Atuz/v4iAOrL9MrbWDpePUW0dQ5X3CR/nb1GD8aSldVB 5IyA8DkSSUlweMUqdzTOx35o8dsa5Y6sW5d99MGtCWklNgMHaBbjW6CqgSxB9+7NS2PF h1kI1JUSUbfe+UWyvD2Hm+XMBYTPdGPCaUGgA= Received: by 10.68.22.7 with SMTP id z7mr923398pbe.492.1314920996085; Thu, 01 Sep 2011 16:49:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.98.5 with HTTP; Thu, 1 Sep 2011 16:49:16 -0700 (PDT) In-Reply-To: References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> From: Frank Ellermann Date: Fri, 2 Sep 2011 01:49:16 +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-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: Thu, 01 Sep 2011 23:48:25 -0000 On 1 September 2011 23:51, Murray S. Kucherawy wrote: Hi, [2119bis] >> Editorial nit section 2: s/BCP 14/RFC 2119/, a new BCP 14 >> could be different, and RFC 2119 suggests to write RFC 2119. > The RFC Editor will update the references if they change > between now and when this actually gets published. This is > pretty standard boilerplate. The problem isn't a new 2119bis published before 3462bis, but a new BCP 14 published after 3462bis with incompatible terms. The standard boilerplate (as specified in 2119) says "2119", and with a fresh existing 2119bis I-D all I can say is "there be dragons". If you like a fight with dragons it's okay, you have been warned. [i18n/EAI] > I'm not really sure we need to say more than what's already > there. =A0This text looks fine with or without EAI being applied. What's not more fine is its silent message header =3D US-ASCII assumption, and switching this paragraph into an i18n section with an informative EAI WG reference could help readers, who are not yet aware of it. I certainly don't insist on it, it's just what I would try to warn readers, and besides I like the BCP 18 (IETF charset policy) rule about "i18n considerations". [obs-FWS] >> Please replace "the header contains all header fields" by >> "the header consists of header fields", and add a reference >> to [MAIL] (RFC 5322) section 3.5. =A0Notably "the first blank >> line" does not always terminate the header, if readers think >> that "blank" includes WSP* CRLF. =A0It's a terminology question, >> maybe s/blank/empty/ would be clearer. > This text is copied verbatim from RFC3462 and there's been no > complaint that this is unclear and no errata posted. The "blank line" business is copied verbatim, and the issue is addressed in RFC 5234 and RFC 5322 among many others. Would "empty" be clearer than "blank"? I don't trust that my "DEnglish" means anything for others, but I'm sure about some issues discovered long after RFC 3462 was published. The "header contains all header fields" is not a verbatim copy, and it sounds odd, because it contains nothing else, but that could be again a bad case of "DEnglish" on my side. Whatever this paragraph tries to say, the real specification including warts such as and is in RFC 5322 section 3.5 (and more), and it is *not* as simple as RFC 3462 puts it. [Xref] > You don't need to read and understand DSN-FORMAT and DSN-SMTP > to implement this specification. =A0Thus, they're not normative > here. ACK, maybe RFC 3462 got this wrong when it replaced *all* old RFC 1892 "references" by new RFC 3462 "normative references" - the complete lack of "informative references" is suspicious. [diff] > The current Introduction section spells out the differences. >=A0Really, there's only one. ACK. And very necessary, for starters it must be possible to send an abusive multipart/report within a multipart/report. >> Please add the required "downref" warning for all references >> on standards track, same idea as for YAM 4409bis. =A0And please >> inform the document shepherd that a publication as Internet >> Standard is hereby "requested", or something :-) > Such warnings typically go in the PROTO writeup, not in the > document itself, as I understand it. NAK, there are two procedures, one old and horrible, and the new and painless RFC 4897 procedure. For an application of the new procedure compare: Otherwise I'd say next stop WG LC followed by PubReq, -Frank From msk@cloudmark.com Thu Sep 1 17:01: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 9BE7921F930A for ; Thu, 1 Sep 2011 17:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.515 X-Spam-Level: X-Spam-Status: No, score=-103.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 3CP+sKu2Lz6I for ; Thu, 1 Sep 2011 17:01:35 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id C4D6921F9306 for ; Thu, 1 Sep 2011 17:01:35 -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, 1 Sep 2011 17:03:04 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Thu, 1 Sep 2011 17:03:02 -0700 Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.txt Thread-Index: AcxpAd2Dcxyk8ySqSRu7ZDeO20JrOAAAJW9A Message-ID: References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] 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: Fri, 02 Sep 2011 00:01:36 -0000 > -----Original Message----- > From: Frank Ellermann [mailto:hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com] > Sent: Thursday, September 01, 2011 4:49 PM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.= txt >=20 > >> Editorial nit section 2: s/BCP 14/RFC 2119/, a new BCP 14 > >> could be different, and RFC 2119 suggests to write RFC 2119. >=20 > > The RFC Editor will update the references if they change > > between now and when this actually gets published. This is > > pretty standard boilerplate. >=20 > The problem isn't a new 2119bis published before 3462bis, but > a new BCP 14 published after 3462bis with incompatible terms. Ah, I see what you mean. I'll take that out. > The "header contains all header fields" is not a verbatim copy, RFC3462: The Text/RFC822-Headers body part should contain all the RFC822 header lines from the message which caused the report. The RFC822 headers include all lines prior to the blank line in the message. They include the MIME-Version and MIME Content-Headers. This one: The text/rfc822-headers body part SHOULD contain all the mail header fields from the message that caused the report. The header includes all header fields prior to the first blank line in the message. They include the MIME-Version and MIME content description fields. There's a slight update to use the current preferred language (header field= s instead of header lines, for example), but it's otherwise the same. The first paragraph of the same section makes a specific reference to RFC53= 22 (as "[MAIL]"). I'm happy to make a change if it actually clarifies something, but if there= isn't evidence that people are confused by the current text then I'd prefe= r to keep further text changes to a minimum. > NAK, there are two procedures, one old and horrible, and the new > and painless RFC 4897 procedure. For an application of the new > procedure compare: > I guess the co-chairs or the ADs should weigh in on which of these they pre= fer. -MSK From healthyao@gmail.com Thu Sep 1 18:57: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 05C6521F956B for ; Thu, 1 Sep 2011 18:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 fekw-mst8B5K for ; Thu, 1 Sep 2011 18:57:24 -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 79CB421F956A for ; Thu, 1 Sep 2011 18:57:24 -0700 (PDT) Received: by pzk33 with SMTP id 33so6885816pzk.18 for ; Thu, 01 Sep 2011 18:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=FmTUizq7+NsAL8uBkcQfAWcWSeuBMVgtbSibmP1I6eI=; b=gFn5JusJ984yE/eEdVytvawkHvTzztdC7SL0Z/aC+q7ASTHvdPPA9BeEBj+KkqQSWq +gel8uXPpM9r6um2j0CCLJjR2lYT9LHUW1kMTD7c6j8fRrkCwnFLWAJ65i7/c0O0c9Ly MUtaHfdzm0HbOe1l0pOcWpdDfIr2B+dN9EpHc= Received: by 10.68.10.161 with SMTP id j1mr1071618pbb.276.1314928739037; Thu, 01 Sep 2011 18:58:59 -0700 (PDT) Received: from LENOVO47E041CF ([218.241.103.28]) by mx.google.com with ESMTPS id z1sm6683081pbz.6.2011.09.01.18.58.53 (version=SSLv3 cipher=OTHER); Thu, 01 Sep 2011 18:58:56 -0700 (PDT) Message-ID: <3C2EE9073EBD464F86DE4610F7C576EB@LENOVO47E041CF> From: "Jiankang Yao" To: "t.petch" , "Barry Leiba" , , References: <004001cc6736$d4baab40$4001a8c0@gateway.2wire.net> <514810775.01672@cnnic.cn> Date: Fri, 2 Sep 2011 09:58:50 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 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: Fri, 02 Sep 2011 01:57:25 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogInQucGV0Y2giIDxpZXRmY0Bi dGNvbm5lY3QuY29tPg0KVG86ICJCYXJyeSBMZWliYSIgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3Jn PjsgPHN0cGV0ZXJAc3RwZXRlci5pbT47IDxtc2tAY2xvdWRtYXJrLmNvbT4NCkNjOiAiQXBwcyBE aXNjdXNzIiA8YXBwcy1kaXNjdXNzQGlldGYub3JnPg0KU2VudDogVGh1cnNkYXksIFNlcHRlbWJl ciAwMSwgMjAxMSAxMjowOCBBTQ0KU3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3NdIE5ldyBhcHBz YXdnIGRvY3VtZW50cw0KDQoNCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCj4gRnJv bTogIkJhcnJ5IExlaWJhIiA8YmFycnlsZWliYUBjb21wdXRlci5vcmc+DQo+IFRvOiAidC5wZXRj aCIgPGlldGZjQGJ0Y29ubmVjdC5jb20+DQo+IENjOiAiQXBwcyBEaXNjdXNzIiA8YXBwcy1kaXNj dXNzQGlldGYub3JnPg0KPiBTZW50OiBUdWVzZGF5LCBBdWd1c3QgMzAsIDIwMTEgODoxNyBQTQ0K PiANCj4+ID4+IEF0IGxlYXN0IHR3byBvZiB0aGVzZSBzZWVtIHRvIGJlIHByb2dyZXNzaW5nIG5p Y2VseSB3aXRob3V0IGFueQ0KPj4gPj4gYWRvcHRpb24gYnkgYXBwc2F3Zywgc28gYWRvcHRpbmcg dGhlbSBzZWVtcyB0byBiZSBhIHdheSBvZiBtYWtpbmcNCj4+ID4+IHdvcmsuDQo+PiANCj4+IEkn bGwgYWRkIHRoYXQgaXQncyB0aGUgZ29hbCBvZiBBcHBzQVdHIHRvIGhlbHAgdGhlIHByb2Nlc3Ms IG5vdCB0bw0KPj4gbWFrZSBleHRyYSB3b3JrIGFuZCBoaW5kZXIgdGhpbmdzLiAgV2l0aG91dCBp dCwgdGhlIGRvY3VtZW50IGVkaXRvcnMNCj4+IGhhdmUgdG8gbWFrZSBzdXJlIHRoZSBkb2N1bWVu dCBnZXRzIHN1ZmZpY2llbnQgcmV2aWV3LCBjb252aW5jZSBhbg0KPj4gQXJlYSBEaXJlY3RvciB0 byBzcG9uc29yIGl0LCBhbmQgZGVhbCB3aXRoIGEgZm91ci13ZWVrIElFVEYgbGFzdCBjYWxsLg0K Pj4gIFdpdGggaXQsIHRoZSB3b3JraW5nIGdyb3VwIGlzIGhlcmUgdG8gcmV2aWV3IHRoZSBkb2N1 bWVudCwgYW5kIHRoZQ0KPj4gZG9jdW1lbnQgc2hlcGhlcmQgKG9uZSBvZiB0aGUgY2hhaXJzIG9y IHNvbWVvbmUgd2UgYXNzaWduKSB3aWxsIGFzc2Vzcw0KPj4gdGhlIHF1YWxpdHkgb2YgcmV2aWV3 LCB3ZSBhbHJlYWR5IGhhdmUgYXBwcm92YWwgZnJvbSB0aGUgQXJlYQ0KPj4gRGlyZWN0b3JzIHRv IGdvIGFoZWFkLCBhbmQgdGhlcmUncyBhIHR3by13ZWVrIGxhc3QgY2FsbCB3aGVuIHdlIHNlbmQN Cj4+IGl0IHVwLg0KPj4gDQo+PiBJZiB0aGUgV0cgaXMgcHV0dGluZyB1bmR1ZSBleHRyYSBwcm9j ZXNzIGluIHRoZSB3YXksIHdlJ3JlIGRvaW5nDQo+PiBzb21ldGhpbmcgd3JvbmcsIGFuZCB0aGF0 J3Mgc29tZXRoaW5nIHdlIHNob3VsZCBkaXNjdXNzLiAgTGV0J3Mgc3RhcnQNCj4+IGJ5IHNlZWlu ZyBob3cgc21vb3RobHkgYSBmZXcgbW9yZSBkb2N1bWVudHMgZ28gKHRoZSBmaXJzdCB0d28gd2Vu dA0KPj4gd2VsbCwgSSB0aGluaykuDQo+IA0KPiBCYXJyeSwgUGV0ZXIsIE11cnJheSwNCj4gDQo+ IFRoYW5rIHlvdSBmb3IgdGhlIGV4cGxhbmF0aW9uLiAgVGhpcyBpcyBzb3J0IG9mIG15IGNvbmNl cm4sIHRoYXQgaXQgbWFrZXMNCj4gYXBwc2F3ZyBzb3VuZCBhIGJpdCBsaWtlIGEgZmFjdG9yeSBm b3IgY2h1cm5pbmcgb3V0IFJGQyBhcyBjaGVhcGx5IGFzIHBvc3NpYmxlLA0KPiBsaWtlIHNvbWUg ZmFyIGVhc3Rlcm4gbWFudWZhY3R1cmVyIG9mIGNvdHRvbiBjbG90aGluZy4NCj4gSSB3YW50IHRo ZSBwcm9jZXNzIG9mIHByb2R1Y2luZyBhbiBSRkMgdG8gYmUgY2hhbGxlbmdpbmcsIHRvIGRlbW9u c3RyYXRlDQo+IHRoYXQgdGhlcmUgaXMgc3VwcG9ydCBmb3IgdGhpcyBhcyBhbiBSRkMgYW5kIHRo YXQgdGhlcmUgaGFzIGJlZW4gYWRlcXVhdGUNCj4gcmV2aWV3LiANCj4NCg0KWW91IG1pZ2h0IG1p eCB1cCB0aGUgZGVmaW5pdGlvbiBvZiBSRkMgYW5kIGRyYWZ0Lg0KVGhlIGRyYWZ0IGRvZXMgbm90 IG1lYW4gdGhhdCBpdCB3aWxsIGJlIGEgUkZDIGluIGZ1dHVyZS4NCk1hbnkgV0cgZHJhZnRzIGRp ZWQgZHVlIHRvIGxhY2sgb2YgV0cgY29uY2Vuc3VzIG9yIGludGVyZXN0cyBhZnRlciBiZWluZyBh IFdHIEktRC4NCkV2ZW4gaWYgdGhlc2Ugc2V2ZW4gSS1EcyBiZWNvbWUgV0cgSS1EIGFmdGVyIHRo ZSBXRyBhZ3JlZW1lbnRzLCBpdCBkb2VzIG5vdA0KbWVhbiB0aGF0IGFsbCBvZiB0aGVtIHdpbGwg YmVjb21lIFJGQ3MuIFNvbWUgb2YgdGhlbSBtYXkgZGllIGlmIGxhY2sgb2YgV0cgY29uc2Vuc3Vz IG9yIGludGVyZXN0cy4NCkFzIHBvaW50ZWQgb3V0IGJ5IEFsZXhleSwgIkFQUFNBV0cgY2hhaXJz IGFyZSBub3QgZ29pbmcgdG8gaW5pdGlhdGUgNyBXR0xDIGF0IHRoZSB2ZXJ5IHNhbWUgbW9tZW50 LiIuDQpXZSB3aWxsIHByb2Nlc3MgdGhlc2UgcG9zc2libGUgV0cgSS1EcyBvbmUgYnkgb25lIGJl Zm9yZSBzZW5kaW5nIHRvIElFU0cuDQpPbiB0aGUgb3RoZXIgaGFuZCwgaWYgdGhlIFdHIGFncmVl cyB0aGF0IGFsbCBvZiB0aGVzZSA3IGRyYWZ0cyBiZWNvbWUgdGhlIFdHIEktRHMsIGl0IHdpbGwg YXR0cmFjdCBtb3JlIHBlb3BsZSB0byBmb2N1cyBvbiB0aGVzZSB0b3BpY3MgYW5kIGdpdmUgdGhl bSBtb3JlIGV4dGVuc2l2ZSByZXZpZXdzLihJIGFzc3VtZSB0aGF0IFdHIHBhcnRpY2lwYW50cyBh cmUgbW9yZSBsaWtlbHkgdG8gZm9jdXMgb24gdGhlIFdHIEktRHMpLiBTbyBmcm9tIHRoaXMgcG9p bnQgb2Ygdmlldywgd2UgdHJ5IHRvIGF0dHJhY3QgbW9yZSBXRyBwYXJ0aWNpcGFudHMgdG8gZm9j dXMgb24gdGhlc2UgdG9waWNzIGFuZCBnaXZlIHRoZW0gbW9yZSByZXZpZXdzLg0KDQoNCg0KSmlh bmthbmcgWWFvDQo= From johnl@iecc.com Thu Sep 1 21:22: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 A3EB621F9374 for ; Thu, 1 Sep 2011 21:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.122 X-Spam-Level: X-Spam-Status: No, score=-111.122 tagged_above=-999 required=5 tests=[AWL=0.077, 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 nkTxOwLde-Rw for ; Thu, 1 Sep 2011 21:22:41 -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 E02D221F9369 for ; Thu, 1 Sep 2011 21:22:40 -0700 (PDT) Received: (qmail 76518 invoked from network); 2 Sep 2011 04:24:13 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 2 Sep 2011 04:24:13 -0000 Received: (qmail 16940 invoked from network); 2 Sep 2011 04:24:13 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Sep 2011 04:24:13 -0000 Date: 2 Sep 2011 04:23:50 -0000 Message-ID: <20110902042350.40513.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] 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: Fri, 02 Sep 2011 04:22:41 -0000 >> section 3. This could also go to a new "i18n considerations" >> with a pointer to the EAI work: The assumption that at least >> the header is 7-bit clean is not more strictly true. EAI is >> out of scope, but nevertheless the 7-bit header assumption is >> now far less clear than in 2003. > >I'm not really sure we need to say more than what's already there. >This text looks fine with or without EAI being applied. Does anyone >else with good EAI fu have a comment here? The EAI group has this reasonably well under control. There's a draft that updates the DSN spec, and adds new EAI mime types message/global, message/global-headers, message/global-delivery-status, and message/global-disposition-notification. See draft-ietf-eai-rfc5337bis-dsn-03.txt Note that EAI no longer is making any attempt to be backward compatible to systems that can't handle 8BITMIME, so you don't have to worry about it. Dunno what the schedule is for the DSN draft, since it hasn't gotten much attention lately. Tony Hansen is the primary author so you can ask him if you're wondering. R's, John From msk@cloudmark.com Fri Sep 2 13:24: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 4784921F8CC6 for ; Fri, 2 Sep 2011 13:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.512 X-Spam-Level: X-Spam-Status: No, score=-103.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 EO7w+NwWosWZ for ; Fri, 2 Sep 2011 13:24:00 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id E0A1921F8CB8 for ; Fri, 2 Sep 2011 13:24:00 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 2 Sep 2011 13:25:37 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Fri, 2 Sep 2011 13:25:36 -0700 Thread-Topic: draft-ietf-appsawg-rfc3462bis: PS or DS? Thread-Index: AcxmzCLQt7ErtqSfR3G31kkH06ZYSAC4dqPw 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: [apps-discuss] draft-ietf-appsawg-rfc3462bis: PS or DS? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Sep 2011 20:24:01 -0000 RFC3462 is currently DS. There's some question as to whether or not this r= evision qualifies to remain at DS, or forces a recycle at PS. The only material change is the removal of a constraint. On the face of it= , it would seem that this doesn't disqualify it from remaining at DS. In a= ddition, Ned has said that many implementations ignore the constraint, so i= t's harmless to remove it. (Ned, could you elucidate on this in support o= f one position or the other?) On the other hand, absent specific data about whether or not this change mi= ght break anything, it might be more correct to do a turn back at PS until = we get some feedback (or, perhaps, the absence of it). So, this is a point we need to discuss. Discussion? -MSK From barryleiba.mailing.lists@gmail.com Fri Sep 2 13:34: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 C0E8D21F8D3A for ; Fri, 2 Sep 2011 13:34:38 -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.047, 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 pYBWwrQ5+g+O for ; Fri, 2 Sep 2011 13:34:38 -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 3D74221F8D32 for ; Fri, 2 Sep 2011 13:34:38 -0700 (PDT) Received: by gxk19 with SMTP id 19so2967543gxk.31 for ; Fri, 02 Sep 2011 13:36: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 :content-transfer-encoding; bh=iWHoHmiur3R5QApo8WTAdqZJKz63eQFfkuCDZx1FgwU=; b=KF6XzeCVtAYLv3QbRVp28C7m7KmHKq/MdcUQYDUPeadNTAuLsENFBValNeZbK6QmGG MOVZbdLBSs1QXHuXrUzy0IOufkqmSYCnF2j/3aYexAQ3GPoOVWY8zCyTrlkIZhjsrVeh GR0r8E4fJH2PpJ0I029V/sA52fmQwByoqTEGo= MIME-Version: 1.0 Received: by 10.236.75.165 with SMTP id z25mr7962198yhd.68.1314995772767; Fri, 02 Sep 2011 13:36:12 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.40.6 with HTTP; Fri, 2 Sep 2011 13:36:12 -0700 (PDT) In-Reply-To: References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> Date: Fri, 2 Sep 2011 16:36:12 -0400 X-Google-Sender-Auth: d_G7-_V2kBa_paAgaCODOs9kytM 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] draft-ietf-appsawg-rfc3462bis: PS or DS? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Sep 2011 20:34:38 -0000 > RFC3462 is currently DS. =A0There's some question as to whether or not > this revision qualifies to remain at DS, or forces a recycle at PS. Chair comment: The decision about the ultimate status of the document will be made by the IESG, but input from the working group is important. I'd like to hear from people either way: if you think this change is acceptable to make in a Draft Standard document, please say; if you think this change requires us to move the document back to Proposed Standard, please say. If you think we can't decide this without more discussion, testing, research, or whatever, please say that as well, and specify what you think needs to be done. Barry, document shepherd From ned.freed@mrochek.com Fri Sep 2 14:12: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 56ECF21F8D4E for ; Fri, 2 Sep 2011 14:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 gWoV9bERyWty for ; Fri, 2 Sep 2011 14:12:32 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9F27921F8D2C for ; Fri, 2 Sep 2011 14:12:31 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O5KWP7SN9C014HBH@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 2 Sep 2011 14:12:42 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O5KW9P7F8W00RCTX@mauve.mrochek.com>; Fri, 2 Sep 2011 14:12:38 -0700 (PDT) Message-id: <01O5KWP5WPAU00RCTX@mauve.mrochek.com> Date: Fri, 02 Sep 2011 14:01:10 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 02 Sep 2011 13:25:36 -0700" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> To: "Murray S. Kucherawy" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1314997982; bh=GE8m9pHTGutaa46N5ykknT0+Yse66U13scPpbfNQV5E=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=tDjGRUfidpH3OISnf1VccfdX4fAlvGah106OVDA4rbdK6wsB/u5zV940vEWGSfknY i5/qs+cUeqZe3wZx3zZMl1XbGXTKLUSLmXORbJNsyp3fwM+vNsEYl5FsruHLIQZfe2 EhLBs4BG6bxE+uGx48CqiVCVg2T06jBwZ+8o7iKo= Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-rfc3462bis: PS or DS? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Sep 2011 21:12:33 -0000 > RFC3462 is currently DS. There's some question as to whether or not this > revision qualifies to remain at DS, or forces a recycle at PS. Why not try for recycle at DS and see what the IESG says? > The only material change is the removal of a constraint. On the face of it, > it would seem that this doesn't disqualify it from remaining at DS. In general that's not true - removal of a constraint that would affect implementations generating the format in some way is something I would see as requiring a reset to proposed. But since this doesn't affect the associated direct uses of multipart/report - the constraint is not removed for them - it's difficult to argue that this has any effect on the usage described in original DSN/MDN specifications. It does affect new uses of multipart/report for other purposes, but that's fine. > In addition, Ned has said that many implementations ignore the constraint, so > it's harmless to remove it. (Ned, could you elucidate on this in support of > one position or the other?) AFAIK in practice nobody ever tried to prevent *indirect* uses of multipart/report in places other than top-level, e.g., no MUA I'm aware of will, when incorporating a DSN/MDN as part of a forwarded message, digest, or whatever, change the media type to avoid violating this constraint, it seems that implementations have already had to deal with it and haven't had any problems. But really, I don't see why we should wring our hands over this. Let's make the change and ask for a recycle at draft, possibly asking for small exception in order to relax the constraint without a reset. Make sure this is mentioned in the last call - let's please not repeat *that* mistake. And if there are no objections and the IESG goes along, fine, and if not, it gets reset to proposed and we advance it without republising in exactly six months. I mean, it's not like we have to do the interop thing over again in this case. > On the other hand, absent specific data about whether or not this change > might break anything, it might be more correct to do a turn back at PS until we > get some feedback (or, perhaps, the absence of it). Why not let the powers-that-be make this call? That's why they get the big bucks ;-) Ned From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Fri Sep 2 15:33:32 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4369E21F8DFD for ; Fri, 2 Sep 2011 15:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.039 X-Spam-Level: X-Spam-Status: No, score=-103.039 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H96ppHKOgwjN for ; Fri, 2 Sep 2011 15:33:31 -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 B040421F8DFC for ; Fri, 2 Sep 2011 15:33:31 -0700 (PDT) Received: by gwb20 with SMTP id 20so2431894gwb.31 for ; Fri, 02 Sep 2011 15:35:08 -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=LWI/Iv1aGk4mcaaDBNBC+eSTDGa8fgNJCd3FM9hHDBU=; b=WcfCrfcfHbTtWKuIPv4mAj6pIaeqda8ASSX+yVg0KObO6FJ5A239zv6ck6HNYAnDCh Cd5eGlqnfeBGM00L1XWpGjjWnOxaYNxgflaAID5kv7IHlj4ciOsQQVW7ujfEnjT0gaR9 c/cw+eLW7F6zf+BHKETAi8VREXOIams2/yi4E= Received: by 10.68.34.34 with SMTP id w2mr2774419pbi.291.1315002908088; Fri, 02 Sep 2011 15:35:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.98.5 with HTTP; Fri, 2 Sep 2011 15:34:27 -0700 (PDT) In-Reply-To: References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> From: Frank Ellermann Date: Sat, 3 Sep 2011 00:34:27 +0200 Message-ID: To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-rfc3462bis: PS or DS? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Sep 2011 22:33:32 -0000 On 2 September 2011 22:36, Barry Leiba wrote: > The decision about the ultimate status of the document will be > made by the IESG, but input from the working group is important. The draft should be in a form allowing them to pick STD. IMO the decision can be only PS (incompatible change) or STD (some minor resctriction removed). What would be a plausible reason for DS ? -Frank From ned.freed@mrochek.com Fri Sep 2 16:34: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 42DD221F8DA1 for ; Fri, 2 Sep 2011 16:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 iu53fCaE74Rt for ; Fri, 2 Sep 2011 16:34:12 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9F62E21F8D6C for ; Fri, 2 Sep 2011 16:34:12 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O5L1MXYWU8012ARN@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 2 Sep 2011 16:34:25 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O5L0EHBOKG00RCTX@mauve.mrochek.com>; Fri, 2 Sep 2011 16:34:20 -0700 (PDT) Message-id: <01O5L1MUPLD200RCTX@mauve.mrochek.com> Date: Fri, 02 Sep 2011 16:31:04 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 03 Sep 2011 00:34:27 +0200" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> To: Frank Ellermann DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1315006486; bh=TrFTImCzdZipjTr0AdY7gRP+zxMuaQV878M12eUKrCo=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=CWhZ7X1QtLMZqR8YeVr6A3zIP76nblhPIwMPG81KV0NKFzpcNbF/Op5QtmD3mqsOg WkogTG/ahkaKsyfXRmhL0xSqQBx5Hq1gKqaIvigzD3kvAK/Cs49VWooFq0+JNmNml5 Jx+I70l1iGMrrm93SGeeyToPUx0BZ7amqCS75YOE= Cc: Barry Leiba , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-rfc3462bis: PS or DS? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Sep 2011 23:34:13 -0000 > On 2 September 2011 22:36, Barry Leiba wrote: > > The decision about the ultimate status of the document will be > > made by the IESG, but input from the working group is important. > The draft should be in a form allowing them to pick STD. IMO the > decision can be only PS (incompatible change) or STD (some minor > resctriction removed). What would be a plausible reason for DS ? AFAICT the argument to move to full standard has not been made, and I for one am a bit uncomfortable with removing a restriction during such a move. Remember: draft is about interoperability, where a case can be made that this change is harmless, full is about deployment, and that's harder to justify. So I don't really support a move to full, and a recycle at proposed seems unnecessary. Ergo, recycle at draft. Ned From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Fri Sep 2 17:10: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 9A90D21F8DDF for ; Fri, 2 Sep 2011 17:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.951 X-Spam-Level: X-Spam-Status: No, score=-102.951 tagged_above=-999 required=5 tests=[AWL=0.148, 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 uXvHResZ1Dpp for ; Fri, 2 Sep 2011 17:10: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 0738A21F8DDE for ; Fri, 2 Sep 2011 17:10:34 -0700 (PDT) Received: by pzk33 with SMTP id 33so10768951pzk.18 for ; Fri, 02 Sep 2011 17:12:12 -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=dTZ5AxIXCJJm5NMxPusqvwACkziwIJFGsuJ4h3i8l/Q=; b=n9SBN5wVIQIkJnLVmlgb/Gsww3BHgLZAslCHAcAlUsotu77V9nHrlVLJlXet1I75xC RCf6WUg7baoaZsKSOaCw8l/MxtkPI0vpWc5D3b/ZOUwbbFev4FTV6fJehDJoDJWIPl0E 8loiT7AjBVEX7ihTzHnH/2INnvwaguQykxsqU= Received: by 10.68.28.167 with SMTP id c7mr2610614pbh.358.1315008732118; Fri, 02 Sep 2011 17:12:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.98.5 with HTTP; Fri, 2 Sep 2011 17:11:32 -0700 (PDT) In-Reply-To: <01O5L1MUPLD200RCTX@mauve.mrochek.com> References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> <01O5L1MUPLD200RCTX@mauve.mrochek.com> From: Frank Ellermann Date: Sat, 3 Sep 2011 02:11:32 +0200 Message-ID: To: Ned Freed Content-Type: text/plain; charset=ISO-8859-1 Cc: Barry Leiba , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-rfc3462bis: PS or DS? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2011 00:10:35 -0000 On 3 September 2011 01:31, Ned Freed wrote: > AFAICT the argument to move to full standard has not been made Well, I tried some days ago. The interoperability reports for DS are rather old, but at least they do not mention "multipart/report not at the top level" issues: > full is about deployment, and that's harder to justify. If all these "significant" and "successful" in RFC 2026 4.1.3 are to be interpreted as "e.g., 4409bis", then I'd have no idea how to demonstrate a similar significance or success of RFC 3462... ...for 4409bis I could at least produce "significant" amounts of messages posted by me, or the "successful" publication of a BCP formerly known as draft-hutzler-spamops. Maybe you don't like "three steps" because you interpret RFC 2026 4.1.3 more strictly. I consider the "third step" as last chance to fix errata and polish a good DS before it's seriously time to start something new and better at PS (e.g., 282?, 532?, 532?bis). -Frank From ned.freed@mrochek.com Fri Sep 2 18:25: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 C14BF21F8CFD for ; Fri, 2 Sep 2011 18:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 kmcKJqr1lsMt for ; Fri, 2 Sep 2011 18:25:22 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 102AD21F8CE4 for ; Fri, 2 Sep 2011 18:25:22 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O5L5IS0YF40169C2@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 2 Sep 2011 18:25:36 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O5L0EHBOKG00RCTX@mauve.mrochek.com>; Fri, 2 Sep 2011 18:25:30 -0700 (PDT) Message-id: <01O5L5IOKV9Y00RCTX@mauve.mrochek.com> Date: Fri, 02 Sep 2011 18:20:58 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 03 Sep 2011 02:11:32 +0200" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> <01O5L1MUPLD200RCTX@mauve.mrochek.com> To: Frank Ellermann DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1315013156; bh=knHX1ZTWxAPsOGETHgb+h1QVrdm6SI6fW+fb2COWqwI=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=GrBejtKSyzG9qfh7Ie64dYVhxx60F8LJaZz3hklXEKkgEz1CQ1VEy6eQJIpNZax78 Ve7PiiUMYziUyrWFkkFMLnMOd7YMb7o+/GjriRvCizsE75g+MWT7kJmwgmYcm87l1F OAtyn9H41GuQgLEug5QFg637xZXzv8uCCOvzZaXE= Cc: Barry Leiba , Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-rfc3462bis: PS or DS? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2011 01:25:22 -0000 > On 3 September 2011 01:31, Ned Freed wrote: > > AFAICT the argument to move to full standard has not been made > Well, I tried some days ago. The interoperability reports for DS > are rather old, but at least they do not mention "multipart/report > not at the top level" issues: > > > full is about deployment, and that's harder to justify. > If all these "significant" and "successful" in RFC 2026 4.1.3 are > to be interpreted as "e.g., 4409bis", then I'd have no idea how > to demonstrate a similar significance or success of RFC 3462... > ...for 4409bis I could at least produce "significant" amounts of > messages posted by me, or the "successful" publication of a BCP > formerly known as draft-hutzler-spamops. > Maybe you don't like "three steps" because you interpret RFC 2026 > 4.1.3 more strictly. I consider the "third step" as last chance > to fix errata and polish a good DS before it's seriously time to > start something new and better at PS (e.g., 282?, 532?, 532?bis). Frank, I honestly don't have a clue what you're driving at in any of this. I was directly asked to give my opinion about whether a recycle at proposed or at draft made more sense for this document and I responded. That's it. All this stuff about moving to full standard seems to have come entirely from left field, so unless some others step up and say they support attempting such a move - which given the recent 4409bis experience I'd say has less than snowball's chance in hell of being successful - I really don't see any point in continuing this discussion. Ned From barryleiba@gmail.com Sat Sep 3 05:42: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 2845121F8B2E for ; Sat, 3 Sep 2011 05:42:29 -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.047, 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 qBmENriOAAjb for ; Sat, 3 Sep 2011 05:42:28 -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 975D421F8B28 for ; Sat, 3 Sep 2011 05:42:28 -0700 (PDT) Received: by gyf3 with SMTP id 3so3055710gyf.31 for ; Sat, 03 Sep 2011 05:44: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; bh=fWkXaXTS9hMTG/psr0cazyNhN+ckbh7qUU9b5tREl9c=; b=xEvF2N8YzHHZwMH4z3tw5ywZ1yz6dKNfJaX54ZQkLc0pOLjugu/SXxQJ7v7VjrOLPr KUkkB48K4uzYXk8YFaIokDAbMKW73jK/sJKM9TJkSYYIu9x0P0U93qM2ihBPmjKFoGow cFk57e8NogXzhCJMxYm1e/VPn4cC2u1sZbwa8= MIME-Version: 1.0 Received: by 10.236.89.70 with SMTP id b46mr10398294yhf.38.1315053847044; Sat, 03 Sep 2011 05:44:07 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.208.35 with HTTP; Sat, 3 Sep 2011 05:44:06 -0700 (PDT) In-Reply-To: <01O5L5IOKV9Y00RCTX@mauve.mrochek.com> References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> <01O5L1MUPLD200RCTX@mauve.mrochek.com> <01O5L5IOKV9Y00RCTX@mauve.mrochek.com> Date: Sat, 3 Sep 2011 08:44:06 -0400 X-Google-Sender-Auth: UOVaVb3kIzhcHelJ3opHhU0aF-Q Message-ID: From: Barry Leiba To: Ned Freed Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-rfc3462bis: PS or DS? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2011 12:42:29 -0000 > All this stuff about moving to full standard seems to have come entirely from > left field, so unless some others step up and say they support attempting such > a move - which given the recent 4409bis experience I'd say has less than > snowball's chance in hell of being successful - I really don't see any point in > continuing this discussion. I agree. If we hear a bunch of other opinions that say we should use this as an opportunity to advance 3462 to full Standard, I will consider putting it to the IESG that way. Otherwise, the goal is to revise 3462 in place, as Draft Standard. So let's continue: reviews, comments, and responses to the question of whether 3462bis has to go back to PS or not. Barry, document shepherd From alexey.melnikov@isode.com Sun Sep 4 13:02: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 D5DB921F8596 for ; Sun, 4 Sep 2011 13:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPUv7xa8O8Iy for ; Sun, 4 Sep 2011 13:02:08 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 0331B21F857D for ; Sun, 4 Sep 2011 13:02:08 -0700 (PDT) Received: from [192.168.20.2] ((unknown) [212.183.140.54]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 4 Sep 2011 21:03:47 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4E63CBF2.8080207@isode.com> Date: Sun, 04 Sep 2011 20:05:22 +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: Ned Freed References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> <01O5KWP5WPAU00RCTX@mauve.mrochek.com> In-Reply-To: <01O5KWP5WPAU00RCTX@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-rfc3462bis: PS or DS? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Sep 2011 20:02:08 -0000 Ned Freed wrote: >>RFC3462 is currently DS. There's some question as to whether or not this >>revision qualifies to remain at DS, or forces a recycle at PS. >> >> > >Why not try for recycle at DS and see what the IESG says? > > For such a small issue I don't see much problems with recycling at DS, especially if there is evidence that the restriction being removed is not obeyed in non DSN contexts. >>The only material change is the removal of a constraint. On the face of it, >>it would seem that this doesn't disqualify it from remaining at DS. >> > >In general that's not true - removal of a constraint that would affect >implementations generating the format in some way is something I would >see as requiring a reset to proposed. > >But since this doesn't affect the associated direct uses of multipart/report - >the constraint is not removed for them - it's difficult to argue that this has >any effect on the usage described in original DSN/MDN specifications. It does >affect new uses of multipart/report for other purposes, but that's fine. > > > >>In addition, Ned has said that many implementations ignore the constraint, so >>it's harmless to remove it. (Ned, could you elucidate on this in support of >>one position or the other?) >> > >AFAIK in practice nobody ever tried to prevent *indirect* uses of >multipart/report in places other than top-level, e.g., no MUA I'm aware of >will, when incorporating a DSN/MDN as part of a forwarded message, digest, or >whatever, change the media type to avoid violating this constraint, it seems >that implementations have already had to deal with it and haven't had any >problems. > >But really, I don't see why we should wring our hands over this. Let's make the >change and ask for a recycle at draft, possibly asking for small exception in >order to relax the constraint without a reset. Make sure this is mentioned in >the last call - let's please not repeat *that* mistake. > Good point. >And if there are no >objections and the IESG goes along, fine, and if not, it gets reset to proposed >and we advance it without republising in exactly six months. I mean, it's not >like we have to do the interop thing over again in this case. > From dhc@dcrocker.net Mon Sep 5 06:11:27 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E127421F851A for ; Mon, 5 Sep 2011 06:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.419 X-Spam-Level: X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 wUxLRG1HK6jS for ; Mon, 5 Sep 2011 06:11:23 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C19AE21F8B42 for ; Mon, 5 Sep 2011 06:11:23 -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 p85DD23u021378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Sep 2011 06:13:07 -0700 Message-ID: <4E64CAD5.9010108@dcrocker.net> Date: Mon, 05 Sep 2011 06:12:53 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> <01O5KWP5WPAU00RCTX@mauve.mrochek.com> In-Reply-To: <01O5KWP5WPAU00RCTX@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]); Mon, 05 Sep 2011 06:13:08 -0700 (PDT) Subject: Re: [apps-discuss] draft-ietf-appsawg-rfc3462bis: PS or DS? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 13:11:28 -0000 On 9/2/2011 2:01 PM, Ned Freed wrote: >> The only material change is the removal of a constraint. On the face of it, >> > it would seem that this doesn't disqualify it from remaining at DS. > In general that's not true - removal of a constraint that would affect > implementations generating the format in some way is something I would > see as requiring a reset to proposed. It might not be obvious why merely removing a restriction should be considered that risky. An example that comes to mind is having a specification that calls for use of ASCII and then removing the 'restriction' on using the 8th bit, to permit support for UTF-8. That would certainly kill interoperability between UTF-8 senders and ASCII (legacy) receivers. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ned.freed@mrochek.com Mon Sep 5 13:49: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 3178A21F8AE6 for ; Mon, 5 Sep 2011 13:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 ylfjAO-skAbd for ; Mon, 5 Sep 2011 13:49:12 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6689721F8ABE for ; Mon, 5 Sep 2011 13:49:12 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O5P2RHNKXS01402I@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 5 Sep 2011 13:49:30 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O5KP14T1K0014O5Z@mauve.mrochek.com>; Mon, 5 Sep 2011 13:49:26 -0700 (PDT) Message-id: <01O5P2RFLHN8014O5Z@mauve.mrochek.com> Date: Mon, 05 Sep 2011 13:10:16 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 22 Aug 2011 13:08:02 +1000" <923B73A9-B10B-48AB-A6BA-147D76D7073A@mnot.net> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <923B73A9-B10B-48AB-A6BA-147D76D7073A@mnot.net> To: Mark Nottingham DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1315255784; bh=8JKuYqGtQ42nwsiEp8AWp7OqI2E2x444fZk5aXMPV30=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=HTWFLAbnLmkwHWc/1Z/VjrsV8Awq2q5+lXuDgvNqkyVsWVtRn9cn4pox+KChF4Zax jVfBN2U0l9AlikjzJCxgGA1FttjLEIgJa7uZPW4h8or0JFqXn3GJ205KIIG3DLD53F 6+NRrHlht7SUn3Bz9RDhB3jIdlh+e4oi3EbCk4CM= Cc: John C Klensin , Ned Freed , Apps Discuss Subject: Re: [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, 05 Sep 2011 20:49:13 -0000 First of all, there's a serious structural error in the present draft - sections 4 and 5 have gotten merged because of a misplaced . If you look at the draft's predecessor, RFC 4288, you'll see what I mean. I believe many if not most of your comments here are a result of this error on my part, for which I apologize. I'm going to post a revised draft that corrects this error immediately. In addition to the problems you note below, this also messes up the structured syntax suffix additions, which are supposed to be in a separat top-level section. > Overall, it seems like there's a fair amount of restatement between section 4 > and those that precede it. Not really seeing it - could you be ore specific? > 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. Section 4 is supposed to lay out the specific requirements in various areas for media types. It is in no way, shape, or form intended to provide a step-by-step instruction list for registering things, and I think it would be a HUGE mistake to change it into something like this. Extensive past experience has shown that attempting to instantiate requirements via a step by step fashion is enormously confusing when something new and slightly different comes along. > Furthermore, section 4 isn't clear about the step-by-step procedure that's > appropriate to various cases. That's hardly surprising since section 4 was in no way intended to provide such a checklist. And I am strongly opposed to trying to turn it into such a checklist. Section 5, OTOH, could benefit from more structuring as step by step lists, and it has been the plan all along to do that. But before that happens there has to be agremeent about what the steps are - especially for standards tree registrations. This is the major open issue in the draft that we really need to be talking about - in particular, whether or not the IESG remains "in the loop", and if they are to be moved out, how far out. It seems pointless for me to try and construct text for this when the most basic aspects of the process are still up in the air. > 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. 4.12.2 in particular is impossible to nail down without clarification of the IESG's role. I agree, however, that the present text is completely inadequate. > 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. I strongly disagree with this approach. The correct thing to be doing IMO is to leave (the proper) section 4 mostly alone and focus on fixing (the proper) section 5. As for how to do that, I think having separate itemized lists for vnd./prs. and for standards trees makes the most sense. Attempting to do them both at once and calling out exceptions between the two processes is just too confusing. I also think that we need to stop pretending it's necessary or even all that helpful to take vnd. and prs. to the ietf-types list prior to registering. Almost nobody does that and it doesn't seem to cause any significant difficulties. And OTOH, just suggesting you're really supposed to get feedback from a mailing list is a big disincentive for a process that really doesn't amount to anything but filling out a web form. So in the vnd./prs. case list review should at most be mentioned as a "need help? here's where to go!" sort of thing. The use of mailing list review in standards tree registrations also needs to be reviewed, but I confess to a certain ambivalence as to exactly how it should be done. > 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). Again, I think most of the issues here are the result of my structural fuckup. Again, sorry about that. Ned From mnot@mnot.net Mon Sep 5 17:17:46 2011 Return-Path: X-Original-To: apps-discuss@ietfc.amsl.com Delivered-To: apps-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6F6AB1B60B00 for ; Mon, 5 Sep 2011 17:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.062 X-Spam-Level: X-Spam-Status: No, score=-105.062 tagged_above=-999 required=5 tests=[AWL=-1.463, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZgKCy-yFger for ; Mon, 5 Sep 2011 17:17:45 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfc.amsl.com (Postfix) with ESMTP id 8B8BC1B60AFC for ; Mon, 5 Sep 2011 17:17:42 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id 304482FDC21 for ; Mon, 5 Sep 2011 18:45:19 -0400 (EDT) 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 C4ED822E257; Mon, 5 Sep 2011 18:44:42 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <01O5P2RFLHN8014O5Z@mauve.mrochek.com> Date: Tue, 6 Sep 2011 08:44:39 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <141FBDEA-D364-4373-87E3-17ED9985FF40@mnot.net> References: <923B73A9-B10B-48AB-A6BA-147D76D7073A@mnot.net> <01O5P2RFLHN8014O5Z@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1244.3) Cc: John C Klensin , Apps Discuss Subject: Re: [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: Tue, 06 Sep 2011 00:17:46 -0000 Thanks, Ned. I'll wait for the revised draft. On 06/09/2011, at 6:10 AM, Ned Freed wrote: > First of all, there's a serious structural error in the present draft = -=20 > sections 4 and 5 have gotten merged because of a misplaced . = If you > look at the draft's predecessor, RFC 4288, you'll see what I mean. >=20 > I believe many if not most of your comments here are a result of this = error on > my part, for which I apologize. I'm going to post a revised draft that = corrects > this error immediately. >=20 > In addition to the problems you note below, this also messes up the = structured > syntax suffix additions, which are supposed to be in a separat = top-level > section. >=20 >> Overall, it seems like there's a fair amount of restatement between = section 4 >> and those that precede it. >=20 > Not really seeing it - could you be ore specific? >=20 >> 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. >=20 > Section 4 is supposed to lay out the specific requirements in various = areas for > media types. It is in no way, shape, or form intended to provide a = step-by-step > instruction list for registering things, and I think it would be a = HUGE mistake > to change it into something like this. >=20 > Extensive past experience has shown that attempting to instantiate = requirements > via a step by step fashion is enormously confusing when something new = and > slightly different comes along. >=20 >> Furthermore, section 4 isn't clear about the step-by-step procedure = that's >> appropriate to various cases. >=20 > That's hardly surprising since section 4 was in no way intended to = provide such > a checklist. And I am strongly opposed to trying to turn it into such = a > checklist. >=20 > Section 5, OTOH, could benefit from more structuring as step by step = lists, and > it has been the plan all along to do that. But before that happens = there has to > be agremeent about what the steps are - especially for standards tree > registrations. This is the major open issue in the draft that we = really need to > be talking about - in particular, whether or not the IESG remains "in = the > loop", and if they are to be moved out, how far out. >=20 > It seems pointless for me to try and construct text for this when the = most > basic aspects of the process are still up in the air. >=20 >> 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 > 4.12.2 in particular is impossible to nail down without clarification = of the > IESG's role. I agree, however, that the present text is completely = inadequate. >=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. >=20 > I strongly disagree with this approach. The correct thing to be doing = IMO is to > leave (the proper) section 4 mostly alone and focus on fixing (the = proper) > section 5. As for how to do that, I think having separate itemized = lists for > vnd./prs. and for standards trees makes the most sense. Attempting to = do them > both at once and calling out exceptions between the two processes is = just too > confusing. >=20 > I also think that we need to stop pretending it's necessary or even = all that > helpful to take vnd. and prs. to the ietf-types list prior to = registering. > Almost nobody does that and it doesn't seem to cause any significant > difficulties. And OTOH, just suggesting you're really supposed to get = feedback > from a mailing list is a big disincentive for a process that really = doesn't > amount to anything but filling out a web form. So in the vnd./prs. = case list > review should at most be mentioned as a "need help? here's where to = go!" sort > of thing. >=20 > The use of mailing list review in standards tree registrations also = needs to be > reviewed, but I confess to a certain ambivalence as to exactly how it = should be > done. >=20 >> 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. >=20 >> 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). >=20 > Again, I think most of the issues here are the result of my structural > fuckup. Again, sorry about that. >=20 > Ned -- Mark Nottingham http://www.mnot.net/ From barryleiba.mailing.lists@gmail.com Wed Sep 7 16:43: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 D116721F8D04 for ; Wed, 7 Sep 2011 16:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.84 X-Spam-Level: X-Spam-Status: No, score=-102.84 tagged_above=-999 required=5 tests=[AWL=0.137, 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 NqRWyQEkE3Qz for ; Wed, 7 Sep 2011 16:43:02 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACE521F8CFF for ; Wed, 7 Sep 2011 16:43:02 -0700 (PDT) Received: by gwb17 with SMTP id 17so266560gwb.15 for ; Wed, 07 Sep 2011 16:44:50 -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=2SmeXoV0SM9xB8+efIDMcvSBr/xqsP14pVX+FeLpGVQ=; b=hkX0xL51wczFi9qvIhwTD+dMutkoTxw6oHrPPk8IBFHk206WmiYRhgm1/x147KjwWv 1oZSQfmnQiCUuPNQjPlR5tuTuOrovTucFXRK3LZbEJE/ngGsOSpI4DW/dK697z37E/zY QkyUktJLAdZWAfXGHKKkpwWgx6xAGrKUbBL80= MIME-Version: 1.0 Received: by 10.236.75.165 with SMTP id z25mr39568yhd.68.1315439090567; Wed, 07 Sep 2011 16:44:50 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.83.8 with HTTP; Wed, 7 Sep 2011 16:44:50 -0700 (PDT) In-Reply-To: <20110907214310.19FE198C284@rfc-editor.org> References: <20110907214310.19FE198C284@rfc-editor.org> Date: Wed, 7 Sep 2011 19:44:50 -0400 X-Google-Sender-Auth: 95GkbY4Fq-v19-dqEnJyiYr3p5Q Message-ID: From: Barry Leiba To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] BCP 166, RFC 6365 on Terminology Used in Internationalization in the IETF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2011 23:43:02 -0000 > A new Request for Comments is now available in online RFC libraries. > > =A0 =A0 =A0 =A0BCP 166 > =A0 =A0 =A0 =A0RFC 6365 > > =A0 =A0 =A0 =A0Title: =A0 =A0 =A0Terminology Used in Internationalization= in > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the IETF > =A0 =A0 =A0 =A0Author: =A0 =A0 P. Hoffman, J. Klensin > =A0 =A0 =A0 =A0Status: =A0 =A0 Best Current Practice This is appsawg's first RFC (5892bis is still in the RFC Editor queue). Bo= o-YA! Barry, appsawg chair From john-ietf@jck.com Wed Sep 7 18:06: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 F39E621F8D21 for ; Wed, 7 Sep 2011 18:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JObNYbMiMnyx for ; Wed, 7 Sep 2011 18:06:03 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 66DD921F8D1D for ; Wed, 7 Sep 2011 18:06:03 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1R1T5t-000D6G-SR; Wed, 07 Sep 2011 21:07:54 -0400 Date: Wed, 07 Sep 2011 21:07:53 -0400 From: John C Klensin To: Barry Leiba , apps-discuss@ietf.org Message-ID: <7EFE851DFE8E017623F50FCF@PST.JCK.COM> In-Reply-To: References: <20110907214310.19FE198C284@rfc-editor.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [apps-discuss] BCP 166, RFC 6365 on Terminology Used in Internationalization in the IETF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Sep 2011 01:06:04 -0000 --On Wednesday, September 07, 2011 19:44 -0400 Barry Leiba wrote: >> A new Request for Comments is now available in online RFC >> libraries. >>=20 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0BCP 166 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 6365 >>=20 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Title: =C2=A0 =C2=A0 = =C2=A0Terminology Used in >> Internationalization in =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the IETF >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Author: =C2=A0 =C2=A0 P. Hoffman, = J. Klensin >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Status: =C2=A0 =C2=A0 Best Current = Practice >=20 > This is appsawg's first RFC (5892bis is still in the RFC > Editor queue). Boo-YA! I'm happy to help with that distinction and am sure Paul is too although a lot of the credit goes to the RFC Editor, particularly Alice Hagens, for doing an outstanding job and doing it very quickly. 5892bis has been stuck in IANA hold (i.e., not either the WG's or the RFC Editor's fault)... I believe there has been another, independent, effort lately to un-stick it, but that may deserve a nudge from the IETF side too. john From barryleiba@gmail.com Wed Sep 7 18:23: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 B82D621F8D31 for ; Wed, 7 Sep 2011 18:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.021 X-Spam-Level: X-Spam-Status: No, score=-103.021 tagged_above=-999 required=5 tests=[AWL=-0.044, 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 QsVhi4Xz7r2D for ; Wed, 7 Sep 2011 18:23: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 A12A121F8D37 for ; Wed, 7 Sep 2011 18:23:05 -0700 (PDT) Received: by gyd12 with SMTP id 12so240224gyd.31 for ; Wed, 07 Sep 2011 18:24:56 -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=xuLLjp3cVXq5doEbk1N52GHWj8Jc5gx9/4HY5KKVkgg=; b=TQ4QW2czQKD0ebH0P34i+mxe8dCtPTlv6LwJKRjRF/wU9Qc+RlUWbbhuNbeCdZ96hc EChJ78wkFU7D/7YEMAIWvfSp+5GFhhhMiRT1f4JPSNwBSk3FzzjoNBs4eg/XxX+wLRj9 Y33xcawKyWSnkzpPQZMFaJ9t1HYGPCddLIpuU= MIME-Version: 1.0 Received: by 10.236.156.38 with SMTP id l26mr335636yhk.107.1315445096301; Wed, 07 Sep 2011 18:24:56 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.203.68 with HTTP; Wed, 7 Sep 2011 18:24:55 -0700 (PDT) In-Reply-To: <7EFE851DFE8E017623F50FCF@PST.JCK.COM> References: <20110907214310.19FE198C284@rfc-editor.org> <7EFE851DFE8E017623F50FCF@PST.JCK.COM> Date: Wed, 7 Sep 2011 21:24:55 -0400 X-Google-Sender-Auth: ktf5qF13WUcb8Gzk4F3guipOmHg Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] BCP 166, RFC 6365 on Terminology Used in Internationalization in the IETF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Sep 2011 01:23:06 -0000 > I'm happy to help with that distinction and am sure Paul is too > although a lot of the credit goes to the RFC Editor, > particularly Alice Hagens, for doing an outstanding job and > doing it very quickly. Indeed; as doc shepherd, I've been following the interaction. John and Paul were very responsive, and Alice has been her usual excellent, professional self. When it all works this way, it's a beautiful thing. > 5892bis has been stuck in IANA hold (i.e., not either the WG's > or the RFC Editor's fault)... I believe there has been another, > independent, effort lately to un-stick it, but that may deserve > a nudge from the IETF side too. Thanks for pointing that out to me; I'll check with Michelle. Barry From sm@elandsys.com Wed Sep 7 22:25: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 DA41321F8BCB for ; Wed, 7 Sep 2011 22:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.608 X-Spam-Level: X-Spam-Status: No, score=-102.608 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, OBSCURED_EMAIL=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 u1W06JvqRz+U for ; Wed, 7 Sep 2011 22:25:03 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 38B5421F8B7D for ; Wed, 7 Sep 2011 22:25:03 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.82]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p885QfEm024929; Wed, 7 Sep 2011 22:26:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1315459608; bh=XeYUuLpW25CvWMQKbTE5xMTaF6s=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=a3YmigeSskclMKccAHcBtdnzIF+pd8BnIbp204rak3zb5FQwSsWNsZpujnLiNu3o5 CdhEosY1kABwFdSbeZG2CH/SBdfN35E0QAQ2Mr10Tk//Vz518YDzK6zK1T9/+5xTNr 8iDPus5tZcMtXbnI8jZMsxxqYBDWAKgvhtXVdsTc= Message-Id: <6.2.5.6.2.20110907222503.06662248@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 07 Sep 2011 22:26:50 -0700 To: "Vijay K. Gurbani" From: S Moonesamy In-Reply-To: <4E67EFE5.3030109@bell-labs.com> References: <4E67EFE5.3030109@bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Apps-area review of draft-ietf-p2psip-base-18 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Sep 2011 05:25:06 -0000 Hi Vijay, Thanks for the review. I am forwarding it to the apps-discuss mailing list. Regards, S. Moonesamy At 15:27 07-09-2011, Vijay K. Gurbani 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-p2psip-base-18 >Title: REsource LOcation And Discovery (RELOAD) Base Protocol >Reviewer: Vijay K. Gurbani >Review Date: Sep-7-2011 >IETF Last Call Date: Not known >IESG Telechat Date: Sep-8-2011 > >Summary: This draft is ready for publication as a Proposed Standard. > >Major Issues: None. > >Minor Issues: 1. > >Nits: Few. > >Minor Issue: > >- In S3.6.1, you may want a forward reference to a later section where > the well-known server URL is used to fetch the configuration document. > >Nits: > >- S2, Terminology: Bootstrap node --- > s/help Nlocate/help locate/ > >- S2, Connection Table: At this point, "Attach" message > has not been described. Maybe a forward reference to S5.5.1 will > help. > >- S2, Destination List --- > s/A list of IDs/A list of Node-IDs/ > >- S9, bullet item towards the end of Page 104 --- > s/(>1000)/(>1000 peers)/ > >- S9.5, right before S9.6 starts --- > s/(n+2^(128-i)/(n+2^(128-i))/ > >Thanks, > >- vijay >-- >Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) >Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com >Web: http://ect.bell-labs.com/who/vkg/ From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Sep 7 23:51: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 8F0A321F8BBE for ; Wed, 7 Sep 2011 23:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.953 X-Spam-Level: X-Spam-Status: No, score=-102.953 tagged_above=-999 required=5 tests=[AWL=0.146, 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 FMY4YbLLetK3 for ; Wed, 7 Sep 2011 23:51:30 -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 ABE1F21F8B74 for ; Wed, 7 Sep 2011 23:51:30 -0700 (PDT) Received: by pzk33 with SMTP id 33so2689973pzk.18 for ; Wed, 07 Sep 2011 23:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Yu1YeVLsdaQkuRWQpDT0vtDZjYpvtEtIxtTidP/fLLc=; b=Z3htxQPOBVcZUiAQ+/As4u6j0cYjCb2y+PhwxoJCJ0amxDbWhnAXd/se8a/1eBIvNh Crqz4G0CA8xznt4fRWPzj2ge3n6oe7qp35vkl5gYvZMvS1x98tMkW4NqQiH/GjNLk1vK RSYP3eP3++AEmFtEGiAPJJEovYeSQp4WcSl+I= Received: by 10.68.33.106 with SMTP id q10mr603255pbi.180.1315464801121; Wed, 07 Sep 2011 23:53:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.101.15 with HTTP; Wed, 7 Sep 2011 23:52:41 -0700 (PDT) In-Reply-To: References: <20110907214310.19FE198C284@rfc-editor.org> <7EFE851DFE8E017623F50FCF@PST.JCK.COM> From: Frank Ellermann Date: Thu, 8 Sep 2011 08:52:41 +0200 Message-ID: To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] BCP 166, RFC 6365 on Terminology Used in Internationalization in the IETF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Sep 2011 06:51:31 -0000 On 8 September 2011 03:24, Barry Leiba wrote: >> 5892bis has been stuck in IANA hold (i.e., not either the WG's >> or the RFC Editor's fault)... I believe there has been another, >> independent, effort lately to un-stick it, but that may deserve >> a nudge from the IETF side too. > Thanks for pointing that out to me; I'll check with Michelle. Hi, I tried to figure out what that is about. Apparently 5892bis fixes three Unicode points in TUS 6.0 for the purposes of IDNA2008. The datatracker notes that "IANA will, in collaboration with its internal IDN team and IETF IDNA experts, update the derived property value registry according to RFC 5892 and property values as defined in The Unicode Standard version 6.0" is the affected IDNA Derived Properties registry, and apparently 5892bis only states that the rows 0CF1..0CF2 and 19D0..19DA will stay as they are when this registry will be updated for TUS 6.0. The relevant IETF IDNA expert is a coauthor of 5892bis. What is this "internal IDN team" -- I don't see why not changing two lines in a registry requires a team, do I miss something obvious? -Frank From john-ietf@jck.com Thu Sep 8 02:58: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 B237921F8B4E for ; Thu, 8 Sep 2011 02:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiHTfxoegHX4 for ; Thu, 8 Sep 2011 02:57:56 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 5681F21F8B3F for ; Thu, 8 Sep 2011 02:57:56 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1R1bOc-000JHv-4G; Thu, 08 Sep 2011 05:59:46 -0400 Date: Thu, 08 Sep 2011 05:59:45 -0400 From: John C Klensin To: Frank Ellermann , Barry Leiba Message-ID: In-Reply-To: References: <20110907214310.19FE198C284@rfc-editor.org> <7EFE851DFE8E017623F50FCF@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: apps-discuss@ietf.org Subject: [apps-discuss] Status of 5892bis and IANA (was: Re: BCP 166, RFC 6365 on Terminology Used in Internationalization in the IETF) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Sep 2011 09:58:00 -0000 --On Thursday, September 08, 2011 08:52 +0200 Frank Ellermann wrote: > On 8 September 2011 03:24, Barry Leiba wrote: > >>> 5892bis has been stuck in IANA hold (i.e., not either the >>> WG's or the RFC Editor's fault)... I believe there has been >>> another, independent, effort lately to un-stick it, but that >>> may deserve a nudge from the IETF side too. > >> Thanks for pointing that out to me; I'll check with Michelle. > > Hi, I tried to figure out what that is about. Apparently > 5892bis fixes three Unicode points in TUS 6.0 for the purposes > of IDNA2008. > > The datatracker notes that "IANA will, in collaboration with > its internal IDN team and IETF IDNA experts, update the > derived property value registry according to RFC 5892 and > property values as defined in The Unicode Standard version 6.0" > > .xml> is the affected IDNA Derived Properties registry, and > apparently 5892bis only states that the rows 0CF1..0CF2 and > 19D0..19DA will stay as they are when this registry will be > updated for TUS 6.0. > > The relevant IETF IDNA expert is a coauthor of 5892bis. What > is this "internal IDN team" -- I don't see why not changing > two lines in a registry requires a team, do I miss something > obvious? IANA is supposed to install and keep complete tables --corresponding roughly to the Stringprep one-- for IDNA character validity for each version of Unicode. These tables represent derived, precomputed, values, not the authoritative ones obtained by making the calculations called for in RFC 5892 and many new code points were added in 6.0, so there is considerably more than "not changing two lines in a registry So, indeed, you missed something obvious this time. best, john From evnikita2@gmail.com Thu Sep 8 07:33: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 6D5FD21F84F7 for ; Thu, 8 Sep 2011 07:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 K8GjvFNx0m8P for ; Thu, 8 Sep 2011 07:33:11 -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 A0F0121F8467 for ; Thu, 8 Sep 2011 07:33:11 -0700 (PDT) Received: by ewy19 with SMTP id 19so360174ewy.31 for ; Thu, 08 Sep 2011 07:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=3eXQxCYCcSmB64vmbHq3Wq0ZwYceaHOBUFOc+DMyHY8=; b=aPWSdNZU94EVcFd7Vk78l9af/fmE5ok47rMUWJSYNXQNtW+OnZfY0HSg/VxU5UTIUr rneZj9HbH/GdoOryZzOK7MgpDQt47lWjohCy8+0CtjoyUe0oPH4Gi23CsX14+Wmxgva0 NmwYKjh+h6+hC5tilUaNTxmwoogwE1JGLTDXk= Received: by 10.204.136.74 with SMTP id q10mr588156bkt.224.1315492503208; Thu, 08 Sep 2011 07:35:03 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id l11sm825281bkb.1.2011.09.08.07.35.01 (version=SSLv3 cipher=OTHER); Thu, 08 Sep 2011 07:35:01 -0700 (PDT) Message-ID: <4E68D2B6.30408@gmail.com> Date: Thu, 08 Sep 2011 17:35:34 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 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] draft-ietf-appsawg-rfc3462bis: PS or DS? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Sep 2011 14:33:12 -0000 Sorry for late response.. I actually think that removal of the requirement which is hardly useful should not be a constraint for advancing the document as Full Standard. If somebody feels that such constrain is useful, and it is really useful, then removing it requires recycling as PS. However, with a constructive change being done, this isn't a problem. Mykyta Yevstifeyev 02.09.2011 23:25, Murray S. Kucherawy wrote: > RFC3462 is currently DS. There's some question as to whether or not this revision qualifies to remain at DS, or forces a recycle at PS. > > The only material change is the removal of a constraint. On the face of it, it would seem that this doesn't disqualify it from remaining at DS. In addition, Ned has said that many implementations ignore the constraint, so it's harmless to remove it. (Ned, could you elucidate on this in support of one position or the other?) > > On the other hand, absent specific data about whether or not this change might break anything, it might be more correct to do a turn back at PS until we get some feedback (or, perhaps, the absence of it). > > So, this is a point we need to discuss. > > Discussion? > > -MSK > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From wwwrun@rfc-editor.org Wed Sep 7 14:41: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 2384F21F87FC; Wed, 7 Sep 2011 14:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, NO_RELAYS=-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 f1HIfd+asuHh; Wed, 7 Sep 2011 14:41:23 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8783021F8B84; Wed, 7 Sep 2011 14:41:19 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 19FE198C284; Wed, 7 Sep 2011 14:43:10 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110907214310.19FE198C284@rfc-editor.org> Date: Wed, 7 Sep 2011 14:43:10 -0700 (PDT) X-Mailman-Approved-At: Thu, 08 Sep 2011 08:02:43 -0700 Cc: apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] BCP 166, RFC 6365 on Terminology Used in Internationalization in the IETF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2011 21:41:24 -0000 A new Request for Comments is now available in online RFC libraries. BCP 166 RFC 6365 Title: Terminology Used in Internationalization in the IETF Author: P. Hoffman, J. Klensin Status: Best Current Practice Stream: IETF Date: September 2011 Mailbox: paul.hoffman@vpnc.org, john+ietf@jck.com Pages: 47 Characters: 103155 Obsoletes: RFC3536 See Also: BCP0166 I-D Tag: draft-ietf-appsawg-rfc3536bis-06.txt URL: http://www.rfc-editor.org/rfc/rfc6365.txt This document provides a list of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This memo documents an Internet Best Current Practice. This document is a product of the Applications Area Working Group Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From evnikita2@gmail.com Thu Sep 8 08:09:06 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9A721F8A7A for ; Thu, 8 Sep 2011 08:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 befDWRVJqlkM for ; Thu, 8 Sep 2011 08:09: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 A932B21F84B2 for ; Thu, 8 Sep 2011 08:09:04 -0700 (PDT) Received: by fxe6 with SMTP id 6so1750681fxe.31 for ; Thu, 08 Sep 2011 08:10:56 -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=EZ0NyLFYMt+5OYpXqxGEjkj8ddXc4Lyx+avMsb0U21I=; b=T8wOxSOIQ9FTNjdEaE/s50nZQ2M1gbLd6kA1xHBA9nhaABGJRzED9J8GsNeccfQKWr 0uApX4rXovAhFl4SVUaPyJaoFyOA4EsQ7H/OK2zIaEdBBm+Bp/8hdy77Od8kQP/6W9Hg ioY83G5NeIOdTbAj6UhnVLpAa440LNRkvux50= Received: by 10.223.22.15 with SMTP id l15mr535899fab.85.1315494656447; Thu, 08 Sep 2011 08:10:56 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id x22sm360460faa.5.2011.09.08.08.10.54 (version=SSLv3 cipher=OTHER); Thu, 08 Sep 2011 08:10:55 -0700 (PDT) Message-ID: <4E68DB1E.6090007@gmail.com> Date: Thu, 08 Sep 2011 18:11:26 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> In-Reply-To: <20110830041853.24036.37.idtracker@ietfa.amsl.com> 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: Thu, 08 Sep 2011 15:09:06 -0000 This draft, Section 3 says: > Required parameters: boundary, report-type Is the "report-type" parameter values tracked somewhere? Is there an IANA registry for this parameter, or is it going to be created? Mykyta Yevstifeyev 30.08.2011 7:18, internet-drafts@ietf.org wrote: > 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. > > 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 > > 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 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From msk@cloudmark.com Thu Sep 8 09:21: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 7F17021F84A9 for ; Thu, 8 Sep 2011 09:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.51 X-Spam-Level: X-Spam-Status: No, score=-103.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 FQqMKoYywBd9 for ; Thu, 8 Sep 2011 09:21:23 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id DDDF221F84A8 for ; Thu, 8 Sep 2011 09:21:20 -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, 8 Sep 2011 09:23:13 -0700 From: "Murray S. Kucherawy" To: Mykyta Yevstifeyev , "apps-discuss@ietf.org" Date: Thu, 8 Sep 2011 09:23:12 -0700 Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.txt Thread-Index: AcxuOYVMxNd3+isySo2iFMw43n4ZKwACfeGw Message-ID: References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> <4E68DB1E.6090007@gmail.com> In-Reply-To: <4E68DB1E.6090007@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: Thu, 08 Sep 2011 16:21:31 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Mykyta Yevstifeyev > Sent: Thursday, September 08, 2011 8:11 AM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.= txt >=20 > Is the "report-type" parameter values tracked somewhere? Is there an > IANA registry for this parameter, or is it going to be created? The document says: "The report-type parameter ... is the MIME sub-type of t= he second body part of the multipart/report." Since MIME types are registe= red, the report-type value is always a value in that registry, so no new re= gistry is needed. From ned.freed@mrochek.com Thu Sep 8 10:08: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 95B3621F8AF7 for ; Thu, 8 Sep 2011 10:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 x+hBkS1zFHhv for ; Thu, 8 Sep 2011 10:08:12 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C109D21F85A4 for ; Thu, 8 Sep 2011 10:08:12 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O5T1WNQG0W011N7Y@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 8 Sep 2011 10:08:35 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O5KP14T1K0014O5Z@mauve.mrochek.com>; Thu, 8 Sep 2011 10:08:32 -0700 (PDT) Message-id: <01O5T1WLWWPI014O5Z@mauve.mrochek.com> Date: Thu, 08 Sep 2011 10:06:16 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 08 Sep 2011 09:23:12 -0700" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> <4E68DB1E.6090007@gmail.com> To: "Murray S. Kucherawy" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1315501722; bh=AKhHWEQD0ZIq+U2tTf6/+EBHbJYkQOpzZlh4Re4Dpxs=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=WRbeyOH3ZZUgOG1cPeSiEkgddSlwEdIBjPptMYkIPG7iNyKngHkOMHmCRtiLbsGec YTtE2SizV0B9TcgRn0E7vC+UsIKg5l/T1tEeQlUA/MVDHSbthNOYpxBSXHCfMkvL/R u75YnnEeam/36stfVOe95kS0HuhMpzcnN6OsEXlA= 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: Thu, 08 Sep 2011 17:08:13 -0000 > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Mykyta Yevstifeyev > > Sent: Thursday, September 08, 2011 8:11 AM > > To: apps-discuss@ietf.org > > Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.txt > > > > Is the "report-type" parameter values tracked somewhere? Is there an > > IANA registry for this parameter, or is it going to be created? > The document says: "The report-type parameter ... is the MIME sub-type of the > second body part of the multipart/report." Since MIME types are registered, > the report-type value is always a value in that registry, so no new registry is > needed. However, the fact that a given media subtype is suitable for use as report-type value needs to be noted in the registration. Perhaps a note to this effect is in order in this document. BTW, there's no need for an additional field for this. We can just note it under intended usage. Ned From msk@cloudmark.com Thu Sep 8 14:12: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 E9F0E21F8804 for ; Thu, 8 Sep 2011 14:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.511 X-Spam-Level: X-Spam-Status: No, score=-103.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 ao7UDWzVwrpU for ; Thu, 8 Sep 2011 14:12:15 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 84DB421F87FA for ; Thu, 8 Sep 2011 14:12:15 -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, 8 Sep 2011 14:14:08 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Thu, 8 Sep 2011 14:14:07 -0700 Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.txt Thread-Index: AcxuSi4mH0zBHHedSU+4yA8jWuCVPgAIfcDg Message-ID: References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> <4E68DB1E.6090007@gmail.com> <01O5T1WLWWPI014O5Z@mauve.mrochek.com> In-Reply-To: <01O5T1WLWWPI014O5Z@mauve.mrochek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] 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: Thu, 08 Sep 2011 21:12:16 -0000 After consulting with Ned off-list, I've added a new section right above th= e IANA Considerations that reads thus (pardon the XML):
Registration of new media types for the purpose of creating a new report format SHOULD note in the Intende= d Usage section of the media type registration that the t= ype being registered is suitable for use as a report-type in the context of this specification.
Support or concerns? -MSK From john-ietf@jck.com Sat Sep 10 04:19: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 22DD321F85AB for ; Sat, 10 Sep 2011 04:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.283 X-Spam-Level: X-Spam-Status: No, score=-103.283 tagged_above=-999 required=5 tests=[AWL=0.716, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_25=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 eIyHGB34nbGJ for ; Sat, 10 Sep 2011 04:19:13 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id F1A5321F85AA for ; Sat, 10 Sep 2011 04:19:12 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1R2Lc1-0005f0-6w; Sat, 10 Sep 2011 07:20:41 -0400 Date: Sat, 10 Sep 2011 07:20:40 -0400 From: John C Klensin To: RFC Errata System , paul.hoffman@vpnc.org Message-ID: <8FDDE9E59CF60C43C95F3951@PST.JCK.COM> In-Reply-To: <20110910083446.7D45098C251@rfc-editor.org> References: <20110910083446.7D45098C251@rfc-editor.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: apps-discuss@ietf.org, bortzmeyer+rfc@nic.fr, presnick@qualcomm.com, barryleiba@computer.org Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (2966) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Sep 2011 11:19:14 -0000 RFC Editor and relevant IESG members: As a general observation, given that we do not change RFCs once published and, especially for IETF Stream RFCs, that there are extensive opportunities to suggest small corrections during pre-approval review (and even post-approval if a problem is noticed after the approval notice but before actual publication), I believe the errata process would be considerably improved by imposing a non-trivial administrative fee for a filing, especially a filing within a few weeks of RFC publication. That fee would appropriately be doubled if the person making the filing were on the mailing list of a WG that considered the document and doubled again if the proposed change were either incorrect or specious. I believe that, if half of the fee went to the RFC Editor Staff Annual Party Fund and the other half were split among relevant ADs, WG Chairs, and authors, it would considerably improve the errata review process as well as providing a small barrier to use of the errata as either DoS attacks or general annoyances. Having the fee would provide those who read documents looking for errors significant encouragement to read the I-Ds and identify issues while they can still be fixed rather than doing post-publication nit-picking on RFCs. If nothing else, it would be useful if categories like "rejected" and "accepted" could be supplemented with "probably technically correct, but a massive waste of time". Now, as to substance, it is first worth remembering that, whatever the writing system is called, the name in Latin-derived characters is a transcription for an Austronesian language that has apparently been written with Indic/Brahmi-derived characters as well as Arabic and Latin ones. Such transcriptions and transliterations are rarely as precise as one might like, especially when one of the scripts through which a term migrates is written without explicit vowel notation. While "Jawi" is, indeed, usually preferred, we've been informed by Malaysian sources that "Jawa" is often used interchangeably. Probably the text in RFC 6365 should have read "Jawi, sometimes referred to as Jawa" or equivalent, a change that would have been trivially made had the issue been identified prior to publication (see above). Neither the Unicode script categories nor ISO 15924 are of use here because they consider Jawi to be simply Arabic Script. Whether it is or is not is a matter of judgment but then so is the question of whether the Arabic script as used to write the Arabic language and the various forms known as Perso-Arabic are really the same script or are, like e.g., Greek and Cyrillic, actually a single script with some variant and additional letter-glyphs and phonemes. The use of the term "Arabic-script-based" in the text was intended to point that out, so "...script (actually a variant of the arabic one)" in the errata does not add any information. regards, john --On Saturday, September 10, 2011 01:34 -0700 RFC Errata System wrote: > > The following errata report has been submitted for RFC6365, > "Terminology Used in Internationalization in the IETF". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6365&eid=2966 > > -------------------------------------- > Type: Editorial > Reported by: St?phane Bortzmeyer > > Section: 2 > > Original Text > ------------- > Malay is primarily written in > > Latin script today, but the earlier, > Arabic-script-based, Jawa > > form is still in use > > Corrected Text > -------------- > Malay is primarily written in > > Latin script today, but the earlier, > Arabic-script-based, Jawi > > form is still in use > > Notes > ----- > I don't know this script myself but it seems that, in english, > it is always called Jawi (Jawa is the old name for the island > it came from, so Jawi = script from Jawa). > > > > This script (actually a variant of the arabic one) does not > seem to be in ISO 15924 so I cannot offer an authoritative > reference. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, > please use "Reply All" to discuss whether it should be > verified or rejected. When a decision is reached, the > verifying party (IESG) can log in to change the status and > edit the report, if necessary. > > -------------------------------------- > RFC6365 (draft-ietf-appsawg-rfc3536bis-06) > -------------------------------------- > Title : Terminology Used in Internationalization > in the IETF Publication Date : September 2011 > Author(s) : P. Hoffman, J. Klensin > Category : BEST CURRENT PRACTICE > Source : Applications Area Working Group > Area : Applications > Stream : IETF > Verifying Party : IESG From wwwrun@rfc-editor.org Sat Sep 10 01:32: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 AF7CC21F86B3 for ; Sat, 10 Sep 2011 01:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, NO_RELAYS=-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 hiYi5XgHSbmJ for ; Sat, 10 Sep 2011 01:32:49 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 4B48D21F86A4 for ; Sat, 10 Sep 2011 01:32:49 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7D45098C251; Sat, 10 Sep 2011 01:34:46 -0700 (PDT) To: paul.hoffman@vpnc.org, john+ietf@jck.com, presnick@qualcomm.com, stpeter@stpeter.im, barryleiba@computer.org, alexey.melnikov@isode.com, yaojk@cnnic.cn From: RFC Errata System Message-Id: <20110910083446.7D45098C251@rfc-editor.org> Date: Sat, 10 Sep 2011 01:34:46 -0700 (PDT) X-Mailman-Approved-At: Sat, 10 Sep 2011 08:27:41 -0700 Cc: bortzmeyer+rfc@nic.fr, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Editorial Errata Reported] RFC6365 (2966) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Sep 2011 08:32:49 -0000 The following errata report has been submitted for RFC6365, "Terminology Used in Internationalization in the IETF". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6365&eid=2966 -------------------------------------- Type: Editorial Reported by: Stéphane Bortzmeyer Section: 2 Original Text ------------- Malay is primarily written in Latin script today, but the earlier, Arabic-script-based, Jawa form is still in use Corrected Text -------------- Malay is primarily written in Latin script today, but the earlier, Arabic-script-based, Jawi form is still in use Notes ----- I don't know this script myself but it seems that, in english, it is always called Jawi (Jawa is the old name for the island it came from, so Jawi = script from Jawa). This script (actually a variant of the arabic one) does not seem to be in ISO 15924 so I cannot offer an authoritative reference. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6365 (draft-ietf-appsawg-rfc3536bis-06) -------------------------------------- Title : Terminology Used in Internationalization in the IETF Publication Date : September 2011 Author(s) : P. Hoffman, J. Klensin Category : BEST CURRENT PRACTICE Source : Applications Area Working Group Area : Applications Stream : IETF Verifying Party : IESG From john-ietf@jck.com Sat Sep 10 15:57: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 8757C21F850E for ; Sat, 10 Sep 2011 15:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, MIME_8BIT_HEADER=0.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 gTgp2JaZU7pw for ; Sat, 10 Sep 2011 15:57:12 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id DA64821F8509 for ; Sat, 10 Sep 2011 15:57:11 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1R2WVh-000FsX-Eb; Sat, 10 Sep 2011 18:58:53 -0400 X-Vipre-Scanned: 00245499002894002455E6-TDI Date: Sat, 10 Sep 2011 18:58:51 -0400 From: John C Klensin To: =?UTF-8?Q?St=C3=A9phane_Bortzmeyer?= Message-ID: <2A0F6A6C7A60F7292A0A104C@[192.168.1.128]> In-Reply-To: <20110910190557.GA13739@laperouse.bortzmeyer.org> References: <20110910083446.7D45098C251@rfc-editor.org> <8FDDE9E59CF60C43C95F3951@PST.JCK.COM> <20110910190557.GA13739@laperouse.bortzmeyer.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: apps-discuss@ietf.org, paul.hoffman@vpnc.org, presnick@qualcomm.com, barryleiba@computer.org, RFC Errata System Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (2966) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Sep 2011 22:57:12 -0000 --On Saturday, September 10, 2011 20:05 +0100 St=C3=A9phane Bortzmeyer wrote: >... >> post-publication nit-picking on RFCs. >=20 > I would say otherwise: such an errata is of small importance, > in the grand scheme of things, but, should a 6365bis appear > one day, it is a good idea if such problems are stored > somewhere for the future revision. What is wrong with using > the errata database as a bug-tracking system? And what is the > actual cost of storing one bug in this database? St=C3=A9phane, First, my apologies for overreacting somewhat. Bad week. Beyond that, there are two answers to your question. The first is that, while it is probably inevitable that something will slip through every once in a while, the amount of nit-picking that goes on with a document like this while it is passing through the approval stages makes it extremely frustrating that something of more significance than many of the things that were caught slips through nonetheless. The second is that, unfortunately from my point of view, the errata system has evolved rather quickly from just what you describe -- at least in large measure a lightweight system for recording minor issues that it would be desirable to check if the document is ever revised -- to a rather heavyweight one in which a half-dozen people and a WG mailing list get involved and a multi-step approval process is needed. Perhaps if the system permitted someone who found a problem that "is of small importance, ... it is a good idea if such problems are stored somewhere for the future revision" to say that when the erratum is submitted --perhaps by checking a "recommend moving this immediately to 'hold for future revision' box" and _not_ copy all present and past ADs and a WG as well as the authors, the RFC Editor could assign that category in the absence of someone deciding to take it up for more serious discussion. That would certainly have been reasonable (and appreciated, at least by me) for this report; the problem if any, lies in the implicit request for a broader discussion and relatively immediate action, if only to classify it that way in the end. best, john =20 From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Sat Sep 10 16:35:32 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD8921F89BA for ; Sat, 10 Sep 2011 16:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.656 X-Spam-Level: X-Spam-Status: No, score=-102.656 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_29=0.6, 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 LxtGINM30kYc for ; Sat, 10 Sep 2011 16:35:31 -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 AA0C421F899D for ; Sat, 10 Sep 2011 16:35:31 -0700 (PDT) Received: by ywa6 with SMTP id 6so975828ywa.31 for ; Sat, 10 Sep 2011 16:37:30 -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=/SgA4QoMgv/6Zk2acGvt3rfaeokfuu20cP8OssKdFfs=; b=EnI7BFkRE7iYTFvEUn3K9+Avpkz8YTsWwzDl+fSaTsK1iwp1kONTRtOQ50xElakVXe boL1xFuWtivVZGLjV7XgYZNpP5SA1RSw2VlirfVW9sdsSvJCq391nKlbj2WXeoICRhG1 72YOTi72IFyopfY5fGnWeoN4dbUN9XYOZQ9Lo= Received: by 10.68.0.104 with SMTP id 8mr1876292pbd.381.1315697850138; Sat, 10 Sep 2011 16:37:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.101.15 with HTTP; Sat, 10 Sep 2011 16:36:50 -0700 (PDT) In-Reply-To: <8FDDE9E59CF60C43C95F3951@PST.JCK.COM> References: <20110910083446.7D45098C251@rfc-editor.org> <8FDDE9E59CF60C43C95F3951@PST.JCK.COM> From: Frank Ellermann Date: Sun, 11 Sep 2011 01:36:50 +0200 Message-ID: To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (2966) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Sep 2011 23:35:32 -0000 On 10 September 2011 13:20, John C Klensin wrote: > [...] > there are extensive opportunities to suggest small > corrections during pre-approval review It happens for obvious reasons; folks look at a draft or RFC again when it somehow triggers their attention. That is how I ended up to report the earth-shattering fact that the MD4-obsolete RFC has the MD2-obsolete page headers (or vice versa) on the day of its publication, when I updated the relevant MD2+MD4+MD5 en:Wikipedia articles. IOW, I did not see this minor nit before; and actually I don't care about MD2+MD4. But it would be stupid to update only the MD5 article when you know that there are similar RFCs for MD2+MD4. There are also authors, notably you, who hate to discuss editorial nits outside of AUTH48. Recently the same pattern had a similar effect, I saw an oddity in a "no-spam-report" draft only *because* it is now in PubReq. I didn't see it at a better time (=3D WG LC). My interest in that WG is not related to the perfectly harmless "no-spam report" draft, and you cannot expect me to find minor nits at a better time: Mostly I stumble over nits, and the timing can be bad. > I believe the errata process would be considerably > improved by imposing a non-trivial administrative fee > for a filing, especially a filing within a few weeks > of RFC publication. Refundable for verified errata, the IETF trust has to cough up the costs caused by publishing erroneous RFCs in their stream. "Held for document update" slowly degrades into "I don't like to check what this really is", therefore it should be handled as "verified" wrt the errata fee. To avoid the fee posting an I-D with biannual renewals would suffice. Insert "" at the place where it belongs. > Many editorial errata are editorial nits, and this has to be fixed years later in a xxxx-bis document. It is perfectly okay to document the fact in a public erratum. It is also good for readers stumbling over the same issue, when they find that this was already reported, and ideally verified. (Or rejected, if the alleged editorial nit turns out to be intentional, and a "fix" would be a mistake.) Some editorial errata are disguised technical errata, I click on "editorial" whenever possible, reserving "technical" for "this is really wrong, and that it is wrong is not obvious". I very much appreciate the work of A. H=F6nes, the RFC errata system is a very important part of the RFCs. It is not at all a waste of my time. Of course I can see your point as author, but all it takes is an ACK or a NAK. You should be also able to "opt-out" from the errata process if you don't like it. After all it's the responsibility of the IETF to care about its published RFCs. > While "Jawi" is, indeed, usually preferred, we've > been informed by Malaysian sources that "Jawa" is > often used interchangeably. Okay, simply put that as reason in a NAK. I couldn't care less about "Jawi vs. Jawa", but I certainly care about the RFC errata process. -Frank From sm@resistor.net Sat Sep 10 17:34: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 8A2F521F8797 for ; Sat, 10 Sep 2011 17:34:01 -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.023, 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 eGFpQ6315prl for ; Sat, 10 Sep 2011 17:33:57 -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 7F61021F877F for ; Sat, 10 Sep 2011 17:33:56 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p8B0ZpYM017848 for ; Sat, 10 Sep 2011 17:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1315701355; bh=PHFxTU6JZu89yVDgNMCZ16msQRz1RlHCg+ukrHD5rm8=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=2dMdRuDSrVu/2Y2JCSDOVie5yiLBGvtUdlipHsJ0RAC4QuVdzjUBrgQIH2VAdM7uv i1bzIV+1CcWcVPjjgecq7GHs1c7bYlEPL5t7OGYd/2iGvf+JWhSLcaV8u70lUKhKfl t9jbn+yxl/Q4T6qLKTscQZMu2H+bH5XndV3/jQfI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1315701355; bh=PHFxTU6JZu89yVDgNMCZ16msQRz1RlHCg+ukrHD5rm8=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=03isA77gFhGIJd4FTFkeXCzctCY6ziNgNOl0y7kbr4Ho5aqGuNSTdagFEnl9eNOEo mg16/jM0XgCPmGUZM3x9fZ9sB7x5kKAYl18LA7SyADmXiO5N4NTn2Iq/OvIbg93dYz fJk6EhGYYF1zai81yoLlfMbuKT8KrN4Zoi5X4lJc= Message-Id: <6.2.5.6.2.20110910171642.087ae4b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 10 Sep 2011 17:31:12 -0700 To: apps-discuss@ietf.org From: SM In-Reply-To: References: <20110910083446.7D45098C251@rfc-editor.org> <8FDDE9E59CF60C43C95F3951@PST.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (2966) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Sep 2011 00:34:01 -0000 At 16:36 10-09-2011, Frank Ellermann wrote: >It happens for obvious reasons; folks look at a draft >or RFC again when it somehow triggers their attention. http://www.bortzmeyer.org/3536.html As for errata [1]: "The idea was to discourage readers from repeatedly pointing out the same typos in published RFCs. This evolved into the errata verification and posting process" "Unfortunately, our understanding of the errata problem was wrong in several ways. The number of errors reported turned out to be significantly greater than anticipated" "We note that allowing technical errata is a slippery slope: there may be a temptation to use errata to "fix" protocol design errors, rather than publishing new RFCs that update the erroneous documents." Regards, -sm 1. draft-rfc-editor-errata-process-02 From derhoermi@gmx.net Sat Sep 10 18:15: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 3213521F8804 for ; Sat, 10 Sep 2011 18:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.271 X-Spam-Level: X-Spam-Status: No, score=-3.271 tagged_above=-999 required=5 tests=[AWL=-0.672, 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 XFoQSUeoDIMH for ; Sat, 10 Sep 2011 18:15:07 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 46DDF21F8781 for ; Sat, 10 Sep 2011 18:15:05 -0700 (PDT) Received: (qmail invoked by alias); 11 Sep 2011 01:17:03 -0000 Received: from dslb-094-223-159-150.pools.arcor-ip.net (EHLO HIVE) [94.223.159.150] by mail.gmx.net (mp053) with SMTP; 11 Sep 2011 03:17:03 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+WsXMkerKW1V9UYlyLcDjbJpAc/I0Hk8b20dExjU eN7C5KO3f6sZ6v From: Bjoern Hoehrmann To: John C Klensin Date: Sun, 11 Sep 2011 03:17:07 +0200 Message-ID: References: <20110910083446.7D45098C251@rfc-editor.org> <8FDDE9E59CF60C43C95F3951@PST.JCK.COM> <20110910190557.GA13739@laperouse.bortzmeyer.org> <2A0F6A6C7A60F7292A0A104C@[192.168.1.128]> In-Reply-To: <2A0F6A6C7A60F7292A0A104C@[192.168.1.128]> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (2966) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Sep 2011 01:15:08 -0000 * John C Klensin wrote: >Perhaps if the system permitted someone who found a problem that >"is of small importance, ... it is a good idea if such problems >are stored somewhere for the future revision" to say that when >the erratum is submitted --perhaps by checking a "recommend >moving this immediately to 'hold for future revision' box" and >_not_ copy all present and past ADs and a WG as well as the >authors, the RFC Editor could assign that category in the >absence of someone deciding to take it up for more serious >discussion. That would certainly have been reasonable (and >appreciated, at least by me) for this report; the problem if >any, lies in the implicit request for a broader discussion and >relatively immediate action, if only to classify it that way in >the end. Could you explain where you got this impression from? The E-Mail that started this thread says "Editorial Errata Reported" in the Subject, and editorial issues typically do not require broad discussion or ur- gent action, and there does not seem much else to suggest it does. So I would think this field already exists. As for copying people, well, I would think most of the people in question are used to dealing with high volume email traffic with mails varying greatly in importance. I am not saying the user interface for this can't be improved, but I do not see the problem you have with it. -- 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 McQuilWP@pobox.com Sat Sep 10 22:03: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 EAE2A21F855F for ; Sat, 10 Sep 2011 22:03:09 -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 w08yedtIPAOA for ; Sat, 10 Sep 2011 22:03:09 -0700 (PDT) Received: from smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id C07CF21F85B8 for ; Sat, 10 Sep 2011 22:03:06 -0700 (PDT) Received: from smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 18D355972; Sun, 11 Sep 2011 01:05:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=5GcFCQ9g69FX ew333vT60R0Vh0A=; b=VCuRlLZ7SlQcwwtz4QwXeHvfFVTDpgWmZLAuZp93QzbH 5LMLV7Rv0DGrD/Ie98eS3V693pnIJQLpwl6667XgZJMF5OQwfl4st6kD87tOdB1v PVllj1XQesZtQgIgqP5+feM8QmwRReFLLN0Wjg6wdcRjAB0H+pDC0V2KLUWeAS8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=YoB0+R DIHzsSpFx+8WXI6FVv5/loBC6Doaz6rvXTyPDbpGCMEf8LORpk2FuiN1295BfP1G XO1Qw1gq+bQR+SOgW5Co9eAo1Nx+Y17cWzEV4926SLKHr2DA+2rG1+d+ChcPKDFj Yuj0f4M21ZeZb1NnFYv9csWlc1SOj/Pr6vwe8= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 10AA35971; Sun, 11 Sep 2011 01:05:05 -0400 (EDT) Received: from BQ07NB (unknown [68.107.110.211]) by b-sasl-quonix.pobox.com (Postfix) with ESMTPA id 74568596E; Sun, 11 Sep 2011 01:05:03 -0400 (EDT) Date: Sat, 10 Sep 2011 22:05:00 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <1014326436.20110910220500@pobox.com> To: Apps-Discusssion In-Reply-To: References: <20110910083446.7D45098C251@rfc-editor.org> <8FDDE9E59CF60C43C95F3951@PST.JCK.COM> <20110910190557.GA13739@laperouse.bortzmeyer.org> <2A0F6A6C7A60F7292A0A104C@[192.168.1.128]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 9BD28290-DC33-11E0-90CA-9DB42E706CDE-02871704!b-pb-sasl-quonix.pobox.com Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (2966) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Sep 2011 05:03:10 -0000 On Sat, 2011-09-10, Bjoern Hoehrmann wrote: > * John C Klensin wrote: >>Perhaps if the system permitted someone who found a problem that >>"is of small importance, ... it is a good idea if such problems >>are stored somewhere for the future revision" to say that when >>the erratum is submitted --perhaps by checking a "recommend >>moving this immediately to 'hold for future revision' box" and >>_not_ copy all present and past ADs and a WG as well as the >>authors, the RFC Editor could assign that category in the >>absence of someone deciding to take it up for more serious >>discussion. That would certainly have been reasonable (and >>appreciated, at least by me) for this report; the problem if >>any, lies in the implicit request for a broader discussion and >>relatively immediate action, if only to classify it that way in >>the end. > Could you explain where you got this impression from? The E-Mail that > started this thread says "Editorial Errata Reported" in the Subject, > and editorial issues typically do not require broad discussion or ur- > gent action, and there does not seem much else to suggest it does. So > I would think this field already exists. As for copying people, well, > I would think most of the people in question are used to dealing with > high volume email traffic with mails varying greatly in importance. I > am not saying the user interface for this can't be improved, but I do > not see the problem you have with it. I suspect that the people that are copied with these Errata emails probably get a lot of them, so I understand the spam-spam-spam sort of frustrated reaction. I think that John's suggestion would be a good one: to have some place to store problems with an RFC for future consideration. For example, I just found a place in RFC 5322 (Internet Message Format) in which the ABNF is clear and correct, but the explanatory text could be read to contradict the ABNF. I know that I have read this area of 5322 before, but not with this particular syntax in mind so it is the first that I have noticed it. The paragraph in question was copied from RFC 2822. Obviously not an earth-shattering problem! I thought that I should use the RFC Errata page to report this. I first checked the existing Errata to see if it had already been reported and it hadn't. No such errata was reported for RFC 2822 either. While I was reviewing the Rejected errata, several of the rejection comments referred to the fact that submitting errata was NOT the way to raise some issues. I drilled down to see what the guidelines were and I *think* that it would not be right to submit *my* suggestion for rewording as an RFC Erratum. The instructions said I should, rather, submit it to the appropriate WG, however, I don't know which that should be! Maybe YAM, but it seems to be disbanding. I really shouldn't have to remember this issue until an opportunity arises to mention it. There should be a cheap mechanism for me to leave a note, associated with RFC 5322 that will be easily picked up when a revision is contemplated. -- Bill McQuillan From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Sat Sep 10 23:11: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 6582D21F8514 for ; Sat, 10 Sep 2011 23:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.954 X-Spam-Level: X-Spam-Status: No, score=-102.954 tagged_above=-999 required=5 tests=[AWL=0.145, 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 9ffTllPeC6dB for ; Sat, 10 Sep 2011 23:11:34 -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 15AF721F84DB for ; Sat, 10 Sep 2011 23:11:29 -0700 (PDT) Received: by pzk33 with SMTP id 33so17473250pzk.18 for ; Sat, 10 Sep 2011 23:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=IGUxFgf/Iw6DcRSrVDNOvkDzs+vd7jTEEGQdSa8t6G0=; b=DQKdN6djpAGpmRyFqNpQMJ9LSGpZr5z1TrZsJQYU5PsfD5+ChMN3EuY6xGJWt+A4am mZ1ku7xB9ozP8L+icYa0dolR6RElPa1/XPwO+EiJ0AaFybH/LTdFVXgb8J/Da3Pt8KI9 1LEGuX9RJofwapFoCtGiJGGfmhMZMO0OZ4Gcw= Received: by 10.68.1.35 with SMTP id 3mr2490236pbj.247.1315721603108; Sat, 10 Sep 2011 23:13:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.101.15 with HTTP; Sat, 10 Sep 2011 23:12:43 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20110910171642.087ae4b8@resistor.net> References: <20110910083446.7D45098C251@rfc-editor.org> <8FDDE9E59CF60C43C95F3951@PST.JCK.COM> <6.2.5.6.2.20110910171642.087ae4b8@resistor.net> From: Frank Ellermann Date: Sun, 11 Sep 2011 08:12:43 +0200 Message-ID: To: SM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (2966) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Sep 2011 06:11:35 -0000 On 11 September 2011 02:31, SM quoted: >=A0"Unfortunately, our understanding of the errata problem was wrong > =A0in several ways. =A0The number of errors reported turned out to be > =A0significantly greater than anticipated" IMHO the process works much better now. > draft-rfc-editor-errata-process-02 The [IESG-Err-Proc] reference in this draft matches the page at , and in this statement "Hold for Document Update" is almost literally the same as "archived" in the rfc-editor-errata-process draft. If that is unrelated to what you wanted to say I need a new clue; especially, why did you mention St=E9phane's RFC 3536 blog entry? -Frank From sm@resistor.net Sun Sep 11 03:34: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 CCC4921F84BC for ; Sun, 11 Sep 2011 03:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 fXpabB-T9gTY for ; Sun, 11 Sep 2011 03:34:52 -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 2CCC321F84BA for ; Sun, 11 Sep 2011 03:34:52 -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 p8BAaWDt024972; Sun, 11 Sep 2011 03:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1315737404; bh=oWdMkAd7Y9O476Zpdw5hLhnexhKAb4XoHz1g2gJTYBc=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Content-Transfer-Encoding; b=PwiPlnrMVEJC3N+EqDDDvAhXf6zmuQlPXY4VvUB1/iHrGwpXjS1elJuBRjkYCA+wd QNJ4oXxpRALByknu1bJCG9LgidlkFl4Xa+p6fumtwYrHm7IIzaGqgRsNyU8bUCpZr8 a1jnpahwY/J3yLoKhN4/6TXEoukJW4e9QOoAPMMM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1315737404; bh=oWdMkAd7Y9O476Zpdw5hLhnexhKAb4XoHz1g2gJTYBc=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Content-Transfer-Encoding; b=fxEbytViZKDHl7vQ1El1N64tXpCdLWjFVRDF7gi/YCNO3W+77DalgX0K1Z0OTMnxw pV7hamGg1mqC42aTqOM/hsi59oIhW4oEwCK7OpBzpAd0o0cX2COt6cT8VQTCjoQOGY 10PzV+2eYVg27dr2t8pLh1QML8znqn+TfoFKDlp4= Message-Id: <6.2.5.6.2.20110911023525.087a8210@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 11 Sep 2011 03:36:02 -0700 To: Frank Ellermann From: SM In-Reply-To: References: <20110910083446.7D45098C251@rfc-editor.org> <8FDDE9E59CF60C43C95F3951@PST.JCK.COM> <6.2.5.6.2.20110910171642.087ae4b8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (2966) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Sep 2011 10:34:53 -0000 Hi Frank, At 23:12 10-09-2011, Frank Ellermann wrote: >If that is unrelated to what you wanted to say I need a new clue; There was a time when the author's email address=20 was published in a RFC. You could send comments=20 to that address. As an author, it can be tedious=20 having the same errors pointed out=20 repeatedly. It is easier for authors if such=20 comments are collected and is publicly=20 accessible. And the errata system took a life of its own. What I wanted to say was read about the initial=20 idea, see how it turned out and draw your own conclusion. >especially, why did you mention St=E9phane's RFC 3536 blog entry? That's a guess about what may have prompted=20 Stephane to read the RFC and send in a=20 comment. As a side note, it is an interesting piece of work. Regards, -sm=20 From john-ietf@jck.com Sun Sep 11 05:46: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 3B27221F84AE for ; Sun, 11 Sep 2011 05:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 RvJnPrOf+a3s for ; Sun, 11 Sep 2011 05:46:16 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 1C20221F845C for ; Sun, 11 Sep 2011 05:46:16 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1R2jSB-0000Uq-Bm; Sun, 11 Sep 2011 08:48:07 -0400 X-Vipre-Scanned: 012E0F450028C8012E1092-TDI Date: Sun, 11 Sep 2011 08:48:06 -0400 From: John C Klensin To: Bill McQuillan , Apps-Discusssion Message-ID: In-Reply-To: <1014326436.20110910220500@pobox.com> References: <20110910083446.7D45098C251@rfc-editor.org> <8FDDE9E59CF60C43C95F3951@PST.JCK.COM> <20110910190557.GA13739@laperouse.bortzmeyer.org> <2A0F6A6C7A60F7292A0A104C@[192.168.1.128]> <1014326436.20110910220500@pobox.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (2966) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Sep 2011 12:46:17 -0000 --On Saturday, September 10, 2011 22:05 -0700 Bill McQuillan wrote: > > On Sat, 2011-09-10, Bjoern Hoehrmann wrote: >> * John C Klensin wrote: >>> Perhaps if the system permitted someone who found a problem >>> that "is of small importance, ... it is a good idea if such >>> problems are stored somewhere for the future revision" to >>> say that when the erratum is submitted --perhaps by checking >... >> Could you explain where you got this impression from? The >> E-Mail that started this thread says "Editorial Errata >> Reported" in the Subject, and editorial issues typically do >> not require broad discussion or ur- gent action, and there >> does not seem much else to suggest it does. So I would think >> this field already exists. As for copying people, well, I >> would think most of the people in question are used to >> dealing with high volume email traffic with mails varying >> greatly in importance. I am not saying the user interface for >> this can't be improved, but I do not see the problem you have >> with it. Perhaps, Bjoern, because you are not the listed author of a lot of RFCs and hence don't see many of these, especially for documents for which there is no near-term prospect of revision. In practice today, the RFC Editor and their tools feel some obligation to take these as serious errors and change requests until proven otherwise and to track down their status. There is no practical way for the submitter to say "minimal distribution; just keep this in the system so it doesn't get lost" and for authors to say "yes, now, for the present, let's move on". A _long_ time ago, an author could have responded to a correction like this by saying "yes, useful clarification", sent a revised draft off to the RFC Editor, and had it published as an update. Today, given that this is a BCP, even starting to think about an update would require a conversation with ADs and WG Chairs about whether the WG should take it on and possibly a discussion on the WG list and consensus call about whether to reopen the document (not about the suggested changes). If things got that far, we would then all have the "opportunity", not just to review this particular change but to go back through the process of asking what definitions are there, what additional definitions people think should be added, and whether other definitions and comments need to be fine-tuned. That is one of the reasons documents don't get revised unless there is a compelling need to do so. It is probably as it should be -- on balance, I think we are better off with a more careful approval and consensus process than we were three decades ago. But, it means that, as Bill points out, some easy way to simply build a file of comments for later consideration --if and when the document is reopened-- would be a good idea. > I suspect that the people that are copied with these Errata > emails probably get a lot of them, so I understand the > spam-spam-spam sort of frustrated reaction. yes. We are, fortunately, nowhere near that point yet (at least I'm not), but it isn't hard to imagine a situation in which a would-be RFC author has to weigh the importance of the work against the potential for more email noise -- noise that cannot be discarded or ignored without reading and responding. > I think that John's suggestion would be a good one: to have > some place to store problems with an RFC for future > consideration. For example, I just found a place in RFC 5322 > (Internet Message Format) in which the ABNF is clear and >... > I really shouldn't have to remember this issue until an > opportunity arises to mention it. There should be a cheap > mechanism for me to leave a note, associated with RFC 5322 that > will be easily picked up when a revision is contemplated. Right. And that flags the fact that there are some textual issues in 5322 that should be examined sometime. john From maileko@gmail.com Sun Sep 11 23:01: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 4FCC621F8B06; Sun, 11 Sep 2011 23:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 HYSRn3BXLEp9; Sun, 11 Sep 2011 23:01:04 -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 E349A21F8B05; Sun, 11 Sep 2011 23:01:03 -0700 (PDT) Received: by pzk33 with SMTP id 33so22062086pzk.18 for ; Sun, 11 Sep 2011 23:03: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:date:message-id:subject:from:to :cc:content-type; bh=e8f53BPrOZPMQemqCVqALYSLGwrQ8NcrP58CRZ6JjaY=; b=LFl2VFUUnfaVfpwCukNgG/v1Ox0oGfzZ7MzbjxATtQRsO0o/glnaeEeBPJrHEVnh1P 2HKSJigGikk6RLOmYnEsmEYzwYO9e7LWRPPnf094anqBzvhBqDi671AyyUijfuEq5s7L 2Jk4hRqVwuSisOyTc0E6Q7kt/HAJPjtUXbonM= MIME-Version: 1.0 Received: by 10.68.20.99 with SMTP id m3mr5535510pbe.444.1315807385973; Sun, 11 Sep 2011 23:03:05 -0700 (PDT) Received: by 10.68.60.39 with HTTP; Sun, 11 Sep 2011 23:03:05 -0700 (PDT) In-Reply-To: <4E5DE57B.8070801@gmail.com> References: <20110829144145.31952.69055.idtracker@ietfa.amsl.com> <4E5D06EA.9040205@gmx.de> <4E5DB9B8.70006@gmail.com> <4E5DD2BF.40801@gmx.de> <4E5DE57B.8070801@gmail.com> Date: Sun, 11 Sep 2011 23:03:05 -0700 Message-ID: From: Maile Ohye To: Mykyta Yevstifeyev Content-Type: multipart/alternative; boundary=bcaec521639dd5752504acb847ae 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: Mon, 12 Sep 2011 06:01:05 -0000 --bcaec521639dd5752504acb847ae Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi everyone, Thanks for the feedback! I'll submit draft-02 which addresses the issues below: 1. CLOSED. M. Yevstifeyev: =93This 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', whic= h desigantes the preferred URI from a set of identical or vastly similar ones= . A similar text should go in the first paragraph of Introduction.=94 -- response by M. Ohye: =93Updated in abstract of draft-02.=94 2. CLOSED. M. Yevstifeyev: =93 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). -- response by M. Ohye: =93Updated to =91target URI=92 in draft-02.=94 3. CLOSED. M. Yevstifeyev: =93Section 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);=94 -- response by M. Ohye: =93Added to draft-02.=94 4. CLOSED. M. Yevstifeyev: =93The 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]);=94 -- response by M. Ohye: =93Changed to: [ The source URI 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 ) ] 5. CLOSED. M. Yevstifeyev: =93A URI that serves a 4xx error code (Section 1= 0.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.=94 -- response by J. Reschke: =93-1. This is useful information. Just because something is specific doesn't mean it shouldn't be mentioned.=94 -- response by M. Ohye: =93Yes, we=92d like to include restrictions, even i= f they are HTTP-specific. Unfortunately, it would be difficult to mention the= m clearly while remaining HTTP-agnostic.=94 6. OPEN. M. Yevstifeyev: =93 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.=94 -- response by J. Reschke: =93+-0.=94 -- response by M. Ohye: =93We=92d prefer not to clutter our point with a li= nk to the =91start=92 relation, but if we could add it in a footnote, that would = be fine.=94 7. CLOSED. M. Yevstifeyev: =93In 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.=94 -- response by J. Reschke: =93-1.=94 8. CLOSED. M. Yevstifeyev: =93References: Why make RFC 2616 and HTML4 spec Normative references? Shouldn't Informative be OK?=94 -- response by J. Reschke: =93For 2616 is makes sense if there are normativ= e constrains specific for HTTP.=94 Thanks again, Maile On Wed, Aug 31, 2011 at 12:40 AM, Mykyta Yevstifeyev wrote: > 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 =3D "Link" ":" #link-value >> link-value =3D "<" 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 >> > > --bcaec521639dd5752504acb847ae Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi everyone,

Thanks for the feedback! I'll submit dr= aft-02 which addresses the issues below:

1. CLOSED. M. Yevstifeyev: =93This isn&#= 39;t clear enough for abstract. =A0I propose:
RFC 5988 specified a way to define relationships betweeen links on the Web.= =A0This document describes a new type of such relationship, 'canonical= ', which desigantes the preferred URI from a set of identical or vastly= similar ones.

=A0=A0o =A0Specify a URI Reference (see [RFC3= 986] Section 4.1) i.e., an absolute URI or a relative reference

=A0=A0o =A0Be a relative URI (see [RFC3986], = Section 4.2);=94


=A0=A0o =A0The source URI of a permanent redi= rect (for HTTP, this refers to
=A0=A0=A0=A0=A0= Section 10.3.2 of [RFC2616]) or a "300 Multiple Choices" URI
=A0=A0=A0=A0=A0(Section 10.3.1 of [RFC2616])


=A0=A0o =A0The URI which is a source of a per= manent redirect (for HTTP, this
=A0=A0=A0=A0= =A0refers to 300 and 301 response codes, defined in Sections
=A0=A0=A0=A0=A010.3.1 and 10.3.2 of RFC 2616 [RFC2616]);=94<= br class=3D"kix-line-break">
-- response by M. Ohye: =93Changed to:
A URI that serves a 4xx error code= (Section 10.4 of [RFC2616]).
o =A0The first page of a m= ulti-page article or multi-page listing of
=A0=A0=A0=A0=A0items (since the first page is not a duplicate or a superse= t or
=A0=A0=A0=A0=A0the context URI). =A0For e= xample, page2 and page3 of an article
=A0=A0= =A0=A0=A0SHOULD NOT specify page1 as the canonical.

http://www.w3.org/TR/1999= /REC-html401-19991224/types.html#idx-link_type), used for this= purpose.=94



=A0=A0=A0=A0=A0=A0traditional strong indicator that a URI's content ha= s been
=A0=A0=A0=A0=A0=A0permanently moved, co= uld not be implemented in place of the
=A0=A0= =A0=A0=A0=A0canonical link relation.






Thanks again,=
Maile

On Wed, Aug 31, 2011 at 12:40 AM, Mykyta Yevstifeyev <evnikita2@gmail.com> wrote:
> 31.08.2= 011 9:20, Julian Reschke wrote:
>>
>> On 2011-08-31 06:34= , Mykyta Yevstifeyev wrote:
>>>
>>> ...
>>> Section 3:
>>>=
>>>> =A0 =A0The target/canonical URI MAY:
>>>&g= t;
>>>> =A0 =A0o =A0Specify a URI Reference (see [RFC3986] S= ection 4.1) i.e., an
>>>> =A0 =A0 =A0 absolute URI or a relative reference
>&g= t;>
>>> What you mean here? If you wanted to show that canon= ical URI may be a
>>> relative one, you should better write:>>>
>>>> =A0 =A0The target/canonical URI MAY:
>>>>>>>> =A0 =A0o =A0Be 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
>= <URI-Reference> from RFC 5988:
>
>> =A0 Link =A0 =A0 = =A0 =A0 =A0 =3D "Link" ":" #link-value
>> =A0 = link-value =A0 =A0 =3D "<" URI-Reference">" *( &q= uot;;" link-param )
>
> and, correspondingly, the target URI *is* (rather than *MAY be= *)
> <URI-Reference>. =A0If the authors want to clarify that ta= rget URI may be
> relative, my proposed text is better.
>
>>
>>> Ibid:
>>>
>>>> =A0 =A0o= =A0A 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 ve= ry likely to
>>> even have the same req/response model as HTTP = has. As this is only
>>> available in HTTP, I propose to exclud= e this bullet, unless you can
>>> reformulate it so that it doesn't use HTTP-only feature.>>
>> -1. This is useful information. Just because somethi= ng is specific doesn't
>> mean it shouldn't be mentioned.<= br> >
> From Section 10.4 of RFC 2616:
>
>> =A0 =A0The = 4xx class of status code is intended for cases in which the
>> =A0= =A0client seems to have erred.
>
> So 4xx responses are used w= hen something is wring with HTTP request. =A0I
> doubt there are alternatives of such definition in *all* protocols for= which
> the URI scheme has been specified. =A0Eg., FTP doesn't a= lter error conditions
> caused by client or server; neither does TFTP= and many others.
>
> We aren't defining the link relation fro 'http' an= d 'https' URIs only; it is
> theoretically to allow any schem= e, including not yet defined.
>
>>> In Section 5:
>>>
>>>> =A0 =A02. =A0Permanent HTTP redirects (Sec= tion 10.3.2 of [RFC2616]), the
>>>> =A0 =A0 =A0 =A0tradition= al strong indicator that a URI's content has been
>>>> = =A0 =A0 =A0 =A0permanently moved, could not be implemented in place of the<= br> >>>> =A0 =A0 =A0 =A0canonical link relation.
>>>>>> Also too HTTP-centric approach. The same as above applies.>>
>> -1
>
> See above.
>
>>
= >>> References:
>>>
>>> Why make RFC 2616 and HTML4 spec Normative ref= erences? Shouldn't
>>> Informative be OK?
>>
&g= t;> For 2616 is makes sense if there are normative constrains specific f= or
>> HTTP.
>
> See above as well. =A0Why tie ourselves with= HTTP only?
>
> Mykyta
>
>>
>> > ...=
>>
>> Best regards, Julian
>>
>
>
--bcaec521639dd5752504acb847ae-- From julian.reschke@gmx.de Mon Sep 12 02:28: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 B2B2121F8AFC for ; Mon, 12 Sep 2011 02:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.232 X-Spam-Level: X-Spam-Status: No, score=-104.232 tagged_above=-999 required=5 tests=[AWL=-1.633, 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 PLhAyAA3VT8G for ; Mon, 12 Sep 2011 02:28: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 A46AA21F8AFA for ; Mon, 12 Sep 2011 02:28:36 -0700 (PDT) Received: (qmail invoked by alias); 12 Sep 2011 09:30:34 -0000 Received: from p508FAAE9.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.170.233] by mail.gmx.net (mp041) with SMTP; 12 Sep 2011 11:30:34 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+h3dV14a2h6RXx6NGjqb6mUttRM2HC1VLt0FTAoV Y5K32//JSyfW7o Message-ID: <4E6DD135.2090102@gmx.de> Date: Mon, 12 Sep 2011 11:30:29 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Maile Ohye References: <20110829144145.31952.69055.idtracker@ietfa.amsl.com> <4E5D06EA.9040205@gmx.de> <4E5DB9B8.70006@gmail.com> <4E5DD2BF.40801@gmx.de> <4E5DE57B.8070801@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; 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: Mon, 12 Sep 2011 09:28:39 -0000 On 2011-09-12 08:03, Maile Ohye wrote: > Hi everyone, > > Thanks for the feedback! I'll submit draft-02 which addresses the issues > below: > ... Thanks. At this point I believe you should send a request for publication to the IESG (iesg@ietf.org). If all goes well, the next step will be an IETF-wide Last Call, which will provide opportunity for a final round of feedback. Let's get this finished! Best regards, Julian From sm@resistor.net Mon Sep 12 03:05:54 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC8421F87F0 for ; Mon, 12 Sep 2011 03:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 iyGO-torpqtc for ; Mon, 12 Sep 2011 03:05:50 -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 B981321F85F6 for ; Mon, 12 Sep 2011 03:05:48 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p8CA7gDT021619; Mon, 12 Sep 2011 03:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1315822071; bh=H8vBe1/15Wcps75me4Yd1aqycyppnFliWnxWBqMjgJQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=4BqkCnv9jnH/t/mr+cSd3u74MkpGbCL/az/cUL3TRlrhKEjlue3yI/DBQUpYpjAd0 jmHJEM3xW7GkYwW9zV652m/UwBp5LAQXewugBRMCdOId4adnG5tmRv2ZEOpVc0981V WnRGMjmAgLXNmCuQ9eFy3jOAOlZgQSWO9wv5hd4Y= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1315822071; bh=H8vBe1/15Wcps75me4Yd1aqycyppnFliWnxWBqMjgJQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=ydwWDja/i2CBtawtYy1HYwoEGZOk3JzQEeDzqShATAQDG3Ps4NyB0WYYfOyL1T1+U vHHcYlkl/fpvCCBMOM/XCtuil/ncjOszXlqTPgtYoDepzvMrIHvgstg2MShzTLBJSE l9Jc4QTEtpLx9E+RDfJbZJD3hNRwoxAz3LPTz++o= Message-Id: <6.2.5.6.2.20110912030202.09feb7f0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 12 Sep 2011 03:07:19 -0700 To: apps-discuss@ietf.org From: SM In-Reply-To: <4E6DD135.2090102@gmx.de> References: <20110829144145.31952.69055.idtracker@ietfa.amsl.com> <4E5D06EA.9040205@gmx.de> <4E5DB9B8.70006@gmail.com> <4E5DD2BF.40801@gmx.de> <4E5DE57B.8070801@gmail.com> <4E6DD135.2090102@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-ohye-canonical-link-relation@tools.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: Mon, 12 Sep 2011 10:05:54 -0000 At 02:30 12-09-2011, Julian Reschke wrote: >At this point I believe you should send a request for publication to >the IESG (iesg@ietf.org). If all goes well, the next step will be an >IETF-wide Last Call, which "If you wish to seek Area Director sponsorship for an individual submission, the best solution is to contact the most relevant Area Director directly, with an explanation of why the draft is appropriate for IETF publication. The Area Director is also the best source of advice about whether an existing WG, or a BoF, may be applicable." See http://tools.ietf.org/area/app/ Regards, -sm From evnikita2@gmail.com Mon Sep 12 05:52:54 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E4D21F84D5; Mon, 12 Sep 2011 05:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.484 X-Spam-Level: X-Spam-Status: No, score=-3.484 tagged_above=-999 required=5 tests=[AWL=0.114, 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 yxm+yqM4xG7s; Mon, 12 Sep 2011 05:52:53 -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 51C8E21F8B38; Mon, 12 Sep 2011 05:52:52 -0700 (PDT) Received: by bkaq10 with SMTP id q10so3926470bka.31 for ; Mon, 12 Sep 2011 05:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=Vr9eVJSkjOYKs6EYRdpztU4TSQnCR/pQ/n7JAZ6tNFM=; b=j1hHYjfl5+x3tRPnuOdZOkAr2fDq6bhVhW63EwiHmVhmfNZMvbvShnPC78PS8hm8AY 07vQyaGkOMcsMpBrVR9V5kqj77VqFEro1FJsXHwD9sRVXo1+pbA4g0O6PvaxnN/NVdHw 5eeWbVPaI13KzVMY0b6JupKIdxs6ZYuB50+us= Received: by 10.204.142.18 with SMTP id o18mr427874bku.30.1315832094584; Mon, 12 Sep 2011 05:54:54 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id y8sm6080664bkb.4.2011.09.12.05.54.51 (version=SSLv3 cipher=OTHER); Mon, 12 Sep 2011 05:54:52 -0700 (PDT) Message-ID: <4E6E013E.6080404@gmail.com> Date: Mon, 12 Sep 2011 15:55:26 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Maile Ohye References: <20110829144145.31952.69055.idtracker@ietfa.amsl.com> <4E5D06EA.9040205@gmx.de> <4E5DB9B8.70006@gmail.com> <4E5DD2BF.40801@gmx.de> <4E5DE57B.8070801@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040006070309090709030507" 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: Mon, 12 Sep 2011 12:52:54 -0000 This is a multi-part message in MIME format. --------------040006070309090709030507 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Maile, Could you please justify why do you want to constrain the requirements of your document with HTTP model? Mykyta Yevstifeyev 12.09.2011 9:03, Maile Ohye wrote: > Hi everyone, > > Thanks for the feedback! I'll submit draft-02 which addresses the > issues below: > > 1. CLOSED. M. Yevstifeyev: “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.” > > -- response by M. Ohye: “Updated in abstract of draft-02.” > > 2. CLOSED. M. Yevstifeyev: “ 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). > > -- response by M. Ohye: “Updated to ‘target URI’ in draft-02.” > > 3. CLOSED. M. Yevstifeyev: “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);” > > -- response by M. Ohye: “Added to draft-02.” > > 4. CLOSED. M. Yevstifeyev: “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]);” > > -- response by M. Ohye: “Changed to: > > [ The source URI 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 target="RFC2616"/>) ] > > 5. CLOSED. M. Yevstifeyev: “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.” > > -- response by J. Reschke: “-1. This is useful information. Just > because something is specific doesn't mean it shouldn't be mentioned.” > -- response by M. Ohye: “Yes, we’d like to include restrictions, even > if they are HTTP-specific. Unfortunately, it would be difficult to > mention them clearly while remaining HTTP-agnostic.” > > 6. OPEN. M. Yevstifeyev: “ > 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.” > > -- response by J. Reschke: “+-0.” > -- response by M. Ohye: “We’d prefer not to clutter our point with a > link to the ‘start’ relation, but if we could add it in a footnote, > that would be fine.” > > 7. CLOSED. M. Yevstifeyev: “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.” > > -- response by J. Reschke: “-1.” > > 8. CLOSED. M. Yevstifeyev: “References: > > Why make RFC 2616 and HTML4 spec Normative references? Shouldn't > Informative be OK?” > > -- response by J. Reschke: “For 2616 is makes sense if there are > normative constrains specific for HTTP.” > > Thanks again, > Maile > > On Wed, Aug 31, 2011 at 12:40 AM, Mykyta Yevstifeyev > > wrote: > > 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 > >> > > > > > --------------040006070309090709030507 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Maile,

Could you please justify why do you want to constrain the requirements of your document with HTTP model?

Mykyta Yevstifeyev

12.09.2011 9:03, Maile Ohye wrote:
Hi everyone,

Thanks for the feedback! I'll submit draft-02 which addresses the issues below:

1. CLOSED. M. Yevstifeyev: “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.”

-- response by M. Ohye: “Updated in abstract of draft-02.”

2. CLOSED. M. Yevstifeyev: “ 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).

-- response by M. Ohye: “Updated to ‘target URI’ in draft-02.”

3. CLOSED. M. Yevstifeyev: “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);”

-- response by M. Ohye: “Added to draft-02.”

4. CLOSED. M. Yevstifeyev: “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]);”

-- response by M. Ohye: “Changed to:

[ The source URI 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 <xref target="RFC2616"/>) ]

5. CLOSED. M. Yevstifeyev: “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.”

-- response by J. Reschke: “-1. This is useful information. Just because something is specific doesn't mean it shouldn't be mentioned.”
-- response by M. Ohye: “Yes, we’d like to include restrictions, even if they are HTTP-specific. Unfortunately, it would be difficult to mention them clearly while remaining HTTP-agnostic.”

6. OPEN. M. Yevstifeyev: “ 
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.”

-- response by J. Reschke: “+-0.”
-- response by M. Ohye: “We’d prefer not to clutter our point with a link to the ‘start’ relation, but if we could add it in a footnote, that would be fine.”

7. CLOSED. M. Yevstifeyev: “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.”

-- response by J. Reschke: “-1.”

8. CLOSED. M. Yevstifeyev: “References:

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

-- response by J. Reschke: “For 2616 is makes sense if there are normative constrains specific for HTTP.”

Thanks again,
Maile

On Wed, Aug 31, 2011 at 12:40 AM, Mykyta Yevstifeyev <evnikita2@gmail.com> wrote:
> 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
> <URI-Reference> from RFC 5988:
>
>>   Link           = "Link" ":" #link-value
>>   link-value     = "<" URI-Reference">" *( ";" link-param )
>
> and, correspondingly, the target URI *is* (rather than *MAY be*)
> <URI-Reference>.  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
>>
>
>


--------------040006070309090709030507-- From julian.reschke@gmx.de Mon Sep 12 05:57: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 E35B621F852E for ; Mon, 12 Sep 2011 05:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.559 X-Spam-Level: X-Spam-Status: No, score=-104.559 tagged_above=-999 required=5 tests=[AWL=-1.960, 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 ofTBTGbJQXJt for ; Mon, 12 Sep 2011 05:57:55 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 09D8221F8512 for ; Mon, 12 Sep 2011 05:57:54 -0700 (PDT) Received: (qmail invoked by alias); 12 Sep 2011 12:59:56 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp059) with SMTP; 12 Sep 2011 14:59:56 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+X0yFFm5eXA8am/OzP64CIEypwVzTo1EABSHh5mt kOnrlT8wE/oijf Message-ID: <4E6E0243.6040709@gmx.de> Date: Mon, 12 Sep 2011 14:59:47 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Mykyta Yevstifeyev References: <20110829144145.31952.69055.idtracker@ietfa.amsl.com> <4E5D06EA.9040205@gmx.de> <4E5DB9B8.70006@gmail.com> <4E5DD2BF.40801@gmx.de> <4E5DE57B.8070801@gmail.com> <4E6E013E.6080404@gmail.com> In-Reply-To: <4E6E013E.6080404@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "link-relations@ietf.org" , apps-discuss@ietf.org, Maile Ohye , draft-ohye-canonical-link-relation@tools.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: Mon, 12 Sep 2011 12:57:56 -0000 On 2011-09-12 14:55, Mykyta Yevstifeyev wrote: > Maile, > > Could you please justify why do you want to constrain the requirements > of your document with HTTP model? > > Mykyta Yevstifeyev > ... I believe that while the link relation itself is not restricted to specific protocols, it still makes sense to explain how it should be used with HTTP URIs. Best regards, Julian From stpeter@stpeter.im Mon Sep 12 09:31: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 073C021F8678 for ; Mon, 12 Sep 2011 09:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 dUSi2XgGfXGT for ; Mon, 12 Sep 2011 09:31:38 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6858321F85AA for ; Mon, 12 Sep 2011 09:31:38 -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 CCC4F419CB; Mon, 12 Sep 2011 10:36:52 -0600 (MDT) Message-ID: <4E6E3466.30705@stpeter.im> Date: Mon, 12 Sep 2011 10:33:42 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: SM References: <20110829144145.31952.69055.idtracker@ietfa.amsl.com> <4E5D06EA.9040205@gmx.de> <4E5DB9B8.70006@gmail.com> <4E5DD2BF.40801@gmx.de> <4E5DE57B.8070801@gmail.com> <4E6DD135.2090102@gmx.de> <6.2.5.6.2.20110912030202.09feb7f0@resistor.net> In-Reply-To: <6.2.5.6.2.20110912030202.09feb7f0@resistor.net> 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: draft-ohye-canonical-link-relation@tools.ietf.org, apps-discuss@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: Mon, 12 Sep 2011 16:31:39 -0000 On 9/12/11 4:07 AM, SM wrote: > At 02:30 12-09-2011, Julian Reschke wrote: >> At this point I believe you should send a request for publication to >> the IESG (iesg@ietf.org). If all goes well, the next step will be an >> IETF-wide Last Call, which > > "If you wish to seek Area Director sponsorship for an > individual submission, the best solution is to contact the > most relevant Area Director directly, with an explanation of > why the draft is appropriate for IETF publication. The Area > Director is also the best source of advice about whether an > existing WG, or a BoF, may be applicable." > > See http://tools.ietf.org/area/app/ I already told authors that I would sponsor this I-D. Peter -- Peter Saint-Andre https://stpeter.im/ From evnikita2@gmail.com Mon Sep 12 09:32:10 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4F221F8B40; Mon, 12 Sep 2011 09:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 NWMApxW7wA5O; Mon, 12 Sep 2011 09:32:09 -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 43A3C21F8B3B; Mon, 12 Sep 2011 09:32:09 -0700 (PDT) Received: by fxd18 with SMTP id 18so1328408fxd.31 for ; Mon, 12 Sep 2011 09:34: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=X7+zTHiWzwJKWZt4MlPv8JMIcSg0KU7nqrneWgGCSmE=; b=qaek14aA4MAwQn70ydVp56ZDOCCCOOgcq/xHj0m1RCmOy4xp11IbI2SNlygMOKIeBV qeT0oOfLJqzmZf8Rlfg4w0qdLq/CcSSE8wZOVCfNnJu55PLAxfzXt46aKCEuML5fMghH FqSJutfV0S/85ZSsFy6D08Y3nQazTQtkmQA6s= Received: by 10.223.14.133 with SMTP id g5mr1231439faa.69.1315845252399; Mon, 12 Sep 2011 09:34:12 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id h22sm9308948fag.15.2011.09.12.09.34.10 (version=SSLv3 cipher=OTHER); Mon, 12 Sep 2011 09:34:11 -0700 (PDT) Message-ID: <4E6E34A3.2040708@gmail.com> Date: Mon, 12 Sep 2011 19:34:43 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 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> <4E5DE57B.8070801@gmail.com> <4E6E013E.6080404@gmail.com> <4E6E0243.6040709@gmx.de> In-Reply-To: <4E6E0243.6040709@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "link-relations@ietf.org" , apps-discuss@ietf.org, Maile Ohye , draft-ohye-canonical-link-relation@tools.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: Mon, 12 Sep 2011 16:32:10 -0000 12.09.2011 15:59, Julian Reschke wrote: > On 2011-09-12 14:55, Mykyta Yevstifeyev wrote: >> Maile, >> >> Could you please justify why do you want to constrain the requirements >> of your document with HTTP model? >> >> Mykyta Yevstifeyev >> ... > > I believe that while the link relation itself is not restricted to > specific protocols, it still makes sense to explain how it should be > used with HTTP URIs. There are plenty of other URI schemes, beyond 'http' and 'https', and I don't see reasons we may overlook them defining semantics for these two only. Otherwise, the authors should have "The 'canonical' link relation type for 'http' and 'https' URIs" rather than "The 'canonical' link relation type" in the title. BTW, there already is a -02 version: http://tools.ietf.org/html/draft-ohye-canonical-link-relation-02. However, there are still the two places where some requirements are constrained by HTTP protocol: > o A URI that serves a 4xx error code (Section 10.4 of [RFC2616]). and > 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. And I still think this HTTP-centric approach is unacceptable. Mykyta Yevstifeyev > > Best regards, Julian > From internet-drafts@ietf.org Tue Sep 13 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 B795921F8BB1; Tue, 13 Sep 2011 10:07:05 -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 RSeg8h+Ppdi7; Tue, 13 Sep 2011 10:07:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E1C21F8B82; Tue, 13 Sep 2011 10:07:05 -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: <20110913170705.8169.5544.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2011 10:07:05 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-xdash-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, 13 Sep 2011 17:07:05 -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 : Deprecating Use of the "X-" Prefix in Applicat= ion Protocols Author(s) : Peter Saint-Andre D. Crocker Mark Nottingham Filename : draft-ietf-appsawg-xdash-00.txt Pages : 12 Date : 2011-09-13 Historically, designers and implementers of application protocols have often distinguished between "standard" and "non-stan= dard" parameters by prefixing the latter with the string "X-" or sim= ilar constructions. 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-ietf-appsawg-xdash-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-xdash-00.txt From barryleiba@gmail.com Tue Sep 13 10:15: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 D12AE21F8C51; Tue, 13 Sep 2011 10:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.007 X-Spam-Level: X-Spam-Status: No, score=-103.007 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 nallJSQ3T8re; Tue, 13 Sep 2011 10:15:47 -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 DA1B421F8C4E; Tue, 13 Sep 2011 10:15:46 -0700 (PDT) Received: by gyd12 with SMTP id 12so727665gyd.31 for ; Tue, 13 Sep 2011 10:17:53 -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:cc:content-type; bh=OVUc9CQyoPnmNiJyLEG99nuJ4uN/Xa3oc+f1kXQ8c1w=; b=FfxHCBuBPlaLVXD+nMVEVRN2MWCJA8TjQw2wAY9BPBv+Zg14tqedjbVEoXbk4TLmPc k06z90dAlh1hlG7CLGiGIzynur7mriYz7HOsdM4PWKFK1uKdicjeanCkR413xlwdy7nA 0B3GgpSEZXG1zRCwkbI3brNe5OQt7HD3gB6yc= MIME-Version: 1.0 Received: by 10.236.145.10 with SMTP id o10mr35810021yhj.90.1315934273391; Tue, 13 Sep 2011 10:17:53 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.203.68 with HTTP; Tue, 13 Sep 2011 10:17:53 -0700 (PDT) Date: Tue, 13 Sep 2011 13:17:53 -0400 X-Google-Sender-Auth: jfkYQfWQh92cqNa1RJmZf4BQb0Y Message-ID: From: Barry Leiba To: apps-discuss@ietf.org, draft-ietf-sidr-ghostbusters.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: iesg@ietf.org Subject: [apps-discuss] apps-team review of draft-ietf-sidr-ghostbusters-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2011 17:15:48 -0000 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-sidr-ghostbusters-09 Title: The RPKI Ghostbusters Record Summary: This draft is ready for publication as a Proposed Standard, with just some very minor tweaking requested. -------------------- Major Issues: Section 1, paragraph 2: OLD lead to the worrisome certificate's or CRL's maintainer. So, "Who do you call?" NEW lead to the worrisome certificate's or CRL's maintainer. So, "Who you gonna call?" REFERENCE: http://www.youtube.com/watch?v=m9We2XsVZfc -------------------- Minor Issues: vCard does use the term "type", unfortunately. The problem is that a "type" in vCard is generally something different, and in the RFC we missed some instances of inconsistent use. But the proper vCard term for what you want here is "property". So: Section 3: OLD An example of an RPKI Ghostbusters Record payload with all types populated is as follows: NEW An example of an RPKI Ghostbusters Record payload with all properties populated is as follows: Section 4: OLD The goal in profiling the vCARD is not to include as much information as possible, but rather to include as few types as possible while NEW The goal in profiling the vCard is not to include as much information as possible, but rather to include as few properties as possible while OLD Per [RFC6350], the BEGIN, VERSION, FN, N, and END types MUST be included in a record. To be useful, one or more of ADR, TEL, and EMAIL MUST be included. Other types MUST NOT be included. NEW Per [RFC6350], the BEGIN, VERSION, FN, N, and END properties MUST be included in a record. To be useful, one or more of ADR, TEL, and EMAIL MUST be included. Other properties MUST NOT be included. -------------------- Nits: Throughout: RFC 6350 uses "vCard", while this document uses "vCARD". It's not a big thing, but it's easy to be consistent with 6350 and switch to "vCard". Section 7: OLD Though there is no on the wire protocol in this specification, NEW Though there is no on-the-wire protocol in this specification, -------------------- Barry From cyrus@daboo.name Tue Sep 13 11:01: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 0F68921F8A7D; Tue, 13 Sep 2011 11:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.679 X-Spam-Level: X-Spam-Status: No, score=-102.679 tagged_above=-999 required=5 tests=[AWL=-0.080, 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 i4zHootbnLob; Tue, 13 Sep 2011 11:01:30 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by ietfa.amsl.com (Postfix) with ESMTP id 43BE211E808E; Tue, 13 Sep 2011 11:01:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 5B44019D2D51; Tue, 13 Sep 2011 14:03:36 -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 2pK1DDLEOIP5; Tue, 13 Sep 2011 14:03:30 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 6CBC719D2D43; Tue, 13 Sep 2011 14:03:28 -0400 (EDT) Date: Tue, 13 Sep 2011 14:03:24 -0400 From: Cyrus Daboo To: apps-discuss@ietf.org, draft-ietf-sidr-ghostbusters.all@tools.ietf.org Message-ID: In-Reply-To: References: 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=1030 Cc: Barry Leiba , iesg@ietf.org Subject: Re: [apps-discuss] apps-team review of draft-ietf-sidr-ghostbusters-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2011 18:01:31 -0000 Hi, --On September 13, 2011 1:17:53 PM -0400 Barry Leiba wrote: > NEW > Per [RFC6350], the BEGIN, VERSION, FN, N, and END properties MUST be > included in a record. To be useful, one or more of ADR, TEL, and > EMAIL MUST be included. Other properties MUST NOT be included. Actually vcard does not require the N property to be present, only VERSION and FN in addition to BEGIN/END (as per ). Note: vcard v3 used to require that N was present, but that requirement was dropped in vcard v4. Also, would it not make sense to include IMPP () as one of the allowed properties? Seems like that matches the intent of using EMAIL and TEL. The "Other types MUST NOT be included." is perhaps a little strong. I can certainly see situations where it might be useful to have other properties such as SOURCE, KIND or REV present. Perhaps that can be changed to a "SHOULD NOT"? -- Cyrus Daboo From barryleiba@gmail.com Tue Sep 13 11:09:19 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A20321F8B73; Tue, 13 Sep 2011 11:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.007 X-Spam-Level: X-Spam-Status: No, score=-103.007 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 ObYdg3lFIi2h; Tue, 13 Sep 2011 11:09:18 -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 8EC4821F8B21; Tue, 13 Sep 2011 11:09:18 -0700 (PDT) Received: by yxt33 with SMTP id 33so779772yxt.31 for ; Tue, 13 Sep 2011 11:11:25 -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=jqKViO941gBGG3N9q2bQ+nyLSgrgL2vHHgT01PTOCEw=; b=fGYwM2E3fDoMQSAqhYxoXhaUipTakBLZIe/GT6FbLjexacNyQ+lZ/cZjDt7iOWtz1n npUeZemWsU4Cb7j5om2kADThby7S5FqfM4RokySJ7BfMfi7qdCG80CFLZvesSF43oukB ufMKnXTPSLVm5f2eo4Uk9ZUy+di3BW86smJhM= MIME-Version: 1.0 Received: by 10.236.73.195 with SMTP id v43mr36570687yhd.5.1315937484619; Tue, 13 Sep 2011 11:11:24 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.203.68 with HTTP; Tue, 13 Sep 2011 11:11:24 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Sep 2011 14:11:24 -0400 X-Google-Sender-Auth: 0LUUhyWR98vJHhVroKr2ouqpOso Message-ID: From: Barry Leiba To: Cyrus Daboo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-sidr-ghostbusters.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] apps-team review of draft-ietf-sidr-ghostbusters-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2011 18:09:19 -0000 >> NEW >> =A0 Per [RFC6350], the BEGIN, VERSION, FN, N, and END properties MUST be >> =A0 included in a record. =A0To be useful, one or more of ADR, TEL, and >> =A0 EMAIL MUST be included. =A0Other properties MUST NOT be included. > > Actually vcard does not require the N property to be present, only VERSIO= N > and FN in addition to BEGIN/END (as per > ). I took the requirement as one that comes from SIDR, not from vCard... > Note: vcard v3 used to require that N was present, but that requirement w= as > dropped in vcard v4. ...but it's possible that SIDR included "N" because vCard v3 did, and they didn't know they could drop it now. Good catch, and they can decide whether they want it in or not. > The "Other types MUST NOT be included." is perhaps a little strong. I can > certainly see situations where it might be useful to have other propertie= s > such as SOURCE, KIND or REV present. Perhaps that can be changed to a > "SHOULD NOT"? It seems clear from the SIDR doc that they very much *want* a MUST NOT. For their use case, it's not too strong; it's exactly what they want in order to keep this record simple. They could certainly extend this later, allowing additional properties if such turn out to make sense for their use case. Barry From barryleiba@gmail.com Tue Sep 13 14:07: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 0443221F8CC2; Tue, 13 Sep 2011 14:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.007 X-Spam-Level: X-Spam-Status: No, score=-103.007 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 C4bGxQFzbQPY; Tue, 13 Sep 2011 14:07:25 -0700 (PDT) Received: from mail-gx0-f170.google.com (mail-gx0-f170.google.com [209.85.161.170]) by ietfa.amsl.com (Postfix) with ESMTP id 622AC21F84DD; Tue, 13 Sep 2011 14:07:25 -0700 (PDT) Received: by gxk27 with SMTP id 27so1486093gxk.15 for ; Tue, 13 Sep 2011 14:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=NqR86nI51n9zZtt0MKQsy5BRLIMEigiozTvKQhQ+Tcw=; b=ppRi/xNg9bKQd5N/EV6DvxRT+B817RDWSF2JbAWASjRPbzw5LRTDVsJfX97NIdT9br x/QlgHy/ay93xSkvOClSuID+jDh9iU7m8nAHfODVJZSdmpU1KTSN0f2XJ0m5m+J2eaPd eBBAIAA+7hV5x1O3SoDkUDC79+Fr6p4tNha5Y= MIME-Version: 1.0 Received: by 10.236.189.42 with SMTP id b30mr37221410yhn.73.1315948170733; Tue, 13 Sep 2011 14:09:30 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.203.68 with HTTP; Tue, 13 Sep 2011 14:09:30 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Sep 2011 17:09:30 -0400 X-Google-Sender-Auth: xTMnvNK__l7eTW2ESyRNZc_U_Gk Message-ID: From: Barry Leiba To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-sidr-ghostbusters.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] apps-team review of draft-ietf-sidr-ghostbusters-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2011 21:07:26 -0000 >>> Actually vcard does not require the N property to be present, only VERSION >>> and FN in addition to BEGIN/END (as per >>> ). > > i will probably drop unless you can explain to me the value it adds. I think dropping "N" is the right answer. Barry From barryleiba@gmail.com Tue Sep 13 16: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 E416421F8B3D; Tue, 13 Sep 2011 16:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.007 X-Spam-Level: X-Spam-Status: No, score=-103.007 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 VDkz4UV7PlPH; Tue, 13 Sep 2011 16:14:18 -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 50F6621F8B35; Tue, 13 Sep 2011 16:14:18 -0700 (PDT) Received: by yxt33 with SMTP id 33so1027883yxt.31 for ; Tue, 13 Sep 2011 16:16:24 -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=7QYw8tJeyNpsyyhYVyHdHWy3xQ0672uT3xqLgXlj/zU=; b=nFsI8qqJOmhMyF+qx4hISJto9QJvc2kX9wgv3KdjWp8pe8pmTUbfZ4GQO19zTLlve4 oMWNsesXqkbDYAxp2DIlKRYSeYOgn5ppkHyRGYPL7hlhjoMhe56Q29MeKh4PflTuPJP+ xXgWF8QVyEFkuZgLdd4kvWvznf0/BKUhcqu68= MIME-Version: 1.0 Received: by 10.236.77.195 with SMTP id d43mr38062726yhe.22.1315955784517; Tue, 13 Sep 2011 16:16:24 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.203.68 with HTTP; Tue, 13 Sep 2011 16:16:24 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Sep 2011 19:16:24 -0400 X-Google-Sender-Auth: Fsd-Np_DI35Du1UG9JNlDdvoLz0 Message-ID: From: Barry Leiba To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-sidr-ghostbusters.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] apps-team review of draft-ietf-sidr-ghostbusters-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2011 23:14:19 -0000 > how is this? > if no squeals by my, currently euro, morning, i will submit it. Apart from the nits, which I'm not going to beat on, there's still this: > Per [RFC6350], the BEGIN, VERSION, FN, N, and END properties MUST be > included in a record. To be useful, one or more of ADR, TEL, and > EMAIL MUST be included. Other properties MUST NOT be included. ...which needs its "N" removed. > thanks for the help! You're very welcome. Barry From sm@elandsys.com Wed Sep 14 01:56: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 589DD21F8C49 for ; Wed, 14 Sep 2011 01:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.907 X-Spam-Level: X-Spam-Status: No, score=-101.907 tagged_above=-999 required=5 tests=[AWL=-0.704, 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 XxNJ+-wk7kq7 for ; Wed, 14 Sep 2011 01:56:14 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 39F4221F8C06 for ; Wed, 14 Sep 2011 01:56:14 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.20]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p8E8w4Un021672; Wed, 14 Sep 2011 01:58:13 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1315990695; bh=+7ltSNfKCpIhckQFHx4dYodTByM=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type: Content-Transfer-Encoding; b=NoPLI+NMjnmr4oRTXFZLZ/g4oDs3WFahDsPvLPU12EPAhjQWdevrga4w+Z4DPg6Tl srjSP/jjP5l6pOFCvpqhzcKiKtwd9RuCPg96uEDnf08aQ/TjFIPKOPCYJjti/wjmv1 k48ydDKMO7WS84AEAQCsnpLbSd9RqT5Xb9JsWblo= Message-Id: <6.2.5.6.2.20110914015457.08f2dd68@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 14 Sep 2011 01:57:49 -0700 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-mif-dns-server-selection@tools.ietf.org Subject: [apps-discuss] Fwd: [apps-review] apps-team review of draft-ietf-mif-dns-server-selection X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2011 08:56:16 -0000 I am forwarding the review performed by Murray S. Kucherawy: I have been selected as the Applications Area=20 Review Team reviewer for this draft (for=20 background on apps-review, please see=20 http://www.a= pps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any=20 other Last Call comments you may receive. Please=20 wait for direction from your document shepherd or=20 AD before posting a new version of the draft. Document: draft-ietf-mif-dns-server-selection-03 Title: Improved DNS Server Selection for Multi-Homed Nodes Reviewer: Murray S. Kucherawy Review Date: September 13, 2011 IETF Last Call Date: N/A (not yet in IETF Last Call) IESG Telechat Date: N/A (not scheduled) Summary: This draft is almost ready for=20 publication as a Standards Track RFC but has a=20 few issues that should be fixed before publication. NOTE: This is an early review, so please ignore=20 the parts of this boilerplate that sound as=20 though you=92re in IETF Last Call. Also, this is a=20 review of the -03 version of the draft. A new=20 version was published after I had already=20 completed a good part of my review, so I=20 completed it based on this version and not the=20 new one. I haven=92t looked at the diffs between the two. Major Issues: =B7 None. Minor Issues: =B7 The IANA Considerations section seems=20 to be a little understated. I would suggest=20 copying the one from RFC3646 and modifying it accordingly. =B7 The use of =93domain=94 in the first=20 paragraph of Section 1 is ambiguous. The word=20 =93domain=94 is unfortunately overloaded to mean=20 management domain, DNS domain, and probably some=20 others, plus the usual dictionary definition. I=20 recommend simply saying =93a solution for=20 IPv6.=94 Don=92t be surprised if a DNS Directorate=20 reviewer complains about this as well. =B7 The document in general makes use of=20 the term =93DNS suffix=94. It could be that I=92ve=20 simply never encountered the term before, but it=20 took me a while of reading to realize this=20 actually meant =93domain name=94. I would suggest=20 clarifying this up front someplace, or changing it to =93domain name=94= throughout. =B7 The last paragraph of Section 2.4 is=20 confusing. It says =93After the interface=20 change[,] a host could have both positive and=20 negative DNS cache entries no longer valid on the=20 new network interface.=94 Should that =93both=85and=94=20 be =93either=85or=94? I=92m not clear on how a single=20 node can have both positive and negative DNS=20 cache entries no longer valid on the new=20 interface, unless you mean some of its cache will=20 be positive and wrong and some of its cache will=20 be negative and wrong (about different names)=20 after the move. This should be clarified. =B7 I found it strange to read RFC2119=20 normative language Section 4.1 which describes an=20 internal-use algorithm for collecting and=20 organizing data learned from DHCP and DHCPv6 to=20 build up a set of rules for deciding which=20 nameserver(s) to use for which queries. The same=20 sort of thing appeared later in Sections 4.5 and=20 4.6. My understanding is that, since DHCP and=20 DHCPv6 are the wire protocols used and this=20 section describes an internal-use mechanism,=20 these bits of the text shouldn=92t include any=20 RFC2119 language; there is nothing here that=20 affects interoperability between two nodes=20 implementing this protocol. If a node=20 implementing this gets it wrong, it only hurts=20 itself; the wire protocols don=92t break. If this=20 section were to be separated into its own=20 document, it would be Informational, not=20 Standards Track. This isn=92t a showstopper for me, but I did find it= unusual. =B7 There are a few places in the document,=20 the Introduction and Section 4.1 for example,=20 that talk about PTR lookup requests matching=20 specific IPv6 prefixes. However, the abstract=20 mentions IPv4 support, and the mechanism is also=20 described for IPv4. I suggest making a quick=20 pass through the document to be sure it doesn=92t=20 appear as if IPv6 is the focus and IPv4 was added in as an after-thought. =B7 The normative language in Section 4.1=20 around DNSSEC seems to be the kind of thing that=20 should be left for local policy. I can envision=20 environments where the client isn=92t doing=20 anything sensitive enough to demand DNSSEC, so=20 the first reply it gets from any nameserver it=20 queried is probably fine. The same sort of thing reappears in Section 4.4. =B7 In Section 4.2, the paragraph starting=20 =93If the OPTION_DNS_SERVER_SELECT contains=85=94 was a=20 little confusing to read. It says in general=20 that when learning about DNS servers available,=20 the node can update what it knows but can=92t=20 forget what it=92s learned, however it can ignore=20 things it chooses to ignore. I found this=20 difficult to follow. Some expansion of this=20 paragraph, perhaps with examples, might help. =B7 At the end of Section 4.2, it says=20 =93=85use of generic DHCPv6 Information Refresh Time=20 Option, as specified in [RFC4242], is=20 envisaged.=94 That wording is odd; shouldn=92t it be=20 RECOMMENDED? It=92s too vague otherwise. =B7 Section 4.4 says a node MUST NOT use=20 the feature being described here unless=20 specifically configured to do so. That seems=20 odd. Is the intent to have implementations force this feature= off-by-default? =B7 I didn=92t understand this sentence in=20 Section 4.5: =93When both options are received from=20 the same network interface =85, the resolver MUST=20 make the decision which one to prefer based on preferences.=94 =B7 Section 7 says =93To ensure nodes=92=20 routing =85 works correctly, network administrators=20 should also deploy related technologies for that=20 purpose.=94 Are there any that can be suggested or referenced here? =B7 Appendix A is called =93Best Current=20 Practice=94, but the first section starts out =93A=20 possible current practice=85=94 Where=92s the best one, and why is it best? Nits: =B7 There are a few places where I saw=20 RFC2119 words used in non-normative ways, such as=20 the last sentence of Section 3.1 or the middle of=20 Section 7. I would suggest considering alternate=20 words like =93might=94 in place of =93may=94 specifically to avoid such= issues. =B7 There=92s a discussion point at the end=20 of Section 4.1 that asks =93What about those DNS=20 servers that instead of a negative answer always=20 return positive reply with an IP address of some=20 captive portal?=94 I don=92t think software=20 implementing this specification can determine=20 that via a DHCP query without other supporting=20 changes to the infrastructure. I suggest not trying to tackle this point. =B7 In Section 4.3, Figure 6, the order of=20 =93DNS-recusrive-name-server=94 and =93prf=94 in the=20 description should be swapped to match the order=20 in which they appear in the diagram. =B7 In Section 5, the explanation bullets=20 under Figure 7 include two DHCPv6 replies. The=20 second one covered =93example.com=94 and a specific=20 IPv6 suffix, but it=92s not clear that there was no=20 overlap with the first one (i.e., the first one=20 could=92ve said the same thing). It should be made=20 clear that they had disjoint replies. =B7 In several places there are references=20 to =93chapters=94 instead of =93sections=94 or the=20 =93section=94 reference is not capitalized, which=20 xml2rfc does for you. It seems then these are=20 manual references rather than automatic ones,=20 though the document does claim to have been=20 produced by xml2rfc. You might make your life=20 easier by changing them to tags. =B7 Section 10 might be improved by=20 dividing separate topics into their own=20 subsections. For example, the first three=20 paragraphs could become Section 10.1, and the=20 remaining two could go in 10.2 and 10.3. =B7 Appendix A.1 uses the term =93hotspot=94=20 which is colloquial and might even be=20 trademarked. I suggest =93wireless network=94. =B7 The document is in need of a full edit=20 pass with attention to corrections of English grammar. _______________________________________________ apps-review mailing list apps-review@ietf.org https://www.ietf.org/mailman/listinfo/apps-review From sm@elandsys.com Wed Sep 14 02:20:54 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A9821F8C95 for ; Wed, 14 Sep 2011 02:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 bsWBU+FSxZPQ for ; Wed, 14 Sep 2011 02:20:51 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id AD54421F8C61 for ; Wed, 14 Sep 2011 02:20:51 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.20]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p8E9Mrpn022760 for ; Wed, 14 Sep 2011 02:22:59 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1315992180; bh=W2yZRwwgZB3uEuvEJDQhap7PzWU=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type; b=y6DdeGJ4GChXk+9MvpmiU/eWTTrlSeX/Tfz/kRD1uxS2jXiH1gupOi1qEr/DoIRWy VGgeygYPyyW82p4bgURyggJLfCkDCz/Vj6gUJjjhBQMvXZR8RrcFDLP18DB220xKTj hV4TfSEbPpTq9NQIAequ7enUG6+qe00WirL+/ryE= Message-Id: <6.2.5.6.2.20110914022059.09f04af0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 14 Sep 2011 02:22:46 -0700 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] Fwd: Review of -- draft-ietf-appsawg-rfc3462bis-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 09:20:54 -0000 I am forwarding the review performed by Dave Crocker. I've been asked to do an appsarea review of this draft. Review: Title: The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages draft-ietf-appsawg-rfc3462bis-00 Reviewer: D. Crocker Review Date: 8 Sept 11 Summary: Multipart/Report is an established format for sending reports. It is defined as a MIME media type, motivated by the need to have a standardized format for sending email handling reports. (After the end of an SMTP transfer session, the receiving server still might need to report back to the author or originator. It must send this in an independent email. This media type provides a standardized means of packaging and identifying such reports.) The draft promises a set of minor, non-normative document cleanup changes, and one significant normative change, that of removing a restriction on use of the media type. This change permits the media type to be nested within a MIME structure, rather than being limited to the top level. The restriction was motivated by the original, primary usage scenario for email reporting, but has proved problematic for other scenarios, including something as simple as forwarding a received report(!) Major Issues: None. In pedagogical terms, the need for this change demonstrates the important difference between documenting a usage restriction that applies only to a particular scenario, versus imposing an inherent restriction to the underlying data type. Confusing the two limits utility of the data type. (Formally, the confusion here was between the "packaging" of the data type and the scenario usage of the data type.) Minor Issues: Appendix A (Document History) needs a note to the RFC Editor to remove the section before publishing. Nits: The document repairs non-normative usage of normative vocabulary, to eliminate confusion. It also changes normative vocabulary to be upper case, to aid detection. However it appears that some of these changes were missed: > 3. The multipart/report Media Type ... > generated, for a human reader who may not have a user agent may -> might > report. The text in the first section may be in any MIME may -> MAY {{ I believe. /d }} > details not present in the first body part that may be useful to may -> might > Return of content may be wasteful of network bandwidth and a variety may -> can > 4. The text/rfc822-headers Media Type ... > to make them legal 7-bit content, they may be encoded with quoted- may -> MAY > 6. Security Considerations ... > reports may cause the sender to incorrectly believe a message was may -> can d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ apps-review mailing list apps-review@ietf.org https://www.ietf.org/mailman/listinfo/apps-review From randy@psg.com Tue Sep 13 14:04: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 30B4821F8C4E; Tue, 13 Sep 2011 14:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 oVq78rJgP-bd; Tue, 13 Sep 2011 14:04:56 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id BC0AF21F8C4C; Tue, 13 Sep 2011 14:04:56 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R3aC3-000CqK-8l; Tue, 13 Sep 2011 21:06:59 +0000 Date: Tue, 13 Sep 2011 23:07:00 +0200 Message-ID: From: Randy Bush To: Barry Leiba In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 14 Sep 2011 08:19:04 -0700 Cc: draft-ietf-sidr-ghostbusters.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] apps-team review of draft-ietf-sidr-ghostbusters-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2011 21:04:57 -0000 >>> NEW >>> =A0 Per [RFC6350], the BEGIN, VERSION, FN, N, and END properties MUST be >>> =A0 included in a record. =A0To be useful, one or more of ADR, TEL, and >>> =A0 EMAIL MUST be included. =A0Other properties MUST NOT be included. >> >> Actually vcard does not require the N property to be present, only VERSI= ON >> and FN in addition to BEGIN/END (as per >> ). >> Note: vcard v3 used to require that N was present, but that requirement = was >> dropped in vcard v4. i will probably drop unless you can explain to me the value it adds. >> The "Other types MUST NOT be included." is perhaps a little strong. I can >> certainly see situations where it might be useful to have other properti= es >> such as SOURCE, KIND or REV present. Perhaps that can be changed to a >> "SHOULD NOT"? >=20 > It seems clear from the SIDR doc that they very much *want* a MUST > NOT. For their use case, it's not too strong; it's exactly what they > want in order to keep this record simple. They could certainly extend > this later, allowing additional properties if such turn out to make > sense for their use case. 'zactly we want to be brutally minimalist. randy From randy@psg.com Tue Sep 13 14:13: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 6A40E11E80AD; Tue, 13 Sep 2011 14:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 KoFrny67IsQ1; Tue, 13 Sep 2011 14:13:29 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id D9AB611E80B8; Tue, 13 Sep 2011 14:13:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R3aKN-000Csc-ON; Tue, 13 Sep 2011 21:15:36 +0000 Date: Tue, 13 Sep 2011 23:15:36 +0200 Message-ID: From: Randy Bush To: Barry Leiba In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Wed, 14 Sep 2011 08:19:19 -0700 Cc: draft-ietf-sidr-ghostbusters.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] apps-team review of draft-ietf-sidr-ghostbusters-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2011 21:13:30 -0000 >>>> Actually vcard does not require the N property to be present, only VERSION >>>> and FN in addition to BEGIN/END (as per >>>> ). >> i will probably drop unless you can explain to me the value it adds. > I think dropping "N" is the right answer. thank you! randy From randy@psg.com Tue Sep 13 14: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 62FD611E80F1; Tue, 13 Sep 2011 14:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] 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 n3hVzQqIzJ2J; Tue, 13 Sep 2011 14:18:52 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 34CCF11E80EC; Tue, 13 Sep 2011 14:18:52 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R3aPZ-000Cta-Pw; Tue, 13 Sep 2011 21:20:58 +0000 Date: Tue, 13 Sep 2011 23:20:56 +0200 Message-ID: From: Randy Bush To: Barry Leiba In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Wed, 14 Sep 2011 08:19:32 -0700 Cc: draft-ietf-sidr-ghostbusters.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] apps-team review of draft-ietf-sidr-ghostbusters-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2011 21:18:53 -0000 how is this? if no squeals by my, currently euro, morning, i will submit it. thanks for the help! randy Network Working Group R. Bush Internet-Draft Internet Initiative Japan Intended status: Standards Track September 13, 2011 Expires: March 16, 2012 The RPKI Ghostbusters Record draft-ietf-sidr-ghostbusters-10 Abstract In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information which might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This draft describes the RPKI Ghostbusters Record containing human contact information which may be verified (indirectly) by a CA certificate. The data in the record are those of a severely profiled vCARD. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 16, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Bush Expires March 16, 2012 [Page 1] Internet-Draft The RPKI Ghostbusters Record September 2011 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . 4 3. RPKI Ghostbusters Record Payload Example . . . . . . . . . . . 4 4. vCARD Profile . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. CMS Packaging . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.2. File Extension . . . . . . . . . . . . . . . . . . . . . . 6 8.3. Media Type . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Bush Expires March 16, 2012 [Page 2] Internet-Draft The RPKI Ghostbusters Record September 2011 1. Introduction In the operational use of the RPKI it can become necessary to contact, human to human, the party responsible for a resource-holding CA certificate, AKA the certificate's maintainer, be it the holder of the certificate's private key or an administrative person in the organization, a NOC, .... An important example is when the operator of a prefix described by a Route Origin Authorization (ROA) sees a problem, or an impending problem, with a certificate or CRL in the path between the ROA and a trust anchor. E.g., a certificate along that path has expired, is soon to expire, or a CRL associated with a CA along the path is stale, thus placing the quality of the routing of the address space described by the ROA in jeopardy. As the names in RPKI certificates are not meaningful to humans, see [I-D.ietf-sidr-cp], there is no way to use a certificate itself to lead to the worrisome certificate's or CRL's maintainer. So, "Who do you call?" This document specifies the RPKI Ghostbusters Record, an object verified via an End Entity (EE) certificate, issued under a CA certificate, the maintainer of which may be contacted using the payload information in the Ghostbusters Record. The Ghostbusters Record conforms to the syntax defined in [I-D.ietf-sidr-signed-object]. Note that the Ghostbusters Record is not an identity certificate, but rather an attestation to the contact data made by the maintainer of the CA certificate issuing the EE certificate whose corresponding private key signs the Ghostbusters Record. This record is not meant to supplant or be used as resource registry whois data. It gives information about an RPKI CA certificate maintainer not a resource holder. The Ghostbusters Record is optional, CA certificates in the RPKI MAY have zero or more associated Ghostbuster Records. This specification has three main sections. The first, Section 4, is the format of the contact payload information, a severely profiled vCARD. The second, Section 5, profiles the packaging of the payload as a profile of the RPKI Signed Object Template specification [I-D.ietf-sidr-signed-object]. The third, Section 6, describes the proper validation of the signed Ghostbusters Record. Bush Expires March 16, 2012 [Page 3] Internet-Draft The RPKI Ghostbusters Record September 2011 2. Suggested Reading It is assumed that the reader understands the RPKI, [I-D.ietf-sidr-arch], the RPKI Repository Structure, [I-D.ietf-sidr-repos-struct], Signed RPKI Objects, [I-D.ietf-sidr-signed-object], and vCARDs [RFC6350]. 3. RPKI Ghostbusters Record Payload Example An example of an RPKI Ghostbusters Record payload with all properties populated is as follows: BEGIN:vCard VERSION:4.0 FN:Human's Name ORG:Organizational Entity ADR;TYPE=WORK:;;42 Twisty Passage;Deep Cavern; WA; 98666;U.S.A. TEL;TYPE=VOICE,MSG,WORK:+1-666-555-1212 TEL;TYPE=FAX,WORK:+1-666-555-1213 EMAIL;TYPE=INTERNET:human@example.com END:vCard 4. vCARD Profile The goal in profiling the vCARD is not to include as much information as possible, but rather to include as few properties as possible while providing the minimal necessary data to enable one to contact the maintainer of the RPKI data which threatens the ROA[s] of concern. The Ghostbusters vCARD payload is a minimalist subset of the vCARD as described in [RFC6350]. BEGIN - pro forma packaging which MUST be the first line in the vCARD and MUST have the value "BEGIN:vCARD" as described in [RFC6350]. VERSION - pro forma packaging which MUST be the second line in the vCARD and MUST have the value "VERSION:4.0" as described in 3.6.9 of [RFC6350]. FN - the name, as described in 6.2.1 of [RFC6350], of a contactable person who responsible a the CA certificate. Bush Expires March 16, 2012 [Page 4] Internet-Draft The RPKI Ghostbusters Record September 2011 ORG - an organization as described in 6.6.4 of [RFC6350]. ADR - a postal address as described in 6.3 of [RFC6350]. TEL - a voice and/or fax phone as described in 6.4.1 of [RFC6350]. EMAIL - an Email address as described in 6.4.2 of [RFC6350] END - pro forma packaging which MUST be the last line in the vCARD and MUST have the value "END:vCARD" as described in [RFC6350]. Per [RFC6350], the BEGIN, VERSION, FN, N, and END properties MUST be included in a record. To be useful, one or more of ADR, TEL, and EMAIL MUST be included. Other properties MUST NOT be included. 5. CMS Packaging The Ghostbusters Record is a CMS signed-data object conforming to the Signed Object Template for the Resource Public Key Infrastructure, [I-D.ietf-sidr-signed-object]. The ContentType of a Ghostbusters Record is defined as id-ct- rpkiGhostbusters, and has the numerical value of 1.2.840.113549.1.9.16.1.35. This OID MUST appear both within the eContentType in the encapContentInfo object as well as the ContentType signed attribute in the signerInfo object. See [I-D.ietf-sidr-signed-object]. eContent: The content of a Ghostbusters Record is described above in Section 4 above. Similarly to a ROA, a Ghostbusters Record is verified using an EE certificate issued by the resource-holding CA certificate whose maintainer is described in the vCARD. The EE certificate used to verify the Ghostbusters Record is the one that appears in the CMS data structure which contains the payload defined above. This EE certificate MUST describe its internet number resources using the "inherit" attribute, rather than explicit description of a resource set, see [RFC3779]. 6. Validation The validation procedure defined in Section 3 of Bush Expires March 16, 2012 [Page 5] Internet-Draft The RPKI Ghostbusters Record September 2011 [I-D.ietf-sidr-signed-object] is applied to a Ghostbusters Record. After this procedure has been performed, the Version number type within the payload is checked, and the OCTET STRING containing the vCARD data is extracted. These data are checked against the profile defined in Section 4 of this document. Only if all of these checks pass is the Ghostbusters payload deemed valid and made available to the application that requested the payload. 7. Security Considerations Though there is no on the wire protocol in this specification, there are attacks which could abuse the data described. As the data, to be useful, need to be public, little can be done to avoid this exposure. Phone Numbers: The vCARDs may contain real world telephone numbers which could be abused for telemarketing, abusive calls, etc. Email Addresses: The vCARDs may contain Email addresses which could be abused for purposes of spam. Relying parties are hereby warned that the data in a Ghostbusters Record are self-asserted. These data have not been verified by the CA that issued the CA certificate to the entity that issued the EE certificate used to validate the Ghostbusters Record. 8. IANA Considerations 8.1. OID The IANA is requested to register the OID for the Ghostbusters Record in the registry created by [I-D.ietf-sidr-signed-object] as follows: Name OID Specification ----------------------------------------------------------- Ghostbusters 1.2.840.113549.1.9.16.1.35 [ This document ] 8.2. File Extension The IANA is requested to add an item for the Ghostbusters Record file extension to the RPKI Repository Name Scheme created by [I-D.ietf-sidr-repos-struct] as follows: Filename Extension RPKI Object Reference ----------------------------------------------------------- .gbr Ghostbusters Record [ This document ] Bush Expires March 16, 2012 [Page 6] Internet-Draft The RPKI Ghostbusters Record September 2011 8.3. Media Type The IANA is requested to register the media type application/ rpki-ghostbusters as follows MIME media type name: application MIME subtype name: rpki-ghostbusters Required parameters: None Optional parameters: None Encoding considerations: binary Security considerations: Carries an RPKI Ghostbusters Record [I-D.ietf-sidr-ghostbusters]. Interoperability considerations: None Published specification: This document Applications which use this media type: Any MIME-complaint transport Additional information: Magic number(s): None File extension(s): .gbr Macintosh File Type Code(s): Person & email address to contact for further information: Randy Bush Intended usage: COMMON Author/Change controller: Randy Bush 9. Acknowledgments The author wishes to thank Russ Housley, the authors of [I-D.ietf-sidr-repos-struct], Stephen Kent, Sandy Murphy, Rob Austein, and Michael Elkins for their contributions. 10. References 10.1. Normative References [I-D.ietf-sidr-ghostbusters] Bush, R., "The RPKI Ghostbusters Record", draft-ietf-sidr-ghostbusters-09 (work in progress), September 2011. [I-D.ietf-sidr-repos-struct] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", draft-ietf-sidr-repos-struct-09 (work in progress), July 2011. [I-D.ietf-sidr-signed-object] Bush Expires March 16, 2012 [Page 7] Internet-Draft The RPKI Ghostbusters Record September 2011 Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure", draft-ietf-sidr-signed-object-04 (work in progress), May 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004. [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, August 2011. 10.2. Informative References [I-D.ietf-sidr-arch] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", draft-ietf-sidr-arch-13 (work in progress), May 2011. [I-D.ietf-sidr-cp] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Policy (CP) for the Resource PKI (RPKI", draft-ietf-sidr-cp-17 (work in progress), April 2011. Author's Address Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, Washington 98110 US Phone: +1 206 780 0431 x1 Email: randy@psg.com Bush Expires March 16, 2012 [Page 8] From randy@psg.com Tue Sep 13 20:13:59 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D1C11E80A0; Tue, 13 Sep 2011 20:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzFKJFBXGG4N; Tue, 13 Sep 2011 20:13:58 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C295811E8093; Tue, 13 Sep 2011 20:13:58 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R3fxC-000EGQ-RR; Wed, 14 Sep 2011 03:16:03 +0000 Date: Wed, 14 Sep 2011 05:16:00 +0200 Message-ID: From: Randy Bush To: Barry Leiba In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Wed, 14 Sep 2011 08:19:44 -0700 Cc: draft-ietf-sidr-ghostbusters.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] apps-team review of draft-ietf-sidr-ghostbusters-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2011 03:13:59 -0000 -10 checked in thanks! randy From moore@network-heretics.com Wed Sep 14 09:35: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 EA0A721F8B53 for ; Wed, 14 Sep 2011 09:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 Y4QmF2IWzQz2 for ; Wed, 14 Sep 2011 09:35:39 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 31EB621F8A35 for ; Wed, 14 Sep 2011 09:35:39 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D38562B09E; Wed, 14 Sep 2011 12:37:47 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 14 Sep 2011 12:37:47 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=fK0N/DH/9HEPCgYK0RSGT6RB9Kk=; b=Zu w0MDy1Qm3xGQQPUXCIjC49DfR1M6F4U4CS1+3V9pgmrNAv14kSoTQ9uiZAwbmkqa ikn0RgNyUT2Psre58812BfN1Vlib20fbAq8DXR0fpciKyMCF+9rm973wjXE3mEuH a4GHzqu2IoGv69Grxb53XRUGdR/3xrgODKqCpaNeA= X-Sasl-enc: oNmmr6jg5KLO1gvqL7WGBQfDCMip5dblo7KXNvvA4okC 1316018267 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 04F775E040E; Wed, 14 Sep 2011 12:37:46 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Wed, 14 Sep 2011 12:37:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1084) 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: Wed, 14 Sep 2011 16:35:40 -0000 On Aug 30, 2011, at 2:25 PM, Murray S. Kucherawy wrote: >> -----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 Mail System Administrative Messages >> Author(s) : Murray S. Kucherawy >> Filename : draft-ietf-appsawg-rfc3462bis-00.txt >> Pages : 13 >> Date : 2011-08-29 >=20 > 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!). I'm not happy with the current draft. I would prefer that it say = something about use of multipart/report when generating DSNs and MDNs. I am in agreement that multipart/report should potentially be able to = appear anywhere. e.g. it should be possible to forward a message = containing a multipart/report, and it should be possible for that = forwarded message to fail to be delivered and be included in its = entirety in a DSN. Keith From simon.perreault@viagenie.ca Wed Sep 14 09: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 3D3B421F8B14; Wed, 14 Sep 2011 09:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] 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 O5RU4dvJ3j2p; Wed, 14 Sep 2011 09:37:50 -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 A98B521F8B10; Wed, 14 Sep 2011 09:37:50 -0700 (PDT) Received: from banana.viagenie.ca (nomis80.org [97.107.136.111]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7C96820C96; Wed, 14 Sep 2011 12:39:58 -0400 (EDT) Message-ID: <4E70D8DB.8010507@viagenie.ca> Date: Wed, 14 Sep 2011 12:39:55 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: Randy Bush References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-sidr-ghostbusters.all@tools.ietf.org, Barry Leiba , iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] apps-team review of draft-ietf-sidr-ghostbusters-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2011 16:37:51 -0000 Randy Bush wrote, on 09/13/2011 11:16 PM: > -10 checked in Some additional comments on the vCard example... > BEGIN:VCARD > VERSION:4.0 > FN:Human's Name > ORG:Organizational Entity > ADR;TYPE=WORK:;;42 Twisty Passage;Deep Cavern; WA; 98666;U.S.A. Should be: ADR;TYPE=WORK:;;42 Twisty Passage;Deep Cavern;WA;98666;U.S.A. > TEL;TYPE=VOICE,MSG,WORK:+1-666-555-1212 > TEL;TYPE=FAX,WORK:+1-666-555-1213 Should be: TEL;TYPE=VOICE,TEXT,WORK;VALUE=uri:tel:+1-666-555-1212 TEL;TYPE=FAX,WORK;VALUE=uri:tel:+1-666-555-1213 > EMAIL;TYPE=INTERNET:human@example.com Should be: EMAIL:human@example.com > END:VCARD 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 msk@cloudmark.com Wed Sep 14 09:54:35 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DAA21F8B8F; Wed, 14 Sep 2011 09:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.497 X-Spam-Level: X-Spam-Status: No, score=-103.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 xZfiVPq4AH54; Wed, 14 Sep 2011 09:54:34 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id BCE6E21F8B86; Wed, 14 Sep 2011 09:54:34 -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, 14 Sep 2011 09:56:44 -0700 From: "Murray S. Kucherawy" To: Randy Bush , Barry Leiba Date: Wed, 14 Sep 2011 09:56:43 -0700 Thread-Topic: [apps-discuss] apps-team review of draft-ietf-sidr-ghostbusters-09 Thread-Index: Acxy8g292OylBKrxSG+tuvHIbG5G3gADRn5w 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 Cc: "draft-ietf-sidr-ghostbusters.all@tools.ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] apps-team review of draft-ietf-sidr-ghostbusters-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2011 16:54:35 -0000 I really, truly hate to do this, but: Is there any risk of trouble to the IETF or Randy or anyone for using the n= ame Ghostbusters? I'm reasonably sure someone in Hollywood would be eager = to exert copyright over the name. -MSK From msk@cloudmark.com Wed Sep 14 09:55: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 2762B21F8BA2 for ; Wed, 14 Sep 2011 09:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.497 X-Spam-Level: X-Spam-Status: No, score=-103.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 bIQPUWdQlJQu for ; Wed, 14 Sep 2011 09:55: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 C67DE21F8B8F for ; Wed, 14 Sep 2011 09:55: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; Wed, 14 Sep 2011 09:57:58 -0700 From: "Murray S. Kucherawy" To: Keith Moore Date: Wed, 14 Sep 2011 09:57:56 -0700 Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.txt Thread-Index: Acxy/KdCepw5IgmJRwCPWY7w6abjGgAAqlIQ Message-ID: References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Wed, 14 Sep 2011 16:55:49 -0000 > -----Original Message----- > From: Keith Moore [mailto:moore@network-heretics.com] > Sent: Wednesday, September 14, 2011 9:38 AM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.= txt >=20 > I'm not happy with the current draft. I would prefer that it say > something about use of multipart/report when generating DSNs and MDNs. I think the discussion I've heard so far is satisfied with the fact that th= e DSN and MDN drafts repeat the "top-most" requirement, so there's no need = to assert it here as well (making it a requirement for those and all future= uses of multipart/report, which is exactly what MARF does not want). From moore@network-heretics.com Wed Sep 14 10:06: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 5CADA21F8BBF for ; Wed, 14 Sep 2011 10:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 K4qRZ12zNaOb for ; Wed, 14 Sep 2011 10:06:56 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7972621F8BA9 for ; Wed, 14 Sep 2011 10:06:56 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D45D324CD4; Wed, 14 Sep 2011 13:09:05 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute4.internal (MEProxy); Wed, 14 Sep 2011 13:09:05 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=NnU0/L/znBFq4eMCwJWMlu7Ajhg=; b=MO 72/d4QnZD61CK9Tj8SFE/PqcKVbuxzWBZTO3NVn3N76NZ4ekD0UGe+zfnHKUDUqu VhodAOQxKv0raFHV1VH+rOSUgT4gYmCu2ofeC6LfgP2exbpkHyel+3sJ7IHWZWzD 3JodhVYi3k8WxDoXw1RX3fcIST9XZnQ/cMKiOxJJ0= X-Sasl-enc: aW0kb9dz497sUI+a/am57aFVDyoQ57LdFabDzsy5olN9 1316020145 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id F37F2AC0294; Wed, 14 Sep 2011 13:09:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Wed, 14 Sep 2011 13:09:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <83FC8B77-CD70-4A25-B639-86879F645DDB@network-heretics.com> References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1084) 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: Wed, 14 Sep 2011 17:06:57 -0000 On Sep 14, 2011, at 12:57 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Keith Moore [mailto:moore@network-heretics.com] >> Sent: Wednesday, September 14, 2011 9:38 AM >> To: Murray S. Kucherawy >> Cc: apps-discuss@ietf.org >> Subject: Re: [apps-discuss] I-D Action: = draft-ietf-appsawg-rfc3462bis-00.txt >>=20 >> I'm not happy with the current draft. I would prefer that it say >> something about use of multipart/report when generating DSNs and = MDNs. >=20 > I think the discussion I've heard so far is satisfied with the fact = that the DSN and MDN drafts repeat the "top-most" requirement, so = there's no need to assert it here as well (making it a requirement for = those and all future uses of multipart/report, which is exactly what = MARF does not want). Ok. I won't make an issue about this. I agree that the DSN and MDN = RFCs is the right place to put these restrictions. Keith From barryleiba.mailing.lists@gmail.com Wed Sep 14 10:17: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 08D4921F8669 for ; Wed, 14 Sep 2011 10:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.006 X-Spam-Level: X-Spam-Status: No, score=-103.006 tagged_above=-999 required=5 tests=[AWL=-0.029, 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 nVMc2WhLvVur for ; Wed, 14 Sep 2011 10:17:40 -0700 (PDT) Received: from mail-gx0-f170.google.com (mail-gx0-f170.google.com [209.85.161.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCC921F85FF for ; Wed, 14 Sep 2011 10:17:40 -0700 (PDT) Received: by gxk27 with SMTP id 27so2766142gxk.15 for ; Wed, 14 Sep 2011 10:19: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=/n/0i6ic3HIBWsySOmEYmDcIO6Fmf34In+f2XmbHtxw=; b=q1/hllDuH7liraxl3UwEEKnNvRoL5sgpGGrsOM2Ur2BCpFMWct1qZeTQbSoauM0LzV VseWRHOY9yufEIy7shrF5GsoHIofxxchVH6GqhHir/8bKsNl8ek33/9DTpGmG0MDtqik 7bWqh5YI4L1JIy5J94frBoANcIxoq0HWZj8z8= MIME-Version: 1.0 Received: by 10.236.75.165 with SMTP id z25mr501928yhd.68.1316020789082; Wed, 14 Sep 2011 10:19:49 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.83.8 with HTTP; Wed, 14 Sep 2011 10:19:49 -0700 (PDT) In-Reply-To: <83FC8B77-CD70-4A25-B639-86879F645DDB@network-heretics.com> References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> <83FC8B77-CD70-4A25-B639-86879F645DDB@network-heretics.com> Date: Wed, 14 Sep 2011 13:19:49 -0400 X-Google-Sender-Auth: BA6vNZhiwrsRh3vcm0VlIDbAl3g Message-ID: From: Barry Leiba To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 14 Sep 2011 17:17:41 -0000 > Ok. =A0I won't make an issue about this. =A0 I agree that the DSN and MDN > RFCs is the right place to put these restrictions. I think with this, and with the other comments and reviews so far, this version is ready to have a last call in the working group. Let's give it another week for comments, and say that I will send this to the ADs on 22 September. So final comments, please, by the end of 21 September. Barry, document shepherd From ned.freed@mrochek.com Wed Sep 14 11:40: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 3D38621F8B1F for ; Wed, 14 Sep 2011 11:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 GGetcoxozV4g for ; Wed, 14 Sep 2011 11:40:35 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9C81821F8B0D for ; Wed, 14 Sep 2011 11:40:35 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O61IWICFLC011AU7@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 14 Sep 2011 11:41:11 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O5ZVDZWEIO00RCTX@mauve.mrochek.com>; Wed, 14 Sep 2011 11:41:05 -0700 (PDT) Message-id: <01O61IWEVN0S00RCTX@mauve.mrochek.com> Date: Wed, 14 Sep 2011 11:40:53 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 14 Sep 2011 13:19:49 -0400" References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> <83FC8B77-CD70-4A25-B639-86879F645DDB@network-heretics.com> To: Barry Leiba DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1316025756; bh=FTdDrvyEKOwHrikjw87Fys+sag42qyNn0Q+Sls+78fg=; h=MIME-version:Content-type:Cc:Message-id:Date:From:Subject: In-reply-to:References:To; b=S+V7j+JYW8pJTs01fak0EsMs9b2SXNxQXHLJ59xPdVJZTowXvLdJDU+IMG0A2b+6B X7i0hDFNEwOKwZzNA7CguE6lVVfZeq+ThNw1qwrlFvFP91m4epympnIFlaPnEeyd1T zcBbc3eelOzH+yMzYHyvTuF6Z0cRsESOFn83ZX54= 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: Wed, 14 Sep 2011 18:40:36 -0000 > > Ok.  I won't make an issue about this.   I agree that the DSN and MDN > > RFCs is the right place to put these restrictions. > I think with this, and with the other comments and reviews so far, > this version is ready to have a last call in the working group. Let's > give it another week for comments, and say that I will send this to > the ADs on 22 September. So final comments, please, by the end of 21 > September. Ship it! Ned From randy@psg.com Wed Sep 14 09:52:44 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9A221F8B7E; Wed, 14 Sep 2011 09:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] 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 E3ZkUvDL-+kh; Wed, 14 Sep 2011 09:52:44 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 8082621F8B7D; Wed, 14 Sep 2011 09:52:44 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R3sjW-000GLv-HS; Wed, 14 Sep 2011 16:54:46 +0000 Date: Wed, 14 Sep 2011 18:54:44 +0200 Message-ID: From: Randy Bush To: Simon Perreault In-Reply-To: <4E70D8DB.8010507@viagenie.ca> References: <4E70D8DB.8010507@viagenie.ca> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Wed, 14 Sep 2011 13:12:19 -0700 Cc: draft-ietf-sidr-ghostbusters.all@tools.ietf.org, Barry Leiba , iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] apps-team review of draft-ietf-sidr-ghostbusters-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2011 16:52:45 -0000 as the apps ducks nibbled him to death, he began to realize that the word 'team' in $SUBJECT was very misleading > Some additional comments on the vCard example... > > > BEGIN:VCARD > > VERSION:4.0 > > FN:Human's Name > > ORG:Organizational Entity > > ADR;TYPE=WORK:;;42 Twisty Passage;Deep Cavern; WA; 98666;U.S.A. > > Should be: > ADR;TYPE=WORK:;;42 Twisty Passage;Deep Cavern;WA;98666;U.S.A. > > > TEL;TYPE=VOICE,MSG,WORK:+1-666-555-1212 > > TEL;TYPE=FAX,WORK:+1-666-555-1213 > > Should be: > TEL;TYPE=VOICE,TEXT,WORK;VALUE=uri:tel:+1-666-555-1212 > TEL;TYPE=FAX,WORK;VALUE=uri:tel:+1-666-555-1213 > > > EMAIL;TYPE=INTERNET:human@example.com > > Should be: > EMAIL:human@example.com thanks randy From randy@psg.com Wed Sep 14 09: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 E96FA21F8B6C; Wed, 14 Sep 2011 09:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 oSto-vcY3lbf; Wed, 14 Sep 2011 09:56:57 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB3B21F8B7F; Wed, 14 Sep 2011 09:56:56 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R3sng-000GNy-Vg; Wed, 14 Sep 2011 16:59:05 +0000 Date: Wed, 14 Sep 2011 18:59:02 +0200 Message-ID: From: Randy Bush To: "Murray S. Kucherawy" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Wed, 14 Sep 2011 13:12:19 -0700 Cc: "draft-ietf-sidr-ghostbusters.all@tools.ietf.org" , Barry Leiba , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] apps-team review of draft-ietf-sidr-ghostbusters-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2011 16:56:58 -0000 > Is there any risk of trouble to the IETF or Randy or anyone for using > the name Ghostbusters? I'm reasonably sure someone in Hollywood would > be eager to exert copyright over the name. rathole! From sm@resistor.net Wed Sep 14 13:20: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 25AEC21F8D03 for ; Wed, 14 Sep 2011 13:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxXAHyF5quEc for ; Wed, 14 Sep 2011 13:20:22 -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 CDA9F21F8D0D for ; Wed, 14 Sep 2011 13:20:21 -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 p8EKMNaA022505; Wed, 14 Sep 2011 13:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1316031749; bh=BTXBCMS/I4NmFtykGCj1rEX5QO2x+bUDmajWFWguFd8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=M7HcrCnOpKYrS63WXCNcc6zohTsOazvt1zAcYzz51PSMmye9qKTc74LAebHL9pOrN XgZy8WBVfVIs/ohm8kmE/pxwZtmO9P3R5+Ez6b6ObMrQ+/YaVAEazRVWROTPnD+QXM VroR6cclnbrLFCm4vz16lqUtV704HcaYv9m7i/W8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1316031749; bh=BTXBCMS/I4NmFtykGCj1rEX5QO2x+bUDmajWFWguFd8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=fvXzkKdqOMXFuzTy2tMDO6cKzUZKp3XGRzmr/+khacUj/hmFg2FnVyGyuuCRS9QwB yCgOS+9gCvT+uRqs+T7xt1W1gGB65B9ZNP1pnsruK3ffxuFX6H+Ypgc20qhwIEmr2F w+CXOkRCNIbYE9/tntG5XwYPDTUiH7/siCk5ne/k= Message-Id: <6.2.5.6.2.20110914124727.0834a378@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 14 Sep 2011 12:57:42 -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] apps-team review of draft-ietf-sidr-ghostbusters-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2011 20:20:28 -0000 Hi Murray, At 09:56 14-09-2011, Murray S. Kucherawy wrote: >Is there any risk of trouble to the IETF or Randy or anyone for >using the name Ghostbusters? I'm reasonably sure someone in >Hollywood would be eager to exert copyright over the name. This is covered by the Note Well and the first sentence in the "Status of this Memo" section of the draft. Regards, -sm From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Thu Sep 15 05:16: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 2031621F85BB for ; Thu, 15 Sep 2011 05:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.345 X-Spam-Level: X-Spam-Status: No, score=-102.345 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, MISSING_HEADERS=1.292, 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 n0F1n7ZwY7Dh for ; Thu, 15 Sep 2011 05:16:12 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 743CA21F8A95 for ; Thu, 15 Sep 2011 05:16:10 -0700 (PDT) Received: by mail-gw0-f42.google.com with SMTP id 17so2771958gwb.15 for ; Thu, 15 Sep 2011 05:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type:content-transfer-encoding; bh=Xg+rNePZa+im6JkOakHcRmWi4JHUFOrgdgCVH3hIA9g=; b=g17viW1wrSGbgmFGJNAwBMkEI+86b9hRWmxWo582U2/iepfwnbKy0vtDOgxC3hyo+2 Xu1AeSd6BImNrCxeY27moZO9+eqTJrWfbG94wArzUWTXmzoYEBVuwsdLaRIVZKGTBrqr A0BcrdUZaIvKk2YWj9boibxMdIqTo2QX/2UmU= Received: by 10.68.33.8 with SMTP id n8mr330802pbi.314.1316089102132; Thu, 15 Sep 2011 05:18:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.101.15 with HTTP; Thu, 15 Sep 2011 05:17:42 -0700 (PDT) In-Reply-To: <20110913170705.8169.5544.idtracker@ietfa.amsl.com> References: <20110913170705.8169.5544.idtracker@ietfa.amsl.com> From: Frank Ellermann Date: Thu, 15 Sep 2011 14:17:42 +0200 Message-ID: Cc: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xdash-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 12:16:13 -0000 >=A0Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-xdash-00.txt Nice. Maybe add image/x-icon vs. image/vnd.microsoft.com as an example where "de facto" vs. "de jure" created an interoperability mess with dozens of articles offering their own "one and final truth" about favicons. -Frank From randy@psg.com Thu Sep 15 09:46:34 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F35F21F84DA for ; Thu, 15 Sep 2011 09:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] 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 B6c269fif6z5 for ; Thu, 15 Sep 2011 09:46:34 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id EC9BE21F84D9 for ; Thu, 15 Sep 2011 09:46:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R4F79-000KDS-Sk; Thu, 15 Sep 2011 16:48:40 +0000 Date: Thu, 15 Sep 2011 18:48:36 +0200 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: <4E70D8DB.8010507@viagenie.ca> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: draft-ietf-sidr-ghostbusters.all@tools.ietf.org, Barry Leiba , apps-discuss@ietf.org Subject: Re: [apps-discuss] apps-team review of draft-ietf-sidr-ghostbusters-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Sep 2011 16:46:34 -0000 > > Randy Bush wrote, on 09/13/2011 11:16 PM: > >> -10 checked in > > > > Some additional comments on the vCard example... > > > >> BEGIN:VCARD > >> VERSION:4.0 > >> FN:Human's Name > >> ORG:Organizational Entity > >> ADR;TYPE=WORK:;;42 Twisty Passage;Deep Cavern; WA; 98666;U.S.A. > > > > Should be: > > ADR;TYPE=WORK:;;42 Twisty Passage;Deep Cavern;WA;98666;U.S.A. > > (whitespace is important? wow.) > > > > >> TEL;TYPE=VOICE,MSG,WORK:+1-666-555-1212 > >> TEL;TYPE=FAX,WORK:+1-666-555-1213 > > > > Should be: > > TEL;TYPE=VOICE,TEXT,WORK;VALUE=uri:tel:+1-666-555-1212 > > TEL;TYPE=FAX,WORK;VALUE=uri:tel:+1-666-555-1213 > > > >> EMAIL;TYPE=INTERNET:human@example.com > > > > Should be: > > EMAIL:human@example.com > > > >> END:VCARD this have long been fixed randy From simon.perreault@viagenie.ca Thu Sep 15 10:21: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 E652621F84D9 for ; Thu, 15 Sep 2011 10:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] 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 hQA1jD-ncTTV for ; Thu, 15 Sep 2011 10:21:34 -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 5D90A21F84D7 for ; Thu, 15 Sep 2011 10:21:34 -0700 (PDT) Received: from banana.viagenie.ca (nomis80.org [97.107.136.111]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C913B20E64; Thu, 15 Sep 2011 13:23:11 -0400 (EDT) Message-ID: <4E72346F.3060606@viagenie.ca> Date: Thu, 15 Sep 2011 13:22:55 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: Sandra Murphy References: <4E70D8DB.8010507@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-sidr-ghostbusters.all@tools.ietf.org, Barry Leiba , apps-discuss@ietf.org Subject: Re: [apps-discuss] apps-team review of draft-ietf-sidr-ghostbusters-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Sep 2011 17:21:35 -0000 Sandra Murphy wrote, on 09/15/2011 12:26 PM: > Simon, are these changes "better style" or "non-conformant, will not pass parsers". See inline... >>> BEGIN:VCARD >>> VERSION:4.0 >>> FN:Human's Name >>> ORG:Organizational Entity >>> ADR;TYPE=WORK:;;42 Twisty Passage;Deep Cavern; WA; 98666;U.S.A. >> >> Should be: >> ADR;TYPE=WORK:;;42 Twisty Passage;Deep Cavern;WA;98666;U.S.A. > > (whitespace is important? wow.) This goes in the category of "probably not what you mean", unless the state is " WA" and the postal code is " 98666" (with leading whitespace). >>> TEL;TYPE=VOICE,MSG,WORK:+1-666-555-1212 >>> TEL;TYPE=FAX,WORK:+1-666-555-1213 >> >> Should be: >> TEL;TYPE=VOICE,TEXT,WORK;VALUE=uri:tel:+1-666-555-1212 >> TEL;TYPE=FAX,WORK;VALUE=uri:tel:+1-666-555-1213 The RFC says that the value of a TEL property SHOULD be reset to a URI. >>> EMAIL;TYPE=INTERNET:human@example.com >> >> Should be: >> EMAIL:human@example.com TYPE=internet does not exist anymore in vCard 4. 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 ted.ietf@gmail.com Thu Sep 15 12:15: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 065E421F8B71; Thu, 15 Sep 2011 12:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] 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 g3VV1DOmnViC; Thu, 15 Sep 2011 12:15:06 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8B36221F8B55; Thu, 15 Sep 2011 12:15:06 -0700 (PDT) Received: by gxk9 with SMTP id 9so3425490gxk.40 for ; Thu, 15 Sep 2011 12:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=LnUaAb7Ayt/uAz4sgLu/5qJ0ym61wPdRtfWsOD3LsLo=; b=brBy4jcVM+IUT3uvnwPYJ32CNE1awDjCjWDAT/TFZLeD5kIY77ZyPJb8n3XlAb3KgP t7Pcfej8s7aEibki/wYmkl0S90mzfybUctE/wfxGEgC7yc0ecU+2nSa2v+969RsW8pec bvu4LGiMB7NgrKgZHJEhYErejwsp9zB+yMVLM= MIME-Version: 1.0 Received: by 10.236.173.69 with SMTP id u45mr9053045yhl.104.1316114238931; Thu, 15 Sep 2011 12:17:18 -0700 (PDT) Received: by 10.236.105.201 with HTTP; Thu, 15 Sep 2011 12:17:18 -0700 (PDT) Date: Thu, 15 Sep 2011 12:17:18 -0700 Message-ID: From: Ted Hardie To: IESG , alto-chairs@ietf.org, sprevidi@cisco.com, martin.stiemerling@neclab.eu, "Woundy, Richard" , yry@cs.yale.edu, Apps Discuss Content-Type: multipart/alternative; boundary=20cf305e2513b2053904acffb971 Subject: [apps-discuss] APPs team review of draft-ietf-alto-reqs-11 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Sep 2011 19:15:08 -0000 --20cf305e2513b2053904acffb971 Content-Type: text/plain; charset=ISO-8859-1 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-alto-reqs-11 Reviewer: Ted Hardie Review Date: September 15, 2011 Summary: I believe that this document needs further work before publication as an Informational RFC. Major Issues: Section 5.2.1 on Classification of Information Disclosure Scenarios has no scenarios relating to the user privacy aspects of disclosure. There is a great deal of work on the potential privacy threats related to correlation of data; some reference to that threat, and any mitigation available, seems required. The privacy discussion in ARv11-49 also does not discuss this, but it is a basic part of the risk here, since an ALTO server could theoretically see a much broader set of resource requests than a single server. Minor Issues: REQ ARv11-8 says: ARv11-8: For host group descriptor types other than "IPv4 address prefix" and "IPv6 address prefix", the host group descriptor type identification MUST be supplemented by a reference to a facility, which can be used to translate host group descriptors of that type to IPv4/IPv6 address prefixes, e.g., by means of a mapping table or an algorithm. I did not see a justification for this limitation here or in RFC 5693. A host group identifier that contained, for example, an AS number seems to be within the scope of the protocol (though admittedly harder to populate in a query). If this limitation is driven by an underlying requirement, I believe it should be made explicit. If this is intended to be allowed under REQ. ARv11-13, then a forward pointer that states that host group descriptors that are not immediately mappable to IP addresses should be extended with a different type would be useful. [Though AS number may not seem to be immediately practical, it might actually be faster to populate in ALTO queries than the current external IP of a NATted or double NATted host. By identifying the AS, the ALTO service provider may be able to identify peering and transit relationships between resource providers and the node making the query--thus helping identify the appropriate choice. ] In ARv11-12, the document is indicating that the preferences expressed are relative, but it does not say whether they are pure ordinals or whether they are weighted. If this is not yet decided, that's fine. But if the intent is to say that they are pure ordinals, it might be good to make that explicit. There's a lot of experience in CONNEG contexts that says implementors will attempt to infer weights and engage is some mighty dodgy math if this is not clear. REQs ARv11-23 and ARv11-24, taken together, seem to implicitly require that the two modes must be distinguishable, so that a client can avoid sending targets to ALTO services that do not support them. If this is the case, an explicit statement of this in one of the two would be useful. ARv11-27 is unclear as to whether ALTO transactions populated only with RFC1918 addresses are what must be supported or whether the intent is integration with methods for determining external addresses. The document currently says: In particular, as a simple way of achieving some basic form of throttling, an ALTO server MAY answer ALTO queries with a "Retry After: {point in time | time delta}" message. This "Retry After" MAY be sent as part of the ALTO reply together with the requested guiding information, or as a standalone (error) message not giving the requested guidance. The first form creates an implicit requirement for a synchronized clock, which should either be made explicit or eliminated in favor of the second form. REQ. ARv11-47 is not clear on the threat being addressed, so it is not clear whether the messages themselves must be encrypted or encryption of the hop-by-hop transport is sufficient. Some clarification would be useful. In REQ. ARv11-50, the document says: An ALTO server MUST provide adequate guidance even if the ALTO client prefers not to specify the desired resource (e.g., keeps the data field empty). Depending on the data distribution method, this may not be possible. I assume that this is meant to cover only target cases where both the resource and target host are mentioned. It would be helpful to clarify this. Editorial: I believe the abstract is difficult to parse. I personally would find something like the following more readable: Certain resources, such as pieces of information or server processes, are available from multiple hosts on the network. Applications which access those resources currently have no guidance on the likely performance of different potential sources. The goal of ALTO is to provide guidance for selecting among candidates sources to applications consuming multiply homed resources. This guidance shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to improve performance (or Quality of Experience) in the application while reducing resource consumption in the underlying network infrastructure. The Introduction says: The logical entities that provide the ALTO service do not take part in the actual user data transport, i.e., they do not implement functions for relaying user data. They may be placed on various kinds of physical nodes, e.g., on dedicated servers, as auxiliary processes in routers, on "trackers" or "super peers" of a P2P application, etc. I believe the phrase "logical entities" here is meant to imply that these functions are separable and that there is no necessary relationship between the entities providing the ALTO service and those providing the access to resources. If this is the case, some clarification may be useful. In section 2.3, I originally read the "see section 2.2" as refering to section 2.2 of RFC 5693 (see section 2.2. above) would be mildly better. Since there is no Section 2.2 in RFC 5693, though, this is a self-correcting problem. --20cf305e2513b2053904acffb971 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/co= ntent/applications-area-review-team). Please resolve these comments alo= ng with any other Last Call comments=20 you may receive. Please wait for direction from your document shepherd=20 or AD before posting a new version of the draft.

Document: draft-ietf-alto-reqs-11
Reviewer: Ted Hardie
Review Date: September 15, 2011

Summary:

I believe that this document needs further work before pub= lication as an Informational RFC.=A0

Major Issues:

Section 5= .2.1 on Classification of Information Disclosure Scenarios
has no scenarios relating to the user privacy aspects of disclosure.=A0 The= re
is a great deal of work on the potential privacy threats related to
correlation of data; some reference to that threat, and any mitigation
available, seems required.=A0 The privacy discussion in ARv11-49 also does<= br> not discuss this, but it is a basic part of the risk here, since an ALTO se= rver
could theoretically see a much broader set of resource requests tha= n
a single server.


Minor Issues:

REQ ARv11-8 says:

=A0=A0 ARv11-8: For host gro= up descriptor types other than "IPv4
=A0=A0 address prefix" an= d "IPv6 address prefix", the host group descriptor
=A0=A0 type= identification MUST be supplemented by a reference to a
=A0=A0 facility, which can be used to translate host group descriptors of=A0=A0 that type to IPv4/IPv6 address prefixes, e.g., by means of a mappi= ng
=A0=A0 table or an algorithm.

I did not see a justification fo= r this limitation here or in RFC 5693.
A host group identifier that contained, for example, an AS number
seems = to be within the scope of the protocol (though admittedly harder
to popu= late in a query).=A0 If this limitation is driven by an
underlying requi= rement, I believe it should be made explicit.=A0 If this
is intended to be allowed under REQ. ARv11-13, then a forward pointer
th= at states that host group descriptors that are not immediately
mappable = to IP addresses should be extended with a different type would be useful.
[Though AS number may not seem to be immediately practical, it might ac= tually
be faster to populate in ALTO queries than the current external I= P of
a NATted or double NATted host.=A0 By identifying the AS, the ALTO<= br> service provider may be able to identify peering and transit
relationshi= ps between resource providers and the node making the query--thus helpingidentify the appropriate choice. ]

In ARv11-12, the document is in= dicating that the preferences expressed
are relative, but it does not say whether they are pure ordinals or
whet= her they are weighted.=A0 If this is not yet decided, that's fine.
B= ut if the intent is to say that they are pure ordinals, it might be
good= to make that explicit.=A0 There's a lot of experience in CONNEG
contexts that says implementors will attempt to infer weights and
engage= is some mighty dodgy math if this is not clear.

REQs ARv11-23 and A= Rv11-24, taken together, seem to implicitly require
that the two modes m= ust be distinguishable, so that a client can avoid
sending targets to ALTO services that do not support them.=A0 If this isthe case, an explicit statement of this in one of the two would be
usef= ul.

ARv11-27 is unclear as to whether ALTO transactions populated on= ly
with RFC1918 addresses are what must be supported or whether the
intent = is integration with methods for determining external addresses.

The = document currently says:

=A0=A0 In particular, as a simple way of ac= hieving some basic form of
=A0=A0 throttling, an ALTO server MAY answer ALTO queries with a "Retr= y
=A0=A0 After: {point in time | time delta}" message.=A0 This &quo= t;Retry After" MAY
=A0=A0 be sent as part of the ALTO reply togethe= r with the requested guiding
=A0=A0 information, or as a standalone (error) message not giving the
= =A0=A0 requested guidance.

The first form creates an implicit requir= ement for a synchronized
clock, which should either be made explicit or = eliminated in favor of
the second form.

REQ. ARv11-47 is not clear on the threat being addr= essed, so it is not
clear whether the messages themselves must be encryp= ted or encryption
of the hop-by-hop transport is sufficient.=A0 Some cla= rification would
be useful.

In REQ. ARv11-50, the document says:

=A0=A0 An ALT= O server MUST provide adequate guidance even if the ALTO
=A0=A0 client p= refers not to specify the desired resource (e.g., keeps the
=A0=A0 data = field empty).

Depending on the data distribution method, this may not be possible.I assume that this is meant to cover only target cases where both the
r= esource and target host are mentioned.=A0 It would be helpful to
clarify= this.

Editorial:

I believe the abstract is difficult to parse.=A0 I pe= rsonally would find
something like the following more readable:

C= ertain resources, such as pieces of information or server processes,
are= available from multiple hosts on the network.=A0 Applications which
access those resources currently have no guidance on the likely
performa= nce of different potential sources.=A0 The goal of ALTO is to
provide gu= idance for selecting among candidates sources to
applications consuming = multiply homed resources.=A0 This guidance shall
be based on parameters that affect performance and efficiency of the
dat= a transmission between the hosts, e.g., the topological distance.
The ul= timate goal is to improve performance (or Quality of Experience)
in the = application while reducing resource consumption in the
underlying network infrastructure.=A0


The Introduction says:
=A0=A0 The logical entities that provide the ALTO service do not take = part
=A0=A0 in the actual user data transport, i.e., they do not impleme= nt
=A0=A0 functions for relaying user data.=A0 They may be placed on various=A0=A0 kinds of physical nodes, e.g., on dedicated servers, as auxiliary<= br>=A0=A0 processes in routers, on "trackers" or "super peer= s" of a P2P
=A0=A0 application, etc.

I believe the phrase "logical entities= " here is meant to imply that
these functions are separable and tha= t there is no necessary
relationship between the entities providing the = ALTO service and those
providing the access to resources.=A0 If this is the case, some
clarific= ation may be useful.

In section 2.3, I originally read the "see= section 2.2" as refering to
section 2.2 of RFC 5693 (see section 2= .2. above) would be mildly
better.=A0 Since there is no Section 2.2 in RFC 5693, though, this is a
= self-correcting problem.

--20cf305e2513b2053904acffb971-- From Sandra.Murphy@cobham.com Thu Sep 15 09:24: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 8D1E621F8B8F for ; Thu, 15 Sep 2011 09:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.996 X-Spam-Level: X-Spam-Status: No, score=-100.996 tagged_above=-999 required=5 tests=[AWL=-0.856, BAYES_20=-0.74, J_CHICKENPOX_74=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 QP62ZGF8RmQz for ; Thu, 15 Sep 2011 09:24:46 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id CCA4E21F8B8A for ; Thu, 15 Sep 2011 09:24:45 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p8FGQruu001319; Thu, 15 Sep 2011 11:26:53 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p8FGQrL0009315; Thu, 15 Sep 2011 11:26:53 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.151]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Sep 2011 12:26:52 -0400 Date: Thu, 15 Sep 2011 12:26:52 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Simon Perreault In-Reply-To: <4E70D8DB.8010507@viagenie.ca> Message-ID: References: <4E70D8DB.8010507@viagenie.ca> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 15 Sep 2011 16:26:52.0704 (UTC) FILETIME=[46E41A00:01CC73C4] X-Mailman-Approved-At: Fri, 16 Sep 2011 08:08:56 -0700 Cc: draft-ietf-sidr-ghostbusters.all@tools.ietf.org, Barry Leiba , apps-discuss@ietf.org Subject: Re: [apps-discuss] apps-team review of draft-ietf-sidr-ghostbusters-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Sep 2011 16:24:47 -0000 Simon, are these changes "better style" or "non-conformant, will not pass parsers". (cc list shortened a bit) --Sandy On Wed, 14 Sep 2011, Simon Perreault wrote: > Randy Bush wrote, on 09/13/2011 11:16 PM: >> -10 checked in > > Some additional comments on the vCard example... > >> BEGIN:VCARD >> VERSION:4.0 >> FN:Human's Name >> ORG:Organizational Entity >> ADR;TYPE=WORK:;;42 Twisty Passage;Deep Cavern; WA; 98666;U.S.A. > > Should be: > ADR;TYPE=WORK:;;42 Twisty Passage;Deep Cavern;WA;98666;U.S.A. (whitespace is important? wow.) > >> TEL;TYPE=VOICE,MSG,WORK:+1-666-555-1212 >> TEL;TYPE=FAX,WORK:+1-666-555-1213 > > Should be: > TEL;TYPE=VOICE,TEXT,WORK;VALUE=uri:tel:+1-666-555-1212 > TEL;TYPE=FAX,WORK;VALUE=uri:tel:+1-666-555-1213 > >> EMAIL;TYPE=INTERNET:human@example.com > > Should be: > EMAIL:human@example.com > >> END:VCARD > > 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 presnick@qualcomm.com Fri Sep 16 12:46: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 29EF021F8BC3 for ; Fri, 16 Sep 2011 12:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.523 X-Spam-Level: X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 duYTUPmZOM-a for ; Fri, 16 Sep 2011 12:46:27 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 9262B21F8B84 for ; Fri, 16 Sep 2011 12:46:27 -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=1316202523; x=1347738523; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4E73A816.2070803@qualcomm.com>|Date:=20Fr i,=2016=20Sep=202011=2014:48:38=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:=20Alexey=20Melnikov=20|CC:=20Ned=20Freed=20,=20"apps-discuss@ietf.org"=0D=0A=09|Subject:=20Re:=20[apps-discuss]=20draft-ietf-appsa wg-rfc3462bis:=20PS=20or=20DS?|References:=20<20110830041 853.24036.37.idtracker@ietfa.amsl.com>=09 =09<01O5KWP5WPAU00RCTX@mauve.mrochek.com>=20<4E63CBF2.808 0207@isode.com>|In-Reply-To:=20<4E63CBF2.8080207@isode.co m>|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=xG2/qWvf/NGqw7T0BMIekt3g6UrpnTOXTfyouEyZxbQ=; b=EL/uJgugI1yHynasrFZDN92/WSpMLBUxYM8n6gxBesEbU4vIQDuB1WDr FWx+oz0VIM7XUr/M13CXkXV8zJxzuprza81PyVqS3e9MAHwOMFTDWCl62 1KnsRq1gjrhc3QYftOM/AmNlqGXtOqeQYLTdAeAdxq7fKoIY+cQ2qbfL+ o=; X-IronPort-AV: E=McAfee;i="5400,1158,6471"; a="119194434" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 16 Sep 2011 12:48:41 -0700 X-IronPort-AV: E=Sophos;i="4.68,393,1312182000"; d="scan'208";a="151282463" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 16 Sep 2011 12:48:41 -0700 Received: from Macintosh-4.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 16 Sep 2011 12:48:40 -0700 Message-ID: <4E73A816.2070803@qualcomm.com> Date: Fri, 16 Sep 2011 14:48:38 -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: Alexey Melnikov References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> <01O5KWP5WPAU00RCTX@mauve.mrochek.com> <4E63CBF2.8080207@isode.com> In-Reply-To: <4E63CBF2.8080207@isode.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-rfc3462bis: PS or DS? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2011 19:46:28 -0000 On 9/4/11 2:05 PM, Alexey Melnikov wrote: > Ned Freed wrote: > >>> RFC3462 is currently DS. There's some question as to whether or not >>> this >>> revision qualifies to remain at DS, or forces a recycle at PS. >> >> Why not try for recycle at DS and see what the IESG says? I had intended to reply to this last week but it got lost in the shuffle: "Try not. Do or Do not. There is no try." :-) Speaking as the AD who's going to bring this to the IESG, I say: Let's have the WG *tell* the IESG what the interoperability implication of this is and *tell* the IESG what is appropriate. That is, the IESG is in no better position (and likely a worse one) than the WG participants to judge whether this change affects interoperability of the protocol. If you all say, "This restriction has not been implemented in any significant way, and for future work interoperability will be helped by removing the restriction", that justifies recycling at DS. If you all say, "We know of some implementations that will barf on this change and therefore we should probably have a bit to see how this deploys", that justifies PS. > For such a small issue I don't see much problems with recycling at DS, > especially if there is evidence that the restriction being removed is > not obeyed in non DSN contexts. Speaking for myself, I agree. My current read of the list is that the WG feels that the restriction has not been significantly implemented and that DS is appropriate, but I will will leave it to the chair to make that call and leave it to the document shepherd to convey that in the writeup. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From alexey.melnikov@isode.com Sat Sep 17 08:45: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 209EA21F8A69 for ; Sat, 17 Sep 2011 08:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 0TdMHNTiyfnj for ; Sat, 17 Sep 2011 08:45:35 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 4C45F21F8A67 for ; Sat, 17 Sep 2011 08:45:35 -0700 (PDT) Received: from [188.28.93.234] (188.28.93.234.threembb.co.uk [188.28.93.234]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 17 Sep 2011 16:47:51 +0100 Message-ID: <4E74C13D.7080908@isode.com> Date: Sat, 17 Sep 2011 16:48:13 +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: apps-discuss@ietf.org References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> <83FC8B77-CD70-4A25-B639-86879F645DDB@network-heretics.com> In-Reply-To: MIME-Version: 1.0 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: Sat, 17 Sep 2011 15:45:36 -0000 Barry Leiba wrote: >>Ok. I won't make an issue about this. I agree that the DSN and MDN >>RFCs is the right place to put these restrictions. >> >> > >I think with this, and with the other comments and reviews so far, >this version is ready to have a last call in the working group. Let's >give it another week for comments, and say that I will send this to >the ADs on 22 September. So final comments, please, by the end of 21 >September. > I think the document is well written and worth progressing. Some specific comments below: 1. Introduction Practical experience has shown that the general requirement of having that media type constrained to be used only as the outermost MIME type of a message, while well-intentioned, has provided little operational benefit and actually limits such things as the transmission of multiple administrative reports within a single overall message container. In particular, it prevents one from forwarding a report as part of another mulipart MIME message. typo: multipart This memo removes that constraint. No other changes apart from some editorial ones are made. Other memos might update other documents to establish or clarify the constraint where it is more appropriate. I suggest changing "constraints" to "constraints on use of multipart/report", as otherwise this is not very clear. 3. The multipart/report Media Type 1. [REQUIRED] The first body part contains a human readable message. The purpose of this message is to provide an easily understood description of the condition(s) that caused the report to be generated, for a human reader who may not have a user agent capable of interpreting the second section of the multipart/ report. The text in the first section may be in any MIME standards-track media type, charset, or language. Is "standards-track" really intended here? This seems both overly restrictive and not well specified (where can one find the list of *all* standards-track media type, or more specifically how long it would take one to find them all?). I suggest replacing with "registered" or "registered with IANA". 7.1. Normative References [OLD-REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003. This reference is Informative as far as I can see. That is there is no need to read and understand RFC 3462 in order to understand and implement this document. From evnikita2@gmail.com Sat Sep 17 08:49: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 34D4F21F87D6 for ; Sat, 17 Sep 2011 08:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 3hoL8U9aP8ZK for ; Sat, 17 Sep 2011 08:49:33 -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 6D34021F8797 for ; Sat, 17 Sep 2011 08:49:33 -0700 (PDT) Received: by fxd18 with SMTP id 18so2860732fxd.31 for ; Sat, 17 Sep 2011 08:51: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=AioTNvSXE+AEp9AF4TghtFBiNaXnsECqrAbdP4A41yg=; b=lSHeqAku7NR5nNeO76J08h7q1w1BVJR2uBOLDLBci6LsvNkxBCVsvM2TMNH6ehLFiS 9CwQcUh5rci+qA1OtPww+lPCl55zpbbh+0aEGR3TzlqM94o2KyWjcpWIaI5G/j/utBUj Sl1z2x5eYnlKFILu10xGY0/zngCOzfnaI5l/Q= Received: by 10.223.5.155 with SMTP id 27mr1401586fav.90.1316274702392; Sat, 17 Sep 2011 08:51:42 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id l8sm7491752fai.16.2011.09.17.08.51.40 (version=SSLv3 cipher=OTHER); Sat, 17 Sep 2011 08:51:41 -0700 (PDT) Message-ID: <4E74C22E.1040208@gmail.com> Date: Sat, 17 Sep 2011 18:52:14 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> <83FC8B77-CD70-4A25-B639-86879F645DDB@network-heretics.com> <4E74C13D.7080908@isode.com> In-Reply-To: <4E74C13D.7080908@isode.com> 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: Sat, 17 Sep 2011 15:49:34 -0000 17.09.2011 18:48, Alexey Melnikov wrote: > 3. The multipart/report Media Type > > 1. [REQUIRED] The first body part contains a human readable message. > The purpose of this message is to provide an easily understood > description of the condition(s) that caused the report to be > generated, for a human reader who may not have a user agent > capable of interpreting the second section of the multipart/ > report. The text in the first section may be in any MIME > standards-track media type, charset, or language. > > Is "standards-track" really intended here? This seems both overly > restrictive > and not well specified (where can one find the list of *all* > standards-track > media type, or more specifically how long it would take one to find > them all?). > I suggest replacing with "registered" or "registered with IANA". As registration guidelines for MIME types are "Expert Review" I also don't think such constraint is useful here. Mykyta From ned.freed@mrochek.com Sat Sep 17 09:55:54 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFA221F8678 for ; Sat, 17 Sep 2011 09:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 HMrbY08LO3LZ for ; Sat, 17 Sep 2011 09:55:53 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 083BA21F8669 for ; Sat, 17 Sep 2011 09:55:49 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O65M4OP134014D3W@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 17 Sep 2011 09:56:26 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O635JCX1I800RCTX@mauve.mrochek.com>; Sat, 17 Sep 2011 09:56:24 -0700 (PDT) Message-id: <01O65M4N7X5O00RCTX@mauve.mrochek.com> Date: Sat, 17 Sep 2011 09:56:14 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 17 Sep 2011 18:52:14 +0300" <4E74C22E.1040208@gmail.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> <83FC8B77-CD70-4A25-B639-86879F645DDB@network-heretics.com> <4E74C13D.7080908@isode.com> <4E74C22E.1040208@gmail.com> To: Mykyta Yevstifeyev DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1316278667; bh=pk35TgI4Bwv6E8Wg1EH6zSgKjCwshB+4RD76zOFiO1Q=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=O+9Ebby7AidUwEtDRo+4QIGzJKM4JMnE3fQJhGO4//h5NSKgsOmIsjERfamOS8gDS prGgFmonOWBNCcby/iiY1FIPg4KAup4ne8oANjBg9G/mtMawqQhfNBoa1nQNTn8OGO UuhQk9Y3dQw5I+zjzYXQ7qFDG88XTTQrwivNpwH0= 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: Sat, 17 Sep 2011 16:55:54 -0000 > 17.09.2011 18:48, Alexey Melnikov wrote: > > 3. The multipart/report Media Type > > > > 1. [REQUIRED] The first body part contains a human readable message. > > The purpose of this message is to provide an easily understood > > description of the condition(s) that caused the report to be > > generated, for a human reader who may not have a user agent > > capable of interpreting the second section of the multipart/ > > report. The text in the first section may be in any MIME > > standards-track media type, charset, or language. > > > > Is "standards-track" really intended here? This seems both overly > > restrictive > > and not well specified (where can one find the list of *all* > > standards-track > > media type, or more specifically how long it would take one to find > > them all?). > > I suggest replacing with "registered" or "registered with IANA". > As registration guidelines for MIME types are "Expert Review" I also > don't think such constraint is useful here. +1 Ned From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Sat Sep 17 14:13: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 B26C121F84D8 for ; Sat, 17 Sep 2011 14:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.297 X-Spam-Level: X-Spam-Status: No, score=-102.297 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, MISSING_HEADERS=1.292, 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 yEolHbwc0EH1 for ; Sat, 17 Sep 2011 14:13:30 -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 D3C9721F84D7 for ; Sat, 17 Sep 2011 14:13:28 -0700 (PDT) Received: by pzk33 with SMTP id 33so9764654pzk.4 for ; Sat, 17 Sep 2011 14:15:44 -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:cc :content-type; bh=U/mSfABl/c8WuTKFY7ND1mr2DYQLBDeCvBlTO/C6bl0=; b=Ci5lreblwJoQIG6DIgaqEgwWCp8j6M96jSrVhXfYoCH80tKvYEOwM0jABI7GLFmwqN ay3s3w48Eof8b2Xoc9jERZTZF99pJJ2vMmEOe9kpiWH+BxoGHoG1WurocsL07Saqf2Uv sRjlxleVSaFNotDZdS2oO6xYmRV6AyQP+OI1s= Received: by 10.68.6.135 with SMTP id b7mr1424350pba.113.1316294144123; Sat, 17 Sep 2011 14:15:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.101.15 with HTTP; Sat, 17 Sep 2011 14:15:04 -0700 (PDT) In-Reply-To: <01O65M4N7X5O00RCTX@mauve.mrochek.com> References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> <83FC8B77-CD70-4A25-B639-86879F645DDB@network-heretics.com> <4E74C13D.7080908@isode.com> <4E74C22E.1040208@gmail.com> <01O65M4N7X5O00RCTX@mauve.mrochek.com> From: Frank Ellermann Date: Sat, 17 Sep 2011 23:15:04 +0200 Message-ID: Cc: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 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: Sat, 17 Sep 2011 21:13:30 -0000 On 17 September 2011 18:56, Ned Freed wrote: > +1 Make that +2, only looking at the diff turns out to be a bad idea again and again, at some point in time I should know that. -Frank From evnikita2@gmail.com Sat Sep 17 21:25:16 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE95321F8531 for ; Sat, 17 Sep 2011 21:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 KLTkionigqqr for ; Sat, 17 Sep 2011 21:25:16 -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 CBAA821F8520 for ; Sat, 17 Sep 2011 21:25:15 -0700 (PDT) Received: by fxd18 with SMTP id 18so3164340fxd.31 for ; Sat, 17 Sep 2011 21:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=AB4OwPy5Y7igHnDpmsgvmJK4g0cselZx+gTV/aR5ZDE=; b=TPh3WVImYKjnbaYpsrq9/mxzrU8Ml6pOiATVTDhNnR0T2074aBchRkEh0pdmKExI70 iCRyaKb8F9aauy974YiwPHwmY9Ps3JsVI/qVc1JoY7c43BjsDWjcFSdVwcAxHKqHObO1 xwDDmbBmwFYuHZDsYJNW21CeOcpvyWufKgnsg= Received: by 10.223.39.25 with SMTP id d25mr2353099fae.131.1316320054525; Sat, 17 Sep 2011 21:27:34 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id t19sm16785130faj.23.2011.09.17.21.27.32 (version=SSLv3 cipher=OTHER); Sat, 17 Sep 2011 21:27:33 -0700 (PDT) Message-ID: <4E757356.4010307@gmail.com> Date: Sun, 18 Sep 2011 07:28:06 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20110913170705.8169.5544.idtracker@ietfa.amsl.com> In-Reply-To: <20110913170705.8169.5544.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xdash-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 04:25:16 -0000 13.09.2011 20:07, internet-drafts@ietf.org wrote: > 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. > > Title : Deprecating Use of the"X-" Prefix in Application Protocols > Author(s) : Peter Saint-Andre > D. Crocker > Mark Nottingham > Filename : draft-ietf-appsawg-xdash-00.txt > Pages : 12 > Date : 2011-09-13 Some comments: 1. Throughout the document: s/HTTP headers/HTTP header fields/. 2. Bullet 3 in Section 4 (and Bullet 1 in Appendix B): > Especially if the parameter > is intended to have meaning to implementers, the name could be a > URI (e.g.,"http://example.com/foo") I don't think this may be appropriate in most of current application-layer protocols (eg. header fields, URI scheme names, URN namespaces, FTP/SMTP/POP commands etc.). 3. Bullet 4 in Section 4: > 4. SHOULD generate meaningless names for parameters that will not > become standardized or widely used (e.g., because an extension is > completely private or purely speculative). I believe that any parameter, even used in presence of bilateral agreement between parties should be named to give enough information about its contents. So I propose to remove this recommendation. 4. Bullet 1 in Section 5: > 1. SHOULD provide unlimited registries with well-defined > registration procedures. Maybe "unlimited registry space" or "registries of unlimited size" here? 5. Appendix A, X*** FTP commands, I think you could also provide some information on further destiny of the commands as an illustration of what you claim in Appendix B: X*** were replaced by non-X *** commands in RFC 959, and caused interoperability problems requiring implementations to support both variant (what they continue to do even now, BTW). Thanks, Mykyta Yevstifeyev From msk@cloudmark.com Sun Sep 18 22:53: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 D09E021F8B11 for ; Sun, 18 Sep 2011 22:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.49 X-Spam-Level: X-Spam-Status: No, score=-103.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 OV94sVDUx-NP for ; Sun, 18 Sep 2011 22:53:24 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB7921F8AF4 for ; Sun, 18 Sep 2011 22:53:24 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 18 Sep 2011 22:55:46 -0700 From: "Murray S. Kucherawy" To: Alexey Melnikov , "apps-discuss@ietf.org" Date: Sun, 18 Sep 2011 22:55:45 -0700 Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.txt Thread-Index: Acx1US7aD0ahGfOOSoql7jFQ4AYuGQBPrdYg Message-ID: References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> <83FC8B77-CD70-4A25-B639-86879F645DDB@network-heretics.com> <4E74C13D.7080908@isode.com> In-Reply-To: <4E74C13D.7080908@isode.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: Mon, 19 Sep 2011 05:53:24 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Alexey Melnikov > Sent: Saturday, September 17, 2011 8:48 AM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.= txt >=20 > 1. Introduction >=20 > Practical experience has shown that the general requirement of having > that media type constrained to be used only as the outermost MIME > type of a message, while well-intentioned, has provided little > operational benefit and actually limits such things as the > transmission of multiple administrative reports within a single > overall message container. In particular, it prevents one from > forwarding a report as part of another mulipart MIME message. >=20 > typo: multipart Fixed. >=20 > This memo removes that constraint. No other changes apart from some > editorial ones are made. Other memos might update other documents to > establish or clarify the constraint where it is more appropriate. >=20 > I suggest changing "constraints" to "constraints on use of > multipart/report", as otherwise this is not very clear. How about (pasting directly from the XML source): This memo removes that constraint. No other changes apart from some editorial ones are made. Other memos might update other documents to establish or clarify the constraints on use of multipart/report in contexts where such are needed. > 3. The multipart/report Media Type >=20 > 1. [REQUIRED] The first body part contains a human readable message. > The purpose of this message is to provide an easily understood > description of the condition(s) that caused the report to be > generated, for a human reader who may not have a user agent > capable of interpreting the second section of the multipart/ > report. The text in the first section may be in any MIME > standards-track media type, charset, or language. >=20 > Is "standards-track" really intended here? This seems both overly restric= tive > and not well specified (where can one find the list of *all* standards- > track media type, or more specifically how long it would take one to find > them all?). I suggest replacing with "registered" or "registered with IAN= A". Works for me. I just copied the text from the original here, but this chan= ge seems fine. > 7.1. Normative References >=20 > [OLD-REPORT] > Vaudreuil, G., "The Multipart/Report Content Type for the > Reporting of Mail System Administrative Messages", > RFC 3462, January 2003. >=20 > This reference is Informative as far as I can see. That is there is no > need to read and understand RFC 3462 in order to understand and implement > this document. Fixed. -MSK From alexey.melnikov@isode.com Mon Sep 19 04:39: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 36CDF21F8BB1 for ; Mon, 19 Sep 2011 04:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 pX0YH3ybrRwe for ; Mon, 19 Sep 2011 04:39:34 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD1721F8BAE for ; Mon, 19 Sep 2011 04:39:34 -0700 (PDT) Received: from [188.29.242.1] (188.29.242.1.threembb.co.uk [188.29.242.1]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 19 Sep 2011 12:41:54 +0100 Message-ID: <4E772A7E.1090002@isode.com> Date: Mon, 19 Sep 2011 12:41:50 +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: "Murray S. Kucherawy" References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> <83FC8B77-CD70-4A25-B639-86879F645DDB@network-heretics.com> <4E74C13D.7080908@isode.com> 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" 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: Mon, 19 Sep 2011 11:39:35 -0000 Hi Murray, Murray S. Kucherawy wrote: [...] >> This memo removes that constraint. No other changes apart from some >> editorial ones are made. Other memos might update other documents to >> establish or clarify the constraint where it is more appropriate. >> >>I suggest changing "constraints" to "constraints on use of >>multipart/report", as otherwise this is not very clear. >> >> >How about (pasting directly from the XML source): > > This memo removes that constraint. No other changes apart > from some editorial ones are made. Other memos might > update other documents to establish or clarify the > constraints on use of multipart/report in contexts where > such are needed. > > Works for me. >>3. The multipart/report Media Type >> >> 1. [REQUIRED] The first body part contains a human readable message. >> The purpose of this message is to provide an easily understood >> description of the condition(s) that caused the report to be >> generated, for a human reader who may not have a user agent >> capable of interpreting the second section of the multipart/ >> report. The text in the first section may be in any MIME >> standards-track media type, charset, or language. >> >>Is "standards-track" really intended here? This seems both overly restrictive >>and not well specified (where can one find the list of *all* standards- >>track media type, or more specifically how long it would take one to find >>them all?). I suggest replacing with "registered" or "registered with IANA". >> >> >Works for me. I just copied the text from the original here, but this change seems fine. > > Ok. I hope other WG participants have no objections to this change. From evnikita2@gmail.com Mon Sep 19 06:04:19 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AFC21F8BE4 for ; Mon, 19 Sep 2011 06:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 mR21SjMM64rN for ; Mon, 19 Sep 2011 06:04:19 -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 D9F3D21F8BC5 for ; Mon, 19 Sep 2011 06:04:18 -0700 (PDT) Received: by bkaq10 with SMTP id q10so5859126bka.31 for ; Mon, 19 Sep 2011 06:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=YtWecjGZYAw0d8l4A2G8EFV3nlad5qVi6lNGabBoc7c=; b=WqJJitm3NMItxz2xxfJ8M41dnlN12yAYOKPbHMAkQLoreWcWtQXPog4opG079l0tYm bWGDkc/36A3DlVeKGVc8R77zsijeX7i3vstp4qIMqwoHhfJlRJQhXgzqc1rgpR2D7AoJ bNxUYEXOtrobJnocw8H7q9DseaFSGz1ehExuI= Received: by 10.204.152.153 with SMTP id g25mr1692487bkw.285.1316437595445; Mon, 19 Sep 2011 06:06:35 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id b17sm14059497bkd.8.2011.09.19.06.06.33 (version=SSLv3 cipher=OTHER); Mon, 19 Sep 2011 06:06:34 -0700 (PDT) Message-ID: <4E773E7B.1070304@gmail.com> Date: Mon, 19 Sep 2011 16:07:07 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> <83FC8B77-CD70-4A25-B639-86879F645DDB@network-heretics.com> <4E74C13D.7080908@isode.com> <4E772A7E.1090002@isode.com> In-Reply-To: <4E772A7E.1090002@isode.com> 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: Mon, 19 Sep 2011 13:04:20 -0000 19.09.2011 14:41, Alexey Melnikov wrote: > Hi Murray, > > Murray S. Kucherawy wrote: > [...] > >>> This memo removes that constraint. No other changes apart from some >>> editorial ones are made. Other memos might update other documents to >>> establish or clarify the constraint where it is more appropriate. >>> >>> I suggest changing "constraints" to "constraints on use of >>> multipart/report", as otherwise this is not very clear. >>> >> How about (pasting directly from the XML source): >> >> This memo removes that constraint. No other changes apart >> from some editorial ones are made. Other memos might >> update other documents to establish or clarify the >> constraints on use of multipart/report in contexts where >> such are needed. I don't think other documents might "update" this one. I think "complement" is OK here. Mykyta >> >> > Works for me. From bortzmeyer+rfc@nic.fr Mon Sep 19 00:02: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 22BE021F8BA8 for ; Mon, 19 Sep 2011 00:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.124 X-Spam-Level: X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=3.825, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 22hvOWKIc89q for ; Mon, 19 Sep 2011 00:02:38 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by ietfa.amsl.com (Postfix) with ESMTP id 7313921F8B14 for ; Mon, 19 Sep 2011 00:02:38 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 906231C0731; Mon, 19 Sep 2011 09:04:57 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 8A6E11C036C; Mon, 19 Sep 2011 09:04:57 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.6.69]) by relay2.nic.fr (Postfix) with ESMTP id 8677F7B006C; Mon, 19 Sep 2011 09:04:57 +0200 (CEST) Date: Mon, 19 Sep 2011 09:04:57 +0200 From: =?iso-8859-1?Q?St=E9phane?= Bortzmeyer To: John C Klensin Message-ID: <20110919070457.GA10883@nic.fr> References: <20110910083446.7D45098C251@rfc-editor.org> <8FDDE9E59CF60C43C95F3951@PST.JCK.COM> <20110910190557.GA13739@laperouse.bortzmeyer.org> <2A0F6A6C7A60F7292A0A104C@[192.168.1.128]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A0F6A6C7A60F7292A0A104C@[192.168.1.128]> X-Operating-System: Debian GNU/Linux 6.0.2 X-Kernel: Linux 2.6.32-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Mon, 19 Sep 2011 08:15:42 -0700 Cc: apps-discuss@ietf.org, paul.hoffman@vpnc.org, =?iso-8859-1?Q?St=E9phane?= Bortzmeyer , presnick@qualcomm.com, barryleiba@computer.org, RFC Errata System Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC6365 (2966) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2011 07:04:18 -0000 On Sat, Sep 10, 2011 at 06:58:51PM -0400, John C Klensin wrote a message of 54 lines which said: > Perhaps if the system permitted someone who found a problem that "is > of small importance, ... it is a good idea if such problems are > stored somewhere for the future revision" to say that when the > erratum is submitted --perhaps by checking a "recommend moving this > immediately to 'hold for future revision' box" Indeed. Most bug tracking systems have such a checkbox, allowing to file the bug as Trivial, Minor, Major or Showstopper, and then sending the email warning only if severity >= Major. That would be a nice improvment to the RFC errata reporting system. (And I disagree with Bjoern Hoehrmann: an "editorial error" CAN be severe.) From sebi@gw01.ehlo.wurstkaes.de Tue Sep 20 02:40: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 D04BF21F8C0F; Tue, 20 Sep 2011 02:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_OBFU_Q1=0.227] 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 htFBuv64V2Q0; Tue, 20 Sep 2011 02:40:12 -0700 (PDT) Received: from gw01.ehlo.wurstkaes.de (gw01.ehlo.wurstkaes.de [188.246.4.151]) by ietfa.amsl.com (Postfix) with ESMTP id 71A1B21F8BF6; Tue, 20 Sep 2011 02:40:10 -0700 (PDT) Received: from sebi by gw01.ehlo.wurstkaes.de with local (Exim 4.69) (envelope-from ) id 1R5wqT-0001oG-Bv; Tue, 20 Sep 2011 11:42:29 +0200 Date: Tue, 20 Sep 2011 11:42:29 +0200 From: Sebastian Kiesel To: Ted Hardie Message-ID: <20110920094229.GA5907@gw01.ehlo.wurstkaes.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Accept-Languages: en, de Organization: my personal mail account User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Tue, 20 Sep 2011 08:07:04 -0700 Cc: alto-chairs@ietf.org, IESG , Apps Discuss , draft-ietf-alto-reqs@tools.ietf.org Subject: Re: [apps-discuss] APPs team review of draft-ietf-alto-reqs-11 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2011 09:40:13 -0000 Ted, thanks for the extensive review. See comments and some questions inline. Please note: I have adjusted the mail's recipient list, in order to catch all authors. Thanks, Sebastian On Thu, Sep 15, 2011 at 09:17:18PM +0200, Ted Hardie 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-alto-reqs-11 > Reviewer: Ted Hardie > Review Date: September 15, 2011 > > Summary: > > I believe that this document needs further work before publication as > an Informational RFC. > > Major Issues: > > Section 5.2.1 on Classification of Information Disclosure Scenarios > has no scenarios relating to the user privacy aspects of disclosure. We believe that the privacy concerns from the user's point of view boil down to what we call "Disclosure of the application behavior to ..." "... the ALTO server" (case 2 in Section 5.2.1) or "... to an unauthorized third party" (4). This follows the logic that at least in the P2P file sharing scenario (which was the first use case for ALTO) it's the users that run the application overlay and therefore their privacy concerns are about not disclosing the application behavior (e.g., who is sharing which files with whom). Should we add a note or clarification about that? Or are you missing a completely different aspect of privacy (which?)? > There is a great deal of work on the potential privacy threats related > to correlation of data; some reference to that threat, and any > mitigation available, seems required. The privacy discussion in > ARv11-49 also does not discuss this, but it is a basic part of the > risk here, since an ALTO server could theoretically see a much broader > set of resource requests than a single server. The main countermeasure against the abovementioned concerns is to use the target-independent query mode (see last paragraph on page 18). ARv11-49 is just an addtional measure, in particular if someone needs to use the target-aware query mode. ***** > Minor Issues: > > REQ ARv11-8 says: > > ARv11-8: For host group descriptor types other than "IPv4 > address prefix" and "IPv6 address prefix", the host group descriptor > type identification MUST be supplemented by a reference to a > facility, which can be used to translate host group descriptors of > that type to IPv4/IPv6 address prefixes, e.g., by means of a mapping > table or an algorithm. > > I did not see a justification for this limitation here or in RFC 5693. > A host group identifier that contained, for example, an AS number > seems to be within the scope of the protocol (though admittedly harder > to populate in a query). We all agree that somtimes, for a network operator it may be easier to express preferences using host group descriptor types other than IP addresses. AS numbers are on obvious example, maybe also cell IDs in cellular mobile networks. However, at the end of the day, an application does a connect() to an IP address, and therefore needs guidance expressing preferences wrt. IP addresses. It is (or at least was, at some point in time) consensus in the WG that the complexity of mapping AS numbers to IP addresses should be server-side, not client-side. > If this limitation is driven by an underlying requirement, I believe > it should be made explicit. I think "complexity should be server-side" is not really a hard underlying requirement, it's more sort of a collective gut feeling that this makes deployment and interoperability easier. If a network operator prefers to express his network topology using whatever description language that's fine, but it should not require the application (with the embedded ALTO client) to implement additional code or acquire additional knowledge. > If this is intended to be allowed under REQ. ARv11-13, then a forward > pointer that states that host group descriptors that are not > immediately mappable to IP addresses should be extended with a > different type would be useful. Extensibility of host group descriptors is covered in ARv11-6. I do not see the relation to ARv11-13. > [Though AS number may not seem to be immediately practical, it might > actually be faster to populate in ALTO queries than the current > external IP of a NATted or double NATted host. How would an ALTO client located behind a NAT reliably find its own AS number and the AS numbers of all candidate resource providers? > By identifying the AS, > the ALTO service provider may be able to identify peering and transit > relationships between resource providers and the node making the > query--thus helping identify the appropriate choice. ] The ALTO requirements draft does not prevent anyone from using AS numbers inside the ALTO server and on the interface through which network topology information is loaded into the ALTO server (said interface is out of the scope of current WG standardization activities). In fact, we cannot prevent anyone from doing so, and as said above, it may make sense to do so. The ALTO requirements draft does not even prevent you from using AS numbers within the ALTO client protocol. All it says is that if you decide to expose AS numbers to the clients, you MUST provide a (reference to a) mechanism for mapping to/from IP addresses (ARv11-8). Does this make sense to you? > In ARv11-12, the document is indicating that the preferences expressed > are relative, but it does not say whether they are pure ordinals or > whether they are weighted. If this is not yet decided, that's fine. The WG was not interested in deciding and freezing this at the requirements level. The only "official" (i.e., WG document) protocol specification does distinguish between ordinal and numerical cost modes. > REQs ARv11-23 and ARv11-24, taken together, seem to implicitly require > that the two modes must be distinguishable, so that a client can avoid > sending targets to ALTO services that do not support them. If this is > the case, an explicit statement of this in one of the two would be > useful. Is there a strong reason why a client should do some kind of capability query and avoid sending unsupported query types? Of course, it's more efficient ... The WG's protocol spec does support this capability query, but do we need to go back to the WG, ask for consensus and freeze that at the requirements level? I assume that we do not have to explicitly state that if some protocol feature is optional, there must be *some kind* of graceful handling if one party does not support it (RFC 2119 already talks about the implications of optional features). > ARv11-27 is unclear as to whether ALTO transactions populated only > with RFC1918 addresses are what must be supported or whether the > intent is integration with methods for determining external addresses. The intent of ARv11-27 is to say that the "exchange of ALTO transactions" must work through NAT, i.e., a transport issue. For example, we do not want to have FTP-style back-connects to random port numbers. There is no intention to make any statement here about the semantics of queries/responses accross the boundary of address realms. Would "transport of ALTO transactions" be clearer? Any other proposal for a wording? > The document currently says: > > In particular, as a simple way of achieving some basic form of > throttling, an ALTO server MAY answer ALTO queries with a "Retry > After: {point in time | time delta}" message. This "Retry After" MAY > be sent as part of the ALTO reply together with the requested guiding > information, or as a standalone (error) message not giving the > requested guidance. > > The first form creates an implicit requirement for a synchronized > clock, which should either be made explicit or eliminated in favor of > the second form. The intent of this note is to state that using HTTP with its retry-after header (RFC 2616, sec. 14.37) as an underlying protocol layer satisfies the requirement. And HTTP defines both point in time and time delta, AFAIR without discussing synchronized clock issues. > REQ. ARv11-47 is not clear on the threat being addressed, so it is not > clear whether the messages themselves must be encrypted or encryption > of the hop-by-hop transport is sufficient. Some clarification would > be useful. At this requirements level, we do not have a clear architecture in mind, e.g., is there such a thing as a proxy? Therefore, it is diffcult to discus hop-by-hop vs. end-to-end encryption. The requirement is here to force authors of a concrete specification to think about this issue... > In REQ. ARv11-50, the document says: > > An ALTO server MUST provide adequate guidance even if the ALTO > client prefers not to specify the desired resource (e.g., keeps the > data field empty). > > Depending on the data distribution method, this may not be possible. > I assume that this is meant to cover only target cases where both the > resource and target host are mentioned. It would be helpful to > clarify this. Not neccessarily. There could be ALTO queries "give me a sorted list of IP prefixes that are expected to give better-than-average performance if I connect to a peer therein" and "give me a sorted list of IP prefixes that are expected to give better-than-average performance if I connect to a peer therein, and, by the way, I am going to watch TV channel ABC over p2p live streaming protocol XYZ." The req. says that also the first query should give some reasonable result. > Editorial: > > I believe the abstract is difficult to parse. I personally would find > something like the following more readable: > > Certain resources, such as pieces of information or server processes, > are available from multiple hosts on the network. Applications which > access those resources currently have no guidance on the likely > performance of different potential sources. The goal of ALTO is to > provide guidance for selecting among candidates sources to > applications consuming multiply homed resources. This guidance shall > be based on parameters that affect performance and efficiency of the > data transmission between the hosts, e.g., the topological distance. > The ultimate goal is to improve performance (or Quality of Experience) > in the application while reducing resource consumption in the > underlying network infrastructure. > > > The Introduction says: > > The logical entities that provide the ALTO service do not take part > in the actual user data transport, i.e., they do not implement > functions for relaying user data. They may be placed on various > kinds of physical nodes, e.g., on dedicated servers, as auxiliary > processes in routers, on "trackers" or "super peers" of a P2P > application, etc. > > I believe the phrase "logical entities" here is meant to imply that > these functions are separable and that there is no necessary > relationship between the entities providing the ALTO service and those > providing the access to resources. right. furthermore, an ALTO server is not necessarily a separate physical box. > If this is the case, some clarification may be useful. Could you please propose text? What exactly needs to be clarified? > > In section 2.3, I originally read the "see section 2.2" as refering to > section 2.2 of RFC 5693 (see section 2.2. above) would be mildly > better. Since there is no Section 2.2 in RFC 5693, though, this is a > self-correcting problem. ACK. Thanks again for the extensive review. -- Sebastian From ted.ietf@gmail.com Wed Sep 21 01:11: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 50C7021F8C93; Wed, 21 Sep 2011 01:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] 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 KL4QnQtHwntD; Wed, 21 Sep 2011 01:11:13 -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 9E64C21F8C91; Wed, 21 Sep 2011 01:11:12 -0700 (PDT) Received: by gxk19 with SMTP id 19so1172210gxk.31 for ; Wed, 21 Sep 2011 01:13: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:date:message-id:subject:from:to :cc:content-type; bh=l+Iji/fkDLMXhsexzXNvKX5FkOGR6Q2MNgynONDaFD4=; b=glYoMdpDPksFip/mjdkxs6cpvu/OwI8d2qrOOwmSSSNSsI6dXmhxMD6rC8MIQ7XDAk 9nL3IVyOoypVq/HkQ67ss51JoMPtgq1Bc6R4xVy+JrzapQ7dyT3fzsBu2aawfamDYrR1 zTpP/QOxFoAijuFqhICyvS3KbKIAp2MD0k344= MIME-Version: 1.0 Received: by 10.236.22.33 with SMTP id s21mr3023702yhs.70.1316592820418; Wed, 21 Sep 2011 01:13:40 -0700 (PDT) Received: by 10.236.105.201 with HTTP; Wed, 21 Sep 2011 01:13:40 -0700 (PDT) In-Reply-To: <20110920094229.GA5907@gw01.ehlo.wurstkaes.de> References: <20110920094229.GA5907@gw01.ehlo.wurstkaes.de> Date: Wed, 21 Sep 2011 10:13:40 +0200 Message-ID: From: Ted Hardie To: Sebastian Kiesel Content-Type: multipart/alternative; boundary=e89a8f6478235ff97b04ad6f27e4 Cc: alto-chairs@ietf.org, IESG , Apps Discuss , draft-ietf-alto-reqs@tools.ietf.org Subject: Re: [apps-discuss] APPs team review of draft-ietf-alto-reqs-11 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2011 08:11:15 -0000 --e89a8f6478235ff97b04ad6f27e4 Content-Type: text/plain; charset=ISO-8859-1 Hi Sebastian, Thanks for your message, some responses inline. On Tue, Sep 20, 2011 at 11:42 AM, Sebastian Kiesel wrote: > Ted, > > thanks for the extensive review. See comments and some questions inline. > > Please note: I have adjusted the mail's recipient list, in order to > catch all authors. > > Thanks, > Sebastian > > > > On Thu, Sep 15, 2011 at 09:17:18PM +0200, Ted Hardie 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-alto-reqs-11 > > Reviewer: Ted Hardie > > Review Date: September 15, 2011 > > > > Summary: > > > > I believe that this document needs further work before publication as > > an Informational RFC. > > > > Major Issues: > > > > Section 5.2.1 on Classification of Information Disclosure Scenarios > > has no scenarios relating to the user privacy aspects of disclosure. > > > We believe that the privacy concerns from the user's point of view boil > down to what we call "Disclosure of the application behavior to ..." > "... the ALTO server" (case 2 in Section 5.2.1) or "... to an > unauthorized third party" (4). > > This follows the logic that at least in the P2P file sharing scenario > (which was the first use case for ALTO) it's the users that run the > application overlay and therefore their privacy concerns are about > not disclosing the application behavior (e.g., who is sharing which > files with whom). > > Should we add a note or clarification about that? > Or are you missing a completely different aspect of privacy (which?)? > > > I think the newcomer to ALTO may have difficulty teasing out what you mean by application behavior. I certainly did not read it to mean "privacy sensitive user data". I believe it would be better list this requirement with reference to what is disclosed rather than in terms of application behavior. > > > There is a great deal of work on the potential privacy threats related > > to correlation of data; some reference to that threat, and any > > mitigation available, seems required. The privacy discussion in > > ARv11-49 also does not discuss this, but it is a basic part of the > > risk here, since an ALTO server could theoretically see a much broader > > set of resource requests than a single server. > > The main countermeasure against the abovementioned concerns is to > use the target-independent query mode (see last paragraph on page 18). > ARv11-49 is just an addtional measure, in particular if someone > needs to use the target-aware query mode. > > Assuming you mean the last paragraph of 17, it begins: The disclosure of candidate resource providers' addresses to the ALTO server can be avoided by allowing ALTO clients to use the target- independent query mode. This issue here is not disclosure of resource providers' address, but disclosure of the queries themselves. Aggregating data about the queries issued allows you to correlate data about the user issuing the queries; that's the privacy issue I mentioned. > > ***** > > Minor Issues: > > > > REQ ARv11-8 says: > > > > ARv11-8: For host group descriptor types other than "IPv4 > > address prefix" and "IPv6 address prefix", the host group descriptor > > type identification MUST be supplemented by a reference to a > > facility, which can be used to translate host group descriptors of > > that type to IPv4/IPv6 address prefixes, e.g., by means of a mapping > > table or an algorithm. > > > > I did not see a justification for this limitation here or in RFC 5693. > > A host group identifier that contained, for example, an AS number > > seems to be within the scope of the protocol (though admittedly harder > > to populate in a query). > > We all agree that somtimes, for a network operator it may be easier > to express preferences using host group descriptor types other > than IP addresses. AS numbers are on obvious example, maybe also > cell IDs in cellular mobile networks. However, at the end of the > day, an application does a connect() to an IP address, and therefore > needs guidance expressing preferences wrt. IP addresses. It is > (or at least was, at some point in time) consensus in the WG > that the complexity of mapping AS numbers to IP addresses should > be server-side, not client-side. > > I think the requirement language may be misleading here. Your explanation makes it sound like the goal here is: "No matter what host descriptor type is used, the service should return candidate IP addresses". The way I originally read it, it sounded like: "Any host descriptor must have a well-known mapping to an IP address before it can be used." Some clarification may be needed if the first is your goal. > > If this limitation is driven by an underlying requirement, I believe > > it should be made explicit. > > I think "complexity should be server-side" is not really a hard > underlying requirement, it's more sort of a collective gut feeling > that this makes deployment and interoperability easier. If a network > operator prefers to express his network topology using whatever > description language that's fine, but it should not require the > application (with the embedded ALTO client) to implement additional > code or acquire additional knowledge. > > Acquiring additional knowledge (e.g. the external IP bound to my NATted internal IP) may be necessary in some cases. Forbidding at a protocol level that this could not be some other piece of additional knowledge does not seem justified by the text in this document or the 5693; as a baseline, I heartily agree--but you are circumscribing extensibility here. Just my personal opinion, of course. > > If this is intended to be allowed under REQ. ARv11-13, then a forward > > pointer that states that host group descriptors that are not > > immediately mappable to IP addresses should be extended with a > > different type would be useful. > > Extensibility of host group descriptors is covered in ARv11-6. > I do not see the relation to ARv11-13. > > I wondered whether ARv11-13 might cover descriptors that did not fall into ARv11-6. Thank you for the clarification. > > [Though AS number may not seem to be immediately practical, it might > > actually be faster to populate in ALTO queries than the current > > external IP of a NATted or double NATted host. > > How would an ALTO client located behind a NAT reliably find its > own AS number and the AS numbers of all candidate resource providers? > > > > By identifying the AS, > > the ALTO service provider may be able to identify peering and transit > > relationships between resource providers and the node making the > > query--thus helping identify the appropriate choice. ] > > The ALTO requirements draft does not prevent anyone from using AS > numbers inside the ALTO server and on the interface through which > network topology information is loaded into the ALTO server (said > interface is out of the scope of current WG standardization activities). > In fact, we cannot prevent anyone from doing so, and as said above, > it may make sense to do so. > > The ALTO requirements draft does not even prevent you from using AS > numbers within the ALTO client protocol. All it says is that if you > decide to expose AS numbers to the clients, you MUST provide a > (reference to a) mechanism for mapping to/from IP addresses (ARv11-8). > > > Does this make sense to you? > > > > In ARv11-12, the document is indicating that the preferences expressed > > are relative, but it does not say whether they are pure ordinals or > > whether they are weighted. If this is not yet decided, that's fine. > > The WG was not interested in deciding and freezing this at the > requirements level. The only "official" (i.e., WG document) > protocol specification does distinguish between ordinal and numerical > cost modes. > > Thanks for the clarification; it might be useful to say something like "Protocol specifications should indicate whether preferences expressed are ordinal or weighted", but if the protocol specification already does so, this may not be required. > > REQs ARv11-23 and ARv11-24, taken together, seem to implicitly require > > that the two modes must be distinguishable, so that a client can avoid > > sending targets to ALTO services that do not support them. If this is > > the case, an explicit statement of this in one of the two would be > > useful. > > Is there a strong reason why a client should do some kind of capability > query and avoid sending unsupported query types? Of course, it's more > efficient ... > > The WG's protocol spec does support this capability query, but do we > need to go back to the WG, ask for consensus and freeze that at the > requirements level? I assume that we do not have to explicitly state > that if some protocol feature is optional, there must be *some kind* of > graceful handling if one party does not support it (RFC 2119 already > talks about the implications of optional features). > > > Frankly, publishing protocol requirements when the spec is already developed all too often results in exactly this: rejiggering the requirements to match the protocol already developed or in development. Please work with your AD on whether this is something that would be valuable. > > ARv11-27 is unclear as to whether ALTO transactions populated only > > with RFC1918 addresses are what must be supported or whether the > > intent is integration with methods for determining external addresses. > > The intent of ARv11-27 is to say that the "exchange of ALTO > transactions" must work through NAT, i.e., a transport issue. > For example, we do not want to have FTP-style back-connects to > random port numbers. > > There is no intention to make any statement here about the semantics > of queries/responses accross the boundary of address realms. > > Would "transport of ALTO transactions" be clearer? Any other > proposal for a wording? > > I believe so, yes. > > > The document currently says: > > > > In particular, as a simple way of achieving some basic form of > > throttling, an ALTO server MAY answer ALTO queries with a "Retry > > After: {point in time | time delta}" message. This "Retry After" MAY > > be sent as part of the ALTO reply together with the requested guiding > > information, or as a standalone (error) message not giving the > > requested guidance. > > > > The first form creates an implicit requirement for a synchronized > > clock, which should either be made explicit or eliminated in favor of > > the second form. > > The intent of this note is to state that using HTTP with its retry-after > header (RFC 2616, sec. 14.37) as an underlying protocol layer satisfies > the requirement. And HTTP defines both point in time and time delta, > AFAIR without discussing synchronized clock issues. > > > The RFC 2616 method also implies the need for a synchronized clock at a resolution of one second, at least in my view. > > REQ. ARv11-47 is not clear on the threat being addressed, so it is not > > clear whether the messages themselves must be encrypted or encryption > > of the hop-by-hop transport is sufficient. Some clarification would > > be useful. > > At this requirements level, we do not have a clear architecture > in mind, e.g., is there such a thing as a proxy? Therefore, it is > diffcult to discus hop-by-hop vs. end-to-end encryption. The requirement > is here to force authors of a concrete specification to think about this > issue... > > If you do not have a threat model in mind, it is not clear to me what justification you have for this requirement at all. Required security mechanisms should be matched against a threat; if you don't know what you're protecting from whom, claiming that encryption of some sort is required at some point seems less than useful. > > > In REQ. ARv11-50, the document says: > > > > An ALTO server MUST provide adequate guidance even if the ALTO > > client prefers not to specify the desired resource (e.g., keeps the > > data field empty). > > > > Depending on the data distribution method, this may not be possible. > > I assume that this is meant to cover only target cases where both the > > resource and target host are mentioned. It would be helpful to > > clarify this. > > Not neccessarily. There could be ALTO queries > > "give me a sorted list of IP prefixes that are expected to give > better-than-average performance if I connect to a peer therein" > > Well, personally, it is hard to see how this is a useful response if the result is that I connect to a peer within that prefix but that node must make onward connections to retrieve the resources I need. In some data distribution methods, that seems a likely result. But this turns on what you mean by "adequate guidance". I assumed, apparently wrongly, that this meant adequate guidance on transfer performance. But if this is adequate guidance on peer connectivity/speed, then this requirement may make more sense. Some clarification of what "adequate guidance" means (that is guidance about what) would be useful. > and > > "give me a sorted list of IP prefixes that are expected to give > better-than-average performance if I connect to a peer therein, > and, by the way, I am going to watch TV channel ABC over p2p > live streaming protocol XYZ." > > > The req. says that also the first query should give some > reasonable result. > > > > Editorial: > > > > I believe the abstract is difficult to parse. I personally would find > > something like the following more readable: > > > > Certain resources, such as pieces of information or server processes, > > are available from multiple hosts on the network. Applications which > > access those resources currently have no guidance on the likely > > performance of different potential sources. The goal of ALTO is to > > provide guidance for selecting among candidates sources to > > applications consuming multiply homed resources. This guidance shall > > be based on parameters that affect performance and efficiency of the > > data transmission between the hosts, e.g., the topological distance. > > The ultimate goal is to improve performance (or Quality of Experience) > > in the application while reducing resource consumption in the > > underlying network infrastructure. > > > > > > The Introduction says: > > > > The logical entities that provide the ALTO service do not take part > > in the actual user data transport, i.e., they do not implement > > functions for relaying user data. They may be placed on various > > kinds of physical nodes, e.g., on dedicated servers, as auxiliary > > processes in routers, on "trackers" or "super peers" of a P2P > > application, etc. > > > > I believe the phrase "logical entities" here is meant to imply that > > these functions are separable and that there is no necessary > > relationship between the entities providing the ALTO service and those > > providing the access to resources. > > right. furthermore, an ALTO server is not necessarily a separate > physical box. > > > If this is the case, some clarification may be useful. > > Could you please propose text? What exactly needs to be clarified? > > I believe it would be useful to recast this in functional terms, but I have not proposed text. > > > > In section 2.3, I originally read the "see section 2.2" as refering to > > section 2.2 of RFC 5693 (see section 2.2. above) would be mildly > > better. Since there is no Section 2.2 in RFC 5693, though, this is a > > self-correcting problem. > > ACK. > > > > Thanks again for the extensive review. > > Thank you for your responses. I believe that working with your AD on the next steps is appropriate. As I said above, my personal view is that time spent on requirements documents once the protocol specification is done or well on its way may not be the best use of a WG's time. How much effort you should spend on these clarifications is a matter for the WG and ADs to work through. regards, Ted > -- Sebastian > --e89a8f6478235ff97b04ad6f27e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Sebastian,

Thanks for your message, some responses in= line. =A0

On Tue, Sep 20, 2011 at 11:42 A= M, Sebastian Kiesel <ietf-alto@skiesel.de> wrote:
Ted,

thanks for the extensive review. See comments and some questions inline.
Please note: I have adjusted the mail's recipient list, in order to
catch all authors.

Thanks,
Sebastian



On Thu, Sep 15, 2011 at 09:17:18PM +0200, Ted Hardie 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-r= eview-team).
> Please resolve these comments along with any other Last Call comments<= br> > you may receive. Please wait for direction from your document shepherd=
> or AD before posting a new version of the draft.
>
> Document: draft-ietf-alto-reqs-11
> Reviewer: Ted Hardie
> Review Date: September 15, 2011
>
> Summary:
>
> I believe that this document needs further work before publication as<= br> > an Informational RFC.
>
> Major Issues:
>
> Section 5.2.1 on Classification of Information Disclosure Scenarios > has no scenarios relating to the user privacy aspects of disclosure.

We believe that the privacy concerns from the user's point of vie= w boil
down to what we call "Disclosure of the application behavior to ...&qu= ot;
"... the ALTO server" (case 2 in Section 5.2.1) or "... to a= n
unauthorized third party" (4).

This follows the logic that at least in the P2P file sharing scenario
(which was the first use case for ALTO) it's the users that run the
application overlay and therefore their privacy concerns are about
not disclosing the application behavior (e.g., who is sharing which
files with whom).

Should we add a note or clarification about that?
Or are you missing a completely different aspect of privacy (which?)?



I think the newcomer to ALTO may= have difficulty teasing out what you mean by application behavior. =A0I ce= rtainly did not read it to mean "privacy sensitive user data". = =A0I believe it would be better list this requirement with reference to wha= t is disclosed rather than in terms of application behavior.

=A0

> There is a great deal of work on the potential privacy threats related=
> to correlation of data; some reference to that threat, and any
> mitigation available, seems required. =A0The privacy discussion in
> ARv11-49 also does not discuss this, but it is a basic part of the
> risk here, since an ALTO server could theoretically see a much broader=
> set of resource requests than a single server.

The main countermeasure against the abovementioned concerns is to
use the target-independent query mode (see last paragraph on page 18).
ARv11-49 is just an addtional measure, in particular if someone
needs to use the target-aware query mode.


Assuming you mean the last paragraph o= f 17, it begins:

The disclosure of candidate resource providers' addresses to the ALTO
   server can be avoided by allowing ALTO clients to use the target-
   independent query mode.

This iss= ue here is not disclosure of resource providers' address, but disclosur= e of the queries themselves. =A0Aggregating data about the queries issued a= llows you to correlate data about the user issuing the queries; that's = the privacy issue I mentioned.
=A0

*****
> Minor Issues:
>
> REQ ARv11-8 says:
>
> =A0 =A0ARv11-8: For host group descriptor types other than "IPv4<= br> > =A0 =A0address prefix" and "IPv6 address prefix", the h= ost group descriptor
> =A0 =A0type identification MUST be supplemented by a reference to a > =A0 =A0facility, which can be used to translate host group descriptors= of
> =A0 =A0that type to IPv4/IPv6 address prefixes, e.g., by means of a ma= pping
> =A0 =A0table or an algorithm.
>
> I did not see a justification for this limitation here or in RFC 5693.=
> A host group identifier that contained, for example, an AS number
> seems to be within the scope of the protocol (though admittedly harder=
> to populate in a query).

We all agree that somtimes, for a network operator it may be easier to express preferences using host group descriptor types other
than IP addresses. AS numbers are on obvious example, maybe also
cell IDs in cellular mobile networks. However, at the end of the
day, an application does a connect() to an IP address, and therefore
needs guidance expressing preferences wrt. IP addresses. It is
(or at least was, at some point in time) consensus in the WG
that the complexity of mapping AS numbers to IP addresses should
be server-side, not client-side.


I think the re= quirement language may be misleading here. =A0Your explanation makes
<= div>it sound like the goal here is: "No matter what host descriptor ty= pe is used, the
service should return candidate IP addresses". =A0 The way I orig= inally read it, it sounded like:
"Any host descriptor must h= ave a well-known mapping to an IP address before it can
be used.&= quot; =A0Some clarification may be needed if the first is your goal.
=A0
> If this limitation is driven by an underlying requirement, I believe > it should be made explicit.

I think "complexity should be server-side" is not really a = hard
underlying requirement, it's more sort of a collective gut feeling
that this makes deployment and interoperability easier. If a network
operator prefers to express his network topology using whatever
description language that's fine, but it should not require the
application (with the embedded ALTO client) to implement additional
code or acquire additional knowledge.


Acquiring addi= tional knowledge (e.g. the external IP bound to my NATted internal IP) may<= /div>
be necessary in some cases. =A0Forbidding at a protocol level tha= t this could not be
some other piece of additional knowledge does not seem justified by th= e text in
this document or the 5693; as a baseline, I heartily ag= ree--but you are circumscribing
extensibility =A0here.=A0

Just my personal opinion, of course.


=A0
> If this is intended to be allowed under REQ. ARv11-13, then a forward<= br> > pointer that states that host group descriptors that are not
> immediately mappable to IP addresses should be extended with a
> different type would be useful.

Extensibility of host group descriptors is covered in ARv11-6.
I do not see the relation to ARv11-13.


I wondered whe= ther ARv11-13 might cover descriptors that did not fall
into ARv1= 1-6. =A0Thank you for the clarification.

=A0
=
> [Though AS number may not seem to be immediately practical, it might > actually be faster to populate in ALTO queries than the current
> external IP of a NATted or double NATted host.

How would an ALTO client located behind a NAT reliably find its
own AS number and the AS numbers of all candidate resource providers?


=A0
> By identifying the AS,
> the ALTO service provider may be able to identify peering and transit<= br> > relationships between resource providers and the node making the
> query--thus helping identify the appropriate choice. ]

The ALTO requirements draft does not prevent anyone from using AS
numbers inside the ALTO server and on the interface through which
network topology information is loaded into the ALTO server (said
interface is out of the scope of current WG standardization activities). In fact, we cannot prevent anyone from doing so, and as said above,
it may make sense to do so.

The ALTO requirements draft does not even prevent you from using AS
numbers within the ALTO client protocol. All it says is that if you
decide to expose AS numbers to the clients, you MUST provide a
(reference to a) mechanism for mapping to/from IP addresses (ARv11-8).


Does this make sense to you?


> In ARv11-12, the document is indicating that the preferences expressed=
> are relative, but it does not say whether they are pure ordinals or > whether they are weighted. =A0If this is not yet decided, that's f= ine.

The WG was not interested in deciding and freezing this at the
requirements level. The only "official" (i.e., WG document)
protocol specification does distinguish between ordinal and numerical
cost modes.


Thanks for the= clarification; it might be useful to say something like
"Pr= otocol specifications should indicate whether preferences expressed are
=A0ordinal or weighted", but if the protocol specification alread= y does so, this
may not be required.


> REQs ARv11-23 and ARv11-24, taken together, seem to implicitly require=
> that the two modes must be distinguishable, so that a client can avoid=
> sending targets to ALTO services that do not support them. =A0If this = is
> the case, an explicit statement of this in one of the two would be
> useful.

Is there a strong reason why a client should do some kind of capabili= ty
query and avoid sending unsupported query types? Of course, it's more efficient ...

The WG's protocol spec does support this capability query, but do we need to go back to the WG, ask for consensus and freeze that at the
requirements level? =A0I assume that we do not have to explicitly state
that if some protocol feature is optional, there must be *some kind* of
graceful handling if one party does not support it (RFC 2119 already
talks about the implications of optional features).



Frankly, =A0publishing protocol = requirements when the spec is already
developed all too often res= ults in exactly this: =A0rejiggering the requirements to match the
protocol already developed or in development. =A0Please work with your AD o= n whether
this is something that would be valuable.

=A0
> ARv11-27 is unclear as to whether ALTO transactions populated only
> with RFC1918 addresses are what must be supported or whether the
> intent is integration with methods for determining external addresses.=

The intent of ARv11-27 is to say that the "exchange of ALTO
transactions" must work through NAT, i.e., a transport issue.
For example, we do not want to have FTP-style back-connects to
random port numbers.

There is no intention to make any statement here about the semantics
of queries/responses accross the boundary of address realms.

Would "transport of ALTO transactions" be clearer? Any other
proposal for a wording?


I believe so, = yes.=A0

> The document currently says:
>
> =A0 =A0In particular, as a simple way of achieving some basic form of<= br> > =A0 =A0throttling, an ALTO server MAY answer ALTO queries with a "= ;Retry
> =A0 =A0After: {point in time | time delta}" message. =A0This &quo= t;Retry After" MAY
> =A0 =A0be sent as part of the ALTO reply together with the requested g= uiding
> =A0 =A0information, or as a standalone (error) message not giving the<= br> > =A0 =A0requested guidance.
>
> The first form creates an implicit requirement for a synchronized
> clock, which should either be made explicit or eliminated in favor of<= br> > the second form.

The intent of this note is to state that using HTTP with its retry-af= ter
header (RFC 2616, sec. 14.37) as an underlying protocol layer satisfies
the requirement. And HTTP defines both point in time and time delta,
AFAIR without discussing synchronized clock issues.



The RFC 2616 method also implies= the need for a synchronized clock at a resolution of one second, at least = in my view.

=A0
> REQ. ARv11-47 is not clear on the threat being addressed, so it is not=
> clear whether the messages themselves must be encrypted or encryption<= br> > of the hop-by-hop transport is sufficient. =A0Some clarification would=
> be useful.

At this requirements level, we do not have a clear architecture
in mind, e.g., is there such a thing as a proxy? Therefore, it is
diffcult to discus hop-by-hop vs. end-to-end encryption. The requirement is here to force authors of a concrete specification to think about this issue...


If you do not = have a threat model in mind, it is not clear to me what justification you h= ave for this requirement at all. =A0Required security mechanisms should be = matched against a threat; if you don't know what you're protecting = from whom, claiming that encryption of some sort is required at some point = seems less than useful.

=A0

> In REQ. ARv11-50, the document says:
>
> =A0 =A0An ALTO server MUST provide adequate guidance even if the ALTO<= br> > =A0 =A0client prefers not to specify the desired resource (e.g., keeps= the
> =A0 =A0data field empty).
>
> Depending on the data distribution method, this may not be possible. > I assume that this is meant to cover only target cases where both the<= br> > resource and target host are mentioned. =A0It would be helpful to
> clarify this.

Not neccessarily. There could be ALTO queries

"give me a sorted list of IP prefixes that are expected to give
better-than-average performance if I connect to a peer therein"


Well, personally, it is hard to see ho= w this is a useful response if the
result is that I connect to a = peer within that prefix but that node must make
onward connection= s to retrieve the resources I need. =A0In some data distribution
methods, that seems a likely result. =A0But this turns on what you mea= n
by "adequate guidance". =A0I assumed, apparently wron= gly, that this meant
adequate guidance on transfer performance. = =A0But if this is adequate guidance
on peer connectivity/speed, then this requirement may make more sense.=
Some clarification of what "adequate guidance" means (= that is guidance about what)
would be useful.
=A0
and

"give me a sorted list of IP prefixes that are expected to give
better-than-average performance if I connect to a peer therein,
and, by the way, I am going to watch TV channel ABC over p2p
live streaming protocol XYZ."


The req. says that also the first query should give some
reasonable result.


> Editorial:
>
> I believe the abstract is difficult to parse. =A0I personally would fi= nd
> something like the following more readable:
>
> Certain resources, such as pieces of information or server processes,<= br> > are available from multiple hosts on the network. =A0Applications whic= h
> access those resources currently have no guidance on the likely
> performance of different potential sources. =A0The goal of ALTO is to<= br> > provide guidance for selecting among candidates sources to
> applications consuming multiply homed resources. =A0This guidance shal= l
> be based on parameters that affect performance and efficiency of the > data transmission between the hosts, e.g., the topological distance. > The ultimate goal is to improve performance (or Quality of Experience)=
> in the application while reducing resource consumption in the
> underlying network infrastructure.
>
>
> The Introduction says:
>
> =A0 =A0The logical entities that provide the ALTO service do not take = part
> =A0 =A0in the actual user data transport, i.e., they do not implement<= br> > =A0 =A0functions for relaying user data. =A0They may be placed on vari= ous
> =A0 =A0kinds of physical nodes, e.g., on dedicated servers, as auxilia= ry
> =A0 =A0processes in routers, on "trackers" or "super pe= ers" of a P2P
> =A0 =A0application, etc.
>
> I believe the phrase "logical entities" here is meant to imp= ly that
> these functions are separable and that there is no necessary
> relationship between the entities providing the ALTO service and those=
> providing the access to resources.

right. furthermore, an ALTO server is not necessarily a separat= e
physical box.

> If this is the case, some clarification may be useful.

Could you please propose text? What exactly needs to be clarified?


I believe it w= ould be useful to recast this in functional terms, but I have
not= proposed text.


>
> In section 2.3, I originally read the "see section 2.2" as r= efering to
> section 2.2 of RFC 5693 (see section 2.2. above) would be mildly
> better. =A0Since there is no Section 2.2 in RFC 5693, though, this is = a
> self-correcting problem.

ACK.



Thanks again for the extensive review.


Thank y= ou for your responses. =A0I believe that working with your AD on the next s= teps is appropriate. =A0As I
said above, my personal view is that= time spent on requirements documents once the protocol specification is do= ne or well on its way may not be the best use of a WG's time. =A0How mu= ch effort you should spend on these clarifications is a matter for the WG a= nd ADs to work through.=A0

regards,

Ted



=A0
=A0 -- Sebastian

--e89a8f6478235ff97b04ad6f27e4-- From msk@cloudmark.com Wed Sep 21 16:23:19 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC77B1F0C54 for ; Wed, 21 Sep 2011 16:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.982 X-Spam-Level: X-Spam-Status: No, score=-102.982 tagged_above=-999 required=5 tests=[AWL=-0.383, 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-eNYi802c7G for ; Wed, 21 Sep 2011 16:23:19 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6E31F0C3E for ; Wed, 21 Sep 2011 16:23:19 -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, 21 Sep 2011 16:25:48 -0700 From: "Murray S. Kucherawy" To: Barry Leiba , "apps-discuss@ietf.org" Date: Wed, 21 Sep 2011 16:25:47 -0700 Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.txt Thread-Index: AcxzAoX1pwNLOwMCT5ef5jI7kl6hbAFsyBoQ Message-ID: References: <20110830041853.24036.37.idtracker@ietfa.amsl.com> <83FC8B77-CD70-4A25-B639-86879F645DDB@network-heretics.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" 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, 21 Sep 2011 23:23:20 -0000 > -----Original Message----- > From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists= @gmail.com] On Behalf Of Barry Leiba > Sent: Wednesday, September 14, 2011 10:20 AM > To: apps-discuss@ietf.org > Cc: Murray S. Kucherawy > Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.= txt >=20 > > Ok. =A0I won't make an issue about this. =A0 I agree that the DSN and M= DN > > RFCs is the right place to put these restrictions. >=20 > I think with this, and with the other comments and reviews so far, > this version is ready to have a last call in the working group. Let's > give it another week for comments, and say that I will send this to > the ADs on 22 September. So final comments, please, by the end of 21 > September. Hey, that's today! Want the -01 posted tonight then? -MSK From lee@cnnic.cn Wed Sep 21 17:30: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 CDBC421F8D2A for ; Wed, 21 Sep 2011 17:30:17 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MSGID_FROM_MTA_HEADER=0.803] 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 l22al61Cu9fQ for ; Wed, 21 Sep 2011 17:30:17 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id D150721F8D25 for ; Wed, 21 Sep 2011 17:30:15 -0700 (PDT) Received: (eyou send program); Thu, 22 Sep 2011 08:32:33 +0800 Message-ID: <516651553.19518@cnnic.cn> X-EYOUMAIL-SMTPAUTH: lee@cnnic.cn Received: from unknown (HELO [218.241.111.252]) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 22 Sep 2011 08:32:33 +0800 Message-ID: <4E7A8225.4060701@cnnic.cn> Date: Thu, 22 Sep 2011 08:32:37 +0800 From: Xiaodong Lee Organization: CNNIC User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org, iesg@ietf.org, bill.huang@chinamobile.com, denghui02@gmail.com, teemu.savolainen@nokia.com, dthaler@microsoft.com, dwing@cisco.com X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: [apps-discuss] apps-team review of draft-ietf-behave-v4v6-bih-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: lee@cnnic.cn List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 00:30:17 -0000 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-behave-v4v6-bih-06 Title: Dual Stack Hosts Using "Bump-in-the-Host" (BIH) Reviewer: Xiaodong Lee Review Date: 2011-09-21 Review Summary: This draft is almost ready for publication but has a few issues that should be clarified and fixed before publication. Major Issues: “BIH has the potential to interfere with the functioning of DNSSEC, because BIH modifies DNS answers, and DNSSEC is designed to detect such modifications and to treat modified answers as bogus.” as in Section 7.4. This document overall provides an valuable 4-6 translation solution. However, the effects this draft will pose on DNS should be deliberately considered. As described in BIH, ENR (Extension Name Resolve) is to modify DNS request and response messages as in ” The Extension Name Resolver (ENR) returns an answer in response to the IPv4 application’s name resolution request.” , which means BIH has the potential to interfere with the functioning of DNSSEC. Yet circumstances alter cases due to the two different ENR implementation options. In the case of the socket API layer implementation option, there is no conflicts with DNSSEC. However, in the case of the network layer implementation option, BIH modifies DNS answers, and DNSSEC is designed to detect such modifications and to treat modified answers as bogus. This draft recognizes the issue and prefers the former as in “Hence the socket API layer option is RECOMMENDED.” in section 2.3. Since this draft is intended for standard track, RECOMMENDED is not strong enough, the socket API layer option should be the “SHOULD” solution or specify that “One implementation SHOULD NOT interferes DNSSEC mechanism”. Minor Issues: NA Nits: NA -- -- Xiaodong LEE VP&CTO, CNNIC Professor, Chinese Academy of Sciences From internet-drafts@ietf.org Wed Sep 21 22:33: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 4611721F8C80; Wed, 21 Sep 2011 22:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 ShDSG0QCad7H; Wed, 21 Sep 2011 22:33:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF9321F8BB2; Wed, 21 Sep 2011 22:33:51 -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: <20110922053351.2337.12758.idtracker@ietfa.amsl.com> Date: Wed, 21 Sep 2011 22:33:51 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 05:33:52 -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-01.txt Pages : 15 Date : 2011-09-21 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-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-ietf-appsawg-rfc3462bis-01.txt From sm@elandsys.com Thu Sep 22 09:47: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 CB29421F8B7D for ; Thu, 22 Sep 2011 09:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 f0n0Lkbfq7jA for ; Thu, 22 Sep 2011 09:47:28 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id CB9E321F8B65 for ; Thu, 22 Sep 2011 09:47:28 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.118]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p8MGnjkF018013; Thu, 22 Sep 2011 09:49:50 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1316710192; bh=6PKZUvFhLBVW0yO0Y4UBv9tGs2s=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=CQvu57ecTke6OL0WkSgnI4LTyYZjXMGzvripOZe7+ZWHykpJWssi10YntMfr85zuz +PHdUQreLQ+O8dFuHJKqyoD8K6we7rvkMa+/HUNsZGwrKHsiREWT0QQJQ23lk6yU/+ 1RXRsMYhA++/y/57XG2XM+blvZsJjxnBkweppqgA= Message-Id: <6.2.5.6.2.20110922094551.09a60060@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 22 Sep 2011 09:49:32 -0700 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Henning Schulzrinne Subject: [apps-discuss] Fwd: review of draft-ietf-ecrit-lost-sync-12 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Sep 2011 16:47:29 -0000 I am forwarding the review performed by Martin Durst. Please direct the follow-up to the apps-discuss mailing list. Thanks, S. Moonesamy 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). Document: draft-ietf-ecrit-lost-sync-12 Reviewer: Martin Durst Review Date: September 22, 2011 Review Summary: This draft should be clarified in various places before being published. There is also a deeper design issue that I will mention upfront and that hopefully will be taken to heart for future work. Document Summary: The document defines a 'protocol' (actually a number of XML messages, under a common Media type, carried over http(s)) for synchronizing Location-to-Service Translation (LoST) service boundaries and mapping elements. Design Issue: It seems still in fashion to define a 'protocol' independent of underlying transport. This is preferable if there is a truely expected need for multiple transports, and if there is a large abstraction gap between the newly defined 'protocol' and the potential underlying transport mechanism. However, in the case at hand, only one transport (HTTP, including its secured equivalent HTTPS) is used, and the abstraction gap is extremely low. Once one has understood REST, it's very easy to see a set of mappings as a resource, a as a simple HTTP GET and a as a PUT. A with element would require some thought, although there are several possible solutions. Major Issues (necessary clarifications): Independence of LoST: The Introduction says: In any case, this document can also be used without the LoST protocol even though the format of the element is re-used from the LoST specification. What does "can be used without the LoST protocol" mean? If it said something like "this specification is independent of the LoST protocol specification except in that it reuses the element (and some error elements) from that specification", that would be easier to understand. Namespaces: It is overkill to define new namespaces for each spec. It's a well-known secret in the XML community that it's easily possible to add a number of new elements to an existing namespace. This would be very appropriate in this case, because the number of reused elements and attributes is quite large, and the number of new elements is low. This would simplify most of the examples. 4.2 Behavior of the LoST Sync Destination: This needs various clarifications. The first paragraph uses 'replace', the next one after the conditions uses 'update'. Is this the same? Then use the same word. Also, it says: If the received mapping M' does not update any existing mapping M then it MUST be added to the local cache as an independent mapping. If I apply this to a mapping with conditions 1. and 2. being true, but condition 3. being false, then this means that older mappings of the same source and sourceID MUST be added to the local cache. Surely this must be wrong. Also, it says that an emply element means that a "corresponding" mapping has to be determined based on source, sourceID, and lastUpdated. The "lastUpdated" here is ambiguous and could lead to differing implementations. Does lastUpdated have to match with equality? Does it have to be (the same or?) newer than the one being cached? Also, all the examples (Figs. 10/12) also contain an 'expires' attribute. Is that necessary? Does it have to be the same as the lastUpdated attribute? Please specify. Further, we have: "The element MAY carry a element": What kind of message element? If this is from RFC 5222, then please say so. In Fig. 12, there is a 'message' attribute, is that what is meant? If yes, then please fix the prose (element-> attribute). If no, then point out the difference. Fig. 12: This uses an attribute value for human-readable text. This is considered bad practice, because it forecloses the use of further markup in case this is considered necessary (can often become the case for internationalization reasons). in Transport, it says: The HTTP request MUST use the Cache-Control response directive "no-cache" to (*) HTTP-level caching At (*), a verb such as 'suppress' or 'avoid' or some such seems to be missing. Please clarify. In Operational Considerations, the use of XML Digital Signatures is mentioned. With just the text that is there, it seems impossible to guess what actually should be done. For example, how is authorization verified? Also, why only sign the first time? Wouldn't it be easier/more straightforward to just sign every time? This looks like either an afterthought (in which case the MUST isn't appropriate, because it doesn't have anything to do with the protocol per se) or some missing context (e.g. from LoST itself) in which case there should be some reference or so to clarify the context. Security Considerations: In particular the last two sentences read like security considerations not for synchronization, but for the underlying PSAP data and LoST itself. Probably similar considerations have already been given in RFC 5222 or elsewhere, in which case they should be included by reference. 9.1: "8-bit characters": This term is highly inappropriate, because it's actually 8-bit bytes, not characters. Please just point to RFC 3023. 9.1, security considerations: Replace the current text with a pointer to the security considerations in the spec (text similar to the "Published Specification" item) p. 25: The namespace document has the namespace as urn:ietf:params:xml:ns:lost1:sync, while in the examples it is urn:ietf:params:xml:ns:lostsync1. Please fix and check carefully. Minor Issues (mainly editorial): Abstract and Introduction: add a comma at end of clause The main data structure, the element, used for encapsulating information about service boundaries*,* is defined... p.4: "we call them Austria and Finland": "we call them" makes sense with fictive country names, but in this case "for example Austria and Finland" makes more sense. p. 8: "Node B issuing the first request and plays" -> "Node B is issuing the first request and plays" p. 12: There should be a short explanation of the element in the prose. 4.3: The first two example given with bullet points add a linebreak after the first attribute, it would be easier if they also added a linebreak after the second one. 6. Relax: Please add some introductory text. 7. Operational Considerations: When B obtained this new mapping it would find out that it has to distribute it to its peer C. C would also want to distribute the mapping to B (and vice versa). Either remove the 'vice versa' or the sentence before it. "If the originally mapping" -> "If the original mapping" Security Considerations: Split the long paragraph into shorter pieces for easier readability. 9.1, Additional Information: Please add "None" 10. In earlier times, the shepherd was called the PROTO shepherd. But these days, PROTO isn't used anymore as far as I know. Please remove. Regards, Martin. From alexey.melnikov@isode.com Mon Sep 26 03:20:20 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634E221F8B7B for ; Mon, 26 Sep 2011 03:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 0v8Cp0PR6Rvm for ; Mon, 26 Sep 2011 03:20:20 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 974F921F8B78 for ; Mon, 26 Sep 2011 03:20:19 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 26 Sep 2011 11:23:00 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4E805282.5050004@isode.com> Date: Mon, 26 Sep 2011 11:22:58 +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: apps-discuss@ietf.org References: <20110922053351.2337.12758.idtracker@ietfa.amsl.com> In-Reply-To: <20110922053351.2337.12758.idtracker@ietfa.amsl.com> MIME-Version: 1.0 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-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, 26 Sep 2011 10:20:20 -0000 internet-drafts@ietf.org wrote: >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. > > Title : The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-appsawg-rfc3462bis-01.txt > Pages : 15 > Date : 2011-09-21 > > 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. > > The new version addresses my earlier concerns. One small new issue: The newly added: 5. Registering New Report Types Registration of new media types for the purpose of creating a new report format SHOULD note in the Intended Usage section of the media type registration that the type being registered is suitable for use as a report-type in the context of this specification. What does "suitable for use as a report-type" means exactly? Do you mean the name of the new media type can be used as the value of this attribute? From iesg-secretary@ietf.org Mon Sep 26 07:05: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 8974521F8D05; Mon, 26 Sep 2011 07:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 lB-r8Aw-isQw; Mon, 26 Sep 2011 07:05:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1493621F8CF9; Mon, 26 Sep 2011 07:05:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110926140508.23825.79228.idtracker@ietfa.amsl.com> Date: Mon, 26 Sep 2011 07:05:08 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages) to Draft Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 14:05:08 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages' as a Draft Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-10-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc3462bis/ Implementation Report can be accessed at http://www.ietf.org/iesg/implementation.html IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc3462bis/ No IPR declarations have been submitted directly on this I-D. From ned.freed@mrochek.com Mon Sep 26 09:21: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 CA3B821F8D86 for ; Mon, 26 Sep 2011 09:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 rO1gTiZw+F8V for ; Mon, 26 Sep 2011 09:21:16 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB5421F8D82 for ; Mon, 26 Sep 2011 09:21:03 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O6I5IYZWZ400W98J@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 26 Sep 2011 09:21:53 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O68GZ66CTS014O5Z@mauve.mrochek.com>; Mon, 26 Sep 2011 09:21:48 -0700 (PDT) Message-id: <01O6I5IVA4F2014O5Z@mauve.mrochek.com> Date: Mon, 26 Sep 2011 09:18:12 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 26 Sep 2011 11:22:58 +0100" <4E805282.5050004@isode.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <20110922053351.2337.12758.idtracker@ietfa.amsl.com> <4E805282.5050004@isode.com> To: Alexey Melnikov Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-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, 26 Sep 2011 16:21:16 -0000 > internet-drafts@ietf.org wrote: > >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. > > > > Title : The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages > > Author(s) : Murray S. Kucherawy > > Filename : draft-ietf-appsawg-rfc3462bis-01.txt > > Pages : 15 > > Date : 2011-09-21 > > > > 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. > > > > > The new version addresses my earlier concerns. > One small new issue: > The newly added: > 5. Registering New Report Types > Registration of new media types for the purpose of creating a new > report format SHOULD note in the Intended Usage section of the media > type registration that the type being registered is suitable for use > as a report-type in the context of this specification. > What does "suitable for use as a report-type" means exactly? It means you're supposed to say something like: This media type is suitable for use in report-type parts per RFC3462bis. in the Intended Usage section of the type registration. In other words, this is a recommended action, not some sort of registration criteria the type must meet. > Do you mean > the name of the new media type can be used as the value of this attribute? No, that's a given for such types. Ned From alexey.melnikov@isode.com Mon Sep 26 15:10:20 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED8521F8E07 for ; Mon, 26 Sep 2011 15:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 GuD6bnVTxqJR for ; Mon, 26 Sep 2011 15:10:18 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 5419321F8DED for ; Mon, 26 Sep 2011 15:10:00 -0700 (PDT) Received: from [188.29.120.97] (188.29.120.97.threembb.co.uk [188.29.120.97]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 26 Sep 2011 23:12:39 +0100 Message-ID: <4E80DA9E.6000101@isode.com> Date: Mon, 26 Sep 2011 21:03:42 +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: Ned Freed References: <20110922053351.2337.12758.idtracker@ietfa.amsl.com> <4E805282.5050004@isode.com> <01O6I5IVA4F2014O5Z@mauve.mrochek.com> In-Reply-To: <01O6I5IVA4F2014O5Z@mauve.mrochek.com> MIME-Version: 1.0 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-ietf-appsawg-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, 26 Sep 2011 22:10:20 -0000 Ned Freed wrote: >> internet-drafts@ietf.org wrote: > >> >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. >> > >> > Title : The Multipart/Report Media Type for the >> Reporting of Mail System Administrative Messages >> > Author(s) : Murray S. Kucherawy >> > Filename : draft-ietf-appsawg-rfc3462bis-01.txt >> > Pages : 15 >> > Date : 2011-09-21 >> > >> > 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. >> > >> > >> The new version addresses my earlier concerns. >> One small new issue: > >> The newly added: >> 5. Registering New Report Types > >> Registration of new media types for the purpose of creating a new >> report format SHOULD note in the Intended Usage section of the media >> type registration that the type being registered is suitable for use >> as a report-type in the context of this specification. > >> What does "suitable for use as a report-type" means exactly? > > It means you're supposed to say something like: > > This media type is suitable for use in report-type parts per > RFC3462bis. > > in the Intended Usage section of the type registration. Ok, maybe this is just me, but I don't think this is clear. Maybe say "suitable for use as the second body part of a multipart/report" instead? > In other words, this is a recommended action, not some sort of > registration > criteria the type must meet. > >> Do you mean >> the name of the new media type can be used as the value of this >> attribute? > > No, that's a given for such types. From alexey.melnikov@isode.com Mon Sep 26 15:11:59 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2C921F8D03 for ; Mon, 26 Sep 2011 15:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 G-1RkgtF+Ol1 for ; Mon, 26 Sep 2011 15:11:59 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 46FBA21F8DAD for ; Mon, 26 Sep 2011 15:11:59 -0700 (PDT) Received: from [188.29.120.97] (188.29.120.97.threembb.co.uk [188.29.120.97]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 26 Sep 2011 23:13:16 +0100 Message-ID: <4E80F79F.80908@isode.com> Date: Mon, 26 Sep 2011 23:07:27 +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: apps-discuss@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Candidates for Applications Area Director position X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2011 22:11:59 -0000 Greetings, I've checked the list of candidates for the Apps AD position and I am only seeing 3(*) candidates who accepted the nomination. I frankly find this to be very unfortunate. There is less then 1 week left to nominate people. So, if you can think of a person who can do the job who is not on the list, please please please nominate them before October 2nd. If you are a person who thinks that he/she can do the job, please don't be shy and nominate yourself. In my humble opinion an average IETF Apps Area attendee is quite ignorant on such matters (including myself), so in many cases might not even think that a person is even available or likely to accept. And finally, if you are the person who was nominated and thinks that you can't do the job this time, please think very hard before declining the nomination. While I can tell you that being on IESG requires lots of hard work, I think many past ADs confirm that they enjoyed the experience and don't regret doing it. Thank you for listening, Alexey (*) As NomCom is using open list for nominees this years I don't think I've disclose any confidential information that people can't find out from the NomCom wiki anyway. From ietfc@btconnect.com Tue Sep 27 04:37: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 BAE5421F87FC for ; Tue, 27 Sep 2011 04:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, 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 Ka356W-Sb85B for ; Tue, 27 Sep 2011 04:37:00 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr07.btconnect.com [213.123.20.125]) by ietfa.amsl.com (Postfix) with ESMTP id BF46B21F87F0 for ; Tue, 27 Sep 2011 04:36:59 -0700 (PDT) Received: from host86-163-147-122.range86-163.btcentralplus.com (HELO pc6) ([86.163.147.122]) by c2bthomr07.btconnect.com with SMTP id ERL35354; Tue, 27 Sep 2011 12:39:31 +0100 (BST) Message-ID: <013901cc7d01$214dfc20$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Alexey Melnikov" , "Ned Freed" References: <20110922053351.2337.12758.idtracker@ietfa.amsl.com><4E805282.5050004@isode.com> <01O6I5IVA4F2014O5Z@mauve.mrochek.com> <4E80DA9E.6000101@isode.com> Date: Tue, 27 Sep 2011 12:34:57 +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=Neutral-1, source=Queried, refid=tid=0001.0A0B0303.4E81B5F1.00B0, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.7.19.51514:17:7.586, ip=86.163.147.122, 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, __URI_NO_PATH, 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=c2bthomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4E81B5F4.00B8,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@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-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: Tue, 27 Sep 2011 11:37:00 -0000 ---- Original Message ----- From: "Alexey Melnikov" To: "Ned Freed" Cc: Sent: Monday, September 26, 2011 10:03 PM > >> > > >> The new version addresses my earlier concerns. > >> One small new issue: > > > >> The newly added: > >> 5. Registering New Report Types > > > >> Registration of new media types for the purpose of creating a new > >> report format SHOULD note in the Intended Usage section of the media > >> type registration that the type being registered is suitable for use > >> as a report-type in the context of this specification. > > > >> What does "suitable for use as a report-type" means exactly? > > > > It means you're supposed to say something like: > > > > This media type is suitable for use in report-type parts per > > RFC3462bis. > > > > in the Intended Usage section of the type registration. > > Ok, maybe this is just me, but I don't think this is clear. Maybe say > "suitable for use as the second body part of a multipart/report" instead? Surely it should say "Registration of new media types for the purpose of creating a new report format SHOULD note in the Intended Usage section of the media type registration **whether or not the type being registered is suitable for use as a report-type in the context of this specification." As the text stands, it merely says that all new media types are suitable, which seems rather pointless:-) Tom Petch > > > In other words, this is a recommended action, not some sort of > > registration > > criteria the type must meet. > > > >> Do you mean > >> the name of the new media type can be used as the value of this > >> attribute? > > > > No, that's a given for such types. > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From teemu.savolainen@nokia.com Mon Sep 26 08:03: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 42CBD21F8D05; Mon, 26 Sep 2011 08:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 CXfUTJioHskg; Mon, 26 Sep 2011 08:03:48 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 59EE121F8CF3; Mon, 26 Sep 2011 08:03:48 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8QF6Cpf030733; Mon, 26 Sep 2011 18:06:19 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 18:06:00 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 26 Sep 2011 17:05:59 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.8]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0339.002; Mon, 26 Sep 2011 17:05:53 +0200 From: To: , , , , , , Thread-Topic: apps-team review of draft-ietf-behave-v4v6-bih-06 Thread-Index: AQHMeL8kJ8Eq7AO5bUCBOUeEamEB1JVfv7EQ Date: Mon, 26 Sep 2011 15:05:52 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962037717EE@008-AM1MPN1-037.mgdnok.nokia.com> References: <4E7A8225.4060701@cnnic.cn> In-Reply-To: <4E7A8225.4060701@cnnic.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Io6FujjSfNcXJGUP9WUdfQoJmpfVHi50dPq5KK9wdv8YNGkrNUplCvmjWdf9phYYMRXhwHrEJX4ib4MabW/xCLlvk8hG/TpdC8+bjCDJNRHJrq4pnSa2HqfNb2yNT6miQyGZIfcm+CuuXr5eddxJ15o/7GHyCGKTpwvHOZOvIpRrxesTFEPoly5rM5rT5pFjJ9ciw+Fla3i/aQw2KnR1QM/c/++CjTBtO0CeiVu4dZ2BzPUvEiP9JKVksK/HCT91wg== x-originating-ip: [10.162.60.47] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0261_01CC7C76.EA4DBC90" MIME-Version: 1.0 X-OriginalArrivalTime: 26 Sep 2011 15:06:00.0587 (UTC) FILETIME=[CD590DB0:01CC7C5D] X-Nokia-AV: Clean X-Mailman-Approved-At: Tue, 27 Sep 2011 08:27:25 -0700 Subject: Re: [apps-discuss] apps-team review of draft-ietf-behave-v4v6-bih-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2011 15:03:50 -0000 ------=_NextPart_000_0261_01CC7C76.EA4DBC90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thank you very much for review. Comments inline: > -----Original Message----- > From: ext Xiaodong Lee [mailto:lee@cnnic.cn] > Sent: 22. syyskuuta 2011 03:33 > To: apps-discuss@ietf.org; iesg@ietf.org; bill.huang@chinamobile.com; > denghui02@gmail.com; Savolainen Teemu (Nokia-CTO/Tampere); > dthaler@microsoft.com; dwing@cisco.com > Subject: apps-team review of draft-ietf-behave-v4v6-bih-06 > Major Issues: > "BIH has the potential to interfere with the functioning of DNSSEC, > because BIH modifies DNS answers, and DNSSEC is designed to detect such > modifications and to treat modified answers as bogus." as in Section 7.4. > > This document overall provides an valuable 4-6 translation solution. > However, the effects this draft will pose on DNS should be deliberately > considered. As described in BIH, ENR (Extension Name Resolve) is to > modify DNS request and response messages as in " The Extension Name > Resolver (ENR) returns an answer in response to the IPv4 application's > name resolution request." , which means BIH has the potential to > interfere with the functioning of DNSSEC. > > Yet circumstances alter cases due to the two different ENR > implementation options. In the case of the socket API layer > implementation option, there is no conflicts with DNSSEC. However, in > the case of the network layer implementation option, BIH modifies DNS > answers, and DNSSEC is designed to detect such modifications and to > treat modified answers as bogus. This draft recognizes the issue and > prefers the former as in "Hence the socket API layer option is > RECOMMENDED." in section 2.3. Since this draft is intended for standard > track, RECOMMENDED is not strong enough, the socket API layer option > should be the "SHOULD" solution or specify that "One implementation > SHOULD NOT interferes DNSSEC mechanism". Current wording uses RECOMMENDED, as DNSSEC can be made to work on either case. It is easier and simpler in the socket API level implementation case (that's why RECOMMENDED), but even in the network layer implementation it should be possible to configure the stub resolver to trust on ENR, which can then perform the validation. The network layer implementation of course cannot be simply dropped into any host, as DNSSEC-aware resolver on the host must work properly with ENR (especially if DNSSEC-aware resolver needs to trust ENR). So.. if the current wording needs improvement, maybe SHOULD be fine e.g. due simplicity and having less things that can go wrong, or we could leave the recommendation totally out. In the tsv-area review there was request to have pros/cons better explained. If a new pros/cons section would be created, it could then be clear that DNSSEC support is easier to arrange in socket API level implementation option. Best regards, Teemu ------=_NextPart_000_0261_01CC7C76.EA4DBC90 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTI2MTUwNTQ2WjAjBgkqhkiG9w0B CQQxFgQUnz4/svkmh5Gw1Z5rbKgkOvyqUiIwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBACWFRpjb3DUA/8NxPWIc TBF2FqVMQBmWp2CDfkl1J5JtGD5DutXsLa6n0e7VvOeX9H7lr1X9/jlgksJTZjk6C4cYBiOGpNyC iwBjhrB6BdV4yjDKPPAhq7cYDL6w07T4fCYcOGsyxnnPgQbA4X8BpWx8Yi2tjbveV/Fe/ruEooW0 26ZLaN6L2HtwTNJbYsbIMWvJEwm2wwJ0xcrGIiHLMgn4Gg7dG4YrGYk269FL18ymK75HfL4Y/Y9W h1DtGmGqiPpNRNEylsK1K5zC+ZXUn0HYjshvfB1YJUWmPumwNtAXDSbXObgBvtlvKKZCabODwr+e qF7z6KpOmXLb9njancYAAAAAAAA= ------=_NextPart_000_0261_01CC7C76.EA4DBC90-- From msk@cloudmark.com Tue Sep 27 12:42:14 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E2721F8C0C for ; Tue, 27 Sep 2011 12:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.18 X-Spam-Level: X-Spam-Status: No, score=-103.18 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 5+D7HLpKHEJr for ; Tue, 27 Sep 2011 12:42:13 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFDD21F8BF9 for ; Tue, 27 Sep 2011 12:42:13 -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, 27 Sep 2011 12:44:59 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Tue, 27 Sep 2011 12:44:57 -0700 Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-01.txt Thread-Index: Acx9CjQ6huSPXQRwSDmfrPe+qJGExAAQ4qhg Message-ID: References: <20110922053351.2337.12758.idtracker@ietfa.amsl.com><4E805282.5050004@isode.com> <01O6I5IVA4F2014O5Z@mauve.mrochek.com> <4E80DA9E.6000101@isode.com> <013901cc7d01$214dfc20$4001a8c0@gateway.2wire.net> In-Reply-To: <013901cc7d01$214dfc20$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] I-D Action: draft-ietf-appsawg-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: Tue, 27 Sep 2011 19:42:14 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of t.petch > Sent: Tuesday, September 27, 2011 3:35 AM > To: Alexey Melnikov; Ned Freed > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-01.= txt >=20 > > >> 5. Registering New Report Types > > > > > >> Registration of new media types for the purpose of creating a ne= w > > >> report format SHOULD note in the Intended Usage section of the m= edia > > >> type registration that the type being registered is suitable for= use > > >> as a report-type in the context of this specification. > > > > Surely it should say >=20 > "Registration of new media types for the purpose of creating a new > report format SHOULD note in the Intended Usage section of the media > type registration **whether or not > the type being registered is suitable for use > as a report-type in the context of this specification." >=20 > As the text stands, it merely says that all new media types are suitable, > which seems rather pointless:-) I don't agree. I think the first line of the new Section 5 makes it clear = that some are (the ones being registered specifically for that purpose), an= d some aren't (the rest). From ned.freed@mrochek.com Tue Sep 27 15:38: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 405D621F8F7C for ; Tue, 27 Sep 2011 15:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 89OSsMl3qAlS for ; Tue, 27 Sep 2011 15:38:07 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 611EE21F8EEA for ; Tue, 27 Sep 2011 15:38:07 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O6JWZRGLSG00IJGK@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 27 Sep 2011 15:38:55 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O68GZ66CTS014O5Z@mauve.mrochek.com>; Tue, 27 Sep 2011 15:38:50 -0700 (PDT) Message-id: <01O6JWZO2QPQ014O5Z@mauve.mrochek.com> Date: Tue, 27 Sep 2011 15:34:01 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 27 Sep 2011 12:34:57 +0200" <013901cc7d01$214dfc20$4001a8c0@gateway.2wire.net> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20110922053351.2337.12758.idtracker@ietfa.amsl.com> <4E805282.5050004@isode.com> <01O6I5IVA4F2014O5Z@mauve.mrochek.com> <4E80DA9E.6000101@isode.com> <013901cc7d01$214dfc20$4001a8c0@gateway.2wire.net> To: "t.petch" Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-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: Tue, 27 Sep 2011 22:38:08 -0000 > ---- Original Message ----- > From: "Alexey Melnikov" > To: "Ned Freed" > Cc: > Sent: Monday, September 26, 2011 10:03 PM > > >> > > > >> The new version addresses my earlier concerns. > > >> One small new issue: > > > > > >> The newly added: > > >> 5. Registering New Report Types > > > > > >> Registration of new media types for the purpose of creating a new > > >> report format SHOULD note in the Intended Usage section of the media > > >> type registration that the type being registered is suitable for use > > >> as a report-type in the context of this specification. > > > > > >> What does "suitable for use as a report-type" means exactly? > > > > > > It means you're supposed to say something like: > > > > > > This media type is suitable for use in report-type parts per > > > RFC3462bis. > > > > > > in the Intended Usage section of the type registration. > > > > Ok, maybe this is just me, but I don't think this is clear. Maybe say > > "suitable for use as the second body part of a multipart/report" instead? Seems like a reasonable change to me. > Surely it should say > "Registration of new media types for the purpose of creating a new > report format SHOULD note in the Intended Usage section of the media > type registration > **whether or not > the type being registered is suitable for use > as a report-type in the context of this specification." No, because a new report format is by definition suitable for use in this area. If it weren't it would not qualify as this sort of type. > As the text stands, it merely says that all new media types are suitable, > which seems rather pointless:-) That might apply if this document was discusingg media types in general, but it isn't. This is quite specifically about report formats, and this text is about the need to note that such formats identify themselves as such in their registration. Ned From ietfc@btconnect.com Wed Sep 28 06:37:40 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDBD21F893C for ; Wed, 28 Sep 2011 06:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.238, 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 PsQn88GcAa0p for ; Wed, 28 Sep 2011 06:37:39 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr09.btconnect.com [213.123.26.187]) by ietfa.amsl.com (Postfix) with ESMTP id 574F421F88B6 for ; Wed, 28 Sep 2011 06:37:35 -0700 (PDT) Received: from host86-163-147-122.range86-163.btcentralplus.com (HELO pc6) ([86.163.147.122]) by c2beaomr09.btconnect.com with SMTP id EOL72062; Wed, 28 Sep 2011 14:40:11 +0100 (BST) Message-ID: <006a01cc7ddb$26470480$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Ned Freed" References: <20110922053351.2337.12758.idtracker@ietfa.amsl.com> <4E805282.5050004@isode.com> <01O6I5IVA4F2014O5Z@mauve.mrochek.com> <4E80DA9E.6000101@isode.com> <013901cc7d01$214dfc20$4001a8c0@gateway.2wire.net> <01O6JWZO2QPQ014O5Z@mauve.mrochek.com> Date: Wed, 28 Sep 2011 14:30:54 +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.0A0B0302.4E8323BA.00E6, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.9.28.125117:17:7.944, ip=86.163.147.122, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __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, __URI_NO_WWW, __URI_NO_PATH, 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, MULTIPLE_RCPTS X-Junkmail-Status: score=10/50, host=c2beaomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4E8323BD.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: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 13:37:40 -0000 ----- Original Message ----- From: "Ned Freed" To: "t.petch" Cc: "Alexey Melnikov" ; "Ned Freed" ; Sent: Wednesday, September 28, 2011 12:34 AM > > ---- Original Message ----- > > From: "Alexey Melnikov" > > To: "Ned Freed" > > Cc: > > Sent: Monday, September 26, 2011 10:03 PM > > > >> > > > > >> The new version addresses my earlier concerns. > > > >> One small new issue: > > > > > > > >> The newly added: > > > >> 5. Registering New Report Types > > > > > > > >> Registration of new media types for the purpose of creating a new > > > >> report format SHOULD note in the Intended Usage section of the media > > > >> type registration that the type being registered is suitable for use > > > >> as a report-type in the context of this specification. > > > > > > > >> What does "suitable for use as a report-type" means exactly? > > > > > > > > It means you're supposed to say something like: > > > > > > > > This media type is suitable for use in report-type parts per > > > > RFC3462bis. > > > > > > > > in the Intended Usage section of the type registration. > > > > > > Ok, maybe this is just me, but I don't think this is clear. Maybe say > > > "suitable for use as the second body part of a multipart/report" instead? > > Seems like a reasonable change to me. > > > Surely it should say > > > "Registration of new media types for the purpose of creating a new > > report format SHOULD note in the Intended Usage section of the media > > type registration > > **whether or not > > the type being registered is suitable for use > > as a report-type in the context of this specification." > > No, because a new report format is by definition suitable for use in > this area. If it weren't it would not qualify as this sort of type. > > > As the text stands, it merely says that all new media types are suitable, > > which seems rather pointless:-) > > That might apply if this document was discusingg media types in general, but > it isn't. This is quite specifically about report formats, and this text > is about the need to note that such formats identify themselves as such > in their registration. Ok, I see now, but did misunderstand, as I think Alexey did. It does seem a bit circular, that you are saying that anything that is a new report format SHOULD be suitable for use in the context of this memo and SHOULD say so. The bit I was missing was the first part, that a new report format is automatically suitable for use; I was thinking of 'report format' as having a looser, more generic meaning of which some would be suitable and some would not. Tom Petch > > Ned From lef.mutualauth@gmail.com Fri Sep 30 22:40: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 66AB921F8B3E; Fri, 30 Sep 2011 22:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lZoHCF3oiJ0; Fri, 30 Sep 2011 22:40:20 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 11EA921F8B29; Fri, 30 Sep 2011 22:40:19 -0700 (PDT) Received: by wwf22 with SMTP id 22so2512930wwf.13 for ; Fri, 30 Sep 2011 22:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i7Bo8h5pZC9ukKVJUpfyqtdueo4nK4C7vKaqUMHkPH8=; b=fWaB+BEYLzObKMm5rK2UouwFVeDs9QNkRvHYhlRKvHfOTUx+hPgPQ2YmLhQtDTObjz QvAqdsPGdQotFR5VxdEWnhnJD+HwIt6qYc7RjgY31lb1vDGfwmPAKG4zqZPrBjJ1B/8Z 5lWxDSOjkamCgMNq9jrO2926Us6E3XOs9A36k= MIME-Version: 1.0 Received: by 10.216.229.103 with SMTP id g81mr9037487weq.0.1317447795219; Fri, 30 Sep 2011 22:43:15 -0700 (PDT) Received: by 10.216.37.146 with HTTP; Fri, 30 Sep 2011 22:43:15 -0700 (PDT) In-Reply-To: <4E2CA293.70603@stpeter.im> References: <5FA6AD59-7570-4A85-B6D1-3DC8E42688F1@mnot.net> <234F16BC-9875-474B-95B3-D61E8BE5A6E0@checkpoint.com> <4E2CA293.70603@stpeter.im> Date: Sat, 1 Oct 2011 14:43:15 +0900 Message-ID: From: "HAYASHI, Tatsuya" To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=0016e6469a2ed81bc904ae3637e9 Cc: "http-auth@ietf.org" , Yoav Nir , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] [http-auth] HTTP-Auth BoF in Quebec City Postponed X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2011 05:40:21 -0000 --0016e6469a2ed81bc904ae3637e9 Content-Type: text/plain; charset=ISO-8859-1 Hi! Peter. The cut-off date of BOF proposal requests in IETF Taipei is coming soon. Taking account of the recent status of this list, I don't think we have a BOF in Taipei. However, I want to improve the authentication in the web too, so is there any intention to have a side meeting to clarify the scope and the problem? As a co-author of the problem statement draft by Yutaka Oiwa, I want the draft enhanced by other guys familiar with authentication. (We are updating a draft!) Sincerely, On Monday, July 25, 2011, Peter Saint-Andre wrote: > On 7/24/11 3:37 PM, Nico Williams wrote: >> Sadly I cannot attend. I planned my travel schedule for this week >> around the original BoF, and so I depart Quebec in the afternoon. I >> look forward to the notes from any bar BoF :) > > A few of us got together just now in a side room to chat informally. > We'll post further about some actions sometime soon. :) > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- -- HAYASHI, Tatsuya Lepidum Co. Ltd. --0016e6469a2ed81bc904ae3637e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi! Peter.

The cut-off date of BOF proposal requests in IETF Tai= pei is coming soon.
Taking account of the recent status of this list, I = don't think we
have a BOF in Taipei. However, I want to improve the = authentication in
the web too, so is there any intention to have a side meeting to
clarify= the scope and the problem?

As a co-author of the problem statement = draft by Yutaka Oiwa, I want
the draft enhanced by other guys familiar w= ith authentication.
(We are updating a draft!)

Sincerely,

On Monday, July 25, 201= 1, Peter Saint-Andre <stpeter@stpe= ter.im> wrote:
> On 7/24/11 3:37 PM, Nico Williams wrote:
>> Sadly I cannot attend. =A0I planned my travel schedule for this we= ek
>> around the original BoF, and so I depart Quebec in the after= noon. =A0I
>> look forward to the notes from any bar BoF :)
>= ;
> A few of us got together just now in a side room to chat informally.> We'll post further about some actions sometime soon. :)
><= br>> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> _______________________________________________
>= ; apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss<= /a>
>

--
--
HAYASHI, Tatsuya
Lepidum Co. Ltd.

--0016e6469a2ed81bc904ae3637e9--