From nobody Mon Jun 1 01:48:59 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3811A9066 for ; Mon, 1 Jun 2015 01:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDm5Jz33GPm8 for ; Mon, 1 Jun 2015 01:48:56 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 429B91A905C for ; Mon, 1 Jun 2015 01:48:55 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 473FEFA0073; Mon, 1 Jun 2015 08:48:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1433148534; bh=5Ky0J1TENqnvYFv3E/2ebQ619ksgrbdPcWCnmuT+2mU=; h=From:To:Subject:References:Date:From; b=P/bFgmyP5igznWvjVxzi0phK9mMo1bNuQKgpGURbErdoX9phBCpJ/R9qgHRU75zoD zQSitDGQ4xQRs4jNQiVZDB8MuA8bYbdTgwdqfyRlMdkIjh9MxOHy3ipWxIoHApP7zi 4EmLS/7L+YPwCG2fNwfYLCIeqSwQpmBKCAJEkRY0= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1433148533-28872-28871/12/37; Mon, 1 Jun 2015 08:48:53 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org, Nick Matavka Message-Id: References: Mime-Version: 1.0 Content-Type: text/plain; format=flowed Date: Mon, 1 Jun 2015 08:48:53 +0000 Archived-At: Subject: Re: [apps-discuss] apps-discuss Digest, Vol 88, Issue 23 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 08:48:57 -0000 In this case the relevant AD is probably the one who has to, if someone has to sort things out and make a decision. That is Barry now, right? It may also be his co-AD, or MSK, but they will all agree, do it does not really matter which one if them decides. Arnt From nobody Mon Jun 1 03:45:28 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE8B1AC3E9 for ; Mon, 1 Jun 2015 03:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4SdohYH4e1S for ; Mon, 1 Jun 2015 03:45:23 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0775.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::775]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D46D1AC3E7 for ; Mon, 1 Jun 2015 03:45:22 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.151.162.168) by DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) with Microsoft SMTP Server (TLS) id 15.1.172.22; Mon, 1 Jun 2015 10:45:02 +0000 Message-ID: <046701d09c57$aeff5040$4001a8c0@gateway.2wire.net> From: t.petch To: Nick Matavka , References: Date: Mon, 1 Jun 2015 11:28:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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-Originating-IP: [81.151.162.168] X-ClientProxiedBy: DB5PR09CA0009.eurprd09.prod.outlook.com (25.161.191.19) To DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB057; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:DB3PR07MB057; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB057; X-Forefront-PRVS: 05947791E4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(5403001)(24454002)(13464003)(10533003)(189002)(18543002)(51704005)(199003)(377454003)(4001540100001)(97736004)(5001770100001)(81156007)(5001830100001)(92566002)(122386002)(1456003)(46102003)(62236002)(44716002)(5001960100002)(107886002)(86362001)(189998001)(61296003)(5001860100001)(77156002)(62966003)(40100003)(105586002)(76176999)(50986999)(81686999)(42186005)(14496001)(84392001)(116806002)(101416001)(81816999)(19580405001)(19580395003)(23676002)(50466002)(33646002)(106356001)(77096005)(15975445007)(68736005)(44736004)(50226001)(1556002)(64706001)(87976001)(47776003)(66066001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB057; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jun 2015 10:45:02.8327 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB057 Archived-At: Subject: Re: [apps-discuss] apps-discuss Digest, Vol 88, Issue 23 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 10:45:26 -0000 ----- Original Message ----- From: "Nick Matavka" To: Sent: Monday, June 01, 2015 1:16 AM > Julian Reschke wrote: > > Nick, this WG discusses whether work on Gopher fits here. Rants like > > these are not helpful at all, and likely will affect the outcome. > > > FWIW, I fully agree with Larry. > > > Best regards, Julian > > I didn't mean to be ranty, Julian. I meant to raise a point, that's all, > and I still haven't received an answer. > > *Who* decides what a "high-value project" is? I think it's an important > question. If it's group "consensus", how is "consensus" defined? Does > consensus mean EVERYONE agrees (unanimous), or simply the prevailing wind > of opinion? Larry makes good points, I agree, but his tone of voice is > infuriating sometimes. What is the definition of a high-value project, > anyway? To whom should the project be highly valuable? If the answer to > this is, "the Internet-using public," who judges what is valuable to the > public? Nick The IETF is a bottom-up organisation, even if it has imported management ideas such as WG Chairs, appeals, the IESG and ADs so it is very much us, for some meaning of us, that decides. I participate here as an individual, very much so, never having been or going to be anything else, such as Chair, AD etc, nor do I contribute much as an author of I-Ds. Yet the approach of the IETF is to take into consideration the views of one such as I along with the views of everyone else who expresses a view. For any one decision, to adopt an I-D, to Last Call, to forward it to the IETF and so on, there is someone allocated to call consensus, and in most cases, it is the WG Chair. So know who they are, and note what they say! Consensus is ill-defined, deliberately so. It takes into consideration views expressed on the mailing list and views not expressed. If noone responds to a call for adoption, the WG Chair will conclude that there is no support and the I-D will be rejected just as if 10 people spoke against adoption. The I-D may be the latest, greatest social media app but if 'us' are unwilling to work on it, then the IETF does not work on it. Consensus is not unanimity, nor is it majority. I have known four in favour, a dozen against, and consensus declared in favour; rightly so, as the four were independent implementors of code. It was going to happen, better in a WG than without. I know what I would call as consensus on gopher but that call is not mine to make, or suggest. The WG Chairs will do so when the time is right (or when they are pushed to do so!). They can justify their call (and it can be appealed) but their logic is unlikely to be the same as yours; it is likely to be along the lines of have enough people said on this list that they will work on it.and progress it through to an RFC. I-Ds that die the death along the way waste a lot of valuable resources that, with hindsight, would have been better spent elsewhere. Tom Petch > Larry's right in being concerned about what I would call the > signal-to-noise ratio of this mailing list. The fact is that there is the > possibility and, in fact, the reality of irrelevant, insulting, and/or > uninformed feedback. Some people just can't be professional about it; I'm > not talking about Larry or myself, because I know we're decent people who > just can't seem to disagree civilly, but the fact is that there are people > with a consistent history of making unconstructive feedback either out of > ignorance or because it amuses them. > > And if I were him, I would raise another reservation; not a pure objection, > because I wouldn't object to my own project, but I would ask if the author > is able and willing to work within the IETF framework. I would ask if the > author or authors are willing to listen to, and heed, technically > reasonable input and to have drafts updated within a reasonable turnaround > time. I would also think about whether the author responds in an adult way > to feedback, either positive or negative. > > I have no objection to Masinter's opinions, but rather his wording. In > fact, I agree with the questions he raises, but he should define his words > more carefully because what he writes might be mistaken for > belligerence---this is why I replied to his comments in an equally > belligerent tone, but with reasoned argument. > > Fraternal regards, > > Ed Matavka > ------------------------------------------------------------------------ -------- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Mon Jun 1 04:20:54 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75501A0021 for ; Mon, 1 Jun 2015 04:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5Vuug4fbE-c for ; Mon, 1 Jun 2015 04:20:51 -0700 (PDT) Received: from APAC01-SG1-obe.outbound.protection.outlook.com (mail-sg1hn0123.outbound.protection.outlook.com [134.170.132.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611241A0006 for ; Mon, 1 Jun 2015 04:20:50 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OS2PR01MB0140.jpnprd01.prod.outlook.com (25.161.77.148) with Microsoft SMTP Server (TLS) id 15.1.172.22; Mon, 1 Jun 2015 11:20:45 +0000 Message-ID: <556C4007.3030408@it.aoyama.ac.jp> Date: Mon, 1 Jun 2015 20:20:39 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: t.petch , Nick Matavka , References: <046701d09c57$aeff5040$4001a8c0@gateway.2wire.net> In-Reply-To: <046701d09c57$aeff5040$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS2PR01CA0011.jpnprd01.prod.outlook.com (25.161.74.149) To OS2PR01MB0140.jpnprd01.prod.outlook.com (25.161.77.148) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS2PR01MB0140; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5005006)(520003)(3002001); SRVR:OS2PR01MB0140; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0140; X-Forefront-PRVS: 05947791E4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(51704005)(189002)(199003)(18543002)(24454002)(5403001)(10533003)(479174004)(80316001)(5001830100001)(5001860100001)(107886002)(5001960100002)(189998001)(19580395003)(83506001)(92566002)(74482002)(46102003)(33656002)(50986999)(87266999)(76176999)(65816999)(101416001)(87976001)(47776003)(50466002)(86362001)(85182001)(23676002)(64126003)(66066001)(65956001)(65806001)(105586002)(2950100001)(77156002)(62966003)(122386002)(40100003)(68736005)(54356999)(64706001)(106356001)(85202003)(59896002)(42186005)(4001540100001)(81156007)(4001350100001)(5001770100001)(97736004)(7059030)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR01MB0140; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jun 2015 11:20:45.8045 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0140 Archived-At: Subject: Re: [apps-discuss] apps-discuss Digest, Vol 88, Issue 23 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 11:20:52 -0000 Thanks Tom for saying most of what I was thinking about saying. Just one additional clarification below. On 2015/06/01 19:28, t.petch wrote: > The IETF is a bottom-up organisation, even if it has imported management > ideas such as WG Chairs, appeals, the IESG and ADs so it is very much > us, for some meaning of us, that decides. I participate here as an > individual, very much so, never having been or going to be anything > else, such as Chair, AD etc, nor do I contribute much as an author of > I-Ds. Yet the approach of the IETF is to take into consideration the > views of one such as I along with the views of everyone else who > expresses a view. > > For any one decision, to adopt an I-D, to Last Call, to forward it to > the IETF and so on, there is someone allocated to call consensus, and in > most cases, it is the WG Chair. So know who they are, and note what > they say! > > Consensus is ill-defined, deliberately so. It takes into consideration > views expressed on the mailing list and views not expressed. If noone > responds to a call for adoption, the WG Chair will conclude that there > is no support and the I-D will be rejected just as if 10 people spoke > against adoption. The I-D may be the latest, greatest social media app > but if 'us' are unwilling to work on it, then the IETF does not work on > it. The 'us' here means anybody who's willing to show up. There's NO barrier to entry except subscribing to a mailing list, and even that isn't necessary for the first expression of interest. Regards, Martin. > Consensus is not unanimity, nor is it majority. I have known four in > favour, a dozen against, and consensus declared in favour; rightly so, > as the four were independent implementors of code. It was going to > happen, better in a WG than without. > > I know what I would call as consensus on gopher but that call is not > mine to make, or suggest. The WG Chairs will do so when the time is > right (or when they are pushed to do so!). They can justify their call > (and it can be appealed) but their logic is unlikely to be the same as > yours; it is likely to be along the lines of have enough people said on > this list that they will work on it.and progress it through to an RFC. > I-Ds that die the death along the way waste a lot of valuable resources > that, with hindsight, would have been better spent elsewhere. > > Tom Petch From nobody Mon Jun 1 11:11:28 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236E61B301D for ; Mon, 1 Jun 2015 11:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kde5syzu2d8M for ; Mon, 1 Jun 2015 11:11:24 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9BF1B2FD2 for ; Mon, 1 Jun 2015 11:11:24 -0700 (PDT) Received: by wgez8 with SMTP id z8so121226573wge.0 for ; Mon, 01 Jun 2015 11:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yEArxfn9RxdbG7B8iKPu7ve54a7D8fpH7GNdqiodois=; b=RFAowNZhfqJpUI4fkMD6NNJ78lYgMyRvwjfKxFYgk98AEst3TFEZt0ZMJL16Rk9q5q jxienmJB3LPO2gMaOKmIi696PXIcAx6vKkm/5JkZgXMjku/p2ChoJw0LerI2URXRrez2 +6xpNXkB3GYu4GjcxuYgRt4eeK4/V6m1gfyAu1FpWFCbvdpq5Bk0VWWDeqb4pXzhMr/3 IFsGn26SUbcVqYSVd5x3dEmnXx0HlCiYCXjY5QUH/OHUhNSVsahU7noIBLPSeiAfAFRY yB+ARLc2kYypRGeqzfGTCw+ruYiK5y/TixIkjC6W47gHHvHTv4FtKUMl9PmFAAptStqG dnWA== MIME-Version: 1.0 X-Received: by 10.194.22.131 with SMTP id d3mr32667910wjf.111.1433182282735; Mon, 01 Jun 2015 11:11:22 -0700 (PDT) Received: by 10.27.6.207 with HTTP; Mon, 1 Jun 2015 11:11:22 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Jun 2015 11:11:22 -0700 Message-ID: From: "Murray S. Kucherawy" To: Nick Matavka Content-Type: multipart/alternative; boundary=047d7b5d504edc6637051778c046 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] apps-discuss Digest, Vol 88, Issue 23 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 18:11:27 -0000 --047d7b5d504edc6637051778c046 Content-Type: text/plain; charset=UTF-8 With no hat on, and speaking only for myself here: On Sun, May 31, 2015 at 5:16 PM, Nick Matavka < n.theodore.matavka.files@gmail.com> wrote: > I didn't mean to be ranty, Julian. I meant to raise a point, that's all, > and I still haven't received an answer. > > *Who* decides what a "high-value project" is? I think it's an important > question. If it's group "consensus", how is "consensus" defined? Does > consensus mean EVERYONE agrees (unanimous), or simply the prevailing wind > of opinion? Larry makes good points, I agree, but his tone of voice is > infuriating sometimes. What is the definition of a high-value project, > anyway? To whom should the project be highly valuable? If the answer to > this is, "the Internet-using public," who judges what is valuable to the > public? > These are all interesting questions, and I daresay the IETF has an ongoing inability to nail them down exactly. I could argue that that's actually a feature and not a bug, because precise rules on the topic could be gamed. The basic answer is that the community decides, via discussion and volunteerism, what work it wants to take on. The results of the discussion are gauged by people elected or appointed to management positions (Working Group chairs, Area Directors, etc.), by gauging the rough consensus of the discussion when a decision needs to be made. That's how we select what things will be taken on by new or existing working groups, and anything that can't find a home by that process can then decide if it wants to go the independent route. What you saw after you posted your draft, and later more official calls for discussion were made, was individual participants weighing in on the question being asked. None of them have specific authority to say "yes" or "no", but rather were part of the community whose rough consensus is to be measured when deciding what option to pursue. Speaking only for myself though, I disagree with the "high-value" idea as being an explicit barrier to entry. Rather, if there's a subset of the community that will commit to putting in the work, then we ought to do the work, even if a few people might think that subset is clearly misguided about what it thinks is important. Some of their concerns are well-founded: We are all volunteers here, so our time to do work is precious, so do need to be careful what we agree to take on. So, then, the filter is us, not some written-down definition of "high-value": The community, in theory representative of the Internet-using public, is assumed to have some idea of what's important, critical, or interesting, and we rely on that assumption and the assumption that they will want to spend their time on those things. > Larry's right in being concerned about what I would call the > signal-to-noise ratio of this mailing list. The fact is that there is the > possibility and, in fact, the reality of irrelevant, insulting, and/or > uninformed feedback. Some people just can't be professional about it; I'm > not talking about Larry or myself, because I know we're decent people who > just can't seem to disagree civilly, but the fact is that there are people > with a consistent history of making unconstructive feedback either out of > ignorance or because it amuses them. > Yes, and people at all levels of the organization are concerned about this sort of thing and have been for quite some time. And if I were him, I would raise another reservation; not a pure objection, > because I wouldn't object to my own project, but I would ask if the author > is able and willing to work within the IETF framework. I would ask if the > author or authors are willing to listen to, and heed, technically > reasonable input and to have drafts updated within a reasonable turnaround > time. I would also think about whether the author responds in an adult way > to feedback, either positive or negative. > Yes again, to all of that. And not only the author, but anyone else that wants to do the work. To use your proposal as a specific example, we haven't seen anyone other than you from outside the IETF express interest in supporting the progression of your draft. To establish a critical mass, that puts a burden on you to find a set of existing IETF participants that are interested in helping you progress the document through a working group or AD sponsorship all the way to publication, since you don't appear to have brought any support of your own (other than yourself, of course). But either way, whoever will "sponsor" the work (an Area Director, or a Working Group chair) does indeed have to ask those questions and be assured of the answers. We certainly don't want to accept a document for processing and then have all the interested parties wander off to do something else before it's done; that's an expensive mistake. -MSK --047d7b5d504edc6637051778c046 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
With no hat on, and speaking only for myself here:

= On Sun, May 31, 2015 at 5:16 PM, Nick Matavka <n.theodore= .matavka.files@gmail.com> wrote:
I didn't mean to be ranty, Julian.=C2=A0 I meant to raise a point, th= at's all, and I still haven't received an answer.

*Who* decides what a "high-value project" is?=C2=A0 I thin= k it's an important question.=C2=A0 If it's group "consensus&q= uot;, how is "consensus" defined?=C2=A0 Does consensus mean EVERY= ONE agrees (unanimous), or simply the prevailing wind of opinion?=C2=A0 Lar= ry makes good points, I agree, but his tone of voice is infuriating sometim= es.=C2=A0 What is the definition of a high-value project, anyway?=C2=A0 To = whom should the project be highly valuable?=C2=A0 If the answer to this is,= "the Internet-using public," who judges what is valuable to the = public?

These are all int= eresting questions, and I daresay the IETF has an ongoing inability to nail= them down exactly.=C2=A0 I could argue that that's actually a feature = and not a bug, because precise rules on the topic could be gamed.

The basic answer is that the community decides, via discussion and= volunteerism, what work it wants to take on.=C2=A0 The results of the disc= ussion are gauged by people elected or appointed to management positions (W= orking Group chairs, Area Directors, etc.), by gauging the rough consensus = of the discussion when a decision needs to be made.=C2=A0 That's how we= select what things will be taken on by new or existing working groups, and= anything that can't find a home by that process can then decide if it = wants to go the independent route.=C2=A0 What you saw after you posted your= draft, and later more official calls for discussion were made, was individ= ual participants weighing in on the question being asked.=C2=A0 None of the= m have specific authority to say "yes" or "no", but rat= her were part of the community whose rough consensus is to be measured when= deciding what option to pursue.

Speaking only= for myself though, I disagree with the "high-value" idea as bein= g an explicit barrier to entry.=C2=A0 Rather, if there's a subset of th= e community that will commit to putting in the work, then we ought to do th= e work, even if a few people might think that subset is clearly misguided a= bout what it thinks is important.=C2=A0 Some of their concerns are well-fou= nded: We are all volunteers here, so our time to do work is precious, so do= need to be careful what we agree to take on.=C2=A0 So, then, the filter is= us, not some written-down definition of "high-value": The commun= ity, in theory representative of the Internet-using public, is assumed to h= ave some idea of what's important, critical, or interesting, and we rel= y on that assumption and the assumption that they will want to spend their = time on those things.
=C2=A0
Larry's right in being concerned abo= ut what I would call the signal-to-noise ratio of this mailing list.=C2=A0 = The fact is that there is the possibility and, in fact, the reality of=C2= =A0irrelevant, insulting, and/or uninforme= d feedback.=C2=A0 Some people just can't be professional about it; I= 9;m not talking about Larry or myself, because I know we're decent peop= le who just can't seem to disagree civilly, but the fact is that there = are people with a consistent history of making unconstructive feedback eith= er out of ignorance or because it amuses them.

Yes, and people at all levels of the organizat= ion are concerned about this sort of thing and have been for quite some tim= e.

<= span style=3D"font-size:12.8px">And if I were him, I would raise another re= servation; not a pure objection, because I wouldn't object to my own pr= oject, but I would ask if the author is able and willing to work within the= IETF framework.=C2=A0 I would ask if the author or authors are willing to = listen to, and heed, technically reasonable input and to have drafts update= d within a reasonable turnaround time.=C2=A0 I would also think about wheth= er the author responds in an adult way to feedback, either positive or nega= tive.

Yes again, t= o all of that.=C2=A0 And not only the author, but anyone else that wants to= do the work.=C2=A0 To use your proposal as a specific example, we haven= 9;t seen anyone other than you from outside the IETF express interest in su= pporting the progression of your draft.=C2=A0 To establish a critical mass,= that puts a burden on you to find a set of existing IETF participants that= are interested in helping you progress the document through a working grou= p or AD sponsorship all the way to publication, since you don't appear = to have brought any support of your own (other than yourself, of course).= =C2=A0 But either way, whoever will "sponsor" the work (an Area D= irector, or a Working Group chair) does indeed have to ask those questions = and be assured of the answers.=C2=A0 We certainly don't want to accept = a document for processing and then have all the interested parties wander o= ff to do something else before it's done; that's an expensive mista= ke.

-MSK
--047d7b5d504edc6637051778c046-- From nobody Tue Jun 2 14:14:47 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485E61B2C1C for ; Tue, 2 Jun 2015 14:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXv4DUyerTE7 for ; Tue, 2 Jun 2015 14:14:45 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425F71A8A49 for ; Tue, 2 Jun 2015 14:14:45 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 63E99202FB for ; Tue, 2 Jun 2015 17:14:44 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 02 Jun 2015 17:14:44 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=ZFg HL/pe9ombGIQPD4epuR4/ENc=; b=Q8c6XS5W0+H3tkRF03taWiDRW4BtTgxRnfX g4hPSU4mfktBMKx0ydQs0r1sMWM2bevS6Bf39JsRN1DRAbsVXA7g5TYCL5uCSixk qWFPJc1ecKrlSIWQToWQuUUOqOcuWAlNeh8c38sQ5obp2MpkwPwuTRGfO1oQ7QHR YIh1kDKI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=ZFgHL/pe9ombGIQPD4epuR4/ENc=; b=PKc7+ FoIPaJk7D4OZA+cJLTT7cHZNsg5ma5ToHsQ4d8Wn2XvinP1nNtK6ebiJEErhQyOR tuenB8uEuWem8ThSXIOlYft7U6KUJ+RyyL7qk2JXap/N/7PcOxiwTb6jqZlZPEsz 8Tl7KpRmjEOF4w0X2bYjm2a6yTo6ywTwwwdpe4= X-Sasl-enc: 3l9pJdcKuRHula6raBymQFxf9WqxP78Iv01CrxDtEubu 1433279683 Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.161]) by mail.messagingengine.com (Postfix) with ESMTPA id BD95368012A for ; Tue, 2 Jun 2015 17:14:43 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <857F0432-9F72-4C4D-ABAF-6E36CDA9A15B@cooperw.in> Date: Tue, 2 Jun 2015 14:14:42 -0700 To: apps-discuss@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [apps-discuss] James Polk X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 21:14:46 -0000 I wanted to let you know that our colleague and friend James Polk passed = away last week. James participated in the IETF for over a decade. Over = the years he made many valuable contributions that spanned the areas, = with particular focus on SIP, emergency services, geolocation, and = differentiated services. Beyond his technical work, he sought to make = improvements in the role of WG chair and the IETF overall. I think we = all knew him as a fierce defender of the solutions he believed in who = also had a softer side. He will be missed at the IETF and at Cisco. Please keep James' family in your thoughts. Alissa= From nobody Wed Jun 3 08:12:13 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508721A8AC5 for ; Wed, 3 Jun 2015 08:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFy3FVvq7LoL for ; Wed, 3 Jun 2015 08:12:11 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4AC21A8ACA for ; Wed, 3 Jun 2015 08:12:10 -0700 (PDT) Received: from [192.168.1.158] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Ltqb7-1Z7png0Di9-0117kI; Wed, 03 Jun 2015 17:12:09 +0200 Message-ID: <556F1940.9020002@gmx.de> Date: Wed, 03 Jun 2015 17:12:00 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Nick Matavka References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:u/z9iOBwSdto76jkKZ1r0ekR9E6qZdaLcpuHpGg4vjqkgWBhgW6 djcMevx9SBi+fLNEFyGX+Iucgfu7JY64j4AQFVOAT7oXJpxbkuKf/4Y1icdwcO+t1UUMVHP 1itM6dCaKosZDyzL/UExgUI+yGGPG1mc+GPTPBOQxukJPMPclf4JmMpTNAeg0uekIgHzSSY veNLZyZW9dwWnSArmBx5w== X-UI-Out-Filterresults: notjunk:1;V01:K0:5XVjsYNojRg=:Of7LOERmdZJBPqHi9ncY3K qchZXIBeRNCiJrzOmAg7VSNZ74LwNl8wo+qclRk6mi82OYU46KnGLsNRSrQla+wEheU4Qz74U QoNVZUlXllD4f2KxVAyPeDSDF2VNGA7dssU/kggSre7TcP9p5hncVushA8Q5NgPa+ydA+8IXr EPgwN3z3/UJPNxhSJy5djh+euTz8fxTVszdpVJ78lTPxT7hVzi+lu5gBOUP+YkWc9tnM9cgEJ 2m7CIJkT2801n5u66xfRUGmO78fVl2HYTgzF1QvkUFQbflcjshVTArBVkRRknSVGLXBimComJ DtiiNY1fL8lgkqbtm58iG+s9koG/vG4txwTfomzjPX3RM2dklYsCMEVPjeVKGOgERD/zb/+IT 3guafO4tQ7vQFuaVytreG3QvH6xncE+s7l20kVE7TqcGR/Y9iwFUKBh0FheERJJtP/uGIvSfV ODXnF+4yKzUoE+zyYgVaaal2kk++szQH+SCNs8bQo05MaRqt62IJwk5QFkoz8XW0+5s8w0L6H IhnZOE0aad3EEX5CQLKS+4faRbQs2voF9RCibyzHkoupbN6WC0Roy083PSaJ5MiecKI3KwZii Ed+hjeFVneQX0ZOIwPMvmGHB5SBtS9v4bBzC+gItEXsIj5YTwZKy95OiLhOg6SZ8TvLp1HUj1 jAtH8ye8hmv08ufWkUT9TUTcs8/2is1Hi0G1fvkb8ZDGZHzi4n7qEyUtpI5FPIJeLZCE= Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] apps-discuss Digest, Vol 88, Issue 23 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jun 2015 15:12:12 -0000 On 2015-06-01 02:16, Nick Matavka wrote: > Julian Reschke wrote: > > Nick, this WG discusses whether work on Gopher fits here. Rants like > > these are not helpful at all, and likely will affect the outcome. > > > FWIW, I fully agree with Larry. > > > Best regards, Julian > > I didn't mean to be ranty, Julian. I meant to raise a point, that's > all, and I still haven't received an answer. Well, you were. And yes, that's subjective. And maybe the reason why you did not get any reply to *that* mail is because of the tone it was written in. Just a theory. Best regards, Julian From nobody Wed Jun 3 08:44:04 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E321A908F for ; Wed, 3 Jun 2015 08:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-fSWHUZLS-B for ; Wed, 3 Jun 2015 08:44:01 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0061A908B for ; Wed, 3 Jun 2015 08:44:00 -0700 (PDT) Received: by lbcue7 with SMTP id ue7so9863835lbc.0 for ; Wed, 03 Jun 2015 08:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fr3+qNAeA1Wosz665V9bC+CtT8g4NKr9DV2UXvoZcc0=; b=gedzbc6PdqwqDjdGno6ig2B1NrD3q0SdYvUW66JOBnKoOMsntOGxyGMIKlLurFqbw7 mXaS3g1nosUsLZTCCUPKZKBvhZ5kJ5A0eU6qZPK4/FjcZq95Ck3igJEifQOtKb4PSHPg r28yhADwElLBFj4i2YIT70NPaO5wK/Gbtk6ZPi71KazAmSz0+oWX+35Nx87AU6nu4U8q FLegyBJX6GDGmo2foyRpjtfgLs+h+st33a21LsUA461Bjt9W8VLuZnDHvb7hSnU1ARTI 5ykRuvpj+W3krr7Wf9J+FEGKRe4XQMLYgDL74X/3TEcYtlvHBSbZDl+EBo0Q7Qq2Twvh QwLg== MIME-Version: 1.0 X-Received: by 10.152.37.67 with SMTP id w3mr32834960laj.123.1433346239257; Wed, 03 Jun 2015 08:43:59 -0700 (PDT) Received: by 10.112.137.99 with HTTP; Wed, 3 Jun 2015 08:43:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Jun 2015 17:43:59 +0200 Message-ID: From: Melvin Carvalho To: Nick Matavka Content-Type: multipart/alternative; boundary=089e0158ba0a6e626705179eed8d Archived-At: Cc: Apps Discuss Subject: Re: [apps-discuss] apps-discuss Digest, Vol 88, Issue 23 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jun 2015 15:44:03 -0000 --089e0158ba0a6e626705179eed8d Content-Type: text/plain; charset=UTF-8 On 1 June 2015 at 02:16, Nick Matavka wrote: > Julian Reschke wrote: > > Nick, this WG discusses whether work on Gopher fits here. Rants like > > these are not helpful at all, and likely will affect the outcome. > > > FWIW, I fully agree with Larry. > > > Best regards, Julian > > I didn't mean to be ranty, Julian. I meant to raise a point, that's all, > and I still haven't received an answer. > > *Who* decides what a "high-value project" is? I think it's an important > question. If it's group "consensus", how is "consensus" defined? Does > consensus mean EVERYONE agrees (unanimous), or simply the prevailing wind > of opinion? Larry makes good points, I agree, but his tone of voice is > infuriating sometimes. What is the definition of a high-value project, > anyway? To whom should the project be highly valuable? If the answer to > this is, "the Internet-using public," who judges what is valuable to the > public? > > Larry's right in being concerned about what I would call the > signal-to-noise ratio of this mailing list. The fact is that there is the > possibility and, in fact, the reality of irrelevant, insulting, and/or > uninformed feedback. Some people just can't be professional about it; I'm > not talking about Larry or myself, because I know we're decent people who > just can't seem to disagree civilly, but the fact is that there are people > with a consistent history of making unconstructive feedback either out of > ignorance or because it amuses them. > > And if I were him, I would raise another reservation; not a pure > objection, because I wouldn't object to my own project, but I would ask if > the author is able and willing to work within the IETF framework. I would > ask if the author or authors are willing to listen to, and heed, > technically reasonable input and to have drafts updated within a reasonable > turnaround time. I would also think about whether the author responds in > an adult way to feedback, either positive or negative. > > I have no objection to Masinter's opinions, but rather his wording. In > fact, I agree with the questions he raises, but he should define his words > more carefully because what he writes might be mistaken for > belligerence---this is why I replied to his comments in an equally > belligerent tone, but with reasoned argument. > I learnt a lot reading this document on consensus: https://tools.ietf.org/html/rfc7282 I also think it's important for any organization to take note of constructive criticism on this topic. It seems inevitable over time that standards bodies become more dogmatic and orthodox. It would be naive to think the IETF is immune from this. To paraphrase Joseph Campbell, "Orthodoxy is the death of an institution, and heresy is its life blood". > > Fraternal regards, > > Ed Matavka > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --089e0158ba0a6e626705179eed8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 1 June 2015 at 02:16, Nick Matavka <n.theodore.mat= avka.files@gmail.com> wrote:
Julian Reschke wrote:
> Nick, t= his WG discusses whether work on Gopher fits here. Rants like
> these= are not helpful at all, and likely will affect the outcome.

> FW= IW, I fully agree with Larry.

> Best regards, Julian

=
I didn't mean to be ranty, Julian.=C2=A0 I meant to raise a = point, that's all, and I still haven't received an answer.

=
*Who* decides what a "high-value project" is?=C2=A0 I = think it's an important question.=C2=A0 If it's group "consens= us", how is "consensus" defined?=C2=A0 Does consensus mean E= VERYONE agrees (unanimous), or simply the prevailing wind of opinion?=C2=A0= Larry makes good points, I agree, but his tone of voice is infuriating som= etimes.=C2=A0 What is the definition of a high-value project, anyway?=C2=A0= To whom should the project be highly valuable?=C2=A0 If the answer to this= is, "the Internet-using public," who judges what is valuable to = the public?

Larry's right in being concerned a= bout what I would call the signal-to-noise ratio of this mailing list.=C2= =A0 The fact is that there is the possibility and, in fact, the reality of= =C2=A0irrelevant, insulting, and/or uninfo= rmed feedback.=C2=A0 Some people just can't be professional about it; I= 'm not talking about Larry or myself, because I know we're decent p= eople who just can't seem to disagree civilly, but the fact is that the= re are people with a consistent history of making unconstructive feedback e= ither out of ignorance or because it amuses them.

And if I were him, I would raise another reservation; not a pure objec= tion, because I wouldn't object to my own project, but I would ask if t= he author is able and willing to work within the IETF framework.=C2=A0 I wo= uld ask if the author or authors are willing to listen to, and heed, techni= cally reasonable input and to have drafts updated within a reasonable turna= round time.=C2=A0 I would also think about whether the author responds in a= n adult way to feedback, either positive or negative.

I have no objection to Masinter's opinions, but rather h= is wording.=C2=A0 In fact, I agree with the questions he raises, but he sho= uld define his words more carefully because what he writes might be mistake= n for belligerence---this is why I replied to his comments in an equally be= lligerent tone, but with reasoned argument.
=

I learnt a lot reading this document on consensus:
<= br>https://tools.ietf.org/h= tml/rfc7282

I also think it's important for any o= rganization to take note of constructive criticism on this topic.=C2=A0 It = seems inevitable over time that standards bodies become more dogmatic and o= rthodox.=C2=A0 It would be naive to think the IETF is immune from this.=C2= =A0 To paraphrase Joseph Campbell, "Orthodoxy is the death of an insti= tution, and heresy is its life blood".
=C2=A0

Fraternal regards,
<= br>
Ed Matavka

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


--089e0158ba0a6e626705179eed8d-- From nobody Wed Jun 3 11:03:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B8C1ACE8B for ; Wed, 3 Jun 2015 11:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mI-rYNVGxMOc for ; Wed, 3 Jun 2015 11:03:22 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 452481A8F4A for ; Wed, 3 Jun 2015 11:03:22 -0700 (PDT) Received: by igbyr2 with SMTP id yr2so119522505igb.0 for ; Wed, 03 Jun 2015 11:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Evas1LOU/UwioFOlvhl7IP9V++L1t6YO0Zv/lywzCJk=; b=j9uOsdnd4sg0AZgUpD6iP5wR11Q6IazjaCfSHbLAMP3gxLRx7LpMzB+cvZks46xCB3 N1m1qs3YDOQ4Bdn82z40l3ta9BmbSJBtqN7o8e0B17Dx2uQEae4PuaYhMrn6bj3IQtwT yRamUIym4FkfHsf3mgP8COnvkRagn6nzre39Snhq1cNQeAVWI+VJsNjso7Npa/MOYe5N ngns+y+ccOchvYmWe3oihNvfuvxrhSkHgm6KNjAi40/DPWfgr++zVeoVGry5nd2sqroM 8Ry1wCeBbii+vohGZ5wfz15avstZTcfPlSiuRmBVz8L4Xgbdw7+jchz419wnHt1M5LFD p7Cg== MIME-Version: 1.0 X-Received: by 10.50.79.166 with SMTP id k6mr28785969igx.25.1433354601779; Wed, 03 Jun 2015 11:03:21 -0700 (PDT) Received: by 10.107.14.77 with HTTP; Wed, 3 Jun 2015 11:03:21 -0700 (PDT) Date: Wed, 3 Jun 2015 20:03:21 +0200 Message-ID: From: Nick Matavka To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=089e013a114ee05a040517a0df08 Archived-At: Subject: [apps-discuss] new gopher i-d X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jun 2015 18:03:23 -0000 --089e013a114ee05a040517a0df08 Content-Type: text/plain; charset=UTF-8 Just to let everyone know, I uploaded a new Gopher draft. This one is in standard format, so that people's eyes can have a rest. Otherwise, this one carries barely any change from the original. The next version will be vastly overhauled. --089e013a114ee05a040517a0df08 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just to let everyone know, = I uploaded a new Gopher draft.=C2=A0 This one is in standard format, so tha= t people's eyes can have a rest.
Otherwise, this one carries barely a= ny change from the original.=C2=A0 The next version will be vastly overhaul= ed.
--089e013a114ee05a040517a0df08-- From nobody Wed Jun 3 13:47:36 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66C81A910F for ; Wed, 3 Jun 2015 13:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-iVRtDiY7DI for ; Wed, 3 Jun 2015 13:47:33 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A741E1B29CF for ; Wed, 3 Jun 2015 13:47:32 -0700 (PDT) Received: (qmail 13135 invoked from network); 3 Jun 2015 20:47:39 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 3 Jun 2015 20:47:39 -0000 Date: 3 Jun 2015 20:47:09 -0000 Message-ID: <20150603204709.40635.qmail@ary.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: 8bit Archived-At: Cc: n.theodore.matavka.files@gmail.com Subject: Re: [apps-discuss] new gopher i-d X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jun 2015 20:47:35 -0000 >Just to let everyone know, I uploaded a new Gopher draft. This one is in >standard format, so that people's eyes can have a rest. It would be helpful if you told us what the draft name is so we can find it. R's, John From nobody Wed Jun 3 13:51:20 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9931B2B54 for ; Wed, 3 Jun 2015 13:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMDmDDDWgiIY for ; Wed, 3 Jun 2015 13:51:17 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E46891B2B52 for ; Wed, 3 Jun 2015 13:51:16 -0700 (PDT) Received: by wgme6 with SMTP id e6so18940332wgm.2 for ; Wed, 03 Jun 2015 13:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1bczo/bWw6GacBPPEPvB4P9nzmJEzyDXMNJLABW8czE=; b=JPAXKZM1J4IUbfHdFz8rqsZJiISMKMRFe58v7nIx+mnHNWSoRezLH1AdubqAAvblRF 2WUKeu5cClze9nP219Aq+VhEZgbiZaavTDFfPIERuTnDIYOz4718E9xk1mHtyihxvJpp Tdt6OJSoI7puD/6lBIKNq2aItiopsLFICjxoPGW8y0KVadwR14XbDgqg66IvhUEhAQwC r6xrF+cTN6wrsMbPQgPDNpBQkVW5W3R7YP5sVuMckk6BGAg6K5/0YphlGx28/stX6fKZ HQe5cWqY9efHRLRCMLGxCMWrOhzIk7U2IKdNv12cEOHMu3H6j5SpOIipsGRGw2ErZ0Zl W4Sw== X-Received: by 10.180.37.200 with SMTP id a8mr46075495wik.11.1433364675623; Wed, 03 Jun 2015 13:51:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.53.205 with HTTP; Wed, 3 Jun 2015 13:50:55 -0700 (PDT) In-Reply-To: <20150603204709.40635.qmail@ary.lan> References: <20150603204709.40635.qmail@ary.lan> From: Ira McDonald Date: Wed, 3 Jun 2015 16:50:55 -0400 Message-ID: To: John Levine , Ira McDonald Content-Type: multipart/alternative; boundary=e89a8f50291c52ffbd0517a33821 Archived-At: Cc: n.theodore.matavka.files@gmail.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] new gopher i-d X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jun 2015 20:51:19 -0000 --e89a8f50291c52ffbd0517a33821 Content-Type: text/plain; charset=UTF-8 Hi, https://datatracker.ietf.org/doc/draft-matavka-gopher-ii/ Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Wed, Jun 3, 2015 at 4:47 PM, John Levine wrote: > >Just to let everyone know, I uploaded a new Gopher draft. This one is in > >standard format, so that people's eyes can have a rest. > > It would be helpful if you told us what the draft name is so we can find > it. > > R's, > John > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --e89a8f50291c52ffbd0517a33821 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

https://datatracker.ietf.org/doc/draft-matavka-gopher-ii/

= Cheers,
- Ira

<= div dir=3D"ltr">Ira McDonald (Musician / Software Architect)
Co-Chair - = TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing= WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO = PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Pri= nter MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com=
Winter=C2=A0 579 Park Place=C2=A0 Saline, MI=C2=A0 48176=C2=A0 734-944-= 0094
Summer=C2=A0 PO Box 221=C2=A0 Grand Marais, MI 49839=C2=A0 906-494-= 2434


On Wed, Jun 3, 2015 at 4:47 PM, John Levine = <= johnl@taugh.com> wrote:
>Just to let everyone know, I uploaded a new Gopher draft.= =C2=A0 This one is in
>standard format, so that people's eyes can have a rest.

It would be helpful if you told us what the draft name is so we can = find it.

R's,
John

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

--e89a8f50291c52ffbd0517a33821-- From nobody Wed Jun 3 17:47:59 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1891A1B30AD; Wed, 3 Jun 2015 17:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pi4pYxKui-da; Wed, 3 Jun 2015 17:47:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EB21B30EF; Wed, 3 Jun 2015 17:47:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150604004754.8406.37107.idtracker@ietfa.amsl.com> Date: Wed, 03 Jun 2015 17:47:54 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-10.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 00:47:58 -0000 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 : Message Header Field for Indicating Message Authentication Status Author : Murray S. Kucherawy Filename : draft-ietf-appsawg-rfc7001bis-10.txt Pages : 51 Date : 2015-06-03 Abstract: This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc7001bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-rfc7001bis-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-rfc7001bis-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 4 06:27:52 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9941B33BB for ; Thu, 4 Jun 2015 06:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fpi4kwjWsWVq for ; Thu, 4 Jun 2015 06:27:47 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40E751A872B for ; Thu, 4 Jun 2015 06:24:59 -0700 (PDT) Received: by wifw1 with SMTP id w1so58517459wif.0 for ; Thu, 04 Jun 2015 06:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Pn5VBqX/YdZEyR0XVDFTzF6lU11VUnwoRapLQBa0NlY=; b=xYCtm5Xo686Fho5kh0hul02wK6Gog4U1HT6p65y01WfwjlLXwoUG+x17fX7CnZSPnB ZdR0B3ZAB/p/fpOAyMzlQbz0FCeJ4qLRw3afi+vB1JaLkAeD8pj7L1T4Faa1x/AkH3GP 1qiv245YnqGd2EgXQpiF1mTVXg8csuB/5may0P515YIgcuaBn9o5vkxQrZ3x5pmlfI8e jyZ3skJrnJwO0guz2dfGzHNAqo8shUB5SxMgLMzNaQDZL/n3fKZlMDqZ7LG5fDAI9zuk kfRcfRaiM4h63aLpNyouPFVRcus4RnPeL5NQnng3XTs60upp8rvyp1fGvdcImrJ1pw+y cUug== MIME-Version: 1.0 X-Received: by 10.194.61.50 with SMTP id m18mr72061642wjr.135.1433424297912; Thu, 04 Jun 2015 06:24:57 -0700 (PDT) Received: by 10.27.6.207 with HTTP; Thu, 4 Jun 2015 06:24:57 -0700 (PDT) In-Reply-To: <20150528071826.3803.44025.idtracker@ietfa.amsl.com> References: <20150528071826.3803.44025.idtracker@ietfa.amsl.com> Date: Thu, 4 Jun 2015 06:24:57 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7b66f8e716ef160517b11a2f Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 13:27:50 -0000 --047d7b66f8e716ef160517b11a2f Content-Type: text/plain; charset=UTF-8 On Thu, May 28, 2015 at 12:18 AM, 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 file URI Scheme > Author : Matthew Kerwin > Filename : draft-ietf-appsawg-file-scheme-02.txt > Pages : 19 > Date : 2015-05-28 > > Abstract: > This document specifies the "file" Uniform Resource Identifier (URI) > scheme, obsoleting the definition in RFC 1738. > > It attemps to define a common core which is intended to interoperate > across the broad spectrum of existing implementations, while at the > same time documenting other current practices. > Colleagues, There have been no comments posted on this version of the draft. The previous version appeared to address Tom Petch's earlier concerns. Have any others looked at this one? Does it need more work or are we ready to go to WGLC here? Dave Crocker has offered to act as document shepherd. -MSK, APPSAWG co-chair --047d7b66f8e716ef160517b11a2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, May 28, 2015 at 12:18 AM, <<= a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">internet-draft= s@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Applications Area Working Group Work= ing Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= The file URI Scheme
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Matt= hew Kerwin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-appsawg-file-scheme-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 19
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-05-28

Abstract:
=C2=A0 =C2=A0This document specifies the "file" Uniform Resource = Identifier (URI)
=C2=A0 =C2=A0scheme, obsoleting the definition in RFC 1738.

=C2=A0 =C2=A0It attemps to define a common core which is intended to intero= perate
=C2=A0 =C2=A0across the broad spectrum of existing implementations, while a= t the
=C2=A0 =C2=A0same time documenting other current practices.

Colleagues,

There have been no comme= nts posted on this version of the draft.=C2=A0 The previous version appeare= d to address Tom Petch's earlier concerns.=C2=A0 Have any others looked= at this one?=C2=A0 Does it need more work or are we ready to go to WGLC he= re?

Dave Crocker has offered to act as document shepherd.=

-MSK, APPSAWG co-chair
--047d7b66f8e716ef160517b11a2f-- From nobody Thu Jun 4 09:26:28 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1481A909A for ; Thu, 4 Jun 2015 09:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z50RCpH7c6U6 for ; Thu, 4 Jun 2015 09:26:24 -0700 (PDT) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 59DD11A90A0 for ; Thu, 4 Jun 2015 09:25:59 -0700 (PDT) Received: from smtp5.mail.ox.ac.uk ([163.1.2.207]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Z0Xxt-0007iq-is for apps-discuss@ietf.org; Thu, 04 Jun 2015 17:25:57 +0100 Received: from [213.205.194.83] (helo=conina.local) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Z0Xxt-0000Dw-ID for apps-discuss@ietf.org; Thu, 04 Jun 2015 17:25:57 +0100 Message-ID: <55707C14.5010507@ninebynine.org> Date: Thu, 04 Jun 2015 17:25:56 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20150528071826.3803.44025.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 16:26:26 -0000 Apologies for responding late in the day. I had intended to review this but it fell out of sight. I am duly reminded and offer some comments below. ... Section 1 vs Section 3 appear to be in conflict: (sect 1): "... there is no well-defined set of operations that can be performed on file URIs..." and (sect 3): "Implementations SHOULD, at a minimum, provide a read-like operation to return the contents of a file located by a file URI." I expect the intent was to say different things, but I find the result is confusing. Suggest drop the confusing bit in section 1, para 2, hence: [[ The file URI scheme is not coupled with a specific protocol, nor with a specific media type. See section 3 for a discussion of operations that can be performed. ]] ... Section 3.2: [[ A file URI can only be translated to a local file path if it has a blank or no authority. Note that this differs from the previous specification in [RFC1738], in that previously an authority of "localhost" was used to refer to the local file system, but in this specification it equates to a UNC string with the host "localhost". ]] I'm uneasy with this non-backwards-compatible change of specification. In the past, I have actually used the "localhost" convention, so that software would be rendered incorrect by this revised spec. Further, I'm not sure what it means to say "it equates to a UNC string with the host "localhost"", expecially on systems that don't use UNC strings. (The reference given for UNC strings, [MS-DTYP], is only informative so I guess that means this whole section is non-normative? Also, this incorporation of UNC string processing appears to be at odds with "This specification neither defines nor forbids a mechanism for accessing non-local files. See SMB [MS-SMB], NFS [RFC3530], NCP [NOVELL] for examples of protocols that can be used to access files over a network." (which I think is fine). ... Section 4: "When the file system's encoding is not known the file URI SHOULD be transported as an Internationalized Resource Identifier (IRI) [RFC3987] to avoid ambiguity." I'm not seeing how this helps. (1) are we talking about the source system or destination system file system encoding being unknown? I'll assume the source. (2) If the file system name encoding is unknown, how is one to achieve a mapping to IRIs, which are defined to be a sequence of characters? (In practice, I have found the main utility of file: URIs has not been for transportation of complete URIs between systems, but providing a mechanism for resolving relative references to the local file system, whatever that may be. In such a scenario, the base file: URI is determined locally and used to generate a full URI from a supplied URI reference, which can in turn be used to access the local file system. Here it is the relative references that are transported. Encoding considerations still apply, but I don't see that there's any reliable way to make this work if the encoding of source file names is not known. My approach has been to %-encode anything that is provided by the file system that is not a known valid URI (as opposed to IRI) character. How this is interpreted at the target system is somewhat dependent on the nature of the system and application concerned.) I'm not claiming my approach solves the compatibility/ambiguity problem, but I also don't think that just saying "send IRIs" does either. I think we have to acknowledge that there may be problems when transferring filenames whose original encoding is unknown. ... That's all for now. #g -- On 04/06/2015 14:24, Murray S. Kucherawy wrote: > On Thu, May 28, 2015 at 12:18 AM, 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 file URI Scheme >> Author : Matthew Kerwin >> Filename : draft-ietf-appsawg-file-scheme-02.txt >> Pages : 19 >> Date : 2015-05-28 >> >> Abstract: >> This document specifies the "file" Uniform Resource Identifier (URI) >> scheme, obsoleting the definition in RFC 1738. >> >> It attemps to define a common core which is intended to interoperate >> across the broad spectrum of existing implementations, while at the >> same time documenting other current practices. >> > > Colleagues, > > There have been no comments posted on this version of the draft. The > previous version appeared to address Tom Petch's earlier concerns. Have > any others looked at this one? Does it need more work or are we ready to > go to WGLC here? > > Dave Crocker has offered to act as document shepherd. > > -MSK, APPSAWG co-chair > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Thu Jun 4 13:32:46 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F42391A916A for ; Thu, 4 Jun 2015 13:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2_Z6DRetD2Z for ; Thu, 4 Jun 2015 13:32:43 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id DF7EF1A9166 for ; Thu, 4 Jun 2015 13:32:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D91E12CEE9 for ; Thu, 4 Jun 2015 23:32:40 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwIaNXJN9brq for ; Thu, 4 Jun 2015 23:32:40 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 44F622CEE5 for ; Thu, 4 Jun 2015 23:32:40 +0300 (EEST) (envelope-from jari.arkko@piuha.net) From: Jari Arkko Content-Type: multipart/signed; boundary="Apple-Mail=_4468E3DF-FB96-42F6-927A-827121212283"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: Date: Thu, 4 Jun 2015 23:32:39 +0300 To: apps-discuss@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [apps-discuss] discussion style and respect: please cool down X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 20:32:46 -0000 --Apple-Mail=_4468E3DF-FB96-42F6-927A-827121212283 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All, I have been watching the Gopher threads here for a while, as well as participating in other heated discussions in other working groups. Please remember to cool down if discussions get heated. Take a pause = before using unnecessarily polarised words or emotional content, condescending or combative discussion style, or dismissive of other people=92s points = of view. The IETF code of conduct (RFC 7154) says:=20 The IETF strives =85 to create and maintain an environment in which = every=20 person is treated with dignity, decency, and respect. People who = participate in the IETF are expected to behave in a professional manner as we = work together to develop interoperable technologies for the Internet. This applies to all of us. And we all can fail occasionally, but we need = to learn from our mistakes. Maybe all of us can take a moment and review our recent discussions and see what we could do to improve going forward. There are many obvious reasons why we need to stay professional and respectful in our discussions. We are an open organisation that should be welcoming, open for new ideas and different viewpoints. We have a lot of respected technologists and as such we need to set an example not only for our technical excellence but our ability to discuss and accommodate broad views. We also get many new proposals and new people. Please keep an open mind to find out what really is being suggested. And if you have a proposal that other people are not interested in, please do not take that as anything more than it is, i.e., people having different interests. There is also the matter of efficiency: occasionally we see discussions that deviate from the core topic, such as discussions that devolve into a discussion of the discussion itself. This isn=92t helping us get to a reasonable conclusion. And a good discussion environment attracts us to participate; negative environment pushes us away. Of course, it is absolutely essential that we all are able to criticise proposals = and express concerns. Neutral tone works usually best: I prefer A over B because =85 =94 or "I believe there is a concern in C because =85=94 At any one time there are hundreds of questions in front of the IETF. When we are polite, respectful, informative, and help each other understand, we can get to conclusions faster. And more importantly, to the right conclusions. I recommend following the usual process for adopting new work. Once you have developed a reasonable understanding of the work and gauged the level of interest in the community, it is much easier to make a decision. I know the chairs are doing it in this case. Lets go through that, but with less heat. Note that when looking at community interest, not everyone is interested in everything, but you need at least a core group of developers and some interest from others. Thanks, Jari Arkko, IETF Chair --Apple-Mail=_4468E3DF-FB96-42F6-927A-827121212283 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVcLXoAAoJEM80gCTQU46qkZUQAK1G95rdUH1leQodzGfjeiB0 yCakN2KUDpWFbDwBW0tv6bx5rZEY51fLvLdG9mkOJsIVx1TP8TwiKf0noXJvk7Ai T4+Leenf8pRzZ+maHLZQwg68XG4EbwHDAyT7P0vT1on7O+kYADBs6HiZWZrsh6nQ y22Y986NmnH8ybxoQ+1KOiCWqbc7inMBa0KUH+7mID+M7N0SUh2y+bzdYAldvFlM HkBDRiBHx8y1fS/ovxxJ8VVrP3egwfF8ytjVzAGGtesjKmTh0bZOovxTdpfF/T4M pe72qcALjEUwqe1p7pyb77Vlx2BSYe6Vrxl5J06xoydd6gWIeg4QSOcxCOBR7K40 FO3Vi33p5Uzlj7bjjgs1wlq0S8tBfRS/rVe4gMvJh71fgdI9kiBmIIRro3YAKJ4I xcJZljBca4Xb21OkAPdymKdSW6leCn7fXAWc2mIb4eaMu7WS1YuNQ37pHOO2G8nv C91igypaTLFzMICYtdTmQtecPaPYD2ZezzVKhD6MXUtbjv7h5zsPLRKvA3vC779N ykzelXe3yWd7PacFbxDzQ1VWRgT/giLOWY5H6l4roFJSqYYjZE4LvTKmlkRaGmJp Or9k2Qd42MAICp+FUelIyLeBHWPYiE28i6CTWedZzx1xjEGKpsN35aI6ptzbsDSk v4DaOQS3gPF4K6Rc+uEk =TZfT -----END PGP SIGNATURE----- --Apple-Mail=_4468E3DF-FB96-42F6-927A-827121212283-- From nobody Thu Jun 4 17:20:35 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F6F1ACDBD for ; Thu, 4 Jun 2015 17:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpRc8KXvQOfT for ; Thu, 4 Jun 2015 17:20:31 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2951A1ACDBC for ; Thu, 4 Jun 2015 17:20:31 -0700 (PDT) Received: by obbqz1 with SMTP id qz1so25840093obb.3 for ; Thu, 04 Jun 2015 17:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rQDOHKRjCHrr2fBjo0qU8KlQScSGF8+/XvHV3gKzUOg=; b=vN+J0bRpDLO6NkG7bmDmGAJRiCkXps+dlZa7RNNLzRo0WyUYZApcsdWlRgcM3Sy4c6 Lk9jlGjILrPbXoY/axY/KumFCEy7wULobU1yy6Ct3tLbn/c5GfSLtfa8mmY489lv6Ysv JGsfIyp5Mc+XG/T5IIOeyzfpHAOwSacW7j0lW7KyxLb7wQ7Q9WuadqOW4yn/ag1W4mfe ZR7mC9EEctANGv69+TRVhxpPxqhRUO9pdpZSDsq2Bk24eGTcW4lqu1+sGK0ZVWFBRNT4 66aTPL1SoCOWzCcuJrlRQ4xgiGPlv07+6mCKXi9se5oKSf2VK2gG3bE8Anb8Ola1Z0ZD 1OZw== MIME-Version: 1.0 X-Received: by 10.182.128.6 with SMTP id nk6mr559889obb.70.1433463630639; Thu, 04 Jun 2015 17:20:30 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.202.226.205 with HTTP; Thu, 4 Jun 2015 17:20:30 -0700 (PDT) In-Reply-To: <55707C14.5010507@ninebynine.org> References: <20150528071826.3803.44025.idtracker@ietfa.amsl.com> <55707C14.5010507@ninebynine.org> Date: Fri, 5 Jun 2015 10:20:30 +1000 X-Google-Sender-Auth: Dz5q2jpSMetJHZo5NAKfQX3eEaQ Message-ID: From: Matthew Kerwin To: Graham Klyne Content-Type: multipart/alternative; boundary=047d7b675af680b9d60517ba4279 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 00:20:34 -0000 --047d7b675af680b9d60517ba4279 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the review Graham (and thanks for the reminder Murray, I'd forgotten to post a follow-up.) On 5 June 2015 at 02:25, Graham Klyne wrote: > Apologies for responding late in the day. I had intended to review this > but it fell out of sight. I am duly reminded and offer some comments bel= ow. > > ... > > Section 1 vs Section 3 appear to be in conflict: > > (sect 1): "... there is no well-defined set of operations that can be > performed on file URIs..." > > and > > (sect 3): "Implementations SHOULD, at a minimum, provide a read-like > operation to return the contents of a file located by a file URI." > > I expect the intent was to say different things, but I find the result is > confusing. Suggest drop the confusing bit in section 1, para 2, hence: > > [[ > The file URI scheme is not coupled with a specific protocol, nor with a > specific media type. See section 3 for a discussion of operations that c= an > be performed. > ]] > > =E2=80=8BYes, I think that's the right thing to do. Partly the text is stil= l in two minds about the original "the only operation is translation to/from a file path" and the new "file URIs are CRUDable." My personal problem is with the phrase "well-defined"... I don't know if "a read-like operation..." counts as well-defined or not. Irrespective, I'll try to write something more accurate in section 1. > ... > > Section 3.2: > > [[ > A file URI can only be translated to a local file path if it has a > blank or no authority. Note that this differs from the previous > specification in [RFC1738], in that previously an authority of > "localhost" was used to refer to the local file system, but in this > specification it equates to a UNC string with the host "localhost". > ]] > > I'm uneasy with this non-backwards-compatible change of specification. I= n > the past, I have actually used the "localhost" convention, so that softwa= re > would be rendered incorrect by this revised spec. > > =E2=80=8BThis point swayed back and forth several times in the earliest rev= isions. It eventually settled on the current version because most of the implementations I'd seen acted that way anyway. Which software supported the originally-specced localhost, if I may ask?=E2=80=8B > Further, I'm not sure what it means to say "it equates to a UNC string > with the host "localhost"", expecially on systems that don't use UNC > strings. (The reference given for UNC strings, [MS-DTYP], is only > informative so I guess that means this whole section is non-normative? > > There are two points here which I'd be happy to have cleared up: 1. editorial: I need a better way to phrase this paragraph (in both its occurrences.) If someone can suggest some text I'd be most obliged. 2. substantive: I'm thinking I should move all mention of UNC (apart from S1.2) to the optional appendices. Is that cool with everybody? It gives the above point a lower priority, too. > Also, this incorporation of UNC string processing appears to be at odds > with "This specification neither defines nor forbids a mechanism for > accessing non-local files. See SMB [MS-SMB], NFS [RFC3530], NCP [NOVELL] > for examples of protocols that can be used to access files over a network= ." > (which I think is fine). > > =E2=80=8BAs I read it (which might be wrong) parsing or translating UNC str= ings doesn't necessarily mean accessing network shares.=E2=80=8B However I think= that moving UNC to an optional appendix reaffirms the written assertion ("...neither defines nor forbids..."), rather than confusing it (as the current text does.) > ... > > Section 4: > > "When the file system's encoding is not known the file URI SHOULD be > transported as an Internationalized Resource Identifier (IRI) [RFC3987] t= o > avoid ambiguity." > > I'm not seeing how this helps. > > (1) are we talking about the source system or destination system file > system encoding being unknown? I'll assume the source. > > =E2=80=8BYes, the source. The issue arises at the time of interpreting the = URI, and we assume the parser/interpreter and the destination file system share knowledge about things like encodings -- so that encoding is known. > (2) If the file system name encoding is unknown, how is one to achieve a > mapping to IRIs, which are defined to be a sequence of characters? > > =E2=80=8BWhen I encode, I can (presumably) map my local encoding to Unicode= , and thus create an unambiguous IRI. This is (local)character -> (unicode)codepoint, without needing a %-encoded intermediate. When I decode, I can (presumably) map Unicode to my local encoding. Again, this is (unicode)codepoint -> (local)character, without a %-encoded interiedmate. There might be codepoints in the IRI that can't be mapped to my local encoding, in which case there's a problem - but it's a known problem. That's no different, really, from including bad %XX sequences in a URI. As the example in Appendix D says, if I'm an NTFS system (for example) and the URI is "file:///%E3%81%A1" and I don't know anything about who encoded it, I don't know if that's a single UTF-8 character, or three CP437 characters, or three EBCDIC characters, any of which could have been a valid filename at the source. The IRIs "file://=E3=81=A1", "file://=CF=80= =C3=BC=C3=AD" and "file://Ta~" are mostly unambiguous. > (In practice, I have found the main utility of file: URIs has not been fo= r > transportation of complete URIs between systems, but providing a mechanis= m > for resolving relative references to the local file system, whatever that > may be. In such a scenario, the base file: URI is determined locally and > used to generate a full URI from a supplied URI reference, which can in > turn be used to access the local file system. Here it is the relative > references that are transported. Encoding considerations still apply, bu= t > I don't see that there's any reliable way to make this work if the encodi= ng > of source file names is not known. My approach has been to %-encode > anything that is provided by the file system that is not a known valid UR= I > (as opposed to IRI) character. How this is interpreted at the target > system is somewhat dependent on the nature of the system and application > concerned.) > > =E2=80=8BThe example is the same as above, bu=E2=80=8Bt without the "file:/= /" part. If, for argument's sake, you have two hypertext documents with "interesting" file names, that reference each other relatively, and you're going to copy them around between FAT, NTFS, HFS and Ext devices, how can you be sure those relative references can be properly resolved at any given time (on any given device)? > I'm not claiming my approach solves the compatibility/ambiguity problem, > but I also don't think that just saying "send IRIs" does either. I think > we have to acknowledge that there may be problems when transferring > filenames whose original encoding is unknown. > > =E2=80=8BOnly if you want to reconstruct the filename as it was on the sour= ce file system. But I can't think of a time we'd want to do that. > ... > > That's all for now. > > #g > -- > > =E2=80=8BThanks!=E2=80=8B --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --047d7b675af680b9d60517ba4279 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the review Graham (and thanks for the = reminder Murray, I'd forgotten to post a follow-up.)

On 5 June 2015 at 02:25, Graha= m Klyne <gk@ninebynine.org> wrote:
Apo= logies for responding late in the day.=C2=A0 I had intended to review this = but it fell out of sight.=C2=A0 I am duly reminded and offer some comments = below.

...

Section 1 vs Section 3 appear to be in conflict:

(sect 1): "... there is no well-defined set of operations that can be = performed on file URIs..."

and

(sect 3): "Implementations SHOULD, at a minimum, provide a read-like o= peration to return the contents of a file located by a file URI."

I expect the intent was to say different things, but I find the result is c= onfusing.=C2=A0 Suggest drop the confusing bit in section 1, para 2, hence:=

[[
The file URI scheme is not coupled with a specific protocol, nor with a spe= cific media type.=C2=A0 See section 3 for a discussion of operations that c= an be performed.
]]


=E2=80=8BYes, I think that= 9;s the right thing to do. Partly the text is still in two minds about the = original "the only operation is translation to/from a file path" = and the new "file URIs are CRUDable."

My personal problem is with the phrase "well-defined"... I = don't know if "a read-like operation..." counts as well-defin= ed or not. Irrespective, I'll try to write something more accurate in s= ection 1.

=C2=A0
...

Section 3.2:

[[
A file URI can only be translated to a local file path if it has a
=C2=A0 =C2=A0blank or no authority.=C2=A0 Note that this differs from the p= revious
=C2=A0 =C2=A0specification in [RFC1738], in that previously an authority of=
=C2=A0 =C2=A0"localhost" was used to refer to the local file syst= em, but in this
=C2=A0 =C2=A0specification it equates to a UNC string with the host "l= ocalhost".
]]

I'm uneasy with this non-backwards-compatible change of specification.= =C2=A0 In the past, I have actually used the "localhost" conventi= on, so that software would be rendered incorrect by this revised spec.


=E2=80=8BThis point swayed ba= ck and forth several times in the earliest revisions. It eventually settled= on the current version because most of the implementations I'd seen ac= ted that way anyway. Which software supported the originally-specced localh= ost, if I may ask?=E2=80=8B

=C2=A0
Further, I'm not sure what it means to say "it equates to a UNC st= ring with the host "localhost"", expecially on systems that = don't use UNC strings.=C2=A0 (The reference given for UNC strings, [MS-= DTYP], is only informative so I guess that means this whole section is non-= normative?


There are two points here whi= ch I'd be happy to have cleared up:

1= . editorial: I need a better way to phrase this paragraph (in both its occu= rrences.) If someone can suggest some text I'd be most obliged.

2. substantive: I'm thinking I should move al= l mention of UNC (apart from S1.2) to the optional appendices. Is that cool= with everybody? It gives the above point a lower priority, too.
<= br>
=C2=A0
Also, this incorporation of UNC string processing appears to be at odds wit= h "This specification neither defines nor forbids a mechanism for acce= ssing non-local files.=C2=A0 See SMB [MS-SMB], NFS [RFC3530], NCP [NOVELL] = for examples of protocols that can be used to access files over a network.&= quot; (which I think is fine).


=E2=80=8BAs I read it (which = might be wrong) parsing or translating UNC strings doesn't necessarily = mean accessing network shares.=E2=80=8B However I think that moving UNC to = an optional appendix reaffirms the written assertion ("...neither defi= nes nor forbids..."), rather than confusing it (as the current text do= es.)

=C2=A0
...

Section 4:

"When the file system's encoding is not known the file URI SHOULD = be transported as an Internationalized Resource Identifier (IRI) [RFC3987] = to avoid ambiguity."

I'm not seeing how this helps.

(1) are we talking about the source system or destination system file syste= m encoding being unknown?=C2=A0 I'll assume the source.


=E2=80=8BYes, the source. The= issue arises at the time of interpreting the URI, and we assume the parser= /interpreter and the destination file system share knowledge about things l= ike encodings -- so that encoding is known.

=C2=A0
(2) If the file system name encoding is unknown, how is one to achieve a ma= pping to IRIs, which are defined to be a sequence of characters?


=E2=80=8BWhen I encode, I can= (presumably) map my local encoding to Unicode, and thus create an unambigu= ous IRI. This is (local)character -> (unicode)codepoint, without needing= a %-encoded intermediate.

When I decode, I can (presumably) map Unicode to my local encoding. Again,= this is (unicode)codepoint -> (local)character, without a %-encoded int= eriedmate. There might be codepoints in the IRI that can't be mapped to= my local encoding, in which case there's a problem - but it's a kn= own problem. That's no different, really, from including bad %XX sequen= ces in a URI.

As the example in Appendix D says, if I'm an NTFS sys= tem (for example) and the URI is "file:///%E3%81%A1"= and I don't know anything about who encoded it, I don't know if th= at's a single UTF-8 character, or three CP437 characters, or three EBCD= IC characters, any of which could have been a valid filename at the source.= The IRIs "file://= =E3=81=A1", "file://=CF=80=C3=BC=C3=AD"<= font face=3D"georgia, serif"> and "file://Ta~" are m= ostly unambiguous.

=C2=A0
(In practice, I have found the main utility of file: URIs has not been for = transportation of complete URIs between systems, but providing a mechanism = for resolving relative references to the local file system, whatever that m= ay be. In such a scenario, the base file: URI is determined locally and use= d to generate a full URI from a supplied URI reference, which can in turn b= e used to access the local file system.=C2=A0 Here it is the relative refer= ences that are transported.=C2=A0 Encoding considerations still apply, but = I don't see that there's any reliable way to make this work if the = encoding of source file names is not known.=C2=A0 My approach has been to %= -encode anything that is provided by the file system that is not a known va= lid URI (as opposed to IRI) character.=C2=A0 How this is interpreted at the= target system is somewhat dependent on the nature of the system and applic= ation concerned.)


=E2=80=8BThe example is the s= ame as above, bu=E2=80=8Bt without the "file://" part. If, for ar= gument's sake, you have two hypertext documents with "interesting&= quot; file names, that reference each other relatively, and you're goin= g to copy them around between FAT, NTFS, HFS and Ext devices, how can you b= e sure those relative references can be properly resolved at any given time= (on any given device)?

=C2=A0
I'm not claiming my approach solves the compatibility/ambiguity problem= , but I also don't think that just saying "send IRIs" does ei= ther.=C2=A0 I think we have to acknowledge that there may be problems when = transferring filenames whose original encoding is unknown.


=E2=80=8BOnly if you want to = reconstruct the filename as it was on the source file system. But I can'= ;t think of a time we'd want to do that.

=C2=A0
...

That's all for now.

#g
--


=E2=80=8BThanks!=E2=80=8B


--
= =C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--047d7b675af680b9d60517ba4279-- From nobody Thu Jun 4 20:29:07 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107691B2A2B for ; Thu, 4 Jun 2015 20:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UI3MLOUdjCSn for ; Thu, 4 Jun 2015 20:29:04 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A0C1B2A22 for ; Thu, 4 Jun 2015 20:29:04 -0700 (PDT) Received: by wiam3 with SMTP id m3so5514313wia.1 for ; Thu, 04 Jun 2015 20:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q6k0V+AjmhIgvZ6SMASqltSilFi2DV7TkuGCim4Fpc0=; b=HNLDKlTVnioCQS2LLvlyX75uO+EtLe4Wq7Gw7hQIEasj8stk+UibxQUcm/3O/uPf9n Ttvmf281/rjcLKYaVnoDoyvlSTjID+1Aaasg/krn3HI4fj7+EkkgZDhv9i2TEUHcMxGD SuUoYz7t+wGriURnppbZ2Nfea1Kx2fAr7Mml0kalhNaknQOO0+BkNupTzXC1pmUZyMbU fwr0qUZsiPlgdInrlmfwSpiGe0iKb89pQZUOyZqYgjIP3R2LLLblY38On61fHpRWp7v4 ppN4Zih/TyQWWq+nFmfCF1+/C3jfiyeob7a9Pc37WYmqYwOUWU20/cY8SbXQrEqtp+Zd nP4g== MIME-Version: 1.0 X-Received: by 10.194.61.50 with SMTP id m18mr2199943wjr.135.1433474943344; Thu, 04 Jun 2015 20:29:03 -0700 (PDT) Received: by 10.27.6.207 with HTTP; Thu, 4 Jun 2015 20:29:03 -0700 (PDT) In-Reply-To: References: Date: Thu, 4 Jun 2015 20:29:03 -0700 Message-ID: From: "Murray S. Kucherawy" To: Nick Matavka Content-Type: multipart/alternative; boundary=047d7b66f8e7cae3e10517bce42b Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] new gopher i-d X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 03:29:06 -0000 --047d7b66f8e7cae3e10517bce42b Content-Type: text/plain; charset=UTF-8 On Wed, Jun 3, 2015 at 11:03 AM, Nick Matavka < n.theodore.matavka.files@gmail.com> wrote: > Just to let everyone know, I uploaded a new Gopher draft. This one is in > standard format, so that people's eyes can have a rest. > > Otherwise, this one carries barely any change from the original. The next > version will be vastly overhauled. > While you're developing the overhaul, I'll remind people that the issue remains open for consideration for a little while longer about whether this work is appropriate for handling someplace in the IETF stream, or via the ISE. Those of you who have weighed in already need not do so again, but I'm interested in hearing from others. -MSK --047d7b66f8e7cae3e10517bce42b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 3, 2015 at 11:03 AM, Nick Matavka <n.theodore.matavka.files@gmail.com> wrote:
Just to let everyone know, I uploaded a new Gopher = draft.=C2=A0 This one is in standard format, so that people's eyes can = have a rest.

Otherwise, this one carries barely an= y change from the original.=C2=A0 The next version will be vastly overhaule= d.

While you're developing the over= haul, I'll remind people that the issue remains open for consideration = for a little while longer about whether this work is appropriate for handli= ng someplace in the IETF stream, or via the ISE.=C2=A0 Those of you who hav= e weighed in already need not do so again, but I'm interested in hearin= g from others.

-MSK
--047d7b66f8e7cae3e10517bce42b-- From nobody Thu Jun 4 21:40:15 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4925F1B2B4A; Thu, 4 Jun 2015 21:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeGbsg1lRqOC; Thu, 4 Jun 2015 21:40:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 346661B2B4C; Thu, 4 Jun 2015 21:40:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150605044012.6440.72425.idtracker@ietfa.amsl.com> Date: Thu, 04 Jun 2015 21:40:12 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 04:40:14 -0000 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 : Message Header Field for Indicating Message Authentication Status Author : Murray S. Kucherawy Filename : draft-ietf-appsawg-rfc7001bis-11.txt Pages : 51 Date : 2015-06-04 Abstract: This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc7001bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-rfc7001bis-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-rfc7001bis-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 4 21:41:30 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A891B2B51 for ; Thu, 4 Jun 2015 21:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPV_SQyQPnOL for ; Thu, 4 Jun 2015 21:41:27 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9527F1B2B50 for ; Thu, 4 Jun 2015 21:41:27 -0700 (PDT) Received: by wiwd19 with SMTP id d19so8629273wiw.0 for ; Thu, 04 Jun 2015 21:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=WEEy52AaOy+5cD4id2GuecI5WyK9LcQ/C+KnW/cZHng=; b=YTDxEuYm9EAD58pLP0qwQH84M2BiZJfBvO9juxNGLCV+IyRkaCZKbnpQu5/XIUdOwa liu+hezKoOhrJE0lN5GKtuDF8obBOPtrpTEbVzdvil5emwi0srOmYTAaT9WUenTWAbHa w/NWCVeSpm4CTY50VZ3hv5Zl6XzrgavxLYuqwpgzhc75ebMNdJtIWKWBtBobTIahQos1 VMAx4C51s0B5Fx9hq4SsrL4UivKCYaHZ2y6PeC81FaSeuCKggMx56uZppLLeZnr5kNS3 V1fz2JpeHqAByXZqtsbjxUgJInhKxKpSrMIbTCpauEkz1a8Rn3UuvzKV8Y1K3Thn/X6g ZlxQ== MIME-Version: 1.0 X-Received: by 10.180.84.170 with SMTP id a10mr14497326wiz.52.1433479286401; Thu, 04 Jun 2015 21:41:26 -0700 (PDT) Received: by 10.27.6.207 with HTTP; Thu, 4 Jun 2015 21:41:26 -0700 (PDT) In-Reply-To: <20150605044012.6440.72425.idtracker@ietfa.amsl.com> References: <20150605044012.6440.72425.idtracker@ietfa.amsl.com> Date: Thu, 4 Jun 2015 21:41:26 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d041827e6a8b0900517bde77c Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 04:41:29 -0000 --f46d041827e6a8b0900517bde77c Content-Type: text/plain; charset=UTF-8 On Thu, Jun 4, 2015 at 9:40 PM, 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 : Message Header Field for Indicating Message > Authentication Status > Author : Murray S. Kucherawy > Filename : draft-ietf-appsawg-rfc7001bis-11.txt > Pages : 51 > Date : 2015-06-04 > > Abstract: > This document specifies a message header field called Authentication- > Results for use with electronic mail messages to indicate the results > of message authentication efforts. Any receiver-side software, such > as mail filters or Mail User Agents (MUAs), can use this header field > to relay that information in a convenient and meaningful way to users > or to make sorting and filtering decisions. > These last two versions just tweak IANA language. Nothing of substance to the protocol, and apologies for the noise. -MSK --f46d041827e6a8b0900517bde77c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 4, 2015 at 9:40 PM, <internet-drafts@= ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Applications Area Working Group Work= ing Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Message Header Field for Indicating Message Authentication Status
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Murr= ay S. Kucherawy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-appsawg-rfc7001bis-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 51
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-06-04

Abstract:
=C2=A0 =C2=A0This document specifies a message header field called Authenti= cation-
=C2=A0 =C2=A0Results for use with electronic mail messages to indicate the = results
=C2=A0 =C2=A0of message authentication efforts.=C2=A0 Any receiver-side sof= tware, such
=C2=A0 =C2=A0as mail filters or Mail User Agents (MUAs), can use this heade= r field
=C2=A0 =C2=A0to relay that information in a convenient and meaningful way t= o users
=C2=A0 =C2=A0or to make sorting and filtering decisions.

These last two versions just tweak IANA language.=C2=A0 N= othing of substance to the protocol, and apologies for the noise.

-MSK
--f46d041827e6a8b0900517bde77c-- From nobody Fri Jun 5 00:53:50 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9C31B2D3B for ; Fri, 5 Jun 2015 00:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5I2QvlO0Osq3 for ; Fri, 5 Jun 2015 00:53:46 -0700 (PDT) Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) by ietfa.amsl.com (Postfix) with ESMTP id DF6791B2D3A for ; Fri, 5 Jun 2015 00:53:45 -0700 (PDT) Received: from smtp5.mail.ox.ac.uk ([163.1.2.207]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Z0mRi-00033V-rc; Fri, 05 Jun 2015 08:53:42 +0100 Received: from [213.205.194.46] (helo=conina.local) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Z0mRi-0007uV-Gk; Fri, 05 Jun 2015 08:53:42 +0100 Message-ID: <55715580.1090008@ninebynine.org> Date: Fri, 05 Jun 2015 08:53:36 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin References: <20150528071826.3803.44025.idtracker@ietfa.amsl.com> <55707C14.5010507@ninebynine.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 07:53:49 -0000 Responses inline... (I'll probably be out of contact for a day or so after this, so I may not be able to respond promptly. I think we're converging :) ) On 05/06/2015 01:20, Matthew Kerwin wrote: > Thanks for the review Graham (and thanks for the reminder Murray, I'd > forgotten to post a follow-up.) > > On 5 June 2015 at 02:25, Graham Klyne wrote: > >> Apologies for responding late in the day. I had intended to review this >> but it fell out of sight. I am duly reminded and offer some comments below. >> >> ... >> >> Section 1 vs Section 3 appear to be in conflict: >> >> (sect 1): "... there is no well-defined set of operations that can be >> performed on file URIs..." >> >> and >> >> (sect 3): "Implementations SHOULD, at a minimum, provide a read-like >> operation to return the contents of a file located by a file URI." >> >> I expect the intent was to say different things, but I find the result is >> confusing. Suggest drop the confusing bit in section 1, para 2, hence: >> >> [[ >> The file URI scheme is not coupled with a specific protocol, nor with a >> specific media type. See section 3 for a discussion of operations that can >> be performed. >> ]] >> >> > ​Yes, I think that's the right thing to do. Partly the text is still in two > minds about the original "the only operation is translation to/from a file > path" and the new "file URIs are CRUDable." > > My personal problem is with the phrase "well-defined"... I don't know if "a > read-like operation..." counts as well-defined or not. Irrespective, I'll > try to write something more accurate in section 1. OK. Here, in the intro, maybe less is more? > >> ... >> >> Section 3.2: >> >> [[ >> A file URI can only be translated to a local file path if it has a >> blank or no authority. Note that this differs from the previous >> specification in [RFC1738], in that previously an authority of >> "localhost" was used to refer to the local file system, but in this >> specification it equates to a UNC string with the host "localhost". >> ]] >> >> I'm uneasy with this non-backwards-compatible change of specification. In >> the past, I have actually used the "localhost" convention, so that software >> would be rendered incorrect by this revised spec. >> >> > ​This point swayed back and forth several times in the earliest revisions. > It eventually settled on the current version because most of the > implementations I'd seen acted that way anyway. Which software supported > the originally-specced localhost, if I may ask?​ > It wasn't a public product, just software I wrote. > >> Further, I'm not sure what it means to say "it equates to a UNC string >> with the host "localhost"", expecially on systems that don't use UNC >> strings. (The reference given for UNC strings, [MS-DTYP], is only >> informative so I guess that means this whole section is non-normative? >> >> > There are two points here which I'd be happy to have cleared up: > > 1. editorial: I need a better way to phrase this paragraph (in both its > occurrences.) If someone can suggest some text I'd be most obliged. > > 2. substantive: I'm thinking I should move all mention of UNC (apart from > S1.2) to the optional appendices. Is that cool with everybody? It gives the > above point a lower priority, too. I think that moving to an appendix would go a long way to alleviating my concern here. > >> Also, this incorporation of UNC string processing appears to be at odds >> with "This specification neither defines nor forbids a mechanism for >> accessing non-local files. See SMB [MS-SMB], NFS [RFC3530], NCP [NOVELL] >> for examples of protocols that can be used to access files over a network." >> (which I think is fine). >> >> > ​As I read it (which might be wrong) parsing or translating UNC strings > doesn't necessarily mean accessing network shares.​ However I think that > moving UNC to an optional appendix reaffirms the written assertion > ("...neither defines nor forbids..."), rather than confusing it (as the > current text does.) > Ack. > > >> ... >> >> Section 4: >> >> "When the file system's encoding is not known the file URI SHOULD be >> transported as an Internationalized Resource Identifier (IRI) [RFC3987] to >> avoid ambiguity." >> >> I'm not seeing how this helps. >> >> (1) are we talking about the source system or destination system file >> system encoding being unknown? I'll assume the source. >> >> > ​Yes, the source. The issue arises at the time of interpreting the URI, and > we assume the parser/interpreter and the destination file system share > knowledge about things like encodings -- so that encoding is known. > > > >> (2) If the file system name encoding is unknown, how is one to achieve a >> mapping to IRIs, which are defined to be a sequence of characters? >> >> > ​When I encode, I can (presumably) map my local encoding to Unicode, and > thus create an unambiguous IRI. This is (local)character -> > (unicode)codepoint, without needing a %-encoded intermediate. I was coming from a viewpoint that there was No knowledge of the filename encoding used. Your text mentions "Note that many modern file systems encode directory and file names as arbitrary sequences of octets. In those cases, the representation as an encoded string often depends on the user's localization settings, or defaults to UTF-8" So yes, if the character encoding is known, it makes sense to use Unicode/UTF-8 for transmission, and the rest works as you suggest. On closer reading, your text does suggest a path forward, but I think it might be clearer ... I think part of my confusion here is that the section title (is it a verb or a noun?) combined with the first sentence pointed me in the wrong direction. And the final para seems to compound my confusion. Suggest: First para of section: [[ To avoid ambiguity, 'file:' URIs SHOULD be transported as Internationalized Resource Identifiers (IRI) [RFC3987] or as URIs with non-ASCII characters UTF-8 encoded and %-escaped as needed (RFC3986, section 2.5). ]] Then adjust what follows to fall in line with this. I think that's the intent of what you're trying to say here? #g -- > > When I decode, I can (presumably) map Unicode to my local encoding. Again, > this is (unicode)codepoint -> (local)character, without a %-encoded > interiedmate. There might be codepoints in the IRI that can't be mapped to > my local encoding, in which case there's a problem - but it's a known > problem. That's no different, really, from including bad %XX sequences in a > URI. > > As the example in Appendix D says, if I'm an NTFS system (for example) and > the URI is "file:///%E3%81%A1" and I don't know anything about who encoded > it, I don't know if that's a single UTF-8 character, or three CP437 > characters, or three EBCDIC characters, any of which could have been a > valid filename at the source. The IRIs "file://ち", "file://πüí" and > "file://Ta~" are mostly unambiguous. > > > >> (In practice, I have found the main utility of file: URIs has not been for >> transportation of complete URIs between systems, but providing a mechanism >> for resolving relative references to the local file system, whatever that >> may be. In such a scenario, the base file: URI is determined locally and >> used to generate a full URI from a supplied URI reference, which can in >> turn be used to access the local file system. Here it is the relative >> references that are transported. Encoding considerations still apply, but >> I don't see that there's any reliable way to make this work if the encoding >> of source file names is not known. My approach has been to %-encode >> anything that is provided by the file system that is not a known valid URI >> (as opposed to IRI) character. How this is interpreted at the target >> system is somewhat dependent on the nature of the system and application >> concerned.) >> >> > ​The example is the same as above, bu​t without the "file://" part. If, for > argument's sake, you have two hypertext documents with "interesting" file > names, that reference each other relatively, and you're going to copy them > around between FAT, NTFS, HFS and Ext devices, how can you be sure those > relative references can be properly resolved at any given time (on any > given device)? > > > >> I'm not claiming my approach solves the compatibility/ambiguity problem, >> but I also don't think that just saying "send IRIs" does either. I think >> we have to acknowledge that there may be problems when transferring >> filenames whose original encoding is unknown. >> >> > ​Only if you want to reconstruct the filename as it was on the source file > system. But I can't think of a time we'd want to do that. > > > >> ... >> >> That's all for now. >> >> #g >> -- >> >> > ​Thanks!​ > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Fri Jun 5 08:44:46 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EE11A8A06 for ; Thu, 4 Jun 2015 12:28:55 -0700 (PDT) X-Quarantine-ID: <1fsukiRmoleB> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fsukiRmoleB for ; Thu, 4 Jun 2015 12:28:52 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68A31A89FD for ; Thu, 4 Jun 2015 12:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1433446132; x=1464982132; h=message-id:date:to:from:subject; bh=LYiHWOvBXyJE4D1k15Fw3d0AbmwF2uor97kfvsq/l1Q=; b=m7gcmhbUKuCczNashHzb+rALBNn0ek1lFbvZvgweYWxwPBturjZvTVc2 W2bEsR2w16HV6eCWWlJVbxQ6IJbaAaF2k09AoKb7KTD8F/CHdbyluViI8 sW0R/JCrp9TJTGpwQ8UE2atw5TqfoZNDXvodj+K0lhW53bxb47508nAGd M=; X-IronPort-AV: E=McAfee;i="5700,7163,7822"; a="90339536" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Jun 2015 12:28:52 -0700 X-IronPort-AV: E=Sophos;i="5.13,554,1427785200"; d="scan'208";a="484856387" X-ojodefuego: yes Received: from myvpn-l-00447.ras.qualcomm.com (HELO [99.111.97.136]) ([10.64.135.38]) by ironmsg02-R.qualcomm.com with ESMTP; 04 Jun 2015 12:28:51 -0700 Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X Date: Thu, 4 Jun 2015 12:28:50 -0700 To: (apps-discuss@ietf.org) From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 Archived-At: X-Mailman-Approved-At: Fri, 05 Jun 2015 08:44:45 -0700 Subject: [apps-discuss] Virtual Bar-BoF for SLIM: June 15 or 18 @2-3 PDT X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 19:28:56 -0000 The Doodle poll to set a time and date for a virtual Bar-BoF for SLIM shows that the two best slots are June 15 2-3 PDT (5-6 EDT) and June 18 2-3 PDT (5-6 EDT). Please immediately participate in the Doodle poll if these times don't work for you. To follow up on the SLIM face-to-face discussion in Dallas, this virtual bar-BoF provides an opportunity for further discussion on moving forward with a charter. In particular: (1) Are there objections to the current proposed charter wording, or is it acceptable? (2) Are there objections to moving forward on this basis? Please participate in the Doodle poll to select the time/date, and then in the virtual Bar-BoF. http://doodle.com/ryuai9ieqxi7hue2 I'm sending this message to the Apps-Discuss list, but all discussion should take place on the SLIM list. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- It is bad luck to be superstitious. From nobody Fri Jun 5 12:17:29 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96CB1A700A for ; Fri, 5 Jun 2015 12:17:27 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6Lpll9nJ1bk for ; Fri, 5 Jun 2015 12:17:26 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268681A7015 for ; Fri, 5 Jun 2015 12:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1433531846; x=1465067846; h=message-id:date:to:from:subject; bh=pUbJ2Mdx8TAU99mR54n7XDdpeWca+zCcQSt/PrR7Gjw=; b=qdp4bBPWIrNAzTTlAh+77I9/ZAVyb2qY962tov8Qs1+c8v81BMEbFuss doo3L1T8bqTOrmi25QyLkx/W0QKIU1zoIpxmauYoSbSABgpbZdti2umE+ kB4aq+8fBgronaL9wIoBzeE8/361Tq6smSyYBd3HVKAZDNpGErEGRCnH0 w=; X-IronPort-AV: E=McAfee;i="5700,7163,7823"; a="121930248" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jun 2015 12:17:25 -0700 X-IronPort-AV: E=Sophos;i="5.13,560,1427785200"; d="scan'208";a="933638944" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jun 2015 12:17:25 -0700 Received: from ironmsg02-R.qualcomm.com (ironmsg02-R.qualcomm.com [172.30.46.16]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t55JHORG007265; Fri, 5 Jun 2015 12:17:25 -0700 X-IronPort-AV: E=Sophos;i="5.13,560,1427785200"; d="scan'208";a="485523238" X-ojodefuego: yes Received: from myvpn-l-00447.ras.qualcomm.com (HELO [99.111.97.136]) ([10.64.135.38]) by ironmsg02-R.qualcomm.com with ESMTP; 05 Jun 2015 12:17:24 -0700 Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X Date: Fri, 5 Jun 2015 12:13:31 -0700 To: apps-discuss@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: [apps-discuss] Confirmed: Virtual Bar-BoF for SLIM: June 18 @2-3 PDT X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 19:17:27 -0000 The time and date for the virtual Bar-BoF for SLIM (from the Doodle poll) is June 18 at 2-3 PDT (5-6 EDT). To follow up on the SLIM face-to-face discussion in Dallas, this virtual bar-BoF provides an opportunity for further discussion on moving forward with a charter. In particular: (1) Are there objections to the current proposed charter wording, or is it acceptable? (2) Are there objections to moving forward on this basis? Please participate in the virtual Bar-BoF. The WebEx link will be sent in advance. I'm sending this message to the Apps-Discuss list, but all discussion should take place on the SLIM list. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- If you think dogs can't count, try putting three dog biscuits in your pocket then giving Fido only two of them. --Phil Pastoret From nobody Sat Jun 6 11:16:32 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F0D1A879D for ; Fri, 5 Jun 2015 12:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWH6q3hDyFxm for ; Fri, 5 Jun 2015 12:17:30 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 564201A8761 for ; Fri, 5 Jun 2015 12:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1433531849; x=1465067849; h=from:message-id:date:to:subject:mime-version; bh=a8XehS3LKWwGllg/UPzBCZLMDPIsg8t87ERDIeLXM2Y=; b=O4ZZ1dPDFIrKK989vo+wAr2V93wApL26w1EksoXTFh53iItl1F8uWMUo yaNNATo8ptjUBB4+CPiV2jE64glhbiYxveNXuQM5upFuiT5fnXngNhrsn Mq3z5lYSlX03NbicmePmCeLWYIBMLdrmOgopTpP8EbNsdwNmt8SlF5dP4 c=; X-IronPort-AV: E=McAfee;i="5700,7163,7823"; a="214424313" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jun 2015 12:17:29 -0700 From: Randall Gellens X-IronPort-AV: E=Sophos;i="5.13,560,1427785200"; d="scan'208";a="987131220" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 Jun 2015 12:17:27 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 5 Jun 2015 12:17:27 -0700 Message-ID: X-Mailer: Eudora for Mac OS X Date: Fri, 5 Jun 2015 12:11:24 -0700 To: (apps-discuss@ietf.org) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.85.0.31) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: X-Mailman-Approved-At: Sat, 06 Jun 2015 11:16:32 -0700 Subject: [apps-discuss] Confirmed: Virtual Bar-BoF for SLIM: June 18 @2-3 PDT X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 19:17:34 -0000 The time and date for the virtual Bar-BoF for SLIM (from the Doodle poll) is June 18 at 2-3 PDT (5-6 EDT). To follow up on the SLIM face-to-face discussion in Dallas, this virtual bar-BoF provides an opportunity for further discussion on moving forward with a charter. In particular: (1) Are there objections to the current proposed charter wording, or is it acceptable? (2) Are there objections to moving forward on this basis? Please participate in the virtual Bar-BoF. The WebEx link will be sent in advance. I'm sending this message to the Apps-Discuss list, but all discussion should take place on the SLIM list. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- mokita (moe-KEE-tah; New Guinean; noun): truth everybody knows but nobody speaks. From nobody Sat Jun 6 13:15:58 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E22B1A0066 for ; Sat, 6 Jun 2015 13:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.588 X-Spam-Level: *** X-Spam-Status: No, score=3.588 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BAYES_999=0.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0-MQ8G845Rp for ; Sat, 6 Jun 2015 13:15:56 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 953771A0065 for ; Sat, 6 Jun 2015 13:15:56 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PMUWS0VH0W00X0GW@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 6 Jun 2015 13:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1433621658; bh=7QoG/BvVFefatKGubiE6FMsiEsZD/PMPDqTAnzig8HI=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=cqy+c3rGsoZlSCl1bvXRCWvq0k6AX+H9eQjnutjcr8C5/In6m7f/LWcNxM/igx7bw VhdGRuS/0cJb3JWGOdWmyJHZIV+XP9TkRlTV5tELJtgz9bO2L12kMMrBm6jcLxACki /asuz6fvOToAX9wFASO+gu4mvLZMKNc2IEUpx5BA= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PMAA9D0GIO0000AQ@mauve.mrochek.com>; Sat, 06 Jun 2015 13:14:14 -0700 (PDT) Message-id: <01PMUWRYP8X40000AQ@mauve.mrochek.com> Date: Sat, 06 Jun 2015 13:10:50 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 04 Jun 2015 20:29:03 -0700" References: To: "Murray S. Kucherawy" Archived-At: Cc: Nick Matavka , IETF Apps Discuss Subject: Re: [apps-discuss] new gopher i-d X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jun 2015 20:15:57 -0000 > On Wed, Jun 3, 2015 at 11:03 AM, Nick Matavka < > n.theodore.matavka.files@gmail.com> wrote: > > Just to let everyone know, I uploaded a new Gopher draft. This one is in > > standard format, so that people's eyes can have a rest. > > > > Otherwise, this one carries barely any change from the original. The next > > version will be vastly overhauled. > > > While you're developing the overhaul, I'll remind people that the issue > remains open for consideration for a little while longer about whether this > work is appropriate for handling someplace in the IETF stream, or via the > ISE. Those of you who have weighed in already need not do so again, but > I'm interested in hearing from others. I'm largely in agreement with the note Lyndon Nerenberg posted at the beginning of this discussion: Gopher played an important role, and for that reason alone it's worthly of an informational RFC. I'm largely indifferent to whether it's an ISE or IETF stream document. I will also note that the recent DMARC specification was an ISE document but received extensive review by an IETF WG, which shows running code for combining the two approaches. Ned From nobody Sat Jun 6 13:46:11 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E6E1A00F9 for ; Sat, 6 Jun 2015 13:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.302 X-Spam-Level: X-Spam-Status: No, score=-99.302 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0prsBIKD8gK for ; Sat, 6 Jun 2015 13:46:08 -0700 (PDT) Received: from ntbbs.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D7F171A00F6 for ; Sat, 6 Jun 2015 13:46:07 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1664; t=1433623557; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:Subject:To:List-ID; bh=3X8xrMRt4mHtujJHGbsC/c6kaos=; b=ji7oqq/ouVwxh9trHBWA7z8HSRobj5zQwyi7VpNsv413rXX//YnKz6iaLsM7xG MtjSKEaZ9H0OLhXSLCOzx7VE4UekmPZ1oUCvA8vih6/xQv1MEV8t74f2LxhCeiJE hp+nann93Dd8UhPCLBWVI5zfkSaS+JjPP2IFu9qG3zMyQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 06 Jun 2015 16:45:57 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3038552151.3911.5132; Sat, 06 Jun 2015 16:45:56 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1664; t=1433623229; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=ZDYpzZA QRBsu8PK5rR7nigrbhQGk0lEse3Es4XRx180=; b=052KAKRvx4+lt3DC2OpY0QG Hn7X039Lj3wIfZQCycmNyvxCaHzWkVe7CXiInRWKSgV48I1oxCKZP0Cq/eOPpwLm xXF1dNvSEGfQEpaXiY964TpBJ1UreluaDoDkwowKH7s5yDvIkqv2WkOr2IvbDvyw FomDwT2ThbRV8PcqWVQE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 06 Jun 2015 16:40:29 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1630798661.9.34064; Sat, 06 Jun 2015 16:40:29 -0400 Message-ID: <55735C04.2040303@isdg.net> Date: Sat, 06 Jun 2015 16:45:56 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 CC: IETF Apps Discuss References: <01PMUWRYP8X40000AQ@mauve.mrochek.com> In-Reply-To: <01PMUWRYP8X40000AQ@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: apps-discuss@ietf.org Archived-At: Subject: Re: [apps-discuss] new gopher i-d X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jun 2015 20:46:10 -0000 On 6/6/2015 4:10 PM, Ned Freed wrote: > > I'm largely in agreement with the note Lyndon Nerenberg posted at the beginning > of this discussion: Gopher played an important role, and for that reason alone > it's worthly of an informational RFC. > > I'm largely indifferent to whether it's an ISE or IETF stream document. I will > also note that the recent DMARC specification was an ISE document but received > extensive review by an IETF WG, which shows running code for combining > the two approaches. +1 Good point. I was going to add such a similar note as well but..... IMO, these days an informational RFC is leveraged as a means to fast track an RFC and also promote and market an idea as if it is the "industry standard." IMO, too much of that is going on and DMARC and others fall in this category. It has concerned me as it increases stress to participate (don't rock the boat), increases cost to explore and implement lower quality work. I really don't care who does the work, but what concerns me the most is that poor quality work creates future compatibility problems. But in this case with an existing technology, I think its important what the status we are looking for here. I think Gopher should be an Informational or BCP to summarize the technology as it is used today. In fact, I believe the IETF should review all the legacy communications technologies that help get each and every one of us here, including FTP and even RS232. People would be surprise to know how in a wide number of enterprise mission critical operations, RS232 is still used to get around TCP/IP Encryption security requirements. -- HLS From nobody Sat Jun 6 15:25:12 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3B21A1A42 for ; Sat, 6 Jun 2015 15:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cx6Os5Fm0Ovp for ; Sat, 6 Jun 2015 15:25:07 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B603B1A079D for ; Sat, 6 Jun 2015 15:25:07 -0700 (PDT) Received: (qmail 4652 invoked from network); 6 Jun 2015 22:25:15 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 6 Jun 2015 22:25:15 -0000 Date: 6 Jun 2015 22:24:44 -0000 Message-ID: <20150606222444.1017.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <01PMUWRYP8X40000AQ@mauve.mrochek.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: ned.freed@mrochek.com Subject: Re: [apps-discuss] new gopher i-d X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jun 2015 22:25:11 -0000 >I'm largely in agreement with the note Lyndon Nerenberg posted at the beginning >of this discussion: Gopher played an important role, and for that reason alone >it's worthly of an informational RFC. RFC 1436 describes the Gopher protocol as I believe it was widely implemented. The I-D we've been talking about is a proposed Gopher II. R's, John From nobody Sat Jun 6 19:07:24 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484FF1A7004 for ; Sat, 6 Jun 2015 19:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.688 X-Spam-Level: X-Spam-Status: No, score=0.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1-YPPkXKg82 for ; Sat, 6 Jun 2015 19:07:22 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8381A1BD1 for ; Sat, 6 Jun 2015 19:07:22 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PMV8XJM5W000VDJ7@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 6 Jun 2015 19:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1433642540; bh=3ngeiRzQLC2uZeB3crV7Ju3OjKdP3Qhfx2bScdgb0wM=; h=Date:From:Subject:In-reply-to:References:To; b=GRz9gKEWOCE+em6nw0I/khoZD42Cm3tjOPn1kpwtlRveYmQkHZ8GKJpuzxWpRPM+D pw5Qwf7ALXDdm4rTEeJYjns/RrUBY1b+t+H38wGl/Ksx7dTPjYuzeLD1gE+SzlTyXI lvBVjq1qOes5ddqqq2xIJIQzyqQPRN3l0lAzM4tw= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PMAA9D0GIO0000AQ@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 06 Jun 2015 19:02:18 -0700 (PDT) Message-id: <01PMV8XIC2DE0000AQ@mauve.mrochek.com> Date: Sat, 06 Jun 2015 18:56:46 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 06 Jun 2015 22:24:44 +0000" <20150606222444.1017.qmail@ary.lan> References: <01PMUWRYP8X40000AQ@mauve.mrochek.com> <20150606222444.1017.qmail@ary.lan> To: apps-discuss@ietf.org Archived-At: Subject: Re: [apps-discuss] new gopher i-d X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jun 2015 02:07:23 -0000 > >I'm largely in agreement with the note Lyndon Nerenberg posted at the beginning > >of this discussion: Gopher played an important role, and for that reason alone > >it's worthly of an informational RFC. > RFC 1436 describes the Gopher protocol as I believe it was widely > implemented. The I-D we've been talking about is a proposed Gopher II. That's not how I read the abstract, which says: The Gopher protocol is over twenty years old. Changing practices and unofficial extensions have caused Gopher as currently used to differ, but remain largely compatible with, the standard established in its official governing document, *The Internet Gopher Protocol (a distributed document search and retrieval protocol)*, known as *RFC 1436*. Therefore, this document attempts to establish a contemporary specification of the Gopher communications protocol, departing as little as possible from current practice. Now, you may argue that any departure from existing practice is too much. And I would disagree - that's why I referred to the DMARC exercise, which I think serves as running code as to how such a process might work and the possible benefits that might accrue. Ned From nobody Sat Jun 6 22:58:32 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB531A87D1 for ; Sat, 6 Jun 2015 22:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.672 X-Spam-Level: ** X-Spam-Status: No, score=2.672 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, MISSING_SUBJECT=1.799, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybjuU0M97daL for ; Sat, 6 Jun 2015 22:58:31 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079B41A8781 for ; Sat, 6 Jun 2015 22:58:31 -0700 (PDT) Received: by pdbki1 with SMTP id ki1so78676893pdb.1 for ; Sat, 06 Jun 2015 22:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:content-transfer-encoding:message-id:date :from:to; bh=OZCISh/S+2djvIW58dqeFkPMxkmCq8PlMvkLptRtR5U=; b=cOrXkjWgSb9Qwp42b8JRvHGgHTE030rkL8CgtwVP+YIYoxhmU2/jW1uKFeRWLM/mGM tK5ToIlDJJAGrT+XaPFhoxdQ1HMNbgNw7vOlRneJAm0kPfFgvyAEeqtP2M3Gmo0Exi0n 1/jja+mGyg5sn6WOMwUp6H4mVgPy/1kT9dCeJ5LENPN1l4XhJ4eAkhmtAUIz6I+pXO4C P7nhoA1dlf4IZDisuj4A066P5QDcvEViF2eNJ0tmxLfesKHesKT8p7AUd2B/G3SCaQZ4 6Qwo0jCrqtGLyxo+mATcXJTc4qg7tfWSTc0iYXQM4a9qLG2n8PjQXZFHeXub6n+fzzMw /rDA== X-Received: by 10.70.43.10 with SMTP id s10mr19152277pdl.57.1433656710691; Sat, 06 Jun 2015 22:58:30 -0700 (PDT) Received: from [127.0.0.1] ([182.11.74.41]) by mx.google.com with ESMTPSA id ff10sm11128315pab.13.2015.06.06.22.58.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Jun 2015 22:58:29 -0700 (PDT) Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.1.2576) Message-ID: <20150607055826.5767247.21470.343@gmail.com> Date: Sun, 07 Jun 2015 12:58:26 +0700 From: Johny wijaya To: %%%/ sussy wijayaVVV/ Archived-At: Subject: [apps-discuss] (no subject) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jun 2015 05:58:31 -0000


Di= kirim dari ponsel cerdas BlackBerry 10 saya&n= bsp;dengan jaringan Telkomsel.
From nobody Sun Jun 7 19:27:17 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE861B2AA4 for ; Sun, 7 Jun 2015 19:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.69 X-Spam-Level: *** X-Spam-Status: No, score=3.69 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BAYES_999=0.2, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXykZ-BoQJZA for ; Sun, 7 Jun 2015 19:27:15 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 897DA1B2AA3 for ; Sun, 7 Jun 2015 19:27:14 -0700 (PDT) Received: from CNNIC-PC (unknown [218.241.119.117]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0B5gZWB_XRV449nBw--.3298S2; Mon, 08 Jun 2015 10:27:13 +0800 (CST) Date: Mon, 8 Jun 2015 10:27:08 +0800 From: "qinxiaowei@cnnic.cn" To: apps-discuss X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <2015060810270811245415@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart084703062262_=----" X-CM-TRANSID: AQAAf0B5gZWB_XRV449nBw--.3298S2 X-Coremail-Antispam: 1UD129KBjvdXoWrZw4DXF1ruFykKFyDury7Awb_yoW3GrbE9a 12q3yUuw4akF47Xws8K3yFvrW8K3yruFWkZFykKa4fu347Ar93tFnrtFZ7W3WxJwn5X3sx WrZaqFyxKr13WjkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbpkYjsxI4VWDJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW7JVWDJwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26F4UJVW0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40En4AK xVAvwIkv4cxYr24l5I8CrVC2j2CEjI02ccxYII8I67AEr4CY67k08wAqx4xG6I8I3I0E8c IF7480aVAKz4kxMcIj6xIIjxv20xvE14v26r106r15McIj6I8E87Iv67AKxVWUJVW8JwAm 72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0w ACY4xI67k04243AVC20s07Mx8GjcxK6IxK0xIIj40E5I8CrwCY02Avz4vE14v_Gr1l42xK 82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWw C20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1j6r15MIIYrxkI7VAKI48J MIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMI IF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY 6I8E87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa 7IU8dnY7UUUUU== X-CM-SenderInfo: xtlq5x5drzvxw6fq0xffof0/ Archived-At: Subject: [apps-discuss] An Upload Acceleration Transport Network for Upstream Traffic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 02:27:16 -0000 This is a multi-part message in MIME format. ------=_001_NextPart084703062262_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBhbGyjrA0KICAgICANCiAgICAgIEFzIG1vYmlsZSBwaG9uZXMgYW5kIG90aGVyIHNtYXJ0 IGRldmljZXMgYXJlIHByb2xpZmVyYXRpbmcsIG1vcmUgYW5kIG1vcmUgZW5kIHVzZXJzIGxpa2Ug ZGlyZWN0bHkgdXBsb2FkaW5nIGFuZCBzaGFyaW5nIHRoZWlyIHBob3RvcywgdmlkZW9zIG9yIG90 aGVyIGRvY3VtZW50cyBieSBkYXRhIGNlbnRlcnMuIA0KICAgICAgQmVzaWRlcywgbW9iaWxlIGRl dmljZXMgZW1lcmdpbmcgYXJlIGZ1bGx5IGNsb3VkLWRlcGVuZGVudCB0aGF0IGFyZSBub3QgZXF1 aXBwZWQgd2l0aCBtdWNoIHN0b3JhZ2UgYnV0IHJlbHkgb24gbGFyZ2Ugc3RvcmFnZSBpbiBkYXRh IGNlbnRlcnMuIA0KICAgICAgRm9yIHRoZXNlIHJlYXNvbnMsIGEgbGFyZ2UgbnVtYmVyIG9mIE9u bGluZSBTdG9yYWdlIFNlcnZpY2UgUHJvdmlkZXJzKE9TU1BzKSxQaG90b3MgU2hhcmluZyBTZXJ2 aWNlIFByb3ZpZGVycyAoUFNTUHMpLCBhbmQgVmlkZW9zIFNoYXJpbmcgU2VydmljZSBQcm92aWRl cnMgKFZTU1BzKSBlbWVyZ2UgYXQgYSBoaXN0b3JpYyBtb21lbnQgc28gdGhhdCBtYWtlIHVwc3Ry ZWFtIHRyYWZmaWNzIHJhcGlkbHkgaW5jcmVhc2luZyBhbmQgZXhwZWN0ZWQgdG8gY29udGludWUg ZG9pbmcgc28gaW4gdGhlIGZ1dHVyZS4gDQogICAgICBBIGxvdCBvZiBmYWN0b3JzLCBzdWNoIGFz IGxvbmcgcm91bmQtdHJpcC10aW1lIChSVFQpLCBsb3cgcm9idXN0bmVzcyBvZiBkZWxpdmVyeSwg YW5kIHRyYW5zcG9ydCBib3R0bGVuZWNrcywgZXRjLiwgbGVhZCB0byBsb3cgdXBsb2FkIHJhdGUs IHdoaWNoIGNhdXNlIHBvb3IgdXNlciBleHBlcmllbmNlcy4NCiAgICAgIEkgaGF2ZSBwcm9wb3Nl ZCBhbiBhcHByb2FjaCB0byB1cGxvYWQgYWNjZWxlcmF0aW9uIHRyYW5zcG9ydCBuZXR3b3JrIGZv ciB1cHN0cmVhbSB0cmFmZmljcywgYW5kIHRoZSBkcmFmdHMgd2FzIHN1Ym1pdHRlZC4gDQogICAg ICBUaGlzIGlzIHRoZSBsaW5rLCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXFpbi10c3Z3Zy11YXRudXQvIA0KICAgICBBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCiAg IFJlZ2FyZHMsDQoNCiAgIFhpYW93ZWkgUWluDQoNCg0KDQo= ------=_001_NextPart084703062262_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable =0A
Dear all=A3=AC
=      
      = As mobile phones and other smart devices are pr= oliferating, more and more end users like directly uploading and sharing t= heir photos, videos or other documents by data centers. 
=
      Besides, mobile devices emerging = are fully cloud-dependent that are not equipped with much storage but rely= on large storage in data centers. 
&= nbsp;     For these reasons, a large number of = Online Storage Service Providers(OSSPs),Photos Sharing Service Providers (= PSSPs), and Videos Sharing Service Providers (VSSPs) emerge at a historic = moment so that make upstream traffics rapidly increasing and expected to c= ontinue doing so in the future. 
    =   A lot of factors, such as long round-trip-time (RTT), low robustnes= s of delivery, and transport bottlenecks, etc., lead to low upload rate, w= hich cause poor user experiences.
    &nbs= p; I have proposed an approach to upload= acceleration transport network for upstream traffics, and     &nbs= p; This is the link, http://datatracker.ietf.org/doc/draf= t-qin-tsvwg-uatnut/ 
     Any comments are welc= ome.

   Regards,
=

   Xiaowei Qin
=0A
=0A
=0A ------=_001_NextPart084703062262_=------ From nobody Mon Jun 8 02:21:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154481B2DE6 for ; Mon, 8 Jun 2015 02:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoctfoKNuYnW for ; Mon, 8 Jun 2015 02:21:14 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A651B2DE2 for ; Mon, 8 Jun 2015 02:21:14 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 23768FA00CC; Mon, 8 Jun 2015 09:21:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1433755272; bh=fAaqntN6wTYZLTa4s5tCFWgRJoI9psu71RApvzud4cQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=e9dGJ+ZJdbqleEgZsHDN+ge4kmt6uwW52ZRDq29NiZ70iCRpp+Z+4nFBj4Qi42oBF yw5WiX8/CSbeyxFFK0D+APsAhrXcUMR05Da1nCZLF6HKHWVyQPIewwxpdb/D6Ym0qX w/UA9ihj4S6iDAB69I8aeCDfOau++CwcEhS4+J0w= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1433755271-25087-25086/12/6; Mon, 8 Jun 2015 09:21:11 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Mon, 8 Jun 2015 10:22:39 +0100 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Debian GNU/Linux 8.0 (jessie) Mime-Version: 1.0 Message-Id: <5c9e933b-396f-4e49-a09d-f607459fb613@gulbrandsen.priv.no> In-Reply-To: <2015060810270811245415@cnnic.cn> References: <2015060810270811245415@cnnic.cn> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [apps-discuss] An Upload Acceleration Transport Network for Upstream Traffic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 09:21:21 -0000 Hi, in the draft you write that According to the report in [1], throughput measurements from over 1.5 million mobile devices have shown that compared with an average downstream throughput of over 1860 Kbps, the average upstream throughput is only about 430 Kbps. This is because of the adoption of cache techniques such as CDNs to acelerate downloading large content that moves the "content" closer to end users. Really? If that is true, then the same problem will also affect non-mobile users. But I have access to logs that show considerably higher typical speeds. I think that before this can progress, you have to show that the problem really is a lack of things like CDNs for upload. Arnt From nobody Mon Jun 8 03:19:45 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E778D1A0060 for ; Mon, 8 Jun 2015 03:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BKIGHbOzYOh for ; Mon, 8 Jun 2015 03:19:43 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A163F1A005D for ; Mon, 8 Jun 2015 03:19:43 -0700 (PDT) Received: by ieclw1 with SMTP id lw1so94786905iec.3 for ; Mon, 08 Jun 2015 03:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vgI+trSgGEXJxthHFCdwRVtWlSSOy2arSuaYAcK2USU=; b=x2BUWsYTTMRbXqTSELibeCH7crG0AtGhp8y0/ZUClObjoIvQC+x49sprNGE9BJhBIs b2wIyS1ZxYV9YC1huobw4IOWgIlzQtVT1yTf11DiWr7Cz6HlKcUIswcAcVQLiOv+sx32 dcvTuHsDp1NgZDdNTCgKERSHq5NI2c3SzMB7h/9MMaBJAj9C7hfgP1LVOTs0osji9Zjr B4pVXBi7+kBVAWJnd+Av2pIq/3eZ+IkmG9MzkAZq4P7tyoJH6RvSVrgQmQsb5qW5kgG9 OH7hgYpLX59h7xu2XNMweayZM9QDAeG1y3JrQqspHAEDx7R0Ss1PxNzHn5mqvPGG9sq5 HAnw== MIME-Version: 1.0 X-Received: by 10.107.128.134 with SMTP id k6mr16525855ioi.7.1433758783186; Mon, 08 Jun 2015 03:19:43 -0700 (PDT) Received: by 10.107.14.77 with HTTP; Mon, 8 Jun 2015 03:19:43 -0700 (PDT) Date: Mon, 8 Jun 2015 12:19:43 +0200 Message-ID: From: Nick Matavka To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=001a113ed292f730060517fefabe Archived-At: Subject: [apps-discuss] New gopherii draft revision X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 10:19:45 -0000 --001a113ed292f730060517fefabe Content-Type: text/plain; charset=UTF-8 It can be seen at https://datatracker.ietf.org/doc/draft-matavka-gopher-ii/ --001a113ed292f730060517fefabe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a113ed292f730060517fefabe-- From nobody Mon Jun 8 04:05:31 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7731A1B44 for ; Mon, 8 Jun 2015 04:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YueN8S_pNHUK for ; Mon, 8 Jun 2015 04:05:28 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981B11A1A72 for ; Mon, 8 Jun 2015 04:05:28 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so56436371igb.1 for ; Mon, 08 Jun 2015 04:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=0ml0984EVfzKy66OYCU985GHU6u3tjVRwaP2CCMxLm8=; b=0pDkncr3nJH1UhBhCat49HJ6APH+Yi/aEt2r/3hMq3D/0lYAyV7EhTTo797Ol/uCV3 g6PN5B/5WykCsCfCyZfxXuby7X4u4cljxbm6p8h18OPnppJDf5LoWgkQdvIrDxJq7ZCK NjasuFSb4fdz1EtoQgKa5fELfIy5EzyYm/y/w+bI4xV05/pBuWaXYp/8NmTaidVJ2E4Z veyPHIUvqxh5HtZRKAHn62DLhvtbQNxhzYEesFgI4cpN0Zm8RMm3v2paXPvP7xfaYbU9 /GJyf9v6bWpnuR+OmaCu/5s4oFp9eL1jEH9ANa8dLy5Rzr7x4KMKRTD0AdUUPFBY4aQN DbJQ== MIME-Version: 1.0 X-Received: by 10.42.146.202 with SMTP id k10mr23187245icv.34.1433761528076; Mon, 08 Jun 2015 04:05:28 -0700 (PDT) Received: by 10.107.14.77 with HTTP; Mon, 8 Jun 2015 04:05:28 -0700 (PDT) Date: Mon, 8 Jun 2015 13:05:28 +0200 Message-ID: From: Nick Matavka To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=90e6ba6e8e9c92e2b90517ff9e0d Archived-At: Subject: [apps-discuss] Formal request for shepherding X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 11:05:30 -0000 --90e6ba6e8e9c92e2b90517ff9e0d Content-Type: text/plain; charset=UTF-8 Hello, world! I think my GopherII internet-draft is coming along nicely, Masinter's perfectly reasonable objections not withstanding. That said, I know that IETF process requires a mentor or "shepherd" to get to the next stage. Therefore, this is my formal request for an experienced hand to take on this role. While I understand that John Klensin is unavailable to take this on for reasons of time and other commitments, the Danish fellow (I think his name is Gulbrandsson) put himself forward for the role, at least that's the way I read his private e-mail. Is anyone else putting their hat in the ring? xx Nick --90e6ba6e8e9c92e2b90517ff9e0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello, world!

I think my = GopherII internet-draft is coming along nicely, Masinter's perfectly re= asonable objections not withstanding.=C2=A0 That said, I know that IETF pro= cess requires a mentor or "shepherd" to get to the next stage.=C2= =A0 Therefore, this is my formal request for an experienced hand to take on= this role.

While I understand that John Klensin is unavailable to take t= his on for reasons of time and other commitments, the Danish fellow (I thin= k his name is Gulbrandsson) put himself forward for the role, at least that= 's the way I read his private e-mail.

Is anyone else putting their ha= t in the ring?

xx Nick
--90e6ba6e8e9c92e2b90517ff9e0d-- From nobody Mon Jun 8 04:06:26 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A272A1A1B44 for ; Mon, 8 Jun 2015 04:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3MhiKe_LvUK for ; Mon, 8 Jun 2015 04:06:23 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F7D81A1A72 for ; Mon, 8 Jun 2015 04:06:23 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so60087412ieb.1 for ; Mon, 08 Jun 2015 04:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+U3yLfU3lL8uVbAKv9koVDNebtnOdENdIXY/o6EgsZo=; b=VGAHYgDZDt+MzpPAx3HCsWbl6PcL0q1WZ8Lgk0WIFdckEgeKCcL5LuCT0h/MJbfFS1 h2ZzdaKBPIDWJBgfBrGyOIuLiSQ5biZZbJhTVc1/4w40azs42G9IS9iIw38DliJZmRKp UnYk4ikU4mjyb34smCc85HxrmrDeC3bXTjHham0QqxA/t4L+xD1CLvowg9nttKRBkaUp 5f07HX0Y3/GXwlkyYK2GOycRMzv67vdOvF7IAUZp8ITteEkNRJi8aY5GPQwVy0B3uCBT UupYuH9UJbTuwp8O3rKpXwfu0VtZH0l2pcjEq58GMO+drcHRk+SmsotamFovWjb/j02h CqXQ== MIME-Version: 1.0 X-Received: by 10.107.160.141 with SMTP id j135mr19467001ioe.43.1433761582757; Mon, 08 Jun 2015 04:06:22 -0700 (PDT) Received: by 10.107.14.77 with HTTP; Mon, 8 Jun 2015 04:06:22 -0700 (PDT) In-Reply-To: References: Date: Mon, 8 Jun 2015 13:06:22 +0200 Message-ID: From: Nick Matavka To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=001a1140a2b6d540340517ffa1ac Archived-At: Subject: [apps-discuss] Fwd: apps-discuss Digest, Vol 88, Issue 20 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 11:06:25 -0000 --001a1140a2b6d540340517ffa1ac Content-Type: text/plain; charset=UTF-8 Does this mean you're putting yourself forward for the role Arnt? If so, I would dearly like to have you. ---------- Forwarded message ---------- From: Arnt Gulbrandsen Date: 28 May 2015 at 16:32 Subject: Re: [apps-discuss] apps-discuss Digest, Vol 88, Issue 20 To: Nick Matavka Nick: Please calm down. And turn off the digest mode. It's not forbidden, but turn it off anyway. The IESG finally decides, and the IESG is good. If it has a weakness, it is that it'll decide against people who use strong language. People who have a well-formatted draft, a document mentor, two independent implementations and a calm tone of voice can get almost anything published, and Gopher certainly is publishable. As long as you have all four conditions, the only question is the wording on the first five lines of the document. People like Larry Masinter or Phillip Whathisname don't have the power to stop anyone who meets those four conditions. The document mentor is really called something else. Steward? I don't remember. Anyway, it's an IETF regular whose tasks include deciding when the document is ready and doing a few chires. There's a form to be filled in. One can be found for Gopher. I'm qualified, and I'm sure Barry can name better candidates. Arnt -- /^\/^\ \----| _---'---~~~~-_ ~~~|~~L~|~~~~ (/_ /~~-- \~ \ / /~ __~\ ~ / ~~----, \ | | / \ /| |/ | | | | | o o /~ | _-~_ | || \ / (// )) | o o \\---' //_- | | \ // |____|\______\__\ ~ | / | | |_ / \ _| /~___| /____\ --001a1140a2b6d540340517ffa1ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Does this mean you're putting yourself forward for the= role Arnt?

If so, I would dearly like to have you.

---------- Forwarded message ---------= -
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.= no>
Date: 28 May 2015 at 16:32
Subject: Re: [apps-discu= ss] apps-discuss Digest, Vol 88, Issue 20
To: Nick Matavka <n.theodore.matavka.files@gma= il.com>


Nick: Please calm down. And turn off the digest m= ode. It's not forbidden, but turn it off anyway.

The IESG finally decides, and the IESG is good. If it has a weakness, it is= that it'll decide against people who use strong language. People who h= ave a well-formatted draft, a document mentor, two independent implementati= ons and a calm tone of voice can get almost anything published, and Gopher = certainly is publishable. As long as you have all four conditions, the only= question is the wording on the first five lines of the document.

People like Larry Masinter or Phillip Whathisname don't have the power = to stop anyone who meets those four conditions.

The document mentor is really called something else. Steward? I don't r= emember. Anyway, it's an IETF regular whose tasks include deciding when= the document is ready and doing a few chires. There's a form to be fil= led in. One can be found for Gopher. I'm qualified, and I'm sure Ba= rry can name better candidates.

Arnt




--
=C2=A0 =C2=A0 =C2=A0 =C2=A0/^\/^\
=C2=A0 =C2=A0 = =C2=A0 =C2=A0\----|
=C2=A0 =C2=A0_---'---~~~~-_ =C2=A0
=C2=A0 = =C2=A0 ~~~|~~L~|~~~~
=C2=A0 =C2=A0 =C2=A0 =C2=A0(/_ =C2=A0/~~--
=C2= =A0 =C2=A0 =C2=A0\~ \ =C2=A0/ =C2=A0/~
=C2=A0 =C2=A0__~\ =C2=A0~ / =C2= =A0 ~~----,
=C2=A0 =C2=A0\ =C2=A0 =C2=A0| | =C2=A0 =C2=A0 =C2=A0 / =C2= =A0\ =C2=A0
=C2=A0 =C2=A0/| =C2=A0 |/ =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2= =A0|
=C2=A0 =C2=A0| | | o =C2=A0o =C2=A0 =C2=A0 /~ =C2=A0 | =C2=A0
= =C2=A0_-~_ =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0|| =C2=A0\ =C2=A0/
(// ))= | o =C2=A0o =C2=A0 =C2=A0\\---'
//_- | =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0\
// =C2=A0 |____|\______\__\
~ =C2=A0 =C2=A0 =C2= =A0| =C2=A0 / | =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0|_ / =C2=A0 \= _|
=C2=A0 =C2=A0 =C2=A0/~___| =C2=A0/____\ =C2=A0 =C2=A0 =C2=A0 =C2=A0=
--001a1140a2b6d540340517ffa1ac-- From nobody Mon Jun 8 06:02:35 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBFD1A82E2 for ; Mon, 8 Jun 2015 06:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7D0SoOuevdkI for ; Mon, 8 Jun 2015 06:02:31 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C520E1A702B for ; Mon, 8 Jun 2015 06:02:31 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 44E25FA00CC; Mon, 8 Jun 2015 13:02:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1433768548; bh=2g1KlZkZsh+3Dfhgu0UgLAmVrVkxvsFdv1Gn6Mdf+hI=; h=From:To:Subject:References:Date:From; b=cJ+yIvk5QAqXnvc5763WQjPYrHlIJ977gUEyww3xIoE/8rsjfD3sEpJa2Dab82n0F fBkmXnDaRVE3DvapmxZ5lYKUvoFR1yUOiCh+suZcXOQGbG5sWv26+Ys8/N5ylw6SME 6KixzWG35F1y+YfWsI/I31HGTJwjRGOQnYaE59Ys= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1433768547-25087-25086/12/9; Mon, 8 Jun 2015 13:02:27 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org, Nick Matavka Message-Id: References: Mime-Version: 1.0 Content-Type: text/plain; format=flowed Date: Mon, 8 Jun 2015 13:02:27 +0000 Archived-At: Subject: Re: [apps-discuss] Formal request for shepherding X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 13:02:33 -0000 I an Norwegian, not Danish, and while I am willing, I am perhaps not the perfect candidate. I have observed that good shepherds are somewhat different from me temperamentally. Arnt From nobody Mon Jun 8 08:38:09 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EA81B2F59 for ; Mon, 8 Jun 2015 08:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PadkM7fD9ndz for ; Mon, 8 Jun 2015 08:38:01 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874D21B2F5A for ; Mon, 8 Jun 2015 08:37:03 -0700 (PDT) Received: from mb-aye.local ([172.56.8.214]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t58FapCH038056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 8 Jun 2015 15:36:55 GMT (envelope-from joelja@bogus.com) To: "qinxiaowei@cnnic.cn" , apps-discuss References: <2015060810270811245415@cnnic.cn> From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <5575B68C.4070305@bogus.com> Date: Mon, 8 Jun 2015 08:36:44 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: <2015060810270811245415@cnnic.cn> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UbMto3ofvHegIHp0DhLuABLLLvUA9aCtj" Archived-At: Subject: Re: [apps-discuss] An Upload Acceleration Transport Network for Upstream Traffic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 15:38:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UbMto3ofvHegIHp0DhLuABLLLvUA9aCtj Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/7/15 7:27 PM, qinxiaowei@cnnic.cn wrote: > Dear all=EF=BF=BD=EF=BF=BD > =20 > As mobile phones and other smart devices are proliferating, more > and more end users like directly uploading and sharing their photos, > videos or other documents by data centers.=20 > Besides, mobile devices emerging are fully cloud-dependent that > are not equipped with much storage but rely on large storage in data > centers.=20 > For these reasons, a large number of Online Storage Service > Providers(OSSPs),Photos Sharing Service Providers (PSSPs), and Videos > Sharing Service Providers (VSSPs) emerge at a historic moment so that > make upstream traffics rapidly increasing and expected to continue doin= g > so in the future.=20 > A lot of factors, such as long round-trip-time (RTT), low > robustness of delivery, and transport bottlenecks, etc., lead to low > upload rate, which cause poor user experiences. > I have proposed an approach to upload acceleration transport > network for upstream traffics, and the drafts was submitted.=20 > This is the > link, http://datatracker.ietf.org/doc/draft-qin-tsvwg-uatnut/=20 > Any comments are welcome. According to the report in [1], throughput measurements from over 1.5 million mobile devices have shown that compared with an average downstream throughput of over 1860 Kbps, the average upstream throughput is only about 430 Kbps. This is because of the adoption of cache techniques such as CDNs to acelerate downloading large content that moves the "content" closer to end users. HSDPA/HSUPA/LTE networks employ asymmetry in data-rates between the tower and the handset, and the handset and the tower; so your first and most direct source of asymmetry is right at radio access-side of things. just installing more data servers will not be enough[RFC6392]. Moving data server closer to the end users results in greater network efficiency: improved Quality of Service (QoS), increased robustness of delivery,and lower latency. The only parameter that distance changes directly is bandwith delay-product. if the carrier's network is congested it's congested irrespective of the destination. > Regards, >=20 > Xiaowei Qin >=20 > -----------------------------------------------------------------------= - >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 --UbMto3ofvHegIHp0DhLuABLLLvUA9aCtj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlV1to0ACgkQ8AA1q7Z/VrKEHACfZrpMWZAVxOmnBopWH7HF6Nja LHAAnjWamPslZZXPCGB2ebj8/Wgrg+p6 =ujIB -----END PGP SIGNATURE----- --UbMto3ofvHegIHp0DhLuABLLLvUA9aCtj-- From nobody Mon Jun 8 10:10:31 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35801B2AA2 for ; Sun, 7 Jun 2015 19:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.69 X-Spam-Level: *** X-Spam-Status: No, score=3.69 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BAYES_999=0.2, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEPrx3u3ASYW for ; Sun, 7 Jun 2015 19:21:56 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4581B2AA1 for ; Sun, 7 Jun 2015 19:21:53 -0700 (PDT) Received: from CNNIC-PC (unknown [218.241.119.117]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0Dp8JQ+_HRV+45nBw--.3384S2; Mon, 08 Jun 2015 10:21:50 +0800 (CST) Date: Mon, 8 Jun 2015 10:21:45 +0800 From: "qinxiaowei@cnnic.cn" To: apps-discuss X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <2015060810214530361312@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart507535120425_=----" X-CM-TRANSID: AQAAf0Dp8JQ+_HRV+45nBw--.3384S2 X-Coremail-Antispam: 1UD129KBjvdXoWrZw4DXF1ruFykKFyDury7Awb_yoW3GrbE9a 12q3yUuw4akF47Xws8K3yFvrW8K3yruFWkZFykKa4fu347Ar93tFnrtFZ7W3WxJwn5X3sx WrZaqFyxKr13WjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbmkYjsxI4VWDJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW7JVWDJwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26F4UJVW0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40En4AK xVAvwIkv4cxYr24l5I8CrVC2j2CEjI02ccxYII8I67AEr4CY67k08wAv7VC0I7IYx2IY67 AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48I cxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2IqxwCjr7xvwV CIw2I0I7xG6c02F41lc2xSY4AK67AK6r4UMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCj c4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4 CE17CEb7AF67AKxVWUJVWUXwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1x MIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJV Cq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UMVCE FcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU8Jku3UUUUU== X-CM-SenderInfo: xtlq5x5drzvxw6fq0xffof0/ Archived-At: X-Mailman-Approved-At: Mon, 08 Jun 2015 10:10:30 -0700 Subject: [apps-discuss] Upload Acceleration Transport Network for Upstream Traffic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 02:21:57 -0000 This is a multi-part message in MIME format. ------=_001_NextPart507535120425_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBhbGyjrA0KICAgICANCiAgICAgIEFzIG1vYmlsZSBwaG9uZXMgYW5kIG90aGVyIHNtYXJ0 IGRldmljZXMgYXJlIHByb2xpZmVyYXRpbmcsIG1vcmUgYW5kIG1vcmUgZW5kIHVzZXJzIGxpa2Ug ZGlyZWN0bHkgdXBsb2FkaW5nIGFuZCBzaGFyaW5nIHRoZWlyIHBob3RvcywgdmlkZW9zIG9yIG90 aGVyIGRvY3VtZW50cyBieSBkYXRhIGNlbnRlcnMuIA0KICAgICAgQmVzaWRlcywgbW9iaWxlIGRl dmljZXMgZW1lcmdpbmcgYXJlIGZ1bGx5IGNsb3VkLWRlcGVuZGVudCB0aGF0IGFyZSBub3QgZXF1 aXBwZWQgd2l0aCBtdWNoIHN0b3JhZ2UgYnV0IHJlbHkgb24gbGFyZ2Ugc3RvcmFnZSBpbiBkYXRh IGNlbnRlcnMuIA0KICAgICAgRm9yIHRoZXNlIHJlYXNvbnMsIGEgbGFyZ2UgbnVtYmVyIG9mIE9u bGluZSBTdG9yYWdlIFNlcnZpY2UgUHJvdmlkZXJzKE9TU1BzKSxQaG90b3MgU2hhcmluZyBTZXJ2 aWNlIFByb3ZpZGVycyAoUFNTUHMpLCBhbmQgVmlkZW9zIFNoYXJpbmcgU2VydmljZSBQcm92aWRl cnMgKFZTU1BzKSBlbWVyZ2UgYXQgYSBoaXN0b3JpYyBtb21lbnQgc28gdGhhdCBtYWtlIHVwc3Ry ZWFtIHRyYWZmaWNzIHJhcGlkbHkgaW5jcmVhc2luZyBhbmQgZXhwZWN0ZWQgdG8gY29udGludWUg ZG9pbmcgc28gaW4gdGhlIGZ1dHVyZS4gDQogICAgICBBIGxvdCBvZiBmYWN0b3JzLCBzdWNoIGFz IGxvbmcgcm91bmQtdHJpcC10aW1lIChSVFQpLCBsb3cgcm9idXN0bmVzcyBvZiBkZWxpdmVyeSwg YW5kIHRyYW5zcG9ydCBib3R0bGVuZWNrcywgZXRjLiwgbGVhZCB0byBsb3cgdXBsb2FkIHJhdGUs IHdoaWNoIGNhdXNlIHBvb3IgdXNlciBleHBlcmllbmNlcy4NCiAgICAgIEkgaGF2ZSBwcm9wb3Nl ZCBhbiBhcHByb2FjaCB0byB1cGxvYWQgYWNjZWxlcmF0aW9uIHRyYW5zcG9ydCBuZXR3b3JrIGZv ciB1cHN0cmVhbSB0cmFmZmljcywgYW5kIHRoZSBkcmFmdHMgd2FzIHN1Ym1pdHRlZC4gDQogICAg ICBUaGlzIGlzIHRoZSBsaW5rLCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXFpbi10c3Z3Zy11YXRudXQvIA0KICAgICBBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCiAg IFJlZ2FyZHMsDQoNCiAgIFhpYW93ZWkgUWluDQoNCg0KDQoNCg== ------=_001_NextPart507535120425_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable
Dear all=A3=AC
     <= /span>
      As mobile phones and other smart devices are proliferating, more an= d more end users like directly uploading and sharing their photos, videos = or other documents by data centers. 
=       Besides, mobile devices emerging are fully cloud-depe= ndent that are not equipped with much storage but rely on large storage in= data centers. 
      = For these reasons, a large number of Online Storage Service Pr= oviders(OSSPs),Photos Sharing Service Providers (PSSPs), and Videos Sharin= g Service Providers (VSSPs) emerge at a historic moment so that make upstr= eam traffics rapidly increasing and expected to continue doing so in the f= uture. 
      A lot of factors, = such as long round-trip-time (RTT), low robustness of delivery, and transp= ort bottlenecks, etc., lead to low upload rate, which cause poor user expe= riences.
      I have proposed an app= roach to upload acceleration transport n= etwork for upstream traffics, and the drafts was submitte= d. 
     Any comments are welcome.

   Regards,

   Xiaowei Qin




------=_001_NextPart507535120425_=------ From nobody Mon Jun 8 18:39:59 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA131A0174 for ; Mon, 8 Jun 2015 18:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6KKwULmoG64 for ; Mon, 8 Jun 2015 18:39:57 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EB991A014E for ; Mon, 8 Jun 2015 18:39:57 -0700 (PDT) Received: by qkx62 with SMTP id 62so2272981qkx.3 for ; Mon, 08 Jun 2015 18:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DkBc1IO4oaGUt77xCTM22IzV7kl2je4zy5DJZQoPFXo=; b=FI+tCawOMeFK1mCLEXzPcyEiFCIaUEO1E5hvJ7BrrmM0nNJafdFBZbqQM2X5kO8KCH bn9wDMnELTWHTuS8ADDqqrVkbaDuALV/NndufzpWGXSUDauF9k/7kXMGW3Khsgd3hQDV S9GHiCX+ihxfeH4pNvUTGkiaGgzfyetQ8rcDikHuvZkxrcfiQT77zcuU+TXbm7RRrsXk CpvYVPPYPx94Ot6EBkB6rccE5hKudQy6YDfQYiyqEjXLClxdl5RuAwIKimqFrR4+jz2y C5OrbLXCfAYgZwSuSzm0lna5MNtcVt6t4dl98788X3mVE1i4GEjmwC1/RVnIR2rQbTVo +ISQ== X-Received: by 10.55.41.166 with SMTP id p38mr36460745qkp.93.1433813996897; Mon, 08 Jun 2015 18:39:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.61.70 with HTTP; Mon, 8 Jun 2015 18:39:16 -0700 (PDT) In-Reply-To: References: From: Vivek Parmar Date: Tue, 9 Jun 2015 07:09:16 +0530 Message-ID: To: Nick Matavka Content-Type: multipart/alternative; boundary=001a114966a0f58ccc05180bd56a Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Formal request for shepherding X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 01:39:59 -0000 --001a114966a0f58ccc05180bd56a Content-Type: text/plain; charset=UTF-8 Hi Nick, Well i am not sure though, but i shall be like to be a part of the initiative you are leading here. Thanks, BR, P, Vivek On Mon, Jun 8, 2015 at 4:35 PM, Nick Matavka < n.theodore.matavka.files@gmail.com> wrote: > Hello, world! > > I think my GopherII internet-draft is coming along nicely, Masinter's > perfectly reasonable objections not withstanding. That said, I know that > IETF process requires a mentor or "shepherd" to get to the next stage. > Therefore, this is my formal request for an experienced hand to take on > this role. > > While I understand that John Klensin is unavailable to take this on for > reasons of time and other commitments, the Danish fellow (I think his name > is Gulbrandsson) put himself forward for the role, at least that's the way > I read his private e-mail. > > Is anyone else putting their hat in the ring? > > xx Nick > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --001a114966a0f58ccc05180bd56a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Nick,

Well i am not sure though, but= i shall be like to be a part of the initiative you are leading here.
=

Thanks,
BR,
P, Vivek

On Mon, Jun 8, 2015 = at 4:35 PM, Nick Matavka <n.theodore.matavka.files@gmail.= com> wrote:
Hello, world!

I think my GopherII internet-= draft is coming along nicely, Masinter's perfectly reasonable objection= s not withstanding.=C2=A0 That said, I know that IETF process requires a me= ntor or "shepherd" to get to the next stage.=C2=A0 Therefore, thi= s is my formal request for an experienced hand to take on this role.
<= div>
While I understand that John Klensin is unavailable to t= ake this on for reasons of time and other commitments, the Danish fellow (I= think his name is Gulbrandsson) put himself forward for the role, at least= that's the way I read his private e-mail.

Is = anyone else putting their hat in the ring?

xx Nick=

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


--001a114966a0f58ccc05180bd56a-- From nobody Mon Jun 8 19:52:55 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA891A8952 for ; Mon, 8 Jun 2015 19:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nozP_IXCtTtB for ; Mon, 8 Jun 2015 19:52:51 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 624AD1A036A for ; Mon, 8 Jun 2015 19:52:50 -0700 (PDT) Received: from CNNIC-PC (unknown [218.241.119.104]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0AZIIT3VHZVBK9oBw--.3525S2; Tue, 09 Jun 2015 10:52:39 +0800 (CST) Date: Tue, 9 Jun 2015 10:52:33 +0800 From: "qinxiaowei@cnnic.cn" To: "Arnt Gulbrandsen" , apps-discuss References: <2015060810270811245415@cnnic.cn>, <5c9e933b-396f-4e49-a09d-f607459fb613@gulbrandsen.priv.no> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <2015060910523122319771@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart621141801171_=----" X-CM-TRANSID: AQAAf0AZIIT3VHZVBK9oBw--.3525S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Zry3XFWrtry3ZryDGr43Awb_yoW8AryUpF y8Kwn3GF18Jw1fKw1kZ3s7Xay8uFyru3y7Zr15AFnrCrZ8WrnxKr18Zw4F934UWr4fXFWY vF4q9FZ8J3W7ZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUHlb7Iv0xC_KF4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40En4AK xVAvwIkv4cxYr24l5I8CrVCF0I0E4I0vr24l5I8CrVC2j2CEjI02ccxYII8I67AEr4CY67 k08wAqx4xG6I8I3I0E8cIF7480aVAKz4kxMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E 87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0V AYjxAxZF0Ew4CEw7xC0wCjr7xvwVCIw2I0I7xG6c02F41lc2xSY4AK67AK6r4UMxAIw28I cxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2 IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI 42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42 IY6xAIw20EY4v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2 z280aVCY1x0267AKxVWUJVW8JwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07 jzdgAUUUUU= X-CM-SenderInfo: xtlq5x5drzvxw6fq0xffof0/ Archived-At: Subject: Re: [apps-discuss] An Upload Acceleration Transport Network for Upstream Traffic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 02:52:53 -0000 This is a multi-part message in MIME format. ------=_001_NextPart621141801171_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEFybnQNClRoYW5rcyBmb3IgdGhlIHJldmlldw0KDQpJbiB5b3VyIGxldHRlcu+8mg0KUmVh bGx5PyBJZiB0aGF0IGlzIHRydWUsIHRoZW4gdGhlIHNhbWUgcHJvYmxlbSB3aWxsIGFsc28gYWZm ZWN0IG5vbi1tb2JpbGUNCnVzZXJzLiBCdXQgSSBoYXZlIGFjY2VzcyB0byBsb2dzIHRoYXQgc2hv dyBjb25zaWRlcmFibHkgaGlnaGVyIHR5cGljYWwNCnNwZWVkcy4NCg0KSSBoYXZlIGRvIHRlc3Qg b25seSBmb3IgbW9iaWxlIGRldmljZXMsIGFuZCB0aGUgdGhlIHJlcG9ydCBjb21lcyBmcm9tOiBo dHRwOi8vdGVzdG15aXBob25lLmNvbS9zdGF0cy4NCklmIHlvdSBoYXZlIHN0YXRpc3RpY3MgZm9y IFBDIG9yIHZpYSBXaUZpLCBjb3VsZCB5b3Ugc2hhcmUgaXQ/IFRoYW5rIHlvdSB2ZXJ5IG11Y2gu DQoNClRoaXMgaXMgdGhlIGxhdGVzdCBzdGF0czoNCkRvd25sb2FkOg0KRG93bmxvYWQgdGVzdHMg dGFrZW4gMywxNDAsMjU3IA0KQXZlcmFnZSBzcGVlZCAzNTg1LjQ0IGticHMNClVwbG9hZDoNClVw bG9hZCB0ZXN0cyB0YWtlbiA3MDgsMTU4DQpBdmVyYWdlIHNwZWVkIDYzMC41NiBrYnBzDQpUaGUg YXN5bW1ldHJpYyBjYXBhY2l0eSBvZiBwaHlzaWNhbCBsaW5rcyBzdWNoIGFzIGluIEFEU0wgbWF5 IGJlIGFsc28gYW4gZmFjdG9yLCBidXQgbWFueSBDb250ZW50IFNlcnZpY2UgUHJvdmlkZXJzIChD U1BzKSBoYXZlIGRlcGxveWVkIHRoZWlyIG93biBDRE5zIG9yIGhhdmUgbWFkZSBhIGJ1c2luZXNz IGFncmVlbWVudCB3aXRoIENETiBwcm92aWRlcnMgLHN1Y2ggYXMgQWthbWFpLCB0byBtb3ZlIHRo ZSBjb250ZW50IGNsb3NlciB0byBlbmQgdXNlcnMgZm9yIGhpZ2ggZG93bmxvYWQgdGhyb3VnaHB1 dC4NCkluIG9yZGVyIHRvIHZhbGlkYXRlIHRoZSBhbmFseXNpcyBkZXNjcmliZWQgYWJvdmUsIEkg aGF2ZSBhbHNvIHRha2UgYSBwcmFjdGljYWwgbWVhc3VyZW1lbnQgaW4gQ2hpbmEgTW9iaWxlIExh YnMgKGxvY2F0ZWQgaW4gQmVpamluZykgd2hpY2ggaXMgdGhlIGRlcGFydG1lbnQgb2YgdGhlIENo aW5hIE1vYmlsZSBMaW1pdGVkLiBBIGRhdGEgc2VydmVyIGRlcGxveWVkIGluIFNoZW56aGVuLCBz aXR1YXRlZCBpbW1lZGlhdGVseSBub3J0aCBvZiBIb25nIEtvbmcgKGFib3V0IDI1MDAga2lsb21l dGVycyBhd2F5IGZyb20gQmVpamluZykgaXMgdXNlZCB0byBjb250aW51b3VzbHkgd2FpdCBmb3Ig cGFja2V0cyBmcm9tIG1vYmlsZSBkZXZpY2VzLiANClRoZSBtb2JpbGUgZGV2aWNlcyBpcyBjb25u ZWN0ZWQgdG8gSW50ZXJuZXQgdmlhIFRELUxURSwgYW5kIGNvbnRlbnQgZ2VuZXJhdGVkIGJ5IG1v YmlsZSBkZXZpY2VzIGlzIGRpcmVjdGx5IHVwbG9hZGVkIHRvIHRoZSByZWNlaXZlciB3aXRob3V0 IGFueSBhY2NlbGVyYXRpb24gcHJvY2Vzc2luZy4gVGhlIGF2ZXJhZ2UgdXBzdHJlYW0gdGhyb3Vn aHB1dCBpcyBhYm91dCAxODAga2Jwcy4gDQpJIGFsc28gZGVwbG95IGEgZGF0YSBzZXJ2ZXIgaW4g QmVpamluZywgIHRoZSBhdmVyYWdlIHVwc3RyZWFtIHRocm91Z2hwdXQgY2FuIGJlIHVwIHRvIDg2 MCBNYnBzLiANClRoZXJlZm9yZSwgIm1vdmluZyBjb250ZW50IGNsb3NlciB0byBlbmQgdXNlcnMg cmVzdWx0cyBpbiBncmVhdGVyIG5ldHdvcmsgZWZmaWNpZW5jeSwgaW5jcmVhc2VkIHJvYnVzdG5l c3Mgb2YgZGVsaXZlcnksIGFuZCBsb3dlciBsYXRlbmN5IiBpbiBbcmZjNjcwN10sW3JmYzY3NzBd LFtyZmM2MzkyXS4NCklNTywgbW92aW5nIHRoZSAiZGF0YSBjZW50ZXIiIGNsb3NlciB0byBlbmQg dXNlcnMgbWF5IGFsc28gcHJvdmlkZSBudW1lcm91cyBiZW5lZml0cyBmb3IgdXBsb2FkaW5nIHNl cnZpY2U6IHJlZHVjZWQgZGVsaXZlcnkgY29zdCwgaW1wcm92ZWQgcXVhbGl0eSBvZiBleHBlcmll bmNlIGZvciBFbmQgVXNlcnMsIGFuZCBpbmNyZWFzZWQgcm9idXN0bmVzcyBvZiBkZWxpdmVyeS4N Cg0KDQoNCg0KDQogDQpGcm9tOiBBcm50IEd1bGJyYW5kc2VuDQpEYXRlOiAyMDE1LTA2LTA4IDE3 OjIyDQpUbzogYXBwcy1kaXNjdXNzDQpTdWJqZWN0OiBSZTogW2FwcHMtZGlzY3Vzc10gQW4gVXBs b2FkIEFjY2VsZXJhdGlvbiBUcmFuc3BvcnQgTmV0d29yayBmb3IgVXBzdHJlYW0gVHJhZmZpYw0K SGksDQogDQppbiB0aGUgZHJhZnQgeW91IHdyaXRlIHRoYXQNCiANCiAgIEFjY29yZGluZyB0byB0 aGUgcmVwb3J0IGluIFsxXSwgdGhyb3VnaHB1dCBtZWFzdXJlbWVudHMNCiAgIGZyb20gb3ZlciAx LjUgbWlsbGlvbiBtb2JpbGUgZGV2aWNlcyBoYXZlIHNob3duIHRoYXQgY29tcGFyZWQgd2l0aCBh bg0KICAgYXZlcmFnZSBkb3duc3RyZWFtIHRocm91Z2hwdXQgb2Ygb3ZlciAxODYwIEticHMsIHRo ZSBhdmVyYWdlIHVwc3RyZWFtDQogICB0aHJvdWdocHV0IGlzIG9ubHkgYWJvdXQgNDMwIEticHMu ICBUaGlzIGlzIGJlY2F1c2Ugb2YgdGhlIGFkb3B0aW9uDQogICBvZiBjYWNoZSB0ZWNobmlxdWVz IHN1Y2ggYXMgQ0ROcyB0byBhY2VsZXJhdGUgZG93bmxvYWRpbmcgbGFyZ2UNCiAgIGNvbnRlbnQg dGhhdCBtb3ZlcyB0aGUgImNvbnRlbnQiIGNsb3NlciB0byBlbmQgdXNlcnMuDQogDQpSZWFsbHk/ IElmIHRoYXQgaXMgdHJ1ZSwgdGhlbiB0aGUgc2FtZSBwcm9ibGVtIHdpbGwgYWxzbyBhZmZlY3Qg bm9uLW1vYmlsZSANCnVzZXJzLiBCdXQgSSBoYXZlIGFjY2VzcyB0byBsb2dzIHRoYXQgc2hvdyBj b25zaWRlcmFibHkgaGlnaGVyIHR5cGljYWwgDQpzcGVlZHMuDQogDQpJIHRoaW5rIHRoYXQgYmVm b3JlIHRoaXMgY2FuIHByb2dyZXNzLCB5b3UgaGF2ZSB0byBzaG93IHRoYXQgdGhlIHByb2JsZW0g DQpyZWFsbHkgaXMgYSBsYWNrIG9mIHRoaW5ncyBsaWtlIENETnMgZm9yIHVwbG9hZC4NCiANCkFy bnQNCiANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQph cHBzLWRpc2N1c3MgbWFpbGluZyBsaXN0DQphcHBzLWRpc2N1c3NAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzDQo= ------=_001_NextPart621141801171_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A
Hi, Arn= t
Thanks for the review

In your letter=EF=BC=9A=
Really? If that is true, then the same problem will also a= ffect non-mobile
users. But I have access to logs that show cons= iderably higher typical
speeds.

<= span style=3D"background-color: rgba(0, 0, 0, 0);">I have do test only for= mobile devices, and the the report comes from: http://testmyiphone.com/stats.
If you have stati= stics for PC or via WiFi, could you share it? Thank you very much.<= /div>

This is the&= nbsp;latest&nbs= p;stats:
Download:
Download tests taken 3,140,257 
Average speed 35= 85.44 kbps
Upload:
Upload tests taken 708,158
Average speed 630.56 kbps
The asymmetric= capacity of physical links such as in ADSL may be also an factor, but man= y Content Service Providers (CSPs) have deployed their own CDNs or have ma= de a business agreement with CDN providers ,such as Akamai, to move the co= ntent closer to end users for high download throughput.
<= span style=3D"background-color: rgba(0, 0, 0, 0); font-size: 10.5pt; line-= height: 1.5;">In order to validate the analysis described above, I have al= so take a practical measurement in China Mobile Labs (located in Beijing) = which is the department of the China Mobile Limited. A data server deploye= d in Shenzhen, situated immediately north of Hong Kong (about 2500 kilomet= ers away from Beijing) is used to continuously wait for packets from mobil= e devices. 
The mobile devices is connected to Internet via TD-LTE, and&nb= sp;content generated by mobile devices is directly uploaded to= the receiver without any acceleration processing. The average upstream throughput is about 180 kbps. 
<= div>I also deploy a data server in Beijing,  the ave= rage upstream throughput can be up to 860 Mbps. 
oving content closer to end user= s results in greater network efficiency, increased robust= ness of delivery, and lower latency" in [rfc6707],[rfc6770],[rfc6392].
IMO, moving the "data center" closer to end users may also&n= bsp;provide numerous benefits for uploading service: reduce= d delivery cost, improved quality of experience for End Users, and increas= ed robustness of delivery.



=0A
=0A
 
Da= te: 2015-06-08 17:22
Subject:&nbs= p;Re: [apps-discuss] An Upload Acceleration Transport Network for Upstream= Traffic
Hi,
=0A
 
=0A
i= n the draft you write that
=0A
 
=0A
   A= ccording to the report in [1], throughput measurements
=0A
 =   from over 1.5 million mobile devices have shown that compared with = an
=0A
   average downstream throughput of over 1860 Kb= ps, the average upstream
=0A
   throughput is only abou= t 430 Kbps.  This is because of the adoption
=0A
  = ; of cache techniques such as CDNs to acelerate downloading large
=0A=
   content that moves the "content" closer to end users.=0A
 
=0A
Really? If that is true, then the same prob= lem will also affect non-mobile
=0A
users. But I have access to = logs that show considerably higher typical
=0A
speeds.
=0A<= div> 
=0A
I think that before this can progress, you have to= show that the problem
=0A
really is a lack of things like CDNs = for upload.
=0A
 
=0A
Arnt
=0A
 =0A
_______________________________________________
=0A
apps= -discuss mailing list
=0A
apps-discuss@ietf.org
=0A
http= s://www.ietf.org/mailman/listinfo/apps-discuss
=0A
= =0A ------=_001_NextPart621141801171_=------ From nobody Mon Jun 8 20:01:42 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E9F1A1E0F for ; Mon, 8 Jun 2015 20:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n08cVIu-pxyn for ; Mon, 8 Jun 2015 20:01:37 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEFE1A1B78 for ; Mon, 8 Jun 2015 20:01:36 -0700 (PDT) Received: from CNNIC-PC (unknown [218.241.119.104]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0AJEZUJV3ZVprBoBw--.3493S2; Tue, 09 Jun 2015 11:01:29 +0800 (CST) Date: Tue, 9 Jun 2015 11:01:23 +0800 From: "qinxiaowei@cnnic.cn" To: "Arnt Gulbrandsen" , apps-discuss References: <2015060810270811245415@cnnic.cn>, <5c9e933b-396f-4e49-a09d-f607459fb613@gulbrandsen.priv.no>, <2015060910523122319771@cnnic.cn> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <2015060911012384032676@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart042762086635_=----" X-CM-TRANSID: AQAAf0AJEZUJV3ZVprBoBw--.3493S2 X-Coremail-Antispam: 1UD129KBjvJXoW7ury8Cr4DXF15KFWUWryfJFb_yoW8Zw4Dpa 48Wwn3Gr18Jw1fKw1vvws5Xay09Fyruay2y345AFnrCrZ8WrnxKr18Zw4F934UWr1fXFWY qF4q9a98J3W7ZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUdCb7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26F4UJVW0owA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG62kE wI0EY4vaYxAvb48xMc02F40E42I26xC2a48xMc02F40Ex7xS67I2xxkvbII20VAFz48EcV AYj21l5I8CrVC20s02628v4x8GjsIEw4AK0wAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2 z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2 IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2IqxwCjr7xvwVCIw2I0I7xG6c02F41l c2xSY4AK67AK6r48MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I 0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWU XVWUAwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcV CY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280 aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JwCE64xvF2IEb7IF0Fy7Yx BIdaVFxhVjvjDU0xZFpf9x07j4iiDUUUUU= X-CM-SenderInfo: xtlq5x5drzvxw6fq0xffof0/ Archived-At: Subject: Re: [apps-discuss] An Upload Acceleration Transport Network for Upstream Traffic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 03:01:39 -0000 This is a multi-part message in MIME format. ------=_001_NextPart042762086635_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 aSBhbSBzb3JyeQ0KdGhlcmUgaXMgYW4gbWlzdGFrZSBpbiAiSSBhbHNvIGRlcGxveSBhIGRhdGEg c2VydmVyIGluIEJlaWppbmcsICB0aGUgYXZlcmFnZSB1cHN0cmVhbSB0aHJvdWdocHV0IGNhbiBi ZSB1cCB0byA4NjAgTWJwc+KAnC4NClRoYXQgaXMgODYwIGticHMuDQoNCg0KDQoNCg0KIA0KRnJv bTogcWlueGlhb3dlaUBjbm5pYy5jbg0KRGF0ZTogMjAxNS0wNi0wOSAxMDo1Mg0KVG86IEFybnQg R3VsYnJhbmRzZW47IGFwcHMtZGlzY3Vzcw0KU3ViamVjdDogUmU6IFJlOiBbYXBwcy1kaXNjdXNz XSBBbiBVcGxvYWQgQWNjZWxlcmF0aW9uIFRyYW5zcG9ydCBOZXR3b3JrIGZvciBVcHN0cmVhbSBU cmFmZmljDQpIaSwgQXJudA0KVGhhbmtzIGZvciB0aGUgcmV2aWV3DQoNCkluIHlvdXIgbGV0dGVy 77yaDQpSZWFsbHk/IElmIHRoYXQgaXMgdHJ1ZSwgdGhlbiB0aGUgc2FtZSBwcm9ibGVtIHdpbGwg YWxzbyBhZmZlY3Qgbm9uLW1vYmlsZQ0KdXNlcnMuIEJ1dCBJIGhhdmUgYWNjZXNzIHRvIGxvZ3Mg dGhhdCBzaG93IGNvbnNpZGVyYWJseSBoaWdoZXIgdHlwaWNhbA0Kc3BlZWRzLg0KDQpJIGhhdmUg ZG8gdGVzdCBvbmx5IGZvciBtb2JpbGUgZGV2aWNlcywgYW5kIHRoZSB0aGUgcmVwb3J0IGNvbWVz IGZyb206IGh0dHA6Ly90ZXN0bXlpcGhvbmUuY29tL3N0YXRzLg0KSWYgeW91IGhhdmUgc3RhdGlz dGljcyBmb3IgUEMgb3IgdmlhIFdpRmksIGNvdWxkIHlvdSBzaGFyZSBpdD8gVGhhbmsgeW91IHZl cnkgbXVjaC4NCg0KVGhpcyBpcyB0aGUgbGF0ZXN0IHN0YXRzOg0KRG93bmxvYWQ6DQpEb3dubG9h ZCB0ZXN0cyB0YWtlbiAzLDE0MCwyNTcgDQpBdmVyYWdlIHNwZWVkIDM1ODUuNDQga2Jwcw0KVXBs b2FkOg0KVXBsb2FkIHRlc3RzIHRha2VuIDcwOCwxNTgNCkF2ZXJhZ2Ugc3BlZWQgNjMwLjU2IGti cHMNClRoZSBhc3ltbWV0cmljIGNhcGFjaXR5IG9mIHBoeXNpY2FsIGxpbmtzIHN1Y2ggYXMgaW4g QURTTCBtYXkgYmUgYWxzbyBhbiBmYWN0b3IsIGJ1dCBtYW55IENvbnRlbnQgU2VydmljZSBQcm92 aWRlcnMgKENTUHMpIGhhdmUgZGVwbG95ZWQgdGhlaXIgb3duIENETnMgb3IgaGF2ZSBtYWRlIGEg YnVzaW5lc3MgYWdyZWVtZW50IHdpdGggQ0ROIHByb3ZpZGVycyAsc3VjaCBhcyBBa2FtYWksIHRv IG1vdmUgdGhlIGNvbnRlbnQgY2xvc2VyIHRvIGVuZCB1c2VycyBmb3IgaGlnaCBkb3dubG9hZCB0 aHJvdWdocHV0Lg0KSW4gb3JkZXIgdG8gdmFsaWRhdGUgdGhlIGFuYWx5c2lzIGRlc2NyaWJlZCBh Ym92ZSwgSSBoYXZlIGFsc28gdGFrZSBhIHByYWN0aWNhbCBtZWFzdXJlbWVudCBpbiBDaGluYSBN b2JpbGUgTGFicyAobG9jYXRlZCBpbiBCZWlqaW5nKSB3aGljaCBpcyB0aGUgZGVwYXJ0bWVudCBv ZiB0aGUgQ2hpbmEgTW9iaWxlIExpbWl0ZWQuIEEgZGF0YSBzZXJ2ZXIgZGVwbG95ZWQgaW4gU2hl bnpoZW4sIHNpdHVhdGVkIGltbWVkaWF0ZWx5IG5vcnRoIG9mIEhvbmcgS29uZyAoYWJvdXQgMjUw MCBraWxvbWV0ZXJzIGF3YXkgZnJvbSBCZWlqaW5nKSBpcyB1c2VkIHRvIGNvbnRpbnVvdXNseSB3 YWl0IGZvciBwYWNrZXRzIGZyb20gbW9iaWxlIGRldmljZXMuIA0KVGhlIG1vYmlsZSBkZXZpY2Vz IGlzIGNvbm5lY3RlZCB0byBJbnRlcm5ldCB2aWEgVEQtTFRFLCBhbmQgY29udGVudCBnZW5lcmF0 ZWQgYnkgbW9iaWxlIGRldmljZXMgaXMgZGlyZWN0bHkgdXBsb2FkZWQgdG8gdGhlIHJlY2VpdmVy IHdpdGhvdXQgYW55IGFjY2VsZXJhdGlvbiBwcm9jZXNzaW5nLiBUaGUgYXZlcmFnZSB1cHN0cmVh bSB0aHJvdWdocHV0IGlzIGFib3V0IDE4MCBrYnBzLiANCkkgYWxzbyBkZXBsb3kgYSBkYXRhIHNl cnZlciBpbiBCZWlqaW5nLCAgdGhlIGF2ZXJhZ2UgdXBzdHJlYW0gdGhyb3VnaHB1dCBjYW4gYmUg dXAgdG8gODYwIE1icHMuIA0KVGhlcmVmb3JlLCAibW92aW5nIGNvbnRlbnQgY2xvc2VyIHRvIGVu ZCB1c2VycyByZXN1bHRzIGluIGdyZWF0ZXIgbmV0d29yayBlZmZpY2llbmN5LCBpbmNyZWFzZWQg cm9idXN0bmVzcyBvZiBkZWxpdmVyeSwgYW5kIGxvd2VyIGxhdGVuY3kiIGluIFtyZmM2NzA3XSxb cmZjNjc3MF0sW3JmYzYzOTJdLg0KSU1PLCBtb3ZpbmcgdGhlICJkYXRhIGNlbnRlciIgY2xvc2Vy IHRvIGVuZCB1c2VycyBtYXkgYWxzbyBwcm92aWRlIG51bWVyb3VzIGJlbmVmaXRzIGZvciB1cGxv YWRpbmcgc2VydmljZTogcmVkdWNlZCBkZWxpdmVyeSBjb3N0LCBpbXByb3ZlZCBxdWFsaXR5IG9m IGV4cGVyaWVuY2UgZm9yIEVuZCBVc2VycywgYW5kIGluY3JlYXNlZCByb2J1c3RuZXNzIG9mIGRl bGl2ZXJ5Lg0KDQoNCg0KDQoNCiANCkZyb206IEFybnQgR3VsYnJhbmRzZW4NCkRhdGU6IDIwMTUt MDYtMDggMTc6MjINClRvOiBhcHBzLWRpc2N1c3MNClN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNz XSBBbiBVcGxvYWQgQWNjZWxlcmF0aW9uIFRyYW5zcG9ydCBOZXR3b3JrIGZvciBVcHN0cmVhbSBU cmFmZmljDQpIaSwNCiANCmluIHRoZSBkcmFmdCB5b3Ugd3JpdGUgdGhhdA0KIA0KICAgQWNjb3Jk aW5nIHRvIHRoZSByZXBvcnQgaW4gWzFdLCB0aHJvdWdocHV0IG1lYXN1cmVtZW50cw0KICAgZnJv bSBvdmVyIDEuNSBtaWxsaW9uIG1vYmlsZSBkZXZpY2VzIGhhdmUgc2hvd24gdGhhdCBjb21wYXJl ZCB3aXRoIGFuDQogICBhdmVyYWdlIGRvd25zdHJlYW0gdGhyb3VnaHB1dCBvZiBvdmVyIDE4NjAg S2JwcywgdGhlIGF2ZXJhZ2UgdXBzdHJlYW0NCiAgIHRocm91Z2hwdXQgaXMgb25seSBhYm91dCA0 MzAgS2Jwcy4gIFRoaXMgaXMgYmVjYXVzZSBvZiB0aGUgYWRvcHRpb24NCiAgIG9mIGNhY2hlIHRl Y2huaXF1ZXMgc3VjaCBhcyBDRE5zIHRvIGFjZWxlcmF0ZSBkb3dubG9hZGluZyBsYXJnZQ0KICAg Y29udGVudCB0aGF0IG1vdmVzIHRoZSAiY29udGVudCIgY2xvc2VyIHRvIGVuZCB1c2Vycy4NCiAN ClJlYWxseT8gSWYgdGhhdCBpcyB0cnVlLCB0aGVuIHRoZSBzYW1lIHByb2JsZW0gd2lsbCBhbHNv IGFmZmVjdCBub24tbW9iaWxlIA0KdXNlcnMuIEJ1dCBJIGhhdmUgYWNjZXNzIHRvIGxvZ3MgdGhh dCBzaG93IGNvbnNpZGVyYWJseSBoaWdoZXIgdHlwaWNhbCANCnNwZWVkcy4NCiANCkkgdGhpbmsg dGhhdCBiZWZvcmUgdGhpcyBjYW4gcHJvZ3Jlc3MsIHlvdSBoYXZlIHRvIHNob3cgdGhhdCB0aGUg cHJvYmxlbSANCnJlYWxseSBpcyBhIGxhY2sgb2YgdGhpbmdzIGxpa2UgQ0ROcyBmb3IgdXBsb2Fk Lg0KIA0KQXJudA0KIA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCmFwcHMtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCmFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCg== ------=_001_NextPart042762086635_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
= i am sorry
there is an mistake in "= I also deploy a data server in Beijing,  the average upst= ream throughput can be up to 860 Mbps=E2=80=9C.
That is 860 kbps.


=0A

=0A<= div>
=0A
 
<= div>From: qinxiaowei@cn= nic.cn
Date: 2015-06-09 10:52
<= b>Subject: Re: Re: [apps-discuss] An Upload Acceleration Transpor= t Network for Upstream Traffic
=0A
Hi, Arnt
Thanks for the review

In your letter=EF=BC=9A
Really? If that is true, then the same problem will also affect non-= mobile
users. But I have access to logs that show considerably h= igher typical
speeds.

I have do test only for mobile de= vices, and the the report comes from: http://testmyiphone.com/stats.
If you have statistics for = PC or via WiFi, could you share it? Thank you very much.
=
This is the latest <= span style=3D"font-size: 10.5pt; line-height: 1.5; background-color: rgba(= 0, 0, 0, 0);">stats:
Download:
Download tests taken 3,140,257 
Average speed 3585.44 kbps=
Upload:
Upload tests taken 708,158
Averag= e speed 630.56 kbps
The asymmetric capacit= y of physical links such as in ADSL may be also an factor, but many Conten= t Service Providers (CSPs) have deployed their own CDNs or have made a bus= iness agreement with CDN providers ,such as Akamai, to move the content cl= oser to end users for high download throughput.
In order to validate the analysis described above, I have also take = a practical measurement in China Mobile Labs (located in Beijing) which is= the department of the China Mobile Limited. A data server deployed in She= nzhen, situated immediately north of Hong Kong (about 2500 kilometers away= from Beijing) is used to continuously wait for packets from mobile device= s. 
The mobile devices is connected to Internet via TD-LTE, and content generated by mobile devices is directly uploaded to the rec= eiver without any acceleration processing. The = average upstream throughput is about 180 kbps. 
I also deploy a data server in Beijing,  the average ups= tream throughput can be up to 860 Mbps. 
Theref= ore, "moving content closer to end users result= s in greater network efficiency, increased robustness of = delivery, and lower latency" in [rfc6707],[rfc6770],[rfc6392].
IMO, moving the "data center" closer to end users may also provide numerous benefits for uploading service: reduced delive= ry cost, improved quality of experience for End Users, and increased robus= tness of delivery.


=0A
=0A
=  
Date:&= nbsp;2015-06-08 17:22
Subject: Re: [a= pps-discuss] An Upload Acceleration Transport Network for Upstream Traffic=
Hi,
=0A
 
=0A
in the dr= aft you write that
=0A
 
=0A
   According= to the report in [1], throughput measurements
=0A
   f= rom over 1.5 million mobile devices have shown that compared with an
= =0A
   average downstream throughput of over 1860 Kbps, the = average upstream
=0A
   throughput is only about 430 Kb= ps.  This is because of the adoption
=0A
   of cac= he techniques such as CDNs to acelerate downloading large
=0A
&nb= sp;  content that moves the "content" closer to end users.
=0A 
=0A
Really? If that is true, then the same problem will= also affect non-mobile
=0A
users. But I have access to logs tha= t show considerably higher typical
=0A
speeds.
=0A
&nbs= p;
=0A
I think that before this can progress, you have to show th= at the problem
=0A
really is a lack of things like CDNs for uplo= ad.
=0A
 
=0A
Arnt
=0A
 
=0A_______________________________________________
=0A
apps-discuss= mailing list
=0A
apps-discuss@ietf.org
=0A
https://www.= ietf.org/mailman/listinfo/apps-discuss
=0A
=0A
=0A ------=_001_NextPart042762086635_=------ From nobody Mon Jun 8 20:14:14 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707A31ACDC3 for ; Mon, 8 Jun 2015 20:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7ZCXkn0Pojz for ; Mon, 8 Jun 2015 20:14:10 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 339171ACDD4 for ; Mon, 8 Jun 2015 20:14:08 -0700 (PDT) Received: from CNNIC-PC (unknown [218.241.119.104]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0CJtnH2WXZVsrJoBw--.18013S2; Tue, 09 Jun 2015 11:13:58 +0800 (CST) Date: Tue, 9 Jun 2015 11:13:52 +0800 From: "qinxiaowei@cnnic.cn" To: "joel jaeggli" , apps-discuss References: <2015060810270811245415@cnnic.cn>, <5575B68C.4070305@bogus.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <2015060911135217305686@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart076658685035_=----" X-CM-TRANSID: AQAAf0CJtnH2WXZVsrJoBw--.18013S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWr15AFy3Cr1UKF1rXFWDJwb_yoWrGw4fpF W3trnrKrykAr1fK34DZw48Way8Zw1rZ3yYkFy5trWfCrZ8ur1Fgr47t3yFgFyUCr93WFyY yrWj9345Aw4DZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUlEb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26F4UJVW0owA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG62kE wI0EY4vaYxAvb48xMc02F40E42I26xC2a48xMc02F40Ex7xS67I2xxkvbII20VAFz48EcV AYj21l5I8CrVC20s02628v4x8GjsIEw4AK0wAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2 z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2 IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2IqxwCjr7xvwVCIw2I0I7xG6c02F41l c2xSY4AK67AK6r48MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMxCIbc kI1I0E14v26r1Y6r17MI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_ JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r 1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_ Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJV W8JwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07bzTmDUUUUU= X-CM-SenderInfo: xtlq5x5drzvxw6fq0xffof0/ Archived-At: Subject: Re: [apps-discuss] An Upload Acceleration Transport Network for Upstream Traffic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 03:14:13 -0000 This is a multi-part message in MIME format. ------=_001_NextPart076658685035_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksIGpvZWwNClRoYW5rcyBmb3IgeW91IHJldmlldy4NCg0KPiBIU0RQQS9IU1VQQS9MVEUgbmV0 d29ya3MgZW1wbG95IGFzeW1tZXRyeSBpbiBkYXRhLXJhdGVzIGJldHdlZW4gdGhlDQo+IHRvd2Vy IGFuZCB0aGUgaGFuZHNldCwgYW5kIHRoZSBoYW5kc2V0IGFuZCB0aGUgdG93ZXI7IHNvIHlvdXIg Zmlyc3QgYW5kDQo+IG1vc3QgZGlyZWN0IHNvdXJjZSBvZiBhc3ltbWV0cnkgaXMgcmlnaHQgYXQg cmFkaW8gYWNjZXNzLXNpZGUgb2YgdGhpbmdzLg0KPiBUaGUgb25seSBwYXJhbWV0ZXIgdGhhdCBk aXN0YW5jZSBjaGFuZ2VzIGRpcmVjdGx5IGlzIGJhbmR3aXRoIGRlbGF5LXByb2R1Y3QuIA0KPiBp ZiB0aGUgY2FycmllcidzIG5ldHdvcmsgaXMgY29uZ2VzdGVkIGl0J3MgY29uZ2VzdGVkIGlycmVz cGVjdGl2ZSBvZiB0aGUgZGVzdGluYXRpb24uDQo+VGhlIG9ubHkgcGFyYW1ldGVyIHRoYXQgZGlz dGFuY2UgY2hhbmdlcyBkaXJlY3RseSBpcyBiYW5kd2l0aA0KPmRlbGF5LXByb2R1Y3QuIGlmIHRo ZSBjYXJyaWVyJ3MgbmV0d29yayBpcyBjb25nZXN0ZWQgaXQncyBjb25nZXN0ZWQNCj5pcnJlc3Bl Y3RpdmUgb2YgdGhlIGRlc3RpbmF0aW9uLg0KDQpZZXMsIGkgYWdyZWUgd2l0aCB5b3UsIHRoZXJl IGV4aXN0cyBhbiBhc3ltbWV0cmljIGNhcGFjaXR5IG9mIHBoeXNpY2FsIGxpbmtzLiBUaGlzIGJl Y2F1c2UgdHJhZGl0aW9uYWwgSW50ZXJuZXQgZGF0YSBzZXJ2aWNlcyBhcmUgZnJlcXVlbnRseSB0 aGF0IGVuZCB1c2VycyBkb3dubG9hZCBjb250ZW50IGZyb20gZGF0YSBjZW50ZXJzIG9yIENvbnRl bnQgU2VydmljZSBQcm92aWRlcnMgKENTUHMpIGRpc3RyaWJ1dGUgY29udGVudCB0byB0aGVpciBl bmQgdXNlcnMsIHNvIHRyYWZmaWMgdm9sdW1lIGdlbmVyYXRlZCBieSBlbmQgdXNlcnMgYWNjb3Vu dCBmb3IgdmVyeSBzbWFsbCBwcm9wb3J0aW9uIG9mIGFsbCBJbnRlcm5ldCB0cmFmZmljcy4NCklN T++8jGVuZCB1c2VycyBjYW4gZ2V0IGhpZ2ggZGF0YSBkb3duc3RyZWFtIHJhdGUgdGhhbiB1cHN0 cmVhbSBub3Qgb25seSBiZWNhdXNlIG9mIGFzeW1tZXRyaWMgY2FwYWNpdHkgb2YgcGh5c2ljYWwg bGlua3PvvIwgYXMgd2VsbCBhcyBvZiB0aGUgYWRvcHRpb24gb2YgY2FjaGUgdGVjaG5pcXVlcyBz dWNoIGFzIENETi4NCkluIG9yZGVyIHRvIHZhbGlkYXRlIHRoZSBhbmFseXNpcyBkZXNjcmliZWQg YWJvdmUsIEkgaGF2ZSBhbHNvIHRha2UgYSBwcmFjdGljYWwgbWVhc3VyZW1lbnQgaW4gQ2hpbmEg TW9iaWxlIExhYnMgKGxvY2F0ZWQgaW4gQmVpamluZykgd2hpY2ggaXMgdGhlIGRlcGFydG1lbnQg b2YgdGhlIENoaW5hIE1vYmlsZSBMaW1pdGVkLiBBIGRhdGEgc2VydmVyIGRlcGxveWVkIGluIFNo ZW56aGVuLCBzaXR1YXRlZCBpbW1lZGlhdGVseSBub3J0aCBvZiBIb25nIEtvbmcgKGFib3V0IDI1 MDAga2lsb21ldGVycyBhd2F5IGZyb20gQmVpamluZykgaXMgdXNlZCB0byBjb250aW51b3VzbHkg d2FpdCBmb3IgcGFja2V0cyBmcm9tIG1vYmlsZSBkZXZpY2VzLiANClRoZSBtb2JpbGUgZGV2aWNl cyBpcyBjb25uZWN0ZWQgdG8gSW50ZXJuZXQgdmlhIFRELUxURSwgYW5kIGNvbnRlbnQgZ2VuZXJh dGVkIGJ5IG1vYmlsZSBkZXZpY2VzIGlzIGRpcmVjdGx5IHVwbG9hZGVkIHRvIHRoZSByZWNlaXZl ciB3aXRob3V0IGFueSBhY2NlbGVyYXRpb24gcHJvY2Vzc2luZy4gVGhlIGF2ZXJhZ2UgdXBzdHJl YW0gdGhyb3VnaHB1dCBpcyBhYm91dCAxODAga2Jwcy4gDQpJIGFsc28gZGVwbG95IGEgZGF0YSBz ZXJ2ZXIgaW4gQmVpamluZywgIHRoZSBhdmVyYWdlIHVwc3RyZWFtIHRocm91Z2hwdXQgY2FuIGJl IHVwIHRvIDg2MCBrYnBzLiANClRoaXMgYmVjYXVzZSBvZiBsb25nIHJvdW5kLXRyaXAtdGltZSAo UlRUKSBjYXVzZXMgbGFyZ2UgZGVsYXkgYW5kIGludmVyc2VseSBwcm9wb3J0aW9uYWwgVENQIHRo cm91Z2hwdXTvvIxldmVuIG92ZXIgYSByZWxhdGl2ZWx5IGxvbmcgZGlzdGFuY2UsIHRocm91Z2hw dXQgbWF5IGdvIGZyb20gbWF4aW11bSB0byBub3RoaW5nLg0KVGhlcmVmb3JlLCBDb250ZW50IFNl cnZpY2UgUHJvdmlkZXJzIChDU1BzKSBoYXZlIGRlcGxveWVkIHRoZWlyIG93biBDRE5zIG9yIGhh dmUgbWFkZSBhIGJ1c2luZXNzIGFncmVlbWVudCB3aXRoIENETiBwcm92aWRlcnMgLHN1Y2ggYXMg QWthbWFpLCB0byBtb3ZlIHRoZSBjb250ZW50IGNsb3NlciB0byBlbmQgdXNlcnMgZm9yIGhpZ2gg ZG93bmxvYWQgdGhyb3VnaHB1dC4NCg0KUmVnYXJkcw0KDQpYaWFvd2VpIFFpbg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCiANCkZyb206IGpvZWwgamFlZ2dsaQ0KRGF0ZTogMjAxNS0wNi0wOCAyMzoz Ng0KVG86IHFpbnhpYW93ZWlAY25uaWMuY247IGFwcHMtZGlzY3Vzcw0KU3ViamVjdDogUmU6IFth cHBzLWRpc2N1c3NdIEFuIFVwbG9hZCBBY2NlbGVyYXRpb24gVHJhbnNwb3J0IE5ldHdvcmsgZm9y IFVwc3RyZWFtIFRyYWZmaWMNCk9uIDYvNy8xNSA3OjI3IFBNLCBxaW54aWFvd2VpQGNubmljLmNu IHdyb3RlOg0KPiBEZWFyIGFsbO+/ve+/vQ0KPiAgICAgIA0KPiAgICAgICBBcyBtb2JpbGUgcGhv bmVzIGFuZCBvdGhlciBzbWFydCBkZXZpY2VzIGFyZSBwcm9saWZlcmF0aW5nLCBtb3JlDQo+IGFu ZCBtb3JlIGVuZCB1c2VycyBsaWtlIGRpcmVjdGx5IHVwbG9hZGluZyBhbmQgc2hhcmluZyB0aGVp ciBwaG90b3MsDQo+IHZpZGVvcyBvciBvdGhlciBkb2N1bWVudHMgYnkgZGF0YSBjZW50ZXJzLiAN Cj4gICAgICAgQmVzaWRlcywgbW9iaWxlIGRldmljZXMgZW1lcmdpbmcgYXJlIGZ1bGx5IGNsb3Vk LWRlcGVuZGVudCB0aGF0DQo+IGFyZSBub3QgZXF1aXBwZWQgd2l0aCBtdWNoIHN0b3JhZ2UgYnV0 IHJlbHkgb24gbGFyZ2Ugc3RvcmFnZSBpbiBkYXRhDQo+IGNlbnRlcnMuIA0KPiAgICAgICBGb3Ig dGhlc2UgcmVhc29ucywgYSBsYXJnZSBudW1iZXIgb2YgT25saW5lIFN0b3JhZ2UgU2VydmljZQ0K PiBQcm92aWRlcnMoT1NTUHMpLFBob3RvcyBTaGFyaW5nIFNlcnZpY2UgUHJvdmlkZXJzIChQU1NQ cyksIGFuZCBWaWRlb3MNCj4gU2hhcmluZyBTZXJ2aWNlIFByb3ZpZGVycyAoVlNTUHMpIGVtZXJn ZSBhdCBhIGhpc3RvcmljIG1vbWVudCBzbyB0aGF0DQo+IG1ha2UgdXBzdHJlYW0gdHJhZmZpY3Mg cmFwaWRseSBpbmNyZWFzaW5nIGFuZCBleHBlY3RlZCB0byBjb250aW51ZSBkb2luZw0KPiBzbyBp biB0aGUgZnV0dXJlLiANCj4gICAgICAgQSBsb3Qgb2YgZmFjdG9ycywgc3VjaCBhcyBsb25nIHJv dW5kLXRyaXAtdGltZSAoUlRUKSwgbG93DQo+IHJvYnVzdG5lc3Mgb2YgZGVsaXZlcnksIGFuZCB0 cmFuc3BvcnQgYm90dGxlbmVja3MsIGV0Yy4sIGxlYWQgdG8gbG93DQo+IHVwbG9hZCByYXRlLCB3 aGljaCBjYXVzZSBwb29yIHVzZXIgZXhwZXJpZW5jZXMuDQo+ICAgICAgIEkgaGF2ZSBwcm9wb3Nl ZCBhbiBhcHByb2FjaCB0byB1cGxvYWQgYWNjZWxlcmF0aW9uIHRyYW5zcG9ydA0KPiBuZXR3b3Jr IGZvciB1cHN0cmVhbSB0cmFmZmljcywgYW5kIHRoZSBkcmFmdHMgd2FzIHN1Ym1pdHRlZC4gDQo+ ICAgICAgIFRoaXMgaXMgdGhlDQo+IGxpbmssIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtcWluLXRzdndnLXVhdG51dC8gDQo+ICAgICAgQW55IGNvbW1lbnRzIGFyZSB3ZWxj b21lLg0KIA0KICAgQWNjb3JkaW5nIHRvIHRoZSByZXBvcnQgaW4gWzFdLCB0aHJvdWdocHV0IG1l YXN1cmVtZW50cw0KICAgZnJvbSBvdmVyIDEuNSBtaWxsaW9uIG1vYmlsZSBkZXZpY2VzIGhhdmUg c2hvd24gdGhhdCBjb21wYXJlZCB3aXRoIGFuDQogICBhdmVyYWdlIGRvd25zdHJlYW0gdGhyb3Vn aHB1dCBvZiBvdmVyIDE4NjAgS2JwcywgdGhlIGF2ZXJhZ2UgdXBzdHJlYW0NCiAgIHRocm91Z2hw dXQgaXMgb25seSBhYm91dCA0MzAgS2Jwcy4gIFRoaXMgaXMgYmVjYXVzZSBvZiB0aGUgYWRvcHRp b24NCiAgIG9mIGNhY2hlIHRlY2huaXF1ZXMgc3VjaCBhcyBDRE5zIHRvIGFjZWxlcmF0ZSBkb3du bG9hZGluZyBsYXJnZQ0KICAgY29udGVudCB0aGF0IG1vdmVzIHRoZSAiY29udGVudCIgY2xvc2Vy IHRvIGVuZCB1c2Vycy4NCiANCkhTRFBBL0hTVVBBL0xURSBuZXR3b3JrcyBlbXBsb3kgYXN5bW1l dHJ5IGluIGRhdGEtcmF0ZXMgYmV0d2VlbiB0aGUNCnRvd2VyIGFuZCB0aGUgaGFuZHNldCwgYW5k IHRoZSBoYW5kc2V0IGFuZCB0aGUgdG93ZXI7IHNvIHlvdXIgZmlyc3QgYW5kDQptb3N0IGRpcmVj dCBzb3VyY2Ugb2YgYXN5bW1ldHJ5IGlzIHJpZ2h0IGF0IHJhZGlvIGFjY2Vzcy1zaWRlIG9mIHRo aW5ncy4NCiANCiANCiAgIGp1c3QNCiAgIGluc3RhbGxpbmcgbW9yZSBkYXRhIHNlcnZlcnMgd2ls bCBub3QgYmUgZW5vdWdoW1JGQzYzOTJdLiAgTW92aW5nDQogICBkYXRhIHNlcnZlciBjbG9zZXIg dG8gdGhlIGVuZCB1c2VycyByZXN1bHRzIGluIGdyZWF0ZXIgbmV0d29yaw0KICAgZWZmaWNpZW5j eTogaW1wcm92ZWQgUXVhbGl0eSBvZiBTZXJ2aWNlIChRb1MpLCBpbmNyZWFzZWQgcm9idXN0bmVz cw0KICAgb2YgZGVsaXZlcnksYW5kIGxvd2VyIGxhdGVuY3kuDQogDQpUaGUgb25seSBwYXJhbWV0 ZXIgdGhhdCBkaXN0YW5jZSBjaGFuZ2VzIGRpcmVjdGx5IGlzIGJhbmR3aXRoDQpkZWxheS1wcm9k dWN0LiBpZiB0aGUgY2FycmllcidzIG5ldHdvcmsgaXMgY29uZ2VzdGVkIGl0J3MgY29uZ2VzdGVk DQppcnJlc3BlY3RpdmUgb2YgdGhlIGRlc3RpbmF0aW9uLg0KIA0KPiAgICBSZWdhcmRzLA0KPiAN Cj4gICAgWGlhb3dlaSBRaW4NCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGFwcHMtZGlzY3Vz cyBtYWlsaW5nIGxpc3QNCj4gYXBwcy1kaXNjdXNzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzDQo+IA0KIA0KIA0K ------=_001_NextPart076658685035_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
Hi, joel
Tha= nks for you review.

> HSDPA/HSUPA/LT= E networks employ asymmetry in data-rates between the
> most direct source of asy= mmetry is right at radio access-side of things.
>&n= bsp;The only pa= rameter that distance changes directly is bandwith delay-product. 
> if the carrier's network is congested it's congested irresp= ective of the destination.
>The= only parameter that distance changes directly is bandwith
= >delay-product. if the carrier's network is congested it's conge= sted
>irrespective of the destination.

Yes, i agree with you, there exists an asymmetric capacity of=0Aphysical links. This because traditional Internet data services are frequently that end user= s download content from data centers or Content Service Providers (CSPs) d= istribute content to their end users, so traffic volume generated by end u= sers account for very small proportion of all Internet traffics.
IMO=EF=BC=8Cend users can= get high data downstream rate than upstream not only because of asymmetric capacity of physical links=EF=BC=8C as well as of the adop= tion of cache techniques such as CDN.
In order to validate the analysis described above, = I have also take a practical measurement in China Mobile Labs (located in = Beijing) which is the department of the China Mobile Limited. A data serve= r deployed in Shenzhen, situated immediately north of Hong Kong (about 250= 0 kilometers away from Beijing) is used to continuously wait for packets f= rom mobile devices. 
The mobile devices is connected to Internet via = TD-LTE, and content generated by mobile devices is direct= ly uploaded to the receiver without any acceleration processing. The average upstream throughput is about 180 kbps. 
I also deploy a data server in Beijing, &nbs= p;the average upstream throughput can be up to 860 kbps.&nb= sp;
This because of long round-trip-t= ime (RTT) causes=0Alarge delay and inversely proportional TCP = throughput=EF=BC=8Ceven over a relatively long = distance, throughput may go from maximum=0Ato nothing.
Th= erefore, Content Service Providers (CSPs) have deployed their ow= n CDNs or have made a business agreement with CDN providers ,such as Akama= i, to move the content closer to end users for high download throughput.

Regards

Xiaowei Qin




<= /div>




=0A
<= br>
=0A
=0A 
Date: 2015-0= 6-08 23:36
Subject: Re: [apps-discuss] An Uploa= d Acceleration Transport Network for Upstream Traffic
On 6/7/15 7:27 PM, qinxiaowei@cnnic.cn wrote:
=0A
> Dea= r all=EF=BF=BD=EF=BF=BD
=0A
>      =0A
>       As mobile phones and = other smart devices are proliferating, more
=0A
> and more end= users like directly uploading and sharing their photos,
=0A
>= videos or other documents by data centers.
=0A
>  =      Besides, mobile devices emerging are fully cloud-= dependent that
=0A
> are not equipped with much storage but re= ly on large storage in data
=0A
> centers.
=0A
>&= nbsp;      For these reasons, a large number of O= nline Storage Service
=0A
> Providers(OSSPs),Photos Sharing Se= rvice Providers (PSSPs), and Videos
=0A
> Sharing Service Prov= iders (VSSPs) emerge at a historic moment so that
=0A
> make u= pstream traffics rapidly increasing and expected to continue doing
= =0A
> so in the future.
=0A
>    &= nbsp;  A lot of factors, such as long round-trip-time (RTT), low=0A
> robustness of delivery, and transport bottlenecks, etc., lea= d to low
=0A
> upload rate, which cause poor user experiences.=
=0A
>       I have proposed an = approach to upload acceleration transport
=0A
> network for up= stream traffics, and the drafts was submitted.
=0A
> &nb= sp;     This is the
=0A
> link, http://dat= atracker.ietf.org/doc/draft-qin-tsvwg-uatnut/
=0A
> &nbs= p;    Any comments are welcome.
=0A
 
= =0A
   According to the report in [1], throughput measuremen= ts
=0A
   from over 1.5 million mobile devices have sho= wn that compared with an
=0A
   average downstream thro= ughput of over 1860 Kbps, the average upstream
=0A
   t= hroughput is only about 430 Kbps.  This is because of the adoption=0A
   of cache techniques such as CDNs to acelerate down= loading large
=0A
   content that moves the "content" c= loser to end users.
=0A
 
=0A
HSDPA/HSUPA/LTE netwo= rks employ asymmetry in data-rates between the
=0A
tower and the = handset, and the handset and the tower; so your first and
=0A
mos= t direct source of asymmetry is right at radio access-side of things.=0A
 
=0A
 
=0A
   just
= =0A
   installing more data servers will not be enough[RFC63= 92].  Moving
=0A
   data server closer to the end = users results in greater network
=0A
   efficiency: imp= roved Quality of Service (QoS), increased robustness
=0A
 &n= bsp; of delivery,and lower latency.
=0A
 
=0A
The o= nly parameter that distance changes directly is bandwith
=0A
dela= y-product. if the carrier's network is congested it's congested
=0Airrespective of the destination.
=0A
 
=0A
>&= nbsp;   Regards,
=0A
>
=0A
>  = ;  Xiaowei Qin
=0A
>
=0A
> -----------------= -------------------------------------------------------
=0A
> =
=0A
>
=0A
> ____________________________________= ___________
=0A
> apps-discuss mailing list
=0A
> = apps-discuss@ietf.org
=0A
> https://www.ietf.org/mailman/listi= nfo/apps-discuss
=0A
>
=0A
 
=0A
 = ;
=0A
=0A ------=_001_NextPart076658685035_=------ From nobody Tue Jun 9 04:03:01 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CA21A005D for ; Tue, 9 Jun 2015 04:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTotT90ylC3T for ; Tue, 9 Jun 2015 04:02:58 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6511A0013 for ; Tue, 9 Jun 2015 04:02:57 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5CD15FA0040; Tue, 9 Jun 2015 11:02:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1433847775; bh=LJlCqfVsgfJmbV4AWwM40wsVFkpIm7S1vqkGt3NfSLM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cpZCZjcPtytPfbI7kaTePdjZ3Igu7ZqoObrcJEVJXe33wUkPiNAgt7QrlRtcWYqe4 nxd1KuenZKPVH9DxMawhNRKcHZ4wGZ/RrurkcxK7cGOy7Hd0A408MzdBt+kKVfsXPc 4cJfAjJA89m93kcD3RNBOBbmQLQfTgvZjfPdMCrA= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1433847774-25087-25086/12/24; Tue, 9 Jun 2015 11:02:54 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Tue, 9 Jun 2015 12:04:25 +0100 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Debian GNU/Linux 8.0 (jessie) Mime-Version: 1.0 Message-Id: <8927de42-126d-4dac-af61-be586854ab5f@gulbrandsen.priv.no> In-Reply-To: <2015060910523122319771@cnnic.cn> References: <2015060810270811245415@cnnic.cn> <5c9e933b-396f-4e49-a09d-f607459fb613@gulbrandsen.priv.no> <2015060910523122319771@cnnic.cn> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [apps-discuss] An Upload Acceleration Transport Network for Upstream Traffic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 11:03:00 -0000 qinxiaowei@cnnic.cn writes: > If you have statistics for PC or via WiFi, could you share it? I'm afraid I cannot. I was a contractor until quite recently and there's an NDA. (I have signed too many NDAs.) I can say that I didn't measure any performance difference based on hop count. I did measure differences for small files (speed started slow and then increased, and the increase was faster when the client was closer), and I did measure large differences based on customer ISP (we had good connections to some ISPs and poor to some). But not based on pure distance or the number of hops. > The asymmetric capacity of physical links such as in ADSL may > be also an factor, but many Content Service Providers (CSPs) > have deployed their own CDNs or have made a business agreement > with CDN providers ,such as Akamai, to move the content closer > to end users for high download throughput. Akamai does several things. For instance, it copies popular content to many servers, so file system bandwidth increases. (At work we use a CDN mostly for this reason.) > In order to validate the analysis described above, I have also > take a practical measurement in China Mobile Labs (located in > Beijing) which is the department of the China Mobile Limited. A > data server deployed in Shenzhen, situated immediately north of > Hong Kong (about 2500 kilometers away from Beijing) is used to > continuously wait for packets from mobile devices. > The mobile devices is connected to Internet via TD-LTE, > and content generated by mobile devices is directly uploaded to > the receiver without any acceleration processing. The average > upstream throughput is about 180 kbps. > I also deploy a data server in Beijing, the average upstream > throughput can be up to 860 Mbps. Yes, but what's the reason for the difference? ISPs playing peering games? Policy routing? Some ISPs even try to detect speed tests and reallocate bandwidth, using products like http://www.ipoque.com/products/prx-g-series which can be configured to do things like "permit fast transfers only if the other end is also our customer, the URL contains /speedtest/ or the packets are routed via a transit provider on this list: ..." Arnt From nobody Tue Jun 9 18:55:09 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A8C1A038A for ; Tue, 9 Jun 2015 18:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.59 X-Spam-Level: ** X-Spam-Status: No, score=2.59 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_46=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLW9nZNgQDY9 for ; Tue, 9 Jun 2015 18:55:04 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 084651A0263 for ; Tue, 9 Jun 2015 18:54:57 -0700 (PDT) Received: from CNNIC-PC (unknown [218.241.119.115]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0AJEZXlmHdV_LxpBw--.3576S2; Wed, 10 Jun 2015 09:54:45 +0800 (CST) Date: Wed, 10 Jun 2015 09:54:39 +0800 From: "qinxiaowei@cnnic.cn" To: "Arnt Gulbrandsen" , apps-discuss References: <2015060810270811245415@cnnic.cn>, <5c9e933b-396f-4e49-a09d-f607459fb613@gulbrandsen.priv.no>, <2015060910523122319771@cnnic.cn>, <8927de42-126d-4dac-af61-be586854ab5f@gulbrandsen.priv.no> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <201506100954391448707@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart485566544143_=----" X-CM-TRANSID: AQAAf0AJEZXlmHdV_LxpBw--.3576S2 X-Coremail-Antispam: 1UD129KBjvJXoWxCryDGr17Jry3ArW3Wry8Xwb_yoW5tFyfpF W5Krn5K34kGr1rC34kZw4fuF1ruas3A3y5AryYkr47Cr98Xryakr1xZw4YvayUur1rX3Wj vrWDu3yDCw1DAFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUdCb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjc xK6I8E87Iv6xkF7I0E14v26F4UJVW0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40E n4AKxVAvwIkv4cxYr24l5I8CrVCF0I0E4I0vr24l5I8CrVC2j2CEjI02ccxYII8I67AEr4 CY67k08wAqx4xG6I8I3I0E8cIF7480aVAKz4kxMcIj6xIIjxv20xvE14v26r106r15McIj 6I8E87Iv67AKxVW8JVWxJwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFc xC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07Mx8GjcxK6IxK0xIIj40E5I8C rwCY02Avz4vE14v_KwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s 026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_ Jrv_JF1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20x vEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280 aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JwCE64xvF2IEb7IF0Fy7Yx BIdaVFxhVjvjDU0xZFpf9x07bFiiDUUUUU= X-CM-SenderInfo: xtlq5x5drzvxw6fq0xffof0/ Archived-At: Subject: Re: [apps-discuss] An Upload Acceleration Transport Network for Upstream Traffic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 01:55:07 -0000 This is a multi-part message in MIME format. ------=_001_NextPart485566544143_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGksQXJudA0KDQo+WWVzLCBidXQgd2hhdCdzIHRoZSByZWFzb24gZm9yIHRoZSBkaWZmZXJlbmNl PyBJU1BzIHBsYXlpbmcgcGVlcmluZyBnYW1lcz8NCj5Qb2xpY3kgcm91dGluZz8gU29tZSBJU1Bz IGV2ZW4gdHJ5IHRvIGRldGVjdCBzcGVlZCB0ZXN0cyBhbmQgcmVhbGxvY2F0ZQ0KPmJhbmR3aWR0 aCwgdXNpbmcgcHJvZHVjdHMgbGlrZSBodHRwOi8vd3d3Lmlwb3F1ZS5jb20vcHJvZHVjdHMvcHJ4 LWctc2VyaWVzDQo+d2hpY2ggY2FuIGJlIGNvbmZpZ3VyZWQgdG8gZG8gdGhpbmdzIGxpa2UgInBl cm1pdCBmYXN0IHRyYW5zZmVycyBvbmx5IGlmDQp0PmhlIG90aGVyIGVuZCBpcyBhbHNvIG91ciBj dXN0b21lciwgdGhlIFVSTCBjb250YWlucyAvc3BlZWR0ZXN0LyBvciB0aGUNCnA+YWNrZXRzIGFy ZSByb3V0ZWQgdmlhIGEgdHJhbnNpdCBwcm92aWRlciBvbiB0aGlzIGxpc3Q6IC4uLiINCg0KVGhl cmUgbWF5IGV4aXN0IGxpbWl0YXRpb24gb2YgbmV0d29yayBiYW5kd2lkdGggYW5kIGhvcHMgZGVs YXkgYmV0d2VlbiB0aGUgdHdvIE1BTnMgLCBvciB0d28gSVNQcy4gQW5kIHRoZXJlIG1heSBhbHNv IGV4aXN0IGRhdGEgdHJhbnNtaXNzaW9uIGJvdHRsZW5lY2tzIGJldHdlZW4gdGhlIHR3byBUZWxl Y29tbXVuaWNhdGlvbiBTZXJ2aWNlIFByb3ZpZGVycy4gU28sIHdlIG5lZWQgbW92ZSB0aGUgImRh dGEgcmVjZWl2ZXIiIGNsb3NlciB0byB0aGUgZW5kIHVzZXIgdG8gYXZvaWQgZGVsaXZlcnkgYm90 dGxlbmVja3MuDQoNCj5Ba2FtYWkgZG9lcyBzZXZlcmFsIHRoaW5ncy4gRm9yIGluc3RhbmNlLCBp dCBjb3BpZXMgcG9wdWxhciBjb250ZW50IHRvIG1hbnkNCj5zZXJ2ZXJzLCBzbyBmaWxlIHN5c3Rl bSBiYW5kd2lkdGggaW5jcmVhc2VzLiAoQXQgd29yayB3ZSB1c2UgYSBDRE4gbW9zdGx5DQo+Zm9y IHRoaXMgcmVhc29uLikNCg0KWWVzLCBJIHdhbnQgdG8gZ2l2ZSBhbiBhY2NlbGVyYXRpb24gbmV0 d29yayBmb3IgdXBzdHJlYW0gdHJhZmZpYyBsaWtlIENETnMuIFdoZW4gZW5kIHVzZXIgcmVxdWVz dHMgdG8gdXBsb2FkIGNvbnRlbnQgdG8gZGF0YSBjZW50ZXIsIHRoZSByZXF1ZXN0IHdpbGwgYmUg cmVkaXJlY3RlZCB0byBhbiBhcHByb3ByaWF0ZSBFZGdlIFNlcnZlcihmb3IgaW5zdGFuY2UsdGhl IEVTIGlzIGFuIGFjY2VzcyBzZXJ2ZXIgYW5kIHRoZSB1c2VyIGlzIGRpcmVjdGx5IGF0dGFjaGVk IHRvIGl0KSwgYW5kIHRoZSBjb250ZW50IGlzIGFjdHVhbGx5IGRlbGl2ZXJlZCB0byBkYXRhIGNl bnRlciBieSB0aGUgVUFUTihVcGxvYWQgQWNjZWxlcmF0aW9uIFRyYW5zcG9ydCBOZXR3b3JrKS4N Cg0KWGlhb3dlaSBRaW4NCg0KDQoNCg0KDQogDQpGcm9tOiBBcm50IEd1bGJyYW5kc2VuDQpEYXRl OiAyMDE1LTA2LTA5IDE5OjA0DQpUbzogYXBwcy1kaXNjdXNzDQpTdWJqZWN0OiBSZTogW2FwcHMt ZGlzY3Vzc10gQW4gVXBsb2FkIEFjY2VsZXJhdGlvbiBUcmFuc3BvcnQgTmV0d29yayBmb3IgVXBz dHJlYW0gVHJhZmZpYw0KcWlueGlhb3dlaUBjbm5pYy5jbiB3cml0ZXM6DQo+IElmIHlvdSBoYXZl IHN0YXRpc3RpY3MgZm9yIFBDIG9yIHZpYSBXaUZpLCBjb3VsZCB5b3Ugc2hhcmUgaXQ/DQogDQpJ J20gYWZyYWlkIEkgY2Fubm90LiBJIHdhcyBhIGNvbnRyYWN0b3IgdW50aWwgcXVpdGUgcmVjZW50 bHkgYW5kIHRoZXJlJ3MgYW4gDQpOREEuIChJIGhhdmUgc2lnbmVkIHRvbyBtYW55IE5EQXMuKQ0K IA0KSSBjYW4gc2F5IHRoYXQgSSBkaWRuJ3QgbWVhc3VyZSBhbnkgcGVyZm9ybWFuY2UgZGlmZmVy ZW5jZSBiYXNlZCBvbiBob3AgDQpjb3VudC4gSSBkaWQgbWVhc3VyZSBkaWZmZXJlbmNlcyBmb3Ig c21hbGwgZmlsZXMgKHNwZWVkIHN0YXJ0ZWQgc2xvdyBhbmQgDQp0aGVuIGluY3JlYXNlZCwgYW5k IHRoZSBpbmNyZWFzZSB3YXMgZmFzdGVyIHdoZW4gdGhlIGNsaWVudCB3YXMgY2xvc2VyKSwgDQph bmQgSSBkaWQgbWVhc3VyZSBsYXJnZSBkaWZmZXJlbmNlcyBiYXNlZCBvbiBjdXN0b21lciBJU1Ag KHdlIGhhZCBnb29kIA0KY29ubmVjdGlvbnMgdG8gc29tZSBJU1BzIGFuZCBwb29yIHRvIHNvbWUp LiBCdXQgbm90IGJhc2VkIG9uIHB1cmUgZGlzdGFuY2UgDQpvciB0aGUgbnVtYmVyIG9mIGhvcHMu DQogDQo+IFRoZSBhc3ltbWV0cmljIGNhcGFjaXR5IG9mIHBoeXNpY2FsIGxpbmtzIHN1Y2ggYXMg aW4gQURTTCBtYXkgDQo+IGJlIGFsc28gYW4gZmFjdG9yLCBidXQgbWFueSBDb250ZW50IFNlcnZp Y2UgUHJvdmlkZXJzIChDU1BzKSANCj4gaGF2ZSBkZXBsb3llZCB0aGVpciBvd24gQ0ROcyBvciBo YXZlIG1hZGUgYSBidXNpbmVzcyBhZ3JlZW1lbnQgDQo+IHdpdGggQ0ROIHByb3ZpZGVycyAsc3Vj aCBhcyBBa2FtYWksIHRvIG1vdmUgdGhlIGNvbnRlbnQgY2xvc2VyIA0KPiB0byBlbmQgdXNlcnMg Zm9yIGhpZ2ggZG93bmxvYWQgdGhyb3VnaHB1dC4NCiANCkFrYW1haSBkb2VzIHNldmVyYWwgdGhp bmdzLiBGb3IgaW5zdGFuY2UsIGl0IGNvcGllcyBwb3B1bGFyIGNvbnRlbnQgdG8gbWFueSANCnNl cnZlcnMsIHNvIGZpbGUgc3lzdGVtIGJhbmR3aWR0aCBpbmNyZWFzZXMuIChBdCB3b3JrIHdlIHVz ZSBhIENETiBtb3N0bHkgDQpmb3IgdGhpcyByZWFzb24uKQ0KIA0KPiBJbiBvcmRlciB0byB2YWxp ZGF0ZSB0aGUgYW5hbHlzaXMgZGVzY3JpYmVkIGFib3ZlLCBJIGhhdmUgYWxzbyANCj4gdGFrZSBh IHByYWN0aWNhbCBtZWFzdXJlbWVudCBpbiBDaGluYSBNb2JpbGUgTGFicyAobG9jYXRlZCBpbiAN Cj4gQmVpamluZykgd2hpY2ggaXMgdGhlIGRlcGFydG1lbnQgb2YgdGhlIENoaW5hIE1vYmlsZSBM aW1pdGVkLiBBIA0KPiBkYXRhIHNlcnZlciBkZXBsb3llZCBpbiBTaGVuemhlbiwgc2l0dWF0ZWQg aW1tZWRpYXRlbHkgbm9ydGggb2YgDQo+IEhvbmcgS29uZyAoYWJvdXQgMjUwMCBraWxvbWV0ZXJz IGF3YXkgZnJvbSBCZWlqaW5nKSBpcyB1c2VkIHRvIA0KPiBjb250aW51b3VzbHkgd2FpdCBmb3Ig cGFja2V0cyBmcm9tIG1vYmlsZSBkZXZpY2VzLiANCj4gVGhlIG1vYmlsZSBkZXZpY2VzIGlzIGNv bm5lY3RlZCB0byBJbnRlcm5ldCB2aWEgVEQtTFRFLCANCj4gYW5kIGNvbnRlbnQgZ2VuZXJhdGVk IGJ5IG1vYmlsZSBkZXZpY2VzIGlzIGRpcmVjdGx5IHVwbG9hZGVkIHRvIA0KPiB0aGUgcmVjZWl2 ZXIgd2l0aG91dCBhbnkgYWNjZWxlcmF0aW9uIHByb2Nlc3NpbmcuIFRoZSBhdmVyYWdlIA0KPiB1 cHN0cmVhbSB0aHJvdWdocHV0IGlzIGFib3V0IDE4MCBrYnBzLiANCj4gSSBhbHNvIGRlcGxveSBh IGRhdGEgc2VydmVyIGluIEJlaWppbmcsICB0aGUgYXZlcmFnZSB1cHN0cmVhbSANCj4gdGhyb3Vn aHB1dCBjYW4gYmUgdXAgdG8gODYwIE1icHMuDQogDQpZZXMsIGJ1dCB3aGF0J3MgdGhlIHJlYXNv biBmb3IgdGhlIGRpZmZlcmVuY2U/IElTUHMgcGxheWluZyBwZWVyaW5nIGdhbWVzPyANClBvbGlj eSByb3V0aW5nPyBTb21lIElTUHMgZXZlbiB0cnkgdG8gZGV0ZWN0IHNwZWVkIHRlc3RzIGFuZCBy ZWFsbG9jYXRlIA0KYmFuZHdpZHRoLCB1c2luZyBwcm9kdWN0cyBsaWtlIGh0dHA6Ly93d3cuaXBv cXVlLmNvbS9wcm9kdWN0cy9wcngtZy1zZXJpZXMNCndoaWNoIGNhbiBiZSBjb25maWd1cmVkIHRv IGRvIHRoaW5ncyBsaWtlICJwZXJtaXQgZmFzdCB0cmFuc2ZlcnMgb25seSBpZiANCnRoZSBvdGhl ciBlbmQgaXMgYWxzbyBvdXIgY3VzdG9tZXIsIHRoZSBVUkwgY29udGFpbnMgL3NwZWVkdGVzdC8g b3IgdGhlIA0KcGFja2V0cyBhcmUgcm91dGVkIHZpYSBhIHRyYW5zaXQgcHJvdmlkZXIgb24gdGhp cyBsaXN0OiAuLi4iDQogDQpBcm50DQogDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KYXBwcy1kaXNjdXNzIG1haWxpbmcgbGlzdA0KYXBwcy1kaXNjdXNz QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlz Y3Vzcw0K ------=_001_NextPart485566544143_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
Hi,Arnt

>Yes, but what's the reason for the difference? ISPs playing peering g= ames?
>Policy routing? Some ISPs even try to dete= ct speed tests and reallocate
>bandwidth, using p= roducts like http://www.ipoque.com/products/prx-g-series
&g= t;which can be configured to do things like "permit fast transfers = only if
t>he other end is also our customer,= the URL contains /speedtest/ or the
p>
=

There may exist limitation of networ= k bandwidth and hops delay between the two MANs , or two ISPs. A= nd there may also exist data transmission bottlenecks between the two Telecommunication Service P= roviders. So, we need move the "data receiver" closer to = the end user to avoid delivery bottlenecks.

>Akamai does several things. For insta= nce, it copies popular content to many
>servers, = so file system bandwidth increases. (At work we use a CDN mostly
>for this reason.)

Yes, I want to give an acceler= ation network for upstream traffic like CDNs. When end user requests to up= load content to data center, the request will be redirected to an appropri= ate Edge Server(for instance,the ES is an access server and the user is di= rectly attached to it), and the content is actually delivered to data cent= er by the UATN(Upload Acceleration Transport Network).

Xiaowei Qin
=


=0A

= =0A
=0A
 
Date: 2015-06-09 19:04
=
Subject: Re: [apps-discuss] An Upload Accelerat= ion Transport Network for Upstream Traffic
qinx= iaowei@cnnic.cn writes:
=0A
> If you have statistics for PC or= via WiFi, could you share it?
=0A
 
=0A
I'm afraid= I cannot. I was a contractor until quite recently and there's an
= =0A
NDA. (I have signed too many NDAs.)
=0A
 
=0AI can say that I didn't measure any performance difference based on hop=
=0A
count. I did measure differences for small files (speed sta= rted slow and
=0A
then increased, and the increase was faster wh= en the client was closer),
=0A
and I did measure large differenc= es based on customer ISP (we had good
=0A
connections to some IS= Ps and poor to some). But not based on pure distance
=0A
or the = number of hops.
=0A
 
=0A
> The asymmetric capac= ity of physical links such as in ADSL may
=0A
> be also an fa= ctor, but many Content Service Providers (CSPs)
=0A
> have de= ployed their own CDNs or have made a business agreement
=0A
>= with CDN providers ,such as Akamai, to move the content closer
=0A<= div>> to end users for high download throughput.
=0A
 =0A
Akamai does several things. For instance, it copies popular con= tent to many
=0A
servers, so file system bandwidth increases. (A= t work we use a CDN mostly
=0A
for this reason.)
=0A
&n= bsp;
=0A
> In order to validate the analysis described above, = I have also
=0A
> take a practical measurement in China Mobil= e Labs (located in
=0A
> Beijing) which is the department of = the China Mobile Limited. A
=0A
> data server deployed in She= nzhen, situated immediately north of
=0A
> Hong Kong (about 2= 500 kilometers away from Beijing) is used to
=0A
> continuous= ly wait for packets from mobile devices.
=0A
> The mobile dev= ices is connected to Internet via TD-LTE,
=0A
> and content g= enerated by mobile devices is directly uploaded to
=0A
> the = receiver without any acceleration processing. The average
=0A
&g= t; upstream throughput is about 180 kbps.
=0A
> I also deploy= a data server in Beijing,  the average upstream
=0A
> t= hroughput can be up to 860 Mbps.
=0A
 
=0A
Yes, but= what's the reason for the difference? ISPs playing peering games?
= =0A
Policy routing? Some ISPs even try to detect speed tests and reall= ocate
=0A
bandwidth, using products like http://www.ipoque.com/p= roducts/prx-g-series
=0A
which can be configured to do things lik= e "permit fast transfers only if
=0A
the other end is also our c= ustomer, the URL contains /speedtest/ or the
=0A
packets are rou= ted via a transit provider on this list: ..."
=0A
 
=0A=
Arnt
=0A
 
=0A
_______________________________= ________________
=0A
apps-discuss mailing list
=0A
apps-= discuss@ietf.org
=0A
https://www.ietf.org/mailman/listinfo/apps-d= iscuss
=0A
=0A ------=_001_NextPart485566544143_=------ From edward.vielmetti@gmail.com Tue Jun 9 12:02:22 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761571B2E63 for ; Tue, 9 Jun 2015 12:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJ6X8sd3houo for ; Tue, 9 Jun 2015 12:02:20 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1231B2EB2 for ; Tue, 9 Jun 2015 12:02:18 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so18816033igb.1 for ; Tue, 09 Jun 2015 12:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=e4wBFHkQYtW7wkNOGWJDbsgxRbYhKO067vUPHhSopkM=; b=oV+Vzu1RPGwAyRR4pcnNOn2dnDA2bR38kLgeuysvQOJmUbAO/Wus+E+S5Axam1wkMr 5/URk/AXGPekNDwEuA4Z2XmzuCW+cM0ut3Lacxyv22g9wZgjjsSFp10QFDr2JanHIlzP +fhc8iJ5a3jFzmblBJDzbE3lKxXSl//x7O8319KVy+RajCFdwE+JqAG9oNFSNYgD0XU3 mIDfyFlk9MTWAS560HI9qnAS2cqPg8hw5m3japkyfA3P8N4b44ibjbx1SboCnQAzKl/5 nEEq4DhWlm18aWI3y4QNDy7/FYYuEOa2Mr5bneM45uX5ThQU8tZdRF0Gc3GpPtASVUj2 XjaA== X-Received: by 10.50.43.227 with SMTP id z3mr2166577igl.22.1433874744687; Tue, 09 Jun 2015 11:32:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.143.131 with HTTP; Tue, 9 Jun 2015 11:31:44 -0700 (PDT) From: Edward Vielmetti Date: Tue, 9 Jun 2015 14:31:44 -0400 Message-ID: To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=089e0111c016cf44e3051819fafd Archived-At: X-Mailman-Approved-At: Wed, 10 Jun 2015 12:33:26 -0700 Subject: [apps-discuss] gopher-ii standardization process & personal introduction X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 19:04:01 -0000 --089e0111c016cf44e3051819fafd Content-Type: text/plain; charset=UTF-8 After a message on the gopher-discuss list I decided to join the apps-discuss list and see what I could do for the gopher-ii standardization process. By way of background, I've contributed to RFCs from the early 1990s including MIME (1341, 1521, 2049), Guide to Network Resource Tools (FYI 23), Network Access to Multimedia Information (1614, RARE 8), and Uniform Resource Locators (1738). I gave a presentation at GopherCon '92 and Prentiss Riddle wrote up the whole thing here: http://vielmetti.typepad.com/vacuum/1992/08/gophercon-92-trip-report-from-prentiss-riddle.html The history of Gopher is that of a protocol that has had a lot of utility at various times in its life. I'm looking at it as a possible lightweight information system for Raspberry Pi sized devices (small single board Linux systems, sub $25 delivered cost). IETF has COAP in that space already, but perhaps Gopher and gopher-ii can live there too, if you have a system constrained enough to be performant on suitable equipment as well as secure enough because of a deployed base of well-understood and well reviewed code. I'm currently at All Hands Active, a maker space in Ann Arbor, and I'm subscribing to this list via a daily digest so don't expect more than a message a day from me. thanks Ed -- Edward Vielmetti +1 734 330 2465 edward.vielmetti@gmail.com --089e0111c016cf44e3051819fafd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
After a message on the gopher-discuss list I decided to jo= in the apps-discuss list and see what I could do for the gopher-ii standard= ization process.

By way of background, I've contribu= ted to RFCs from the early 1990s including MIME (1341, 1521, 2049), Guide t= o Network Resource Tools (FYI 23),=C2=A0 Network Access to Multimedia Infor= mation (1614, RARE 8), and=C2=A0Uniform Resource Locators (1738).=C2=A0

I gave= a presentation at GopherCon '92 and Prentiss Riddle wrote up the whole= thing here:=C2=A0

http://vielmetti.typepad.com/vacuum/1992/08/gophercon-92-trip-report-from-= prentiss-riddle.html

The history o= f Gopher is that of a protocol that has had a lot of utility at various tim= es in its life. I'm looking at it as a possible lightweight information= system for Raspberry Pi sized devices (small single board Linux systems, s= ub $25 delivered cost). IETF has COAP in that space already, but perhaps Go= pher and gopher-ii can live there too, if you have a system constrained eno= ugh to be performant on suitable equipment as well as secure enough because= of a deployed base of well-understood and well reviewed code.
I'm currently at All Hands Active, a maker space in Ann Ar= bor, and I'm subscribing to this list via a daily digest so don't e= xpect more than a message a day from me.

thanks

Ed
--
= Edward Vielmetti=C2=A0+1 734 330 2465

--089e0111c016cf44e3051819fafd-- From nobody Thu Jun 11 00:50:24 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3FE1AC3AE for ; Thu, 11 Jun 2015 00:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5JKeb5I8418 for ; Thu, 11 Jun 2015 00:50:22 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AB741AC39F for ; Thu, 11 Jun 2015 00:50:22 -0700 (PDT) Received: (qmail 12966 invoked from network); 11 Jun 2015 07:50:29 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 11 Jun 2015 07:50:29 -0000 Date: 11 Jun 2015 07:49:58 -0000 Message-ID: <20150611074958.9083.qmail@ary.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: 8bit Archived-At: Cc: edward.vielmetti@gmail.com Subject: Re: [apps-discuss] gopher-ii standardization process & personal introduction X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 07:50:23 -0000 >After a message on the gopher-discuss list I decided to join the >apps-discuss list and see what I could do for the gopher-ii standardization >process. Hi. Long time, no see. > I'm looking at it as a possible lightweight >information system for Raspberry Pi sized devices (small single board Linux >systems, sub $25 delivered cost). IETF has COAP in that space already, but >perhaps Gopher and gopher-ii can live there too, if you have a system >constrained enough to be performant on suitable equipment as well as secure >enough because of a deployed base of well-understood and well reviewed code. Gee, I wish someone had given us this background a month ago. I get your point, but Raspberry Pi runs linux and it's hard to believe that a lightweight web server like lighttpd wouldn't work perfectly well and be comparably secure since its code gets a lot of scrutiny. If you want a client, there's always lynx. CoAP is intended for really tiny things, with the usual example being to tell a smart lightbulb to turn itself on. Gopher seems too heavy for that. R's, John From nobody Thu Jun 11 08:05:45 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDAC1B302F for ; Thu, 11 Jun 2015 08:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggY5FBcpXOrY for ; Thu, 11 Jun 2015 08:05:44 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABFF11B302B for ; Thu, 11 Jun 2015 08:05:42 -0700 (PDT) Received: (qmail 83753 invoked from network); 11 Jun 2015 15:05:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=14728.5579a3ce.k1506; bh=/iFZcvZYNAN2FU5iFsyMzjmP+5+UVoByDG0+E5cQMXE=; b=loH7UDjePPnbs5jpvnUxohBB/wFABmQvKnrxq7N1056EqO/HJvtjXY2v0eUNGY1TNem89N6pF7h4nvQkaZKV9SLyFOiuslgFGfxmwYtzCuZmsX/IzPK/z8f+BagbgeZTuQRE3nAyDZMqp7aC2R9d6s9QK1xvTNoUeIesRaXsmYU13suJlckQpUCJcExm6M3Pj9enuLR2cVWwcOmjlxYOwRaWsJfw+Fjyh3vL9Cah6ag7ItWTORCKu0MdYpIIa/M8 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=14728.5579a3ce.k1506; bh=/iFZcvZYNAN2FU5iFsyMzjmP+5+UVoByDG0+E5cQMXE=; b=nhTrp9LfKEAwm8UzGvgCHSavJC688jSR7AIg99pYIbbU0cehTz7BHSeQnMSraUORFn6kPSv/XuinYnTGgLojvhgQxAJ1m5ZSdlJTGyPbEjEl0ui72ZS8zr5qRG3pR+C8xUUuaHHe3SgEYVwnHTaAGeTnz2XoQz4GdtnjQ3OSuGamfs54/hP3AkIIuJlTV1L1oQK7bm/I4EQ4GTjD6B5m1Eb3/UenLZRHxTDN0jOvqvx29D/ltZYFqEGgmj3JDLGF Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 11 Jun 2015 15:05:50 -0000 Date: 11 Jun 2015 16:05:39 +0100 Message-ID: From: "John R Levine" To: "Edward Vielmetti" In-Reply-To: References: <20150611074958.9083.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] gopher-ii standardization process & personal introduction X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 15:05:45 -0000 > I'm not worried about clients on tiny machines, lynx supports Gopher just > fine. I'm more worried about reasonable client-server arrangements where > the server is a $25 Raspberry Pi or even a $3 ESP8266 (which talks MQTT > just fine, as I understand it, and for which it would be perfectly > cromulent to get a Gopher server running on.) If you're going to run HTTP > you want to proxy it anyway through some service that scales up to web > scale, because the internet will crush your puny web server. I still don't get it. The Internet will only crush your server if a lot of random places send requests to which you send expensive replies. On the wire, http and gopher are essentially the same, open a TCP session, send a blob of request, the server sends a blob of result, and you're done. There's all sorts of extra optional bells and whistles in http, but you don't have to support them if you don't want to. Take a look at Mongoose, a minimal web server intended for embedded applications, 5600 lines of source code. If you want to keep tourists from hammering on your web server, you do that by keeping spiders away from it. Running it on another port works pretty well. It's still very unclear to me what practical problem is addressed here that existing tools don't. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Jun 11 09:23:30 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5480D1B2BDC for ; Thu, 11 Jun 2015 09:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xixEoTOthCEK for ; Thu, 11 Jun 2015 09:23:26 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B471B2B94 for ; Thu, 11 Jun 2015 09:23:26 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 574B5FA0040; Thu, 11 Jun 2015 16:23:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1434039804; bh=emTF0/Q9IzLGgRKWucXWAlmZg5SxWzaXgrEcU99/Arw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZYutd7qgbmMYSulFbg+HQcMUT05xlYQvr33fBmZlRFJ2R2piKx++kiseDwLXnGjvv MTmqtMqjcIRpGZ1eJvIZPoE8GeqxCwSiwmbc8LuHyuwJl4WOOdmo3X9lmsxGZwv/dA Bflb6qIS/wRJ+YM0pjFUXyw19XWBZRhMrchrtiwM= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1434039803-25087-25086/12/41; Thu, 11 Jun 2015 16:23:23 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Thu, 11 Jun 2015 17:25:00 +0100 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Debian GNU/Linux 8.0 (jessie) Mime-Version: 1.0 Message-Id: <94d1268c-e2bf-4c45-8b15-59e08131cd6e@gulbrandsen.priv.no> In-Reply-To: References: <20150611074958.9083.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [apps-discuss] gopher-ii standardization process & personal introduction X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 16:23:28 -0000 John R Levine writes: > It's still very unclear to me what practical problem is > addressed here that existing tools don't. You sound like a windows user who doesn't understand why anyone would use (or even work on!) those unix things when windows does the job. (I don't see why they do it either. But they clearly have running code and roughly agree on the protocol to use.) Arnt From nobody Thu Jun 11 09:28:49 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECA71B29A8 for ; Thu, 11 Jun 2015 07:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVHLUGMklK7s for ; Thu, 11 Jun 2015 07:17:08 -0700 (PDT) Received: from mail-ig0-x244.google.com (mail-ig0-x244.google.com [IPv6:2607:f8b0:4001:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AACD01B2850 for ; Thu, 11 Jun 2015 07:17:08 -0700 (PDT) Received: by igdh15 with SMTP id h15so1858333igd.1 for ; Thu, 11 Jun 2015 07:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=N/kwlGRTmJPsZCw8JflF2t8ODFtYPVsqS8YrEtQc4mQ=; b=Lczzcl3aTryb448OcjW8fX5T9Yzna6y3L61eH0phh4eTmjIdF2NCQIFsCb00apuQxB sebco/rWcZx6aNk3KEVZ/IeiWUhiJx9lMt9BFWtKzcprX6Gn2blmD26RvWwP6CLq+rVy bG40M82cFMJp9QHAU3Y99bmWDo8/eB6GA7h34lrj8hpNDWyhbqJCTbyjV1leWtJeNF/t +/tl4tEfUvQaYXIHPJ68gfVNFGkFAnRfadU5cxZ3CNzFpjOgc0ml5SbzLOCrwtLoRShz RjfnX5tIyTAaOG5XvIUVVeSLBuHkRjEReExs0ldMxmFCBHbfuTPy3iFjNkjeBSCpN/Gw C2Wg== X-Received: by 10.43.44.130 with SMTP id ug2mr11380930icb.53.1434032228061; Thu, 11 Jun 2015 07:17:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.143.131 with HTTP; Thu, 11 Jun 2015 07:16:27 -0700 (PDT) In-Reply-To: <20150611074958.9083.qmail@ary.lan> References: <20150611074958.9083.qmail@ary.lan> From: Edward Vielmetti Date: Thu, 11 Jun 2015 10:16:27 -0400 Message-ID: To: John Levine Content-Type: multipart/alternative; boundary=bcaec52e604f8cd84305183ea580 Archived-At: X-Mailman-Approved-At: Thu, 11 Jun 2015 09:28:47 -0700 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] gopher-ii standardization process & personal introduction X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 14:17:11 -0000 --bcaec52e604f8cd84305183ea580 Content-Type: text/plain; charset=UTF-8 John - CoAP is intended for really tiny things, but in practice a lot more people use MQTT (an OASIS protocol) which is a publish-subscribe protocol. A very tiny Docker container for MQTT running mosquitto - https://registry.hub.docker.com/u/lapax/tiny-mosquitto/ is a reasonable design and consumes only a few megabytes. A system like Node-RED from IBM runs that nicely as its inter-machine communcation and fits on a Pi or a Beaglebone reasonably well. That said - HTTP/HTML5 is a pretty big protocol, and Gopher (even gopher-ii) is a much smaller protocol. The minimum Docker image serving up a Gopher server is a good design target - you just expose port 70, do just your tiny little thing, and don't try to construct an entire web service out of it (and track HTML5 etc etc ad nauseum). I'm not worried about clients on tiny machines, lynx supports Gopher just fine. I'm more worried about reasonable client-server arrangements where the server is a $25 Raspberry Pi or even a $3 ESP8266 (which talks MQTT just fine, as I understand it, and for which it would be perfectly cromulent to get a Gopher server running on.) If you're going to run HTTP you want to proxy it anyway through some service that scales up to web scale, because the internet will crush your puny web server. As to the comments about retrocomputing, just note that the Pi and the Beaglebone and their ilk are two orders of magnitude cheaper than the computers of the 1990s that are contemporaneous with Gopher, and roughly comparable in power. Rewinding the protocol stack back to 1992 and building out from there with what we learned in the intervening 23 years is a reasonable exercise. At minimum it gives us a secure base to build from for April Fools. thanks Ed On Thu, Jun 11, 2015 at 3:49 AM, John Levine wrote: > >After a message on the gopher-discuss list I decided to join the > >apps-discuss list and see what I could do for the gopher-ii > standardization > >process. > > Hi. Long time, no see. > > > I'm looking at it as a possible lightweight > >information system for Raspberry Pi sized devices (small single board > Linux > >systems, sub $25 delivered cost). IETF has COAP in that space already, but > >perhaps Gopher and gopher-ii can live there too, if you have a system > >constrained enough to be performant on suitable equipment as well as > secure > >enough because of a deployed base of well-understood and well reviewed > code. > > Gee, I wish someone had given us this background a month ago. I get > your point, but Raspberry Pi runs linux and it's hard to believe that > a lightweight web server like lighttpd wouldn't work perfectly well > and be comparably secure since its code gets a lot of scrutiny. If > you want a client, there's always lynx. > > CoAP is intended for really tiny things, with the usual example being > to tell a smart lightbulb to turn itself on. Gopher seems too heavy > for that. > > R's, > John > -- Edward Vielmetti +1 734 330 2465 edward.vielmetti@gmail.com --bcaec52e604f8cd84305183ea580 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John -

CoAP is intended for really tiny= things, but in practice a lot more people use MQTT (an OASIS protocol) whi= ch is a publish-subscribe protocol. A very tiny Docker container for MQTT r= unning mosquitto -=C2=A0


is a reasonable de= sign and consumes only a few megabytes. A system like Node-RED from IBM run= s that nicely as its inter-machine communcation and fits on a Pi or a Beagl= ebone reasonably well.=C2=A0

That said -

HTTP/HTML5 is a pretty big protocol, and Gopher (even gophe= r-ii) is a much smaller protocol. The minimum Docker image serving up a Gop= her server is a good design target - you just expose port 70, do just your = tiny little thing, and don't try to construct an entire web service out= of it (and track HTML5 etc etc ad nauseum).=C2=A0

I'm not worried about clients on tiny machines, lynx supports Gopher j= ust fine. I'm more worried about reasonable client-server arrangements = where the server is a $25 Raspberry Pi or even a $3 ESP8266 (which talks MQ= TT just fine, as I understand it, and for which it would be perfectly cromu= lent to get a Gopher server running on.) If you're going to run HTTP yo= u want to proxy it anyway through some service that scales up to web scale,= because the internet will crush your puny web server.

=
As to the comments about retrocomputing, just note that the Pi and the= Beaglebone and their ilk are two orders of magnitude cheaper than the comp= uters of the 1990s that are contemporaneous with Gopher, and roughly compar= able in power. Rewinding the protocol stack back to 1992 and building out f= rom there with what we learned in the intervening 23 years is a reasonable = exercise. At minimum it gives us a secure base to build from for April Fool= s.

thanks

Ed
<= div class=3D"gmail_extra">
On Thu, Jun 11, 20= 15 at 3:49 AM, John Levine <johnl@taugh.com> wrote:
>After a message on the gopher-= discuss list I decided to join the
>apps-discuss list and see what I could do for the gopher-ii standardiza= tion
>process.

Hi.=C2=A0 Long time, no see.

> I'm looking at it as a possible lightweight
>information system for Raspberry Pi sized devices (small single board L= inux
>systems, sub $25 delivered cost). IETF has COAP in that space already, = but
>perhaps Gopher and gopher-ii can live there too, if you have a system >constrained enough to be performant on suitable equipment as well as se= cure
>enough because of a deployed base of well-understood and well reviewed = code.

Gee, I wish someone had given us this background a month ago.=C2=A0 = I get
your point, but Raspberry Pi runs linux and it's hard to believe that a lightweight web server like lighttpd wouldn't work perfectly well
and be comparably secure since its code gets a lot of scrutiny.=C2=A0 If you want a client, there's always lynx.

CoAP is intended for really tiny things, with the usual example being
to tell a smart lightbulb to turn itself on.=C2=A0 Gopher seems too heavy for that.

R's,
John



--
Edward Vielmetti=C2=A0+1 734 330 2465

--bcaec52e604f8cd84305183ea580-- From nobody Thu Jun 11 09:32:28 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296D51B3069 for ; Thu, 11 Jun 2015 09:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_IpH-J1AibU for ; Thu, 11 Jun 2015 09:32:25 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 301981B308E for ; Thu, 11 Jun 2015 09:32:22 -0700 (PDT) Received: by wgv5 with SMTP id 5so8344372wgv.1 for ; Thu, 11 Jun 2015 09:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xzaSnYVosf2KXKPDAZq/ym50Oab1vTI5ivcwFgmXHO4=; b=nkqnbbdfsR1UVhB4Z5HiLn9+MhRtcGicrzcThrqP8c9YIZk+qy+m+6mPV+dUTW5Jso G0TTyTnWFDdNUDJSf899ZqTWAhRzB3YLGA1T851dBf6RdIJPYX98aMzVGRWKgQpzX/76 7wKtM6n7wKgfexWFBDSEapappY1FTmeAlME9TYO5Is7zC6VNadMTEOULgMTtJ25OEqy5 Nbbkh2OV8UNIo7XXD8RdGIg8RMPiKt0xlb17K6P9D+m44+BT3hXUZQhVJHR+uidTbv+P wZquUJ/TYOxQBsjrZL6R6eqyY82yHWkUGk57HQvFyy54CvPI0Qmt8LrgMmhs5CokR30Y DYXg== MIME-Version: 1.0 X-Received: by 10.194.109.36 with SMTP id hp4mr17742547wjb.4.1434040340785; Thu, 11 Jun 2015 09:32:20 -0700 (PDT) Received: by 10.27.6.207 with HTTP; Thu, 11 Jun 2015 09:32:20 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Jun 2015 09:32:20 -0700 Message-ID: From: "Murray S. Kucherawy" To: Edward Vielmetti Content-Type: multipart/alternative; boundary=047d7bf10a741b318c05184089d9 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] gopher-ii standardization process & personal introduction X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 16:32:27 -0000 --047d7bf10a741b318c05184089d9 Content-Type: text/plain; charset=UTF-8 Edward, and any other lurkers in general: On Tue, Jun 9, 2015 at 11:31 AM, Edward Vielmetti < edward.vielmetti@gmail.com> wrote: > I'm currently at All Hands Active, a maker space in Ann Arbor, and I'm > subscribing to this list via a daily digest so don't expect more than a > message a day from me. > You don't appear to be subscribed at all, because your messages keep getting caught in moderation. Please make sure you confirm your subscription if you intend to participate. Posts that get stuck in moderation can take a while to get cleared, which messes with thread order, and might even expire in the very rare event that we don't get to them quickly enough. If you need help getting subscribed, please drop a note to appsawg-chairs@ietf.org or apps-discuss-owners@ietf.org. -MSK, apps-discuss moderator --047d7bf10a741b318c05184089d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Edward, and any other lurkers in general:

On Tue, J= un 9, 2015 at 11:31 AM, Edward Vielmetti <edward.vielmetti@gmail.= com> wrote:
I'm currently a= t All Hands Active, a maker space in Ann Arbor, and I'm subscribing to = this list via a daily digest so don't expect more than a message a day = from me.

You don't appear to = be subscribed at all, because your messages keep getting caught in moderati= on.=C2=A0 Please make sure you confirm your subscription if you intend to p= articipate.=C2=A0 Posts that get stuck in moderation can take a while to ge= t cleared, which messes with thread order, and might even expire in the ver= y rare event that we don't get to them quickly enough.

If you need help getting subscribed, please drop a note to appsawg-chairs@ietf.org or apps-discuss-owners@ietf.org.

-MSK, apps-discuss moderator
--047d7bf10a741b318c05184089d9-- From nobody Thu Jun 11 09:38:18 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04391B30D3 for ; Thu, 11 Jun 2015 09:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSNcPB3fWG_d for ; Thu, 11 Jun 2015 09:38:15 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42DF11B30C0 for ; Thu, 11 Jun 2015 09:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t5BGcAxL008686; Thu, 11 Jun 2015 18:38:10 +0200 (CEST) Received: from alma.local (p5DCCC91B.dip0.t-ipconnect.de [93.204.201.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3m6rTZ2HYhz98v2; Thu, 11 Jun 2015 18:38:10 +0200 (CEST) Date: Thu, 11 Jun 2015 18:38:08 +0200 From: Carsten Bormann To: Edward Vielmetti Message-ID: In-Reply-To: References: <20150611074958.9083.qmail@ary.lan> X-Mailer: Airmail (303) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5579b971_3d379458_c064" Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] gopher-ii standardization process & personal introduction X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 16:38:16 -0000 --5579b971_3d379458_c064 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 11 Jun 2015 at 18:29:02, Edward Vielmetti (edward.vielmetti=40gmail.co= m) wrote: =243 ESP8266 (which talks MQTT=C2=A0 just fine, as I understand it, and for which it would be perfectly=C2=A0 cromulent to get a Gopher server running on.) Waste of energy; the ESP8266 runs CoAP just fine as well. cs=3Dcoap.Server() cs:listen(5683) myvar=3D1 cs:var(=22myvar=22) -- get coap://.../v1/v/myvar will return the value of= myvar: 1 Gr=C3=BC=C3=9Fe, Carsten --5579b971_3d379458_c064 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <= body>=0A

=0A


=


Murray & Alexey,
=

I would like to have a 10-minute time slot to present the UATN to o= ur folks in the Prague IETF meeting. 

= I have already proposed an approach to Upload Acceleration Transport Netwo= rk(UATN) for upstream traffics, but the drafts was submitted to the" Trans= port Area Working Group (tsvwg)".  Be= cause, as a CDN-related draft, UATN should belong in the TSV Area . <= /span>This is the link,&n= bsp;h= ttps://datatracker.ietf.org/doc/draft-qin-tsvwg-uatnut/.

Unfortunately, two weeks ago, the IETF Area into w= hich the CDNI WG was recently moved, and the CDNI WG was moved into "Appli= cations and Real-Time" Area. So,IMO, the UATN may belong in= the appsawg.

  

Regards,

Xiaowei Qin



Colleagues,=0AWe have requested our usual APPSAWG=
/APPAREA Monday morning 9:30 slot, with=0Athe usual conflict set, for the =
Prague meeting.=0APlease propose agenda items for this meeting in response=
 to this thread.=0AWe'll have our usual updates from the co-chairs and ADs=
 and will be=0Ainviting chairs of BoFs and newly formed working groups to =
give short=0Apresentations on what's happening during the week.=0AIf you a=
re working on a document already in APPSAWG that requires face time=0Ato r=
esolve some issues, or would like to make or request a presentation on=0Aa=
 particular topic, please let us know as soon as possible.  Our=0Aprelimin=
ary agenda is due to the Secretariat on Monday, July 6th, which is=0Aalso =
the final date to be able to submit drafts to the datatracker before=0Athe=
 meeting.=0AWe will generally only assign meeting time to discuss document=
s that have=0Aalready been introduced to on this list.  The in-person meet=
ings are not=0Aappropriate places to propose brand new work items except i=
n the "any other=0Abusiness" slot at the end.=0APlease email appsawg-chair=
s@tools.ietf.org if you have any questions.=0A-MSK, APPSAWG co-chair
=
=0A
=0A ------=_001_NextPart218255017127_=------ From nobody Fri Jun 26 14:01:19 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6FB1A1A19 for ; Fri, 26 Jun 2015 14:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ko5OcLVeKld for ; Fri, 26 Jun 2015 14:01:15 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25FB91A0419 for ; Fri, 26 Jun 2015 14:01:15 -0700 (PDT) Received: by lagi2 with SMTP id i2so70743073lag.2 for ; Fri, 26 Jun 2015 14:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Sus38zw1Wssjm5PF+pJFC7pNGWfLY9RNiRnZ11kFQIg=; b=aVGB4PcSubVyHJAyXtyOCgeZttrTqxuYHDix0s/5WmbAA4MvQyNxsIjD0XYNdUJTMV JcVfKaQU05XxLKByx+lYmB5OwaD2zL5k/CZ92/eo8V+lEU5eDd5GWALqa9SUrlmZGROo BSjZ87x5PMvLbj9pAVKkeVqFlXEh1GvmKDi9vrGv6u1VysvqLbKR5Cs7b3h/dq6xKT6Z zu1MAAVyO0itE7bHULoeEpJirhNaEGfFSTCL9in0vOFqJIDAeegcXOfddklAAZ0NCPu2 8WPOuftzRHJ6WBb9/qAerDFFgnKsYVV9/NNU7uqF0uyPYgENC8Nwl9JfVggbyo3c4vky PNWg== MIME-Version: 1.0 X-Received: by 10.112.135.131 with SMTP id ps3mr3307880lbb.84.1435352473627; Fri, 26 Jun 2015 14:01:13 -0700 (PDT) Received: by 10.112.137.99 with HTTP; Fri, 26 Jun 2015 14:01:13 -0700 (PDT) In-Reply-To: <558ADE8E.1060407@berkeley.edu> References: <558ABA64.8050604@andrew.cmu.edu> <558ADE8E.1060407@berkeley.edu> Date: Fri, 26 Jun 2015 23:01:13 +0200 Message-ID: From: Melvin Carvalho To: Erik Wilde Content-Type: multipart/alternative; boundary=089e0112c2705172ac0519720a92 Archived-At: Cc: Apps Discuss Subject: Re: [apps-discuss] returning something from http 402 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2015 21:01:17 -0000 --089e0112c2705172ac0519720a92 Content-Type: text/plain; charset=UTF-8 On 24 June 2015 at 18:45, Erik Wilde wrote: > hello melvin. > > On 2015-06-24 07:53, Melvin Carvalho wrote: > >> On 24 June 2015 at 16:10, Ken Murchison > > wrote: >> Perhaps leverage >> https://tools.ietf.org/html/draft-ietf-appsawg-http-problem-00 >> It's great that RDFa is mentioned in the doc. I suspect the >> serializations I would be working with would be JSON-LD and Turtle. >> > > currently, the canonical model is defined in JSON. appendix a talks about > how to represent that model in XML. appendix b talks about "other > metamodels" and mentions RDF in passing, simply as one example of those > other metamodels. it would be possible to add more details about how to use > the canonical model in RDF-land, so that there would be no doubt *how* to > represent the canonical model in RDF. if there's any interest, that's > something that could be done in an additional appendix, and talking about > how that would look in JSON-LD as one RDF representation then also would be > pretty straightforward. > Thanks for getting back! So I raised http 402 with timbl today, to ask the history. He did invent ("scribbled down was his term :)") 402 the idea being that the web should be a platform for both paid and unpaid content. He said he originally envisioned it as being quite important, else it wouldnt have been put before 403! He also said the w3c payments group (either cg/ig/wg there's 3 now!) might be a good place to standardize 402. The document you made seems a good fit, do you have thoughts on: 1. The RFC is 4xx and I'd like to do something 402 specific 2. Thoughts on redirecting to a machine readable representation vs returning a machine readable representtion 3. General thoughts on mime types -- I may be trying to request non JSON paid media e.g. html or video, and the client may not be expecting the mime type it gets -- I really need to think through this point more or make a proof of concept Would love to hear thoughts. If there's a better place to discuss this e.g. the HTTP WG, pls let me know. > > cheers, > > dret. > > -- > erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | > | UC Berkeley - School of Information (ISchool) | > | http://dret.net/netdret http://twitter.com/dret | > --089e0112c2705172ac0519720a92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 24 June 2015 at 18:45, Erik Wilde <dret@berkeley.edu>= wrote:
hello melvin.<= span>

On 2015-06-24 07:53, Melvin Carvalho wrote:
On 24 June 2015 at 16:10, Ken Murchison <murch@andrew.cmu.edu
 <mailto:murch@= andrew.cmu.edu>> wrote:
=C2=A0 =C2=A0 Perhaps leverage
=C2=A0 =C2=A0 https://tools.ietf.org/h= tml/draft-ietf-appsawg-http-problem-00
It's great that RDFa is mentioned in the doc.=C2=A0 I suspect the
serializations I would be working with would be JSON-LD and Turtle.

currently, the canonical model is defined in JSON. appendix a talks about h= ow to represent that model in XML. appendix b talks about "other metam= odels" and mentions RDF in passing, simply as one example of those oth= er metamodels. it would be possible to add more details about how to use th= e canonical model in RDF-land, so that there would be no doubt *how* to rep= resent the canonical model in RDF. if there's any interest, that's = something that could be done in an additional appendix, and talking about h= ow that would look in JSON-LD as one RDF representation then also would be = pretty straightforward.

Thanks for gett= ing back!

So I raised http 402 with tim= bl today, to ask the history.

He did invent ("scribb= led down was his term :)") 402 the idea being = that the web should be a platform for both paid and unpaid content.

=
He said he originally envisioned it as being quite important, el= se it wouldnt have been put before 403!

He also said the w3c p= ayments group (either cg/ig/wg there's 3 now!) might be a good place to= standardize 402.

The document yo= u made seems a good fit, do you have thoughts on:

1. The = RFC is 4xx and I'd like to do something 402 specific
2. T= houghts on redirecting to a machine readable representation vs returning a = machine readable representtion
3. General thoughts on mime ty= pes -- I may be trying to request non JSON paid media e.g. html or video, a= nd the client may not be expecting the mime type it gets -- I really need t= o think through this point more or make a proof of concept

Would love to hear thoughts.=C2=A0 If there's a better place to discu= ss this e.g. the HTTP WG, pls let me know.
=C2=A0

cheers,

dret.

--
erik wilde | mailto:= dret@berkeley.edu=C2=A0 -=C2=A0 tel:+1-510-2061079 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| UC Berkeley=C2=A0 -=C2=A0 School= of Information (ISchool) |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://dret.net/netdret http://t= witter.com/dret |

--089e0112c2705172ac0519720a92-- From nobody Tue Jun 30 16:36:50 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A910E1B2A99; Tue, 30 Jun 2015 16:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSC3vpnkUqU2; Tue, 30 Jun 2015 16:36:36 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6C79D1B2A87; Tue, 30 Jun 2015 16:36:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9B834180470; Tue, 30 Jun 2015 16:33:25 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150630233325.9B834180470@rfc-editor.org> Date: Tue, 30 Jun 2015 16:33:25 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] RFC 7505 on A "Null MX" No Service Resource Record for Domains That Accept No Mail X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 23:36:40 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7505 Title: A "Null MX" No Service Resource Record for Domains That Accept No Mail Author: J. Levine, M. Delany Status: Standards Track Stream: IETF Date: June 2015 Mailbox: standards@taugh.com, mx0dot@yahoo.com Pages: 6 Characters: 12534 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-appsawg-nullmx-10.txt URL: https://www.rfc-editor.org/info/rfc7505 DOI: http://dx.doi.org/10.17487/RFC7505 Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately, this means that the A/AAAA record is taken to be mail server address even when that address does not accept mail. The No Service MX RR, informally called "null MX", formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server; this permits significant operational efficiencies. This document is a product of the Applications Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://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