From nobody Tue Dec 1 01:58:40 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271E81B3A35; Tue, 1 Dec 2015 01:58:36 -0800 (PST) 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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKA89VYfnnlU; Tue, 1 Dec 2015 01:58:34 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437C81B3A26; Tue, 1 Dec 2015 01:58:34 -0800 (PST) Received: from [192.168.1.158] ([5.10.171.186]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Me8ws-1ZetA11r6U-00Px1l; Tue, 01 Dec 2015 10:58:31 +0100 To: ietf@ietf.org References: <20151120205655.17511.99851.idtracker@ietfa.amsl.com> From: Julian Reschke Message-ID: <565D6F4A.6060007@gmx.de> Date: Tue, 1 Dec 2015 10:58:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151120205655.17511.99851.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:t4Iz6SU+Tf6SwMri4A7ZSjWW7Zu2j4Ffc9cIw3oydo7OIdlyBhW PKLnG9qTkLQ//gETI0tVFvy+YG9rFgOE/s1Wsez8PQo5VJl3Gp58Fs0MCIqvoMQkuOFWMcf VI/iD6rFiqweh1lSsJUVYw+AjdeHEPF2BiJFn+FVmNGpbDdOL95mto+uvYcWUPAWMurGZMQ LLBFkACRlSDyn+tfaA+fQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:n9ASk9yCK94=:SsfGdaX048eg7MKf3VGxWm mrwGuoI9DF8IYTu9iuNunmPu9awxG76bFxZuCbf91MMjiYgeWLq14vD+ZaxTeeylpfSSRdymu n4at4YW4UqWerB1GBhipE90/bAXb3K0pSYWwKjJEOj5uOh5BhbPjaucygak408K88BhCQx/1G hN7HKvIaJGBTv+sXKeOr5SPbPOIIqaMQVOeTArTzdGk1EaCVO4CvuCTsOeOJP7foqscvDtq7l 3g9CjSbmz1q0NdJ8OXPt75kLU5u1RMDnz/1id1Ry7rJWs1H6Aepz9LxWw5Vb1Q7gZ9E6LZ1eY 0IJ5u0mMe2pvtErZiOjKDhXh4owMkhIftEo1uzPMFjeCZgCS7yfiXrrDduaVXUAqype8qjD2K MYrGcXsVTpEMVU0kV6IGLM6jaU1/EIiJ1oHWRVwpDx0zhd2oRExAHs6vaTw7rpLzIrpN77PGM Z45FioTJM/+7MB1y8dxjsicfrz7ZptQOfgpJfEHqcYKk1pXP6JnsAPUCE7EXvFqhu/AFnzbRO mE/D5o/42cZpTAC1932Qf5f3aCqN+2lUlZyD4PpmPIMF4NfjMs046Gj/11BefYIVmGRLEYSjn zEyIf0AL8ajUDd6nvM4QzYf5ezrrZSYQhOLJFhddj91Qc+IUhtiArSvNB1QFoKgTvV1eZvEDm jJQEH8TrgklTeM/1MiTuw7aV/7gYZAmV+31b2RcQZMnnmRgRFh32m/dOZprPF/YZu/eanAgHJ +eOPvMSpGzZHECPGlSLhLY5K6ODs+saBZ9RFHzcidvYcwNO1xzws535a6ljy58RTgIjZFLguC WVVvWHt Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-http-problem@ietf.org, apps-discuss@ietf.org, barryleiba@gmail.com Subject: Re: [apps-discuss] Last Call: (Problem Details for HTTP APIs) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 09:58:36 -0000 On 2015-11-20 21:56, The IESG wrote: > ... Minor nit: the media type registration templates miss a few fields defined in . Best regards, Julian From nobody Tue Dec 1 02:16:33 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60A21B3A77 for ; Tue, 1 Dec 2015 02:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Daj5K2fb69PI for ; Tue, 1 Dec 2015 02:16:29 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0777.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::777]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A6381B3A73 for ; Tue, 1 Dec 2015 02:16:28 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 1 Dec 2015 10:16:09 +0000 Message-ID: <01be01d12c21$123410c0$4001a8c0@gateway.2wire.net> From: t.petch To: Matthew Kerwin , IETF Apps Discuss References: <20151201004350.6084.94598.idtracker@ietfa.amsl.com> Date: Tue, 1 Dec 2015 10:14:20 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: DB5PR01CA0065.eurprd01.prod.exchangelabs.com (25.163.24.33) To AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB055; 2:pQWFK2IyLWa5Tjuc8HBPtmf0IhJ/ovAyDwGF+JluL5uXuEDN5o7zBs7JZxdaqp4NNmA7LQqAbxfCQjTheC9/YxBnBnWLQ0RYK1o6nILNxt2F+eh37XA15eUiYyLeZ+MPi7r05vB8WeQ20qehgA06PA==; 3:LKtqF2SF7yyivkFaH88wYtCOpTyVTWJ4h6JstmA/RkXqHUSarR1SdDyLFWTg/8UrWOx8XBnkCW+YS68Z0VginSe8IU2Zk36c1TGDPJ716fstKHkLjh0MvUAiLJFru0MP; 25:iaUObmVDHk9S8JSXBdfsyWJgoAw2EnATIh1BCSgepHqBcFnvMsA8ia8WRsne6zPKHTBPBrGbE5EEwOlHDl+/1c2YHP255ARx6LA+0PqZr6TOuEQdYH3l6dxjQTdRVPUWjUMp3JW3XtqfQbCnlNzsHU6Xjt8iB9eDqiZTwu++EYeusJYYuDIeXh8KS8/6spdZC8oREm8PvxYPg0NOFdVVasJAYCR+kyzajQ8fhce1B+sSW0LDsqgSQs7OfmlP4iCJAhP0D3ydLeJBA3sBCebAjg==; 4:CX7S/NdtaIVnsRoDu5M1lBY9riVpEHWTn+k+ebmUjYVY1oRcIa1WL3AZHuKsJyptBa61IlkmstPo0Sh5yInVj6DgzvubnNIzo7PCJtNOyPIO5tY7eMBBYbN4T2CblLsNc2TW4pqmTLQAUm4oJlgUWYtNL71dgkJO1g6qYAa6K6kiHfX/xFljikKBpsp1ahaj60zqJA7ooXp0i6z+2RNOPSgQ+KW1sjSb/zB6A2+Xv7JpWH7E1Ya0sqPlHLjpYZw5EJJvIRwKZr3qznNafw7fSpeIZL+twYS6Q4CKCH4f8PCuvrcbDIQ8CRl/b+lJlG2qji9KhCMXin+GvFAs7GDu/HI8Rke9t4ycyGCV/6m5VkePgvipm9EOUppmAlaqCqYA X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:AMXPR07MB055; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB055; X-Forefront-PRVS: 07778E4001 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(13464003)(199003)(377424004)(24454002)(77096005)(61296003)(4001150100001)(106356001)(1456003)(230783001)(50986999)(15975445007)(5820100001)(50226001)(33646002)(19580405001)(5001960100002)(5008740100001)(19580395003)(23676002)(116806002)(81156007)(189998001)(5001770100001)(107886002)(44736004)(50466002)(76176999)(92566002)(101416001)(3846002)(62236002)(40100003)(230700001)(105586002)(5004730100002)(97736004)(81686999)(586003)(81816999)(86362001)(42186005)(87976001)(66066001)(1096002)(44716002)(1556002)(14496001)(47776003)(122386002)(6116002)(84392001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB055; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTVhQUjA3TUIwNTU7MjM6OWIrYURjWlpuRUhBbmJra2FLcFVxZmVVWkVL?= =?utf-8?B?UEgrMEpOQ0lkVUFUb3Y0K2txYVVHdzR2NXJIeElEa0FIMlN5MkNKcXJ5WTND?= =?utf-8?B?MTBXWldLYnpPU1FaWHZLNzE5ZlMwVW5tK0NRbGxXOXZQMS9ialBGc045REFl?= =?utf-8?B?YkxPRjhFaGJxSUY5K3FQQUtzVENkM1Z1V0xFb1R0a1pvVVN4OEZqd08yQmFy?= =?utf-8?B?TTg4SHVNdTNCQWFLTTJSZTdTSGRmK3U2aTFjTldtMkNLYk0rY0xZWHV4VWhJ?= =?utf-8?B?NzhWeDVEQVk3eldPN3NOL2grVk5idmpNb3NRNFpzcHlyNXlPYTRQdy9QYjJa?= =?utf-8?B?WXpUcEVkWndvTkpxOUVORysxRTBINDRWMEpBc084OGp0cXJZM2NrVlpONldl?= =?utf-8?B?NmU1em1sTktya2pnOGJNQm9kcWZ0OSs1RDNjeXlRay9WR0NoazJJbTNVc3Rw?= =?utf-8?B?NHZpL0hTSGR2dk1wMWNXYUZwcDBFTjFZanRxN3N6aVJpaHo0Ny85bnJRUEJw?= =?utf-8?B?akN2NVRpTUE3YnFrT1N1dzJveS9hcmlncmNhdFZsZGJKVlV1UDh1bjRIN2Y3?= =?utf-8?B?eVJxZk0xNEN6SlRGTlk3ZDdlUXNPSnFOMTF4Y3NWSEVHdnpyZDI4cFE5WUlk?= =?utf-8?B?aWlENFNucEduR3lNUnNJa3A4ZkdkTjZobDZYNVVsSVcxVWQ0aTJzVEVnQTVl?= =?utf-8?B?WXZpOStzMThQZ3VuU0xCeWFKcHFEV3BmanJhMnhUb1c3Y2gvamFPck1YNTd3?= =?utf-8?B?VkFwb1F5azBudE11Ykh2U3N5SzErSUtwSDhWS3ZJSk5ndDFNbnpSZkt4czQ0?= =?utf-8?B?MERqSGpscHdPRm1kOXRqNjZxbTIxRmxCUllSTFhCaUx5ZU13bDV5UCtVWXZO?= =?utf-8?B?eHA2OVd2S3dqd2pjUHg3STkxeGI5QXJJc2pWakFsa1orY1VYbDV2RzNuWjRE?= =?utf-8?B?VXFnRUMrWjl4bjJMQ3RDdURZR2NGNDlmU0ZoZmRvT0d0RHBhdzB2SG80bjJy?= =?utf-8?B?Zkp4bFJFcEZxVkxlSmo2d2dmOFFYU2s0U3pVb0RBekJhWjM4aHREWnltYzY5?= =?utf-8?B?Y3dGd1ZGRldydFJXNFV2eDVnT2NlbCtxbG9XZ2dzRW04OUFMRWtsK1BiNlpk?= =?utf-8?B?YVNCTWJsWDQvdVpLbkZBMjNlbldqUnllU1dQRFBhNC8yVUNwN09rY2dHVkYx?= =?utf-8?B?MXJ2Q05Bb3B4VU9nZmJ2bGUySDYwRDRrYWFXdjFNMzEwaFY0V1VHQTVPNitm?= =?utf-8?B?TVNzRUMzeW40NHRvVEMwZDMrMjZOWHA2MG1JaFZzZ3dIMVFxSnlZeGJnZXZM?= =?utf-8?B?L3Z0TTRaZkowRU9XNlpTQjlFRzhTYmVFSEtSVi9qZ2xxVXQ5UW8yYUlldG5B?= =?utf-8?B?NmFJOGdmeEk3RHptVlVsOUs3NDlPbVoxUFAxdFF3bDFmeDVMOTl5RVRBSGVE?= =?utf-8?B?MmNnN3lHV3RBdUdvUDRseWQ5UnluNHE1MDJsekMrZWJEbEQ5ci9GZGcwT2tX?= =?utf-8?B?K1puREF3Q3c1ajRlaWlsM2FucjVlaWxTNVpJbHZWNkVrUGxaMy9Mdlo5bHZO?= =?utf-8?B?NUJLdFRUcHM2RFZpSTBPeDcrdlBZZXRpemQvV0ErYUNUeVFENFZkSHA4bSs1?= =?utf-8?B?VXZ2dzZ1NzAwSVhHNGNvSkVoLzhFZU9hL0U2M2JweU1CamEydnhCODRFVG80?= =?utf-8?B?NGlpR1hFMDZoNnZnajU2ZUg2NWRxM0lwU0FEZmp6QXZZbFJXVVcvVkUxVVRI?= =?utf-8?B?Q1YraFFPMzVaVjFTRlZNdVRPM3pWZ1hENEVScnFyRzBjUFQ1dERFeWczNWw0?= =?utf-8?B?ZGFZOG1uRGlNM0VuM051VHNveS9lSlRSOFZZc1l2SjQ0S0V2cWJObi9SK2R6?= =?utf-8?B?UmV6SmJjYnByZzlHeTBHcWcrbXJPYkoxbFY1RkxHNnpTdm9qNUR2MlhwcGw5?= =?utf-8?Q?FUtdjnjFEhRafCjHEsb99ypoeDBVw=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB055; 5:MNdMy3Em4gXb+LN2iA8wB3cj0vOWjaecmcRHukWfXv9XNb4xq2wufUO3mZAhEUE/JNTfshQ4S0tGKrr9l5NKQIgzGaVSwJa1LUtHiXT2/Be6ugn3mmkPquCb7jY8eijhLYNbLvHvHD4GuNrU4BIsbQ==; 24:JsSVcTi9XyAUV2Ng6SOspaYYKY55rAbNdebArbzO+RY3i3f+tDkez0LXW+YMX1kezCJS93NG+mj2BOhuARQDLgisRroDNRhZ5fcErNLD+sA= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Dec 2015 10:16:09.9735 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB055 Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 10:16:32 -0000 Looks good. I like the /en-au/ in the Microsoft URI! Tom Petch ----- Original Message ----- From: "Matthew Kerwin" To: "IETF Apps Discuss" Sent: Tuesday, December 01, 2015 12:56 AM > Hi folks, > > I've pushed out a new version of the file URI draft which I believe > addresses most of the feedback received over the past couple of weeks. > Looking at the rfcdiff[1] the biggest changes were: being more clear about > how we're using/overriding components like "authority" from RFC 3986, and > rearranging the examples throughout the appendices to be "description - > example" (from "example - description".) > > I also misspelled "ooperation." :\ > > Cheers > > [1]: > https://tools.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-05.tx t > > > On 1 December 2015 at 10:43, wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the ART Area General Applications Working > > Group Working Group of the IETF. > > > > Title : The file URI Scheme > > Author : Matthew Kerwin > > Filename : draft-ietf-appsawg-file-scheme-05.txt > > Pages : 20 > > Date : 2015-11-30 > > > > Abstract: > > This document specifies the "file" Uniform Resource Identifier (URI) > > scheme, obsoleting the definition in RFC 1738. > > > > It attempts to define a common core which is intended to interoperate > > across the broad spectrum of existing implementations, while at the > > same time documenting other current practices. > > > > Note to Readers (To be removed by the RFC Editor) > > > > This draft should be discussed on the IETF Applications Area Working > > Group discussion list . > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-05 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-05 > > > > > > 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/ > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > -- > Matthew Kerwin > http://matthew.kerwin.net.au/ > From nobody Tue Dec 1 02:57:58 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1ECB1A89FA; Tue, 1 Dec 2015 02:57:55 -0800 (PST) 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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2hRCdjJq8-m; Tue, 1 Dec 2015 02:57:54 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA8B91A89F6; Tue, 1 Dec 2015 02:57:53 -0800 (PST) Received: from [192.168.1.158] ([5.10.171.186]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MJGFi-1a23vX09j0-002mc9; Tue, 01 Dec 2015 11:57:05 +0100 To: Erik Wilde , ietf@ietf.org, appsawg-chairs@ietf.org References: <20151120205655.17511.99851.idtracker@ietfa.amsl.com> <565D6F4A.6060007@gmx.de> <565D7AD6.4000908@dret.net> From: Julian Reschke Message-ID: <565D7D03.8060809@gmx.de> Date: Tue, 1 Dec 2015 11:57:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565D7AD6.4000908@dret.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:bUa8fjzRuxbgAom3+b66L293nyngDfedAiI3ncOXdqXPp4fp5An 8mO6t7EVzpss3nVmsdP+EXWk0Z0XjvbirxdjA8VXs4R8qzv/VH1zmaMzHRvu/w1GAqO1VER sNkZcjR0oL6A0bSAHZIE9jqxxEr9bWKLqJSHkEtIfRo3FaVh7A63lXfUOHoqcKBhjeiZJx5 iJ7C6RpzIGWHbjMfeUZWA== X-UI-Out-Filterresults: notjunk:1;V01:K0:VvFT0tUliWw=:mYdKqXBLNbF/hu2wPpZ4gO VK8okFJP3AuV4dX4Wz1b3bK/cIifhpDb7o+P+JMRnJhhzqXVw1SDMmeUP+Qoh7rzrqu83Xv01 rQMAit/v8uVSyh8VgRJgN/+k6iM3odPHuigYFjsik80EmjGjAce8oiV08TmutGQIvpu1eeVdC h8LX0oZGxFqgKSh9n7lxajZICd8jb9pd3fvSPs/DKWqzVFvSHy7C5MUWAeLjtDqOsm1wYwUfG jEHh+N7dpuacf9A7qRNx/QaZnkkzykKKjTI7rUMmfMA2NhURRo2FRP+hjhV4KkrJZTvrUPEac 5EmJXBMNVhTVNG0tcOpdejNvnW0KIn0O2bPv11+3IlnuEN1Lav2UhFZt08+SCPU+3+Rgg097y nVlYn0oIaVdkdLi7BgzHVM7Dgi2G8Pb4K3A3f7EXmK8Ne9pgPQL/v9Dstf7+doMeAxeKEX+Wu OQN307uEUpxht9Bgpc6uxxec+Ds+a8LHL2VRKQ+DxTzmVumAv3HLfalxpZIB6D4QzWGBzcZA4 +UanDFTOH7rH2DzD+ve4Yt8XGiDolpDrxCbE2tmz8GodG8drdqdan+jSa3oTblsXKiNtTv0RX dN9qh8ts0Vl8/F7HUE16X14g2Ax+6rs5abYo9f420hoioZsXSwSUqt3t31J8cYWUyRjEdlfEq 4A476x7aFZlZ4NvUoe2fKHyuOxN6e3+9zby8NesM0Z183XsgWAQ3f+AW6qO8W9jcv0f0jp5j1 j7PkBon5g3k2AYHWv6tVbheIzRS77vz6Df/h9yldO+ywet7cJjebb6bhYONj5dSzPE/vPc3vt ZTNs1tY Archived-At: Cc: draft-ietf-appsawg-http-problem@ietf.org, apps-discuss@ietf.org, barryleiba@gmail.com Subject: Re: [apps-discuss] Last Call: (Problem Details for HTTP APIs) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 10:57:56 -0000 On 2015-12-01 11:47, Erik Wilde wrote: > On 2015-12-01 10:58, Julian Reschke wrote: >> On 2015-11-20 21:56, The IESG wrote: >> Minor nit: the media type registration templates miss a few fields >> defined in . > > i could only find one and https://github.com/mnot/I-D/pull/162 is adding > this last one. which other ones are you missing? > > thanks and cheers, > > dret. "Fragment identifier considerations:" ... Best regards, Julian From nobody Tue Dec 1 04:17:05 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B9B1B2B0F; Tue, 1 Dec 2015 04:17:01 -0800 (PST) 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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMpguhEf1qxi; Tue, 1 Dec 2015 04:16:59 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18FC01B2A51; Tue, 1 Dec 2015 04:16:58 -0800 (PST) Received: from [192.168.1.158] ([5.10.171.186]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LwF9u-1aMxGw16j8-01860I; Tue, 01 Dec 2015 13:16:08 +0100 To: Erik Wilde , ietf@ietf.org, appsawg-chairs@ietf.org References: <20151120205655.17511.99851.idtracker@ietfa.amsl.com> <565D6F4A.6060007@gmx.de> <565D7AD6.4000908@dret.net> <565D7D03.8060809@gmx.de> <565D869F.7010705@dret.net> From: Julian Reschke Message-ID: <565D8F8A.3050601@gmx.de> Date: Tue, 1 Dec 2015 13:16:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565D869F.7010705@dret.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Q1/1vNM4hGF6Ww7EOk5gKouLfv3T1PLpnOHllG75j/3s++FuF2X H/uiS/y0iiB8SHWF3xNyqKEG8GKOBVL88rOftHeyG2Ff/E8XjzfztWYF6cLCZybD/xHs/7h fzOsKgIAZ8oWyMeCGBf+K/Z9ztHQrbMpQD7CUNhPl6JuDFdvHcIEuHrmaKgJDKgjBEjmljz H+GYc4RfPg1iZc3gyatdw== X-UI-Out-Filterresults: notjunk:1;V01:K0:KlpA0+QnM+U=:rtePNpRXDWdtEMVVmNW54J 3+kNxO5Jniz40esUKtLC4/d9xl//Znld8E8ozdv25JstVUSopMS0QlXa+EHwGPUD3RFAyu9ay UQIVC0AvEcpxTiL160QqFhK0M3uYn9TxeRowrpkqzjUqYce4QWC17W/LiwwOtmg6Z+C8+flBD klaCmR2KyJdqsvonQaaXpvyiCae3TSkHlHt3knkPr9GAUKaSg81nLrkTlLpx9P2WDYCtN3br6 g/LqeklTZfWbtnl9Y40Ay6F4XLbwTNZ/GgvROWoW8a1kmHdhyjwZYIOgB9lunLUZuG23GQri7 apMRjlQycRnMKbFzYKEoVDWqKoFAXVxGdVG6qA3aRVVPKcmrgfcpyH9+RbLG0LduHWe4A+pd/ bpz5iG58GJPWbQdEfvUBu1dpniaQMK565SqsHzvIMUxwMW2BeYsleuJh3320gqUma0nv4wiUw bU8l2EADbbN7dA6AS5Z6woF/DG4pQ4sr3og2XlNrLCPMHHqxNu4Pke+2a++99BZBVOHomGUIy UJv8l+Ton0+PNgq2xU0hq0uG1KkHqjbevHaoNLBpZVeK1dfpgKnF0obdY3rlkqCFh4LMQqulc fTYoN627cxTanrGHCrI3wmGUxfYzJTVNy/JG7TQt32Q4irm1S8HMsyJQF4t4W85bdOmnCNjwt DI/O69zEsLz4EfnSI+fX0h5vOXoI1f2ptgvc3mIF4vKFnjpYYx32MgfyQ0WLrLaeounGn/BbE EIIAHYoOs+sTFAUuTwHtJoKlirF/DujXGGNNQ7Uv6KiQl3V3kInlK3tYYtmQB0CEPdjCjJG4k opXiPkC Archived-At: Cc: draft-ietf-appsawg-http-problem@ietf.org, apps-discuss@ietf.org, barryleiba@gmail.com Subject: Re: [apps-discuss] Last Call: (Problem Details for HTTP APIs) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 12:17:01 -0000 On 2015-12-01 12:38, Erik Wilde wrote: > On 2015-12-01 11:57, Julian Reschke wrote: >> On 2015-12-01 11:47, Erik Wilde wrote: >>> On 2015-12-01 10:58, Julian Reschke wrote: >>>> Minor nit: the media type registration templates miss a few fields >>>> defined in . >>> i could only find one and https://github.com/mnot/I-D/pull/162 is adding >>> this last one. which other ones are you missing? >> "Fragment identifier considerations:" ... > > thanks, i added those to the existing pull request. > > interestingly, when i looked at > https://tools.ietf.org/html/rfc7303#section-9.1 to check which > information application/xml was specifying there, this registration > field was missing on the registration as well. same for > https://tools.ietf.org/html/rfc7159#section-11 for application/json, > which also is missing such a registration field. > > thanks and cheers, > > dret. Interesting. I was looking at the HTTP (RFC723*) registrations, and those had the new fields. Best regards, Julian From nobody Tue Dec 1 12:36:52 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE851B32C7; Tue, 1 Dec 2015 12:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkHdDNpPgmpQ; Tue, 1 Dec 2015 12:36:49 -0800 (PST) Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) by ietfa.amsl.com (Postfix) with ESMTP id 77A471B2F19; Tue, 1 Dec 2015 12:36:49 -0800 (PST) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1a3rfM-0001q6-ck; Tue, 01 Dec 2015 20:36:48 +0000 Received: from gklyne38.plus.com ([81.174.129.24] helo=conina-wl.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1a3rfL-0004q2-Fr; Tue, 01 Dec 2015 20:36:47 +0000 Message-ID: <565E04DF.7010205@ninebynine.org> Date: Tue, 01 Dec 2015 20:36:47 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , ietf@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Subject: [apps-discuss] Registration of vnc: URI scheme - request for comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 20:36:51 -0000 In my role as URI scheme registration designated reviewer, I'm reviewing a request for permanent registration of the 'vnc:' URI scheme, per https://tools.ietf.org/html/draft-warden-appsawg-vnc-scheme-07#appendix-A The scheme registration document appears to be thorough, and it has received some review on the uri-review@ietf.org mailing list with substantially positive responses, and appears (from a brief Google search) to be quite widely implemented. But the registration document is being submitted though the RFC ISE stream, which does not receive the same level of IETF review as IETF stream publication, and in the past registrations from ISE documents have been restricted to "provisional" status. I understand publication via ISE stream was at the suggestion of an IETF application area director (I don't know who). Taking all the above into account, I am minded to approve permanent registration in this case (which has the effect of conferring something approaching "standard" status). Are there any concerns anyone would raise about my proposed response? If I hear no objections over the next week or so, I propose to recommend permanent registration as requested. #g -- From nobody Tue Dec 1 12:49:39 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069891B37BB; Tue, 1 Dec 2015 12:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dfw53KNd4Oub; Tue, 1 Dec 2015 12:49:29 -0800 (PST) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B6C1B3859; Tue, 1 Dec 2015 12:49:29 -0800 (PST) Received: from mfilter35-d.gandi.net (mfilter35-d.gandi.net [217.70.178.166]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id CDA9DC5A56; Tue, 1 Dec 2015 21:49:27 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter35-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter35-d.gandi.net (mfilter35-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id IpZxQzf_QuUu; Tue, 1 Dec 2015 21:49:26 +0100 (CET) X-Originating-IP: 93.199.254.229 Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 989DBC5A5A; Tue, 1 Dec 2015 21:49:25 +0100 (CET) Message-ID: <565E07D3.1020601@tzi.org> Date: Tue, 01 Dec 2015 21:49:23 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Graham Klyne References: <565E04DF.7010205@ninebynine.org> In-Reply-To: <565E04DF.7010205@ninebynine.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: ietf@ietf.org, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Registration of vnc: URI scheme - request for comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 20:49:34 -0000 Graham Klyne wrote: > But the registration document is being submitted though the RFC ISE > stream, which does not receive the same level of IETF review as IETF > stream publication, and in the past registrations from ISE documents > have been restricted to "provisional" status. I understand publication > via ISE stream was at the suggestion of an IETF application area > director (I don't know who). (Beyond the permanent /vnc/ scheme registration itself, which I certainly support, but don't have a really strong opinion on:) I think this is symptomatic of a more widespread problem we are having: only the extremes of ISE stream and IETF consensus seem to be available to documents that support some forms of registration. It is the nature of some registrations that they only address a comparatively narrow set of users, so running the whole IETF consensus machine is not always appropriate. Still, where some review was achieved, it would be useful to have a weaker form of "this was reviewed" status. I don't have a specific proposal just yet. For now, I wanted to highlight this isn't an isolated instance. Grüße, Carsten From nobody Tue Dec 1 18:01:56 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6584E1B30F9 for ; Tue, 1 Dec 2015 18:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lC8asHJMmMYU for ; Tue, 1 Dec 2015 18:01:54 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465411B30F8 for ; Tue, 1 Dec 2015 18:01:54 -0800 (PST) Received: (qmail 50925 invoked from network); 2 Dec 2015 02:01:53 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 2 Dec 2015 02:01:53 -0000 Date: 2 Dec 2015 02:01:31 -0000 Message-ID: <20151202020131.19630.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <565E04DF.7010205@ninebynine.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: gk@ninebynine.org Subject: Re: [apps-discuss] Registration of vnc: URI scheme - request for comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 02:01:55 -0000 >Taking all the above into account, I am minded to approve permanent registration >in this case (which has the effect of conferring something approaching >"standard" status). > >Are there any concerns anyone would raise about my proposed response? Seems reasonable to me. I note that RFC 7595 says 'Permanent' status is appropriate for, but not limited to, use in standards" so you certainly have latitude to do so. VNC and its underlying RFB protcocol had been around for a decade when we wrote AD-sponsored RFC 6143 in 2011, and the guts of the protocol haven't changed for a long time. If this isn't stable enough for permanent registration it's hard to say what would be. R's, John From nobody Wed Dec 2 01:15:54 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7641A1A66 for ; Wed, 2 Dec 2015 01:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JzAPTJqiLo2 for ; Wed, 2 Dec 2015 01:15:42 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC7C61A1A20 for ; Wed, 2 Dec 2015 01:15:41 -0800 (PST) Received: internal info suppressed Date: Wed, 2 Dec 2015 10:06:03 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: John Levine In-Reply-To: <20151202020131.19630.qmail@ary.lan> Message-ID: References: <20151202020131.19630.qmail@ary.lan> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1449047162; bh=NwQxjsmNaqLg5rGVRFiSnn0Tp2VGynJFPGxZFscsLkQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KHGY9jLpVYYAaTfzr7yOs7R/099m2pCo2mssAKD5SIJCN1pdoe+Gb6fQEu5FF4BtD hv1cVcqbsw01wEqsIZgFkzkSpFRpeNSrtk9fmB+PgBaafLQz42TvLBMKlZdk1t5BhF Tu1Mlyuxc2NDcoxo5e4lhtzRCDZNm/4Yi8uG9mUs= Archived-At: Cc: gk@ninebynine.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Registration of vnc: URI scheme - request for comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 09:15:44 -0000 On Wed, 2 Dec 2015, John Levine wrote: >> Taking all the above into account, I am minded to approve permanent registration >> in this case (which has the effect of conferring something approaching >> "standard" status). >> >> Are there any concerns anyone would raise about my proposed response? > > Seems reasonable to me. I note that RFC 7595 says 'Permanent' > status is appropriate for, but not limited to, use in standards" > so you certainly have latitude to do so. > > VNC and its underlying RFB protcocol had been around for a decade when > we wrote AD-sponsored RFC 6143 in 2011, and the guts of the protocol > haven't changed for a long time. > > If this isn't stable enough for permanent registration it's hard to > say what would be. > > R's, > John and it is now being delivered as "standard utility" embedded in many OS, and is available on platforms I know, including mobile phones... so it also proved very well "interoperability of indipendent implementations". > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > ------------------------------------------------------------------------------ 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; http://www.cert.garr.it/pgp/garr-cert-pgp-keys From nobody Wed Dec 2 07:03:54 2015 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0F91ACD83; Wed, 2 Dec 2015 07:03:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151202150350.13170.6643.idtracker@ietfa.amsl.com> Date: Wed, 02 Dec 2015 07:03:50 -0800 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-mdn-3798bis-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 15:03:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ART Area General Applications Working Group Working Group of the IETF. Title : Message Disposition Notification Authors : Tony Hansen Alexey Melnikov Filename : draft-ietf-appsawg-mdn-3798bis-05.txt Pages : 31 Date : 2015-12-02 Abstract: This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-mdn-3798bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-mdn-3798bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-mdn-3798bis-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 3 00:00:35 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27F51A90AD; Tue, 1 Dec 2015 03:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mov2fcsv-XdC; Tue, 1 Dec 2015 03:38:08 -0800 (PST) Received: from cm01fe.ist.berkeley.edu (cm01fe.ist.berkeley.edu [169.229.218.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59BA1A90AB; Tue, 1 Dec 2015 03:38:08 -0800 (PST) Received: from 46-126-159-4.dynamic.hispeed.ch ([46.126.159.4] helo=dretair11.local) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1a3jG3-0000Eg-4A; Tue, 01 Dec 2015 03:38:08 -0800 To: Julian Reschke , ietf@ietf.org, appsawg-chairs@ietf.org References: <20151120205655.17511.99851.idtracker@ietfa.amsl.com> <565D6F4A.6060007@gmx.de> <565D7AD6.4000908@dret.net> <565D7D03.8060809@gmx.de> From: Erik Wilde Message-ID: <565D869F.7010705@dret.net> Date: Tue, 1 Dec 2015 12:38:07 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <565D7D03.8060809@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 03 Dec 2015 00:00:34 -0800 Cc: draft-ietf-appsawg-http-problem@ietf.org, apps-discuss@ietf.org, barryleiba@gmail.com Subject: Re: [apps-discuss] Last Call: (Problem Details for HTTP APIs) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 11:38:11 -0000 On 2015-12-01 11:57, Julian Reschke wrote: > On 2015-12-01 11:47, Erik Wilde wrote: >> On 2015-12-01 10:58, Julian Reschke wrote: >>> Minor nit: the media type registration templates miss a few fields >>> defined in . >> i could only find one and https://github.com/mnot/I-D/pull/162 is adding >> this last one. which other ones are you missing? > "Fragment identifier considerations:" ... thanks, i added those to the existing pull request. interestingly, when i looked at https://tools.ietf.org/html/rfc7303#section-9.1 to check which information application/xml was specifying there, this registration field was missing on the registration as well. same for https://tools.ietf.org/html/rfc7159#section-11 for application/json, which also is missing such a registration field. thanks and cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Thu Dec 3 00:01:03 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB1E1A8972; Tue, 1 Dec 2015 02:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rz-haoSG3Jsm; Tue, 1 Dec 2015 02:47:52 -0800 (PST) Received: from cm01fe.ist.berkeley.edu (cm01fe.ist.berkeley.edu [169.229.218.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB9921A8974; Tue, 1 Dec 2015 02:47:52 -0800 (PST) Received: from 46-126-159-4.dynamic.hispeed.ch ([46.126.159.4] helo=dretair11.local) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1a3iTO-0007Ad-5U; Tue, 01 Dec 2015 02:47:52 -0800 To: ietf@ietf.org, appsawg-chairs@ietf.org References: <20151120205655.17511.99851.idtracker@ietfa.amsl.com> <565D6F4A.6060007@gmx.de> From: Erik Wilde Message-ID: <565D7AD6.4000908@dret.net> Date: Tue, 1 Dec 2015 11:47:50 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <565D6F4A.6060007@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 03 Dec 2015 00:00:54 -0800 Cc: Julian Reschke , draft-ietf-appsawg-http-problem@ietf.org, apps-discuss@ietf.org, barryleiba@gmail.com Subject: Re: [apps-discuss] Last Call: (Problem Details for HTTP APIs) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 10:47:54 -0000 On 2015-12-01 10:58, Julian Reschke wrote: > On 2015-11-20 21:56, The IESG wrote: > Minor nit: the media type registration templates miss a few fields > defined in . i could only find one and https://github.com/mnot/I-D/pull/162 is adding this last one. which other ones are you missing? thanks and cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Fri Dec 4 03:02:20 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F1C1B3003; Fri, 4 Dec 2015 03:02:16 -0800 (PST) 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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWxpLDrc6CZN; Fri, 4 Dec 2015 03:02:14 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27D701B3000; Fri, 4 Dec 2015 03:02:13 -0800 (PST) Received: from [192.168.1.158] ([5.10.171.186]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LjN0F-1ahjFW1pWB-00dUJN; Fri, 04 Dec 2015 12:02:09 +0100 To: Mark Nottingham References: <20151120205655.17511.99851.idtracker@ietfa.amsl.com> <565588D8.50402@greenbytes.de> From: Julian Reschke Message-ID: <566172B5.4040808@gmx.de> Date: Fri, 4 Dec 2015 12:02:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:e6CDvVNH8jfU5ot7eQgZEhBN16+e92nfK96AN8Is/K2iccwxrWb PM918hYbmv3k31L6AwgAqasKj0hyjUQsq/UkeYQWZ2KivPydRp6AfT1kVljfKg2FNuQBKUK 3aUe5tjKHbJQgfuxQWKOJ1+D7QJmmDcWOVo4qUzsdcin3ybbOVKvLmcCF/nP1bYzrPOHhxY iOlOoCzvciw/GIF1iMN1Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:wTxDu7lEpJA=:cOz0ZeVCGvRZW9Fzl8xVnG hUumnolJuFfxrrT8tI45G9mf3cRlCCuUFExG0HYEsx+EeNX2hTD6FEW5x2tS9VKjC3ST1kZRi vrygJ6lkZaPK9ssxaZi5YktJ3Q77y/bLbaSLWxS6e8lxMTiOwl2IojQOkyJBChVveAf7L2nb8 ZqDl0cSoAj59fE22ntUmXFmvcQZCQFAybndktK/YJ8KlgVz7YDEczOYMy3c3qidAFdG4I2Kwg tMOMeIpwEuJ10F1gGD+Xl38wWhYA4VG4O4joPFnsB/6XMqs20/lfcfZrgkM5Fv2CG+pr/9VwI UhqKbsg+S0EYprSvQ+NHEuRt91YB0A54RxubTza45f5+TPsmt1IlKftvuhj8XoYRCYoOBkmCt G65Bosc+0J4NP0m8Jms/caozpHECoEKpd2iuXy+mDgThVuCAyUo/0PlIsgExYz1MgRq2hy/iA 6M76OoYqPB53tedIzYXJUuaUutb5gyjGaTAhIMtzohKAlJMCX+8R0E6VFhN3p0K+wlL9A1Kf+ oEquQdgAvXwvJAlmSK0Om2GQuLms65PZxJ+CP4oHLlhIqevxk2SKqJYcGjZPTX19UvCU3Vp7c xFYfSChbqTL2vmHGTRDMaPUvEXyfDj3HxCspDCdHm4eL/gnDpi/ECSR56pOx+inKOQ2W/Cglh HMh3S3kp+KsHvzkXhikiPdcivpPmjPc945GNNp4BkBHcsJplcmvxbhAG7XSjU/8u+UFozlwpd 1joaD1CmAVzAwEZm6RxegQft+SU/zPciAQAW+FYcFHAGazINm1lJj/bhgi0vXDCleRqm9WZbI bDdhwve Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-http-problem@ietf.org, ietf@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Problem Details for HTTP APIs) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 11:02:16 -0000 On 2015-11-25 23:45, Mark Nottingham wrote: > Sorry about that, Julian. > > I've updated to include everything except the XML-related questions; Erik? > > See: > http://mnot.github.io/I-D/http-problem/ > http://tools.ietf.org/rfcdiff?url1=draft-ietf-appsawg-http-problem-01&url2=https://mnot.github.io/I-D/http-problem/index.txt So can we please get the XML-related issues resolved and get a new draft submitted? Best regards, Julian From nobody Fri Dec 4 06:10:21 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FFC1A872F; Fri, 4 Dec 2015 06:10:21 -0800 (PST) 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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LsudAuDcnVf; Fri, 4 Dec 2015 06:10:19 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 932641A86FA; Fri, 4 Dec 2015 06:10:18 -0800 (PST) Received: from [192.168.1.158] ([5.10.171.186]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MGzwE-1a11K11QWI-00Drur; Fri, 04 Dec 2015 15:10:15 +0100 To: Erik Wilde , ietf@ietf.org References: <20151120205655.17511.99851.idtracker@ietfa.amsl.com> <565588D8.50402@greenbytes.de> <56619DDF.3090002@dret.net> From: Julian Reschke Message-ID: <56619EC8.9070807@gmx.de> Date: Fri, 4 Dec 2015 15:10:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <56619DDF.3090002@dret.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:HF7lQsxVOi6gfk5igS12Q+hqVlponbA4EyuIFOiiOsx/KZzz6/M 1ZtvHA4nyXsPr1yRxcZJ7pWZhEU+EaKPZOklhmz0Bd/ZooFBL7rExvggt08i+n31NnCd1CC 4gmwBaarRQTOFjPd4NS8kQTIhwhQOcgx7lXHFkRe52ineHw5lnuq1ClyQ9ygur1WXjcGKSH CMDwzUxcP8+sQ9rrnazEQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:dYfZU0WoDis=:zaWr+LdGX+hyF/JU+EyxUJ la/aZM7FO52u3aXc9PZv9JDFsKqld+1z7xjcgxmztBcTPcGxj5beVYzEv8BTKnCgoOvzrrEm5 MUbJ5FGWWd/oB/T3Yy2BZtjw5NE9EsRHCUoGK3iuWIl/cW4pB4pcWoDEhYUPNeLrcwuTRHm8f zTeNMT8KHbkktgCTg2fiDxA/ui5Hi/fwX2cxGlzmrIKvmRjLRBoir0AOlKwbWh73jfzL9nwJL 23hoHZzUUMrfcBZkB4MoKqFNr1s8jb0useCFqrIdLN9zdPM2E5SauLsxJxY3DeRmTSS8osI+L KbdR5AItgyz5VceQMAvhIPwqrY8eWPqbf8E6w/QvDSRd1WnxVGwMaSQ1oAhT4CF6yTDOay4Hd 7JGlSXxunnWe7G5hS9lrWvKzPVFaLK8QCrUKItisSC5jaCYyyFXxFZBIIHPwxwg/cFnQUCzJ6 MmkXmWFUq1Vt4Ax66mSoHPdhcg1s7vO0I10B7dWrKajLORn2eob64n66G8m2NEd/HdZ+mpSVc JhBWPF5uT3kRh0ABC0ELjTTxGyjfUVzlBZwd0UU51y1gjikuVlFD3q/EuqGieJQZ2zDMV6jNQ noebQYxcBeEpqOI8ijwy80d5YxVeLpN5s58tEQffpgCc3/leorF/iL2KM5JgDAPTa8Bj7c/9l +XRIoWakB+R09yvHdjpkUGSeG7eXQSOuNkfEVadpaBH9VMOpRTCuNLrVsrg3VovGEhSzAuIzD LJDeyvDAnJQb9VJWe5vfg6o4k//zU8a+hjTVcXu1fz5kmpN7sMptbFwrhhFQJILVpd3eEweC1 cXJSFkv Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-http-problem@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Problem Details for HTTP APIs) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 14:10:21 -0000 On 2015-12-04 15:06, Erik Wilde wrote: > On 2015-11-25 11:09, Julian Reschke wrote: >> I don't believe that all of my WGLC feedback from December 2014 has been >> addressed (and that includes subjects on where we agreed on changes). >> See >> . >> > > quoting from this message, these changes should address your issues: > >> 2) The spec talks about using Accept to instruct the server whether to >> return problem details or HTML. Maybe it would be worthwhile to >> mention that if you use XML, you could *always* send problem details, >> and then use to instruct the UA >> to convert to HTML; that would get rid of the conneg complexity. > > https://github.com/dret/I-D-1/commit/6f37bcaca5a5295a76592231a1a614b0f0f76957 > should take care of this. it recommends to use XSLT 1.0. > >>> The data model for problem details is a JSON [RFC7159] object; when >>> formatted as a JSON document, it uses the "application/problem+json" >>> media type. Appendix A defines how to express them in an equivalent >>> XML format, which uses the "application/problem+xml" media type. >> Why is this an appendix? > > i am honestly not sure about this. mark preferred to have it as an > appendix, and since he is the main author, that's where it ended up. > >>> The OPTIONAL RELAX NG schema [ISO-19757-2] for the XML format is: >> What does "OPTIONAL" mean here? The schema doesn't seem optional at >> all; lacking it, you wouldn't even know what XML namespace to use. > > the idea was to not mandate that people use RELAX NG. we picked RELAX NG > because it's easier to read than XSD, but the idea is that there should > be no normative schema because schemas never completely capture what's > in a spec. i agree that the term "OPTIONAL" may be a bit confusing here, > though, so i rephrased that section a bit. > > https://github.com/dret/I-D-1/commit/46b02840131147b75795d64baa09ac1004e5e132 > > >>> default namespace ns = "urn:ietf:rfc:XXXX" >> This needs to state that it will be updated based on the assigned RFC >> number. > > https://github.com/mnot/I-D/blob/gh-pages/http-problem/draft-ietf-appsawg-http-problem-02.txt#L29 > takes care of that. > >>> Extension arrays and objects can be serialized into the XML format by >>> considering an element containing a child or children to represent an >>> object, except for elements that contain only child element(s) named >>> 'i', which are considered arrays. For example, an alternate version >>> of the example above would appear in XML as: >> This is written like guidance, but it's normative, right? > > yes, these are the rules how it has to be done. does this rephrasing > work for you? > > https://github.com/dret/I-D-1/commit/eac63fbd5659b89ac2a408987368f4e21030382e > > >>> >>> http://example.net/account/12345/msgs/abc >>> >> It would be good to point out that due to the type definitions in the >> schema, the whitespace inside is ignorable. > > that may be more complicated and potentially confusing than to simply > fix the XML to not contain whitespace, right? > > https://github.com/dret/I-D-1/commit/69c39606c4087c53710695124cdb9020a5438ac3 > > > https://github.com/mnot/I-D/pull/165 is where all the commits live for > now, i hope they are addressing all of your issues? > > thanks and cheers, Yes, I believe so. Thanks. Best regards, Julian From nobody Fri Dec 4 08:49:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF1F1A89AC; Fri, 4 Dec 2015 08:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJAGqfg6veYi; Fri, 4 Dec 2015 08:49:22 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40B001A89A5; Fri, 4 Dec 2015 08:49:22 -0800 (PST) Received: by iofh3 with SMTP id h3so122101365iof.3; Fri, 04 Dec 2015 08:49:21 -0800 (PST) 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=aeX+V3erdFaUL0W4HD5gFLwSHNTGN6DbloFiVRj4qUY=; b=lbSErReLxDUDsg+6wMNsDlfH4/gmrkhrMjKt6tmInH/5uRQCto7bI32/3vbTFJhDKg 99aKUmREtPlZ/imtGnhOeoRWZeoVkMXHNgzvGa1FJ/mJU0S6zsBaGfdOeFJjs/F+BKfE Mxmm+W1Ljkk5o+58KK7tg+L8dMcL/K/y8kZgF57J6agS9g6UG+DYOQLvKkY2eF4XJni1 JT1JPPrZ8m6oneRNqmLD56sIk9GBYw82jOpoYTsNAjk/6UOxeVgxbLK32vFTmSjK+InL l1o0WhVKGBnIohJVkO7XpaYg44xyrY5YqqsdUdheBEa3dpkuOKXxwnDO0KGT4j9QQmc4 uJ0g== MIME-Version: 1.0 X-Received: by 10.107.28.144 with SMTP id c138mr15187846ioc.15.1449247761627; Fri, 04 Dec 2015 08:49:21 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.156.67 with HTTP; Fri, 4 Dec 2015 08:49:21 -0800 (PST) In-Reply-To: <565E04DF.7010205@ninebynine.org> References: <565E04DF.7010205@ninebynine.org> Date: Fri, 4 Dec 2015 11:49:21 -0500 X-Google-Sender-Auth: Nxh66cafirIuTedsdRnjDdHuqgU Message-ID: From: Barry Leiba To: Graham Klyne Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF discussion list , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Registration of vnc: URI scheme - request for comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 16:49:23 -0000 Hi, Graham. > But the registration document is being submitted though the RFC ISE stream, > which does not receive the same level of IETF review as IETF stream > publication, and in the past registrations from ISE documents have been > restricted to "provisional" status. I understand publication via ISE stream > was at the suggestion of an IETF application area director (I don't know > who). That'd be me, after consulting with Cullen and Robert, who were the ones who AD-sponsored RFC 6143. The policy for registering permanent URI schemes is Expert Review, and the designated expert has quite a bit of room for judgment. RFC 7595 says these: 'Permanent' status is appropriate for, but not limited to, use in standards. ...and... The registration procedure is intended to be very lightweight for noncontentious registrations. For the most part, we expect the good sense of submitters and reviewers, guided by these procedures, to achieve an acceptable and useful consensus for the community. ...and... The role of the Designated Expert in the procedure for 'permanent' registrations described here is to ensure that the normal open review process has been properly followed and to raise possible concerns about wider implications of proposals for the use and deployment ...and that the requester should... Prepare a scheme registration request using the template specified in Section 7.4. The scheme registration request can be contained in an Internet-Draft, submitted alone, or as part of some other permanently available, stable, protocol specification. No specification is formally required at all, beyond the registration template ("submitted alone"), and an Independent Stream RFC certainly qualifies as a permanently available, stable specification. I know that Graham knows this; I'm clarifying for others who may not be as familiar with the registration requirements. So the fact that we've usually used the IETF Stream for permanent URI scheme registrations doesn't mean that the Independent Stream is in any way inappropriate, and Graham is doing the right thing in making sure that there's been enough open review of this to satisfy him. And it sounds like he's satisfied: > Taking all the above into account, I am minded to approve permanent > registration in this case (which has the effect of conferring something > approaching "standard" status). > > Are there any concerns anyone would raise about my proposed response? > > If I hear no objections over the next week or so, I propose to recommend > permanent registration as requested. Great! Thanks, as always, Graham, for your excellent review work on this. I really appreciate that you continue to be willing and able to serve as a URI Schemes expert. Barry From nobody Fri Dec 4 16:27:29 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4871B31CF; Fri, 4 Dec 2015 06:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aLNISSc6dts; Fri, 4 Dec 2015 06:06:33 -0800 (PST) Received: from cm01fe.ist.berkeley.edu (cm01fe.ist.berkeley.edu [169.229.218.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 579A61B31C6; Fri, 4 Dec 2015 06:06:33 -0800 (PST) Received: from 46-126-159-4.dynamic.hispeed.ch ([46.126.159.4] helo=dretair11.local) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1a4r0G-0007Dl-4s; Fri, 04 Dec 2015 06:06:32 -0800 To: Julian Reschke , ietf@ietf.org References: <20151120205655.17511.99851.idtracker@ietfa.amsl.com> <565588D8.50402@greenbytes.de> From: Erik Wilde Message-ID: <56619DDF.3090002@dret.net> Date: Fri, 4 Dec 2015 15:06:23 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <565588D8.50402@greenbytes.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Fri, 04 Dec 2015 16:27:27 -0800 Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-http-problem@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Problem Details for HTTP APIs) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 14:06:36 -0000 On 2015-11-25 11:09, Julian Reschke wrote: > I don't believe that all of my WGLC feedback from December 2014 has been > addressed (and that includes subjects on where we agreed on changes). > See > . quoting from this message, these changes should address your issues: > 2) The spec talks about using Accept to instruct the server whether to return problem details or HTML. Maybe it would be worthwhile to mention that if you use XML, you could *always* send problem details, and then use to instruct the UA to convert to HTML; that would get rid of the conneg complexity. https://github.com/dret/I-D-1/commit/6f37bcaca5a5295a76592231a1a614b0f0f76957 should take care of this. it recommends to use XSLT 1.0. >> The data model for problem details is a JSON [RFC7159] object; when >> formatted as a JSON document, it uses the "application/problem+json" >> media type. Appendix A defines how to express them in an equivalent >> XML format, which uses the "application/problem+xml" media type. > Why is this an appendix? i am honestly not sure about this. mark preferred to have it as an appendix, and since he is the main author, that's where it ended up. >> The OPTIONAL RELAX NG schema [ISO-19757-2] for the XML format is: > What does "OPTIONAL" mean here? The schema doesn't seem optional at all; lacking it, you wouldn't even know what XML namespace to use. the idea was to not mandate that people use RELAX NG. we picked RELAX NG because it's easier to read than XSD, but the idea is that there should be no normative schema because schemas never completely capture what's in a spec. i agree that the term "OPTIONAL" may be a bit confusing here, though, so i rephrased that section a bit. https://github.com/dret/I-D-1/commit/46b02840131147b75795d64baa09ac1004e5e132 >> default namespace ns = "urn:ietf:rfc:XXXX" > This needs to state that it will be updated based on the assigned RFC number. https://github.com/mnot/I-D/blob/gh-pages/http-problem/draft-ietf-appsawg-http-problem-02.txt#L29 takes care of that. >> Extension arrays and objects can be serialized into the XML format by >> considering an element containing a child or children to represent an >> object, except for elements that contain only child element(s) named >> 'i', which are considered arrays. For example, an alternate version >> of the example above would appear in XML as: > This is written like guidance, but it's normative, right? yes, these are the rules how it has to be done. does this rephrasing work for you? https://github.com/dret/I-D-1/commit/eac63fbd5659b89ac2a408987368f4e21030382e >> >> http://example.net/account/12345/msgs/abc >> > It would be good to point out that due to the type definitions in the schema, the whitespace inside is ignorable. that may be more complicated and potentially confusing than to simply fix the XML to not contain whitespace, right? https://github.com/dret/I-D-1/commit/69c39606c4087c53710695124cdb9020a5438ac3 https://github.com/mnot/I-D/pull/165 is where all the commits live for now, i hope they are addressing all of your issues? thanks and cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Sat Dec 5 14:54:04 2015 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F5B1A9141; Sat, 5 Dec 2015 14:54:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151205225402.17796.28292.idtracker@ietfa.amsl.com> Date: Sat, 05 Dec 2015 14:54:02 -0800 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-http-problem-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 22:54:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ART Area General Applications Working Group Working Group of the IETF. Title : Problem Details for HTTP APIs Authors : Mark Nottingham Erik Wilde Filename : draft-ietf-appsawg-http-problem-02.txt Pages : 16 Date : 2015-12-05 Abstract: This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response, to avoid the need to define new error response formats for HTTP APIs. Note to Readers This draft should be discussed on the apps-discuss mailing list [1]. This section is to be removed before publication. Note to RFC Editor Please replace all occurrences of "XXXX" with the final RFC number chosen for this draft. This section is to be removed before publication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-problem/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-http-problem-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-http-problem-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 8 09:19:21 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3D51A01F6; Tue, 8 Dec 2015 09:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iI2PN6MC-Wg0; Tue, 8 Dec 2015 09:19:18 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BFF21A01A9; Tue, 8 Dec 2015 09:19:18 -0800 (PST) Received: by qgcc31 with SMTP id c31so26096497qgc.3; Tue, 08 Dec 2015 09:19:17 -0800 (PST) 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:content-type; bh=rjll+w5vKnpbaOjf6dGgSCdURk6dRdMiP4DCHumljXc=; b=sXzVpROV6iQbTbby/tofdaUjB75e9UL+oMRSoLZap4EzUrzgmLrE8s0EP8/MdxPH8R CQSvJ/ZybrZnEShLFM2Bs/m8Ktkf2N0olm7UJhbegEAM0lPoik/zxTuax1GqzFoi5b8g 2FZeCZJ719dc6s2uMc3Iy14Zc92wmVMjoXtgv9RVOnbTZnSwaD9duF9iHF1ARZAY/e8P 6W8ijBIRdZrrmECI7KsX3O55tI3dYDUpAvQeHufEwCVhtcl6iPEDEQ8nPPXxSn7PhTBO v1pi3SWQZrjqsjCfsv5aNCFvSK0vZfomYSUFxnO3CwzsaIpwa7oMmdwfZM9CzId9zYdd zhIA== MIME-Version: 1.0 X-Received: by 10.140.253.66 with SMTP id y63mr1878515qhc.39.1449595157655; Tue, 08 Dec 2015 09:19:17 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.55.27.146 with HTTP; Tue, 8 Dec 2015 09:19:17 -0800 (PST) In-Reply-To: <20151208155640.29167.39623.idtracker@ietfa.amsl.com> References: <20151208155640.29167.39623.idtracker@ietfa.amsl.com> Date: Tue, 8 Dec 2015 12:19:17 -0500 X-Google-Sender-Auth: EtFrgGtqe8uroYz4Okd4mFiZvtA Message-ID: From: Barry Leiba To: "apps-discuss@ietf.org" , dispatch@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [apps-discuss] Fwd: Last Call: (Improving the Organizational Flexibility of the SIP Change Process.) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 17:19:20 -0000 Denizens of apps-discuss and dispatch need to be aware of this last call. Comments to the main IETF list , please. Barry, Alissa, Ben ---------- Forwarded message ---------- From: The IESG Date: Tue, Dec 8, 2015 at 10:56 AM Subject: Last Call: (Improving the Organizational Flexibility of the SIP Change Process.) to Best Current Practice To: IETF-Announce Cc: mary.ietf.barnes@gmail.com, draft-campbell-art-rfc5727-update@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'Improving the Organizational Flexibility of the SIP Change Process.' as Best Current Practice 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 2016-01-05. 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 RFC 5727 defines several processes for the Real-time Applications and Infrastructure (RAI) area. These processes include the evolution of the Session Initiation Protocol (SIP) and related protocols, as well as the operation of the DISPATCH and SIPCORE working groups. This document updates RFC 5727 to allow flexibility for the area and working group structure, while preserving the SIP change processes. It also generalizes the DISPATCH working group processes so that they can be easily adopted by other working groups. The file can be obtained via https://datatracker.ietf.org/doc/draft-campbell-art-rfc5727-update/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-campbell-art-rfc5727-update/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Dec 11 09:16:36 2015 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7265C1B2D11; Fri, 11 Dec 2015 09:16:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151211171634.29111.641.idtracker@ietfa.amsl.com> Date: Fri, 11 Dec 2015 09:16:34 -0800 Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-http-problem@ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Stephen Farrell's Yes on draft-ietf-appsawg-http-problem-02: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 17:16:34 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-appsawg-http-problem-02: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-problem/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 3.1: "SHOULD NOT automatically" de-ref the type URI. Hmm, under what circumstances would it be reasonable for any code to automatically de-ref the type URI? If none, then either s/SHOULD/MUST/ or maybe s/automatically// - 3.1, last para: I'm sure this is a known thing, but I don't know the answer, so I'll ask:-) If I send a request for URL example.com/foo and am re-directed to example.net/bar, against which of those is a relative URL in the problem detail evaluated? I hope the answer is example.net - if not, there could be some attack that could be mounted but I've not got a concrete example to offer. - 3.2, last para: should "media type" be "problem type" at the end? - 4: "typically with the "http" scheme" - your examples are all https, don't you mean https here too? From nobody Tue Dec 15 21:45:35 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6A01B2A16 for ; Mon, 14 Dec 2015 19:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90PYTTQv-cET for ; Mon, 14 Dec 2015 19:47:06 -0800 (PST) Received: from cm03fe.ist.berkeley.edu (cm03fe.ist.berkeley.edu [169.229.218.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3578B1B2A11 for ; Mon, 14 Dec 2015 19:47:05 -0800 (PST) Received: from 108-67-65-66.lightspeed.sntcca.sbcglobal.net ([108.67.65.66] helo=[192.168.1.77]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1a8gZq-0000WN-C4; Mon, 14 Dec 2015 19:47:04 -0800 To: IETF Apps Discuss , Nevil Brownlee From: Erik Wilde Message-ID: <566F8D34.10304@dret.net> Date: Mon, 14 Dec 2015 19:47:00 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 15 Dec 2015 21:45:34 -0800 Subject: [apps-discuss] review for draft-seantek-text-nfo-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 03:47:08 -0000 hello. i have volunteered to review draft-seantek-text-nfo-02. there already have been reviews and comments made in the following thread: https://www.ietf.org/mail-archive/web/apps-discuss/current/threads.html#14639 section 2: if the charset media type parameter is required, why would it even have a default? nit: since "baud" really is about bit rate, it probably should be "bps" instead (baud is slightly different in its definition), but that's as minor as things can possibly get. wrt to the question about how/if escape sequences count for RFC 5147 fragment identifiers: i am not sure why they wouldn't (as the current draft says), because RFC 5147 does not operate at the level of text/nfo (which does define rather elaborate semantics for certain character sequences). from the perspective of text/plain (which is what RFC 5147 is defined for), escape sequences are nothing special; they simply are sequences of encoded characters. for this reason, i would assume that escape sequences count like other characters, but maybe martin duerst (co-author of RFC 5147) could pitch in here as well? section 3: after reading through section 3, the following sentence from the abstract does not really seem to apply: 'While mostly compatible with text/plain, ".NFO" filesand content have unique encoding and rendering characteristics that make them distinguishable from typical plain text.' it seems more that text/nfo is a language that does have text-based parts, but also have rather elaborate semantics when it comes to rendering the media type with all required formatting semantics. kind regards, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Wed Dec 16 08:19:46 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434511A0856 for ; Wed, 16 Dec 2015 08:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PybFP2bFhxKU for ; Wed, 16 Dec 2015 08:19:34 -0800 (PST) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE5581A03A3 for ; Wed, 16 Dec 2015 08:19:32 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) (authenticated bits=0) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id tBGGJIVu012033; Wed, 16 Dec 2015 17:19:18 +0100 From: "Jose Saldana" To: Date: Wed, 16 Dec 2015 17:19:26 +0100 Message-ID: <010f01d1381d$888d6570$99a83050$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0110_01D13825.EA535410" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdE4HHz7udC6IFP2Qby55sXu88HW7A== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: Cc: =?iso-8859-2?Q?'Mirko_Su=BEnjevi=E6'?= Subject: [apps-discuss] A draft about delay limits for real-time services X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 16:19:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0110_01D13825.EA535410 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Hi all, We have submitted this draft: https://datatracker.ietf.org/doc/draft-suznjevic-dispatch-delay-limits/ It surveys a set of recommendations about the maximum latency tolerated by the users of services with delay constraints. Some recommendations already exist for e.g. VoIP, but emerging services as e.g. online gaming, have different requirements. Different papers in the literature reporting these constraints are surveyed, and a summary of the latency limits for each service is provided. The draft has been adapted from a more specific one, which was submitted some time ago to the Transport Area WG ( http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/). The current version is more general, and not specific for the case of traffic optimization with multiplexing. We have first submitted it to the Dispatch WG, and the advice we have received is that we could ask in appsawg. The proposal does not aim to propose any new WG, and it is related to real-time applications as e.g. VoIP or online games. As said in the charter, "The Applications Area sometimes receives proposals for the development of specifications dealing with application-related topics that are not in scope for an existing working group and do not justify the formation of a new working group." Thanks in advance, Jose Saldana & Mirko Suznjevic ------=_NextPart_000_0110_01D13825.EA535410 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We have submitted this draft: = https://datatracker.ietf.org/doc/draft-= suznjevic-dispatch-delay-limits/

 

It surveys a set of recommendations = about the maximum latency tolerated by the users of services with delay = constraints. Some recommendations already exist for e.g. VoIP, but = emerging services as e.g. online gaming, have different = requirements.

 

Different papers in the literature = reporting these constraints are surveyed, and a summary of the latency = limits for each service is provided.

 

The draft has been adapted from a more = specific one, which was submitted some time ago to the Transport Area WG = (http://datatracker.ietf.org/doc/draft-s= uznjevic-tsvwg-mtd-tcmtf/). The current version is more = general, and not specific for the case of traffic optimization with = multiplexing.

 

We have first submitted it to the = Dispatch WG, and the advice we have received is that we could ask in = appsawg. The proposal does not aim to = propose any new WG, and it is related to real-time applications as e.g. = VoIP or online games. As said in the charter, “The Applications = Area sometimes receives proposals for the development of specifications = dealing with application-related topics that are not in scope for an = existing working group and do not justify the formation of a new working = group.”

 

 

Thanks in = advance,

 

Jose Saldana & Mirko = Suznjevic

 

------=_NextPart_000_0110_01D13825.EA535410-- From nobody Wed Dec 16 14:05:03 2015 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB681A802D; Wed, 16 Dec 2015 14:05:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151216220500.1665.11980.idtracker@ietfa.amsl.com> Date: Wed, 16 Dec 2015 14:05:00 -0800 Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-http-problem@ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Spencer Dawkins' Yes on draft-ietf-appsawg-http-problem-02: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 22:05:00 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-appsawg-http-problem-02: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-problem/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I've wished this mechanism was available, a few times already. In this text, If such additional members are defined, their names SHOULD start with a letter (ALPHA, as per [RFC5234], Appendix B.1) and SHOULD consist of characters from ALPHA, DIGIT (Ibid.), and "_" (so that it can be serialized in formats other than JSON), and SHOULD be three characters or longer. are there any benefits to not conforming to these SHOULDs? For example, would you really need to have a two-character member name, and you'd fail if the member name was three characters long? ("Why are these not MUSTs?") In this text, The "status" member duplicates the information available in the HTTP status code itself, thereby bringing the possibility of disagreement between the two. Their relative precedence is not clear, since a disagreement might indicate that (for example) an intermediary has modified the HTTP status code in transit. As such, those defining problem types as well as generators and consumers of problems need to be aware that generic software (such as proxies, load balancers, firewalls, virus scanners) are unlikely to know of or respect the status code conveyed in this member. I understand what you're saying about a mismatch being possible, and some of the possible reasons why that might happen, but isn't this saying that anyone who can understand the "status" member should prefer its value when there's a mismatch (because it's less likely to have been dorked with by an intermediary - or is that even true)? From nobody Wed Dec 16 14:08:33 2015 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02FD91A8A8E; Wed, 16 Dec 2015 14:08:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151216220829.2448.53583.idtracker@ietfa.amsl.com> Date: Wed, 16 Dec 2015 14:08:29 -0800 Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-http-problem@ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Ben Campbell's Yes on draft-ietf-appsawg-http-problem-02: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 22:08:30 -0000 Ben Campbell has entered the following ballot position for draft-ietf-appsawg-http-problem-02: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-problem/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 4 talks about how a problem type SHOULD resolve to HTML documentation. Is there ever a case where an API might be standardized to be used by multiple origin servers? Would each server host it's own documentation? Would the problem type be a relative URL under those circumstances? (You say it can be relative, but all the examples are fully qualified) - 4, 2nd paragraph: "New problem types need to carefully consider..." This is a pedantic nit, really a personal pet peeve: Designers of new problem types should consider this. I doubt the types themselves will :-) From nobody Thu Dec 17 06:38:43 2015 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB341B2E37; Thu, 17 Dec 2015 06:38:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151217143841.8732.14093.idtracker@ietfa.amsl.com> Date: Thu, 17 Dec 2015 06:38:41 -0800 Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-http-problem@ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Spencer Dawkins' Discuss on draft-ietf-appsawg-http-problem-02: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 14:38:41 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-appsawg-http-problem-02: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-problem/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm elevating this to a (late) Discuss, because I haven't heard anything back, and didn't want the document approved without having a (short) discussion. I'll be back to Yes after that. In this text, The "status" member duplicates the information available in the HTTP status code itself, thereby bringing the possibility of disagreement between the two. Their relative precedence is not clear, since a disagreement might indicate that (for example) an intermediary has modified the HTTP status code in transit. As such, those defining problem types as well as generators and consumers of problems need to be aware that generic software (such as proxies, load balancers, firewalls, virus scanners) are unlikely to know of or respect the status code conveyed in this member. I understand what you're saying about a mismatch being possible, and some of the possible reasons why that might happen, but isn't this saying that anyone who can understand the "status" member should prefer its value when there's a mismatch (because it's less likely to have been dorked with by an intermediary - or is that even true)? So, the situation looks to me, like there's a MUST The status member, if present, is only advisory; it conveys the HTTP status code used for the convenience of the consumer. Generators MUST use the same status code in the actual HTTP response, to assure that generic HTTP software that does not understand this format still behaves correctly. that some intermediary can dork with, so the result violates the MUST, and we really can't tell the receiver what you should do at that point. "Gee, I guess you're gonna have to flip a coin to decide who to believe" would be sad, but it would be more guidance than the document has now :-) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I've wished this mechanism was available, a few times already. In this text, If such additional members are defined, their names SHOULD start with a letter (ALPHA, as per [RFC5234], Appendix B.1) and SHOULD consist of characters from ALPHA, DIGIT (Ibid.), and "_" (so that it can be serialized in formats other than JSON), and SHOULD be three characters or longer. are there any benefits to not conforming to these SHOULDs? For example, would you really need to have a two-character member name, and you'd fail if the member name was three characters long? ("Why are these not MUSTs?") From nobody Thu Dec 17 16:05:31 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDCBA1B3136; Thu, 17 Dec 2015 16:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kC8PcR8dSxK4; Thu, 17 Dec 2015 16:05:26 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467981B3134; Thu, 17 Dec 2015 16:05:26 -0800 (PST) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 87F5622E200; Thu, 17 Dec 2015 19:05:23 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: <20151217143841.8732.14093.idtracker@ietfa.amsl.com> Date: Fri, 18 Dec 2015 11:05:20 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151217143841.8732.14093.idtracker@ietfa.amsl.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.2104) Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-http-problem@ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] Spencer Dawkins' Discuss on draft-ietf-appsawg-http-problem-02: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2015 00:05:29 -0000 Hi Spencer, On 18 Dec 2015, at 1:38 am, Spencer Dawkins = wrote: > I'm elevating this to a (late) Discuss, because I haven't heard = anything > back, and didn't want the document approved without having a (short) > discussion. I'll be back to Yes after that. >=20 > In this text, >=20 > The "status" member duplicates the information available in the HTTP > status code itself, thereby bringing the possibility of disagreement > between the two. Their relative precedence is not clear, since a > disagreement might indicate that (for example) an intermediary has > modified the HTTP status code in transit. As such, those defining > problem types as well as generators and consumers of problems need = to > be aware that generic software (such as proxies, load balancers, > firewalls, virus scanners) are unlikely to know of or respect the > status code conveyed in this member. >=20 > I understand what you're saying about a mismatch being possible, and = some > of the possible reasons why that might happen, but isn't this saying = that > anyone who can understand the "status" member should prefer its value > when there's a mismatch (because it's less likely to have been dorked > with by an intermediary - or is that even true)? It really depends on what their purpose is. The HTTP status might be = updated because of legitimate HTTP machinery -- e.g., by a cache (304), = or a proxy (various things like proxy auth, disconnected operation). The = status member is there to preserve the original intent of the author, = and also for convenience (e.g., when a message is persisted, often the = status is lost).=20 > So, the situation looks to me, like there's a MUST >=20 > The status member, if present, is only advisory; it conveys the HTTP > status code used for the convenience of the consumer. Generators > MUST use the same status code in the actual HTTP response, to assure > that generic HTTP software that does not understand this format = still > behaves correctly. =20 >=20 > that some intermediary can dork with, so the result violates the MUST, > and we really can't tell the receiver what you should do at that = point. > "Gee, I guess you're gonna have to flip a coin to decide who to = believe" > would be sad, but it would be more guidance than the document has now = :-) If you're implementing generic HTTP software, you're going to be using = the HTTP status. If you're interpreting the HTTP problem itself, you're = probably going to pay attention to the one in-document, IF you pay = attention to it at all. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I've wished this mechanism was available, a few times already. >=20 > In this text, >=20 > If such additional members are defined, their names SHOULD start = with > a letter (ALPHA, as per [RFC5234], Appendix B.1) and SHOULD consist > of characters from ALPHA, DIGIT (Ibid.), and "_" (so that it can be > serialized in formats other than JSON), and SHOULD be three > characters or longer. >=20 > are there any benefits to not conforming to these SHOULDs? For = example, > would you really need to have a two-character member name, and you'd = fail > if the member name was three characters long? ("Why are these not > MUSTs?") Those requirements are to make it compatible with the XML mapping. = They're SHOULDs because someone might be really, really sure that their = problems will never be used in XML. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Thu Dec 17 16:17:10 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089AD1B3143; Thu, 17 Dec 2015 16:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEvf19Nz1OTH; Thu, 17 Dec 2015 16:17:07 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A3A61B313F; Thu, 17 Dec 2015 16:17:07 -0800 (PST) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 31F7322E25F; Thu, 17 Dec 2015 19:17:04 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: <20151216220829.2448.53583.idtracker@ietfa.amsl.com> Date: Fri, 18 Dec 2015 11:17:02 +1100 Content-Transfer-Encoding: 7bit Message-Id: References: <20151216220829.2448.53583.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-http-problem@ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] Ben Campbell's Yes on draft-ietf-appsawg-http-problem-02: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2015 00:17:09 -0000 Hi Ben, On 17 Dec 2015, at 9:08 am, Ben Campbell wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 4 talks about how a problem type SHOULD resolve to HTML > documentation. Is there ever a case where an API might be standardized to > be used by multiple origin servers? Yes. > Would each server host it's own > documentation? Possibly. > Would the problem type be a relative URL under those > circumstances? (You say it can be relative, but all the examples are > fully qualified) It could be; see the last para of 3.1. > - 4, 2nd paragraph: "New problem types need to carefully > consider..." > This is a pedantic nit, really a personal pet peeve: Designers of new > problem types should consider this. I doubt the types themselves will :-) Ack - see: https://github.com/mnot/I-D/commit/848c2f4c8 Thanks, -- Mark Nottingham https://www.mnot.net/ From nobody Thu Dec 17 16:30:31 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B74A1B3153; Thu, 17 Dec 2015 16:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNaMONOerWTo; Thu, 17 Dec 2015 16:30:24 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074001B3150; Thu, 17 Dec 2015 16:30:23 -0800 (PST) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8A4D722E272; Thu, 17 Dec 2015 19:30:21 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: <20151211171634.29111.641.idtracker@ietfa.amsl.com> Date: Fri, 18 Dec 2015 11:30:18 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151211171634.29111.641.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-http-problem@ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] Stephen Farrell's Yes on draft-ietf-appsawg-http-problem-02: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2015 00:30:26 -0000 Hi Stephen, On 12 Dec 2015, at 4:16 am, Stephen Farrell = wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - 3.1: "SHOULD NOT automatically" de-ref the type URI. Hmm, under > what circumstances would it be reasonable for any code to > automatically de-ref the type URI? If none, then either > s/SHOULD/MUST/ or maybe s/automatically//=20 I might write a linter that checks how problem types are used, and a = companion format that gives it machine-readable information about them. = In that use case, it makes sense to automatically dereference the = problem type. > - 3.1, last para: I'm sure this is a known thing, but I don't know > the answer, so I'll ask:-) If I send a request for URL > example.com/foo and am re-directed to example.net/bar, against which > of those is a relative URL in the problem detail evaluated? I hope > the answer is example.net - if not, there could be some attack that > could be mounted but I've not got a concrete example to offer. A redirect is a separate request, so it establishes the base URI. See = , especially 5.1.3. > - 3.2, last para: should "media type" be "problem type" at the end? No, we mean media type. If you want to introduce a new, = non-problem-type-specific "standard" parameter (like those already = defined), it needs to be signalled with a new media type. > - 4: "typically with the "http" scheme" - your examples are all > https, don't you mean https here too? Changing to "http or https": https://github.com/mnot/I-D/commit/c082522cfb0 Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Thu Dec 17 23:11:11 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E551B33EA; Thu, 17 Dec 2015 23:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etb2YKuFfYwa; Thu, 17 Dec 2015 23:11:07 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77C971B33E3; Thu, 17 Dec 2015 23:11:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 28733BEC3; Fri, 18 Dec 2015 07:11:05 +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 hEwrL5qKkq89; Fri, 18 Dec 2015 07:11:03 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.22.208]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AA64CBEAF; Fri, 18 Dec 2015 07:11:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1450422663; bh=7Bu4lpliu2pgsLYn/So8c6PbmwLpjyuzi3BD/zkP7iw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=swlLDD/zno5NkfN7t5m75jVvLVBlByvsn1v6xfA1EHgxOAX/4rvGm03X3x0rOgxWk hA96JPPiGI/MlqaIG+BJMBcvBpCDb6pPj9ChZCY3wqMR/8GTh8pTx3o8nUWVCUhX6n /hncqvuvi6Kl8mv0CMrOv4/kIXjjVZoTdOehu0mc= To: Mark Nottingham References: <20151211171634.29111.641.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5673B186.3000703@cs.tcd.ie> Date: Fri, 18 Dec 2015 07:11:02 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-http-problem@ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] Stephen Farrell's Yes on draft-ietf-appsawg-http-problem-02: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2015 07:11:09 -0000 Fair enough - those all all good answers, Ta, S. On 18/12/15 00:30, Mark Nottingham wrote: > Hi Stephen, > > On 12 Dec 2015, at 4:16 am, Stephen Farrell wrote: >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - 3.1: "SHOULD NOT automatically" de-ref the type URI. Hmm, under >> what circumstances would it be reasonable for any code to >> automatically de-ref the type URI? If none, then either >> s/SHOULD/MUST/ or maybe s/automatically// > > I might write a linter that checks how problem types are used, and a companion format that gives it machine-readable information about them. In that use case, it makes sense to automatically dereference the problem type. > > >> - 3.1, last para: I'm sure this is a known thing, but I don't know >> the answer, so I'll ask:-) If I send a request for URL >> example.com/foo and am re-directed to example.net/bar, against which >> of those is a relative URL in the problem detail evaluated? I hope >> the answer is example.net - if not, there could be some attack that >> could be mounted but I've not got a concrete example to offer. > > A redirect is a separate request, so it establishes the base URI. See , especially 5.1.3. > > >> - 3.2, last para: should "media type" be "problem type" at the end? > > No, we mean media type. If you want to introduce a new, non-problem-type-specific "standard" parameter (like those already defined), it needs to be signalled with a new media type. > > >> - 4: "typically with the "http" scheme" - your examples are all >> https, don't you mean https here too? > > Changing to "http or https": > https://github.com/mnot/I-D/commit/c082522cfb0 > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Wed Dec 23 07:28:45 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADF31A1A4B for ; Wed, 23 Dec 2015 07:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.112 X-Spam-Level: X-Spam-Status: No, score=-0.112 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0tHPppG7uPb for ; Wed, 23 Dec 2015 07:28:40 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 979051A1A10 for ; Wed, 23 Dec 2015 07:28:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1450884519; d=isode.com; s=selector; i=@isode.com; bh=f0OJ0TnXhhNtj9uSEnWFQTgIxQ1bJqUEnKIcEORqyho=; 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=CO/SSfNmYjaOK1K/TypsFKBp/F1A1leVYuAFyAdwcNIbxkwrVImUeKN8noSf490CGaDvEh A6fxd38go910rOadt07Kvg7el4m5RrKp/1fToHCvaPZqbTRp9UxFNdrhwdFJnA4HSF7SoJ 3lsgdcQzORxuyBbrN2M3Ncy+qFYfMOs=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 23 Dec 2015 15:28:39 +0000 To: IETF Apps Discuss From: Alexey Melnikov Message-ID: <567ABD93.4060307@isode.com> Date: Wed, 23 Dec 2015 15:28:19 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [apps-discuss] 2 remaining open issues in draft-ietf-appsawg-mdn-3798bis-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 15:28:44 -0000 Hi, There are 2 remaining issues that Tony and I would like to resolve before WGLC should be started on the document: 1) The document should say something about cardinality of Disposition-Notification-To (I think "0 or 1") and Disposition-Notification-Options header fields (not sure, 0 or 1?). If multiple instances of Disposition-Notification-Options are allowed, what should be their semantics? If you have general information about how clients handle multiple Disposition-Notification-To and/or Disposition-Notification-Options, please let us know. 2) Should RFC 2047 encoded words be allowed in various places in the machine parseable MDN part? My default preference would be to disallow that (comments are allowed in various places) and refer implementors to RFC 6533 if they want non ASCII comments. I can also see a small argument for allowing encoded words in the Reporting-UA field. If you have information about use of encoded words by existing MDN parsers/generators, please let us know. Best Regards, Alexey