From internet-drafts@ietf.org Tue Oct 1 23:57:12 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1610121E82C7; Tue, 1 Oct 2013 23:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E392FQi95RXz; Tue, 1 Oct 2013 23:57:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB7521E8281; Tue, 1 Oct 2013 23:56:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131002065659.20697.94865.idtracker@ietfa.amsl.com> Date: Tue, 01 Oct 2013 23:56:59 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-multipart-form-data-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 06:57:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Returning Values from Forms: multipart/form-data Author(s) : Larry Masinter Filename : draft-ietf-appsawg-multipart-form-data-00.txt Pages : 9 Date : 2013-10-01 Abstract: This specification (re)defines the multipart/form-data Internet Media Type, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. It replaces RFC 2388. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-multipart-form-data-00 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 julian.reschke@gmx.de Fri Oct 4 07:26:33 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8120721F9B86 for ; Fri, 4 Oct 2013 07:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.639 X-Spam-Level: X-Spam-Status: No, score=-100.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kcc69-xeu3rS for ; Fri, 4 Oct 2013 07:26:16 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 0558021F9B0D for ; Fri, 4 Oct 2013 07:22:40 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MegbQ-1VCdpD3hyy-00OJID for ; Fri, 04 Oct 2013 16:22:36 +0200 Message-ID: <524ECF1E.2080803@gmx.de> Date: Fri, 04 Oct 2013 16:22:22 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Larry Masinter , "apps-discuss@ietf.org" References: <5249762E.7010206@gmx.de> In-Reply-To: <5249762E.7010206@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:GIEcP+gAvSvlSxQDtehnEHMw+FUyKxw3TnaCflsY1MvBb4RWysa rdypEkCHxM/AvgVrU8oVZy86Mqno5qCXZDiu88EV+tzTDO5wO3A2yYtWQvhQ6g8zkoZeSp4 UNDO4aSNHc2qc640IMLxFSXwm2G4toYsx3MDkYafR1VhAuY/mXW28zhDEDRC5tTlLgLfEwx Pywd/94Eq1wopG78bW/uQ== Subject: Re: [apps-discuss] Unicode normalization and Content-Disposition filename (RFC6266) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Oct 2013 14:26:33 -0000 On 2013-09-30 15:01, Julian Reschke wrote: > ... > Funny enough, this just turned into a product issue for me (hey, paid > work!). > > Interesting links: > > https://bugzilla.mozilla.org/show_bug.cgi?id=695995 and > https://www.w3.org/Bugs/Public/show_bug.cgi?id=14526 > ... I just did some testing, and, indeed, Firefox sends the filename as obtained from the OS (and specified in HTML5), while Chrome normalizes to NFC. Best regards, Julian From nico@cryptonector.com Fri Oct 4 08:17:36 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F216521F9E28 for ; Fri, 4 Oct 2013 08:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1L7EuaKWB2L for ; Fri, 4 Oct 2013 08:17:24 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD4521F9D99 for ; Fri, 4 Oct 2013 08:14:45 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id DB138508064 for ; Fri, 4 Oct 2013 08:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=eOJImS51DkvBlD121TNu LMhC8b4=; b=LYMP+UnMIEjcrZHC1hchAMJJR/icLze/Uf5tsVGP/14x2WEKSITS P1T0Qszs1ejcgXj58UD1caPizJC4qfPU0ViOB3KxgvSa0mYiteguDgMoZP4kUSDv VoBEIXCSJMtky/Skn9rAuk2cfvIp30cK7wUoOD0VGKmeQyRx1CANEy8= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 63CB650808F for ; Fri, 4 Oct 2013 08:14:44 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id w61so4805325wes.31 for ; Fri, 04 Oct 2013 08:14:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mKfTTlf4BeESUmKRbxcVtpLi7h1bMbrzMPityK9prds=; b=iJ11Ig2QXaFmwxjiKRU8KnK4ZybHa3q/YwKdbv6YrRyWRjkY+kqhVl5dbnpTBUtBzn eAlShCeFX9ODMudG2GSYn9WJ8l9FIIV6LZjf0Sh2CtUSrKCkg7FtxBMLeqXKvlYDBs18 v25YMYsDVORUnXW1EYf8NKgZUivN+ycvzcrSnvGE3+j5xotJHv/sOjKdbZ9k4Qp2bVpp xSQSE/QuuUwASqUEjvRTaJW/4zHPUrdQtibAXwfP+PS6VglNbZZgcAs9mzeBCS0r/z4B 1dicXUg1coEtpuI/NI9H4z4/Q0a8KEsxkFzXUT1hptJanEXHgHHXtjYcBh2OB32XNdpZ zo3g== MIME-Version: 1.0 X-Received: by 10.194.21.104 with SMTP id u8mr1999315wje.63.1380899682520; Fri, 04 Oct 2013 08:14:42 -0700 (PDT) Received: by 10.216.165.5 with HTTP; Fri, 4 Oct 2013 08:14:42 -0700 (PDT) Received: by 10.216.165.5 with HTTP; Fri, 4 Oct 2013 08:14:42 -0700 (PDT) In-Reply-To: <524ECF1E.2080803@gmx.de> References: <5249762E.7010206@gmx.de> <524ECF1E.2080803@gmx.de> Date: Fri, 4 Oct 2013 10:14:42 -0500 Message-ID: From: Nico Williams To: Julian Reschke Content-Type: multipart/alternative; boundary=047d7b5d97cb0c184004e7ebc377 Cc: Apps Discuss Subject: Re: [apps-discuss] Unicode normalization and Content-Disposition filename (RFC6266) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Oct 2013 15:17:36 -0000 --047d7b5d97cb0c184004e7ebc377 Content-Type: text/plain; charset=UTF-8 On Oct 4, 2013 11:26 AM, "Julian Reschke" wrote: > > On 2013-09-30 15:01, Julian Reschke wrote: >> >> ... >> Funny enough, this just turned into a product issue for me (hey, paid >> work!). >> >> Interesting links: >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=695995 and >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14526 >> ... > > > I just did some testing, and, indeed, Firefox sends the filename as obtained from the OS (and specified in HTML5), while Chrome normalizes to NFC. Interesting. Because most filesystems are just-don't-normalize-anywhere or just-use-8 and most input modes produce something close to NFC, it helps to normalize to NFC in the clients for some protocols or some filesystems even. I think there's no ideal, but the best combo is probably form-insensitive/preserving on the server, with fallback on normalization to NFC on the client. For NFSv4, for example, knowing what a given filesystem is just-use-8 then the client should normalize to NFC, but if the fs is normalize-to-NFDish or form-insensitive/preserving then the client should not bother normalizing. Is three any reason not to apply this logic to all fileserver protocols? Nico -- --047d7b5d97cb0c184004e7ebc377 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 4, 2013 11:26 AM, "Julian Reschke" <julian.reschke@gmx.de> wrote:
>
> On 2013-09-30 15:01, Julian Reschke wrote:
>>
>> ...
>> Funny enough, this just turned into a product issue for me (hey, p= aid
>> work!).
>>
>> Interesting links:
>>
>> = https://bugzilla.mozilla.org/show_bug.cgi?id=3D695995 and
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=3D14526
>> ...
>
>
> I just did some testing, and, indeed, Firefox sends the filename as ob= tained from the OS (and specified in HTML5), while Chrome normalizes to NFC= .

Interesting.=C2=A0 Because most filesystems are just-don'= ;t-normalize-anywhere or just-use-8 and most input modes produce something = close to NFC, it helps to normalize to NFC in the clients for some protocol= s or some filesystems even.=C2=A0 I think there's no ideal, but the bes= t combo is probably form-insensitive/preserving on the server, with fallbac= k on normalization to NFC on the client.

For NFSv4, for example, knowing what a given filesystem is j= ust-use-8 then the client should normalize to NFC, but if the fs is normali= ze-to-NFDish or form-insensitive/preserving then the client should not both= er normalizing.=C2=A0 Is three any reason not to apply this logic to all fi= leserver protocols?

Nico
--

--047d7b5d97cb0c184004e7ebc377-- From julian.reschke@gmx.de Fri Oct 4 08:28:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5AE21F9A31 for ; Fri, 4 Oct 2013 08:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.639 X-Spam-Level: X-Spam-Status: No, score=-100.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiwUh0pyy0En for ; Fri, 4 Oct 2013 08:28:46 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id CA03621F9B85 for ; Fri, 4 Oct 2013 08:28:26 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MQR3s-1VFyFA2Uvs-00TmM7 for ; Fri, 04 Oct 2013 17:28:24 +0200 Message-ID: <524EDE86.5030605@gmx.de> Date: Fri, 04 Oct 2013 17:28:06 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Nico Williams References: <5249762E.7010206@gmx.de> <524ECF1E.2080803@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:pJn6A9DuE//DZpyVMWWcJHgFnLDFFIwAdZt5DwaYEHXoI/Zd/fr /Lr14qfUz0v54/tGH9pJG+4KKxwvaRLTkO4IjNdHldDnyf7B3799GXrkt75PuOWchtphzZW WQdS4Qdw51AB13WuoZa6gOB3HFDrCqyQHW45T/KGntDgk8OvpRtWdBRa+4zpnG+S6gxg2rG c70k/JWFQyau09y7L9r8Q== Cc: Apps Discuss Subject: Re: [apps-discuss] Unicode normalization and Content-Disposition filename (RFC6266) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Oct 2013 15:28:58 -0000 On 2013-10-04 17:14, Nico Williams wrote: > > On Oct 4, 2013 11:26 AM, "Julian Reschke" > wrote: > > > > On 2013-09-30 15:01, Julian Reschke wrote: > >> > >> ... > >> Funny enough, this just turned into a product issue for me (hey, paid > >> work!). > >> > >> Interesting links: > >> > >> https://bugzilla.mozilla.org/show_bug.cgi?id=695995 and > >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14526 > >> ... > > > > > > I just did some testing, and, indeed, Firefox sends the filename as > obtained from the OS (and specified in HTML5), while Chrome normalizes > to NFC. > > Interesting. Because most filesystems are just-don't-normalize-anywhere > or just-use-8 and most input modes produce something close to NFC, it > helps to normalize to NFC in the clients for some protocols or some > filesystems even. I think there's no ideal, but the best combo is > probably form-insensitive/preserving on the server, with fallback on > normalization to NFC on the client. > ... In WebDAV, if a server preserves "everyting" (== allows both NFC and NFD in the same folder), clients get very confused (at least Mac OSX). Wouldn't it help if the server always normalized to NFC? Best regards, Julian From James.H.Manger@team.telstra.com Fri Oct 4 09:34:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A9421F9A90 for ; Fri, 4 Oct 2013 09:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.754 X-Spam-Level: X-Spam-Status: No, score=0.754 tagged_above=-999 required=5 tests=[AWL=-1.245, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_54=0.6, MANGLED_FORM=2.3, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaxFGynTJvp7 for ; Fri, 4 Oct 2013 09:34:20 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5B15021F997D for ; Fri, 4 Oct 2013 09:34:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,1034,1371045600"; d="scan'208";a="163949178" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 05 Oct 2013 02:34:11 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7217"; a="163742721" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcdvi.tcif.telstra.com.au with ESMTP; 05 Oct 2013 02:34:11 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Sat, 5 Oct 2013 02:34:10 +1000 From: "Manger, James H" To: "Murray S. Kucherawy" , IETF Apps Discuss Date: Sat, 5 Oct 2013 02:34:08 +1000 Thread-Topic: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-json-merge-patch Thread-Index: Ac6z2mRIcK8FhpN5TzytZyPRI6gDJwNMYA0Q Message-ID: <255B9BB34FB7D647A506DC292726F6E11531A56CC0@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-json-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Oct 2013 16:34:26 -0000 Q29tbWVudHMgb24gZHJhZnQtaWV0Zi1hcHBzYXdnLWpzb24tbWVyZ2UtcGF0Y2gtMDE6DQoNCjEu IENoYW5nZSB0aGUgdGl0bGUuDQpGcm9tOiAiVGhlIGFwcGxpY2F0aW9uL2pzb24tbWVyZ2UtcGF0 Y2ggTWVkaWEgVHlwZSINClRvICA6ICJKU09OIE1lcmdlLVBhdGNoIG9wZXJhdGlvbiINCkhvdyB0 aGUgbWVyZ2UtcGF0Y2ggb3BlcmF0ZXMgaXMgdGhlIG1vc3QgaW1wb3J0YW50IGFzcGVjdC4gVGhl IG1lZGlhIHR5cGUgaXMgYSB1c2VmdWwsIGJ1dCBzZWNvbmRhcnksIGFzcGVjdC4NCg0KMi4gQ2hh bmdlIHRoZSBtZWRpYSB0eXBlLg0KRnJvbTogYXBwbGljYXRpb24vanNvbi1tZXJnZS1wYXRjaA0K VG8gIDogYXBwbGljYXRpb24vbWVyZ2UtcGF0Y2granNvbg0KVGhlICIranNvbiIgc3VmZml4IGlu ZGljYXRlcyB0aGUgY29udGVudCBpcyBKU09OLg0KDQozLiBLZWVwIG9ubHkgb25lIGluaXRpYWwg ZXhhbXBsZS4NClNlY3Rpb24gMSAiSW50cm9kdWN0aW9uIiBoYXMgYW4gZXhhbXBsZSBzbyBzZWN0 aW9uIDIgZG9lc24ndCBuZWVkIGFub3RoZXIuIERvbid0IG1peCBhbiBleGFtcGxlIGFuZCBwcm9j ZXNzaW5nIHJ1bGVzIGluIHRoZSBzYW1lIHNlY3Rpb24uDQoNCjQuIERlZmluZSB0aGUgb3BlcmF0 aW9uIGFzIGFwcGx5aW5nIHRvIGEgSlNPTiB0YXJnZXQuDQpQYWdlIDQgdGFsa3MgYWJvdXQgdW5k ZXJzdGFuZGluZyB0aGUgInRhcmdldCByZXNvdXJjZSBtZWRpYSB0eXBlIGFuZCB0aGUgdW5kZXJs eWluZyBkYXRhIG1vZGVsIG9mIHRoZSB0YXJnZXQgcmVzb3VyY2UiIGFzIHRob3VnaCB0aGlzIEpT T04gTWVyZ2UtUGF0Y2ggY2FuIGFwcGx5IHRvIHRhcmdldHMgb3RoZXIgdGhhbiBKU09OLiBUaGlz IGlzIG5vdCB3b3J0aCBtZW50aW9uaW5nOyBpdCBvbmx5IGNvbmZ1c2VzLiANClRoaXMgc3BlYyBz aG91bGQgb25seSBkZWZpbmUgYSBKU09OIHBhdGNoIG9wZXJhdGluZyBvbiBhIEpTT04gdGFyZ2V0 Lg0KDQo1LiBUZXJtaW5vbG9neS4NCkRlc2NyaWJlIHRoZSBvcGVyYXRpb24gaW4gdGVybXMgb2Yg J3BhdGNoJyBhbmQgJ3RhcmdldCcgSlNPTiB2YWx1ZXMsIG5vdCAidGhlIGRhdGEgcHJvdmlkZWQg aW4gdGhlIHBheWxvYWQiIGFuZCAidGFyZ2V0IHJlc291cmNlIi4NCg0KNi4gU2VwYXJhdGUgdGhl IGxvZ2ljYWwgb3BlcmF0aW9uIGZyb20gdGhlIEhUVFAgUEFUQ0ggcmVxdWVzdC4NClNlY3Rpb24g MiBjYW4gZGVzY3JpYmUgdGhlIHJ1bGVzIGZvciBhcHBseWluZyAncGF0Y2gnIChhIEpTT04gdmFs dWUpIHRvICd0YXJnZXQnIChhIEpTT04gdmFsdWUpIHRvIHByb2R1Y2UgJ3Jlc3VsdCcgKGEgSlNP TiB2YWx1ZSkuDQpTZWN0aW9uIDMgY2FuIGRlc2NyaWJlIGhvdyB0byB1c2UgdGhpcyB3aXRoIEhU VFAuIFRoYXQgaXMsIHdpdGggUEFUQ0ggYXMgdGhlIEhUVFAgbWV0aG9kLCBhcHBsaWNhdGlvbi9t ZXJnZS1wYXRjaCtqc29uIGFzIHRoZSBtZWRpYSB0eXBlLCAncGF0Y2gnIGFzIHRoZSBib2R5LCBh bmQgJ3RhcmdldCcgaXMgdGhlIHJlc291cmNlLg0KDQo3LiBEZWZpbmVzIHJ1bGVzIGZvciAncGF0 Y2gnIGFuZCAndGFyZ2V0JyBiZWluZyBhbnkgSlNPTiAqdmFsdWUqIChub3QganVzdCBvYmplY3Rz IGFuZCBhcnJheXMpLg0KDQo4LiBEb24ndCBodW50IG91dCBudWxscyBpbiBhcnJheXMuDQpUcmVh dCBhbnkgYXJyYXkgaW4gJ3BhdGNoJyBhcyBvcGFxdWUuIEl0IGlzIHBvaW50bGVzcyB0byByZXF1 aXJlIGEgcHJvY2Vzc29yIHRvIHdhbGsgdGhyb3VnaCBhbiBhcnJheSBpbiAncGF0Y2gnIGxvb2tp bmcgZm9yIG51bGxzLg0KUmVtb3ZlIHRoZSB3aG9sZSBwYXJhZ3JhcGggd2l0aCAiSlNPTiBBcnJh eXMgY29udGFpbmVkIHdpdGhpbiB0aGUgbWVyZ2UgcGF0Y2ggZG9jdW1lbnQgU0hPVUxEIE5PVCBj b250YWluIG51bGwgbWVtYmVycyIuIFRoZSBwYXJhZ3JhcGggc2F5cyBudWxscyBpbnNpZGUgYXJy YXlzICJNVVNUIGJlIGlnbm9yZWQiLCBidXQgcmVxdWlyZXMgdGhleSBiZSBodW50ZWQgb3V0IGFu ZCByZW1vdmVkLCB3aGljaCBpcyBoYXJkbHkgaWdub3JpbmcgdGhlbS4NCg0KOS4gUmVtb3Zpbmcg YSBub24tZXhpc3RlbnQgbWVtYmVyIGlzIG5vdCBhbiBlcnJvci4NCkNoYW5nZSAiU0hPVUxEIE5P VCIgdG8gIk1VU1QgTk9UIiBpbiAidGhlIHNlcnZlciBTSE9VTEQgTk9UIGNvbnNpZGVyIHRoZSBy ZXF1ZXN0IHRvIGJlIGluIGVycm9yIi4gQmV0dGVyIHN0aWxsLCBpbiB0aGUgcnVsZXMgZXhwbGlj aXRseSBjb3ZlciB0aGUgY2FzZSBvZiBhICdwYXRjaCcgbWVtYmVyIHdpdGggdmFsdWUgbnVsbCBh bmQgbm8gY29ycmVzcG9uZGluZyBtZW1iZXIgaW4gJ3RhcmdldCcgKGllIGl0IGlzIGEgbm8gb3Ap Lg0KDQoxMC4gUmVtb3ZlIGNoYXJzZXQgcGFyYW1ldGVyLg0KQ2FuJ3Qgd2Ugc2F5IGFwcGxpY2F0 aW9uL21lcmdlLXBhdGNoK2pzb24gaWRlbnRpZmllcyBjb250ZW50IHRoYXQgaXMgYSBVVEYtOCBl bmNvZGVkIEpTT04gdmFsdWUsIGluc3RlYWQgb2YgYWxsb3dpbmcgYSBjaGFyc2V0IHBhcmFtZXRl ci4NCkFjdHVhbGx5LCBJIGd1ZXNzIHdlIHNob3VsZCBkbyB3aGF0ZXZlciBpcyBkZWZpbmVkIGZv ciAiK2pzb24iIG1lZGlhIHR5cGVzLg0KDQoxMS5TZWN1cml0eSBDb25zaWRlcmF0aW9ucy4NClRo ZSBzcGVjIGRlZmluZXMgdGhlIGNoYW5nZXMuIFJlbW92ZSB0aGUgcGFyYWdyYXBoIGFib3V0IHRo ZSBzZXJ2ZXIgZGV0ZXJtaW5pbmcgdGhlIHNwZWNpZmljIHNldCBvZiBjaGFuZ2Ugb3BlcmF0aW9u cyB0byBiZSBhcHBsaWVkLg0KDQoxMi4gTW9yZSBzdWNjaW5jdCBleGFtcGxlIEphdmFTY3JpcHQg aW1wbGVtZW50YXRpb24uDQpmdW5jdGlvbiBtZXJnZShvcmlnLCBwYXRjaCkgew0KCXZhciByZXN1 bHQ7DQoJaWYgKHBhdGNoID09PSBudWxsKSB7DQoJCS8vIGxlYXZlIHJlc3VsdCB1bmRlZmluZWQN Cgl9DQoJZWxzZSBpZiAodHlwZW9mIHBhdGNoID09PSAnc3RyaW5nJyB8fA0KCQl0eXBlb2YgcGF0 Y2ggPT09ICdudW1iZXInIHx8DQoJCXR5cGVvZiBwYXRjaCA9PT0gJ2Jvb2xlYW4nIHx8DQoJCUFy cmF5LmlzQXJyYXkocGF0Y2gpKQ0KCXsNCgkJcmVzdWx0ID0gcGF0Y2g7DQoJfQ0KCWVsc2UgeyAv LyBwYXRjaCBpcyBhbiBvYmplY3QNCgkJcmVzdWx0ID0ge307DQoJCWlmIChvcmlnIGluc3RhbmNl b2YgT2JqZWN0ICYmICFBcnJheS5pc0FycmF5KG9yaWcpKSB7DQoJCQlmb3IgKG0gaW4gb3JpZykN CgkJCQlyZXN1bHRbbV0gPSBvcmlnW21dOw0KCQl9DQoJCWZvciAobSBpbiBwYXRjaCkgew0KCQkJ cmVzdWx0W21dID0gbWVyZ2UocmVzdWx0W21dLCBwYXRjaFttXSk7DQoJCX0NCgl9DQoJcmV0dXJu IHJlc3VsdDsNCn0NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQoNCkZyb206IGFwcHMtZGlzY3Vzcy1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBNdXJyYXkgUy4gS3VjaGVyYXd5DQpTZW50OiBXZWRuZXNkYXksIDE4IFNlcHRl bWJlciAyMDEzIDU6MTYgQU0NClRvOiBJRVRGIEFwcHMgRGlzY3Vzcw0KU3ViamVjdDogW2FwcHMt ZGlzY3Vzc10gV29ya2luZyBHcm91cCBMYXN0IENhbGw6IGRyYWZ0LWlldGYtYXBwc2F3Zy1qc29u LW1lcmdlLXBhdGNoDQoNClRoaXMgbm90ZSBiZWdpbnMgV29ya2luZyBHcm91cCBMYXN0IENhbGwg Zm9yIGRyYWZ0LWlldGYtYXBwc2F3Zy1qc29uLW1lcmdlLXBhdGNoLCBlbmRpbmcgT2N0b2JlciA0 LCAyMDEzLg0KUGxlYXNlIHJldmlldyB0aGUgZG9jdW1lbnQgYW5kIHBvc3QgcmV2aWV3IGNvbW1l bnRzIHRvIHRoaXMgbGlzdC7CoCBQbGVhc2UgaW5kaWNhdGUgaW4geW91ciByZXBseSB3aGV0aGVy IHlvdSBzdXBwb3J0IHB1YmxpY2F0aW9uIGluIGl0cyBjdXJyZW50IGZvcm0sIHdpdGggeW91ciBj b25zdHJ1Y3RpdmUgY29tbWVudHMgYWNjb21tb2RhdGVkLCBvciBpZiBpdCBuZWVkcyBtb3JlIGRl dmVsb3BtZW50LsKgIEEgc2ltcGxlICIrMSIgaXMgbm90IGVzcGVjaWFsbHkgdXNlZnVsLsKgIFRo ZSBtb3JlIGRldGFpbGVkIHlvdXIgcmV2aWV3IGNvbW1lbnRzIGFyZSwgdGhlIG1vcmUgdXNlZnVs IHRoZXkgYXJlLg0KV2UgYWxzbyBuZWVkIHRvIHNlZSBlbm91Z2ggb2YgdGhlc2UgdG8gYmUgYWJs ZSB0byBzYXkgdW5zYXJjYXN0aWNhbGx5IHRoYXQgdGhlIGRvY3VtZW50IGhhcyBjb25zZW5zdXMg c3VwcG9ydCBvZiB0aGUgd29ya2luZyBncm91cC4NClRoYW5rcywNCi1NU0ssIEFQUFNBV0cgY28t Y2hhaXINCg== From ht@inf.ed.ac.uk Fri Oct 4 11:00:12 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABDA21F9D99 for ; Fri, 4 Oct 2013 11:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WoVRFS9LGyD for ; Fri, 4 Oct 2013 11:00:07 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id CF07921F9D95 for ; Fri, 4 Oct 2013 11:00:00 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id r94HxhPL000916 for ; Fri, 4 Oct 2013 18:59:49 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r94HxgUo005443 for ; Fri, 4 Oct 2013 18:59:42 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r94HxgsQ023447 for ; Fri, 4 Oct 2013 18:59:42 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id r94Hxfa5023443; Fri, 4 Oct 2013 18:59:41 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: apps-discuss@ietf.org References: From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 04 Oct 2013 18:59:41 +0100 In-Reply-To: (Henry S. Thompson's message of "Tue\, 24 Sep 2013 10\:19\:08 +0100") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Subject: Re: [apps-discuss] Priority of in-band vs. out-of-band encoding information X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Oct 2013 18:00:12 -0000 Trying again with a simpler question: Is anyone aware of any media-type registration or other spec. which discusses the status of a Mime entity which a) begins with a BOM; b) has an associated charset param which is incompatible with that BOM ? ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From derhoermi@gmx.net Fri Oct 4 11:26:17 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A0321F9E00 for ; Fri, 4 Oct 2013 11:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.775 X-Spam-Level: X-Spam-Status: No, score=-0.775 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4c5RNwAdrHp for ; Fri, 4 Oct 2013 11:26:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id B17D621F9DC7 for ; Fri, 4 Oct 2013 11:26:04 -0700 (PDT) Received: from netb.Speedport_W_700V ([91.35.57.193]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0LhCDT-1WCpXu1179-00oUxT for ; Fri, 04 Oct 2013 20:26:01 +0200 From: Bjoern Hoehrmann To: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 04 Oct 2013 20:25:58 +0200 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:A8UWJtAc+q1ToJuBhcOVHcwFgorWftsUetFiHNFxLydKDwEvdKD kYuLwVppyooxjgKKTUOHS8lXyPbxjaU9DTgpEFx5tDe4W/xgm89c5T1BC+c3KjW2Upfb8aY 8X85sJmaBiNGJ6PWVclb+ZZiBLm+EjeutSMm7PaDLzC3FI4xLqfz1lahlmkpCD1SUS8RQRb p4ixujGv0LQxd9kY7tu+g== Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Priority of in-band vs. out-of-band encoding information X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Oct 2013 18:26:17 -0000 * Henry S. Thompson wrote: >Trying again with a simpler question: > >Is anyone aware of any media-type registration or other spec. which >discusses the status of a Mime entity which > a) begins with a BOM; > b) has an associated charset param which is incompatible with that > BOM >? A few individuals employed by browser vendors have decided some time ago that Unicode signatures should override higher level meta data; that is the opposite of what had been unanimity before then. This should already be implemented in some of their products for formats like XML, CSS, and more. What the XML specification or RFC3023bis or the IETF might have to say on the matter is of no concern to them. I find the reasoning behind their decision unpersuasive and dangerous, but I have not seen anyone else having a problem with it, neither technically nor procedurally, not as far as I can remember anyway. The CSS specifications are an example of the kind you seek. My RFC 4329 would be another (with caveats). An example for a format that ostensibly and explicitly disallows BOMs is JSON as defined in RFC 4627. Many old formats let the charset override inline markers by virtue of the inline markers being added later, HTML 4.01 for instance does discuss BOMs, but limits their effect to content labeled as "UTF-16" without indication of the byte order. Historically, you probably encounter different approaches after the XML specification got modified to clarify the status of the UTF-8 Unicode signature. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From superuser@gmail.com Fri Oct 4 12:19:12 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF9D21F9AB4 for ; Fri, 4 Oct 2013 12:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I76JZWRi+XoJ for ; Fri, 4 Oct 2013 12:19:12 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id AB4E321F9A2E for ; Fri, 4 Oct 2013 12:19:11 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id q59so4191952wes.39 for ; Fri, 04 Oct 2013 12:19:11 -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=F+ivfap9FEFvNCWIRRyqDraHXdOzg91PD94xFr7gmM0=; b=oEpsKXBEtQ4ClIGA09lpVzFaAHfYb+IeLqEDbNlLxtTCXKA75b8PGWj6bw5jn6eJmR cDbYEIrNIBV9jtki1nK89X/1bxVrP4ejeysiAMiOFOYKe9Szu1vUgaeGNOzJ0sYD+1ya mbMEE7qWezb7ztQbQnmrOeCOv6vWS7tC9QDR3Y3vLvMw2bfeLgKgs+R4RjUk0uHH3eTp Tmj5ihgq6rB1RhdJ9Su1Q2xPEZtcUSIJEnAqlS/YTtqM+/R2bm72ttHm50uW5OWIzYyU tmWaIp1yLp5tVY1Sy+GL4vsxQxxLhVlBBhleROOE4ji34bdmW09i/FkNnaL8+IjykCPN FmPw== MIME-Version: 1.0 X-Received: by 10.180.189.132 with SMTP id gi4mr8746482wic.19.1380914350962; Fri, 04 Oct 2013 12:19:10 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Fri, 4 Oct 2013 12:19:10 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Oct 2013 12:19:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c352945ac59604e7ef2d04 Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-json-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Oct 2013 19:19:12 -0000 --001a11c352945ac59604e7ef2d04 Content-Type: text/plain; charset=ISO-8859-1 A quick reminder that this Working Group Last Call ends today. So far there's been one review on this thread, which is hardly enough to be able to send it to the IESG. Could we please get some more eyes on this and some substantive review comments? -MSK On Tue, Sep 17, 2013 at 12:16 PM, Murray S. Kucherawy wrote: > This note begins Working Group Last Call for > draft-ietf-appsawg-json-merge-patch, ending October 4, 2013. > > Please review the document and post review comments to this list. Please > indicate in your reply whether you support publication in its current form, > with your constructive comments accommodated, or if it needs more > development. A simple "+1" is not especially useful. The more detailed > your review comments are, the more useful they are. > > We also need to see enough of these to be able to say unsarcastically that > the document has consensus support of the working group. > > Thanks, > > -MSK, APPSAWG co-chair > > --001a11c352945ac59604e7ef2d04 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
A quick reminder that this Working Group Last Call en= ds today.=A0 So far there's been one review on this thread, which is ha= rdly enough to be able to send it to the IESG.=A0 Could we please get some = more eyes on this and some substantive review comments?

-MSK


On Tue, Sep 17, 2013 at 12:16 PM, Murray S. Kucherawy <super= user@gmail.com> wrote:
This no= te begins Working Group Last Call for draft-ietf-appsawg-json-merge-patch, = ending October 4, 2013.

Please review the document and post review comments to this list.= =A0 Please indicate in your reply whether you support publication in its cu= rrent form, with your constructive comments accommodated, or if it needs mo= re development.=A0 A simple "+1" is not especially useful.=A0 The= more detailed your review comments are, the more useful they are.

We also need to see enough of these to be able to say unsarcastic= ally that the document has consensus support of the working group.

<= /div>Thanks,

-MSK, APPSAWG co-chair


--001a11c352945ac59604e7ef2d04-- From nico@cryptonector.com Fri Oct 4 13:24:13 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE2421F9DF6 for ; Fri, 4 Oct 2013 13:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSQJ1WgFNrJQ for ; Fri, 4 Oct 2013 13:24:08 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 172BE21F9E02 for ; Fri, 4 Oct 2013 13:24:07 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 6160F508091 for ; Fri, 4 Oct 2013 13:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=+xI2/ewfdOxvGf7wW9Wi DSsWqUQ=; b=tBKFwjlDMBAONHN29brLdS77GHmuy4XIFnn2jCxaGiKfIOB52u26 Dh3Gkd3+zQYktJp45Dbsd3BYdGpXA1uFevAdlwQgE/qGzDI6Jp+v3DILohWV8VfM O0ehD+4nXYLzI2hLCcFOfoXOsOG/IktBIUECnU0QcOHgWmnCZd9lVto= Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id DFFA650808F for ; Fri, 4 Oct 2013 13:24:06 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p61so5300155wes.12 for ; Fri, 04 Oct 2013 13:24:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xsaKAUCeZrzUBRFoxaLXQ3Hanj+NrxF2lWkwq+UdMNg=; b=KnP6VueRunO3fey6g5WJQ2G+aURyDXUX3IVnQzgGHNOxH11NUGWItUZWPIVIoMS3nv Lb5efDFTz5rB81V8aImH1AL/jtBpcLV5Rmsd7i0o3aVRpi3/l91YpEptNgUP2J/gJasL UyNUDbReqv+ymQSJLjIa5ECeLO34tJDHe0ZR81mAY7aRCuLzhT+00j2ll6hGO1lxfCqj /uy4h70hroS3bHSaOteEbHoSHDDb358i5WoOpR5dHNIQXAnokVzbJQzr/KdCmJ1zMWy5 7FXoddfxVbqva2fyz7DauffJwf1MpyJf8s5les4/69OV1AxnSEBgC7Gci3DtnwlRRQgW GnAg== MIME-Version: 1.0 X-Received: by 10.180.107.167 with SMTP id hd7mr9126723wib.13.1380918245354; Fri, 04 Oct 2013 13:24:05 -0700 (PDT) Received: by 10.216.165.5 with HTTP; Fri, 4 Oct 2013 13:24:05 -0700 (PDT) In-Reply-To: <524EDE86.5030605@gmx.de> References: <5249762E.7010206@gmx.de> <524ECF1E.2080803@gmx.de> <524EDE86.5030605@gmx.de> Date: Fri, 4 Oct 2013 15:24:05 -0500 Message-ID: From: Nico Williams To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Cc: Apps Discuss Subject: Re: [apps-discuss] Unicode normalization and Content-Disposition filename (RFC6266) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Oct 2013 20:24:13 -0000 On Fri, Oct 4, 2013 at 10:28 AM, Julian Reschke wrote: > On 2013-10-04 17:14, Nico Williams wrote: >> Interesting. Because most filesystems are just-don't-normalize-anywhere >> or just-use-8 and most input modes produce something close to NFC, it >> helps to normalize to NFC in the clients for some protocols or some >> filesystems even. I think there's no ideal, but the best combo is >> probably form-insensitive/preserving on the server, with fallback on >> normalization to NFC on the client. >> ... > > In WebDAV, if a server preserves "everyting" (== allows both NFC and NFD in > the same folder), clients get very confused (at least Mac OSX). Wouldn't it > help if the server always normalized to NFC? We thought about it long and very carefully for ZFS and we settled on form-insensitive/preserving as the most interoperable behavior ("f-i/p"). We did that specifically because of HFS+'s impedance mismatch with input modes and the fact that clients in general did not, do not, and really, still cannot be counted on to normalize or otherwise implement f-i/p behavior with decent performance (of course). Of course, the server could normalize to NFC, as you suggest. Both options, I think, can be said to create some surprise (i.e., to violate POSIX), but ZFS has had this for many years now and no one ever complained (except about the Apple port, which was changed to match HFS+'s behavior). Whereas people do notice problems caused by HFS+ -- i.e., we know that normalize on CREATE, at least if it's to any form other than that produced by input modes, is surprising. F-i/p behavior happens only violates POSIX in the same sort of way as case-insensitive/preserving behavior would: by creating apparent aliases that are neither symlinks nor hardlinks. Normalizing on CREATE has a different surprise: that names you create don't appear when you list a directory back. I think f-i/p is less surprising than normalization on CREATE is, and I think the HFS+/ZFS experience backs this up. Of course, it might be that normalization to NFC on CREATE is also not surprising, and we don't have enough experience to back that up. But if it works it's only because it matches input modes, and therein lies a problem: input modes don't produce NFC, they produce something close to NFC. Worse, different OSes/input modes may produce different forms for the same names. Normalizing on CREATE to *any* form might well have all of the problems that HFS+'s normalization to NFD(ish) has. My conclusion (biased by our experience with ZFS and my then-advocacy for f-i/p behavior) is that f-i/p is the best solution. It can only be implemented at the filesystem though -- not the fileserver, not the "VFS" (where there is one) on the server, and certainly not the client. IF f-i/p is simply not available then the next best choice is to normalize on CREATE to either NFC or a form derived from common input mode output forms, and then you get to figure out which of client and/or server should do *that*. BTW, note that f-i/p at the filesystem and normalization on CREATE at the client and/or server are not mutually exclusive. Nico -- From nico@cryptonector.com Fri Oct 4 13:27:53 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C4521F9E40 for ; Fri, 4 Oct 2013 13:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpj+rUAVFF+n for ; Fri, 4 Oct 2013 13:27:48 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2C921F9E2B for ; Fri, 4 Oct 2013 13:27:48 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 3000E2007F20A for ; Fri, 4 Oct 2013 13:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=1mnRr/L96cGabfxoLQTb y2YZIX4=; b=em2v+zhS52xIhaFIY+40xJKMBHiftaoVSmpBiMr1QYOVlf+KkYGi KrBgCq4t3JX8sFNDvvaLu9A16SQQVAhS0urLJK+obww3e22wj12+13dD1TNkGI1A JDD+lC2oiJfDjURlCQHaR85sE47QSYMUQ81dJMS0ayRKJIfU5Q8DqWU= Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPSA id CB8342007F209 for ; Fri, 4 Oct 2013 13:27:47 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id l18so4777745wgh.16 for ; Fri, 04 Oct 2013 13:27:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WpgOfwmQt1brJQKpLqueshaeGM875uTUQKEBKtXa6JU=; b=lGqPSdmudHT4g+bMqkY8ujcdH2WOAdAlCCLjr89aMdN9oA5uFtzEayneTBcDRDKY0J 3z3JEJZeY9VNh7faPMw3akaZbsRZ+uJq4OlwheCd1IihyKb4TeQ94rQNP4jM1Hyf2+df FHp5C4fbHSNEOTnXOaoF9LUbyzGLn3PBdQOwRKXlQApaQgCrepEpNJxhfv/QWmG+miQv r88PkMc2PNWMtQuVHx7deIfEVg01e9ouGFPYI7gCxsqABFAWwbwMD+E8npsm3LHNNNYN dlH//AusnAzhRRIGeWUqwhoG2wdjpnW5BRAVGMj1B5otOVd9cqMk4BdKzZiWDgamgp0f whAw== MIME-Version: 1.0 X-Received: by 10.180.73.239 with SMTP id o15mr8911189wiv.36.1380918466355; Fri, 04 Oct 2013 13:27:46 -0700 (PDT) Received: by 10.216.165.5 with HTTP; Fri, 4 Oct 2013 13:27:46 -0700 (PDT) In-Reply-To: References: <5249762E.7010206@gmx.de> <524ECF1E.2080803@gmx.de> Date: Fri, 4 Oct 2013 15:27:46 -0500 Message-ID: From: Nico Williams To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Cc: Apps Discuss Subject: Re: [apps-discuss] Unicode normalization and Content-Disposition filename (RFC6266) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Oct 2013 20:27:53 -0000 On Fri, Oct 4, 2013 at 10:14 AM, Nico Williams wrote: > ... > For NFSv4, for example, knowing what a given filesystem is just-use-8 then > the client should normalize to NFC, but if the fs is normalize-to-NFDish or > form-insensitive/preserving then the client should not bother normalizing. > Is three any reason not to apply this logic to all fileserver protocols? Right, I forgot, there is a reason not to apply this willy-nilly: the client doesn't always know its local inputs' codeset/encoding. In particular most NFS/AFS/Lustre/... clients have no clue what locale user-land is running. However, client-side normalization on CREATE could be recommended when: a) the filesystem (note: not the server) advertises that it wants only Unicode, and b) the filesystem advertises that it does nothing about normalization. Nico -- From ned.freed@mrochek.com Fri Oct 4 14:01:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8E021F9E02 for ; Fri, 4 Oct 2013 14:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBdFmc0humNV for ; Fri, 4 Oct 2013 14:01:18 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id A890521F9E00 for ; Fri, 4 Oct 2013 14:01:15 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OZ6SJ494S0005I6U@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 4 Oct 2013 13:57:40 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OZ6IG5K1XC00004S@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 4 Oct 2013 13:57:37 -0700 (PDT) Message-id: <01OZ6SJ2IZWK00004S@mauve.mrochek.com> Date: Fri, 04 Oct 2013 13:57:04 -0700 (PDT) From: Ned Freed To: "apps-discuss@ietf.org" Subject: [apps-discuss] Request for additional reviews of draft-ietf-appsawg-sieve-duplicate X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Oct 2013 21:01:23 -0000 I'd like to get this into WGLC soon, so some additional reviews would be helpful. Ned From superuser@gmail.com Fri Oct 4 16:08:40 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621D321F9AE3 for ; Fri, 4 Oct 2013 16:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGF6pUCZ3UNe for ; Fri, 4 Oct 2013 16:08:39 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D384021F9A59 for ; Fri, 4 Oct 2013 16:08:38 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id p61so5284568wes.16 for ; Fri, 04 Oct 2013 16:08:36 -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=b4AC+MFGH6gf32tz2JqFTAIoRDVfxielRSyq8Iu7y24=; b=Eb8WJigEtXTOgobALwwAp6+TeNYC572SVzy7ozpcmLTvGgwsOiQuKhTBVKrUf2HoWa kx7Eh16+zQGwlHoFizdgh8NZzJ44XMveNnsQ1HSxukx/dVThGRJ6QogDQCnjee1eJ0qX 8MdHjEBUMZinBaZ3IEPdDZfczfZHUoeOvmZlyCpzd4/xIO1Njflszgi6Knq5aPkXosdU LGuUcjEirwbdOpTSeD+gSTE2tevSVZDT1J0y74BPbPcTGOWDq9lLdFMDeb5twPJvku0Q tq8Vuv7sHIN/FKWdOsgS7Cisofom9bpfrD1Mu4f42yEIDWhqEhBajr+IzlA8hlEXH4vX LKNA== MIME-Version: 1.0 X-Received: by 10.180.72.226 with SMTP id g2mr9345845wiv.52.1380928116664; Fri, 04 Oct 2013 16:08:36 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Fri, 4 Oct 2013 16:08:36 -0700 (PDT) In-Reply-To: <20131004173149.22991.14931.idtracker@ietfa.amsl.com> References: <20131004173149.22991.14931.idtracker@ietfa.amsl.com> Date: Fri, 4 Oct 2013 16:08:36 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d043890eddaaf7104e7f261cf Subject: [apps-discuss] Fwd: NOMCOM 2013 - Second Call for Nominations - two weeks left X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Oct 2013 23:08:40 -0000 --f46d043890eddaaf7104e7f261cf Content-Type: text/plain; charset=ISO-8859-1 ---------- Forwarded message ---------- From: NomCom Chair 2013 Date: Fri, Oct 4, 2013 at 10:31 AM Subject: NOMCOM 2013 - Second Call for Nominations - two weeks left To: IETF Announcement List Cc: IETF Discuss List Nominations for the IESG, IAB, and IAOC are due to the Nomcom by Friday, 18 October, 2013. Is there someone you work with at IETF who has leadership potential and a growing track record? Please read the Nomcom call for nominations and consider nominating her or him. Or several folks! Deadline for nominations is October 18. Nominate soon to give your nominee(s) plenty time to fill in the questionnaire. Information about the desired expertise for positions is here: https://datatracker.ietf.org/nomcom/2013/expertise Lots more, including which positions are open, how to make a nomination, and how to send us your feedback on the desired expertise, follows. IETFers, let's hear from you! Make nominations, accept nominations! If you have any questions about the process, feel free to get in touch with me. Best regards, Allison for the Nomcom Allison Mankin Nomcom Chair 2013-14 ----- The Info You Need for Nominating ----- The 2013-14 Nominating Committee (Nomcom) is seeking nominations from now until October 18, 2013. The open positions being considered by this year's Nomcom can be found later in this section, and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2013/ Nominations may be made by selecting the Nominate link at the top of the Nomcom 2013 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2013/nominate/ Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ Nominations may also be made by email to nomcom13 at ietf.org. If you nominate by email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you use email, please use a separate email for each person you nominate, and for each position (if you are nominating one person for multiple positions). Self-nomination is welcome! No need to be shy. Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. As stated in RFC 5680: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. In all other ways, the confidentiality requirements of RFC 3777/BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the Nomcom on or before October 18, 2013. Please submit your nominations as early as possible for the sake of your nominees, as we've set the questionnaire submission deadline for October 25, 2013. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which we are accepting nominations: IAOC Chris Griffiths IAB Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF. Also, please give serious consideration to accepting nominations you receive. The summaries of the desired expertise for the positions, developed by the respective bodies, are found at: https://datatracker.ietf.org/nomcom/2013/expertise/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. You can send us email about this to nomcom13 at ietf.org, and we will use this feedback actively. Thank you for your help in nominating a great pool of strong and interesting nominees! --f46d043890eddaaf7104e7f261cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


---------- Forwarded me= ssage ----------
From: NomCom Chair 2013 <nomc= om-chair-2013@ietf.org>
Date: Fri, Oct 4, 2013 at 10:31 AM
Subject: NOMCOM 2013 - Second Call fo= r Nominations - two weeks left
To: IETF Announcement List <ietf-announce@ietf.org>
Cc: IETF = Discuss List <ietf@ietf.org>


Nominations for the IESG, IAB, and IAOC are due to the Nomcom by Fr= iday, 18 October, 2013.

Is there someone you work with at IETF who has leadership potential and a g= rowing track record? Please read the Nomcom call for nominations and consid= er nominating her or him. Or several folks! Deadline for nominations is Oct= ober 18. =A0Nominate soon to give your nominee(s) plenty time to fill in th= e questionnaire. Information about the desired expertise for positions is h= ere:
=A0 =A0 =A0 =A0 =A0 =A0https://datatracker.ietf.org/nomcom/2013/exper= tise

Lots more, including which positions are open, how to make a nomination, an= d how to
send us your feedback on the desired expertise, follows.

IETFers, let's hear from you! =A0Make nominations, accept nominations!<= br>
If you have any questions about the process, feel free to get in touch with= me.

Best regards,

Allison for the Nomcom

Allison Mankin
Nomcom Chair 2013-14

----- The Info You Need for Nominating -----

The 2013-14 Nominating Committee (Nomcom) is seeking nominations
from now until October 18, 2013. The open positions being considered
by this year's Nomcom can be found later in this section, and also on this year's Nomcom website:

htt= ps://datatracker.ietf.org/nomcom/2013/

Nominations may be made by selecting the Nominate link at the top of
the Nomcom 2013 home page, or by visiting the following URL:

https://datatracker.ietf.org/nomcom/2013/nominate/

Note that nominations made using the web tool require an ietf.org
datatracker account. You can create a datatracker ietf.org account
if you don't have one already by visiting the following URL:

https://datatracker.ietf.org/accounts/create/

Nominations may also be made by email to nomcom13 at ietf.org.
If you nominate by email, please include the word "Nominate" in t= he Subject
and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you
are making the nomination. If you use email, please use a separate email fo= r
each person you nominate, and for each position (if you are nominating one<= br> person for multiple positions).

Self-nomination is welcome! =A0No need to be shy.

Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing<= br> Nominees" described in RFC 5680. =A0As stated in RFC 5680: "The l= ist of
nominees willing to be considered for positions under review in the
current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a
datatracker account may access the lists. =A0In all other ways, the
confidentiality requirements of RFC 3777/BCP10 remain in effect. =A0All
feedback and all Nomcom deliberations will remain confidential and will
not be disclosed.

In order to ensure time to collect sufficient community feedback about
each of the willing nominees, nominations must be received by the
Nomcom on or before October 18, 2013. =A0Please submit your nominations
as early as possible for the sake of your nominees, as we've set the questionnaire submission deadline for October 25, 2013.

The list of people and posts whose terms end with the March 2014 IETF meeti= ng,
and thus the positions for which we are accepting nominations:

IAOC
Chris Griffiths

IAB
Bernard Aboba
Marc Blanchet
Ross Callon
Eliot Lear
Hannes Tschofenig

IESG
Barry Leiba (Applications)
Brian Haberman (Internet)
Benoit Claise (Operations and Management)
Gonzalo Camarillo (RAI)
Stewart Bryant (Routing)
Sean Turner (Security)
Martin Stiemerling (Transport)

Please be resourceful in identifying possible candidates for these
positions, as developing our talent is a very crucial requirement for
the IETF. =A0Also, please give serious consideration to accepting nominatio= ns
you receive.

The summaries of the desired expertise for the positions, developed by the<= br> respective bodies, are found at:

https://datatracker.ietf.org/nomcom/2013/expertise/

In addition to nominations, the Nomcom seeks community input on
the positions themselves. =A0We need and welcome the community's
views and input on the jobs within each organization. If you
have ideas on the positions' responsibilities (more, less,
different), please let us know. =A0You can send us email about this to
nomcom13 at ietf.org, and= we will use this feedback actively.

Thank you for your help in nominating a great pool of strong and interestin= g
nominees!




--f46d043890eddaaf7104e7f261cf-- From ned.freed@mrochek.com Sat Oct 5 16:53:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB7621F9DD5 for ; Sat, 5 Oct 2013 16:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78VWKCN34liV for ; Sat, 5 Oct 2013 16:53:37 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 77F9921F88DD for ; Sat, 5 Oct 2013 16:53:36 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OZ8CSBZKMO005BHD@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 5 Oct 2013 16:48:33 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OZ27UH630000004R@mauve.mrochek.com>; Sat, 5 Oct 2013 16:48:30 -0700 (PDT) Message-id: <01OZ8CSA8EQM00004R@mauve.mrochek.com> Date: Sat, 05 Oct 2013 16:01:37 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 24 Sep 2013 10:19:08 +0100" References: To: ht@inf.ed.ac.uk Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Priority of in-band vs. out-of-band encoding information X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Oct 2013 23:53:42 -0000 > In reviewing the relationship between > draft-ietf-appsawg-xml-mediatypes and the XML specification itself, I > was reminded that the XML spec. defers to "RFC3023 or successor" with > respect to the relative priority of the charset parameter > and any available document-internal information about character > encoding (BOM and/or the XML encoding declaration). > Empirical evidence suggests that wrt both XML and HTML media types, > web browsers give priority to a BOM. That is, if the body of an HTTP > response begins with a BOM, it is treated as authoritative and any > charset parameter in a Content-Type header is ignored. The current > draft of the HTML5 spec. makes this explicit. > Is anyone aware of any existing media type registration or other RFC > which addresses this issue explicitly? No, not really. There may have been some talk about having what became RFC 6657 go there, but it never happened. I will note that when it comes to sniffing and UTF-8/UTF-16, I regard this entire issue as "mostly harmless". A document that begins with a 16-bit BOM cannot possibly be valid utf-8, and the chances that a UTF-16 document without a BOM will parse as vaid UTF-8 are very low. So this sort of guessing tends to work, although whether or not it's actually useful is a different question. In my experience the place where making guesses about charsets is highly problematic isn't with XML and isn't with UTF-8 or UTF-16. It used to be the attempts to tell the difference between the various iso-8859-* variants and friends, these days the problems have moved to the the CJK space, where there are now multiple variant charsets that have been built on top iso-2022-jp, euc-jp, and so on that add various Unicode characters to these charsets in incompatible ways. (I used to think that GB18030 (basically GB2312 extended to cover all of Unicode) was a dumb thing to do, but given what's happened on the Japanese side of things I've decided I was wrong.) Ned From internet-drafts@ietf.org Sat Oct 5 19:38:54 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64FD21F84F8; Sat, 5 Oct 2013 19:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPD2NeqehJXi; Sat, 5 Oct 2013 19:38:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A049921F9E0B; Sat, 5 Oct 2013 19:38:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131006023853.31033.44560.idtracker@ietfa.amsl.com> Date: Sat, 05 Oct 2013 19:38:53 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-09.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 02:38:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Advice for Safe Handling of Malformed Messages Author(s) : Murray S. Kucherawy Gregory N. Shapiro N. Freed Filename : draft-ietf-appsawg-malformed-mail-09.txt Pages : 22 Date : 2013-10-05 Abstract: Although Internet mail formats have been precisely defined since the 1970s, authoring and handling software often show only mild conformance to the specifications. The malformed messages that result are non-standard. Nonetheless, decades of experience has shown that handling with some tolerance the malformations that result is often an acceptable approach, and is better than rejecting the messages outright as nonconformant. This document includes a collection of the best advice available regarding a variety of common malformed mail situations, to be used as implementation guidance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-malformed-mail There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-malformed-mail-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-malformed-mail-09 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 superuser@gmail.com Sat Oct 5 19:40:52 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4C521F9D65 for ; Sat, 5 Oct 2013 19:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wnd3zpFya6at for ; Sat, 5 Oct 2013 19:40:52 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id E985821F84F8 for ; Sat, 5 Oct 2013 19:40:51 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id l18so3611200wgh.0 for ; Sat, 05 Oct 2013 19:40:51 -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=Jgb5jDbHdalIlopdCMhVfQYvlzeC1K4bSC+OUfnNIAs=; b=yGgXAjMai17UbvSTlXgYx5BescVV+mPSB44JQ05TQYNbTha934c6evSiLMQABRZ1Lv Z9Ngnuca7v7q9qqikhH5yuQzPLXCvrSunGQXGdisVFiqAO2w7yxNfTdRHx7Ca2E7h7oj MsHvNjTCCxV1PwfCGWLbSisE2Y4zX53gg3MKaKTYd7HP3gtOHypJtdDdOcEFrVdJgvj6 twYk7kpE4iTPKysH1Vtmvrb87IWpdWf3IyOnaHceQjh8BN2D+jbLVUNW+zcBWbWJtHm9 5D6O2InIBs7QJHhqML6nRrWOBOMUNPDK8GezB8F+k1yprtu9SPpigdn4OOWs7gMHJiDF LD6Q== MIME-Version: 1.0 X-Received: by 10.180.189.132 with SMTP id gi4mr13327350wic.19.1381027250942; Sat, 05 Oct 2013 19:40:50 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Sat, 5 Oct 2013 19:40:50 -0700 (PDT) In-Reply-To: <20131006023853.31033.44560.idtracker@ietfa.amsl.com> References: <20131006023853.31033.44560.idtracker@ietfa.amsl.com> Date: Sat, 5 Oct 2013 19:40:50 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c35294b7b95604e809765c Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-09.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 02:40:52 -0000 --001a11c35294b7b95604e809765c Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 5, 2013 at 7:38 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 : Advice for Safe Handling of Malformed Messages > Author(s) : Murray S. Kucherawy > Gregory N. Shapiro > N. Freed > Filename : draft-ietf-appsawg-malformed-mail-09.txt > Pages : 22 > Date : 2013-10-05 > > Abstract: > Although Internet mail formats have been precisely defined since the > 1970s, authoring and handling software often show only mild > conformance to the specifications. The malformed messages that > result are non-standard. Nonetheless, decades of experience has > shown that handling with some tolerance the malformations that result > is often an acceptable approach, and is better than rejecting the > messages outright as nonconformant. This document includes a > collection of the best advice available regarding a variety of common > malformed mail situations, to be used as implementation guidance. > > Changes resulting from AD Evaluation; mostly small, all editorial. -MSK --001a11c35294b7b95604e809765c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Oct 5, 2013 at 7:38 PM, <internet-drafts@= ietf.org> wrote:

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

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Advice for Safe Handling of Mal= formed Messages
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Murray S. Kucherawy
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gregory N. Shapiro
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 N. Freed
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-malformed-mail= -09.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 22
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-10-05

Abstract:
=A0 =A0Although Internet mail formats have been precisely defined since the=
=A0 =A01970s, authoring and handling software often show only mild
=A0 =A0conformance to the specifications. =A0The malformed messages that =A0 =A0result are non-standard. =A0Nonetheless, decades of experience has =A0 =A0shown that handling with some tolerance the malformations that resul= t
=A0 =A0is often an acceptable approach, and is better than rejecting the =A0 =A0messages outright as nonconformant. =A0This document includes a
=A0 =A0collection of the best advice available regarding a variety of commo= n
=A0 =A0malformed mail situations, to be used as implementation guidance.

Changes resulting from AD Evaluation; = mostly small, all editorial.
=A0
-MSK
--001a11c35294b7b95604e809765c-- From superuser@gmail.com Sat Oct 5 19:42:31 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391FD21F9E0B for ; Sat, 5 Oct 2013 19:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDv+b5NkbOCW for ; Sat, 5 Oct 2013 19:42:30 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E1B5B21F9DD5 for ; Sat, 5 Oct 2013 19:42:29 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id u57so4645328wes.15 for ; Sat, 05 Oct 2013 19:42:29 -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=LiXKdGguKJQ+/491kog3XFm8vGvFhRcNJ7ZWTb4DDIw=; b=bpSvF5KtSAfCaRCeMd1su1BwIppcZ8bJOvO5wH5n45LjAtOcj5EhtWoTAnDRwUT81F AY/dwHzkLyzp5MoqKcCy/iy1h9G5W8nAABXzKUXwd2tz7SlMQiG91NN8tl0RXy4X18lB VyAkPsRu0kvibxyyVthIO50xBorLBrmMzd2zWCkGl2TGku/8S/ZZXbNzoaLtrTHq4NF6 lt4ehW0DA23sWlGJE+6jLp/tNF7GiCYmtrUYfQW24PY7JGIzaS9swMsY3alNSrb/vuMQ 2ALCvW/H5mJIff7he9+0Uq7RKe4cU0PgiJwyGSoQ1y0LMWraxskKCmyi1+LoYQkcBbBr IuzQ== MIME-Version: 1.0 X-Received: by 10.180.189.9 with SMTP id ge9mr13547810wic.52.1381027349180; Sat, 05 Oct 2013 19:42:29 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Sat, 5 Oct 2013 19:42:29 -0700 (PDT) Date: Sat, 5 Oct 2013 19:42:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c3430292b88a04e8097c11 Subject: [apps-discuss] IETF 88 preliminary agenda available X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Oct 2013 02:42:31 -0000 --001a11c3430292b88a04e8097c11 Content-Type: text/plain; charset=ISO-8859-1 The IETF 88 Preliminary Agenda has been posted. The final agenda will be published on Friday, October 11th. https://datatracker.ietf.org/meeting/88/agenda.html https://datatracker.ietf.org/meeting/88/agenda.txt We tentatively have our usual Monday morning slot. See you all there! -MSK --001a11c3430292b88a04e8097c11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The IETF 88 Preliminary Agenda has been posted. = The final agenda will be published on Friday, October 11th.

https://datatracker.ietf.org/meeting/88/agenda.html
https://datatracker.ietf.org/meeting/88/agenda.txt

W= e tentatively have our usual Monday morning slot.=A0 See you all there!
=
-MSK
--001a11c3430292b88a04e8097c11-- From jtrentadams@gmail.com Mon Oct 7 13:37:13 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3257611E8135 for ; Mon, 7 Oct 2013 13:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czYdWivtMlEh for ; Mon, 7 Oct 2013 13:37:12 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7791C11E8152 for ; Mon, 7 Oct 2013 13:37:10 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id qd12so16939625ieb.22 for ; Mon, 07 Oct 2013 13:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=v4GpEsqRjOm7Cl1Z02l33QedLKK1LwvJkzfNw0OruNk=; b=xNRnrFh3y8WDJPFHXQkHECrVYFBeslbzQi32l3mVNRe9nnBAV2+7JdGKQZhsPWgx+Q 91rKNvWJr2o/mHFTWZGXIP33bIlV6iLGnbHVoQrGbvTtSEuQ1LoMSJv7EDqGqWhJaSh0 A++ZVNXYTG6bNjnbXnK6b2TgXkklyv+hhPrNq7Npd1jCXlelFeQuAYC9L59eLfXHXQ3Y PONjRcslUR22JlcRhodRLhuVdZFyiLkutAp7cMhkw3iXI4fulcz1d76Sf2J32q3Z/T32 i8+ov/pJjE/DgwuCur01/3jFfghr4eXHkFyv9PFZ/fuONb8iwZroMUQpBM4j7lzz7UUP eSVQ== X-Received: by 10.50.147.65 with SMTP id ti1mr18740890igb.12.1381178229893; Mon, 07 Oct 2013 13:37:09 -0700 (PDT) Received: from jtrentadams-isoc.local (c-24-9-3-96.hsd1.co.comcast.net. [24.9.3.96]) by mx.google.com with ESMTPSA id x5sm335812iga.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Oct 2013 13:37:09 -0700 (PDT) Message-ID: <52531B74.4090403@gmail.com> Date: Mon, 07 Oct 2013 14:37:08 -0600 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: IETF Apps Discuss X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Shepherding the Require-Recipient-Valid-Since Header Field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2013 20:37:13 -0000 Folks - I've been asked to help shepherd the Require-Recipient-Valid-Since Header Field (draft-ietf-appsawg-rrvs-header-field-00) specification. For easy reference, here's a link to the specification in the datatracker: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field/ As a reminder, there was a flury of activity in early August, but the dust seems to have settled around the initial set of comments. As IETF 88 is just around the corner, it'd be great to see if we could tackle any remaining issues before the moratorium on updates. In fact, perhaps we're close to closing out all open issues and could target moving into last call. Anyway, please fire off any suggestions that you'd like to see addressed. Thanks, Trent -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams From superuser@gmail.com Mon Oct 7 16:16:53 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD37F21E80CD for ; Mon, 7 Oct 2013 16:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6ZFKBUU0v+k for ; Mon, 7 Oct 2013 16:16:53 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id E5F3021E80CC for ; Mon, 7 Oct 2013 16:16:52 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id q59so7872733wes.9 for ; Mon, 07 Oct 2013 16:16:52 -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=B41KYJ5oqYe4+AN+7dTejemlV1wTMqlX+EWdYeWgSVY=; b=f0ENS9/zAapniJUikExfQcvFEk1qsbduSmteAHIycmDbVzw/wl5wFOtASrm6R5gFl3 skfB4ND+CxSPk3rp31cY6csr1klRpk0vJC3BshNFA/Sa/6AZ+WaDR0wy/BpYvM8VTiy4 xQ6C9Jb1mQ+hSAIv556qO5w4DuEGLWdHW2IxIl6y/PAnkIwtYw6vbWTTKcXYLzZJarXQ nqRkrtnoGNLiKArtLTzH+gzF4KCBLSkBBb0A9e5+6RTObrHbDTsAAzTeY3CldwAkcJtE G61PbHrynkHx6J5qwWrAn/MPWvuwI1KwkALObLgYERPQtf1Uq+D+QmSyqtMcWjZ9OAxh UiOQ== MIME-Version: 1.0 X-Received: by 10.180.72.226 with SMTP id g2mr20821945wiv.52.1381187812141; Mon, 07 Oct 2013 16:16:52 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Mon, 7 Oct 2013 16:16:52 -0700 (PDT) In-Reply-To: <52531B74.4090403@gmail.com> References: <52531B74.4090403@gmail.com> Date: Mon, 7 Oct 2013 16:16:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Trent Adams" Content-Type: multipart/alternative; boundary=f46d043890ede9308c04e82ed87e Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Shepherding the Require-Recipient-Valid-Since Header Field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2013 23:16:53 -0000 --f46d043890ede9308c04e82ed87e Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 7, 2013 at 1:37 PM, J. Trent Adams wrote: > As IETF 88 is just around the corner, it'd be great to see if we could > tackle any remaining issues before the moratorium on updates. In fact, > perhaps we're close to closing out all open issues and could target > moving into last call. > > Anyway, please fire off any suggestions that you'd like to see addressed. > > Thanks, Trent. The authors have nothing outstanding here, so any outstanding comments or even some reviews would be great. -MSK --f46d043890ede9308c04e82ed87e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 7, 2013 at 1:37 PM, J. Trent Adams <jtr= entadams@gmail.com> wrote:
As IETF 88 is just around the corner, it'= ;d be great to see if we could
tackle any remaining issues before the moratorium on updates. =A0In fact, perhaps we're close to closing out all open issues and could target
moving into last call.

Anyway, please fire off any suggestions that you'd like to see addresse= d.


Thanks, Trent.=A0 The authors have not= hing outstanding here, so any outstanding comments or even some reviews wou= ld be great.

-MSK

--f46d043890ede9308c04e82ed87e-- From stpeter@stpeter.im Tue Oct 8 12:27:25 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D8821F9ED4 for ; Tue, 8 Oct 2013 12:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUEqzrVupxEQ for ; Tue, 8 Oct 2013 12:27:17 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C799D21F9EAF for ; Tue, 8 Oct 2013 12:26:46 -0700 (PDT) Received: from sjc-vpn5-1390.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B1854414D9; Tue, 8 Oct 2013 13:32:27 -0600 (MDT) Message-ID: <52545C64.7030701@stpeter.im> Date: Tue, 08 Oct 2013 13:26:28 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <20131008184514.32189.48777.idtracker@ietfa.amsl.com> In-Reply-To: <20131008184514.32189.48777.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 X-Forwarded-Message-Id: <20131008184514.32189.48777.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Fwd: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 19:27:25 -0000 Folks, it appears that the NOMCOM would like more nominations for Applications Area Director. Please consider volunteering! Peter -------- Original Message -------- Subject: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV Date: Tue, 08 Oct 2013 11:45:14 -0700 From: NomCom Chair Reply-To: nomcom-chair-2013@ietf.org To: IETF Announcement List CC: ietf@ietf.org UPDATE: nominations are too sparse in several of the IESG areas: APP, OAM, RAI, and TSV. If you know one or more of those areas, exercise your social network and submit nominations. We'll be very grateful! Is there someone you work with at IETF who has leadership potential and a growing track record? Please read this Nomcom call for nominations and consider nominating her or him. Or several folks! Deadline for nominations is October 18. Nominate soon to give your nominee(s) plenty time to fill in the questionnaire. If you're nominated, even if you support the present incumbent, being reviewed by Nomcom is great IETF experience. The questionnaire offers a chance to think about IETF and about your area. Whether or not your candidacy progresses this time, you'll have gained some valuable insights, and you'll have contributed greatly. This process only works because many IETFers take part; please join in. Lots more, including which positions are open, how to make a nomination (including nomination of yourself), and how to send us your feedback on the desired expertise, follows. IETFers, let's hear from you! Make nominations, accept nominations! If you have any questions about the process, feel free to get in touch with me. Best regards, Allison for the Nomcom Allison Mankin Nomcom Chair 2013-14 ----- The Info You Need for Nominating ----- The 2013-14 Nominating Committee (Nomcom) is seeking nominations from now until October 18, 2013. The open positions being considered by this year's Nomcom can be found later in this section, and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2013/ Information about the desired expertise for positions is here: https://datatracker.ietf.org/nomcom/2013/expertise Nominations may be made by selecting the Nominate link at the top of the Nomcom 2013 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2013/nominate/ Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ Nominations may also be made by email to nomcom13 at ietf.org. If you nominate by email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you use email, please use a separate email for each person you nominate, and for each position (if you are nominating one person for multiple positions). Self-nomination is welcome! No need to be shy. Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. As stated in RFC 5680: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. In all other ways, the confidentiality requirements of RFC 3777/BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the Nomcom on or before October 18, 2013. Please submit your nominations as early as possible for the sake of your nominees, as we've set the questionnaire submission deadline for October 25, 2013. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which we are accepting nominations: IAOC Chris Griffiths IAB Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF. Also, please give serious consideration to accepting nominations you receive. The summaries of the desired expertise for the positions, developed by the respective bodies, are found at: https://datatracker.ietf.org/nomcom/2013/expertise/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. You can send us email about this to nomcom13 at ietf.org, and we will use this feedback actively. Thank you for your help in nominating a great pool of strong and interesting nominees! From dave@cridland.net Tue Oct 8 13:01:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FCE11E8106 for ; Tue, 8 Oct 2013 13:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdxWoxG-kfGN for ; Tue, 8 Oct 2013 13:01:07 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6E51321F9EC4 for ; Tue, 8 Oct 2013 13:01:06 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id z5so7299883lbh.37 for ; Tue, 08 Oct 2013 13:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3rnU72Hr2RkrNLL9PZ1MfEdkHQ0hoQFbNH9msmzZlVQ=; b=Lg9AhaOaiVn6VSaEre/rNV7a7dcf1GuNS0Q4n9Xz1Too6nnU4OcH1QKX+yZyenDDkz sJUyrLFCVgb7ta1z1qgeBiRE8P0i9RlksnuUi0/ohrw/tTUAXenRAoHPvUHxcunl69iv INk45rzwJAUBKoJXixFp1AEWMh3bywK87VTMA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3rnU72Hr2RkrNLL9PZ1MfEdkHQ0hoQFbNH9msmzZlVQ=; b=lclQ/0rea74hAw3EjkWA9uY0lGvVaqTa6Cg8Wj7f+MEh2DzoPtmHX1PHgeYSQF+j0n h+McNsXjLXbXMrnUN2gVlj2C0g4uhMlHtc04Zh0I7m9pUwVUgVtidh26xJa07IgxJMIG oP+bYdlIYhg1oVvh8byH70vTtjLZDtzXlqJ8aL5g7LFA0iSC29OKMbW5BBmQ76CXUdSM 8ogZstsQqvUA7+pT9uhjx2W5UFsWkhyKyqHLB7PVMcRH50EXQPF/6jai0hAKjYhwgV9e 0iqymDCXw1AW+trZHixSIyEjLYkaFOPeCESvYMzadARFdudii2xEoJyPkZR1eVQB6tLS vmyA== X-Gm-Message-State: ALoCoQlHtCSvxjBZrmThSTI0MCpP2G4etPxfvTeYAISgl3QK+mvPBoKxGWCyx7yQWUhAbkl50sPo MIME-Version: 1.0 X-Received: by 10.152.116.109 with SMTP id jv13mr2804504lab.30.1381262465337; Tue, 08 Oct 2013 13:01:05 -0700 (PDT) Received: by 10.114.183.47 with HTTP; Tue, 8 Oct 2013 13:01:05 -0700 (PDT) Received: by 10.114.183.47 with HTTP; Tue, 8 Oct 2013 13:01:05 -0700 (PDT) In-Reply-To: References: Date: Tue, 8 Oct 2013 21:01:05 +0100 Message-ID: From: Dave Cridland To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a11c3675e9699e304e8403a89 Cc: Bill Mills , apps-discuss@ietf.org Subject: Re: [apps-discuss] [appsdir] Review request: draft-ietf-appsawg-rrvs-header-field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 20:01:08 -0000 --001a11c3675e9699e304e8403a89 Content-Type: text/plain; charset=ISO-8859-1 On 8 Oct 2013 01:42, "Murray S. Kucherawy" wrote: > > Hi Dave, > > This should probably move to apps-discuss. I'll let you decide if you agree before doing so. > > *blinks* Yes. Yes, it totally should have been on that mailing list. That'll teach me to write things while jetlagged. Or indeed read them. Or try to think. > On Mon, Oct 7, 2013 at 6:18 PM, Dave Cridland wrote: >> >> My fundamental problem with the design is that if it were an ESMTP extension, it would fail clearly per-recipient, whereas this is an all or nothing approach. There's no way to tell, from the defined response, which mailbox[es] have changed ownership. > > > We discussed this in there (Section 5 of the current draft). The concern is that there might be an intermediary that doesn't support it, at which point you either have to turn the message back or lose the security as it goes forward. Neither is acceptable in our use case. Yes, and I do understand that, but that's an argument against any extension. I agree that this would benefit from header field magic, I just think having that as a fallback would be better than having it as a default. >> >> That said, given the scope, this may not be an issue - however, I'm slightly confused by this scope. At Arcode, we were considering using this to mark outgoing messages from our MUA, but this is stated to be intended only for use by automated senders. It's not obvious why, and no rationale is given. > > We said that to highlight what the origin of the work is and describe our use cases. That doesn't mean this can't be used in other contexts where it might work; if it makes sense to use this in the context of user-generated email, that's fine, but we wouldn't expect end users to maintain a table of when they last knew their various recipients to be valid so it seems less useful overall for MUAs to do it. We could add a remark about that if it would help. If this is merely a perspective, that's fine, and yes - a remark or two clarifying scope would be useful. >> >> Section 3 contains the recommendation to remove the header field. This seems wrong to me - I would suggest that: >> >> a) It's useful for debugging purposes to keep it. >> >> b) If the header is signed via DKIM (which is breifly discussed later) removal would invalidate the signature, I think. > > Right on both counts, which is why we went with RECOMMENDED, which allows for local exceptions as long as you have a really good reason to do what you're doing. Those both seem like good reasons to ignore the recommendation to me. We should probably point out the DKIM thing explicitly, however. What are the really good reasons not to ignore your recommendation, though? >> >> Also, I suggest that only those RRVS fields below the uppermost set of trace fields should be examined. That is, any trace field after any RRVS field should cause any further RRVS fields to be ignored. This should prevent cases where a mail is resent, or automatically forwarded, from causing any complications. > > This is definitely something that should get wider discussion, because I don't know the implications of making that change. It seems okay off the top of my head though. > >> >> Section 8.2 includes the suggestion to restrict use to recipients known to implement; but as far as I can tell, there's no signalling to allow this to be discovered. > > There isn't. > >> >> I suggest: >> >> 1) We should do an ESMTP extension. I agree that a header field would also be useful; but deciding explicitly not to do an ESMTP extension to avoid the possibility of loss, and *only* doing a header field seems to me to be optimizing for the failure case. > > In my experience, adding support for a header field to an MTA (or more commonly, plugin or filter) has a much faster deployment rate than adding support for an ESMTP extension. That means solving the immediate problem will take a lot longer. There's also been other work (RFC 6758, for example) that takes this approach where tunneling of the value through non-participants is important. I agree, but I don't think this is a case where the circumstances rule out a ESMTP RCPT parameter entirely, though. In fact, RFC 6758 is itself a fallback mechanism for an ESMTP extension, so you're supporting my argument with that example, thanks. :-) >> >> 2) The signalling problem above solves itself if an ESMTP extension is done, of course. But even if not a basic extension simply with a keyword in the EHLO response would help. Otherwise, the only option I can suggest is to have a special RRVS field value, or another field name, which could be used to probe for support. Seems very ugly, though. > > Using ESMTP for signaling doesn't always help. The ultimate recipient might have support for it, but it's not meaningful if there's an intermediary that doesn't support it. The "known to support" thing just means the sender has a list of domains it knows a priori will know what to do with this field, and only generates the field for them. I'll admit to being slightly over-enthusiastic there; I think that an ESMTP extension would give a considerably better idea, though. >> >> 3) The 5.7.7 ESC needs to have the text syntax defined to include the failing mailbox[es]. >> >> Dave. > > Isn't the text part typically free-form and not specified? Typically, but there are exceptions - RFC 5321's EXPN response is specified for the 250 case, for example, in section 3.5. Dave. --001a11c3675e9699e304e8403a89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On 8 Oct 2013 01:42, "Murray S. Kucherawy" <superuser@gmail.com> wrote:
>
> Hi Dave,
>
> This should probably move to apps-discuss.=A0 I'll let you decide = if you agree before doing so.
>
>

*blinks*

Yes. Yes, it totally should have been on that mailing list. = That'll teach me to write things while jetlagged. Or indeed read them. = Or try to think.

> On Mon, Oct 7, 2013 at 6:18 PM, Dave Cridland <dave@cridland.net> wrote:
>>
>> My fundamental problem with the design is that if it were an ESMTP= extension, it would fail clearly per-recipient, whereas this is an all or = nothing approach. There's no way to tell, from the defined response, wh= ich mailbox[es] have changed ownership.
>
>
> We discussed this in there (Section 5 of the current draft).=A0 The co= ncern is that there might be an intermediary that doesn't support it, a= t which point you either have to turn the message back or lose the security= as it goes forward.=A0 Neither is acceptable in our use case.

Yes, and I do understand that, but that's an argument ag= ainst any extension. I agree that this would benefit from header field magi= c, I just think having that as a fallback would be better than having it as= a default.

>>
>> That said, given the scope, this may not be an issue - however, I&= #39;m slightly confused by this scope. At Arcode, we were considering using= this to mark outgoing messages from our MUA, but this is stated to be inte= nded only for use by automated senders. It's not obvious why, and no ra= tionale is given.
>
> We said that to highlight what the origin of the work is and describe = our use cases.=A0 That doesn't mean this can't be used in other con= texts where it might work; if it makes sense to use this in the context of = user-generated email, that's fine, but we wouldn't expect end users= to maintain a table of when they last knew their various recipients to be = valid so it seems less useful overall for MUAs to do it.=A0 We could add a = remark about that if it would help.

If this is merely a perspective, that's fine, and yes - = a remark or two clarifying scope would be useful.

>>
>> Section 3 contains the recommendation to remove the header field. = This seems wrong to me - I would suggest that:
>>
>> a) It's useful for debugging purposes to keep it.
>>
>> b) If the header is signed via DKIM (which is breifly discussed la= ter) removal would invalidate the signature, I think.
>
> Right on both counts, which is why we went with RECOMMENDED, which all= ows for local exceptions as long as you have a really good reason to do wha= t you're doing.=A0 Those both seem like good reasons to ignore the reco= mmendation to me.=A0 We should probably point out the DKIM thing explicitly= , however.

What are the really good reasons not to ignore your recommen= dation, though?

>>
>> Also, I suggest that only those RRVS fields below the uppermost se= t of trace fields should be examined. That is, any trace field after any RR= VS field should cause any further RRVS fields to be ignored. This should pr= event cases where a mail is resent, or automatically forwarded, from causin= g any complications.
>
> This is definitely something that should get wider discussion, because= I don't know the implications of making that change.=A0 It seems okay = off the top of my head though.
> =A0
>>
>> Section 8.2 includes the suggestion to restrict use to recipients = known to implement; but as far as I can tell, there's no signalling to = allow this to be discovered.
>
> There isn't.
> =A0
>>
>> I suggest:
>>
>> 1) We should do an ESMTP extension. I agree that a header field wo= uld also be useful; but deciding explicitly not to do an ESMTP extension to= avoid the possibility of loss, and *only* doing a header field seems to me= to be optimizing for the failure case.
>
> In my experience, adding support for a header field to an MTA (or more= commonly, plugin or filter) has a much faster deployment rate than adding = support for an ESMTP extension.=A0 That means solving the immediate problem= will take a lot longer.=A0 There's also been other work (RFC 6758, for= example) that takes this approach where tunneling of the value through non= -participants is important.

I agree, but I don't think this is a case where the circ= umstances rule out a ESMTP RCPT parameter entirely, though.

In fact, RFC 6758 is itself a fallback mechanism for an ESMT= P extension, so you're supporting my argument with that example, thanks= . :-)

>>
>> 2) The signalling problem above solves itself if an ESMTP extensio= n is done, of course. But even if not a basic extension simply with a keywo= rd in the EHLO response would help. Otherwise, the only option I can sugges= t is to have a special RRVS field value, or another field name, which could= be used to probe for support. Seems very ugly, though.
>
> Using ESMTP for signaling doesn't always help.=A0 The ultimate rec= ipient might have support for it, but it's not meaningful if there'= s an intermediary that doesn't support it.=A0 The "known to suppor= t" thing just means the sender has a list of domains it knows a priori= will know what to do with this field, and only generates the field for the= m.

I'll admit to being slightly over-enthusiastic there; I = think that an ESMTP extension would give a considerably better idea, though= .

>>
>> 3) The 5.7.7 ESC needs to have the text syntax defined to include = the failing mailbox[es].
>>
>> Dave.
>
> Isn't the text part typically free-form and not specified?

Typically, but there are exceptions - RFC 5321's EXPN re= sponse is specified for the 250 case, for example, in section 3.5.

Dave.

--001a11c3675e9699e304e8403a89-- From superuser@gmail.com Tue Oct 8 13:20:14 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5696121F90E5 for ; Tue, 8 Oct 2013 13:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiDeohcOo7iR for ; Tue, 8 Oct 2013 13:20:13 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id F289D21F9CCC for ; Tue, 8 Oct 2013 13:20:01 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u56so6218606wes.33 for ; Tue, 08 Oct 2013 13:20:01 -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=mHBT2gWtSt70DR5UmODgXA3Q3FSgqcrEmF4ivmr9mJk=; b=mSQncWibWfveRnHPWmjxG3oN1sZQvgJgGDSDq5/Fxni5DYhG/iMQGd/8lazZMXOnhb ZjlpxqOt0k3c5xRJIAmGECCD445yDvVPh7+m0Wkykk1L9Xk1enD1ZCBp7DZz5chqXwOD V82G3cnPKhizIfUrTbkXXB+29is6G8epTEepbmF9UDKXk7wAiw7gJl1mmi6P5E7Mj9cC N0BjeEdfpyX3g9eiYC/e5cOQEEb3jJoWW3dXnLl7aeu3oiX0f7KYYQzLObDvX+DQ2HEH h4r1ybolNofluvQxoa0mXodjKq80I1dofT+ccfiUseYt+Qq7L0glADE+lxl69tNIVwhs cenw== MIME-Version: 1.0 X-Received: by 10.180.13.113 with SMTP id g17mr3257764wic.19.1381263601149; Tue, 08 Oct 2013 13:20:01 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Tue, 8 Oct 2013 13:20:01 -0700 (PDT) In-Reply-To: References: Date: Tue, 8 Oct 2013 13:20:01 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Cridland Content-Type: multipart/alternative; boundary=001a11c23c2449aa6104e8407ef9 Cc: Bill Mills , IETF Apps Discuss Subject: Re: [apps-discuss] [appsdir] Review request: draft-ietf-appsawg-rrvs-header-field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 20:20:14 -0000 --001a11c23c2449aa6104e8407ef9 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 8, 2013 at 1:01 PM, Dave Cridland wrote: > >> My fundamental problem with the design is that if it were an ESMTP > extension, it would fail clearly per-recipient, whereas this is an all or > nothing approach. There's no way to tell, from the defined response, which > mailbox[es] have changed ownership. > > > > > > > We discussed this in there (Section 5 of the current draft). The > concern is that there might be an intermediary that doesn't support it, at > which point you either have to turn the message back or lose the security > as it goes forward. Neither is acceptable in our use case. > > Yes, and I do understand that, but that's an argument against any > extension. I agree that this would benefit from header field magic, I just > think having that as a fallback would be better than having it as a default. > I'm inclined to think that this is a pretty general problem with this sort of work (RFC 6758 being another recent example), and so maybe there's some work to be done around a general description for the method of tunneling SMTP extensions through header fields since it's come up before. That said, I suppose this point needs commentary from more people in the area. Ned in particular mentioned it before, saying that an extension is architecturally the right way to do it but it's possible to be successful arguing for doing it this way. I don't know if we've made the right arguments here, so more feedback is needed. >> > >> That said, given the scope, this may not be an issue - however, I'm > slightly confused by this scope. At Arcode, we were considering using this > to mark outgoing messages from our MUA, but this is stated to be intended > only for use by automated senders. It's not obvious why, and no rationale > is given. > > > > We said that to highlight what the origin of the work is and describe > our use cases. That doesn't mean this can't be used in other contexts > where it might work; if it makes sense to use this in the context of > user-generated email, that's fine, but we wouldn't expect end users to > maintain a table of when they last knew their various recipients to be > valid so it seems less useful overall for MUAs to do it. We could add a > remark about that if it would help. > > If this is merely a perspective, that's fine, and yes - a remark or two > clarifying scope would be useful. > Added for the next version. > >> > >> Section 3 contains the recommendation to remove the header field. This > seems wrong to me - I would suggest that: > >> > >> a) It's useful for debugging purposes to keep it. > >> > >> b) If the header is signed via DKIM (which is breifly discussed later) > removal would invalidate the signature, I think. > > > > Right on both counts, which is why we went with RECOMMENDED, which > allows for local exceptions as long as you have a really good reason to do > what you're doing. Those both seem like good reasons to ignore the > recommendation to me. We should probably point out the DKIM thing > explicitly, however. > > What are the really good reasons not to ignore your recommendation, though? > The date/time at which A verified that B had a particular owner is probably not the kind of thing that should be accidentally revealed should the message be forwarded or exposed in some other way. >> 3) The 5.7.7 ESC needs to have the text syntax defined to include the > failing mailbox[es]. > > >> > >> Dave. > > > > Isn't the text part typically free-form and not specified? > > Typically, but there are exceptions - RFC 5321's EXPN response is > specified for the 250 case, for example, in section 3.5. > > Dave. > Why's it appropriate here and not elsewhere? I'm trying to be lazy by asking that question, but rather I'm trying to understand when it's necessary to establish syntax around something that's nearly always free-form, and when it's better not to do so. -MSK --001a11c23c2449aa6104e8407ef9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 8, 2013 at 1:01 PM, Dave Cridland <dave@cridl= and.net> wrote:
>> My fundamental problem with the des= ign is that if it were an ESMTP extension, it would fail clearly per-recipi= ent, whereas this is an all or nothing approach. There's no way to tell= , from the defined response, which mailbox[es] have changed ownership.

>
>
> We discussed this in there (Section 5 of the current draft).=A0 The co= ncern is that there might be an intermediary that doesn't support it, a= t which point you either have to turn the message back or lose the security= as it goes forward.=A0 Neither is acceptable in our use case.

Yes, and I do understand that, but that's an argum= ent against any extension. I agree that this would benefit from header fiel= d magic, I just think having that as a fallback would be better than having= it as a default.

I'm inclined to think that this is a pretty general p= roblem with this sort of work (RFC 6758 being another recent example), and = so maybe there's some work to be done around a general description for = the method of tunneling SMTP extensions through header fields since it'= s come up before.

That said, I suppose this point needs commentary from more p= eople in the area.=A0 Ned in particular mentioned it before, saying that an= extension is architecturally the right way to do it but it's possible = to be successful arguing for doing it this way.=A0 I don't know if we&#= 39;ve made the right arguments here, so more feedback is needed.

>>
>> That said, given the scope, this may not be an issue - however, I&= #39;m slightly confused by this scope. At Arcode, we were considering using= this to mark outgoing messages from our MUA, but this is stated to be inte= nded only for use by automated senders. It's not obvious why, and no ra= tionale is given.
>
> We said that to highlight what the origin of the work is and describe = our use cases.=A0 That doesn't mean this can't be used in other con= texts where it might work; if it makes sense to use this in the context of = user-generated email, that's fine, but we wouldn't expect end users= to maintain a table of when they last knew their various recipients to be = valid so it seems less useful overall for MUAs to do it.=A0 We could add a = remark about that if it would help.

If this is merely a perspective, that's fine, and = yes - a remark or two clarifying scope would be useful.


Added for the next version.
=A0

>>
>> Section 3 contains the recommendation to remove the header field. = This seems wrong to me - I would suggest that:
>>
>> a) It's useful for debugging purposes to keep it.
>>
>> b) If the header is signed via DKIM (which is breifly discussed la= ter) removal would invalidate the signature, I think.
>
> Right on both counts, which is why we went with RECOMMENDED, which all= ows for local exceptions as long as you have a really good reason to do wha= t you're doing.=A0 Those both seem like good reasons to ignore the reco= mmendation to me.=A0 We should probably point out the DKIM thing explicitly= , however.

What are the really good reasons not to ignore your re= commendation, though?

The date/time at which A verifie= d that B had a particular owner is probably not the kind of thing that shou= ld be accidentally revealed should the message be forwarded or exposed in s= ome other way.

>> 3) The 5.7.7 ESC needs to= have the text syntax defined to include the failing mailbox[es].

>>
>> Dave.
>
> Isn't the text part typically free-form and not specified?

Typically, but there are exceptions - RFC 5321's E= XPN response is specified for the 250 case, for example, in section 3.5.

Dave.


Why&#= 39;s it appropriate here and not elsewhere?=A0 I'm trying to be lazy by= asking that question, but rather I'm trying to understand when it'= s necessary to establish syntax around something that's nearly always f= ree-form, and when it's better not to do so.

-MSK
--001a11c23c2449aa6104e8407ef9-- From dthaler@microsoft.com Thu Oct 10 07:52:13 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F34521E8090 for ; Thu, 10 Oct 2013 07:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.544 X-Spam-Level: X-Spam-Status: No, score=-103.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmoeQ8brZzWq for ; Thu, 10 Oct 2013 07:52:07 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 4470521F9301 for ; Thu, 10 Oct 2013 07:51:42 -0700 (PDT) Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB271.namprd03.prod.outlook.com (10.242.37.14) with Microsoft SMTP Server (TLS) id 15.0.785.10; Thu, 10 Oct 2013 14:51:32 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.62]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.130]) with mapi id 15.00.0785.001; Thu, 10 Oct 2013 14:51:32 +0000 From: Dave Thaler To: "apps-discuss@ietf.org" Thread-Topic: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt Thread-Index: AQHOxce7UfreuZ9+VUWiXUx23KuGZ5nuBJaQ Date: Thu, 10 Oct 2013 14:51:32 +0000 Message-ID: <7e12b97cac364127b5ab56574eecf627@BY2PR03MB269.namprd03.prod.outlook.com> References: <20131010144721.30339.98848.idtracker@ietfa.amsl.com> In-Reply-To: <20131010144721.30339.98848.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.135.4.20] x-forefront-prvs: 0995196AA2 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(13464003)(199002)(189002)(377424004)(81816001)(81686001)(33646001)(80022001)(76482001)(53806001)(66066001)(74876001)(80976001)(54356001)(83072001)(54316002)(46102001)(15202345003)(81542001)(56776001)(51856001)(63696002)(59766001)(47976001)(79102001)(77982001)(74366001)(69226001)(65816001)(50986001)(76786001)(81342001)(74502001)(19580405001)(47446002)(31966008)(4396001)(49866001)(47736001)(83322001)(74662001)(74316001)(19580395003)(76796001)(56816003)(77096001)(76576001)(74706001)(85306002)(15975445006)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB271; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:50.135.4.20; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Subject: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 14:52:13 -0000 VGhpcyBpcyByZWxldmFudCB0byBhcHBzYXdnLiAgQ29tbWVudHMgd2VsY29tZS4NCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAx MCwgMjAxMyA3OjQ3IEFNDQpUbzogRGF2ZSBUaGFsZXINClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtdGhhbGVyLXVyaS1zY2hlbWUtcmVnLXBzLTAwLnR4dA0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC10aGFsZXItdXJpLXNjaGVtZS1yZWctcHMtMDAu dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IERhdmUgVGhhbGVyIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC10aGFsZXIt dXJpLXNjaGVtZS1yZWctcHMNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIEd1aWRlbGluZXMgYW5k IFJlZ2lzdHJhdGlvbiBQcm9jZWR1cmVzIGZvciBOZXcgVVJJIFNjaGVtZXM6IFByb2JsZW0gU3Rh dGVtZW50DQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0xMC0xMA0KR3JvdXA6CQkgSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDYNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdGhhbGVyLXVyaS1zY2hlbWUtcmVnLXBz LTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXRoYWxlci11cmktc2NoZW1lLXJlZy1wcw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10aGFsZXItdXJpLXNjaGVtZS1yZWctcHMtMDANCg0K DQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHNvbWUgcHJvYmxlbXMgd2l0 aCB0aGUgZXhpc3RpbmcgZ3VpZGVsaW5lcw0KICAgYW5kIHByb2NlZHVyZXMsIGFzIGRvY3VtZW50 ZWQgaW4gUkZDIDQzOTUsIGZvciBuZXcgVVJJIHNjaGVtZXMuDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNy ZXRhcmlhdA0K From derhoermi@gmx.net Thu Oct 10 08:05:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A356021E8132 for ; Thu, 10 Oct 2013 08:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.757 X-Spam-Level: X-Spam-Status: No, score=-1.757 tagged_above=-999 required=5 tests=[AWL=0.842, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTXywyylFHXM for ; Thu, 10 Oct 2013 08:05:04 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 41BA321F9F08 for ; Thu, 10 Oct 2013 08:04:21 -0700 (PDT) Received: from netb.Speedport_W_700V ([91.35.13.136]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MO7Ca-1VOo8T1Pym-005alf for ; Thu, 10 Oct 2013 17:04:17 +0200 From: Bjoern Hoehrmann To: Dave Thaler Date: Thu, 10 Oct 2013 17:04:18 +0200 Message-ID: References: <20131010144721.30339.98848.idtracker@ietfa.amsl.com> <7e12b97cac364127b5ab56574eecf627@BY2PR03MB269.namprd03.prod.outlook.com> In-Reply-To: <7e12b97cac364127b5ab56574eecf627@BY2PR03MB269.namprd03.prod.outlook.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:oOEgWcJu0Unt3Ene+aOO+q4yOJZYmgKDIWthIMtp0/8ByXLy2D6 98OqDbg34dXK4zymPq0+85BQJ9QSd7YT0s4wn4da+ByyT+lZmPKFqCJiiH1vP6o93d8t/u0 O9RY3x9afBppvJyOWhIpySbJTkHb+J9aIGlhmh5PvdDM8M+zaCIYNW4g8Jf0cGUZJo4Qd2q eKmDXKoEDiIxDWrROjRug== Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 15:05:23 -0000 * Dave Thaler wrote: >Htmlized: http://tools.ietf.org/html/draft-thaler-uri-scheme-reg-ps-00 In section 2.1 you write "What if all new applications being submitted to an app store started sending requests for Provisional URI schemes?" That would seem to be a spam or denial of service attack scenario, not people just following best practises, it would seem. Why would we need, or what good would it do, to have more than a couple of hundred schemes? At some point schemes are not sufficiently distinct to warrant multiple top level names. Rather than changing registration guidelines it might be better to tell people to deploy better delegation mechanisms. An OS that can dispatch based on the scheme name, but not on anything else in addresses, is clearly broken, for instance. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From dthaler@microsoft.com Thu Oct 10 08:16:22 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F198521E8132 for ; Thu, 10 Oct 2013 08:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.559 X-Spam-Level: X-Spam-Status: No, score=-103.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BC-02IXJpuX for ; Thu, 10 Oct 2013 08:16:14 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0152.outbound.protection.outlook.com [207.46.163.152]) by ietfa.amsl.com (Postfix) with ESMTP id CDA0211E817D for ; Thu, 10 Oct 2013 08:15:26 -0700 (PDT) Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB272.namprd03.prod.outlook.com (10.242.37.24) with Microsoft SMTP Server (TLS) id 15.0.785.10; Thu, 10 Oct 2013 15:15:09 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.62]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.130]) with mapi id 15.00.0785.001; Thu, 10 Oct 2013 15:15:09 +0000 From: Dave Thaler To: Bjoern Hoehrmann Thread-Topic: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt Thread-Index: AQHOxce7UfreuZ9+VUWiXUx23KuGZ5nuBJaQgAAD1gCAAAIscA== Date: Thu, 10 Oct 2013 15:15:08 +0000 Message-ID: <23c10ed0337840bd91fb413e9160a4d0@BY2PR03MB269.namprd03.prod.outlook.com> References: <20131010144721.30339.98848.idtracker@ietfa.amsl.com> <7e12b97cac364127b5ab56574eecf627@BY2PR03MB269.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.135.4.20] x-forefront-prvs: 0995196AA2 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(51704005)(377454003)(13464003)(24454002)(56776001)(81342001)(31966008)(76482001)(85306002)(16601075003)(74706001)(81542001)(74876001)(74662001)(54316002)(74502001)(47446002)(33646001)(15975445006)(76576001)(76796001)(83072001)(76786001)(74316001)(81816001)(66066001)(56816003)(77096001)(65816001)(51856001)(54356001)(77982001)(53806001)(80022001)(47736001)(47976001)(83322001)(49866001)(50986001)(19580395003)(19580405001)(15202345003)(4396001)(81686001)(69226001)(74366001)(79102001)(63696002)(59766001)(80976001)(46102001)(24736002)(18886065003); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB272; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:50.135.4.20; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 15:16:22 -0000 > -----Original Message----- > From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net] > Sent: Thursday, October 10, 2013 8:04 AM > To: Dave Thaler > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] FW: New Version Notification for draft-thaler= -uri- > scheme-reg-ps-00.txt >=20 > * Dave Thaler wrote: > >Htmlized: http://tools.ietf.org/html/draft-thaler-uri-scheme-reg-= ps-00 >=20 > In section 2.1 you write "What if all new applications being submitted to= an > app store started sending requests for Provisional URI schemes?" >=20 > That would seem to be a spam or denial of service attack scenario, not > people just following best practises, it would seem. Why would we need, o= r > what good would it do, to have more than a couple of hundred schemes? As noted elsewhere in the doc, it's unlikely since there's little/no incent= ive to register anyway. > At some point schemes are not sufficiently distinct to warrant multiple t= op > level names. The quoted guidance about private name spaces is the obvious counter argument to that (it has wording issues but the intent is valid). > Rather than changing registration guidelines it might be better > to tell people to deploy better delegation mechanisms. An OS that can > dispatch based on the scheme name, but not on anything else in addresses, > is clearly broken, for instance. I'd say that ship has already sailed. If you want to suggest a solution, b= y all means write a draft. This document is just the problem statement. -Dave > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 > http://bjoern.hoehrmann.de Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 = =B7 > http://www.bjoernsworld.de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev= .de/ From derhoermi@gmx.net Thu Oct 10 08:47:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C122121F9B08 for ; Thu, 10 Oct 2013 08:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.777, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKUkyOiyIBxd for ; Thu, 10 Oct 2013 08:47:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 625C121F9BF3 for ; Thu, 10 Oct 2013 08:47:05 -0700 (PDT) Received: from netb.Speedport_W_700V ([91.35.13.136]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0LzGV3-1VqPh80IZl-014RFW for ; Thu, 10 Oct 2013 17:47:03 +0200 From: Bjoern Hoehrmann To: Dave Thaler Date: Thu, 10 Oct 2013 17:47:04 +0200 Message-ID: <7mid59tid3u4apv460egn4an94h1mre6a6@hive.bjoern.hoehrmann.de> References: <20131010144721.30339.98848.idtracker@ietfa.amsl.com> <7e12b97cac364127b5ab56574eecf627@BY2PR03MB269.namprd03.prod.outlook.com> <23c10ed0337840bd91fb413e9160a4d0@BY2PR03MB269.namprd03.prod.outlook.com> In-Reply-To: <23c10ed0337840bd91fb413e9160a4d0@BY2PR03MB269.namprd03.prod.outlook.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:v3spWucBTCFmOKJml30+kKNDZxwaNn4WHPJQsjagmg3TwJShHr6 +oNaXzsOkEoHijqZVzNoIt1EXnproNZShHPQldfFyLtkVjhnBtKCnsG2RGnsAx5CA9vSHIW KEQOFod3toJUbHRJVuY8bU7/piQraD1+R6DPsY48gNCxgOxEVMz1R9wRZqe9TmdlFhYVIOy PY0Y+c7L+amqknmNbV3rw== Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 15:47:10 -0000 * Dave Thaler wrote: >> In section 2.1 you write "What if all new applications being submitted to an >> app store started sending requests for Provisional URI schemes?" >As noted elsewhere in the doc, it's unlikely since there's little/no incentive >to register anyway. >I'd say that ship has already sailed. If you want to suggest a solution, by all means >write a draft. This document is just the problem statement. Let me put it differently. I do not understand how the question quoted above is useful in understanding the problem the document is stating. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From dthaler@microsoft.com Thu Oct 10 09:16:52 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A0021F9E9F for ; Thu, 10 Oct 2013 09:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.564 X-Spam-Level: X-Spam-Status: No, score=-103.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KQuLRpYJbeA for ; Thu, 10 Oct 2013 09:16:46 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id 6C64321F9B0D for ; Thu, 10 Oct 2013 09:16:44 -0700 (PDT) Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB271.namprd03.prod.outlook.com (10.242.37.14) with Microsoft SMTP Server (TLS) id 15.0.785.10; Thu, 10 Oct 2013 16:16:42 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.62]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.130]) with mapi id 15.00.0785.001; Thu, 10 Oct 2013 16:16:42 +0000 From: Dave Thaler To: Bjoern Hoehrmann Thread-Topic: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt Thread-Index: AQHOxce7UfreuZ9+VUWiXUx23KuGZ5nuBJaQgAAD1gCAAAIscIAACccAgAAHs5A= Date: Thu, 10 Oct 2013 16:16:41 +0000 Message-ID: <1fdc5b0c5ef043d4884aabd31a3d8c81@BY2PR03MB269.namprd03.prod.outlook.com> References: <20131010144721.30339.98848.idtracker@ietfa.amsl.com> <7e12b97cac364127b5ab56574eecf627@BY2PR03MB269.namprd03.prod.outlook.com> <23c10ed0337840bd91fb413e9160a4d0@BY2PR03MB269.namprd03.prod.outlook.com> <7mid59tid3u4apv460egn4an94h1mre6a6@hive.bjoern.hoehrmann.de> In-Reply-To: <7mid59tid3u4apv460egn4an94h1mre6a6@hive.bjoern.hoehrmann.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.135.4.20] x-forefront-prvs: 0995196AA2 x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(199002)(189002)(13464003)(24454002)(377454003)(74662001)(19580395003)(74316001)(4396001)(47736001)(49866001)(83322001)(76796001)(81342001)(50986001)(76786001)(31966008)(47446002)(19580405001)(74502001)(85306002)(74706001)(77096001)(56816003)(76576001)(74876001)(54316002)(83072001)(54356001)(80976001)(66066001)(46102001)(81686001)(81816001)(80022001)(33646001)(53806001)(76482001)(77982001)(79102001)(74366001)(47976001)(65816001)(69226001)(56776001)(81542001)(63696002)(59766001)(51856001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB271; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:50.135.4.20; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 16:16:52 -0000 > -----Original Message----- > From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net] > Sent: Thursday, October 10, 2013 8:47 AM > To: Dave Thaler > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] FW: New Version Notification for draft-thaler= -uri- > scheme-reg-ps-00.txt >=20 > * Dave Thaler wrote: > >> In section 2.1 you write "What if all new applications being > >> submitted to an app store started sending requests for Provisional URI > schemes?" >=20 > >As noted elsewhere in the doc, it's unlikely since there's little/no > >incentive to register anyway. >=20 > >I'd say that ship has already sailed. If you want to suggest a > >solution, by all means write a draft. This document is just the problem > statement. >=20 > Let me put it differently. I do not understand how the question quoted > above is useful in understanding the problem the document is stating. Ok, let me try to answer that. RFC 4395 defines a set of goals which are quoted in section 1. The current mechanism does not meet those goals. To really meet the stated goals would require the majority of schemes to be registered. The current process cannot scale to do so, given current practice. Hence we either need to change the process or change the goals or both. Does that help? -Dave From tony@att.com Thu Oct 10 09:39:16 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A1E21E8118 for ; Thu, 10 Oct 2013 09:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yc9APwXXmYkT for ; Thu, 10 Oct 2013 09:39:10 -0700 (PDT) Received: from flpi497.enaf.ffdc.sbc.com (egssmtp02.att.com [144.160.128.166]) by ietfa.amsl.com (Postfix) with ESMTP id 9761721E811B for ; Thu, 10 Oct 2013 09:39:10 -0700 (PDT) Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp02.att.com (8.14.5/8.14.5) with ESMTP id r9AGd8Kl014142 for ; Thu, 10 Oct 2013 09:39:09 -0700 Received: from [135.70.69.70] (vpn-135-70-69-70.vpn.swst.att.com[135.70.69.70]) by maillennium.att.com (mailgw1) with ESMTP id <20131010163907gw100q0g39e> (Authid: tony); Thu, 10 Oct 2013 16:39:08 +0000 X-Originating-IP: [135.70.69.70] Message-ID: <5256D82B.2060602@att.com> Date: Thu, 10 Oct 2013 12:39:07 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Dave Thaler References: <20131010144721.30339.98848.idtracker@ietfa.amsl.com> <7e12b97cac364127b5ab56574eecf627@BY2PR03MB269.namprd03.prod.outlook.com> <23c10ed0337840bd91fb413e9160a4d0@BY2PR03MB269.namprd03.prod.outlook.com> <7mid59tid3u4apv460egn4an94h1mre6a6@hive.bjoern.hoehrmann.de> <1fdc5b0c5ef043d4884aabd31a3d8c81@BY2PR03MB269.namprd03.prod.outlook.com> In-Reply-To: <1fdc5b0c5ef043d4884aabd31a3d8c81@BY2PR03MB269.namprd03.prod.outlook.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------040604060908050700010308" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 16:39:17 -0000 This is a multi-part message in MIME format. --------------040604060908050700010308 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/10/2013 12:16 PM, Dave Thaler wrote: > Ok, let me try to answer that. RFC 4395 defines a set of goals which are > quoted in section 1. The current mechanism does not meet those goals. > To really meet the stated goals would require the majority of schemes to > be registered. The current process cannot scale to do so, given current > practice. Hence we either need to change the process or change the goals > or both. Dave, please take a look at draft-ietf-iri-4395bis-irireg. This was an effort to update 4395 for many of the issues you raise as well as updating 4395 for IRIs. Work on it paused when the IRI WG imploded. If you ignore the changes oriented around IRIs, does what is documented there solve the problems that you bring up? (I admit I have not taken your document and done a side-by-side check.) The editors of that draft have discussed resurrecting work on that draft without the IRI working group, but haven't received the kick in the pants needed to do so. Tony Hansen --------------040604060908050700010308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/10/2013 12:16 PM, Dave Thaler wrote: 
Ok, let me try to answer that.  RFC 4395 defines a set of goals which are
quoted in section 1.  The current mechanism does not meet those goals.
To really meet the stated goals would require the majority of schemes to
be registered.  The current process cannot scale to do so, given current
practice.  Hence we either need to change the process or change the goals
or both.

Dave, please take a look at draft-ietf-iri-4395bis-irireg. This was an effort to update 4395 for many of the issues you raise as well as updating 4395 for IRIs. Work on it paused when the IRI WG imploded.

If you ignore the changes oriented around IRIs, does what is documented there solve the problems that you bring up? (I admit I have not taken your document and done a side-by-side check.)

The editors of that draft have discussed resurrecting work on that draft without the IRI working group, but haven't received the kick in the pants needed to do so.

    Tony Hansen
--------------040604060908050700010308-- From ietfc@btconnect.com Fri Oct 11 02:07:00 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E5121E80C1 for ; Fri, 11 Oct 2013 02:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xi1GksUrLkhh for ; Fri, 11 Oct 2013 02:06:54 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 61A4311E8128 for ; Fri, 11 Oct 2013 02:06:53 -0700 (PDT) Received: from mail133-co9-R.bigfish.com (10.236.132.228) by CO9EHSOBE023.bigfish.com (10.236.130.86) with Microsoft SMTP Server id 14.1.225.22; Fri, 11 Oct 2013 09:06:52 +0000 Received: from mail133-co9 (localhost [127.0.0.1]) by mail133-co9-R.bigfish.com (Postfix) with ESMTP id 32967CC01BE for ; Fri, 11 Oct 2013 09:06:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -15 X-BigFish: PS-15(zz9371I936eI542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h20f7h1d1ah1d2ah1fc6hz97hz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail133-co9 (localhost.localdomain [127.0.0.1]) by mail133-co9 (MessageSwitch) id 1381482409991499_21449; Fri, 11 Oct 2013 09:06:49 +0000 (UTC) Received: from CO9EHSMHS019.bigfish.com (unknown [10.236.132.238]) by mail133-co9.bigfish.com (Postfix) with ESMTP id ECF1C3C0055; Fri, 11 Oct 2013 09:06:49 +0000 (UTC) Received: from AM2PRD0710HT003.eurprd07.prod.outlook.com (157.56.249.213) by CO9EHSMHS019.bigfish.com (10.236.130.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 11 Oct 2013 09:06:49 +0000 Received: from DB3PRD0411HT003.eurprd04.prod.outlook.com (157.56.253.53) by pod51017.outlook.com (10.255.165.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 11 Oct 2013 09:06:38 +0000 Message-ID: <019e01cec660$f1b5b2e0$4001a8c0@gateway.2wire.net> From: t.petch To: Dave Thaler , References: <20131010144721.30339.98848.idtracker@ietfa.amsl.com> <7e12b97cac364127b5ab56574eecf627@BY2PR03MB269.namprd03.prod.outlook.com> Date: Fri, 11 Oct 2013 09:48:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.53] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 09:07:00 -0000 Dave What do you mean by "such that when the URI is accessed"? Is this the user clicking on an anchor, an API call, both, neither...? I am used to using URI to access resources, I am not clear what you mean to access a URI. I sort of get the feeling that the context of this is smartphones, of whose technology I am ignorant. Tom Petch ----- Original Message ----- From: "Dave Thaler" To: Sent: Thursday, October 10, 2013 3:51 PM Subject: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt > This is relevant to appsawg. Comments welcome. > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, October 10, 2013 7:47 AM > To: Dave Thaler > Subject: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt > > > A new version of I-D, draft-thaler-uri-scheme-reg-ps-00.txt > has been successfully submitted by Dave Thaler and posted to the IETF repository. > > Filename: draft-thaler-uri-scheme-reg-ps > Revision: 00 > Title: Guidelines and Registration Procedures for New URI Schemes: Problem Statement > Creation date: 2013-10-10 > Group: Individual Submission > Number of pages: 6 > URL: http://www.ietf.org/internet-drafts/draft-thaler-uri-scheme-reg-ps-00.tx t > Status: http://datatracker.ietf.org/doc/draft-thaler-uri-scheme-reg-ps > Htmlized: http://tools.ietf.org/html/draft-thaler-uri-scheme-reg-ps-00 > > > Abstract: > This document describes some problems with the existing guidelines > and procedures, as documented in RFC 4395, for new URI schemes. > > > 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. > > The IETF Secretariat > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From dthaler@microsoft.com Fri Oct 11 10:50:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A0321E81EC for ; Fri, 11 Oct 2013 10:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.546 X-Spam-Level: X-Spam-Status: No, score=-103.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjtHcQx8ImGo for ; Fri, 11 Oct 2013 10:50:05 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0154.outbound.protection.outlook.com [207.46.163.154]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6AF21E81E4 for ; Fri, 11 Oct 2013 10:50:04 -0700 (PDT) Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) with Microsoft SMTP Server (TLS) id 15.0.800.7; Fri, 11 Oct 2013 17:50:00 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.163]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.163]) with mapi id 15.00.0800.005; Fri, 11 Oct 2013 17:50:00 +0000 From: Dave Thaler To: Tony Hansen Thread-Topic: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt Thread-Index: AQHOxce7UfreuZ9+VUWiXUx23KuGZ5nuBJaQgAAD1gCAAAIscIAACccAgAAHs5CAAAbYgIABpRPQ Date: Fri, 11 Oct 2013 17:49:59 +0000 Message-ID: <787b0d38ce9d43d2a93cd5a89b0855c6@BY2PR03MB269.namprd03.prod.outlook.com> References: <20131010144721.30339.98848.idtracker@ietfa.amsl.com> <7e12b97cac364127b5ab56574eecf627@BY2PR03MB269.namprd03.prod.outlook.com> <23c10ed0337840bd91fb413e9160a4d0@BY2PR03MB269.namprd03.prod.outlook.com> <7mid59tid3u4apv460egn4an94h1mre6a6@hive.bjoern.hoehrmann.de> <1fdc5b0c5ef043d4884aabd31a3d8c81@BY2PR03MB269.namprd03.prod.outlook.com> <5256D82B.2060602@att.com> In-Reply-To: <5256D82B.2060602@att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::3] x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(479174003)(377454003)(199002)(24454002)(46102001)(80022001)(81542001)(65816001)(56776001)(80976001)(54316002)(74366001)(56816003)(81342001)(74502001)(81816001)(47446002)(53806001)(54356001)(15975445006)(19580395003)(15202345003)(33646001)(74706001)(74662001)(81686001)(74876001)(19580405001)(83322001)(69226001)(85306002)(76786001)(4396001)(59766001)(77982001)(74316001)(19300405004)(76796001)(83072001)(63696002)(77096001)(51856001)(16236675002)(47736001)(49866001)(50986001)(47976001)(31966008)(79102001)(76482001)(76576001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB269; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ee31::3; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_787b0d38ce9d43d2a93cd5a89b0855c6BY2PR03MB269namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 17:50:11 -0000 --_000_787b0d38ce9d43d2a93cd5a89b0855c6BY2PR03MB269namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, I know, I've reviewed that document many times. I considered referen= cing it in my draft but ended up deleting references to it because it didn't really change the = problem statement. I could add the reference back in in a -01 if it would help. So in short: no the latest version does not address the issues or I would h= ave just been arguing for publishing it as is. However, that is the doc that I would expect the = solution to the problems to be done in, but as I'm not currently a co-author (about the time IRI WG = was closed, I did volunteer to help edit the document as I do think it's important) and becau= se I want to focus discussion on the problem without presuming a particular solution, I wrote = a separate draft for now that I would expect to go away once we decide on an appropriate dir= ection. -Dave From: Tony Hansen [mailto:tony@att.com] Sent: Thursday, October 10, 2013 9:39 AM To: Dave Thaler Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] FW: New Version Notification for draft-thaler-u= ri-scheme-reg-ps-00.txt On 10/10/2013 12:16 PM, Dave Thaler wrote: Ok, let me try to answer that. RFC 4395 defines a set of goals which are quoted in section 1. The current mechanism does not meet those goals. To really meet the stated goals would require the majority of schemes to be registered. The current process cannot scale to do so, given current practice. Hence we either need to change the process or change the goals or both. Dave, please take a look at draft-ietf-iri-4395bis-irireg. This was an effo= rt to update 4395 for many of the issues you raise as well as updating 4395= for IRIs. Work on it paused when the IRI WG imploded. If you ignore the changes oriented around IRIs, does what is documented the= re solve the problems that you bring up? (I admit I have not taken your doc= ument and done a side-by-side check.) The editors of that draft have discussed resurrecting work on that draft wi= thout the IRI working group, but haven't received the kick in the pants nee= ded to do so. Tony Hansen --_000_787b0d38ce9d43d2a93cd5a89b0855c6BY2PR03MB269namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, I know, I’ve r= eviewed that document many times.   I considered referencing it i= n my draft

but ended up deleting ref= erences to it because it didn’t really change the problem statement.<= o:p>

I could add the reference= back in in a -01 if it would help.

 <= /p>

So in short: no the lates= t version does not address the issues or I would have just been arguing

for publishing it as is.&= nbsp; However, that is the doc that I would expect the solution to the prob= lems

to be done in, but as I&#= 8217;m not currently a co-author (about the time IRI WG was closed, I did

volunteer to help edit th= e document as I do think it’s important) and because I want to focus<= o:p>

discussion on the problem= without presuming a particular solution, I wrote a separate draft

for now that I would expe= ct to go away once we decide on an appropriate direction.=

 <= /p>

-Dave

 <= /p>

From: Tony Hansen [mailto:tony@att.com]
Sent: Thursday, October 10, 2013 9:39 AM
To: Dave Thaler
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] FW: New Version Notification for draft-t= haler-uri-scheme-reg-ps-00.txt

 

On 10/10/2013 12:16 PM, Dave Thaler wrote: 

Ok, let me try to answer that.  RFC 4395 defines a set of goals w=
hich are
quoted in section 1.  The current mechanism does not meet those g=
oals.
To really meet the stated goals would require the majority of schemes =
to
be registered.  The current process cannot scale to do so, given =
current
practice.  Hence we either need to change the process or change t=
he goals
or both.


Dave, please take a look at draft-ietf-iri-4395bis-irireg. This was an effo= rt to update 4395 for many of the issues you raise as well as updating 4395= for IRIs. Work on it paused when the IRI WG imploded.

If you ignore the changes oriented around IRIs, does what is documented the= re solve the problems that you bring up? (I admit I have not taken your doc= ument and done a side-by-side check.)

The editors of that draft have discussed resurrecting work on that draft wi= thout the IRI working group, but haven't received the kick in the pants nee= ded to do so.

    Tony Hansen

--_000_787b0d38ce9d43d2a93cd5a89b0855c6BY2PR03MB269namprd03pro_-- From dthaler@microsoft.com Fri Oct 11 11:01:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1CF11E80E0 for ; Fri, 11 Oct 2013 11:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.55 X-Spam-Level: X-Spam-Status: No, score=-103.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sobnJ5ckX9OB for ; Fri, 11 Oct 2013 11:01:14 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id D6D6421F9D87 for ; Fri, 11 Oct 2013 11:01:13 -0700 (PDT) Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) with Microsoft SMTP Server (TLS) id 15.0.800.7; Fri, 11 Oct 2013 18:01:05 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.163]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.163]) with mapi id 15.00.0800.005; Fri, 11 Oct 2013 18:01:05 +0000 From: Dave Thaler To: t.petch , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt Thread-Index: AQHOxce7UfreuZ9+VUWiXUx23KuGZ5nuBJaQgAEyjUKAAJH2UA== Date: Fri, 11 Oct 2013 18:01:05 +0000 Message-ID: <360e6b873a8a48f2ac5d5f76f3105b9f@BY2PR03MB269.namprd03.prod.outlook.com> References: <20131010144721.30339.98848.idtracker@ietfa.amsl.com> <7e12b97cac364127b5ab56574eecf627@BY2PR03MB269.namprd03.prod.outlook.com> <019e01cec660$f1b5b2e0$4001a8c0@gateway.2wire.net> In-Reply-To: <019e01cec660$f1b5b2e0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::3] x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(51704005)(74316001)(76796001)(76786001)(4396001)(59766001)(77982001)(50986001)(47976001)(49866001)(47736001)(79102001)(76576001)(76482001)(31966008)(83072001)(77096001)(63696002)(51856001)(81816001)(74502001)(47446002)(81342001)(74366001)(56816003)(54356001)(53806001)(46102001)(65816001)(81542001)(80022001)(54316002)(80976001)(56776001)(33646001)(74706001)(74662001)(69226001)(83322001)(85306002)(81686001)(74876001)(15975445006)(15202345003)(19580395003)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB269; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ee31::3; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 18:01:19 -0000 Tom Petch writes: > What do you mean by > "such that when the URI is accessed"? >=20 > Is this the user clicking on an anchor, an API call, both, neither...? > I am used to using URI to access resources, I am not clear what you mean = to > access a URI. Both. I could clarify this in an update to the document, but from a brows= er it means clicking on a link. From another app it generally means an API call. For = example on Windows, LaunchUriAsync (http://msdn.microsoft.com/en-us/library/windows/apps/Hh7014= 80.aspx) Is one such API. > I sort of get the feeling that the context of this is smartphones, > of whose technology I am ignorant. Not specific to smartphones. It happens on many platforms including PCs, Mac OSX, smartphones, etc. -Dave=20 From hsantos@isdg.net Mon Oct 14 10:59:55 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E36611E8156 for ; Mon, 14 Oct 2013 10:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2wNVt4Z+zz3 for ; Mon, 14 Oct 2013 10:59:50 -0700 (PDT) Received: from mail.santronics.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3B31D11E8152 for ; Mon, 14 Oct 2013 10:59:49 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3212; t=1381773588; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=sb+6VibT6q2Mfv25oFXBFuHROm8=; b=qOhwm4BAgjV2reC4xv56 8mg+zKGPn7fHutHTD24XYwN7F9Hbq176z9S5JKCKMFff7ToHppZtS6FSJdHjUy2e bzm+laCMcKPRhU7980T8PhYgUBcTG17ol33V728Ura/9Gg6EcVs9T8Ace6yRmy6R QaIAmftvVVU06WdXVKmCQZs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 14 Oct 2013 13:59:48 -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; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3941083338.17297.4784; Mon, 14 Oct 2013 13:59:47 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3212; t=1381773181; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=NdR6VmL 2sP/9pPfMA8Pdfr69jLQ1iWEkw8VCK18HOic=; b=mXGvM2Ry5GLXasib8w9jv1j gBhpWIE31ov6nOeQzUHC5Tsr0w3g7cF4CpTNfMRCENE5Bi4h9j7ZyvfLJB0cSsto k0ja9UOWjCL89oMhGFPxKLe4smLr9njoqoJMbZoHzAcREWALbSLPajJJQ0RLhF0T rfCaFLq+NinqfHJfXVyA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 14 Oct 2013 13:53:01 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3387461659.9.1804; Mon, 14 Oct 2013 13:53:00 -0400 Message-ID: <525C310D.3050406@isdg.net> Date: Mon, 14 Oct 2013 13:59:41 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "J. Trent Adams" References: <52531B74.4090403@gmail.com> In-Reply-To: <52531B74.4090403@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Shepherding the Require-Recipient-Valid-Since Header Field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Oct 2013 17:59:55 -0000 As a potential implementer, I have reviewed the draft and much of the follow up discussions. I believe this should be a dual solution with an ESMTP Extension with the payload 5322 RRVS header solution. This will resolved two issues: 1) The optimization and high rate of rejection at the RCPT TO state machine with 55x responses. 2) Two different scripting tools used for Envelope checking (4 parameters; IP, client machine name, return path and forwarding path) and Payload (5322 parts) filtering at DATA EOD (End of Data). Overall the draft is promoting a shift to the higher overhead DATA payload rejection with very little utility and general purpose. I won't repeat but I agree 100% with all the security related concerns mentioned. I don't see the pros outweighing the cons here. This solution works best in isolated proprietary or joint venture environments but not in a public environment. We have sysadm (system administrator) scripting tools to purge accounts because on their own rules. I can see some value in processing inbound but don't see why the exporting (creation of RRVS headers) of mail should expose these generally very private information, not only private to the user but private to the vendor BI (business intelligence). Maybe the true value of this proposal is just in the proposed reply status code that may help some clients. But ultimately, it is a common and general 55x response and behavior despite the details. If the proposal expects ESMTP support for extended replies, then it should be using EHLO rather than HELO in its example. In other words, the receiver processing an HELO client COULD BE disabling any extended responses. I have to double check, but maybe it MUST disable the extended responses when there is a fallback HELO support mode activated. I think this proposal should be an experimental as there is really no "standard" approach to cleaning up and reusing expired user accounts. Perhaps this is more of an informational status document allowing Yahoo and Facebook to describe how they plan to cooperate with automated messages and to clean up old user accounts. More of a problem statement. I can see better and more secured methods than this "proposed standard" method described. -- Hector Santos, CTO http://www.santronics.com On 10/7/2013 4:37 PM, J. Trent Adams wrote: > > Folks - > > I've been asked to help shepherd the Require-Recipient-Valid-Since > Header Field (draft-ietf-appsawg-rrvs-header-field-00) specification. > > For easy reference, here's a link to the specification in the datatracker: > > https://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field/ > > As a reminder, there was a flury of activity in early August, but the > dust seems to have settled around the initial set of comments. > > As IETF 88 is just around the corner, it'd be great to see if we could > tackle any remaining issues before the moratorium on updates. In fact, > perhaps we're close to closing out all open issues and could target > moving into last call. > > Anyway, please fire off any suggestions that you'd like to see addressed. > > Thanks, > Trent > -- HLS From hsantos@isdg.net Mon Oct 14 11:21:16 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D413D11E8187 for ; Mon, 14 Oct 2013 11:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPqiKCDvJd4i for ; Mon, 14 Oct 2013 11:21:11 -0700 (PDT) Received: from mail.santronics.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2B11411E8189 for ; Mon, 14 Oct 2013 11:21:09 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2080; t=1381774864; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=MXE83d2TTOEaoDQC/ULakoytiVw=; b=pj+zz4rxmnNr0krMcUqP oCQ5z1RyCqclrzvCecmPx5UhMsf60mpraPoscnumQjD/ElpHLhOP+fmANepLF273 VgH89t9GXjaUVUpoyvxUxrDuz56bG6VTyZYBTdkOGu+gu//yWqwOkV2FKxnPieYZ VFnslgZT32YjnBFwiTFM3io= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 14 Oct 2013 14:21:04 -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; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3942358771.17297.5172; Mon, 14 Oct 2013 14:21:03 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2080; t=1381774458; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Ravrh7w ISEKwvthXNbwfydScIbRO1le9Ww5n4qS6ZRU=; b=QENKKJPvSk47Cr4k1xojn9m HIkkLrbo0d7sDFFv5QR1c9Wnk/jgSxD+H0KYDW59ffPO98dBozBukh63NdmjlHoE 0g2xW7Xymh+1Vlk0VJmejc1dOK9m/lXPWa2WfuxtI2ms0hSK18VjuRY4yjKPR9QR mUr8Qi2Bl7A9z2IXcbPw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 14 Oct 2013 14:14:18 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3388739941.9.6948; Mon, 14 Oct 2013 14:14:18 -0400 Message-ID: <525C360C.2070200@isdg.net> Date: Mon, 14 Oct 2013 14:21:00 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Bill Mills , IETF Apps Discuss Subject: Re: [apps-discuss] [appsdir] Review request: draft-ietf-appsawg-rrvs-header-field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Oct 2013 18:21:16 -0000 On 10/8/2013 4:20 PM, Murray S. Kucherawy wrote: > I'm inclined to think that this is a pretty general problem with this sort > of work (RFC 6758 being another recent example), and so maybe there's some > work to be done around a general description for the method of tunneling > SMTP extensions through header fields since it's come up before. > That said, I suppose this point needs commentary from more people in the > area. Ned in particular mentioned it before, saying that an extension is > architecturally the right way to do it but it's possible to be successful > arguing for doing it this way. I don't know if we've made the right > arguments here, so more feedback is needed. This is a clever ("tunneling") argument, but there are two key reasons to support a dual solution (ESMTP extension and the RRVS payload header): 1) The already highly optimized (no payload transfer required) rejection rate for local user account validation. This is a major consideration in reducing the SORBIG-like bounce attacks by avoiding the higher overhead DATA transfer and processing requirement. 2) As with our package, this may be two different scripting tools; one tool for processing envelope parameters (IP, EHLO/HELO, MAIL FROM, RCPT TO) and one tool for processing the payload using RBM (Rule-Based Messaging) scripts tools, i.e. SIEVE-like based tools. Look at it as supporting the wider coverage because the proposal is promoting a major shift in repeating the same functional design requirement (USER API lookup) with the ultimate same result (55x) to the DATA state machine point from the highly more optimal RCPT TO state machine point. This will definitely increase the processing overhead and also could require a different programming tool with increase complexity in order to implement. Again, with ultimately the same result (55x) there is no real gain in benefits in this design to shift to DATA. So offer both for wider coverage (and potential adoption). -- Hector Santos, CTO http://www.santronics.com From prvs=0992d5ac80=johnl@iecc.com Mon Oct 14 13:02:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4213621E80EE for ; Mon, 14 Oct 2013 13:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgBD8cS8yas2 for ; Mon, 14 Oct 2013 13:02:26 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C674F21E8105 for ; Mon, 14 Oct 2013 13:02:00 -0700 (PDT) Received: (qmail 46212 invoked from network); 14 Oct 2013 20:01:53 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Oct 2013 20:01:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=525c4db1.xn--30v786c.k1310; i=johnl@user.iecc.com; bh=DjKGwttHIGzPL7kah9RFuwjigwbe+jw+/Kr9rTHaauw=; b=XkxDwDQe3avNUFA/cPdzCMnIz+rp6KCuX0OL1Jy2Rh+VcfXbIFq6MCvienOyzd/rafYadaZwT1fqZp+uspRI2dGnMnqZ1V72Rt30805Bo9O3SV5blG6LYfMv5enSTXMZ65qLyVRxwctA/hqePmX7JVW41k12B2fNKX9jFoyXjEd0IERPTt6hNUkvhE1jmc9heuGsUnfxPUUyMWaCDgXGSFw6AUvmhg0K+VINqXzkvkO6/roand2JruhwSSsC2sOQ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=525c4db1.xn--30v786c.k1310; olt=johnl@user.iecc.com; bh=DjKGwttHIGzPL7kah9RFuwjigwbe+jw+/Kr9rTHaauw=; b=N2Pyrx6UsGjgfPwzRa5zHHb3JZoc/nGvX0XUOJhBPHl1Ifnf9NKipf4tdekK/7VVcIQ4Bd0LAUSdJjwRgN/NMIsY1FjZzl7Ly5Pp+KIDJEkivxpDh2B2GHLpvy9UeZHqzXGNiQF7vYJglDqzmv5eCXkVFS0VJgAHALLb75/k+vAATbR+nAICHVD78xEDW8lNVLw31MXPJ6wLaE6G9O2jenbMzfaPzLKW6YyheGFAV0XLR+7jqcGCuZ0fGrf4rBO4 Date: 14 Oct 2013 20:01:31 -0000 Message-ID: <20131014200131.53936.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] Shepherding the Require-Recipient-Valid-Since Header Field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Oct 2013 20:02:40 -0000 >Thanks, Trent. The authors have nothing outstanding here, so any >outstanding comments or even some reviews would be great. It's nearly ready to ship. In section 3, on page 4, delete step 3, delete the last sentence of step 5 (which will now be step 4) and add: 5. If the address is a role account as listed in [ROLES], deliver the message whether or not the address has been under continuous ownership. If the address has not, alert the recipient when she reads the message that it was likely intended for one of her predecessors, if it is practical to do so. 6. Otherwise, if the address has not been under continuous ownership, reject the message. If I register foo.example, and I get mail to uucp@foo.example, with a RRVS header from a year ago, it's intended for the previous registrant, which is useful to know. (On the other hand, try sending mail to uucp@computer.org.) You might put a note in 8.2 reminding people that if a domain has been registered before, you don't know what addresses the prior owner assigned, hence no addresses can be known not to have had a single owner, or not to have existed at all. Since the question has arisen again, I agree that an SMTP extension would be a bad idea, for the reasons listed in section 5. From masinter@adobe.com Mon Oct 14 14:34:27 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3D821E8108 for ; Mon, 14 Oct 2013 14:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.595 X-Spam-Level: X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpifGYDNvVoQ for ; Mon, 14 Oct 2013 14:34:23 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id EBB2921E812E for ; Mon, 14 Oct 2013 14:34:19 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKUlxjWwfE8T/eIQhUYtfT3TyRvYZsd9+Y@postini.com; Mon, 14 Oct 2013 14:34:20 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1.corp.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r9ELYHQu002077 for ; Mon, 14 Oct 2013 14:34:17 -0700 (PDT) Received: from SJ1SWM219.corp.adobe.com (sj1swm219.corp.adobe.com [10.5.77.61]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r9ELYG6A018629 for ; Mon, 14 Oct 2013 14:34:16 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by SJ1SWM219.corp.adobe.com ([fe80::d55c:7209:7a34:fcf7%11]) with mapi; Mon, 14 Oct 2013 14:34:16 -0700 From: Larry Masinter To: "apps-discuss@ietf.org" Date: Mon, 14 Oct 2013 14:34:14 -0700 Thread-Topic: registering "feed:" and "javascript:" ? Thread-Index: Ac7JJNJ0lNuwx+54QcWBqvILeu9lyA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [apps-discuss] registering "feed:" and "javascript:" ? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Oct 2013 21:34:27 -0000 Did http://tools.ietf.org/html/draft-hoehrmann-javascript-scheme-03 get dro= pped? should http://www.iana.org/assignments/uri-schemes/prov/feed be moved to pe= rmanent? Larry From dret@berkeley.edu Tue Oct 15 00:45:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DCA21E80B2 for ; Tue, 15 Oct 2013 00:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VdYWamv941y for ; Tue, 15 Oct 2013 00:45:53 -0700 (PDT) Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id E167721E80AE for ; Tue, 15 Oct 2013 00:45:50 -0700 (PDT) Received: from rrcs-173-197-107-11.west.biz.rr.com ([173.197.107.11] helo=dretair.local) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1VVzK8-0005ni-K6; Tue, 15 Oct 2013 00:45:50 -0700 Message-ID: <525CF2A8.2090904@berkeley.edu> Date: Mon, 14 Oct 2013 21:45:44 -1000 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <5238B9E9.7010204@gmx.de> In-Reply-To: <5238B9E9.7010204@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Reschke Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 07:45:58 -0000 On 2013-09-17 10:22 , Julian Reschke wrote: > On 2013-07-29 10:08, Murray S. Kucherawy wrote: >> This note begins a Working Group Last Call for >> draft-ietf-appsawg-xml-mediatypes, ending on Friday, August 16. >> Please provide reviews and comments on this list or privately to the >> authors as soon as possible. > Here's my late feedback (IETF, interim meetings, vacation, etc pp): here's my even later feedback for draft-ietf-appsawg-xml-mediatypes first of all, i'd like to thank julian for his very thorough review, and i think for all the charset-related issues, he's definitely in a much better position to provide feedback than i am. therefore i am supporting the comments julian made in his review, and my review is focusing more on the XML side of things. > Network Working Group C. Lilley > Internet-Draft W3C > Obsoletes: 3023 (if approved) M. Murata > Updates: 4289, 6839 (if approved) International University of Japan i guess i have the same question here as julian: why would it update RFC 6839, instead of just referencing it? if this is just the technicality of RFC 6839 referencing this draft, then that would probably answer my question. > This specification standardizes three media types -- application/xml, > application/xml-external-parsed-entity, and application/xml-dtd -- > for use in exchanging network entities that are related to the > Extensible Markup Language (XML) while defining text/xml and text/ > xml-external-parsed-entity as aliases for the respective application/ > types. This specification also standardizes a convention (using the > suffix '+xml') for naming media types outside of these five types > when those media types represent XML MIME entities. isn't that convention standardized by RFC 6839 already? i guess the problem is that instead of defining a registry that can be updated, any change to the suffixes needs to update RFC 6839? maybe rephrase this to say "updates the convention", because when reading this abstract, people knowing RFC 6839 may be wondering what's going on. > Major differences from [RFC3023] are alignment of charset handling > for text/xml and text/xml-external-parsed-entity with application/ > xml, the addition of XPointer and XML Base as fragment identifiers > and base URIs, respectively, mention of the XPointer Registry, and > updating of many references. agree with julian that this is should not be part of the abstract. it's useful and probably could be easily moved to someplace else. > 3. XML Media Types > This specification standardizes three media types related to XML MIME > entities: application/xml (with text/xml as an alias), application/ > xml-external-parsed-entity (with text/xml-external-parsed-entity as > an alias), and application/xml-dtd. Registration information for > these media types is described in the sections below. it would be useful to add application/xsd+xml in the updated spec, since XSD does not have its own media type. > The top-level media type "text" has some restrictions on MIME > entities and they are described in [RFC2045] and [RFC2046]. In > particular, for transports other than HTTP [RFC2616] or HTTPS > (which uses a MIME-like mechanism). the UTF-16 family, UCS-4, and > UTF-32 are not allowed However, section 4.3.3 of [XML] says: s/mechanism). the/mechanism), the i am not quite understanding the paranthesis after HTTPS. isn't HTTP doing exactly the same as HTTP, only over a safe transport? what does "which uses a MIME-like mechanism" refer to? > XML provides a general framework for defining sequences of structured > data. In some cases, it may be desirable to define new media types > that use XML but define a specific application of XML, perhaps due to > domain-specific display, editing, security considerations or runtime > information. the "perhaps" part seems a bit modest. there's quite a large set of web service designers thinking that unless you are exposing generic XML facilities (such as an XML database), you shouldn't be using a generic XML media type. so i would not make this sound as restricted as it is sounding now. > Interoperability considerations: XML has proven to be interoperable > across both generic and task-specific applications and for import > and export from multiple XML authoring and editting tools. For s/editting/editing/ > Applications that use this media type: XML is device-, platform-, > and vendor-neutral and is supported by a wide range of generic XML > tools (editors, parsers, Web agents, ...) and task-specific > applications. i am not sure this needs to be spelled out, but in between generic XML and task-specific applications, there's a large set of generic XML-based formats (such as Atom) which does not really seem to fit well into this characterization of applications? > Although no byte sequences can be counted on to always be > present, XML MIME entities in ASCII-compatible charsets s/charsets/character sets/ > (including UTF-8) often begin with hexadecimal 3C 3F 78 6D 6C > (" FF 00 3C 00 3F 00 78 00 6D 00 6C or FF FE 3C 00 3F 00 78 00 6D > 00 6C 00 (the Byte Order Mark (BOM) followed by " more information, see Appendix F of [XML]. maybe turn the reference [XML] into [XML1.0], so that it's always easy to see which version you're referencing? > The syntax and semantics of fragment identifiers for the XML media > types defined in this specification are based on the > [XPointerFramework] W3C Recommendation. It allows simple names, and > more complex constructions based on named schemes. When the syntax > of a fragment identifier part of any URI or IRI with a retrieved > media type governed by this specification conforms to the syntax > specified in [XPointerFramework], conformant applications MUST not sure: s/conformant/conforming/ > interpret such fragment identifiers as designating that part of the > retrieved representation specified by [XPointerFramework] and > whatever other specifications define any XPointer schemes used. > Conformant applications MUST support the 'element' scheme as defined again, not sure: s/Conformant/Conforming/ > See Section 8.1 for additional rquirements which apply when an XML- s/rquirements/requirements/ > When a URI has a fragment identifier, it is encoded by a limited > subset of the repertoire of US-ASCII [ASCII] characters, as defined > in [RFC3986]. When an IRI contains a fragment identifier, it is this reads a bit odd. what about saying: "URIs [RFC3986] are encoded in a limited subset of the repertoire of US-ASCII [ASCII], and therefore this encoding applies to fragment identifier parts of URIs as well." an editorial note: sometime, the text is written like this: - "For more information, see Appendix F of [XML]" and sometimes like this: - "a limited subset of the repertoire of US-ASCII [ASCII]" maybe make the entire text consistent by either using references as a noun or not. > Section 5.1 of [RFC3986] specifies that the semantics of a relative > URI reference embedded in a MIME entity is dependent on the base URI. > The base URI is either (1) the base URI embedded in context, (2) the > base URI from the encapsulating entity, (3) the base URI from the > Retrieval URI, or (4) the default base URI, where (1) has the highest > precedence. s/where (1) has the highest precedence./sorted by declining precedence./ > The media type dependent mechanism for embedding the base URI in a > MIME entity of type application/xml, text/xml, application/xml- > external-parsed-entity or text/xml-external-parsed-entity is to use > the xml:base attribute described in detail in [XBase]. maybe rename the reference to [XMLBase] to reflect the name of the spec? not that i think this matters in practice, but this means that it is impossible to use anything other than XML Base for this, right? XML itself really does not say anything about it, so it seems than text/xml goes a little bit in the direction of the infoset set, specifying additional (but fewer) constraints. is the intention to make this a MUST? if so, wouldn't it be appropriate to use normative language? and if not, wouldn't it be good to say that using XML Base probably is a Really Good Idea, but not actually required? > Note that the base URI may be embedded in a different MIME entity, > since the default value for the xml:base attribute may be specified > in an external DTD subset or external parameter entity. so this means that the base URI changes depending on whether the used XML processor is validating or not, right? maybe it would be worth spelling this out, because it may come as a surprise to some. > MIME entities by comparing the subtype to the pattern '*/*+xml'. (Of > course, 4 of the 5 media types defined in this specification -- text/ > xml, application/xml, text/xml-external-parsed-entity, and > application/xml-external-parsed-entity -- also represent XML MIME > entities while not conforming to the '*/*+xml' pattern.) maybe: s/Of Course/For historical reasons/ > The registration process for specific '+xml' media types is described > in [RFC6838] and [RFC6839]. just [RFC6838], i think. > 8.2. +xml Structured Syntax Suffix Registration maybe a formality, but does it need to be registered if it has been an integral part of RFC 6839, and will be updated by RFC 3032bis? doesn't this update mean it exists without having to be registered? > For application... cases, if sent using a 7-bit transport (e.g., s/application.../application\/.../ > Omitting the charset parameter is NOT RECOMMENDED for application/... > when used with transports other than HTTP or HTTPS---text/... SHOULD > NOT be used for 16-bit MIME with transports other than HTTP or HTTPS > (see discussion above (Section 9.2, Paragraph 6)). s/HTTPS---text/HTTPS. text/ > XML MIME entities contain information which may be parsed and further > processed by the recipient's XML system. s/XML system/system/ > These entities may contain > and such systems may permit explicit system level commands to be > executed while processing the data. To the extent that an XML system s/XML system/XML-based system/ i guess i am struggling here to understand what "XML system" is supposed to mean. just the XML processing parts? or the complete system that works with XML-based data? clarifying this upfront might help. > will execute arbitrary command strings, recipients of XML MIME > entities may be a risk. In general, it may be possible to specify > commands that perform unauthorized file operations or make changes to > the display processor's environment that affect subsequent > operations. where do these two rather specific command types (file access, display processor) come from? probably from resolving references within XML content, and trying to render it, but maybe either make that a little more explicit, or keep the warning more general? > The simplest attack involves adding declarations that break > validation. Adding extraneous declarations to a list of character > XML-entities can effectively "break the contract" used by documents. > A tiny change that produces a fatal error in a DTD could halt XML > processing on a large scale. Extraneous declarations are fairly > obvious, but more sophisticated tricks, like changing attributes from > being optional to required, can be difficult to track down. Perhaps > the most dangerous option available to crackers is redefining default > values for attributes: e.g., if developers have relied on defaulted > attributes for security, a relatively small change might expose > enormous quantities of information. this of course only matters if the processing model actually uses a schema language that supports default values. that in itself is something that has been discussed for a long time in terms of benefits and risks. maybe it would be worth pointing out that the security problem only exists when a certain processing model (in this case defined by the choice of schema language) is chosen. > Apart from the structural possibilities, another option, "XML-entity > spoofing," can be used to insert text into documents, vandalizing and > perhaps conveying an unintended message. Because XML permits > multiple XML-entity declarations, and the first declaration takes > precedence, it's possible to insert malicious content where an XML- s/it's/it is/ kind regards, 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 | From derhoermi@gmx.net Tue Oct 15 05:28:01 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0DE11E8188 for ; Tue, 15 Oct 2013 05:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APQPNsm6BPGM for ; Tue, 15 Oct 2013 05:27:57 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3E34E11E8116 for ; Tue, 15 Oct 2013 05:27:57 -0700 (PDT) Received: from netb.Speedport_W_700V ([91.35.29.63]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0LeSOH-1W6Aly3OEH-00q9JO for ; Tue, 15 Oct 2013 14:27:56 +0200 From: Bjoern Hoehrmann To: Erik Wilde Date: Tue, 15 Oct 2013 14:28:00 +0200 Message-ID: <6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de> References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <5238B9E9.7010204@gmx.de> <525CF2A8.2090904@berkeley.edu> In-Reply-To: <525CF2A8.2090904@berkeley.edu> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:3wRT1CSxbW3t/VxWhlCoDArNeW4yVXcjQSoOhND8pk25F2qx5v8 +OPYlaxlCCv4pwo2k9zmazYHKyrrPNge7z/qb3IJYMaDE6naOHLUXB6u1LeqboZPpNuunTS 4tX0v1UgwXWXLUCiub3qq5Gjg4UJ6/nRTZX08aWhrrmW5CPRawFCV0GYynnUcXL3K7bY6ZR LpjR+Wf6McjknJZL8VuyA== Cc: Julian Reschke , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 12:28:02 -0000 * Erik Wilde wrote: >i guess i have the same question here as julian: why would it update RFC >6839, instead of just referencing it? if this is just the technicality >of RFC 6839 referencing this draft, then that would probably answer my >question. The update to RFC 6839 is that RFC 6839 no longer defines the `+xml` structured suffix, draft-ietf-appsawg-xml-mediatypes does that once approved. Note that RFC 6839 took that role from RFC 3023 which it updates for the same reason. >> This specification standardizes three media types -- application/xml, >> application/xml-external-parsed-entity, and application/xml-dtd -- >> for use in exchanging network entities that are related to the >> Extensible Markup Language (XML) while defining text/xml and text/ >> xml-external-parsed-entity as aliases for the respective application/ >> types. This specification also standardizes a convention (using the >> suffix '+xml') for naming media types outside of these five types >> when those media types represent XML MIME entities. > >isn't that convention standardized by RFC 6839 already? i guess the >problem is that instead of defining a registry that can be updated, any >change to the suffixes needs to update RFC 6839? maybe rephrase this to >say "updates the convention", because when reading this abstract, people >knowing RFC 6839 may be wondering what's going on. It seems s/standardizes/defines/ would address this comment. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From julian.reschke@gmx.de Tue Oct 15 05:43:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E09A11E81DA for ; Tue, 15 Oct 2013 05:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.864 X-Spam-Level: X-Spam-Status: No, score=-102.864 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ls-xC7Z9Nurz for ; Tue, 15 Oct 2013 05:43:36 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9A97F11E81E0 for ; Tue, 15 Oct 2013 05:43:32 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0ME33j-1VXNwV0gRD-00HOSS for ; Tue, 15 Oct 2013 14:43:28 +0200 Message-ID: <525D386B.3070705@gmx.de> Date: Tue, 15 Oct 2013 14:43:23 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Bjoern Hoehrmann , Erik Wilde References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <5238B9E9.7010204@gmx.de> <525CF2A8.2090904@berkeley.edu> <6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de> In-Reply-To: <6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:jQQK8XMDlbvFsRoBf2yuWEHtd8l/uFSt3iX/jENkIR7q5JHBgJ+ CKovHGAyhnz0vmPz5dTglkL8cS5H7Db+9wweJx5JJ/Zpw9E8Cg5Nib2A/4pg/lVcCNFqvvG ifXKNqU/aWx7Q/jzjy4JB2J5hiJ8FHS6o1n892Cke6lhHfUMiyXPd6rkD+7gfEdVbfBYk5a oQw/CxYx2lscWSEzYCEsw== Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 12:43:42 -0000 On 2013-10-15 14:28, Bjoern Hoehrmann wrote: > * Erik Wilde wrote: >> i guess i have the same question here as julian: why would it update RFC >> 6839, instead of just referencing it? if this is just the technicality >> of RFC 6839 referencing this draft, then that would probably answer my >> question. > > The update to RFC 6839 is that RFC 6839 no longer defines the `+xml` > structured suffix, draft-ietf-appsawg-xml-mediatypes does that once > approved. Note that RFC 6839 took that role from RFC 3023 which it > updates for the same reason. Yes and no. RFC 6838 established an IANA registry for this, so from now on it's not necessary anymore to do the "update/obsolete" dance. (I may sound like a broken record but it is weird that an RFC that establishes an IANA registry doesn't contain the URI of the registry). > ... Best regards, Julian From derhoermi@gmx.net Tue Oct 15 05:56:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D27111E81E4 for ; Tue, 15 Oct 2013 05:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWqsy53md2H9 for ; Tue, 15 Oct 2013 05:55:58 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 971F811E813B for ; Tue, 15 Oct 2013 05:55:57 -0700 (PDT) Received: from netb.Speedport_W_700V ([91.35.29.63]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0Las1k-1WBxUy2IYq-00kOCn for ; Tue, 15 Oct 2013 14:55:56 +0200 From: Bjoern Hoehrmann To: Julian Reschke Date: Tue, 15 Oct 2013 14:56:01 +0200 Message-ID: References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <5238B9E9.7010204@gmx.de> <525CF2A8.2090904@berkeley.edu> <6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de> <525D386B.3070705@gmx.de> In-Reply-To: <525D386B.3070705@gmx.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:BARgBwdwRGQ1HDSCDeU4HKD81nHZBu5OWo8QWG0FXVHWyJBx3EE j12WVjrBSqXnKvrjfYIozjDL0xkD1RKyFr/hwkEVirDva9nYATlnVtXZa4KnAmn2PxNEUuE 0EjuRvD9ARWT76oDSK9CGvNcCWeRMpTENY7MLtUS6hrwOvWPTTxRNmZX/LEwHGy5yV8U6uv EAj39GaTWNJurvBEj6luQ== Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 12:56:02 -0000 * Julian Reschke wrote: >On 2013-10-15 14:28, Bjoern Hoehrmann wrote: >> * Erik Wilde wrote: >>> i guess i have the same question here as julian: why would it update RFC >>> 6839, instead of just referencing it? if this is just the technicality >>> of RFC 6839 referencing this draft, then that would probably answer my >>> question. >> >> The update to RFC 6839 is that RFC 6839 no longer defines the `+xml` >> structured suffix, draft-ietf-appsawg-xml-mediatypes does that once >> approved. Note that RFC 6839 took that role from RFC 3023 which it >> updates for the same reason. > >Yes and no. RFC 6838 established an IANA registry for this, so from now >on it's not necessary anymore to do the "update/obsolete" dance. I do not know about "necessary", but if RFC 6839 contained only the `+xml` registration I would expect draft-ietf-appsawg-xml-mediatypes to obsolete RFC 6839 just like it obsoletes RFC 3023; but since RFC 6839 contains more than `+xml` it can only "partially obsolete" it, and "Updates" conveys that more clearly than saying nothing. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From julian.reschke@gmx.de Tue Oct 15 06:03:49 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE0F11E8121 for ; Tue, 15 Oct 2013 06:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.811 X-Spam-Level: X-Spam-Status: No, score=-102.811 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrKv5bsO--5T for ; Tue, 15 Oct 2013 06:03:43 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0821321E80C0 for ; Tue, 15 Oct 2013 06:03:35 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MfiFU-1V917p2yUm-00N8q3 for ; Tue, 15 Oct 2013 15:03:33 +0200 Message-ID: <525D3D24.3030702@gmx.de> Date: Tue, 15 Oct 2013 15:03:32 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <5238B9E9.7010204@gmx.de> <525CF2A8.2090904@berkeley.edu> <6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de> <525D386B.3070705@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:UrJrPHfAwJJYSykWsrduYKi1PnDVp9gXJJHwcD0LNHb4Y0hhERd gC4PplignR5sHFAw7NooiyR7h7OOmKa5xHgQ/7DOVVd1aF2NoP8GqRhOGsHItNriXCoiRiy 0natMLbX2JgxuMZR5Um02ZQI3x4eYvmmo8TGEjNgNQAAgrdT3FzKODFrrE7hhCe9Mdbv9/S 02TR1VtNZyfyafPdL+2tA== Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 13:03:49 -0000 On 2013-10-15 14:56, Bjoern Hoehrmann wrote: > * Julian Reschke wrote: >> On 2013-10-15 14:28, Bjoern Hoehrmann wrote: >>> * Erik Wilde wrote: >>>> i guess i have the same question here as julian: why would it update RFC >>>> 6839, instead of just referencing it? if this is just the technicality >>>> of RFC 6839 referencing this draft, then that would probably answer my >>>> question. >>> >>> The update to RFC 6839 is that RFC 6839 no longer defines the `+xml` >>> structured suffix, draft-ietf-appsawg-xml-mediatypes does that once >>> approved. Note that RFC 6839 took that role from RFC 3023 which it >>> updates for the same reason. >> >> Yes and no. RFC 6838 established an IANA registry for this, so from now >> on it's not necessary anymore to do the "update/obsolete" dance. > > I do not know about "necessary", but if RFC 6839 contained only the > `+xml` registration I would expect draft-ietf-appsawg-xml-mediatypes > to obsolete RFC 6839 just like it obsoletes RFC 3023; but since RFC > 6839 contains more than `+xml` it can only "partially obsolete" it, > and "Updates" conveys that more clearly than saying nothing. The point I was trying to make is that we now have a registry. The registry is authoritative; if we move the definition of "+xml", it's sufficient to simply update the registry. Best regards, Julian From ht@inf.ed.ac.uk Tue Oct 15 10:08:48 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEB111E81A1 for ; Tue, 15 Oct 2013 10:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUU5cBCeyjHJ for ; Tue, 15 Oct 2013 10:08:43 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 357AA11E8199 for ; Tue, 15 Oct 2013 10:08:41 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id r9FH8OLb027458; Tue, 15 Oct 2013 18:08:24 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r9FH8MNB008875; Tue, 15 Oct 2013 18:08:22 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r9FH8N07014176; Tue, 15 Oct 2013 18:08:23 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id r9FH8MEc014172; Tue, 15 Oct 2013 18:08:22 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Julian Reschke References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <5238B9E9.7010204@gmx.de> <525CF2A8.2090904@berkeley.edu> <6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de> <525D386B.3070705@gmx.de> <525D3D24.3030702@gmx.de> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 15 Oct 2013 18:08:22 +0100 In-Reply-To: <525D3D24.3030702@gmx.de> (Julian Reschke's message of "Tue\, 15 Oct 2013 15\:03\:32 +0200") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: Bjoern Hoehrmann , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 17:08:48 -0000 Julian Reschke writes: > The point I was trying to make is that we now have a registry. The > registry is authoritative; if we move the definition of "+xml", it's > sufficient to simply update the registry. I don't agree. If we don't include 'Updates: 6839', then 6839 will not get an 'Updated by [3023bis]', and anyone reading 6839 will be free to conclude that it defines +xml, which would be false. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From julian.reschke@gmx.de Tue Oct 15 10:17:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D3E11E80E3 for ; Tue, 15 Oct 2013 10:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.705 X-Spam-Level: X-Spam-Status: No, score=-102.705 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rA01SRifub9S for ; Tue, 15 Oct 2013 10:16:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB4211E81D4 for ; Tue, 15 Oct 2013 10:16:49 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LsOsW-1VuM8u3y8W-0120mv for ; Tue, 15 Oct 2013 19:16:41 +0200 Message-ID: <525D7877.6080905@gmx.de> Date: Tue, 15 Oct 2013 19:16:39 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Henry S. Thompson" References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <5238B9E9.7010204@gmx.de> <525CF2A8.2090904@berkeley.edu> <6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de> <525D386B.3070705@gmx.de> <525D3D24.3030702@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:mdwk6UGPH/NGxeVB+lrIEFjJRFn22zyDwU6jvK9O0Ho0LciwZOq nkUi0aGiMmRzU01ThYJEXk1e9o9wV4J/CcU4cl6MvcKQZurOPry6tEdoSxCtQe7mzXU/yYF ZKESUBlYHN9BMhPbBOPQw+1w1awafVbOUC7tgW0PaQryHDvtwrXnx6JyGP/E7wURx/sAfTD 1Woo4fPh2DHTXsMaEvreQ== Cc: Bjoern Hoehrmann , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 17:17:02 -0000 On 2013-10-15 19:08, Henry S. Thompson wrote: > Julian Reschke writes: > >> The point I was trying to make is that we now have a registry. The >> registry is authoritative; if we move the definition of "+xml", it's >> sufficient to simply update the registry. > > I don't agree. If we don't include 'Updates: 6839', then 6839 will > not get an 'Updated by [3023bis]', and anyone reading 6839 will be > free to conclude that it defines +xml, which would be false. Anyone reading it that way would be reading it incorrectly :-) But anyway, that's something the IESG can worry about. Best regards, Julian From amankin@verisign.com Tue Oct 15 07:01:16 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9108A21F81FF for ; Tue, 15 Oct 2013 07:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.434 X-Spam-Level: X-Spam-Status: No, score=-6.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kgMcorpa2dI for ; Tue, 15 Oct 2013 07:01:11 -0700 (PDT) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id 2140621E80BF for ; Tue, 15 Oct 2013 07:01:04 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKUl1Kn+GDPLc22RnxSYBWsPbDJ/XN+7gp@postini.com; Tue, 15 Oct 2013 07:01:04 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r9FE13WV028719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 15 Oct 2013 10:01:03 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 15 Oct 2013 10:01:02 -0400 From: "Mankin, Allison" To: "apps-discuss@ietf.org" Thread-Topic: NOMCOM 2013 - Need APP Candidates Thread-Index: AQHOya77xc1/7KO9pUWIPurvAx4wQA== Date: Tue, 15 Oct 2013 14:01:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <9845380A1D83F8419F9108835D03078E@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 15 Oct 2013 10:42:35 -0700 Subject: [apps-discuss] NOMCOM 2013 - Need APP Candidates X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 14:01:16 -0000 Hi, Apps-area folks, We are very low on candidates for the APP AD position. Even if you support the present incumbent, there's a lot to be said for accepting a nomination - you'll have learned about your company's willingness to support; you'll have filled out the questionnaire, which I've always found to be a good opportunity to think about one's area and about the IETF; and you'll have experienced and contributed to the nomcom process overall, a key part of the IETF's culture. This process only works because many IETFers take part; please join in. Nominate yourself, or nominate someone whom you've observed working, someone who you think is showing leadership potential, someone who could be a great AD. If there's someone who you think should be an AD in future, ask her or him to consider accepting a nomination now. Deadline for nominations is October 18. Nominate soon to give your nominee(s) enough time to fill in the questionnaire, which is due October 25. Lots more, including which positions are open, how to make a nomination (including nomination of yourself), and how to send us your feedback on the desired expertise, follows. IETFers, let's hear from you! Please make and accept nominations. If you have any questions about the process, feel free to get in touch with= me. Best regards, Allison for the Nomcom Allison Mankin Nomcom Chair 2013-14 ----- The Info You Need for Nominating ----- The 2013-14 Nominating Committee (Nomcom) is seeking nominations from now until October 18, 2013. The open positions being considered by this year's Nomcom can be found later in this section, and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2013/ Information about the desired expertise for positions is here: https://datatracker.ietf.org/nomcom/2013/expertise Nominations may be made by selecting the Nominate link at the top of the Nomcom 2013 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2013/nominate/ Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ Nominations may also be made by email to nomcom13 at ietf.org. If you nominate by email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you use email, please use a separate email fo= r each person you nominate, and for each position (if you are nominating one person for multiple positions). Self-nomination is welcome! No need to be shy. Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. As stated in RFC 5680: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. In all other ways, the confidentiality requirements of RFC 3777/BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the Nomcom on or before October 18, 2013. Please submit your nominations as early as possible for the sake of your nominees, as we've set the questionnaire submission deadline for October 25, 2013. The list of people and posts whose terms end with the March 2014 IETF meeti= ng, and thus the positions for which we are accepting nominations: IAOC Chris Griffiths IAB Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF. Also, please give serious consideration to accepting nominations you receive. The summaries of the desired expertise for the positions, developed by the respective bodies, are found at: https://datatracker.ietf.org/nomcom/2013/expertise/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. You can send us email about this to nomcom13 at ietf.org, and we will use this feedback actively. Thank you for your help in nominating a great pool of strong and interestin= g nominees!= From ullner@gmail.com Sun Oct 13 13:19:07 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C5721F9C8E; Sun, 13 Oct 2013 13:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrofiekQbTuU; Sun, 13 Oct 2013 13:19:06 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC4B21F9C70; Sun, 13 Oct 2013 13:18:57 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id x10so6569853pdj.15 for ; Sun, 13 Oct 2013 13:18: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:date:message-id:subject:from:to :cc:content-type; bh=sc5pMAUn5cD6zK9Jq8UC2BzGvW6d4fX1pA+PiLu5f5g=; b=rYok8WOEY0OXTRnonW08pscJPiFSAslAd85TH/QH1tPjfp3pLEH1uQpWyhGWtjvh+S AgLcx25tzA+M9jasLhZZaIythqVvRy0lp1sd6K0M3kF4eh4VDZr0Xs0/dU6vRB99JWn/ lqiqMhSkNdoYgPZ+1sNYtXxczRWXcXtm40tX+2nFxwLzzVVmT3zC4XiOElXZqONlVoHX Ipf24I5F6+yAknCpMRDAkqvLFUePTyov0y7GPzDtdmPZd9BhxlZA2tkWUOaouwxg2/X2 MX8wRNP3Xu+Gaf5FzUhjgjWaA91NB1HkC1blkMg98E+Rg6sWlZo9zafAPNyB1Ma+plzw HkOw== MIME-Version: 1.0 X-Received: by 10.66.149.231 with SMTP id ud7mr34544613pab.8.1381695537264; Sun, 13 Oct 2013 13:18:57 -0700 (PDT) Received: by 10.68.254.231 with HTTP; Sun, 13 Oct 2013 13:18:57 -0700 (PDT) In-Reply-To: References: <512663B2.20809@tibco.com> <51278B10.10200@ninebynine.org> <513CAD82.409@ninebynine.org> <513E26F5.9080207@tibco.com> Date: Sun, 13 Oct 2013 22:18:57 +0200 Message-ID: From: Fredrik Ullner To: Eric Johnson Content-Type: multipart/alternative; boundary=047d7b6d95d0afc0fa04e8a50fba X-Mailman-Approved-At: Tue, 15 Oct 2013 10:42:46 -0700 Cc: uri-review@ietf.org, Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] URI scheme registration request - dchub X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Oct 2013 20:19:07 -0000 --047d7b6d95d0afc0fa04e8a50fba Content-Type: text/plain; charset=ISO-8859-1 Hi, Sorry, but I'm not sure if the previous link was correctly pointing to the 0.4 version, but here it is: < http://nmdc.sourceforge.net/Versions/nmdc-uri-scheme-0.4.txt> (I blame Gmail) On Sun, Oct 13, 2013 at 9:18 PM, Fredrik Ullner wrote: > Hi, > > There is now a new version of the dchub URI scheme proposal at < > http://nmdc.sourceforge.net/Versions/nmdc-uri-scheme-0.4.txt>. > The following changes have been made: > > * The "Applications/protocols" section revamped to be more generic, so it > doesn't have to specify each implementation. > * Changed from Permanent to Provisional; this is to make sure that the > scheme will be accepted as a first step (possibly later filing a permanent > one, if people find that the scheme provides ample information to deem it > worthy of permanent status). > > For other (minor changes), please see the SVN. > > If people are satisfied with the current scheme specification, I will > proceed to submit it to the appropriate IETF list. > > > -- > Fredrik Ullner > -- Fredrik Ullner --047d7b6d95d0afc0fa04e8a50fba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Sorry, but I'm not sure if the = previous link was correctly pointing to the 0.4 version, but here it is: &l= t;= http://nmdc.sourceforge.net/Versions/nmdc-uri-scheme-0.4.txt> (I bla= me Gmail)


On Sun, Oct 1= 3, 2013 at 9:18 PM, Fredrik Ullner <ullner@gmail.com> wrote:<= br>
Hi,

There is now a new version of the dchub URI scheme= proposal at <http://nmdc.sourceforge.net/Versions/nmdc-uri-scheme-0.4= .txt>. T= he following changes have been made:

=
* The "Applications/pro= tocols" section revamped to be more generic, so it doesn't have to= specify each implementation.
* Changed from Permanent to Provi= sional; this is to make sure that the scheme will be accepted as a first st= ep (possibly later filing a permanent one, if people find that the scheme p= rovides ample information to deem it worthy of permanent status).

For other (minor changes), please see the SVN.

If people are satisfied with the current sche= me specification, I will proceed to submit it to the appropriate IETF list.=


--
Fredrik Ull= ner



--
Fredrik Ulln= er
--047d7b6d95d0afc0fa04e8a50fba-- From ullner@gmail.com Sun Oct 13 12:18:48 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E34921F9473; Sun, 13 Oct 2013 12:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdFsVVDWqFur; Sun, 13 Oct 2013 12:18:48 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id ED6F221F941F; Sun, 13 Oct 2013 12:18:47 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id bj1so6665015pad.14 for ; Sun, 13 Oct 2013 12:18:47 -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=qw/Z1tC8dhHfKnuYx9k9y1F8uPM9aktycDNunNqPqvM=; b=O6BKKyjrIrepv/S/NNbaxZrg6IJSZfWwI2Sr42NRpGiL3zNVzveXvI7QlUTML34OHX PMJr9En/cwTXRUO0w6FkvCTbANMs38uV2vmh/F6BPcICIl8JaTz+TK21EecOl8YekWxi tjXcEx2CuME+egg+uUcSxXIuI9FuwwjT56tVOk8GL5pmDkEga1PVC1AH/Mbiz6vlIw3y DRxZ9mAeJekkqWNRoakP/mwmyjMdoX77Ip9s+JvZvsMF4hN+rLVaLIOWIKTTU/p7edcJ T5VtPXbMK0/MPhMLUtWYsDNsAMZ4AjFBEHk8Uq0X+zn8L0Q2nSCwX73KLqNEw/y8TMZi 4oiw== MIME-Version: 1.0 X-Received: by 10.66.121.201 with SMTP id lm9mr33375229pab.80.1381691927592; Sun, 13 Oct 2013 12:18:47 -0700 (PDT) Received: by 10.68.254.231 with HTTP; Sun, 13 Oct 2013 12:18:47 -0700 (PDT) In-Reply-To: References: <512663B2.20809@tibco.com> <51278B10.10200@ninebynine.org> <513CAD82.409@ninebynine.org> <513E26F5.9080207@tibco.com> Date: Sun, 13 Oct 2013 21:18:47 +0200 Message-ID: From: Fredrik Ullner To: Eric Johnson Content-Type: multipart/alternative; boundary=047d7b2e4ca488848704e8a4383d X-Mailman-Approved-At: Tue, 15 Oct 2013 10:42:58 -0700 Cc: uri-review@ietf.org, Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] URI scheme registration request - dchub X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Oct 2013 19:18:48 -0000 --047d7b2e4ca488848704e8a4383d Content-Type: text/plain; charset=ISO-8859-1 Hi, There is now a new version of the dchub URI scheme proposal at < http://nmdc.sourceforge.net/Versions/nmdc-uri-scheme-0.4.txt>. The following changes have been made: * The "Applications/protocols" section revamped to be more generic, so it doesn't have to specify each implementation. * Changed from Permanent to Provisional; this is to make sure that the scheme will be accepted as a first step (possibly later filing a permanent one, if people find that the scheme provides ample information to deem it worthy of permanent status). For other (minor changes), please see the SVN. If people are satisfied with the current scheme specification, I will proceed to submit it to the appropriate IETF list. -- Fredrik Ullner --047d7b2e4ca488848704e8a4383d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

There is now a new version of the dchub URI scheme= proposal at <http://nmdc.sourceforge.net/Versions/nmdc-uri-scheme-0.4= .txt>. T= he following changes have been made:

=
* The "Applications/protocols" section revamped to be more generic, so it do= esn't have to specify each implementation.
* Changed from P= ermanent to Provisional; this is to make sure that the scheme will be accep= ted as a first step (possibly later filing a permanent one, if people find = that the scheme provides ample information to deem it worthy of permanent s= tatus).

For other (mino= r changes), please see the SVN.

If people a= re satisfied with the current scheme specification, I will proceed to submi= t it to the appropriate IETF list.


--
Fredrik Ull= ner
--047d7b2e4ca488848704e8a4383d-- From tho@koanlogic.com Tue Oct 15 12:11:05 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE70A1F0D5E for ; Tue, 15 Oct 2013 12:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.069 X-Spam-Level: X-Spam-Status: No, score=-1.069 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrMt+5-HBaww for ; Tue, 15 Oct 2013 12:11:00 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1C86221F958A for ; Tue, 15 Oct 2013 12:10:36 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id y6so7235183lbh.34 for ; Tue, 15 Oct 2013 12:10:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=l4gnTNvVKuV6lRyQSU9IMpu1EJtx+rsmQtKqVVXHA6E=; b=mFbxCoaMoxK2gN1abvyqRMWFyJYSoXIL2DnpLEevGW86i5X2pq0Q2LEXqGgdxlwEq+ BMAdPD1Fo+nj+Cz0JM+xcHjba2aBu028lashkThj9j/loTjeSJIrt3GASlsFNFeIOzdo cEs4+mpiq+19b4xImaRgjzsY5s4io4lCgTL6f0rnUqMUcT73r3XTGRCVmCVGmujHlG52 Q+7DhNu7Mkcs4zAHy/AlFSjxW/eJ1aUlr2oCDlxusdVct6mM5dTKoXBP32w4jXuiiqvO wSkVE3OIEf/u6bycBX9lIaEsovKmU5nSNpocA1joYj/wmlpLXHKGn2H1N2Xf3sDF91sN 3nFQ== X-Gm-Message-State: ALoCoQnQ5cOVzKUfeC4EXuF0tkqX6Gau6IpLkznhGfShoCQZP6ZI29R6N1emjLG4KjRIjOEmJiAX MIME-Version: 1.0 X-Received: by 10.112.168.35 with SMTP id zt3mr36172597lbb.11.1381864223927; Tue, 15 Oct 2013 12:10:23 -0700 (PDT) Received: by 10.114.21.4 with HTTP; Tue, 15 Oct 2013 12:10:23 -0700 (PDT) X-Originating-IP: [2.96.108.221] Date: Tue, 15 Oct 2013 20:10:23 +0100 Message-ID: From: Thomas Fossati To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Registering new Link Format attributes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 19:11:06 -0000 Hello all, I need to allocate a new Link Format attribute for use in CoAP, but unfortunately RFC 6690 doesn't explain what the procedure for that would be. (In fact, the three new link format attributes defined there -- rt, if, and sz -- are introduced by further specialising the link-extension production of RFC 5988.) Should I post my request to the "Link Relations" registry? Or is it HTTP specific? Clearly, having precise directions for handling this would help avoiding any collision issue. Cheers From barryleiba.mailing.lists@gmail.com Tue Oct 15 15:03:06 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD38621F9B8D for ; Tue, 15 Oct 2013 15:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.984 X-Spam-Level: X-Spam-Status: No, score=-101.984 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ev68-PHeY34j for ; Tue, 15 Oct 2013 15:03:06 -0700 (PDT) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id AD06F21F9E40 for ; Tue, 15 Oct 2013 15:03:01 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id nc12so6759253qeb.16 for ; Tue, 15 Oct 2013 15:03:01 -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=FOLbDpT4Yipd2O+KCSMfmdp9dq4zjvzn1setbl8JQp8=; b=BXVWs7UInAl87ClXLm0VY6pDUEP3QDrh6tleajIaevCzAMXdZesW7FqSS3aQbLLOJU nUDofMzjphQ5PL5xRkur64CCBXuEwYT9IMPFabng2DFNMzpkRvJh4lSvuG11SOg8KfyO hekV4pXhX02IpLdUXW8OP8c08gtv+KBvi+j2twOlryuvCdy9JGPwui4tAzCJWKULH7W8 n36jih4F1z+6aZY+I94MhCSOeJox39QrPjYE7zWqzIjNs0x5BP+FbSMudcMZBgqaWdQf ZLp86VLVO4B9xx66NE6mmOA6DULm+sAGkt1mHu5ehXGEbozRXRqJsNV3ECrr3t1TPOTK DF+Q== MIME-Version: 1.0 X-Received: by 10.49.88.3 with SMTP id bc3mr36949227qeb.30.1381874580956; Tue, 15 Oct 2013 15:03:00 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.49.86.4 with HTTP; Tue, 15 Oct 2013 15:03:00 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Oct 2013 18:03:00 -0400 X-Google-Sender-Auth: 0BKxnAQRgExnPbqwZlD-f9pf3Pw Message-ID: From: Barry Leiba To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: "Mankin, Allison" Subject: Re: [apps-discuss] NOMCOM 2013 - Need APP Candidates X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 22:03:07 -0000 > We are very low on candidates for the APP AD position. Even if you > support the present incumbent, there's a lot to be said for accepting > a nomination As the present incumbent, I want to stress that I echo what Allison says. While I would like another term, there could be all sorts of reasons that the NomCom would prefer to make a change. Or my job situation could change unexpectedly. The NomCom needs choices to consider; please consider giving them choices. Barry On Tue, Oct 15, 2013 at 10:01 AM, Mankin, Allison wrote: > Hi, Apps-area folks, > > We are very low on candidates for the APP AD position. Even if you > support the present incumbent, there's a lot to be said for accepting > a nomination - you'll have learned about your company's willingness to > support; you'll have filled out the questionnaire, which I've always > found to be a good opportunity to think about one's area and about the > IETF; and you'll have experienced and contributed to the nomcom > process overall, a key part of the IETF's culture. This process only > works because many IETFers take part; please join in. > > Nominate yourself, or nominate someone whom you've observed working, > someone who you think is showing leadership potential, someone who > could be a great AD. If there's someone who you think should be an AD > in future, ask her or him to consider accepting a nomination now. > > Deadline for nominations is October 18. Nominate soon to give your > nominee(s) enough time to fill in the questionnaire, which is due > October 25. > > Lots more, including which positions are open, how to make a nomination > (including nomination of yourself), and how to send us your feedback on > the desired expertise, follows. > > IETFers, let's hear from you! Please make and accept nominations. > > If you have any questions about the process, feel free to get in touch with me. > > Best regards, > > Allison for the Nomcom > > Allison Mankin > Nomcom Chair 2013-14 > > ----- The Info You Need for Nominating ----- > > The 2013-14 Nominating Committee (Nomcom) is seeking nominations > from now until October 18, 2013. The open positions being considered > by this year's Nomcom can be found later in this section, and also on > this year's Nomcom website: > > https://datatracker.ietf.org/nomcom/2013/ > > Information about the desired expertise for positions is here: > https://datatracker.ietf.org/nomcom/2013/expertise > > Nominations may be made by selecting the Nominate link at the top of > the Nomcom 2013 home page, or by visiting the following URL: > > https://datatracker.ietf.org/nomcom/2013/nominate/ > > Note that nominations made using the web tool require an ietf.org > datatracker account. You can create a datatracker ietf.org account > if you don't have one already by visiting the following URL: > > https://datatracker.ietf.org/accounts/create/ > > Nominations may also be made by email to nomcom13 at ietf.org. > If you nominate by email, please include the word "Nominate" in the Subject > and indicate in the email who is being nominated, their email address (to > confirm acceptance of the nomination), and the position for which you > are making the nomination. If you use email, please use a separate email for > each person you nominate, and for each position (if you are nominating one > person for multiple positions). > > Self-nomination is welcome! No need to be shy. > > Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing > Nominees" described in RFC 5680. As stated in RFC 5680: "The list of > nominees willing to be considered for positions under review in the > current Nomcom cycle is not confidential". Willing nominees for each > position will be listed in a publicly accessible way - anyone with a > datatracker account may access the lists. In all other ways, the > confidentiality requirements of RFC 3777/BCP10 remain in effect. All > feedback and all Nomcom deliberations will remain confidential and will > not be disclosed. > > In order to ensure time to collect sufficient community feedback about > each of the willing nominees, nominations must be received by the > Nomcom on or before October 18, 2013. Please submit your nominations > as early as possible for the sake of your nominees, as we've set the > questionnaire submission deadline for October 25, 2013. > > The list of people and posts whose terms end with the March 2014 IETF meeting, > and thus the positions for which we are accepting nominations: > > IAOC > Chris Griffiths > > IAB > Bernard Aboba > Marc Blanchet > Ross Callon > Eliot Lear > Hannes Tschofenig > > IESG > Barry Leiba (Applications) > Brian Haberman (Internet) > Benoit Claise (Operations and Management) > Gonzalo Camarillo (RAI) > Stewart Bryant (Routing) > Sean Turner (Security) > Martin Stiemerling (Transport) > > Please be resourceful in identifying possible candidates for these > positions, as developing our talent is a very crucial requirement for > the IETF. Also, please give serious consideration to accepting nominations > you receive. > > The summaries of the desired expertise for the positions, developed by the > respective bodies, are found at: > > https://datatracker.ietf.org/nomcom/2013/expertise/ > > In addition to nominations, the Nomcom seeks community input on > the positions themselves. We need and welcome the community's > views and input on the jobs within each organization. If you > have ideas on the positions' responsibilities (more, less, > different), please let us know. You can send us email about this to > nomcom13 at ietf.org, and we will use this feedback actively. > > Thank you for your help in nominating a great pool of strong and interesting > nominees! > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From iesg-secretary@ietf.org Tue Oct 15 15:45:31 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CAB21F9DB0; Tue, 15 Oct 2013 15:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.43 X-Spam-Level: X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SM3Sc59DfA3; Tue, 15 Oct 2013 15:45:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F61821F8263; Tue, 15 Oct 2013 15:45:24 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131015224523.2118.3609.idtracker@ietfa.amsl.com> Date: Tue, 15 Oct 2013 15:45:23 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (Advice for Safe Handling of Malformed Messages) to Informational RFC X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 22:45:31 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Advice for Safe Handling of Malformed Messages' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-10-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Although Internet mail formats have been precisely defined since the 1970s, authoring and handling software often show only mild conformance to the specifications. The malformed messages that result are non-standard. Nonetheless, decades of experience has shown that handling with some tolerance the malformations that result is often an acceptable approach, and is better than rejecting the messages outright as nonconformant. This document includes a collection of the best advice available regarding a variety of common malformed mail situations, to be used as implementation guidance. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-malformed-mail/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-malformed-mail/ballot/ No IPR declarations have been submitted directly on this I-D. From duerst@it.aoyama.ac.jp Tue Oct 15 18:30:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B3221F9A2E for ; Tue, 15 Oct 2013 18:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.542 X-Spam-Level: X-Spam-Status: No, score=-103.542 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+eQgAmAvc1L for ; Tue, 15 Oct 2013 18:30:44 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFF121F9A05 for ; Tue, 15 Oct 2013 18:30:43 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r9G1U3PF015972; Wed, 16 Oct 2013 10:30:03 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 260b_53a9_7b2c0388_3602_11e3_a2f0_001e6722eec2; Wed, 16 Oct 2013 10:30:02 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 16271BF521; Wed, 16 Oct 2013 10:30:03 +0900 (JST) Message-ID: <525DEC05.20905@it.aoyama.ac.jp> Date: Wed, 16 Oct 2013 10:29:41 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Dave Thaler References: <20131010144721.30339.98848.idtracker@ietfa.amsl.com> <7e12b97cac364127b5ab56574eecf627@BY2PR03MB269.namprd03.prod.outlook.com> <23c10ed0337840bd91fb413e9160a4d0@BY2PR03MB269.namprd03.prod.outlook.com> <7mid59tid3u4apv460egn4an94h1mre6a6@hive.bjoern.hoehrmann.de> <1fdc5b0c5ef043d4884aabd31a3d8c81@BY2PR03MB269.namprd03.prod.outlook.com> <5256D82B.2060602@att.com> <787b0d38ce9d43d2a93cd5a89b0855c6@BY2PR03MB269.namprd03.prod.outlook.com> In-Reply-To: <787b0d38ce9d43d2a93cd5a89b0855c6@BY2PR03MB269.namprd03.prod.outlook.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 01:30:50 -0000 Hello Dave, On 2013/10/12 2:49, Dave Thaler wrote: > Yes, I know, I've reviewed that document many times. I considered referencing it in my draft > but ended up deleting references to it because it didn't really change the problem statement. > I could add the reference back in in a -01 if it would help. It would help indeed, in the sense that it would show that you had a look at it (which I guessed, but others may not have known) and also to say, in your draft, how it relates to what's in draft-ietf-iri-4395bis-irireg. Regards, Martin. > So in short: no the latest version does not address the issues or I would have just been arguing > for publishing it as is. However, that is the doc that I would expect the solution to the problems > to be done in, but as I'm not currently a co-author (about the time IRI WG was closed, I did > volunteer to help edit the document as I do think it's important) and because I want to focus > discussion on the problem without presuming a particular solution, I wrote a separate draft > for now that I would expect to go away once we decide on an appropriate direction. > > -Dave > > From: Tony Hansen [mailto:tony@att.com] > Sent: Thursday, October 10, 2013 9:39 AM > To: Dave Thaler > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt > > On 10/10/2013 12:16 PM, Dave Thaler wrote: > > Ok, let me try to answer that. RFC 4395 defines a set of goals which are > > quoted in section 1. The current mechanism does not meet those goals. > > To really meet the stated goals would require the majority of schemes to > > be registered. The current process cannot scale to do so, given current > > practice. Hence we either need to change the process or change the goals > > or both. > > Dave, please take a look at draft-ietf-iri-4395bis-irireg. This was an effort to update 4395 for many of the issues you raise as well as updating 4395 for IRIs. Work on it paused when the IRI WG imploded. > > If you ignore the changes oriented around IRIs, does what is documented there solve the problems that you bring up? (I admit I have not taken your document and done a side-by-side check.) > > The editors of that draft have discussed resurrecting work on that draft without the IRI working group, but haven't received the kick in the pants needed to do so. > > Tony Hansen > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From duerst@it.aoyama.ac.jp Tue Oct 15 18:45:33 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0231B21F9B86 for ; Tue, 15 Oct 2013 18:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.556 X-Spam-Level: X-Spam-Status: No, score=-103.556 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1T9wzzczxldO for ; Tue, 15 Oct 2013 18:45:23 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9492621F9611 for ; Tue, 15 Oct 2013 18:45:22 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r9G1jGQ9027834; Wed, 16 Oct 2013 10:45:16 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 260b_57da_9b7493f6_3604_11e3_a2f0_001e6722eec2; Wed, 16 Oct 2013 10:45:15 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 41FF0BF521; Wed, 16 Oct 2013 10:45:16 +0900 (JST) Message-ID: <525DEF96.6050907@it.aoyama.ac.jp> Date: Wed, 16 Oct 2013 10:44:54 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Tony Hansen References: <20131010144721.30339.98848.idtracker@ietfa.amsl.com> <7e12b97cac364127b5ab56574eecf627@BY2PR03MB269.namprd03.prod.outlook.com> <23c10ed0337840bd91fb413e9160a4d0@BY2PR03MB269.namprd03.prod.outlook.com> <7mid59tid3u4apv460egn4an94h1mre6a6@hive.bjoern.hoehrmann.de> <1fdc5b0c5ef043d4884aabd31a3d8c81@BY2PR03MB269.namprd03.prod.outlook.com> <5256D82B.2060602@att.com> In-Reply-To: <5256D82B.2060602@att.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 01:45:34 -0000 Hello Tony, others, On 2013/10/11 1:39, Tony Hansen wrote: > On 10/10/2013 12:16 PM, Dave Thaler wrote: >> Ok, let me try to answer that. RFC 4395 defines a set of goals which are >> quoted in section 1. The current mechanism does not meet those goals. >> To really meet the stated goals would require the majority of schemes to >> be registered. The current process cannot scale to do so, given current >> practice. Hence we either need to change the process or change the goals >> or both. > > Dave, please take a look at draft-ietf-iri-4395bis-irireg. This was an > effort to update 4395 for many of the issues you raise as well as > updating 4395 for IRIs. Work on it paused when the IRI WG imploded. It should be pointed out that the IRI WG imploded not because of *I*RI issues (i.e. not because of internationalization issues) but because of strong differences between browser implementers (or those who claimed to represent them on the few occasions they showed up in the WG) and others more e.g. with an IETF apps background. The main differences were: - Whether to concentrate on how things ought to behave, with occasional detours into aberrations of implementations, or how some actual implementations behaved, warts and all - Spec style: IETF style (ABNFs plus additional constraints) vs. pseudo-code style - Whether to create a spec for protocol elements or a spec including browser APIs - What to call the things (URIs/IRIs vs. URLs) - Whether there was a need to distinguish 'resource' and 'representation' - Whether to have every change go through a WG approval process or whether to have a strong editor who would listen to input when appropriate > If you ignore the changes oriented around IRIs, IRI issues are most probably orthogonal to the issues pointed out in Dave's draft, and in that sense, they can be ignored. On the other hand, as far as I remember, most if not all of the changes oriented around IRIs are independent from the controversies (sketched above) that let to the dissolution of the IRI WG. > does what is documented > there solve the problems that you bring up? (I admit I have not taken > your document and done a side-by-side check.) > > The editors of that draft have discussed resurrecting work on that draft > without the IRI working group, but haven't received the kick in the > pants needed to do so. Yes, please resurrect the work on this draft! Regards, Martin. From duerst@it.aoyama.ac.jp Tue Oct 15 21:08:22 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B5911E8242 for ; Tue, 15 Oct 2013 21:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.634 X-Spam-Level: X-Spam-Status: No, score=-103.634 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuGXY7c716tR for ; Tue, 15 Oct 2013 21:08:16 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4244311E8244 for ; Tue, 15 Oct 2013 21:08:06 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r9G47xte007900; Wed, 16 Oct 2013 13:07:59 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 260b_8359_8b307c4e_3618_11e3_a2f0_001e6722eec2; Wed, 16 Oct 2013 13:07:58 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id C8262BF521; Wed, 16 Oct 2013 13:07:58 +0900 (JST) Message-ID: <525E1109.1000308@it.aoyama.ac.jp> Date: Wed, 16 Oct 2013 13:07:37 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Tony Hansen References: <20131010144721.30339.98848.idtracker@ietfa.amsl.com> <7e12b97cac364127b5ab56574eecf627@BY2PR03MB269.namprd03.prod.outlook.com> <23c10ed0337840bd91fb413e9160a4d0@BY2PR03MB269.namprd03.prod.outlook.com> <7mid59tid3u4apv460egn4an94h1mre6a6@hive.bjoern.hoehrmann.de> <1fdc5b0c5ef043d4884aabd31a3d8c81@BY2PR03MB269.namprd03.prod.outlook.com> <5256D82B.2060602@att.com> <525DEF96.6050907@it.aoyama.ac.jp> In-Reply-To: <525DEF96.6050907@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 04:08:22 -0000 On 2013/10/16 10:44, "Martin J. D=C3=BCrst" wrote: > It should be pointed out that the IRI WG imploded not because of *I*RI > issues (i.e. not because of internationalization issues) but because of > strong differences between browser implementers (or those who claimed t= o > represent them on the few occasions they showed up in the WG) and other= s > more e.g. with an IETF apps background. > > The main differences were: > - Whether to concentrate on how things ought to behave, with occasional > detours into aberrations of implementations, or how some actual > implementations behaved, warts and all > - Spec style: IETF style (ABNFs plus additional constraints) vs. > pseudo-code style > - Whether to create a spec for protocol elements or a spec including > browser APIs one more: - Whether to use 'instant' publishing (each change to the spec, however=20 minor, results in a new publication) or 'occasional' publishing (such as=20 usual with Internet Drafts and RFCs). > - What to call the things (URIs/IRIs vs. URLs) > - Whether there was a need to distinguish 'resource' and 'representatio= n' > - Whether to have every change go through a WG approval process or > whether to have a strong editor who would listen to input when appropri= ate From weihaw@google.com Tue Oct 15 22:27:33 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E59C11E825C for ; Tue, 15 Oct 2013 22:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwpnVNQzaKh8 for ; Tue, 15 Oct 2013 22:27:33 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D6B2911E825B for ; Tue, 15 Oct 2013 22:27:32 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id c9so188456qcz.17 for ; Tue, 15 Oct 2013 22:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=DF5Dl4Iau6IyUGMAMNf7GFPByl3y/9mVZA9Fc8Hrdjo=; b=fwScLqGYcnoK/6rZks08YQGVKQetPqlHorOCEmpN55eR6JqA30QW8r8kFvZno8LkaG RBqPh5Z22uRWc+04vpSo5/tiJlb0Ubn0J+dmA2cb6FYgW/KUhHz2zS5/G72AWqDG12DH Ye056y6zMolqb4XzcsvAAmHQdSsCzld2ltP8TjeCDcrcIp03ZKHSeib6dTTSRSZFyC6R eQltb6xb2LUVpSJl+mabx7a5H28aueAFLcVKvyjmqvLUFQMdd0aIXxTvd8GzjVOErNJ1 yZn4xTYiWHT9pHf0/QM3z2FEP+aMP3eV70GtKkfXfUTYEp26sVzDrIhoFkPAcZ4XHOCN WYTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=DF5Dl4Iau6IyUGMAMNf7GFPByl3y/9mVZA9Fc8Hrdjo=; b=dduGrz0n08QoNnZNibxu3H6OoA0P54CZdfEY2NNco7xYlyzLzkQgoUlCjWKQPRo2CW dFmSHPkJvImBjNLEGRrydjwwyngiPu46jxlC7vgh2aiSTGnu+OOay1mWRThgcVwbpMJV 0lP3CvZXoHm48Xa/83KvZlDHcQ9w5CjQgB7P9XS2Ye+0Bf0NORjsvFU1337R3uQ1In4N tNWKTuVXKk4wKx6BmumEYwyVuTB6zCMOQ0NSWg2oD6ttahkSLc+RDfO4CxM1ZBR68RC/ 11G1c5ejeLPaoV/o+RfnN9hnDaUWaEAHN+5t0gsHoeP/v87U5GMG+3jky/x10fgKecAO La5A== X-Gm-Message-State: ALoCoQlYr3wvNPGKHmlSoirqDcCrCOl/hXVXQl/Pfz4G1gmnPBCSOGYqPiIv42EVvmn0oHNkzCCcvKWiDGXmEwxoI29qpqX4p2RQQFqicJYW+tzDav26zSVXsLdq7e8yqUtC0fD9/vzj3u69qJHycoMOft45k5SGY60azUNbT48rnFG6hceLPz1av0xjSv7N17ByU+r/5SIhBpFBtf2BPHDXtdnFu+G4fA== X-Received: by 10.224.12.207 with SMTP id y15mr1997759qay.101.1381901252415; Tue, 15 Oct 2013 22:27:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.183.132 with HTTP; Tue, 15 Oct 2013 22:27:12 -0700 (PDT) In-Reply-To: References: From: Wei Chuang Date: Tue, 15 Oct 2013 22:27:12 -0700 Message-ID: To: apps-discuss Content-Type: multipart/alternative; boundary=089e0149cf9643ec1204e8d4f511 Subject: [apps-discuss] Fwd: Request for discussion of Mandatory Secure Mail Delivery proposal (draft-wchuang-msmd) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 05:27:33 -0000 --089e0149cf9643ec1204e8d4f511 Content-Type: text/plain; charset=ISO-8859-1 Hi apps-discuss, (resend) Request for discussion (draft-wchuang-msmd) of a proposal to secure mail from eavesdropping and MitM attacks. I posted the primary thread to ietf-smtp@and request that all discussion go to that list . Here's the abstract: Opportunistic SMTP TLS does not enforce electronic mail delivery using TLS leading to potential loss of privacy and security. We propose an optional mail header extension "mandatory-secure-mail- delivery:" and SMTP EHLO response extension "MSMD" that indicates mail must be delivered privately using TLS and with integrity using DKIM, and thereby provide a security guarantee to the user. When mail is sent with the header indicating privacy and integrity and if the receiving party does not support this, the mail is instead bounced. To protect the mail after delivery, the destination SMTP server must advertise its capabilities as part of the EHLO response, and the sender can choose whether the destination is able to honor the privacy requirements specified on the mail header. Link to the proposal here: http://datatracker.ietf.org/doc/draft-wchuang-msmd/ -Wei PS Pardon for any IETF formatting or etiquette errors as I'm very new to the IETF process. --089e0149cf9643ec1204e8d4f511 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi apps-discuss,

(resend)

Request for discussion= (draft-wchuang-msmd) of a proposal to secure mail=A0from eavesdropping and MitM attacks. = =A0I posted the primary thread to ietf-smtp@ and request that all discussio= n go to that list.

Her= e's the abstract:

   Opportunistic SMTP TLS does not enforce electronic mail delivery
   using TLS leading to potential loss of privacy and security.  We
   propose an optional mail header extension "mandatory-secure-mail-
   delivery:" and SMTP EHLO response extension "MSMD" that i=
ndicates
   mail must be delivered privately using TLS and with integrity using
   DKIM, and thereby provide a security guarantee to the user.  When
   mail is sent with the header indicating privacy and integrity and if
   the receiving party does not support this, the mail is instead
   bounced.  To protect the mail after delivery, the destination SMTP
   server must advertise its capabilities as part of the EHLO response,
   and the sender can choose whether the destination is able to honor
   the privacy requirements specified on the mail header.
<= span style=3D"font-family:arial,sans-serif;font-size:13px">
Link to t= he proposal here:

-Wei

PS Pardon for any IETF formatting or etiquette errors as I'm very ne= w to the IETF process.


--089e0149cf9643ec1204e8d4f511-- From GK@ninebynine.org Wed Oct 16 02:11:01 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75CB11E8267 for ; Wed, 16 Oct 2013 02:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.941 X-Spam-Level: X-Spam-Status: No, score=-5.941 tagged_above=-999 required=5 tests=[AWL=0.659, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oc+9WcaswhXy for ; Wed, 16 Oct 2013 02:10:56 -0700 (PDT) Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) by ietfa.amsl.com (Postfix) with ESMTP id 557F621F9985 for ; Wed, 16 Oct 2013 02:10:52 -0700 (PDT) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1VWN7y-0005yf-c4; Wed, 16 Oct 2013 10:10:50 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1VWN7y-0007G5-4E; Wed, 16 Oct 2013 10:10:50 +0100 Message-ID: <525E4596.3020304@ninebynine.org> Date: Wed, 16 Oct 2013 08:51:50 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Dave Thaler References: <20131010144721.30339.98848.idtracker@ietfa.amsl.com> <7e12b97cac364127b5ab56574eecf627@BY2PR03MB269.namprd03.prod.outlook.com> In-Reply-To: <7e12b97cac364127b5ab56574eecf627@BY2PR03MB269.namprd03.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 09:11:02 -0000 Hi, Sorry I'm a bit late to the party here. (Disclosure: I'm the "expert" reviewer.) I agree with your premise that the URI scheme registration process doesn't scale *if* every application is registered as a separate URI scheme. I think this suggests a deeper conflict than just the registration process. Web architecture is conceived using a global namespace of URIs, and (for reasons covered in RFC4395) adding new schemes in that context can be expensive. The scenario you raise is one of *local* use of URIs to invoke applications on a platform. It might be argued that this is an abuse of URI schemes, but there is clearly some local utility in doing this. If, in the spirit of "rough consensus and running code", we allow such use, how is this to be balanced with the concerns of the global web, for which URIs have been defined in the first place? The web is about content as much, if not more, than about protocols. And URIs are part of that content, not just elements in the protocols that drive Web interactions. As reviewer, one question I ask myself when I review a URI scheme registration request is "what does this URI identify?". That's hard to answer coherently when it is being used as a protocol trick to fire up an application. (Personally, I'd prefer to see application invocation handled more in the style of Web Intents (http://www.w3.org/TR/web-intents/) than tying them to URI schemes.) So my question is: should we promote this proliferation of URI schemes to fire up applications? If so, how are we to reconcile this use with the needs of the Web as a global information system? #g -- On 10/10/2013 15:51, Dave Thaler wrote: > This is relevant to appsawg. Comments welcome. > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, October 10, 2013 7:47 AM > To: Dave Thaler > Subject: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt > > > A new version of I-D, draft-thaler-uri-scheme-reg-ps-00.txt > has been successfully submitted by Dave Thaler and posted to the IETF repository. > > Filename: draft-thaler-uri-scheme-reg-ps > Revision: 00 > Title: Guidelines and Registration Procedures for New URI Schemes: Problem Statement > Creation date: 2013-10-10 > Group: Individual Submission > Number of pages: 6 > URL: http://www.ietf.org/internet-drafts/draft-thaler-uri-scheme-reg-ps-00.txt > Status: http://datatracker.ietf.org/doc/draft-thaler-uri-scheme-reg-ps > Htmlized: http://tools.ietf.org/html/draft-thaler-uri-scheme-reg-ps-00 > > > Abstract: > This document describes some problems with the existing guidelines > and procedures, as documented in RFC 4395, for new URI schemes. > > > 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. > > The IETF Secretariat > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From GK@ninebynine.org Wed Oct 16 02:11:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721B511E82A5; Wed, 16 Oct 2013 02:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.16 X-Spam-Level: X-Spam-Status: No, score=-6.16 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCEsYEhZxrW6; Wed, 16 Oct 2013 02:11:02 -0700 (PDT) Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6DD21F9D17; Wed, 16 Oct 2013 02:10:57 -0700 (PDT) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1VWN80-0008DM-dw; Wed, 16 Oct 2013 10:10:52 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1VWN7z-0007G8-6P; Wed, 16 Oct 2013 10:10:52 +0100 Message-ID: <525E5749.4010504@ninebynine.org> Date: Wed, 16 Oct 2013 10:07:21 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Fredrik Ullner References: <512663B2.20809@tibco.com> <51278B10.10200@ninebynine.org> <513CAD82.409@ninebynine.org> <513E26F5.9080207@tibco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: uri-review@ietf.org, Eric Johnson , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] URI scheme registration request - dchub X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 09:11:08 -0000 I think I've made a similar comment previously (some time ago, my memory fades), but for someone (me) who does not know about "dchub" the template isn't very informative. There is mention of Neo-Modus Direct Connect (NMDC) client clients and NMDC protocol, but it's not clear where these are described. I would also find it helpful if it were clear what a dchub: URI actually identifies - is it dereferencable? What kind of resource is returned when it is dereferenced? (One of the reference names suggests file sharing, so the resource accessed would be a file?) It feels to me as if there is both too much and too little protocol information in the URI template. (e.g. "A Neo-Modus Direct Connect (NMDC) client, given an URL, ought to connect to the specified address with the appropriate protocol commands and sequence.") Far better, in my option, would be to provide a clear reference to the protocol specification and then describe the URI scheme through reference to that. Example: "A dchub: URI identifies a file resource that may be accessed using the NMDC protocol [@@ref]". Then add some indication of the operations that are possible using a dchub: URI. Under "encoding considerations, there are some considerations that I think are really interoperability considerations (e.g. "but MAY be case-insensitive in hubs that mandate as such."). I think that should be: "Some hubs may treat dchub: URIs that differ only in case of the user component as identifying the same resource" (as an interop consideration). A key point here is that the string comparison should make it clear when two URIs may be regarded as the same URI, which I think is when they compare (case sensitive) as equal strings after RFC3986 syntax normalization. (Note: comparing equal is not necessarily the same as identifying the same resource.) Based on my brief reading of the wikipedia page, I'd like to see something like the following included: [[ The Direct Connect is a peer-to-peer file sharing protocol used by Neo-Modus Direct Connect (NMDC) clients, and reversed engineered for use in a number of other systems. There is no definitive publicly available specification, but the [Wikipedia page] contains a general description. ]] #g -- On 13/10/2013 21:18, Fredrik Ullner wrote: > Hi, > > Sorry, but I'm not sure if the previous link was correctly pointing to the > 0.4 version, but here it is: < > http://nmdc.sourceforge.net/Versions/nmdc-uri-scheme-0.4.txt> (I blame > Gmail) > > > On Sun, Oct 13, 2013 at 9:18 PM, Fredrik Ullner wrote: > >> Hi, >> >> There is now a new version of the dchub URI scheme proposal at < >> http://nmdc.sourceforge.net/Versions/nmdc-uri-scheme-0.4.txt>. >> The following changes have been made: >> >> * The "Applications/protocols" section revamped to be more generic, so it >> doesn't have to specify each implementation. >> * Changed from Permanent to Provisional; this is to make sure that the >> scheme will be accepted as a first step (possibly later filing a permanent >> one, if people find that the scheme provides ample information to deem it >> worthy of permanent status). >> >> For other (minor changes), please see the SVN. >> >> If people are satisfied with the current scheme specification, I will >> proceed to submit it to the appropriate IETF list. >> >> >> -- >> Fredrik Ullner >> > > > From internet-drafts@ietf.org Wed Oct 16 06:11:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC1E11E82A3; Wed, 16 Oct 2013 06:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cR-qz3ICdXmy; Wed, 16 Oct 2013 06:11:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF0111E82A7; Wed, 16 Oct 2013 06:11:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131016131142.32211.49752.idtracker@ietfa.amsl.com> Date: Wed, 16 Oct 2013 06:11:42 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 13:11:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : XML Media Types Author(s) : Henry S. Thompson Chris Lilley Filename : draft-ietf-appsawg-xml-mediatypes-03.txt Pages : 27 Date : 2013-10-16 Abstract: This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes the '+xml' suffix for naming media types outside of these five types when those media types represent XML MIME entities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-xml-mediatypes There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-xml-mediatypes-03 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 ht@inf.ed.ac.uk Wed Oct 16 06:26:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B0721F935A; Wed, 16 Oct 2013 06:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3w5yVtwBJBe; Wed, 16 Oct 2013 06:26:15 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7898911E813B; Wed, 16 Oct 2013 06:26:10 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id r9GDQ4fg028316; Wed, 16 Oct 2013 14:26:04 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r9GDQ2sd023958; Wed, 16 Oct 2013 14:26:02 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r9GDQ3mI004804; Wed, 16 Oct 2013 14:26:03 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id r9GDQ34s004800; Wed, 16 Oct 2013 14:26:03 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: apps-discuss@ietf.org References: <20131016131142.32211.49752.idtracker@ietfa.amsl.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 16 Oct 2013 14:26:03 +0100 In-Reply-To: <20131016131142.32211.49752.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Wed\, 16 Oct 2013 06\:11\:42 -0700") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: xml-mime@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 13:26:19 -0000 internet-drafts writes: > 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 : XML Media Types > Author(s) : Henry S. Thompson > Chris Lilley > Filename : draft-ietf-appsawg-xml-mediatypes-03.txt > Pages : 27 > Date : 2013-10-16 > > Abstract: > This specification standardizes three media types -- application/xml, > application/xml-external-parsed-entity, and application/xml-dtd -- > for use in exchanging network entities that are related to the > Extensible Markup Language (XML) while defining text/xml and text/ > xml-external-parsed-entity as aliases for the respective application/ > types. This specification also standardizes the '+xml' suffix for > naming media types outside of these five types when those media types > represent XML MIME entities. > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-xml-mediatypes > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-03 A thorough exposition of all comments received on the previous draft, and their resolution, is available at http://www.w3.org/XML/2012/10/3023bis/02-comments.html Many thanks to the commentators, particularly Julian Reschke and Erik Wilde, for careful reading and helpful input. An author-markup-based diff is available at http://www.w3.org/XML/2012/10/3023bis/draft-ietf-appsawg-xml-mediatypes-03_diff.html This is much easier to read than the IETF auto-generated one. Please note in particular that a significant addition has been made to section 3.6 [1], to address the fact that the XML spec. itself defers to this spec. to define the precedence of charset parameter, BOM and XML encoding declaration. The key new paragraph reads: All processors SHOULD treat a BOM (Section 4) as authoritative if it is present in an XML MIME entity. In the absence of a BOM (Section 4), all processors SHOULD treat the charset parameter as authoritative. Section 4.3.3 of the [XML] specification does _not_ make it an error for the charset parameter and the XML encoding declaration to be inconsistent. Comments on this section, and wider review, would be very welcome. ht [1] http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-03#section-3.6 -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From dthaler@microsoft.com Wed Oct 16 18:38:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAC111E81F9 for ; Wed, 16 Oct 2013 18:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.559 X-Spam-Level: X-Spam-Status: No, score=-103.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lg3iUVepS36y for ; Wed, 16 Oct 2013 18:38:20 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0157.outbound.protection.outlook.com [207.46.163.157]) by ietfa.amsl.com (Postfix) with ESMTP id 9272A11E821E for ; Wed, 16 Oct 2013 18:38:11 -0700 (PDT) Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB271.namprd03.prod.outlook.com (10.242.37.14) with Microsoft SMTP Server (TLS) id 15.0.800.7; Thu, 17 Oct 2013 01:38:08 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.163]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.163]) with mapi id 15.00.0800.005; Thu, 17 Oct 2013 01:38:08 +0000 From: Dave Thaler To: "apps-discuss@ietf.org" Thread-Topic: New Version Notification for draft-thaler-uri-scheme-reg-ps-01.txt Thread-Index: AQHOytiZNJFixRVL2kKe6U33AGlUBZn4G8xg Date: Thu, 17 Oct 2013 01:38:08 +0000 Message-ID: <5c1a8bdd2fce447f9b5b778dfcafe9e1@BY2PR03MB269.namprd03.prod.outlook.com> References: <20131017013122.5051.48229.idtracker@ietfa.amsl.com> In-Reply-To: <20131017013122.5051.48229.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::2] x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(377454003)(377424004)(199002)(189002)(76576001)(76796001)(76786001)(81342001)(77096001)(56816003)(79102001)(74876001)(69226001)(81686001)(81816001)(56776001)(77982001)(59766001)(54316002)(15975445006)(33646001)(74366001)(63696002)(80976001)(74706001)(76482001)(15202345003)(85306002)(74316001)(65816001)(49866001)(47736001)(47976001)(50986001)(54356001)(53806001)(19580395003)(46102001)(51856001)(81542001)(4396001)(74662001)(31966008)(47446002)(80022001)(74502001)(83072001)(19580405001)(83322001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB271; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ee31::2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 01:38:24 -0000 VGhpcyBkb2N1bWVudCBoYXMgbm93IGJlZW4gdXBkYXRlZCBiYXNlZCBvbiB0aGUgZGlzY3Vzc2lv biBvbiB0aGUgbGlzdC4NCkl0IG5vdyBpbmNsdWRlcyB0aGUgYW5zd2VycyB0byB0aGUgY2xhcmlm eWluZyBxdWVzdGlvbnMgcmFpc2VkIHNvIGZhciwNCmFuZCByZWZlcmVuY2VzIGRyYWZ0LWlldGYt aXJpLTQzOTViaXMtaXJpcmVnIGFzIHN1Z2dlc3RlZC4NCg0KLURhdmUNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTYsIDIw MTMgNjozMSBQTQ0KVG86IERhdmUgVGhhbGVyDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LXRoYWxlci11cmktc2NoZW1lLXJlZy1wcy0wMS50eHQNCg0KDQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdGhhbGVyLXVyaS1zY2hlbWUtcmVnLXBzLTAxLnR4dA0K aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBEYXZlIFRoYWxlciBhbmQgcG9zdGVk IHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtdGhhbGVyLXVyaS1z Y2hlbWUtcmVnLXBzDQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBHdWlkZWxpbmVzIGFuZCBSZWdp c3RyYXRpb24gUHJvY2VkdXJlcyBmb3IgTmV3IFVSSSBTY2hlbWVzOiBQcm9ibGVtIFN0YXRlbWVu dA0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMTAtMTcNCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlz c2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA3DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXRoYWxlci11cmktc2NoZW1lLXJlZy1wcy0wMS50 eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC10aGFsZXItdXJpLXNjaGVtZS1yZWctcHMNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtdGhhbGVyLXVyaS1zY2hlbWUtcmVnLXBzLTAxDQpEaWZmOiAg ICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXRoYWxlci11 cmktc2NoZW1lLXJlZy1wcy0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIHNvbWUgcHJvYmxlbXMgd2l0aCB0aGUgZXhpc3RpbmcgZ3VpZGVsaW5lcw0KICAgYW5kIHBy b2NlZHVyZXMsIGFzIGRvY3VtZW50ZWQgaW4gUkZDIDQzOTUsIGZvciBuZXcgVVJJIHNjaGVtZXMu DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From superuser@gmail.com Thu Oct 17 00:13:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4236A21F9E89; Thu, 17 Oct 2013 00:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1ZeyUvunuSh; Thu, 17 Oct 2013 00:13:03 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id DF06B11E8101; Thu, 17 Oct 2013 00:12:59 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id l18so1778730wgh.18 for ; Thu, 17 Oct 2013 00:12: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=A+/+eYjiB/yUkiiEEhqvt0Fblhmb2R9aaz75RJlLoFU=; b=TJN7VUVN4jE60ZeNWiTQT4qcEijTUfTglgJcwNlZKfyhHyfmAQP63EG1SpR5ekFmFT Etz7ajjcHg4tIO5W//02knmjKq/pzC3MlOnnWPgmA/0bB3svCr/ROIGXz3kKYaMOL/5C E6XyHGHAMN6+y2u6KhIhPOGAa5EZgPSBIdIvnBi2GrMHk6hjsjuS7qLeUyN3qVH1LVhh Qy3ipk4D17lerSRnJfwRHG78mvTa6FGqgl+yM+VNvaM011jOir0RuJX8IffXVem/Mskz FHxOFF6WXRGCEo03xNnzFkb+t4LteMqCTY9tntV4LLtQsiJmELJgqFHEhIrt5Mi1IF+l Dudw== MIME-Version: 1.0 X-Received: by 10.180.11.6 with SMTP id m6mr27698046wib.52.1381993979027; Thu, 17 Oct 2013 00:12:59 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Thu, 17 Oct 2013 00:12:58 -0700 (PDT) In-Reply-To: References: <20131016131142.32211.49752.idtracker@ietfa.amsl.com> Date: Thu, 17 Oct 2013 00:12:58 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Henry S. Thompson" Content-Type: multipart/alternative; boundary=001a11c2491233a7b604e8ea8c4b Cc: xml-mime@ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 07:13:04 -0000 --001a11c2491233a7b604e8ea8c4b Content-Type: text/plain; charset=ISO-8859-1 Colleagues, This one has already finished WGLC, but saw very little in the way of reviews during. There's been some good activity since, so I'm hoping we can move this along soon. Could we get those who commented before to chime in again to indicate they've ready the revision and either have more feedback, or think it's ready to progress? And a few others? Thanks, -MSK, APPSAWG co-chair & document shepherd On Wed, Oct 16, 2013 at 6:26 AM, Henry S. Thompson wrote: > internet-drafts writes: > > > 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 : XML Media Types > > Author(s) : Henry S. Thompson > > Chris Lilley > > Filename : draft-ietf-appsawg-xml-mediatypes-03.txt > > Pages : 27 > > Date : 2013-10-16 > > > > Abstract: > > This specification standardizes three media types -- application/xml, > > application/xml-external-parsed-entity, and application/xml-dtd -- > > for use in exchanging network entities that are related to the > > Extensible Markup Language (XML) while defining text/xml and text/ > > xml-external-parsed-entity as aliases for the respective application/ > > types. This specification also standardizes the '+xml' suffix for > > naming media types outside of these five types when those media types > > represent XML MIME entities. > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-appsawg-xml-mediatypes > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-03 > > A thorough exposition of all comments received on the previous draft, > and their resolution, is available at > > http://www.w3.org/XML/2012/10/3023bis/02-comments.html > > Many thanks to the commentators, particularly Julian Reschke and Erik > Wilde, for careful reading and helpful input. > > An author-markup-based diff is available at > > > http://www.w3.org/XML/2012/10/3023bis/draft-ietf-appsawg-xml-mediatypes-03_diff.html > > This is much easier to read than the IETF auto-generated one. > > Please note in particular that a significant addition has been made to > section 3.6 [1], to address the fact that the XML spec. itself defers > to this spec. to define the precedence of charset parameter, BOM and > XML encoding declaration. > > The key new paragraph reads: > > All processors SHOULD treat a BOM (Section 4) as authoritative if it > is present in an XML MIME entity. In the absence of a BOM (Section > 4), all processors SHOULD treat the charset parameter as > authoritative. Section 4.3.3 of the [XML] specification does _not_ > make it an error for the charset parameter and the XML encoding > declaration to be inconsistent. > > Comments on this section, and wider review, would be very welcome. > > ht > > [1] > http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-03#section-3.6 > -- > Henry S. Thompson, School of Informatics, University of Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail from me _always_ has a .sig like this -- mail without it is forged > spam] > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a11c2491233a7b604e8ea8c4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

This one has already finished WGLC= , but saw very little in the way of reviews during.=A0 There's been som= e good activity since, so I'm hoping we can move this along soon.=A0 Co= uld we get those who commented before to chime in again to indicate they= 9;ve ready the revision and either have more feedback, or think it's re= ady to progress?=A0 And a few others?

Thanks,
-MSK, APPSAWG co-chair & document shepherd

=


On Wed,= Oct 16, 2013 at 6:26 AM, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
internet-drafts writes:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. =A0This draft is a work item of the Applications Area
> Working Group Working Group of the IETF.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : XML Media Types
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Henry S. Thompson
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Chris Lilley
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-xml-mediatype= s-03.txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 27
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-10-16
>
> Abstract:
> =A0 =A0This specification standardizes three media types -- applicatio= n/xml,
> =A0 =A0application/xml-external-parsed-entity, and application/xml-dtd= --
> =A0 =A0for use in exchanging network entities that are related to the<= br> > =A0 =A0Extensible Markup Language (XML) while defining text/xml and te= xt/
> =A0 =A0xml-external-parsed-entity as aliases for the respective applic= ation/
> =A0 =A0types. =A0This specification also standardizes the '+xml= 9; suffix for
> =A0 =A0naming media types outside of these five types when those media= types
> =A0 =A0represent XML MIME entities.
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-apps= awg-xml-mediatypes
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-appsawg-xml-m= ediatypes-03

A thorough exposition of all comments received on the previous draft,=
and their resolution, is available at

=A0 http://www.w3.org/XML/2012/10/3023bis/02-comments.html
Many thanks to the commentators, particularly Julian Reschke and Erik
Wilde, for careful reading and helpful input.

An author-markup-based diff is available at

=A0http://www.w3.org/XML/2012/10/30= 23bis/draft-ietf-appsawg-xml-mediatypes-03_diff.html

This is much easier to read than the IETF auto-generated one.

Please note in particular that a significant addition has been made to
section 3.6 [1], to address the fact that the XML spec. itself defers
to this spec. to define the precedence of charset parameter, BOM and
XML encoding declaration.

The key new paragraph reads:

=A0 All processors SHOULD treat a BOM (Section 4) as authoritative if it =A0 is present in an XML MIME entity. =A0In the absence of a BOM (Section =A0 4), all processors SHOULD treat the charset parameter as
=A0 authoritative. =A0Section 4.3.3 of the [XML] specification does _not_ =A0 make it an error for the charset parameter and the XML encoding
=A0 declaration to be inconsistent.

Comments on this section, and wider review, would be very welcome.

ht

[1] http://tools.ietf.org/html/draft-ietf-ap= psawg-xml-mediatypes-03#section-3.6
--
=A0 =A0 =A0 =A0Henry S. Thompson, School of Informatics, University of Edin= burgh
=A0 =A0 =A0 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650= -4440
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0URL: http://www.ltg.ed.ac.uk/~ht/
=A0[mail from me _always_ has a .sig like this -- mail without it is forged= spam]
_____________________= __________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--001a11c2491233a7b604e8ea8c4b-- From superuser@gmail.com Thu Oct 17 00:29:33 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A51F21F9A59 for ; Thu, 17 Oct 2013 00:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdFR+g7q0wvn for ; Thu, 17 Oct 2013 00:29:32 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D272821F9D0D for ; Thu, 17 Oct 2013 00:29:21 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id n12so417590wgh.3 for ; Thu, 17 Oct 2013 00:29:21 -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=eeTrBl31CCShXpCsUFtVr7MwOwNBPfNxU/Ih96SfxQ4=; b=UmPO4UKdr+8hS5mVOZopkWKpeiSEaqS8dd1mp0a0vrw8+iE1rqJionCSKfQ3WQa7gI ke4p04LdBSYAPAtAYCpXfymLUkVqIHvLjXRvN/nMa3eM9sue42JObB0dWskV8dDOPskj 2ubiAlPZUIgCv5jNWWekI2KbKOWYJNeeayIAz1O7Vx1oi+DC+UgZtUElV0T/yfjhf9+Z JZRJz7ldwPotAGymTeT758JhPd6RGlvB/gdtrSj4U/w9IQLjFR/NTVj4xHNJhS/HtrE9 +2MrHmpORwlcBpXYMavDfBGV4dB0lU87qaXNYCKa4H65SINq6NlRAAac5e4AA/YomaRB L60A== MIME-Version: 1.0 X-Received: by 10.194.174.36 with SMTP id bp4mr5813556wjc.7.1381994961035; Thu, 17 Oct 2013 00:29:21 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Thu, 17 Oct 2013 00:29:20 -0700 (PDT) In-Reply-To: <20131014200131.53936.qmail@joyce.lan> References: <20131014200131.53936.qmail@joyce.lan> Date: Thu, 17 Oct 2013 00:29:20 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=089e0141a0aebbe68804e8eac69e Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Shepherding the Require-Recipient-Valid-Since Header Field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 07:29:33 -0000 --089e0141a0aebbe68804e8eac69e Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 14, 2013 at 1:01 PM, John Levine wrote: > > It's nearly ready to ship. In section 3, on page 4, delete step 3, > delete the last sentence of step 5 (which will now be step 4) and > add: > > 5. If the address is a role account as listed in [ROLES], deliver the > message whether or not the address has been under continuous > ownership. If the address has not, alert the recipient when she > reads the message that it was likely intended for one of her > predecessors, if it is practical to do so. > > 6. Otherwise, if the address has not been under continuous ownership, > reject the message. > > If I register foo.example, and I get mail to uucp@foo.example, with a > RRVS header from a year ago, it's intended for the previous > registrant, which is useful to know. (On the other hand, try sending > mail to uucp@computer.org.) > The current set of steps does wind up always delivering to role accounts. The only thing different that I can see here is the insertion of an interstitial that notifies the recipient of the likely intent. I think that's possibly best done in prose outside of the list of steps, so I'll handle your suggestion that way. > > You might put a note in 8.2 reminding people that if a domain has been > registered before, you don't know what addresses the prior owner > assigned, hence no addresses can be known not to have had a single > owner, or not to have existed at all. > Added. > > Since the question has arisen again, I agree that an SMTP extension would > be a bad idea, for the reasons listed in section 5. > > What do others think about this? I feel as though there's momentum toward adding one since it's the architecturally correct thing to do, but there will ultimately be only a few implementations and most people will just implement the header field. That said, there's precedent for doing both, and only using the header field method when the data have to be tunneled, so we could follow that precedent. -MSK --089e0141a0aebbe68804e8eac69e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 14, 2013 at 1:01 PM, John Levine <johnl@taugh.c= om> wrote:

It's nearly ready to ship. =A0In section 3, on page 4, delete ste= p 3,
delete the last sentence of step 5 (which will now be step 4) and
add:

5. =A0If the address is a role account as listed in [ROLES], deliver the =A0 =A0 message whether or not the address has been under continuous
=A0 =A0 ownership. =A0If the address has not, alert the recipient when she<= br> =A0 =A0 reads the message that it was likely intended for one of her
=A0 =A0 predecessors, if it is practical to do so.

6. =A0Otherwise, if the address has not been under continuous ownership, =A0 =A0 reject the message.

If I register foo.example, and I get mail to uucp@foo.example, with a
RRVS header from a year ago, it's intended for the previous
registrant, which is useful to know. =A0(On the other hand, try sending
mail to uucp@computer.org.)

The current set of steps does wind up always = delivering to role accounts.=A0 The only thing different that I can see her= e is the insertion of an interstitial that notifies the recipient of the li= kely intent.=A0 I think that's possibly best done in prose outside of t= he list of steps, so I'll handle your suggestion that way.
=A0

You might put a note in 8.2 reminding people that if a domain has been
registered before, you don't know what addresses the prior owner
assigned, hence no addresses can be known not to have had a single
owner, or not to have existed at all.

A= dded.
=A0

Since the question has arisen again, I agree that an SMTP extension would be a bad idea, for the reasons listed in section 5.


What do others thin= k about this?=A0 I feel as though there's momentum toward adding one si= nce it's the architecturally correct thing to do, but there will ultima= tely be only a few implementations and most people will just implement the = header field.=A0 That said, there's precedent for doing both, and only = using the header field method when the data have to be tunneled, so we coul= d follow that precedent.

-MSK
--089e0141a0aebbe68804e8eac69e-- From weihaw@google.com Tue Oct 15 12:35:48 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32C411E8166 for ; Tue, 15 Oct 2013 12:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjfgWU-EDVsl for ; Tue, 15 Oct 2013 12:35:47 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 074CE11E8156 for ; Tue, 15 Oct 2013 12:35:46 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id j15so3729143qaq.5 for ; Tue, 15 Oct 2013 12:35:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=XP5Yw9nVKfruYacdmea5P5zIPW1R/BDR8w1kPUeIDqo=; b=RZom+PonusmqhGAhbsJzl5+bRpYG5hQOGvMD20biQ6BrKAVuR2b9AEXkQ7h/VmYOeZ 0AEGDRov8rbjMCeuLw0mHNusDKhjhIXE1Bl2hZmuIEN4foQ71G+S/zi1CcHnv9GWUIj2 uIKTv4/HbilmZhseib2Q9sRCwXj+YWMX0AJ7sPe/93wzZjsULPTz6RGKTYwRPGPR+lpS nCgFUwvGRRBdU5HA+LNaEncEt4J8eIAbufTT3hUhKIx8L7Vz+fMPY+BLxa5X56YLfFj1 8rx9gEd0iak2Sf1j+m2KN4X9Z2vDMdmfUddKkLCbEHTIDh8JMxxqkRF5IJd1+JDmcs0X 388g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=XP5Yw9nVKfruYacdmea5P5zIPW1R/BDR8w1kPUeIDqo=; b=KigeV27YdHyygy42G8Jx/EyUhwZIlJa8swHNIw14xg2nNe5cvkFeomWgJbvfc1Ryh4 2bJf0da/9I88CM7qoBnTdgie56YX9uUeRZzd+pRZJPb3bmkSWyY8PpzP65SSkdSL+jPl MSXN97h3CoADHaUWp1//G61aXaDltHzFdWNwHdeFQWVO2SmcewlSDslrqjhTuE4vEiRw DkBvYScNb88c8vQ9PgYG/fQiAFywjMHiu3c15KtzQQmNQREiXpzzBQsMj8fYScepHvIY u0E0ujy6xc8qdYid1byNAGpkEIPnCunHPwS6Ha9A80dQgAFFVshoVZFXUi+aawQvBIml oxyw== X-Gm-Message-State: ALoCoQmC/1+QW75LklYVEqRNczW5prja1wbpWga4pc7V4hBWiUjNxHHY6yC/G/lldLlB/mQyf6g1pLw+uw7pP3SFl3QDJEl1ootXzqtAQ1I1QocIH29U+xITqLw907vZDXxMz/NE7bs2LINlGhXHiUaXOhRdy27TfrSfRoh+nfUT/gNCKNcIOvk7bI3d1yMOyvRJuR8vwuq+EDMKaUizkXFp0frLwjqaRA== X-Received: by 10.224.138.4 with SMTP id y4mr27044589qat.65.1381865746272; Tue, 15 Oct 2013 12:35:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.183.132 with HTTP; Tue, 15 Oct 2013 12:35:26 -0700 (PDT) From: Wei Chuang Date: Tue, 15 Oct 2013 12:35:26 -0700 Message-ID: To: apps-discuss@ietf.org, saag@ietf.org Content-Type: multipart/alternative; boundary=001a11c29f4cef29ed04e8ccb059 X-Mailman-Approved-At: Thu, 17 Oct 2013 06:49:48 -0700 Subject: [apps-discuss] Request for discussion of Mandatory Secure Mail Delivery proposal (draft-wchuang-msmd) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 19:38:53 -0000 --001a11c29f4cef29ed04e8ccb059 Content-Type: text/plain; charset=ISO-8859-1 Hi apps-discuss and saag, Request for discussion (draft-wchuang-msmd) of a proposal to secure mail from eavesdropping and MitM attacks. I posted the primary thread to ietf-smtp@and request that all discussion go to that list . Here's the abstract: Opportunistic SMTP TLS does not enforce electronic mail delivery using TLS leading to potential loss of privacy and security. We propose an optional mail header extension "mandatory-secure-mail- delivery:" and SMTP EHLO response extension "MSMD" that indicates mail must be delivered privately using TLS and with integrity using DKIM, and thereby provide a security guarantee to the user. When mail is sent with the header indicating privacy and integrity and if the receiving party does not support this, the mail is instead bounced. To protect the mail after delivery, the destination SMTP server must advertise its capabilities as part of the EHLO response, and the sender can choose whether the destination is able to honor the privacy requirements specified on the mail header. Link to the proposal here: http://datatracker.ietf.org/doc/draft-wchuang-msmd/ -Wei PS Pardon for any IETF formatting or etiquette errors as I'm very new to the IETF process. --001a11c29f4cef29ed04e8ccb059 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi apps-discus= s and saag,

Request for discussion (draft-wchuang-msmd) = of a proposal to secure mail=A0from eavesdropping and MitM attacks. =A0I posted the primar= y thread to ietf-smtp@ and request that all discussion go to that list.

Her= e's the abstract:

   Opportunistic SMTP TLS does not enforce electronic mail delivery
   using TLS leading to potential loss of privacy and security.  We
   propose an optional mail header extension "mandatory-secure-mail-
   delivery:" and SMTP EHLO response extension "MSMD" that i=
ndicates
   mail must be delivered privately using TLS and with integrity using
   DKIM, and thereby provide a security guarantee to the user.  When
   mail is sent with the header indicating privacy and integrity and if
   the receiving party does not support this, the mail is instead
   bounced.  To protect the mail after delivery, the destination SMTP
   server must advertise its capabilities as part of the EHLO response,
   and the sender can choose whether the destination is able to honor
   the privacy requirements specified on the mail header.
<= span style=3D"font-family:arial,sans-serif;font-size:13px">
Link to t= he proposal here:
<= div>
-Wei

PS Pardon for any IETF formatting or etiquette errors as I'm very ne= w to the IETF process.

--001a11c29f4cef29ed04e8ccb059-- From prvs=0995bac712=johnl@taugh.com Thu Oct 17 07:06:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139BB21F9A3B for ; Thu, 17 Oct 2013 07:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GC4wRibo8UC9 for ; Thu, 17 Oct 2013 07:06:38 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDB621F8F07 for ; Thu, 17 Oct 2013 07:06:38 -0700 (PDT) Received: (qmail 39340 invoked from network); 17 Oct 2013 14:06:37 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 Oct 2013 14:06:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=525feeed.xn--9vv.k1310; i=sendmail-bs@submit.iecc.com; bh=OQoDceF79hkO9N5HisjdXYX3WBT+fqYn23vSpHWUBj8=; b=wFyfarC5XhyK0DxRAX6P6rjFny/NwolBCJcc6d85GZ1+y4FrjQQ+KyuEYK29tlGqIscQmlaEYo18tdCIAcNrvK7JWp30Isy3uW7423SptVno+jZkHD7MCEZoxpnjgkbKoULXNWjdhE5/yqtslMTu49D+BamK92ikBSm6xN9kSQkI2KNG1PD188oycjUh5s++a3c7mMckm7UZXMg74RuyCkMc6uumz2tQndgR6o2F7iDFPvsXwsOaxZ32k7EOPtRd DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=525feeed.xn--9vv.k1310; olt=sendmail-bs@submit.iecc.com; bh=OQoDceF79hkO9N5HisjdXYX3WBT+fqYn23vSpHWUBj8=; b=skm5HOsEvIXjb2EPUdw7xLOC9jRKgf25XgjkzM5RX9Tn5cyxEgeNqrKXQCUt5uxYzm0OKz5GnGgJ2A37pS5KiKfb1JyTFu7ykzEIT6dry4INaEnz4N7Bm7mb4jvTEYdjOeMAGV6r9coat1yYNJxE/+xzlyKGzXXPuoDDd/PW6b7SL8ufuw2IulUh0TptTsefKZw0Sx7NSGmwhDXvtzkJ1LZV5Y60kWgJ2tBUKxXGCeDdxDJ5M3Hod7h7ezRejgHx Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 17 Oct 2013 14:06:37 -0000 Date: Thu, 17 Oct 2013 10:06:37 -0400 (EDT) From: John R Levine To: "Murray S. Kucherawy" In-Reply-To: Message-ID: References: <20131014200131.53936.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Shepherding the Require-Recipient-Valid-Since Header Field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 14:06:50 -0000 > The current set of steps does wind up always delivering to role accounts. > The only thing different that I can see here is the insertion of an > interstitial that notifies the recipient of the likely intent. I think > that's possibly best done in prose outside of the list of steps, so I'll > handle your suggestion that way. That's fine, so long as it acknowledges the underlying issue that domains change owners and you don't know what previous owners do. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From prvs=0995fd6dac=johnl@iecc.com Thu Oct 17 07:52:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B507211E80F9 for ; Thu, 17 Oct 2013 07:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZwkkaJMAbtm for ; Thu, 17 Oct 2013 07:52:00 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1D511E80F5 for ; Thu, 17 Oct 2013 07:51:59 -0700 (PDT) Received: (qmail 46688 invoked from network); 17 Oct 2013 14:51:58 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 Oct 2013 14:51:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=525ff98e.xn--30v786c.k1310; i=johnl@user.iecc.com; bh=mFA9pV2w8cCHe6HbXSjmU3fiHbuD02O96wVvE9VHAyE=; b=fx03F7B8d3TNr/hLZQOLRv6cfhkoxKO73lpYuKnrZLjw2t1aQPucSHtlG6wLkG2zEtrIT0/+hi1sz3q1Zn+EFjzWSkyPvnTi2mio7UA3XgZD/Gg8nHqWy5sznHVvcvvceYGwIbhfzVAEjj9bKoYDhUGfNmdQJjC6PpYG7XoyizHfO2GwIaAdD7WA4lfN8PaYYiM5xTzRSkymoL2Q/mlA7MqNgSNqSrALlJH2icA/dxDwGwS8H2MsoJqM74MwiTgd DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=525ff98e.xn--30v786c.k1310; olt=johnl@user.iecc.com; bh=mFA9pV2w8cCHe6HbXSjmU3fiHbuD02O96wVvE9VHAyE=; b=l5LmReaOfiVb+0vMq4kp5rdZaytiwUGbp55wyxdtTzZt4TDwKOIYMnz9hq+EhWOMnf42G7JK3+C/iahsVd2x57BMKioT4FjscpGobk3HM1wbOI0QK9ybfV3x8YlxiSTShhOZcxbWqN/4zLM8GvHSKntfAw4gjS7mhbVGYDthXp+o17rTCT5MpHN2z5Y4gVMTn8OVsuYHYIQZ0KH49XAP59ByYYK2hSFd4qM8Q/wz0Ire2g7K3zV1Aqsq2Mslh+eq Date: 17 Oct 2013 14:51:36 -0000 Message-ID: <20131017145136.34553.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] Shepherding the Require-Recipient-Valid-Since Header Field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 14:52:04 -0000 >> Since the question has arisen again, I agree that an SMTP extension would >> be a bad idea, for the reasons listed in section 5. >> >What do others think about this? I feel as though there's momentum toward >adding one since it's the architecturally correct thing to do, but there >will ultimately be only a few implementations and most people will just >implement the header field. That said, there's precedent for doing both, >and only using the header field method when the data have to be tunneled, >so we could follow that precedent. This promises interop problems when one end only does the header and the other end only does the SMTP extension. So to fix that the rule is you have to add and interpret the header if you implement the SMTP extension, which makes the extension pretty pointless. For people who do body filtering in the SMTP session, they're equivalent other than the issue of mail to multiple recipients which I think is an edge case in this application. For people who don't, we're more likely to know the history of a particular address at delivery time than at SMTP time, which means that to use the extension, now we need some A-R: like thing to remember what it said at SMTP time, which would look an awful lot like the header. Just the header, please. R's, John R's, John From masinter@adobe.com Thu Oct 17 08:13:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF08011E8243 for ; Thu, 17 Oct 2013 08:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.394 X-Spam-Level: X-Spam-Status: No, score=-6.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YHVM+Wl2I9g for ; Thu, 17 Oct 2013 08:13:02 -0700 (PDT) Received: from exprod6og121.obsmtp.com (exprod6og121.obsmtp.com [64.18.1.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9836D11E813B for ; Thu, 17 Oct 2013 08:13:01 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob121.postini.com ([64.18.5.12]) with SMTP ID DSNKUl/+eiDuyg6/UsyrOuEHCKkxF+nBJBU1@postini.com; Thu, 17 Oct 2013 08:13:01 PDT Received: from inner-relay-2.corp.adobe.com (inner-relay-2.corp.adobe.com [153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r9HFCuQu020393; Thu, 17 Oct 2013 08:12:57 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r9HFCtOV023723; Thu, 17 Oct 2013 08:12:55 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Thu, 17 Oct 2013 08:12:55 -0700 From: Larry Masinter To: Graham Klyne , Dave Thaler Date: Thu, 17 Oct 2013 08:12:52 -0700 Thread-Topic: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt Thread-Index: Ac7KT6YUT/YWdmsaRziBmFqcHHNRYQA9zw3A Message-ID: References: <20131010144721.30339.98848.idtracker@ietfa.amsl.com> <7e12b97cac364127b5ab56574eecf627@BY2PR03MB269.namprd03.prod.outlook.com> <525E4596.3020304@ninebynine.org> In-Reply-To: <525E4596.3020304@ninebynine.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 15:13:19 -0000 I like Dave's draft, and I think it will help set the agenda for reviewing an updated IRIREG process. I didn't think we were making progress on irireg precisely because we didn't have an agreed on problem statement. Of course, what originally led the discussion on irireg was to clarify the issue of whether a URI scheme was also an IRI scheme, whether all URIs could be internationalized or did they need processing one at a time, and whether the scheme definition could be (should be) in terms of Unicode code points rather than ASCII characters. Some other questions that arose during registration process review included: Did the scheme define fragment identifiers (no), allowable "methods" (can you GET, PUT, POST to a URI of various schemes, and did the scheme definition have to tell you how. The changes were extensive:=20 http://tools.ietf.org/rfcdiff?url1=3Drfc4395&url2=3Ddraft-ietf-iri-4395bis-= irireg-04.txt but worth (I think) re-reviewing. The issue of dynamic allocation was raised as a discussion of "registerProtocolHandler" in HTML5. Originally the discussion was about registering "web+" prefix but I think the main issue is: if web sites= =20 can cause browsers and OSes to recognize new URI schemes dynamically, why bother with registering at all, ever? http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06774.html and I raised this http://www.ietf.org/proceedings/85/slides/slides-85-appsa= wg-8 some other links: http://tools.ietf.org/id/draft-castellani-core-advanced-http-mapping-02.txt http://lists.w3.org/Archives/Public/public-ietf-w3c/2012Sep/0004.html http://lists.w3.org/Archives/Public/public-html/2012Aug/0115.html https://www.w3.org/Bugs/Public/show_bug.cgi?id=3D13904 http://lists.w3.org/Archives/Public/public-ietf-w3c/2012Sep/0035.html From ietfc@btconnect.com Thu Oct 17 09:30:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D901811E8273 for ; Thu, 17 Oct 2013 09:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.666 X-Spam-Level: X-Spam-Status: No, score=-3.666 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IF8CEKcHugQc for ; Thu, 17 Oct 2013 09:30:29 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by ietfa.amsl.com (Postfix) with ESMTP id 89AE511E827C for ; Thu, 17 Oct 2013 09:30:21 -0700 (PDT) Received: from mail146-db8-R.bigfish.com (10.174.8.225) by DB8EHSOBE004.bigfish.com (10.174.4.67) with Microsoft SMTP Server id 14.1.225.22; Thu, 17 Oct 2013 16:30:20 +0000 Received: from mail146-db8 (localhost [127.0.0.1]) by mail146-db8-R.bigfish.com (Postfix) with ESMTP id 4CED03E01EA; Thu, 17 Oct 2013 16:30:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -17 X-BigFish: PS-17(zz98dI9371I936eI146fI542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h20f7h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL8275dh1de097hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh19f0h1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail146-db8 (localhost.localdomain [127.0.0.1]) by mail146-db8 (MessageSwitch) id 138202741846287_14144; Thu, 17 Oct 2013 16:30:18 +0000 (UTC) Received: from DB8EHSMHS021.bigfish.com (unknown [10.174.8.232]) by mail146-db8.bigfish.com (Postfix) with ESMTP id 073F0C0085; Thu, 17 Oct 2013 16:30:18 +0000 (UTC) Received: from DB3PRD0710HT002.eurprd07.prod.outlook.com (157.56.253.85) by DB8EHSMHS021.bigfish.com (10.174.4.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 17 Oct 2013 16:30:16 +0000 Received: from DB3PRD0210HT002.eurprd02.prod.outlook.com (157.56.253.69) by pod51017.outlook.com (10.255.75.37) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 17 Oct 2013 16:30:15 +0000 Message-ID: <024801cecb55$e478be20$4001a8c0@gateway.2wire.net> From: t.petch To: Julian Reschke , "Henry S. Thompson" References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <5238B9E9.7010204@gmx.de><525CF2A8.2090904@berkeley.edu> <6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de> <525D386B.3070705@gmx.de> <525D3D24.3030702@gmx.de> <525D7877.6080905@gmx.de> Date: Thu, 17 Oct 2013 17:23:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.69] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Bjoern Hoehrmann , apps-discuss@ietf.org Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 16:30:36 -0000 ----- Original Message ----- From: "Julian Reschke" To: "Henry S. Thompson" Cc: "Bjoern Hoehrmann" ; Sent: Tuesday, October 15, 2013 6:16 PM > On 2013-10-15 19:08, Henry S. Thompson wrote: > > Julian Reschke writes: > > > >> The point I was trying to make is that we now have a registry. The > >> registry is authoritative; if we move the definition of "+xml", it's > >> sufficient to simply update the registry. > > > > I don't agree. If we don't include 'Updates: 6839', then 6839 will > > not get an 'Updated by [3023bis]', and anyone reading 6839 will be > > free to conclude that it defines +xml, which would be false. > > Anyone reading it that way would be reading it incorrectly :-) > > But anyway, that's something the IESG can worry about. Having just read about the difficulty in finding potential members of the IESG, I think we should do what we can as a WG to make the task of the IESG simpler, in this case by putting forward a rough consensus from the WG. I am with Henry on this one. It is true that if your world revolves around web pages, then the IANA web page will take you to the current definition whereever that is. But if you start with RFC, for example with the rfc-index, and that does not mention an update to an RFC, then you will go astray. Comparing the two definitions, in RFC6839 and this I-D, they seem to me like chalk and cheese, as for example in who has change control and who the contact is, so that the RFC6839 one will be wiped from the face of the earth; specifying 'Updates' seems the least we can do. Tom Petch > Best regards, Julian > From superuser@gmail.com Thu Oct 17 10:51:27 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBD111E81D4 for ; Thu, 17 Oct 2013 10:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCzgZ-1wd2gv for ; Thu, 17 Oct 2013 10:51:27 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 09FFE11E8169 for ; Thu, 17 Oct 2013 10:51:25 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id q58so2735655wes.28 for ; Thu, 17 Oct 2013 10:51:25 -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=n1urgMXhcm1OUdWs6Li5GQJR6/lLjLX191XDTPZlt1g=; b=QdedWI4xtNDEBbBWCjJ30N7UvIYnivJzw3dT8Jlv30XzKW65nYyrgiioxL+6lVBa5E Tg91pfA7LCj7w3FfRHUBFAhnzpmK2r6ry4DHbQqLMOvQaq6Ej0hHsi8tq5eShc3YnD4I ojZC0CdveJzCK6DPL0NxsPO1P03MtrDQfoJ+JKI4QIexd6ion1Gz39yNw6wKOKpipLwj wD8p3RxerrUWsaj2aHKCbcyg397NRTpA0PlJ7HT4EayNKOnkMFEhZ96SEvWU14KO1YDN kKqwmC8DQsyysF09g0NMYEOW1e+Lh1XmsP2lE79dbQGU8kCyAFLZNQPIf7AaxITvH3fp XpCw== MIME-Version: 1.0 X-Received: by 10.180.83.194 with SMTP id s2mr1248419wiy.60.1382032284907; Thu, 17 Oct 2013 10:51:24 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Thu, 17 Oct 2013 10:51:24 -0700 (PDT) In-Reply-To: <20131017145136.34553.qmail@joyce.lan> References: <20131017145136.34553.qmail@joyce.lan> Date: Thu, 17 Oct 2013 10:51:24 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=f46d0434bc1469033104e8f377bd Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Shepherding the Require-Recipient-Valid-Since Header Field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 17:51:27 -0000 --f46d0434bc1469033104e8f377bd Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 17, 2013 at 7:51 AM, John Levine wrote: > This promises interop problems when one end only does the header and > the other end only does the SMTP extension. So to fix that the rule > is you have to add and interpret the header if you implement the SMTP > extension, which makes the extension pretty pointless. > It is possible (though arguably error-prone) to say at each hop: "If you're sending this onward and the receiving MTA does the SMTP extension, then remove the header field and use the extension; if it doesn't, add the header field." For example, as I mentioned in a reply to Dave Cridland, this same method was done in RFC 6758, corresponding to the SMTP extension defined in RFC 6710. Alexey, if you're listening: Has this approach been successful for MT-Priority? -MSK --f46d0434bc1469033104e8f377bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 17, 2013 at 7:51 AM, John Levine <johnl@taugh.c= om> wrote:
This promises interop problems when one end only does the header and
the other end only does the SMTP extension. =A0So to fix that the rule
is you have to add and interpret the header if you implement the SMTP
extension, which makes the extension pretty pointless.

It is possible (though arguably error-prone) to say at each hop:= "If you're sending this onward and the receiving MTA does the SMT= P extension, then remove the header field and use the extension; if it does= n't, add the header field."=A0 For example, as I mentioned in a re= ply to Dave Cridland, this same method was done in RFC 6758, corresponding = to the SMTP extension defined in RFC 6710.

Alexe= y, if you're listening: Has this approach been successful for MT-Priori= ty?

-MSK
--f46d0434bc1469033104e8f377bd-- From wmills@yahoo-inc.com Thu Oct 17 11:22:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035DB11E81A2 for ; Thu, 17 Oct 2013 11:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.598 X-Spam-Level: X-Spam-Status: No, score=-18.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuoLbiQkkZ2Y for ; Thu, 17 Oct 2013 11:22:23 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by ietfa.amsl.com (Postfix) with ESMTP id B0C2E21F9B25 for ; Thu, 17 Oct 2013 11:22:23 -0700 (PDT) Received: from GQ1-EX10-CAHT19.y.corp.yahoo.com (gq1-ex10-caht19.corp.gq1.yahoo.com [10.73.119.200]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r9HILEaD021892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 17 Oct 2013 11:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1382034075; bh=HfASZegNzYyjV7FhXeXIGfi/DLr7oJ/f/8MDKjzv4fE=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To: MIME-Version:Content-Type; b=kjclv6yhzWjxhRChM1H+XkF1ureNWKasrnwwHbDFCUT7CNjQ1KYGxtE3/P0jqNpp5 fFGZMaeFiXrWk0Wwf7NJYtlbehg1yzX95ND6tEF85xt2QwUR5ZlKcpf4xklFlcKbWS +0/NPZs4k8KUmDud9DSLNOefqEgmLL3oXmB9hgxI= Received: from omp1037.mail.ne1.yahoo.com (98.138.88.237) by GQ1-EX10-CAHT19.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Oct 2013 11:21:13 -0700 Received: (qmail 94449 invoked by uid 1000); 17 Oct 2013 18:21:12 -0000 Received: (qmail 55723 invoked by uid 60001); 17 Oct 2013 18:21:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1382034072; bh=xJg3EPuv2ccf1+tKWBsca0oKhL7SO8P73BY7rjkLq5U=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=QFKCPEaS0ZXzVmV90w5YUGUpKS/en44k7UmCdlFMdKtAwb44oqQfLMh1n549iKy58r0hSnVJId9+EiyIv0xkNTsNWY1vFKOasScyhR/bifkOwgcoWilBBnCsZiaBwseYGsDJcLbHC4aUFNRCcALwHttEnXrXBh25oBpFhapSwNc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=bjg4Am3u/IYkn0S5XcVyqYtMnppopRPFPnd8YW1cgW3ebKQvXUcdASDO3v3jn1h3nPkT39rqs9SpWH/8K/qodF4/HFnE9EuD/59XFScsdJ0xHlXdbootXRlfDijTlMvSVsFKFslEIJDO+4cQ/GP97aEVFoh7+/OSuV6ljqifDnA=; X-YMail-OSG: AEtwnf0VM1mWCK22HFH6OmlAp2poJuzXeKA4GbGFGC8Ft6O yJnR3EgEeiPzhp1wdl_e293JuIFDaz_BgmOXYKGzsU8QdtSNrWdXLm.2KaZe UeCqcpbQzuNIalsBDYPpUqprEsGEPbFjhoe9kas7CrQTBEe7QhzGrPomkFOB 63w4WVPRsv3_CJSTDsB7W_wE.rED8N2XCzjjpEHq5BGSQpyrXIA0DZQJPybg K4BPAMUUH8BASHuITzWXst_AQ3bJU3he.ZYZ3M3.jF.1M8kBj5oqp9gotEYY JB8zgdhrRpzIzlAMZRWbdCJqH Received: from [66.228.162.40] by web125604.mail.ne1.yahoo.com via HTTP; Thu, 17 Oct 2013 11:21:11 PDT X-Rocket-MIMEInfo: 002.001, KzEKClRoaXMgZXhwcmVzc2VzIHNvbWVodGluZyBJIGhhZG4ndCBiZWVuIGFibGUgdG8gZ2V0IGludG8gY29oZXJlbnQgZm9ybSB0byBzYXkuCgoKwqAKLWJpbGwKCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KV2lsbGlhbSBKLiBNaWxscwoiUGFyYW5vaWQiIFlhaG9vIQoKCgoKCk9uIFRodXJzZGF5LCBPY3RvYmVyIDE3LCAyMDEzIDc6NTEgQU0sIEpvaG4gTGV2aW5lIDxqb2hubEB0YXVnaC5jb20.IHdyb3RlOgogCj4.IFNpbmNlIHRoZSBxdWVzdGlvbiBoYXMgYXJpc2VuIGFnYWluLCBJIGEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131017145136.34553.qmail@joyce.lan> Message-ID: <1382034071.44559.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Thu, 17 Oct 2013 11:21:11 -0700 From: Bill Mills To: John Levine , "apps-discuss@ietf.org" In-Reply-To: <20131017145136.34553.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-685807438-854369392-1382034071=:44559" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 034075000 Subject: Re: [apps-discuss] Shepherding the Require-Recipient-Valid-Since Header Field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 18:22:30 -0000 ---685807438-854369392-1382034071=:44559 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1=0A=0AThis expresses somehting I hadn't been able to get into coherent fo= rm to say.=0A=0A=0A=A0=0A-bill=0A=0A=0A=0A--------------------------------= =0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A=0A=0AOn Thursday, Octob= er 17, 2013 7:51 AM, John Levine wrote:=0A =0A>> Since th= e question has arisen again, I agree that an SMTP extension would=0A>> be a= bad idea, for the reasons listed in section 5.=0A>>=0A>What do others thin= k about this?=A0 I feel as though there's momentum toward=0A>adding one sin= ce it's the architecturally correct thing to do, but there=0A>will ultimate= ly be only a few implementations and most people will just=0A>implement the= header field.=A0 That said, there's precedent for doing both,=0A>and only = using the header field method when the data have to be tunneled,=0A>so we c= ould follow that precedent.=0A=0AThis promises interop problems when one en= d only does the header and=0Athe other end only does the SMTP extension.=A0= So to fix that the rule=0Ais you have to add and interpret the header if y= ou implement the SMTP=0Aextension, which makes the extension pretty pointle= ss.=0A=0AFor people who do body filtering in the SMTP session, they're=0Aeq= uivalent other than the issue of mail to multiple recipients which I=0Athin= k is an edge case in this application.=A0 For people who don't,=0Awe're mor= e likely to know the history of a particular address at=0Adelivery time tha= n at SMTP time, which means that to use the=0Aextension, now we need some A= -R: like thing to remember what it said=0Aat SMTP time, which would look an= awful lot like the header.=0A=0AJust the header, please.=0A=0AR's,=0AJohn= =0AR's,=0A=0AJohn=0A_______________________________________________=0Aapps-= discuss mailing list=0Aapps-discuss@ietf.org=0Ahttps://www.ietf.org/mailman= /listinfo/apps-discuss ---685807438-854369392-1382034071=:44559 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
+1

This expresses somehting I hadn't been able to get = into coherent form to say.

 
=
-bill


--------------------------------
William J. Mills=
"Paranoid" Yahoo!



On Thursday, October 17, 2013 7:51 AM, John = Levine <johnl@taugh.com> wrote:
>> Since the question has arisen again, I agree that an SMTP = extension would
>> be a bad idea, for the reasons l= isted in section 5.
>>
>What d= o others think about this?  I feel as though there's momentum toward>adding one since it's the architecturally correct thin= g to do, but there
>will ultimately be only a few impl= ementations and most people will just
>implement the h= eader field.  That said, there's precedent for doing both,
>and only using the header field method when the data have to be = tunneled,
>so we could follow that precedent.

This promises interop problems when one end on= ly does the header and
the other end only does the SMTP e= xtension.  So to fix that the rule
is you have to add and interpret= the header if you implement the SMTP
extension, which ma= kes the extension pretty pointless.

Fo= r people who do body filtering in the SMTP session, they're
equivalent other than the issue of mail to multiple recipients which Ithink is an edge case in this application.  For peopl= e who don't,
we're more likely to know the history of a p= articular address at
delivery time than at SMTP time, whi= ch means that to use the
extension, now we need some A-R:= like thing to remember what it said
at SMTP time, which = would look an awful lot like the header.

Just the header, please.

R's,
John
R's,

John
____________________________________= ___________
apps-discuss mailing list
<= a shape=3D"rect" ymailto=3D"mailto:apps-discuss@ietf.org" href=3D"mailto:ap= ps-discuss@ietf.org">apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


---685807438-854369392-1382034071=:44559-- From wmills@yahoo-inc.com Thu Oct 17 11:33:55 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFC011E8191 for ; Thu, 17 Oct 2013 11:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.598 X-Spam-Level: X-Spam-Status: No, score=-18.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUMfLs+JFQPV for ; Thu, 17 Oct 2013 11:33:51 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9F511E82A4 for ; Thu, 17 Oct 2013 11:33:51 -0700 (PDT) Received: from GQ1-EX10-CAHT08.y.corp.yahoo.com (gq1-ex10-caht08.corp.gq1.yahoo.com [10.73.118.87]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r9HIWwcA027108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 17 Oct 2013 11:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1382034779; bh=k6ChyKBeCWOB7C3hWWuK6KE9vA8hBqcKCRWL1Ov5msU=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To: MIME-Version:Content-Type; b=ljZLBQvMDum8fdCWCEhE1Mns4GY5VGhfRGhdnNwdQQbYiPCBzd6ETUbU1LV5KNj1B v8me4x5m6IXZhkVhb0+vslNNZdrrUQmhZLje5cajfZZk8DhriOqelu5DmoFz8bGXQU 6lpJhIuYjgGdoWanTikBx4LFlEqDCwAA371a6SoI= Received: from omp1072.mail.ne1.yahoo.com (98.138.101.161) by GQ1-EX10-CAHT08.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Oct 2013 11:32:56 -0700 Received: (qmail 41919 invoked by uid 1000); 17 Oct 2013 18:32:55 -0000 Received: (qmail 18563 invoked by uid 60001); 17 Oct 2013 18:32:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1382034775; bh=faMBVIBnGMkualGNnw89NPu//OAEghZDX1MSieeSIBE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=T+M33dBmQaiJ0d1VDFuy9Ef/AUoT2ttOHcQia0hfT4LBv23w/rXVt8tKLTyeCgamyiUo4FZ+C/BDksX52k5/h/ZXDELRp1Ybh5W3kKzCH0sMgNofgH6lbumiGuyojF6L7eFXnrPEzY97Bu41t5CdinvsLJOk93Tfu36CYjJTos4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=chWQO8ql1WDx63Y+wkB6oXTkmZ4/FXsNW1cEHFOZb6IpZZlxt2FjlBTNre+21oqH1QRIwD/ZRNltbf1SN4wG87IkyLMbZauL9Mfuktdy//ez6YzhemvbTK25XQJAfoncHVOGCdMxziGk40izzkHub6akFiliW9ItYrl6IixZxSI=; X-YMail-OSG: iLC0w2sVM1nojY8jlx3BEKk7krU_F2ZkBeCXKt.AalQQLJb 4h2q905hbVTnX_SAHK6ezGX_chHUB8OzH9ab6vDUdSzhy22F3EgVzn5IXDlR HLOZ4NMod32J.q47HcnukQ8TykSDJ6q2wAD2kEK4QGv163uxQXQl1vOQaX7H maFCi1EHf9vxZHTT8lbsLk6vk8Peu2fpIwWmri6aEoV7iUtUFuEFnR_MsPHC PJrP2otwHytIwy_tiHtAE_1XOOMHjM9Jy7nUdEWxKEKY2furFP_Kvq_Fodza rAFR0IWAuVH3UP2sYuTk3BFuC Received: from [66.228.162.40] by web125603.mail.ne1.yahoo.com via HTTP; Thu, 17 Oct 2013 11:32:55 PDT X-Rocket-MIMEInfo: 002.001, MSkgSWYgdGhlIHNlbmRlciB3YW50cyB0byBlbmZvcmNlIHRoaXMgdGhleSBjYW4gc2ltcGx5IHJlZnVzZSB0byBzZW5kIHVubGVzcyBTVEFSVFRMUyBpcyBhdmFpbGFibGU_CgoyKSBIb3cgbyB5b3UgZW5zdXJlIHRoYXQgYWxsIGhvcHMgdG8gdGhlIGRlc3RpbmF0aW9uIGFyZSBjb3ZlcmVkIGJ5IFRMUz8KCsKgCi1iaWxsCgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCldpbGxpYW0gSi4gTWlsbHMKIlBhcmFub2lkIiBZYWhvbyEKCgoKCgpPbiBUdWVzZGF5LCBPY3RvYmVyIDE1LCAyMDEzIDEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: Message-ID: <1382034775.16463.YahooMailNeo@web125603.mail.ne1.yahoo.com> Date: Thu, 17 Oct 2013 11:32:55 -0700 From: Bill Mills To: Wei Chuang , "apps-discuss@ietf.org" , "saag@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="933233344-1249971505-1382034775=:16463" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 034778006 Subject: Re: [apps-discuss] Request for discussion of Mandatory Secure Mail Delivery proposal (draft-wchuang-msmd) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 18:33:56 -0000 --933233344-1249971505-1382034775=:16463 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 1) If the sender wants to enforce this they can simply refuse to send unles= s STARTTLS is available?=0A=0A2) How o you ensure that all hops to the dest= ination are covered by TLS?=0A=0A=A0=0A-bill=0A=0A=0A=0A-------------------= -------------=0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A=0A=0AOn Tu= esday, October 15, 2013 12:35 PM, Wei Chuang wrote:=0A = =0AHi apps-discuss and saag,=0A=0ARequest for discussion (draft-wchuang-msm= d) of a proposal to secure mail=A0from eavesdropping and MitM attacks. =A0I= posted the primary thread to ietf-smtp@ and request that all discussion go= to that list.=0A=0AHere's the abstract:=0AOpportunistic SMTP TLS does not = enforce electronic mail delivery using TLS leading to potential loss of pri= vacy and security. We propose an optional mail header extension "mandatory= -secure-mail- delivery:" and SMTP EHLO response extension "MSMD" that indic= ates mail must be delivered privately using TLS and with integrity using DK= IM, and thereby provide a security guarantee to the user. When mail is sen= t with the header indicating privacy and integrity and if the receiving par= ty does not support this, the mail is instead bounced. To protect the mail= after delivery, the destination SMTP server must advertise its capabilitie= s as part of the EHLO response, and the sender can choose whether the desti= nation is able to honor the privacy requirements specified on the mail head= er.=0A=0ALink to the proposal here:=0Ahttp://datatracker.ietf.org/doc/draft= -wchuang-msmd/=0A=0A=0A-Wei=0A=0APS Pardon for any IETF formatting or etiqu= ette errors as I'm very new to the IETF process.=0A=0A_____________________= __________________________=0Aapps-discuss mailing list=0Aapps-discuss@ietf.= org=0Ahttps://www.ietf.org/mailman/listinfo/apps-discuss --933233344-1249971505-1382034775=:16463 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
1) If the sender wants to enforce this they can si= mply refuse to send unless STARTTLS is available?

2) How o you ensure that all hops to the destination are c= overed by TLS?

 
-bill


--= ------------------------------
William J. Mills
"Paranoid" Yahoo!
=

=

On Tuesday, October 15, 2013 12:35 PM, Wei Chuang <weihaw@google= .com> wrote:
Hi apps-discuss and saag,

Request for = discussion (draft-wchuang-msmd) of a proposal to secure mail from eavesdropping and MitM atta= cks.  I posted the primary thread to ietf-smtp@ and request that all d= iscussion go to that list.
=0A=0A=0A

Here's the abstract:
  =
 Opportunistic SMTP TLS does not enforce electronic mail delivery=0A   usin=
g TLS leading to potential loss of privacy and security.  We=0A   propose a=
n optional mail header extension "mandatory-secure-mail-=0A   delivery:" an=
d SMTP EHLO response extension "MSMD" that indicates=0A   mail must be deli=
vered privately using TLS and with integrity using=0A   DKIM, and thereby p=
rovide a security guarantee to the user.  When=0A   mail is sent with the h=
eader indicating privacy and integrity and if=0A   the receiving party does=
 not support this, the mail is instead=0A   bounced.  To protect the mail a=
fter delivery, the destination SMTP=0A   server must advertise its capabili=
ties as part of the EHLO response,=0A   and the sender can choose whether t=
he destination is able to honor=0A   the privacy requirements specified on =
the mail header.

Link to the proposal here:
=0A=0A= =0A
http://datatracker.ietf.org/doc/draft-wchuang-msmd/
=0A=0A=0A<= /div>

<= /div>
-We= i

=0A=0A
PS Pardon for any IETF formatting or eti= quette errors as I'm very new to the IETF process.
=0A
=0A=


_______________________________________________apps-discuss mailing list
apps-discuss@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/apps-discuss


--933233344-1249971505-1382034775=:16463-- From hannes.tschofenig@gmx.net Fri Oct 18 02:06:37 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BF721F9F31 for ; Fri, 18 Oct 2013 02:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiboSO5jypnW for ; Fri, 18 Oct 2013 02:06:37 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id D1F0221F9F84 for ; Fri, 18 Oct 2013 02:06:07 -0700 (PDT) Received: from [172.16.254.200] ([80.92.116.76]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MfjJY-1VKult3hNk-00N9ZU for ; Fri, 18 Oct 2013 11:06:06 +0200 Message-ID: <5260FA1B.6080009@gmx.net> Date: Fri, 18 Oct 2013 11:06:35 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Bert Greevenbosch , "apps-discuss@ietf.org" , "iesg@ietf.org" , "draft-ietf-tls-oob-pubkey.all@tools.ietf.org" References: <46A1DF3F04371240B504290A071B4DB63D7D4E65@szxeml558-mbx.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D7D4E65@szxeml558-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:cDwnpTPImuyZadkoBxGmgjnQbLiwAwMX2u+8kA9knec2/KBQBPB CELgoqwFV1aEmr5V/ntadCl+JlnLY7/KLlrLgmF3ROfi3zjONI0GgI5bTxVhyybDKo5NxGR FtRwhhGE/H4vsGvYAoMpP9KhIUR6G1xrfj236nFppnvpW55XRQx3GgzPYmW1fjX2PQ6dA5R tYNIkXonregfGM9RfCTZg== Subject: Re: [apps-discuss] Applications Area Directorate Review of draft-ietf-tls-oob-pubkey-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 09:06:37 -0000 Hi Bert, thanks for your review comments. A few remarks below. On 08/07/2013 03:40 AM, Bert Greevenbosch wrote: > Document: draft-ietf-tls-oob-pubkey-09 Title: Out-of-band Public Key > Validation for Transport Layer Security (TLS) Reviewer: Bert > Greevenbosch Review Date: 7 August 2013 IETF Last Call Date: until 16 > August 2013 IESG Telechat Date: [include if known] Summary: Given the > goal of reducing network usage and processing cost, the Raw Public > Key as defined in a draft indeed does a good job. It alone cannot > provide the same level of security as PKI, but I think the "Security > Considerations" section indeed addresses the related trade-offs in > security sufficiently. I think the draft is close to finalised state, > but it needs some changes as proposed below. > > Major Issues: > > (M1) The certificate negotiation (by including > client_certificate_type and server_certificate_type in client_hello > and server_hello) brings along some security issues. More > specifically, as the hello messages are not integrity protected it > allows an adversary to change the certificate format options, > especially to create a preference towards a weaker certificate > format. I suggest to add text about this, recommending that a > receiving party verifies that a certificate is indeed in one of the > forms it requested. (I can see deployments were an entity has > different certificate requirements for different situations, so not > advertising a format does not necessarily mean the entity does not > support the format.) I added a paragraph about this issue to the security consideration section. TLS luckily has a mechanism for dealing with these types of attacks by computing a hash of the handshake messages and exchanging it in the TLS Finished message. > > (M2) Page 7: "In order to indicate the support of out-of-band raw > public keys ...". Are these keys really out-of-band? It seems that > the draft focuses on the delivery of Raw Public Keys (RPKs) within an > TLS exchange, so it seems that out-of-band is incorrect here. If > out-of-band RPK delivery is supported, then how does this work? Does > that need any standardisation or is it proprietary by nature? Maybe > it is up to the out-of-band delivery method specification to define > the used format. The text on page 7 "If the client hello indicates > support of raw public keys in the 'client_certificate_type' extension > and the server chooses to use raw public keys then the TLS server > MUST place the SubjectPublicKeyInfo structure into the Certificate > payload." also seems to point at in-band delivery of RPKs. This is indeed an incorrect wording. Thanks for spotting it. It should read "In order to indicate the support of raw public keys ..." The out-of-band refers to the validation of the binding between the public key and an entity using that public key. > > Minor Issues: > > (m1) The title of the draft is misleading. It seems that the document > defines a mechanism for key validation, whereas in fact it defines a > format and TLS handshake extension for Raw Public Keys. Validation of > the key (authentication, binding) is explicitly left out of scope of > the draft. I suggest to change the title, e.g. to "Raw Public Key" or > "A TLS extension to support Raw Public Keys". When I think about it you are right that the title could be a bit more descriptive. I changed it to "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) > > Nits: > > (n1) Page 3, I propose to change "As part of the manufacturing > process, the embedded device may be configured with the address and > the public key of a dedicated CoAP server, as well as a public key > for the client itself." to "As part of the manufacturing process, the > embedded device may be configured with the address and the public key > of a dedicated CoAP server, as well as a public/private key pair for > the client itself." Fixed. > > (n2) The "Certificate" struct is an adaptation of its original form > in RFC5246. It would be good to say this explicitly. Fixed. Yaron, who did the SecDir review, also got confused about it. > > (n3) On page 4, change "an DER encoded ASN.1 format" to "a DER > encoded ASN.1 format". Fixed. > > (n4) On page 4, figure 3, I suggest to change "Digital Signature > Algorithm (DSS)" to "Digital Signature Algorithm (DSA)", although DSA > indeed is defined in the Digital Signature Standard (DSS). Fixed. > > (n5) On page 5, figure 4, add a comma behind > "client_certificate_type". Fixed. Ciao Hannes > _______________________________________________ apps-discuss mailing > list apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From David.Biesack@sas.com Fri Oct 18 08:53:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0727721F9D1B for ; Fri, 18 Oct 2013 08:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PM9MdggJoPMm for ; Fri, 18 Oct 2013 08:53:16 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 27B3511E82F0 for ; Fri, 18 Oct 2013 08:53:11 -0700 (PDT) Received: from mail87-co9-R.bigfish.com (10.236.132.234) by CO9EHSOBE005.bigfish.com (10.236.130.68) with Microsoft SMTP Server id 14.1.225.22; Fri, 18 Oct 2013 15:53:10 +0000 Received: from mail87-co9 (localhost [127.0.0.1]) by mail87-co9-R.bigfish.com (Postfix) with ESMTP id 49EB14C0295 for ; Fri, 18 Oct 2013 15:53:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:149.173.6.149; KIP:(null); UIP:(null); IPV:NLI; H:mercav05r.na.sas.com; RD:mercav05r.na.sas.com; EFVD:NLI X-SpamScore: -19 X-BigFish: S-19(zz148cIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dh1de097h186068h18602eh8275bh1cd15fiz2fh2a8h839h944hcf6hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h1c22i1155h) Received-SPF: pass (mail87-co9: domain of sas.com designates 149.173.6.149 as permitted sender) client-ip=149.173.6.149; envelope-from=David.Biesack@sas.com; helo=mercav05r.na.sas.com ; r.na.sas.com ; Received: from mail87-co9 (localhost.localdomain [127.0.0.1]) by mail87-co9 (MessageSwitch) id 1382111588559779_18144; Fri, 18 Oct 2013 15:53:08 +0000 (UTC) Received: from CO9EHSMHS011.bigfish.com (unknown [10.236.132.239]) by mail87-co9.bigfish.com (Postfix) with ESMTP id 844F822005B for ; Fri, 18 Oct 2013 15:53:08 +0000 (UTC) Received: from mercav05r.na.sas.com (149.173.6.149) by CO9EHSMHS011.bigfish.com (10.236.130.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 18 Oct 2013 15:53:07 +0000 X-TM-IMSS-Message-ID: Received: from d77781.na.sas.com.na.sas.com ([10.23.16.105]) by mercav05r.na.sas.com ([10.16.10.186]) with ESMTP (TREND IMSS SMTP Service 7.1) id b9cd1d8e001eb6ec ; Fri, 18 Oct 2013 11:53:05 -0400 From: "David J. Biesack" To: Date: Fri, 18 Oct 2013 11:52:43 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginatorOrg: sas.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [apps-discuss] draft-nottingham-http-problem-04 - details, remediation, links X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2013 15:53:21 -0000 I just learned of this draft, and I have some suggestions related to "Problem Details for HTTP APIs draft-nottingham-http-problem-04", http://tools.ietf.org/html/draft-nottingham-http-problem-04 In our error response, the details is an array of strings instead of a single "detail" string, as there may be multiple details associated with a problem. (One example we have is when parsing a request; we can list multiple syntax errors from a parser.) In addition, we separate problem details from problem remediation - i.e. the suggested means to remediate or correct the problem. Finally, we use Atom links in the error response, so we can link to multiple resources (documentation, to clarify the details and/or remediation and/or error code, etc) with different link relations. (The draft's "problemInstance" could be just a link relation in the set of Atom links.) { "details" : [ "no viable alternative at character '@'" ], "errorCode" : 1732, "httpStatusCode" : 400, "message" : "The request parameter 'filter' with value '@' has invalid syntax", "remediation" : "Use correct filter syntax", "links" : [ { "rel" : "errorDoc", "href" : "http://www.example.com/errorDoc/1732", "method" : "GET", ..... }, { "rel" : "synatx", "href" : "http://www.example.com/reference/synatx/media-types/vnd.sas.foo", ... }, ... ] "version" : 1 } Other minor points: Our "message" corresponds to this draft's "title". Our error code is an integer, not a string/enumeration. I can see that enumerations may be better. The "version" is the media type/representation's schema version. I saw some comments on draft -03 that seemed geared towards distinguishing between human consumers of an API (and its problem responses) and programmatic consumers. In our case, we do expect that in many cases, there is a human using the client application that is invoking the API, and the client needs to present problem reports - clients may not be able to cleanse or validate all user input, for example. That's all for now, thanks for listening. djb -- David J. Biesack | Principal API Architect, SAS | @davidbiesack | 919-531-7771 | www.sas.com From wangjinzhu@chinamobile.com Sun Oct 20 19:48:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750B611E8118 for ; Sun, 20 Oct 2013 19:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_221=2.222] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCW1ffM6C3L9 for ; Sun, 20 Oct 2013 19:48:14 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id D989211E845A for ; Sun, 20 Oct 2013 19:48:11 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15264959344c-7f44c; Mon, 21 Oct 2013 10:46:43 +0800 (CST) X-RM-TRANSID: 2ee15264959344c-7f44c Received: from cmccPC (unknown[10.2.43.175]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee352649591ac0-0eb1f; Mon, 21 Oct 2013 10:46:43 +0800 (CST) X-RM-TRANSID: 2ee352649591ac0-0eb1f From: "wangjinzhu" To: Date: Mon, 21 Oct 2013 10:48:12 +0800 Message-ID: <003001cece07$fc014e40$f403eac0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7M1qX5mj8t1rjSSm2cL2AWArn57ABMPHnQ Content-Language: zh-cn Cc: =?utf-8?B?J+mCk+eBteiOiS9MaW5nbGkgRGVuZyc=?= Subject: [apps-discuss] Request for discussion of end2end SIP Overload Control X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 02:48:24 -0000 Dear all Request for discussion of a proposal to end2end SIP Overload Control = (draft-wang-appsawg-end2end-overload-control).=20 Any comments or suggestions will be greatly appreciated. Best Regards Jinzhu Wang China Mobile -----Original Mail----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2013=E5=B9=B410=E6=9C=8819=E6=97=A5 22:10 =E6=94=B6=E4=BB=B6=E4=BA=BA: Yu Qing; Deng Lingli; wangjinzhu; Qing Yu; = Jinzhu Wang; Lingli Deng =E4=B8=BB=E9=A2=98: New Version Notification for = draft-wang-appsawg-end2end-overload-control-00.txt A new version of I-D, draft-wang-appsawg-end2end-overload-control-00.txt has been successfully submitted by Jinzhu Wang and posted to the IETF = repository. Filename: draft-wang-appsawg-end2end-overload-control Revision: 00 Title: End-to-end Session Initiation Protocol (SIP) overload control Creation date: 2013-10-18 Group: Individual Submission Number of pages: 6 URL: = http://www.ietf.org/internet-drafts/draft-wang-appsawg-end2end-overload-c= ontrol-00.txt Status: = http://datatracker.ietf.org/doc/draft-wang-appsawg-end2end-overload-contr= ol Htmlized: = http://tools.ietf.org/html/draft-wang-appsawg-end2end-overload-control-00= Abstract: This draft proposes end-to-end Session Initiation Protocol (SIP) overload control, in which the edge servers of the SIP network throttle the arriving calls in order to control overload for the SIP network. Compared to the local and hop-by-hop SIP overload control, the end-to-end SIP overload control can achieve best performance. = =20 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. The IETF Secretariat From mnot@mnot.net Mon Oct 21 00:20:49 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1838B11E834E for ; Mon, 21 Oct 2013 00:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.998 X-Spam-Level: X-Spam-Status: No, score=-104.998 tagged_above=-999 required=5 tests=[AWL=-2.401, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ze04cMUimCdV for ; Mon, 21 Oct 2013 00:20:45 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id A39BF11E8135 for ; Mon, 21 Oct 2013 00:20:44 -0700 (PDT) Received: from [192.168.1.64] (unknown [118.209.145.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7F33950A84 for ; Mon, 21 Oct 2013 03:20:41 -0400 (EDT) From: Mark Nottingham Content-Type: multipart/mixed; boundary="Apple-Mail=_F2334E7A-A7BF-4202-BCB3-84726729D8DF" Date: Mon, 21 Oct 2013 18:20:38 +1100 References: <20131021071846.8743.66753.idtracker@ietfa.amsl.com> To: Apps Discuss Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [apps-discuss] Fwd: New Version Notification for draft-nottingham-safe-hint-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 07:20:49 -0000 --Apple-Mail=_F2334E7A-A7BF-4202-BCB3-84726729D8DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This might get lost in the noise (well, signal, really) of Snowdonia, = but I've had some nibbles of vendor interest in this.=20 The draft is pretty self-explanatory; I'd be quite interested to hear = what people think. Less eye-watering format attached. Cheers, --Apple-Mail=_F2334E7A-A7BF-4202-BCB3-84726729D8DF Content-Disposition: attachment; filename=draft-nottingham-safe-hint-00.html Content-Type: text/html; name="draft-nottingham-safe-hint-00.html" Content-Transfer-Encoding: quoted-printable The "safe" HTTP Client Hint
Network Working GroupM. = Nottingham
Internet-DraftOctober 21, 2013
Intended = status: Informational
Expires: April 24, 2014

The "safe" = HTTP Client Hint
draft-nottingham-safe-hint-00

Abstract

This = specification defines a “safe” HTTP Client Hint, expressing = a user preference to avoid “objectionable” = content.

Status of this = Memo

This Internet-Draft is submitted in full conformance = with the provisions of BCP 78 and BCP 79.

Internet-Drafts are = working documents of the Internet Engineering Task Force (IETF). Note = that other groups may also distribute working documents as = Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ie= tf.org/drafts/current/.

Internet-Drafts are draft documents = valid for a maximum of six months and may be updated, replaced, or = obsoleted by other documents at any time. It is inappropriate to use = Internet-Drafts as reference material or to cite them other than as = “work in progress”.

This Internet-Draft will expire on = April 24, 2014.

Copyright Notice

Copyright =A9 = 2013 IETF Trust and the persons identified as the document authors. All = rights reserved.

This document is subject to BCP 78 and the IETF = Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/lice= nse-info) in effect on the date of publication of this document. = Please review these documents carefully, as they describe your rights = and restrictions with respect to this document. Code Components = extracted from this document must include Simplified BSD License text as = described in Section 4.e of the Trust Legal Provisions and are provided = without warranty as described in the Simplified BSD License.

1. Introduction

Many Web sites have a “safe” mode, = to assist those who don’t want to be exposed to = “objectionable” content, or who don’t want their = children to be exposed to such content. YouTube [youtube], = Yahoo! Search [yahoo], Google Search [google], Bing Search [bing], and many other services have such a = setting.

However, a user that wishes to = have this preference honoured would need to go to each Web site in turn, = navigate to the appropriate page, (possibly creating an account along = the way) to get a cookie [RFC6265] set in the browser. They = would need to do this for each browser on every device they use. As has = been widely noted, this is difficult [age-privacy].

This = can be onerous to nearly impossible to achieve effectively, because = there are too many permutations of sites, user agents and devices.

If instead this preference is proactively = advertised by the user agent, things become much simpler. A user agent = that supports this (whether it be an individual browser, or through an = Operating System HTTP library) need only be configured once to assure = that the preference is advertised to all sites that understand and = choose to act upon it. It’s no longer necessary to go to each site = that has potentially “unsafe” content and configure a = “safe” mode.

Furthermore, a = proxy (for example, at a school) can be used to ensure that the = preference is associated with all (unencrypted) requests flowing through = it, helping to assure that clients behind it are not exposed to = “objectionable” content.

This = specification defines how to associate this preference with a request, = as a HTTP Client Hint [grigorik-http-client-hints].

Note that this approach does not define what = “safe” is; rather, it is interpreted within the scope of = each Web site that chooses to act upon this information (or not). As = such, it does not require agreement upon what “safe” is, nor = does it require application of policy in the user agent or an = intermediary (which can be problematic for many reasons).

1.1 Notational = Conventions

The key words = “MUST”, “MUST NOT”, “REQUIRED”, = “SHALL”, “SHALL NOT”, “SHOULD”, = “SHOULD NOT”, “RECOMMENDED”, “MAY”, = and “OPTIONAL” in this document are to be interpreted as = described in [RFC2119].

2. The “safe” HTTP Client = Hint

When present in a request, the = “safe” HTTP Client Hint indicates that the user prefers = content which is not objectionable, according to the server’s = definition of the concept.

For example a = request that includes the “safe” hint:

GET /foo.html HTTP/1.1
Host: www.example.org
User-Agent: ExampleBrowser/1.0
CH: safe

When configured to do so, user agents = SHOULD include the “safe” hint in every request, to ensure = that the preference is applied (where possible) to all resources.

For example, a Web browser might have a = “Request Safe Browsing” preference option. additionally, = other clients MAY insert it; e.g., an operating system might choose to = insert the hint in requests based upon system-wide preferences, or a = proxy might do so based upon its configuration.

Servers that utilise the “safe” = hint SHOULD document that they do so, along with the criteria that they = use to denote objectionable content. If a site has more fine-grained = degrees of “safety”, it SHOULD select a reasonable default = to use, and document that; it MAY use additional mechanisms (e.g., = cookies) to fine-tune.

A response = corresponding to the request above might have headers that look like = this:

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: text/html
Server: ExampleServer/2.0
Vary: CH

Note that the Vary response header = needs to be sent if responses associated with the resource might change = depending on the value of the “CH” header; this is not only = true for those responses that have changed, but also the = “default” unchanged responses.

3. Security Considerations

The “safe” client hint is not a = secure mechanism; it can be inserted or removed by intermediaries with = access to the data stream. Its presence reveals information about the = user, which may be of small assistance in “fingerprinting” = the user (1 bit of information, to be precise).

Due to its nature, including it in requests = does not assure that all content will actually be safe; it is only when = servers elect to honour it that it might change content.

Even then, a malicious server might adapt = content so that it is even less “safe” (by some definition = of the word). As such, this mechanism on its own is not enough to assure = that only “safe” content is seen; users who wish to ensure = that will need to combine its use with other techniques (e.g., content = filtering).

Furthermore, the server and = user may have differing ideas regarding the semantics of = “safe.” As such, the “safety” of the = user’s experience when browsing from site to site might (and = probably will) change.

4. IANA = Considerations

This specification = registers the “safe” HTTP Client Hint [grigorik-http-client-hints]:

  • Hint Name: safe
  • Hint = Value: boolean
  • Description: Indicates that the user (or one = responsible for them) prefers “safe” / = “unobjectionable” content.
  • Contact: = mnot@mnot.net
  • Specification: (this = document)
  • Notes:

5. References

5.1 Normative References

Grigorik, I., “HTTP Client Hints”, = 2013.
[RFC2119]Bradner, S., “Key words for use in RFCs to = Indicate Requirement Levels”, BCP 14, RFC 2119, = March 1997.
[grigorik-http-client-hints]

5.2 Informative = References

[google]
[RFC6265]Barth, A., “HTTP State Management = Mechanism”, RFC 6265, April 2011.
[yahoo]Yahoo! Inc., “Yahoo! Search = Preferences”, 2013, <http://search.yah= oo.com/preferences/preferences>.
[bing]Microsoft, “Bing = Help: Block Explicit Web Sites”, 2013, <http://o= nlinehelp.microsoft.com/en-AU/bing/ff808441.aspx>.
Google, “SafeSearch: turn on or off”, 2013, = <http://support.google.com/websearch/bin/answer.p= y?p=3Dsettings_safesearch&answer=3D510>.
[youtube]Google, “H= ow to access and turn on Safety Mode?”, 2013, <h= ttp://support.google.com/youtube/bin/answer.py?answer=3D174084>.
[age-privacy]Moses, A., = “Privacy concern as apps share data from kids left to their own = devices”, 2012, <http://www.theage.com.au/technology/technology-news/privacy-concern-as= -apps-share-data-from-kids-left-to-their-own-devices-20121222-2bso6.html>.

Author's Address

Mark = NottinghamNottinghamMarkEMail: mnot@mnot.netURI: http://www.mnot.net/

A. Acknowledgements

Thanks to Alissa Cooper, Ilya Grigorik and Emma = Llanso for their comments.

= --Apple-Mail=_F2334E7A-A7BF-4202-BCB3-84726729D8DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-nottingham-safe-hint-00.txt > Date: 21 October 2013 6:18:46 PM AEDT > To: Mark Nottingham >=20 >=20 > A new version of I-D, draft-nottingham-safe-hint-00.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. >=20 > Filename: draft-nottingham-safe-hint > Revision: 00 > Title: The "safe" HTTP Client Hint > Creation date: 2013-10-21 > Group: Individual Submission > Number of pages: 6 > URL: = http://www.ietf.org/internet-drafts/draft-nottingham-safe-hint-00.txt > Status: = http://datatracker.ietf.org/doc/draft-nottingham-safe-hint > Htmlized: = http://tools.ietf.org/html/draft-nottingham-safe-hint-00 >=20 >=20 > Abstract: > This specification defines a "safe" HTTP Client Hint, expressing a > user preference to avoid "objectionable" content. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 -- Mark Nottingham http://www.mnot.net/ --Apple-Mail=_F2334E7A-A7BF-4202-BCB3-84726729D8DF-- From mnot@mnot.net Mon Oct 21 00:33:55 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A20911E84C9 for ; Mon, 21 Oct 2013 00:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZOzw+MME8D7 for ; Mon, 21 Oct 2013 00:33:49 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7E911E84E5 for ; Mon, 21 Oct 2013 00:33:43 -0700 (PDT) Received: from [192.168.1.64] (unknown [118.209.145.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9381E509B6; Mon, 21 Oct 2013 03:33:39 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Mark Nottingham In-Reply-To: Date: Mon, 21 Oct 2013 18:33:35 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: David J. Biesack X-Mailer: Apple Mail (2.1510) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-nottingham-http-problem-04 - details, remediation, links X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 07:33:55 -0000 Hi David, On 19/10/2013, at 2:52 AM, David J. Biesack = wrote: > I just learned of this draft, and I have some suggestions related to = "Problem Details for HTTP APIs draft-nottingham-http-problem-04", = http://tools.ietf.org/html/draft-nottingham-http-problem-04 >=20 > In our error response, the details is an array of strings instead of a = single "detail" string, as there may be multiple details associated with = a problem. (One example we have is when parsing a request; we can list = multiple syntax errors from a parser.) Yes; this has come up in discussion a few times; I should add a FAQ. The problem (ha!) is that people often try to lump multiple types of = problems into one message, leading into a mismatch between the HTTP = status code and the payload. This conundrum led to the Multistatus = status code in WebDAV, which is widely agreed to be a Bad Thing. OTOH if your problem type can encompass multiple details (e.g., "these = records are bad"), you can easily encode that in a type-specific = extension (which supports both arrays and objects). > In addition, we separate problem details from problem remediation - = i.e. the suggested means to remediate or correct the problem. Interesting. Do you have variations between remediation strategies = within a single error code? > Finally, we use Atom links in the error response, so we can link to = multiple resources (documentation, to clarify the details and/or = remediation and/or error code, etc) with different link relations. (The = draft's "problemInstance" could be just a link relation in the set of = Atom links.) I think you mean link relations -- see RFC5988 :) It might be interesting to add a generic 'links' object, but without = strong motivation I'm a bit wary of this, as some people will see it as = a needless abstraction. Since a problem type can firmly identify all of = the extensions in use, I'm not sure there is one, unless people want to = be able to add typed links to problems arbitrarily (i.e., without them = being nominated by the problem type). I'm about to publish a (hopefully final) draft, where the only major = change might be shortening the CamelCase to be lowercase (e.g., = "problemType" to "type"), so as not to collide with different people's = JSON conventions. Would that cause any problems (for you or anyone else = reading)? Cheers and thanks much for the feedback, -- Mark Nottingham http://www.mnot.net/ From darrel.miller@gmail.com Mon Oct 21 06:49:12 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDAC11E8559 for ; Mon, 21 Oct 2013 06:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLJCZbsSOuvP for ; Mon, 21 Oct 2013 06:49:11 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A2B1611E8549 for ; Mon, 21 Oct 2013 06:48:59 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id at1so11768527iec.15 for ; Mon, 21 Oct 2013 06:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=pAsZ1aOnP90QHAnxMAyJc8vcaGvqRG/C0kYgmsRM89s=; b=Zzw0/V000iu58ujMY+S55sVSFGy92RsL8bXQ0U/Q4WyLER249zfaDB3bQmjXX1niM0 4rqrb9zKkFvAetiMxSmmYn+ltOqbO2EeNASJRwRc5GMq06G0kelzBVBRf3M7tDbhcGDm NyG/7jF2A2aFMS3VSTnvUnw5s9Klnk+berjWwuyVTPF/C4QEPhSYfYImLtj44aLuAsxV NDKl3DxwEMfNqEcg9uXOnMuSCuXTbVhD+uW6KR8Sm3Nrcj8tABwkPgJL6emxPyaKDvhJ KlDTeOoakEpG/ScGaN8+UmfQAgWmq3vnV/9+y8PdkXVH3ZHNfaZpRTWJxRaTLr5Bsm+W XVTA== MIME-Version: 1.0 X-Received: by 10.43.114.6 with SMTP id ey6mr134035icc.87.1382363337687; Mon, 21 Oct 2013 06:48:57 -0700 (PDT) Received: by 10.43.77.66 with HTTP; Mon, 21 Oct 2013 06:48:57 -0700 (PDT) Date: Mon, 21 Oct 2013 09:48:57 -0400 Message-ID: From: Darrel Miller To: IETF Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] draft-nottingham-http-problem-04 - details, remediation, links X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: darrel@tavis.ca List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 13:49:12 -0000 On Mon, Oct 21, 2013 at 3:33 AM, Mark Nottingham wrote: > I'm about to publish a (hopefully final) draft, where the only major chan= ge might be shortening the CamelCase to be lowercase (e.g., "problemType" t= o "type"), so as not to collide with different people's JSON conventions. W= ould that cause any problems (for you or anyone else reading)? > I don't see any issue with changing the CamelCase to be lower case. It would be a breaking change to my library but one that is easily accommodated. On the positive side it would make it easier to consider registering "probleminstance" as link relation considering the requirement for link relation types to be lowercase. Which actually leads me to the question, would simply "instance" be a reasonable link relation to describe the relation between the problem details and the specific instance of the problem? I can certainly imagine other scenarios where the notion of an "instance" might be valuable. Could this stand on it's own? Darrel From David.Biesack@sas.com Mon Oct 21 08:25:30 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498D411E8409 for ; Mon, 21 Oct 2013 08:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-tQI+-tze+h for ; Mon, 21 Oct 2013 08:25:20 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id DEC2511E85A6 for ; Mon, 21 Oct 2013 08:25:12 -0700 (PDT) Received: from mail154-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.22; Mon, 21 Oct 2013 15:25:12 +0000 Received: from mail154-va3 (localhost [127.0.0.1]) by mail154-va3-R.bigfish.com (Postfix) with ESMTP id 048D24E00E7 for ; Mon, 21 Oct 2013 15:25:12 +0000 (UTC) X-Forefront-Antispam-Report: CIP:149.173.6.148; KIP:(null); UIP:(null); IPV:NLI; H:mercav06d.na.sas.com; RD:mercav06d.na.sas.com; EFVD:NLI X-SpamScore: -26 X-BigFish: S-26(zzbb2dI98dI9371I103dK1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah8275dh1de097h186068h8275bhz2fh2a8h839h944hcf6hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h1c22i1155h) Received-SPF: pass (mail154-va3: domain of sas.com designates 149.173.6.148 as permitted sender) client-ip=149.173.6.148; envelope-from=David.Biesack@sas.com; helo=mercav06d.na.sas.com ; d.na.sas.com ; Received: from mail154-va3 (localhost.localdomain [127.0.0.1]) by mail154-va3 (MessageSwitch) id 1382369110261500_22741; Mon, 21 Oct 2013 15:25:10 +0000 (UTC) Received: from VA3EHSMHS009.bigfish.com (unknown [10.7.14.230]) by mail154-va3.bigfish.com (Postfix) with ESMTP id 2F4033E0053 for ; Mon, 21 Oct 2013 15:25:10 +0000 (UTC) Received: from mercav06d.na.sas.com (149.173.6.148) by VA3EHSMHS009.bigfish.com (10.7.99.19) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 21 Oct 2013 15:25:08 +0000 X-TM-IMSS-Message-ID: <86f8901e00214b9d@mercav06d.na.sas.com> Received: from d77781.na.sas.com.na.sas.com ([10.23.16.105]) by mercav06d.na.sas.com ([10.36.10.11]) with ESMTP (TREND IMSS SMTP Service 7.1) id 86f8901e00214b9d ; Mon, 21 Oct 2013 11:25:06 -0400 From: "David J. Biesack" To: Mark Nottingham , In-Reply-To: (message from Mark Nottingham on Mon, 21 Oct 2013 18:33:35 +1100) Date: Mon, 21 Oct 2013 11:24:36 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginatorOrg: sas.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [apps-discuss] draft-nottingham-http-problem-04 - details, remediation, links X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 15:25:31 -0000 Mark Nottingham writes: > Hi David, > > On 19/10/2013, at 2:52 AM, David J. Biesack wrote: > >> I just learned of this draft, and I have some suggestions related to "Problem Details for HTTP APIs draft-nottingham-http-problem-04", http://tools.ietf.org/html/draft-nottingham-http-problem-04 >> >> In our error response, the details is an array of strings instead of a single "detail" string, as there may be multiple details associated with a problem. (One example we have is when parsing a request; we can list multiple syntax errors from a parser.) > > Yes; this has come up in discussion a few times; I should add a FAQ. > > The problem (ha!) is that people often try to lump multiple types of problems into one message, leading into a mismatch between the HTTP status code and the payload. This conundrum led to the Multistatus status code in WebDAV, which is widely agreed to be a Bad Thing. > > OTOH if your problem type can encompass multiple details (e.g., "these records are bad"), you can easily encode that in a type-specific extension (which supports both arrays and objects). I can see the danger of getting t0o complex. Given form-based requests or multiple query parameters, there may be errors (problems) in each. When I run a compiler on a source program, I want to get back all the errors, so I can fix them all rather than iterate and fix one at a time. Since we can't trust all clients, we must be prepared to validate all input. We like the flexibility to report *all* problems with a request. (This is generic as opposed to a type-specific problem report, i.e. a multi-record media type) I'll have to investigate the use of type-specific extensions but of course that would be non-standard and thus create tighter coupling between clients and servers that adopt that extension. Of course, other APIs from different vendors might (will) implement the same concept differently. I'm not well-versed in WebDAV and its history. Can you point out some of the criticism/consensus against multi-response, and what is recommended in its place to deal with multifarious request problems? >> In addition, we separate problem details from problem remediation - i.e. the suggested means to remediate or correct the problem. > > Interesting. Do you have variations between remediation strategies within a single error code? Not at this time. >> Finally, we use Atom links in the error response, so we can link to multiple resources (documentation, to clarify the details and/or remediation and/or error code, etc) with different link relations. (The draft's "problemInstance" could be just a link relation in the set of Atom links.) > > I think you mean link relations -- see RFC5988 :) > It might be interesting to add a generic 'links' object, but without strong motivation I'm a bit wary of this, as some people will see it as a needless abstraction. Since a problem type can firmly identify all of the extensions in use, I'm not sure there is one, unless people want to be able to add typed links to problems arbitrarily (i.e., without them being nominated by the problem type). We simply find it more RESTful to include links (and link relations) in the error response. We embed links objects in the JSON response using Atom link representation instead of using response headers. "problemInstance" could be a link relation in one of these link elements. We prefer embedded link objects over headers, because our representations often contain subobjects (each with their own links). Similarly, we can envision one of these Error responses itself being embedded in some other larger response (which itself may not be an error; embedded links are more natural for this scenario than pushing the links into the response header as per rfc5988. "problemType" could also be a link relation; this would allow multiple links with types in addition to text/html. But that too may be overly complex. I'm just trying to anticipate likely and uniform extensibility. Perhaps your FAQ can elaborate on "a problem type can firmly identify all of the extensions in use", with some examples. I.e. how are extensions identifier? (Note: section 3 has a typo: 'and "account" gives a link where the account can be topped up.' The JSON shows an array, accounts, not an "account" scalar link) > I'm about to publish a (hopefully final) draft, where the only major change might be shortening the CamelCase to be lowercase (e.g., "problemType" to "type"), so as not to collide with different people's JSON conventions. Would that cause any problems (for you or anyone else reading)? > > Cheers and thanks much for the feedback, thanks! > -- > Mark Nottingham http://www.mnot.net/ djb From julian.reschke@gmx.de Mon Oct 21 09:21:25 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973BA11E81E4 for ; Mon, 21 Oct 2013 09:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQeW59ehUHHu for ; Mon, 21 Oct 2013 09:21:20 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4702211E81DC for ; Mon, 21 Oct 2013 09:21:19 -0700 (PDT) Received: from [10.5.235.154] ([79.109.233.10]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MUkxk-1VDLY82l7U-00Y9xC for ; Mon, 21 Oct 2013 18:21:18 +0200 Message-ID: <52655479.2010605@gmx.de> Date: Mon, 21 Oct 2013 18:21:13 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Mark Nottingham , "David J. Biesack" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:gLlfM9gpg+aTQwXptc9N1s7YZ5T6Az3H5s23+xa7xymx1/2V3gw rEpnqOBqL1/jDL5zXj/jvF6cq/6IIHXdz+QcWktg5oLZiqxv7iZmCuF3xY8OiB5TywZyZtS pG9jDP2q2TujG75raOW75ABwd7jAPOj75C8rZio0+GwjYUt4t0K9m6R+4aMQ+GN+mAWWOQY YFxM6MF1eL8WmLjsDl6pA== Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-nottingham-http-problem-04 - details, remediation, links X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 16:21:25 -0000 On 2013-10-21 09:33, Mark Nottingham wrote: > Hi David, > > On 19/10/2013, at 2:52 AM, David J. Biesack wrote: > >> I just learned of this draft, and I have some suggestions related to "Problem Details for HTTP APIs draft-nottingham-http-problem-04", http://tools.ietf.org/html/draft-nottingham-http-problem-04 >> >> In our error response, the details is an array of strings instead of a single "detail" string, as there may be multiple details associated with a problem. (One example we have is when parsing a request; we can list multiple syntax errors from a parser.) > > Yes; this has come up in discussion a few times; I should add a FAQ. > > The problem (ha!) is that people often try to lump multiple types of problems into one message, leading into a mismatch between the HTTP status code and the payload. This conundrum led to the Multistatus status code in WebDAV, which is widely agreed to be a Bad Thing. It would be nice if you could back that up a bit. > ... Best regards, Julian From dret@berkeley.edu Mon Oct 21 11:37:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA88D11E8229 for ; Mon, 21 Oct 2013 11:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoBUp2cjfgKG for ; Mon, 21 Oct 2013 11:37:25 -0700 (PDT) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3532D11E8235 for ; Mon, 21 Oct 2013 11:36:40 -0700 (PDT) Received: from c-24-6-239-29.hsd1.ca.comcast.net ([24.6.239.29] helo=dretair.local) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1VYKLG-0003Ei-Ds; Mon, 21 Oct 2013 11:36:39 -0700 Message-ID: <52657433.60809@berkeley.edu> Date: Mon, 21 Oct 2013 11:36:35 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , "David J. Biesack" Subject: Re: [apps-discuss] draft-nottingham-http-problem-04 - details, remediation, links X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 18:37:37 -0000 hello david. just honing in on this one comment of yours: On 2013-10-21 08:24 , David J. Biesack wrote: > "problemType" could also be a link relation; this would allow multiple links with types in addition to text/html. But that too may be overly complex. I'm just trying to anticipate likely and uniform extensibility. and then there's something related that darrel was writing a little earlier today: On 2013-10-21 06:48 , Darrel Miller wrote: > On the positive side it would make it easier to consider registering > "probleminstance" as link relation considering the requirement for > link relation types to be lowercase. Which actually leads me to the > question, would simply "instance" be a reasonable link relation to > describe the relation between the problem details and the specific > instance of the problem? I can certainly imagine other scenarios > where the notion of an "instance" might be valuable. Could this stand > on it's own? these are interesting and complementary thoughts. in the context of an HTTP problem report, type and instance indeed might be defined and reused based on more generic link relations. interestingly, there already is a "type" link relation: http://tools.ietf.org/html/rfc6903#section-6 afaict, there is no existing link relation corresponding to the "instance" concept proposed by darrel. and i am not 100% sure which link relation to best use here, if we wanted to reuse an existing one. if we wanted to use link relations, would anybody see a good candidate, or would it make more sense to mint and register a new link relation for what is now covered by "problemInstance"? thanks and 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 | From darrel.miller@gmail.com Mon Oct 21 11:44:05 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8072411E8452 for ; Mon, 21 Oct 2013 11:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ondiO1qN5nAD for ; Mon, 21 Oct 2013 11:44:02 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 232FB11E84C7 for ; Mon, 21 Oct 2013 11:43:52 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id aq17so12582144iec.34 for ; Mon, 21 Oct 2013 11:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=ImVE8OxUls4KxkE/sYB7FKVaNrlDPmKslZXHJVf1IS0=; b=VSZGHkv2XKTIFMgCHU2cx39/nngCFnqA5kieOG6+wujuI2+VDS/pwmNjKpiGekbzcH TeueGqng+ISHPXTbChV66/vDLpEzk/DD8Flx/+9SwgmIXZ0YEpqKRB/20zSBWdvO+R1e oBpHKfDm3E9rO8I0KOn7FdflPnQeuRYUEoxAn3E3z6w5NfrKL8Yy4mu5XEVYcWgxp2bW oZEMIUB7txzeYcpb2uqpoco1mvIZsZ75AaHLnxslTafxeT+3h9D13Akkyb4BoweMefT7 lNG6RjMATwqyAhQfZnsM6Tb+CLUqjB1sxPaA4gjbCFFKbO7NuSIIm5lnpyxBluG1uwkp v58w== MIME-Version: 1.0 X-Received: by 10.50.136.137 with SMTP id qa9mr10533671igb.42.1382381030062; Mon, 21 Oct 2013 11:43:50 -0700 (PDT) Received: by 10.43.77.66 with HTTP; Mon, 21 Oct 2013 11:43:49 -0700 (PDT) In-Reply-To: References: <52657433.60809@berkeley.edu> Date: Mon, 21 Oct 2013 14:43:50 -0400 Message-ID: From: Darrel Miller To: IETF Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Fwd: draft-nottingham-http-problem-04 - details, remediation, links X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: darrel@tavis.ca List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 18:44:05 -0000 Erik, David, The only challenge I see with having problemType as a link relation, or even using the existing 'type' link relation type is that currently the problemType URI does not have to resolve to a representation. The spec says it is a should not a must. If we use a link relation, are we not forcing the dev's hand to effectively make it a must? I wouldn't object to the change, but others might. Darrel From derhoermi@gmx.net Mon Oct 21 14:53:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D991B11E862E for ; Mon, 21 Oct 2013 14:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqwnZ6eNgLXo for ; Mon, 21 Oct 2013 14:52:58 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 41D3211E86B1 for ; Mon, 21 Oct 2013 14:52:57 -0700 (PDT) Received: from netb.Speedport_W_700V ([91.35.27.33]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0MTvUT-1V7jrq21QX-00Qjcn for ; Mon, 21 Oct 2013 23:52:55 +0200 From: Bjoern Hoehrmann To: Alexey.Melnikov@isode.com Date: Mon, 21 Oct 2013 23:52:55 +0200 Message-ID: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:B2WeaW1N1MaSEl/TfRPlt9C6fcjCuOs++1w4ZQsGBAihBkMY2op oid7FOm9rmP8IvwdLkJTaYr8TTefGFUrOWfsWfjj+MVqGI1sCVk7DOYFctVbskgZPWy8aCe S1g0nCRW3cTRgfBl7okyeoWK+umT78uL4ySoTy2/65b9DMFK31aFeisQANhymC7yC/FXVQc JFGl+3Z9PbNhD1JDurzyg== Cc: discuss@apps.ietf.org Subject: [apps-discuss] Comments on draft-melnikov-email-user-agent-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 21:53:05 -0000 Hi, Re http://tools.ietf.org/html/draft-melnikov-email-user-agent-00 I am a bit surprised that `User-Agent` had not already been registered for mail, given that it's registered for HTTP and Netnews, but okay... In the abstract, "registers User-Agent and X-Mailer header fields" might be better as "the header fields User-Agent and X-Mailer". In the introduction, "User-Agent and X-Mailer are common Email header fields for identifying any software (and its components) that generates email messages." I think the emphasis should be on a given message, like "the software that generated a message". In the second sentence, s/, for tracking/and for tracking/ probably. Also, s/NetNews/Netnews/ as far as the last Netnews RFCs are concerned. Inconsistent capitalisation of "email" in the first paragraph... More importantly, it is not clear whether and if how the syntax of the User-Agent header field is different for mail compared to HTTP and Net- news. If it's the same as one or the other, the definition should be through normative reference. If not, that needs to be discussed in the document. (I see that there is a note about this at the end of the section, but it is not clear whether it is meant to be exhaustive, and there is no word about User-Agent in Netnews). The "MAY" should probably be something else, the normative permission to use more than one product token is already in the ABNF and requirements should not be spelled out more than once (use e.g. "can" instead, or if you really want to use RFC 2119 keywords for this, add that it MUST con- tain one -- and MAY contain more). The definition of the X-Mailer header is missing. There should be some note as to the purpose of Appendix A. FWIW, I do realise this is a last minute -00 version, and thank you for getting these registered. You would not happen to know, and that is why I read the document mostly, why many "recent" mail clients refuse to i- dentify through these headers? I am thinking horrendously broken web mail products in particular. There ought to be a SHOULD somewhere to use them, that would make repairing the mess they leave behind easier... (https://github.com/hoehrmann/email-analysis/ and various postings to W3C's www-archive mailing list are my latest efforts in the area...) regards, -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From internet-drafts@ietf.org Mon Oct 21 15:27:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B4411E82BB; Mon, 21 Oct 2013 15:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWazz5h9H0g9; Mon, 21 Oct 2013 15:27:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DCC11E876E; Mon, 21 Oct 2013 15:27:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021222717.32574.54111.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 15:27:17 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:27:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : The Require-Recipient-Valid-Since Header Field and SMTP = Service Extension Author(s) : William J. Mills Murray S. Kucherawy Filename : draft-ietf-appsawg-rrvs-header-field-01.txt Pages : 14 Date : 2013-10-21 Abstract: This document defines an extension for the Simple Mail Transfer Protocol called RRVS, and a header field called Require-Recipient- Valid-Since, to provide a method for senders to indicate to receivers the time when the sender last confirmed the ownership of the target mailbox. This can be used to detect changes of mailbox ownership, and thus prevent mail from being delivered to the wrong party. The intended use of these facilities is on automatically generated messages that might contain sensitive information, though it may also be useful in other applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-rrvs-header-field-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rrvs-header-field-01 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 superuser@gmail.com Mon Oct 21 15:29:40 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA60611E8779; Mon, 21 Oct 2013 15:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVtYkSTTgdu9; Mon, 21 Oct 2013 15:29:40 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B527511E8789; Mon, 21 Oct 2013 15:29:39 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id t60so7126564wes.16 for ; Mon, 21 Oct 2013 15:29:38 -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=LcFSTk+zoF0Dhs7c66JkcbaMap3S1VTlStGkJR31wz8=; b=PtzCk427wprh8KSv2TLg72aCwlaJHHO73yQ+M67YOcAINiUiSBLXn9QlebYtjb751Z z74nV5sBJWyaE3Qeb7Drznyk/kxuedmwMA6+ACIwqxsCpk63PAwmJ4D2v+jNiTzvuKbt WVq/32yBBTj3kzF3jJIRwFcSCmX07U+kR4TVUcPN5yc40rSYM9+CsAUo7yU5bfUP3t9w zkB6do9OcRgSszpDIwIHVVOesbmLQO/IrMkVUybC52zC3IfNeYSsw/o6tWXMCoFli3B0 Ts0p4Knl7JPFzT1ElV4f8H5wCg4RAQd8QvsI26Vjl91ru98ol+BVTK72cUy4WseKwipz 5Qog== MIME-Version: 1.0 X-Received: by 10.180.208.2 with SMTP id ma2mr11667582wic.52.1382394578762; Mon, 21 Oct 2013 15:29:38 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Mon, 21 Oct 2013 15:29:38 -0700 (PDT) In-Reply-To: <20131021222717.32574.54111.idtracker@ietfa.amsl.com> References: <20131021222717.32574.54111.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 15:29:38 -0700 Message-ID: From: "Murray S. Kucherawy" To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=001a11c38dfccf1a4c04e947d173 Cc: IETF Apps Discuss , i-d-announce@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:29:41 -0000 --001a11c38dfccf1a4c04e947d173 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 21, 2013 at 3:27 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 : The Require-Recipient-Valid-Since Header Field > and SMTP Service Extension > Author(s) : William J. Mills > Murray S. Kucherawy > Filename : draft-ietf-appsawg-rrvs-header-field-01.txt > Pages : 14 > Date : 2013-10-21 > > Abstract: > This document defines an extension for the Simple Mail Transfer > Protocol called RRVS, and a header field called Require-Recipient- > Valid-Since, to provide a method for senders to indicate to receivers > the time when the sender last confirmed the ownership of the target > mailbox. This can be used to detect changes of mailbox ownership, > and thus prevent mail from being delivered to the wrong party. > > The intended use of these facilities is on automatically generated > messages that might contain sensitive information, though it may also > be useful in other applications. > > This takes into account feedback we've received to date. Most notably, it adds an SMTP extension, as a couple of people have suggested. It looks like we'll need to have some discussion about whether this is feasible, practical, procedurally correct, etc., so please have at it! -MSK (co-author) --001a11c38dfccf1a4c04e947d173 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 21, 2013 at 3:27 PM, <internet-drafts= @ietf.org> wrote:

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

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : The Require-Recipient-Valid-Sin= ce Header Field and SMTP Service Extension
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : William J. Mills
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Murray S. Kucherawy
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-rrvs-header-fi= eld-01.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 14
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-10-21

Abstract:
=A0 =A0This document defines an extension for the Simple Mail Transfer
=A0 =A0Protocol called RRVS, and a header field called Require-Recipient- =A0 =A0Valid-Since, to provide a method for senders to indicate to receiver= s
=A0 =A0the time when the sender last confirmed the ownership of the target<= br> =A0 =A0mailbox. =A0This can be used to detect changes of mailbox ownership,=
=A0 =A0and thus prevent mail from being delivered to the wrong party.

=A0 =A0The intended use of these facilities is on automatically generated =A0 =A0messages that might contain sensitive information, though it may als= o
=A0 =A0be useful in other applications.


This takes into account feedback we= 9;ve received to date.=A0 Most notably, it adds an SMTP extension, as a cou= ple of people have suggested.=A0 It looks like we'll need to have some = discussion about whether this is feasible, practical, procedurally correct,= etc., so please have at it!

-MSK (co-author)
=A0

--001a11c38dfccf1a4c04e947d173-- From derhoermi@gmx.net Mon Oct 21 15:51:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A25F11E879D for ; Mon, 21 Oct 2013 15:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Li4nJpFVFoDW for ; Mon, 21 Oct 2013 15:51:23 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id BA2C721F9B4B for ; Mon, 21 Oct 2013 15:50:50 -0700 (PDT) Received: from netb.Speedport_W_700V ([91.35.27.33]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0MQvDO-1V9f672brK-00UIP6 for ; Tue, 22 Oct 2013 00:50:49 +0200 From: Bjoern Hoehrmann To: Larry Masinter Date: Tue, 22 Oct 2013 00:50:49 +0200 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:IKfJ7Izox0rkvto1O7So/cHsVNL7yD3Fjaqsb0SCg5lDNkWqOpn RI61jsm01C5mw3YAhfnjAADBOw+Q+oaLiC8avo8fDrISpodMd9wiwDv/q1z4qtbPSNwdvGL 4fMhtEAQvLkYUvutE3vMAZL5VqzAx8gcF89gLzqo/xLVKpyZ7RDaF+jKbyXNxLiDQIHypdi oG7SvK2pUeFAGJpezrbiQ== Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] registering "feed:" and "javascript:" ? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 22:51:29 -0000 * Larry Masinter wrote: >Did http://tools.ietf.org/html/draft-hoehrmann-javascript-scheme-03 get dropped? One relatively recent issue was that the IRI WG wanted to change the scheme registration guidelines in ways that might affect the draft... The draft has not really changed since -00 seven years ago, only some wordsmithing in response to feedback. I am not eager to do anything more for the document than sending a "publish please" mail somewhere and doing the AUTH48 review and approval. What I should do is reading through the last round of comments again and see what I've not been able to address yet, compare to the document, decide what to do with the feedback, possibly update the document, and then try to write up a fair summary of what people have been unhappy with in past reviews, and include that in the publication request to the IESG (or the RFC Editor, I forget whether that is an option here), and then demand people send very good diffs if they want editorial changes. Now, it doesn't have to be me who does that... -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From stephan@rename-it.nl Mon Oct 21 17:26:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7724C11E82DB for ; Mon, 21 Oct 2013 17:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMJgAWz4jHYa for ; Mon, 21 Oct 2013 17:26:12 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id 82CB811E80DE for ; Mon, 21 Oct 2013 17:26:11 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:58441 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1VYPnT-0000ZR-7E; Tue, 22 Oct 2013 02:26:09 +0200 Message-ID: <5265C5FF.4020704@rename-it.nl> Date: Tue, 22 Oct 2013 02:25:35 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20131021222717.32574.54111.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 00:26:18 -0000 On 10/22/2013 12:29 AM, Murray S. Kucherawy wrote: > This takes into account feedback we've received to date. Most > notably, it adds an SMTP extension, as a couple of people have > suggested. It looks like we'll need to have some discussion about > whether this is feasible, practical, procedurally correct, etc., so > please have at it! I gave this a quick read and I have one comment: Section 3.1 describes the SMTP extension. The value it takes is described as follows: The new parameter is "RRVS", which takes a value that is an integer timestamp expressed as an "epoch" time, namely the number of seconds since midnight on January 1, 1970. For consistency with e.g. RFC 4865 ("SMTP Future Message Release"), I'd suggest using the ISO 8601-based format described in RFC 3339 ("Date and Time on the Internet: Timestamps") instead. Regards, Stephan. From mnot@mnot.net Mon Oct 21 22:41:36 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9826711E8440 for ; Mon, 21 Oct 2013 22:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.781 X-Spam-Level: X-Spam-Status: No, score=-104.781 tagged_above=-999 required=5 tests=[AWL=-2.182, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2y9ysT60oyxh for ; Mon, 21 Oct 2013 22:41:31 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id F1CE211E845D for ; Mon, 21 Oct 2013 22:41:30 -0700 (PDT) Received: from [192.168.1.64] (unknown [118.209.145.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5255D509B5; Tue, 22 Oct 2013 01:41:29 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Mark Nottingham In-Reply-To: <52655479.2010605@gmx.de> Date: Tue, 22 Oct 2013 16:41:25 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52655479.2010605@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1510) Cc: "David J. Biesack" , apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-nottingham-http-problem-04 - details, remediation, links X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2013 05:41:36 -0000 On 22/10/2013, at 3:21 AM, Julian Reschke wrote: >> The problem (ha!) is that people often try to lump multiple types of = problems into one message, leading into a mismatch between the HTTP = status code and the payload. This conundrum led to the Multistatus = status code in WebDAV, which is widely agreed to be a Bad Thing. >=20 > It would be nice if you could back that up a bit. Sure. Much of the value of a HTTP status code is that it's visible, so that = intermediaries, high-level (or low-level, depending upon perspective) = HTTP stacks, etc., can use it to provide things like caching, automatic = retries, etc. By stuffing several status codes into a payload and = labelling it with one generic one, you require all of that generic = software to understand a specific format, which generally doesn't work. In a nutshell, it's tunnelling. Yaron talks about it more in the WebDAV Book of Why: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0128.html He finishes up: > While this logic is sound it ignores the bigger picture. Future = generations > are quite likely to use 207 and equally like to muck things up and use = it in > a context where someone receiving it may not have expected it. However = they > will expect to be able to rely on the response class and the response = class > fails them here because it will always be 207 even if everything = inside of > it is a failure. >=20 > In the end however, the mixed error case refused to admit a sensible > solution. So rather than mucking up the protocol with a large number = of > response line codes with arcane rules specifying their use we decided = to > keep matters simple and return a single response line code. Cheers, -- Mark Nottingham http://www.mnot.net/ From Bert.Greevenbosch@huawei.com Tue Oct 22 01:41:33 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F13B11E8354; Tue, 22 Oct 2013 01:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJIvysNbTtQZ; Tue, 22 Oct 2013 01:41:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6D49A11E82D5; Tue, 22 Oct 2013 01:41:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXB08822; Tue, 22 Oct 2013 08:41:23 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 22 Oct 2013 09:41:10 +0100 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 22 Oct 2013 09:41:19 +0100 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.217]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.03.0146.000; Tue, 22 Oct 2013 16:41:14 +0800 From: Bert Greevenbosch To: Hannes Tschofenig , "apps-discuss@ietf.org" , "iesg@ietf.org" , "draft-ietf-tls-oob-pubkey.all@tools.ietf.org" Thread-Topic: [apps-discuss] Applications Area Directorate Review of draft-ietf-tls-oob-pubkey-09 Thread-Index: AQHOy+FRt5Qms+YHz0e3r9yYeXC0b5oAbOhg Date: Tue, 22 Oct 2013 08:41:13 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D950B16@szxeml558-mbx.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB63D7D4E65@szxeml558-mbx.china.huawei.com> <5260FA1B.6080009@gmx.net> In-Reply-To: <5260FA1B.6080009@gmx.net> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [apps-discuss] Applications Area Directorate Review of draft-ietf-tls-oob-pubkey-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 08:41:33 -0000 Hi Hannes, Excellent, thanks for addressing my comments! Best regards, Bert > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: 18 October 2013 17:07 > To: Bert Greevenbosch; apps-discuss@ietf.org; iesg@ietf.org; draft- > ietf-tls-oob-pubkey.all@tools.ietf.org > Subject: Re: [apps-discuss] Applications Area Directorate Review of > draft-ietf-tls-oob-pubkey-09 >=20 > Hi Bert, >=20 > thanks for your review comments. A few remarks below. >=20 > On 08/07/2013 03:40 AM, Bert Greevenbosch wrote: > > Document: draft-ietf-tls-oob-pubkey-09 Title: Out-of-band Public Key > > Validation for Transport Layer Security (TLS) Reviewer: Bert > > Greevenbosch Review Date: 7 August 2013 IETF Last Call Date: until 16 > > August 2013 IESG Telechat Date: [include if known] Summary: Given the > > goal of reducing network usage and processing cost, the Raw Public > > Key as defined in a draft indeed does a good job. It alone cannot > > provide the same level of security as PKI, but I think the "Security > > Considerations" section indeed addresses the related trade-offs in > > security sufficiently. I think the draft is close to finalised state, > > but it needs some changes as proposed below. > > > > Major Issues: > > > > (M1) The certificate negotiation (by including > > client_certificate_type and server_certificate_type in client_hello > > and server_hello) brings along some security issues. More > > specifically, as the hello messages are not integrity protected it > > allows an adversary to change the certificate format options, > > especially to create a preference towards a weaker certificate > > format. I suggest to add text about this, recommending that a > > receiving party verifies that a certificate is indeed in one of the > > forms it requested. (I can see deployments were an entity has > > different certificate requirements for different situations, so not > > advertising a format does not necessarily mean the entity does not > > support the format.) >=20 > I added a paragraph about this issue to the security consideration > section. TLS luckily has a mechanism for dealing with these types of > attacks by computing a hash of the handshake messages and exchanging it > in the TLS Finished message. >=20 > > > > (M2) Page 7: "In order to indicate the support of out-of-band raw > > public keys ...". Are these keys really out-of-band? It seems that > > the draft focuses on the delivery of Raw Public Keys (RPKs) within an > > TLS exchange, so it seems that out-of-band is incorrect here. If > > out-of-band RPK delivery is supported, then how does this work? Does > > that need any standardisation or is it proprietary by nature? Maybe > > it is up to the out-of-band delivery method specification to define > > the used format. The text on page 7 "If the client hello indicates > > support of raw public keys in the 'client_certificate_type' extension > > and the server chooses to use raw public keys then the TLS server > > MUST place the SubjectPublicKeyInfo structure into the Certificate > > payload." also seems to point at in-band delivery of RPKs. >=20 > This is indeed an incorrect wording. Thanks for spotting it. > It should read "In order to indicate the support of raw public > keys ..." > The out-of-band refers to the validation of the binding between the > public key and an entity using that public key. >=20 > > > > Minor Issues: > > > > (m1) The title of the draft is misleading. It seems that the document > > defines a mechanism for key validation, whereas in fact it defines a > > format and TLS handshake extension for Raw Public Keys. Validation of > > the key (authentication, binding) is explicitly left out of scope of > > the draft. I suggest to change the title, e.g. to "Raw Public Key" or > > "A TLS extension to support Raw Public Keys". >=20 > When I think about it you are right that the title could be a bit more > descriptive. >=20 > I changed it to "Using Raw Public Keys in Transport Layer Security (TLS) > and Datagram Transport Layer Security (DTLS) > > > > Nits: > > > > (n1) Page 3, I propose to change "As part of the manufacturing > > process, the embedded device may be configured with the address and > > the public key of a dedicated CoAP server, as well as a public key > > for the client itself." to "As part of the manufacturing process, the > > embedded device may be configured with the address and the public key > > of a dedicated CoAP server, as well as a public/private key pair for > > the client itself." >=20 > Fixed. >=20 > > > > (n2) The "Certificate" struct is an adaptation of its original form > > in RFC5246. It would be good to say this explicitly. >=20 > Fixed. Yaron, who did the SecDir review, also got confused about it. >=20 >=20 > > > > (n3) On page 4, change "an DER encoded ASN.1 format" to "a DER > > encoded ASN.1 format". >=20 > Fixed. >=20 > > > > (n4) On page 4, figure 3, I suggest to change "Digital Signature > > Algorithm (DSS)" to "Digital Signature Algorithm (DSA)", although DSA > > indeed is defined in the Digital Signature Standard (DSS). >=20 > Fixed. >=20 > > > > (n5) On page 5, figure 4, add a comma behind > > "client_certificate_type". >=20 > Fixed. >=20 > Ciao > Hannes >=20 > > _______________________________________________ apps-discuss mailing > > list apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > From ht@inf.ed.ac.uk Tue Oct 22 08:14:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A6E11E83AB; Tue, 22 Oct 2013 08:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.902 X-Spam-Level: X-Spam-Status: No, score=-5.902 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfDY2o84p1Hi; Tue, 22 Oct 2013 08:14:05 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 0382F11E84B9; Tue, 22 Oct 2013 08:14:02 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id r9MFDu1p012716; Tue, 22 Oct 2013 16:13:56 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r9MFDuGn032041; Tue, 22 Oct 2013 16:13:56 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r9MFDvmf009720; Tue, 22 Oct 2013 16:13:57 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id r9MFDuMD009716; Tue, 22 Oct 2013 16:13:56 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: apps-discuss@ietf.org, public-xml-core-wg@w3.org, xml-mime@ietf.org References: <20131016131142.32211.49752.idtracker@ietfa.amsl.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 22 Oct 2013 16:13:56 +0100 In-Reply-To: <20131016131142.32211.49752.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Wed\, 16 Oct 2013 06\:11\:42 -0700") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 15:14:10 -0000 I've produced a new draft, with only one (moderately large) change, agreed in discussion with my fellow editor Chris Lilley. I've missed the official cutoff for publishing new drafts before Berlin, so please see http://www.w3.org/XML/2012/10/3023bis/draft-ietf-appsawg-xml-mediatypes-04.html#charset http://www.w3.org/XML/2012/10/3023bis/draft-ietf-appsawg-xml-mediatypes-04_diff.html#charset for substantial clarifications to the rework of Section 3.6 _Charset considerations_ given in version -03. Any existing reviewing work on any _other_ section based on version -03 is still relevant, as no other section has changed in any significant way. Note also accordingly that the diffs in the above -04_diff.html are still against version -02. Thanks, ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From julian.reschke@gmx.de Tue Oct 22 09:38:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF2F11E828B for ; Tue, 22 Oct 2013 09:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKhO+4r3LqFy for ; Tue, 22 Oct 2013 09:37:45 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id C7F4921F9E3A for ; Tue, 22 Oct 2013 09:37:42 -0700 (PDT) Received: from [10.5.235.154] ([79.109.233.10]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M85r3-1Vusba3dU9-00vjif for ; Tue, 22 Oct 2013 18:37:41 +0200 Message-ID: <5266A9C4.1020706@gmx.de> Date: Tue, 22 Oct 2013 18:37:24 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Mark Nottingham References: <52655479.2010605@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:VaIvQ67YGmDEZ68VzMGBRxVWi4mzuA8JkdLQhK76/0v+9N3D086 xBz87zWpNc+aNhoeoARM9aS2Th/6HzSpTz1AMt/dBgrfNZahvpqbs6gks98JpsDOS1Bgfbg 5M/EERwBCbc1bBhVyxiVxT9Uk5uIKV5/gsOf3LnZmc1rp6FFmaKvdyUurBh5gjmhOGZ49uE F4Oiix0k5SxLBqjNEejTQ== Cc: "David J. Biesack" , apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-nottingham-http-problem-04 - details, remediation, links X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2013 16:38:12 -0000 On 2013-10-22 07:41, Mark Nottingham wrote: > > On 22/10/2013, at 3:21 AM, Julian Reschke wrote: > >>> The problem (ha!) is that people often try to lump multiple types of problems into one message, leading into a mismatch between the HTTP status code and the payload. This conundrum led to the Multistatus status code in WebDAV, which is widely agreed to be a Bad Thing. >> >> It would be nice if you could back that up a bit. > > Sure. > > Much of the value of a HTTP status code is that it's visible, so that intermediaries, high-level (or low-level, depending upon perspective) HTTP stacks, etc., can use it to provide things like caching, automatic retries, etc. By stuffing several status codes into a payload and labelling it with one generic one, you require all of that generic software to understand a specific format, which generally doesn't work. > > In a nutshell, it's tunnelling. Well, it's at least a well-defined tunnel. I wish that people who dismiss a WebDAV feature actually fully understood how it's used. I've seen lots of complaints about the inner workings of WebDAV, and many discussions about how things *could* be better for some value of "better", but so far nobody has produced something that actually works and is inter-operable. > Yaron talks about it more in the WebDAV Book of Why: > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0128.html > > He finishes up: > >> While this logic is sound it ignores the bigger picture. Future generations >> are quite likely to use 207 and equally like to muck things up and use it in >> a context where someone receiving it may not have expected it. However they >> will expect to be able to rely on the response class and the response class >> fails them here because it will always be 207 even if everything inside of >> it is a failure. That's every very misleading; if "everything" failed you won't get a 207 in the first place. People who dismiss the 207/multistatus approach altogether are invited to come up with a "bad" example, and a concrete proposal what would have been a better design. (And yes, that includes Yaron :-) > ... Best regards, Julian From prvs=00008272c5=johnl@iecc.com Tue Oct 22 11:24:05 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14EB111E8178 for ; Tue, 22 Oct 2013 11:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+NM47jPCpGs for ; Tue, 22 Oct 2013 11:24:00 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB1421F9D0F for ; Tue, 22 Oct 2013 11:24:00 -0700 (PDT) Received: (qmail 97860 invoked from network); 22 Oct 2013 18:23:59 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Oct 2013 18:23:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5266c2bf.xn--30v786c.k1310; i=johnl@user.iecc.com; bh=54+jvokHj6A2fBvQNZLkeydGI9hVp3D7DLO7uwGG3cU=; b=BdU+6TTOtSudKSlDSfztWJEmpzKxoRjMF5LGBfPFkfMB3ugoo8ZX9ebcXb+2pmEOmyVpdH5G6477thBZr70Z/zsVCtpu9JlzE/sLPC3o5QJeMehid7u+/PUEUvlKO1rb0grNlvb93xOcQhMyJKNZSM3CZfGIr1K3/hYAnRwpB7tBk5mnItyOi8rbucDmKYxiKMYVo+x/gnZoXsQxQ+euOvsq6rAyYn8K0kISHypfknQlnldmQhH8DpCPbk7ilIqv DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5266c2bf.xn--30v786c.k1310; olt=johnl@user.iecc.com; bh=54+jvokHj6A2fBvQNZLkeydGI9hVp3D7DLO7uwGG3cU=; b=BP5d65eQkX58G88S9epeIRjPYiH+ykZTEEqnL6UwJiDy/4cmBHoevmM1q2z8ngI54LPicxXuSmOMD5DkRBPZyuAq1y1rd7elw3ul85SrX8lv85FFuZyuxT42+bHQw0Edow9+eyxOub/TfCtLI5ysUol/AlSp/chgQP/EZBIxf6E4XprQ1S1sUAToYkNbjGWIZuaVGXCKEP5S+sk5EAUR5JOg5orDfPw+/PRQHuWl6HiXwx31pnDIb5s/y+a0UubT Date: 22 Oct 2013 18:23:37 -0000 Message-ID: <20131022182337.4789.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 18:24:05 -0000 >This takes into account feedback we've received to date. Most notably, it >adds an SMTP extension, as a couple of people have suggested. It looks >like we'll need to have some discussion about whether this is feasible, >practical, procedurally correct, etc., so please have at it! Hmmn. Section 6 asserts that: "the additional detail about the relationship between the message author and its intended recipient is at best a property of the message transaction and not part of the message itself. That seems wrong. RRVS says this message is for the person who had the target address at time T, which sure seems like a property of the message. If it were a property of the transaction, that suggests you might have one transaction that delivers a message with RRVS, and another which delivers the same message to the same recipient without it, which is silly. Sec 6 suggests deleting RRVS headers when a subsequent relay supports the SMTP extension, which will break signatures. You could suggest not signing RRVS headers, I suppose, but I'm not sure if that has security implications. I'm aware of two problems the SMTP extension might solve, neither of which is important. One is to allow reject before data, which seems to me like a horse that left the barn long before DMARC burned the barn down. The other is that it allows selective rejection on messages with multiple recipients, but the kind of mail this is likely to be used on rarely has multiple recipients. But the stuff about adding and deleting headers based on the next hop's EHLO responses strikes me as the kind of stuff that won't ever be implemented, or if it is, it'll be wrong, e.g., it'll add headers but won't delete them. So my preference is still to take it out. R's, John From envite@rolamasao.org Tue Oct 22 15:04:12 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E4611E8293 for ; Tue, 22 Oct 2013 15:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.287 X-Spam-Level: ** X-Spam-Status: No, score=2.287 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_EQ_STATIC=1.172, MANGLED_SPAM=2.3, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4YSncy3iLmr for ; Tue, 22 Oct 2013 15:04:08 -0700 (PDT) Received: from rolamasao.org (68.167.216.87.static.jazztel.es [87.216.167.68]) by ietfa.amsl.com (Postfix) with ESMTP id BA2CE11E821F for ; Tue, 22 Oct 2013 15:04:04 -0700 (PDT) Received: from tochox.localnet (localhost [IPv6:::1]) by rolamasao.org (Postfix_t) with ESMTPSA id 1C1F211EF2 for ; Tue, 22 Oct 2013 23:04:03 +0100 (WEST) From: Noel David Torres =?iso-8859-1?q?Ta=F1o?= To: apps-discuss@ietf.org Date: Tue, 22 Oct 2013 23:03:58 +0100 User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) References: <20131022214922.3673.qmail@joyce.lan> In-Reply-To: <20131022214922.3673.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1678604.SnvpnVNSS0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201310222303.59123.envite@rolamasao.org> Subject: Re: [apps-discuss] doubt about WG for e-mail protocol enhancement X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2013 22:04:12 -0000 --nextPart1678604.SnvpnVNSS0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > The appsarea list would be the appropriate place, but first you might > want to check the wiki from the former Anti-Spam Research Group and > see if we already know about it. >=20 > http://wiki.asrg.sp.am/wiki/Taxonomy_of_anti-spam_techniques >=20 > R's, > John >=20 >=20 > >I have an idea for e-mail enhancement regading security and spam. Which = Working Group should I join to? > > > >Thanks in advance > > > >Noel Torres > >er Envite > >------------------------- > >A: Because it breaks the logical flow of discussion. > >Q: Why is top posting bad? >=20 >=20 Hi all Is this here? Thanks in advance Noel Torres er Envite =2D------------------------ A: Because it breaks the logical flow of discussion. Q: Why is top posting bad? --nextPart1678604.SnvpnVNSS0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlJm9k8ACgkQcLQA8+7Hw3IfqwCfc9QNAIvTxbypuJMzHL5b5N/a fqIAmgL8N6P/Yj8siTCeEbgjalL/j5TL =6ktQ -----END PGP SIGNATURE----- --nextPart1678604.SnvpnVNSS0-- From superuser@gmail.com Tue Oct 22 17:27:06 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B221711E827C for ; Tue, 22 Oct 2013 17:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpsv2OPdCitH for ; Tue, 22 Oct 2013 17:27:06 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4278711E82A0 for ; Tue, 22 Oct 2013 17:27:05 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q58so73679wes.17 for ; Tue, 22 Oct 2013 17:27:04 -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=ABRvxtdTq/JlK1cvW5L71pWkIWDhzkhCnbbCSjdo3Uk=; b=D+iaORzW1ogpovqqOHJIsUoFUfv+9DpOWxCU8kcB03ow+/wFH9D8dd6oeRiA4DeBkY L5IdUJSLuNjxm2TN+RH8Eq+uIOOsOeKow9BKzwQG71KKr3MTIdKgrhxJO6Nk4LC0OGR0 IWyGPeuHwiflYqd1wrVN/nZkjJCZQclAYiuCcQKC8yiF5YJ613z4hJ0oc9OWFydO3Dce RUDcvia7plkP4W8oBhzKXSNk00J52NH3PZtUFcC8jwb2kT0PXxfjaWWtOLzesQOE8Vtm QzgyqF8hiUC2JenKCF8T6n7EoxRpO2WcR9b+FE1cMlzhsZJcDR5m2LzsEtaNyiR9QVuc AlxA== MIME-Version: 1.0 X-Received: by 10.194.219.70 with SMTP id pm6mr4594257wjc.47.1382488024318; Tue, 22 Oct 2013 17:27:04 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Tue, 22 Oct 2013 17:27:04 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Oct 2013 17:27:04 -0700 Message-ID: From: "Murray S. Kucherawy" To: Bjoern Hoehrmann Content-Type: multipart/alternative; boundary=001a11c1b31c98878d04e95d9341 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] registering "feed:" and "javascript:" ? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Oct 2013 00:27:06 -0000 --001a11c1b31c98878d04e95d9341 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 21, 2013 at 3:50 PM, Bjoern Hoehrmann wrote: > * Larry Masinter wrote: > >Did http://tools.ietf.org/html/draft-hoehrmann-javascript-scheme-03 get > dropped? > > One relatively recent issue was that the IRI WG wanted to change the > scheme registration guidelines in ways that might affect the draft... > > The draft has not really changed since -00 seven years ago, only some > wordsmithing in response to feedback. I am not eager to do anything > more for the document than sending a "publish please" mail somewhere > and doing the AUTH48 review and approval. > > What I should do is reading through the last round of comments again and > see what I've not been able to address yet, compare to the document, > decide what to do with the feedback, possibly update the document, and > then try to write up a fair summary of what people have been unhappy > with in past reviews, and include that in the publication request to the > IESG (or the RFC Editor, I forget whether that is an option here), and > then demand people send very good diffs if they want editorial changes. > > IRI appears to be inactive now, and it seems like this WG is probably the one whose charter is most likely to cover this space. So it depends on whether the IESG thinks this work ought to be processed in the IETF stream vs. them being fine with it going through the RFC Editor. Our docket is presently full-ish but there are a few documents crawling toward their last calls, so you or Larry or whoever wants to carry the torch for it could propose APPSAWG handle it if there's sufficient interest in doing so once those move on. -MSK (co-chairin') --001a11c1b31c98878d04e95d9341 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 21, 2013 at 3:50 PM, Bjoern Hoehrmann <derhoe= rmi@gmx.net> wrote:
* Larry Masinter wrote: >Did http://tools.ietf.org/html/draft-hoehrmann-javas= cript-scheme-03 get dropped?

One relatively recent issue was that the IRI WG wanted to change the<= br> scheme registration guidelines in ways that might affect the draft...

The draft has not really changed since -00 seven years ago, only some
wordsmithing in response to feedback. I am not eager to do anything
more for the document than sending a "publish please" mail somewh= ere
and doing the AUTH48 review and approval.

What I should do is reading through the last round of comments again and see what I've not been able to address yet, compare to the document, decide what to do with the feedback, possibly update the document, and
then try to write up a fair summary of what people have been unhappy
with in past reviews, and include that in the publication request to the IESG (or the RFC Editor, I forget whether that is an option here), and
then demand people send very good diffs if they want editorial changes.


IRI appears to be inactive now, and i= t seems like this WG is probably the one whose charter is most likely to co= ver this space.=A0 So it depends on whether the IESG thinks this work ought= to be processed in the IETF stream vs. them being fine with it going throu= gh the RFC Editor.=A0 Our docket is presently full-ish but there are a few = documents crawling toward their last calls, so you or Larry or whoever want= s to carry the torch for it could propose APPSAWG handle it if there's = sufficient interest in doing so once those move on.

-MSK (co-chairin')
--001a11c1b31c98878d04e95d9341-- From Claudio.Allocchio@garr.it Fri Oct 25 02:11:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E558D11E834F; Fri, 25 Oct 2013 02:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.651 X-Spam-Level: X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QBwA6Y34ew8; Fri, 25 Oct 2013 02:11:13 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 0D86211E816D; Fri, 25 Oct 2013 02:11:09 -0700 (PDT) Received: internal info suppressed Date: Fri, 25 Oct 2013 11:11:01 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: Roni Even In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C23E53B3BB@szxpml507-mbs.exmail.huawei.com> Message-ID: References: <760B7D45D1EFF74988DBF5C2122830C23E53B3BB@szxpml507-mbs.exmail.huawei.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1541218831-1382692264=:7642" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1382692264; bh=ix5ExuQ9w5Ea5LAw4ERrHyVu7o/eJr2ttzHz7x3NLUA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Fl3SYT55Jl5qTz/c7har1okv+Pspwnf8bfrbFMnnzJX/4sqVVP/ll3ADE7a/MMUzx 6+qO2HgCKGy0RvoXH5DiemCSgR/9nOlc6BmgM6zUmmdeue3t96sO/l8xQOuABAm8Yn xgn53GTmlpa9Bm2Q4rjZL3pQ4lISKlzLo9YLmHic= Cc: "ron.even.tlv@gmail.com" , "draft-ietf-clue-telepresence-use-cases.all@tools.ietf.org" , "apps-discuss@ietf.org" , "Stephen.Botzko@polycom.com" , IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-clue-telepresence-use-cases-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2013 09:11:20 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1541218831-1382692264=:7642 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Hi Roni! On Thu, 24 Oct 2013, Roni Even wrote: > Hi Claudio, > Thanks for the review. > > The technical feedback on sections 3.2, 3.3, 3.4,3.5, 3.6, and 3.8 all > seem to be based on a misunderstanding of the document's purpose. As > stated in the introduction, it is merely a set of use cases that the > CLUE WG agreed to consider in the development of requirements. I think there is no misunderstanding at all. I indeed made those suggestions exactly to make the use cases even more close to reality that users experience now. As I said, just suggestions, drawn directly from user's feedback; at GARR we do run all those services, with about 3 million users around them, thus the help/support desk knows quite a wide set of users' comments :-) BUT, JUST SUGGESTIONS! > What the document is NOT is > (a) an attempt to precisely define the boundaries between telepresence > systems and traditional systems. The CLUE WG agreed early on that this > was both problematic and unnecessary. > (b) an attempt to define the best solution for each presented scenario. > Generally there is no "best" solution, and vendors will continue to make > different choices. Listing possible approaches (generally in use today) > is intended to help the CLUE WG ensure that that its protocol building > blocks are flexible enough to enable multiple solutions. This is clear already from the introduction. > Rather than add the proposed new material to sections 3.2, 3.3, 3.4, > 3.5, 3.6, and 3.8, we propose a clarifying sentence be added to the end > of the first paragraph of section 2: > > "We also specifically do not attempt to precisely define the boundaries > between telepresence systems and other systems, nor do we attempt to > identify the “best” solution for each presented scenario. " that helps, but does not get my suggestions. If you want to add additional facts about current users' experiences, than you just take my suggestions and expand them a bit into some text. But you can also just state "Furtheremore we do not attempt to details all possible scenarios, including current problems which users can experinces when sitting in one of them." and such addition will also work fine. > In addition, there is an editorial suggestion to move sections 3.5 and > 3.6 to appendices. We do not see any benefits in reorganizing the text > in this way, and we do see a drawback. CLUE agreed that all of these > use cases were germane to its requirements definition. It seems to us > that shifting these sections to appendices would create confusion on > that point. as you prefer. > We will remove the duplicate text from section 2 and reference the introduction. > Thanks you are welcome! all the best! > Roni Even > > > ________________________________________ > From: Claudio Allocchio [Claudio.Allocchio@garr.it] > Sent: Thursday, September 26, 2013 11:27 AM > To: apps-discuss@ietf.org; draft-ietf-clue-telepresence-use-cases.all@tools.ietf.org > Cc: IESG > Subject: APPSDIR review of draft-ietf-clue-telepresence-use-cases-07 > > Hello all, > > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see ​ > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-clue-telepresence-use-cases-07 > Title: Use Cases for Telepresence Multi-streams > Reviewer: Claudio Allocchio > Review Date: Sep 26th 2013 > IETF Last Call Date: Sep 26th 2013 > IESG Telechat Date: Not known > > Summary: This draft is almost ready for publication as an Informational > RFC. However it needs some editing and maybe a re-ordering of some > sections. Also a more detailed descprition of the "audio scenario" in all > sections is worth an efort before publication. > > Major issues: > > none. > > Minor issues: > > General comment: most of the documet focuses a lot on the video aspect of > telepresence, and only is some section the "audio presence" is quickly > described as possible stereo, or surround or multible monophonic channels. > I think the audio aspect is as important as the video one in making > participatns feel the telepresence effect, thus each section should add a > carful audio setup scenario as detailed as the video on. The voice of a > partiipants must come from where his/her virtual image is. > > There is a text repetition in Introduction and in section 2 (page 5): > > The basic features that give telepresence its distinctive > characteristics are implemented in disparate ways in different > systems. Currently Telepresence systems from diverse vendors > interoperate to some extent, but this is not supported in a standards > based fashion. Interworking requires that translation and > transcoding devices be included in the architecture. Such devices > increase latency, reducing the quality of interpersonal interaction. > Use of these devices is often not automatic; it frequently requires > substantial manual configuration and a detailed understanding of the > nature of underlying audio and video streams. This state of affairs > is not acceptable for the continued growth of telepresence - > telepresence systems should have the same ease of interoperability as > do telephones. > > Either you make a shorter statement in the Introduction, of you just refer > to the introduction text in section 2, page 5. > > 3.2 section. The whole section describes possible techniques to overcome > the mismatched situation at the 2 sites... but it does not analyse at all > possible effects that different proposed solutions have on the > "telepresence effect" itself, and on human participants. As this is a > "scenario introduction", we should also consider this aspect, as then > technical specification can also handle possible mitigation actions to > reduce the problm. For example, in some of the cases - remote participants > chenging dynamically on the screens - a potential very bad seasick > situation will happen easily, making the telepresence esperience a > nightmare. Note that this comment also applies to 3.3 section. > > 3.3 section. The description applies to current techniques for multisites, > bue there is no mention of possible overcome situations when different > systems are used. Of course this is very similar to 3.2 case, but with > complexity multiplied by the number of dirrefent sites. It should be > useful to mention explicitly also this fact. > > 3.4 section. The currect text describes what you do with the H.239 > equivalent channel data, and suggests the need of additional streams (not > a sigle one): fine but what is the problem to solve here, is any? Ok, > maybe you just need to state that you need to make interoperable the sigle > "presentaton channel" provided by any site. > > 3.5 section. A basic doubt: is this section into the scope of this > Informational document? If we aim to help deployment of complete > interoparting systems, maybe it is, because most existing telepresence > systems have proprietary (or likely) ways to allow participatns with non > telepresence devices. If we are only aiming to real telepresence systems > interoperability, then this section could go into an appendix section. > > 3.6 section. I tend to think that also this case is worth for an appendix > (see 3.5 comments). > > 3.8 section. My basic doubt here is "does this belong to telepresence > scenario at all? Immersive scnenario in this situation is quite different > that the one described in the beginning (a typical business meeting). This > comment also applies to section 3.6 > > Nits: > > none. > > ------------------------------------------------------------------------------ > Claudio Allocchio G A R R Claudio.Allocchio@garr.it > Senior Technical Officer > tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; > fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; > > PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca --0-1541218831-1382692264=:7642-- From ned.freed@mrochek.com Fri Oct 25 17:31:55 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B41111E81CD for ; Fri, 25 Oct 2013 17:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhNcltPWfTSa for ; Fri, 25 Oct 2013 17:31:50 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id E782C11E818F for ; Fri, 25 Oct 2013 17:31:49 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P00BXN1XG0000TGS@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 25 Oct 2013 17:26:46 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OZQXEDTQ3400004R@mauve.mrochek.com>; Fri, 25 Oct 2013 17:26:44 -0700 (PDT) Message-id: <01P00BXM2CJU00004R@mauve.mrochek.com> Date: Fri, 25 Oct 2013 16:03:55 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 22 Oct 2013 18:23:37 +0000" <20131022182337.4789.qmail@joyce.lan> References: <20131022182337.4789.qmail@joyce.lan> To: John Levine Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 00:31:55 -0000 > >This takes into account feedback we've received to date. Most notably, it > >adds an SMTP extension, as a couple of people have suggested. It looks > >like we'll need to have some discussion about whether this is feasible, > >practical, procedurally correct, etc., so please have at it! > Hmmn. > Section 6 asserts that: > "the additional detail about the relationship > between the message author and its intended recipient is at best a > property of the message transaction and not part of the message > itself. > That seems wrong. RRVS says this message is for the person who had > the target address at time T, which sure seems like a property of the > message. If it were a property of the transaction, that suggests you > might have one transaction that delivers a message with RRVS, and > another which delivers the same message to the same recipient without > it, which is silly. > Sec 6 suggests deleting RRVS headers when a subsequent relay supports > the SMTP extension, which will break signatures. You could suggest > not signing RRVS headers, I suppose, but I'm not sure if that has > security implications. You actually want to delete the headers you recognize regardless, in order to limit information exposures. > I'm aware of two problems the SMTP extension might solve, neither of > which is important. One is to allow reject before data, which seems > to me like a horse that left the barn long before DMARC burned the > barn down. That's entirely wrong. It's a huge benefit to be able to reject this stuff early; see below. > The other is that it allows selective rejection on > messages with multiple recipients, but the kind of mail this is likely > to be used on rarely has multiple recipients. No, the advantage is that you can handle multiple recipients trivially instead of with considerable difficulty. I don't care how "likely" such usage is; an implementor that cares about producing a high quality product has to deal with it. And people take stuff we define and use it in unexpected ways all the time, to the point where the surprise is when this doesn't happen. > But the stuff about > adding and deleting headers based on the next hop's EHLO responses > strikes me as the kind of stuff that won't ever be implemented, or if > it is, it'll be wrong, e.g., it'll add headers but won't delete them. > So my preference is still to take it out. I just finished implementing this draft, and based on that experience I have to strongly disagree. I now believe that if anything the header mechanism is what needs to go. The SMTP extension turns out to be very easy to implement. The RRVS value is directly attached to the address, so there only two cases: (1) The address is local, in which case you check the information against the account if you have it. And throw the information away no matter what. (2) The address is nonlocal, in which case you attach the information to the address so it can be relayed. This only took me a couple of hours to code. I actually implemented the SMTP extension before the new draft came out, and what I did matched the draft with the exception that I used same format for the time value as was specified in RFC 4865. Note that Stephan Bosch reached the same conclusion about the right format to use independently. (Obviously I concur with Stephan that the draft needs to be changed.) A nice thing about the SMTP extension is most of the security issues just take care of themselves. The information is never part of the message so you don't have to worry about it leaking. The only remaining issue is the ability to use the extension to determine the age of the account, which is made a little easier. But the mitigation given in the draft addresses most of this, and applies to both approaches. I also find the argument about deployability problems to be a bit overblown, at least as far as the primary use-case is concerned. As I understand it, the primary use-case is for banks, e-sellers, and similar sorts sending status messages to MSPs and ISPs. In such cases what intermediaries are there likely to be? (I'll also note that you can't on the one hand argue that only one use-case really matters while on the other hand using the problems associated with other use-cases to dismiss the simpler approach.) Anyway, once I had the extension I started in on the header stuff. I expected this to be harder due to the need to handle the header-envelope matcheup as well as the possibility of partial failures, but I was gobsmacked at the difficultly. This has taken me literally days to get right. The multiple recipient issue is a big part of it, but not all. Just as one example of how tricky the multiple recipient issue is, suppose you have two recipients A and B that forward to the same address C: A -> C B -> C So what recreation date do you attach to that one address? If either one doesn't have a recreation date the answe is "you don't attach one". But they both do the correct thing is to attach and check both. That means making some data structure changes, which to be honest I didn't bother to do. I think this is enough of a corner case that I can ignore it. But I could be wrong, in which case this will be even more work. But this is nasty even if there's only a single recipient and header. The basic problem is you've introduced a new failure case after the content of the message has been received, and it turns out to have somewhat different semantics from other failure cases at this point, in my implementation at least. It's not like throwing out the message because, say, it was a big pile of binary nonsense. Or because it violated overall site policy in some way. In such cases there's justification for returning an error and dropping the trash in the trashcan. But RRVS differs in that it's almost certainly a bad idea to ignore legal intercept or other archiving requirements for what is, after all a valid message. (And before you say otherwise, think what happens when Silk Road supports this on the sending side.) This led me to conclude that RRVS is much more like a sieve ereject - which already had support in place for multiple recipients - and that's more or less how I ended up implementing it. But the interactions with actual sieves are different, the handling in the event of sieve errors are different, and ereject doesn't allow specification of a specific enhanced status code so support for that had to be added. The bottom line is this ended up being a fair bit of work. I think I finally have it right, but the final call for tht will be for the Q/A folks to make, who I'm sure will just love it to pieces. Or perhaps not. Ned From prvs=00047521ba=johnl@taugh.com Fri Oct 25 18:13:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3897511E822A for ; Fri, 25 Oct 2013 18:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oc7gE-gE2Hnz for ; Fri, 25 Oct 2013 18:13:07 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B7FCB11E8228 for ; Fri, 25 Oct 2013 18:13:06 -0700 (PDT) Received: (qmail 53863 invoked from network); 26 Oct 2013 01:13:05 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Oct 2013 01:13:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=526b1720.xn--30v786c.k1310; i=sendmail-bs@submit.iecc.com; bh=rXjSegil2ytz3U3rekgdBOjnRX2MpDB3riZ5U3wz8Jw=; b=WoBnmCq9j8zWOsdwYRXBeY9M3YmZqyzWwTmxas5K/baKzS17bxMueezPtwyuA+Z12r5mXqmltU6cOct+6cqL5mHTgu6cthtppW2WAW+Nm+H9W51L7ZXdRCLNE5T51DURjATGMbrnduf5wXVdUbcCjzpGneped8C/MsJn+ubdqCjPEHeXM83edi8fMJI7vnKNPwdxN1MnJdSjOylgh1ye/MV8KtqrDJuOlv5co6sxkqmxBrKL+gYTSPz5f9FqQ5je DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=526b1720.xn--30v786c.k1310; olt=sendmail-bs@submit.iecc.com; bh=rXjSegil2ytz3U3rekgdBOjnRX2MpDB3riZ5U3wz8Jw=; b=rooDzFqLHYTlxlkExvbyRJa3nc/B9gfrJF0SLM+5H0O3p8lZBFrXkDR0zkXqvxySAaMgjtNmZyiQ2tF7hp8pFcsMhQR0UMXOdQWXAKpmipA3OHQvSUydyApD6RQdrhYEubH7TASAfv2Aw5Gnvas+l5sTwFKrW/bhEVnm0qP+ESIoSKl5f132pQKPro+ivSaZTQPbPUOHAlfTlNDk4nV3PVHGc1Xecwrut4cITYtBs6m2jaWlXngn4BSMz/D4Z5Vl Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 26 Oct 2013 01:13:04 -0000 Date: Fri, 25 Oct 2013 21:13:04 -0400 (EDT) From: John R Levine To: Ned Freed In-Reply-To: <01P00BXM2CJU00004R@mauve.mrochek.com> Message-ID: References: <20131022182337.4789.qmail@joyce.lan> <01P00BXM2CJU00004R@mauve.mrochek.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 01:13:11 -0000 > As I understand it, the primary use-case is for banks, e-sellers, and > similar sorts sending status messages to MSPs and ISPs. In such cases > what intermediaries are there likely to be? I'm thinking of spam filtering proxies, either services like Messagelabs, or a linux box put in front of an organization's Exchange server. My impression is that they often do some sort of LDAP call to find out what addresses are valid. I don't know enough about LDAP to know how hard it would be to check the age of the address at the same time. R's, John From ned.freed@mrochek.com Fri Oct 25 20:10:57 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5ED11E814B for ; Fri, 25 Oct 2013 20:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVQF0iHsVvQP for ; Fri, 25 Oct 2013 20:10:52 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id A7F6511E80FE for ; Fri, 25 Oct 2013 20:10:52 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P00HHTULF4007C84@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 25 Oct 2013 20:05:50 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OZQXEDTQ3400004R@mauve.mrochek.com>; Fri, 25 Oct 2013 20:05:46 -0700 (PDT) Message-id: <01P00HHRN7VK00004R@mauve.mrochek.com> Date: Fri, 25 Oct 2013 20:00:20 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 25 Oct 2013 21:13:04 -0400 (EDT)" References: <20131022182337.4789.qmail@joyce.lan> <01P00BXM2CJU00004R@mauve.mrochek.com> To: John R Levine Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 03:10:57 -0000 > > As I understand it, the primary use-case is for banks, e-sellers, and > > similar sorts sending status messages to MSPs and ISPs. In such cases > > what intermediaries are there likely to be? > I'm thinking of spam filtering proxies, either services like Messagelabs, > or a linux box put in front of an organization's Exchange server. My > impression is that they often do some sort of LDAP call to find out what > addresses are valid. I don't know enough about LDAP to know how hard it > would be to check the age of the address at the same time. These "solutions" tend to work spectacularly badly for all sorts of reasons. In regards to using LDAP, the real problem is getting them to do the lookup competently. Getting at an additional attribute is very small beer compared to other issues. It would actually be far better to define a non-LDAP way to retrieve both this and other important information (e.g., spam filter settings), but unfortunately nobody seems inclined to work on it. Ned From roni.even@mail01.huawei.com Thu Oct 24 12:14:54 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4257F11E8137; Thu, 24 Oct 2013 12:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k73a1W9RORDf; Thu, 24 Oct 2013 12:14:47 -0700 (PDT) Received: from hwsga02-in.huaweimarine.com (hwsga02-in.huaweimarine.com [119.145.15.224]) by ietfa.amsl.com (Postfix) with ESMTP id 0047421F9C00; Thu, 24 Oct 2013 12:14:46 -0700 (PDT) Received: from 172.24.1.79 (EHLO szxpml202-edg.exmail.huawei.com) ([172.24.1.79]) by szxrg12-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTE50747; Fri, 25 Oct 2013 03:14:41 +0800 (CST) From: Roni Even To: Claudio Allocchio , "apps-discuss@ietf.org" , "draft-ietf-clue-telepresence-use-cases.all@tools.ietf.org" Thread-Topic: APPSDIR review of draft-ietf-clue-telepresence-use-cases-07 Thread-Index: AQHOupq65yD711A4fkmOMUaph4UIeJoEZG9V Date: Thu, 24 Oct 2013 19:14:31 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C23E53B3BB@szxpml507-mbs.exmail.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.60] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Fri, 25 Oct 2013 23:54:04 -0700 Cc: "ron.even.tlv@gmail.com" , "Stephen.Botzko@polycom.com" , IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-clue-telepresence-use-cases-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2013 19:14:54 -0000 SGkgQ2xhdWRpbywNClRoYW5rcyBmb3IgdGhlIHJldmlldy4NCg0KVGhlIHRlY2huaWNhbCBmZWVk YmFjayBvbiBzZWN0aW9ucyAzLjIsIDMuMywgMy40LDMuNSwgMy42LCBhbmQgMy44IGFsbCBzZWVt IHRvIGJlIGJhc2VkIG9uIGEgbWlzdW5kZXJzdGFuZGluZyBvZiB0aGUgZG9jdW1lbnQncyBwdXJw b3NlLiAgQXMgc3RhdGVkIGluIHRoZSBpbnRyb2R1Y3Rpb24sIGl0IGlzIG1lcmVseSBhIHNldCBv ZiB1c2UgY2FzZXMgdGhhdCB0aGUgQ0xVRSBXRyBhZ3JlZWQgdG8gY29uc2lkZXIgaW4gdGhlIGRl dmVsb3BtZW50IG9mIHJlcXVpcmVtZW50cy4NCiANCldoYXQgdGhlIGRvY3VtZW50IGlzIE5PVCBp cw0KKGEpIGFuIGF0dGVtcHQgdG8gcHJlY2lzZWx5IGRlZmluZSB0aGUgYm91bmRhcmllcyBiZXR3 ZWVuIHRlbGVwcmVzZW5jZSBzeXN0ZW1zIGFuZCB0cmFkaXRpb25hbCBzeXN0ZW1zLiAgVGhlIENM VUUgV0cgYWdyZWVkIGVhcmx5IG9uIHRoYXQgdGhpcyB3YXMgYm90aCBwcm9ibGVtYXRpYyBhbmQg dW5uZWNlc3NhcnkuICANCihiKSBhbiBhdHRlbXB0IHRvIGRlZmluZSB0aGUgYmVzdCBzb2x1dGlv biBmb3IgZWFjaCBwcmVzZW50ZWQgc2NlbmFyaW8uICAgIEdlbmVyYWxseSB0aGVyZSBpcyBubyAi YmVzdCIgc29sdXRpb24sIGFuZCB2ZW5kb3JzIHdpbGwgY29udGludWUgdG8gbWFrZSBkaWZmZXJl bnQgY2hvaWNlcy4gIExpc3RpbmcgcG9zc2libGUgYXBwcm9hY2hlcyAoZ2VuZXJhbGx5IGluIHVz ZSB0b2RheSkgaXMgaW50ZW5kZWQgdG8gaGVscCB0aGUgQ0xVRSBXRyBlbnN1cmUgdGhhdCB0aGF0 IGl0cyBwcm90b2NvbCBidWlsZGluZyBibG9ja3MgYXJlIGZsZXhpYmxlIGVub3VnaCB0byBlbmFi bGUgbXVsdGlwbGUgc29sdXRpb25zLg0KIA0KUmF0aGVyIHRoYW4gYWRkIHRoZSBwcm9wb3NlZCBu ZXcgbWF0ZXJpYWwgdG8gc2VjdGlvbnMgMy4yLCAzLjMsIDMuNCwgMy41LCAzLjYsIGFuZCAzLjgs IHdlIHByb3Bvc2UgYSBjbGFyaWZ5aW5nIHNlbnRlbmNlIGJlIGFkZGVkIHRvIHRoZSBlbmQgb2Yg dGhlIGZpcnN0IHBhcmFncmFwaCBvZiBzZWN0aW9uIDI6DQogIA0KICJXZSBhbHNvIHNwZWNpZmlj YWxseSBkbyBub3QgYXR0ZW1wdCB0byBwcmVjaXNlbHkgZGVmaW5lIHRoZSBib3VuZGFyaWVzIGJl dHdlZW4gdGVsZXByZXNlbmNlIHN5c3RlbXMgYW5kIG90aGVyIHN5c3RlbXMsIG5vciBkbyB3ZSBh dHRlbXB0IHRvIGlkZW50aWZ5IHRoZSDigJxiZXN04oCdIHNvbHV0aW9uIGZvciBlYWNoIHByZXNl bnRlZCBzY2VuYXJpby4gICINCiANCiANCkluIGFkZGl0aW9uLCB0aGVyZSBpcyBhbiBlZGl0b3Jp YWwgc3VnZ2VzdGlvbiB0byBtb3ZlIHNlY3Rpb25zIDMuNSBhbmQgMy42IHRvIGFwcGVuZGljZXMu ICBXZSBkbyBub3Qgc2VlIGFueSBiZW5lZml0cyBpbiByZW9yZ2FuaXppbmcgdGhlIHRleHQgaW4g dGhpcyB3YXksIGFuZCB3ZSBkbyBzZWUgYSBkcmF3YmFjay4gIENMVUUgYWdyZWVkIHRoYXQgYWxs IG9mIHRoZXNlIHVzZSBjYXNlcyB3ZXJlIGdlcm1hbmUgdG8gaXRzIHJlcXVpcmVtZW50cyBkZWZp bml0aW9uLiAgSXQgc2VlbXMgdG8gdXMgdGhhdCBzaGlmdGluZyB0aGVzZSBzZWN0aW9ucyB0byBh cHBlbmRpY2VzIHdvdWxkIGNyZWF0ZSBjb25mdXNpb24gb24gdGhhdCBwb2ludC4NCg0KV2Ugd2ls bCByZW1vdmUgdGhlIGR1cGxpY2F0ZSB0ZXh0IGZyb20gc2VjdGlvbiAyIGFuZCByZWZlcmVuY2Ug dGhlIGludHJvZHVjdGlvbi4NClRoYW5rcw0KUm9uaSBFdmVuDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogQ2xhdWRpbyBBbGxvY2NoaW8gW0NsYXVk aW8uQWxsb2NjaGlvQGdhcnIuaXRdDQpTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDI2LCAyMDEz IDExOjI3IEFNDQpUbzogYXBwcy1kaXNjdXNzQGlldGYub3JnOyBkcmFmdC1pZXRmLWNsdWUtdGVs ZXByZXNlbmNlLXVzZS1jYXNlcy5hbGxAdG9vbHMuaWV0Zi5vcmcNCkNjOiBJRVNHDQpTdWJqZWN0 OiBBUFBTRElSIHJldmlldyBvZiBkcmFmdC1pZXRmLWNsdWUtdGVsZXByZXNlbmNlLXVzZS1jYXNl cy0wNw0KDQpIZWxsbyBhbGwsDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBBcHBsaWNh dGlvbnMgQXJlYSBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3INCnRoaXMgZHJhZnQgKGZvciBiYWNr Z3JvdW5kIG9uIGFwcHNkaXIsIHBsZWFzZSBzZWUg4oCLDQpodHRwOi8vdHJhYy50b29scy5pZXRm Lm9yZy9hcmVhL2FwcC90cmFjL3dpa2kvQXBwbGljYXRpb25zQXJlYURpcmVjdG9yYXRlICkuDQoN ClBsZWFzZSByZXNvbHZlIHRoZXNlIGNvbW1lbnRzIGFsb25nIHdpdGggYW55IG90aGVyIExhc3Qg Q2FsbCBjb21tZW50cw0KeW91IG1heSByZWNlaXZlLiBQbGVhc2Ugd2FpdCBmb3IgZGlyZWN0aW9u IGZyb20geW91ciBkb2N1bWVudCBzaGVwaGVyZA0Kb3IgQUQgYmVmb3JlIHBvc3RpbmcgYSBuZXcg dmVyc2lvbiBvZiB0aGUgZHJhZnQuDQoNCkRvY3VtZW50OiBkcmFmdC1pZXRmLWNsdWUtdGVsZXBy ZXNlbmNlLXVzZS1jYXNlcy0wNw0KVGl0bGU6IFVzZSBDYXNlcyBmb3IgVGVsZXByZXNlbmNlIE11 bHRpLXN0cmVhbXMNClJldmlld2VyOiBDbGF1ZGlvIEFsbG9jY2hpbw0KUmV2aWV3IERhdGU6IFNl cCAyNnRoIDIwMTMNCklFVEYgTGFzdCBDYWxsIERhdGU6IFNlcCAyNnRoIDIwMTMNCklFU0cgVGVs ZWNoYXQgRGF0ZTogTm90IGtub3duDQoNClN1bW1hcnk6IFRoaXMgZHJhZnQgaXMgYWxtb3N0IHJl YWR5IGZvciBwdWJsaWNhdGlvbiBhcyBhbiBJbmZvcm1hdGlvbmFsDQpSRkMuIEhvd2V2ZXIgaXQg bmVlZHMgc29tZSBlZGl0aW5nIGFuZCBtYXliZSBhIHJlLW9yZGVyaW5nIG9mIHNvbWUNCnNlY3Rp b25zLiBBbHNvIGEgbW9yZSBkZXRhaWxlZCBkZXNjcHJpdGlvbiBvZiB0aGUgImF1ZGlvIHNjZW5h cmlvIiBpbiBhbGwNCnNlY3Rpb25zIGlzIHdvcnRoIGFuIGVmb3J0IGJlZm9yZSBwdWJsaWNhdGlv bi4NCg0KTWFqb3IgaXNzdWVzOg0KDQpub25lLg0KDQpNaW5vciBpc3N1ZXM6DQoNCkdlbmVyYWwg Y29tbWVudDogbW9zdCBvZiB0aGUgZG9jdW1ldCBmb2N1c2VzIGEgbG90IG9uIHRoZSB2aWRlbyBh c3BlY3Qgb2YNCnRlbGVwcmVzZW5jZSwgYW5kIG9ubHkgaXMgc29tZSBzZWN0aW9uIHRoZSAiYXVk aW8gcHJlc2VuY2UiIGlzIHF1aWNrbHkNCmRlc2NyaWJlZCBhcyBwb3NzaWJsZSBzdGVyZW8sIG9y IHN1cnJvdW5kIG9yIG11bHRpYmxlIG1vbm9waG9uaWMgY2hhbm5lbHMuDQpJIHRoaW5rIHRoZSBh dWRpbyBhc3BlY3QgaXMgYXMgaW1wb3J0YW50IGFzIHRoZSB2aWRlbyBvbmUgaW4gbWFraW5nDQpw YXJ0aWNpcGF0bnMgZmVlbCB0aGUgdGVsZXByZXNlbmNlIGVmZmVjdCwgdGh1cyBlYWNoIHNlY3Rp b24gc2hvdWxkIGFkZCBhDQpjYXJmdWwgYXVkaW8gc2V0dXAgc2NlbmFyaW8gYXMgZGV0YWlsZWQg YXMgdGhlIHZpZGVvIG9uLiBUaGUgdm9pY2Ugb2YgYQ0KcGFydGlpcGFudHMgbXVzdCBjb21lIGZy b20gd2hlcmUgaGlzL2hlciB2aXJ0dWFsIGltYWdlIGlzLg0KDQpUaGVyZSBpcyBhIHRleHQgcmVw ZXRpdGlvbiBpbiBJbnRyb2R1Y3Rpb24gYW5kIGluIHNlY3Rpb24gMiAocGFnZSA1KToNCg0KICAg IFRoZSBiYXNpYyBmZWF0dXJlcyB0aGF0IGdpdmUgdGVsZXByZXNlbmNlIGl0cyBkaXN0aW5jdGl2 ZQ0KICAgIGNoYXJhY3RlcmlzdGljcyBhcmUgaW1wbGVtZW50ZWQgaW4gZGlzcGFyYXRlIHdheXMg aW4gZGlmZmVyZW50DQogICAgc3lzdGVtcy4gIEN1cnJlbnRseSBUZWxlcHJlc2VuY2Ugc3lzdGVt cyBmcm9tIGRpdmVyc2UgdmVuZG9ycw0KICAgIGludGVyb3BlcmF0ZSB0byBzb21lIGV4dGVudCwg YnV0IHRoaXMgaXMgbm90IHN1cHBvcnRlZCBpbiBhIHN0YW5kYXJkcw0KICAgIGJhc2VkIGZhc2hp b24uICBJbnRlcndvcmtpbmcgcmVxdWlyZXMgdGhhdCB0cmFuc2xhdGlvbiBhbmQNCiAgICB0cmFu c2NvZGluZyBkZXZpY2VzIGJlIGluY2x1ZGVkIGluIHRoZSBhcmNoaXRlY3R1cmUuICBTdWNoIGRl dmljZXMNCiAgICBpbmNyZWFzZSBsYXRlbmN5LCByZWR1Y2luZyB0aGUgcXVhbGl0eSBvZiBpbnRl cnBlcnNvbmFsIGludGVyYWN0aW9uLg0KICAgIFVzZSBvZiB0aGVzZSBkZXZpY2VzIGlzIG9mdGVu IG5vdCBhdXRvbWF0aWM7IGl0IGZyZXF1ZW50bHkgcmVxdWlyZXMNCiAgICBzdWJzdGFudGlhbCBt YW51YWwgY29uZmlndXJhdGlvbiBhbmQgYSBkZXRhaWxlZCB1bmRlcnN0YW5kaW5nIG9mIHRoZQ0K ICAgIG5hdHVyZSBvZiB1bmRlcmx5aW5nIGF1ZGlvIGFuZCB2aWRlbyBzdHJlYW1zLiBUaGlzIHN0 YXRlIG9mIGFmZmFpcnMNCiAgICBpcyBub3QgYWNjZXB0YWJsZSBmb3IgdGhlIGNvbnRpbnVlZCBn cm93dGggb2YgdGVsZXByZXNlbmNlIC0NCiAgICB0ZWxlcHJlc2VuY2Ugc3lzdGVtcyBzaG91bGQg aGF2ZSB0aGUgc2FtZSBlYXNlIG9mIGludGVyb3BlcmFiaWxpdHkgYXMNCiAgICBkbyB0ZWxlcGhv bmVzLg0KDQpFaXRoZXIgeW91IG1ha2UgYSBzaG9ydGVyIHN0YXRlbWVudCBpbiB0aGUgSW50cm9k dWN0aW9uLCBvZiB5b3UganVzdCByZWZlcg0KdG8gdGhlIGludHJvZHVjdGlvbiB0ZXh0IGluIHNl Y3Rpb24gMiwgcGFnZSA1Lg0KDQozLjIgc2VjdGlvbi4gVGhlIHdob2xlIHNlY3Rpb24gZGVzY3Jp YmVzIHBvc3NpYmxlIHRlY2huaXF1ZXMgdG8gb3ZlcmNvbWUNCnRoZSBtaXNtYXRjaGVkIHNpdHVh dGlvbiBhdCB0aGUgMiBzaXRlcy4uLiBidXQgaXQgZG9lcyBub3QgYW5hbHlzZSBhdCBhbGwNCnBv c3NpYmxlIGVmZmVjdHMgdGhhdCBkaWZmZXJlbnQgcHJvcG9zZWQgc29sdXRpb25zIGhhdmUgb24g dGhlDQoidGVsZXByZXNlbmNlIGVmZmVjdCIgaXRzZWxmLCBhbmQgb24gaHVtYW4gcGFydGljaXBh bnRzLiBBcyB0aGlzIGlzIGENCiJzY2VuYXJpbyBpbnRyb2R1Y3Rpb24iLCB3ZSBzaG91bGQgYWxz byBjb25zaWRlciB0aGlzIGFzcGVjdCwgYXMgdGhlbg0KdGVjaG5pY2FsIHNwZWNpZmljYXRpb24g Y2FuIGFsc28gaGFuZGxlIHBvc3NpYmxlIG1pdGlnYXRpb24gYWN0aW9ucyB0bw0KcmVkdWNlIHRo ZSBwcm9ibG0uIEZvciBleGFtcGxlLCBpbiBzb21lIG9mIHRoZSBjYXNlcyAtIHJlbW90ZSBwYXJ0 aWNpcGFudHMNCmNoZW5naW5nIGR5bmFtaWNhbGx5IG9uIHRoZSBzY3JlZW5zIC0gYSBwb3RlbnRp YWwgdmVyeSBiYWQgc2Vhc2ljaw0Kc2l0dWF0aW9uIHdpbGwgaGFwcGVuIGVhc2lseSwgbWFraW5n IHRoZSB0ZWxlcHJlc2VuY2UgZXNwZXJpZW5jZSBhDQpuaWdodG1hcmUuIE5vdGUgdGhhdCB0aGlz IGNvbW1lbnQgYWxzbyBhcHBsaWVzIHRvIDMuMyBzZWN0aW9uLg0KDQozLjMgc2VjdGlvbi4gVGhl IGRlc2NyaXB0aW9uIGFwcGxpZXMgdG8gY3VycmVudCB0ZWNobmlxdWVzIGZvciBtdWx0aXNpdGVz LA0KYnVlIHRoZXJlIGlzIG5vIG1lbnRpb24gb2YgcG9zc2libGUgb3ZlcmNvbWUgc2l0dWF0aW9u cyB3aGVuIGRpZmZlcmVudA0Kc3lzdGVtcyBhcmUgdXNlZC4gT2YgY291cnNlIHRoaXMgaXMgdmVy eSBzaW1pbGFyIHRvIDMuMiBjYXNlLCBidXQgd2l0aA0KY29tcGxleGl0eSBtdWx0aXBsaWVkIGJ5 IHRoZSBudW1iZXIgb2YgZGlycmVmZW50IHNpdGVzLiBJdCBzaG91bGQgYmUNCnVzZWZ1bCB0byBt ZW50aW9uIGV4cGxpY2l0bHkgYWxzbyB0aGlzIGZhY3QuDQoNCjMuNCBzZWN0aW9uLiBUaGUgY3Vy cmVjdCB0ZXh0IGRlc2NyaWJlcyB3aGF0IHlvdSBkbyB3aXRoIHRoZSBILjIzOQ0KZXF1aXZhbGVu dCBjaGFubmVsIGRhdGEsIGFuZCBzdWdnZXN0cyB0aGUgbmVlZCBvZiBhZGRpdGlvbmFsIHN0cmVh bXMgKG5vdA0KYSBzaWdsZSBvbmUpOiBmaW5lIGJ1dCB3aGF0IGlzIHRoZSBwcm9ibGVtIHRvIHNv bHZlIGhlcmUsIGlzIGFueT8gT2ssDQptYXliZSB5b3UganVzdCBuZWVkIHRvIHN0YXRlIHRoYXQg eW91IG5lZWQgdG8gbWFrZSBpbnRlcm9wZXJhYmxlIHRoZSBzaWdsZQ0KInByZXNlbnRhdG9uIGNo YW5uZWwiIHByb3ZpZGVkIGJ5IGFueSBzaXRlLg0KDQozLjUgc2VjdGlvbi4gQSBiYXNpYyBkb3Vi dDogaXMgdGhpcyBzZWN0aW9uIGludG8gdGhlIHNjb3BlIG9mIHRoaXMNCkluZm9ybWF0aW9uYWwg ZG9jdW1lbnQ/IElmIHdlIGFpbSB0byBoZWxwIGRlcGxveW1lbnQgb2YgY29tcGxldGUNCmludGVy b3BhcnRpbmcgc3lzdGVtcywgbWF5YmUgaXQgaXMsIGJlY2F1c2UgbW9zdCBleGlzdGluZyB0ZWxl cHJlc2VuY2UNCnN5c3RlbXMgaGF2ZSBwcm9wcmlldGFyeSAob3IgbGlrZWx5KSB3YXlzIHRvIGFs bG93IHBhcnRpY2lwYXRucyB3aXRoIG5vbg0KdGVsZXByZXNlbmNlIGRldmljZXMuIElmIHdlIGFy ZSBvbmx5IGFpbWluZyB0byByZWFsIHRlbGVwcmVzZW5jZSBzeXN0ZW1zDQppbnRlcm9wZXJhYmls aXR5LCB0aGVuIHRoaXMgc2VjdGlvbiBjb3VsZCBnbyBpbnRvIGFuIGFwcGVuZGl4IHNlY3Rpb24u DQoNCjMuNiBzZWN0aW9uLiBJIHRlbmQgdG8gdGhpbmsgdGhhdCBhbHNvIHRoaXMgY2FzZSBpcyB3 b3J0aCBmb3IgYW4gYXBwZW5kaXgNCihzZWUgMy41IGNvbW1lbnRzKS4NCg0KMy44IHNlY3Rpb24u IE15IGJhc2ljIGRvdWJ0IGhlcmUgaXMgImRvZXMgdGhpcyBiZWxvbmcgdG8gdGVsZXByZXNlbmNl DQpzY2VuYXJpbyBhdCBhbGw/IEltbWVyc2l2ZSBzY25lbmFyaW8gaW4gdGhpcyBzaXR1YXRpb24g aXMgcXVpdGUgZGlmZmVyZW50DQp0aGF0IHRoZSBvbmUgZGVzY3JpYmVkIGluIHRoZSBiZWdpbm5p bmcgKGEgdHlwaWNhbCBidXNpbmVzcyBtZWV0aW5nKS4gVGhpcw0KY29tbWVudCBhbHNvIGFwcGxp ZXMgdG8gc2VjdGlvbiAzLjYNCg0KTml0czoNCg0Kbm9uZS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpDbGF1ZGlvIEFsbG9jY2hpbyAgICAgICAgICAgICBHICAgQSAgIFIgICBSICAgICAgICAg IENsYXVkaW8uQWxsb2NjaGlvQGdhcnIuaXQNCiAgICAgICAgICAgICAgICAgICAgICAgICBTZW5p b3IgVGVjaG5pY2FsIE9mZmljZXINCnRlbDogKzM5IDA0MCAzNzU4NTIzICAgICAgSXRhbGlhbiBB Y2FkZW1pYyBhbmQgICAgICAgRz1DbGF1ZGlvOyBTPUFsbG9jY2hpbzsNCmZheDogKzM5IDA0MCAz NzU4NTY1ICAgICAgICBSZXNlYXJjaCBOZXR3b3JrICAgICAgICAgUD1nYXJyOyBBPWdhcnI7IEM9 aXQ7DQoNCiAgICAgICAgICAgIFBHUCBLZXk6IGh0dHA6Ly93d3cuY2VydC5nYXJyLml0L1BHUC9r ZXlzLnBocDMjY2E= From superuser@gmail.com Sat Oct 26 00:21:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B297621F9E9C for ; Sat, 26 Oct 2013 00:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rwoR64uAN5r for ; Sat, 26 Oct 2013 00:21:19 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 00B5C21F9A3D for ; Sat, 26 Oct 2013 00:21:18 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id ez12so1942195wid.17 for ; Sat, 26 Oct 2013 00:21:18 -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=1zzyh7mZJ6I1x1SzGh45Z02EGX1zTE+SRA0a1vlvK3E=; b=lK83I1XRhivgH8w0uX/mLrHg7hA2sNtaBMZTP+kPXicnmHCBsqv2rmOORbcEtDi9Y6 s4sNVNYVqRmSClFnAvMr24kryt42Pe0tDRNFmLMXtb2uh7CAl5LjEuCWBhw2g1p6iu+5 ozQBoJBzeh8bEh8WzuSahr9zTKw5zqrXyEW9PFOs6OPVpSRNYiD2kgri2zIz9ll7BJQD ZyDz2jBjucdiyqQdh/wF9mUaCJNOBb2seYLQWR4udXWPp75KpFalMSuROSec9W5cIf7k q75G9gBws3FmVy8I0fDWtsyIkz2gt6TV+kF9ZF85jzeg3LoUYgmDnr7gubOElD7G4B0Z Edbg== MIME-Version: 1.0 X-Received: by 10.194.250.6 with SMTP id yy6mr10501866wjc.13.1382772078214; Sat, 26 Oct 2013 00:21:18 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Sat, 26 Oct 2013 00:21:18 -0700 (PDT) Date: Sat, 26 Oct 2013 00:21:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c1ba4a87024504e99fb6a4 Subject: [apps-discuss] Draft IETF 88 APPSAWG/APPAREA agenda available X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Oct 2013 07:21:19 -0000 --001a11c1ba4a87024504e99fb6a4 Content-Type: text/plain; charset=ISO-8859-1 Colleagues, With apologies for its tardiness, the draft agenda for the joint APPSAWG/APPAREA meeting is now available here: http://www.ietf.org/proceedings/88/agenda/agenda-88-appsawg If you requested a time slot and you don't see your request reflected in the agenda, then I couldn't find your request in my inbox. Please email appsawg-chairs@tools.ietf.org with your request ASAP since the revised agendas are due Monday afternoon local time. The TBDs will be filled in shortly as we hear back from various invited presenters and more details become available. -MSK, APPSAWG co-chair --001a11c1ba4a87024504e99fb6a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

With apologies for its t= ardiness, the draft agenda for the joint APPSAWG/APPAREA meeting is now ava= ilable here:

http://www.ietf.org/proceedings/88/agenda/agenda-88-appsaw= g

If you requested a time slot and you don't see your request r= eflected in the agenda, then I couldn't find your request in my inbox.= =A0 Please email appsawg-c= hairs@tools.ietf.org with your request ASAP since the revised agendas a= re due Monday afternoon local time.

The TBDs will be filled in shortly as we hear back from various i= nvited presenters and more details become available.

-MSK, APP= SAWG co-chair

--001a11c1ba4a87024504e99fb6a4-- From vesely@tana.it Sat Oct 26 04:54:45 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1892511E8232 for ; Sat, 26 Oct 2013 04:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.644 X-Spam-Level: X-Spam-Status: No, score=-4.644 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sd0b4n6DBa2J for ; Sat, 26 Oct 2013 04:54:37 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id AD82611E810E for ; Sat, 26 Oct 2013 04:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1382788476; bh=ClSKQBVdxXKKfTgowcTttWSPvVDhP/6X1Ke+hOJJSIU=; l=1349; h=Date:From:To:References:In-Reply-To; b=Wa5btoY+gsXlAG6eXGbs8J0tZm3JJjWm3m/2G54vIGorodC1U59wGFzP4fYWpAcF+ tSLcWIkTRjusoXt/vk98u7O3+5o7O7yIuELg3xoDuTiathzZeuyht/50cmNwtvNrgT tHl9H8OGPeRUciOCNxEnQgbTfvFEDEQswV5/heFQ= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Sat, 26 Oct 2013 13:54:36 +0200 id 00000000005DC035.00000000526BAD7C.000007D3 Message-ID: <526BAD7B.1000003@tana.it> Date: Sat, 26 Oct 2013 13:54:35 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20131022182337.4789.qmail@joyce.lan> <01P00BXM2CJU00004R@mauve.mrochek.com> In-Reply-To: <01P00BXM2CJU00004R@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 11:54:45 -0000 On Sat 26/Oct/2013 01:03:55 +0200 Ned Freed wrote: > > The SMTP extension turns out to be very easy to implement. The RRVS value > is directly attached to the address, so there only two cases: > > (1) The address is local, in which case you check the information against > the account if you have it. And throw the information away no matter > what. > > (2) The address is nonlocal, in which case you attach the information to > the address so it can be relayed. I agree the extension looks easier than the header field. However, the concept of "local" is not thoroughly clear. An MTA can have both some sort of alias database and dot-forward recipes. The latter can be scripts or other artifacts dealt with by the local MDA only. So a message can be relayed even if it looked local when it was accepted. I rise this in order to check how this extension would work for email address portability. I client can learn a forwarding address from a 251/551 reply, or sending a test message with NOTIFY=SUCCESS and waiting for the DSN, or some other to-be-devised mechanism. I'd call _email address portability_ the possibility that an MTA reliably stores and uses addresses learned that way. In such scenario, RRVS would add the ability to tell it "go back and relearn, because something changed." Does that make sense? Ale From melvincarvalho@gmail.com Sat Oct 26 15:21:12 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6BC11E8196 for ; Sat, 26 Oct 2013 15:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTMVO8kisPBJ for ; Sat, 26 Oct 2013 15:21:12 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9C59011E81CF for ; Sat, 26 Oct 2013 15:21:11 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id hp15so4128713lab.18 for ; Sat, 26 Oct 2013 15:21:10 -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=EWoAp+vHwC2IS7o0minfR9HwV+GbW+bGpOft3bQxqww=; b=k1oC35CKwofvVA3y7Lac0t8e62olfpw01suyo7HC0GzpQ3EQJkVqZAS3D4dEoLvPBF wOeKLpbY3li4t6rM6yBCb7aIZ1dpQA6jgSlyccp+BkAGM4dp7ESRK99/Wuno9ZdrthtD Hb8Knh9A8scd5xmDVUpCaiMuJW9Dl+O5oxmE78VngJ6cXK4GUQT36pf8czHyWBf68N84 8aZyMtZ3KWXCzwNwP0v1U0Wa7NBztfGCJPYB/68tO/GfjmqVSRSDvjXaonvVeSqIofIX NHwgFtNvgujLDF9egE0fCe+4LWnENGZsNyobOegAsCbrPE+T8PFp4YVUY7QVXHTWriiG l9bA== MIME-Version: 1.0 X-Received: by 10.112.219.2 with SMTP id pk2mr6387788lbc.2.1382826070643; Sat, 26 Oct 2013 15:21:10 -0700 (PDT) Received: by 10.112.159.233 with HTTP; Sat, 26 Oct 2013 15:21:10 -0700 (PDT) Date: Sun, 27 Oct 2013 00:21:10 +0200 Message-ID: From: Melvin Carvalho To: Apps Discuss Content-Type: multipart/alternative; boundary=001a11c3dc58ba194a04e9ac48fe Subject: [apps-discuss] RFC 6920 ni: URIs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Oct 2013 22:21:12 -0000 --001a11c3dc58ba194a04e9ac48fe Content-Type: text/plain; charset=ISO-8859-1 I was wondering if RFC 6920 has any deployments currently? http://tools.ietf.org/html/rfc6920 I was thinking about reusing this, or doing something very similar in the field of virtual currencies on the web and it would be good to see some real world examples RFC6920 seems to have everything we need, but in cryto currencies people are used to dealing with base16 encoded, rather than, base64, so it would be good to understand how this works in practice... --001a11c3dc58ba194a04e9ac48fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I was wondering if RFC 6920 has any deployments currently?=
I was thinking = about reusing this, or doing something very similar in the field of virtual= currencies on the web and it would be good to see some real world examples=

RFC6920 seems to have everything we need, but in cryto curre= ncies people are used to dealing with base16 encoded, rather than, base64, = so it would be good to understand how this works in practice...
--001a11c3dc58ba194a04e9ac48fe-- From stephen.farrell@cs.tcd.ie Sun Oct 27 07:46:01 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF4B11E8260 for ; Sun, 27 Oct 2013 07:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAa19m83oqKk for ; Sun, 27 Oct 2013 07:45:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 67B9A11E8192 for ; Sun, 27 Oct 2013 07:45:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 138BDBEC9; Sun, 27 Oct 2013 14:45:49 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmmb4j5Rag+l; Sun, 27 Oct 2013 14:45:47 +0000 (GMT) Received: from [10.87.48.9] (unknown [86.42.23.144]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B3044BEC6; Sun, 27 Oct 2013 14:45:47 +0000 (GMT) Message-ID: <526D2719.10003@cs.tcd.ie> Date: Sun, 27 Oct 2013 14:45:45 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Melvin Carvalho , Apps Discuss , =?ISO-8859-1?Q?B=F6rje_Ohlman?= References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [apps-discuss] RFC 6920 ni: URIs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Oct 2013 14:46:01 -0000 Hiya, On 10/26/2013 11:21 PM, Melvin Carvalho wrote: > I was wondering if RFC 6920 has any deployments currently? I'm not aware of deployments. There is code [1] that's been used in various ICN experiments, and there'll be a demo of a FF browser with ni support in Vancouver at the ICNRG session on Sunday, that demo's not mine, so not sure if its using the netinf code or not, I've cc'd Brje who, being an ICNRG chair, knows more. > http://tools.ietf.org/html/rfc6920 > > I was thinking about reusing this, or doing something very similar in the > field of virtual currencies on the web and it would be good to see some > real world examples > > RFC6920 seems to have everything we need, but in cryto currencies people > are used to dealing with base16 encoded, rather than, base64, so it would > be good to understand how this works in practice... In the coding/testing we've done, base64 hasn't been an issue at all. Cheers, S. [1] http://sourceforge.net/projects/netinf/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From sm@elandsys.com Sun Oct 27 11:48:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB3221F9F6C; Sun, 27 Oct 2013 11:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.216 X-Spam-Level: X-Spam-Status: No, score=-102.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6x+FFSQFpp7; Sun, 27 Oct 2013 11:48:30 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A0911E819F; Sun, 27 Oct 2013 11:48:25 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.154.55]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9RIm6Lx012860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Oct 2013 11:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1382899703; bh=yZ18CMOR7cvkVGqi2WKALKp3VNkv8C2TCslZxBUchSM=; h=Date:To:From:Subject:Cc; b=JTYouWhgRo3YUmhrvIcqg0z+lRCCxXKanf6lrdS3IJYlT667K8/fRa3T28D9ixF0L RyZTsBU6XNHOCD3RNZWONdi7aO+G1i9sZOjIE6u52sicsoD9ap0VPldsTwKKbAQiL1 9qdW+/kUr6qGPOZWihlgiiqyAyqZ7m/zjxMTPRYA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1382899703; i=@elandsys.com; bh=yZ18CMOR7cvkVGqi2WKALKp3VNkv8C2TCslZxBUchSM=; h=Date:To:From:Subject:Cc; b=QjgQMUMEZ4+HmmY2zANoZhaqmv418/xfCA0rjNKdxSfwoMSR2bFk9ldVvag1HQvts sciWHRjD/Jw4leao1iXja6WrdNEHJ3Kl1jrhI150ylU5p2Z+epgOvOJP2LgvppBMFv ScwNJq+ccwSKxxwIDn1zu1O5pJ4QK8t6iTvePXfc= Message-Id: <6.2.5.6.2.20131026225145.0bee7bb8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 27 Oct 2013 11:44:46 -0700 To: apps-discuss@ietf.org, draft-ietf-httpbis-p1-messaging.all@tools.ietf.org, iesg@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf-http-wg@w3.org, ietf@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-httpbis-p1-messaging-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Oct 2013 18:48:32 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-httpbis-p1-messaging-24 Title: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing Reviewer: S. Moonesamy Review Date: October 27, 2013 IETF Last Call Date: October 21, 2013 Summary: This draft is almost ready for publication as a Proposed Standard. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations. The document is well-written and clear. I did not verify the changes between this specification and RFC 2616 as the intended status is Proposed Standard. This specification can affect other specifications in the Applications Area as there are several specifications which are built upon HTTP. Major issues: None Minor issues: In Section 2.6: "Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) MUST send their own HTTP-version in forwarded messages. In other words, they MUST NOT blindly forward the first line of an HTTP message without ensuring that the protocol version in that message matches a version to which that intermediary is conformant for both the receiving and sending of messages." The first RFC 2119 requirement (see above) states that the intermediary has to send its own HTTP-version while the second RFC 2119 requirement prohibits the intermediary from blindly forwarding the first line of the HTTP message. The intent of the first requirement seems clear to me. I suggest having the second requirement as clarifying text instead of a RFC 2119 requirement. "A client SHOULD send a request version equal to the highest version to which the client is conformant and whose major version is no higher than the highest version supported by the server, if this is known." The client would have to track the version supported by the server once it knows that information. A server can be one or more HTTP implementations. In practice these implementations will likely support HTTP 1.1. I'll list the "and whose major version is no higher than the highest version supported ..." as an issue. Is the intent to ensure that the client can work with HTTP 2.0? "A server MAY send a 505 (HTTP Version Not Supported) response if it cannot send a response using the major version used in the client's request." Why is this a RFC 2119 "may"? In Section 5.7: "An intermediary MUST NOT forward a message to itself unless it is protected from an infinite request loop. In general, an intermediary ought to recognize its own server names, including any aliases, local variations, or literal IP addresses, and respond to such requests directly." I don't understand why an intermediary would forward a message to itself. Please note that I do not consider this prohibition as an issue. In Section 6.1: "Recipients that trigger certain connection behavior based on the presence of connection options MUST do so based on the presence of the connection-option rather than only the presence of the optional header field. In other words, if the connection option is received as a header field but not indicated within the Connection field-value, then the recipient MUST ignore the connection-specific header field because it has likely been forwarded by an intermediary that is only partially conformant. I am flagging the usage of a requirement followed by the "must ignore" requirement as an issue as the "in other words" suggest that it is a clarification of the first requirement. In Section 6.4 "A client SHOULD limit the number of simultaneous open connections that it maintains to a given server." There is an explanation about why a specific number is not included for this recommendation in the paragraphs following the above text. I read Issue #131. I don't see any discussion of the tradeoffs in Section 6.4. The is a note about servers may reject an excessive number of connections from a client if they deem that it is abusive. The HTTP Transfer Coding namespace (Section 8.4) is currently "First Come First Served". The new registration procedure required IETF Review. What is the reason for the change? In Section 8.5.1: 'The registration SHOULD name a set of expected "protocol-version" tokens associated with that token at the time of registration.' Why is this a RFC 2119 "should"? "The IESG MAY reassign responsibility for a protocol token. This will normally only be used in the case when a responsible party cannot be contacted." I suggest using plain English instead of RFC 2119 key words for the above (and for the rest of the text in Section 8.5.1). Nits: For Section 8.1, the Message Header Field Names registry is at http://www.iana.org/assignments/message-headers/ For Section 8.2, the URI Schemes registry is at http://www.iana.org/assignments/uri-schemes/ In Section 8.4, the RFC 2119 key words are not needed as that section is about a procedure for registration. Plain English is usually clear enough. Regards, S. Moonesamy From melvincarvalho@gmail.com Sun Oct 27 12:22:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC7511E80E9 for ; Sun, 27 Oct 2013 12:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zVI5ydPMRR5 for ; Sun, 27 Oct 2013 12:22:03 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id D45AA11E81DE for ; Sun, 27 Oct 2013 12:22:01 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id o14so2249197lbi.9 for ; Sun, 27 Oct 2013 12:22:00 -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=2vjsTD5Z6rrrZU+4mm2oIrC0cwwNWNRoaRkwpxFkii8=; b=xDaXjrUkmKa6CwpEtgn3/IZW/Rm1BHR+CvWZI9ybjeCo4krS6GPAOPtOvSwMJvI3Qi Qox2GHKhfXZ9LsubU9RG5Jq7vf2FHSSjFCodi0dXiGIbV1WvVXTF0RyMUdPG+eTOZa83 hqM/d4SZGcKvOCqwrnXGaT4/cXbuJ6PichZ2ae1rpqMqxF7s3oxiPwI9g4+R4entgENp DkxWxyJCNejwBEX+M7cC5feaDQmbs1NFE9iuc+NuaaDBMS2aRA0ANjJ6sz5Wn81OMYVl WstYCLowuy4BnJ6qUmUEnCujP+nuqchqL7rvBgi30RQ6uVjmQJeMa+TSOZ0Y8hM16aeY 8w+Q== MIME-Version: 1.0 X-Received: by 10.112.136.65 with SMTP id py1mr5073379lbb.4.1382901720778; Sun, 27 Oct 2013 12:22:00 -0700 (PDT) Received: by 10.112.159.233 with HTTP; Sun, 27 Oct 2013 12:22:00 -0700 (PDT) In-Reply-To: <526D2719.10003@cs.tcd.ie> References: <526D2719.10003@cs.tcd.ie> Date: Sun, 27 Oct 2013 20:22:00 +0100 Message-ID: From: Melvin Carvalho To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e0115f6c4d38d1404e9bde594 Cc: =?ISO-8859-1?Q?B=F6rje_Ohlman?= , Apps Discuss Subject: Re: [apps-discuss] RFC 6920 ni: URIs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Oct 2013 19:22:03 -0000 --089e0115f6c4d38d1404e9bde594 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 27 October 2013 15:45, Stephen Farrell wrote= : > > Hiya, > > On 10/26/2013 11:21 PM, Melvin Carvalho wrote: > > I was wondering if RFC 6920 has any deployments currently? > > I'm not aware of deployments. There is code [1] that's > been used in various ICN experiments, and there'll be > a demo of a FF browser with ni support in Vancouver at > the ICNRG session on Sunday, that demo's not mine, so > not sure if its using the netinf code or not, I've cc'd > B=F6rje who, being an ICNRG chair, knows more. > > > http://tools.ietf.org/html/rfc6920 > > > > I was thinking about reusing this, or doing something very similar in t= he > > field of virtual currencies on the web and it would be good to see some > > real world examples > > > > RFC6920 seems to have everything we need, but in cryto currencies peopl= e > > are used to dealing with base16 encoded, rather than, base64, so it wou= ld > > be good to understand how this works in practice... > > In the coding/testing we've done, base64 hasn't been an > issue at all. > Thanks, I'm going to try and deploy some of these then (small scale) The encoding wasnt too bad after working out the +/ becomes -_ The thing is the community I work with will probably not consider 64 bit encodings "correct" but I guess there's no way to do 16bit right now without making a new spec, which seems overkill ... > > Cheers, > S. > > [1] http://sourceforge.net/projects/netinf/ > > > > > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > --089e0115f6c4d38d1404e9bde594 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 27 October 2013 15:45, Stephen Farrell <stephen.farrell= @cs.tcd.ie> wrote:

Hiya,

On 10/26/2013 11:21 PM, Melvin Carvalho wrote:
> I was wondering if RFC 6920 has any deployments currently?

I'm not aware of deployments. There is code [1] that's
been used in various ICN experiments, and there'll be
a demo of a FF browser with ni support in Vancouver at
the ICNRG session on Sunday, that demo's not mine, so
not sure if its using the netinf code or not, I've cc'd
B=F6rje who, being an ICNRG chair, knows more.

> http:= //tools.ietf.org/html/rfc6920
>
> I was thinking about reusing this, or doing something very similar in = the
> field of virtual currencies on the web and it would be good to see som= e
> real world examples
>
> RFC6920 seems to have everything we need, but in cryto currencies peop= le
> are used to dealing with base16 encoded, rather than, base64, so it wo= uld
> be good to understand how this works in practice...

In the coding/testing we've done, base64 hasn't been an
issue at all.

Thanks, I'm going to = try and deploy some of these then (small scale)

The encod= ing wasnt too bad after working out the +/ becomes -_

The thing is the community I work with will probably not consider 64 bit en= codings "correct" but I guess there's no way to do 16bit righ= t now without making a new spec, which seems overkill ...
=A0

Cheers,
S.

[1] h= ttp://sourceforge.net/projects/netinf/


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

--089e0115f6c4d38d1404e9bde594-- From ned.freed@mrochek.com Sun Oct 27 14:06:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AC111E82C0; Sun, 27 Oct 2013 14:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIItHkdXmec5; Sun, 27 Oct 2013 14:06:37 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 58A2611E82BD; Sun, 27 Oct 2013 14:06:37 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P02XCP055S006LUY@mauve.mrochek.com>; Sun, 27 Oct 2013 14:01:24 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OZQXEDTQ3400004R@mauve.mrochek.com>; Sun, 27 Oct 2013 14:01:07 -0700 (PDT) Message-id: <01P02XCD0M6W00004R@mauve.mrochek.com> Date: Sun, 27 Oct 2013 13:40:54 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 22 Oct 2013 16:13:56 +0100" References: <20131016131142.32211.49752.idtracker@ietfa.amsl.com> To: ht@inf.ed.ac.uk Cc: xml-mime@ietf.org, public-xml-core-wg@w3.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 21:06:42 -0000 > I've produced a new draft, with only one (moderately large) change, > agreed in discussion with my fellow editor Chris Lilley. I've missed > the official cutoff for publishing new drafts before Berlin, so please > see > http://www.w3.org/XML/2012/10/3023bis/draft-ietf-appsawg-xml-mediatypes-04.html#charset > http://www.w3.org/XML/2012/10/3023bis/draft-ietf-appsawg-xml-mediatypes-04_diff.html#charset The new charset material looks fine to me. > for substantial clarifications to the rework of Section 3.6 _Charset > considerations_ given in version -03. > Any existing reviewing work on any _other_ section based on version > -03 is still relevant, as no other section has changed in any > significant way. > Note also accordingly that the diffs in the above -04_diff.html are > still against version -02. A few additional comments, all fairly minor. In section 3, there are a couple of places where it says "The media types application/xml and text/xml MUST NOT be used". Would it make sense to include the +xml suffix as something that MUST NOT be used? The material at the end of Section 9.2 is arguably a little too important to relegate to an example. The obvious place to move it would be to Section 3.2. Ther probably should be a pointer at the end of Section 3.6 to the examples in Section 9. There's a missing period on the last sentence of Section 9.8. The IANA Considerations in Section 10 need to list the types being registered here. That's it! Ned From julian.reschke@gmx.de Sun Oct 27 14:18:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D10221F9F19 for ; Sun, 27 Oct 2013 14:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.909 X-Spam-Level: X-Spam-Status: No, score=-102.909 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWOLUrH9pt9X for ; Sun, 27 Oct 2013 14:18:11 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 11A2D11E82B7 for ; Sun, 27 Oct 2013 14:18:04 -0700 (PDT) Received: from [192.168.2.117] ([93.217.109.236]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M2nfO-1VrWft2yes-00sb0M for ; Sun, 27 Oct 2013 22:18:04 +0100 Message-ID: <526D830E.60704@gmx.de> Date: Sun, 27 Oct 2013 22:18:06 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: S Moonesamy , apps-discuss@ietf.org, draft-ietf-httpbis-p1-messaging.all@tools.ietf.org, iesg@ietf.org References: <6.2.5.6.2.20131026225145.0bee7bb8@elandnews.com> In-Reply-To: <6.2.5.6.2.20131026225145.0bee7bb8@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:COC14TfM6yIpCpz7NpdROueSupYBzt158gi2pUT1T5MFszOMkgN qNB1LWkRwD7BEnqyUBhMO9bhmAdcmY5taS37xCWLNTmaHg8RxpKkcseKjJc6Nx5LSE8ub1V tNV4vGrPOnc4KExiH3X64BtiwOt5qB3l+uA0vDt7pzzL5vMdXX9z+EPwCaHsujaQwz5wM76 mUF7VpGV+OK1SPugObUwQ== Cc: ietf-http-wg@w3.org, ietf@ietf.org Subject: [apps-discuss] IANA URIS, was: APPSDIR review of draft-ietf-httpbis-p1-messaging-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Oct 2013 21:18:12 -0000 On 2013-10-27 19:44, S Moonesamy wrote: > ... > Nits: > > For Section 8.1, the Message Header Field Names registry is at > http://www.iana.org/assignments/message-headers/ > > For Section 8.2, the URI Schemes registry is at > http://www.iana.org/assignments/uri-schemes/ > ... Ack. Out of curiosity: is there an obvious way to find out what the "canonical" URI of a registry is? Best regards, Julian From ned.freed@mrochek.com Sun Oct 27 22:47:17 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40EA21F9FBA for ; Sun, 27 Oct 2013 22:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJUo8cTz8yLF for ; Sun, 27 Oct 2013 22:47:10 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4F32911E8122 for ; Sun, 27 Oct 2013 22:47:06 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P03FJ7STBK007F5W@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 27 Oct 2013 22:42:04 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OZQXEDTQ3400004R@mauve.mrochek.com>; Sun, 27 Oct 2013 22:42:00 -0700 (PDT) Message-id: <01P03FJ5YVMC00004R@mauve.mrochek.com> Date: Sun, 27 Oct 2013 19:27:46 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 26 Oct 2013 13:54:35 +0200" <526BAD7B.1000003@tana.it> References: <20131022182337.4789.qmail@joyce.lan> <01P00BXM2CJU00004R@mauve.mrochek.com> <526BAD7B.1000003@tana.it> To: Alessandro Vesely Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 05:47:17 -0000 > On Sat 26/Oct/2013 01:03:55 +0200 Ned Freed wrote: > > > > The SMTP extension turns out to be very easy to implement. The RRVS value > > is directly attached to the address, so there only two cases: > > > > (1) The address is local, in which case you check the information against > > the account if you have it. And throw the information away no matter > > what. > > > > (2) The address is nonlocal, in which case you attach the information to > > the address so it can be relayed. > I agree the extension looks easier than the header field. However, > the concept of "local" is not thoroughly clear. An MTA can have both > some sort of alias database and dot-forward recipes. The latter can > be scripts or other artifacts dealt with by the local MDA only. So a > message can be relayed even if it looked local when it was accepted. But in both of the cases you cite, you have effectively validated the incoming address in terms of RRVS, breaking the RRVS chain. The entire point of having aliases and dot-forward files is to have a stable address that can be redirected in various ways. Of course nothing says that the forwarding address can't start a new RRVS chain by recording when forwarding to that particular was first set up. The only problem with that is going to be error reporting: Who do you report the problem to so whoever owns the forwarding address can update it? In any case, unless there's some sort of special relationship between the forwarder and where it forwards to, the RRVS information should not carry through an alias, redirection, whatever. And if such a relationship exists, then I don't see much point in regarding this as anything other than a local matter. > I rise this in order to check how this extension would work for email > address portability. I client can learn a forwarding address from a > 251/551 reply, or sending a test message with NOTIFY=SUCCESS and > waiting for the DSN, or some other to-be-devised mechanism. I'd call > _email address portability_ the possibility that an MTA reliably > stores and uses addresses learned that way. In such scenario, RRVS > would add the ability to tell it "go back and relearn, because > something changed." Does that make sense? First of all, I don't see this RRVS into forwarding entry as having anything to do with email address portability. Use of RRVS to insure the forwarder itself doesn't end up forwarding to the wrong might make sense, but that doesn't really impact the portability issue per se. Second, the 251/551 mechanism is *very* different than a success DSN. Anyone who updates addresses on their list in any way other than deleting it on the basis of a DSN response is way out in the weeds - there is no DSN-based mechanism defined for updating addresses. The x.1.6 status code for "mailbox has moved" explicitly says "no forwarding address". As for 251/551, I'm afraid I regard the whole approach as obsolete. The main problem is security: As noted in section 7.2 of RFC 5321, a MITM attack on such mechanisms can be used to redirect not only the current but all future messages. Absent far more ubiquitous use of security on relay connections, this whole approach is just too risky. All that said, if someone was, let's call it "bold" enough to enable use of 251/551, and there was a server that actually sent such replies often enough to matter, then I fail to see much semantic difference between this and having a user update their email address on some account using a web form or whatever. Updating the address associated with an account obviously has to wipe out any RRVS information on file and so should a 251/551 update. The only wrinkle I see is that the old address does need to be notified of the change, and that notification has to operate using the old RRVS info. Ned From sm@elandsys.com Mon Oct 28 01:08:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2904221F9F40; Mon, 28 Oct 2013 01:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.235 X-Spam-Level: X-Spam-Status: No, score=-102.235 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpcZ1rZvTNQF; Mon, 28 Oct 2013 01:08:25 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B965C11E8151; Mon, 28 Oct 2013 01:08:23 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.154.55]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9S8879B021796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Oct 2013 01:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1382947700; bh=brm049+R5VV06af1eqFZ9hamPFoFEA6dnx7Q7QmH8ss=; h=Date:To:From:Subject:Cc; b=Va4BOaKL5W/mkUcnX/Dw4Su0UnEQ1j1DAsu+vGR9vXuVY5R8Z27D1QeH/i4v3GSAW X2KVv+hykMFBj6nsWCrrLsOsyFC2WF4U4clk9s/eBMa7L/4wxpblRNYbBmLg6Ue++u dPgEG34HBnMDLbXRTE8xIUsI0IGOpPR0RuqFTge0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1382947700; i=@elandsys.com; bh=brm049+R5VV06af1eqFZ9hamPFoFEA6dnx7Q7QmH8ss=; h=Date:To:From:Subject:Cc; b=aE/7bY1UE+i/v732xpJnwchDiIUUNR/PgUs6O5nNxqn4Rw9uf3H0XZCW/R9A8Qe1/ BJ0d5I5DBXCRAJVEcYb1apsQdgjDY4EpA56nIugauEqwICLKd74An3fH4rI5SYbj+s wgba1w8QA7W7B+DdnK8myep64IBSSD0Blj8pXwkQ= Message-Id: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 28 Oct 2013 01:07:31 -0700 To: apps-discuss@ietf.org, draft-ietf-httpbis-p2-semantics.all@tools.ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: iesg@ietf.org, ietf-http-wg@w3.org, ietf@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 08:08:26 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-httpbis-p2-semantics-24 Title: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content Reviewer: S. Moonesamy Review Date: October 28, 2013 IETF Last Call Date: October 21, 2013 Summary: This draft is almost ready for publication as a Proposed Standard. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation. The draft is well-written and clear. Major Issues: In Section 3.1.1.5: 'If a Content-Type header field is not present, the recipient MAY either assume a media type of "application/octet-stream" ([RFC2046], Section 4.5.1) or examine the data to determine its type.' According to RFC 2046, the "octet-stream" subtype is used to indicate that a body contains arbitrary data. The RFC 2119 "may" leaves it to the implementor to make an assumption. I suggest turning this into a recommendation so that the assumption is clear to the implementor. There is a discussion of MIME sniffing in draft-ietf-websec-mime-sniff-03. There has been discussion about MIME or Content sniffing over the years. I am aware that some browsers do MIME sniffing. I understand that it is sometimes needed to make the Web work. However, it can lead to security vulnerabilities. The paragraph which follows the one quoted above discusses about that. I listed this as a major issue for the attention of the Applications Area Directors. Minor Issues: In Section 5.5.1: 'The "From" header field contains an Internet email address for a human user who controls the requesting user agent. The address ought to be machine-usable, as defined by "mailbox" in Section 3.4 of [RFC5322]:' The above text is similar to text which was in RFC 2068 and RFC 2616. The "mailbox" may also contain a display name whereas the "addr-spec" (see Section 3.4.1) is an Internet mail address. I listed this issue as minor to flag it for the attention of the HTTPbis Working Group. In Section 5.5.3: "a sender MUST NOT generate advertising or other non-essential information within the product identifier" I suggest having the text as guidance together with an explanation instead of a RFC 2119 prohibition. In Section 7.1.1: "The preferred format is a fixed-length and single-zone subset of the date and time specification used by the Internet Message Format [RFC5322]" The ABNF imports obs-date from RFC 5322. "GMT" is defined in "obs-zone" (see RFC 5322). There is the following in the section: "For example, messages are occasionally forwarded over HTTP from a non-HTTP source that might generate any of the date and time specifications defined by the Internet Message Format." I listed this as a minor issue. I am not suggesting any change as "GMT" is used in other header fields. I'll defer to the HTTPbis Working Group as to whether there should be a note about "GMT" with an explanation that although "GMT" is deprecated the use is widespread. Section 8.1 defines a HTTP Method Registry where registration requires IETF Review. I took a quick look at Issue #364. Section 4.2 discusses about common method properties, e.g. cacheable. The fields in Section 8.1.1 does not include cacheable. There are considerations for new methods in Section 8.1.2. I gather that the working group understands that someone will have to review the specification and raise an issue if the considerations are not followed. The table in Section 8.1.3 only mentions the section number. There is an assumption that the specification text is in this draft. I suggest also adding a reference for the RFC number. As a note for the reader, draft-ietf-httpbis-method-registrations-13 also registers some HTTP methods. The above assumption also applies to Section 8.2. I suggest updating the existing registrations at http://www.iana.org/assignments/http-status-codes/ so that the HTTP Status Code Registry is compliant with Section 8.2.1. Nits: In Section 5.5.2: "Referer allows servers to generate back-links to other resources for" "information disclosure in Referer ought to restrict their changes to" I'll defer to the editors as to whether to add "header field". I suggest changing the RFC 1305 reference in Section 7.1.1.1 to RFC 5905. In Section 8.3.1: 'Authors of specifications defining new fields are advised to keep the name as short as practical and to not prefix the name with "X-" unless the header field will never be used on the Internet.' I suggest adding a reference to BCP 178. Regards, S. Moonesamy From sm@elandsys.com Mon Oct 28 02:08:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1740711E823F; Mon, 28 Oct 2013 02:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.253 X-Spam-Level: X-Spam-Status: No, score=-102.253 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ie2wYN4qJoeG; Mon, 28 Oct 2013 02:08:42 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 169FE11E816F; Mon, 28 Oct 2013 02:08:20 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.154.55]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9S980lA006556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Oct 2013 02:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1382951292; bh=RTWj+YlCGGUUF8pMLP4Xpuq4W3lahx23+PKodWDnPQ8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OQpYNsCYGcXnMapOZ0GzXX1ibjsymNCBLeYFDtwT5Omd3ur7NHWev7mx8ezQNuM/Z Tva+7VTBg7KLF7uvcTmSU6Vgk/c8dPi85KzBlXatwoX25fn4Mi7893ohf4BQGhX4s6 CQgC+g3BGTFLsZa6CaLAj8ybJYI7PSwui9hvA8/s= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1382951292; i=@elandsys.com; bh=RTWj+YlCGGUUF8pMLP4Xpuq4W3lahx23+PKodWDnPQ8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=T8uDyrvWzLkVXM3itlJ3UuIdL2hV47cKlAkR+6gfsEFyR1jNFxPrRm0WBRHZfxr4S 6UTwqYLRVEfbAsiMugCIwB2T9SYWiqlejUKJGviEFU83Ht+WHaX1Gn69cFsqKECh99 sA4n2UovYHIY7cAm1FTHy/Z7O8jZEO6A3KTs6oAQ= Message-Id: <6.2.5.6.2.20131028015520.0d6cd4d8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 28 Oct 2013 02:06:16 -0700 To: Julian Reschke From: S Moonesamy In-Reply-To: <526D830E.60704@gmx.de> References: <6.2.5.6.2.20131026225145.0bee7bb8@elandnews.com> <526D830E.60704@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf-http-wg@w3.org, apps-discuss@ietf.org, ietf@ietf.org Subject: Re: [apps-discuss] IANA URIS, was: APPSDIR review of draft-ietf-httpbis-p1-messaging-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 09:08:47 -0000 Hi Julian, At 14:18 27-10-2013, Julian Reschke wrote: >Out of curiosity: is there an obvious way to find out what the >"canonical" URI of a registry is? There was a comment from IANA about its intention to keep http://www.iana.org/assignments/example format working. The obvious way is to drop the file name and extension (e.g. http://www.iana.org/assignments/uri-schemes ). Regards, S. Moonesamy From vesely@tana.it Mon Oct 28 03:12:01 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C3111E8115 for ; Mon, 28 Oct 2013 03:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.659 X-Spam-Level: X-Spam-Status: No, score=-4.659 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFH6tH4Jm7mG for ; Mon, 28 Oct 2013 03:11:55 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 979E111E8149 for ; Mon, 28 Oct 2013 03:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1382955081; bh=bueghx/Qzdk9R7iDLZKToRjJdkC1xpiCfpp4bVupZTs=; l=5564; h=Date:From:To:CC:References:In-Reply-To; b=EYOtOQAwEunavEDYeB4m53JCNTec+OO16FYPVOtZxKtshyIlDzdojjhZeM/ZQiykK r2G43kzm70KsGB3FFkIwyZnBsGR1KIg9FPM+rm8+/zvaLebpvVajjJ8OCTnojRMNe1 cqZ4PKFVk/du/WKo1rWB/NBVujJ/qOPXtN3LSjOk= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 28 Oct 2013 11:11:21 +0100 id 00000000005DC039.00000000526E3849.00004201 Message-ID: <526E3849.5000801@tana.it> Date: Mon, 28 Oct 2013 11:11:21 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9 MIME-Version: 1.0 To: Ned Freed References: <20131022182337.4789.qmail@joyce.lan> <01P00BXM2CJU00004R@mauve.mrochek.com> <526BAD7B.1000003@tana.it> <01P03FJ5YVMC00004R@mauve.mrochek.com> In-Reply-To: <01P03FJ5YVMC00004R@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 10:12:01 -0000 On Mon 28/Oct/2013 03:27:46 +0100 Ned Freed wrote: >>> >>> The SMTP extension turns out to be very easy to implement. The RRVS >>> value is directly attached to the address, so there only two cases: >>> >>> (1) The address is local, in which case you check the information >>> against the account if you have it. And throw the information >>> away no matter what. >>> >>> (2) The address is nonlocal, in which case you attach the >>> information to the address so it can be relayed. > >> I agree the extension looks easier than the header field. >> However, the concept of "local" is not thoroughly clear. An MTA >> can have both some sort of alias database and dot-forward >> recipes. The latter can be scripts or other artifacts dealt with >> by the local MDA only. So a message can be relayed even if it >> looked local when it was accepted. > > But in both of the cases you cite, you have effectively validated > the incoming address in terms of RRVS, breaking the RRVS chain. The > entire point of having aliases and dot-forward files is to have a > stable address that can be redirected in various ways. > > Of course nothing says that the forwarding address can't start a > new RRVS chain by recording when forwarding to that particular was > first set up. The only problem with that is going to be error > reporting: Who do you report the problem to so whoever owns the > forwarding address can update it? Hm, I thought the whole purpose of saving the RRVS to the header was to reinstate using it as a client in case it forwarded. You consider it a MAY(?), while I thought it was meant to be a SHOULD. Perhaps, the draft needs to clarify this point. For simple forwarding, rejection would trigger an NDN as usual. No? > In any case, unless there's some sort of special relationship > between the forwarder and where it forwards to, the RRVS > information should not carry through an alias, redirection, > whatever. You mean "SHOULD NOT"? >> I rise this in order to check how this extension would work for email >> address portability. I client can learn a forwarding address from a >> 251/551 reply, or sending a test message with NOTIFY=SUCCESS and >> waiting for the DSN, or some other to-be-devised mechanism. I'd call >> _email address portability_ the possibility that an MTA reliably >> stores and uses addresses learned that way. In such scenario, RRVS >> would add the ability to tell it "go back and relearn, because >> something changed." Does that make sense? > > First of all, I don't see this RRVS into forwarding entry as having > anything to do with email address portability. Use of RRVS to > insure the forwarder itself doesn't end up forwarding to the wrong > might make sense, but that doesn't really impact the portability > issue per se. Yes, of course. The idea is just to check the robustness of the specification by considering how it can be (mis)understood when viewed from a different angle. > Second, the 251/551 mechanism is *very* different than a success > DSN. Anyone who updates addresses on their list in any way other > than deleting it on the basis of a DSN response is way out in the > weeds - there is no DSN-based mechanism defined for updating > addresses. The x.1.6 status code for "mailbox has moved" explicitly > says "no forwarding address". AFAIK, sending servers maintain no lists of "ported addresses", so there is no mechanism to update them. (The traffic increase due to dot-forward recipes seems to be negligible compared to spam, and forwarding can be used to add spam filters.) But a protocol-fiction story could consider shortcuts as a means to skip possible spy-points, besides using domain-level encryption, say. > As for 251/551, I'm afraid I regard the whole approach as obsolete. > The main problem is security: As noted in section 7.2 of RFC 5321, > a MITM attack on such mechanisms can be used to redirect not only > the current but all future messages. Absent far more ubiquitous use > of security on relay connections, this whole approach is just too > risky. I assume you mean Section 7.4, "Mail Rerouting Based on the 251 and 551 Response Codes". I never saw code to act on it automatically. > All that said, if someone was, let's call it "bold" enough to > enable use of 251/551, and there was a server that actually sent > such replies often enough to matter, then I fail to see much > semantic difference between this and having a user update their > email address on some account using a web form or whatever. > Updating the address associated with an account obviously has to > wipe out any RRVS information on file and so should a 251/551 > update. > > The only wrinkle I see is that the old address does need to be > notified of the change, and that notification has to operate using > the old RRVS info. Consider a sending server which stored the forwarding A->B after a 251 reply. When it sends directly to B it uses RRVS with the date on which it learned A->B. If the recipient subsequently changes A->B into A->C, he or she should also set B->C or B->A. In that case, the receiving server will have a dot-forward file with an st_mtime more recent than the RRVS date used by the sending server. That does not necessarily imply a change of ownership, but it might. How about modifying the spec so as to have the receiving server reply something different in the "unknown" cases? For example: 251 Something changed; will possibly forward to Ale From julian.reschke@gmx.de Mon Oct 28 06:28:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4513111E8306 for ; Mon, 28 Oct 2013 06:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.481 X-Spam-Level: X-Spam-Status: No, score=-103.481 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHtmS+FfZYqi for ; Mon, 28 Oct 2013 06:27:41 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id E196511E82D3 for ; Mon, 28 Oct 2013 06:27:31 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LjdS8-1W7voY1bGS-00bbhi for ; Mon, 28 Oct 2013 14:27:30 +0100 Message-ID: <526E6640.6030500@gmx.de> Date: Mon, 28 Oct 2013 14:27:28 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Henry S. Thompson" , apps-discuss@ietf.org References: <20131016131142.32211.49752.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:uNWBNu0vE2CFav3xAGO5gVvqbf0QvJWjIczCUUXZkT4/uxFkKkx kMJ6LADU4tBtUHgGYElXOM4AhWVuxig8tU68gGDdqInvu4MtuXvDUSC2qLRagEMPvGp8xkt 5vuKCcXJnYbYNhzR+o6QUdr4zSDG8E6eFl+OEFlo6xMNyGwLYbqUNjyLEz7vNa0HZQ0YZxE 0b//hpdLDH6iIGzB8G+ag== Cc: xml-mime@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 13:28:02 -0000 On 2013-10-16 15:26, Henry S. Thompson wrote: > internet-drafts writes: > >> 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 : XML Media Types >> Author(s) : Henry S. Thompson >> Chris Lilley >> Filename : draft-ietf-appsawg-xml-mediatypes-03.txt >> Pages : 27 >> Date : 2013-10-16 >> >> Abstract: >> This specification standardizes three media types -- application/xml, >> application/xml-external-parsed-entity, and application/xml-dtd -- >> for use in exchanging network entities that are related to the >> Extensible Markup Language (XML) while defining text/xml and text/ >> xml-external-parsed-entity as aliases for the respective application/ >> types. This specification also standardizes the '+xml' suffix for >> naming media types outside of these five types when those media types >> represent XML MIME entities. >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-appsawg-xml-mediatypes >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-03 > > A thorough exposition of all comments received on the previous draft, > and their resolution, is available at > > http://www.w3.org/XML/2012/10/3023bis/02-comments.html > > Many thanks to the commentators, particularly Julian Reschke and Erik > Wilde, for careful reading and helpful input. > > An author-markup-based diff is available at > > http://www.w3.org/XML/2012/10/3023bis/draft-ietf-appsawg-xml-mediatypes-03_diff.html > > This is much easier to read than the IETF auto-generated one. > > Please note in particular that a significant addition has been made to > section 3.6 [1], to address the fact that the XML spec. itself defers > to this spec. to define the precedence of charset parameter, BOM and > XML encoding declaration. > > The key new paragraph reads: > > All processors SHOULD treat a BOM (Section 4) as authoritative if it > is present in an XML MIME entity. In the absence of a BOM (Section > 4), all processors SHOULD treat the charset parameter as > authoritative. Section 4.3.3 of the [XML] specification does _not_ > make it an error for the charset parameter and the XML encoding > declaration to be inconsistent. > > Comments on this section, and wider review, would be very welcome. > > ht > > [1] http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-03#section-3.6 I will probably have to re-read the new document to review what's left to do (please post a new draft early next week when ID submission re-opens). One thing I noticed is that we now have informative references to HTTPbis, and normative references to RFC 2616. It should be the other way round (so the normative refs should be updated for HTTPbis, and if they can't this might be a problem either in this spec or HTTPbis, in which case it needs to be reported ASAP due to IETF LC). Best regards, Julian From julian.reschke@gmx.de Mon Oct 28 07:00:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E065C11E8278 for ; Mon, 28 Oct 2013 07:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.397 X-Spam-Level: X-Spam-Status: No, score=-103.397 tagged_above=-999 required=5 tests=[AWL=-0.798, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZM3FC57JeA48 for ; Mon, 28 Oct 2013 07:00:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id BF13511E8143 for ; Mon, 28 Oct 2013 07:00:38 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LevUh-1W27tA05uR-00ql7S for ; Mon, 28 Oct 2013 15:00:23 +0100 Message-ID: <526E6DF4.4030509@gmx.de> Date: Mon, 28 Oct 2013 15:00:20 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: S Moonesamy , apps-discuss@ietf.org, draft-ietf-httpbis-p2-semantics.all@tools.ietf.org References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> In-Reply-To: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:UDjpqCIUpfTTTiBapTrX3MmBS8Qlp739FLuRGo5FW3lmQQYEH9y //y1eV4g5eT0oxlGYeAqRhNVxTkZ/sRCfqrg9F615nN7btpF1kfXC1/aYg+NBBD2B8xA1mk WA+ZpWfsyiM7eyfjsN+JHFwwAQKuacdGI/PX6/FhYKS64UL18ADcnbyx9v+6jeNej7kcsoo V5hpJJeHuKSXEugn59aaA== Cc: ietf@ietf.org, iesg@ietf.org, ietf-http-wg@w3.org Subject: [apps-discuss] obs-date, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 14:00:56 -0000 On 2013-10-28 09:07, S Moonesamy wrote: > ... > In Section 7.1.1: > > "The preferred format is a fixed-length and single-zone subset of > the date and time specification used by the Internet Message Format > [RFC5322]" > > The ABNF imports obs-date from RFC 5322. "GMT" is defined in "obs-zone" > (see RFC 5322). There is the following in the section: > > "For example, messages are occasionally forwarded over HTTP from a > non-HTTP source that might generate any of the date and time > specifications defined by the Internet Message Format." > > I listed this as a minor issue. I am not suggesting any change as "GMT" > is used in other header fields. I'll defer to the HTTPbis Working Group > as to whether there should be a note about "GMT" with an explanation > that although "GMT" is deprecated the use is widespread. > ... Actually, HTTPbis has its own obs-date: obs-date = rfc850-date / asctime-date So there doesn't seem to be an issue here. Best regards, Julian From julian.reschke@greenbytes.de Mon Oct 28 07:14:54 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3EB11E818C; Mon, 28 Oct 2013 07:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3jfRxiLuB8A; Mon, 28 Oct 2013 07:14:50 -0700 (PDT) Received: from central.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE6F11E8185; Mon, 28 Oct 2013 07:14:48 -0700 (PDT) Received: from [192.168.1.102] (unknown [217.91.35.233]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by central.greenbytes.de (Postfix) with ESMTPSA id 9F53510C0665; Mon, 28 Oct 2013 15:14:46 +0100 (CET) Message-ID: <526E7154.2070005@greenbytes.de> Date: Mon, 28 Oct 2013 15:14:44 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: S Moonesamy , apps-discuss@ietf.org, draft-ietf-httpbis-p2-semantics.all@tools.ietf.org References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> In-Reply-To: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: iesg@ietf.org, ietf-http-wg@w3.org, ietf@ietf.org Subject: [apps-discuss] IANA issues, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 14:14:54 -0000 On 2013-10-28 09:07, S Moonesamy wrote: > ... > Section 8.1 defines a HTTP Method Registry where registration requires > IETF Review. I took a quick look at Issue #364. Section 4.2 discusses > about common method properties, e.g. cacheable. The fields in Section > 8.1.1 does not include cacheable. > ... Yes -- this is not necessarily a problem. There are many things that need to be defined for a new method, and not all of these fit into the template. > There are considerations for new methods in Section 8.1.2. I gather > that the working group understands that someone will have to review the > specification and raise an issue if the considerations are not followed. Yes. > The table in Section 8.1.3 only mentions the section number. There is > an assumption that the specification text is in this draft. I suggest That's an assumption that is true for all "bare" Section references. > also adding a reference for the RFC number. As a note for the reader, > draft-ietf-httpbis-method-registrations-13 also registers some HTTP > methods. The IANA Considerations are processed by the RFC Editor and IANA, and they will make sure that the registry is properly populated. There's no point in mentioning a still unknown RFC # here. > The above assumption also applies to Section 8.2. I suggest updating > the existing registrations at > http://www.iana.org/assignments/http-status-codes/ so that the > HTTP Status Code Registry is compliant with Section 8.2.1. > ... What, precisely? > ... Best regards, Julian -- bytes GmbH, Hafenweg 16, D-48155 Mnster, Germany Amtsgericht Mnster: HRB5782 From julian.reschke@gmx.de Mon Oct 28 07:25:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A891811E8276 for ; Mon, 28 Oct 2013 07:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.502 X-Spam-Level: X-Spam-Status: No, score=-103.502 tagged_above=-999 required=5 tests=[AWL=-0.903, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aw5rMoAcexS for ; Mon, 28 Oct 2013 07:25:03 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 50A2F11E8306 for ; Mon, 28 Oct 2013 07:25:00 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M9KR0-1VO81c2bRW-00CjMZ for ; Mon, 28 Oct 2013 15:24:59 +0100 Message-ID: <526E73B8.90705@gmx.de> Date: Mon, 28 Oct 2013 15:24:56 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: John C Klensin , S Moonesamy , apps-discuss@ietf.org, draft-ietf-httpbis-p2-semantics.all@tools.ietf.org References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E6DF4.4030509@gmx.de> <751EE3ED19D0A62BD858585C@JcK-HP8200.jck.com> In-Reply-To: <751EE3ED19D0A62BD858585C@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:9nFOSrGxnApcdbMmAc0LcJJKTs0je8GHW8IUocVFezFc0x/uGzN 2LwdNC3UBlLbF/bDZ4YTdUsyvyLXN3JitiZuSCi/1iazjBLW2tG8dOGN9b+Fp82pkVMHsAG Q1y/JKXcxq36aPDrlJf3LQ0Z0i62Trz9t7/H63OT4mnsGUwPevvMOJbN+R3u41GkIUOWjfC xpQoBVJdEUglSzM7YjUCQ== Cc: ietf-http-wg@w3.org, ietf@ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] obs-date, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 14:25:10 -0000 On 2013-10-28 15:22, John C Klensin wrote: > --On Monday, October 28, 2013 15:00 +0100 Julian Reschke > wrote: > >> On 2013-10-28 09:07, S Moonesamy wrote: >>> ... >>> In Section 7.1.1: >>> >>> "The preferred format is a fixed-length and single-zone >>> subset of the date and time specification used by the >>> Internet Message Format [RFC5322]" >> ... >> Actually, HTTPbis has its own obs-date: >> >> obs-date = rfc850-date / asctime-date >> >> > ics-24.html#rfc.section.7.1.1.1> > > Julian, > > I've been reluctant to step into this mess, but, having had > another bad experience over the weekend, and with the > understanding that we already have multiple "obsolete" forms > floating around that implementations are supposed to recognize, > I'd like to see if it is still possible to think about moving to > an ISO-compatible "preferred form" that would eliminate the > difficulty in handling and ambiguities in month names (and the > frequent violations where they are made upper-case or translated > into local languages). Doing so, and getting rid of "GMT" > (which about half the world's population seems to think is a > synonym for whatever time is being used around Greenwich), in > favor of UT (which no one who has any understanding at all seems > to think might change in the summer), would save a lot of > problems long-term. That would make the preferred form > > [day-name ","] year "-" monthNumber "-" day SP time-of-day SP > "UT" > > with > monthNumber = 2DIGIT > > and > obs-date = rfc850-date / asctime-date / IMF-fixdate > if that is necessary. > > I don't care whether day-name is optional or not, but there > would be some small i18n charm in saying "either write it the > way the spec says or leave it out" rather than the current rule, > which is effectively "use those English-based abbreviations no > matter how obnoxious they are in your environment". > > It is obviously late to be suggesting this, but it was also late > a dozen years ago and will be a lot later five or ten years > hence. > ... John, that change would make almost every HTTP/1.1 code ever written non-compliant. And yes, it would have been nice if a same date format would have been chosen back then. Best regards, Julian From ned.freed@mrochek.com Mon Oct 28 07:49:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607C611E817A for ; Mon, 28 Oct 2013 07:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zB5-4+9-oi3 for ; Mon, 28 Oct 2013 07:49:27 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3CD11E817E for ; Mon, 28 Oct 2013 07:49:25 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P03YHKVUSW005UQ4@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 28 Oct 2013 07:44:23 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OZQXEDTQ3400004R@mauve.mrochek.com>; Mon, 28 Oct 2013 07:44:20 -0700 (PDT) Message-id: <01P03YHJCHLS00004R@mauve.mrochek.com> Date: Mon, 28 Oct 2013 07:28:49 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 28 Oct 2013 11:11:21 +0100" <526E3849.5000801@tana.it> References: <20131022182337.4789.qmail@joyce.lan> <01P00BXM2CJU00004R@mauve.mrochek.com> <526BAD7B.1000003@tana.it> <01P03FJ5YVMC00004R@mauve.mrochek.com> <526E3849.5000801@tana.it> To: Alessandro Vesely Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 14:49:32 -0000 > On Mon 28/Oct/2013 03:27:46 +0100 Ned Freed wrote: > >>> > >>> The SMTP extension turns out to be very easy to implement. The RRVS > >>> value is directly attached to the address, so there only two cases: > >>> > >>> (1) The address is local, in which case you check the information > >>> against the account if you have it. And throw the information > >>> away no matter what. > >>> > >>> (2) The address is nonlocal, in which case you attach the > >>> information to the address so it can be relayed. > > > >> I agree the extension looks easier than the header field. > >> However, the concept of "local" is not thoroughly clear. An MTA > >> can have both some sort of alias database and dot-forward > >> recipes. The latter can be scripts or other artifacts dealt with > >> by the local MDA only. So a message can be relayed even if it > >> looked local when it was accepted. > > > > But in both of the cases you cite, you have effectively validated > > the incoming address in terms of RRVS, breaking the RRVS chain. The > > entire point of having aliases and dot-forward files is to have a > > stable address that can be redirected in various ways. > > > > Of course nothing says that the forwarding address can't start a > > new RRVS chain by recording when forwarding to that particular was > > first set up. The only problem with that is going to be error > > reporting: Who do you report the problem to so whoever owns the > > forwarding address can update it? > Hm, I thought the whole purpose of saving the RRVS to the header was > to reinstate using it as a client in case it forwarded. Absolutely not! This is not now and never has been a mechanism intended for clients to be involved in. If the mechanism hasn't done it's job before the message is in the user's hands, it has failed. > You consider > it a MAY(?), while I thought it was meant to be a SHOULD. Perhaps, > the draft needs to clarify this point. I think you're seeing things that aren't there. I can't find a single reference in the draft anywhere to the recieving client being involved in any RRVS handling. You'd think that there would be some mention of it if the header was intended for that purpose. > For simple forwarding, rejection would trigger an NDN as usual. No? I assume you're talking about the case where the forwarder itself is using RRVS and the check fails. If so, then yes, a DSN will be sent, but the question is to where and to what purpose. If the forwarder didn't alter the envelope from then the DSN will go back to original sender, and if that sender happens to be one that knows how to deal with RRVS mail sending will be suspended or whatever. Which is a reasonable outcome, except that when the user notices the problem and goes to fix it it may be difficult for them to figure out what's wrong. But suppose the forwarder overrode the envelope from. This will likely have the effect of dropping the message on the floor. Not the greatest outcome, but there's really no other realistic alternative. > > In any case, unless there's some sort of special relationship > > between the forwarder and where it forwards to, the RRVS > > information should not carry through an alias, redirection, > > whatever. > You mean "SHOULD NOT"? It's already a SHOULD in the draft for every case that is described. Right now there is insufficient discussion of the RRVS extension, including discussing whether or not to carry the parameter through. > > The only wrinkle I see is that the old address does need to be > > notified of the change, and that notification has to operate using > > the old RRVS info. > Consider a sending server which stored the forwarding A->B after a 251 > reply. When it sends directly to B it uses RRVS with the date on > which it learned A->B. If the recipient subsequently changes A->B > into A->C, he or she should also set B->C or B->A. In that case, the > receiving server will have a dot-forward file with an st_mtime more > recent than the RRVS date used by the sending server. That does not > necessarily imply a change of ownership, but it might. > How about modifying the spec so as to have the receiving server reply > something different in the "unknown" cases? For example: > 251 Something changed; will possibly forward to I seriously doubt this is worth worrying about. Ned From julian.reschke@gmx.de Mon Oct 28 08:53:48 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0C011E81F8 for ; Mon, 28 Oct 2013 08:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.705 X-Spam-Level: X-Spam-Status: No, score=-103.705 tagged_above=-999 required=5 tests=[AWL=-1.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0xCfoIcnq05 for ; Mon, 28 Oct 2013 08:53:32 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEF811E8192 for ; Mon, 28 Oct 2013 08:53:32 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Mb31L-1VGoTJ38gN-00Kd8D for ; Mon, 28 Oct 2013 16:53:31 +0100 Message-ID: <526E8878.5030903@gmx.de> Date: Mon, 28 Oct 2013 16:53:28 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: S Moonesamy , apps-discuss@ietf.org, draft-ietf-httpbis-p1-messaging.all@tools.ietf.org, iesg@ietf.org References: <6.2.5.6.2.20131026225145.0bee7bb8@elandnews.com> In-Reply-To: <6.2.5.6.2.20131026225145.0bee7bb8@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Iyy4hEjTtKuZwmb9gGAuOcUf/ghlos/Cq/okQxKqyuG2nckqf5+ wF65B4rOZAEB4KOkDHZWPzrNaNNL7+HHRMirswndDsDzc0aiieW2YoH9y5xamTtSlvijUhF M/Kg52PttVikMs4BThhjt3fSQhD/7d6DK0TdftibDScbXJ/yXA8/N3W3ADwYWKVzpdDR1pv i9ZREtT28Tvc0ZrD+2atA== Cc: ietf-http-wg@w3.org, ietf@ietf.org Subject: [apps-discuss] Registration requirements for transfer codings, was: APPSDIR review of draft-ietf-httpbis-p1-messaging-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 15:53:48 -0000 On 2013-10-27 19:44, S Moonesamy wrote: > ... > The HTTP Transfer Coding namespace (Section 8.4) is currently "First > Come First Served". The new registration procedure required IETF > Review. What is the reason for the change? > ... My understanding is that we wanted to set a high bar because this really ought to happen with lots of care and review. The related ticket is , and it was discussed during IETF 75 (). Best regards, Julian From julian.reschke@gmx.de Mon Oct 28 09:07:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049AE11E814D for ; Mon, 28 Oct 2013 09:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.729 X-Spam-Level: X-Spam-Status: No, score=-103.729 tagged_above=-999 required=5 tests=[AWL=-1.130, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0HgV0Y-Pu4T for ; Mon, 28 Oct 2013 09:07:11 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 860A621E8094 for ; Mon, 28 Oct 2013 09:07:11 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MUkxk-1VBe3B0sJA-00YC9h for ; Mon, 28 Oct 2013 17:06:58 +0100 Message-ID: <526E8B9E.8030006@gmx.de> Date: Mon, 28 Oct 2013 17:06:54 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: S Moonesamy , apps-discuss@ietf.org, draft-ietf-httpbis-p2-semantics.all@tools.ietf.org References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> In-Reply-To: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Eb6pzQFNlXxKcEgy5IkTCjWMbyLXwkbvGIe2qWvaJ/9DjNl7VZs M9L0yBkxVq9GOucqJuylxvhsj1gU1nWGC7/yE6oCWVLcewltnYAE6lrv8A2pZMLzhy17y4m hayKOTBxhkkvhAHPlHQXUPlJUFsdUDsoJGV23Kv6FPiloLLFZUNAsqAl21Yj7Pcstr0706i ygc6HBZxguq7O5xsUcC0g== Cc: ietf@ietf.org, iesg@ietf.org, ietf-http-wg@w3.org Subject: [apps-discuss] content inspection in absence of media type, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 16:07:18 -0000 On 2013-10-28 09:07, S Moonesamy wrote: > ... > Major Issues: > > In Section 3.1.1.5: > > 'If a Content-Type header field is not present, the recipient MAY > either assume a media type of "application/octet-stream" ([RFC2046], > Section 4.5.1) or examine the data to determine its type.' > > According to RFC 2046, the "octet-stream" subtype is used to indicate > that a body contains arbitrary data. The RFC 2119 "may" leaves it to > the implementor to make an assumption. I suggest turning this into a > recommendation so that the assumption is clear to the implementor. > There is a discussion of MIME sniffing in > draft-ietf-websec-mime-sniff-03. There has been discussion about MIME (which expired ~2 years ago) > or Content sniffing over the years. I am aware that some browsers do > MIME sniffing. I understand that it is sometimes needed to make the Web > work. However, it can lead to security vulnerabilities. The paragraph > which follows the one quoted above discusses about that. I listed this > as a major issue for the attention of the Applications Area Directors. > ... Could you clarify what exactly the issue is? RFC 2616 said (): > Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream". ...which isn't that different. Best regards, Julian From stephen.farrell@cs.tcd.ie Mon Oct 28 09:16:15 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606EC11E8282 for ; Mon, 28 Oct 2013 09:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6gHdfwFMpJb for ; Mon, 28 Oct 2013 09:16:10 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 87A8711E827B for ; Mon, 28 Oct 2013 09:16:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3CE2DBEE7; Mon, 28 Oct 2013 16:16:09 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VqUEdDrXPQH; Mon, 28 Oct 2013 16:16:07 +0000 (GMT) Received: from [10.87.48.9] (unknown [86.42.16.82]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5F04EBEDC; Mon, 28 Oct 2013 16:16:07 +0000 (GMT) Message-ID: <526E8DC7.3050204@cs.tcd.ie> Date: Mon, 28 Oct 2013 16:16:07 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Melvin Carvalho References: <526D2719.10003@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: =?ISO-8859-1?Q?B=F6rje_Ohlman?= , Apps Discuss Subject: Re: [apps-discuss] RFC 6920 ni: URIs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 16:16:15 -0000 On 10/27/2013 07:22 PM, Melvin Carvalho wrote: > On 27 October 2013 15:45, Stephen Farrell wrote: > >> >> Hiya, >> >> On 10/26/2013 11:21 PM, Melvin Carvalho wrote: >>> I was wondering if RFC 6920 has any deployments currently? >> >> I'm not aware of deployments. There is code [1] that's >> been used in various ICN experiments, and there'll be >> a demo of a FF browser with ni support in Vancouver at >> the ICNRG session on Sunday, that demo's not mine, so >> not sure if its using the netinf code or not, I've cc'd >> Brje who, being an ICNRG chair, knows more. >> >>> http://tools.ietf.org/html/rfc6920 >>> >>> I was thinking about reusing this, or doing something very similar in the >>> field of virtual currencies on the web and it would be good to see some >>> real world examples >>> >>> RFC6920 seems to have everything we need, but in cryto currencies people >>> are used to dealing with base16 encoded, rather than, base64, so it would >>> be good to understand how this works in practice... >> >> In the coding/testing we've done, base64 hasn't been an >> issue at all. >> > > Thanks, I'm going to try and deploy some of these then (small scale) > > The encoding wasnt too bad after working out the +/ becomes -_ > > The thing is the community I work with will probably not consider 64 bit > encodings "correct" but I guess there's no way to do 16bit right now > without making a new spec, which seems overkill ... Cool. Be interested in how you get on. If changing our current code in some way made it more useful for you then happy to chat about that. (Though the URI handling is easy enough so I'm guessing you'll end up with your own code for that.) S. > > >> >> Cheers, >> S. >> >> [1] http://sourceforge.net/projects/netinf/ >> >> >>> >>> >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> >> > From wmills@yahoo-inc.com Mon Oct 28 09:21:37 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA7D11E8192 for ; Mon, 28 Oct 2013 09:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.998 X-Spam-Level: X-Spam-Status: No, score=-14.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txi7xxM-CGTM for ; Mon, 28 Oct 2013 09:21:32 -0700 (PDT) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by ietfa.amsl.com (Postfix) with ESMTP id 996E821E80AB for ; Mon, 28 Oct 2013 09:21:31 -0700 (PDT) Received: from GQ1-EX10-CAHT17.y.corp.yahoo.com (gq1-ex10-caht17.corp.gq1.yahoo.com [10.73.119.198]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r9SGL6FZ081214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 28 Oct 2013 09:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1382977268; bh=KGvuQgZSet9T9UJMakCrV1pUEnJp3X728kbdWUxjQoo=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=ply5S/yoPRLOaZD0U+Rjv6OJyDad/K9gA/WgRpg27hOzeTzGnYOdM0+CmwaiCRWVY krYphqPsWuiHpbA9tRpvvzgLQ0hvoM3KCkjXUyOWcpbWGJRiEhv8F6qhOixyH6U8Pn ccL1aLOZItM4oALr/SCooCsxegbz5SPw8BMBK+mw= Received: from omp1009.mail.ne1.yahoo.com (98.138.87.9) by GQ1-EX10-CAHT17.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 28 Oct 2013 09:21:06 -0700 Received: (qmail 91869 invoked by uid 1000); 28 Oct 2013 16:21:04 -0000 Received: (qmail 45049 invoked by uid 60001); 28 Oct 2013 16:21:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1382977264; bh=1OIHCh/PK67J36nZ+72uVPLt3fMTxT+C4U2YgXPv4Jw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ATlanbMJJvV4xKvLXSDP8mX8MPtJX3tEYfS4DL33gXyXUwxny7C8T9pqJC57SMNfV1uCZXMsjNspFgpeWejCGiMGT13H1OTlnIBhlJCH+cCjP/XastOmSb2/NhIS6XcdZ77/mnDMbh0ayDjE2i7sp4arT40kUWeKypad9UEkTm0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Aqw8PhOzpB7OmTSaFa+DY6kYkiJ73KMhduvCL9IDZ2QaMH+Ams6D7ilSk0cPiWURMUQ0phVDY8Ei1LNVC9OH39vjaXAZlK8CeNuqY//A1C0mbIImCSoowja4zFbpIJlkYwmUb4V6xp0O+Zwe1K6aKcOO6MHaz3ZcGRI8yAe+iu8=; X-YMail-OSG: u2UtU4MVM1nUdw6MWx5jngOyQu0Wd8Q2S3Hvjy8pFdkc56s vANKiOKZ9aDfU4LnDTOTzjdv_naKNCxj19xU_LvRSvXJ4c5dOG1HcNApPA7e vXLlZg7PIN2ZXglIgOYQhcK2JB6vbfo3GUs2zF0Wq3obk.ZBb3USapEKVRBH y9dmg7IV_i5aK.dUihbMWBXe2sFGUj_H_Up45QkBQ.j6XH4SCdqCYRguN6Tj UBclqxgRvz3r9ALKv1GfYRQhxn43Zp3dpjQeK2aoGsyIfuD6Dcd0zj1_TlBG yJUfvVPHlPcOqHQ2Y0XpRGJui8SpcmsJQRyQ- Received: from [209.131.62.115] by web125601.mail.ne1.yahoo.com via HTTP; Mon, 28 Oct 2013 09:21:04 PDT X-Rocket-MIMEInfo: 002.001, QW0gSSByaWdodCB0aGF0IHRoZSBTTVRQIGV4dGVuc2lvbiBpcyBhIG9uZS10aW1lIHRoaW5nLCBhbmQgbm8gc3RhdGUgaXMgY2FycmllZCB0aHJvdWdoIHdpdGggdGhlIG1lc3NhZ2UgaXRzZWxmPwoKSG93IGRvZXMgdGhpcyBlbnN1cmUgdGhhdCB0aGUgUlJWUyBjaGVjayBwYXNzZXMgYWxsIHRoZSB3YXkgdGhyb3VnaCB0byB0aGUgYXV0aG9yaXRhdGl2ZSBNWD_CoCBJZiB5b3UncmUgcGFzc2luZyB0aHJvdWdoIGEgY2hhaW4gb2YgTVggYm94ZXMgdGhlbiB0aGUgd2hvbGUgY2hhaW4gaGFzIHRvIHN1cHBvcnQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131022182337.4789.qmail@joyce.lan> <01P00BXM2CJU00004R@mauve.mrochek.com> <526BAD7B.1000003@tana.it> <01P03FJ5YVMC00004R@mauve.mrochek.com> <526E3849.5000801@tana.it> <01P03YHJCHLS00004R@mauve.mrochek.com> Message-ID: <1382977264.41169.YahooMailNeo@web125601.mail.ne1.yahoo.com> Date: Mon, 28 Oct 2013 09:21:04 -0700 From: Bill Mills To: Ned Freed , Alessandro Vesely In-Reply-To: <01P03YHJCHLS00004R@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1981468715-2045816953-1382977264=:41169" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 977268001 Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] SMTP extension Re: I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 16:21:37 -0000 ---1981468715-2045816953-1382977264=:41169 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am I right that the SMTP extension is a one-time thing, and no state is car= ried through with the message itself?=0A=0AHow does this ensure that the RR= VS check passes all the way through to the authoritative MX?=A0 If you're p= assing through a chain of MX boxes then the whole chain has to support the = extension?=0A=0A=0A=0A-bill=0A=0A=0A=0A--------------------------------=0AW= illiam J. Mills=0A"Paranoid" Yahoo! ---1981468715-2045816953-1382977264=:41169 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Am I right that the SMTP extension is a one-time thing, and no state is c= arried through with the message itself?

How does this ensure that the RRVS ch= eck passes all the way through to the authoritative MX?  If you= 're passing through a chain of MX boxes then the whole chain has to support= the extension?


-bill


--------------------------------
William J. Mills
"Paranoid" Yah= oo!



---1981468715-2045816953-1382977264=:41169-- From prvs=0006ef84c5=johnl@iecc.com Mon Oct 28 09:36:14 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEA711E8187 for ; Mon, 28 Oct 2013 09:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z17lsFipJsv3 for ; Mon, 28 Oct 2013 09:36:10 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFF511E8182 for ; Mon, 28 Oct 2013 09:36:09 -0700 (PDT) Received: (qmail 76499 invoked from network); 28 Oct 2013 16:36:08 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 28 Oct 2013 16:36:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=526e9278.xn--9vv.k1310; i=johnl@user.iecc.com; bh=2SDjItDf7xzlWzXHLlJatByiejofY9pTmh9K35nTMv8=; b=GZ+EaCY6CrixTyIwX7hq4bw5T9judk4d6Ldjbzlm9OmmS6VVK0c90lM4UXRvYW7B9yQpTNFs6yJaRjD/9bo+AoflR1Ktb3iDOVN9E9GvkNoQq1JyRGuFpzTiCmaFTvEJk4/OTnSWuEGtwoyvsvkjIjAuqVSj3Ck/ym8rM8z5SNCS9yKvzOnXoPfCg1VLS12HuwwCbya70q+a42NRkuBQlOUciSI1SgKfO8gKNhSHyb78mUVuEV2bY1/5UcTDmXsE DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=526e9278.xn--9vv.k1310; olt=johnl@user.iecc.com; bh=2SDjItDf7xzlWzXHLlJatByiejofY9pTmh9K35nTMv8=; b=gg7ASzxt07aS/ThsQOl7cEoR4teFCOMF+R3I+1iYKFnAMAmMPOoLgCrcHCmvtgvZF7ASh+G5kLFV+WZRqLMAu6LGhjnGolG16Xl/jyaMFenYyYyEbtThFC/U+Et6UZP2IzUzTc4M1cPZ0Xydn56P5gdGfuDFznX4Z0mJBAGIP/jNreuveO1g0Arocv1f1+Dwf3cliQk4t1fR46Cc51EO4vxKymxFf0IlFeXBV0mW/t4bf+3KB3DsES+D0BQKnQBQ Date: 28 Oct 2013 16:35:46 -0000 Message-ID: <20131028163546.8393.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <526E3849.5000801@tana.it> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: vesely@tana.it Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 16:36:14 -0000 >Hm, I thought the whole purpose of saving the RRVS to the header was >to reinstate using it as a client in case it forwarded. I think we may be confusing relays and forwards here. First case: I send a mail to foo@example.com. The MX for example.com is just a gateway, and it relays the mail to another locally determined host, still addressed to foo@example.com. Second case: I send a mail to foo@example.com. The MX for example.com decides to forward it to bar@example.net, so it sends it using the address bar@example.net, to the MX for example.net. In the first relay case, it makes sense to preserve the RRVS info. In the second forward case it does not. An extra complication that Ned mentioned is that in the second case, the forwarder might want to add new RRVS info noting the time that the forward to bar was set up. R's, John From prvs=0006ef84c5=johnl@iecc.com Mon Oct 28 09:39:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE9E21F9CFB for ; Mon, 28 Oct 2013 09:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HTOoZxSubXl for ; Mon, 28 Oct 2013 09:38:58 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id DC12321F9E89 for ; Mon, 28 Oct 2013 09:38:57 -0700 (PDT) Received: (qmail 76914 invoked from network); 28 Oct 2013 16:38:57 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 28 Oct 2013 16:38:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=526e9321.xn--30v786c.k1310; i=johnl@user.iecc.com; bh=Hr4Aj5W52wxoYGKHWedW8yGsVhwstFgOaQDgfEkSwAw=; b=YVTBWYd6Mf06TGj4IB7O0zKgqT+UqE1xbEvLu9f1y/rHdSMCX5OFRGUZjsvZZTEfGx648FcmPIcJf8YHSjMLP3Jy1uK6xc5/670pqc/f1povmVYbPpFAytWQM4ZDzZKlGXBoCaE8avAgbIIuRpzhUTqUA+Ddzav0UKicrq7oZ4pZ5y/zldKLKs7WFLJV4yRJh6NARFst9Yz+HP8PdlDuRy110yicEHlLDbPX9+xJiyBGeAWuXRcbFfSA0a2+LgfT DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=526e9321.xn--30v786c.k1310; olt=johnl@user.iecc.com; bh=Hr4Aj5W52wxoYGKHWedW8yGsVhwstFgOaQDgfEkSwAw=; b=mcYmpFCFKCbxoKoZ51mlyDn6MwcyzrLRpJMjqJZ7wEGgX1SpomYZQ3sMwTFt+L/YYzRIN3mLI/GVoTkO1OJ3zTSMS3jEqtBNQJ+Qaa46GE7o75upJGuRuRCtkaPeggyq28QScd17O/CMh9qfn23Dzt0rmdT6Wjr8yByl9xWtbsG5B2KuPOd1FdMY3TPrFFseXRjFSVHV2MbvCHFAfA9iY0OC+uDByNIthxUCmU5gyu6yQjH2n4srVgE834PboTe8 Date: 28 Oct 2013 16:38:35 -0000 Message-ID: <20131028163835.8415.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <1382977264.41169.YahooMailNeo@web125601.mail.ne1.yahoo.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] SMTP extension for draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 16:39:02 -0000 >Am I right that the SMTP extension is a one-time thing, and no state >is carried through with the message itself? Maybe. If the message is delivered through gateways that don't rewrite the address, it's possible that the host that knows the creation date of the address will be a few hops down. A plausible scenario would be a spam filtering proxy like the ones provided by Symantec and Tucows. From ned.freed@mrochek.com Mon Oct 28 11:12:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1269611E8290 for ; Mon, 28 Oct 2013 11:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYgHfSDwFESb for ; Mon, 28 Oct 2013 11:12:38 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id EAE0A11E8155 for ; Mon, 28 Oct 2013 11:12:37 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P045KHUSXS0072U6@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 28 Oct 2013 11:07:33 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OZQXEDTQ3400004R@mauve.mrochek.com>; Mon, 28 Oct 2013 11:07:30 -0700 (PDT) Message-id: <01P045KGGNH200004R@mauve.mrochek.com> Date: Mon, 28 Oct 2013 10:59:06 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 28 Oct 2013 09:21:04 -0700" <1382977264.41169.YahooMailNeo@web125601.mail.ne1.yahoo.com> References: <20131022182337.4789.qmail@joyce.lan> <01P00BXM2CJU00004R@mauve.mrochek.com> <526BAD7B.1000003@tana.it> <01P03FJ5YVMC00004R@mauve.mrochek.com> <526E3849.5000801@tana.it> <01P03YHJCHLS00004R@mauve.mrochek.com> <1382977264.41169.YahooMailNeo@web125601.mail.ne1.yahoo.com> To: Bill Mills Cc: Ned Freed , "apps-discuss@ietf.org" , Alessandro Vesely Subject: Re: [apps-discuss] SMTP extension Re: I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 18:12:43 -0000 > Am I right that the SMTP extension is a one-time thing, and no state is > carried through with the message itself? No, that's incorrect, and it's something the draft needs to cover. An MTA operating as a front-end proxy without full knowledge of account ownership should pass the information along. I implemented this as a matter of course and accounted for it in my previous notes about implementation difficulty. > How does this ensure that the RRVS check passes all the way through to the > authoritative MX? If you're passing through a chain of MX boxes then the whole > chain has to support the extension? I'll again note that the issues faced by forwards operating outside the administative domain are formidable. RRVS is at best a tiny part of this. But absent any interest in working on a solution, I see no reason for RRVS to wade into this morass. It should simply note this as an issue and move on. Ned P.S. Anyone who thinks there aren't problems in this area really should try operating a secondary MX for someone. Doesn't need to be a big site, doesn't need to handle a lot of traffic, doesn't have to involve RRVS, it's still a PITA. From ned.freed@mrochek.com Mon Oct 28 11:12:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA39E11E8155 for ; Mon, 28 Oct 2013 11:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCeZFWhtTIjQ for ; Mon, 28 Oct 2013 11:12:38 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id A7D7C11E828D for ; Mon, 28 Oct 2013 11:12:38 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P045LL7Z800072U6@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 28 Oct 2013 11:08:26 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OZQXEDTQ3400004R@mauve.mrochek.com>; Mon, 28 Oct 2013 11:08:23 -0700 (PDT) Message-id: <01P045LJYXEU00004R@mauve.mrochek.com> Date: Mon, 28 Oct 2013 11:08:13 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 28 Oct 2013 16:35:46 +0000" <20131028163546.8393.qmail@joyce.lan> References: <526E3849.5000801@tana.it> <20131028163546.8393.qmail@joyce.lan> To: John Levine Cc: apps-discuss@ietf.org, vesely@tana.it Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 18:12:43 -0000 > >Hm, I thought the whole purpose of saving the RRVS to the header was > >to reinstate using it as a client in case it forwarded. > I think we may be confusing relays and forwards here. > First case: I send a mail to foo@example.com. The MX for example.com > is just a gateway, and it relays the mail to another locally > determined host, still addressed to foo@example.com. > Second case: I send a mail to foo@example.com. The MX for example.com > decides to forward it to bar@example.net, so it sends it using the > address bar@example.net, to the MX for example.net. > In the first relay case, it makes sense to preserve the RRVS info. In > the second forward case it does not. An extra complication that Ned > mentioned is that in the second case, the forwarder might want to add > new RRVS info noting the time that the forward to bar was set up. Nice summary! Ned From mnot@mnot.net Mon Oct 28 22:48:31 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E7C11E812A for ; Mon, 28 Oct 2013 22:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.922 X-Spam-Level: X-Spam-Status: No, score=-104.922 tagged_above=-999 required=5 tests=[AWL=-2.323, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pi7blJx-nKMO for ; Mon, 28 Oct 2013 22:48:27 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1C911E8211 for ; Mon, 28 Oct 2013 22:48:24 -0700 (PDT) Received: from [192.168.1.64] (unknown [118.209.167.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0B7C222E1F4; Tue, 29 Oct 2013 01:48:04 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Mark Nottingham In-Reply-To: Date: Tue, 29 Oct 2013 16:48:00 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: James M Snell X-Mailer: Apple Mail (2.1510) Cc: "ietf-http-wg@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 05:48:31 -0000 On 24/09/2013, at 5:17 AM, James M Snell wrote: > Just a general FYI... I have submitted iteration -04 of the > LINK/UNLINK draft with a few minor editorial fixes... and, I have > formally requested Last Call status as an Independent Submission on > the Standards Track. >=20 > http://tools.ietf.org/html/draft-snell-link-method-04 In Section 2 of -05: "For any pair of resources, exactly one relationship of any given type = can exist." That's a new and apparently backwards-incompatible change to the model = of linking on the Web... e.g., consider "stylesheet". Also, can these methods be made conditional? Cheers, -- Mark Nottingham http://www.mnot.net/ From jasnell@gmail.com Mon Oct 28 22:59:45 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6611811E80FC for ; Mon, 28 Oct 2013 22:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNw44c83Gfh9 for ; Mon, 28 Oct 2013 22:59:44 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 766C511E81C1 for ; Mon, 28 Oct 2013 22:59:44 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id i13so2690370qae.9 for ; Mon, 28 Oct 2013 22:59:41 -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=i/vuYb8sVnRjFL5V6bjbJ9ENTuzj1ztL/bC8MqCtaIM=; b=YinDDVS+9AAxMB/T1a0d6ow5JSK7nk5HAtXYex1OZcqVBJd0W44f0EArcxO1lapi07 tPinf5Yh1bhW5cL3MZ+wJ/a6hH4sNL+F1IQpY1wN4/0iu7q4Xz4TWGZhMB4mjNc5Ej3R SofzslJxPPDwWwzc5vKnuOwsqISZ8zP7g3Sm+vSJXTyfU5wcPGcukCBAwLEY8rYv5ov0 b6TT6hAwFXQwktoZ/MW57c2ZswsAlZHMA6uCyoGqO+giQn18Bdxn3Uh8YwYX+GNJNVxf 62Yxsok7b0xViz111bVDCm7CIKbBCPY9xPotjbOWx8stGp7VokZOQyzCLjuGwGUk7ow/ i0vA== MIME-Version: 1.0 X-Received: by 10.49.62.137 with SMTP id y9mr33289110qer.59.1383026381072; Mon, 28 Oct 2013 22:59:41 -0700 (PDT) Received: by 10.49.61.101 with HTTP; Mon, 28 Oct 2013 22:59:40 -0700 (PDT) Received: by 10.49.61.101 with HTTP; Mon, 28 Oct 2013 22:59:40 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Oct 2013 22:59:40 -0700 Message-ID: From: James M Snell To: Mark Nottingham Content-Type: multipart/alternative; boundary=047d7bdc0b3c28afd504e9daec61 Cc: ietf-http-wg@w3.org, IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 05:59:45 -0000 --047d7bdc0b3c28afd504e9daec61 Content-Type: text/plain; charset=UTF-8 On Oct 28, 2013 10:48 PM, "Mark Nottingham" wrote: > > > On 24/09/2013, at 5:17 AM, James M Snell wrote: > > > Just a general FYI... I have submitted iteration -04 of the > > LINK/UNLINK draft with a few minor editorial fixes... and, I have > > formally requested Last Call status as an Independent Submission on > > the Standards Track. > > > > http://tools.ietf.org/html/draft-snell-link-method-04 > > In Section 2 of -05: > > "For any pair of resources, exactly one relationship of any given type can exist." > > That's a new and apparently backwards-incompatible change to the model of linking on the Web... e.g., consider "stylesheet". > No, read it again, as a uniqueness constraint on the tuple (resource, link relation, resource). That's not new or novel. > Also, can these methods be made conditional? > Yes. Of course. > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > > --047d7bdc0b3c28afd504e9daec61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 28, 2013 10:48 PM, "Mark Nottingham" <mnot@mnot.net> wrote:
>
>
> On 24/09/2013, at 5:17 AM, James M Snell <jasnell@gmail.com> wrote:
>
> > Just a general FYI... I have submitted iteration -04 of the
> > LINK/UNLINK draft with a few minor editorial fixes... and, I have=
> > formally requested Last Call status as an Independent Submission = on
> > the Standards Track.
> >
> > =C2=A0http://tools.ietf.org/html/draft-snell-link-method-04
>
> In Section 2 of -05:
>
> "For any pair of resources, exactly one relationship of any given= type can exist."
>
> That's a new and apparently backwards-incompatible change to the m= odel of linking on the Web... e.g., consider "stylesheet".
>

No, read it again, as a uniqueness constraint on the tuple (= resource, link relation, resource). That's not new or novel.

> Also, can these methods be made conditional?
>

Yes. Of course.

> Cheers,
>
> --
> Mark Nottingham =C2=A0 http://www.mno= t.net/
>
>
>

--047d7bdc0b3c28afd504e9daec61-- From mnot@mnot.net Mon Oct 28 23:01:40 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E7411E8211 for ; Mon, 28 Oct 2013 23:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.893 X-Spam-Level: X-Spam-Status: No, score=-104.893 tagged_above=-999 required=5 tests=[AWL=-2.294, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdNDsB-bF4Mt for ; Mon, 28 Oct 2013 23:01:36 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE1011E81C1 for ; Mon, 28 Oct 2013 23:01:36 -0700 (PDT) Received: from [192.168.1.64] (unknown [118.209.167.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D0D0722E1F3; Tue, 29 Oct 2013 02:01:34 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Mark Nottingham In-Reply-To: Date: Tue, 29 Oct 2013 17:01:30 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: James M Snell X-Mailer: Apple Mail (2.1510) Cc: ietf-http-wg@w3.org, IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 06:01:41 -0000 On 29/10/2013, at 4:59 PM, James M Snell wrote: >=20 > On Oct 28, 2013 10:48 PM, "Mark Nottingham" wrote: > > > > > > On 24/09/2013, at 5:17 AM, James M Snell wrote: > > > > > Just a general FYI... I have submitted iteration -04 of the > > > LINK/UNLINK draft with a few minor editorial fixes... and, I have > > > formally requested Last Call status as an Independent Submission = on > > > the Standards Track. > > > > > > http://tools.ietf.org/html/draft-snell-link-method-04 > > > > In Section 2 of -05: > > > > "For any pair of resources, exactly one relationship of any given = type can exist." > > > > That's a new and apparently backwards-incompatible change to the = model of linking on the Web... e.g., consider "stylesheet". > > >=20 > No, read it again, as a uniqueness constraint on the tuple (resource, = link relation, resource). That's not new or novel.=20 Right. Thanks :) > > Also, can these methods be made conditional? > > >=20 > Yes. Of course. Mention it in the text, then; it's not automatic. Examples would be good = too. Cheers, -- Mark Nottingham http://www.mnot.net/ From jasnell@gmail.com Mon Oct 28 23:03:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04EF621E80D2 for ; Mon, 28 Oct 2013 23:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHw8KF6tL8V6 for ; Mon, 28 Oct 2013 23:03:19 -0700 (PDT) Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 567CF11E81C1 for ; Mon, 28 Oct 2013 23:03:19 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id 1so4702493qec.13 for ; Mon, 28 Oct 2013 23:03:17 -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=Kna7lm9D0z2Two3WE6B2ypdlKm9Abissa511D82zsxM=; b=Mtm/FTOhp2ZCg/RMQGTUUz4bY8FU3nUubwKs6jNe67W3CQjoP/DiIl0Er8o08WHEMo gZfRGsL5ldQDP4ZTJs9Nm+MboqT/RwQfh2GeDQrFRHKcojKFMZGRH2oc+qRpm01OihFV Wg6qam1T6PjIZzb8tkv/9m0XBLF9gicB4xmG7OypHlhNPi2BLofOUIKy41f9tkHYagnZ M9rGsrMIbC11ycyYaLZhJH1yk3HVnDPUziVCh1l6S3mP7ZMb9YJjJpFsRuhoUYGodCu3 WyJyQG+Acn0/o4Zfhj+VGbn7V1Y2a2KqF43Ju0cgLYDCYDSh3MzNsuo5xzfKoWip4JPA Nccg== MIME-Version: 1.0 X-Received: by 10.229.172.3 with SMTP id j3mr31259926qcz.10.1383026597474; Mon, 28 Oct 2013 23:03:17 -0700 (PDT) Received: by 10.49.61.101 with HTTP; Mon, 28 Oct 2013 23:03:17 -0700 (PDT) Received: by 10.49.61.101 with HTTP; Mon, 28 Oct 2013 23:03:17 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Oct 2013 23:03:17 -0700 Message-ID: From: James M Snell To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a11c300ea0eb9a204e9daf9e8 Cc: ietf-http-wg@w3.org, IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 06:03:20 -0000 --001a11c300ea0eb9a204e9daf9e8 Content-Type: text/plain; charset=UTF-8 Good idea :) will do. On Oct 28, 2013 11:01 PM, "Mark Nottingham" wrote: > > On 29/10/2013, at 4:59 PM, James M Snell wrote: > > > > > On Oct 28, 2013 10:48 PM, "Mark Nottingham" wrote: > > > > > > > > > On 24/09/2013, at 5:17 AM, James M Snell wrote: > > > > > > > Just a general FYI... I have submitted iteration -04 of the > > > > LINK/UNLINK draft with a few minor editorial fixes... and, I have > > > > formally requested Last Call status as an Independent Submission on > > > > the Standards Track. > > > > > > > > http://tools.ietf.org/html/draft-snell-link-method-04 > > > > > > In Section 2 of -05: > > > > > > "For any pair of resources, exactly one relationship of any given type > can exist." > > > > > > That's a new and apparently backwards-incompatible change to the model > of linking on the Web... e.g., consider "stylesheet". > > > > > > > No, read it again, as a uniqueness constraint on the tuple (resource, > link relation, resource). That's not new or novel. > > Right. Thanks :) > > > > Also, can these methods be made conditional? > > > > > > > Yes. Of course. > > Mention it in the text, then; it's not automatic. Examples would be good > too. > > Cheers, > > > -- > Mark Nottingham http://www.mnot.net/ > > > > --001a11c300ea0eb9a204e9daf9e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Good idea :) will do.

On Oct 28, 2013 11:01 PM, "Mark Nottingham&= quot; <mnot@mnot.net> wrote:

On 29/10/2013, at 4:59 PM, James M Snell <jasnell@gmail.com> wrote:

>
> On Oct 28, 2013 10:48 PM, "Mark Nottingham" <mnot@mnot.net> wrote:
> >
> >
> > On 24/09/2013, at 5:17 AM, James M Snell <jasnell@gmail.com> wrote:
> >
> > > Just a general FYI... I have submitted iteration -04 of the<= br> > > > LINK/UNLINK draft with a few minor editorial fixes... and, I= have
> > > formally requested Last Call status as an Independent Submis= sion on
> > > the Standards Track.
> > >
> > > =C2=A0http://tools.ietf.org/html/draft-snell-link-m= ethod-04
> >
> > In Section 2 of -05:
> >
> > "For any pair of resources, exactly one relationship of any = given type can exist."
> >
> > That's a new and apparently backwards-incompatible change to = the model of linking on the Web... e.g., consider "stylesheet". > >
>
> No, read it again, as a uniqueness constraint on the tuple (resource, = link relation, resource). That's not new or novel.

Right. Thanks :)

> > Also, can these methods be made conditional?
> >
>
> Yes. Of course.

Mention it in the text, then; it's not automatic. Examples would be goo= d too.

Cheers,


--
Mark Nottingham =C2=A0 h= ttp://www.mnot.net/



--001a11c300ea0eb9a204e9daf9e8-- From sm@elandsys.com Tue Oct 29 01:14:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D8821E80E8; Tue, 29 Oct 2013 01:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.787 X-Spam-Level: X-Spam-Status: No, score=-101.787 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcw6fCsYsUDy; Tue, 29 Oct 2013 01:14:02 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D106E21E80E3; Tue, 29 Oct 2013 01:13:59 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.158.76]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9T8DiNJ027720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 01:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383034438; bh=6KdK3rpcs8xdhcnxt+PY1yyGglmuACeGuHczbpk1isE=; h=Date:To:From:Subject:Cc; b=pYM7aPD0/MEPUMyPxsU75C29/mmo3k+HSsbzFUbgZmeqrwK8K52ipBOelSR6pAuDt 33Wuv93dgns8gFEUQ+14NkS0OUeNQqGdnFENg/uw05SMew5QaBRZM6Hn5bYO+1mL7z YM0sBYAXbQ2iFcjzFcctADjy1oPPxCcvEV0hUa4o= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1383034438; i=@elandsys.com; bh=6KdK3rpcs8xdhcnxt+PY1yyGglmuACeGuHczbpk1isE=; h=Date:To:From:Subject:Cc; b=x/kcJg7ydD5/LxJXogNoulYrTEgiurksFh0YHXTO2TeQSRd6JYK4mKjEcV1Gkwx+b Yye7Hi2YBShiQ63U4YbKNOdhqMjdyfxAbo3smo1tqfpwS1RQ3OcucVg5V3MJN0rUqm 4fxFshtgOjLTDSB2f6R2u2y8+6CQ3nB/mzggIOG0= Message-Id: <6.2.5.6.2.20131028082531.0ddd0810@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 28 Oct 2013 10:10:30 -0700 To: apps-discuss@ietf.org, draft-ietf-httpbis-p4-conditional.all@tools.ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: iesg@ietf.org, ietf-http-wg@w3.org, ietf@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-httpbis-p4-conditional-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 08:14:03 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-httpbis-p4-conditional-24 Title: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests Reviewer: S. Moonesamy Review Date: October 28, 2013 IETF Last Call Date: October 21, 2013 Summary: This draft is almost ready for publication as a Proposed Standard. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false. The document is well-written and clear. Major Issues: In Section 2.2: Last-Modified = HTTP-date There is a note about the imported ABNF in Appendix B. I suggest moving that text to Section 1.2 so that the text is part of the specification. Minor Issues: I will comment about the IANA Considerations section in a separate message. Nits: Editorial comments were not included in the review. Regards, S. Moonesamy From sm@elandsys.com Tue Oct 29 01:14:17 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE3121E80FB; Tue, 29 Oct 2013 01:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.779 X-Spam-Level: X-Spam-Status: No, score=-101.779 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpVzzguiNa56; Tue, 29 Oct 2013 01:14:16 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 296E221E80E6; Tue, 29 Oct 2013 01:14:04 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.158.76]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9T8DiNL027720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 01:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383034443; bh=FuN3oWHkH3mXWXWvN78EMK2XYiaeFjCbWsX8+9AeOWM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=4AgwH5Isfq6e4odAmWCp7KgHZp3kYFWSY+uZQPQsJZ49Q6a4l0f87BqSoN3fRzW72 wyVcfJtK5IGReZVV2OypYcEXX7wHp5c/Ggm9v2dYbl6w4igSyqjLphI/XcPyNc2h01 FmzyzqA2upfthSIPudy3rKHMmYSSwVPkHSIVEvmg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1383034443; i=@elandsys.com; bh=FuN3oWHkH3mXWXWvN78EMK2XYiaeFjCbWsX8+9AeOWM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1ZV8r1TYVsBQx1VbspzW03fRQeadnRHEu9FjnGSEZUYnMYDruJo48YtPJygGejdEm KmdnhypnQ6ZrfBBvhwnEitXWSjFZv2cRBl8poOnfbkREN2dGzzLajLPGBIeHbGd8fC cvdYXcy4T6uxCETXyiVSPveuXBskyR4G7YbXXgmM= Message-Id: <6.2.5.6.2.20131028091247.0e37b9d0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 28 Oct 2013 09:55:10 -0700 To: apps-discuss@ietf.org, draft-ietf-httpbis-p1-messaging.all@tools.ietf.org From: S Moonesamy In-Reply-To: <6.2.5.6.2.20131026225145.0bee7bb8@elandnews.com> References: <6.2.5.6.2.20131026225145.0bee7bb8@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf-http-wg@w3.org, ietf@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-httpbis-p1-messaging-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 08:14:17 -0000 Hello, While I was reviewing other drafts in the set I noticed that Section 3.2.4 of draft-ietf-httpbis-p1-messaging-24 has the following: "Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type (Section 8.3.1). A sender MUST NOT generate a message that includes line folding (i.e., that has any field-value that contains a match to the obs-fold rule) unless the message is intended for packaging within the message/http media type." There is an IETF specification which interpreted Section 4.2 of RFC 2616 as follows: "the HTTP header syntax allows extending single header values across multiple lines, by inserting a line break followed by whitespace" I'll classify deprecating line folding as an issue. Section 4.2 of RFC 2616 (and RFC 2068) follows the same generic format as that given in Section 3.1 of RFC 822. Section 2.2 of RFC 2616 states that: "HTTP/1.1 header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab." I suggest that implementors of specifications which have a dependency on RFC 2616 review the relevant section in draft-ietf-httpbis-p1-messaging-24 about line folding and comment if they consider the deprecation as a problem. Regards, S. Moonesamy From sm@elandsys.com Tue Oct 29 01:14:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934C321E8107; Tue, 29 Oct 2013 01:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.268 X-Spam-Level: X-Spam-Status: No, score=-102.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WudwOIDCVOa1; Tue, 29 Oct 2013 01:14:17 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E1021E80FA; Tue, 29 Oct 2013 01:14:12 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.158.76]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9T8DiNN027720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 01:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383034448; bh=4DN0+871qsIPdCxIoSjsjSaGqddU7cqgySWqXuChML0=; h=Date:To:From:Subject:Cc; b=giBNlJjtb6CHlbgklspsRt0H9QavZ2dz8/mxnpeM/4gGXjvTrh6Ey8lM+TMp3ezPJ GQUy2QuYPacDoPraayOq5FhNkCd3tDsNJpxDXRMsBmWz3rmBDfkE6lGDI41cScDVUm huHyN0HrVwhJnbWNckEo6nWdgWQjyeeGURPB8iA8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1383034448; i=@elandsys.com; bh=4DN0+871qsIPdCxIoSjsjSaGqddU7cqgySWqXuChML0=; h=Date:To:From:Subject:Cc; b=ImUwNbCnQxliKeDlGgCpwUoVBr8/kU10o2mmJgjc8JLRRUyZvO2/5bRFmso+l+lMX jqr8OZ2oQhkzuTtASp3KpsdzDTuHBBQIkdCvms+Aqcjbe14CyQuakVJwUIwKWphrkU LPYMfvWKvqO/BYKuvPGQYPIrDIDnNuj4iA8TEGkA= Message-Id: <6.2.5.6.2.20131028101123.0e37a698@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 29 Oct 2013 01:13:08 -0700 To: apps-discuss@ietf.org, draft-ietf-httpbis-p5-range.all@tools.ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: iesg@ietf.org, ietf-http-wg@w3.org, ietf@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-httpbis-p5-range-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 08:14:20 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-httpbis-p5-range-24 Title: Hypertext Transfer Protocol (HTTP/1.1): Range Requests Reviewer: S. Moonesamy Review Date: October 29, 2013 IETF Last Call Date: October 21, 2013 Summary: This draft requires further review. This document defines HTTP/1.1 range requests, partial responses, and the multipart/byteranges media type. This document is well-written. The Introduction section mentions that the byte range feature is an optional feature of HTTP. This feature can be used to, for example, resume the download of a large file. The feature is part of the set of documents for the protocol while the feature can be considered as not being part of the base protocol. The Security Consideration sections (see Part 1 and Part 2) do not discuss about whether the feature can be misused (e.g. denial of service). Major Issues: In Section 2.3: 'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.' There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1: "A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations." My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional. In Section 3.2: "HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2. In Section 2.1: "Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive): bytes=500-600,601-999 bytes=500-700,601-999" And Section 3.1: "A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier." I am trying to understand what the server should do when it receives one or several overlapping ranges. In Section 4.1: "If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A" It is unusual to have a RFC 2119 requirement defined in an appendix. "If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part." I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response? "When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range- spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges." It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should". In Appendix A: "The following definition is to be registered with IANA [BCP13]." The request to IANA should be in the IANA Considerations section. Minor Issues: In Section 1: "Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability." As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase. In Section 2.1: "In the byte range syntax, first-byte-pos, last-byte-pos, and suffix- length are expressed as decimal number of octets. Since there is no predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows." There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable. Nits: In Section 2.2: "Range units are intended to be extensible." Section 3.12 of RFC 2616 states that: "The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges." I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units. In Section 2.3: "A server that does not support any kind of range request for the target resource resource MAY send" The word "resource" is duplicated. Regards, S. Moonesamy From sm@elandsys.com Tue Oct 29 06:49:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A922811E824C; Tue, 29 Oct 2013 06:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.728 X-Spam-Level: X-Spam-Status: No, score=-102.728 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNwgcA4QM7-W; Tue, 29 Oct 2013 06:49:58 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE80C11E8242; Tue, 29 Oct 2013 06:49:58 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.128.39]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9TDne3n017632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 06:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383054594; bh=d73n3/K2HZ/iy8R9KTgH8dYoY+Wzn/c+g2rRWgLgsL4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=muz2fkPNs62YeJ7wHV7tFWLkSdk0PmG//kVQs6OdPoCyO7VH68TqSLtsPAlkMD2zR Fjgvhce3+yKO7uZ3cUdxmwxPRIbJ0HYnkTUTern0Zn7Qg4NV0TfCyf2lBL6+B0vnmz 2IAEW0a5xmnrE2siK/IgZFjiFocZ1yE6tikujP1g= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1383054594; i=@elandsys.com; bh=d73n3/K2HZ/iy8R9KTgH8dYoY+Wzn/c+g2rRWgLgsL4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dJyAeT6Nz9MvtOfwXncj15YGLm9DP+Wem0bhQm3iGqzrxP96L153Ips63dECdKGkK AGxizHGLvNi+02jiHGUe2P9l7A91MJvxfIcxkVVyNUdCoLlkFHm/ybqBLJj/ymW3Nq m1XIa696fQ8cy6DUH1TDAgc3RFx0A6KZv2gSUGLI= Message-Id: <6.2.5.6.2.20131029050405.0caf8b40@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 29 Oct 2013 06:26:34 -0700 To: Julian Reschke , apps-discuss@ietf.org, draft-ietf-httpbis-p2-semantics.all@tools.ietf.org From: S Moonesamy In-Reply-To: <526E8B9E.8030006@gmx.de> References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E8B9E.8030006@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf@ietf.org, iesg@ietf.org, ietf-http-wg@w3.org Subject: Re: [apps-discuss] content inspection in absence of media type, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 13:49:59 -0000 Hi Julian, At 09:06 28-10-2013, Julian Reschke wrote: >On 2013-10-28 09:07, S Moonesamy wrote: >(which expired ~2 years ago) I guess that the working group gave up. Please note that I did not suggest adding a reference. >Could you clarify what exactly the issue is? > >RFC 2616 said >(): > >>Any HTTP/1.1 message containing an entity-body SHOULD include a >>Content-Type header field defining the media type of that body. If >>and only if the media type is not given by a Content-Type field, >>the recipient MAY attempt to guess the media type via inspection of >>its content and/or the name extension(s) of the URI used to >>identify the resource. If the media type remains unknown, the >>recipient SHOULD treat it as type "application/octet-stream". > >...which isn't that different. The 'If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream' from RFC 2616 is not in draft-ietf-httpbis-p2-semantics-24. The issue is the "or examine the data to determine its type". I'll comment about the text (Section 3.1.1.5) again. The server has to generate a Content-Type header field unless the media type is unknown. There is then a RFC 2119 "may" which is applicable when the (previous) RFC 2119 "should" cannot be applied. My reading of the "may" is that the usage is not entirely correct. I am not raising that as an issue. The issue is whether there is a security problem and whether there is adequate discussion of it (e.g. it is discussed in a Security Considerations section). Regards, S. Moonesamy From sm@elandsys.com Tue Oct 29 06:50:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB7F21E8127; Tue, 29 Oct 2013 06:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.723 X-Spam-Level: X-Spam-Status: No, score=-102.723 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7FC-qaOTHJO; Tue, 29 Oct 2013 06:50:03 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A7321E8125; Tue, 29 Oct 2013 06:50:03 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.128.39]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9TDne3p017632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 06:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383054599; bh=W1VKHQtS2s7E9bcsq+kjPLQ2C7ykIk7VCnCXX6ObrmY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jviLBA7T9gAftEcBSEqkg4mg+uvD7KjGOIEZfKbqeTwwXMrEccj4TmFW+2ONRokoX Sbw6Pd8dA/43uunKVx6PLk6Whcly9yDlX7ifPDLmlzoB7glnVaN4sMg1ElDHcBrVKI CuhQ4nRr5Yi8DKoaIq0/zdvEPR7jtDKc2/+OuV3k= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1383054599; i=@elandsys.com; bh=W1VKHQtS2s7E9bcsq+kjPLQ2C7ykIk7VCnCXX6ObrmY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=k/cc7Ne+1NgR+ckEL2WC8Gv7LSE/PoxPK2BQwieoHhiqhh7p9ETXi6LMgJPWVdoLA nLgsjglbf8fXBDO4Qj+B31s+HZIsQFeJAk6Co/BPrHexieIT9OFmUDc4SdyYhhiAaJ ADWv+PA5RrAORHOHbbG54E9huva580Pk8Cyc1kNo= Message-Id: <6.2.5.6.2.20131029062834.0c4b9f98@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 29 Oct 2013 06:39:14 -0700 To: Julian Reschke , apps-discuss@ietf.org, draft-ietf-httpbis-p1-messaging.all@tools.ietf.org From: S Moonesamy In-Reply-To: <526E8878.5030903@gmx.de> References: <6.2.5.6.2.20131026225145.0bee7bb8@elandnews.com> <526E8878.5030903@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf-http-wg@w3.org, ietf@ietf.org Subject: Re: [apps-discuss] Registration requirements for transfer codings, was: APPSDIR review of draft-ietf-httpbis-p1-messaging-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 13:50:04 -0000 Hi Julian, At 08:53 28-10-2013, Julian Reschke wrote: >My understanding is that we wanted to set a high bar because this >really ought to happen with lots of care and review. > >The related ticket is >, and it was >discussed during IETF 75 >(). I'll consider this as addressed. Regards, S. Moonesamy From julian.reschke@gmx.de Tue Oct 29 07:12:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DBB11E8259 for ; Tue, 29 Oct 2013 07:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.671 X-Spam-Level: X-Spam-Status: No, score=-103.671 tagged_above=-999 required=5 tests=[AWL=-1.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Xng2kvp1+AT for ; Tue, 29 Oct 2013 07:12:42 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id D944C11E825B for ; Tue, 29 Oct 2013 07:12:34 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MKpQ4-1VbA250ZUm-0006Wy for ; Tue, 29 Oct 2013 15:12:33 +0100 Message-ID: <526FC24D.7060704@gmx.de> Date: Tue, 29 Oct 2013 15:12:29 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: S Moonesamy , apps-discuss@ietf.org, draft-ietf-httpbis-p2-semantics.all@tools.ietf.org References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E8B9E.8030006@gmx.de> <6.2.5.6.2.20131029050405.0caf8b40@elandnews.com> In-Reply-To: <6.2.5.6.2.20131029050405.0caf8b40@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:QsCD1Pxdv/OjgwbgOKCjKC/H0TyzoD8flKYfbLdYh+3+xMXjv93 qI9tjUVaAuUufcofrgDi6dZbpeSErZOECK0lR3xXFbMZ3cjrGvZI/5ZI7hmUDEnygwVMuHt LiYdOs5z8cLuuiPpa5f2ekv1gbenf4fydTztLbN0JUrgDWvZ75iunLfrrZWf5GxvbYw/t42 asHw8amOaf1hSVmhIfhQQ== Cc: ietf@ietf.org, iesg@ietf.org, ietf-http-wg@w3.org Subject: Re: [apps-discuss] content inspection in absence of media type, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 14:12:43 -0000 On 2013-10-29 14:26, S Moonesamy wrote: > Hi Julian, > At 09:06 28-10-2013, Julian Reschke wrote: >> On 2013-10-28 09:07, S Moonesamy wrote: >> (which expired ~2 years ago) > > I guess that the working group gave up. Please note that I did not > suggest adding a reference. > >> Could you clarify what exactly the issue is? >> >> RFC 2616 said >> (): >> >>> Any HTTP/1.1 message containing an entity-body SHOULD include a >>> Content-Type header field defining the media type of that body. If >>> and only if the media type is not given by a Content-Type field, the >>> recipient MAY attempt to guess the media type via inspection of its >>> content and/or the name extension(s) of the URI used to identify the >>> resource. If the media type remains unknown, the recipient SHOULD >>> treat it as type "application/octet-stream". >> >> ...which isn't that different. > > The 'If the media type remains unknown, the recipient SHOULD treat it as > type "application/octet-stream' from RFC 2616 is not in > draft-ietf-httpbis-p2-semantics-24. I consider that sentence to be useless - if I can't detect the type, what else but "treating as arbitrary data" is left as an option anyway? > The issue is the "or examine the data to determine its type". I'll > comment about the text (Section 3.1.1.5) again. The server has to > generate a Content-Type header field unless the media type is unknown. Yes. > There is then a RFC 2119 "may" which is applicable when the (previous) > RFC 2119 "should" cannot be applied. My reading of the "may" is that > the usage is not entirely correct. I am not raising that as an issue. I still don't get what the issue is :-) > The issue is whether there is a security problem and whether there is > adequate discussion of it (e.g. it is discussed in a Security > Considerations section). The subsequent text is: "In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for a given representation, with the result that some clients will examine a payload's content and override the specified type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege escalation"). Furthermore, it is impossible to determine the sender's intent by examining the data format: many data formats match multiple media types that differ only in processing semantics. Implementers are encouraged to provide a means of disabling such "content sniffing" when it is used." Do you think this is insufficient, or that it needs to move to a different part of the spec? Best regards, Julian From julian.reschke@gmx.de Tue Oct 29 08:03:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A7011E8279 for ; Tue, 29 Oct 2013 08:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.723 X-Spam-Level: X-Spam-Status: No, score=-103.723 tagged_above=-999 required=5 tests=[AWL=-1.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm9GjlPn8k0k for ; Tue, 29 Oct 2013 08:03:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE5E11E810E for ; Tue, 29 Oct 2013 08:03:19 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MJjUO-1Va4MS3Gaa-001CJa for ; Tue, 29 Oct 2013 16:03:18 +0100 Message-ID: <526FCE32.8090309@gmx.de> Date: Tue, 29 Oct 2013 16:03:14 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: S Moonesamy , apps-discuss@ietf.org, draft-ietf-httpbis-p5-range.all@tools.ietf.org References: <6.2.5.6.2.20131028101123.0e37a698@elandnews.com> In-Reply-To: <6.2.5.6.2.20131028101123.0e37a698@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:gm6ouZCX3qSnktQ9y/92vOUYBZiJdBQkEIMUzz0OTqfO2VvJvAP UoxKnKRdPNjS02k3Or/gC5kZ22/cI26P575YUsgo0VHTG5+gjF+pHMbKrSXbRZqFq50+Nni PxeE2sV/RMpDc9h/Trr/eC3tPHWWK4utpkMOT5k+QxGmZDCziiTbNClNMUdu6/qbJfIdCbq uVej2QB96tSONrZMmku5g== Cc: iesg@ietf.org, ietf-http-wg@w3.org, ietf@ietf.org Subject: [apps-discuss] custom byte ranges, was: APPSDIR review of draft-ietf-httpbis-p5-range-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 15:03:24 -0000 On 2013-10-29 09:13, S Moonesamy wrote: > ... > In Section 2.2: > > "Range units are intended to be extensible." > > Section 3.12 of RFC 2616 states that: > > "The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 > implementations MAY ignore ranges specified using other units. > HTTP/1.1 has been designed to allow implementations of applications > that do not depend on knowledge of ranges." > > I consider the creation of the registry as "it does not cost anything to > add one more registry". The text from RFC 2616 suggests that the only > unit specified is "bytes" and that HTTP/1.1 does not depend upon the > knowledge of this optional feature. I don't see any reason to have > other range units. > ... Actually, it was a case of "this is used in the wild already, and more use is coming up, so better document it properly and add the registry". See for the history. Best regards, Julian From julian.reschke@gmx.de Tue Oct 29 08:28:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6FE21E814E for ; Tue, 29 Oct 2013 08:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.739 X-Spam-Level: X-Spam-Status: No, score=-103.739 tagged_above=-999 required=5 tests=[AWL=-1.140, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+yfaOQs4G6n for ; Tue, 29 Oct 2013 08:28:09 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 35D2511E82EC for ; Tue, 29 Oct 2013 08:27:42 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MV6PJ-1VBZAc2g7p-00YP5s for ; Tue, 29 Oct 2013 16:27:40 +0100 Message-ID: <526FD3E8.9010904@gmx.de> Date: Tue, 29 Oct 2013 16:27:36 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: S Moonesamy , apps-discuss@ietf.org, draft-ietf-httpbis-p5-range.all@tools.ietf.org References: <6.2.5.6.2.20131028101123.0e37a698@elandnews.com> In-Reply-To: <6.2.5.6.2.20131028101123.0e37a698@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:WdlhOEQMUwdL19vv6itXshiLggEqNKNzfXMdtTdPGkauu9+3fDH kHFL0tSi1Tb22vARYHMR+dbPCNdHTM15cUtgBBxIgSDjywR6cBF7fE8LPbiiyY3MED5cRH/ AUx/Pml65wfu0McepEK/mU8Qn89rfTJpIGDWplZRKz3fUs/6QxplAUCOrvjrdVBHGTrqxko u82RI2OiIbrH5a0rgy1/Q== Cc: iesg@ietf.org, ietf-http-wg@w3.org, ietf@ietf.org Subject: [apps-discuss] #506, was: APPSDIR review of draft-ietf-httpbis-p5-range-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 15:28:09 -0000 Hi SM, thanks a lot for the incoming reviews! I'm tracking them in the WG's trac instance. Below are comments on the non-editorial parts of your review. On 2013-10-29 09:13, S Moonesamy wrote: > ... > Major Issues: > > In Section 2.3: > > 'The "Accept-Ranges" header field allows a server to indicate that it > supports range requests for the target resource.' > > There isn't any recommendation or requirement for the server to send > "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there > is a recommendation for the server to advertise the feature if the > server supports it. There is the following text in Section 3.1: Well, it's optional, and we didn't want to make it a SHOULD. It adds overhead to GET responses, even though only few clients will make range requests. > "A server MAY ignore the Range header field. However, origin servers > and intermediate caches ought to support byte ranges when possible, > since Range supports efficient recovery from partially failed > transfers and partial retrieval of large representations." > > My understanding of the above is that the server can ignore the Range > header field but it is politely recommended that origin servers and > intermediate caches support it. This looks like a workaround to avoid > introducing a RFC 2119 "should". The text explains why it is worthwhile > to support byte ranges while the Introduction sections states that this > feature is optional. Yes. Do you think this is a problem? Why? > In Section 3.2: > > "HTTP-date" is defined in the Appendix C. I suggest importing the rules > should be in Section 1.2. > In Section 2.1: > > "Other valid (but not canonical) specifications of the second 500 > bytes (byte offsets 500-999, inclusive): > > bytes=500-600,601-999 > bytes=500-700,601-999" > > And Section 3.1: > > "A client that is requesting multiple ranges SHOULD list those ranges > in ascending order (the order in which they would typically be > received in a complete representation) unless there is a specific > need to request a later part earlier." > > I am trying to understand what the server should do when it receives one > or several overlapping ranges. "A server that supports range requests MAY ignore or reject a Range header field that consists of more than two overlapping ranges, or a set of many small ranges that are not listed in ascending order, since both are indications of either a broken client or a deliberate denial of service attack (Section 6.1). A client SHOULD NOT request multiple ranges that are inherently less efficient to process and transfer than a single range that encompasses the same data." ..or it can serve the response as multipart/byteranges as requested. > In Section 4.1: > > "If multiple parts are being transferred, the server generating the > 206 response MUST generate a "multipart/byteranges" payload, as > defined in Appendix A" > > It is unusual to have a RFC 2119 requirement defined in an appendix. > "If the selected representation would have had a Content-Type > header field in a 200 (OK) response, the server SHOULD generate > that same Content-Type field in the header area of each body part." > > I don't understand why the RFC 2119 "should" is used in the above. When > can the "should" be ignored? Is the server supposed to generate the Dunno. > same Content-Type header field in each header area if the selected > representation would have a Content-Type header field for a 200 (OK) > response? That's what the above says, no? > "When a multipart response payload is generated, the server SHOULD > send the parts in the same order that the corresponding byte-range- > spec appeared in the received Range header field, excluding those > ranges that were deemed unsatisfiable or that were coalesced into > other ranges." > > It is recommended in the Section 3.1 that the client lists the ranges it > requests in ascending order. The above text recommends that the server > should send the parts in the same order as the request. There can be an > interoperability issue when the two sides are told to do RFC 2119 "should". Such as? > In Appendix A: > > "The following definition is to be registered with IANA [BCP13]." > > The request to IANA should be in the IANA Considerations section. Right. Fixed in . > Minor Issues: > > In Section 1: > > "Range requests are an OPTIONAL feature of HTTP, designed so that > recipients not implementing this feature (or not supporting it > for the target resource) can respond as if it is a normal GET > request without impacting interoperability." > > As the word "OPTIONAL" in the above is not interpreted according to RFC > 2119 I suggest using plain English instead of a word in uppercase. It is supposed to be interpreted per RFC 2119. > In Section 2.1: > > "In the byte range syntax, first-byte-pos, last-byte-pos, and suffix- > length are expressed as decimal number of octets. Since there is no > predefined limit to the length of a payload, recipients ought to > anticipate potentially large decimal numerals and prevent parsing > errors due to integer conversion overflows." > > There is a RFC 2119 "should" in Section 3.3.2 of > draft-ietf-httpbis-p1-messaging-24 about integer conversion and a > reference to Section 9.3 of that draft. I may have missed integer > conversation issues in the reviews. I suggest doing a verification to > verify that there is adequate text where it is applicable. Raised as . > .. Best regards, Julian From barryleiba@gmail.com Tue Oct 29 08:28:30 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5E421E8151; Tue, 29 Oct 2013 08:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.657 X-Spam-Level: X-Spam-Status: No, score=-101.657 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_63=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7re7sPtN0QL; Tue, 29 Oct 2013 08:28:29 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 93EFF21E8143; Tue, 29 Oct 2013 08:28:09 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id k18so4328qcv.10 for ; Tue, 29 Oct 2013 08:28:04 -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=4tuRPMQWEaqIBoNw50thWZT41IgrR3tEmgtzAlm7cD8=; b=aYTw8gLPU3lTrYjYVV8EfkD1bVqgzwIHfb1xtYBjx2T4l7fn32dH0dF5VU1yesheIM Yo6mw6DoEVAc3rKkd8iirUv0hQF9IW14rYnry7vz9KnPjaEk95eVpxK0bitt3aqgY4Yg a8YUUpgR20bYQN+3qEBE9c78MuHD78/IEBH4OBG4KV2Uf8L0y2ds3yN6Jx1wgYZlRFTn Ul9nk17Bw1oKNGKGtkV197qoTw5679RHMbxk5+pOZvhNcmCcaObuqjAyJ2xfPSHAKWPs LK89FCORL2ESLFZZ7v8sVPNewUIYU4nLDLpUxbbXyPc3GPyrtIUTgflkGZtaTufInJ4U pVAQ== MIME-Version: 1.0 X-Received: by 10.229.101.136 with SMTP id c8mr256228qco.17.1383060484895; Tue, 29 Oct 2013 08:28:04 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.67.130 with HTTP; Tue, 29 Oct 2013 08:28:04 -0700 (PDT) In-Reply-To: <526FC24D.7060704@gmx.de> References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E8B9E.8030006@gmx.de> <6.2.5.6.2.20131029050405.0caf8b40@elandnews.com> <526FC24D.7060704@gmx.de> Date: Tue, 29 Oct 2013 11:28:04 -0400 X-Google-Sender-Auth: cZk9QgaywxIVRlrTabqNwy6vofs Message-ID: From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF discussion list , Apps Discuss , S Moonesamy , draft-ietf-httpbis-p2-semantics.all@tools.ietf.org, IESG , HTTP Working Group Subject: Re: [apps-discuss] content inspection in absence of media type, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 15:28:30 -0000 >> There is then a RFC 2119 "may" which is applicable when the (previous) >> RFC 2119 "should" cannot be applied. My reading of the "may" is that >> the usage is not entirely correct. I am not raising that as an issue. > > I still don't get what the issue is :-) Yeh, neither do I, and I'm pretty sensitive to those SHOULD+MAY issues. The one in Section 3.1.1.5 seems perfectly fine: it says that the server SHOULD do something, and that if the server has not done that the client MAY do something to try to compensate. A-OK to me. The tricky bits with SHOULD+MAY occur when both key words apply to the same entity under the same conditions. That's not the case here. Barry From julian.reschke@gmx.de Tue Oct 29 09:03:53 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D91111E825D for ; Tue, 29 Oct 2013 09:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.753 X-Spam-Level: X-Spam-Status: No, score=-103.753 tagged_above=-999 required=5 tests=[AWL=-1.154, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojNPFy0VJX1W for ; Tue, 29 Oct 2013 09:03:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6293B11E81FB for ; Tue, 29 Oct 2013 09:03:40 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MWwp6-1VE2BR161c-00VzBo for ; Tue, 29 Oct 2013 17:03:39 +0100 Message-ID: <526FDC52.3030808@gmx.de> Date: Tue, 29 Oct 2013 17:03:30 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: S Moonesamy , apps-discuss@ietf.org, draft-ietf-httpbis-p1-messaging.all@tools.ietf.org, iesg@ietf.org References: <6.2.5.6.2.20131026225145.0bee7bb8@elandnews.com> In-Reply-To: <6.2.5.6.2.20131026225145.0bee7bb8@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:9kqQMpO7zr1hGJ46bctQwQN8xbarAMItGerWlBW0XpsFxU6YAfI F9Cx/ngL88G8Bfe4d/12M0F4annkMA26aNvYlShk73huWwqAk2kdWSTxebYZJgsYDINFYUt Zbgw8LZADVBib6zBxDjoJSOyuB8FX1QD8HlOFKskLjcUuOTxRZ9IBY+9UUUoZhW3RT7IzG4 KcsLDLso03Hqb9eLpKalg== Cc: ietf-http-wg@w3.org, ietf@ietf.org Subject: [apps-discuss] connection limits, was: APPSDIR review of draft-ietf-httpbis-p1-messaging-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 16:03:53 -0000 On 2013-10-27 19:44, S Moonesamy wrote: > ... > In Section 6.4 > > "A client SHOULD limit the number of simultaneous open connections > that it maintains to a given server." > > There is an explanation about why a specific number is not included for > this recommendation in the paragraphs following the above text. I read > Issue #131. I don't see any discussion of the tradeoffs in Section > 6.4. The is a note about servers may reject an excessive number of > connections from a client if they deem that it is abusive. > ... I have trouble parsing this comment. Do you see an issue here? Best regards, Julian From superuser@gmail.com Tue Oct 29 09:27:49 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA22211E81B9 for ; Tue, 29 Oct 2013 09:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Am034REyX2j9 for ; Tue, 29 Oct 2013 09:27:49 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8462911E8185 for ; Tue, 29 Oct 2013 09:27:37 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id m15so90733wgh.25 for ; Tue, 29 Oct 2013 09:27:36 -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=Ynxz6K1BpnH7uTOrbUEoAgGTnVpg4n9UR05g9GNP+uQ=; b=xJ8Z24PKkZ39J5nQXMUSX0uqouT9OcAztjlzh99mR4P15jWNZLZV5U2aofhodjHiVU V/4bcTeIwxHTozLy47lNTOG/ZAA/ZL82SUJ2NZwyDwpDCJbBnBjkV3gE+fzsZg0Cdleu nhhTHBvBeuTxz/alK3B/6siluYDSxQuYEJQtzkBnkTmRv5wPfuhauBAE56HXub2vzUa1 ctBCm6Efd19W40LSYYXz+wmwJBdkAuLHvX6b3hsjmDNNEVX/PgzGpVTDpy7MHrfS5Xe+ dPwuApyqWm/Mf1wpdYa296yHXqcrTRXZ65G9Bgwf+FgBKHFMth3j7c7l6gV1h2YTQBiq Kkuw== MIME-Version: 1.0 X-Received: by 10.180.19.133 with SMTP id f5mr13847379wie.60.1383064056657; Tue, 29 Oct 2013 09:27:36 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Tue, 29 Oct 2013 09:27:36 -0700 (PDT) In-Reply-To: <01P045KGGNH200004R@mauve.mrochek.com> References: <20131022182337.4789.qmail@joyce.lan> <01P00BXM2CJU00004R@mauve.mrochek.com> <526BAD7B.1000003@tana.it> <01P03FJ5YVMC00004R@mauve.mrochek.com> <526E3849.5000801@tana.it> <01P03YHJCHLS00004R@mauve.mrochek.com> <1382977264.41169.YahooMailNeo@web125601.mail.ne1.yahoo.com> <01P045KGGNH200004R@mauve.mrochek.com> Date: Tue, 29 Oct 2013 09:27:36 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=bcaec53f37e5cc7c6704e9e3b1f3 Cc: "apps-discuss@ietf.org" , Alessandro Vesely Subject: Re: [apps-discuss] SMTP extension Re: I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 16:27:49 -0000 --bcaec53f37e5cc7c6704e9e3b1f3 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 28, 2013 at 10:59 AM, Ned Freed wrote: > > How does this ensure that the RRVS check passes all the way through to > the > > authoritative MX? If you're passing through a chain of MX boxes then > the whole > > chain has to support the extension? > > I'll again note that the issues faced by forwards operating outside the > administative domain are formidable. RRVS is at best a tiny part of this. > > But absent any interest in working on a solution, I see no reason for RRVS > to > wade into this morass. It should simply note this as an issue and move on. > That's an option, of course, but isn't tunneling the sender's request via a header field something potentially workable? I think what I mean by that is: Should this draft just take out the header field and be hand-wavey on that topic, as opposed to what's there now? -MSK --bcaec53f37e5cc7c6704e9e3b1f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 28, 2013 at 10:59 AM, Ned Freed <ned.free= d@mrochek.com> wrote:
> How does this ensure that the RRVS chec= k passes all the way through to the
> authoritative MX?=A0 If you're passing through a chain of MX boxes= then the whole
> chain has to support the extension?

I'll again note that the issues faced by forwards operating outsi= de the
administative domain are formidable. RRVS is at best a tiny part of this.
But absent any interest in working on a solution, I see no reason for RRVS = to
wade into this morass. It should simply note this as an issue and move on.<= br>

That's an option, of course, but is= n't tunneling the sender's request via a header field something pot= entially workable?=A0 I think what I mean by that is: Should this draft jus= t take out the header field and be hand-wavey on that topic, as opposed to = what's there now?

-MSK
--bcaec53f37e5cc7c6704e9e3b1f3-- From ned.freed@mrochek.com Tue Oct 29 09:49:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C80A21E8089 for ; Tue, 29 Oct 2013 09:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgvkXuiOcamc for ; Tue, 29 Oct 2013 09:49:21 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 25CA021F9B65 for ; Tue, 29 Oct 2013 09:47:25 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P05GVSJC3K007OQR@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 29 Oct 2013 09:42:02 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OZQXEDTQ3400004R@mauve.mrochek.com>; Tue, 29 Oct 2013 09:41:57 -0700 (PDT) Message-id: <01P05GVOY8RU00004R@mauve.mrochek.com> Date: Tue, 29 Oct 2013 09:33:52 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 29 Oct 2013 09:27:36 -0700" References: <20131022182337.4789.qmail@joyce.lan> <01P00BXM2CJU00004R@mauve.mrochek.com> <526BAD7B.1000003@tana.it> <01P03FJ5YVMC00004R@mauve.mrochek.com> <526E3849.5000801@tana.it> <01P03YHJCHLS00004R@mauve.mrochek.com> <1382977264.41169.YahooMailNeo@web125601.mail.ne1.yahoo.com> <01P045KGGNH200004R@mauve.mrochek.com> To: "Murray S. Kucherawy" Cc: Ned Freed , "apps-discuss@ietf.org" , Alessandro Vesely Subject: Re: [apps-discuss] SMTP extension Re: I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 16:49:35 -0000 > On Mon, Oct 28, 2013 at 10:59 AM, Ned Freed wrote: > > > How does this ensure that the RRVS check passes all the way through to > > the > > > authoritative MX? If you're passing through a chain of MX boxes then > > the whole > > > chain has to support the extension? > > > > I'll again note that the issues faced by forwards operating outside the > > administative domain are formidable. RRVS is at best a tiny part of this. > > > > But absent any interest in working on a solution, I see no reason for RRVS > > to > > wade into this morass. It should simply note this as an issue and move on. > > > That's an option, of course, but isn't tunneling the sender's request via a > header field something potentially workable? I think what I mean by that > is: Should this draft just take out the header field and be hand-wavey on > that topic, as opposed to what's there now? That's an entirely different topic - my point was that whether or not you "solve" the RRVS problem in the case of secondary MXes isn't going to have any real impact on the MX problem space. I have to say I'm not wild about the notion of downgrading the RRVS extension to the header mechanism on the fly, because it grots up code that otherwise is able to do things like BDAT in a single, simple operation. But it is implementable. Ned From prvs=0007d183c0=johnl@iecc.com Tue Oct 29 12:03:40 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055A321E809D for ; Tue, 29 Oct 2013 12:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZ+aADAOBWHi for ; Tue, 29 Oct 2013 12:03:26 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A5B7421F9D0A for ; Tue, 29 Oct 2013 12:02:58 -0700 (PDT) Received: (qmail 2208 invoked from network); 29 Oct 2013 19:02:57 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 29 Oct 2013 19:02:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52700661.xn--30v786c.k1310; i=johnl@user.iecc.com; bh=1BQ7uOA1P15/LxJpwHzLzSi5AmsJS6RtuS6eshnVVDo=; b=vKuIt4Uo1idsGDR7lCE9a/NGaybkQX1/C2q0RXYmrnzaVRUjMeXMjlNjGgRoULqMzPjYsjZbiUY/BP5e4vIKbFeZ+zi9gbHuDUYaE+0Sfe39w3MFgCEqCLDu4AAP6YjtmTlUUXq2yShRLOdvLcmLsYmpaC+VHQRhUtNK4yj8fdtUdJGOf8t5ywxXyjOWAwRKo+YX7trtp2ovgKgOp2v5xGSt7JZYvfCpRXxDoTHLxdftgancoiACizKiAzVMU5PI DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52700661.xn--30v786c.k1310; olt=johnl@user.iecc.com; bh=1BQ7uOA1P15/LxJpwHzLzSi5AmsJS6RtuS6eshnVVDo=; b=Brr2Ixqzoo5ZqihKaRO8NOoLXT12rdjBJZ+SKNwGdeIf3WR14xtbeLiqpwjHrn1ybt8AQyMwNV0r89gU7HfYnlfTBGFgp1XV1KBH48VRVal7RDL8TDjZokSpEU2K1tOJXIHZMqueOEV4zn841DeRX4SosXxDcyI2TsPV+hfqyd7YmW+HBTaV132Q86r1Eu1V0Sc7sA++GIX72RmrMhex6VlJF1ndwLW5z+8aRer3BrIIRWlK1rnwg2cc5mSkQmeI Date: 29 Oct 2013 19:02:35 -0000 Message-ID: <20131029190235.20826.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <01P05GVOY8RU00004R@mauve.mrochek.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: ned.freed@mrochek.com Subject: Re: [apps-discuss] SMTP extension Re: I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 19:03:40 -0000 >I have to say I'm not wild about the notion of downgrading the RRVS extension >to the header mechanism on the fly, because it grots up code that otherwise is >able to do things like BDAT in a single, simple operation. But it is >implementable. I don't think anyone is, but considering the number of relay servers that exist, we need to say something. I'm pretty much with Murray, note it and don't try to solve the problem. If a relay is able to remember the RRVS envelope info, it can pass it along in the next SMTP session. Or it could stick it in the message as an RRVS header, although since RRVS isn't a trace header that runs the risk of breaking signatures and other confusion. R's, John From sm@elandsys.com Tue Oct 29 21:47:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD2521F9CE9; Tue, 29 Oct 2013 21:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.933 X-Spam-Level: X-Spam-Status: No, score=-102.933 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuedJu65JiX0; Tue, 29 Oct 2013 21:47:50 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E987C21F9A4A; Tue, 29 Oct 2013 21:44:53 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.128.39]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9U4gwbr023165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 21:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383108235; bh=UjjwrxI/a5LQh8NW7oyVJYtqK0/+lI0u0nMWFK6uXvs=; h=Date:To:From:Subject:Cc; b=kpNQXYyvxnaf47FXROkAennw3l4Z501anY3SUvENizGnB3j0uTqld7rYnvH1czz8v gwBI+nmCusGN2UymChy9IEz7I9w+KLTgDxWCetJx7NjkdZ/OJNTV1bBB/tJ2wh9ckD QBjWEKemp24JOwCkgx3UOjfqyzsWKjMGC6aOxD8U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1383108235; i=@elandsys.com; bh=UjjwrxI/a5LQh8NW7oyVJYtqK0/+lI0u0nMWFK6uXvs=; h=Date:To:From:Subject:Cc; b=agkqyGdpLxGUgdDa49EZXjQRAjMQo9MnbU7tvcwtNDRu/E/+xXozJi1GbvD5/kaek sJIl2Ll8QmH1RnB8z4nzJ8afRXZnwtr3ahtis/vlN+RBTrj4KPhwJav0nNt+EykBx/ saFqB04YzUCGR5QpTH3fBwbdq2IJ6ek9Oqg6sxZs= Message-Id: <6.2.5.6.2.20131029174854.0c2cee28@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 29 Oct 2013 17:58:05 -0700 To: apps-discuss@ietf.org, draft-ietf-httpbis-authscheme-registrations.all@tools.ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf-http-wg@w3.org, iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-httpbis-authscheme-registrations-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 04:47:51 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-httpbis-authscheme-registrations-08 Title: Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations Reviewer: S. Moonesamy Review Date: October 29, 2013 IETF Last Call Date: October 21, 2013 Summary: This draft is almost ready for publication as an Informational RFC. This document registers Hypertext Transfer Protocol (HTTP) authentication schemes which have been defined in standards-track RFCs before the IANA HTTP Authentication Scheme Registry was established. Major Issues: None: Minor Issues: The initial registrations of HTTP authentication schemes for the IANA HTTP Authentication Scheme registry are in the Appendix instead of the IANA Considerations section. I suggest having them in that section. Nits: This review does not contain editorial nits. Regards, S. Moonesamy From sm@elandsys.com Tue Oct 29 21:47:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961AD21F9A4A; Tue, 29 Oct 2013 21:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.409 X-Spam-Level: X-Spam-Status: No, score=-102.409 tagged_above=-999 required=5 tests=[AWL=-0.879, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4+lmJQ0Wr7g; Tue, 29 Oct 2013 21:47:51 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 592F611E81CB; Tue, 29 Oct 2013 21:44:49 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.128.39]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9U4gwbn023165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 21:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383108206; bh=jEDwl6HgFuazbOmphFeLDKl24kHI17FGzOxBa4UXlho=; h=Date:To:From:Subject:Cc; b=4BFChIctuK0lSPKushnd1+u892DT0S5fxQXZaBt+AfTH4cVM11M+3wfiZn+3GSykB ePIFD5ju49waZPuq1Ap2Pb4t8fSmByDPBhr/c7jjuvHfonjowuzEH3Z/93eofNaqaB eY51aFmtFH5XWKQ+uLvmhAHZY6aCZiqMbXSvMqZQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1383108206; i=@elandsys.com; bh=jEDwl6HgFuazbOmphFeLDKl24kHI17FGzOxBa4UXlho=; h=Date:To:From:Subject:Cc; b=yAPpcd3gqeZZkoTYjiBxlF4AyuhfxPLYsRwaKomEqMxHL5Ls5V3Q5I/22ljnIGTAt I2ZRQ3fqCap1KcTasDDis9Hwz/siZuQqOh0hxTrRHNrsBXsEW5/2SlRWGoINkxxKHd lw46z188Eb+hBkHAtCJc8kFmlzhHJjbu4Wp1wGUA= Message-Id: <6.2.5.6.2.20131029070026.0c491228@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 29 Oct 2013 15:19:25 -0700 To: apps-discuss@ietf.org, draft-ietf-httpbis-p6-cache.all@tools.ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: iesg@ietf.org, ietf-http-wg@w3.org, ietf@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-httpbis-p6-cache-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 04:47:51 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-httpbis-p6-cache-24 Title: Hypertext Transfer Protocol (HTTP/1.1): Caching Reviewer: S. Moonesamy Review Date: October 29, 2013 IETF Last Call Date: October 21, 2013 Summary: This draft is almost ready for publication as a Proposed Standard This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. Caching is an optional feature of HTTP. The document is clear and well-written. Major Issues: None Minor Issues: In Section 1: "Any client or server MAY employ a cache, though a cache cannot be used by a server that is acting as a tunnel." I suggest not using the RFC 2119 "may" in the Introduction section. In Section 1.2.1: "If a cache receives a delta-seconds value larger than the largest positive integer it can represent, or if any of its subsequent calculations overflows, the cache MUST consider the value to be 2147483648 (2^31). A recipient parsing a delta-seconds value MUST use an arithmetic type of at least 31 bits of range, and a sender MUST NOT generate delta-seconds with a value greater than 2147483648.." Shouldn't the largest value be 2147483647 (see MAX_INT)? It seems superfluous to have the second RFC 2119 "must" and the RFC 2119 "must not". In Section 5.2.2.2: "Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)." I suggest not having RFC 2119 key words as part of a note. In Section 5.2.2.3: 'The "no-store" response directive indicates that a cache MUST NOT store any part of either the immediate request or response. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best- effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.' There is a RFC 2119 "must not" followed by an explanation of the requirement which includes a RFC 2119 "must not" and a "must". I suggest rewriting the (first) requirement so that it is clear instead of explaining a requirement with another requirement. In Section 5.2.2.6: "Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)." I suggest not having the RFC 2119 "should not" as a part of a note. This suggestion also applies to the note in Section 5.2.2.8 and Section 5.2.2.9. Nits: In Section 4.2: "o A cache recipient MUST NOT allow local time zones to influence the calculation or comparison of an age or expiration time. o A cache recipient SHOULD consider a date with a zone abbreviation other than GMT or UTC to be invalid for calculating expiration." Section 7.1.1.1 of draft-ietf-httpbis-p2-semantics-24 states that: "An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC)." If there is a requirement for the cache to use UTC (re. HTTP-date) internally the above RFC 2119 key words could be collapsed into that. Regards, S. Moonesamy From sm@elandsys.com Tue Oct 29 21:48:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF51621F9D22; Tue, 29 Oct 2013 21:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.896 X-Spam-Level: X-Spam-Status: No, score=-102.896 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CZzIqcyhUhy; Tue, 29 Oct 2013 21:48:02 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D19F21F9D46; Tue, 29 Oct 2013 21:44:45 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.128.39]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9U4gwbp023165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 21:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383108222; bh=nZrZ+ivyJh+jBc4JoipycAe5Kppgbh+yM+wmlYezyhU=; h=Date:To:From:Subject:Cc; b=hlptHRWikGlzJMlCeRV7HAEtgXKlSxkabxypcqcMDG1b+D/9WzkIabBTNTNmlagYx GApt7IVcMI66GFCsCFTOn92uj3vfbgUeTmQ5LoXSUewMjcuzm7/CpViII8tGyMDEiR Hy2bamS6uOYyZyXqn4sOFbgdxVTu+Gxb2WDp83uc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1383108222; i=@elandsys.com; bh=nZrZ+ivyJh+jBc4JoipycAe5Kppgbh+yM+wmlYezyhU=; h=Date:To:From:Subject:Cc; b=qjgzVYN9pmGrKeTR/T1Cv0ap5fCSGcbRGkOk/hBAhyiaY8kI42zcAWuFL+7MPBe6t 9wY+3lCbABdC3lS6WdfSt3pKaQR+D2YoC1hWRLO8cJQZiDRYtpcmtYMNEDncsiusSd dQd8qt3qo2KqrPiJ/NPdYofgevB44Z9PwwOB7y4k= Message-Id: <6.2.5.6.2.20131029152147.0c123670@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 29 Oct 2013 17:48:20 -0700 To: apps-discuss@ietf.org, draft-ietf-httpbis-p7-auth.all@tools.ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: iesg@ietf.org, ietf-http-wg@w3.org, ietf@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-httpbis-p7-auth-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 04:48:03 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-httpbis-p7-auth-24 Title: Hypertext Transfer Protocol (HTTP/1.1): Authentication Reviewer: S. Moonesamy Review Date: October 29, 2013 IETF Last Call Date: October 21, 2013 Summary: This draft is almost ready for publication as a Proposed Standard. This document defines the HTTP Authentication framework. The document is well-written and clear. Major Issues: None Minor Issues: In Section 1: "HTTP provides several OPTIONAL challenge-response authentication schemes that can be used by a server to challenge a client request and by a client to provide authentication information." I suggest using RFC 2119 after Section 1.2. Nits: In Section 2.1: "Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information." The RFC 2119 "may" is unnecessary. Regards, S. Moonesamy From john-ietf@jck.com Mon Oct 28 07:22:38 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22B711E8306; Mon, 28 Oct 2013 07:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.553 X-Spam-Level: X-Spam-Status: No, score=-103.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6d6nixOdLFLS; Mon, 28 Oct 2013 07:22:33 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 89B0B11E817E; Mon, 28 Oct 2013 07:22:31 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Vani6-000F6i-Ds; Mon, 28 Oct 2013 10:22:26 -0400 Date: Mon, 28 Oct 2013 10:22:21 -0400 From: John C Klensin To: Julian Reschke , S Moonesamy , apps-discuss@ietf.org, draft-ietf-httpbis-p2-semantics.all@tools.ietf.org Message-ID: <751EE3ED19D0A62BD858585C@JcK-HP8200.jck.com> In-Reply-To: <526E6DF4.4030509@gmx.de> References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E6DF4.4030509@gmx.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Tue, 29 Oct 2013 21:59:47 -0700 Cc: ietf-http-wg@w3.org, ietf@ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] obs-date, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 14:22:38 -0000 --On Monday, October 28, 2013 15:00 +0100 Julian Reschke wrote: > On 2013-10-28 09:07, S Moonesamy wrote: >> ... >> In Section 7.1.1: >> >> "The preferred format is a fixed-length and single-zone >> subset of the date and time specification used by the >> Internet Message Format [RFC5322]" >... > Actually, HTTPbis has its own obs-date: > > obs-date = rfc850-date / asctime-date > > ics-24.html#rfc.section.7.1.1.1> Julian, I've been reluctant to step into this mess, but, having had another bad experience over the weekend, and with the understanding that we already have multiple "obsolete" forms floating around that implementations are supposed to recognize, I'd like to see if it is still possible to think about moving to an ISO-compatible "preferred form" that would eliminate the difficulty in handling and ambiguities in month names (and the frequent violations where they are made upper-case or translated into local languages). Doing so, and getting rid of "GMT" (which about half the world's population seems to think is a synonym for whatever time is being used around Greenwich), in favor of UT (which no one who has any understanding at all seems to think might change in the summer), would save a lot of problems long-term. That would make the preferred form [day-name ","] year "-" monthNumber "-" day SP time-of-day SP "UT" with monthNumber = 2DIGIT and obs-date = rfc850-date / asctime-date / IMF-fixdate if that is necessary. I don't care whether day-name is optional or not, but there would be some small i18n charm in saying "either write it the way the spec says or leave it out" rather than the current rule, which is effectively "use those English-based abbreviations no matter how obnoxious they are in your environment". It is obviously late to be suggesting this, but it was also late a dozen years ago and will be a lot later five or ten years hence. best, john From john-ietf@jck.com Mon Oct 28 12:22:34 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DC511E82BD; Mon, 28 Oct 2013 12:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.652 X-Spam-Level: X-Spam-Status: No, score=-103.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R26Tm19qVgvM; Mon, 28 Oct 2013 12:22:28 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id A3DEC11E81D0; Mon, 28 Oct 2013 12:22:28 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1VasOL-000FSQ-Qw; Mon, 28 Oct 2013 15:22:21 -0400 Date: Mon, 28 Oct 2013 15:22:16 -0400 From: John C Klensin To: Julian Reschke , S Moonesamy , apps-discuss@ietf.org, draft-ietf-httpbis-p2-semantics.all@tools.ietf.org Message-ID: <4F6568484E956ADBC46BEB16@JcK-HP8200.jck.com> In-Reply-To: <526E73B8.90705@gmx.de> References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E6DF4.4030509@gmx.de> <751EE3ED19D0A62BD858585C@JcK-HP8200.jck.com> <526E73B8.90705@gmx.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Tue, 29 Oct 2013 21:59:47 -0700 Cc: ietf-http-wg@w3.org, ietf@ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] obs-date, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 19:22:34 -0000 --On Monday, October 28, 2013 15:24 +0100 Julian Reschke wrote: > > John, > > that change would make almost every HTTP/1.1 code ever written > non-compliant. > > And yes, it would have been nice if a same date format would > have been chosen back then. Julian, I don't know enough of the issues in enough detail to argue this, and won't. My goal is only to be sure the question has been asked. My understanding is that the HTTPbis work is a rather major revision with at least some cases for which "get it right" is more important that complete backward compatibility, especially if there is a clear migration path. All of the usual arguments for that are relevant, especially the ones that focus on how many implementations and pages are likely to be created in the future relative to those that exist today. Here, the clear migration path would be a narrow and restrictive "send syntax" and a permissive "receive syntax" that requires support of all known older forms, _especially_ those that were recommended by HTTP 1.1. It has been rather longer than I think we expected, but it was clear when HTTP 1.1 was adopted (I am sure it was clear at least to the relevant ADs) that there could be incompatible changes in the future and that the concern should be a non-disruptive migration path, not absolute forward compatibility. That is one of the several reasons why the successor to HTTP 1.0 was identified as HTTP 1.1, not HTTP 2. This sort of change would still make HTTP 1.1 implementations non-compliant with HTTP 2.0, but that is ok -- they still comply with HTTP 1.1 and I hope no one is going to claim that all HTTP 1.1 implementations are non-compliant with HTTP the day HTTP 2.0 is published. If the WG has considered these options and rejected them after an open discusssion, please ignore the comment/ suggestion. > And yes, it would have been nice if a same date format would > have been chosen back then. Yes, even for the mail header syntax that inspired the current form and that predates the web by more than a decade. But that was before there was an ISO Standard, few of us were worried about the year 2000 transition, etc. My practical concern is that, as we internationalize more, those perfectly well-specified ASCII month and day names will get mapped, by implementations who consider the local (and sometimes paying) customers far more important than any standard, into local names that no one else can read. That would be fine if the local forms stayed local, but we have lots of experience, including with email, to indicate that they will leak and cause at least user confusion if not interoperability problems. So, from my point of view, this isn't about introducing an incompatibility with something that one merely regrets not being done differently. It is rather more about what might be the last chance to get it right and, in the process, eliminate completely predictable future confusion and interoperability problems. best, john john From squid3@treenet.co.nz Mon Oct 28 18:27:25 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F0911E81ED; Mon, 28 Oct 2013 18:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.631 X-Spam-Level: X-Spam-Status: No, score=-5.631 tagged_above=-999 required=5 tests=[AWL=-4.583, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnP4-gdzk4zE; Mon, 28 Oct 2013 18:27:15 -0700 (PDT) Received: from treenet.co.nz (ipv6.rio.treenetnz.com [IPv6:2002:3a1c:99e9:0:206:5bff:fe7c:b8a]) by ietfa.amsl.com (Postfix) with ESMTP id 51BDD11E81DD; Mon, 28 Oct 2013 18:26:39 -0700 (PDT) Received: from [192.168.0.6] (unknown [121.99.144.92]) by treenet.co.nz (Postfix) with ESMTP id 14C71E7392; Tue, 29 Oct 2013 14:26:27 +1300 (NZDT) Message-ID: <526F0EC1.7010809@treenet.co.nz> Date: Tue, 29 Oct 2013 14:26:25 +1300 From: Amos Jeffries User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: John C Klensin , Julian Reschke , S Moonesamy , apps-discuss@ietf.org, draft-ietf-httpbis-p2-semantics.all@tools.ietf.org References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E6DF4.4030509@gmx.de> <751EE3ED19D0A62BD858585C@JcK-HP8200.jck.com> <526E73B8.90705@gmx.de> <4F6568484E956ADBC46BEB16@JcK-HP8200.jck.com> In-Reply-To: <4F6568484E956ADBC46BEB16@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 29 Oct 2013 22:00:04 -0700 Cc: ietf-http-wg@w3.org, ietf@ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] obs-date, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Oct 2013 01:27:25 -0000 On 29/10/2013 8:22 a.m., John C Klensin wrote: > > --On Monday, October 28, 2013 15:24 +0100 Julian Reschke > wrote: > >> John, >> >> that change would make almost every HTTP/1.1 code ever written >> non-compliant. >> >> And yes, it would have been nice if a same date format would >> have been chosen back then. > Julian, > > I don't know enough of the issues in enough detail to argue > this, and won't. My goal is only to be sure the question has > been asked. > > My understanding is that the HTTPbis work is a rather major > revision with at least some cases for which "get it right" is > more important that complete backward compatibility, especially > if there is a clear migration path. No. The focus on the WG has been to document what is actually *working* and clarify existing HTTP behaviour in order to encourage interoperability. > All of the usual arguments > for that are relevant, especially the ones that focus on how > many implementations and pages are likely to be created in the > future relative to those that exist today. Here, the clear > migration path would be a narrow and restrictive "send syntax" > and a permissive "receive syntax" that requires support of all > known older forms, _especially_ those that were recommended by > HTTP 1.1. However it is important to note that there is no clear migration path. Many implementations are actively *rejecting* or ignoring date formats which do not include the "GMT" moniker. > It has been rather longer than I think we expected, but it was > clear when HTTP 1.1 was adopted (I am sure it was clear at least > to the relevant ADs) that there could be incompatible changes in > the future and that the concern should be a non-disruptive > migration path, not absolute forward compatibility. That is one > of the several reasons why the successor to HTTP 1.0 was > identified as HTTP 1.1, not HTTP 2. Indeed. This option was considered by the WG several times as people keep bringing up this same point. (I myself even a few years back). The WG charter is explicitly prohibiting addition of a new version number in these documents so there are several things like this which have had to be left unchanged. > This sort of change would still make HTTP 1.1 implementations > non-compliant with HTTP 2.0, but that is ok -- they still comply > with HTTP 1.1 and I hope no one is going to claim that all HTTP > 1.1 implementations are non-compliant with HTTP the day HTTP 2.0 > is published. Those existing 1.1 implementations will certainly not be compliant with 2.0 binary traffic encoding! But mapping between 1.1 with its useless GMT / day-of-week and the new improved 2.0 date format (whatever that may be) can be explicitly specified for the 1.1<->2.0 gateway translations in the new 2.0 implementations without altering 1.1 compliance for any existing or future implementations. The WG has chosen this approach over attempting a difficult upgrade within 1.1 itself. Amos From sm@elandsys.com Wed Oct 30 01:43:45 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF60811E8102; Wed, 30 Oct 2013 01:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.171 X-Spam-Level: X-Spam-Status: No, score=-103.171 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCq4Rx+9-TFj; Wed, 30 Oct 2013 01:43:44 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2D311E8265; Wed, 30 Oct 2013 01:43:20 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.128.39]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9U8gxju013206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 01:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383122593; bh=4X17+HyNpu5KNKrD3oCBWVG1PxRW/lRT16i5LF6scU0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=yAsUb2CYRcKeJiPQ6J12BlDmFFtMfv5PI6hJy6xWeryVZ3BI7DmgdSCbuuiY3HG5Y ckCZD8sQyW5G8FMsH9lMIVnS4t+bp2dix8UwKjKA7zgVT3f2REZUDGse1kE1MzprGz Z2aofggD6lqgjOxsN2lQFRM8/RtrvuRs5moVU0gg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1383122593; i=@elandsys.com; bh=4X17+HyNpu5KNKrD3oCBWVG1PxRW/lRT16i5LF6scU0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=B49zGi320ENoliAJZaUVguLz7rsSwt6Boy0+9VC+Oe2f3TuXEhO1IsgdBxaAWPRiN tnwH+aJ3TQC0rjhADNg6JGPhCM0Ov/esLZm1yiH/BUF0Vka5IKmjhLgc4DPkhrBPTz rSX0YXRpoCiNGILG+b8AH+RRYeEtMF4pVnAww5+U= Message-Id: <6.2.5.6.2.20131029214748.0b93d3b8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 29 Oct 2013 22:24:32 -0700 To: Julian Reschke , apps-discuss@ietf.org, draft-ietf-httpbis-p2-semantics.all@tools.ietf.org From: S Moonesamy In-Reply-To: <526E7154.2070005@greenbytes.de> References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E7154.2070005@greenbytes.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf-http-wg@w3.org, ietf@ietf.org Subject: Re: [apps-discuss] IANA issues, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 08:43:45 -0000 Hi Julian, At 07:14 28-10-2013, Julian Reschke wrote: >Yes -- this is not necessarily a problem. There are many things that >need to be defined for a new method, and not all of these fit into >the template. A DISCUSS about this can be easily addressed. :-) What is the intent behind the HTTP Method Registry (Section 8.1.3)? What information should that registry convey to the reader? For example, is it a quick way for the reader to find out whether POST is cacheable (re. a choice that a browser vendor made some time back) or should the person read the relevant specification text to get accurate answer? >That's an assumption that is true for all "bare" Section references. The problem is that people copy and paste them blindly. I suggest having information in the tables as the working group would like it to appear in the registry >The IANA Considerations are processed by the RFC Editor and IANA, >and they will make sure that the registry is properly populated. >There's no point in mentioning a still unknown RFC # here. It is up to the Responsible Area Director and the the document shepherd to make sure that the registry is properly populated. >What, precisely? I suggest adding "RFC XXXX" in the tables. I read draft-reschke-http-status-308-07. The reference is similar to what is in draft-ietf-httpbis-p2-semantics-24. They are two different drafts and that makes referencing only the sections ambiguous. RFC 6585 updated the HTTP Status Code registry last year. The current registry format only references the RFC number. I suggest making the change clear so that, in some distant future, someone working on this can figure out the details of the registry. Regards, S. Moonesamy From sm@elandsys.com Wed Oct 30 01:43:46 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B5211E8102; Wed, 30 Oct 2013 01:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.177 X-Spam-Level: X-Spam-Status: No, score=-103.177 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mmiVvGBRW8c; Wed, 30 Oct 2013 01:43:45 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A33311E8272; Wed, 30 Oct 2013 01:43:20 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.128.39]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9U8gxjw013206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 01:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383122598; bh=e1hoBZoErs6MEj9SLtqH4TRp+V6cTqky8NNWEeQOBPk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jdr/w7MRlZs08qNk0V6NT2bQtrGTWO5AR4/8hCaMlCTzqMTdB9UsSAalAkhhRbsJv E036U6rQQSoE+WxnUqyzgIyxDNMrL18gGoprALbPl7ZtPTkLncCwRMRWNhkpGeGHnQ exTvUu84D8W042ZdJaadNm0nvNs5889JdEAzEvlY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1383122598; i=@elandsys.com; bh=e1hoBZoErs6MEj9SLtqH4TRp+V6cTqky8NNWEeQOBPk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=im7v1pyPFXMX0IR8PlgiAyxowYjQ15MbBcsvktRme7X0v5hfKS2IttO0xFGAziJKM V+SxJuvvTO6/7kpMXrEAZ3Q0uybtxmuQEPL7Lv248RMWJhLXK6R1bji4oHZLV/TGwN 3O2rjVY+hGsYj9KGpJ4t+Ygb68cMupGvrqKXYYQQ= Message-Id: <6.2.5.6.2.20131029223814.0ce8c880@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 29 Oct 2013 23:26:12 -0700 To: John C Klensin , Amos Jeffries From: S Moonesamy In-Reply-To: <4F6568484E956ADBC46BEB16@JcK-HP8200.jck.com> <526F0EC1.7010809@treenet.co.nz> References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E6DF4.4030509@gmx.de> <751EE3ED19D0A62BD858585C@JcK-HP8200.jck.com> <526E73B8.90705@gmx.de> <4F6568484E956ADBC46BEB16@JcK-HP8200.jck.com> <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E6DF4.4030509@gmx.de> <751EE3ED19D0A62BD858585C@JcK-HP8200.jck.com> <526E73B8.90705@gmx.de> <4F6568484E956ADBC46BEB16@JcK-HP8200.jck.com> <526F0EC1.7010809@treenet.co.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-ietf-httpbis-p2-semantics.all@tools.ietf.org, ietf@ietf.org, apps-discuss@ietf.org, ietf-http-wg@w3.org Subject: Re: [apps-discuss] obs-date, was: APPSDIR review, etc. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 08:43:46 -0000 At 12:22 28-10-2013, John C Klensin wrote: >My understanding is that the HTTPbis work is a rather major >revision with at least some cases for which "get it right" is >more important that complete backward compatibility, especially >if there is a clear migration path. All of the usual arguments >for that are relevant, especially the ones that focus on how >many implementations and pages are likely to be created in the >future relative to those that exist today. Here, the clear >migration path would be a narrow and restrictive "send syntax" >and a permissive "receive syntax" that requires support of all >known older forms, _especially_ those that were recommended by >HTTP 1.1. Yes. >So, from my point of view, this isn't about introducing an >incompatibility with something that one merely regrets not being >done differently. It is rather more about what might be the >last chance to get it right and, in the process, eliminate >completely predictable future confusion and interoperability >problems. The argument is about code complexity versus what the working group charter says. It is difficult to review a specification when the current specification is still referencing RFC 822. I don't recall whether there are any other application-related specifications using "GMT". The HTTPbis drafts discusses about "GMT" when it actually means "UTC". At 18:26 28-10-2013, Amos Jeffries wrote: >However it is important to note that there is no clear migration path. Many >implementations are actively *rejecting* or ignoring date formats which do >not include the "GMT" moniker. That can be a problem. >Indeed. This option was considered by the WG several times as people keep >bringing up this same point. (I myself even a few years back). The WG charter >is explicitly prohibiting addition of a new version number in these documents >so there are several things like this which have had to be left unchanged. People usually keep bringing up the same point when a choice is not documented. I read what John Klensin wrote as during each revision of the specification the above argument is used to avoid making a change. Regards, S. Moonesamy From sm@elandsys.com Wed Oct 30 01:44:01 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7CB21E80F0; Wed, 30 Oct 2013 01:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.15 X-Spam-Level: X-Spam-Status: No, score=-103.15 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gsuwYCShZLy; Wed, 30 Oct 2013 01:43:58 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAD021E8096; Wed, 30 Oct 2013 01:43:27 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.128.39]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9U8gxk0013206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 01:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383122603; bh=03b49fo2DAGdas52zHjPMR9PGo8yGdLB30mQ8JleKew=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=sY4aJJIf8GHC1saeqv0076NyQy4FVVCdt8ff2IiJzDgOnDpQgwOAlDhfX/TWC9ARM doyso6nFH7fJey8nxLf0I5pyHddNEBIn4XNAmDPcsjDY4/aLe5xnBnGqTi2owk6hry inbzSU420J1b612ikw6W2Lxdvf/L/Cdpso5GGNeU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1383122603; i=@elandsys.com; bh=03b49fo2DAGdas52zHjPMR9PGo8yGdLB30mQ8JleKew=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cB2fGEHMKtv37Dvbl3Y7ZDXJlLCxnW5pfAuQM29EJdiwbei6BRskWhEB3NMOEvrtT 2z+0OHdcQQrRNwYNkQungXVv0iQqRuNXNuEnogrigh2p7hTbFV1m6Ju4ewaj+WBcmV QRu3KmwF6hYSv6jHSGjzPmM+DHuMbjoAryrQ4IKU= Message-Id: <6.2.5.6.2.20131029232953.0ce8cc58@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 30 Oct 2013 00:46:51 -0700 To: Julian Reschke , apps-discuss@ietf.org, draft-ietf-httpbis-p5-range.all@tools.ietf.org From: S Moonesamy In-Reply-To: <526FD3E8.9010904@gmx.de> References: <6.2.5.6.2.20131028101123.0e37a698@elandnews.com> <526FD3E8.9010904@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf-http-wg@w3.org, ietf@ietf.org Subject: Re: [apps-discuss] #506, was: APPSDIR review of draft-ietf-httpbis-p5-range-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 08:44:01 -0000 Hi Julian, At 08:27 29-10-2013, Julian Reschke wrote: >thanks a lot for the incoming reviews! I'm tracking them in the WG's >trac instance. Ok. As you understand how things work I'll defer to you on the issues instead of tracking down what has been addressed. >Well, it's optional, and we didn't want to make it a SHOULD. It adds >overhead to GET responses, even though only few clients will make >range requests. Ok. >Yes. Do you think this is a problem? Why? It's the kind of text which generates long threads outside the IETF. Some people can argue that it is a "may" written in uppercase while other people will argue that the plain English says something else. My preference is for the intent of the text to be clear unless there is a good reason not to be clear. > That's applicable to several drafts in the set. >"A server that supports range requests MAY ignore or reject a Range >header field that consists of more than two overlapping ranges, or a >set of many small ranges that are not listed in ascending order, >since both are indications of either a broken client or a deliberate >denial of service attack (Section 6.1). A client SHOULD NOT request >multiple ranges that are inherently less efficient to process and >transfer than a single range that encompasses the same data." > >..or it can serve the response as multipart/byteranges as requested. Ok. >> "If the selected representation would have had a Content-Type >> header field in a 200 (OK) response, the server SHOULD generate >> that same Content-Type field in the header area of each body part." >> >>I don't understand why the RFC 2119 "should" is used in the above. When >>can the "should" be ignored? Is the server supposed to generate the > >Dunno. > >>same Content-Type header field in each header area if the selected >>representation would have a Content-Type header field for a 200 (OK) >>response? > >That's what the above says, no? Ok. >Such as? What I mean is that what happens is undefined when both sides do not follow the RFC 2119 "should". >Right. Fixed in . Ok. >It is supposed to be interpreted per RFC 2119. It is better to use the uppercase words after the RFC 2119 boilerplate. Regards, S. Moonesamy From julian.reschke@greenbytes.de Wed Oct 30 01:48:45 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFB911E8118; Wed, 30 Oct 2013 01:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-2.450, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkF6Prix4aae; Wed, 30 Oct 2013 01:48:39 -0700 (PDT) Received: from central.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7643011E8296; Wed, 30 Oct 2013 01:48:22 -0700 (PDT) Received: from [192.168.2.117] (unknown [93.217.127.91]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by central.greenbytes.de (Postfix) with ESMTPSA id 48C7610C06EE; Wed, 30 Oct 2013 09:48:20 +0100 (CET) Message-ID: <5270C7D2.5010702@greenbytes.de> Date: Wed, 30 Oct 2013 09:48:18 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: S Moonesamy , apps-discuss@ietf.org, draft-ietf-httpbis-p2-semantics.all@tools.ietf.org References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E7154.2070005@greenbytes.de> <6.2.5.6.2.20131029214748.0b93d3b8@elandnews.com> In-Reply-To: <6.2.5.6.2.20131029214748.0b93d3b8@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-http-wg@w3.org, ietf@ietf.org Subject: Re: [apps-discuss] IANA issues, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 08:48:45 -0000 On 2013-10-30 06:24, S Moonesamy wrote: > Hi Julian, > At 07:14 28-10-2013, Julian Reschke wrote: >> Yes -- this is not necessarily a problem. There are many things that >> need to be defined for a new method, and not all of these fit into the >> template. > > A DISCUSS about this can be easily addressed. :-) > > What is the intent behind the HTTP Method Registry (Section 8.1.3)? > What information should that registry convey to the reader? For > example, is it a quick way for the reader to find out whether POST is > cacheable (re. a choice that a browser vendor made some time back) or > should the person read the relevant specification text to get accurate > answer? The template only contains a subset of the information, so in general, the reader will have to read the referenced RFC. The entries in the template serve the purpose of shortcutting this lookup for considerations that can be answered with a simple "yes" or "no". >> That's an assumption that is true for all "bare" Section references. > > The problem is that people copy and paste them blindly. I suggest > having information in the tables as the working group would like it to > appear in the registry > >> The IANA Considerations are processed by the RFC Editor and IANA, and >> they will make sure that the registry is properly populated. There's >> no point in mentioning a still unknown RFC # here. > > It is up to the Responsible Area Director and the the document shepherd > to make sure that the registry is properly populated. And the authors during AUTH48. There is no problem here. We will make sure that the registry gets populated properly. Trust me. > ... Best regards, Julian From duerst@it.aoyama.ac.jp Wed Oct 30 01:53:07 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448B611E818D; Wed, 30 Oct 2013 01:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.792 X-Spam-Level: X-Spam-Status: No, score=-101.792 tagged_above=-999 required=5 tests=[AWL=-2.002, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtH1ziOPlDAz; Wed, 30 Oct 2013 01:53:01 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id B531C21F9FBA; Wed, 30 Oct 2013 01:53:00 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r9U8pmE9007965; Wed, 30 Oct 2013 17:51:48 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 6990_8e4f_833d925a_4140_11e3_b8e9_001e6722eec2; Wed, 30 Oct 2013 17:51:48 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 4477EBFF5D; Wed, 30 Oct 2013 17:51:47 +0900 (JST) Message-ID: <5270C896.6080204@it.aoyama.ac.jp> Date: Wed, 30 Oct 2013 17:51:34 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Julian Reschke References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E8B9E.8030006@gmx.de> <6.2.5.6.2.20131029050405.0caf8b40@elandnews.com> <526FC24D.7060704@gmx.de> In-Reply-To: <526FC24D.7060704@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, apps-discuss@ietf.org, S Moonesamy , draft-ietf-httpbis-p2-semantics.all@tools.ietf.org, iesg@ietf.org, ietf-http-wg@w3.org Subject: Re: [apps-discuss] content inspection in absence of media type, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 08:53:07 -0000 On 2013/10/29 23:12, Julian Reschke wrote: > On 2013-10-29 14:26, S Moonesamy wrote: >> Hi Julian, >> At 09:06 28-10-2013, Julian Reschke wrote: >>> On 2013-10-28 09:07, S Moonesamy wrote: >>> RFC 2616 said >>> (): >>> >>>> Any HTTP/1.1 message containing an entity-body SHOULD include a >>>> Content-Type header field defining the media type of that body. If >>>> and only if the media type is not given by a Content-Type field, the >>>> recipient MAY attempt to guess the media type via inspection of its >>>> content and/or the name extension(s) of the URI used to identify the >>>> resource. If the media type remains unknown, the recipient SHOULD >>>> treat it as type "application/octet-stream". >>> >>> ...which isn't that different. >> >> The 'If the media type remains unknown, the recipient SHOULD treat it as >> type "application/octet-stream' from RFC 2616 is not in >> draft-ietf-httpbis-p2-semantics-24. > > I consider that sentence to be useless - if I can't detect the type, > what else but "treating as arbitrary data" is left as an option anyway? I have to say that I don't consider this sentence to be useless. As far as I remember, there are other specs (mail?) that say that text/plain is the default. So some implementers may be used to this, and apply it to http, too. Also, while every natural language text has to assume that the reader uses a certain amount of rational thinking, specs are usually written with a somewhat reduced expectation in that respect, not because the average reader is particularly dumb, but because the consequences of interpreting something wrong are different than the consequences of getting something wrong when e.g. reading a novel. So I don't see any reason for not keeping that sentence. Even if it doesn't help, it definitely doesn't hurt. Regards, Martin. From julian.reschke@gmx.de Wed Oct 30 01:57:15 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DD111E8193 for ; Wed, 30 Oct 2013 01:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.017 X-Spam-Level: X-Spam-Status: No, score=-103.017 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atcAhcxioJF5 for ; Wed, 30 Oct 2013 01:57:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id AFA2B11E8211 for ; Wed, 30 Oct 2013 01:57:09 -0700 (PDT) Received: from [192.168.2.117] ([93.217.127.91]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LguAU-1Vz0pJ2eH8-00oCpI for ; Wed, 30 Oct 2013 09:57:08 +0100 Message-ID: <5270C9DE.3000104@gmx.de> Date: Wed, 30 Oct 2013 09:57:02 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: S Moonesamy , apps-discuss@ietf.org, draft-ietf-httpbis-p5-range.all@tools.ietf.org References: <6.2.5.6.2.20131028101123.0e37a698@elandnews.com> <526FD3E8.9010904@gmx.de> <6.2.5.6.2.20131029232953.0ce8cc58@elandnews.com> In-Reply-To: <6.2.5.6.2.20131029232953.0ce8cc58@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Se9gwCJ4/BuuevtgYA9WTDv0W0eOgo1j25bO6mVL6NRgPz5lRSI LrPdXmGI3wjjN8Y0FSyQGfN7YMR9sInf0AW58htiJUvnJaWue3/9JsDDhzwDjkXp/7rwEJX ZMxs6yTf2TPEG7S4F1O+1jvwPBQCewHkLYhjzIQJdebGZOmzAWNpDSulHJx1I225IpSgEga uxccOFAehRG5wA8iwu0hQ== Cc: ietf-http-wg@w3.org, ietf@ietf.org Subject: Re: [apps-discuss] #506, was: APPSDIR review of draft-ietf-httpbis-p5-range-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 08:57:16 -0000 On 2013-10-30 08:46, S Moonesamy wrote: > ... >> Such as? > > What I mean is that what happens is undefined when both sides do not > follow the RFC 2119 "should". The response is self-descriptive, so it's up to the client to properly process it. >> It is supposed to be interpreted per RFC 2119. > > It is better to use the uppercase words after the RFC 2119 boilerplate. But then, we don't want the boilerplate to be in front of the Introduction. Any *concrete* suggestion how to address this? Best regards, Julian From duerst@it.aoyama.ac.jp Wed Oct 30 02:02:38 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E7B21F9FF2; Wed, 30 Oct 2013 02:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.715 X-Spam-Level: X-Spam-Status: No, score=-103.715 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBuDNZ3Y5b3e; Wed, 30 Oct 2013 02:02:32 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 157F411E828B; Wed, 30 Oct 2013 02:02:30 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r9U926CH024750; Wed, 30 Oct 2013 18:02:06 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 6994_f8b4_f3b34056_4141_11e3_b29c_001e6722eec2; Wed, 30 Oct 2013 18:02:06 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 20E96BFF5D; Wed, 30 Oct 2013 18:02:06 +0900 (JST) Message-ID: <5270CB01.9@it.aoyama.ac.jp> Date: Wed, 30 Oct 2013 18:01:53 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Amos Jeffries References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E6DF4.4030509@gmx.de> <751EE3ED19D0A62BD858585C@JcK-HP8200.jck.com> <526E73B8.90705@gmx.de> <4F6568484E956ADBC46BEB16@JcK-HP8200.jck.com> <526F0EC1.7010809@treenet.co.nz> In-Reply-To: <526F0EC1.7010809@treenet.co.nz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, apps-discuss@ietf.org, Julian Reschke , S Moonesamy , draft-ietf-httpbis-p2-semantics.all@tools.ietf.org, iesg@ietf.org, John C Klensin , ietf-http-wg@w3.org Subject: Re: [apps-discuss] obs-date, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 09:02:38 -0000 On 2013/10/29 10:26, Amos Jeffries wrote: > On 29/10/2013 8:22 a.m., John C Klensin wrote: >> My understanding is that the HTTPbis work is a rather major >> revision with at least some cases for which "get it right" is >> more important that complete backward compatibility, especially >> if there is a clear migration path. > > No. The focus on the WG has been to document what is actually *working* > and clarify existing HTTP behaviour in order to encourage interoperability. To clarify for people not too involved in the HTTPbis work: The HTTPbis WG has two main work items: 1) Moving HTTP 1.1 to Standard. That's what all the drafts are about that are currently under review and discussion in apps-discuss. For people familiar with Internet mail, that's somewhat similar to the work that happened when moving from RFCs 2821,... to RFCs 5321,... As such, it doesn't leave much room for innovation or even fixing stuff that looks broken from the outside, and the HTTPbis WG was particularly careful to avoid any such breakage. 2) HTTP 2.0: This is a completely new protocol design, so there is quite a bit of room for "getting things right", and stuff like using integers for representing dates (because the protocol is binary) is being considered. This on many fronts allows cleanup similar e.g. to what happened in EAI (Email Address Internationalization), because there's no deployed base to worry about. But HTTP 2.0 is not yet ready for general review. Regards, Martin. From sm@elandsys.com Wed Oct 30 02:02:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00EF11E8265 for ; Wed, 30 Oct 2013 02:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.432 X-Spam-Level: X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVUCuC2Hf+lE for ; Wed, 30 Oct 2013 02:02:50 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DA821F9FED for ; Wed, 30 Oct 2013 02:02:36 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.128.39]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9U8gxk4013206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 01:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383122612; bh=LBZ61wVZ9wle2+C8gt6aXMgQuWhtanoRfkL10vphevM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Q0o7EiW6ap3eJgc/mDjcpxOEp76helPmuMbsFkASExm8D2zNo/Eh7M29dozZZ26iJ 9/oifVDhcEH8y2YZQNpcwqvZKB9rMyzpT6kBRnB4TiuDsQ/jZGmFZ9Q+fQ5gcVvCPL VCaRR7ggzSiiTcKQWlWjnSaeZYsRSiAp3Q7Ex2As= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1383122612; i=@elandsys.com; bh=LBZ61wVZ9wle2+C8gt6aXMgQuWhtanoRfkL10vphevM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=D5PeMf2gyOe30JDt4vulJPl8hFrfJf/Nfu9neI1fVbR3swdoskTdwf96PRsbIzD3H NMRVPGjISeNNmCttZ2yKeJgeDqnTCUa+eovO2wL75YJrHR5/03cWIoybuuaXDNBXof ToOrNhyeD0yV2FatSzN9ePdpXwCHQlpKFnOtGzEY= Message-Id: <6.2.5.6.2.20131030013246.0ce8d550@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 30 Oct 2013 01:38:30 -0700 To: Julian Reschke , apps-discuss@ietf.org, draft-ietf-httpbis-p5-range.all@tools.ietf.org From: S Moonesamy In-Reply-To: <526FCE32.8090309@gmx.de> References: <6.2.5.6.2.20131028101123.0e37a698@elandnews.com> <526FCE32.8090309@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf-http-wg@w3.org Subject: Re: [apps-discuss] custom byte ranges, was: APPSDIR review of draft-ietf-httpbis-p5-range-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 09:02:51 -0000 Hi Julian, At 08:03 29-10-2013, Julian Reschke wrote: >Actually, it was a case of "this is used in the wild already, and >more use is coming up, so better document it properly and add the >registry". See > for the history. Thanks. I'll consider this as addressed. I gather that the working group is leaving what can registered as a range unit to IETF Review instead of providing specific guidance. Regards, S. Moonesamy From julian.reschke@gmx.de Wed Oct 30 02:48:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC6311E8102 for ; Wed, 30 Oct 2013 02:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.673 X-Spam-Level: X-Spam-Status: No, score=-103.673 tagged_above=-999 required=5 tests=[AWL=-1.374, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COoOP6Qw+9O9 for ; Wed, 30 Oct 2013 02:48:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id F0EB311E8118 for ; Wed, 30 Oct 2013 02:48:03 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lkwpt-1WBsza1y6f-00ao5T for ; Wed, 30 Oct 2013 10:48:00 +0100 Message-ID: <5270D5C9.4090004@gmx.de> Date: Wed, 30 Oct 2013 10:47:53 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E8B9E.8030006@gmx.de> <6.2.5.6.2.20131029050405.0caf8b40@elandnews.com> <526FC24D.7060704@gmx.de> <5270C896.6080204@it.aoyama.ac.jp> In-Reply-To: <5270C896.6080204@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:O6chdqnwPV4p7ngoMHDnB2S8BKvKFQyeWyB95K+Foa9nLMPhBl1 uyyRhLSNVI3B0+Do24S0GSt0MqAS7qE+W5eJNfZrkHyURLmtxk1XGB5F3CfqHpfkKTV39U8 2787EUJUoOVAjhT/ueOe2RRbQ/D8wiUp+kyXUrRQ8Jq19LKLDQdcjWtk7H9wHtP2DOCt7xI s1I8lUs7pR9D56Ue9sQXg== Cc: ietf@ietf.org, apps-discuss@ietf.org, S Moonesamy , draft-ietf-httpbis-p2-semantics.all@tools.ietf.org, iesg@ietf.org, ietf-http-wg@w3.org Subject: Re: [apps-discuss] content inspection in absence of media type, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 09:48:25 -0000 On 2013-10-30 09:51, "Martin J. Dürst" wrote: > I have to say that I don't consider this sentence to be useless. > > As far as I remember, there are other specs (mail?) that say that > text/plain is the default. So some implementers may be used to this, and > apply it to http, too. > > Also, while every natural language text has to assume that the reader > uses a certain amount of rational thinking, specs are usually written > with a somewhat reduced expectation in that respect, not because the > average reader is particularly dumb, but because the consequences of > interpreting something wrong are different than the consequences of > getting something wrong when e.g. reading a novel. > > So I don't see any reason for not keeping that sentence. Even if it > doesn't help, it definitely doesn't hurt. So what exactly does it mean in *practice* to treat something as "arbitrary data". What do you expect a browser to do in that case? Best regards, Julian From alexey.melnikov@isode.com Wed Oct 30 04:41:52 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93BCE11E811A for ; Wed, 30 Oct 2013 04:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.092 X-Spam-Level: X-Spam-Status: No, score=-103.092 tagged_above=-999 required=5 tests=[AWL=-0.493, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVFmVRvMgMKu for ; Wed, 30 Oct 2013 04:41:48 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id E665211E8115 for ; Wed, 30 Oct 2013 04:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1383133305; d=isode.com; s=selector; i=@isode.com; bh=A3u5JE+MnKbZ7Auq3NwlV2rwlWVZ/a8bd24ioUJv8rI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=KJFrNICMv7YKwqCQsbVyLT0na96Xc+dmCKe/CdiTEOJlGlkUJm0CA9fN8DMD9E4A6zWXwM OOQrob1GrhujOplibLypIczTRwpGOkP47y1oAhkDO0CAM/VsNwuYJ1amACs1dNVytL46W1 3FSxSY15M10QUrF4Ahyop1LQUYL/h/g=; Received: from [172.16.1.29] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 30 Oct 2013 11:41:45 +0000 Message-ID: <5270F07C.3010909@isode.com> Date: Wed, 30 Oct 2013 11:41:48 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: Bjoern Hoehrmann References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: discuss@apps.ietf.org Subject: Re: [apps-discuss] Comments on draft-melnikov-email-user-agent-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 11:41:52 -0000 On 21/10/2013 22:52, Bjoern Hoehrmann wrote: > Hi, Hi, Sorry for the delayed response. > Re http://tools.ietf.org/html/draft-melnikov-email-user-agent-00 I am > a bit surprised that `User-Agent` had not already been registered for > mail, given that it's registered for HTTP and Netnews, but okay... I was as well... > In the abstract, "registers User-Agent and X-Mailer header fields" might > be better as "the header fields User-Agent and X-Mailer". > > In the introduction, "User-Agent and X-Mailer are common Email header > fields for identifying any software (and its components) that generates > email messages." I think the emphasis should be on a given message, like > "the software that generated a message". > > In the second sentence, s/, for tracking/and for tracking/ probably. > > Also, s/NetNews/Netnews/ as far as the last Netnews RFCs are concerned. Ok, I will apply these in the next revision. > Inconsistent capitalisation of "email" in the first paragraph... I typically let RFC Editor decide this. I don't particularly care. > More importantly, it is not clear whether and if how the syntax of the > User-Agent header field is different for mail compared to HTTP and Net- > news. If it's the same as one or the other, the definition should be > through normative reference. If not, that needs to be discussed in the > document. (I see that there is a note about this at the end of the > section, but it is not clear whether it is meant to be exhaustive, and > there is no word about User-Agent in Netnews). It is effectively the same as in Netnews, except that the SP after ":" is not required, as historically that was not done in email. I could have pointed to the Netnews RFC, but I decided against it. I think people are more likely to find this in a standalone RFC. But I am happy to change my mind, if people have strong feelings about this. The HTTP format is a bit more restrictive. > The "MAY" should probably be something else, the normative permission to > use more than one product token is already in the ABNF and requirements > should not be spelled out more than once (use e.g. "can" instead, or if > you really want to use RFC 2119 keywords for this, add that it MUST con- > tain one -- and MAY contain more). This is just emphasizing that multiple are allowed. I don't think it is wrong. But I can change. > The definition of the X-Mailer header is missing. Good point. It is supposed to have the same syntax as the User-Agent header field. > There should be some note as to the purpose of Appendix A. I did an informal survey of some messages in my INBOX. I was trying to decide whether to use X-Mailer or User-Agent (none of the email messages I've seen have both, but some don't contain either one.) in an email client that I am writing. I was a bit surprised how widespread X-Mailer is. > FWIW, I do realise this is a last minute -00 version, and thank you for > getting these registered. You would not happen to know, and that is why > I read the document mostly, why many "recent" mail clients refuse to i- > dentify through these headers? I don't know. I think including one of X-Mailer/User-Agent is rather a no brainer. Some Microsoft products (possibly older ones) don't include these. But luckily they are easy to identify by presence of some other Microsoft specific header fields. > I am thinking horrendously broken web > mail products in particular. There ought to be a SHOULD somewhere to use > them, that would make repairing the mess they leave behind easier... Indeed. Although I don't think mandating this in my document is going to help much. > (https://github.com/hoehrmann/email-analysis/ and various postings to > W3C's www-archive mailing list are my latest efforts in the area...) > > regards, Best Regards, Alexey From julian.reschke@gmx.de Wed Oct 30 06:53:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA71B11E81DB for ; Wed, 30 Oct 2013 06:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.956 X-Spam-Level: X-Spam-Status: No, score=-103.956 tagged_above=-999 required=5 tests=[AWL=-1.357, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-3IP1vFyPsa for ; Wed, 30 Oct 2013 06:53:40 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 293D811E822A for ; Wed, 30 Oct 2013 06:53:40 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MQ2Tn-1VXPLl2o1T-005Esv for ; Wed, 30 Oct 2013 14:53:39 +0100 Message-ID: <52710F60.7060206@gmx.de> Date: Wed, 30 Oct 2013 14:53:36 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: S Moonesamy , apps-discuss@ietf.org, draft-ietf-httpbis-p1-messaging.all@tools.ietf.org References: <6.2.5.6.2.20131026225145.0bee7bb8@elandnews.com> <6.2.5.6.2.20131028091247.0e37b9d0@resistor.net> In-Reply-To: <6.2.5.6.2.20131028091247.0e37b9d0@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:M1fy09Zcn2kFbupmzfkT7+5xJ/4rCxEyzh4Ey+wU/hAPzFmWVpU 9ViT6dGUtiMetp9uAFFPsEt7/TO13JZx+Ca7WL/Nao3Yw7I17n7laJ9lTtk5uC77aNpRP2h PIJnuP2EwQd49nC+WOGzWrVAEt7tma5eYYSxQmFX+5PyVA0sHP/BlbrWgh6yi1pC5kyY9ys UlZ4YXWasOTVuBblyFsRA== Cc: ietf-http-wg@w3.org, ietf@ietf.org Subject: [apps-discuss] deprecation of HTTP header field line folding, was: APPSDIR review of draft-ietf-httpbis-p1-messaging-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 13:53:44 -0000 On 2013-10-28 17:55, S Moonesamy wrote: > Hello, > > While I was reviewing other drafts in the set I noticed that Section > 3.2.4 of draft-ietf-httpbis-p1-messaging-24 has the following: > > "Historically, HTTP header field values could be extended over > multiple lines by preceding each extra line with at least one space > or horizontal tab (obs-fold). This specification deprecates such > line folding except within the message/http media type > (Section 8.3.1). A sender MUST NOT generate a message that includes > line folding (i.e., that has any field-value that contains a match to > the obs-fold rule) unless the message is intended for packaging > within the message/http media type." > > There is an IETF specification which interpreted Section 4.2 of RFC 2616 > as follows: > > "the HTTP header syntax allows extending single header values across > multiple lines, by inserting a line break followed by whitespace" So yes, this is a change from 2616 that we made due to security problems (header injection). > I'll classify deprecating line folding as an issue. > > Section 4.2 of RFC 2616 (and RFC 2068) follows the same generic format > as that given in Section 3.1 of RFC 822. Section 2.2 of RFC 2616 states > that: > > "HTTP/1.1 header field values can be folded onto multiple lines if the > continuation line begins with a space or horizontal tab." > > I suggest that implementors of specifications which have a dependency on > RFC 2616 review the relevant section in > draft-ietf-httpbis-p1-messaging-24 about line folding and comment if > they consider the deprecation as a problem. Review is always good. Note that the change is listed in : "Header fields that span multiple lines ("line folding") are deprecated. (Section 3.2.4)" Best regards, Julian From sm@elandsys.com Wed Oct 30 10:20:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCE021E8135; Wed, 30 Oct 2013 10:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.479 X-Spam-Level: X-Spam-Status: No, score=-103.479 tagged_above=-999 required=5 tests=[AWL=-0.880, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mdu+x0hSN4L; Wed, 30 Oct 2013 10:20:41 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1E021E8144; Wed, 30 Oct 2013 10:19:25 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.154]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9UHIkA3029683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 10:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383153558; bh=A/n87butjfDIZlcNwmpbdRVoqtHbz8fPDDMr+9w3j7g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=f42ZCWZl821lUInpn08KzEQjz1CV8UyySIT9/PsFaO3SM5Up2a93L3PQqEc656n3b RXzDOiIJzPRC3rZweDh/bbkxTI17cqk8EksnIfkjqAFZh0y/kzCZAxCnZDjHRVo7Wo lRL0sEEupWjYIOrmkgfhyikkDUC9UFP5ojA6v+4w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1383153558; i=@elandsys.com; bh=A/n87butjfDIZlcNwmpbdRVoqtHbz8fPDDMr+9w3j7g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=my0VGwurWxjiYI587ONFCZURDjsN4It3iZxegrvGnso76MmdI57gVlX/dNhCnEQp8 f6wXzeiYguI0Pbb/2MrKNexdBxBm2XfZ3kDRYJXYgH6RPDd1MTzFDo00ae88sGcmvT J+wfRaj5ZYnr7lmU9EVkLWNi99U9rqa8Qg1PBE38= Message-Id: <6.2.5.6.2.20131030060359.0cb29068@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 30 Oct 2013 08:49:52 -0700 To: Julian Reschke , apps-discuss@ietf.org, draft-ietf-httpbis-p2-semantics.all@tools.ietf.org From: S Moonesamy In-Reply-To: <526FC24D.7060704@gmx.de> References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E8B9E.8030006@gmx.de> <6.2.5.6.2.20131029050405.0caf8b40@elandnews.com> <526FC24D.7060704@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf-http-wg@w3.org, ietf@ietf.org Subject: Re: [apps-discuss] content inspection in absence of media type, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 17:20:42 -0000 Hi Julian, At 07:12 29-10-2013, Julian Reschke wrote: >I consider that sentence to be useless - if I can't detect the type, >what else but "treating as arbitrary data" is left as an option anyway? I'll comment below. >I still don't get what the issue is :-) My preference is not to generate material which create more work for you. It's better not to pursue this one. :-) >The subsequent text is: > >"In practice, resource owners do not always properly configure their >origin server to provide the correct Content-Type for a given >representation, with the result that some clients will examine a >payload's content and override the specified type. Clients that do >so risk drawing incorrect conclusions, which might expose additional >security risks (e.g., "privilege escalation"). Furthermore, it is >impossible to determine the sender's intent by examining the data >format: many data formats match multiple media types that differ >only in processing semantics. Implementers are encouraged to provide >a means of disabling such "content sniffing" when it is used." > >Do you think this is insufficient, or that it needs to move to a >different part of the spec? The subsequent text is, to put it simply, about an operational issue and security considerations. The recommendation in Section 3.1.1.5 is to generate a Content-Type header field if the server knows the media type. There are cases when the server does not know the media type. In such cases the server sends the client "application/octet-stream". There is where the user has to determine whether the server is operated by good person or a bad person (re. arbitrary data). The user relies on the browser to perform some magic to determine that. That magic does not always work well. If it was my decision (and it is not) I would discuss about this under Security Considerations and mention that content sniffing can cause security problems. Please note that there are different alternatives to tackle the issue. Regards, S. Moonesamy From sm@elandsys.com Wed Oct 30 14:51:06 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC2211E81C9; Wed, 30 Oct 2013 14:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.523 X-Spam-Level: X-Spam-Status: No, score=-103.523 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsVQ4zuxrlU9; Wed, 30 Oct 2013 14:51:05 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E9811E80F1; Wed, 30 Oct 2013 14:51:03 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.154]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9ULolug011263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 14:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383169860; bh=SzsIHzfjl5wKnCjtGjoohKveXMH2e1ou1Azm/qSSB40=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=L4jI5cklLhqE05M4kqp+JPjpXODyRFZqhbdRey+cvhDqqcM1Xc9LUQ0Vv7XPX7mKe bMIF8m2hTF63LFiT7X/USI09Bvjzv7dneEiyiJwL82k+v9H7SZTu/ugqKuejYRgr9f cKzkwptPENZ1eG+Jf/j/3iixZK1cbF141AlPU0ck= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1383169860; i=@elandsys.com; bh=SzsIHzfjl5wKnCjtGjoohKveXMH2e1ou1Azm/qSSB40=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HX91AAsE9aN41mouJYUU8/cLF4P8ZiXfNIQFhSgOlS2phVFZc+la5pvMiN5EtyasQ lLbgFinXHPXAIHAPruE6skR4Xp1bi3x/++oGMSavn0YpjExZqqvdpFB2LQx6ix04Bh 1DHXHLRI7QhKJBgvfCvRikdMsrFGXmz/UhfoQXxc= Message-Id: <6.2.5.6.2.20131030141311.0cf57b20@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 30 Oct 2013 14:49:59 -0700 To: Julian Reschke , apps-discuss@ietf.org, draft-ietf-httpbis-p5-range.all@tools.ietf.org From: S Moonesamy In-Reply-To: <5270C9DE.3000104@gmx.de> References: <6.2.5.6.2.20131028101123.0e37a698@elandnews.com> <526FD3E8.9010904@gmx.de> <6.2.5.6.2.20131029232953.0ce8cc58@elandnews.com> <5270C9DE.3000104@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf-http-wg@w3.org, ietf@ietf.org Subject: Re: [apps-discuss] #506, was: APPSDIR review of draft-ietf-httpbis-p5-range-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 21:51:06 -0000 Hi Julian, At 01:57 30-10-2013, Julian Reschke wrote: >But then, we don't want the boilerplate to be in front of the >Introduction. Any *concrete* suggestion how to address this? The sentence about "OPTIONAL feature" can be added to Section 3 of draft-ietf-httpbis-p5-range-24. I would consider adding some text to the paragraph in Section 2.5 of draft-ietf-httpbis-p1-messaging-24 about "considered conformant". This is to make it clear which features are part of basic HTTP. Regards, S. Moonesamy From mnot@mnot.net Wed Oct 30 20:31:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D764021E80BB; Wed, 30 Oct 2013 20:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.694 X-Spam-Level: X-Spam-Status: No, score=-104.694 tagged_above=-999 required=5 tests=[AWL=-2.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HrO5PMwto2O; Wed, 30 Oct 2013 20:31:41 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 65E0921F9DE9; Wed, 30 Oct 2013 20:31:41 -0700 (PDT) Received: from [192.168.1.64] (unknown [118.209.167.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 39FA922E2CA; Wed, 30 Oct 2013 23:31:31 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Mark Nottingham In-Reply-To: <6.2.5.6.2.20131030060359.0cb29068@elandnews.com> Date: Thu, 31 Oct 2013 14:31:28 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E8B9E.8030006@gmx.de> <6.2.5.6.2.20131029050405.0caf8b40@elandnews.com> <526FC24D.7060704@gmx.de> <6.2.5.6.2.20131030060359.0cb29068@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1510) Cc: Julian Reschke , draft-ietf-httpbis-p2-semantics.all@tools.ietf.org, ietf-http-wg@w3.org, apps-discuss@ietf.org, ietf@ietf.org Subject: Re: [apps-discuss] content inspection in absence of media type, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 31 Oct 2013 03:31:47 -0000 SM, Consensus around this text was particularly hard-won; unless there is a = very good reason to make a change, I'd rather not risk falling into that = rat-hole again. Regards, On 31/10/2013, at 2:49 AM, S Moonesamy wrote: > Hi Julian, > At 07:12 29-10-2013, Julian Reschke wrote: >> I consider that sentence to be useless - if I can't detect the type, = what else but "treating as arbitrary data" is left as an option anyway? >=20 > I'll comment below. >=20 >> I still don't get what the issue is :-) >=20 > My preference is not to generate material which create more work for = you. It's better not to pursue this one. :-) >=20 >> The subsequent text is: >>=20 >> "In practice, resource owners do not always properly configure their = origin server to provide the correct Content-Type for a given = representation, with the result that some clients will examine a = payload's content and override the specified type. Clients that do so = risk drawing incorrect conclusions, which might expose additional = security risks (e.g., "privilege escalation"). Furthermore, it is = impossible to determine the sender's intent by examining the data = format: many data formats match multiple media types that differ only in = processing semantics. Implementers are encouraged to provide a means of = disabling such "content sniffing" when it is used." >>=20 >> Do you think this is insufficient, or that it needs to move to a = different part of the spec? >=20 > The subsequent text is, to put it simply, about an operational issue = and security considerations. The recommendation in Section 3.1.1.5 is = to generate a Content-Type header field if the server knows the media = type. There are cases when the server does not know the media type. In = such cases the server sends the client "application/octet-stream". = There is where the user has to determine whether the server is operated = by good person or a bad person (re. arbitrary data). The user relies on = the browser to perform some magic to determine that. That magic does = not always work well. >=20 > If it was my decision (and it is not) I would discuss about this under = Security Considerations and mention that content sniffing can cause = security problems. Please note that there are different alternatives to = tackle the issue. >=20 > Regards, > S. Moonesamy=20 >=20 -- Mark Nottingham http://www.mnot.net/ From duerst@it.aoyama.ac.jp Wed Oct 30 21:33:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563A011E830C; Wed, 30 Oct 2013 21:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.947 X-Spam-Level: X-Spam-Status: No, score=-103.947 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UVBrdxCK4cK; Wed, 30 Oct 2013 21:33:03 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 09B8511E830E; Wed, 30 Oct 2013 21:33:02 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r9V4WQAk032007; Thu, 31 Oct 2013 13:32:27 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 0263_5a55_718ee91e_41e5_11e3_866d_001e6722eec2; Thu, 31 Oct 2013 13:32:25 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 5B5F8BF4BB; Thu, 31 Oct 2013 13:32:25 +0900 (JST) Message-ID: <5271DD41.2030107@it.aoyama.ac.jp> Date: Thu, 31 Oct 2013 13:32:01 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Julian Reschke References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E8B9E.8030006@gmx.de> <6.2.5.6.2.20131029050405.0caf8b40@elandnews.com> <526FC24D.7060704@gmx.de> <5270C896.6080204@it.aoyama.ac.jp> <5270D5C9.4090004@gmx.de> In-Reply-To: <5270D5C9.4090004@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org, apps-discuss@ietf.org, S Moonesamy , draft-ietf-httpbis-p2-semantics.all@tools.ietf.org, iesg@ietf.org, ietf-http-wg@w3.org Subject: Re: [apps-discuss] content inspection in absence of media type, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 31 Oct 2013 04:33:10 -0000 On 2013/10/30 18:47, Julian Reschke wrote: > On 2013-10-30 09:51, "Martin J. D=C3=BCrst" wrote: >> I have to say that I don't consider this sentence to be useless. >> >> As far as I remember, there are other specs (mail?) that say that >> text/plain is the default. So some implementers may be used to this, a= nd >> apply it to http, too. >> >> Also, while every natural language text has to assume that the reader >> uses a certain amount of rational thinking, specs are usually written >> with a somewhat reduced expectation in that respect, not because the >> average reader is particularly dumb, but because the consequences of >> interpreting something wrong are different than the consequences of >> getting something wrong when e.g. reading a novel. >> >> So I don't see any reason for not keeping that sentence. Even if it >> doesn't help, it definitely doesn't hurt. > > So what exactly does it mean in *practice* to treat something as > "arbitrary data". What do you expect a browser to do in that case? Let's say ask the user. That's what they are doing currently, as far as=20 I'm aware of. I haven't checked every latest version of every browser,=20 but on average, I'd expect a dialog that asks whether (and then where) I=20 want to save the file, or with what application I want to open it. But of course HTTP cannot say that, because HTTP is about more than=20 browsers. But then, HTTP doesn't say what to do with data that is marked=20 as application/octet-stream, the same way as it doesn't say what to do=20 with data that is marked as text/html or any other media type. And that=20 seems just fine. Put another way, the sentence is not useless because clients already=20 have to figure out what to do with data marked as application/octet=20 stream. We just tell them to reuse and leverage what they have figured=20 out and apply it to unlabeled content. If a client implementer, e.g. for=20 a debugging tool, has figured out that they want to show=20 application/octet-stream as plain text assuming a 'charset' that shows=20 each byte separately, then it's fine for them to use that for unlabeled=20 data. That also means that the requirement is testable. Just check whether the=20 same happens for data labeled as application/octet-stream and for=20 unlabeled data. It may be difficult to automate such a test, in=20 particular in a test suite that is supposed to work across clients, but=20 it's nevertheless testable. Also, the sentence is not useless because it tells implementers to NOT=20 treat as any of the other available content types, and that's what's=20 important. Regards, Martin. From sm@elandsys.com Wed Oct 30 22:29:27 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5925E11E8200; Wed, 30 Oct 2013 22:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.564 X-Spam-Level: X-Spam-Status: No, score=-103.564 tagged_above=-999 required=5 tests=[AWL=-0.965, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dISD3tkySdt1; Wed, 30 Oct 2013 22:29:26 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F6D11E81C7; Wed, 30 Oct 2013 22:29:26 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.154]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9V5Sdap011994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 22:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383197334; bh=G3oHs+ULiNXdNnSeILvnkjIh0rte+oNIYoAwiq/gG70=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=iL/+RdZtg8+IDaDhuAXV6/Ngy1VvhrO1XXdQrTVk07IbCdMrsuWH6FkcFEPrX0rTD VwsLVUxQQhUn22BY+Q/ogY/JDJC3BMudySWZG3Z3zBTCooOt+TqjivF0+FQPcfrjKe Lys9qVteB0l5gWy27JbGJ6q//fzOCJmWXspVKHiA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1383197334; i=@elandsys.com; bh=G3oHs+ULiNXdNnSeILvnkjIh0rte+oNIYoAwiq/gG70=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=lOGRbhc8vRuoqaDZPmCEJLs2rsH+5CS+17U6AMxQf4xYXwnfQPPSx18PNcS5+ofGU 0QqKel5aIziVDIHBEkFVLAEuwYNR5+YFuVmQbutLkItp3hO3HOGajXmQb2lcNy8Kaf BDaCXSQm72vrPVDdXl6G0QQoFvPQ4XYV7o8yMCN0= Message-Id: <6.2.5.6.2.20131030221454.0de19bf8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 30 Oct 2013 22:24:58 -0700 To: Mark Nottingham From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E8B9E.8030006@gmx.de> <6.2.5.6.2.20131029050405.0caf8b40@elandnews.com> <526FC24D.7060704@gmx.de> <6.2.5.6.2.20131030060359.0cb29068@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf@ietf.org, apps-discuss@ietf.org, Julian Reschke , Pete Resnick , draft-ietf-httpbis-p2-semantics.all@tools.ietf.org, ietf-http-wg@w3.org, Barry Leiba Subject: Re: [apps-discuss] content inspection in absence of media type, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 31 Oct 2013 05:29:27 -0000 Hi Mark, At 20:31 30-10-2013, Mark Nottingham wrote: >Consensus around this text was particularly hard-won; unless there >is a very good reason to make a change, I'd rather not risk falling >into that rat-hole again. Understood. I'll copy this message to the Application Area Directors in case they have any guidance to provide. Regards, S. Moonesamy From vesely@tana.it Thu Oct 31 10:59:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07EF111E8164 for ; Thu, 31 Oct 2013 10:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.669 X-Spam-Level: X-Spam-Status: No, score=-4.669 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNbEodaEnCHS for ; Thu, 31 Oct 2013 10:59:27 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6900911E824A for ; Thu, 31 Oct 2013 10:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1383242362; bh=tYEa5MK7mEN643D1aujQDV5aZqDWYaWHJyufMI3/5Ig=; l=1578; h=Date:From:To:References:In-Reply-To; b=iQHrqcgMOzrN+bzk53YpG8e1jdrpaDhqY8vJf6wLtgqxcFGkIndQC12ZcsB3kWV+1 30RPQNEyNc3pj8/Hc94W1Z/Zjv889AFQa+S7QLrAr3RIyj4/954kNQ7/ZLl8Q/lcjY IOxuNtBanSJM2JNfBflXGXFZziGbXj3RudP+epn8= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Thu, 31 Oct 2013 18:59:22 +0100 id 00000000005DC035.0000000052729A7A.00007CEB Message-ID: <52729A7A.5060701@tana.it> Date: Thu, 31 Oct 2013 18:59:22 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <5270F07C.3010909@isode.com> In-Reply-To: <5270F07C.3010909@isode.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Comments on draft-melnikov-email-user-agent-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 17:59:32 -0000 On Wed 30/Oct/2013 12:41:48 +0100 Alexey Melnikov wrote: > On 21/10/2013 22:52, Bjoern Hoehrmann wrote: >> The definition of the X-Mailer header is missing. > Good point. It is supposed to have the same syntax as the User-Agent > header field. User-Agent and X-Mailer seem to have different syntax. The former often report multiple products, while the latter look rather unformatted, and quite frequently contain raw http URLs and other data which don't obey that ABNF, . >> There should be some note as to the purpose of Appendix A. > I did an informal survey of some messages in my INBOX. I was trying to > decide whether to use X-Mailer or User-Agent (none of the email > messages I've seen have both, but some don't contain either one.) in > an email client that I am writing. I was a bit surprised how > widespread X-Mailer is. It seems that a proper "Implementation Status" section requires too much boilerplate to be appealing. Anyway, you may want to add Alpine, Eudora, Gnus, KMail, Microsoft-Entourage, and Microsoft-MacOutlook, which have User-Agent, while Evolution, Eudora for Mac, and Eudora light have X-Mailer. ExpressionEngine and CodeIgniter have both fields; so does SquirrelMail/1.4.3a, but more recent versions have only User-Agent. [*] For Security Considerations, I think spear phishing should be a concern when too much information is being disclosed about users' system versions and languages. Keep up the good work Ale -- [*] collected from my mailbox: http://www.tana.it/mailers.txt From superuser@gmail.com Thu Oct 31 12:05:39 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809B711E814F for ; Thu, 31 Oct 2013 12:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoGwl+L0SV7U for ; Thu, 31 Oct 2013 12:05:39 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id CA18C11E823C for ; Thu, 31 Oct 2013 12:05:36 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id ex4so167617wid.9 for ; Thu, 31 Oct 2013 12:05:35 -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=UN+ACix8CNDAXrqB3XSDv7YS8OvUBhMXPaYf4++xiiU=; b=IvZTLsK8xug7kQnuYew2YW44tTMW7LlvqQ3P1xOK3iHf7ANTUqLjGvjyES6rhOfZtH AbxsPrs4dY2CE+dWsaCxGMzQUzknYJXuOl3snoimrL2ww/Ri7YyRZqgJpuuk48HfzTWU OkNOyxwoBeiyAHeBOetRvdLqYm23htsfFGRHcrWx7ykcCnxcQjFBcq4uCJ7C9IQ4C4D9 gWJUEpboy43Plzaxnd33q2tvDUPbaH+QB9S33DQmXdXWs2AoV0XXe6PAmdh4J9yxXLNk 0uoYUt8MHI4MOzxxIqRlrfzE1rU1cuc5soj3N/H7ZllbgxMk7rMss6/umKoLtNKPleP6 Hobw== MIME-Version: 1.0 X-Received: by 10.180.79.230 with SMTP id m6mr727857wix.19.1383246335824; Thu, 31 Oct 2013 12:05:35 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Thu, 31 Oct 2013 12:05:35 -0700 (PDT) Date: Thu, 31 Oct 2013 12:05:35 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d044403787bda8a04ea0e2286 Subject: [apps-discuss] Revised IETF 88 APPSAWG/APPAREA agenda posted X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 31 Oct 2013 19:05:39 -0000 --f46d044403787bda8a04ea0e2286 Content-Type: text/plain; charset=ISO-8859-1 http://www.ietf.org/proceedings/88/agenda/agenda-88-appsawg We are still finalizing the security-related presentations, so there may be one small update between now and Monday. See you all there! -MSK, APPSAWG co-chair --f46d044403787bda8a04ea0e2286 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We are still finalizing the security-related pres= entations, so there may be one small update between now and Monday.

See you all there!

-MSK, APPSAWG co-chair
--f46d044403787bda8a04ea0e2286-- From msweet@apple.com Wed Oct 30 05:38:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C394621E80B7; Wed, 30 Oct 2013 05:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.053 X-Spam-Level: X-Spam-Status: No, score=-8.053 tagged_above=-999 required=5 tests=[AWL=2.546, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrh4eFIaOnWl; Wed, 30 Oct 2013 05:38:04 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id D870F21E8064; Wed, 30 Oct 2013 05:37:57 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MVH00657F2ZZH02@mail-out.apple.com>; Wed, 30 Oct 2013 05:37:49 -0700 (PDT) X-AuditID: 1180715a-b7f3c6d00000020e-ed-5270fd9a0d3b Received: from [17.153.58.123] (Unknown_Domain [17.153.58.123]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id A2.27.00526.B9DF0725; Wed, 30 Oct 2013 05:37:49 -0700 (PDT) From: Michael Sweet In-reply-to: <5270C9DE.3000104@gmx.de> Date: Wed, 30 Oct 2013 08:37:46 -0400 Message-id: References: <6.2.5.6.2.20131028101123.0e37a698@elandnews.com> <526FD3E8.9010904@gmx.de> <6.2.5.6.2.20131029232953.0ce8cc58@elandnews.com> <5270C9DE.3000104@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1812) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUiONOqWnfu34Igg4ev+CxWv1zBZnHnwC02 i8Mts5gsnm2cz2Kx+eEbVosj32ItXvXfZHVg99h68gebx703H5k8PnyM81iy5CeTx5fLn9k8 js7bzxrAFsVlk5Kak1mWWqRvl8CV0fe0i6XgHVvFpZ6ZzA2Mu1m7GDk5JARMJP6vv8QOYYtJ XLi3nq2LkYtDSKCXSeLAxKmMIAlhAQ+J44u7mUBsXgE9iSuPt7OA2MwCOhI7t95hA7HZBNQk fk/qAxvKCWRvm3WXGcRmEVCV+H+xgwlkKLPAdkaJ9z3f2SGatSWWLXzNDDHURmLLz5lMEJsX M0osv7cYbKqIgJbE7Xt7ga7gADpPVuLTYbMJjPyzkNwxC8kds5CMXcDIvIpRoCg1J7HSTC+x oCAnVS85P3cTIyiYGwqjdjA2LLc6xCjAwajEw9v5KD9IiDWxrLgy9xCjBAezkgjvqY8FQUK8 KYmVValF+fFFpTmpxYcYpTlYlMR55f2AUgLpiSWp2ampBalFMFkmDk6pBkZhdfN1hvu3ntf0 b9dR/zVVpO1ZqUv57IRWnTMGnyrP3pH8/9Nv31vxnqSIv7PO6vw5a21vIsWddn+dlWLP4ZTp U5vm+/5UZHyTUnfD+4Oiusi7Wi/+D3fO5pSuutaRFmY1c3Vh+3H/vcZHVSVC+yX3Xsvany1n /uWDcS+br53Gu4JTvEqNnkosxRmJhlrMRcWJAGu77hhiAgAA X-Mailman-Approved-At: Thu, 31 Oct 2013 20:54:14 -0700 Cc: "ietf-http-wg@w3.org Group" , ietf@ietf.org, S Moonesamy , apps-discuss@ietf.org, draft-ietf-httpbis-p5-range.all@tools.ietf.org Subject: Re: [apps-discuss] #506, was: APPSDIR review of draft-ietf-httpbis-p5-range-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 12:38:10 -0000 Add a forward reference to the boilerplate after the uppercase word? On Oct 30, 2013, at 4:57 AM, Julian Reschke wrote: > On 2013-10-30 08:46, S Moonesamy wrote: >> ... >>> Such as? >> >> What I mean is that what happens is undefined when both sides do not >> follow the RFC 2119 "should". > > The response is self-descriptive, so it's up to the client to properly process it. > >>> It is supposed to be interpreted per RFC 2119. >> >> It is better to use the uppercase words after the RFC 2119 boilerplate. > > But then, we don't want the boilerplate to be in front of the Introduction. Any *concrete* suggestion how to address this? > > Best regards, Julian > > > _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair