From nobody Tue Sep 2 06:45:41 2014 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 041FB1A0401; Tue, 2 Sep 2014 06:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FH42ahtPLddG; Tue, 2 Sep 2014 06:45:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A6C1A874C; Tue, 2 Sep 2014 06:44:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140902134456.6992.96449.idtracker@ietfa.amsl.com> Date: Tue, 02 Sep 2014 06:44:56 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/tNCDh79WaSfZafAvS6mzlXhnexk Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-nottingham-safe-hint-04.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: Tue, 02 Sep 2014 13:45:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : The "safe" HTTP Preference Author : Mark Nottingham Filename : draft-nottingham-safe-hint-04.txt Pages : 8 Date : 2014-09-02 Abstract: This specification defines a "safe" preference for HTTP requests, expressing a desire to avoid "objectionable" content. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-nottingham-safe-hint/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-nottingham-safe-hint-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-nottingham-safe-hint-04 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 Sep 2 09:25:58 2014 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 294401A0ACF for ; Tue, 2 Sep 2014 09:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 vDLe3AGMyclS for ; Tue, 2 Sep 2014 09:25:54 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C74A1A0706 for ; Tue, 2 Sep 2014 09:25:09 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s82GP5Qr018155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 2 Sep 2014 09:25:08 -0700 Message-ID: <5405EEB2.1040107@dcrocker.net> Date: Tue, 02 Sep 2014 09:22:10 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 02 Sep 2014 09:25:08 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kSRK3Jgyljh1dxKnwVrt8Xc8pNs Subject: [apps-discuss] Atkins' blog: Email History through RFCs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 16:25:56 -0000 Email History through RFCs https://wordtothewise.com/2014/09/email-history-rfcs/ Worth a read-through. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Sep 4 11:04:58 2014 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 68E6F1A0164 for ; Thu, 4 Sep 2014 11:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCzusykRIuLH for ; Thu, 4 Sep 2014 11:04:55 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8C6F1A00B8 for ; Thu, 4 Sep 2014 11:04:54 -0700 (PDT) Received: (qmail 43274 invoked from network); 4 Sep 2014 18:04:53 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 4 Sep 2014 18:04:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:mime-version:content-type:content-transfer-encoding; s=f040.5408a9c5.k1409; i=johnl@user.iecc.com; bh=1DRbFrrlG1A3hH07sBCQtjB3YSmlo06yQPv1N7Qfu3M=; b=G+G7vQapSHbHSbn6dO/185yY3+oypTiRSrumtNQaeSW/sSGYgO4+HJTZ6AxC0tdFvwg9oyXZSrgqn1XQSEr9UmPXY31oYS+lHrC+XeK4WogSniBguEs1ia4iPPGKp8F3kopHk93639nYa71hgomNjYVIJCGi6de1ApN/iACTBJUE4gOL28Rtxl4y/XZzxbpiJZfogOF/GaevyxHMo9gdkiVrOuq69nIMLBExrKqVDI8KM+r4GVpqi4V0VqgbG80Y DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:mime-version:content-type:content-transfer-encoding; s=f040.5408a9c5.k1409; olt=johnl@user.iecc.com; bh=1DRbFrrlG1A3hH07sBCQtjB3YSmlo06yQPv1N7Qfu3M=; b=Kc2FUGBAXSktt5zHJf7JOc0xwUQeFhfPUMXRkfZuCXdRU3G9idfU9WgQRzU6s4+Sh2Wm2UMeJ536IYrB93hvZcNZ0zngd4NiaKYMwt5Us+vJUjIZS/KuGxpMrFISrpycxfTY/O93KT8sK3Zss5a8OxUmc1dUWPSCHZ7wUw5nS8oH7wutbvEWLIqF/D4BRRsu8z8NNulHLKlA/0nyO/TQEd8WFo3noapebGH4fPcJ8DDxxeZpj1YdURwZNNnwV5+C Date: 4 Sep 2014 18:04:26 -0000 Message-ID: <20140904180426.61503.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/UuHEF4ssanCT-kvkmoEnZZagrmU Cc: jck@jck.com Subject: [apps-discuss] Last minute concern on nullmx draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 18:04:57 -0000 Wietse Venema and Viktor Dukhovni just noticed the nullmx draft (sigh) and have concerns about using a 521 return code on RCPT TO. They didn't explain it very clearly, but now I see that the problem is that 221, 421, and 521 currently always mean that you should disconnect now. We're proposing a context where it just means that an address can't be delivered but the SMTP session is otherwise OK. They argue that this makes it harder to write milters and such. This seems like a plausible concern. So I'd suggest changing the 521 return code to 550 (Requested action not taken: mailbox unavailable) or 553 (Requested action not taken: mailbox name not allowed) instead. I realize this is pretty late in the process, but it seems like a reasonable change to make. R's, John From nobody Thu Sep 4 15:26:59 2014 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 A72521A0061 for ; Thu, 4 Sep 2014 15:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xq-lypUDVyJ7 for ; Thu, 4 Sep 2014 15:26:56 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDE0D1A005F for ; Thu, 4 Sep 2014 15:26:55 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id u10so12594050lbd.34 for ; Thu, 04 Sep 2014 15:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ul20RdLwtSOxqh1zgPOH/YUFnz9mlLZXCMp9zTS6Cj4=; b=eezEHgXvKZgWwjpEu0NO/W4U/MfZ8Ejmjnzxx3cbjXTTOguZ7UNuNPl+cn/YcxOEXO m/sYtuxg2RVIcSqBJa0SFApz9YMCym1Dsf8eMmQvHCozygVen1Not+o9NhjTsen2VCeh KZvD8K1JVja4XNrhgo4JqSC9jIKWwmJuvj42g0JLzyEtt3XjoWrpjm/DxQPHSVhwFwgV dqemKP+2kHIrzpeXmHMEyhgUeZW8R2Z3PZshyTHH9R9TzSnYGynMEwksh0IlbhvbUNAN ayTodJH6DENYRlZUIoyBA151lC4FgzJ5BPo+ICCekzzie7/BYfuMa4od+L9XNgz1j77i VE6g== MIME-Version: 1.0 X-Received: by 10.112.225.7 with SMTP id rg7mr7119686lbc.52.1409869614154; Thu, 04 Sep 2014 15:26:54 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Thu, 4 Sep 2014 15:26:54 -0700 (PDT) In-Reply-To: <20140904180426.61503.qmail@joyce.lan> References: <20140904180426.61503.qmail@joyce.lan> Date: Thu, 4 Sep 2014 15:26:54 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=001a11348d4e880d2a050244d929 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/vv4khuTgSg_-AkmBZoUpGv787Ig Cc: jck@jck.com, IETF Apps Discuss Subject: Re: [apps-discuss] Last minute concern on nullmx draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 22:26:57 -0000 --001a11348d4e880d2a050244d929 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 4, 2014 at 11:04 AM, John Levine wrote: > They didn't explain it very clearly, but now I see that the problem is > that 221, 421, and 521 currently always mean that you should > disconnect now. We're proposing a context where it just means that an > address can't be delivered but the SMTP session is otherwise OK. They > argue that this makes it harder to write milters and such. This seems > like a plausible concern. > Interesting observation. Is that by design, or was it a coincidence? Why does it make milters harder to write? Suggested resolution seems OK to me. -MSK --001a11348d4e880d2a050244d929 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 4, 2014 at 11:04 AM, John Levine <johnl@taugh.c= om> wrote:
They didn't explain it very clearly, but now I see that the problem is<= br> that 221, 421, and 521 currently always mean that you should
disconnect now. We're proposing a context where it just means that an address can't be delivered but the SMTP session is otherwise OK.=C2=A0 = They
argue that this makes it harder to write milters and such.=C2=A0 This seems=
like a plausible concern.

Interesting o= bservation.=C2=A0 Is that by design, or was it a coincidence?

=
Why does it make milters harder to write?

Suggested = resolution seems OK to me.

-MSK
--001a11348d4e880d2a050244d929-- From nobody Thu Sep 4 15:43:26 2014 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 A0E701A0092 for ; Thu, 4 Sep 2014 15:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 TJftPWUFjO9Y for ; Thu, 4 Sep 2014 15:43:24 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id BF4B51A0084 for ; Thu, 4 Sep 2014 15:43:24 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 3C8D410062 for ; Thu, 4 Sep 2014 15:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=L0cJg5MLeBAVhEW73HC5 PIEROiU=; b=Vel9tdkluchvzZrFj8et7kuUNqJulA8pY8yu6JK7RDuHdkjBBoqM wbEVXlUU7SBw52Ne3WqmC3YlfDXCjE1xwLOTTFL3qlnZNGYjRQ/vIsJAUBl/ivSG PeHVOJoZn88pAatODyzXK/vEfae9pLKsPtGHyfXYqz/GY4mUAmEu2cs= Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id E5AAC10060 for ; Thu, 4 Sep 2014 15:43:23 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id w61so10967345wes.39 for ; Thu, 04 Sep 2014 15:43:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.37.241 with SMTP id b17mr9410561wik.70.1409870602589; Thu, 04 Sep 2014 15:43:22 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Thu, 4 Sep 2014 15:43:22 -0700 (PDT) In-Reply-To: References: <20140904180426.61503.qmail@joyce.lan> Date: Thu, 4 Sep 2014 17:43:22 -0500 Message-ID: From: Nico Williams To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/IIpvkoifXfaIXzspXpdU7O2IKdE Cc: jck@jck.com, John Levine , IETF Apps Discuss Subject: Re: [apps-discuss] Last minute concern on nullmx draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 22:43:25 -0000 On Thu, Sep 4, 2014 at 5:26 PM, Murray S. Kucherawy wrote: > On Thu, Sep 4, 2014 at 11:04 AM, John Levine wrote: >> >> They didn't explain it very clearly, but now I see that the problem is >> that 221, 421, and 521 currently always mean that you should >> disconnect now. We're proposing a context where it just means that an >> address can't be delivered but the SMTP session is otherwise OK. They >> argue that this makes it harder to write milters and such. This seems >> like a plausible concern. > > Interesting observation. Is that by design, or was it a coincidence? The same codes are not assigned for the 2xx/4xx/5xx ranges, but at least for x21 they are. > Why does it make milters harder to write? http://www.ietf.org/mail-archive/web/ietf/current/msg89507.html The idea is that 5xx can be mapped to 4xx: | Until now the Postfix community has relied on this property as part | of a temporary safety net (to avoid missing email, replace 5XY with | 4XY; after watching the logs for some time, remove the safety net). Seems more than plausible to me. Nico -- From nobody Thu Sep 4 17:28:51 2014 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 CD4861A02E9 for ; Thu, 4 Sep 2014 17:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASKZ2zhqVBRy for ; Thu, 4 Sep 2014 17:28:49 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 721CF1A02E6 for ; Thu, 4 Sep 2014 17:28:49 -0700 (PDT) Received: (qmail 91057 invoked from network); 5 Sep 2014 00:28:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=163b0.540903c0.k1409; bh=tclFqBJMq775qn98pusUyukxbjmqXI+d2dveqFuGcvM=; b=rq2wumwPvUj0moiPhBczhkpUeKRH3ggI+69YqIX6PVKpdh3RYPoIiBSnYSUWn3+Wv838Sa2h663ldlH8mj5Hxzck9Hy7zDQm2VM7VccSclZ52qEpDEgWzdKiHpGp9cDo4co4U13l2qBuX0yj3Ctpn42tHUELBlACIat9r/tQZiMmUalgyA8dCifooc4NcVPyhHncWh4YYLfrlu+ymjr47pNMR2ILK5hSbV15R/BQvbX+TPd1OpHaOUOx6Pr44Be+ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=163b0.540903c0.k1409; bh=tclFqBJMq775qn98pusUyukxbjmqXI+d2dveqFuGcvM=; b=l3OtiMj5IpKErEDYwr+jcsi4DkZaJsR82dIrMLJ2tGh3SN8aunHRMetit0XmVyKX1OYdfq7op5xSlwNwj9XAdE1a5mkk5EfZh3esiUWkyiYHdBSkt9sUKKyI23JG9pMYR5pkmNj82GdlcTfL2WN7Pc3GHK9o5P+1CurlV91YiCaid4bKgCOFGL7spog/pnL0iegLB5+tj0bZWyYKpxeDFgJCO9c8LMbUxaMjRc0v5m0C0EOgajjIu1cUHLz1ZeQF Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 05 Sep 2014 00:28:47 -0000 Date: 4 Sep 2014 20:28:47 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20140904180426.61503.qmail@joyce.lan> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/OnfxWsG1ba4v5bXgL4EDh92brQc Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Last minute concern on nullmx draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 00:28:50 -0000 >> They didn't explain it very clearly, but now I see that the problem is >> that 221, 421, and 521 currently always mean that you should >> disconnect now. We're proposing a context where it just means that an >> address can't be delivered but the SMTP session is otherwise OK. They >> argue that this makes it harder to write milters and such. This seems >> like a plausible concern. >> > > Interesting observation. Is that by design, or was it a coincidence? > > Why does it make milters harder to write? Beats me, I still use qmail and milters are this strange exotic thing. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Sep 4 17:34:05 2014 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 74D981A031D for ; Thu, 4 Sep 2014 17:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668] 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 XzCUQMvqHT7A for ; Thu, 4 Sep 2014 17:34:02 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id A574E1A02EF for ; Thu, 4 Sep 2014 17:34:02 -0700 (PDT) Received: from [192.168.80.56] (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 742C180EC1 for ; Thu, 4 Sep 2014 17:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1409877242; bh=Jg00dHpIaXIts1HqMFflUwik2MKODoH9K4xiRF7gJM8=; h=Subject:From:In-Reply-To:Date:References:To:From; b=jTJg9wADtqfua05QpD07XX6FVakBYuwEfZNwzcKRR6td7X9bqmRPUxQgVBSL/LgAn LiG4q1NHqaPmnQGKMtBzQig7clmAGISA6A//H3sbD3GHzfM4X/UPBqilx2AxpE7h8K mzbAs6xtsAIFqSd6Cv0gH5IDfOdRrUKJFaVjULFU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Steve Atkins In-Reply-To: Date: Thu, 4 Sep 2014 17:33:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <263D27FA-185B-48FD-AEB7-7FF173F08ACC@wordtothewise.com> References: <20140904180426.61503.qmail@joyce.lan> To: IETF Apps Discuss X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/174IQ2NDjaEmIJiICg8YOeXru04 Subject: Re: [apps-discuss] Last minute concern on nullmx draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 00:34:04 -0000 On Sep 4, 2014, at 3:43 PM, Nico Williams wrote: > On Thu, Sep 4, 2014 at 5:26 PM, Murray S. Kucherawy = wrote: >> On Thu, Sep 4, 2014 at 11:04 AM, John Levine wrote: >>>=20 >>> They didn't explain it very clearly, but now I see that the problem = is >>> that 221, 421, and 521 currently always mean that you should >>> disconnect now. We're proposing a context where it just means that = an >>> address can't be delivered but the SMTP session is otherwise OK. = They >>> argue that this makes it harder to write milters and such. This = seems >>> like a plausible concern. 553 seems like a reasonable change. >>=20 >> Interesting observation. Is that by design, or was it a coincidence? >=20 > The same codes are not assigned for the 2xx/4xx/5xx ranges, but at > least for x21 they are. >=20 >> Why does it make milters harder to write? >=20 > http://www.ietf.org/mail-archive/web/ietf/current/msg89507.html >=20 > The idea is that 5xx can be mapped to 4xx: >=20 > | Until now the Postfix community has relied on this property as part > | of a temporary safety net (to avoid missing email, replace 5XY with > | 4XY; after watching the logs for some time, remove the safety net). Is this documented anywhere? (Should it be?) Cheers, Steve From nobody Thu Sep 4 20:12:41 2014 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 9A5DB1A02BD for ; Thu, 4 Sep 2014 20:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668, 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 nEjacgAs_EPy for ; Thu, 4 Sep 2014 20:12:38 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8F31A0250 for ; Thu, 4 Sep 2014 20:12:37 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PC752G25J400310C@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 4 Sep 2014 20:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1409886457; bh=N8heHtrcSyTWCcfe3evF+k6T+U59Uree16RV5qZwdok=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=GLa9gifKd+AFTfMFA84fmb6SR/QA/zZt30+34r/0ddp6jn/XzV0cAQsNbHaU5/Wiw h3qfs/QXkqdeBS0Gbz9AR/EtFf+vuyZraKoRoJL7FhICKlQYXBTJxYv1PxHOYzLp8T 6MMwCfz6aBpc5JYXvDYzUIiZQXYqJ3K1m3yr1pWo= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PC6T697XOG002TYP@mauve.mrochek.com>; Thu, 04 Sep 2014 20:07:32 -0700 (PDT) Message-id: <01PC752EKWWC002TYP@mauve.mrochek.com> Date: Thu, 04 Sep 2014 20:01:56 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 04 Sep 2014 17:33:55 -0700" <263D27FA-185B-48FD-AEB7-7FF173F08ACC@wordtothewise.com> References: <20140904180426.61503.qmail@joyce.lan> <263D27FA-185B-48FD-AEB7-7FF173F08ACC@wordtothewise.com> To: Steve Atkins Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ngBFAFKmd5dB7UuzeQg3a0Htklo Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Last minute concern on nullmx draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 03:12:39 -0000 > On Sep 4, 2014, at 3:43 PM, Nico Williams wrote: > > On Thu, Sep 4, 2014 at 5:26 PM, Murray S. Kucherawy wrote: > >> On Thu, Sep 4, 2014 at 11:04 AM, John Levine wrote: > >>> > >>> They didn't explain it very clearly, but now I see that the problem is > >>> that 221, 421, and 521 currently always mean that you should > >>> disconnect now. We're proposing a context where it just means that an > >>> address can't be delivered but the SMTP session is otherwise OK. They > >>> argue that this makes it harder to write milters and such. This seems > >>> like a plausible concern. > 553 seems like a reasonable change. > >> > >> Interesting observation. Is that by design, or was it a coincidence? > > > > The same codes are not assigned for the 2xx/4xx/5xx ranges, but at > > least for x21 they are. > > > >> Why does it make milters harder to write? > > > > http://www.ietf.org/mail-archive/web/ietf/current/msg89507.html > > > > The idea is that 5xx can be mapped to 4xx: > > > > | Until now the Postfix community has relied on this property as part > > | of a temporary safety net (to avoid missing email, replace 5XY with > > | 4XY; after watching the logs for some time, remove the safety net). > Is this documented anywhere? (Should it be?) As I pointed out previously, since the mapping fails in a large number of cases, either resulting in undefined codes or a semantically distinct code, I certainly hope not. As for what actually is documented, the theory of reply codes in RFC 821 only states that the third digit is reserved for "the finest gradation of information". Ned From nobody Thu Sep 4 20:20:36 2014 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 7A5581A03AD for ; Thu, 4 Sep 2014 20:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668, 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 BHEbu50rvEyS for ; Thu, 4 Sep 2014 20:20:33 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE3D1A03AB for ; Thu, 4 Sep 2014 20:20:33 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PC75C9QBAO002QDE@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 4 Sep 2014 20:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1409886932; bh=uWvBlqPnt3XGq6sbGme2tLY8SrbufXp9C0BRFCL8X/8=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=QHSozqhdzQ76OHTl+/vYXlWA6LoWZ18DzmQNX8aNyal4Cx8vcnTvr0iIvMhrUmOHE FwgpVeGHc+IYoV/T38DyB/ksx8U/AQbrgF+Ex8bogqKAws3c+cgbveQJCee1nudahL /WUug+mOBoOn+leqFkjhAKmD5PJJhsKPG/VzMZqk= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PC6T697XOG002TYP@mauve.mrochek.com>; Thu, 04 Sep 2014 20:15:28 -0700 (PDT) Message-id: <01PC75C8IP96002TYP@mauve.mrochek.com> Date: Thu, 04 Sep 2014 20:13:01 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 04 Sep 2014 17:43:22 -0500" References: <20140904180426.61503.qmail@joyce.lan> To: Nico Williams Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/rKYeuASuBakKOBvAW4yyDkF2axM Cc: John Levine , jck@jck.com, IETF Apps Discuss Subject: Re: [apps-discuss] Last minute concern on nullmx draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 03:20:34 -0000 > On Thu, Sep 4, 2014 at 5:26 PM, Murray S. Kucherawy wrote: > > On Thu, Sep 4, 2014 at 11:04 AM, John Levine wrote: > >> > >> They didn't explain it very clearly, but now I see that the problem is > >> that 221, 421, and 521 currently always mean that you should > >> disconnect now. We're proposing a context where it just means that an > >> address can't be delivered but the SMTP session is otherwise OK. They > >> argue that this makes it harder to write milters and such. This seems > >> like a plausible concern. > > > > Interesting observation. Is that by design, or was it a coincidence? > The same codes are not assigned for the 2xx/4xx/5xx ranges, but at > least for x21 they are. > > Why does it make milters harder to write? > http://www.ietf.org/mail-archive/web/ietf/current/msg89507.html > The idea is that 5xx can be mapped to 4xx: > | Until now the Postfix community has relied on this property as part > | of a temporary safety net (to avoid missing email, replace 5XY with > | 4XY; after watching the logs for some time, remove the safety net). > Seems more than plausible to me. The concept of treating a 5YZ as temporary is entirely plausible, the specific implementation of blindly mapping codes around is not. And it still doesn't explain why this makes milters hard to write. Ned From nobody Fri Sep 5 03:22:08 2014 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 7474F1A0681 for ; Fri, 5 Sep 2014 03:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_R5M7Q_OKBa for ; Fri, 5 Sep 2014 03:21:41 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF9101A0647 for ; Fri, 5 Sep 2014 03:21:40 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:42136) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1XPqe8-0004b3-si (Exim 4.82_3-c0e5623) (return-path ); Fri, 05 Sep 2014 11:21:37 +0100 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1XPqe8-000706-Ti (Exim 4.72) (return-path ); Fri, 05 Sep 2014 11:21:36 +0100 Date: Fri, 5 Sep 2014 11:21:36 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John Levine In-Reply-To: <20140904180426.61503.qmail@joyce.lan> Message-ID: References: <20140904180426.61503.qmail@joyce.lan> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/dFp4ezNh_cZpbcFx91hHzh_W9u8 Cc: jck@jck.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Last minute concern on nullmx draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 10:21:43 -0000 John Levine wrote: > > They didn't explain it very clearly, but now I see that the problem is > that 221, 421, and 521 currently always mean that you should > disconnect now. We're proposing a context where it just means that an > address can't be delivered but the SMTP session is otherwise OK. I think they are right that this is not following the theory of reply codes properly. Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. From nobody Fri Sep 5 07:54:21 2014 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 1E6741A06F6 for ; Fri, 5 Sep 2014 07:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] 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 pK0h1-AVNfE8 for ; Fri, 5 Sep 2014 07:54:16 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5281A02FC for ; Fri, 5 Sep 2014 07:54:16 -0700 (PDT) Received: from [198.252.137.121] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XPutz-000Iv0-3X; Fri, 05 Sep 2014 10:54:15 -0400 Date: Fri, 05 Sep 2014 10:54:10 -0400 From: John C Klensin To: John Levine Message-ID: <314068007672D901AF0FC6DC@JcK-HP8200.jck.com> In-Reply-To: <20140904180426.61503.qmail@joyce.lan> References: <20140904180426.61503.qmail@joyce.lan> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.121 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-v-Fq0DXoUlaaiPKiqdngr5uZ34 Cc: apps-discuss@ietf.org Subject: [apps-discuss] SMTP reply codes and nullMX (was: Re: Last minute concern on nullmx draft) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 14:54:18 -0000 --On Thursday, September 04, 2014 18:04 +0000 John Levine wrote: >... > They didn't explain it very clearly, but now I see that the > problem is that 221, 421, and 521 currently always mean that > you should disconnect now. We're proposing a context where it > just means that an address can't be delivered but the SMTP > session is otherwise OK. They argue that this makes it harder > to write milters and such. This seems like a plausible > concern. > > So I'd suggest changing the 521 return code to 550 (Requested > action not taken: mailbox unavailable) or 553 (Requested > action not taken: mailbox name not allowed) instead. Hi. Replying to this message for convenience, but I have read the "Last minute concern" thread to date. John wrote me on Tuesday suggesting that I fix draft-klensin-smtp-521code to explicitly allow for the RCPT case. I had intended to get that done immediately but was then distracted by another set of issues. Turns out that was good luck... and better luck that I decided to read this thread before posting that revision. All other things being equal, I prefer not using 521 for a situation in which an SMTP client concludes from external information (nullMX included) that a site won't accept mail. My interpretation of the SMTP model is that the only way one can definitively figure out that a server won't accept something is to ask the relevant server. This is true whether the thing being proposed is a domain name/ host name, a mailbox (and hence a local-part), an extension, or a command (e.g., VRFY or EXPN). That doesn't argue against nullMX, but, especially in the light of many years of experience with disconnects between mail/SMTP administrators and DNS administrators, it strongly suggests that we should distinguish between direct information and indirect information. Given the theory of second-digit reply codes, I also believe that 55x is a better choice for the RCPT case than 521. But I'm also reluctant to see anything in the 550 - 554 range used, partially because of the "indirect information" issue outlined above. So, if we have to invent or assign a different code, why not invent 556 or, in principle, 522? I/we have the "code 521" draft open; it would take only a few extra minutes to add a new code to it with very specific functionality of either "the DNS told me there was no service for that domain" or "I know from external sources, such as the DNS, there there is no service". I will hold draft-klensin-smtp-521code-02 until someone tells me what to do. If 521 is not needed for nullMX, we don't need additional codes, it is probably ready to go to Barry and Pete as an independent submission. john p.s. In working on draft-klensin-smtp-521code, I discovered another glitch in nullMX; watch for a separate note. p.p.s. "jck@jck.com" is not a deliverable address. From nobody Fri Sep 5 07:59:16 2014 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 1F0DD1A070B for ; Fri, 5 Sep 2014 07:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMlwj4wd9zxj for ; Fri, 5 Sep 2014 07:59:13 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC5E31A06F6 for ; Fri, 5 Sep 2014 07:59:12 -0700 (PDT) Received: (qmail 86890 invoked from network); 5 Sep 2014 14:59:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15369.5409cfbf.k1409; bh=/NJd2IoWaBMjFjedPc/JXzPbROW9vYnRuP5Vwn/By4I=; b=JcwK2Zx/A23WzFsBwIFOycKpi/8HvJ2sAD6ZrUTqVYS7YNub2eYf2h5zTxdntQlgqExnTPY3OXPfphW/XEFn1uTlSfNBpG2Wl7nYgkYsG/4tGIM9bePa9h/ohW0seuf5QkIXCumU1tdPMQFEo2trXWKDPYbX/GHi73PcWmRF3bzLNsiSPQLcHirex79YIqTGIZFcwdbGXxvhw8Zm/757gemC0T918BLTPj6UfQ3o2DUYiBqwURGiR0CmK+mzTzgQ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15369.5409cfbf.k1409; bh=/NJd2IoWaBMjFjedPc/JXzPbROW9vYnRuP5Vwn/By4I=; b=5sesaJPyax1IyRfI8y7vJ2BWi/9t9d4caRQaKh/TFLojc0WsnpN6HqWPFzYM8A7W3LyyDdTF80Pxrqd2qwtIMOMJE0QDMwoMQSCq8CAph+Fy/Y6GWgvkKJZeqwpcfKImKZE1P48i30MLU8QkkgANvfGW+mILv4TonU8zcgU29QWRjx6vD74/fzTvgRWLLGLVoOq4hh7bliBk/qJA/UgP6ty6o8oAyEJ9HYfeEa7iQtzfqkwlv+yFNmY9xm26jBpT Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 05 Sep 2014 14:59:11 -0000 Date: 5 Sep 2014 10:59:10 -0400 Message-ID: From: "John R Levine" To: "John C Klensin" In-Reply-To: <314068007672D901AF0FC6DC@JcK-HP8200.jck.com> References: <20140904180426.61503.qmail@joyce.lan> <314068007672D901AF0FC6DC@JcK-HP8200.jck.com> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0JDB8AZNOirkulSB24k3fpSHE5g Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] SMTP reply codes and nullMX (was: Re: Last minute concern on nullmx draft) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 14:59:14 -0000 > So, if we have to invent or assign a different code, why not > invent 556 or, in principle, 522? I/we have the "code 521" > draft open; it would take only a few extra minutes to add a new > code to it with very specific functionality of either "the DNS > told me there was no service for that domain" or "I know from > external sources, such as the DNS, there there is no service". 556 is fine with me if it's fine with everyone else. I'm assuming that if your draft invents it, we can just refer to it in nullmx, right? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri Sep 5 08:32:38 2014 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 5244B1A0745 for ; Fri, 5 Sep 2014 08:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] 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 7wgk-4gIgqRy for ; Fri, 5 Sep 2014 08:32:31 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 702941A071C for ; Fri, 5 Sep 2014 08:32:31 -0700 (PDT) Received: from [198.252.137.121] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XPvV0-000J1i-08 for apps-discuss@ietf.org; Fri, 05 Sep 2014 11:32:30 -0400 Date: Fri, 05 Sep 2014 11:32:24 -0400 From: John C Klensin To: IETF Apps Discuss Message-ID: <666FFC4DAB7A1AF03D24545D@JcK-HP8200.jck.com> In-Reply-To: <01PC75C8IP96002TYP@mauve.mrochek.com> References: <20140904180426.61503.qmail@joyce.lan> <01PC75C8IP96002TYP@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.121 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3G0lbFY8K7OhHZlLXoOo79FfYsQ Subject: [apps-discuss] Another veyr late nullMX glitch (was: Last minute concern on nullmx draft) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 15:32:35 -0000 Hi. In the process of working on nullMX-related text for draft-klensin-smtp-521code, I realized that there is a missing piece that the spec should address. It is a little more complex than trying to pick an error code. Even without extensions, SMTP has three commands whose arguments are forward-pointing addresses, not just RCPT. The dummy server approach of RFC 1846 (etc.) deals with all of them the same way -- if the host won't accept an SMTP connection, then RCPT, VRFY, and EXPN are equally irrelevant. But, if the client is scanning for commands and doing DNS lookups, things get more complicated. In the RCTP case, there is a clear specification about doing MX lookups on the domain in the address -- the facility on which nullMX depends. But there is no such specification or requirement to do MX lookups for VRFY and EXPN. At least by implication, the server with which the mail session is open is expected to figure out how to respond to the command with information or indicate that it cannot (with 252, 251, or 551 -- See RFC 5321 Section 3.5.3). The other thing that is notable about this is that 252 is a kind of "indirect information" response, specifically that the host contacted will try to deliver a message sent to that address, but has no information as to whether it is valid. The nullMX spec is correct as written because it talks about "mail delivery" and "mail delivery attempts" but phrases like "without requiring domains to create SMTP listeners dedicated to preventing delivery attempts" strongly imply that SMTP listeners are unnecessary to prevent timeout and potential retry behavior. It seems to me that the nullMX spec is incomplete if it does not address this issue in some way, even if all it says is that the DNS entry provides protection against actual mail transactions but not, e.g., query transactions such as those implied by VRFY or EXPN. In particular, a client can conform to the nullMX spec but still try to open SMTP connections to the relevant target host. best, john From nobody Fri Sep 5 09:04:02 2014 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 92BB61A0724 for ; Fri, 5 Sep 2014 09:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] 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 3xRoLWzfsY4s for ; Fri, 5 Sep 2014 09:03:46 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29DAB1A034E for ; Fri, 5 Sep 2014 09:03:39 -0700 (PDT) Received: from [198.252.137.121] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XPvz5-000J3r-57; Fri, 05 Sep 2014 12:03:35 -0400 Date: Fri, 05 Sep 2014 12:03:30 -0400 From: John C Klensin To: John R Levine Message-ID: <824E7E0026F4B3333BA1AA3F@JcK-HP8200.jck.com> In-Reply-To: References: <20140904180426.61503.qmail@joyce.lan> <314068007672D901AF0FC6DC@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.121 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/YjvY9pxjgVg21Rl5_ByHxsmCzGY Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] SMTP reply codes and nullMX (was: Re: Last minute concern on nullmx draft) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 16:03:52 -0000 --On Friday, September 05, 2014 10:59 -0400 John R Levine wrote: >> So, if we have to invent or assign a different code, why not >> invent 556 or, in principle, 522? I/we have the "code 521" >> draft open; it would take only a few extra minutes to add a >> new code to it with very specific functionality of either >> "the DNS told me there was no service for that domain" or "I >> know from external sources, such as the DNS, there there is >> no service". > > 556 is fine with me if it's fine with everyone else. I'm > assuming that if your draft invents it, we can just refer to > it in nullmx, right? Absolutely -- no more problem referring to it than there was with 221 (or a bit less given our exchange at the beginning of the week). If others like that, I'll get a new draft with it specified out RSN. The ADs and this WG should figure out, ideally very soon, whether it wants to adopt/review that draft or whether I should specify discussion on ietf-smtp and handle it as an individual submission. john From nobody Fri Sep 5 10:12:07 2014 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 29B431A0479 for ; Fri, 5 Sep 2014 10:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMFimM0owh88 for ; Fri, 5 Sep 2014 10:12:04 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2753F1A037B for ; Fri, 5 Sep 2014 10:12:03 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id gl10so636937lab.17 for ; Fri, 05 Sep 2014 10:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ITqmuJpYK0jLT/7hyTINXQ7YwwrBGaAT66SsnxhXEG0=; b=dfd9FaVvKJtBu/3+qQzVuQNVEb/pZgcP1n9qcE/Ms30QdPti9KZLAkKzO4M/FWYXGt lo2re/X7CZXuQnduDD68s+HN4bMk2PIDRv3VZUdgFVn8K45+2RWxjf8vFN46kDMkOaf6 0nQeF/zFuz0VumIj2ubjTo9ld8NAl8FIuGLGjsDdZOFFWwtmJ3szlPJwrJJfpCHtqfRk wxXOKgWsNTGxNX6/gkjFftmqjnaV7X2mzgKnv5w8in2U3xTfF9F0eb2eF/QkOj3r0Cz8 8gUJqPO6LGlye9TKWxGA1GUjIvxZBZ76adMLE279SpwC+bXPprU69nU0nbbpzZmTm78c QjDA== MIME-Version: 1.0 X-Received: by 10.152.7.212 with SMTP id l20mr13305915laa.7.1409937122423; Fri, 05 Sep 2014 10:12:02 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Fri, 5 Sep 2014 10:12:02 -0700 (PDT) In-Reply-To: References: <20140904180426.61503.qmail@joyce.lan> Date: Fri, 5 Sep 2014 10:12:02 -0700 Message-ID: From: "Murray S. Kucherawy" To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c34a0a5679340502549125 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/AJSwomoF0Cfw7DAHlhon-GErIRo Cc: jck@jck.com, John Levine , IETF Apps Discuss Subject: Re: [apps-discuss] Last minute concern on nullmx draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 17:12:06 -0000 --001a11c34a0a5679340502549125 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 4, 2014 at 3:43 PM, Nico Williams wrote: > > Interesting observation. Is that by design, or was it a coincidence? > > The same codes are not assigned for the 2xx/4xx/5xx ranges, but at > least for x21 they are. > > > Why does it make milters harder to write? > > http://www.ietf.org/mail-archive/web/ietf/current/msg89507.html > > The idea is that 5xx can be mapped to 4xx: > > | Until now the Postfix community has relied on this property as part > | of a temporary safety net (to avoid missing email, replace 5XY with > | 4XY; after watching the logs for some time, remove the safety net). > > Seems more than plausible to me. > But this seems to me like it's building something based on a coincidence, which is never a safe thing to do. I suppose since there's widely deployed code that does it, then that's something worth considering. -MSK --001a11c34a0a5679340502549125 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 4, 2014 at 3:43 PM, Nico Williams <nico@c= ryptonector.com> wrote:
> Int= eresting observation.=C2=A0 Is that by design, or was it a coincidence?

The same codes are not assigned for the 2xx/4xx/5xx ranges, but at least for x21 they are.

> Why does it make milters harder to write?

http://www.ietf.org/mail-archive/web/ietf/current/= msg89507.html

The idea is that 5xx can be mapped to 4xx:

| Until now the Postfix community has relied on this property as part
| of a temporary safety net (to avoid missing email, replace 5XY with
| 4XY; after watching the logs for some time, remove the safety net).

Seems more than plausible to me.

But th= is seems to me like it's building something based on a coincidence, whi= ch is never a safe thing to do.

I suppose since there's widely d= eployed code that does it, then that's something worth considering.
=
-MSK
--001a11c34a0a5679340502549125-- From nobody Fri Sep 5 10:24:30 2014 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 2835B1A0386 for ; Fri, 5 Sep 2014 10:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zF5zH-ppxF6E for ; Fri, 5 Sep 2014 10:24:28 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E20801A071F for ; Fri, 5 Sep 2014 10:24:27 -0700 (PDT) Received: (qmail 8344 invoked from network); 5 Sep 2014 17:24:26 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 5 Sep 2014 17:24:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1909.5409f1ca.k1409; i=johnl@user.iecc.com; bh=4+NC2KqECQ7s1s3pnhk9YJvkb11NfimU4T5dRTE/zgM=; b=egHI4IjevqsJUoYSbJ4g+c1vxIqceBRFepuyH7rLLDfT8uEj3qWWxKyOznvYdkTh/wHSr820/ncoLiPFu4aOaRsd1nd5nwSNzAJgW0Hnq7htsNEJw68Zd/ZeiQcktIUBEoEVt0LFr05qqulMU76Zq/lLs/4uK9IYHGPWRuBYtHzOplK8woSb1LoAUO9tUaOoF8Yi3gyTKjJPnstn1y7Xsj7AX4+QoaD3TPUE7OEmukIkzJ3/Arx1naRtOaRsuCm3 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1909.5409f1ca.k1409; olt=johnl@user.iecc.com; bh=4+NC2KqECQ7s1s3pnhk9YJvkb11NfimU4T5dRTE/zgM=; b=p6MR9Jt+5juZjxpQRajuO+Ent36SZ05LYXL74EPZXVHYvgmZF1WKbSM2FPWHWZ+JZWfU2DfALvpjW2GI5qKfboc8wRffjqPI2jmnFv/AMCQTiGla3g8WcE0sgmmbg21JyoK8MG7UxOl0UZmdx7OW+UbvaT//zuIG5wK0gVF6k89EH6AxE1SJT7aqWLQ7NtRMGkKrZo40hQFF7H8Ldy7FIjQm6NOkYBCINyn8ef96fYyckUvefaAtAyPsd6hyo1rS Date: 5 Sep 2014 17:24:04 -0000 Message-ID: <20140905172404.6408.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <666FFC4DAB7A1AF03D24545D@JcK-HP8200.jck.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7MZfY0bSqBLRjs98VQx2ZmR21ME Subject: Re: [apps-discuss] Another veyr late nullMX glitch (was: Last minute concern on nullmx draft) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 17:24:29 -0000 > In particular, a client can conform to the nullMX spec >but still try to open SMTP connections to the relevant target >host. I don't see how this can happen. If a domain publishes nullmx, there is no target host. Perhaps I'm misreading 5321, but it's always been my understanding that VRFY and EXPN only apply to domains for which the current host is a delivery host. If I am foo.com, not an MX of bar.com, and you say "VRFY alice@bar.com" or "EXPN bob@bar.com", I'd return 550 or maybe a passive aggressive 252. How would nullmx change this? R's, John From nobody Fri Sep 5 11:05:24 2014 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 0BE291A6EFB for ; Fri, 5 Sep 2014 11:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668, 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 C8HdKDc7Bxh4 for ; Fri, 5 Sep 2014 11:04:52 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id CA32B1A6EE8 for ; Fri, 5 Sep 2014 11:04:47 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PC808KCNBK002G4J@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 5 Sep 2014 10:59:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1409939985; bh=70W0xYWSSwn+Zkla34hLWqYvFVJ0Mv+onMX7eifRPU0=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=rwGSSb6h3DP8QS5vZoPTXCqcI/G1ObDjwrB9m/QZENWS2sdcptiVetdUuQGUw+pax 0xsFoXC3slifOm/OMdw35dU4LtvOzC5RS+beAB6SL6YGgV8ZJ8g/aMIN2zPiRSoLPm O2LhfVW9R6TsNSB6ohsyVdwKOJlE2nstf/acuKFw= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PC6KHUDFZ4002WQY@mauve.mrochek.com>; Fri, 05 Sep 2014 10:59:42 -0700 (PDT) Message-id: <01PC808IXI0I002WQY@mauve.mrochek.com> Date: Fri, 05 Sep 2014 10:38:44 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 05 Sep 2014 11:32:24 -0400" <666FFC4DAB7A1AF03D24545D@JcK-HP8200.jck.com> References: <20140904180426.61503.qmail@joyce.lan> <01PC75C8IP96002TYP@mauve.mrochek.com> <666FFC4DAB7A1AF03D24545D@JcK-HP8200.jck.com> To: John C Klensin Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Oi6Pt3rxaW6Rx0BaHIp_OrwRe24 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Another veyr late nullMX glitch (was: Last minute concern on nullmx draft) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 18:05:12 -0000 > Hi. > In the process of working on nullMX-related text for > draft-klensin-smtp-521code, I realized that there is a missing > piece that the spec should address. It is a little more complex > than trying to pick an error code. > Even without extensions, SMTP has three commands whose arguments > are forward-pointing addresses, not just RCPT. The dummy server > approach of RFC 1846 (etc.) deals with all of them the same way > -- if the host won't accept an SMTP connection, then RCPT, VRFY, > and EXPN are equally irrelevant. But, if the client is scanning > for commands and doing DNS lookups, things get more complicated. > In the RCTP case, there is a clear specification about doing MX > lookups on the domain in the address -- the facility on which > nullMX depends. There are actually two cases here - doing the lookup at RCPT TO time and doing it later. And both of them apply much more to SUBMIT than to SMTP. These days SMTP servers that act as open relays blindly accepting mail for domains they have no direct knowledge of are rare. Of course configuration and implementation errors happen, so you could end up getting mail for a remote system that ends up having a null MX. But as you say, this case is reasonably well specified. > But there is no such specification or > requirement to do MX lookups for VRFY and EXPN. At least by > implication, the server with which the mail session is open is > expected to figure out how to respond to the command with > information or indicate that it cannot (with 252, 251, or 551 -- > See RFC 5321 Section 3.5.3). I think that to the extent there's any expectation that VRFY or EXPN would be used for validating addresses outside the server's administrative domain, that's an error in RFC 5321. At an absolute minimum it would warrant a discussion of the security implications of a command that lets the client cause a server to do lots of MX lookups and pretty much nothing else, and I don't see any such discussion in RFC 5321. And as far as using DNS operations of any sort as part of VRFY or EXPN support within the administrative domain, I see that as a local matter. Really, getting into this in at any sort of realistic level is going to require talking about split DNS and probably various sorts of directory servers. > The other thing that is notable about this is that 252 is a kind > of "indirect information" response, specifically that the host > contacted will try to deliver a message sent to that address, > but has no information as to whether it is valid. > The nullMX spec is correct as written because it talks about > "mail delivery" and "mail delivery attempts" but phrases like > "without requiring domains to create SMTP listeners dedicated to > preventing delivery attempts" strongly imply that SMTP listeners > are unnecessary to prevent timeout and potential retry behavior. > It seems to me that the nullMX spec is incomplete if it does not > address this issue in some way, even if all it says is that the > DNS entry provides protection against actual mail transactions > but not, e.g., query transactions such as those implied by VRFY > or EXPN. In particular, a client can conform to the nullMX spec > but still try to open SMTP connections to the relevant target > host. I assume by this you mean that someone would implement null MX suppport only in the RCPT TO code path but not in VRFY or EXPN. If so, then I think that would require code that violates the existing MX specification. If you treat the null MX record as somehow valid you're going to look something up that fails to get back any A or AAAA records. You'd have to have an implementation that falls back to A/AAAA records for the MX itself when it sees this condition. But regardless, since I see this as falling within the purview of local operation choices, I don't think it needs to be addressed. Ned From nobody Fri Sep 5 11:11:02 2014 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 4AF6E1A6F11 for ; Fri, 5 Sep 2014 11:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668, 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 Ijd1SjPpKgv7 for ; Fri, 5 Sep 2014 11:10:54 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 36E671A6F34 for ; Fri, 5 Sep 2014 11:10:13 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PC80FAS5G0002Q3V@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 5 Sep 2014 11:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1409940311; bh=Pp1RQthIupwkLdIdbPeWgN8xwvAWeL/bUU7/3dVYTg8=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=pWg0YyPFvqc/PQX6icvYGRlKovqtfq0g/o9hLqBCFlFD2DKjwovHYpBYhdU5Z2BrK BLrl1ocCsKysXkKG87bQwjh8kE+WAZ3ASghYGeKnfl+u9SgNir2BcK/sjwklhFa4WR ZpO24X3iu0cnOZx/zrM8MBqCmTAxGW7H77DwLdAM= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PC6KHUDFZ4002WQY@mauve.mrochek.com>; Fri, 05 Sep 2014 11:05:09 -0700 (PDT) Message-id: <01PC80F9SMF4002WQY@mauve.mrochek.com> Date: Fri, 05 Sep 2014 11:01:55 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 05 Sep 2014 12:03:30 -0400" <824E7E0026F4B3333BA1AA3F@JcK-HP8200.jck.com> References: <20140904180426.61503.qmail@joyce.lan> <314068007672D901AF0FC6DC@JcK-HP8200.jck.com> <824E7E0026F4B3333BA1AA3F@JcK-HP8200.jck.com> To: John C Klensin Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/LT6UOyrbEKv6fp3CCdcJqCJe6A0 Cc: John R Levine , apps-discuss@ietf.org Subject: Re: [apps-discuss] SMTP reply codes and nullMX (was: Re: Last minute concern on nullmx draft) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 18:10:59 -0000 > --On Friday, September 05, 2014 10:59 -0400 John R Levine > wrote: > >> So, if we have to invent or assign a different code, why not > >> invent 556 or, in principle, 522? I/we have the "code 521" > >> draft open; it would take only a few extra minutes to add a > >> new code to it with very specific functionality of either > >> "the DNS told me there was no service for that domain" or "I > >> know from external sources, such as the DNS, there there is > >> no service". > > > > 556 is fine with me if it's fine with everyone else. I'm > > assuming that if your draft invents it, we can just refer to > > it in nullmx, right? > Absolutely -- no more problem referring to it than there was > with 221 (or a bit less given our exchange at the beginning of > the week). If others like that, I'll get a new draft with it > specified out RSN. > The ADs and this WG should figure out, ideally very soon, > whether it wants to adopt/review that draft or whether I should > specify discussion on ietf-smtp and handle it as an individual > submission. I have no problem with assigning 556 for this purpose. But at the same time I can't resist pointing out that "corresponding" code 456 is defined in draft-martin-smtp-ipv6-to-ipv4-fallback-00.xml as an indicator of a need for IPv4 fallback, and should this code be assigned and that draft adopted agents which do this correspondence thing are going to behave in "interesting" ways. Ned From nobody Fri Sep 5 11:47:09 2014 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 3FE1E1A0196 for ; Fri, 5 Sep 2014 11:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] 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 8Nro9dhSeWBb for ; Fri, 5 Sep 2014 11:47:04 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64C631A0167 for ; Fri, 5 Sep 2014 11:47:04 -0700 (PDT) Received: from [198.252.137.121] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XPyX9-000JQC-Lz; Fri, 05 Sep 2014 14:46:55 -0400 Date: Fri, 05 Sep 2014 14:46:50 -0400 From: John C Klensin To: Ned Freed Message-ID: <9263DE14EEAAF72591E750BF@JcK-HP8200.jck.com> In-Reply-To: <01PC80F9SMF4002WQY@mauve.mrochek.com> References: <20140904180426.61503.qmail@joyce.lan> <314068007672D901AF0FC6DC@JcK-HP8200.jck.com> <824E7E0026F4B3333BA1AA3F@JcK-HP8200.jck.com> <01PC80F9SMF4002WQY@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.121 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/NX-jz4efQQN404Cu8LTVcTmv_5Q Cc: John R Levine , apps-discuss@ietf.org Subject: Re: [apps-discuss] SMTP reply codes and nullMX (was: Re: Last minute concern on nullmx draft) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 18:47:06 -0000 --On Friday, September 05, 2014 11:01 -0700 Ned Freed wrote: >> The ADs and this WG should figure out, ideally very soon, >> whether it wants to adopt/review that draft or whether I >> should specify discussion on ietf-smtp and handle it as an >> individual submission. > > I have no problem with assigning 556 for this purpose. > > But at the same time I can't resist pointing out that > "corresponding" code 456 is defined in > draft-martin-smtp-ipv6-to-ipv4-fallback-00.xml as an indicator > of a need for IPv4 fallback, and should this code be assigned > and that draft adopted agents which do this correspondence > thing are going to behave in "interesting" ways. I still read the reply code theory, as I think you mentioned that you do, as the third digit being a discriminator but, unlike Nyz or xNz, with no cross-code implications. I find it impossible to read "The third digit and any supplemental information that may be present is reserved for the finest gradation of information" in any other way. Conversely, if one did want to follow the theory as closely as possible, then use of an x5z code for "go fallback to something else" seems a little off. Maybe we should be suggesting that draft-martin-smtp-ipv6-to-ipv4-fallback use, e.g., 541, and that we reserve either all of 54z or a larger subset than one code for "fallback to something else needed" or "different capabilities needed". That would allow an IPv6-only SMTP system to reply with "521 IPv6 fallback necessary" when approached via IPv4, or a NextGreatIdea system to reply with "542 Need to use Next Big Thing, won't accept mail that narrowly conforms to 5321 or 821". I hope I'm being a little facetious, but especially in the wake of EAI, "if you don't ask for my preferred extensions, I won't talk with you" isn't far away and probably should get a distinctive code. Grump (about the situation, not any individual or suggestion) john From nobody Fri Sep 5 12:54:04 2014 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 BDDE71A0019 for ; Fri, 5 Sep 2014 12:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 zQlY5MVmRtxF for ; Fri, 5 Sep 2014 12:54:01 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 27A311A006A for ; Fri, 5 Sep 2014 12:54:01 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id CC900594059 for ; Fri, 5 Sep 2014 12:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=tA8ZzJwzjj7yCv/tB+rL intL+EY=; b=Nsyj8BLXSfHcXG8ifIc/kb/e0JukaswSS9kNa5vIFVwWR0E8nbY/ I4bDmmfaH9bAdimckJMROgzYreAaVkZdmHO1SDhgWnL4pzsOzcqRyqgq02wavs0y v77X1EmhwIz5gvHJCYF8eRz1V6urCNRA1tiNUBaUJxBCb9ckGgN0EhA= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 7E699594058 for ; Fri, 5 Sep 2014 12:54:00 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cc10so324380wib.10 for ; Fri, 05 Sep 2014 12:53:59 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.13.195 with SMTP id j3mr5958044wic.70.1409946839200; Fri, 05 Sep 2014 12:53:59 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Fri, 5 Sep 2014 12:53:59 -0700 (PDT) In-Reply-To: References: <20140904180426.61503.qmail@joyce.lan> Date: Fri, 5 Sep 2014 14:53:59 -0500 Message-ID: From: Nico Williams To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/41n0_aljRCxMspTlAbEE4DrgwQk Cc: jck@jck.com, John Levine , IETF Apps Discuss Subject: Re: [apps-discuss] Last minute concern on nullmx draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 19:54:01 -0000 On Fri, Sep 5, 2014 at 12:12 PM, Murray S. Kucherawy wrote: > On Thu, Sep 4, 2014 at 3:43 PM, Nico Williams wrote: >> > Interesting observation. Is that by design, or was it a coincidence? >> >> The same codes are not assigned for the 2xx/4xx/5xx ranges, but at >> least for x21 they are. >> >> [...] >> >> The idea is that 5xx can be mapped to 4xx: >> >> | Until now the Postfix community has relied on this property as part >> | of a temporary safety net (to avoid missing email, replace 5XY with >> | 4XY; after watching the logs for some time, remove the safety net). >> >> Seems more than plausible to me. > > But this seems to me like it's building something based on a coincidence, > which is never a safe thing to do. I agree, but: > I suppose since there's widely deployed code that does it, then that's > something worth considering. Right. It's rough consensus and running code. There's the running code. What it does isn't wrong, at least not for x21. From nobody Fri Sep 5 14:05:03 2014 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 038811A0068 for ; Fri, 5 Sep 2014 14:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668, 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 JubxtDG6r3Uw for ; Fri, 5 Sep 2014 14:04:56 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 392121A00AB for ; Fri, 5 Sep 2014 14:04:55 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PC86IVLKW00037L9@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 5 Sep 2014 13:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1409950792; bh=f2ZOn6CpCqURB6k5njZ/q8WejGBbB5wBIm/iw96Ezuk=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=W+ucXpKY6LZuvhLPRylDYSXIMBxqLp5TMvirIAElMC3LKwOcKt8Q82FvGJMbewZlA ltYptpARMNjocf007AopOpB/ihT/wNva1wsOp/bb0Xdx+AvqzY/efpsRNkiZJUfKBS lwCGaL34B/uj0pqYCLnJaoiEiq+dkodaRxim2x9A= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PC6KHUDFZ4002WQY@mauve.mrochek.com>; Fri, 05 Sep 2014 13:59:49 -0700 (PDT) Message-id: <01PC86ITKXEI002WQY@mauve.mrochek.com> Date: Fri, 05 Sep 2014 13:59:02 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 05 Sep 2014 14:46:50 -0400" <9263DE14EEAAF72591E750BF@JcK-HP8200.jck.com> References: <20140904180426.61503.qmail@joyce.lan> <314068007672D901AF0FC6DC@JcK-HP8200.jck.com> <824E7E0026F4B3333BA1AA3F@JcK-HP8200.jck.com> <01PC80F9SMF4002WQY@mauve.mrochek.com> <9263DE14EEAAF72591E750BF@JcK-HP8200.jck.com> To: John C Klensin Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0L7-LzgduZoMjau6kkTovgwcU2c Cc: John R Levine , Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] SMTP reply codes and nullMX (was: Re: Last minute concern on nullmx draft) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 21:04:58 -0000 > --On Friday, September 05, 2014 11:01 -0700 Ned Freed > wrote: > >> The ADs and this WG should figure out, ideally very soon, > >> whether it wants to adopt/review that draft or whether I > >> should specify discussion on ietf-smtp and handle it as an > >> individual submission. > > > > I have no problem with assigning 556 for this purpose. > > > > But at the same time I can't resist pointing out that > > "corresponding" code 456 is defined in > > draft-martin-smtp-ipv6-to-ipv4-fallback-00.xml as an indicator > > of a need for IPv4 fallback, and should this code be assigned > > and that draft adopted agents which do this correspondence > > thing are going to behave in "interesting" ways. > I still read the reply code theory, as I think you mentioned > that you do, as the third digit being a discriminator but, > unlike Nyz or xNz, with no cross-code implications. I find it > impossible to read "The third digit and any supplemental > information that may be present is reserved for the finest > gradation of information" in any other way. Exactly. > Conversely, if one did want to follow the theory as closely as > possible, then use of an x5z code for "go fallback to something > else" seems a little off. Maybe we should be suggesting that > draft-martin-smtp-ipv6-to-ipv4-fallback use, e.g., 541, and that > we reserve either all of 54z or a larger subset than one code > for "fallback to something else needed" or "different > capabilities needed". That would allow an IPv6-only SMTP system > to reply with "521 IPv6 fallback necessary" when approached via > IPv4, or a NextGreatIdea system to reply with "542 Need to use > Next Big Thing, won't accept mail that narrowly conforms to 5321 > or 821". I hope I'm being a little facetious, but especially > in the wake of EAI, "if you don't ask for my preferred > extensions, I won't talk with you" isn't far away and probably > should get a distinctive code. Not a bad idea. If that draft gets traction we should suggest making that change. Ned From nobody Fri Sep 5 22:13:13 2014 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 C97201A02DB for ; Thu, 4 Sep 2014 11:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-8umi68XGFc for ; Thu, 4 Sep 2014 11:54:51 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C571A0235 for ; Thu, 4 Sep 2014 11:54:51 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id e4so1709855wiv.14 for ; Thu, 04 Sep 2014 11:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KcX+hdcLTSyE2KJLnTk43vK2QRUc3PMohAHSt6Jr+0U=; b=GFfUYEPYKVZC0HZPCb2UGh8uP4qe95qEUfjeqjQj10CS7fXRLmtkDAAu3GsB3FR0P9 MXTpvKjmEskQ29dULSmCLwA0WodriGtiaf5tQk97AGRfjmlz0W2W/SjOP2JlihCoGpeN Rcy6arxKkDgQVInRP6cbFxWeUEeavmFzGy8jk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KcX+hdcLTSyE2KJLnTk43vK2QRUc3PMohAHSt6Jr+0U=; b=Pe48oEIhbGcNJCY2xmaQyx2PRolWOX4LGAVBYx8HxnFu1GSuJtXaYhSKAY+gjF5cX6 PWrgcqegpOA7jpmMCGaYSZ8SRBVBUrLX4+vOLAMrtKND/Zhyr2NEIf1Kbeax0Jni6yeM T9Ecr1AY0I0rxfjz1G0tWtkXXP2nl3JPfbnmZ3PtGSjBNyZ8hYsKRk5O58RYUed8c+MN exL1E9X/f8S3jL6qSovuFp7d6uGOeh7rIHl4F8ABNGKxenn01JPOs3a87W4pdib7ra90 utqYzqczqExqi+4XsiUeeosuw54U6n7yGJLtgTgorgMVlEbirX81JELZ6NWey0WmJevU mHBQ== X-Gm-Message-State: ALoCoQkvdQeSWbpklG6gBq6jbqetlg6ZUjWy/7uM3QNkSne0GlCNrCoRgEedCBavdD11TdVuLq6s MIME-Version: 1.0 X-Received: by 10.194.5.234 with SMTP id v10mr8433178wjv.45.1409856889858; Thu, 04 Sep 2014 11:54:49 -0700 (PDT) Received: by 10.194.237.133 with HTTP; Thu, 4 Sep 2014 11:54:49 -0700 (PDT) In-Reply-To: <20140904180426.61503.qmail@joyce.lan> References: <20140904180426.61503.qmail@joyce.lan> Date: Thu, 4 Sep 2014 11:54:49 -0700 Message-ID: From: Kurt Andersen To: John Levine Content-Type: multipart/alternative; boundary=047d7b5d2fde1ac87b050241e32c Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hUi8fO02YUrDtp5GCjGzPDBL8jg X-Mailman-Approved-At: Fri, 05 Sep 2014 22:13:09 -0700 Cc: jck@jck.com, IETF Apps Discuss Subject: Re: [apps-discuss] Last minute concern on nullmx draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 18:54:54 -0000 --047d7b5d2fde1ac87b050241e32c Content-Type: text/plain; charset=UTF-8 On Thu, Sep 4, 2014 at 11:04 AM, John Levine wrote: > So I'd suggest changing the 521 return code to 550 (Requested action > not taken: mailbox unavailable) or 553 (Requested action not taken: > mailbox name not allowed) instead. > We were wanting to use something that would be slightly distinctive so of the two, I think 553 would be the better choice. The "not allowed" fits with the use of a null MX although of course it is the domain rather than the mailbox name that is the factor here. I think that making the change is OK to do. Cheers, Kurt Andersen --047d7b5d2fde1ac87b050241e32c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 4, 2014 at 11:04 AM, John Levine <johnl@taugh.c= om> wrote:
=C2=A0
So I'd suggest changing the = 521 return code to 550 (Requested action
not taken: mailbox unavailable) or 553 (Requested action not taken:
mailbox name not allowed) instead.

We w= ere wanting to use something that would be slightly distinctive so of the t= wo, I think 553 would be the better choice. The "not allowed" fit= s with the use of a null MX although of course it is the domain rather than= the mailbox name that is the factor here.

I think that making the change is OK to do.

Cheers,
=C2=A0 Kurt Andersen

--047d7b5d2fde1ac87b050241e32c-- From nobody Fri Sep 5 22:20:37 2014 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 8EAA01A03EE for ; Fri, 5 Sep 2014 22:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwgXKj5f64MO for ; Fri, 5 Sep 2014 22:20:32 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C891A03ED for ; Fri, 5 Sep 2014 22:20:32 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id b17so14860349lan.22 for ; Fri, 05 Sep 2014 22:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LN4cplJSQZP+QJlLLWBVhVEpZG0Fg63AciKXcmRum9U=; b=lzAq4BV4VIc3uKSIu7nh483/DqbjTONQB190ai21SCUtcKq/yJ3cq/vy2PTdScwIRB +LIOl/cDiGklvjhA0J3aGP0Y598gDFircY07JRaBUwkOEKAk0U0Q4VLmDTvmrss99EXP +xE1cFVVQeHIAl6qwbbABBzNhYMH3Wu7qpUpzC18whhBPoSkPK/MNYo76JKeRJkJNWH1 tA2TubkSlFkdA1MnI5lUSTzqS5TuhiEoAJ4Z7p+KX9li9UgWYPLUTuCJB0findUqPvGe kyUIrsrpPu4sr/nVolXviBcJs/xCA+YmyHNGz1SZ86R552cdO/43Ck9IxLBljuh463w4 6tgw== MIME-Version: 1.0 X-Received: by 10.112.138.39 with SMTP id qn7mr14869590lbb.25.1409980830552; Fri, 05 Sep 2014 22:20:30 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Fri, 5 Sep 2014 22:20:30 -0700 (PDT) In-Reply-To: <824E7E0026F4B3333BA1AA3F@JcK-HP8200.jck.com> References: <20140904180426.61503.qmail@joyce.lan> <314068007672D901AF0FC6DC@JcK-HP8200.jck.com> <824E7E0026F4B3333BA1AA3F@JcK-HP8200.jck.com> Date: Fri, 5 Sep 2014 22:20:30 -0700 Message-ID: From: "Murray S. Kucherawy" To: John C Klensin Content-Type: multipart/alternative; boundary=089e011614ec8b987405025ebe7c Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wzUYmwwhrwMPtOh8ma0TL7AQmSw Cc: John R Levine , IETF Apps Discuss Subject: Re: [apps-discuss] SMTP reply codes and nullMX (was: Re: Last minute concern on nullmx draft) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 05:20:35 -0000 --089e011614ec8b987405025ebe7c Content-Type: text/plain; charset=UTF-8 On Fri, Sep 5, 2014 at 9:03 AM, John C Klensin wrote: > > The ADs and this WG should figure out, ideally very soon, > whether it wants to adopt/review that draft or whether I should > specify discussion on ietf-smtp and handle it as an individual > submission. > I was under the impression that the 521 draft would be AD-sponsored. If the idea of doing it through APPSAWG is back on the table, then I'm happy to entertain a call for adoption. Barry and Alexey, what say you? -MSK, co-chairin' but on vacation --089e011614ec8b987405025ebe7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Sep 5, 2014 at 9:03 AM, John C Klensin <john-ie= tf@jck.com> wrote:

The ADs and this WG should figure out, ideally very soon,
whether it wants to adopt/review that draft or whether I should
specify discussion on ietf-smtp and handle it as an individual
submission.

I was under = the impression that the 521 draft would be AD-sponsored.=C2=A0 If the idea = of doing it through APPSAWG is back on the table, then I'm happy to ent= ertain a call for adoption.

Barry and Alexey, = what say you?

-MSK, co-chairin' but on vacation
--089e011614ec8b987405025ebe7c-- From nobody Sat Sep 6 23:23:57 2014 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 131DA1A0301 for ; Sat, 6 Sep 2014 23:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoLdJgwEvuUi for ; Sat, 6 Sep 2014 23:23:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9085F1A0376 for ; Sat, 6 Sep 2014 23:23:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140907062354.6716.41624.idtracker@ietfa.amsl.com> Date: Sat, 06 Sep 2014 23:23:54 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/YlInwuuphbpDXVlFldbxVo8lsVY Subject: [apps-discuss] Milestones changed for appsawg WG 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: Sun, 07 Sep 2014 06:23:56 -0000 URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nobody Sun Sep 7 06:27:56 2014 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 AE1081A035F for ; Sun, 7 Sep 2014 06:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cw-jMfdxYnLW for ; Sun, 7 Sep 2014 06:27:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FE41A038D for ; Sun, 7 Sep 2014 06:27:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140907132754.28413.70930.idtracker@ietfa.amsl.com> Date: Sun, 07 Sep 2014 06:27:54 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/SDr1XoiCnwnNNYEIUlD5FbYASjo Subject: [apps-discuss] Milestones changed for appsawg WG 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: Sun, 07 Sep 2014 13:27:55 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-authres-ptypes-registry", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nobody Sun Sep 7 09:14:40 2014 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 41F921A040E for ; Sun, 7 Sep 2014 09:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652] 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 QSnHYrD9qOdd for ; Sun, 7 Sep 2014 09:14:37 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3821A0455 for ; Sun, 7 Sep 2014 09:14:36 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XQf6p-000DgT-F1 for apps-discuss@ietf.org; Sun, 07 Sep 2014 12:14:35 -0400 Date: Sun, 07 Sep 2014 12:14:35 -0400 From: John C Klensin To: IETF Apps Discuss Message-ID: <8780051EF914306F7FEBB4AF@[192.168.1.128]> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/u-EFHqC1JZlfrJGAMayFpHlE6-I Subject: [apps-discuss] nullMX, new code, and draft-klensin-smtp-521code-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: Sun, 07 Sep 2014 16:14:38 -0000 Hi. I've just posted draft-klensin-smtp-521code-02, which changes SMTP to support two new reply codes, 521 (to support the behavior of dummy servers as discussed in RFC 1846) and 556 (primarily to support nullMX). To reprise discussion on this list, use of two separate codes helps distinguish between reaching the actual host and having it indicate it doesn't support mail and finding out by indirect means, such as a DNS entry. The separation also works around an SMTP violation in which a popular implementation assumes a relationship among reply codes that share the last two digits. The text is intended to treat nullMX as an example of a family of indirect techniques rather than, e.g., creating a normative reference to it or restricting use of the 556 code to that particular case. While it does not discuss the other cases, a Submission server that knew that a particular domain, perhaps a local one, did not accept any mail would be justified in returning a 556 code whether a nullMX record was present or not. The draft is being mentioned on this list only because of the relationship to nullMX. The I-D is not expected to become an AppsAWG work item. As indicated in the I-D, discussion of details not specific to nullMX should probably occur on the ietf-smtp list. john From nobody Sun Sep 7 09:30:52 2014 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 D12D91A066D for ; Sun, 7 Sep 2014 09:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 PN3my4JNSj1a for ; Sun, 7 Sep 2014 09:30:49 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581CA1A0667 for ; Sun, 7 Sep 2014 09:30:49 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 294C3FA0079; Sun, 7 Sep 2014 16:30:46 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1410107445-20915-20914/12/94; Sun, 7 Sep 2014 16:30:45 +0000 From: Arnt Gulbrandsen To: IETF Apps Discuss , John C Klensin Message-Id: References: <8780051EF914306F7FEBB4AF@[192.168.1.128]> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Date: Sun, 7 Sep 2014 16:30:45 +0000 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Os94P-D3kAkUFFLu6hqCcs_Q7S4 Subject: [apps-discuss] nullMX, new code, and draft-klensin-smtp-521code-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: Sun, 07 Sep 2014 16:30:51 -0000 I don't think what postfix does is a protocol violation. The 4xy and 5xy = reply codes were assigned according to the same principles, and so = _should_ be similar apart from the permanent/temporary bit. Arnt From nobody Sun Sep 7 10:10:21 2014 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 CBDF11A048C for ; Sun, 7 Sep 2014 10:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652] 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 iDUmZbr9gc1l for ; Sun, 7 Sep 2014 10:10:14 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79EC1A0487 for ; Sun, 7 Sep 2014 10:10:14 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XQfyf-000Dmb-NT; Sun, 07 Sep 2014 13:10:13 -0400 Date: Sun, 07 Sep 2014 13:10:13 -0400 From: John C Klensin To: Arnt Gulbrandsen , IETF Apps Discuss Message-ID: <3658A273625189506B103124@[192.168.1.128]> In-Reply-To: References: <8780051EF914306F7FEBB4AF@[192.168.1.128]> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Jke3CoEvxSRvTZO_zwaDjNlL-hs Subject: Re: [apps-discuss] nullMX, new code, and draft-klensin-smtp-521code-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: Sun, 07 Sep 2014 17:10:20 -0000 --On Sunday, 07 September, 2014 16:30 +0000 Arnt Gulbrandsen wrote: > I don't think what postfix does is a protocol violation. The > 4xy and 5xy reply codes were assigned according to the same > principles, and so _should_ be similar apart from the > permanent/temporary bit. Reply is on the SMTP list as indicated in the draft. Please take the discussion there. john From nobody Mon Sep 8 13:39:05 2014 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 60F9E1A0376 for ; Mon, 8 Sep 2014 13:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652, 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 MYZ519yF-lYe for ; Mon, 8 Sep 2014 13:39:02 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC211A030E for ; Mon, 8 Sep 2014 13:39:02 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PCCCCCSO4W002YBA@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 8 Sep 2014 13:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1410208174; bh=pX2gzlQKjCP3fRNVbU2zQxKpvUJRno9TFlFewDEoM6U=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=KlaQLelLzpUa+6SyCFsdlptzaCVZN/9ba5N31osLoCA3bihJy1JAozYVGapX5uoKd qRFMOtSExyY+kECQjBJNnkadZC2y8FrLguPfuamrPHmlvMjKF4lAqXsfSK2FxIlhpz wGgXMKzNC1bIx75ARQkZoFnDYjBaoPda+wJekzGs= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PBOD9M5PXC0000SM@mauve.mrochek.com>; Mon, 08 Sep 2014 13:29:32 -0700 (PDT) Message-id: <01PCCCCBJMAY0000SM@mauve.mrochek.com> Date: Mon, 08 Sep 2014 13:24:42 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 07 Sep 2014 16:30:45 +0000" References: <8780051EF914306F7FEBB4AF@[192.168.1.128]> To: Arnt Gulbrandsen Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/CNbBy5riWJ23dB2dtee27GYx2-s Cc: IETF Apps Discuss Subject: Re: [apps-discuss] nullMX, new code, and draft-klensin-smtp-521code-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: Mon, 08 Sep 2014 20:39:03 -0000 > I don't think what postfix does is a protocol violation. Of course it's not a protocol violation. The syntax restrictions on 5yz and 4yz codes are the same, so as long as you check the 5yz code for validity you're not going to ever send back something illegal. But returning a random valid response code isn't a protocol violation either. That doesn't means it's something you should do. > The 4xy and 5xy reply codes were assigned according to the same principles, > and so _should_ be similar apart from the permanent/temporary bit. Even the most cursory examination of the set of assigned codes shows this is not the case. The fact that 521/421/221 align is essentially serendipitous. I've already pointed out other cases where the alignment is poor. Ned From nobody Mon Sep 8 13:53:49 2014 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 DAD531A0267 for ; Mon, 8 Sep 2014 13:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Gv91rKbz3-Ob for ; Mon, 8 Sep 2014 13:53:46 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BA0C1A00F5 for ; Mon, 8 Sep 2014 13:53:46 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 0752ED0449D; Mon, 8 Sep 2014 16:53:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1410209625; bh=xuXXgiDLSO6KCOscRlZh5918UJkhurfdhmIIgVCeMDM=; h=In-Reply-To:References:Subject:From:Date:To:From; b=sjjVpPkMaEhDOHzyDEtUAnysBEDg26g+rmWGIUyNCOX+T8iOAmbWQGtl2o+e3nIER kSMeAi6kyeqeytCeyZV/PuelmkXiVsO0NgEfR6i5ViJO5vh2zi9cdXX1M0nQNRu/YH cpqeMjdZYtK0IobGzavyzH3mrsGfTByJ8E1cUtn0= Received: from [IPV6:2600:1003:b112:af17:6c7b:de1b:5e5b:1006] (unknown [IPv6:2600:1003:b112:af17:6c7b:de1b:5e5b:1006]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 5DDA3D0408D; Mon, 8 Sep 2014 16:53:44 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <01PCCCCBJMAY0000SM@mauve.mrochek.com> References: <8780051EF914306F7FEBB4AF@[192.168.1.128]> <01PCCCCBJMAY0000SM@mauve.mrochek.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Mon, 08 Sep 2014 16:53:41 -0400 To: IETF Apps Discuss Message-ID: X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Gb3Q8AF1EV5RbFEkvUu21BxEEfk Subject: Re: [apps-discuss] nullMX, new code, and draft-klensin-smtp-521code-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: Mon, 08 Sep 2014 20:53:48 -0000 On September 8, 2014 4:24:42 PM EDT, Ned Freed wrote: >> I don't think what postfix does is a protocol violation. > >Of course it's not a protocol violation. The syntax restrictions on 5yz >and >4yz codes are the same, so as long as you check the 5yz code for >validity you're not going to ever send back something illegal. > >But returning a random valid response code isn't a protocol violation >either. That doesn't means it's something you should do. > >> The 4xy and 5xy reply codes were assigned according to the same >principles, >> and so _should_ be similar apart from the permanent/temporary bit. > >Even the most cursory examination of the set of assigned codes shows >this is >not the case. The fact that 521/421/221 align is essentially >serendipitous. >I've already pointed out other cases where the alignment is poor. AIUI, Postfix only relies on this alignment for x21, so that should be fine. Scott K From nobody Tue Sep 9 08:01:43 2014 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 8ABE51A6FD8; Tue, 9 Sep 2014 08:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5UsWjxB2wKq; Tue, 9 Sep 2014 08:01:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2F71A0371; Tue, 9 Sep 2014 08:01:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140909150137.15453.17444.idtracker@ietfa.amsl.com> Date: Tue, 09 Sep 2014 08:01:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/nh-zv598a1GTWWnfJ7Pe0r4hUDk Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-00.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: Tue, 09 Sep 2014 15:01:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : The text/markdown Media Type Author : Sean Leonard Filename : draft-ietf-appsawg-text-markdown-00.txt Pages : 9 Date : 2014-09-09 Abstract: This document registers the text/markdown media type for use with Markdown, a family of plain text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 9 09:07:01 2014 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 20C6D1A6FE3 for ; Tue, 9 Sep 2014 09:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, 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 4oNX1mPGg8Jp for ; Tue, 9 Sep 2014 09:06:54 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A95261A6FF9 for ; Tue, 9 Sep 2014 09:06:53 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-22.dsl.dynamic.fusionbroadband.com [142.254.17.22]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s89G6p6G003192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 9 Sep 2014 09:06:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-22.dsl.dynamic.fusionbroadband.com [142.254.17.22] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <20140909150137.15453.17444.idtracker@ietfa.amsl.com> Date: Tue, 9 Sep 2014 09:06:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <82040482-FC42-421D-B612-3302645D96EE@vpnc.org> References: <20140909150137.15453.17444.idtracker@ietfa.amsl.com> To: Apps Discuss X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZfyOdRDCUQYVLGsDifdNHElKNs4 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-00.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, 09 Sep 2014 16:06:57 -0000 This seems particularly ill-timed. There is a group of markdown users = who last week announced that they are creating a standardized Markdown, = using that name, and thus taking the name away from the inventor of the = format. The is a lot of bad blood between them now. I propose that this WG do *nothing* about this for a few months, and = that the chairs contact the parties involved before further action. We are in no rush, and anything we do could look like a land-grab at a = time when ownership is in question. --Paul Hoffman On Sep 9, 2014, at 8:01 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Applications Area Working Group = Working Group of the IETF. >=20 > Title : The text/markdown Media Type > Author : Sean Leonard > Filename : draft-ietf-appsawg-text-markdown-00.txt > Pages : 9 > Date : 2014-09-09 >=20 > Abstract: > This document registers the text/markdown media type for use with > Markdown, a family of plain text formatting syntaxes that optionally > can be converted to formal markup languages such as HTML. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Tue Sep 9 09:18:03 2014 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 2BFD41A6FF4; Tue, 9 Sep 2014 09:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UR8YQ1JHZ67e; Tue, 9 Sep 2014 09:17:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6942F1A6FFF; Tue, 9 Sep 2014 09:17:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> Date: Tue, 09 Sep 2014 09:17:48 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/m7Kg1BOzpjUPIuCu7-LEPjs-IdE Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-01.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: Tue, 09 Sep 2014 16:17:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : The text/markdown Media Type Author : Sean Leonard Filename : draft-ietf-appsawg-text-markdown-01.txt Pages : 14 Date : 2014-09-09 Abstract: This document registers the text/markdown media type for use with Markdown, a family of plain text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-text-markdown-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 9 09:34:01 2014 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 DD2231A7016 for ; Tue, 9 Sep 2014 09:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, 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 AaqRgHQ30kR6 for ; Tue, 9 Sep 2014 09:33:58 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D74F1A7015 for ; Tue, 9 Sep 2014 09:33:57 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-22.dsl.dynamic.fusionbroadband.com [142.254.17.22]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s89GXsFP004354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 9 Sep 2014 09:33:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-22.dsl.dynamic.fusionbroadband.com [142.254.17.22] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> Date: Tue, 9 Sep 2014 09:33:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> To: Apps Discuss X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/P2yo6yDIW29BCFtF_u0Rfxc-Ft8 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-01.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, 09 Sep 2014 16:34:00 -0000 For the record, I think the changes Sean made in the -01 make the = situation significantly worse. Please: let's let the Markdown = "community" settle down before we go barging in with a media type, = particularly one that puts *other people's names* in the registry. --Paul Hoffman= From nobody Tue Sep 9 10:19:12 2014 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 0FBFE1A8026 for ; Tue, 9 Sep 2014 10:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-mAmXWzwA3Y for ; Tue, 9 Sep 2014 10:19:05 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1CEA1A702D for ; Tue, 9 Sep 2014 10:19:04 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s89HJ1wn022697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 9 Sep 2014 10:19:04 -0700 Message-ID: <540F35C4.5050906@dcrocker.net> Date: Tue, 09 Sep 2014 10:15:48 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Hoffman , Apps Discuss References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 09 Sep 2014 10:19:04 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/x6GVoa7_C7wfHgxb1BulwL11NQc Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 17:19:10 -0000 On 9/9/2014 9:33 AM, Paul Hoffman wrote: > For the record, I think the changes Sean made in the -01 make the situation significantly worse. Please: let's let the Markdown "community" settle down before we go barging in with a media type, particularly one that puts *other people's names* in the registry. What is the formal basis in IETF process for slow-rolling a media type request? I'm not challenging your concern, just the question of following our own rules. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Sep 9 10:26:13 2014 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 C109A1A86EB for ; Tue, 9 Sep 2014 10:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, 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 5vSW1CUbheSx for ; Tue, 9 Sep 2014 10:26:10 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A9D1A86EA for ; Tue, 9 Sep 2014 10:26:07 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-22.dsl.dynamic.fusionbroadband.com [142.254.17.22]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s89HQ1lw006215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Sep 2014 10:26:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-22.dsl.dynamic.fusionbroadband.com [142.254.17.22] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <540F35C4.5050906@dcrocker.net> Date: Tue, 9 Sep 2014 10:26:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <10B44A1C-EC17-41A7-B2F0-8B45F0891CC4@vpnc.org> References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <540F35C4.5050906@dcrocker.net> To: Dave Crocker X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/P-vSJJIkYv9gjeHQQuS5_vqgph4 Cc: Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-01.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, 09 Sep 2014 17:26:11 -0000 On Sep 9, 2014, at 10:15 AM, Dave Crocker wrote: > On 9/9/2014 9:33 AM, Paul Hoffman wrote: >> For the record, I think the changes Sean made in the -01 make the = situation significantly worse. Please: let's let the Markdown = "community" settle down before we go barging in with a media type, = particularly one that puts *other people's names* in the registry. >=20 >=20 > What is the formal basis in IETF process for slow-rolling a media type > request? Why does there need to be a "formal basis"? It's about being polite to = the people outside the IETF, not about formal processes. We remember how = to do the former, I hope. --Paul Hoffman= From nobody Tue Sep 9 10:31:46 2014 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 7B2461A700F for ; Tue, 9 Sep 2014 10:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-EjoSizMazO for ; Tue, 9 Sep 2014 10:31:43 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9381A700B for ; Tue, 9 Sep 2014 10:31:43 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s89HVdIg023088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 9 Sep 2014 10:31:43 -0700 Message-ID: <540F38BB.5050508@dcrocker.net> Date: Tue, 09 Sep 2014 10:28:27 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Hoffman References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <540F35C4.5050906@dcrocker.net> <10B44A1C-EC17-41A7-B2F0-8B45F0891CC4@vpnc.org> In-Reply-To: <10B44A1C-EC17-41A7-B2F0-8B45F0891CC4@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 09 Sep 2014 10:31:43 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/z79JeSE_Yr7SYXLrPCDlinD6mxY Cc: Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 17:31:44 -0000 On 9/9/2014 10:26 AM, Paul Hoffman wrote: > On Sep 9, 2014, at 10:15 AM, Dave Crocker wrote: >> What is the formal basis in IETF process for slow-rolling a media type >> request? > > Why does there need to be a "formal basis"? It's about being polite > to the people outside the IETF, not about formal processes. We remember how> > to do the former, I hope. Being polite in a way that results in differential handling of formally-legitimate requests can also be interpreted as unfair treatment. It's not enough that your or we "mean well". d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Sep 9 10:50:33 2014 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 D7D3F1A8762 for ; Tue, 9 Sep 2014 10:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcsLgU-g5dnS for ; Tue, 9 Sep 2014 10:50:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 240751A8763 for ; Tue, 9 Sep 2014 10:50:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140909175030.22012.11212.idtracker@ietfa.amsl.com> Date: Tue, 09 Sep 2014 10:50:30 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/y2CSheuY-OSOM3eKQ9cNww_z_Xw Subject: [apps-discuss] Milestones changed for appsawg WG 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: Tue, 09 Sep 2014 17:50:32 -0000 URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nobody Tue Sep 9 11:33:56 2014 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 B5D0C1A889F for ; Tue, 9 Sep 2014 11:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 UlSYmjzmbtLP for ; Tue, 9 Sep 2014 11:33:30 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 921E41A88B6 for ; Tue, 9 Sep 2014 11:32:41 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 5F41A2C806D; Tue, 9 Sep 2014 11:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=0wven9eyvLUSKH ge3D1TMiP8iss=; b=HXDJOmZNg2VoP6+lpKINBIFe02oiA2tEhX09C7yq+dvbIA 05ytQkAzQb+mXifmyRlTMbIfHs6ZYLppYbDC46MQUYiuW/aGLcY20hcWOhRW4FW5 x8oYgGF2xJSmHo7lGjF/1xjrTHSrulKxzTmq4ndS7G6sk/oSsd6oIWZYOZQss= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPA id 0412E2C8058; Tue, 9 Sep 2014 11:32:39 -0700 (PDT) Date: Tue, 9 Sep 2014 13:32:39 -0500 From: Nico Williams To: dcrocker@bbiw.net Message-ID: <20140909183237.GC10013@localhost> References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <540F35C4.5050906@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <540F35C4.5050906@dcrocker.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/oQFthgJb17y5X0Tf2A6KLP4bVk8 Cc: Paul Hoffman , Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-01.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, 09 Sep 2014 18:33:30 -0000 On Tue, Sep 09, 2014 at 10:15:48AM -0700, Dave Crocker wrote: > On 9/9/2014 9:33 AM, Paul Hoffman wrote: > > For the record, I think the changes Sean made in the -01 make the situation significantly worse. Please: let's let the Markdown "community" settle down before we go barging in with a media type, particularly one that puts *other people's names* in the registry. > > What is the formal basis in IETF process for slow-rolling a media type > request? > > I'm not challenging your concern, just the question of following our own > rules. BTW, the I-D uses a MIME type parameter to distinguish between sub-types of Markdown, including the original. A bigger concern for me than the name (is there a trademark to worry about? I think there isn't) is the fact that the I-D doesn't describe the format except via informative references to unstable documents. Of course, for specific extensions that might be unavoidable, but at least for the original it ought to be possible to include a normative[*] description. [*] Yes, I know, the I-D targets publication on the Informational track. Nico -- From nobody Tue Sep 9 11:51:31 2014 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 581291A0154 for ; Tue, 9 Sep 2014 11:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOwfor_-Jjr0 for ; Tue, 9 Sep 2014 11:51:01 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D741A016D for ; Tue, 9 Sep 2014 11:51:01 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 55EB4FA0079; Tue, 9 Sep 2014 18:50:58 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1410288656-20915-20914/12/114; Tue, 9 Sep 2014 18:50:56 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Tue, 9 Sep 2014 20:50:57 +0200 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: <904f81ac-fa36-41cf-9f73-bf30429db981@gulbrandsen.priv.no> In-Reply-To: <20140909183237.GC10013@localhost> References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <540F35C4.5050906@dcrocker.net> <20140909183237.GC10013@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0vb3i_l7b6LvkOlqZf7RQTp-DaQ Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-01.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, 09 Sep 2014 18:51:08 -0000 On Tuesday, September 9, 2014 8:32:39 PM CEST, Nico Williams wrote: > ... the I-D doesn't describe > the format except via informative references to unstable documents. Of > course, for specific extensions that might be unavoidable, but at least > for the original it ought to be possible to include a normative[*] > description. The original is a brief description and a perl implementation, and the two mostly agree but have many minor differences. So which of the two would you reference? Arnt From nobody Tue Sep 9 11:57:17 2014 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 D3E591A00E0 for ; Tue, 9 Sep 2014 11:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 fI3uhTagmf4e for ; Tue, 9 Sep 2014 11:56:57 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CECFE1A0013 for ; Tue, 9 Sep 2014 11:56:57 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id AC2AC4012D695; Tue, 9 Sep 2014 11:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=uTKUQcnePSSd2z FMtcF3q/xF+dQ=; b=F+9Tmxiz70TVHmnYTbZT2EWi+JSbtzil7Mauaj63etDUn0 ozydJzxqa+HnbJiSWUsLVi485z7bbDYooTcuFRSNn7uUW9sq9cDHFogf0yeTECy3 8oLxl0gDXGGRGcLkDJCNHK3F3yKlmdIxBdLDQMpn0ap1GBMQYn2KYaz9YSV/A= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPA id 683BE4012D694; Tue, 9 Sep 2014 11:56:57 -0700 (PDT) Date: Tue, 9 Sep 2014 13:56:56 -0500 From: Nico Williams To: Arnt Gulbrandsen Message-ID: <20140909185655.GD10013@localhost> References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <540F35C4.5050906@dcrocker.net> <20140909183237.GC10013@localhost> <904f81ac-fa36-41cf-9f73-bf30429db981@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <904f81ac-fa36-41cf-9f73-bf30429db981@gulbrandsen.priv.no> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/aAQoa8mLhrC8WR4XjFvHPP1SwyM Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-01.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, 09 Sep 2014 18:57:00 -0000 On Tue, Sep 09, 2014 at 08:50:57PM +0200, Arnt Gulbrandsen wrote: > On Tuesday, September 9, 2014 8:32:39 PM CEST, Nico Williams wrote: > >... the I-D doesn't describe > >the format except via informative references to unstable documents. Of > >course, for specific extensions that might be unavoidable, but at least > >for the original it ought to be possible to include a normative[*] > >description. > > The original is a brief description and a perl implementation, and > the two mostly agree but have many minor differences. So which of > the two would you reference? I don't know yet. But we could certainly study the matter and pick or (or a subset). Some things that the author (and reviewers) could do to resolve any disagreements between the two original "specifications": - ask the original author which of those two should be normative - identify a common subset, and if it's useful enough consider using that as normative - review running code to see which of the two is closest to what's deployed and pick that Nico -- From nobody Tue Sep 9 12:12:10 2014 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 DEAD91A0137 for ; Tue, 9 Sep 2014 12:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EB-jUphMJWCg for ; Tue, 9 Sep 2014 12:12:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 198D41A017D for ; Tue, 9 Sep 2014 12:12:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140909191207.21089.85539.idtracker@ietfa.amsl.com> Date: Tue, 09 Sep 2014 12:12:07 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ndeeqv1ZVAfbiBsUOg_IAy-sXKk Subject: [apps-discuss] Milestones changed for appsawg WG 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: Tue, 09 Sep 2014 19:12:09 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-text-markdown", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nobody Tue Sep 9 13:34:03 2014 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 88CFE1A0100 for ; Tue, 9 Sep 2014 13:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwYzIp4vFIAH for ; Tue, 9 Sep 2014 13:34:00 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77AFE1A00FA for ; Tue, 9 Sep 2014 13:34:00 -0700 (PDT) Received: (qmail 271 invoked from network); 9 Sep 2014 20:33:59 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 9 Sep 2014 20:33:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=107da.540f6437.k1409; i=johnl@user.iecc.com; bh=enPKLnOh+y96S55EKmxLS1IWt664DpynMPy/wx4dL+U=; b=ObAdOx5IYTT7hBO/4WTTLhqw5p+gFmM4aMyYGhApxoi1npm9o8bqCaS0QfJ1DrHaCIYmqXAisg8zca7SmbX03FA6brx0nAd1LMr2rqf4mO4NylXOwZUVYe9VXMD93nElHJg3ca1RGFp/o46tfUfFgkgZH9ebag69pytmAmXMQ5WRqTGYlFayUFp6xNS664iAK0Z2UI/Kfeerjr80I55D9pLLFg0X1n+ST5yYMPpq3/i9KChPVuOf7hbm/fOvdvlu DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=107da.540f6437.k1409; olt=johnl@user.iecc.com; bh=enPKLnOh+y96S55EKmxLS1IWt664DpynMPy/wx4dL+U=; b=NSWNq6gDUtk8s+cJHQQXDfUE/sjmnn4X6tVKqOjzvW90sWiVfa+ClsGUauV5whERMgIH0YRc8VNhmME/HT8++09jUbsQr5F4NMbSLI2WkIRueSzOReQ+pQXSJYXtzrvkjwjKfLOYY8IxhIuIAzWqXqEA0D5fvjfhNPHkE3cylYNUcaobUG/Jkfw3Q2zI3d7XfhOdaKzRyzBluXxKSMNnNZIMLvgtYYiy2wuU0VlCXfznH5Nu2p/fLPYEXK7cEv+t Date: 9 Sep 2014 20:33:35 -0000 Message-ID: <20140909203335.67545.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <10B44A1C-EC17-41A7-B2F0-8B45F0891CC4@vpnc.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/PLWse4LXx2Slz9Jm5NdYAoTUIc8 Cc: paul.hoffman@vpnc.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-01.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, 09 Sep 2014 20:34:01 -0000 >>> For the record, I think the changes Sean made in the -01 make the situation significantly worse. Please: let's let >the Markdown "community" settle down before we go barging in with a media type, particularly one that puts *other >people's names* in the registry. Agreed. It seems to me that the point of a text/markdown media type is to identify whatever format it is that markdown users expect to find. If, as in this case, it's not obvious which of multiple versions of that format is most widely used, or where it's defined, it's more than reasonable to delay until the smoke clears. As Paul noted, it's been around for a decade, and there's nothing urgent about defining the media type right this minute. R's, John From nobody Tue Sep 9 13:57:40 2014 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 A98F01A88C5 for ; Tue, 9 Sep 2014 13:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-uw4kn1MeWX for ; Tue, 9 Sep 2014 13:57:37 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA4C1A0104 for ; Tue, 9 Sep 2014 13:57:36 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id b17so19915323lan.41 for ; Tue, 09 Sep 2014 13:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1w+1qfpbCOolFv4Qbm00lVMMFCmlvxLt35oxBbaEtAw=; b=yQca0L/xVo/tbwE+fjDE4dsPNny2Yt5oRzHR+pqGtjwwTg8Z5MFTnZIfI8l6i8ertu gFsCQaFdQGJ6/EWJCmUAomnTxpSDSwP4s2LpM1ZMiO3YcJe9J/KgiNdkTKkCUfUIfVr4 Ky8wz/uOwt0jgKIFG8PDUiunEJWoO8mvcf2jUjrJ/hdeWs/x15PLsUg8kxSRyu5mAuBC U0Wiq4Zm8xC3yDN5jHUrrlppr5x1MnbA1Dy0xhWXHdtL/sWMe+bGMtReji25qXM9fI9s VnLRP8vXJOgMko9hQxyYF76OHdq5/XyMwqPwyr+KTbl5qjZ52xfVTQqwZ7gbv2ydeXMv Copg== MIME-Version: 1.0 X-Received: by 10.112.35.44 with SMTP id e12mr35572440lbj.13.1410296255178; Tue, 09 Sep 2014 13:57:35 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Tue, 9 Sep 2014 13:57:35 -0700 (PDT) In-Reply-To: <20140909185655.GD10013@localhost> References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <540F35C4.5050906@dcrocker.net> <20140909183237.GC10013@localhost> <904f81ac-fa36-41cf-9f73-bf30429db981@gulbrandsen.priv.no> <20140909185655.GD10013@localhost> Date: Tue, 9 Sep 2014 13:57:35 -0700 Message-ID: From: "Murray S. Kucherawy" To: Nico Williams Content-Type: multipart/alternative; boundary=14dae93d970a516ece0502a82f34 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0wefvcNgFSBrr4I38kZb0rVb7Vk Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-01.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, 09 Sep 2014 20:57:38 -0000 --14dae93d970a516ece0502a82f34 Content-Type: text/plain; charset=UTF-8 On Tue, Sep 9, 2014 at 11:56 AM, Nico Williams wrote: > > The original is a brief description and a perl implementation, and > > the two mostly agree but have many minor differences. So which of > > the two would you reference? > > I don't know yet. But we could certainly study the matter and pick or > (or a subset). > > Some things that the author (and reviewers) could do to resolve any > disagreements between the two original "specifications": > > - ask the original author which of those two should be normative > > - identify a common subset, and if it's useful enough consider using > that as normative > > - review running code to see which of the two is closest to what's > deployed and pick that As I read it, the mini-charter submitted for this document specifically declares as out-of-scope any discussion of what markdown format elements we might want to choose as standard or normative, or making any definitions of such on our own. Thus, all of those suggestions can't be followed without renegotiating with the WG. What is agreed is that we would create an IANA registry and registration process for assigning token words to specific versions of markdown and their defining documents. This "standard" version might be just another entry in such a registry. That said, I concur that there's no hurry to expedite this work, and also that we should not do this in a vacuum. As much as possible, the markdown community should be made aware of the work proposed here, and participate in the selection and definition of at least the initial set of registry entries and their corresponding reference materials. I'm willing to wait a reasonable period for that to happen. -MSK, with half of the APPSAWG chair hat on --14dae93d970a516ece0502a82f34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 9, 2014 at 11:56 AM, Nico Williams <nic= o@cryptonector.com> wrote:
>= The original is a brief description and a perl implementation, and
> the two mostly agree but have many minor differences. So which of
> the two would you reference?

I don't know yet.=C2=A0 But we could certainly study the matter = and pick or
(or a subset).

Some things that the author (and reviewers) could do to resolve any
disagreements between the two original "specifications":

=C2=A0- ask the original author which of those two should be normative

=C2=A0- identify a common subset, and if it's useful enough consider us= ing
=C2=A0 =C2=A0that as normative

=C2=A0- review running code to see which of the two is closest to what'= s
=C2=A0 =C2=A0deployed and pick that

As I re= ad it, the mini-charter submitted for this document specifically declares a= s out-of-scope any discussion of what markdown format elements we might wan= t to choose as standard or normative, or making any definitions of such on = our own.=C2=A0 Thus, all of those suggestions can't be followed without= renegotiating with the WG.

What is agreed is that we wou= ld create an IANA registry and registration process for assigning token wor= ds to specific versions of markdown and their defining documents.=C2=A0 Thi= s "standard" version might be just another entry in such a regist= ry.

That said, I concur that there's no hurry to expe= dite this work, and also that we should not do this in a vacuum.=C2=A0 As m= uch as possible, the markdown community should be made aware of the work pr= oposed here, and participate in the selection and definition of at least th= e initial set of registry entries and their corresponding reference materia= ls.=C2=A0 I'm willing to wait a reasonable period for that to happen.
-MSK, with half of the APPSAWG chair hat on
--14dae93d970a516ece0502a82f34-- From nobody Wed Sep 10 08:49:40 2014 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 3AB471A8737 for ; Wed, 10 Sep 2014 08:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWGtONmMCAJC for ; Wed, 10 Sep 2014 08:49:37 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA591A872F for ; Wed, 10 Sep 2014 08:49:36 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id c11so5355409lbj.37 for ; Wed, 10 Sep 2014 08:49:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9hhuQHX4Bbhg1jTuUIVO4br4goLFQYUazCKel3nNDyE=; b=yTLebwjoq52QPvZgRX0Z1g45eMWJ/clqgDDfZL/tal29HWDUdlMKWkRYUuFquLRCOJ rs/VTPAhQIVq1qbeMMDw3zE+/9jsPyWjYdX6NlE8/yuWDsJHvHnEx9tWPOVxEHZ8sd4h rf3gAc3uLlS4wD27HmO0PjvkX9OO6rVJgMqRHoM/PL3RJrPNtK6gGg2NJG+YcswP3ZZ3 tgulzn1xjcIeB2TBT2tXnaAG0zlMJvIFWd9c7MTgmb/RQuquKIokdz/mdpnECnKxMPg8 hMnH3DmCcKVOJ7YJxjipcTKRYJBEN5hAuK+yc63HsJeQJ3IAPKh+MeaA0C4i6h/osrL5 aldA== MIME-Version: 1.0 X-Received: by 10.152.20.1 with SMTP id j1mr29323425lae.57.1410364175172; Wed, 10 Sep 2014 08:49:35 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Wed, 10 Sep 2014 08:49:35 -0700 (PDT) In-Reply-To: References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <540F35C4.5050906@dcrocker.net> <20140909183237.GC10013@localhost> <904f81ac-fa36-41cf-9f73-bf30429db981@gulbrandsen.priv.no> <20140909185655.GD10013@localhost> Date: Wed, 10 Sep 2014 08:49:35 -0700 Message-ID: From: "Murray S. Kucherawy" To: Nico Williams Content-Type: multipart/alternative; boundary=089e013d1d4caa4c000502b7ffb4 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/TrejuoAmDzdPxanG4KjZKdk7K7Q Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-01.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, 10 Sep 2014 15:49:38 -0000 --089e013d1d4caa4c000502b7ffb4 Content-Type: text/plain; charset=UTF-8 On Tue, Sep 9, 2014 at 1:57 PM, Murray S. Kucherawy wrote: > > That said, I concur that there's no hurry to expedite this work, and also > that we should not do this in a vacuum. As much as possible, the markdown > community should be made aware of the work proposed here, and participate > in the selection and definition of at least the initial set of registry > entries and their corresponding reference materials. I'm willing to wait a > reasonable period for that to happen. > > If I were to prepare something that looks like a liaison statement from APPSAWG to the markdown community asking them for feedback on what we're proposing, is there a mailing list or a specific set of people to which I should send it? -MSK --089e013d1d4caa4c000502b7ffb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 9, 2014 at 1:57 PM, Murray S. Kucherawy <su= peruser@gmail.com> wrote:

That said, I concur that there's no hurry to expedite this work,= and also that we should not do this in a vacuum.=C2=A0 As much as possible= , the markdown community should be made aware of the work proposed here, an= d participate in the selection and definition of at least the initial set o= f registry entries and their corresponding reference materials.=C2=A0 I'= ;m willing to wait a reasonable period for that to happen.


If I were to prepare someth= ing that looks like a liaison statement from APPSAWG to the markdown commun= ity asking them for feedback on what we're proposing, is there a mailin= g list or a specific set of people to which I should send it?

=
-MSK
--089e013d1d4caa4c000502b7ffb4-- From nobody Wed Sep 10 09:03:24 2014 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 C95D31A8757 for ; Wed, 10 Sep 2014 09:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdctO-fS_6Ui for ; Wed, 10 Sep 2014 09:03:21 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC10A1A873F for ; Wed, 10 Sep 2014 09:03:21 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8AG3E59020394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 10 Sep 2014 09:03:17 -0700 Message-ID: <5410757F.8000009@dcrocker.net> Date: Wed, 10 Sep 2014 08:59:59 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Nico Williams References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <540F35C4.5050906@dcrocker.net> <20140909183237.GC10013@localhost> <904f81ac-fa36-41cf-9f73-bf30429db981@gulbrandsen.priv.no> <20140909185655.GD10013@localhost> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 10 Sep 2014 09:03:17 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/PPXtxxzStTD1r0lCkh1IjDPCPh0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 16:03:23 -0000 On 9/9/2014 1:57 PM, Murray S. Kucherawy wrote: > > As I read it, the mini-charter submitted for this document specifically > declares as out-of-scope any discussion of what markdown format elements > we might want to choose as standard or normative, or making any > definitions of such on our own. Thus, all of those suggestions can't be > followed without renegotiating with the WG. > > What is agreed is that we would create an IANA registry and registration > process for assigning token words to specific versions of markdown and > their defining documents. This "standard" version might be just another > entry in such a registry. The emergence of some sort of competitive situation for markdown for me encourages two points: 1. For any label registered under markdown, require a real and useful specification, not a handwave. 2. Do /not/ register 'standard', since it implies a preferred choice; especially in the midst of rancorous competition, that merely offends whoever does not get the label. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Sep 10 09:50:11 2014 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 B90E41A899B for ; Wed, 10 Sep 2014 09:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652, URIBL_RHS_DOB=1.514] 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 yiMVDKHyvUbu for ; Wed, 10 Sep 2014 09:50:08 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 93ED11A8A09 for ; Wed, 10 Sep 2014 09:50:08 -0700 (PDT) Received: from [192.168.80.56] (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id E84C0811EA for ; Wed, 10 Sep 2014 09:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1410367808; bh=jLgMDRJfpYA8F/MTN5ghvNYVLKKSsCAgLno/x/EbpM4=; h=Subject:From:In-Reply-To:Date:References:To:From; b=SF/7GdG5YOIbVRs6IxnuMya8P9qymRNXgaL0bPggRfRw5Jg3VTGD68mrUsjXHKpzh /QnueJS9LY/DxusN1hZxyX9n6WNgkXZrmM48uUIlrbQMeF4RVWOrifFsgUvlE8fwPO Lfu0sb7Jn6Xm6dpDzhkFL3sQr9fy5pSDCZGqvfek= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Steve Atkins In-Reply-To: Date: Wed, 10 Sep 2014 09:50:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <540F35C4.5050906@dcrocker.net> <20140909183237.GC10013@localhost> <904f81ac-fa36-41cf-9f73-bf30429db981@gulbrandsen.priv.no> <20140909185655.GD10013@localhost> To: IETF Apps Discuss X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/sC9ByadqYSVmM_7trjLMpNNs-k8 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-01.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, 10 Sep 2014 16:50:09 -0000 On Sep 10, 2014, at 8:49 AM, Murray S. Kucherawy = wrote: > On Tue, Sep 9, 2014 at 1:57 PM, Murray S. Kucherawy = wrote: >=20 > That said, I concur that there's no hurry to expedite this work, and = also that we should not do this in a vacuum. As much as possible, the = markdown community should be made aware of the work proposed here, and = participate in the selection and definition of at least the initial set = of registry entries and their corresponding reference materials. I'm = willing to wait a reasonable period for that to happen. >=20 >=20 > If I were to prepare something that looks like a liaison statement = from APPSAWG to the markdown community asking them for feedback on what = we're proposing, is there a mailing list or a specific set of people to = which I should send it? The six people listed at http://commonmark.org + John Grubor are = probably a decent place to start. The recent rancor between them seems = to have calmed down a bit, but it's probably worth avoiding the word = "standard" anyway. Cheers, Steve= From nobody Wed Sep 10 09:57:53 2014 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 8FC241A90EE for ; Wed, 10 Sep 2014 09:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xc7nDiC2YMeC for ; Wed, 10 Sep 2014 09:57:50 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B54E1A9113 for ; Wed, 10 Sep 2014 09:57:45 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5886DFA0081; Wed, 10 Sep 2014 16:57:42 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1410368261-20915-20914/12/129; Wed, 10 Sep 2014 16:57:41 +0000 From: Arnt Gulbrandsen To: IETF Apps Discuss , Steve Atkins Message-Id: <9984b7a44d87ffb2fac019f74a9ff5f1473f3210de2eacb110824ece5a4b54f4.sha-256@android.antelope.email> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Date: Wed, 10 Sep 2014 16:57:41 +0000 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/eF1fJaBPK0sFGV20GJ7cXDtc5Fw Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-01.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, 10 Sep 2014 16:57:51 -0000 One more thing... I would say that the lack of a specified flavour does = not mean standard or original, but rather unknown. For many senders it = is difficult to find out what kind of markdown a particular document is. Army From nobody Wed Sep 10 13:38:24 2014 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 B12371A9128 for ; Wed, 10 Sep 2014 13:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 2OLMTcUm4UEc for ; Wed, 10 Sep 2014 13:38:20 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F5E1A8821 for ; Wed, 10 Sep 2014 13:38:20 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2425B509B6 for ; Wed, 10 Sep 2014 16:38:18 -0400 (EDT) Message-ID: <5410B6CE.9090504@seantek.com> Date: Wed, 10 Sep 2014 13:38:38 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <9984b7a44d87ffb2fac019f74a9ff5f1473f3210de2eacb110824ece5a4b54f4.sha-256@android.antelope.email> In-Reply-To: <9984b7a44d87ffb2fac019f74a9ff5f1473f3210de2eacb110824ece5a4b54f4.sha-256@android.antelope.email> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/h3pxEb3cNTzwUpaxcv27Z5BEa-s Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-01.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, 10 Sep 2014 20:38:21 -0000 On 9/10/2014 9:57 AM, Arnt Gulbrandsen wrote: > One more thing... I would say that the lack of a specified flavour=20 > does not mean standard or original, but rather unknown. For many=20 > senders it is difficult to find out what kind of markdown a particular = > document is. > Right; this is reflected in the paragraph on page 5 of draft-01: When this parameter conveyed (even if empty), the implicit first rule is "Original", namely, the original Markdown rules provided in John Gruber's Markdown Syntax from 2004 [MDSYNTAX ]. Whe= n this parameter is not conveyed, the author does not express any intent= about which rules apply: [MDSYNTAX ] may not necessarily be= the author's intent. -Sean From nobody Thu Sep 11 10:31:14 2014 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 05B141A8989; Thu, 11 Sep 2014 10:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JCQO1J686Ph; Thu, 11 Sep 2014 10:31:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F651A8978; Thu, 11 Sep 2014 10:30:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140911173054.27154.22464.idtracker@ietfa.amsl.com> Date: Thu, 11 Sep 2014 10:30:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/1hffuO7s1dUc8bs3yQJrytgIUbE Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-mdn-3798bis-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 17:31:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Message Disposition Notification Authors : Tony Hansen Alexey Melnikov Filename : draft-ietf-appsawg-mdn-3798bis-00.txt Pages : 32 Date : 2014-09-11 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: http://tools.ietf.org/html/draft-ietf-appsawg-mdn-3798bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 11 14:13:45 2014 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 BF21B1A01EE for ; Thu, 11 Sep 2014 14:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CK58LV3VQMa for ; Thu, 11 Sep 2014 14:13:43 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA701A01E0 for ; Thu, 11 Sep 2014 14:13:43 -0700 (PDT) Received: (qmail 70448 invoked from network); 11 Sep 2014 21:13:42 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 11 Sep 2014 21:13:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=dfd.54121086.k1409; i=johnl@user.iecc.com; bh=17V+2Xs9jb8BQ6OooyjNqRVXmwZfSTELId+sI3Kxi/U=; b=bA704sA9WtOthWtwJbgB3MxBgQitbEi/YbweVno6Qzr5xkTh0tpUTIkBkFkGxOrqeaCmFb4YNijO0Jt7Q/S9soVjdheosc/Rzk+ObbFNTSpdd6GJwv5XrMd9EcY1pc27iAXZ9XGriVaMAcsXf6Z6pP/06t7ulqFc1r5urF4OqawIannmaPGzvC9Gv92OiqaLurR9I9VzVLfyOidshAGwf9mGZlJ8qQdL1PV3AlBBCGam1aEY+FF0Pen/VS6uTBl8 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=dfd.54121086.k1409; olt=johnl@user.iecc.com; bh=17V+2Xs9jb8BQ6OooyjNqRVXmwZfSTELId+sI3Kxi/U=; b=KbGlh/6cfvtcuFSiai4RdIJd/2SEZpa5mY/e6QpRMTy1Ualyj3aVb3Y0vNkC59+y4k6ntxSfTE0kihZaAJ4qWyh56jVrUyOBMwO7gq6ynCk+8GepM7aHnuklDk9Hfrs6xEs3PZ0+04wxWKpVXUhnH7SUqc88xe5/qWVnYArVFAnbJf55VU+qebn8ZXjP03/xjtUWz+Rk82IZhX19JmlQdowYPwMVzRDw4f3MKTCpWTGf7DDXAU0bH847K5lW2sB4 Date: 11 Sep 2014 21:13:19 -0000 Message-ID: <20140911211319.3580.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/RjtUaSEqyV0ZyFbAfNuvDQu48b4 Cc: johnl@taugh.com Subject: Re: [apps-discuss] SMTP reply codes and nullMX (was: Re: Last minute concern on nullmx draft) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 21:13:44 -0000 >556 is fine with me if it's fine with everyone else. I'm assuming that if >your draft invents it, we can just refer to it in nullmx, right? Not having heard anything for a few days, can I assume it's OK to change the 521 to 556, and change the reference from RFC 1846, to, uh, what? Klensin's draft-klensin-smtp-521code-02 ? R's, John From nobody Thu Sep 11 16:17:33 2014 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 21D501A02A3 for ; Thu, 11 Sep 2014 16:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652, 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 rFgbXyhl2_QU for ; Thu, 11 Sep 2014 16:17:31 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 415A01A0242 for ; Thu, 11 Sep 2014 16:17:31 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PCGOWDI580003U3T@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 11 Sep 2014 16:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1410477152; bh=EKioOYUjjE9OJDDcGa8thzWWXFX6Ysg/JUYtBf6VW9c=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=A4pBtNtMjvso5FfjKc9gAfVPDwpGBCL5h45c8Keya591UGPRdrC6Fx81FRqj07ugo YpjA1UHFmEI8SQjORxX8PiywqNtgP2wcukKbDihsWtY8ZNOssYIMQv8xcKEhKV/BV4 Wu6RWNWQboXJ3iaFhyQgFVcBt1isaXe8nlWbUAQE= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PBOD9M5PXC0000SM@mauve.mrochek.com>; Thu, 11 Sep 2014 16:12:26 -0700 (PDT) Message-id: <01PCGOWC31T20000SM@mauve.mrochek.com> Date: Thu, 11 Sep 2014 16:11:52 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 11 Sep 2014 21:13:19 +0000" <20140911211319.3580.qmail@joyce.lan> References: <20140911211319.3580.qmail@joyce.lan> To: John Levine Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0U33PBKn6mjnvc-YFgY_K-KZZdM Cc: johnl@taugh.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] SMTP reply codes and nullMX (was: Re: Last minute concern on nullmx draft) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 23:17:32 -0000 > >556 is fine with me if it's fine with everyone else. I'm assuming that if > >your draft invents it, we can just refer to it in nullmx, right? > Not having heard anything for a few days, can I assume it's OK to > change the 521 to 556, and change the reference from RFC 1846, to, uh, > what? Klensin's draft-klensin-smtp-521code-02 ? The 556 change seems fine to me. The reference issue is beyond my pay grade. Ned From nobody Thu Sep 11 16:38:00 2014 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 54ECD1A01E8 for ; Thu, 11 Sep 2014 16:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vqn9lEMJwLqd for ; Thu, 11 Sep 2014 16:37:57 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADEA01A001E for ; Thu, 11 Sep 2014 16:37:56 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id pv20so3353588lab.36 for ; Thu, 11 Sep 2014 16:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oyaQsaL9kOglTBFff1Yo2HzE6Jx2MhcfNsBECbTZdMQ=; b=FbwvsxA3LAZjoTxYqr7MVW/zSXRLyNuAr7y/NC83NwLyGMgjCc5gSmB4aKv+PA/P7X 2XMN+aJGC5ubP4hb4M3PZfibpFYXOIg0LyXZPvKjdLNLkWROviKk3SS822gfOsTiahSF ZRjsyjk97/wdnoexyjcQJZtQd76y+uewL2jZFUMjTRT8tXIHZw/c+rtQUYI39OgywGXb 6/vzF4Rub3xSMxHTZstkLKc0mGlmMwlg5+MczkLQbKub0lQYht/UmCOOz2U/LudWOrPm 7NiFP2PzwH9QHIcwJAr9mJatIPi1CSsG3omaazc9anXWp1Ewh1zSP8T8SYPDSIabsNce oYyA== MIME-Version: 1.0 X-Received: by 10.112.225.7 with SMTP id rg7mr4514234lbc.52.1410478674891; Thu, 11 Sep 2014 16:37:54 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Thu, 11 Sep 2014 16:37:54 -0700 (PDT) In-Reply-To: <01PCGOWC31T20000SM@mauve.mrochek.com> References: <20140911211319.3580.qmail@joyce.lan> <01PCGOWC31T20000SM@mauve.mrochek.com> Date: Thu, 11 Sep 2014 16:37:54 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=001a11348d4e615b7f0502d2a808 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/q4TDTlwenyaI4xGCLwgiNKDGIz8 Cc: John Levine , IETF Apps Discuss Subject: Re: [apps-discuss] SMTP reply codes and nullMX (was: Re: Last minute concern on nullmx draft) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 23:37:58 -0000 --001a11348d4e615b7f0502d2a808 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 11, 2014 at 4:11 PM, Ned Freed wrote: > > >556 is fine with me if it's fine with everyone else. I'm assuming that > if > > >your draft invents it, we can just refer to it in nullmx, right? > > > Not having heard anything for a few days, can I assume it's OK to > > change the 521 to 556, and change the reference from RFC 1846, to, uh, > > what? Klensin's draft-klensin-smtp-521code-02 ? > > The 556 change seems fine to me. > +1. > > The reference issue is beyond my pay grade. > That reference change also looks correct (though omit the version number). -MSK --001a11348d4e615b7f0502d2a808 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 11, 2014 at 4:11 PM, Ned Freed <ned.freed= @mrochek.com> wrote:
> >5= 56 is fine with me if it's fine with everyone else.=C2=A0 I'm assum= ing that if
> >your draft invents it, we can just refer to it in nullmx, right?
> Not having heard anything for a few days, can I assume it's OK to<= br> > change the 521 to 556, and change the reference from RFC 1846, to, uh,=
> what?=C2=A0 Klensin's draft-klensin-smtp-521code-02 ?

The 556 change seems fine to me.

+1.
=C2= =A0

The reference issue is beyond my pay grade.
=C2=A0
<= div>
That reference change also looks correct (though omit th= e version number).

-MSK
--001a11348d4e615b7f0502d2a808-- From nobody Thu Sep 11 19:09:18 2014 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 B52811A0337 for ; Thu, 11 Sep 2014 19:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652] 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 2mRKE3NA1THB for ; Thu, 11 Sep 2014 19:09:14 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B87CB1A0302 for ; Thu, 11 Sep 2014 19:09:14 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XSGIT-000KZo-Hb; Thu, 11 Sep 2014 22:09:13 -0400 Date: Thu, 11 Sep 2014 22:09:08 -0400 From: John C Klensin To: John Levine , apps-discuss@ietf.org Message-ID: <43CF8062835FB274110018E9@JcK-HP8200.jck.com> In-Reply-To: <20140911211319.3580.qmail@joyce.lan> References: <20140911211319.3580.qmail@joyce.lan> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hRqEQi3G-7wnb-KtAfa6HT8ZxjY Subject: Re: [apps-discuss] SMTP reply codes and nullMX (was: Re: Last minute concern on nullmx draft) 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, 12 Sep 2014 02:09:17 -0000 --On Thursday, September 11, 2014 21:13 +0000 John Levine wrote: >> 556 is fine with me if it's fine with everyone else. I'm >> assuming that if your draft invents it, we can just refer to >> it in nullmx, right? > > Not having heard anything for a few days, can I assume it's OK > to change the 521 to 556, and change the reference from RFC > 1846, to, uh, what? Klensin's draft-klensin-smtp-521code-02 ? I think so, yes. Since that draft is the only place where 556 is described, it probably has to be the document cited. I've now responded to the only comment I've seen about that I-D so think it is probably ready for a Last Call as soon as some handy AD can get around to it. john From nobody Fri Sep 12 10:00:57 2014 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 E7CE21A7014; Fri, 12 Sep 2014 10:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 mIzL8ICCNR15; Fri, 12 Sep 2014 10:00:37 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id CDD151A7008; Fri, 12 Sep 2014 10:00:21 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id s8CGxior021931; Fri, 12 Sep 2014 17:59:44 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s8CGxiio008624; Fri, 12 Sep 2014 17:59:44 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s8CGxhiA014476; Fri, 12 Sep 2014 17:59:43 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id s8CGxfRH014472; Fri, 12 Sep 2014 17:59:41 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: apps-discuss@ietf.org, draft-ietf-mile-enum-reference-format.all@tools.ietf.org, mile@ietf.org From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 12 Sep 2014 17:59:41 +0100 Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/VW9W0y_h6I__CHBkO29yL8y1HU8 Cc: "Melnikov Alexey Takeshi Takahashi" , S Moonesamy Subject: [apps-discuss] Early Appsdir review of draft-ietf-mile-enum-reference-format-08 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, 12 Sep 2014 17:00:45 -0000 I have been selected as the Applications Area Directorate reviewer for this draft. Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your WG chairman(s) before posting a new version of the draft. Document: draft-ietf-mile-enum-reference-format-08 Title: IODEF Enumeration Reference Format Reviewer: Henry S. Thompson Review Date: 2014-09-12 Summary: This draft has a serious structural problem, which needs to be resolved before it can progress Major Issues: This draft identifies a problem with _The Incident Object Description Exchange Format_ (IODEF) [1] as regards the means provided to specifiy references to IDS alerts etc., and proposes changes to the Reference class in IODEF [2] and to its XML serialization. The proposal as such is fine, but the draft does not adequately address the question of how the proposed change is to be integrated into the existing definition of the XML serialization, as specified in the XML schema given in IODEF [3]. The schema given in IODEF puts the (original) ReferenceName element in the IODEF namespace, urn:ietf:params:xml:ns:iodef-1.0. The schema given in the draft at hand puts the new one in a new namespace, urn:ietf:params:xml:ns:iodef-enum-1.0 . This means that the example Reference serialization given in section 2.1 cannot be validated successfully, either against the IODEF schema, or the one in this draft, or a combination of the two. I note that IODEFv2 [4] has no changes in this regard either. I think this needs to be coordinated with IODEFv2, so that it contains a revised schema for the IODEF namespace. There a number of ways this could be done, depending on the approach you jointly agree to take wrt backwards compatibility. Assuming you want backward compatibility, i.e. you want existing IODEF XML serializations to be valid against the schema in IODEFv2, then you will want a) To make the example explicit wrt namespaces: CXI-1234-XYZ http://cxi.example.com Foo b) To modify the IODEFv2 schema along the following lines: ... Minor Issues: 1) Please clarify whether the 'abbreviation' field in the registry is required or optional, and include an 'abbreviation' in the example registry entry. 2) Please explain what the 'version' entry in the registry is for -- version of what? If it's a version of the specification, how is that not covered by the 'specification' field? The reader finds the use of 'version: any' in the registry example completely baffling. . . 3) Broken record time: The lack of any specified mapping from the (to my mind) unnecessary level of indirection from integers via registry entries to URIs which would actually give _access_ to such entries is irritating at least. Can't we at least _ask_ that IANA provide such a mapping, along the lines of http://www.iana.org/assignments/enumeration-reference-type/abbrev_version Nits: The subsections of section 2 must not be marked up properly, as they don't make it into the index. [1] https://tools.ietf.org/html/rfc5070 [2] https://tools.ietf.org/html/rfc5070#section-3.9.1 [3] https://tools.ietf.org/html/rfc5070#section-8 [4] http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-08.html -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Fri Sep 12 14:37:11 2014 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 D44CB1A0049 for ; Fri, 12 Sep 2014 14:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 CVdP-wS6rjcy for ; Fri, 12 Sep 2014 14:37:08 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 567E81A0032 for ; Fri, 12 Sep 2014 14:37:08 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 48F4150A73 for ; Fri, 12 Sep 2014 17:37:04 -0400 (EDT) Message-ID: <54136795.2070500@seantek.com> Date: Fri, 12 Sep 2014 14:37:25 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> In-Reply-To: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wqq1EIeaXMUfGOlKn5NDCr3M94s Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 21:37:10 -0000 Hi all, First, thanks for your comments, both publicly and privately. The Markdown community is fairly distributed. A significant part of the=20 community lurks on the markdown-discuss@six.pairlist.net list=20 . There are=20 other groups on the Internet as well--I have reached out to a few. I=20 also asked some implementers to participate directly. I even asked John=20 Gruber, back when the work started. He did not have objections. Most of the ideas that informed this draft-01, were already discussed in = July 2014-September 2014 on that list: http://six.pairlist.net/pipermail/markdown-discuss/2014-July/thread.html In addition to those conversations, several of the volunteer reviewers=20 have provided very detailed feedback. I specifically asked some=20 implementers to be reviewers, and they are graciously volunteering their = time. You can see the list on the APPSAWG wiki. One point of feedback in particular is that the introduction lacks a=20 disucssion of the goals and use cases for a) Markdown, and b) the=20 text/markdown media type. Some respondents have said "nobody is going to = use such-and-such thing" when in fact the matter was discussed, and=20 there are people who have come forward who really want to see=20 such-and-such thing for well-defined purposes. If these purposes are=20 spelled out clearly and concisely in the draft, it would help explain=20 why such-and-such thing exists. To this end I created a GoalsAndUses wiki: http://trac.tools.ietf.org/wg/appsawg/trac/wiki/TextMarkdown/GoalsAndUses= To everyone who is using Markdown...please put your use cases on that=20 webpage. It centralizes it and allows everyone to see them, so I can=20 (potentially) incorporate them into future drafts. Thanks! Sean From nobody Sat Sep 13 10:23:33 2014 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 35C5A1A0015; Sat, 13 Sep 2014 10:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqJDPob3cY0T; Sat, 13 Sep 2014 10:23:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E8A1A0020; Sat, 13 Sep 2014 10:23:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140913172325.16748.77364.idtracker@ietfa.amsl.com> Date: Sat, 13 Sep 2014 10:23:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZX0WxIyg8VR70ax0a5Kng6hkdEY Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-09.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, 13 Sep 2014 17:23:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : A "Null MX" No Service Resource Record for Domains that Accept No Mail Authors : John Levine Mark Delany Filename : draft-ietf-appsawg-nullmx-09.txt Pages : 8 Date : 2014-09-13 Abstract: Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately this means that the A/ AAAA record is taken to be mail server address even when that address does not accept mail. The no service MX RR, informally called null MX, formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server, which permits significant operational efficiencies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-nullmx-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-nullmx-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Sep 13 10:25:06 2014 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 36B9C1A001A for ; Sat, 13 Sep 2014 10:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCFbdtg9R5Fe for ; Sat, 13 Sep 2014 10:25:03 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A46E1A0025 for ; Sat, 13 Sep 2014 10:25:02 -0700 (PDT) Received: (qmail 53039 invoked from network); 13 Sep 2014 17:25:02 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 13 Sep 2014 17:25:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=b6c.54147ded.k1409; i=johnl@user.iecc.com; bh=iYoI9Az69sMi/sv2BvRO04XFVm9zJZZb3Yrb4YNy0uo=; b=0fRN5kMDv3ZbAxkhBK43IBqnhHC2ssl6IwovqPWyThi8eWM+wHvNoBAOahhTEL6VRTZCWmaqOtnibkJ394Xuz+ijtbnt5JJEQPAnUTPtXBSGSF8ALYuhoTMFibSX2TFygCZzmOBnycRgZLfOMKMYR+0vaPQLQDjvefrYLOaELm9DlkXcKJGHbZGS7eqTcLalhjQJiP3EbnejJIqKKVoEaLycYoHfoYdOdiTc12E/NoLqb+CXJ/3V28yCz0/sDCwn DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=b6c.54147ded.k1409; olt=johnl@user.iecc.com; bh=iYoI9Az69sMi/sv2BvRO04XFVm9zJZZb3Yrb4YNy0uo=; b=b7wMHSQcayggbLaRx0JouwE9JmzJlWFuPb0eB+xsqx8r8C2zwya7WPitn708TjLh1ldp0rA/vyiLWoje1VHl7dZyvRhaNY1sP4nnbJqkg+mawr/uV8ypn+0zhHVNGPD1P6XOFmEX4c60ap+iMVQRs3R+8eLaaerkFypbYmTm3dRaJ2dN0mWD7qWWB4F+aZDREp+YwZDIQN9shezIS/rgsQZ2s4BIAV27LHDYtcGcg2LN+ZSyoGrhI4M0y1uk6Tv4 Date: 13 Sep 2014 17:24:39 -0000 Message-ID: <20140913172439.2923.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/vkMDSIL_0SecKYuTQP1EMPqIqRY Subject: Re: [apps-discuss] SMTP reply codes and nullMX (was: Re: Last minute concern on nullmx draft) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 17:25:04 -0000 >> > >556 is fine with me if it's fine with everyone else. I'm assuming that >> if >> > >your draft invents it, we can just refer to it in nullmx, right? >> >> > Not having heard anything for a few days, can I assume it's OK to >> > change the 521 to 556, and change the reference from RFC 1846, to, uh, >> > what? Klensin's draft-klensin-smtp-521code-02 ? >> >> The 556 change seems fine to me. >That reference change also looks correct (though omit the version number). OK, uploaded -09 with 521->556 and rfc1846 is now rfc1846bis. Also changed the new enhanced return code numbers to TBD per IANA suggestion. This may introduce a dependency on 1846bis, but after eight years in the hopper, another month or two hardly matters. R's, John From nobody Sat Sep 13 10:46:19 2014 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 AA33A1A0039 for ; Sat, 13 Sep 2014 10:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652] 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 IRj00T-kXSU0 for ; Sat, 13 Sep 2014 10:46:15 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D501A0031 for ; Sat, 13 Sep 2014 10:46:14 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XSrOn-000P1j-UT; Sat, 13 Sep 2014 13:46:13 -0400 Date: Sat, 13 Sep 2014 13:46:08 -0400 From: John C Klensin To: John Levine Message-ID: In-Reply-To: <20140913172439.2923.qmail@joyce.lan> References: <20140913172439.2923.qmail@joyce.lan> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wXfQeXkkS6-0snbfnPvG38WM6uI Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] SMTP reply codes and nullMX (was: Re: Last minute concern on nullmx draft) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 17:46:17 -0000 --On Saturday, September 13, 2014 17:24 +0000 John Levine wrote: > >>> > > 556 is fine with me if it's fine with everyone else. >>> > > I'm assuming that >>> if >>> > > your draft invents it, we can just refer to it in >>> > > nullmx, right? >>> >>> > Not having heard anything for a few days, can I assume >>> > it's OK to change the 521 to 556, and change the reference >>> > from RFC 1846, to, uh, what? Klensin's >>> > draft-klensin-smtp-521code-02 ? >>> >>> The 556 change seems fine to me. > >> That reference change also looks correct (though omit the >> version number). > > OK, uploaded -09 with 521->556 and rfc1846 is now rfc1846bis. > Also changed the new enhanced return code numbers to TBD per > IANA suggestion. Ok. When you start working with the RFC Editor, be sure that the reference points to the document whose title you quoted (draft-klensin-smtp-521code-02). It is not really 1846bis, which is a separate task for the future. Replacing 1846 would have required addressing a series of "no mail here" issues that are independent of the codes. I tried doing that with draft-klensin-rfc1846bis-00 but it because obvious in consultation with the 1846 authors that it would be more effort than anyone was ready for, so replaced it with draft-klensin-smtp-521code-02. I think the I-D is fine, just worried about possible disconnects down the road. > This may introduce a dependency on 1846bis, but after eight > years in the hopper, another month or two hardly matters. Agreed. john From nobody Sat Sep 13 12:01:55 2014 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 422081A007E; Sat, 13 Sep 2014 12:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqBJHWuHn9bc; Sat, 13 Sep 2014 12:01:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 168ED1A008D; Sat, 13 Sep 2014 12:01:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140913190149.2570.10739.idtracker@ietfa.amsl.com> Date: Sat, 13 Sep 2014 12:01:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/w8h5skX4pneVz-fZZLYRCRNesfw Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-10.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 19:01:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : A "Null MX" No Service Resource Record for Domains that Accept No Mail Authors : John Levine Mark Delany Filename : draft-ietf-appsawg-nullmx-10.txt Pages : 8 Date : 2014-09-13 Abstract: Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately this means that the A/ AAAA record is taken to be mail server address even when that address does not accept mail. The no service MX RR, informally called null MX, formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server, which permits significant operational efficiencies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-nullmx-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-nullmx-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Sep 13 12:03:17 2014 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 318421A008D for ; Sat, 13 Sep 2014 12:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aloFSS23TQxy for ; Sat, 13 Sep 2014 12:03:14 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E4B1A00A9 for ; Sat, 13 Sep 2014 12:03:13 -0700 (PDT) Received: (qmail 61481 invoked from network); 13 Sep 2014 19:03:11 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 13 Sep 2014 19:03:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=cae.541494ef.k1409; i=johnl@user.iecc.com; bh=1xda1efNBF7KstTu2AljPcjejhdfYEuZ0zltqnVQ4F8=; b=oF3Tgds9T3v1KCt7p+tRI929JNJwQS08Jno65hwUKyi61wdNfD/caLAVlswNz9G2wYjwR5lmuTCwHCE96bIZh4K9Udd/jxa1zW2MFMQmsdou/WhSCHBjs5sDietF0J3XAVRn2/kyrlwH8Vd8stqShKBiFckB+gKrhTl/BuovjNuh1cIPA+LS8TDoYBaMZEBe7OfRMzhRRJw3cVKf4ywptHJZpocADPBpRJH4DArM8E20rHxCSnuWnrl+WwsqW8Tx DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=cae.541494ef.k1409; olt=johnl@user.iecc.com; bh=1xda1efNBF7KstTu2AljPcjejhdfYEuZ0zltqnVQ4F8=; b=ckA88UsDu1iPgTZ8HxK4huPsoN6x+9ESo7UodM7l1Fz7NRRh3t2p9ALCRS0heFcuVrTl1fpVZzcRS2ZRTW938fRuACG+SrKy+cdJR6TL/bxBKWJQjShuo0PG7l4UDdXljgFYZgkX14/O9jZzKQiY+BRQaGrgmhBv2UHlfBUD7dFME36RylmzL/5FruAbFK/geyUJlzI0pddwnFOE3bhNp5wJoV8YnOsRWsooe2+y6g2N/ERkl2j3lLd9LU7TO/N1 Date: 13 Sep 2014 19:02:49 -0000 Message-ID: <20140913190249.3245.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/FwdtSagvrR0utdAPjtgSV2_1t1o Subject: Re: [apps-discuss] SMTP reply codes and nullMX (was: Re: Last minute concern on nullmx draft) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 19:03:15 -0000 >Ok. When you start working with the RFC Editor, be sure that >the reference points to the document whose title you quoted >(draft-klensin-smtp-521code-02). It is not really 1846bis, OK, sent in a -10 with a few small twiddles to make it unambiguously clear that's the draft in question. R's, John From nobody Sat Sep 13 13:46:10 2014 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 D0AA61A00D4 for ; Sat, 13 Sep 2014 13:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, 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 8f033-fhvfX9 for ; Sat, 13 Sep 2014 13:45:59 -0700 (PDT) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id 060E41A0119 for ; Sat, 13 Sep 2014 13:45:59 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3hwQpY2qwJz5MhBy; Sat, 13 Sep 2014 22:45:57 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3hwQpY1RFpz5Mh9k; Sat, 13 Sep 2014 22:45:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 5710C123377; Sat, 13 Sep 2014 22:45:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id y_QzY-Ic47uz; Sat, 13 Sep 2014 22:45:47 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 33989123341; Sat, 13 Sep 2014 22:45:47 +0200 (CEST) Message-ID: <5414ACFA.7020705@sonnection.nl> Date: Sat, 13 Sep 2014 22:45:46 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: John Levine , apps-discuss@ietf.org References: <20140913190249.3245.qmail@joyce.lan> In-Reply-To: <20140913190249.3245.qmail@joyce.lan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1410641157; bh=jy+MHNM1JBQa/6+Tu0XZorbv/j9dOVs96bR6NSetqWo=; h=Message-ID:Date:From:To:Subject:From; b=XSA/JfkbpXVD3U/o2HwfE3LEnmrStsg1FHUpwGfsrnsqjDn9CDLtjzek3wjDAvrlA QHofDd/Gs7Ve89bbwnG1JZNOmGT6ABO2N99ezWqpwomObUu7HDbSk0CnucXjcTMb2m IWmUqZS+zK0ILuNZ8Gmb9NeL4qpBGu+iJfM+ryrQ= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3hwQpY2qwJz5MhBy Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Uv7yLo2R91OAYUpYq52bSUkXYSk Subject: Re: [apps-discuss] SMTP reply codes and nullMX (was: Re: Last minute concern on nullmx draft) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 20:46:08 -0000 Hi, John, On 09/13/2014 09:02 PM, John Levine wrote: >> Ok. When you start working with the RFC Editor, be sure that >> the reference points to the document whose title you quoted >> (draft-klensin-smtp-521code-02). It is not really 1846bis, > OK, sent in a -10 with a few small twiddles to make it unambiguously > clear that's the draft in question. sorry for being late at the party and excuse me if this has been discussed before. RFC1035 has some restrictions on labels, a.o. in par. 2.3.1: The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less. The phrase "must start with a letter" implicitely forbids a zero-length label, isn't it? Furthermore, par. 3.1 of RFC1035 says: Since every domain name ends with the null label of the root, a domain name is terminated by a length byte of zero. I.e. the only zero-length label is the label that terminates a series of labels (i.e. the root label). /rolf From nobody Sun Sep 14 14:29:54 2014 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 3CAA41A02D7 for ; Sun, 14 Sep 2014 14:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnf-2XKyz-7m for ; Sun, 14 Sep 2014 14:29:52 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E75A1A02C1 for ; Sun, 14 Sep 2014 14:29:51 -0700 (PDT) Received: (qmail 10516 invoked from network); 14 Sep 2014 21:29:50 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 14 Sep 2014 21:29:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=80b.541608ce.k1409; i=johnl@user.iecc.com; bh=bBDOSSRLnNfvVfJjFAjTOq11K6TeKPIvqRTM6VrpXAM=; b=amfn0kBFlZOJWfZoBj4pKlq3Nx6tBoEo3YIas1JNShObCGJkY8qrgKahczNO5sL0DOAgZm7zoY9NVHzZ/eGz/KUk6Tc7iHUtsXEX3znEuQWLtpGGcm+dGxUA3HzhzPOEtmOao0txBWMpT7UkGfJ+ZHFKLA/LzBAwoRGEyG5/ntYdrlKun/JVvLWf5GgKlccudQuZIk7I0B9hbUp2Dqa2UBOQNS+l60z6rPRANv+sVm6PStPJ19FqBe91nryXDYBu DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=80b.541608ce.k1409; olt=johnl@user.iecc.com; bh=bBDOSSRLnNfvVfJjFAjTOq11K6TeKPIvqRTM6VrpXAM=; b=SXIIlvyYFIzyB7KlvcFL4hSJ/AwtRrrlzUnydjjdxaskf9Ldh+eAHHOm4lSkY8F3UW8+WPJpYMzkiLJ89Rel0e4hFDQTsbso6F1QJrlTHw7Nd7Xx8NkwE0ORmg0KIltpohBpUpN2Js/f810z93DDZ6LshscBm4hv/q0HhD89sQdwC0aoz/N8wM0NvYBeBYKxfbHH/Z+mN6PkRO64/c9aXzx9qv9RnIAmKKzUbxIriWRhh5BKhoIH9a+6hZAcFLIX Date: 14 Sep 2014 21:29:27 -0000 Message-ID: <20140914212927.2058.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <5414ACFA.7020705@sonnection.nl> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/rZskoW72ydVTkrGHhHah9RehQ64 Subject: Re: [apps-discuss] SMTP reply codes and nullMX (was: Re: Last minute concern on nullmx draft) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 21:29:53 -0000 >I.e. the only zero-length label is the label that terminates a series of >labels (i.e. the root label). Yes, that's the one that nullmx uses. I don't understand what you think is wrong here. R's, John From nobody Mon Sep 15 12:30:00 2014 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 747A51A0026 for ; Mon, 15 Sep 2014 12:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csByJBBNnIIq for ; Mon, 15 Sep 2014 12:29:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CEC1A6F52 for ; Mon, 15 Sep 2014 12:29:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140915192955.7792.61041.idtracker@ietfa.amsl.com> Date: Mon, 15 Sep 2014 12:29:55 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/dqRxCidWpeRl8TQBY1a-wLI8DPI Subject: [apps-discuss] Milestones changed for appsawg WG 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: Mon, 15 Sep 2014 19:29:58 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-authres-ptypes-registry", resolved as "Done". URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nobody Mon Sep 15 12:55:47 2014 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 97A131A6F99 for ; Mon, 15 Sep 2014 12:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 KsPW67RnSUkF for ; Mon, 15 Sep 2014 12:55:43 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id C53481A6FC5 for ; Mon, 15 Sep 2014 12:55:42 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3hxdbd50Yfz1L8f3; Mon, 15 Sep 2014 21:55:41 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3hxdbd2Yswz1L8f2; Mon, 15 Sep 2014 21:55:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id CBFFE12338C; Mon, 15 Sep 2014 21:55:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Vgz7sCHM_y82; Mon, 15 Sep 2014 21:55:32 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 46172123377; Mon, 15 Sep 2014 21:55:32 +0200 (CEST) Message-ID: <54174433.50707@sonnection.nl> Date: Mon, 15 Sep 2014 21:55:31 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: John Levine , apps-discuss@ietf.org References: <20140914212927.2058.qmail@joyce.lan> In-Reply-To: <20140914212927.2058.qmail@joyce.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1410810941; bh=W2XO0mEsmy55ZWYUpAoUObO+zOiYhfF/8kcKvi8A+RM=; h=Message-ID:Date:From:To:Subject:From; b=mFxVvdH2JHJ3854UgiDbpjVGxgnbjlkn+nQVBZ3weNoWxc5xGUrQ3JRPRJh37Fphw KEEuwqKSXYQ3inRiLOXiRuIkn98nb1H3lvBXuaYmq+JHoy9YFOC5X/Pxcdpdyt4bTS IRv3RE7OZVFwiiY9/OlY9j+B9jrmrichTimlDn4o= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3hxdbd50Yfz1L8f3 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/SCbudmxYwrMszm1-qXOHSQ4g5nI Subject: Re: [apps-discuss] SMTP reply codes and nullMX (was: Re: Last minute concern on nullmx draft) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 19:55:45 -0000 On 09/14/2014 11:29 PM, John Levine wrote: >> I.e. the only zero-length label is the label that terminates a series of >> labels (i.e. the root label). > Yes, that's the one that nullmx uses. > > I don't understand what you think is wrong here. nothing wrong, the zero-length label and the single dot were a bit confusing, but after re-reading the draft and RFC1035 it's now clear to me that draft and RFC1035 are coherent ;-). /rolf From nobody Mon Sep 15 13:16:04 2014 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 CD0DA1A6F41 for ; Mon, 15 Sep 2014 13:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_fPebl6oGe2 for ; Mon, 15 Sep 2014 13:16:02 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395331A802A for ; Mon, 15 Sep 2014 13:15:30 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id pv20so5377446lab.8 for ; Mon, 15 Sep 2014 13:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=flGnA69D1RifPQguYALJuNQ8ZJR2q7CpZviGCZE9Jdc=; b=tJGUNkQk7KTNWMVmkjRcnqDT34tOEs0QsjNz7tBzffpHZUvaCf7dRb5QpI+Owv1zdu gsOfo0pvkKsyTI3EDOKuO2e8H2HL5JhLzVhv04NYZ4CDyip433hJivQwazmUEO2O2ZOO iRm3UYohp/fUQzqaDs+GOD7zBwOAMsO9yzlWPDqxPsCHxGshVQRVxabKwPhznueYUKcC 6WzN8/jTjIKxckmUWf4sGMe7SHUerSK3Ts9pHbHL4Fp8Q67fnyk1XIWt20of3oQmkOGx w2wsFLhHlLlQmeVFFR5uLQ98/ljSAdKyPZdCPqOhE7ZCqy639UYa8XnurcJ6MKglpE1u GUZw== MIME-Version: 1.0 X-Received: by 10.112.63.71 with SMTP id e7mr5840084lbs.89.1410812128301; Mon, 15 Sep 2014 13:15:28 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Mon, 15 Sep 2014 13:15:28 -0700 (PDT) Date: Mon, 15 Sep 2014 13:15:28 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c3ee62c0a0720503204b63 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Zu2hgelCs3KS1fN-4dxbjOXvXeI Subject: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 20:16:03 -0000 --001a11c3ee62c0a0720503204b63 Content-Type: text/plain; charset=UTF-8 Is there a sufficiently stable definition for "REST" or "RESTful" we can reference from a future RFC? I can't think of anything authoritative, and search engines point me to things that I don't imagine we'd consider to be stable enough. Wikipedia seems to be the closest thing; do we allow such references in RFCs these days? Thanks, -MSK --001a11c3ee62c0a0720503204b63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is there a sufficiently stable definition for "REST&q= uot; or "RESTful" we can reference from a future RFC?=C2=A0 I can= 't think of anything authoritative, and search engines point me to thin= gs that I don't imagine we'd consider to be stable enough.=C2=A0 Wi= kipedia seems to be the closest thing; do we allow such references in RFCs = these days?

Thanks,
-MSK
--001a11c3ee62c0a0720503204b63-- From nobody Mon Sep 15 13:18:35 2014 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 7806D1A86E2 for ; Mon, 15 Sep 2014 13:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 DP04gYl0wocK for ; Mon, 15 Sep 2014 13:18:30 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 377501A7035 for ; Mon, 15 Sep 2014 13:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s8FKIDqB023309; Mon, 15 Sep 2014 22:18:13 +0200 (CEST) Received: from [192.168.217.106] (p54890261.dip0.t-ipconnect.de [84.137.2.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 65EABA2; Mon, 15 Sep 2014 22:18:10 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Mon, 15 Sep 2014 22:18:06 +0200 X-Mao-Original-Outgoing-Id: 432505086.518968-380a2a32d32359ce1c294b0e50a356f7 Content-Transfer-Encoding: quoted-printable Message-Id: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/u7wDuV-Qzv6o3SmXjj8imx5Flo8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 20:18:34 -0000 On 15 Sep 2014, at 22:15, Murray S. Kucherawy = wrote: > Is there a sufficiently stable definition for "REST" or "RESTful" we = can reference from a future RFC? I can't think of anything = authoritative,=20 What=92s wrong with Roy Fielding=92s dissertation? For RFC 7252, we used: [REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Ph.D. Dissertation, University of California, Irvine, 2000, . Gr=FC=DFe, Carsten From nobody Mon Sep 15 13:24:55 2014 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 D8A741A6F7E for ; Mon, 15 Sep 2014 13:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHwZgFQr0pAQ for ; Mon, 15 Sep 2014 13:24:49 -0700 (PDT) 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 13C271A7023 for ; Mon, 15 Sep 2014 13:24:22 -0700 (PDT) Received: from [192.168.2.160] ([93.217.117.238]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MFgxF-1XWhsH23HR-00EgJ7; Mon, 15 Sep 2014 22:24:20 +0200 Message-ID: <54174AF2.4000101@gmx.de> Date: Mon, 15 Sep 2014 22:24:18 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Carsten Bormann , "Murray S. Kucherawy" References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> In-Reply-To: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:Hodd0XTCF1wWESWDlXrJb1Qa/hmqMK6vgm7s4UW/5bFsrvCvrFK +1tu+dpxExyYpzumKUYIwnDTQW/1QBnbYQVoEi5oApDLaM2deb9E750d0y64ttpAGv1Fhh0 okOZRm95q1UDV0KTD6WWkxjws13gahgxArhGpmfOGGrTTiavbILQdo1/jri2Jd4WDx4WUK7 4SMC/XSzBUUc+x+0VFh4w== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/5_5Wt6juhetPCW5Puvdf-apYQ_s Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 20:24:51 -0000 On 2014-09-15 22:18, Carsten Bormann wrote: > On 15 Sep 2014, at 22:15, Murray S. Kucherawy wrote: > >> Is there a sufficiently stable definition for "REST" or "RESTful" we can reference from a future RFC? I can't think of anything authoritative, > > What’s wrong with Roy Fielding’s dissertation? > For RFC 7252, we used: > > [REST] Fielding, R., "Architectural Styles and the Design of > Network-based Software Architectures", Ph.D. Dissertation, > University of California, Irvine, 2000, > fielding_dissertation.pdf>. > Or : > [REST] Fielding, R., “Architectural Styles and the Design of Network-based Software Architectures”, Doctoral Dissertation, University of California, Irvine, September 2000, . Which is what we used in HTTP. Best regards, Julian From nobody Mon Sep 15 13:26:00 2014 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 D84AA1A6F6D for ; Mon, 15 Sep 2014 13:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWCmOV9KaeYA for ; Mon, 15 Sep 2014 13:25:59 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E2B81A6F5A for ; Mon, 15 Sep 2014 13:25:58 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8FKPqes027719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 15 Sep 2014 13:25:56 -0700 Message-ID: <54174A83.2020704@dcrocker.net> Date: Mon, 15 Sep 2014 13:22:27 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Carsten Bormann , "Murray S. Kucherawy" References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> In-Reply-To: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 15 Sep 2014 13:25:56 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/iDIitHC_4OII1kWrQVT4KTarZuU Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 20:26:00 -0000 On 9/15/2014 1:18 PM, Carsten Bormann wrote: > On 15 Sep 2014, at 22:15, Murray S. Kucherawy wrote: > >> Is there a sufficiently stable definition for "REST" or "RESTful" we can reference from a future RFC? I can't think of anything authoritative, > > What’s wrong with Roy Fielding’s dissertation? > For RFC 7252, we used: A "definition" is usually relatively short, measured by a few sentences. An entire book is rather too long to qualify. A tight reference to a few sentences /in/ a book might be useful, of course. It is also possible that, over the years, the industry has found some concise wording to define the term that is better than what Roy came up with for his dissertation. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Sep 15 13:31:58 2014 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 1FCCA1A6F6B for ; Mon, 15 Sep 2014 13:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 IlR7_JeJRh5x for ; Mon, 15 Sep 2014 13:31:56 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB7B1A86FC for ; Mon, 15 Sep 2014 13:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s8FKVa1m024458; Mon, 15 Sep 2014 22:31:36 +0200 (CEST) Received: from [192.168.217.106] (p54890261.dip0.t-ipconnect.de [84.137.2.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id ED52BAA; Mon, 15 Sep 2014 22:31:35 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <54174A83.2020704@dcrocker.net> Date: Mon, 15 Sep 2014 22:31:34 +0200 X-Mao-Original-Outgoing-Id: 432505894.218581-11d5f837eae2789ae14aa381af4d9027 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/xNVXLsykj34BqVJVxqpQUDAIrMY Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 20:31:57 -0000 On 15 Sep 2014, at 22:22, Dave Crocker wrote: > A "definition" is usually relatively short, measured by a few = sentences. Sure, =93REST, short for Representational State Transfer, is an = architectural style defined in [REST].=94 I doubt one can capture the essence of REST in a few sentences. (Unfortunately, the dissertation has some editorial issues that make it = hard to extract that essence except through a number of careful = readings. That=92s the stuff religions are made of... But exegesis is = worth it in this case.) Gr=FC=DFe, Carsten From nobody Mon Sep 15 13:35:27 2014 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 7E4721A8027 for ; Mon, 15 Sep 2014 13:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6y0VdJEtRpj for ; Mon, 15 Sep 2014 13:35:25 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758F11A702F for ; Mon, 15 Sep 2014 13:35:25 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8FKZKIs027889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 15 Sep 2014 13:35:24 -0700 Message-ID: <54174CBB.7070007@dcrocker.net> Date: Mon, 15 Sep 2014 13:31:55 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Carsten Bormann , dcrocker@bbiw.net References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 15 Sep 2014 13:35:24 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/i8cfo-aghS6-4h_t7LAXDEF0s_g Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 20:35:26 -0000 On 9/15/2014 1:31 PM, Carsten Bormann wrote: > On 15 Sep 2014, at 22:22, Dave Crocker wrote:>> A "definition" is usually relatively short, measured by a few >> sentences. > > Sure, “REST, short for Representational State Transfer, is an > architectural style defined in [REST].” > > I doubt one can capture the essence of REST in a few sentences. That's almost certainly a problem. It suggests a poor community understanding of its essence. Given how ingrained the term is and for how long it has been used, the problem is probably not a minor one. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Sep 15 14:51:35 2014 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 C0D011A87A6 for ; Mon, 15 Sep 2014 14:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PoogaKfALq8 for ; Mon, 15 Sep 2014 14:51:32 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A52D51A87B0 for ; Mon, 15 Sep 2014 14:51:29 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id gi9so5705151lab.30 for ; Mon, 15 Sep 2014 14:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QCVbqCaFoeCrBm7eeDDfyD8CLmBER+nHWDCPaJCg/wQ=; b=PKDjqT+521dwlMDUJwP3xDumy4A0rpFRYckf38mofHgQZePrPUapEznmjix2lJ53lq zTt6Z5zlBWMz8THEO4JtVbnbeGbGUrbIRMzPq8RZo60Jp7fT302wKEZp2zmI4tEdyhbs sYULLoMwgflILwPa46eXzCEV0Lut/9DdeOenn/mAx+b9WI20HyUGbhYCBdTZL9O1Jp1E T1p6rSvfiFf3qyzBHoTopmmJLu//U9RNWt0llJWu45/1o+0X8dJcDDBO1jgpe6vNfqzv A+/X42JWOE+/tu/AxJlTdSmlqifbP1R83uTWiUYtLUvnTmpda9ZJlzvIab+nbYzSiBi6 jFlg== MIME-Version: 1.0 X-Received: by 10.152.1.6 with SMTP id 6mr31960613lai.22.1410817887949; Mon, 15 Sep 2014 14:51:27 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Mon, 15 Sep 2014 14:51:27 -0700 (PDT) In-Reply-To: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> Date: Mon, 15 Sep 2014 14:51:27 -0700 Message-ID: From: "Murray S. Kucherawy" To: Carsten Bormann Content-Type: multipart/alternative; boundary=089e013c67060dd888050321a302 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/akDe2wWhlscL4sYVE1kfsYapR4Q Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 21:51:33 -0000 --089e013c67060dd888050321a302 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 15, 2014 at 1:18 PM, Carsten Bormann wrote: > On 15 Sep 2014, at 22:15, Murray S. Kucherawy wrote= : > > > Is there a sufficiently stable definition for "REST" or "RESTful" we ca= n > reference from a future RFC? I can't think of anything authoritative, > > What=E2=80=99s wrong with Roy Fielding=E2=80=99s dissertation? > For RFC 7252, we used: > > [REST] Fielding, R., "Architectural Styles and the Design of > Network-based Software Architectures", Ph.D. Dissertation, > University of California, Irvine, 2000, > fielding_dissertation.pdf>. > I saw that one, but I didn't know if that URI is considered permanent enough to be used as a citation in an RFC. Since there's precedent, I guess that answers my question. Thanks! -MSK --089e013c67060dd888050321a302 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 15, 2014 at 1:18 PM, Carsten Bormann <cabo@tzi.org= > wrote:
On 15 Sep 2014, at 22:= 15, Murray S. Kucherawy <superuse= r@gmail.com> wrote:

> Is there a sufficiently stable definition for "REST" or &quo= t;RESTful" we can reference from a future RFC?=C2=A0 I can't think= of anything authoritative,

What=E2=80=99s wrong with Roy Fielding=E2=80=99s dissertation?
For RFC 7252, we used:

=C2=A0 =C2=A0[REST]=C2=A0 =C2=A0 =C2=A0Fielding, R., "Architectural St= yles and the Design of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Network-based Software Arc= hitectures", Ph.D. Dissertation,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 University of California, = Irvine, 2000,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.ics.= uci.edu/~fielding/pubs/dissertation/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fielding_dissertation.pdf&= gt;.

I saw that one, but I didn't k= now if that URI is considered permanent enough to be used as a citation in = an RFC.=C2=A0 Since there's precedent, I guess that answers my question= .=C2=A0 Thanks!

-MSK
--089e013c67060dd888050321a302-- From nobody Mon Sep 15 14:57:30 2014 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 9BCE81A87DB for ; Mon, 15 Sep 2014 14:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L25fyNOWnSVv for ; Mon, 15 Sep 2014 14:57:26 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23FD41A87B9 for ; Mon, 15 Sep 2014 14:57:26 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id h3so4747826igd.17 for ; Mon, 15 Sep 2014 14:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=P8aRKkEKrhQMqqf2tnYWRrbcWjxFzb5NAu2Lt29970Y=; b=QC0RZ+830uu9zwQORYggrK31RPexOauVBj/wVwK2TnndxgC0Kw0QWLWjuDlOYxfNz0 5rXicBXgGJzlQrN1bufAlrFW7M5PWGuXFTJamUNsq2VYZwBCBVJgUBcljRK/cZnnpVTq /WhCg/7M/bzIfwwPWF6VbYrJlu0qOt61o0z/+xuM0eaQ4amfgDMfvV/OFh2D9NPW3Yoj V3MmwkK7hC3J4T9X7ac0oxyLIX2aQ7fUOERGwiT4ulP8YVbKtJvABTh2jOmcbhfaHGsX brQq0uCgr2agY4tIJhvvlS87X9aNWE+/MqxcMGZMlY8ebeBoOdKqASUdBl+rF0ZACDrJ yAJw== X-Received: by 10.42.98.15 with SMTP id q15mr27592794icn.29.1410818245526; Mon, 15 Sep 2014 14:57:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.156.67 with HTTP; Mon, 15 Sep 2014 14:57:05 -0700 (PDT) In-Reply-To: <54174CBB.7070007@dcrocker.net> References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> From: Ira McDonald Date: Mon, 15 Sep 2014 17:57:05 -0400 Message-ID: To: dcrocker@bbiw.net, Ira McDonald Content-Type: multipart/alternative; boundary=90e6ba61465e5e0819050321b8c9 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3knhEeswOJsp0UurzOn1mP2Un2A Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 21:57:27 -0000 --90e6ba61465e5e0819050321b8c9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I agree with Dave Crocker's comments. Citing REST, in the absence of a concise definition, is dubious in any open standard. Cheers, - Ira On Mon, Sep 15, 2014 at 4:31 PM, Dave Crocker wrote: > On 9/15/2014 1:31 PM, Carsten Bormann wrote: > > On 15 Sep 2014, at 22:22, Dave Crocker wrote:>> A > "definition" is usually relatively short, measured by a few > >> sentences. > > > > Sure, =E2=80=9CREST, short for Representational State Transfer, is an > > architectural style defined in [REST].=E2=80=9D > > > > I doubt one can capture the essence of REST in a few sentences. > > > That's almost certainly a problem. It suggests a poor community > understanding of its essence. > > Given how ingrained the term is and for how long it has been used, the > problem is probably not a minor one. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --90e6ba61465e5e0819050321b8c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I agree with Dave Cro= cker's comments.=C2=A0 Citing REST, in the absence of
a concise def= inition, is dubious in any open standard.

Cheers,
- Ira

On Mon, Sep 15, 2014 at 4:31 PM,= Dave Crocker <dhc@dcrocker.net> wrote:
On 9/15/2014 1:31 = PM, Carsten Bormann wrote:
> On 15 Sep 2014, at 22:22, Dave Crocker <dhc@dcrocker.net> wrote:>> A "definition" i= s usually relatively short, measured by a few
>> sentences.
>
> Sure, =E2=80=9CREST, short for Representational State Transfer, is an<= br> > architectural style defined in [REST].=E2=80=9D
>
> I doubt one can capture the essence of REST in a few sentences.


That's almost certainly a problem.=C2=A0 It suggests a poor comm= unity
understanding of its essence.

Given how ingrained the term is and for how long it has been used, the
problem is probably not a minor one.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

____________________________= ___________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--90e6ba61465e5e0819050321b8c9-- From nobody Mon Sep 15 15:01:43 2014 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 B69701A87C4 for ; Mon, 15 Sep 2014 15:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 2QJUbOAGaWy5 for ; Mon, 15 Sep 2014 15:01:42 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE011A87E9 for ; Mon, 15 Sep 2014 15:01:41 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id D2332318064 for ; Mon, 15 Sep 2014 15:01:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=k5IEEPgjFPrcQ9sWLeVp Wj7Qp2k=; b=qPz8QANlpyKiFuQbyO90zwgAFAXP+1zJ1SCDYVG4sbI7L82bJGJN MN+BbD5LE/Qkps+eZ3UTvxF7SYPa9KlhgmieXnyXSbOnoVKRSY2Uiyc408NMK9EO B/7SCwCkTlFvVLXwCuBs7fkYWRSHSytlW6an6CapeZykFwub5E0lay4= Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 8572831805C for ; Mon, 15 Sep 2014 15:01:40 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id u57so4699443wes.15 for ; Mon, 15 Sep 2014 15:01:39 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.77.243 with SMTP id v19mr36940336wjw.18.1410818499329; Mon, 15 Sep 2014 15:01:39 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Mon, 15 Sep 2014 15:01:39 -0700 (PDT) In-Reply-To: References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> Date: Mon, 15 Sep 2014 17:01:39 -0500 Message-ID: From: Nico Williams To: Ira McDonald Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/l_5Ar6Pe9hSg8Bs02_4BKy--s4Q Cc: Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 22:01:42 -0000 On Mon, Sep 15, 2014 at 4:57 PM, Ira McDonald wrote: > I agree with Dave Crocker's comments. Citing REST, in the absence of > a concise definition, is dubious in any open standard. We have some enormous RFCs. Spec length is not the problem. The problem is that a dissertation generally doesn't make a good spec, but also ISTM that a pithy description of REST (or a very useful subset of it) should be feasible. Nico -- From nobody Mon Sep 15 15:02:07 2014 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 889E11A87E9 for ; Mon, 15 Sep 2014 15:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 7tGJeOyWsnFm for ; Mon, 15 Sep 2014 15:02:06 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB591A87AA for ; Mon, 15 Sep 2014 15:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s8FM1uJL016197; Tue, 16 Sep 2014 00:01:56 +0200 (CEST) Received: from [192.168.217.106] (p54890261.dip0.t-ipconnect.de [84.137.2.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D0E49102; Tue, 16 Sep 2014 00:01:55 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Tue, 16 Sep 2014 00:01:54 +0200 X-Mao-Original-Outgoing-Id: 432511314.216888-70ec389f141fcfd607bf9d86db215645 Content-Transfer-Encoding: quoted-printable Message-Id: <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> To: Ira McDonald X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/56_qD4ZEBfPVY0s5wBmVvoNSbzk Cc: dcrocker@bbiw.net, IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 22:02:06 -0000 On 15 Sep 2014, at 23:57, Ira McDonald wrote: > Citing REST, in the absence of=20 > a concise definition, is dubious in any open standard. I don=92t get it. Say, > citing TCP, in the absence of=20 > a concise definition, is dubious in any open standard. wouldn=92t work for me, either. You need to read that RFC, and the others that followed, and the roadmap = RFC, and the bis I-D for that roadmap RFC, etc. (Of course, if we do = any reference for TCP at all, we just reference RFC 793 and act like the = other ones don=92t matter.) Gr=FC=DFe, Carsten From nobody Mon Sep 15 15:16:37 2014 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 EFD471A882A for ; Mon, 15 Sep 2014 15:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CQWipgd0-jY for ; Mon, 15 Sep 2014 15:16:35 -0700 (PDT) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B131A8730 for ; Mon, 15 Sep 2014 15:16:34 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id le20so4131437vcb.18 for ; Mon, 15 Sep 2014 15:16:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xU0pV/nRleWt9cj36QyF3T7Eo3kGyS0wvwMSjvULuYY=; b=WXooWnA4i6/PtlbEtlSepHj6gvzeuYRBeA1WVPb0SR48F8mxAAHsFNsljUwW0SUguZ ml1L2vAIg6egkjb1IlO1c7JrqIrmSeNO5evG4TGMK2FcqgP1SsrXzLoOrB6/reyMSwi7 Cp4vS9bgFUSG/CUikEcjuY0Tl45ENnyPcX2bXl9xMZ9T32xy3PNtc6f2PtRRSgFFgmNO cuj0sVVIiQS3wUjOhkC3e7cHijJc9TDb1SQgJaTU5n5irqbCBfcoUvj7qBRupiVf6Wam lEyVJg993x/7VJ4e6O2p6wH4MtGHL5OfFcL4WCzrOc7SfAyteYvNXH3jYedsQO5JUJjP tUnQ== X-Gm-Message-State: ALoCoQmprk9qo2BtV86kFg9lsneadTjjrOlovOKFVkB2FAtzkw2jDYfbGK6znLXd9MUM/w0SpRzP X-Received: by 10.220.59.138 with SMTP id l10mr4427691vch.59.1410819394056; Mon, 15 Sep 2014 15:16:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.214.4 with HTTP; Mon, 15 Sep 2014 15:16:13 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> From: Tim Bray Date: Mon, 15 Sep 2014 15:16:13 -0700 Message-ID: To: Ira McDonald Content-Type: multipart/alternative; boundary=001a11c25182d36cc9050321fc09 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Bh1irpuNW9l92QbyvGfZSlRMsmI Cc: Dave CROCKER , IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 22:16:37 -0000 --001a11c25182d36cc9050321fc09 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 15, 2014 at 2:57 PM, Ira McDonald wrote: =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > I agree with Dave Crocker's comments. Citing REST, in the absence of > =E2=80=8B=E2=80=8B > a concise definition, is dubious in any open standard. > =E2=80=8BI agree. Asserting RESTfulness can get you into theological argume= nts; for example, people will come after you for insufficient HATEOS-fu. In practice, out there in the industry, RESTful has come to be effectively a synonym for =E2=80=9CEverything is done with HTTP and routed through GET/POST/PUT/DELETE.=E2=80=9D I note that the IETF has excellent reference material to support that kind of assertion in our drafts. =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8B > Cheers, > - Ira > > On Mon, Sep 15, 2014 at 4:31 PM, Dave Crocker wrote: > >> On 9/15/2014 1:31 PM, Carsten Bormann wrote: >> > On 15 Sep 2014, at 22:22, Dave Crocker wrote:>> A >> "definition" is usually relatively short, measured by a few >> >> sentences. >> > >> > Sure, =E2=80=9CREST, short for Representational State Transfer, is an >> > architectural style defined in [REST].=E2=80=9D >> > >> > I doubt one can capture the essence of REST in a few sentences. >> >> >> That's almost certainly a problem. It suggests a poor community >> understanding of its essence. >> >> Given how ingrained the term is and for how long it has been used, the >> problem is probably not a minor one. >> >> d/ >> >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11c25182d36cc9050321fc09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = Mon, Sep 15, 2014 at 2:57 PM, Ira McDonald <blueroofmusic@gmail.com<= /a>> wrote:

=E2=80=8B=E2=80= =8B

- I= ra

On Mon, Sep 15, 2014 at 4:31 PM, Dave = Crocker <dhc@dcrocker.net> wrote:
On 9/15/2014 1:31 PM, Carsten Borma= nn wrote:
> On 15 Sep 2014, at 22:22, Dave Crocker <dhc@dcrocker.net> wrote:>> A "= definition" is usually relatively short, measured by a few
>> sentences.
>
> Sure, =E2=80=9CREST, short for Representational State Transfer, is an<= br> > architectural style defined in [REST].=E2=80=9D
>
> I doubt one can capture the essence of REST in a few sentences.


That's almost certainly a problem.=C2=A0 It suggests a poor comm= unity
understanding of its essence.

Given how ingrained the term is and for how long it has been used, the
problem is probably not a minor one.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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


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




--
- Tim Bray (If you=E2=80=99d like to send me a private messag= e, see https://key= base.io/timbray)
--001a11c25182d36cc9050321fc09-- From nobody Mon Sep 15 15:19:31 2014 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 C28721A8730 for ; Mon, 15 Sep 2014 15:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoLfwGp0McNV for ; Mon, 15 Sep 2014 15:19:22 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DC711A8822 for ; Mon, 15 Sep 2014 15:19:21 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id r10so4819525igi.6 for ; Mon, 15 Sep 2014 15:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wSmqRLjH9g+bXldh7fbCw62PDFySuxplo2Om9dsiZOo=; b=QU4Ki5ic3XkcbHXZvqQiBoiNKj2K1vQHbbv6uOH4LKPxzooRh7/nltPjlh1quTOKCY WNjdB19Nn4F1pbXxfW6xDlm/GEjvh13k1l9qmJujIHO34s1Cf3LdPpKW9E1oiOT+Vfwm xRdp0RTmwT8QhR309sAJxe4AMei/5U6m2834e21gDNss9bFLtDSAEDapWO+WApZmVSvM r/nP4Z9dU5dxwTAPwE+Ujj12Ny0JVdw5akPHm4sE9BEY8YnV5nZRqiwxFzEybn0Qpr+0 eCIfwMLFroQa0VjyyJ4RvJMEVtAOis1OGykQNqzuqBTM+LQ2Y8JLintwc26NY5F7aUJF EtMQ== X-Received: by 10.42.63.129 with SMTP id c1mr5259036ici.82.1410819561385; Mon, 15 Sep 2014 15:19:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.156.67 with HTTP; Mon, 15 Sep 2014 15:19:01 -0700 (PDT) In-Reply-To: <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> From: Ira McDonald Date: Mon, 15 Sep 2014 18:19:01 -0400 Message-ID: To: Carsten Bormann , Ira McDonald Content-Type: multipart/alternative; boundary=90e6ba615458cc75db05032206bd Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/oZjKTv2W3UasCx7Fj9tPymRSghA Cc: dcrocker@bbiw.net, IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 22:19:23 -0000 --90e6ba615458cc75db05032206bd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, Security and computing glossaries do indeed have brief, descriptive definitions of TCP (coupled w/ an RFC 793 backing reference). If REST or RESTful cannot be concisely defined and also no RFC or other public standard extended definition exists, then using the term in IETF standards-track specs is dubious. I liked Tim Bray's further comment a moment ago. Cheers, - Ira On Mon, Sep 15, 2014 at 6:01 PM, Carsten Bormann wrote: > On 15 Sep 2014, at 23:57, Ira McDonald wrote: > > > Citing REST, in the absence of > > a concise definition, is dubious in any open standard. > > I don=E2=80=99t get it. > > Say, > > > citing TCP, in the absence of > > a concise definition, is dubious in any open standard. > > wouldn=E2=80=99t work for me, either. > You need to read that RFC, and the others that followed, and the roadmap > RFC, and the bis I-D for that roadmap RFC, etc. (Of course, if we do any > reference for TCP at all, we just reference RFC 793 and act like the othe= r > ones don=E2=80=99t matter.) > > Gr=C3=BC=C3=9Fe, Carsten > > --90e6ba615458cc75db05032206bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carsten,

Security= and computing glossaries do indeed have brief, descriptive
defini= tions of TCP (coupled w/ an RFC 793 backing reference).

If RES= T or RESTful cannot be concisely defined and also no RFC or
other = public standard extended definition exists, then using the term
in IETF= standards-track specs is dubious.

I liked Tim Bray's= further comment a moment ago.

Cheers,
- Ira


On Mon, Sep 15, 2014 at 6:01 PM, Carsten Bor= mann <cabo@tzi.org> wrote:
On 15 Sep 2014, at 23:57, Ira McDonald <blueroofmusic@gmail.com> wrote:

> Citing REST, in the absence of
> a concise definition, is dubious in any open standard.

I don=E2=80=99t get it.

Say,

> citing TCP, in the absence of
> a concise definition, is dubious in any open standard= .

wouldn=E2=80=99t work for me, either.
You need to read that RFC, and the others that followed, and the roadmap RF= C, and the bis I-D for that roadmap RFC, etc.=C2=A0 (Of course, if we do an= y reference for TCP at all, we just reference RFC 793 and act like the othe= r ones don=E2=80=99t matter.)

Gr=C3=BC=C3=9Fe, Carsten


--90e6ba615458cc75db05032206bd-- From nobody Mon Sep 15 15:36:49 2014 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 756561A87D8 for ; Mon, 15 Sep 2014 15:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.029 X-Spam-Level: X-Spam-Status: No, score=-3.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, 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 8PBEMsFxZfYS for ; Mon, 15 Sep 2014 15:36:46 -0700 (PDT) Received: from nm28-vm4.bullet.mail.gq1.yahoo.com (nm28-vm4.bullet.mail.gq1.yahoo.com [98.136.216.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04531A882B for ; Mon, 15 Sep 2014 15:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1410820605; bh=/06S64iIR4rkYpLCk6VTlNX4Mo5ttTDMreWBllKOs+E=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Gm-Message-State:X-Received:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc:Content-Type:From:Subject; b=UKt0pDPUwxFjEc1/r7OTJSU7XKnhUnS1O4lZKntlXCIFtHdrdLhY2HAxWwrL+bSA/RQrhaZlgohdG8SbhoPXeWosgPt30syGnPdnwj5ydP+t1OwyjcgsJfQ8yN9CLDLg56EC2NDfS6ehbP4DRhZDh5iwbbFhHvLBWDtHKAHLtJ9uJvCeq/EAPrkAAxUKE+j+4jsO+PcNFl6o03ZNkqm4/MRqhqbviYp35jXtH8hzkQ6ZZy3t6l/qDxqC5OHWP4E217bDF6kzvrl3aU3Z1hA/eSCp0kCiJ0TRZyDDiJg4INSFp0JvYY5pS9VZzgzAE6lGoOo5Gf6p/K9rnr2AOwlCQg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=cfOT15MGABScB0Dc7j/MnYnsOPnq79bHrb1CmY/+8+HnY94OVfDwFNbL1YfmA8yePQolEzbcEYAz+XoAHSjgk9tJXZuwSBewMBBhUi3Y4shKhfflEh/N+CHA8QtFe8PB4YDIE67F1uq7CGQdpeuwNAGJUZpUE6UagSTGBAkRSIZyXEuPPh1+JUH8vweubLT6X4BYlwwEMXKx2xv2dscbZA4elcV6VqksDczkh4fp+Mzo1Vfz20N8aMOtQ2UxRpAGhbJhyu/RitHQQx+NnT/XHrWQnxi0x7KOdE8rF0zfzYDqPmfC3QOFvJD8WIZQJDQEO7Mi83WPZL5siSQIA/nZ7g==; Received: from [98.137.12.189] by nm28.bullet.mail.gq1.yahoo.com with NNFMP; 15 Sep 2014 22:36:45 -0000 Received: from [98.136.164.64] by tm10.bullet.mail.gq1.yahoo.com with NNFMP; 15 Sep 2014 22:36:45 -0000 Received: from [127.0.0.1] by smtp226.mail.gq1.yahoo.com with NNFMP; 15 Sep 2014 22:36:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1410820605; bh=/06S64iIR4rkYpLCk6VTlNX4Mo5ttTDMreWBllKOs+E=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Gm-Message-State:X-Received:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=LN1S31kDxkJnDtMsFefDCd0tCGqXxASgOL9P7f3U10oCBgG53IR0f7kbNr0FCT/TfA0v7BJLBWj1zjN7R4ebA4GbVgMP/FVBpCm+vD+URu1R2V5roiGhBvEtv5AODmzS7GYQb1pYb3L4gh0pdJ6XFUyQJO2xrK/X5KijHx6L+Xc= X-Yahoo-Newman-Id: 443424.65446.bm@smtp226.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 6sRsGLwVM1m1gRgmG41OetXLYxqB0VLGXLDjvPCD9oJWx29 4gpWQJIHrjbmuYPpL_kw9rcLyWVhYc4s87gHPGfh8yOVBIEUwH6lj6ftkOgN 0mZsI9uujuJ93qUx0qikVjSPrUWg2e4WMUAe7mqPXDifSEP7FuK9tSw4Pkpk MgRFB1i3.wi0V5d_PWWcumvDNrOBFSDSXQ5MLdOKJKJ5W3PggvpEZdu5Lhqi mFQMiyH6hCxuCxZWFaiuMbW55EzEY4FVrJ.K4BHnPolc3Sh7VGvsM7hAYdAk ciERxJrhjfimExcyTwtr6TDt4b2HhZeNNQD2Sg.7dmlXouJCbkBfGcfmUheU BeTHqIsdyrNP6bxXAz1Z_6ILvxWIfhKaCQBEg8M8P5reUNkgMIe7iy7kKUve HSZSz0xgV8g5OkOt.LjDFAVTN_tUwNpNj3paA0BlHEchfzXSTbC_J6CBBm.4 DNIXm7QzxsbHB9SevyC2Yw6EVbVlaUJ8A_6dhXmu_NXNZrpP4WtMiEjUeIhC 1EvWnGUCcaybaQU69W3NIKRRFNGJpHZvpKm_K1gp5zFhV2lH6Ot0E7grCzn4 dbpiYQOd2jNvar2_.I1RIt9NIqyi7LDs429_NGg4nWUB.fT7iWl4dt_JkZok 8faEa8nkrXrj98L.cqmD5cqi.EZJ6qIGvaWAETkV6r1XGPR1chqEmMrgIaPc jeXoUogZBqee2AcIVs0PmDmTHWd8PmWrcq1nOJDLPNFWHY_8SwIl9xiXYoLK ykXaWaRqOBMETGzks2QoIqUNhDE_eL9VsCi6Oqyw- X-Yahoo-SMTP: i12ABOmswBAkPG1PnjmsmmFRWA-- Received: by mail-la0-f41.google.com with SMTP id s18so5662071lam.14 for ; Mon, 15 Sep 2014 15:36:43 -0700 (PDT) X-Gm-Message-State: ALoCoQkbE2l83mQy0UWwrLsPUyvSo6yhr7+sadL41sMhdbYGDbJkz9AMu5RDWNQ5L9/uujPQkUA5 X-Received: by 10.152.44.230 with SMTP id h6mr31802512lam.51.1410820603165; Mon, 15 Sep 2014 15:36:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.218.8 with HTTP; Mon, 15 Sep 2014 15:36:22 -0700 (PDT) In-Reply-To: References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> From: mike amundsen Date: Mon, 15 Sep 2014 18:36:22 -0400 Message-ID: To: dcrocker@bbiw.net Content-Type: multipart/alternative; boundary=089e0158c3bee4d2b405032244f7 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/KignrQVnTR6lWf8GquOkoBGMta0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 22:36:48 -0000 --089e0158c3bee4d2b405032244f7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > yes, since the dissertation is not *about* REST (REST is the example), > there is no simple definition there. > > i suspect something that combines the first para in Fielding's chapter > 5[0] with the second para in this wiki entry about impressionism[1] would > proly be useful. > > i might take a shot if it's thought useful. would this be a worthwhile > (tiny) Informational RFC? > > > [0] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.ht= m > [1] http://en.wikipedia.org/wiki/Impressionism > > > On Sep 15, 2014 4:31 PM, "Dave Crocker" wrote: > >> On 9/15/2014 1:31 PM, Carsten Bormann wrote: >> > On 15 Sep 2014, at 22:22, Dave Crocker wrote:>> A >> "definition" is usually relatively short, measured by a few >> >> sentences. >> > >> > Sure, =E2=80=9CREST, short for Representational State Transfer, is an >> > architectural style defined in [REST].=E2=80=9D >> > >> > I doubt one can capture the essence of REST in a few sentences. >> >> >> That's almost certainly a problem. It suggests a poor community >> understanding of its essence. >> >> Given how ingrained the term is and for how long it has been used, the >> problem is probably not a minor one. >> >> d/ >> >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > --089e0158c3bee4d2b405032244f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

yes, since the dissertation = is not *about* REST (REST is the example), there is no simple definition th= ere.

i suspect something that combines the first para in Fielding'= ;s chapter 5[0] with the second para in this wiki entry about impressionism= [1] would proly be useful.

i might take a shot if it's thought us= eful. would this be a worthwhile (tiny) Informational RFC?


[0]=C2=A0http://www.ics.uci.edu/~fielding/pubs/d= issertation/rest_arch_style.htm
[1]=C2=A0http://en.wikipedia.org/wiki/= Impressionism


On Sep 15, 2014 4:31 PM, "Dave Crocker"= ; <dhc@dcrocker.ne= t> wrote:
On 9/15/2014 1:31= PM, Carsten Bormann wrote:
> On 15 Sep 2014, at 22:22, Dave Crocker <dhc@dcrocker.net> wrote:>> A "= definition" is usually relatively short, measured by a few
>> sentences.
>
> Sure, =E2=80=9CREST, short for Representational State Transfer, is an<= br> > architectural style defined in [REST].=E2=80=9D
>
> I doubt one can capture the essence of REST in a few sentences.


That's almost certainly a problem.=C2=A0 It suggests a poor community understanding of its essence.

Given how ingrained the term is and for how long it has been used, the
problem is probably not a minor one.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

--089e0158c3bee4d2b405032244f7-- From nobody Mon Sep 15 15:40:29 2014 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 19C091A8845 for ; Mon, 15 Sep 2014 15:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RltIBghlFeE5 for ; Mon, 15 Sep 2014 15:40:19 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4091A8844 for ; Mon, 15 Sep 2014 15:40:19 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8FMeEqd030198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 15 Sep 2014 15:40:17 -0700 Message-ID: <54176A00.3050905@dcrocker.net> Date: Mon, 15 Sep 2014 15:36:48 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Carsten Bormann , Ira McDonald References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> In-Reply-To: <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 15 Sep 2014 15:40:17 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/V7OkGjTXa6aTxzAjtid1nwChM-8 Cc: dcrocker@bbiw.net, IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 22:40:21 -0000 On 9/15/2014 3:01 PM, Carsten Bormann wrote: > On 15 Sep 2014, at 23:57, Ira McDonald wrote: >> citing TCP, in the absence of >> a concise definition, is dubious in any open standard. > > wouldn’t work for me, either. > You need to read that RFC, and the others that followed, and the roadmap RFC, and the bis I-D for that roadmap RFC, etc. (Of course, if we do any reference for TCP at all, we just reference RFC 793 and act like the other ones don’t matter.) I'm not against including a citation; it's relying on an entire book to provide a meaningful definition to the reader that is the problem. Citing TCP is useful as a counter-example, because it permits highlighting some interesting differences. The major difference, IMO, is that TCP is a very specific protocol, whereas REST(ful) is more like a paradigm (or, if it weren't such a dangerous term in the IETF these days, I'd say "pattern".) So it is more conceptual and used to describe a protocol "approach". The more vague the concept, the more important a usefully and concise definition is needed, if we want different people to use the term with any sort of common meaning. It is also true that the essence of TCP can be, and has been, described very concisely, so that it's pretty to understand what it's about without reading the spec.[1][ We need the same thing for REST. d/ [1] I think the second and third sentence in the Wikipedia entrance is just dandy: "TCP provides reliable, ordered and error-checked delivery of a stream of octets between programs running on computers connected to a local area network, intranet or the public Internet. It resides at the transport layer." -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Sep 15 15:52:49 2014 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 527931A87DE for ; Mon, 15 Sep 2014 15:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.253 X-Spam-Level: X-Spam-Status: No, score=-4.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652, 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 A7g-IpV5Ry8Y for ; Mon, 15 Sep 2014 15:52:44 -0700 (PDT) Received: from nerval.la-grange.net (nerval.la-grange.net [128.30.54.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31DF01A87D1 for ; Mon, 15 Sep 2014 15:52:44 -0700 (PDT) Received: from [IPv6:::1] (nerval.la-grange.net [128.30.54.58]) by nerval.la-grange.net (8.14.9/8.14.9) with ESMTP id s8FMqssj048208 for ; Mon, 15 Sep 2014 18:52:56 -0400 (EDT) (envelope-from karl@la-grange.net) X-Authentication-Warning: nerval.la-grange.net: Host nerval.la-grange.net [128.30.54.58] claimed to be [IPv6:::1] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Karl Dubost In-Reply-To: Date: Tue, 16 Sep 2014 07:52:38 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> To: IETF Apps Discuss X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/DVoeSVWoZLhwIJ3jGGNK_mbnedg Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 22:52:46 -0000 Murray, who started this thread, has said he was satisfied:=20 Le 16 sept. 2014 =C3=A0 06:51, Murray S. Kucherawy = a =C3=A9crit : > I saw that one, but I didn't know if that URI is considered permanent = enough to be used as a citation in an RFC. Since there's precedent, I = guess that answers my question. Thanks! So I guess that solves somehow the purpose of this thread? Discussing about creating a definition without knowing the context of it = doesn't really work either.=20 --=20 Karl Dubost =F0=9F=90=84 http://www.la-grange.net/karl/ From nobody Mon Sep 15 15:54:54 2014 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 971D01A87E8 for ; Mon, 15 Sep 2014 15:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iQSV_kwFSnJ for ; Mon, 15 Sep 2014 15:54:51 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA3B31A02D6 for ; Mon, 15 Sep 2014 15:54:51 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8FMslZC030999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 15 Sep 2014 15:54:51 -0700 Message-ID: <54176D6A.2020903@dcrocker.net> Date: Mon, 15 Sep 2014 15:51:22 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Karl Dubost , IETF Apps Discuss References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 15 Sep 2014 15:54:51 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/lznkm6Oro2TWGjCyT7zhUVw3Akw Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 22:54:52 -0000 On 9/15/2014 3:52 PM, Karl Dubost wrote: > Discussing about creating a definition without knowing the context of it doesn't really work either. If the definition of REST(ful) depends upon the context in which the definition is used.... oh boy... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Sep 15 15:58:02 2014 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 DC6681A87E8 for ; Mon, 15 Sep 2014 15:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpSqyAj3FSnC for ; Mon, 15 Sep 2014 15:57:58 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC62D1A02D6 for ; Mon, 15 Sep 2014 15:57:57 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id s18so5721086lam.28 for ; Mon, 15 Sep 2014 15:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BvgcJogJNX0jrPODAky1sKPerRwUthSqWWSBAV3nqn4=; b=e3gnJvUsygDhKv+mxtNfiotApOiLjise0y4zq/GCVHzWT2KRs+pU/KZJuemEmEDPPT lgcjmSdDNy7OCPI7Fezk4KLKK2uNP0qT2BgZvswYskJis/phHJg5r5MsoWFUwd64Gr1A Bo0zXFrkPjRtiKxDi03Ei3XSjbEGG/YjQUxnyElh9h1EJMCEilJ3ocDqgtQCgc85OX8C hgHVn6eOoNBCUvQ14etmDg8jqTZ/8TbpFHP3/NxLtLlYtwMTmzXIi8Wdvvzv4My1TQPn Ri5GjfQX+LQgh1VCF5WKwTvCODuiW5CF0OQ57q1ER8TEEDWZuG/opTNb0DbtERt2+Fcl 5gBw== MIME-Version: 1.0 X-Received: by 10.152.206.35 with SMTP id ll3mr1007499lac.88.1410821876176; Mon, 15 Sep 2014 15:57:56 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Mon, 15 Sep 2014 15:57:56 -0700 (PDT) In-Reply-To: <54176A00.3050905@dcrocker.net> References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> Date: Mon, 15 Sep 2014 15:57:56 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=001a11348914c55c2505032290f7 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/K8WcP0p2pHltpD8y-80KmIOFGr4 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 22:58:00 -0000 --001a11348914c55c2505032290f7 Content-Type: text/plain; charset=UTF-8 On Mon, Sep 15, 2014 at 3:36 PM, Dave Crocker wrote: > It is also true that the essence of TCP can be, and has been, described > very concisely, so that it's pretty to understand what it's about > without reading the spec.[1][ > > We need the same thing for REST. > I asked this question because there's a document in a WG I'm chairing (not this one) that I believe needs such a definition, either included or referenced. I'm happy to push for such a definition to be included in that document, but only if one can be found or generated, such that it has consensus, in fairly short order because we have a timeline to which we're trying to adhere. I'm inclined to do what RFC7252 did in the absence of something else, because it has precedent. On the flipside, if such a definition could be generated that's satisfactory to this community, then the document could include that, and future IETF work could conveniently reference it. Another option would be to create an RFC including such a definition that could then be cited by other future work, but that seems like a lot of process just to write down a definition for something. At least that would decouple it from that other WG's strict timeline. -MSK --001a11348914c55c2505032290f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 15, 2014 at 3:36 PM, Dave Crocker <dhc@dcrocke= r.net> wrote:
It is also true that the essence o= f TCP can be, and has been, described
very concisely, so that it's pretty to understand what it's about without reading the spec.[1][

We need the same thing for REST.

I aske= d this question because there's a document in a WG I'm chairing (no= t this one) that I believe needs such a definition, either included or refe= renced.=C2=A0 I'm happy to push for such a definition to be included in= that document, but only if one can be found or generated, such that it has= consensus, in fairly short order because we have a timeline to which we= 9;re trying to adhere.

I'm inclined to do what RFC725= 2 did in the absence of something else, because it has precedent.=C2=A0 On = the flipside, if such a definition could be generated that's satisfacto= ry to this community, then the document could include that, and future IETF= work could conveniently reference it.

Another option wou= ld be to create an RFC including such a definition that could then be cited= by other future work, but that seems like a lot of process just to write d= own a definition for something.=C2=A0 At least that would decouple it from = that other WG's strict timeline.

-MSK
=
--001a11348914c55c2505032290f7-- From nobody Mon Sep 15 16:05:49 2014 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 17D921A885C for ; Mon, 15 Sep 2014 16:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.253 X-Spam-Level: X-Spam-Status: No, score=-4.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652, 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 ksvH3eXSTHhS for ; Mon, 15 Sep 2014 16:05:45 -0700 (PDT) Received: from nerval.la-grange.net (nerval.la-grange.net [128.30.54.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29181A885A for ; Mon, 15 Sep 2014 16:05:44 -0700 (PDT) Received: from [IPv6:::1] (nerval.la-grange.net [128.30.54.58]) by nerval.la-grange.net (8.14.9/8.14.9) with ESMTP id s8FN5gNm048473; Mon, 15 Sep 2014 19:05:46 -0400 (EDT) (envelope-from karl@la-grange.net) X-Authentication-Warning: nerval.la-grange.net: Host nerval.la-grange.net [128.30.54.58] claimed to be [IPv6:::1] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Karl Dubost In-Reply-To: <54176D6A.2020903@dcrocker.net> Date: Tue, 16 Sep 2014 08:05:26 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54176D6A.2020903@dcrocker.net> To: dcrocker@bbiw.net, Dave Crocker X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/19JG7ftoIGVSMSJkPQoIDHluDwU Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 23:05:46 -0000 Le 16 sept. 2014 =C3=A0 07:51, Dave Crocker a =C3=A9cri= t : > If the definition of REST(ful) depends upon the context in which the > definition is used.... oh boy=E2=80=A6 * cow: (verb) to intimidate * cow: (noun) a fully grown female animal of a domesticated breed of ox * cow: (noun) a domestic bovine animal, regardless of sex or age. * cow: (noun) include here derogatory meaning * cow: (culture) symbol used in many religions for representing gods. * cow: (culture) animal which has been banned for consumptions in some = populations. There are many ways of looking at one word. REST is exactly a good = example of that from Roy's thesis to the multiple usage and = understanding by different communities. :) --=20 Karl Dubost =F0=9F=90=84 http://www.la-grange.net/karl/ From nobody Mon Sep 15 17:23:41 2014 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 9639D1A0071; Mon, 15 Sep 2014 17:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.554 X-Spam-Level: X-Spam-Status: No, score=-108.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgkxUNHAFGHD; Mon, 15 Sep 2014 17:23:36 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id CB7FD1A0087; Mon, 15 Sep 2014 17:23:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id EAA50182539; Mon, 15 Sep 2014 17:23:05 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140916002305.EAA50182539@rfc-editor.org> Date: Mon, 15 Sep 2014 17:23:05 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XczsXJN1Kk7YBkAow79pfYmaeKM Cc: drafts-update-ref@iana.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] RFC 7352 on Sieve Email Filtering: Detecting Duplicate Deliveries 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, 16 Sep 2014 00:23:38 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7352 Title: Sieve Email Filtering: Detecting Duplicate Deliveries Author: S. Bosch Status: Standards Track Stream: IETF Date: September 2014 Mailbox: stephan@rename-it.nl Pages: 15 Characters: 31191 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-appsawg-sieve-duplicate-09.txt URL: https://www.rfc-editor.org/rfc/rfc7352.txt This document defines a new test command, "duplicate", for the Sieve email filtering language. This test adds the ability to detect duplications. The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages. For more complex applications, the "duplicate" test can also use the content of a specific header field or other parts of the message. This document is a product of the Applications Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Sep 15 17:24:11 2014 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 2DDCE1A00E1; Mon, 15 Sep 2014 17:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.554 X-Spam-Level: X-Spam-Status: No, score=-108.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqWAPCBm1OdX; Mon, 15 Sep 2014 17:23:59 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACED1A00B0; Mon, 15 Sep 2014 17:23:59 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 94DDC182539; Mon, 15 Sep 2014 17:23:28 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140916002328.94DDC182539@rfc-editor.org> Date: Mon, 15 Sep 2014 17:23:28 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/iCRHLTl_hBPkdG-YtSKPP4KKIgc Cc: drafts-update-ref@iana.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] RFC 7372 on Email Authentication Status Codes 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, 16 Sep 2014 00:24:01 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7372 Title: Email Authentication Status Codes Author: M. Kucherawy Status: Standards Track Stream: IETF Date: September 2014 Mailbox: superuser@gmail.com Pages: 8 Characters: 14224 Updates: RFC 7208 I-D Tag: draft-ietf-appsawg-email-auth-codes-07.txt URL: https://www.rfc-editor.org/rfc/rfc7372.txt This document registers code points to allow status codes to be returned to an email client to indicate that a message is being rejected or deferred specifically because of email authentication failures. This document updates RFC 7208, since some of the code points registered replace the ones recommended for use in that document. This document is a product of the Applications Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Sep 15 22:48:01 2014 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 9D1ED1A02D0 for ; Mon, 15 Sep 2014 22:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Y36PYJUjxY8l for ; Mon, 15 Sep 2014 22:47:59 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2FB1A02C1 for ; Mon, 15 Sep 2014 22:47:59 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8396E509B5 for ; Tue, 16 Sep 2014 01:47:58 -0400 (EDT) Message-ID: <5417CF14.7040206@seantek.com> Date: Mon, 15 Sep 2014 22:48:04 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> In-Reply-To: <54136795.2070500@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/1BqP8QSHaOQJnYUm4MTvI62UZmg Subject: [apps-discuss] Request additional reviewer for Markdown 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, 16 Sep 2014 05:48:00 -0000 Hi all, Looks like I have the required 5 reviewers for the Markdown draft.=20 However the reviewer set is starting to skew more heavily to non-IETFers = than IETFers, as I assembled a set of reviewers from around the Markdown = community (including developers of Markdown tools, and users in=20 industry-specific domains). It would be nice if the draft could have one = additional reviewer who has more experience in the IETF, particularly=20 relating to media types and protocol issues associated with them. Any=20 takers? Thanks, Sean From nobody Mon Sep 15 23:04:47 2014 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 139A71A02E6; Mon, 15 Sep 2014 23:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 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, RP_MATCHES_RCVD=-1.652, 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 oKyeJwwrV3Nv; Mon, 15 Sep 2014 23:04:38 -0700 (PDT) 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 F33AA1A02E4; Mon, 15 Sep 2014 23:04:37 -0700 (PDT) Received: internal info suppressed Date: Tue, 16 Sep 2014 08:04:17 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: Sean Leonard In-Reply-To: <5417CF14.7040206@seantek.com> Message-ID: References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) 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=1410847476; bh=TqPgcyG6wEMtMcFd5PaRyoA1QsnuOdsy0v3DR7KZfFM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=jd5beDWssxY8adzuzHjQDNU7iY8el5BNkFiusLTwFO0+DNtlhCPQmx0pwBBR3p4bb 6w+SLpoINVLmy2zODvJmlwlRVSlMtCFaZzCtanHwGxIfGTnGPTqeGb2gtajeocqy+C r4N7DDM6IGntOEOnIIu4ZED5bMbKAqIjbC15d5x4= Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/o4455PRwBqOowIS_R15IYYDZEGo Cc: appsdir@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Request additional reviewer for Markdown 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, 16 Sep 2014 06:04:40 -0000 On Mon, 15 Sep 2014, Sean Leonard wrote: > Hi all, > > Looks like I have the required 5 reviewers for the Markdown draft. However > the reviewer set is starting to skew more heavily to non-IETFers than > IETFers, as I assembled a set of reviewers from around the Markdown community > (including developers of Markdown tools, and users in industry-specific > domains). It would be nice if the draft could have one additional reviewer > who has more experience in the IETF, particularly relating to media types and > protocol issues associated with them. Any takers? Hello Sean, we can ask the APSDIR for a review... to hich draft are you explicitly referring to? draft-ietf-appsawg-text-markdown-01.txt draft-seantek-text-markdown-00.txt both? > > Thanks, > > Sean > > _______________________________________________ > 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; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Mon Sep 15 23:15:21 2014 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 316E31A02EF; Mon, 15 Sep 2014 23:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 i88grJ131OGC; Mon, 15 Sep 2014 23:15:18 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01D331A02C1; Mon, 15 Sep 2014 23:15:17 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 18067509B5; Tue, 16 Sep 2014 02:15:15 -0400 (EDT) Message-ID: <5417D579.3010900@seantek.com> Date: Mon, 15 Sep 2014 23:15:21 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Claudio Allocchio References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/KPQg5Ulz-oqkmJrzwjA4Fn6BDBE Cc: appsdir@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Request additional reviewer for Markdown 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, 16 Sep 2014 06:15:19 -0000 On 9/15/2014 11:04 PM, Claudio Allocchio wrote: > > On Mon, 15 Sep 2014, Sean Leonard wrote: > >> Hi all, >> >> Looks like I have the required 5 reviewers for the Markdown draft. >> However the reviewer set is starting to skew more heavily to >> non-IETFers than IETFers, as I assembled a set of reviewers from >> around the Markdown community (including developers of Markdown >> tools, and users in industry-specific domains). It would be nice if >> the draft could have one additional reviewer who has more experience >> in the IETF, particularly relating to media types and protocol issues >> associated with them. Any takers? > > Hello Sean, > > we can ask the APSDIR for a review... > > to hich draft are you explicitly referring to? > > draft-ietf-appsawg-text-markdown-01.txt > draft-seantek-text-markdown-00.txt draft-ietf-appsawg-text-markdown-01.txt -Sean From nobody Mon Sep 15 23:27:13 2014 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 EF5761A030B for ; Mon, 15 Sep 2014 23:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 qWS5ji06S4BQ for ; Mon, 15 Sep 2014 23:27:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C771A0309 for ; Mon, 15 Sep 2014 23:27:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMQ59006; Tue, 16 Sep 2014 06:27:04 +0000 (GMT) Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 16 Sep 2014 07:27:03 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Tue, 16 Sep 2014 14:26:59 +0800 From: Bert Greevenbosch To: "apps-discuss@ietf.org" Thread-Topic: Upload of CDDL draft v03: draft-greevenbosch-appsawg-cbor-cddl-03 Thread-Index: Ac/RdzdHLfR5OobVRwSOKmAOqYys/g== Date: Tue, 16 Sep 2014 06:26:58 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63E74D7B8@SZXEMA510-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: multipart/alternative; boundary="_000_46A1DF3F04371240B504290A071B4DB63E74D7B8SZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Yn6FTk2GnjdqiiQsaTggbvm3RCQ Subject: [apps-discuss] Upload of CDDL draft v03: draft-greevenbosch-appsawg-cbor-cddl-03 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, 16 Sep 2014 06:27:09 -0000 --_000_46A1DF3F04371240B504290A071B4DB63E74D7B8SZXEMA510MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, We have updated the CBOR Data Description Language (CDDL) draft. It is ava= ilable under the following link: https://datatracker.ietf.org/doc/draft-greevenbosch-appsawg-cbor-cddl The changes since v02 are as follows: * Added information about characters used in names * Added text about an overall data structure and the order of the d= efinitions of the fields * Added text about encoding of keys * Added table with keywords * Added strings and integer writing conventions * Added an ABNF description of CDDL Christoph Vigano is now co-author. He made several changes/simplifications = based on his implementation experience. We look forward to your questions and remarks! Best regards, Bert --_000_46A1DF3F04371240B504290A071B4DB63E74D7B8SZXEMA510MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

We have updated the CBOR Data Description  Lang= uage (CDDL) draft. It is available under the following link:

 

https://datatracker.ietf.org/doc/draft-greeve= nbosch-appsawg-cbor-cddl

 

The changes since v02 are as follows:

 

·         Added information about characters used in n= ames

·         Added text about an overall data structure a= nd the order of the definitions of the fields

·         Added text about encoding of keys=

·         Added table with keywords

·         Added strings and integer writing convention= s

·         Added an ABNF description of CDDL=

 

Christoph Vigano is now co-author. He made several c= hanges/simplifications based on his implementation experience.

 

We look forward to your questions and remarks!<= /o:p>

 

Best regards,

Bert

 

--_000_46A1DF3F04371240B504290A071B4DB63E74D7B8SZXEMA510MBXchi_-- From nobody Tue Sep 16 03:32:00 2014 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 563491A01F3 for ; Tue, 16 Sep 2014 03:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OHGsN85HH2H for ; Tue, 16 Sep 2014 03:31:55 -0700 (PDT) Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) by ietfa.amsl.com (Postfix) with ESMTP id 364531A0484 for ; Tue, 16 Sep 2014 03:31:55 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1XTq37-00053k-cZ; Tue, 16 Sep 2014 11:31:53 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1XTq37-0000jz-1W; Tue, 16 Sep 2014 11:31:53 +0100 Message-ID: <54181186.4030507@ninebynine.org> Date: Tue, 16 Sep 2014 11:31:34 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sean Leonard , "apps-discuss@ietf.org" References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> In-Reply-To: <5417D579.3010900@seantek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/5QrPMFMHdSjarezcxM3Jo_NxkRc Subject: Re: [apps-discuss] Request additional reviewer for Markdown 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, 16 Sep 2014 10:31:57 -0000 On 16/09/2014 07:15, Sean Leonard wrote: > draft-ietf-appsawg-text-markdown-01.txt Reviewing https://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-01 # 1. Introduction First para (Nit): This seems a bit bloated. I don't think anything relevant is lost by deleting from "Compare with [RFC6838] Section 4.2.1." to the end of the paragraph. Para starting "Markdown specifically is a family of syntaxes..." (nit): I would be inclined to remove the text "Fed up with the complexity and security pitfalls of formal markup languages (e.g., HTML5) and proprietary binary formats (e.g., commercial word processing software), yet unwilling to be confined to the restrictions of plain text," and leave just "Many users have turned to Markdown for document processing" # 2. Markdown Media Type Registration Applications General: I have my doubts about creating a registry of processors. Could the required information for interoperability not be captured by capturing the processor capabilities as rules? For comparison, consider the example of HTTP feature negotiation (type, language, encoding, etc.) vs UA string testing and/or user-agent sniffing, which is frequently regarded as a poor way to do content matching. This specification appears to be blessing an approach analogous to UA string testing. Maybe this was discussed and I missed it? The description of "processor-args" seems odd to me - it seems to tie the media type string to a particular form of implementation (posix commands). Would it not be more flexible to use some kind of attribute/value list (e.g. similar to media type parameters themselves), and let the application turn them into command line options or environment variables or whatever is needed? (As you plan to allow references to web resources here, maybe use something like encoded JSON, which can be a common representation for direct or indirect values?) I think such an approach could also sidestep some of the unresolved security concerns in the draft (e.g. [[TODO: discuss the implications of processor-args, and safeguards.]], etc.) Para "Interoperability considerations": Contains the text: "When it is desirable to reflect the author's intent in the output, stick with the flavor identified in the flavor parameter." What is this "flavor" parameter? I'm not seeing it. [later: looks like left over from a previous incarnation - maybe worth a global search for changed names?] # 4. IANA Considerations Is it really necessary to have "expert review" for these registries? That requires a volunteer and may impose some additional overhead on IANA. Would "First come first served" not work here? What are the requirements for updating a registry entry? I'd suggest including an "escape" clause that allows IESG or an IETF-stream RFC to update any entry. (I'd trust the community to not do this capriciously). Rather than reserve some names for future use, why not just pre-register them (even if the descriptions are vague for now, allowing that they can be updated later)? #g From nobody Tue Sep 16 07:11:05 2014 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 D48F01A0347 for ; Tue, 16 Sep 2014 07:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqmN3ZURNaxd for ; Tue, 16 Sep 2014 07:10:38 -0700 (PDT) Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA281A0342 for ; Tue, 16 Sep 2014 07:10:32 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1XTtSi-0003RW-aP for apps-discuss@ietf.org; Tue, 16 Sep 2014 15:10:32 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1XTtSh-0005a1-2Y for apps-discuss@ietf.org; Tue, 16 Sep 2014 15:10:31 +0100 Message-ID: <541844C3.2030200@ninebynine.org> Date: Tue, 16 Sep 2014 15:10:11 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> <54181186.4030507@ninebynine.org> In-Reply-To: <54181186.4030507@ninebynine.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JiZkFGJsKiHR4_sUR4vK_R28mXM Subject: Re: [apps-discuss] Request additional reviewer for Markdown 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, 16 Sep 2014 14:10:47 -0000 Further to my previous review, I just noticed another thing. The draft indicates it is intended to be informational. Is it allowed in IETF process for an informational RFC to create an IANA registry? I don't know, just asking. (I usually associate such actions with standards track or BCP documents.) Now that I've had a little time to reflect on this, Ill say: 1. That I think it's a reasonable idea to define this media type, and that the broad approach is OK, but ... 2. I think the spec could do with some trimming and polishing, and 3. I'd prefer to see the 'processor' and 'processor-args' parameters dropped completely, and focus on creating a tabulation of rules to capture information about the varieties of Markdown that are actually used. (And a thought: rather than requiring the rule definitions to resolve any potential conflicts between themselves, have a simple left-to-right processing of parameters such that where there is a conflict, parameters appearing later in the list override earlier ones. That would provide a well-defined way to say something like "github flavoured markdown, except that newlines are not rendered as line breaks in the output".) #g -- On 16/09/2014 11:31, Graham Klyne wrote: > On 16/09/2014 07:15, Sean Leonard wrote: >> draft-ietf-appsawg-text-markdown-01.txt > > Reviewing https://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-01 > > > # 1. Introduction > > First para (Nit): > > This seems a bit bloated. I don't think anything relevant is lost by deleting > from "Compare with [RFC6838] Section 4.2.1." to the end of the paragraph. > > > Para starting "Markdown specifically is a family of syntaxes..." (nit): > > I would be inclined to remove the text > > "Fed > up with the complexity and security pitfalls of formal markup > languages (e.g., HTML5) and proprietary binary formats (e.g., > commercial word processing software), yet unwilling to be confined to > the restrictions of plain text," > > and leave just "Many users have turned to Markdown for document processing" > > > # 2. Markdown Media Type Registration Applications > > > General: > > I have my doubts about creating a registry of processors. Could the required > information for interoperability not be captured by capturing the processor > capabilities as rules? > > For comparison, consider the example of HTTP feature negotiation (type, > language, encoding, etc.) vs UA string testing and/or user-agent sniffing, which > is frequently regarded as a poor way to do content matching. This specification > appears to be blessing an approach analogous to UA string testing. > > Maybe this was discussed and I missed it? > > > The description of "processor-args" seems odd to me - it seems to tie the media > type string to a particular form of implementation (posix commands). Would it > not be more flexible to use some kind of attribute/value list (e.g. similar to > media type parameters themselves), and let the application turn them into > command line options or environment variables or whatever is needed? (As you > plan to allow references to web resources here, maybe use something like encoded > JSON, which can be a common representation for direct or indirect values?) > > I think such an approach could also sidestep some of the unresolved security > concerns in the draft (e.g. [[TODO: discuss the implications of processor-args, > and safeguards.]], etc.) > > > Para "Interoperability considerations": > > Contains the text: "When it is desirable to reflect the author's intent in the > output, stick with the flavor identified in the flavor parameter." What is this > "flavor" parameter? I'm not seeing it. > > [later: looks like left over from a previous incarnation - maybe worth a global > search for changed names?] > > > # 4. IANA Considerations > > Is it really necessary to have "expert review" for these registries? That > requires a volunteer and may impose some additional overhead on IANA. Would > "First come first served" not work here? > > What are the requirements for updating a registry entry? I'd suggest including > an "escape" clause that allows IESG or an IETF-stream RFC to update any entry. > (I'd trust the community to not do this capriciously). > > Rather than reserve some names for future use, why not just pre-register them > (even if the descriptions are vague for now, allowing that they can be updated > later)? > > #g > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Tue Sep 16 07:43:16 2014 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 406521A071C for ; Tue, 16 Sep 2014 07:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fiKOS64FSlw for ; Tue, 16 Sep 2014 07:43:14 -0700 (PDT) Received: from nrcan.gc.ca (s-bsc-edge1.nrcan.gc.ca [132.156.238.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE7681A0515 for ; Tue, 16 Sep 2014 07:43:13 -0700 (PDT) Received: from S-BSC-CAS2.nrn.nrcan.gc.ca (132.156.238.12) by S-BSC-EDGE1.nrcan.gc.ca (132.156.238.13) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 16 Sep 2014 10:43:12 -0400 Received: from S-BSC-MBX1.nrn.nrcan.gc.ca ([169.254.1.242]) by S-BSC-CAS2.nrn.nrcan.gc.ca ([fe80::48d4:f168:78ba:d4e8%19]) with mapi id 14.03.0123.003; Tue, 16 Sep 2014 10:43:12 -0400 From: "Rushforth, Peter" To: IETF Apps Discuss Thread-Topic: [apps-discuss] RESTful definition Thread-Index: AQHP0SHjtrg1+xrzGUuUQjHFbblP95wC5RsAgAAaFYCAABEYAP///6YAgAAD7gCAAMA80A== Date: Tue, 16 Sep 2014 14:43:11 +0000 Message-ID: <1CD55F04538DEA4F85F3ADF7745464AF24C4C7B1@S-BSC-MBX1.nrn.nrcan.gc.ca> References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54176D6A.2020903@dcrocker.net> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.156.238.22] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/q4DDyHKX2oYQJ9I1eVPZxF0wP5Y Subject: Re: [apps-discuss] RESTful definition 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, 16 Sep 2014 14:43:16 -0000 SGksDQoNCkFsdGhvdWdoIHRoZXJlIGFyZSBtYW55IG92ZXJsb2FkZWQgd29yZHMgaW4gbGFuZ3Vh Z2UsIFJFU1QgaGFzIGJlZW4gdW5kZXJsb2FkZWQsIGluIHRoZSBzZW5zZSB0aGF0IHRoZQ0Kc29t ZSBvZiB0aGUgaW1wb3J0YW50IHF1YWxpdGllcyB0aGF0IHRoZSB0ZXJtIHdhcyBjb2luZWQgdG8g ZGVzY3JpYmUgYW5kIGV2b2tlIGhhdmUgYmVlbiBkaXNjYXJkZWQgYnkgDQpjb21tb24gdXNhZ2Uu ICAgIFBlcmhhcHMgSEFURU9BUyBpcyAqdGhlIG1vc3QqIGltcG9ydGFudCBzdWNoIHF1YWxpdHks IGFzIGl0IGZvcm1zIHRoZSBiYXNpcyBvZiB0aGUgc3RhbmRhcmQNCldlYiwgd2hpY2ggY3VycmVu dGx5IHNlcGFyYXRlcyB1cyBmcm9tIHBsYXRmb3JtaWZpY2F0aW9uIG9yIHdoYXQgaGF2ZSB5b3Uu DQoNClJGQyBhdXRob3JzIHdvdWxkIGJlbmVmaXQgZnJvbSBhbiBSRkMgZm9yIFJFU1QsIElNSE8u ICBBdCBsZWFzdCBpdCBjb3VsZCBiZSB1c2VmdWwgYXMgYSBzdGljayB0byBiZWF0IHRob3NlIG9y Z2FuaXphdGlvbnMgd2hpY2gNCm9taXQgSEFURU9BUyBmcm9tIHRoZWlyIGRlZmluaXRpb24gb2Yg UkVTVC4gICBTaW1pbGFyIHRvIHRoZSB1dGlsaXR5IG9mIFJGQyA3MzIwLg0KDQpSZWdhcmRzLA0K UGV0ZXIgUnVzaGZvcnRoDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBhcHBz LWRpc2N1c3MgW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEthcmwgRHVib3N0DQpTZW50OiBTZXB0ZW1iZXIgMTUsIDIwMTQgMTk6MDUNClRvOiBkY3Jv Y2tlckBiYml3Lm5ldDsgRGF2ZSBDcm9ja2VyDQpDYzogSUVURiBBcHBzIERpc2N1c3MNClN1Ympl Y3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBSRVNUZnVsIGRlZmluaXRpb24NCg0KDQpMZSAxNiBzZXB0 LiAyMDE0IMOgIDA3OjUxLCBEYXZlIENyb2NrZXIgPGRoY0BkY3JvY2tlci5uZXQ+IGEgw6ljcml0 IDoNCj4gSWYgdGhlIGRlZmluaXRpb24gb2YgUkVTVChmdWwpIGRlcGVuZHMgdXBvbiB0aGUgY29u dGV4dCBpbiB3aGljaCB0aGUgDQo+IGRlZmluaXRpb24gaXMgdXNlZC4uLi4gb2ggYm954oCmDQoN CiogY293OiAodmVyYikgdG8gaW50aW1pZGF0ZQ0KKiBjb3c6IChub3VuKSBhIGZ1bGx5IGdyb3du IGZlbWFsZSBhbmltYWwgb2YgYSBkb21lc3RpY2F0ZWQgYnJlZWQgb2Ygb3gNCiogY293OiAobm91 bikgYSBkb21lc3RpYyBib3ZpbmUgYW5pbWFsLCByZWdhcmRsZXNzIG9mIHNleCBvciBhZ2UuDQoq IGNvdzogKG5vdW4pIGluY2x1ZGUgaGVyZSBkZXJvZ2F0b3J5IG1lYW5pbmcNCiogY293OiAoY3Vs dHVyZSkgc3ltYm9sIHVzZWQgaW4gbWFueSByZWxpZ2lvbnMgZm9yIHJlcHJlc2VudGluZyBnb2Rz Lg0KKiBjb3c6IChjdWx0dXJlKSBhbmltYWwgd2hpY2ggaGFzIGJlZW4gYmFubmVkIGZvciBjb25z dW1wdGlvbnMgaW4gc29tZSBwb3B1bGF0aW9ucy4NCg0KVGhlcmUgYXJlIG1hbnkgd2F5cyBvZiBs b29raW5nIGF0IG9uZSB3b3JkLiBSRVNUIGlzIGV4YWN0bHkgYSBnb29kIGV4YW1wbGUgb2YgdGhh dCBmcm9tIFJveSdzIHRoZXNpcyB0byB0aGUgbXVsdGlwbGUgdXNhZ2UgYW5kIHVuZGVyc3RhbmRp bmcgYnkgZGlmZmVyZW50IGNvbW11bml0aWVzLiA6KQ0KDQoNCi0tDQpLYXJsIER1Ym9zdCDwn5CE DQpodHRwOi8vd3d3LmxhLWdyYW5nZS5uZXQva2FybC8NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCmFwcHMtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCmFw cHMtZGlzY3Vzc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9hcHBzLWRpc2N1c3MNCg== From nobody Tue Sep 16 07:49:28 2014 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 26EA81A0656 for ; Tue, 16 Sep 2014 07:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1gLsCSYWdCz for ; Tue, 16 Sep 2014 07:49:26 -0700 (PDT) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F100E1A0356 for ; Tue, 16 Sep 2014 07:49:25 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id g10so8704715pdj.38 for ; Tue, 16 Sep 2014 07:49:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=obnEXVgXXrFFkkUtR+uVGKNpShAU2VXFnEbipGkfEyc=; b=egnoGk20LgUi0IVgLH/qt5E3t72KH24kpoWo53vVo8IJBuTIqz9/wgGonwv9JCsxPj lgkLW6awFXJ/3Ncm41ZbiKJZKzQZp7cBacSVO3bd4KYeKfd7PmRY+1k9XSP47Un6RXCj Zv0VTpCq/PJ6GBVz3/Bmg2KnlRMgNzD8PEy1uNrOnAJz0oYyTsMs9SOaWUfWL5hnqk9z UlWMvxNKvkB5h9YoWEP3LhKxyI5QcovCvJD62Bd3cn9YZd67g/2lmhqV8520s026irz8 jRZZIBqCtGIB9nsA/d7Bd40OeYELiaCkSEb5g4nYJt2sStkxAqwDg4dG4ySV+TGs5SQQ 4xXA== X-Gm-Message-State: ALoCoQn3FNwxA+4a1B75kIRpIKNsRN95+SNnm1o/zbPyUlKt9DdycSJScB8ZI8vKJHAsLAEFVl7G MIME-Version: 1.0 X-Received: by 10.66.100.231 with SMTP id fb7mr16436239pab.147.1410878965501; Tue, 16 Sep 2014 07:49:25 -0700 (PDT) Sender: mark@coactus.com Received: by 10.70.138.45 with HTTP; Tue, 16 Sep 2014 07:49:25 -0700 (PDT) X-Originating-IP: [192.0.216.13] In-Reply-To: <54174A83.2020704@dcrocker.net> References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> Date: Tue, 16 Sep 2014 10:49:25 -0400 X-Google-Sender-Auth: gYaOMKCXRDFcvwrwiYzhRz9T-Mc Message-ID: From: Mark Baker To: Dave Crocker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/O_3krDe2F2uZuNyfiVw2kRjdJQI Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RESTful definition 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, 16 Sep 2014 14:49:27 -0000 On Sep 15, 2014 4:26 PM, "Dave Crocker" wrote: > > On 9/15/2014 1:18 PM, Carsten Bormann wrote: > > On 15 Sep 2014, at 22:15, Murray S. Kucherawy wro= te: > > > >> Is there a sufficiently stable definition for "REST" or "RESTful" we c= an reference from a future RFC? I can't think of anything authoritative, > > > > What=E2=80=99s wrong with Roy Fielding=E2=80=99s dissertation? > > For RFC 7252, we used: > > > > A "definition" is usually relatively short, measured by a few sentences. > > An entire book is rather too long to qualify. It's really only chapter 5 that defines REST, with the preceding chapters defining terms and concepts that enable chapter 5. If those terms and concepts were themselves commonly used in IETF circles, I'd suggest referencing chapter 5 directly, but they aren't so I see no problem referencing the whole dissertation. tl;dr RTFM From nobody Tue Sep 16 07:52:10 2014 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 9CB7C1A0714 for ; Tue, 16 Sep 2014 07:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aryWzBNsnim8 for ; Tue, 16 Sep 2014 07:52:08 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F631A0357 for ; Tue, 16 Sep 2014 07:52:08 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8GEq4XU019077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 Sep 2014 07:52:07 -0700 Message-ID: <54184E92.7050407@dcrocker.net> Date: Tue, 16 Sep 2014 07:52:02 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mark Baker References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 16 Sep 2014 07:52:07 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_XyNmeXh-2X2LsAAPoacnZRZ10g Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 14:52:09 -0000 On 9/16/2014 7:49 AM, Mark Baker wrote: > It's really only chapter 5 that defines REST, with the preceding > chapters defining terms and concepts that enable chapter 5. If those > terms and concepts were themselves commonly used in IETF circles, I'd > suggest referencing chapter 5 directly, but they aren't so I see no > problem referencing the whole dissertation. Other than the fact that it's useless? Citing only an entire volume, as a means of defining a concept, vastly raises the barrier to utility of the document making the citation. It also tends to indicate a community failure to develop a shared understanding of the construct. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Sep 16 08:02:05 2014 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 8C0531A068A for ; Tue, 16 Sep 2014 08:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 dEr9a_jlQZVl for ; Tue, 16 Sep 2014 08:02:00 -0700 (PDT) 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 8D6701A0656 for ; Tue, 16 Sep 2014 08:02:00 -0700 (PDT) Received: from [73.189.85.237] (helo=dretpro.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1XTuGQ-0004lT-BZ; Tue, 16 Sep 2014 08:02:00 -0700 Message-ID: <541850DB.1050705@berkeley.edu> Date: Tue, 16 Sep 2014 08:01:47 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Rushforth, Peter" , IETF Apps Discuss References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54176D6A.2020903@dcrocker.net> <1CD55F04538DEA4F85F3ADF7745464AF24C4C7B1@S-BSC-MBX1.nrn.nrcan.gc.ca> In-Reply-To: <1CD55F04538DEA4F85F3ADF7745464AF24C4C7B1@S-BSC-MBX1.nrn.nrcan.gc.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/OR7mHSPirDK0SfSffr4i5TDlMQk Subject: Re: [apps-discuss] RESTful definition 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, 16 Sep 2014 15:02:03 -0000 hello. having spent considerable time and energy in the REST space, i think it would be great if the IETF had some minimal guidance on what it is, why it matters, and what people might want to consider when trying to be RESTful. there are two extremes: - one is to be pure and insist on the fact that REST is not a technology, but an architectural style. this is "correct", but most people think this is not very helpful. - tim bray's pragmatic view that anything using HTTP these days is being sold as RESTful. this is a bit sad, but this is how it is. a useful definition would be in between. focusing on actual technologies, but still making explicit statements about the things that matter for being RESTful. On 2014-09-16, 7:43 , Rushforth, Peter wrote: > Although there are many overloaded words in language, REST has been underloaded, in the sense that the > some of the important qualities that the term was coined to describe and evoke have been discarded by > common usage. Perhaps HATEOAS is *the most* important such quality, as it forms the basis of the standard > Web, which currently separates us from platformification or what have you. REST really does not define that many constraints, and hypermedia is an important one. at least highlighting that (even if people often choose to ignore it) might be helpful to some. in my experience, people that just want to call something "REST" because it's hip or sells better will not care about descriptions or guidelines anyway. they just want the branding. but there also are many who are a bit confused by "The Definition" (it's not a technology, it's an architectural style) and the use of the term out in the wild. those people might be served very well with a concise document that makes some simple statements about what matters most. cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From nobody Tue Sep 16 08:40:37 2014 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 5B4801A0721 for ; Tue, 16 Sep 2014 08:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOofUKBefBKD for ; Tue, 16 Sep 2014 08:40:32 -0700 (PDT) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 635BC1A0366 for ; Tue, 16 Sep 2014 08:40:32 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lj1so25998pab.29 for ; Tue, 16 Sep 2014 08:40:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Dks4Ah0lWxlAtBhbPv0tKxRgFjvRIRYu81HDmZo/4NY=; b=Ey4mKSAdxJJwyFgNkUApPK8f68RmYGpHhrwTvmbON4a3V5t6WMgIBghcGblZsbfd46 +OGs2Zm+O1sb1NI7f5o1mHw6efIyZq1dkYxi8smx+7f2Ct4zkAh+KFT9iG5sH4jeYU9T ZYu1/yz3E26ggDniTa/YQUIuakwemYvFdeclYKMxJYjJ8AUTs3Ezl0ENvLVSl97Sz+OC xiEigCxO0R2QHVLJkjzanaIJsClica5H+dUEr7VwNYMgu2BfFyV1iTSKbZDmBizYeEsM NpGIutaY0qSNK3s5oTVo0uuB5vu7M4c7dvfA31KNOs7A80TGP9vmxoVaa1jBRizR5tKo LyjQ== X-Gm-Message-State: ALoCoQk+ppCuNjqZva03Fiz3/gTh7fgeQSKJgB5XdTK7BZCe+m9pbXL1zAnvsb2KElNa58ndtKbm MIME-Version: 1.0 X-Received: by 10.70.65.34 with SMTP id u2mr60794517pds.58.1410882032122; Tue, 16 Sep 2014 08:40:32 -0700 (PDT) Sender: mark@coactus.com Received: by 10.70.138.45 with HTTP; Tue, 16 Sep 2014 08:40:31 -0700 (PDT) X-Originating-IP: [192.0.216.13] In-Reply-To: <54184E92.7050407@dcrocker.net> References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54184E92.7050407@dcrocker.net> Date: Tue, 16 Sep 2014 11:40:31 -0400 X-Google-Sender-Auth: zsEotMKL8ryi8M9fV2Z6uhHq1Sg Message-ID: From: Mark Baker To: Dave Crocker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/lJraTqvsJJW6Xh7sdL81W6ox_FU Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RESTful definition 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, 16 Sep 2014 15:40:34 -0000 On Tue, Sep 16, 2014 at 10:52 AM, Dave Crocker wrote: > On 9/16/2014 7:49 AM, Mark Baker wrote: >> It's really only chapter 5 that defines REST, with the preceding >> chapters defining terms and concepts that enable chapter 5. If those >> terms and concepts were themselves commonly used in IETF circles, I'd >> suggest referencing chapter 5 directly, but they aren't so I see no >> problem referencing the whole dissertation. > > > Other than the fact that it's useless? > > Citing only an entire volume, as a means of defining a concept, vastly > raises the barrier to utility of the document making the citation. Presumably these aren't normative references, as that would make no sense. But an informative reference would seem the perfect vehicle for the editors to inform readers about some of the decisions made in the design of the protocol. > It also tends to indicate a community failure to develop a shared > understanding of the construct. Not at all from my POV. That seems par for the course when one community wants to be informed by another. From nobody Tue Sep 16 09:32:45 2014 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 DF70C1A87CB for ; Tue, 16 Sep 2014 09:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 zcjCv-KCueED for ; Tue, 16 Sep 2014 09:32:42 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D511A877C for ; Tue, 16 Sep 2014 09:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s8GGWW32003726; Tue, 16 Sep 2014 18:32:32 +0200 (CEST) Received: from [192.168.217.106] (p548903B6.dip0.t-ipconnect.de [84.137.3.182]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 47A8C7C2; Tue, 16 Sep 2014 18:32:31 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Tue, 16 Sep 2014 18:32:29 +0200 X-Mao-Original-Outgoing-Id: 432577948.982276-5bd31d5cfb9b477d90705ec3c9a07b55 Content-Transfer-Encoding: quoted-printable Message-Id: <6EE29D08-4254-448E-821D-722756E1810C@tzi.org> References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/b1bQ8_0KHcwldXHW9bPHkioub0w Cc: Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition 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, 16 Sep 2014 16:32:44 -0000 > I asked this question because there's a document in a WG I'm chairing = (not this one) that I believe needs such a definition, either included = or referenced. =20 You mean as in defining/referencing REST in a normative way? I=92d love to know what that document is trying to accomplish. (The current discussion does not make any sense if the point is just = about an informative reference to the concept =97 clearly the thesis is = fine for that, and there are secondary sources such as Wikipedia for = those who want to save time.) > I'm happy to push for such a definition to be included in that = document, but only if one can be found or generated, such that it has = consensus, in fairly short order because we have a timeline to which = we're trying to adhere. Section 4 of the Wikipedia article is a pretty concise definition of = REST (if it is the architectural constraints you are after). Probably = section 2 and 3 are needed, too, for context. Of course, you could just = list the names of the six architectural constraints; this would be even = more concise but not really meaningful any more. But I still question the point here. When we need a unit for time in IETF standards, we use =93seconds=94, = generally without referencing ISO/IEC 80000. If we were into cabling standards, we would use terms such as =93green=94 = for the color of a strand=92s isolation without a formal definition of = =93green". Obviously, the term =93green=94 is being abused in the industry about as = much as the term =93REST" is, but that wouldn=92t change the above (it = would be obvious from context this is not about =93eco-friendly=94 = isolation). Gr=FC=DFe, Carsten From nobody Tue Sep 16 09:43:49 2014 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 838D61A6FB4 for ; Tue, 16 Sep 2014 09:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ot_yWjJjrpF for ; Tue, 16 Sep 2014 09:43:45 -0700 (PDT) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02E51A0B06 for ; Tue, 16 Sep 2014 09:43:44 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id e89so148809qgf.38 for ; Tue, 16 Sep 2014 09:43:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vAU4lZv9C8GkZLv73N7XW2lwWrlcVa2Rhb2HAsRgbgY=; b=RGpD/TCHTQWshhNWcyk3G1gH+atqtvutMS/tZbJgR5UWySDsn+1NrDkxFj8Vv6MP7g OkLOD8UlcnUeELIowTEeS6xiJ9odnPP0An/7N5jdBRGYX0AaEx9K2elC1CDVx0pI57e1 y/HzSe4xyXbvIeNXudEtSf3ilOuZCjC3c4Ry60aTSZisNTXe0b4xTCPCVFKPx5J+XF/v 9mubghi/+EY34U/LSiIybwxmbAN7WuACOcouAbE5Bgk/iFKAFNZs6xHLmDwc/qR+EkvJ empKaju9cjQky03YpTCJb4TRJyEkJHWGSvdoXdo2IR4ye/uPpdRq0/e9MQY1XbAcapvg It9g== X-Gm-Message-State: ALoCoQl4Codfl1zWQHXFTHzcdShpOQ2ODj4n4dpgX5NSz3ROIjWV6xCJbo6FsaPUJV3TLG0rEElZ X-Received: by 10.140.48.203 with SMTP id o69mr17305386qga.102.1410885824049; Tue, 16 Sep 2014 09:43:44 -0700 (PDT) Received: from Everready.local ([76.73.248.16]) by mx.google.com with ESMTPSA id w15sm1763330qaw.23.2014.09.16.09.43.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Sep 2014 09:43:43 -0700 (PDT) Message-ID: <541868BD.3040501@fletcherpenney.net> Date: Tue, 16 Sep 2014 12:43:41 -0400 From: "Fletcher T. Penney" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> <54181186.4030507@ninebynine.org> <541844C3.2030200@ninebynine.org> In-Reply-To: <541844C3.2030200@ninebynine.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hkIKRigdzTk3TjMbRdKEALJQ6Lg Subject: Re: [apps-discuss] Request additional reviewer for Markdown 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, 16 Sep 2014 16:43:47 -0000 In the interest of furthering discussion... I actually prefer the opposite (well -- keep `processor`, but get rid of `processor-args` and the feature list) . From a practical standpoint, are there more than 10 people in the world who are going to define lists of arguments to ask for specific features from Markdown-like processors, when those specific features aren't even clearly defined anywhere? Who's going to write software to take an arbitrary feature list, and then try to match it up with the ever-growing number of Markdown-like implementations, each with their own slightly different take on features and syntax? For example, you request "footnote" support. Do you mean MultiMarkdown footnotes? PHP Markdown Extra Footnotes? Pandoc footnotes? Something else? As for MMD, do you mean the more recent footnotes that include "inline" footnotes, or just the old-school reference style footnotes? Which HTML formatting do you mean? Wrapped in a `
`? Mixed in with citations, or as two separate lists? You think CommonMark sparked a ####storm? I imagine that trying to define a canonical feature list is likely to cause just as big of one.... Who gets to keep "footnote" and who gets stuck with "footnote-brand-x"? Standardizing certain features across implementations would be nice. It has been brought up countless times on the discussion list without any traction. IMO, this effort is not the forum to try to sneak that in through the back door. I think this is a very deep rabbit hole that is unlikely to lead to anything concretely useful. On the other hand, if you say "Pandoc", then I have a rough idea of what is likely to work and what isn't when I use MultiMarkdown instead. I also have an obvious solution handed to me and giftwrapped -- use pandoc if the document isn't parsing as expected. As a user, a list of expected features would not be particularly helpful in troubleshooting. Fletcher On 9/16/14, 10:10 AM, Graham Klyne wrote: > 3. I'd prefer to see the 'processor' and 'processor-args' parameters > dropped completely, and focus on creating a tabulation of rules to > capture information > about the varieties of Markdown that are actually used. > > (And a thought: rather than requiring the rule definitions to resolve > any potential conflicts between themselves, have a simple left-to-right > processing of parameters such that where there is a conflict, parameters > appearing later in the list override earlier ones. That would provide a > well-defined way to say something like "github flavoured markdown, > except that newlines are not rendered as line breaks in the output".) > > #g > -- > > > On 16/09/2014 11:31, Graham Klyne wrote: >> On 16/09/2014 07:15, Sean Leonard wrote: >>> draft-ietf-appsawg-text-markdown-01.txt >> >> Reviewing https://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-01 >> >> >> # 1. Introduction >> >> First para (Nit): >> >> This seems a bit bloated. I don't think anything relevant is lost by >> deleting >> from "Compare with [RFC6838] Section 4.2.1." to the end of the paragraph. >> >> >> Para starting "Markdown specifically is a family of syntaxes..." (nit): >> >> I would be inclined to remove the text >> >> "Fed >> up with the complexity and security pitfalls of formal markup >> languages (e.g., HTML5) and proprietary binary formats (e.g., >> commercial word processing software), yet unwilling to be confined to >> the restrictions of plain text," >> >> and leave just "Many users have turned to Markdown for document >> processing" >> >> >> # 2. Markdown Media Type Registration Applications >> >> >> General: >> >> I have my doubts about creating a registry of processors. Could the >> required >> information for interoperability not be captured by capturing the >> processor >> capabilities as rules? >> >> For comparison, consider the example of HTTP feature negotiation (type, >> language, encoding, etc.) vs UA string testing and/or user-agent >> sniffing, which >> is frequently regarded as a poor way to do content matching. This >> specification >> appears to be blessing an approach analogous to UA string testing. >> >> Maybe this was discussed and I missed it? >> >> >> The description of "processor-args" seems odd to me - it seems to tie >> the media >> type string to a particular form of implementation (posix commands). >> Would it >> not be more flexible to use some kind of attribute/value list (e.g. >> similar to >> media type parameters themselves), and let the application turn them into >> command line options or environment variables or whatever is needed? >> (As you >> plan to allow references to web resources here, maybe use something >> like encoded >> JSON, which can be a common representation for direct or indirect >> values?) >> >> I think such an approach could also sidestep some of the unresolved >> security >> concerns in the draft (e.g. [[TODO: discuss the implications of >> processor-args, >> and safeguards.]], etc.) >> >> >> Para "Interoperability considerations": >> >> Contains the text: "When it is desirable to reflect the author's >> intent in the >> output, stick with the flavor identified in the flavor parameter." >> What is this >> "flavor" parameter? I'm not seeing it. >> >> [later: looks like left over from a previous incarnation - maybe worth >> a global >> search for changed names?] >> >> >> # 4. IANA Considerations >> >> Is it really necessary to have "expert review" for these registries? >> That >> requires a volunteer and may impose some additional overhead on IANA. >> Would >> "First come first served" not work here? >> >> What are the requirements for updating a registry entry? I'd suggest >> including >> an "escape" clause that allows IESG or an IETF-stream RFC to update >> any entry. >> (I'd trust the community to not do this capriciously). >> >> Rather than reserve some names for future use, why not just >> pre-register them >> (even if the descriptions are vague for now, allowing that they can be >> updated >> later)? >> >> #g >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Fletcher T. Penney fletcher@fletcherpenney.net From nobody Tue Sep 16 10:39:25 2014 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 31C6C1A7011 for ; Tue, 16 Sep 2014 10:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fqgeAMvwHyI for ; Tue, 16 Sep 2014 10:39:22 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7E7C1A87E2 for ; Tue, 16 Sep 2014 10:39:18 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id c11so267004lbj.9 for ; Tue, 16 Sep 2014 10:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N8NTMXi4YxsFBR2KUkg8guATKKLTovTRTyIncoKJgd4=; b=xQGq7BvMXGPKoENhogQA85zsfrf+fXp9Uu8dhLOxPAxV40e6GdZrNgRJSSJomuA0PX TfswK2JXWZTELpuDHWfTaHYSOlxK6jToHg4jeTGipdEWxFAQL1Pb/jN4LqXoTYYPZxcl d/DSPm+p64bP0ZqInF4pNoUPoRrTpEvZJPD6dueNwocNg59ja7Y7kw0UvGdafvoCccir ag8dot6BOekq9LD936JMF1eNJckM/VIDwfORZnuY1XhSqzsXZDJVImCPNhTgJrybeBYP PrT12ymaQqzlj+GwawYE8iuLYo5DDVo8N5GQcxCJKwJK7lgJrzIaTEsBWe00Vs0BV/v2 CJ6A== MIME-Version: 1.0 X-Received: by 10.112.34.78 with SMTP id x14mr36722090lbi.38.1410889157021; Tue, 16 Sep 2014 10:39:17 -0700 (PDT) Received: by 10.25.211.7 with HTTP; Tue, 16 Sep 2014 10:39:16 -0700 (PDT) In-Reply-To: <6EE29D08-4254-448E-821D-722756E1810C@tzi.org> References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <6EE29D08-4254-448E-821D-722756E1810C@tzi.org> Date: Tue, 16 Sep 2014 10:39:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: Carsten Bormann Content-Type: multipart/alternative; boundary=bcaec5554fb20596590503323bcf Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JGkVXzTGwW4CWs5o9WgR5Ya-K50 Cc: Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition 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, 16 Sep 2014 17:39:24 -0000 --bcaec5554fb20596590503323bcf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Sep 16, 2014 at 9:32 AM, Carsten Bormann wrote: > You mean as in defining/referencing REST in a normative way? > I=E2=80=99d love to know what that document is trying to accomplish. > I mean defining it at all, in the same way that a reviewer running across an acronym with which she is unfamiliar needs to know what it means to understand what's going on in the rest of the document. I'm basically trying to resolve a "Define this term on first use". It's hardly uncommon for us to insist on expansion of an acronym on first use and then also include a definition or a reference to one, is it? But I still question the point here. > > When we need a unit for time in IETF standards, we use =E2=80=9Cseconds= =E2=80=9D, > generally without referencing ISO/IEC 80000. > If we were into cabling standards, we would use terms such as =E2=80=9Cgr= een=E2=80=9D for > the color of a strand=E2=80=99s isolation without a formal definition of = =E2=80=9Cgreen". > I hope it's not actually debatable that there are more RFC readers who know what seconds and green are than who know what REST means. I get that you think a good understanding of REST is ubiquitous; respectfully, I disagree (because I didn't until recently, for example), and I'd like to ensure this document accommodates those readers who don't. -MSK --bcaec5554fb20596590503323bcf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 16, 2014 at 9:32 AM, Carsten Bormann <cabo@tzi.org= > wrote:
You mean as in defining/referencing RES= T in a normative way?
I=E2=80=99d love to know what that document is trying to accomplish.

I mean defining it at all, in the same way th= at a reviewer running across an acronym with which she is unfamiliar needs = to know what it means to understand what's going on in the rest of the = document.=C2=A0 I'm basically trying to resolve a "Define this ter= m on first use".

It's hardly uncommon for us to= insist on expansion of an acronym on first use and then also include a def= inition or a reference to one, is it?

But I still question the point here.

When we need a unit for time in IETF standards, we use =E2=80=9Cseconds=E2= =80=9D, generally without referencing ISO/IEC 80000.=C2=A0

If we were into cabling standards, we would use terms such as =E2=80=9Cgree= n=E2=80=9D for the color of a strand=E2=80=99s isolation without a formal d= efinition of =E2=80=9Cgreen".

I ho= pe it's not actually debatable that there are more RFC readers who know= what seconds and green are than who know what REST means.

I get tha= t you think a good understanding of REST is ubiquitous; respectfully, I dis= agree (because I didn't until recently, for example), and I'd like = to ensure this document accommodates those readers who don't.

-MSK
--bcaec5554fb20596590503323bcf-- From nobody Tue Sep 16 11:07:13 2014 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 A44891A8702 for ; Tue, 16 Sep 2014 11:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 33OHD7jbRNSX for ; Tue, 16 Sep 2014 11:07:06 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686681A7021 for ; Tue, 16 Sep 2014 11:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s8GI6uSY004441; Tue, 16 Sep 2014 20:06:56 +0200 (CEST) Received: from [192.168.217.106] (p548903B6.dip0.t-ipconnect.de [84.137.3.182]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7B3FA834; Tue, 16 Sep 2014 20:06:55 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Tue, 16 Sep 2014 20:06:53 +0200 X-Mao-Original-Outgoing-Id: 432583613.661197-1f66f0d1ab668add108e5e237e1c0a24 Content-Transfer-Encoding: quoted-printable Message-Id: <2CF21998-BB63-4F76-BBE8-05744459C2B1@tzi.org> References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <6EE29D08-4254-448E-821D-722756E1810C@tzi.org> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3zm-4Ev8eGCl8iNjZUdEgIQSFLM Cc: Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition 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, 16 Sep 2014 18:07:09 -0000 > I mean defining it at all, in the same way that a reviewer running = across an acronym with which she is unfamiliar needs to know what it = means to understand what's going on in the rest of the document. I'm = basically trying to resolve a "Define this term on first use".=20 >=20 > It's hardly uncommon for us to insist on expansion of an acronym on = first use and then also include a definition or a reference to one, is = it? Ah, good, that=92s exactly what we needed in RFC 7252, and which has = been solved by the reference to the dissertation. So my recommendation would, again, be to mirror that (or the reference = in RFC 7231). > I hope it's not actually debatable that there are more RFC readers who = know what seconds and green are than who know what REST means. To the level of a formal definition? E.g., based on the CIE 1931 color = model or L*a*b* coordinates? I=92m not so sure... For some reason some people seem to insist on a formality of the = definition of what REST is that we wouldn=92t require in other places. = May have something to do with the marketing value of the term and the = desire for =93requirements engineering=94*)... > I get that you think a good understanding of REST is ubiquitous; Ubiquitous: certainly not (outside the small circle that really cares = about Web architecture, that is). Readily achievable: I wish that there were a good, authoritative, = reasonably correct tutorial document that one could cite, but for now, = the dissertation (or, for a more superficial understanding, some = secondary literature like the Wikipedia article) will have to do. I just don=92t think that =93a good understanding of REST=94 can be = conveyed by a concise definition. So, if that is what is actually needed, the reference to the = dissertation is even more necessary. Gr=FC=DFe, Carsten *) =93requirements engineering=94, in standardization, is the = engineering of the requirements in such a way that only your preferred = solution meets the requirements. A common way of generating the = necessary =93consensus=94 for those is to employ terms that sound good = but have a formal meaning with some non-obvious consequences. From nobody Tue Sep 16 11:21:13 2014 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 6B35E1A8768 for ; Tue, 16 Sep 2014 11:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0QqOBeUkiuB for ; Tue, 16 Sep 2014 11:21:09 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DD4B1A6F40 for ; Tue, 16 Sep 2014 11:21:09 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id le20so268904vcb.13 for ; Tue, 16 Sep 2014 11:21:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=sH8Etn81sw14mUGKawmrpzql40ANOFCTsj1GggZEbU4=; b=CgNkzF9dARJla61vUfEumdyLxQ77TBOHWXjlFfNR4DQPbbtY0Gv13YuoUX9pNfO2Mg CwFI55jvBXK1pUQprWBY+W/wW8rnrmsW6OJLIJeMMlVafEbm0jtTqv1m5CkGMXvxEWx0 MVcPyAWQEIUq25w4l/QFRJLEQVVxeu+QOjCnwJ8yU19uM3C5WT9CPIq0abME5Xa2/i4j 606TfsZ2Nl1IVFl3nvKOCbBre+3+MGs6b+4TjRJtwwVwVRj6LSrvGR9JsT/UysPO8Y6Q iXpt6/6flrQjZ8hOM5QbrdB3KzY0kC0Kyyc/a18xDQj/XW14Rt0LIUcb0R3pR8aU1oCv taRA== X-Gm-Message-State: ALoCoQmwnkihvztq7PmFVztxbTCC5vMNPBHdogKBb49xzq73UTcCe9uUYYt2qGowBN+mS7NnOp0a X-Received: by 10.52.89.198 with SMTP id bq6mr20896742vdb.41.1410891668187; Tue, 16 Sep 2014 11:21:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.214.4 with HTTP; Tue, 16 Sep 2014 11:20:48 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <6EE29D08-4254-448E-821D-722756E1810C@tzi.org> From: Tim Bray Date: Tue, 16 Sep 2014 11:20:48 -0700 Message-ID: To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=bcaec50162f1b2f771050332d09f Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/rapWwapENM9hM2XkjhzBnsfdRwg Cc: Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition 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, 16 Sep 2014 18:21:11 -0000 --bcaec50162f1b2f771050332d09f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Seriously, I would actually ask whether your need is to appeal to the full intellectual apparatus of REST, or simply to say =E2=80=9CWe=E2=80=99re usi= ng 4-verb HTTP and respecting the idempotence semantics=E2=80=9D. Because in a huge propo= rtion of case, the latter is what people really mean. And there=E2=80=99s nothing w= rong with that. On Tue, Sep 16, 2014 at 10:39 AM, Murray S. Kucherawy wrote: > On Tue, Sep 16, 2014 at 9:32 AM, Carsten Bormann wrote: > >> You mean as in defining/referencing REST in a normative way? >> I=E2=80=99d love to know what that document is trying to accomplish. >> > > I mean defining it at all, in the same way that a reviewer running across > an acronym with which she is unfamiliar needs to know what it means to > understand what's going on in the rest of the document. I'm basically > trying to resolve a "Define this term on first use". > > It's hardly uncommon for us to insist on expansion of an acronym on first > use and then also include a definition or a reference to one, is it? > > But I still question the point here. >> >> When we need a unit for time in IETF standards, we use =E2=80=9Cseconds= =E2=80=9D, >> generally without referencing ISO/IEC 80000. > > >> If we were into cabling standards, we would use terms such as =E2=80=9Cg= reen=E2=80=9D for >> the color of a strand=E2=80=99s isolation without a formal definition of= =E2=80=9Cgreen". >> > > I hope it's not actually debatable that there are more RFC readers who > know what seconds and green are than who know what REST means. > > I get that you think a good understanding of REST is ubiquitous; > respectfully, I disagree (because I didn't until recently, for example), > and I'd like to ensure this document accommodates those readers who don't= . > > -MSK > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --bcaec50162f1b2f771050332d09f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ser= iously, I would actually ask whether your need is to appeal to the full int= ellectual apparatus of REST, or simply to say =E2=80=9CWe=E2=80=99re using = 4-verb HTTP and respecting the idempotence semantics=E2=80=9D. =C2=A0Becaus= e in a huge proportion of case, the latter is what people really mean. =C2= =A0And there=E2=80=99s nothing wrong with that.

On Tue, Sep 16, 2014 at 10:39 AM,= Murray S. Kucherawy <superuser@gmail.com> wrote:
On Tue, Sep 16,= 2014 at 9:32 AM, Carsten Bormann <cabo@tzi.org> wrote:
You mean as in defining/referencing REST in a n= ormative way?
I=E2=80=99d love to know what that document is trying to accomplish.

I mean defining it at all, in the same= way that a reviewer running across an acronym with which she is unfamiliar= needs to know what it means to understand what's going on in the rest = of the document.=C2=A0 I'm basically trying to resolve a "Define t= his term on first use".

It's hardly uncommon fo= r us to insist on expansion of an acronym on first use and then also includ= e a definition or a reference to one, is it?

=
But I still question the point here.

When we need a unit for time in IETF standards, we use =E2=80=9Cseconds=E2= =80=9D, generally without referencing ISO/IEC 80000.=C2=A0

If we were into cabling standards, we would use terms such as =E2=80=9Cgree= n=E2=80=9D for the color of a strand=E2=80=99s isolation without a formal d= efinition of =E2=80=9Cgreen".

I hope it's not actually debatable that there are more RFC readers w= ho know what seconds and green are than who know what REST means.

I = get that you think a good understanding of REST is ubiquitous; respectfully= , I disagree (because I didn't until recently, for example), and I'= d like to ensure this document accommodates those readers who don't.

-MSK

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




--
- Tim Bray (If you=E2=80=99d like to send me a private messag= e, see https://key= base.io/timbray)
--bcaec50162f1b2f771050332d09f-- From nobody Tue Sep 16 12:52:29 2014 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 55F591A6EED; Tue, 16 Sep 2014 12:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jZW-yAjpqKr; Tue, 16 Sep 2014 12:52:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7C31A8856; Tue, 16 Sep 2014 12:52:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140916195225.23455.64063.idtracker@ietfa.amsl.com> Date: Tue, 16 Sep 2014 12:52:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XOUl6UWqW24Q79XDSP67XoMwLoQ Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-authres-ptypes-registry-03.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: Tue, 16 Sep 2014 19:52:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : A Property Types Registry for the Authentication-Results Header Field Author : Murray S. Kucherawy Filename : draft-ietf-appsawg-authres-ptypes-registry-03.txt Pages : 5 Date : 2014-09-16 Abstract: This document updates RFC7001 by creating a registry for property types in the Authentication-Results header field, used in email authentication work, rather than limiting participants to using the original, small set of fixed values. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-authres-ptypes-registry/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-authres-ptypes-registry-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-authres-ptypes-registry-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 16 13:09:28 2014 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 76E7A1A00D2 for ; Tue, 16 Sep 2014 13:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNOAKDJ2M0F3 for ; Tue, 16 Sep 2014 13:09:22 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311301A009C for ; Tue, 16 Sep 2014 13:09:21 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id 10so531128lbg.16 for ; Tue, 16 Sep 2014 13:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=eicQv9IevMl7bxuKWqwgBQJEUgV/FRs67UsSONBvJwY=; b=X0LLKt+QDXhPEEy4ZmxTZXGrCdqJLDSFP2y3wU8cCavNPPOdVHagYxSZZPRlhxe1hT yLh2Qnej9j9fMuHU/vH61aDDXDZk/k5HYYn5fI37D/Kb+pUYnHQlHU4KMTK/EFoEfjdO CjpUkPZ7j8Ho0vKu4wT59UH30dqKxoCGbzQuSUbGoI3Ev30NPChsaCRnPjoc7RAE5Jwa gFb7m5GUP/HfUS4V/XkemvXLbjqQvRJgNq5C7MovXqPpYwzoP3UqGSiKXhQSFWPBTkbf 5hNflcQZUFK29DI69o9Vf1IvcPSs3jZFB0/ilBmgsEMhDflvHYAPaO3G42Rczn5a9uIz AzLA== MIME-Version: 1.0 X-Received: by 10.112.78.38 with SMTP id y6mr13293759lbw.94.1410898160371; Tue, 16 Sep 2014 13:09:20 -0700 (PDT) Received: by 10.25.211.7 with HTTP; Tue, 16 Sep 2014 13:09:20 -0700 (PDT) Date: Tue, 16 Sep 2014 13:09:20 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c3db42a9d9cf05033453d8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/BtTBL_Etta3ZPoBqshpkjLgO6Q8 Subject: [apps-discuss] Working Group Last Call on draft-ietf-appsawg-multipart-form-data 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, 16 Sep 2014 20:09:26 -0000 --001a11c3db42a9d9cf05033453d8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Working Group Last Call: draft-ietf-appsawg-multipart-form-data Colleagues, This note starts a Working Group Last Call for draft-ietf-appsawg-multipart-form-data. The document seems to have stabilized and I believe Larry got the help he needed in setting up test cases he needed. Please provide review comments or expressions of support for the current version either on this list or privately to draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org on or before October 3, 2014. Be as detailed as possible. The co-chairs need to determine if the document has working group consensus, which means we need to know people have read the latest version and agree with its content and with the idea that it is ready to proceed. A simple =E2=80=9C+1=E2=80=9D d= oesn=E2=80=99t tell us anything. Also, if any participant has knowledge of IPR that needs to be declared on this work, please do so, as required by BCPs 78 and 79. is fulfilling the duties of document shepherd. -MSK, APPSAWG co-chair --001a11c3db42a9d9cf05033453d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Working Group Last Call: draft-ietf-appsawg-multipart-form= -data

Colleagues,

This note starts a Working Group Last Call = for draft-ietf-appsawg-multipart-form-data.=C2=A0 The document seems to hav= e stabilized and I believe Larry got the help he needed in setting up test = cases he needed.

Please provide review comments or expressions of su= pport for the current version either on this list or privately to draft= -ietf-appsawg-multipart-form-data.all@tools.ietf.org on or before Octob= er 3, 2014.=C2=A0 Be as detailed as possible.=C2=A0 The co-chairs need to d= etermine if the document has working group consensus, which means we need t= o know people have read the latest version and agree with its content and w= ith the idea that it is ready to proceed.=C2=A0 A simple =E2=80=9C+1=E2=80= =9D doesn=E2=80=99t tell us anything.

Also, if any participant has k= nowledge of IPR that needs to be declared on this work, please do so, as re= quired by BCPs 78 and 79.

<name> is fulfilling the duties of d= ocument shepherd.

-MSK, APPSAWG co-chair
--001a11c3db42a9d9cf05033453d8-- From nobody Tue Sep 16 13:10:12 2014 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 CAD831A0390 for ; Tue, 16 Sep 2014 13:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.079 X-Spam-Level: X-Spam-Status: No, score=-101.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 M84mwQq8WD4E for ; Tue, 16 Sep 2014 13:10:01 -0700 (PDT) Received: from ftp.catinthebox.net (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E99951A0026 for ; Tue, 16 Sep 2014 13:09:50 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3137; t=1410898185; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=7+VH25kvtb/4Gt91u5R8RHrzrRE=; b=q+O6B8lsq2sySM9NofbF 9lHmGp6QvA3m6iHtck4ov/yCYEPySk+iNP5S1yetwldzTfT8iLPwlDTJIedlrZJP VJs+CwWM4mmRIRtdh/bEKJd2qD/yUWT7Nkk8YlkSICbdLEYF1sfv0Pcg+gWZVNDv Kl4DaqUEyBa2acWypa83qJE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 16 Sep 2014 16:09:45 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1788276373.3109.2724; Tue, 16 Sep 2014 16:09:44 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3137; t=1410897841; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=+gNzdWX tJyAKpTJxJ2g+IA3AwCPoHWn2ChwUO6K8/38=; b=qFj/V2bvFFGvh/y/tXvKagd fA/uA+t5mjOqkFI64Rdp+lkkWHkpsuxpSaKZO11fYdhw3Qv9HJNcRPfNjsOzDot2 JkFwD+a5dAy8zA9yvDB0vHeSXDWFdTNJZyQLJ9uClLImcyxgg9pHvE4dVaBxswKw s8M7CBrUnDs0jWxLafmU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 16 Sep 2014 16:04:01 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 380721266.9.5232; Tue, 16 Sep 2014 16:04:00 -0400 Message-ID: <54189906.8070005@isdg.net> Date: Tue, 16 Sep 2014 16:09:42 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Carsten Bormann References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <6EE29D08-4254-448E-821D-722756E1810C@tzi.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/iubUieLMnL_0APrTNBAF-daJaJY Cc: Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition 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, 16 Sep 2014 20:10:05 -0000 Murray, Historically, when it came to RPC (Remote Procedure Calls) API development that included web servers, client/servers, etc, the key was how was the API defined (the options) and the data passed. In general, you can do GET and/or POST. But most servers did not do both. Either one or the other. POST was harder to do and migrate too, but it allowed for the "unlimited" or larger data part needs. SOAP is a good example of this API. A SOAP API can be RESTFUL as well if you are passing options via the command line. Overall, the shortest definition that MOST should understand is: WEB-based Application Command line (URL) options. You can't do that with POST. Its only GET. I remember when the term REST began to be used when many systems direction were developing APIs and using URL COMMAND LINE Options for their system or operation was the simplest and quickest path. Doing a SOAP was "harder." So to me, when you say "REST" or "RESTFUL" I am expecting GET command line options. Note: Some servers can take a POST and present the data to the server-side applications as GET values. The server side application is independent of how the data/options are passed (Command Line versus Posted). I suggest to just look at the RFC HTTP documents for the following definitions: request line request query query I think a reference to the HTTP RFCs regarding "HTTP GET query command" or anything close to that is probably the best "layman" definition for REST. -- HLS On 9/16/2014 1:39 PM, Murray S. Kucherawy wrote: > On Tue, Sep 16, 2014 at 9:32 AM, Carsten Bormann wrote: > >> You mean as in defining/referencing REST in a normative way? >> I’d love to know what that document is trying to accomplish. >> > > I mean defining it at all, in the same way that a reviewer running across > an acronym with which she is unfamiliar needs to know what it means to > understand what's going on in the rest of the document. I'm basically > trying to resolve a "Define this term on first use". > > It's hardly uncommon for us to insist on expansion of an acronym on first > use and then also include a definition or a reference to one, is it? > > But I still question the point here. >> >> When we need a unit for time in IETF standards, we use “secondsâ€, >> generally without referencing ISO/IEC 80000. > > >> If we were into cabling standards, we would use terms such as “green†for >> the color of a strand’s isolation without a formal definition of “green". >> > > I hope it's not actually debatable that there are more RFC readers who know > what seconds and green are than who know what REST means. > > I get that you think a good understanding of REST is ubiquitous; > respectfully, I disagree (because I didn't until recently, for example), > and I'd like to ensure this document accommodates those readers who don't. > > -MSK > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- HLS From nobody Tue Sep 16 13:41:33 2014 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 376241A0464; Tue, 16 Sep 2014 13:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-_UOK9JSzKx; Tue, 16 Sep 2014 13:41:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1750F1A0390; Tue, 16 Sep 2014 13:41:31 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140916204131.23593.40644.idtracker@ietfa.amsl.com> Date: Tue, 16 Sep 2014 13:41:31 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/bgzwPP3ImY39DWkdVu5elXRUuaI Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (A Property Types Registry for the Authentication-Results Header Field) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 20:41:32 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'A Property Types Registry for the Authentication-Results Header Field' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-09-30. 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 This document updates RFC7001 by creating a registry for property types in the Authentication-Results header field, used in email authentication work, rather than limiting participants to using the original, small set of fixed values. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-authres-ptypes-registry/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-authres-ptypes-registry/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Sep 16 17:33:38 2014 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 4F1071A008B for ; Tue, 16 Sep 2014 17:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 eFPFUpq-VdUg for ; Tue, 16 Sep 2014 17:33:35 -0700 (PDT) Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 867E61A016F for ; Tue, 16 Sep 2014 17:33:35 -0700 (PDT) Received: from [73.189.85.237] (helo=dretair11.local) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1XU3Bc-0003Sl-Kw; Tue, 16 Sep 2014 17:33:33 -0700 Message-ID: <5418D6D5.6080907@berkeley.edu> Date: Tue, 16 Sep 2014 17:33:25 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Carsten Bormann , "Murray S. Kucherawy" , IETF Apps Discuss References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <6EE29D08-4254-448E-821D-722756E1810C@tzi.org> <2CF21998-BB63-4F76-BBE8-05744459C2B1@tzi.org> In-Reply-To: <2CF21998-BB63-4F76-BBE8-05744459C2B1@tzi.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Ory9A8ZuRKQORJ3CFSwa5HuNHDA Cc: Dave Crocker Subject: Re: [apps-discuss] RESTful definition 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, 17 Sep 2014 00:33:37 -0000 hello carsten. On 2014-09-16, 11:06, Carsten Bormann wrote: > I just don’t think that “a good understanding of REST” can be conveyed by a concise definition. > So, if that is what is actually needed, the reference to the dissertation is even more necessary. agreed that definitions usually not good tutorial materials. But a concise definition does not exclude a reference to more exhaustive documentation, right? we've had at least some success with presenting people with an easy "check list", telling them that if you miss any of those, you probably have an issue with actually doing REST: "What is REST? A set of constraints that inform an architecture * Resource Identification * Uniform Interface * Self-Describing Messages * Hypermedia Driving Application State * Stateless Interactions" http://dret.net/netdret/docs/rest-icwe2010/rest#%2812%29 but then again, that's against tim bray's more pragmatic view of "anything that's using HTTP and some reasonable set of methods without violating their HTTP semantics". cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From nobody Tue Sep 16 17:48:42 2014 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 5E7BF1A0656 for ; Tue, 16 Sep 2014 17:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, 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 FcUMOLX-AO48 for ; Tue, 16 Sep 2014 17:48:39 -0700 (PDT) Received: from nm18.bullet.mail.gq1.yahoo.com (nm18.bullet.mail.gq1.yahoo.com [98.136.217.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73ADD1A01EF for ; Tue, 16 Sep 2014 17:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1410914919; bh=vmtCBsQ0sF1Vly8e0kK9owyGjVRU369YVEm1I4J6W3c=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Gm-Message-State:X-Received:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc:Content-Type:From:Subject; b=LN1g/YR6uIyzqr22pBF4losS14s1XHdVUZ4RAcI+QNn5EEdnfvQf19IQj7uCN2ldNDTpGY1YwO4/wvBuZtGiK4SVHof1aCn3PR42D66fvTrduqTbekP5V6Wfu5s8SVu2TPbV7If74HmDldtQpPpFiHsNO8QUbm8y/lsS4DJ3SwhNNNPn9qR85BcojsMs0ygHRlDh+mAxyVd+fioFsSH4qK0UsfptxnJW99q0lMqNhlaGtF9YmxlWGHD7FZ+VhaYDN0PGA6UVL88iOLUS7IM9uwsjR7H4+anK6GKEKzrL/HjpcAeTJadIbB99uImrFDhEGKTSITcly8vllo5qhcDzbg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=JnVpKsN5vbib6Y118b5QxFdny6Bdl1qIzAfzcspp0/81qvxWK5YrxUarcM/5JLmMs1R6CHBcTZpJcjzfxKuvcHqQe7fTxLbXeX4VJ64D2uAnsLazd7hbdXfA/QjCRtkHu/hmOTrd/wKyhcU/e3LKZb21RImgiwpIZmeHTqCOYxtPVpUXTggHq5iw2ktO4iqj11XyC85t0Zs/V8VY7tEeJ+5XJ6bc9VoZqFlRe9gIzwGqjYjiAXeKPq3G1dciHbBiI1Ygr3p67RAi3bSzNk45kibnzXwfzypdFS9USodhO26AuZKMbZpC8EZI7ZbFymv3sLHMmWRXWOX3ruP4sOqAJw==; Received: from [98.137.12.175] by nm18.bullet.mail.gq1.yahoo.com with NNFMP; 17 Sep 2014 00:48:39 -0000 Received: from [208.71.42.206] by tm14.bullet.mail.gq1.yahoo.com with NNFMP; 17 Sep 2014 00:48:39 -0000 Received: from [127.0.0.1] by smtp217.mail.gq1.yahoo.com with NNFMP; 17 Sep 2014 00:48:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1410914919; bh=vmtCBsQ0sF1Vly8e0kK9owyGjVRU369YVEm1I4J6W3c=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Gm-Message-State:X-Received:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=a7eUXryuwFsOAHZ6Hpnr6hWiH+HC6KdTL705jwGHMCWFoLlbayBeJ3/6mVJOuUilVCnn8ikhxYBbdbv5jYivRnSvZ7waQW6+/Xv3NotuNCIw3LmxNa+/qOo9f8xQJDa/TQr0zt+fdkDu2KcjKfNWrx4iCKR1p2HxTrjs2MGhvds= X-Yahoo-Newman-Id: 163361.70368.bm@smtp217.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: JSFeivAVM1nIjbs2fWEjXzOdqCAXjsr0U48mCM8a5X3Q85L shccD8PUVe53DVU_LdK0NUkbyQQ8baDZVaZy2sKt0LOeug46RJDHnVmttg8M fF4PJP6BE.jqXSGc.11k8HErryMckRcQ_mRfH9z.qQ5fSzH1rZ9lPxPfiW1J 9dpZiGRczcimmOusS7Tq3s40fxP8ErMSz_bq9UxeaWI.S9rynE0__JO4Lv3d 5oUhMMty12hhuKaIHw_V._yls_TSb0Wq9jazobBbUOIKCaoFA4mfIY6oQA_M DA1hgs_Z22PZ25w8dzGdEGTx8xwZ9sJ3u5jcE787.kQJPcg_pwM__x8.xQgz INdTIZa3LO3cRA4j52sEtP0OcRaj92tB7FIxCPNpXENiASZnqCmkll1XHHtF YjaxpE7wOtaPpTB8QGEtW6fu9Ijhv7.4QhBd9_rw87.Pz8v9BL.2nOw8IKhJ yDv1kLcdEkN6c9OAYLj3LlrAEp.YEIqR61Mrw63VYbdlvT6m5Nn3_llMxQQJ 1w5A7Mar895CzY3hBFdj3aUFk9KKUJ4NAl.u7.jl9lAWVhHGZHxcTKimxnWT uwyeO5QMAQo4cM83R.UmDvFiNvi5FT7DfmFpE14AdLGipcMvHODAzRAnpraO pIYLH.EDpxsx1cmp6Q13hYqkKI0Vi7FbFWsuLIU75KU9FkbQ_qf0GXwlms9L H0A9QcwZkG4bsWt9sy.OBOZUMRHjBjRlqMnDt0qEXw5c1UDae_EvDGK.yejA XrLb0hmU017nPQQCFKjmX4n..48Hb5Wfxd7M0G9JWvrYgntozvMAkdkvm2Sw A0A-- X-Yahoo-SMTP: i12ABOmswBAkPG1PnjmsmmFRWA-- Received: by mail-la0-f42.google.com with SMTP id hz20so883344lab.1 for ; Tue, 16 Sep 2014 17:48:36 -0700 (PDT) X-Gm-Message-State: ALoCoQkdHKDzVhvKviOxl/sVNaAU3aqQvhv4CIEHZE0LPq+/AhYTjxWUqMrf3crhKObdQd+hRvra X-Received: by 10.152.206.35 with SMTP id ll3mr9372055lac.88.1410914916434; Tue, 16 Sep 2014 17:48:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.218.8 with HTTP; Tue, 16 Sep 2014 17:48:16 -0700 (PDT) In-Reply-To: <5418D6D5.6080907@berkeley.edu> References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <6EE29D08-4254-448E-821D-722756E1810C@tzi.org> <2CF21998-BB63-4F76-BBE8-05744459C2B1@tzi.org> <5418D6D5.6080907@berkeley.edu> From: mike amundsen Date: Tue, 16 Sep 2014 20:48:16 -0400 Message-ID: To: Erik Wilde Content-Type: multipart/alternative; boundary=001a11348914671a030503383a4c Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kLGF6FMNZkfx4DGbcZeUivHOMto Cc: Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition 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, 17 Sep 2014 00:48:41 -0000 --001a11348914671a030503383a4c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable *style* definitions don't need to be "pragmatic", they need to be helpful/useful/etc. in a disputed space (e.g. the arts) definitions can be identified by "schools", etc. *implementation* advice can be pragmatic or pedantic or anything in between= . whether style or implementation, the definitions should be useful/helpful. mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://linkedin.com/in/mamund On Tue, Sep 16, 2014 at 8:33 PM, Erik Wilde wrote: > hello carsten. > > On 2014-09-16, 11:06, Carsten Bormann wrote: > >> I just don=E2=80=99t think that =E2=80=9Ca good understanding of REST=E2= =80=9D can be conveyed by >> a concise definition. >> So, if that is what is actually needed, the reference to the dissertatio= n >> is even more necessary. >> > > agreed that definitions usually not good tutorial materials. But a concis= e > definition does not exclude a reference to more exhaustive documentation, > right? we've had at least some success with presenting people with an eas= y > "check list", telling them that if you miss any of those, you probably ha= ve > an issue with actually doing REST: > > "What is REST? A set of constraints that inform an architecture > * Resource Identification > * Uniform Interface > * Self-Describing Messages > * Hypermedia Driving Application State > * Stateless Interactions" > > http://dret.net/netdret/docs/rest-icwe2010/rest#%2812%29 > > but then again, that's against tim bray's more pragmatic view of "anythin= g > that's using HTTP and some reasonable set of methods without violating > their HTTP semantics". > > cheers, > > dret. > > -- > erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | > | UC Berkeley - School of Information (ISchool) | > | http://dret.net/netdret http://twitter.com/dret | > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a11348914671a030503383a4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
*style* definitions don't need to be "pragmatic&q= uot;, they need to be helpful/useful/etc. in a disputed space (e.g. the art= s) definitions can be identified by "schools", etc.

*implementation* advice can be pragmatic or pedantic or anything in b= etween.

whether style or implementation, the defin= itions should be useful/helpful.



mamund+1.859.757.1449
skype: mca.amundsen
<= a href=3D"http://amundsen.com/blog/" target=3D"_blank">http://amundsen.com/= blog/
http:/= /twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund

On Tue, Sep 16, 2014 at 8:33 PM, Erik Wilde = <dret@berkeley.edu> wrote:
hello carsten.

On 2014-09-16, 11:06, Carsten Bormann wrote:
I just don=E2=80=99t think that =E2=80=9Ca good understanding of REST=E2=80= =9D can be conveyed by a concise definition.
So, if that is what is actually needed, the reference to the dissertation i= s even more necessary.

 agreed that definitions usually not good tutorial materials. But a concise = definition does not exclude a reference to more exhaustive documentation, r= ight? we've had at least some success with presenting people with an ea= sy "check list", telling them that if you miss any of those, you = probably have an issue with actually doing REST:

"What is REST? A set of constraints that inform an architecture
=C2=A0* Resource Identification
=C2=A0* Uniform Interface
=C2=A0* Self-Describing Messages
=C2=A0* Hypermedia Driving Application State
=C2=A0* Stateless Interactions"

http://dret.net/netdret/docs/rest-icwe2010/rest#%2812%29=

but then again, that's against tim bray's more pragmatic view of &q= uot;anything that's using HTTP and some reasonable set of methods witho= ut violating their HTTP semantics".

cheers,

dret.

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

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

--001a11348914671a030503383a4c-- From nobody Tue Sep 16 20:09:38 2014 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 32DEB1A0185 for ; Tue, 16 Sep 2014 20:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.653 X-Spam-Level: X-Spam-Status: No, score=-8.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, 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 WLjKuIn1q8qo for ; Tue, 16 Sep 2014 20:08:15 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 721721A0019 for ; Tue, 16 Sep 2014 20:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1410923295; x=1442459295; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=kSpbVve3pc215Q7//SKKM/3sC3m8eYSnLA7bJcMiEqw=; b=X1mvNboProFpBRFz+OhXPgmO+2Z6+LcBIOGRnTawC+8IuviEOPtmTIzN B1uDxYZ+3/hGv7lbh+fbA22Z+tjI8KpzplrcLQcGY5TQSfjG4keU2MaiI MAQ7bPyDaIg1iSWI5mzl6mklhYEWto6kRGi1T0kn7D93NE8irmYXNjHJO U=; X-IronPort-AV: E=McAfee;i="5600,1067,7563"; a="74898423" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth02.qualcomm.com with ESMTP; 16 Sep 2014 20:08:14 -0700 X-IronPort-AV: E=Sophos;i="5.04,538,1406617200"; d="scan'208";a="752224362" Received: from nasanexhc12.na.qualcomm.com ([172.30.39.187]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Sep 2014 20:08:14 -0700 Received: from NASANEXM01B.na.qualcomm.com (129.46.53.226) by nasanexhc12.na.qualcomm.com (172.30.39.187) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 16 Sep 2014 20:08:14 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01B.na.qualcomm.com (129.46.53.226) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 16 Sep 2014 20:08:13 -0700 Message-ID: <5418FB1C.5080605@qti.qualcomm.com> Date: Tue, 16 Sep 2014 22:08:12 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Apps Discuss Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (129.46.53.226) To NASANEXM01B.na.qualcomm.com (129.46.53.226) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Q5kKNdqjQElpx30FswtWp0KBsAs Subject: [apps-discuss] Pete not standing again for Apps AD 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, 17 Sep 2014 03:08:17 -0000 Folks, I realized that though I've mentioned this to a few people, it would be good to say this publicly: I have let the NomCom know that I am not going to stand for another term as Apps AD. I have very much enjoyed my tenure, and I plan to stay very involved in the IETF and take on leadership roles in the future as they are available, but right now I need a break. After two terms, I am running out of energy and I can see in the distance that I will eventually hit a wall. It would be unfortunate for everyone involved if I made a commitment for years 5 and 6 and then hit that wall in year 4.5. So I'll be stepping down at the end of this term. I also want to use this message to encourage all of you to consider throwing your hat in the ring. Being an AD is very rewarding. You can do a great deal to improve and influence the direction of the IETF as an AD. Yes, it can be frustrating at times, and figuring out how to get to rough consensus with the other ADs, let alone with the entire organization, is quite the challenge, but I've found it to be energizing. And yes, it is quite a bit of work. However, while you can certainly make it a near full-time job if you want to, I am convinced you can make it a bit-more-than-half-time job pretty straightforwardly, and with some effort and planning you could even make it a third-time job (with occasional bursts of activity). I am happy to chat with anyone who has questions about the position. Cheers, pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Sep 16 20:16:15 2014 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 203151A0193 for ; Tue, 16 Sep 2014 20:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMi5rCrHPPTR for ; Tue, 16 Sep 2014 20:14:56 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B56F71A0177 for ; Tue, 16 Sep 2014 20:14:56 -0700 (PDT) Received: by mail-oi0-f54.google.com with SMTP id a3so481813oib.41 for ; Tue, 16 Sep 2014 20:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rtq9zP4SArptjDqJz/jPYW7QaxkEzW/WwkBe3HGdFFA=; b=Rnf31Q+o1dkmwvu8jAuLxo2pYIh7FW3fSPrCam93jgGZBHCTJwzwED4PNWRXHjG5vU nrILZs/X1GuGoUnJH2S8s/rjWu7lVuSaOOqdMtMRs68qsW3wg4CUNfAiDRfry2yWFa+l XUqPRWTn5Rv3X3wi40T8KmZ0JbRwwstTjtS0M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rtq9zP4SArptjDqJz/jPYW7QaxkEzW/WwkBe3HGdFFA=; b=SfqGV2qZaEVpMUErVGK3lEhnzrpNs5D8edXuG39+nNPAwxzJiJwj2vCrX25i0ISJms CGhCKT55H3zwTjtSXWKR+Dk9g5syVeSAvCA6bABE3U3dDGj4xqNkcJ8bcmpZ53SmMwz8 1UOlvyLUjCG6tswp+JE+HX/F54gXVrZHAYKR5CDVApSM3m6Z5b22d58D5+wTsZR7kSn6 UVh35tRsMQRSYWAUtaXx0Wj9IQxnKXUnD5Jv3wY0K7N+/SD1QL6wQlifCPaHuJ9UZArO 8sOZaYWfvmcbTBCy2WcSvdIfXLvC2gbp+hGQN3vANsD20JYw2yvAGkoKCisoa2Xu6qW/ e/LQ== X-Gm-Message-State: ALoCoQm2oaanY6cD7kTrTMfghM3csbohF6tx/K/YlcSn9pYZWd7qqDAJ233IU4nROju8Kv/E+WaN MIME-Version: 1.0 X-Received: by 10.182.249.52 with SMTP id yr20mr39568231obc.10.1410923696021; Tue, 16 Sep 2014 20:14:56 -0700 (PDT) Received: by 10.60.55.1 with HTTP; Tue, 16 Sep 2014 20:14:55 -0700 (PDT) In-Reply-To: <54174CBB.7070007@dcrocker.net> References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> Date: Wed, 17 Sep 2014 04:14:55 +0100 Message-ID: From: Dave Cridland To: Dave Crocker Content-Type: multipart/alternative; boundary=e89a8f92410eb4fb5f05033a4532 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mXhORypiFqFeN0VFYeK2QF773kM Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition 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, 17 Sep 2014 03:14:58 -0000 --e89a8f92410eb4fb5f05033a4532 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15 September 2014 21:31, Dave Crocker wrote: > On 9/15/2014 1:31 PM, Carsten Bormann wrote: > > On 15 Sep 2014, at 22:22, Dave Crocker wrote:>> A > "definition" is usually relatively short, measured by a few > >> sentences. > > > > Sure, =E2=80=9CREST, short for Representational State Transfer, is an > > architectural style defined in [REST].=E2=80=9D > > > > I doubt one can capture the essence of REST in a few sentences. > > > That's almost certainly a problem. It suggests a poor community > understanding of its essence. > > I think you're misunderstanding. "REST" is not a technical term, but a religious one. > Given how ingrained the term is and for how long it has been used, the > problem is probably not a minor one. > > Right. Consider: "To some extent, people get REST wrong because I failed to include enough detail on media type design within my dissertation. That=E2=80=99s because = I ran out of time, not because I thought it was any less important than the other aspects of REST. Likewise, I suspect a lot of people get it wrong because they read only the Wikipedia entry on the subject, which is not based on authoritative sources." (Roy Fielding, 2008). What he's saying here is that: a) The thesis is incomplete. b) Any other document is not "authoritative". The net result is that there exists no description of REST, and therefore nothing to cite. Dave. --e89a8f92410eb4fb5f05033a4532 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 15 September 2014 21:31, Dave Crocker <dhc@dcrocker.net> wrote:
On 9/15/2014 1:31 PM, Carst= en Bormann wrote:
> On 15 Sep 2014, at 22:22, Dave Crocker <dhc@dcrocker.net> wrote:>> A "definition" i= s usually relatively short, measured by a few
>> sentences.
>
> Sure, =E2=80=9CREST, short for Representational State Transfer, is an<= br> > architectural style defined in [REST].=E2=80=9D
>
> I doubt one can capture the essence of REST in a few sentences.


That's almost certainly a problem.=C2=A0 It suggests a poor comm= unity
understanding of its essence.


I think you're misunderstanding. &= quot;REST" is not a technical term, but a religious one.
=C2= =A0
Given how ingrained the term is and for how long it has been used, the
problem is probably not a minor one.


Right. Consi= der:

"To some extent, people get REST wro= ng because I failed to include enough detail on media type design within my= dissertation. That=E2=80=99s because I ran out of time, not because I thou= ght it was any less important than the other aspects of REST. Likewise, I s= uspect a lot of people get it wrong because they read only the Wikipedia en= try on the subject, which is not based on authoritative sources." (Roy= Fielding, 2008).

What he's saying here= is that:

a) The thesis is incomplete.
b= ) Any other document is not "authoritative".

=
The net result is that there exists no description of REST, and theref= ore nothing to cite.

Dave.
--e89a8f92410eb4fb5f05033a4532-- From nobody Wed Sep 17 01:30:03 2014 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 ED2711A0046 for ; Wed, 17 Sep 2014 01:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhHyfhStn_dc for ; Wed, 17 Sep 2014 01:29:58 -0700 (PDT) Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEA81A0013 for ; Wed, 17 Sep 2014 01:29:58 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1XUAcf-0002xS-dE; Wed, 17 Sep 2014 09:29:57 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1XUAce-0005Ip-29; Wed, 17 Sep 2014 09:29:57 +0100 Message-ID: <5419466B.6080403@ninebynine.org> Date: Wed, 17 Sep 2014 09:29:31 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Fletcher T. Penney" , apps-discuss@ietf.org References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> <54181186.4030507@ninebynine.org> <541844C3.2030200@ninebynine.org> <541868BD.3040501@fletcherpenney.net> In-Reply-To: <541868BD.3040501@fletcherpenney.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/d7kCzIhpzA485sjaILMDXfJ3knQ Subject: Re: [apps-discuss] Request additional reviewer for Markdown 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, 17 Sep 2014 08:30:02 -0000 On 16/09/2014 17:43, Fletcher T. Penney wrote: > In the interest of furthering discussion... > > I actually prefer the opposite (well -- keep `processor`, but get rid of > `processor-args` and the feature list) . > > > From a practical standpoint, are there more than 10 people in the world who are > going to define lists of arguments to ask for specific features from > Markdown-like processors, when those specific features aren't even clearly > defined anywhere? Who's going to write software to take an arbitrary feature > list, and then try to match it up with the ever-growing number of Markdown-like > implementations, each with their own slightly different take on features and > syntax? > > > For example, you request "footnote" support. Do you mean MultiMarkdown > footnotes? PHP Markdown Extra Footnotes? Pandoc footnotes? Something else? > As for MMD, do you mean the more recent footnotes that include "inline" > footnotes, or just the old-school reference style footnotes? Which HTML > formatting do you mean? Wrapped in a `
`? Mixed in with citations, or as > two separate lists? > > You think CommonMark sparked a ####storm? I imagine that trying to define a > canonical feature list is likely to cause just as big of one.... Who gets to > keep "footnote" and who gets stuck with "footnote-brand-x"? > > Standardizing certain features across implementations would be nice. It has > been brought up countless times on the discussion list without any traction. > IMO, this effort is not the forum to try to sneak that in through the back door. > > I think this is a very deep rabbit hole that is unlikely to lead to anything > concretely useful. It was not my intent in suggesting to stick with rules rather than processors to define a One True Way for every feature. It would be perfectly reasonable in my view to introduce a rule that corresponds to a set of features supported by a particular processor (I mentioned GitHub as an example previously). But I think it's also useful to be able to refer to particular features in isolation from a processor, as then there's a possibility for a community of use to converge around some set of features. E.g. Scholarly Markdown [1] might be expressed in such terms. [1] http://blog.martinfenner.org/2013/06/17/what-is-scholarly-markdown/ > > On the other hand, if you say "Pandoc", then I have a rough idea of what is > likely to work and what isn't when I use MultiMarkdown instead. I also have an > obvious solution handed to me and giftwrapped -- use pandoc if the document > isn't parsing as expected. As a user, a list of expected features would not be > particularly helpful in troubleshooting. Hmmm, but specifying just "Pandoc" wouldn't tell you what Pandoc options should be used when rendering a document. Rules that can specify individual features could encompass that, IMO. My suggested starting point for populating a table of rules (I'm skirting around the term "registry" here) would be to look at the various features that can be enabled in Pandoc by command line switches, plus a few common feature sets like 'original', 'github', 'pandoc-default', etc. We don't currently have enough experience to know how to best describe Markdown flavours, particularly in a way that maximizes interoperability, so I'd argue for simplicity and flexibility, which I think a list of "rules" can be. #g -- > > On 9/16/14, 10:10 AM, Graham Klyne wrote: > >> 3. I'd prefer to see the 'processor' and 'processor-args' parameters >> dropped completely, and focus on creating a tabulation of rules to >> capture information >> about the varieties of Markdown that are actually used. >> >> (And a thought: rather than requiring the rule definitions to resolve >> any potential conflicts between themselves, have a simple left-to-right >> processing of parameters such that where there is a conflict, parameters >> appearing later in the list override earlier ones. That would provide a >> well-defined way to say something like "github flavoured markdown, >> except that newlines are not rendered as line breaks in the output".) >> >> #g >> -- >> >> >> On 16/09/2014 11:31, Graham Klyne wrote: >>> On 16/09/2014 07:15, Sean Leonard wrote: >>>> draft-ietf-appsawg-text-markdown-01.txt >>> >>> Reviewing https://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-01 >>> >>> >>> # 1. Introduction >>> >>> First para (Nit): >>> >>> This seems a bit bloated. I don't think anything relevant is lost by >>> deleting >>> from "Compare with [RFC6838] Section 4.2.1." to the end of the paragraph. >>> >>> >>> Para starting "Markdown specifically is a family of syntaxes..." (nit): >>> >>> I would be inclined to remove the text >>> >>> "Fed >>> up with the complexity and security pitfalls of formal markup >>> languages (e.g., HTML5) and proprietary binary formats (e.g., >>> commercial word processing software), yet unwilling to be confined to >>> the restrictions of plain text," >>> >>> and leave just "Many users have turned to Markdown for document >>> processing" >>> >>> >>> # 2. Markdown Media Type Registration Applications >>> >>> >>> General: >>> >>> I have my doubts about creating a registry of processors. Could the >>> required >>> information for interoperability not be captured by capturing the >>> processor >>> capabilities as rules? >>> >>> For comparison, consider the example of HTTP feature negotiation (type, >>> language, encoding, etc.) vs UA string testing and/or user-agent >>> sniffing, which >>> is frequently regarded as a poor way to do content matching. This >>> specification >>> appears to be blessing an approach analogous to UA string testing. >>> >>> Maybe this was discussed and I missed it? >>> >>> >>> The description of "processor-args" seems odd to me - it seems to tie >>> the media >>> type string to a particular form of implementation (posix commands). >>> Would it >>> not be more flexible to use some kind of attribute/value list (e.g. >>> similar to >>> media type parameters themselves), and let the application turn them into >>> command line options or environment variables or whatever is needed? >>> (As you >>> plan to allow references to web resources here, maybe use something >>> like encoded >>> JSON, which can be a common representation for direct or indirect >>> values?) >>> >>> I think such an approach could also sidestep some of the unresolved >>> security >>> concerns in the draft (e.g. [[TODO: discuss the implications of >>> processor-args, >>> and safeguards.]], etc.) >>> >>> >>> Para "Interoperability considerations": >>> >>> Contains the text: "When it is desirable to reflect the author's >>> intent in the >>> output, stick with the flavor identified in the flavor parameter." >>> What is this >>> "flavor" parameter? I'm not seeing it. >>> >>> [later: looks like left over from a previous incarnation - maybe worth >>> a global >>> search for changed names?] >>> >>> >>> # 4. IANA Considerations >>> >>> Is it really necessary to have "expert review" for these registries? >>> That >>> requires a volunteer and may impose some additional overhead on IANA. >>> Would >>> "First come first served" not work here? >>> >>> What are the requirements for updating a registry entry? I'd suggest >>> including >>> an "escape" clause that allows IESG or an IETF-stream RFC to update >>> any entry. >>> (I'd trust the community to not do this capriciously). >>> >>> Rather than reserve some names for future use, why not just >>> pre-register them >>> (even if the descriptions are vague for now, allowing that they can be >>> updated >>> later)? >>> >>> #g >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Wed Sep 17 09:20:52 2014 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 3D51D1A067B for ; Wed, 17 Sep 2014 09:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pnq2hSkYnDYL for ; Wed, 17 Sep 2014 09:20:47 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ABB91A0675 for ; Wed, 17 Sep 2014 09:20:47 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id m20so2436706qcx.25 for ; Wed, 17 Sep 2014 09:20:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0W25Agu9qQUrUYhut3q2GduJ9q42osZ0CQ8ilOK5dDw=; b=QVvlpMSKi5gp5ocOnikKbZSU+5UVXgcEy8745NDWW+7sCwAEYb2+ZMou+dXK+oL9gd zeuQdOQ9ygFlqQZlqilLP5Q+lxX7AIEb8f7PKccc9HV+fm+860aluMKPomxWuxaXsN2G mPR+rsQNnzH1FABDv/4wOyOR9P3CZxwrPUOSj94AlJChrochFgQzbaLXuDdzGTM8THuF qI2Afs9WpwYIJbuGv6z9yQTe3HSrTeZYTrtK1r4lhD1t9tAOdRc5SkV2/54S+V1S5uXo ofia41Vym7ky7eoF5W8sVtyZVGKsJpeg+xVnGEvh9tf41eS2B45pVGbZZ30vcI9hkZEu RWcA== X-Gm-Message-State: ALoCoQm9X23nW3Bm8Or5SjD/z354PpsCORU2SfDieSEh7DqiffjlaJqwan9PjqhEvCfrd5YGXTej MIME-Version: 1.0 X-Received: by 10.224.151.69 with SMTP id b5mr27887040qaw.25.1410970846101; Wed, 17 Sep 2014 09:20:46 -0700 (PDT) Received: by 10.140.47.108 with HTTP; Wed, 17 Sep 2014 09:20:45 -0700 (PDT) X-Originating-IP: [2001:500:4:15:a9bd:8de9:5ad8:3cc1] In-Reply-To: References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <6EE29D08-4254-448E-821D-722756E1810C@tzi.org> Date: Wed, 17 Sep 2014 12:20:45 -0400 Message-ID: From: Andrew Newton To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/IurKqSvu1449Lx8UvxHeVKtbPHQ Cc: Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition 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, 17 Sep 2014 16:20:49 -0000 On Tue, Sep 16, 2014 at 2:20 PM, Tim Bray wrote: > Seriously, I would actually ask whether your need is to appeal to the ful= l > intellectual apparatus of REST, or simply to say =E2=80=9CWe=E2=80=99re u= sing 4-verb HTTP > and respecting the idempotence semantics=E2=80=9D. Because in a huge pro= portion of > case, the latter is what people really mean. And there=E2=80=99s nothing= wrong with > that. +1 Additionally, I have found that many people use the term "RESTful" to mean this practical thing they are trying to do and not the whole REST "religion". -andy From nobody Wed Sep 17 10:26:56 2014 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 8F1501A05D3 for ; Wed, 17 Sep 2014 10:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.653 X-Spam-Level: X-Spam-Status: No, score=-3.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652, 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 a0J8wLfcCgI0 for ; Wed, 17 Sep 2014 10:26:53 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883C61A0491 for ; Wed, 17 Sep 2014 10:26:53 -0700 (PDT) Received: from splunge.local (c-50-136-244-117.hsd1.ca.comcast.net [50.136.244.117]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id s8HHQiIS014432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 17 Sep 2014 10:26:46 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1410974806; bh=7UVN8Q9TbP4jlQfrzdpfLA3JmtBdChEPGhvifKPECUg=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=RXqhXpKsMX6GAPUIQQTaIvMpKoWdwz/kPeOXky8H5zfqqaqKtt8XFMTfi94EivEn1 VV9AZ3Gxk7wbz0P9w8MUxolA2aqpXNc0IN4peaYBftowTDIuAL7rdMSB4idwg37RjF cBEx1KQZXn5lJCOGnLg/GCWSuh9wA6MlKPtqUz6o= Message-ID: <5419C454.2000701@bluepopcorn.net> Date: Wed, 17 Sep 2014 10:26:44 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Carsten Bormann References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <6EE29D08-4254-448E-821D-722756E1810C@tzi.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/xwtTWtEEwXatkHvGi_s004iZmtM Cc: Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition 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, 17 Sep 2014 17:26:54 -0000 On 9/16/14 10:39 AM, Murray S. Kucherawy wrote: > > I hope it's not actually debatable that there are more RFC readers who > know what seconds and green are than who know what REST means. Count me in that group. I avoid using the term REST because I don't know what's included: is the use of GET/POST/PUT/DELETE verbs sufficient (as Tim Bray suggests)? Do I also need to include some flavor of .well-known service discovery? Is there anything special about the way that URIs need to be structured? > > I get that you think a good understanding of REST is ubiquitous; > respectfully, I disagree (because I didn't until recently, for > example), and I'd like to ensure this document accommodates those > readers who don't. > +1 -Jim From nobody Wed Sep 17 10:48:20 2014 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 9D0F81A06E3 for ; Wed, 17 Sep 2014 10:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XsB6L8RIs4a for ; Wed, 17 Sep 2014 10:48:16 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BEA91A02D9 for ; Wed, 17 Sep 2014 10:48:16 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8HHmCTr026769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 17 Sep 2014 10:48:16 -0700 Message-ID: <5419C957.9080806@dcrocker.net> Date: Wed, 17 Sep 2014 10:48:07 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: IETF Apps Discuss References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <6EE29D08-4254-448E-821D-722756E1810C@tzi.org> <5419C454.2000701@bluepopcorn.net> In-Reply-To: <5419C454.2000701@bluepopcorn.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 17 Sep 2014 10:48:16 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/EO9wPK0DZN_y4DpiVqNAWqZ2HzE Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 17:48:17 -0000 On 9/17/2014 10:26 AM, Jim Fenton wrote: > On 9/16/14 10:39 AM, Murray S. Kucherawy wrote: >> I get that you think a good understanding of REST is ubiquitous; >> respectfully, I disagree (because I didn't until recently, for >> example), and I'd like to ensure this document accommodates those >> readers who don't. >> > +1 The IETF has been showing a pattern of willingness to invoke language that has tends to have little shared meaning. What is ironic is that we are in the business of creating specifications that are precise enough to permit interoperability, yet we are not inclined to do the same with the vocabulary we use. One piece of this problem seems to stem from a failure to distinguish between those already deeply immersed in the topic (and its vocabulary), versus the rest of the Internet community -- those other folk who will read the new document and use the new term -- that is not immersed, and that therefore needs concise and tutorial support material. Telling such folk that the 'meaning' of a term requires reading an entire tome is merely a way of preventing informed participation by them. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Sep 19 10:32:27 2014 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 560FA1A04B1; Fri, 19 Sep 2014 10:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gf2n99CMX-VU; Fri, 19 Sep 2014 10:32:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 330BA1A04A4; Fri, 19 Sep 2014 10:32:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140919173225.28890.36281.idtracker@ietfa.amsl.com> Date: Fri, 19 Sep 2014 10:32:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/EV5jXU5_JmZpajU50zG08HSjWyE Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-http-problem-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 17:32:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Problem Details for HTTP APIs Authors : Mark Nottingham Erik Wilde Filename : draft-ietf-appsawg-http-problem-00.txt Pages : 13 Date : 2014-09-19 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 invent new error response formats for HTTP APIs. Note to Readers This draft should be discussed on the apps-discuss mailing list [1]. 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: http://tools.ietf.org/html/draft-ietf-appsawg-http-problem-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 19 11:37:36 2014 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 D80A21A6FB7 for ; Fri, 19 Sep 2014 11:37:29 -0700 (PDT) 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 zUjnG40AtXyi for ; Fri, 19 Sep 2014 11:37:25 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BC2B1A6FB1 for ; Fri, 19 Sep 2014 11:37:25 -0700 (PDT) Received: from [172.30.74.57] (unknown [23.79.231.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 658AD50A86; Fri, 19 Sep 2014 14:37:22 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Mark Nottingham In-Reply-To: Date: Fri, 19 Sep 2014 11:37:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <561C70B6-7D61-4ECA-92B4-0DB6F3BB50FD@mnot.net> References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/DX1GlJy3zxD4TCe8HK-B9dpRud8 Cc: Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition 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, 19 Sep 2014 18:37:30 -0000 Hey Murray, On 15 Sep 2014, at 3:57 pm, Murray S. Kucherawy = wrote: > I asked this question because there's a document in a WG I'm chairing = (not this one) that I believe needs such a definition, either included = or referenced. I'm happy to push for such a definition to be included = in that document, but only if one can be found or generated, such that = it has consensus, in fairly short order because we have a timeline to = which we're trying to adhere. I think the important question here is why the WG thinks it needs a = reference. If it=92s just a non-normative link to more information about the design = choices made in a protocol, referencing Roy=92s thesis is entirely = appropriate (although I wonder if ti=92s necessary; the IETF isn=92t = publishing academic papers=85). If it=92s trying to assert that a protocol has particular properties, or = conforms to a particular worldview, it may be more trouble than it=92s = worth, since (as we=92ve seen), the term REST means many things to = different people. I can think of several things that are better to do than this with the = IETF=92s time. Normally I wouldn=92t mind in selected participants = having their time consumed by such an effort, but if the output were to = try to =93define=94 REST normatively, I suspect that it would end up = consuming a lot of my time (and Roy=92s, and others=92), and so I would = object to starting this work. Cheers, -- Mark Nottingham http://www.mnot.net/ From nobody Fri Sep 19 11:45:54 2014 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 B1B1E1A06E1 for ; Fri, 19 Sep 2014 11:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, 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 RmWUzSH9ZxZN for ; Fri, 19 Sep 2014 11:45:47 -0700 (PDT) Received: from nm3-vm8.bullet.mail.gq1.yahoo.com (nm3-vm8.bullet.mail.gq1.yahoo.com [98.136.218.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A23A81A064B for ; Fri, 19 Sep 2014 11:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1411152346; bh=fpCY2UF7qTRSTqMYWdfeIn1/Oyxae1wS31NiJffDn1k=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Gm-Message-State:X-Received:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc:Content-Type:From:Subject; b=Iz3e1vlxApv467P/u6KwKX+uat8R2LQaQLHQRKslBaJglCcozhAyf1On2G+5U6VHG2NbnJyOfBYW2xAyNPmgFETyss96lrzVbAYrcJ0b1wBYKuxoLm9o+6FQNN4rNbQZwHKjAQGVQALp1dPNBIkg8KPU7VMZi/piT42wIWKo55iJaA1lofQpAZPd9oTOdqWdB4nxEiXxK5XN0bZNU9DszNkprPL4mJRxRuysD7b3TPPWieMHoSna5LM2cHz1jQbFUUn/icr5BZdxBWMVjVewQk6Kfi28TmdqNnT+2H1ng4q4OQScSc3557ePFKk6HaYtla73XwdhrP1DcCjg906Qjg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=t9HqdqY19GgyCuXHI68HEfWIBT2GD+vCjPBtjEnBVETbjteCo/uRY/7V3MMW5mhKqHe16ks4IpLFkDiWN++MR+JB9D9d+h68YcTSVbtYVYk/MKdUCA/lLRP/7O9Mcxbo36JJkVde7KaVwdMUoqLhlzi0lm3gnDU9/idwM+IZDfXGMwP5EPWftyfP0TiviX2gfN8dXJeX2vd1HvCvGC6GkNobkVy6tkkD7EHwhLGgpFOFrlc56lkULuVnjffF+j6n3SKDXRu0GXwpV5fyI53P9u26ss7yuok4Pmf+qQhftj5xQ96RXCP983YeuaJVwrZWxonCDEy8gWVRNuKqmW43hw==; Received: from [216.39.60.183] by nm3.bullet.mail.gq1.yahoo.com with NNFMP; 19 Sep 2014 18:45:46 -0000 Received: from [208.71.42.206] by tm19.bullet.mail.gq1.yahoo.com with NNFMP; 19 Sep 2014 18:45:46 -0000 Received: from [127.0.0.1] by smtp217.mail.gq1.yahoo.com with NNFMP; 19 Sep 2014 18:45:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1411152346; bh=fpCY2UF7qTRSTqMYWdfeIn1/Oyxae1wS31NiJffDn1k=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Gm-Message-State:X-Received:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=qIx/Cva+9HHT2OLqbvVMsby3UViMHZCgyKWZj4riFS9PgBT9570Cta0i6Nv0hJxT72gl5ZD6En18G5z/bOkA34LzjEnf2BdnPmzzxy3KQZreNHqncx49MSMHOjuiANDee6XRDfj0ZSn2AYjLA6+5dkpYAs7af+hydY7W3wxRBhU= X-Yahoo-Newman-Id: 304515.1554.bm@smtp217.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: mD_xk_4VM1mT3yo_T16VGw5oezIY6ow7KpdLl6CO6cKe_Eg 1_9uXW8NqpmNQ5BZu6ChJxhoMK5ZZB7uLYDD_e0eXTxxRIStx_1zm7J6YeD1 dJtjFfMuP9joS6sV.TbPQiNVEzEsGkWr5qeUM7XMGv3e3j8uZcuvJO5vBMXY UpC8XMrj8uqg4lTFn9Hl5793A.0he_CqaIYrBpwROKr1VsbGDfF3W63qkjOz e7LsknbQ2FqM888r5wU_6i0Vs58zAtLzhz7JCh0V2iOjJKfnrFdwilnfWWNV V7I75qUqmsFEbGUcmpxokfcfcavpYfh_rKX0OI4HWvb1PIDgtsnQfE_Kz6zg p0y94t4e72ju9B1viB8gpqotmPbaQIiGL_T_3gihZrf5RG5T9jVdCHQKIimX c7xdrwSnjRlHQCWxJODQQ2YM8Yct6pWwjMMb3cddh47TYoofwfp90bbyN2Yl nsomXcvYrBem7VC5o0GF2Xt.oSdiDawArpPHsodzRlLUG_qw..pNL_zP7ryF sRxCsd2eyGfqlhd3iW4IFEBDszqWRG__kYixe15uEawheiNDoOLEx.drOCAF nnzM7XEuyIyAQY7iONmwGKj9fStp7WsjVhS4prwDho.UtG1f4jtcLKkgI5fu ReEJ4Mme0SriEVR4lGLigx2l24SruKzV1CeyMdpWOSTdnhDqEzUbNR_HnqOz SeSk8VIz.WSTthIo2JT.p81kRFFoCZTGNRy8Sihvy16Eo43wxvvG.9WOrJC5 Ps9_PAznE2PnmKOYD5iBk9D4- X-Yahoo-SMTP: i12ABOmswBAkPG1PnjmsmmFRWA-- Received: by mail-qc0-f173.google.com with SMTP id i8so3604301qcq.32 for ; Fri, 19 Sep 2014 11:45:45 -0700 (PDT) X-Gm-Message-State: ALoCoQkyDV16J0VMdz9gXmdUdrj7ceTZTe96+oEkhfUQJSGLVPK12rS6gL2HK4Cy7BW1t7axZjxb X-Received: by 10.224.20.9 with SMTP id d9mr3148933qab.7.1411152345261; Fri, 19 Sep 2014 11:45:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.186.197 with HTTP; Fri, 19 Sep 2014 11:45:24 -0700 (PDT) In-Reply-To: <561C70B6-7D61-4ECA-92B4-0DB6F3BB50FD@mnot.net> References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <561C70B6-7D61-4ECA-92B4-0DB6F3BB50FD@mnot.net> From: mike amundsen Date: Fri, 19 Sep 2014 14:45:24 -0400 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a11c1c56043a4d605036f82fc Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/NA5tg2JoWJNnqqkQllv65cespP0 Cc: Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition 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, 19 Sep 2014 18:45:49 -0000 --001a11c1c56043a4d605036f82fc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable if the output were to try to =E2=80=9Cdefine=E2=80=9D REST normatively, I s= uspect that it would end up consuming a lot of my time (and Roy=E2=80=99s, and others=E2= =80=99), and so I would object to starting this work. would you feed differently if this was about creating a reference for an informative definition? mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://linkedin.com/in/mamund On Fri, Sep 19, 2014 at 2:37 PM, Mark Nottingham wrote: > Hey Murray, > > On 15 Sep 2014, at 3:57 pm, Murray S. Kucherawy > wrote: > > > I asked this question because there's a document in a WG I'm chairing > (not this one) that I believe needs such a definition, either included or > referenced. I'm happy to push for such a definition to be included in th= at > document, but only if one can be found or generated, such that it has > consensus, in fairly short order because we have a timeline to which we'r= e > trying to adhere. > > I think the important question here is why the WG thinks it needs a > reference. > > If it=E2=80=99s just a non-normative link to more information about the d= esign > choices made in a protocol, referencing Roy=E2=80=99s thesis is entirely > appropriate (although I wonder if ti=E2=80=99s necessary; the IETF isn=E2= =80=99t publishing > academic papers=E2=80=A6). > > If it=E2=80=99s trying to assert that a protocol has particular propertie= s, or > conforms to a particular worldview, it may be more trouble than it=E2=80= =99s worth, > since (as we=E2=80=99ve seen), the term REST means many things to differe= nt people. > > I can think of several things that are better to do than this with the > IETF=E2=80=99s time. Normally I wouldn=E2=80=99t mind in selected partici= pants having their > time consumed by such an effort, but if the output were to try to =E2=80= =9Cdefine=E2=80=9D > REST normatively, I suspect that it would end up consuming a lot of my ti= me > (and Roy=E2=80=99s, and others=E2=80=99), and so I would object to starti= ng this work. > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a11c1c56043a4d605036f82fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<snip>
if the output were to try to =E2=80=9Cdefine=E2=80=9D RE= ST normatively, I suspect that it would end up consuming a lot of my time (= and Roy=E2=80=99s, and others=E2=80=99), and so I would object to starting = this work.
=
<= /snip>

would you feed differently if this = was about creating a reference for an informative=C2=A0definition?


<= /div>


On Fri, Sep 19, 2014 at 2:37 PM, Mark Nottin= gham <mnot@mnot.net> wrote:
He= y Murray,

On 15 Sep 2014, at 3:57 pm, Murray S. Kucherawy <superuser@gmail.com> wrote:

> I asked this question because there's a document in a WG I'm c= hairing (not this one) that I believe needs such a definition, either inclu= ded or referenced.=C2=A0 I'm happy to push for such a definition to be = included in that document, but only if one can be found or generated, such = that it has consensus, in fairly short order because we have a timeline to = which we're trying to adhere.

I think the important question here is why the WG thinks it needs a = reference.

If it=E2=80=99s just a non-normative link to more information about the des= ign choices made in a protocol, referencing Roy=E2=80=99s thesis is entirel= y appropriate (although I wonder if ti=E2=80=99s necessary; the IETF isn=E2= =80=99t publishing academic papers=E2=80=A6).

If it=E2=80=99s trying to assert that a protocol has particular properties,= or conforms to a particular worldview, it may be more trouble than it=E2= =80=99s worth, since (as we=E2=80=99ve seen), the term REST means many thin= gs to different people.

I can think of several things that are better to do than this with the IETF= =E2=80=99s time. Normally I wouldn=E2=80=99t mind in selected participants = having their time consumed by such an effort, but if the output were to try= to =E2=80=9Cdefine=E2=80=9D REST normatively, I suspect that it would end = up consuming a lot of my time (and Roy=E2=80=99s, and others=E2=80=99), and= so I would object to starting this work.

Cheers,

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



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

--001a11c1c56043a4d605036f82fc-- From nobody Fri Sep 19 11:49:04 2014 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 806EB1A04FA for ; Fri, 19 Sep 2014 11:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_38=0.6, 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 xqnH5Q4elD2F for ; Fri, 19 Sep 2014 11:49:01 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E67F51A0456 for ; Fri, 19 Sep 2014 11:49:00 -0700 (PDT) Received: from [172.30.74.57] (unknown [23.79.231.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BB870509B6; Fri, 19 Sep 2014 14:48:58 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Mark Nottingham In-Reply-To: Date: Fri, 19 Sep 2014 11:48:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <561C70B6-7D61-4ECA-92B4-0DB6F3BB50FD@mnot.net> To: mike amundsen X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XMZQSA_-oQQsEmX0EUORLD67xqc Cc: Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition 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, 19 Sep 2014 18:49:03 -0000 Not really. I see many potential downsides, not a lot of upside. Now, if someone wanted to go off and write such a document = optimistically, and was willing to bring it here to have arrows thrown = at it, it could be interesting. It=92s just that all of the people who = are most qualified to write such a thing are really busy. YMMV, of course. Cheers, On 19 Sep 2014, at 11:45 am, mike amundsen wrote: > > if the output were to try to =93define=94 REST normatively, I suspect = that it would end up consuming a lot of my time (and Roy=92s, and = others=92), and so I would object to starting this work. > >=20 > would you feed differently if this was about creating a reference for = an informative definition? >=20 >=20 >=20 >=20 > mamund > +1.859.757.1449 > skype: mca.amundsen > http://amundsen.com/blog/ > http://twitter.com/mamund > https://github.com/mamund > http://linkedin.com/in/mamund >=20 > On Fri, Sep 19, 2014 at 2:37 PM, Mark Nottingham = wrote: > Hey Murray, >=20 > On 15 Sep 2014, at 3:57 pm, Murray S. Kucherawy = wrote: >=20 > > I asked this question because there's a document in a WG I'm = chairing (not this one) that I believe needs such a definition, either = included or referenced. I'm happy to push for such a definition to be = included in that document, but only if one can be found or generated, = such that it has consensus, in fairly short order because we have a = timeline to which we're trying to adhere. >=20 > I think the important question here is why the WG thinks it needs a = reference. >=20 > If it=92s just a non-normative link to more information about the = design choices made in a protocol, referencing Roy=92s thesis is = entirely appropriate (although I wonder if ti=92s necessary; the IETF = isn=92t publishing academic papers=85). >=20 > If it=92s trying to assert that a protocol has particular properties, = or conforms to a particular worldview, it may be more trouble than it=92s = worth, since (as we=92ve seen), the term REST means many things to = different people. >=20 > I can think of several things that are better to do than this with the = IETF=92s time. Normally I wouldn=92t mind in selected participants = having their time consumed by such an effort, but if the output were to = try to =93define=94 REST normatively, I suspect that it would end up = consuming a lot of my time (and Roy=92s, and others=92), and so I would = object to starting this work. >=20 > Cheers, >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 -- Mark Nottingham http://www.mnot.net/ From nobody Fri Sep 19 14:47:42 2014 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 45F701A0AE5 for ; Fri, 19 Sep 2014 14:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BIUhIUguVvsV for ; Fri, 19 Sep 2014 14:47:38 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0619.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:619]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819641A88B6 for ; Fri, 19 Sep 2014 14:47:36 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB417.namprd02.prod.outlook.com (10.141.94.11) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Fri, 19 Sep 2014 21:47:13 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.1034.003; Fri, 19 Sep 2014 21:47:13 +0000 From: Larry Masinter To: Erik Wilde Thread-Topic: [apps-discuss] RESTful definition Thread-Index: AQHP0SH+tn2U17DDnE2kiKhgp65yKpwCog0AgAAaFYCAABEYAP///6YAgAAD7gCAAQYBgIAABTKAgAUmPbA= Date: Fri, 19 Sep 2014 21:47:13 +0000 Message-ID: References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54176D6A.2020903@dcrocker.net> <1CD55F04538DEA4F85F3ADF7745464AF24C4C7B1@S-BSC-MBX1.nrn.nrcan.gc.ca> <541850DB.1050705@berkeley.edu> In-Reply-To: <541850DB.1050705@berkeley.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.150.10.210] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0339F89554 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(24454002)(13464003)(377424004)(189002)(199003)(377454003)(76576001)(15975445006)(74316001)(21056001)(95666004)(15202345003)(85306004)(108616004)(90102001)(31966008)(93886004)(74662003)(80022003)(74502003)(81542003)(79102003)(2171001)(97736003)(92566001)(46102003)(81342003)(77982003)(110136001)(86362001)(19580405001)(19580395003)(83322001)(87936001)(66066001)(64706001)(15395725005)(2656002)(85852003)(76482002)(83072002)(4396001)(106116001)(50986999)(20776003)(99396002)(54356999)(101416001)(99286002)(76176999)(107046002)(105586002)(106356001)(33646002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR02MB417; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zA3M_QWKDi7pbWW8lKxkCxh7rJM Cc: Roy Fielding , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RESTful definition 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, 19 Sep 2014 21:47:40 -0000 "Defining" the term doesn't seem useful. But what about a BCP Best Current= Practice "Guidelines for creating RESTful services Protocols" with a focus on summarizing what future IETF application protocol designers= SHOULD do to be RESTful, and when they SHOULD do it. BCPs carry some weight but allow for exceptions and evolution. If REST isn'= t a 'best current practice' we should stop talking about it. If it is, then= a summary of why and when seems just right for BCP. > -----Original Message----- > From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Er= ik > Wilde > Sent: Tuesday, September 16, 2014 8:02 AM > To: Rushforth, Peter; IETF Apps Discuss > Subject: Re: [apps-discuss] RESTful definition >=20 > hello. >=20 > having spent considerable time and energy in the REST space, i think it w= ould be > great if the IETF had some minimal guidance on what it is, why it matters= , and > what people might want to consider when trying to be RESTful. >=20 > there are two extremes: >=20 > - one is to be pure and insist on the fact that REST is not a technology,= but an > architectural style. this is "correct", but most people think this is not= very > helpful. >=20 > - tim bray's pragmatic view that anything using HTTP these days is being = sold as > RESTful. this is a bit sad, but this is how it is. >=20 > a useful definition would be in between. focusing on actual technologies,= but > still making explicit statements about the things that matter for being R= ESTful. >=20 > On 2014-09-16, 7:43 , Rushforth, Peter wrote: > > Although there are many overloaded words in language, REST has been > > underloaded, in the sense that the some of the important qualities that= the > term was coined to describe and evoke have been discarded by > > common usage. Perhaps HATEOAS is *the most* important such quality, = as > it forms the basis of the standard > > Web, which currently separates us from platformification or what have y= ou. >=20 > REST really does not define that many constraints, and hypermedia is an > important one. at least highlighting that (even if people often choose to= ignore > it) might be helpful to some. >=20 > in my experience, people that just want to call something "REST" because = it's > hip or sells better will not care about descriptions or guidelines anyway= . they > just want the branding. but there also are many who are a bit confused by= "The > Definition" (it's not a technology, it's an architectural style) and the = use of the > term out in the wild. those people might be served very well with a conci= se > document that makes some simple statements about what matters most. >=20 > cheers, >=20 > dret. >=20 > -- > erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | > | UC Berkeley - School of Information (ISchool) | > | http://dret.net/netdret http://twitter.com/dret | >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Fri Sep 19 14:48:40 2014 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 C1E8E1A875F for ; Fri, 19 Sep 2014 14:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVmzGCXEEYbE for ; Fri, 19 Sep 2014 14:48:31 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1411B1A8768 for ; Fri, 19 Sep 2014 14:48:30 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id n15so4000233lbi.34 for ; Fri, 19 Sep 2014 14:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q8bk6ZaB/OArGm8dmaFj3f8Y2qbSQKbahPcDL7WOxtI=; b=QGRPunJIN2JoPKHjp20qLoDWEcou4rnORuRELZFI6Ba9JckcQNLyEuXqvhiTBu1HrR uCli57PcnexTfSMcNx6yfJIZVVd/0gFglLYOk+SbJ3UAGgDGdJk7EqG/3rG4dMnd+/8C 8XKOQKSWvXGfM/DszZ5HtvPaOD1RjTtIBmXrBB8OD1xPDvrxoe9hce6FQfz9rEoz0tQl P/7F6l3pQyblPTFM1fdI80RGzTeEBIrrC/rHcQbe3BEAjacEyVq6vuAD01ECmQYu/McC TvX6ozIwbYG53S1xbiNT7860E81jX7/WP+VJCu/090h4SzPN3ftIp9FKQX4abS/ZTsY5 0l/g== MIME-Version: 1.0 X-Received: by 10.112.171.202 with SMTP id aw10mr8896976lbc.52.1411163309218; Fri, 19 Sep 2014 14:48:29 -0700 (PDT) Received: by 10.25.211.7 with HTTP; Fri, 19 Sep 2014 14:48:29 -0700 (PDT) In-Reply-To: References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <561C70B6-7D61-4ECA-92B4-0DB6F3BB50FD@mnot.net> Date: Fri, 19 Sep 2014 14:48:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a11c36b22c4201c0503720fdf Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/AqDXWuET9WaO7eA_ic2URjnpHJ0 Cc: Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition 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, 19 Sep 2014 21:48:33 -0000 --001a11c36b22c4201c0503720fdf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Sep 19, 2014 at 11:48 AM, Mark Nottingham wrote: > Not really. I see many potential downsides, not a lot of upside. > > Now, if someone wanted to go off and write such a document optimistically= , > and was willing to bring it here to have arrows thrown at it, it could be > interesting. It=E2=80=99s just that all of the people who are most qualif= ied to > write such a thing are really busy. > > YMMV, of course. > My goal here is pretty simple: We don't like undefined acronyms in RFCs. "Please expand HTTP on first use" has to be something you've seen before in your various document reviews, for example. How do I resolve that when the acronym is REST? -MSK --001a11c36b22c4201c0503720fdf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Sep 19, 2014 at 11:48 AM, Mark Nottingham <mnot@mnot.= net> wrote:
Not really. I see many potential dow= nsides, not a lot of upside.

Now, if someone wanted to go off and write such a document optimistically, = and was willing to bring it here to have arrows thrown at it, it could be i= nteresting. It=E2=80=99s just that all of the people who are most qualified= to write such a thing are really busy.

YMMV, of course.

My goal here is pretty= simple: We don't like undefined acronyms in RFCs.=C2=A0 "Please e= xpand HTTP on first use" has to be something you've seen before in= your various document reviews, for example.

How do I resolve that w= hen the acronym is REST?

-MSK
--001a11c36b22c4201c0503720fdf-- From nobody Fri Sep 19 14:53:09 2014 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 3A35C1A88B8 for ; Fri, 19 Sep 2014 14:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 7mOCzgmwyDQ0 for ; Fri, 19 Sep 2014 14:53:07 -0700 (PDT) Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB4F61A8768 for ; Fri, 19 Sep 2014 14:53:06 -0700 (PDT) Received: from dhcp-128-32-211-233.lips.berkeley.edu ([128.32.211.233]) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1XV66z-0000wd-Gn; Fri, 19 Sep 2014 14:53:06 -0700 Message-ID: <541CA5C0.1060205@berkeley.edu> Date: Fri, 19 Sep 2014 14:53:04 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Larry Masinter References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54176D6A.2020903@dcrocker.net> <1CD55F04538DEA4F85F3ADF7745464AF24C4C7B1@S-BSC-MBX1.nrn.nrcan.gc.ca> <541850DB.1050705@berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/sZHtYU5OEhpHgHaBCTDP61e5QTk Cc: Roy Fielding , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RESTful definition 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, 19 Sep 2014 21:53:08 -0000 hello. On 2014-09-19, 14:47 , Larry Masinter wrote: > "Defining" the term doesn't seem useful. But what about a BCP Best Current Practice there's a fine line between defining and describing, in particular when the authoritative definition itself is on an abstraction level that for most practical purposes is one level too high. > "Guidelines for creating RESTful services Protocols" i like that. summarize patterns and best practices, and leave it at that. that's what in my experience a lot of people already find helpful, and when it's just on the "you might want to consider doing it like this" level, it's less judgmental than a description/definition. > with a focus on summarizing what future IETF application protocol designers SHOULD do to be RESTful, and when they SHOULD do it. ... and why it's a good idea and where it's already used successfully in some existing and deployed solutions. cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From nobody Fri Sep 19 15:14:26 2014 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 52C2F1A88E0 for ; Fri, 19 Sep 2014 15:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87dntan7o_cj for ; Fri, 19 Sep 2014 15:14:22 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A0E1A88D2 for ; Fri, 19 Sep 2014 15:14:22 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id hq11so2468446vcb.39 for ; Fri, 19 Sep 2014 15:14:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qU7FjXZr7whHRBhZ1O8kkPYH09S7G9DAJ5gC9XjPuBU=; b=VNECIbsG7jErxgUWNc9Vp2PqoSP08z3g48BTBk4wuyLIW/Stxo++TJD/uoltWNNme0 SY6LNhdm/fvpOjUoFKzL03dAyt7K3u8EgntcarJkRR1JzGgOYPIjaAkwzQoW8YqMM4R3 ZCJchg21bbZga6d+fYoH81i2iFZbjBtu5P2qd+nAuWfOzyvaETzEWWHknVcbRhCC2YHN AStQOJUSk6cZzwvKqqPfUTf3YcmckGFTbXmK77OXKl3epUAMXsrGptEG7Eo1PXyVdwaa 9Yx0nfBeMf3dhI1fwGvJSJgY20/0lSa9KsDFAQUO8RoIF+C/RfdtD8OnN80UqDJSMwAD JH4w== X-Gm-Message-State: ALoCoQkb1AjCQs8NQm86Mjbo3KC3YU7XLRi2BjRvEXROJ2MhZHRYLJcCk36Euha4EwT+KJBgI+Np X-Received: by 10.221.55.2 with SMTP id vw2mr2329914vcb.29.1411164861251; Fri, 19 Sep 2014 15:14:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.214.4 with HTTP; Fri, 19 Sep 2014 15:14:01 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <561C70B6-7D61-4ECA-92B4-0DB6F3BB50FD@mnot.net> From: Tim Bray Date: Fri, 19 Sep 2014 15:14:01 -0700 Message-ID: To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a1133a0fe4659010503726cf0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/oVK3uXt6uRYSggZci0IHeqD0KLg Cc: Mark Nottingham , Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition 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, 19 Sep 2014 22:14:24 -0000 --001a1133a0fe4659010503726cf0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Murray, the question has been raised a couple of times; apologies if you addressed it and I missed it. What is the context? Are you sure you really mean Representational State Transfer? Are you sure you couldn=E2=80= =99t just get away by saying something like =E2=80=9CThe interface is via HTTP, using the A, B, and C verbs, taking adv= antage of the idempotence characteristics of A and C, with the payload being delivered as application/D, and with a cleanly-designed URI space=E2=80=9D Because there=E2=80=99s nothing in there that you can=E2=80=99t find an goo= d reference for around here. On Fri, Sep 19, 2014 at 2:48 PM, Murray S. Kucherawy wrote: > On Fri, Sep 19, 2014 at 11:48 AM, Mark Nottingham wrote: > >> Not really. I see many potential downsides, not a lot of upside. >> >> Now, if someone wanted to go off and write such a document >> optimistically, and was willing to bring it here to have arrows thrown a= t >> it, it could be interesting. It=E2=80=99s just that all of the people wh= o are most >> qualified to write such a thing are really busy. >> >> YMMV, of course. >> > > My goal here is pretty simple: We don't like undefined acronyms in RFCs. > "Please expand HTTP on first use" has to be something you've seen before = in > your various document reviews, for example. > > How do I resolve that when the acronym is REST? > > -MSK > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a1133a0fe4659010503726cf0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mur= ray, the question has been raised a couple of times; apologies if you addre= ssed it and I missed it. =C2=A0What is the context? =C2=A0Are you sure you = really mean Representational State Transfer? =C2=A0Are you sure you couldn= =E2=80=99t just get away by saying something like=C2=A0

=E2=80=9CThe interface is via HTTP, using th= e A, B, and C verbs, taking advantage of the idempotence characteristics of= A and C, with the payload being delivered as application/D, and with a cle= anly-designed URI space=E2=80=9D

Because there=E2=80=99s nothing in there that you can=E2=80=99t fin= d an good reference for around here.
=
On Fri, Sep 19, 2014 at 2:48 PM, Murray S. K= ucherawy <superuser@gmail.com> wrote:
On Fri, Sep 19, 2014 at 11:= 48 AM, Mark Nottingham <mnot@mnot.net> wrote:
Not really. I see many potential downsides, not a lot of= upside.

Now, if someone wanted to go off and write such a document optimistically, = and was willing to bring it here to have arrows thrown at it, it could be i= nteresting. It=E2=80=99s just that all of the people who are most qualified= to write such a thing are really busy.

YMMV, of course.

My goal here is= pretty simple: We don't like undefined acronyms in RFCs.=C2=A0 "P= lease expand HTTP on first use" has to be something you've seen be= fore in your various document reviews, for example.

How do I resolve= that when the acronym is REST?

-MSK

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




--
- Tim Bray (If you=E2=80=99d like to send me a private messag= e, see https://key= base.io/timbray)
--001a1133a0fe4659010503726cf0-- From nobody Fri Sep 19 15:24:30 2014 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 BDF241A6F34 for ; Fri, 19 Sep 2014 15:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, 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 rwD6pyKK7P9a for ; Fri, 19 Sep 2014 15:24:25 -0700 (PDT) Received: from nm11-vm8.bullet.mail.gq1.yahoo.com (nm11-vm8.bullet.mail.gq1.yahoo.com [98.136.218.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110F31A06BF for ; Fri, 19 Sep 2014 15:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1411165464; bh=A/POqMbCucEWYrSckM8GkayaOI2N3shk/CZjfM+QTZ0=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Gm-Message-State:X-Received:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc:Content-Type:From:Subject; b=qIxg2sSNF9T0xhq8vDRNrgvTq4fjtjYQH40qhcpiUGolj3gBc+8P2Z8ttQSZRPo7u6dvNuQuJEBYq9GVnHXB82nIPRbW6dE+lPoCCHznV181fSRMx47OCMN7tqqX3DPmRg46bR6d3DdY9fYxVMgVGvbNARgqTqB3IIt6o2TWbkdifhD6bc61JUtN05kpS43YSxJ5ocsJFPt2qqlurHLSGp074J8bIg9zj9vwQ5s9l+L3vb2PqfwfXeksTzIMgSoRJp+c8aR/H6ftNqFbxRsKxoxu1ospsp6QXPH5NGY0MddjKcPJfKniRqMw7MBKlX4JhvCYX4srbO+04o+B+vdsZA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=f3VwAMfDdhPybCVQAKJqXY8rHsgjZDSLbOU+SByXc1/eSwVTr/prW6tJPK9XHkV4NGNAeBznJaDLbPZDfKj3NGPjOTgDbXXxCw2rZIDPgM8auPUl5LxDBjI3ctNrm4EQEn6czH7cMdSpeOz2b8+NkMjROTfEd9ZWrSI6J82WgFdi1NxsaitciE0I57I14tbsQ9VPK5mDOD0WuL9fAydJDKn5jBI0XXmRSfYOrS0rfGHjqq65SfHCzUlnZnzCXDUKn+aIhoYtZldhDk2DFqnCrJHz5nmiJM29EKTDbZHekQZxoJ+PevSM3ETLSoQQD7wteQMqhluAha3OLGFxEy2RmQ==; Received: from [98.137.12.174] by nm11.bullet.mail.gq1.yahoo.com with NNFMP; 19 Sep 2014 22:24:24 -0000 Received: from [208.71.42.194] by tm13.bullet.mail.gq1.yahoo.com with NNFMP; 19 Sep 2014 22:24:24 -0000 Received: from [127.0.0.1] by smtp205.mail.gq1.yahoo.com with NNFMP; 19 Sep 2014 22:24:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1411165464; bh=A/POqMbCucEWYrSckM8GkayaOI2N3shk/CZjfM+QTZ0=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Gm-Message-State:X-Received:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=tS88qaqwK/RckbhL2UYf7e+Z/XQjgMbGbx4KjbSJlZ3wzwLhc84YMW6PKDx77PhhcBOsMlRD1IvIvu3I3sbptVqb0kfJXRqx2c16V+/rK4fCstYEFDj5vrxkfg7D04TqrPWVAEvntUSHtXdNC3JTH1irzZ0LFua9yKDFt82Xi50= X-Yahoo-Newman-Id: 761847.2560.bm@smtp205.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 8LOR4.YVM1lx6Wo0qy5vLmc.ripHt5MDTVM_L.PDd..B8c0 Dmmcz.vQ.j337D_HsLV586oXUMCKuC3xRsNVVvXLKtwaA0UDuEVbFCAXv.Ha KetzfVR7uPZe7qH2pvEJcjIBwOV_e3bjoc8U00s3juz.FHT8zUJ722V0ocEU XSPWJZFKReFGi3eB92zfjv_pATG6kcd3oJWqfuu_aBT36.30u_DcQOX6O3Sk t140WFIOw1ukQANG7Tv1__YkUXGni2MxHLs8EuVH9K8vLgNVXd4wh5h5QL5p vhc.NCS1HrKyvILms86BPn9SmNJCDzj_6hajOm2fi0DRbS7YQCT7.wEaVTqF MqpmSYzWW.Amj1DaZO2V1L51r0Srrxr59hJcBIeuWpsP9nSGw5J9ru_SSZVK dR4FGMRYYuniM3.eDRek6fknvhzIA.UZiSXVUl9Y7tOZ3F6sQ_6jmVLQ5Jax ItfhVrL3TctsePXcH4_7wMpjxWF2Tnr9s0Mcd5T1jy8uCadKCLfCKp3CZUx1 _jfAQU9GKm8Pv3JeWGxuURi7Fe2bNLtaNHX2r_Mqg2kBsXRzSyXklLhLwcmB CzDx3P3_rqGb4CtkzTg_BV6P41F7LIllnvoxw3Qt7x0C1T07WS_1Z.aWS1XX AWgYTV2GNoUiFgnOHO0eNWAGG5P3Xk0hEcuX7J03NYOay7WqPLH_MrcreTq6 MjBqK.o.pGPFOamKNsC.5nVLgkMCOH.Kc08D2SXZopFoDQ2vxHNhtpd93jYl Sxk8lmSSUsUi6nV_B2c9UVmPk8e4MQIoxW9syFOxrWeXSZW.ooiRsnORcV0m Q8y8Dkg-- X-Yahoo-SMTP: i12ABOmswBAkPG1PnjmsmmFRWA-- Received: by mail-lb0-f177.google.com with SMTP id z12so4009941lbi.36 for ; Fri, 19 Sep 2014 15:24:22 -0700 (PDT) X-Gm-Message-State: ALoCoQkwUK1oluOy/gkTlKWEtc5LLqaGxpNMpTQaK690DqIj5d1/BacKoikSIO7d4Z4dQiKL5CHT X-Received: by 10.112.198.228 with SMTP id jf4mr9008983lbc.35.1411165462510; Fri, 19 Sep 2014 15:24:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.218.8 with HTTP; Fri, 19 Sep 2014 15:24:02 -0700 (PDT) In-Reply-To: References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54176D6A.2020903@dcrocker.net> <1CD55F04538DEA4F85F3ADF7745464AF24C4C7B1@S-BSC-MBX1.nrn.nrcan.gc.ca> <541850DB.1050705@berkeley.edu> From: mike amundsen Date: Fri, 19 Sep 2014 18:24:02 -0400 Message-ID: To: Larry Masinter Content-Type: multipart/alternative; boundary=001a11c27dc81cd4650503729035 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/M02wmRyq3GlzlItU22fYECtYFCM Cc: Roy Fielding , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RESTful definition 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, 19 Sep 2014 22:24:28 -0000 --001a11c27dc81cd4650503729035 Content-Type: text/plain; charset=UTF-8 yep - BCP seems right to me, too. mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://linkedin.com/in/mamund On Fri, Sep 19, 2014 at 5:47 PM, Larry Masinter wrote: > "Defining" the term doesn't seem useful. But what about a BCP Best > Current Practice > > "Guidelines for creating RESTful services Protocols" > > with a focus on summarizing what future IETF application protocol > designers SHOULD do to be RESTful, and when they SHOULD do it. > > BCPs carry some weight but allow for exceptions and evolution. If REST > isn't a 'best current practice' we should stop talking about it. If it is, > then a summary of why and when seems just right for BCP. > > > -----Original Message----- > > From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of > Erik > > Wilde > > Sent: Tuesday, September 16, 2014 8:02 AM > > To: Rushforth, Peter; IETF Apps Discuss > > Subject: Re: [apps-discuss] RESTful definition > > > > hello. > > > > having spent considerable time and energy in the REST space, i think it > would be > > great if the IETF had some minimal guidance on what it is, why it > matters, and > > what people might want to consider when trying to be RESTful. > > > > there are two extremes: > > > > - one is to be pure and insist on the fact that REST is not a > technology, but an > > architectural style. this is "correct", but most people think this is > not very > > helpful. > > > > - tim bray's pragmatic view that anything using HTTP these days is being > sold as > > RESTful. this is a bit sad, but this is how it is. > > > > a useful definition would be in between. focusing on actual > technologies, but > > still making explicit statements about the things that matter for being > RESTful. > > > > On 2014-09-16, 7:43 , Rushforth, Peter wrote: > > > Although there are many overloaded words in language, REST has been > > > underloaded, in the sense that the some of the important qualities > that the > > term was coined to describe and evoke have been discarded by > > > common usage. Perhaps HATEOAS is *the most* important such quality, > as > > it forms the basis of the standard > > > Web, which currently separates us from platformification or what have > you. > > > > REST really does not define that many constraints, and hypermedia is an > > important one. at least highlighting that (even if people often choose > to ignore > > it) might be helpful to some. > > > > in my experience, people that just want to call something "REST" because > it's > > hip or sells better will not care about descriptions or guidelines > anyway. they > > just want the branding. but there also are many who are a bit confused > by "The > > Definition" (it's not a technology, it's an architectural style) and the > use of the > > term out in the wild. those people might be served very well with a > concise > > document that makes some simple statements about what matters most. > > > > cheers, > > > > dret. > > > > -- > > erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | > > | UC Berkeley - School of Information (ISchool) | > > | http://dret.net/netdret http://twitter.com/dret | > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a11c27dc81cd4650503729035 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
yep - BCP seems right to me, too.


On Fri, Sep 19, 2014 at 5:47 PM, Larry Masin= ter <masinter@adobe.com> wrote:
"Defining" the term doesn't seem useful. But what abou= t a BCP=C2=A0 Best Current Practice

"Guidelines for creating RESTful services Protocols"

with a focus on summarizing what future IETF application protocol designers= SHOULD do to be RESTful, and when they SHOULD do it.

BCPs carry some weight but allow for exceptions and evolution. If REST isn&= #39;t a 'best current practice' we should stop talking about it. If= it is, then a summary of why and when seems just right for BCP.

> -----Original Message-----
> From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Erik
> Wilde
> Sent: Tuesday, September 16, 2014 8:02 AM
> To: Rushforth, Peter; IETF Apps Discuss
> Subject: Re: [apps-discuss] RESTful definition
>
> hello.
>
> having spent considerable time and energy in the REST space, i think i= t would be
> great if the IETF had some minimal guidance on what it is, why it matt= ers, and
> what people might want to consider when trying to be RESTful.
>
> there are two extremes:
>
> - one is to be pure and insist on the fact that REST is not a technolo= gy, but an
> architectural style. this is "correct", but most people thin= k this is not very
> helpful.
>
> - tim bray's pragmatic view that anything using HTTP these days is= being sold as
> RESTful. this is a bit sad, but this is how it is.
>
> a useful definition would be in between. focusing on actual technologi= es, but
> still making explicit statements about the things that matter for bein= g RESTful.
>
> On 2014-09-16, 7:43 , Rushforth, Peter wrote:
> > Although there are many overloaded words in language, REST has be= en
> > underloaded, in the sense that the some of the important qualitie= s that the
> term was coined to describe and evoke have been discarded by
> > common usage.=C2=A0 =C2=A0 Perhaps HATEOAS is *the most* importan= t such quality, as
> it forms the basis of the standard
> > Web, which currently separates us from platformification or what = have you.
>
> REST really does not define that many constraints, and hypermedia is a= n
> important one. at least highlighting that (even if people often choose= to ignore
> it) might be helpful to some.
>
> in my experience, people that just want to call something "REST&q= uot; because it's
> hip or sells better will not care about descriptions or guidelines any= way. they
> just want the branding. but there also are many who are a bit confused= by "The
> Definition" (it's not a technology, it's an architectural= style) and the use of the
> term out in the wild. those people might be served very well with a co= ncise
> document that makes some simple statements about what matters most. >
> cheers,
>
> dret.
>
> --
> erik wilde | mailto:dret@berkeley= .edu=C2=A0 -=C2=A0 tel:+1-510-2061079 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| UC Berkeley=C2=A0 -= =C2=A0 School of Information (ISchool) |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://dret.net/netdret http://twitter.com/dret |
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

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

--001a11c27dc81cd4650503729035-- From nobody Fri Sep 19 16:54:15 2014 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 3C5CD1A8903 for ; Fri, 19 Sep 2014 16:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJym7pKJEIb4 for ; Fri, 19 Sep 2014 16:54:12 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113071A8902 for ; Fri, 19 Sep 2014 16:54:11 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ge10so4093144lab.27 for ; Fri, 19 Sep 2014 16:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LCvBLGBn2pQAvqQjQ7qnWAFEA9MHbCfV8CdwWnYlp5A=; b=mTzCDUwpyQRKpRcPfHeoHFs4XKPCzfymvI5ROtXqNUwNuH/Xzqq+FAWDAUjncS9y8C c6XyB7VxcU4DilZRPBf8uQhjPTQjYsslyEgyJHvqMtzAI1wWhzkFLdRXKdSEavQ5FpAQ jWqHChXSKNSp+IMMkhtgLwutPlV/CyeIupu4G8OMjZDlZlF4Ke18URFj26wHRj7YqvbF P5qyoIeMFKY1Z6QhQUahlZ3/EIBxwM1cQWlgb2so0lAi1Kmw6w/YVpmQd7P0S77gm1Eg p7iP2aquAxEneSoHi1Wi9YPtFddNO3IOymnDreqp2A7jZRxQWh2+pQcbowea4swird7g CCEA== MIME-Version: 1.0 X-Received: by 10.152.3.130 with SMTP id c2mr9963105lac.72.1411170850414; Fri, 19 Sep 2014 16:54:10 -0700 (PDT) Received: by 10.25.211.7 with HTTP; Fri, 19 Sep 2014 16:54:10 -0700 (PDT) In-Reply-To: References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <561C70B6-7D61-4ECA-92B4-0DB6F3BB50FD@mnot.net> Date: Fri, 19 Sep 2014 16:54:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: Tim Bray Content-Type: multipart/alternative; boundary=089e0149339241a630050373d16e Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/CmIqa1EjR7L0-0FM81DYe7NB22Q Cc: Mark Nottingham , Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition 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, 19 Sep 2014 23:54:14 -0000 --089e0149339241a630050373d16e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Sep 19, 2014 at 3:14 PM, Tim Bray wrote: > Murray, the question has been raised a couple of times; apologies if you > addressed it and I missed it. What is the context? > It is, quite literally, a "this acronym should be expanded on first use in this document" issue, which is a common thing pointed out during AD or IESG evaluation of a document. What I think what you mean by "context" is actually more a question about whether REST is even the right or necessary term to use in this document in the first place. That, I think, is a different question than what I'm trying to answer, although it might even be the more important one. Still, let me see if I can construct a more concrete example: "This document describes the use of the HyperText Transport Protocol (HTTP; [RFC7230]) to provide service X." So, if I have this, which follows the same common form we use in RFCs: "This document describes a service that provides service X while adhering to the principles of REpresentational State Transfer (REST; [xxxx])." What would you suggest we put for "xxxx" there? Are you sure you really mean Representational State Transfer? Are you sure > you couldn=E2=80=99t just get away by saying something like > > =E2=80=9CThe interface is via HTTP, using the A, B, and C verbs, taking a= dvantage > of the idempotence characteristics of A and C, with the payload being > delivered as application/D, and with a cleanly-designed URI space=E2=80= =9D > > Because there=E2=80=99s nothing in there that you can=E2=80=99t find an g= ood reference for > around here. > And that might be absolutely fine. I'll forward this suggestion to the authors and let them decide if that solves the reference problem without losing anything they feel needs to be there. Thanks! -MSK --089e0149339241a630050373d16e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Sep 19, 2014 at 3:14 PM, Tim Bray <tbray@textu= ality.com> wrote:
Murray, the question has been raised a couple of times; a= pologies if you addressed it and I missed it.=C2=A0 What is the context?

It is, quite literally, a &qu= ot;this acronym should be expanded on first use in this document" issu= e, which is a common thing pointed out during AD or IESG evaluation of a do= cument.

What I think what you mean by "context"= is actually more a question about whether REST is even the right or necess= ary term to use in this document in the first place.=C2=A0 That, I think, i= s a different question than what I'm trying to answer, although it migh= t even be the more important one.

Still, let me see if I = can construct a more concrete example:

"This documen= t describes the use of the HyperText Transport Protocol (HTTP; [RFC7230]) t= o provide service X."

So, if I have this, which foll= ows the same common form we use in RFCs:

"This document describ= es a service that provides service X while adhering to the principles of RE= presentational State Transfer (REST; [xxxx])."

What would you suggest we put for "xxxx" there?

Are you sure you really mean Representational State Transfer?=C2=A0 A= re you sure you couldn=E2=80=99t just get away by saying something like=C2= =A0

=E2=80=9CThe interface is via HTTP, using the A, B, and C verbs, taki= ng advantage of the idempotence characteristics of A and C, with the payloa= d being delivered as application/D, and with a cleanly-designed URI space= =E2=80=9D

Because there=E2=80=99s nothing in there that you can=E2=80=99t= find an good reference for around here.

<= /div>
And that might be absolutely fine. =C2=A0 I'll forward this s= uggestion to the authors and let them decide if that solves the reference p= roblem without losing anything they feel needs to be there.

Thanks!

-MSK
--089e0149339241a630050373d16e-- From nobody Fri Sep 19 16:59:02 2014 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 40C121A88F9 for ; Fri, 19 Sep 2014 16:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQvfgyblkHHY for ; Fri, 19 Sep 2014 16:58:59 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94CCA1A02EB for ; Fri, 19 Sep 2014 16:58:58 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id gi9so4031945lab.10 for ; Fri, 19 Sep 2014 16:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Ao4HGap1mTiY3RmXSrJ4YTBxnGP886mxJY6hE2XR7M0=; b=XNQW1o4wNvC1+nDEwL/GnRG6+Z8Vlr5vn5q3rOiX9+0qlV+0C2418UBsznk5Y9nUdc i29yvYWDKBqbuxMZhAaZ6Y4EL5F6WiE1EM+Kv6WYof0l+JoXDLBCLiakh9mXNMJah0GZ nchTlSO0f6HiQtloFtC5PfIwft0dKAUWKyWGlTkGzzmYUcRdIvp29sADu4gkr+UHy+wB BSSP6abrhaV5eJuoE9wpDVntxfzdxWQVDrEvG6ZLyLbpZAbwDVAkAYGgJ5FzMqZBHPoi 6pRkqurHcBrCRKq1YcIPE+IYJwHzZm3SjBpWzpbyVYuNavh4XVD8iZtB9W1xatvFnAiM i2DQ== MIME-Version: 1.0 X-Received: by 10.112.199.232 with SMTP id jn8mr9445475lbc.30.1411171136924; Fri, 19 Sep 2014 16:58:56 -0700 (PDT) Received: by 10.25.211.7 with HTTP; Fri, 19 Sep 2014 16:58:56 -0700 (PDT) In-Reply-To: <20140919173225.28890.36281.idtracker@ietfa.amsl.com> References: <20140919173225.28890.36281.idtracker@ietfa.amsl.com> Date: Fri, 19 Sep 2014 16:58:56 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c2b6ce55740b050373e248 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/UdtVF9XHgeOanzEmAIacKd06-qs Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-http-problem-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 23:59:00 -0000 --001a11c2b6ce55740b050373e248 Content-Type: text/plain; charset=UTF-8 On Fri, Sep 19, 2014 at 10:32 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Applications Area Working Group Working > Group of the IETF. > > Title : Problem Details for HTTP APIs > Authors : Mark Nottingham > Erik Wilde > Filename : draft-ietf-appsawg-http-problem-00.txt > Pages : 13 > Date : 2014-09-19 > > 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 > invent new error response formats for HTTP APIs. > As we've announced before, APPSAWG makes liberal use of our discretion to assign non-chair shepherds. Is there anyone on the list who would be interested in shepherding this document and wants to volunteer? -MSK --001a11c2b6ce55740b050373e248 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Sep 19, 2014 at 10:32 AM, <<= a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">internet-draft= s@ietf.org> wrote:

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Problem Details for HTTP APIs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mark= Nottingham
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Erik Wilde
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-appsawg-http-problem-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 13
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-09-19

Abstract:
=C2=A0 =C2=A0This document defines a "problem detail" as a way to= carry machine-
=C2=A0 =C2=A0readable details of errors in a HTTP response, to avoid the ne= ed to
=C2=A0 =C2=A0invent new error response formats for HTTP APIs.

As we've announced before, APPSAWG makes liberal= use of our discretion to assign non-chair shepherds.=C2=A0 Is there anyone= on the list who would be interested in shepherding this document and wants= to volunteer?

-MSK
--001a11c2b6ce55740b050373e248-- From nobody Fri Sep 19 17:28:01 2014 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 0F7341A890B for ; Fri, 19 Sep 2014 17:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 AZp54hAmf_BG for ; Fri, 19 Sep 2014 17:27:59 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D21B61A8912 for ; Fri, 19 Sep 2014 17:27:52 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 52A2A1DE05D for ; Fri, 19 Sep 2014 17:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Kg6RbleP5BdlHOdGhxb2 x15DOm0=; b=IwNpcsUREW5i2Nvfg3f+G4y60raIvSHssg/Rbomi8NH561hP4V2b 3cjef2uydP6Ecaj5n8YJ+ICPDwnzZrCHR5iCq8gpGmaTTVrKaNQAkH9msr+gBsSv ylLTOQhk96lPjjSbG1c4NgO47bkpxsufE5+0mNbXVW56P6M7rpGUcpc= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 087B11DE058 for ; Fri, 19 Sep 2014 17:27:51 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id k48so483719wev.30 for ; Fri, 19 Sep 2014 17:27:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.61.99 with SMTP id o3mr86311wjr.103.1411172870695; Fri, 19 Sep 2014 17:27:50 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Fri, 19 Sep 2014 17:27:50 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Sep 2014 19:27:50 -0500 Message-ID: From: Nico Williams To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QOAeyXW3efcrloMgC89ZVjT8NdY Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 00:28:00 -0000 If "RESTful" and "REST" are merely social signifiers ^W^W informative, then don't use them in RFCs. We could also just accept them as social/cultural signifiers and use them in RFCs without offering a definition. OTOH, if "RESTful" and "REST" denote normative semantics, then we must define them. Quite aside from that, there have been many arguments about what is and isn't RESTful (is this an understatement?)... It'd be nice to have a clear definition that all accept. If nothing else I could make a killing in popcorn stocks if we take up that challenge! More seriously: I propose that we avoid these terms in Internet RFCs as much as possible. Nico -- From nobody Fri Sep 19 18:09:57 2014 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 D86891A882B for ; Fri, 19 Sep 2014 18:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, 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 VvZQ8o8zLuzC for ; Fri, 19 Sep 2014 18:09:51 -0700 (PDT) Received: from nm30-vm4.bullet.mail.gq1.yahoo.com (nm30-vm4.bullet.mail.gq1.yahoo.com [98.136.216.195]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 729B11A8826 for ; Fri, 19 Sep 2014 18:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1411175391; bh=J0o14a4DGqp+rUKzpycMTiQpJH0i313YlLsL82ku9ig=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Gm-Message-State:X-Received:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc:Content-Type:From:Subject; b=nh2ytRm5q8ZNqtJ1pvglJFabtQUGu7LBhzhtrb4vlB5Trf7MYEcVbQ1DycVaxQN9dPJVkjgfhPB05rBWZFAtbolP/aTrnrDswjNLYZwhgNSj1osRxHpOBo7zDlEPy0vYJ4Eh91+jyiVSyl1JLntb4VuWgpV5713/NcZyRjnhJ35vyhUERawb9F6vdHGX1/Mn+SY47/bIs0Pld8sC6uL/giG1+EOZbPJURUSEhUC1F3a+uxd2rVNUfdN4cR9at9hl285xCc60P1n3jhykTc9J8NnrAon71yRaiyh6dqV5PVvNMhUn7EiP/8ykEVuaegsJl0DwNPqTLlHKw6rDkZ8BZA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=iNcMduznxdC/6CV1sbPleujXB7CqKuVLpyyXGAVbv60Q4A0uFShb9VzEavRfQVKV0J0PWaFDPwvVZ13HUvRKHFZ1VhI6HNWc8ekhD1DPioV93SbgJfR7uIG4JNtC8FwcvwWXLexZOvJYWLXTtP8to8flUfnS+TNXT7MbjGMoNdlY7dCqohvFFyfJZ2L8KIRwvYJZ15fHneWkCauL6mmKDs63Mq9vBdkoTnW1jT0BD6KEtrdpNdHpO6aKw5+setgfBiP7+xdQuBH5/qy6H21h+Q7QuKrtL3/J1kJjGqAi2tud558R6HhJ20VkuEli9I2n2MO2+US3A5W3LyQqSYOYtw==; Received: from [216.39.60.180] by nm30.bullet.mail.gq1.yahoo.com with NNFMP; 20 Sep 2014 01:09:51 -0000 Received: from [208.71.42.204] by tm16.bullet.mail.gq1.yahoo.com with NNFMP; 20 Sep 2014 01:09:51 -0000 Received: from [127.0.0.1] by smtp215.mail.gq1.yahoo.com with NNFMP; 20 Sep 2014 01:09:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1411175391; bh=J0o14a4DGqp+rUKzpycMTiQpJH0i313YlLsL82ku9ig=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Gm-Message-State:X-Received:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=P7gOjbxZriHUvGTcTXQnTEb38ut/rNMO5yJaXkEydsoi2IoRCKNUt7TX/DQ1XRXAN8Yz5cA+JvRl3nX2CabCJfw6whegIKdyXawVniLIE5GNhxHOtxsPzRDZlnen3mdOkGd4/ZYKI5Ujlh/0F5V9PBgbk4DJTuHrGiwTQ0Wd7uA= X-Yahoo-Newman-Id: 55820.97533.bm@smtp215.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: eU8LBwIVM1lxVT4BXMARqmQCGkUdoNQ1idnY5c_mKaCzyED b2dI5ctfVLv8xNCJp4qkCGptzwEbWFK.GgCE3cb8FvlUkeNuTu65YczyxNJE AuNJ2vB6ohyQpoD9TwnrRAeYCjZb1Wo0ypgqwgARkkyqFGnFtQFX22zvrOOY 0EUZHedldNBf.SNSCNhxvXLiRavfG9VSLQxv_U.02USlDnZ0lffUeexn1tco lWSOP2dl906CZEkxD9zvh0rFanGkIHQZDzIuSyc4uPZ_JsXXzjAgGEl8W0cJ B9m9fyaSQEsDjVmvUFjyJ3xEW62Icy56zOkABCLopLQUawHnbT3uSybmDhFZ 46RbY4ekBMaUsP.sUOaPae_bFORZfYsmzY3jzPrhUH2Ea7X_OfNkCafXZ1VZ 2HjQr3pD61I0lkTKPlQxY7cncYXC0RA.AhzLB2y66aZtZ9SyEoHIMAoXIysZ 4nAtDlZqEMKAn6gWs.p4_KdxNNX2hNpZ0Ix4Ymj5XCyYxWJuxpnmEsxrZnUx n5pxu7Q8D2HMz4rxQbtlHbJMm_3na1aqLbHGNcrbDQpWyh8wT0UsB5DDVSJH cMEJBMXSVoEhNWShNBSr8.fsFJfhrFfkxSPonbEpnI4joJ3ETVAYhdMCF_Uo aojDP8Y9V0TCdCulGN7BE5T8lPktuqJhqbp9fkmikb4weRpPRKmODRqJRPWR IV3R9Bt0GcHMTfRz9IP2gxN2k7zEt_foTIOqgDQ0tNvcraoQT0sKHJcjQmb8 sNXxd0hIbEjoer1RmkNXy7g-- X-Yahoo-SMTP: i12ABOmswBAkPG1PnjmsmmFRWA-- Received: by mail-la0-f47.google.com with SMTP id mc6so4140009lab.34 for ; Fri, 19 Sep 2014 18:09:48 -0700 (PDT) X-Gm-Message-State: ALoCoQnYjeQLlF64aspniUVfo9yzFINsY6UfefmbbPIi187nli+Nam7l6Qwf2jf4xYrkGFAtPacX X-Received: by 10.152.2.41 with SMTP id 9mr9996099lar.79.1411175388157; Fri, 19 Sep 2014 18:09:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.218.8 with HTTP; Fri, 19 Sep 2014 18:09:28 -0700 (PDT) In-Reply-To: References: From: mike amundsen Date: Fri, 19 Sep 2014 21:09:28 -0400 Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=089e013c6258ba3138050374df1f Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wUFHkGuSAbcH4jFj6AKRI8nnvdc Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 01:09:54 -0000 --089e013c6258ba3138050374df1f Content-Type: text/plain; charset=UTF-8 If the word/acronym "REST" is to be used at all in RFCs, it should be clearly defined (the *word*). Without a useful shared definition of the word, leaving it out of RFCs is the right thing to do. FWIW, I think MSK's example is spot on. "This document describes a service that provides service X while adhering to the principles of REpresentational State Transfer (REST; [xxxx])." Right now, we do not have a proper document for reference. To date, uses of that word in RFCs have been tied to Fielding's dissertation which is NOT about REST at all. Referring to the single Chapter that outlines REST is, IMO, not acceptable since the chapter is full of references to previous content in the dissertation. I agree w/ Crocker that this is too big a chunk to use as a reference *for that term*. A short BCP (per Masinter's suggestion) should suffice. What I find instructive is that no one here wants to even *hazard* a definition or point to one (save MSK's reference to the Wikipedia entry). So I've started an experiment[1] to collect definitions and I invite folks on this list to offer theirs up (or point to an existing one). I plan use this material in a short session at RESTFest next week and post notes/comments from that session. It would help the convo quite a bit to see more volunteers adding to the list. Cheers [1] https://github.com/RESTFest/2014-Greenville/wiki/Mike-Amundsen#rest mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://linkedin.com/in/mamund On Fri, Sep 19, 2014 at 8:27 PM, Nico Williams wrote: > If "RESTful" and "REST" are merely social signifiers ^W^W informative, > then don't use them in RFCs. We could also just accept them as > social/cultural signifiers and use them in RFCs without offering a > definition. > > OTOH, if "RESTful" and "REST" denote normative semantics, then we must > define them. > > Quite aside from that, there have been many arguments about what is > and isn't RESTful (is this an understatement?)... It'd be nice to > have a clear definition that all accept. If nothing else I could make > a killing in popcorn stocks if we take up that challenge! > > More seriously: I propose that we avoid these terms in Internet RFCs > as much as possible. > > Nico > -- > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e013c6258ba3138050374df1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If the word/acronym "REST" is to be us= ed at all in RFCs, it should be clearly defined (the *word*). Without a use= ful shared definition of the word, leaving it out of RFCs is the right thin= g to do.

FWIW, I think=C2=A0MSK's=C2= =A0example is spot on.=C2=A0
<snip>
"This document describes= a service that provides service X while adhering to the principles of REpr= esentational State Transfer (REST; [xxxx])."
</= snip>
Right now, we do not have a proper document for referenc= e. To date, uses of that word in RFCs have been tied to Fielding's diss= ertation which is NOT about REST at all. Referring to the single Chapter th= at outlines REST is, IMO, not acceptable since the chapter is full of refer= ences to previous content in the dissertation. I agree w/ Crocker that this= is too big a chunk to use as a reference *for that term*.

A short BCP (per Masinter's suggestion) should suffice.= =C2=A0

What I find instructive is that no one here= wants to even *hazard* a definition or point to one (save MSK's refere= nce to the Wikipedia entry). So I've started an experiment[1] to collec= t definitions and I invite folks on this list to offer theirs up (or point = to an existing one). I plan use this material in a short session at RESTFes= t next week and post notes/comments from that session.=C2=A0 It would help = the convo quite a bit to see more volunteers adding to the list.
=
Cheers




=

mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/ma= mund
htt= p://linkedin.com/in/mamund

On Fri, Sep 19, 2014 at 8:27 PM, Nico Willia= ms <nico@cryptonector.com> wrote:
If "RESTful" and "REST" are merely social= signifiers ^W^W informative,
then don't use them in RFCs.=C2=A0 We could also just accept them as social/cultural signifiers and use them in RFCs without offering a
definition.

OTOH, if "RESTful" and "REST" denote normative semantic= s, then we must
define them.

Quite aside from that, there have been many arguments about what is
and isn't RESTful (is this an understatement?)...=C2=A0 It'd be nic= e to
have a clear definition that all accept.=C2=A0 If nothing else I could make=
a killing in popcorn stocks if we take up that challenge!

More seriously: I propose that we avoid these terms in Internet RFCs
as much as possible.

Nico
--

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

--089e013c6258ba3138050374df1f-- From nobody Fri Sep 19 23:22:58 2014 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 3DB591A891F for ; Fri, 19 Sep 2014 23:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQLKt0pZseAn for ; Fri, 19 Sep 2014 23:22:56 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE3C1A891E for ; Fri, 19 Sep 2014 23:22:55 -0700 (PDT) Received: (qmail 65327 invoked from network); 20 Sep 2014 06:22:54 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 20 Sep 2014 06:22:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=19a9.541d1d45.k1409; i=johnl@user.iecc.com; bh=uBqxbgG6huB+KGLUIVhnHZG81R5veUS3xPtk7vpFjbI=; b=tBfyWtbBpkQe1xqQBikM8b6ZoPW8JQzbsxjbIVJULkCWL54M8+H1fPzuJz2ifttn/WhkRtqk3KidlC/y/m6OqAIukRs2xPqTdQXP6LhZ9hxuNWTUnMPFGLCQfXPYzQTenHUIuSRXbZ6dOvMZInQw2XDAHyGZda6DY1juQSUgMJ7TFQXIMvnmQiapx33AF9hYs/xXJvImRRuySnqCnvrZdBa8gNJTMtKjNZAqi3iPSUTtzYOBp5pQg5GjtswifYQC DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=19a9.541d1d45.k1409; olt=johnl@user.iecc.com; bh=uBqxbgG6huB+KGLUIVhnHZG81R5veUS3xPtk7vpFjbI=; b=D68r89c98kbmhaUh6ROHxsfHfVStV03l0hunfpMuC+PI55UMcCfK3RMmBvyyLagRDy7flKJmc0Ftaps/Pf/KxzxU25UveAPbDaDue4s8EPi2/AU4g7X3rFShYyxtniZQlQViVvX+ozLpKvgfGmn6SolaGPnG/OzWx+SWye601tLcA5dBwdyxsLaLsAr0mWxijgGdB0tTHbC5+6pDTmClFTk/hXDf6tT2w8K/NWeo2yh3FbDb/mWdHg8awf4Oa33Z Date: 20 Sep 2014 06:22:38 -0000 Message-ID: <20140920062238.6568.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/sE_hO0l1zoFwO-y9Mlo1xL8h2hg Cc: mnot@mnot.net Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 06:22:57 -0000 In article you write: >Not really. I see many potential downsides, not a lot of upside. > >Now, if someone wanted to go off and write such a document >optimistically, and was willing to bring it here to have arrows thrown >at it, it could be interesting. It’s just that all of the people who are >most qualified to write such a thing are really busy. This sounds completely correct to me. I look forward to seeing what the people who think that such documents would be useful write. R's, John From nobody Sat Sep 20 01:09:40 2014 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 C469C1A894A for ; Sat, 20 Sep 2014 01:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VAtn_Xl9QMq for ; Sat, 20 Sep 2014 01:09:36 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098041A8949 for ; Sat, 20 Sep 2014 01:09:35 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id z107so916860qgd.21 for ; Sat, 20 Sep 2014 01:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=EU2KVSstIBGigk9TeMkLntopwg5zLWjpGvQ3vTCat+M=; b=FwN+XnVw1k6X4XUdEGyCCzXT+QK+WeoqmrJhfZ0ZZYB2iUlfrpy6JcQQnAe/CJsVNd Z4sS0P1GfkPvAVnpxKPdAo89xywqDylWmKMkwpko5Gk9ITh9M3PFpUHVZ1AxMP4cyp0g 2wAOtxBOIzKgcaITiQ8T38VMOsBUCWWa4QAJTyOD5Bk7UR4TxmsEVl0W+NDDK8I+6Y3S TF6He/oC6aVgabz5mka6nasOIxQY3Cc9+oPcyBWSfG0T0JcSQboPkrEm5P9v8q6z0t1L Tz6o9P56A0SpvjUExjQx5VEUJOHDpzwWAQUVHwBmypCxSm3jynaC3xaN0h6/NsiKtMP5 sPtQ== MIME-Version: 1.0 X-Received: by 10.224.55.201 with SMTP id v9mr1582434qag.36.1411200575283; Sat, 20 Sep 2014 01:09:35 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.140.25.150 with HTTP; Sat, 20 Sep 2014 01:09:35 -0700 (PDT) In-Reply-To: References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <561C70B6-7D61-4ECA-92B4-0DB6F3BB50FD@mnot.net> Date: Sat, 20 Sep 2014 18:09:35 +1000 X-Google-Sender-Auth: qVO8jqhKrG3oK3ubEWDA1gdhL74 Message-ID: From: Matthew Kerwin To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a11c30c34ff29d305037abc04 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/iWi-Vx4o4EapDSEb3qLxFJOA3x4 Cc: Mark Nottingham , Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 08:09:38 -0000 --001a11c30c34ff29d305037abc04 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 20 September 2014 09:54, Murray S. Kucherawy wrote= : > > So, if I have this, which follows the same common form we use in RFCs: > > "This document describes a service that provides service X while adhering > to the principles of REpresentational State Transfer (REST; [xxxx])." > > What would you suggest we put for "xxxx" there? > > =E2=80=8BSeems to me to be a perfectly reasonable situation to reference Ro= y's dissertation. "Adhering to principles" is already pretty hand-wavey, so I think the reference doesn't have to be particularly formal. Adhering to the principles of Buddhism doesn't require a reference to a BCP of the Five Precepts. Alternatively, as Tim says, you could replace the reference with an inline enumeration of the principles, if that doesn't introduce Too Much Words. --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a11c30c34ff29d305037abc04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= On 20 September 2014 09:54, Murray S. Kucherawy <superuser@gmail.com> wrote:
=

So, if I have this, which follows the same common form = we use in RFCs:

"This document describes a service that provide= s service X while adhering to the principles of REpresentational State Tran= sfer (REST; [xxxx])."

What would you sugg= est we put for "xxxx" there?


=E2=80=8BSeems = to me to be a perfectly reasonable situation to reference Roy's dissert= ation. "Adhering to principles" is already pretty hand-wavey, so = I think the reference doesn't have to be particularly formal. =C2=A0Adh= ering to the principles of Buddhism doesn't require a reference to a BC= P of the Five Precepts.

Alternatively, as = Tim says, you could replace the reference with an inline enumeration of the= principles, if that doesn't introduce Too Much Words.

--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/<= /a>
--001a11c30c34ff29d305037abc04-- From nobody Sat Sep 20 01:20:55 2014 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 3899A1A894A for ; Sat, 20 Sep 2014 01:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 zrt8W8ugCO0m for ; Sat, 20 Sep 2014 01:20:50 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF161A8949 for ; Sat, 20 Sep 2014 01:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s8K8KZk0000807; Sat, 20 Sep 2014 10:20:35 +0200 (CEST) Received: from [192.168.217.145] (p5489260B.dip0.t-ipconnect.de [84.137.38.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EDC022A7; Sat, 20 Sep 2014 10:20:33 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Sat, 20 Sep 2014 10:20:31 +0200 X-Mao-Original-Outgoing-Id: 432894030.909536-6d4c2d55fc973c411678e8d372c8e35d Content-Transfer-Encoding: quoted-printable Message-Id: <57604ECC-2DF0-480E-B2CA-929695EB8CA6@tzi.org> References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <561C70B6-7D61-4ECA-92B4-0DB6F3BB50FD@mnot.net> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/4qVuBEEnYj5zeRn3I3Fm2grVmFc Cc: Mark Nottingham , Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 08:20:52 -0000 >=20 > How do I resolve that when the acronym is REST? I thought I gave a recipe already: bla bla bla Representational State Transfer [REST] bla bla bla [REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Ph.D. Dissertation, University of California, Irvine, 2000, . No consensus definition of the term needed. (People can find secondary literature about REST in Wikipedia, in = bookstores, and in a few blogs. There is no need to reference all that secondary literature. And we stopped publishing FYIs a while ago.) More importantly, I=92ll repeat myself: If somebody thinks they need a normative definition of REST in their = protocol specification, I=92d really like to know what that is trying = to achieve. I like Mike=92s experiment, but I agree with Mark that the IETF has no = need to spend an enormous amount of cycles on this. I=92m having a little de ja vu here with respect to the US =93debate=94 = about evolution: There is a published opinion that likes to make it look like there is a = great debate about what REST means. Frankly, I=92m not aware of such a debate. (There *is* a debate whether it is always the right thing to follow all = constraints of REST. The term RESTful was invented to indicate a varying degree of adherence = to them; it does not have a well-defined meaning except just that, so = debating whether something =93is RESTful=94 degenerates into a = discussion of taste. There also have been debates around fine points of REST practice, say, = the meaning of POST. Finally, REST practice is evolving, e.g. via the PATCH method (RFC 5789) = and URI templates (RFC 6570), but the basic constraints are surprisingly = stable.) Gr=FC=DFe, Carsten From nobody Sat Sep 20 07:59:02 2014 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 6F9B11A010C for ; Sat, 20 Sep 2014 07:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIDWezDKR7NY for ; Sat, 20 Sep 2014 07:58:57 -0700 (PDT) Received: from mail.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1CB1A0109 for ; Sat, 20 Sep 2014 07:58:56 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2177; t=1411225128; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=zYw7Y3cgASOPQakzN85epOCiT8Y=; b=UVW1v9yMbm/5BIkVDTWI +/9gwpQeZuwASydR4S2RiyBQUWO7oYrU9zXaN5MPqPJ3s+Qvgl8a6JBkx2NBlSSc k2lhgChpCjCxjmIiJvvQw3HNQ9qcXQB/My3MlMVuYvXC1DuQFPZyww3u+8eyxSbH XMZGnG1JWNELQeH7MK3l+g8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 20 Sep 2014 10:58:48 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2115215859.9219.3408; Sat, 20 Sep 2014 10:58:47 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2177; t=1411224776; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=YWqiKVt eeO+0eX87LjPlZgYcdToQwOIrqX6G98auh4c=; b=snWayOV0LhsGSAMOon9ZU+n 7KsdQ/xMngH9npczH3TofnduLtwywaxvUqCFA38TUUr+w5PXVfEQSmcVmB0vQhg3 ZN/Ly+ESRkRUKKFCyk029IEpOUnE/HOk4+qD/Nucuo3fqhZBhWifok7jTt4mJj0i QEJ/8FRLfisByg2c/NFM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 20 Sep 2014 10:52:56 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 707655704.9.4268; Sat, 20 Sep 2014 10:52:55 -0400 Message-ID: <541D961E.3020805@isdg.net> Date: Sat, 20 Sep 2014 10:58:38 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Mark Nottingham References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <561C70B6-7D61-4ECA-92B4-0DB6F3BB50FD@mnot.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZiNAKCgwU48pIrx2h6tboUvY-7o Cc: Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 14:59:00 -0000 On 9/19/2014 5:48 PM, Murray S. Kucherawy wrote: > On Fri, Sep 19, 2014 at 11:48 AM, Mark Nottingham wrote: > >> Not really. I see many potential downsides, not a lot of upside. >> >> Now, if someone wanted to go off and write such a document optimistically, >> and was willing to bring it here to have arrows thrown at it, it could be >> interesting. It’s just that all of the people who are most qualified to >> write such a thing are really busy. >> >> YMMV, of course. >> > > My goal here is pretty simple: We don't like undefined acronyms in RFCs. > "Please expand HTTP on first use" has to be something you've seen before in > your various document reviews, for example. > > How do I resolve that when the acronym is REST? > > -MSK It depends in how you will be using it. Maybe you don't have a "REST" situation? and just a normal concept of preparing a HTTP query? Thats pretty standard and plenty of HTTP RFC references for that. Are you really developing a REST API? If so, then I guess you want to use Roy's document but you SHOULD also reference the HTTP RFC docs as that is the basic even for Roy's doc. We write APIs Murray and we have very rich set of API for nearly all the native languages, including "REST" forms of the API for the WEB side interfaces. I am not going to read Roy's doc unless there is something very specific you want us to know about thats only found there and not in an standard HTTP docs. Maybe for your specific Protocol, you don't need to mention REST at all unless you think it will help with your "technical marketing" of the protocol. If you want to cater to the "layman" application developer and implementer as you stated you desired to, you can say.... Protocol XYZ is a "REST" based protocol. REST which stands for "Representational State Transfer" [REST] is a common industry term used for preparing HTTP Queries [HTTP] for Web-based API development. [REST] Representational State Transfer http://en.wikipedia.org/wiki/REST_API [HTTP] Hypertext Transfer Protocol -- HTTP/1.1 http://tools.ietf.org/html/rfc2616 Keep it simple. -- HLS From nobody Sat Sep 20 08:01:14 2014 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 1C8E71A010C for ; Sat, 20 Sep 2014 08:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prTd90jT9_So for ; Sat, 20 Sep 2014 08:01:09 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104481A006A for ; Sat, 20 Sep 2014 08:01:08 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ge10so4646946lab.13 for ; Sat, 20 Sep 2014 08:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kHZ4AiG1aT6MYVx84vLLTdethEg2sS/RyqIq125jdvY=; b=VapEKeVdnlWpGlnWTX6mJeo7PeBGknYE3NhAo1m8w370aTZPz6Us77zXkd92Kwe77U fG2Q68z4ICj2DWE8V6vgqkLs0teQhJTVPXIar8hXyNgs8v/sB5/LWMhG1CAm217uGFy1 VeqhBUS4aI+O5WRubhfWWw/ueW2nMqqn1FCEE+x9PGQbwOro3hlKsO4jVw7I2j5xrhEB qvVMeylxNT1rcsXD0CJ1/JXSE6K1N/Mudx4iNHbu9QN9rpkvfx7RgQ6RKG4O4T9L4vi2 p9v++s0DIeDPnu/MdiiStSorjpko89Q1bai//vmqMsASleDCLBGE4AllWKq/drVM5T8Q H/lA== MIME-Version: 1.0 X-Received: by 10.112.143.105 with SMTP id sd9mr13122143lbb.43.1411225267024; Sat, 20 Sep 2014 08:01:07 -0700 (PDT) Received: by 10.25.211.7 with HTTP; Sat, 20 Sep 2014 08:01:06 -0700 (PDT) In-Reply-To: <57604ECC-2DF0-480E-B2CA-929695EB8CA6@tzi.org> References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <561C70B6-7D61-4ECA-92B4-0DB6F3BB50FD@mnot.net> <57604ECC-2DF0-480E-B2CA-929695EB8CA6@tzi.org> Date: Sat, 20 Sep 2014 08:01:06 -0700 Message-ID: From: "Murray S. Kucherawy" To: Carsten Bormann Content-Type: multipart/alternative; boundary=089e010d8d02bd390d0503807c2f Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/O1E-hvIF0fQuT-lCWC0jt0SdMyU Cc: Mark Nottingham , Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 15:01:11 -0000 --089e010d8d02bd390d0503807c2f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Sep 20, 2014 at 1:20 AM, Carsten Bormann wrote: > > > > How do I resolve that when the acronym is REST? > > I thought I gave a recipe already: > Yes, you did, but I was asked again why this is needed, so I answered. More importantly, I=E2=80=99ll repeat myself: > > If somebody thinks they need a normative definition of REST in their > protocol specification, I=E2=80=99d really like to know what that is try= ing to > achieve. > I don't think repeating oneself really helps here, but I'll try it too: > So, if I have this, which follows the same common form we use in RFCs: > > "This document describes a service that provides service X while adhering to the principles of REpresentational State Transfer > (REST; [xxxx])." > > What would you suggest we put for "xxxx" there? What I'm trying to achieve is an answer to that question for a document I'm shepherding. You've given one answer (more than once now); thank you for that. Other people seem to have other opinions, in some cases suggesting the document should be saying something else completely. That's why this thread is still going. I like Mike=E2=80=99s experiment, but I agree with Mark that the IETF has n= o need > to spend an enormous amount of cycles on this. > I agree. I just want to move this document forward. -MSK --089e010d8d02bd390d0503807c2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Sep 20, 2014 at 1:20 AM, Carsten Bormann <cabo@tzi.org= > wrote:
>= ;
> How do I resolve that when the acronym is REST?

I thought I gave a recipe already:

Yes, you did, but I was asked again why this is needed, so I answered.
More importantly, I=E2=80=99ll repeat myself:

If somebody thinks they need a normative definition of REST in their protoc= ol specification, I=E2=80=99d really like to know=C2=A0 what that is trying= to achieve.

I don't think repeatin= g oneself really helps here, but I'll try it too:

> So, = if I have this, which follows the same common form we use in RFCs:
> =
> "This document describes a service that provides service X while adhering to=20 the principles of REpresentational State Transfer
> (REST; [xxxx]).&q= uot;
>
> What would you suggest we put f= or "xxxx" there?

What I'm trying to a= chieve is an answer to that question for a document I'm shepherding.=C2= =A0 You've given one answer (more than once now); thank you for that.= =C2=A0 Other people seem to have other opinions, in some cases suggesting t= he document should be saying something else completely.=C2=A0 That's wh= y this thread is still going.

I like Mike=E2=80=99s experiment, but I agree with Mark that the IETF has n= o need to spend an enormous amount of cycles on this.
=
I agree.=C2=A0 I just want to move this document forward.
-MSK
--089e010d8d02bd390d0503807c2f-- From nobody Sat Sep 20 09:01:47 2014 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 469E01A0109 for ; Sat, 20 Sep 2014 09:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 qnUCbZgMfXcC for ; Sat, 20 Sep 2014 09:01:44 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68A431A00FE for ; Sat, 20 Sep 2014 09:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s8KG1bOO028597; Sat, 20 Sep 2014 18:01:37 +0200 (CEST) Received: from [192.168.217.106] (p5489260B.dip0.t-ipconnect.de [84.137.38.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8BD73433; Sat, 20 Sep 2014 18:01:36 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Sat, 20 Sep 2014 18:01:35 +0200 X-Mao-Original-Outgoing-Id: 432921694.909674-45fc1c2aca19a7cae84c47b9f0a43923 Content-Transfer-Encoding: quoted-printable Message-Id: <6A03AF70-34AD-43B5-B4E8-15BAF39D1ADA@tzi.org> References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <561C70B6-7D61-4ECA-92B4-0DB6F3BB50FD@mnot.net> <57604ECC-2DF0-480E-B2CA-929695EB8CA6@tzi.org> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6PN1oySUJ0kAHuEr0X923r-J7B0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 16:01:46 -0000 On 20 Sep 2014, at 17:01, Murray S. Kucherawy = wrote: > for a document I'm shepherding It=92s probably easier to answer your question in an intelligent way if = you share what that document is... As posed, this simply is not a new question, and there is the tried and = true answer [RFC 6120, RFC 6503, RFC 6690, RFC 7231, RFC 7252], = variations of which Julian and I gave. RFC 6392 chose not to give a = reference, and this and other documents [RFC 7285] use the term = =93RESTful=94 or =93REST-ful=94 without distinction from REST, RFC 6272 = even seems to equate it with REST. (A few more documents, e.g. RFC = 6574, are using =93RESTful=94 as a part of the name of the CoRE working = group only. By now you probably can guess why I do care about this = issue.) Gr=FC=DFe, Carsten From nobody Sat Sep 20 22:51:15 2014 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 068681A034A for ; Sat, 20 Sep 2014 22:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jD2IZOObeWpq for ; Sat, 20 Sep 2014 22:51:10 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F4411A0345 for ; Sat, 20 Sep 2014 22:51:10 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id mc6so5173390lab.34 for ; Sat, 20 Sep 2014 22:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=euIbBUhs3yQZi5JJflv9gFzIQORaIgcrOwaPMTygNc0=; b=GXL0glHoS3qM/x0PjlBjn9DjmiCTcsM74LgGQ32VzPjLpokxckU8seWOB0Q7Qt/9nJ pVYp5XzWDk5TFUnqf0DttHJAv8nuBNBB5Fe4Uvm0aXdnThT/S5YVrU8yLA8KGWk8rEC+ sVJkMdHiRIqejLz66+K4hUuiIZHQgv6TyaBqBV1OEIMVN1sO3lekYkiXlPJ8liYNPRj6 KJUcN8357c+tzkxwKG9HgXsB9Zx4yQjfA4rwopXqQakkJVGxZ9m64k/jZjZmXzw8wIZz LK+hn8Q//5ix9Z7jF+cBiLwoTYGHpCXBWbIGaA6YlbJl9P6NaLRAfi/ek+b9/ZqmMWMe ZnBg== MIME-Version: 1.0 X-Received: by 10.152.1.6 with SMTP id 6mr17439947lai.22.1411278668514; Sat, 20 Sep 2014 22:51:08 -0700 (PDT) Received: by 10.25.211.7 with HTTP; Sat, 20 Sep 2014 22:51:08 -0700 (PDT) In-Reply-To: <6A03AF70-34AD-43B5-B4E8-15BAF39D1ADA@tzi.org> References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <561C70B6-7D61-4ECA-92B4-0DB6F3BB50FD@mnot.net> <57604ECC-2DF0-480E-B2CA-929695EB8CA6@tzi.org> <6A03AF70-34AD-43B5-B4E8-15BAF39D1ADA@tzi.org> Date: Sat, 20 Sep 2014 22:51:08 -0700 Message-ID: From: "Murray S. Kucherawy" To: Carsten Bormann Content-Type: multipart/alternative; boundary=089e013c6706b74b6505038ceb7a Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/nBxa6I2ahd4wWGsbGIONvIiR5Us Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 05:51:12 -0000 --089e013c6706b74b6505038ceb7a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Sep 20, 2014 at 9:01 AM, Carsten Bormann wrote: > On 20 Sep 2014, at 17:01, Murray S. Kucherawy wrote= : > > > for a document I'm shepherding > > It=E2=80=99s probably easier to answer your question in an intelligent wa= y if you > share what that document is... > Have a look at https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/. -MSK --089e013c6706b74b6505038ceb7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Sep 20, 2014 at 9:01 AM, Carsten Bormann <cabo@tzi.org= > wrote:
On = 20 Sep 2014, at 17:01, Murray S. Kucherawy <superuser@gmail.com> wrote:

> for a document I'm shepherding

It=E2=80=99s probably easier to answer your question in an intellige= nt way if you share what that document is...
--089e013c6706b74b6505038ceb7a-- From nobody Sun Sep 21 00:35:02 2014 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 414671A000B for ; Sun, 21 Sep 2014 00:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 wpTZNjIuypBw for ; Sun, 21 Sep 2014 00:35:00 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C185A1A0008 for ; Sun, 21 Sep 2014 00:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s8L7YuZQ026576; Sun, 21 Sep 2014 09:34:56 +0200 (CEST) Received: from [192.168.217.145] (p548911B0.dip0.t-ipconnect.de [84.137.17.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E42EF639; Sun, 21 Sep 2014 09:34:55 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Sun, 21 Sep 2014 09:34:54 +0200 X-Mao-Original-Outgoing-Id: 432977694.443792-eee14b341ef6735104695ccd69e00336 Content-Transfer-Encoding: quoted-printable Message-Id: <3E85BC44-0589-478C-985F-71A47D415F9B@tzi.org> References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <561C70B6-7D61-4ECA-92B4-0DB6F3BB50FD@mnot.net> <57604ECC-2DF0-480E-B2CA-929695EB8CA6@tzi.org> <6A03AF70-34AD-43B5-B4E8-15BAF39D1ADA@tzi.org> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/PQ8HcRvbl-bHEEystgPyWQtzmOw Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 07:35:01 -0000 On 21 Sep 2014, at 07:51, Murray S. Kucherawy = wrote: > Have a look at = https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/. Thanks. To avoid the somewhat ill-defined =93RESTful=94, I would change = =93RESTful practices=94 into =93practices informed by the = Representational State Transfer [REST] architectural style=94, change = =93RESTful web services=94 similarly into =93web services informed by = the Representational State Transfer [REST] architectural style", and add = the reference. Gr=FC=DFe, Carsten From nobody Sun Sep 21 07:36:45 2014 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 2D2591A0326; Fri, 19 Sep 2014 09:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 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, RP_MATCHES_RCVD=-1.652, 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 PvbTT7S1vezV; Fri, 19 Sep 2014 09:38:58 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F39281A0330; Fri, 19 Sep 2014 09:38:56 -0700 (PDT) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s8JGcKGD014824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Sep 2014 12:38:20 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s8JGcKGD014824 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1411144701; bh=QL0iW1SXRV0Ejg4u1U04MoyJUVk=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=HNIwVzA+4kcaaQVwgkEA85wxm7Gw2fBhnJ7jD/t45Zbc6187MpONq6FysMEPZ9RMi lT95/zeyWKQb+ZRqFssS9t+ZrlioVImV9MaFwYtpomd+/IXLoaLGSCCaSv55klQSs0 uYiAxD++SwXe71+gXbNsz0dNX+Rk5GNYRjriavZ4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s8JGcKGD014824 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd54.lss.emc.com (RSA Interceptor); Fri, 19 Sep 2014 12:38:05 -0400 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s8JGc4p5019265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Sep 2014 12:38:05 -0400 Received: from mx15a.corp.emc.com ([169.254.1.67]) by mxhub16.corp.emc.com ([128.222.70.237]) with mapi; Fri, 19 Sep 2014 12:38:04 -0400 From: "Black, David" To: "Henry S. Thompson" , "apps-discuss@ietf.org" , "draft-ietf-mile-enum-reference-format.all@tools.ietf.org" , "mile@ietf.org" Date: Fri, 19 Sep 2014 12:38:03 -0400 Thread-Topic: Early Appsdir review of draft-ietf-mile-enum-reference-format-08 Thread-Index: Ac/Oqyf7X64mBHLhQj62ke4xTH3MkgFeiRQA Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077D725613@MX15A.corp.emc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QhgSdKEuAOoP1GzdWGBQ0k64xhE X-Mailman-Approved-At: Sun, 21 Sep 2014 07:36:43 -0700 Cc: Takeshi Takahashi , S Moonesamy Subject: Re: [apps-discuss] Early Appsdir review of draft-ietf-mile-enum-reference-format-08 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, 19 Sep 2014 16:39:02 -0000 Henry, Thank you for this review, and on the major issue, namely use of this schem= a by IODEF, this draft is guilty as charged ;-). The current intent (as I understand discussion in the mile WG) is that the existing IODEF schema (RFC 5070) will not be updated, but a future version of the IODEFv2 draft will use this reference format via reference to the schema in this draft. On the first two registry issues: - All the fields are mandatory, including abbreviation, which is used in the schema. - Version is the version of the referenced specification. We'll make all of this clear in the revised draft. On the third registry issue: > 3) Broken record time: The lack of any specified mapping from the (to > my mind) unnecessary level of indirection from integers via > registry entries to URIs which would actually give _access_ to such > entries is irritating at least. Can't we at least _ask_ that IANA > provide such a mapping, along the lines of >=20 > http://www.iana.org/assignments/enumeration-reference-type/abbrev_vers= ion So, for a reference to version 2.5 of the CXI spec, the URI would be: http://www.iana.org/assignments/enumeration-reference-type/CXI_2.5 Is that what you envision? If so, the current allowance for all printable ASCII characters in version strings will require percent-encoding in those URIs, e.g. if a '/' is embed= ded in a version string. Thanks, --David > -----Original Message----- > From: Henry S. Thompson [mailto:ht@inf.ed.ac.uk] > Sent: Friday, September 12, 2014 1:00 PM > To: apps-discuss@ietf.org; draft-ietf-mile-enum-reference- > format.all@tools.ietf.org; mile@ietf.org > Cc: Melnikov Alexey Takeshi Takahashi; S Moonesamy= ; > Claudio Allocchio > Subject: Early Appsdir review of draft-ietf-mile-enum-reference-format-08 >=20 > I have been selected as the Applications Area Directorate reviewer for > this draft. >=20 > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your WG chairman(s) > before posting a new version of the draft. >=20 > Document: draft-ietf-mile-enum-reference-format-08 > Title: IODEF Enumeration Reference Format > Reviewer: Henry S. Thompson > Review Date: 2014-09-12 > Summary: This draft has a serious structural problem, which needs to > be resolved before it can progress >=20 > Major Issues: >=20 > This draft identifies a problem with _The Incident Object Description > Exchange Format_ (IODEF) [1] as regards the means provided to specifiy > references to IDS alerts etc., and proposes changes to the Reference > class in IODEF [2] and to its XML serialization. >=20 > The proposal as such is fine, but the draft does not adequately > address the question of how the proposed change is to be integrated > into the existing definition of the XML serialization, as specified in > the XML schema given in IODEF [3]. >=20 > The schema given in IODEF puts the (original) ReferenceName element in > the IODEF namespace, urn:ietf:params:xml:ns:iodef-1.0. The schema > given in the draft at hand puts the new one in a new namespace, > urn:ietf:params:xml:ns:iodef-enum-1.0 . >=20 > This means that the example Reference serialization given in section > 2.1 cannot be validated successfully, either against the IODEF schema, > or the one in this draft, or a combination of the two. >=20 > I note that IODEFv2 [4] has no changes in this regard either. >=20 > I think this needs to be coordinated with IODEFv2, so that it contains > a revised schema for the IODEF namespace. There a number of ways this > could be done, depending on the approach you jointly agree to take wrt > backwards compatibility. Assuming you want backward compatibility, > i.e. you want existing IODEF XML serializations to be valid against > the schema in IODEFv2, then you will want >=20 > a) To make the example explicit wrt namespaces: >=20 > 1.0" > xmlns:iodef=3D"urn:ietf:params:xml:ns:iodef-1.0"> > > CXI-1234-XYZ > > http://cxi.example.com > Foo > >=20 > b) To modify the IODEFv2 schema along the following lines: >=20 > >=20 > ... >=20 > xmlns:iodefEnum=3D"urn:ietf:params:xml:ns:iodef-enum-1.0"= > > > > > type=3D"iodef:MLStringType"/> > > > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > >=20 > Minor Issues: >=20 > 1) Please clarify whether the 'abbreviation' field in the registry is > required or optional, and include an 'abbreviation' in the example > registry entry. >=20 > 2) Please explain what the 'version' entry in the registry is for -- > version of what? If it's a version of the specification, how is > that not covered by the 'specification' field? The reader finds > the use of 'version: any' in the registry example completely > baffling. . . >=20 > 3) Broken record time: The lack of any specified mapping from the (to > my mind) unnecessary level of indirection from integers via > registry entries to URIs which would actually give _access_ to such > entries is irritating at least. Can't we at least _ask_ that IANA > provide such a mapping, along the lines of >=20 > http://www.iana.org/assignments/enumeration-reference-type/abbrev_vers= ion >=20 > Nits: >=20 > The subsections of section 2 must not be marked up properly, as they > don't make it into the index. >=20 > [1] https://tools.ietf.org/html/rfc5070 > [2] https://tools.ietf.org/html/rfc5070#section-3.9.1 > [3] https://tools.ietf.org/html/rfc5070#section-8 > [4] http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-08.html >=20 > -- > Henry S. Thompson, School of Informatics, University of Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-444= 0 > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail from me _always_ has a .sig like this -- mail without it is forged > spam] From nobody Sun Sep 21 09:23:28 2014 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 3B9CD1A0280 for ; Sun, 21 Sep 2014 09:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohUi5MFgMrsg for ; Sun, 21 Sep 2014 09:23:20 -0700 (PDT) Received: from mail.santronics.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 19D8D1A023F for ; Sun, 21 Sep 2014 09:23:19 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1504; t=1411316595; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=aEeYFh1GVK0Eax49mxRZTsmD2Mc=; b=VkvdWuV4n8keFQC+JqJn GNQwGz7jwG6DzMTyzsh+192Y0fnD7U5b6l7FpiTN70H44zv7vclFXDVu/r6xPoM6 NoYtkOWJPE3TjRXyj/tj9MMKLbloMXslE0AfEbjgwY5JncG1s7Gty1Cibn0RFpSC I7Z0LKsze/P7xaGMhuuekPM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sun, 21 Sep 2014 12:23:15 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2206682146.10652.3100; Sun, 21 Sep 2014 12:23:15 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1504; t=1411316244; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=/5ptF/y 9lwbti5OmK4cyAkFxy+5OAcTy9Vkt7FVgtd8=; b=hrrsMDOHAFvoQZSb9lqd2Kd vt0Ue070sFxra3CX7hUrNj0GXbZCWpb+Bz+Eh+ATLXsYwa/Se7MnFiWBY3zjNf24 djc/adp1jBwKgmaHLnDloCp5mfHOTDP++U0dBMaUBiA+ZotE1Ge6ZDRPAQhNS++l 5clD0tcWu1R/+GBFloak= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sun, 21 Sep 2014 12:17:24 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 799124563.9.6448; Sun, 21 Sep 2014 12:17:24 -0400 Message-ID: <541EFB6F.6070803@isdg.net> Date: Sun, 21 Sep 2014 12:23:11 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Carsten Bormann , "Murray S. Kucherawy" References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <561C70B6-7D61-4ECA-92B4-0DB6F3BB50FD@mnot.net> <57604ECC-2DF0-480E-B2CA-929695EB8CA6@tzi.org> <6A03AF70-34AD-43B5-B4E8-15BAF39D1ADA@tzi.org> <3E85BC44-0589-478C-985F-71A47D415F9B@tzi.org> In-Reply-To: <3E85BC44-0589-478C-985F-71A47D415F9B@tzi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/VKYEYIGrKyYk7I678TGNPQMFgoE Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 16:23:25 -0000 On 9/21/2014 3:34 AM, Carsten Bormann wrote: > On 21 Sep 2014, at 07:51, Murray S. Kucherawy wrote: > >> Have a look at https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/. > > Thanks. To avoid the somewhat ill-defined �RESTful�, I would change �RESTful practices� into �practices informed by the Representational State Transfer [REST] architectural style�, change �RESTful web services� similarly into �web services informed by the Representational State Transfer [REST] architectural style", and add the reference. > > Gr��e, Carsten That or remove it all together and just say "standard web-based (or http) query methods. In fact, at the end of the intro, it says this: The purpose of this document is to clarify the use of standard HTTP mechanisms for this application. That line should probably in the abstract and/or earlier in the intro. RESTFul should only suggest to the reader that there is a formal HTTP-query-based API for input and output. I haven't read Roy's doc but I don't think I need to. Does the reader need to read it? Anyway, thats my opinion. "RESTFUL practices" is fine to me because I am an API developer so I know what it means or what it tries to imply. Question, does Roy's doc provide a mechanism or methods for optimizing HTTP Client/Service query frameworks? If it does, then the reader might be interesting in exploring that if that is what "Restful Practices" means. -- HLS From nobody Sun Sep 21 09:54:41 2014 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 4AEDF1A010D for ; Sun, 21 Sep 2014 09:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf4mGfcU7O43 for ; Sun, 21 Sep 2014 09:54:37 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F461A00BF for ; Sun, 21 Sep 2014 09:54:36 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id ik5so2217815vcb.40 for ; Sun, 21 Sep 2014 09:54:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=oz7s8KLa2oOEVpyz0gXuOfYjpqtrPFnS0x4oZtPevcQ=; b=lW79BKFjZEc1A6wbvjG/36lOXYw78s9XMCUJDmRKiZAGqOjTf1O5t9LcVk79Xgps5X tGJspX/8GPqWf4RbMcMFrZhWBCXVywhMXeMeSjauyWPsoFbiIdZ9HG1OGO/YBZ1gDDXk zcgerJvBV2Dk0vf1nIae7ZWSeEUISzkotInRyDdDrj2WB23h24b/eERAXYU77/qJnVP0 2lhB2RT5cqZLiNbK9Me8Y20GWc/cf8uU2bK6wk9z9P/A5cDjKolOVn3Mo382V5yBQX78 exrbBxZTf57smpLC49Fs77Pky0PWhpDUG01emUjYgwt+IZDhqaizeZAK1BD19ncKaVFq sWJw== X-Gm-Message-State: ALoCoQlO1gTSXyTuZSVzgHf33x6A9YJs5CZBsv52yvvvBQrB8bdstkFlV5KxflLS5gPOPM7skRCB X-Received: by 10.221.62.194 with SMTP id xb2mr2417428vcb.40.1411318475510; Sun, 21 Sep 2014 09:54:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.214.4 with HTTP; Sun, 21 Sep 2014 09:54:15 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <541EFB6F.6070803@isdg.net> References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <561C70B6-7D61-4ECA-92B4-0DB6F3BB50FD@mnot.net> <57604ECC-2DF0-480E-B2CA-929695EB8CA6@tzi.org> <6A03AF70-34AD-43B5-B4E8-15BAF39D1ADA@tzi.org> <3E85BC44-0589-478C-985F-71A47D415F9B@tzi.org> <541EFB6F.6070803@isdg.net> From: Tim Bray Date: Sun, 21 Sep 2014 09:54:15 -0700 Message-ID: To: Hector Santos Content-Type: multipart/alternative; boundary=001a1136211e65eaea05039630d5 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8VMUcGt63XBogNXWhknMFjGtBuM Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 16:54:39 -0000 --001a1136211e65eaea05039630d5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Sep 21, 2014 at 9:23 AM, Hector Santos wrote: Anyway, thats my opinion. "RESTFUL practices" is fine to me because I am an > API developer so I know what it means or what it tries to imply. > =E2=80=8BIn industrial practice it means JSON-over-HTTP. In this document, I think it amounts to arm-waving. I think the best solution to Murray=E2=80=99s problem in this case is is to remove the =E2= =80=8Bterm RESTful; I don=E2=80=99t think it really adds value to the draft. > > Question, does Roy's doc provide a mechanism or methods for optimizing > HTTP Client/Service query frameworks? If it does, then the reader might = be > interesting in exploring that if that is what "Restful Practices" means. > > -- > HLS > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a1136211e65eaea05039630d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = Sun, Sep 21, 2014 at 9:23 AM, Hector Santos <hsantos@isdg.net> wrote:
=
Anyway, thats my opinion. "RESTFUL practices"= is fine to me because I am an API developer so I know what it means or wha= t it tries to imply.

=E2=80=8BIn industrial practice it mea= ns JSON-over-HTTP. =C2=A0

In this document, I think it amounts to arm-waving. I think the best solut= ion to Murray=E2=80=99s problem in this case is is to remove the =E2=80=8Bt= erm RESTful; I don=E2=80=99t think it really adds value to the draft.
=
=C2=A0

Question, does Roy's doc provide a mechanism or methods for optimizing = HTTP Client/Service query frameworks?=C2=A0 If it does, then the reader mig= ht be interesting in exploring that if that is what "Restful Practices= " means.

--
HLS



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



--
=
- Tim Bray (If you=E2=80=99d like to send me a privat= e message, see htt= ps://keybase.io/timbray)
--001a1136211e65eaea05039630d5-- From nobody Mon Sep 22 07:08:04 2014 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 099F01A1B26 for ; Mon, 22 Sep 2014 07:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NMgSvH-zTLo for ; Mon, 22 Sep 2014 07:07:48 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 787CC1A6EED for ; Mon, 22 Sep 2014 06:52:56 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id o8so49185qcw.35 for ; Mon, 22 Sep 2014 06:52:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gSbfyzbgvrEi6m3iCf8Pg4zNZkrogX2296a4U0nXakI=; b=U/G2/ZdkGuXEGgNASaVqiIcIrrAvb2fVYAZS79M17vebNKfT0VETsybF7yYgk5MJtQ QMjietyhDV+4cuoor9Kqw/EZMDZkkee2vpGkeH6sYYicu2k2IK94k86wcnL84yYXRQ0l ia7V1aZ0ndb1XUYZ2P/dEp7GjbymC5Vz+JfOgPbbksWPb9K4gDLWj/qudVMv5qUPqF3p IJpHm8FjZV8XxVndjWfhWKNsDrwDXcTYd3odSCFY9J3jeBGj/zffbp0xTVFn1UaVo4k9 ihD04PmPCyIl75GXH1lRdZ+efhyDos7uYnI0Y3f5r1EPKzM3rDPrsIUEFdkMl3lcjRnl 8YmQ== X-Gm-Message-State: ALoCoQkCTn/E2FOykhy2NsO29sTobbMRaZCiXvPd4PSFLyErg230t6ywOfRL2bIPuO5CP6Yyfh/7 X-Received: by 10.229.230.3 with SMTP id jk3mr25090413qcb.24.1411393975623; Mon, 22 Sep 2014 06:52:55 -0700 (PDT) Received: from Everready.local ([76.73.248.16]) by mx.google.com with ESMTPSA id n46sm7797993qgn.9.2014.09.22.06.52.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Sep 2014 06:52:55 -0700 (PDT) Message-ID: <542029B1.7080103@fletcherpenney.net> Date: Mon, 22 Sep 2014 09:52:49 -0400 From: "Fletcher T. Penney" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> <54181186.4030507@ninebynine.org> <541844C3.2030200@ninebynine.org> <541868BD.3040501@fletcherpenney.net> <5419466B.6080403@ninebynine.org> In-Reply-To: <5419466B.6080403@ninebynine.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hs1sc5tOx6W3qsr_GuALnCauMzs Subject: Re: [apps-discuss] Request additional reviewer for Markdown X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 14:07:52 -0000 On 9/17/14, 4:29 AM, Graham Klyne wrote: > We don't currently have enough experience to know how to best describe > Markdown flavours, particularly in a way that maximizes > interoperability, so I'd argue for simplicity and flexibility, which I > think a list of "rules" can be. I absolutely agree with this sentiment, but I believe you and I have different definitions of the word simplicity. ;) For example: Content-Type: text/markdown; charset=UTF-8; flavor=GitHub; processor="MultiMarkdown-3.0 -c" In my view, this is bordering on the edge of simplicity vs complexity. I'm already wondering, did you mean GFM or MMD? Why specify both? (This is a rhetorical question, BTW) But to add anything else (e.g. a list of which options are enabled, which are disabled, etc.) is really getting too complicated, IMHO. The reality of the Markdown ecosystem is complex, messy, and still in flux. To try to create a complex schema to accurately classify the author's exact intention with this level of specificity seems to be a bit of a fool's errand at this time. Stick to the 50,000 foot view -- specify a "flavor/processor/whatever" and leave it at that. If the processor is allowed to include command line arguments as a single string (as above), then that might be a necessary evil. But at least it should take care of allowing identification the author's intent. FTP -- Fletcher T. Penney fletcher@fletcherpenney.net From nobody Mon Sep 22 10:42:13 2014 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 675761A1AF4 for ; Mon, 22 Sep 2014 10:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02_pP-cdf61Z for ; Mon, 22 Sep 2014 10:42:10 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2C2D1A1AA3 for ; Mon, 22 Sep 2014 10:42:09 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id u56so3304493wes.11 for ; Mon, 22 Sep 2014 10:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k5hmuJhimeeZC2t4FX9RnS9GQYYp6BoDZM1dBRWLeEc=; b=1GQA0GXY8tyvI8sM1EGMVSC6rMAzNpgKYTJCdTZ9jivvO5bZOTru+TuwswpPCcemJt CrJKSRle6PVNj8q7C1TNV5L5h8EvTcKbcdHMktUJSu4ts2q5khDhYpiggHFDrSJfNhKG wQuZUrRHeB4Txuo+XWOJ3wZM8kt9OyswM0TCFnyV9OI6OmBtndB3TebTn7oQQC1mIH60 shqe/2VtagDT7M8XYX1NMQGpiP1Bi8zIEHu7zpqO8obQQZ9ggO+vsr0MUJQ1ex07oAkb EWJzyM1qROt2GfR1Be9hVrF5JE2VRdOUOBPo1kGJWEOjre+lBPpr0/ZcfAiU0YO4lfAi dPbQ== MIME-Version: 1.0 X-Received: by 10.180.184.20 with SMTP id eq20mr16752981wic.61.1411407728508; Mon, 22 Sep 2014 10:42:08 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Mon, 22 Sep 2014 10:42:08 -0700 (PDT) In-Reply-To: <542029B1.7080103@fletcherpenney.net> References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> <54181186.4030507@ninebynine.org> <541844C3.2030200@ninebynine.org> <541868BD.3040501@fletcherpenney.net> <5419466B.6080403@ninebynine.org> <542029B1.7080103@fletcherpenney.net> Date: Mon, 22 Sep 2014 10:42:08 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Fletcher T. Penney" Content-Type: multipart/alternative; boundary=001a11c3536a4b68740503aaf8b3 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QoUIOlT8mTQQB1mtheFY--qNbF8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Request additional reviewer for Markdown X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 17:42:11 -0000 --001a11c3536a4b68740503aaf8b3 Content-Type: text/plain; charset=UTF-8 On Mon, Sep 22, 2014 at 6:52 AM, Fletcher T. Penney < fletcher@fletcherpenney.net> wrote: > The reality of the Markdown ecosystem is complex, messy, and still in > flux. To try to create a complex schema to accurately classify the > author's exact intention with this level of specificity seems to be a bit > of a fool's errand at this time. Stick to the 50,000 foot view -- specify > a "flavor/processor/whatever" and leave it at that. If the processor is > allowed to include command line arguments as a single string (as above), > then that might be a necessary evil. But at least it should take care of > allowing identification the author's intent. +1. Moreover, providing more direction than that, especially down to the level of command line options and minimum package versions, smells a lot like a security problem waiting to happen. -MSK, just participatin' --001a11c3536a4b68740503aaf8b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 22, 2014 at 6:52 AM, Fletcher T. Penney <fletcher@fletcherpenney.net> wrote:
The re= ality of the Markdown ecosystem is complex, messy, and still in flux.=C2=A0= To try to create a complex schema to accurately classify the author's = exact intention with this level of specificity seems to be a bit of a fool&= #39;s errand at this time.=C2=A0 Stick to the 50,000 foot view -- specify a= "flavor/processor/whatever" and leave it at that.=C2=A0 If the p= rocessor is allowed to include command line arguments as a single string (a= s above), then that might be a necessary evil. But at least it should take = care of allowing identification the author's intent.

= +1.=C2=A0 Moreover, providing more direction than that, especially down to = the level of command line options and minimum package versions, smells a lo= t like a security problem waiting to happen.

-MSK, just p= articipatin'
--001a11c3536a4b68740503aaf8b3-- From nobody Mon Sep 22 11:34:37 2014 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 56AE61A1BC8 for ; Mon, 22 Sep 2014 11:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 0qJZJk3reTDy for ; Mon, 22 Sep 2014 11:34:35 -0700 (PDT) Received: from cp.hebergementsolutions.com (cp.hebergementsolutions.com [184.170.132.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 987FC1A1BE8 for ; Mon, 22 Sep 2014 11:34:35 -0700 (PDT) Received: from [173.246.4.178] (port=53943 helo=minimi.michelf.ca) by cp.hebergementsolutions.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XW8TS-0000t9-Ng for apps-discuss@ietf.org; Mon, 22 Sep 2014 14:36:34 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michel Fortin In-Reply-To: <542029B1.7080103@fletcherpenney.net> Date: Mon, 22 Sep 2014 14:34:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <68C2BA5D-32C4-4BA0-9911-C75D837AEF36@michelf.ca> References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> <54181186.4030507@ninebynine.org> <541844C3.2030200@ninebynine.org> <541868BD.3040501@fletcherpenney.net> <5419466B.6080403@ninebynine.org> <542029B1.7080103@fletcherpenney.net> To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.1878.6) X-cPanel-MailScanner-Information: Please contact the ISP for more information X-cPanel-MailScanner-ID: 1XW8TS-0000t9-Ng X-cPanel-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-cPanel-MailScanner-SpamCheck: X-cPanel-MailScanner-From: michel.fortin@michelf.ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cp.hebergementsolutions.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - michelf.ca X-Get-Message-Sender-Via: cp.hebergementsolutions.com: authenticated_id: michel.fortin@michelf.ca Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/tuWL7xqWOF5WnBQiyjgFx5HH9d0 Subject: Re: [apps-discuss] Request additional reviewer for Markdown X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 18:34:37 -0000 Le 22-sept.-2014 =E0 9:52, Fletcher T. Penney = a =E9crit : > If the processor is allowed to include command line arguments as a = single string (as above), then that might be a necessary evil. But at = least it should take care of allowing identification the author's = intent. Well, command line arguments might for some implementations of Markdown. = I can't claim to have surveyed them all, but many Markdown processors = out there are actually libraries that often come with no command line = syntax, but with a programatic API meant to be called in a specific = language. This is the case of PHP Markdown for instance. To me, the = whole part that deals with processor arguments just seems out of place. --=20 Michel Fortin michel.fortin@michelf.ca http://michelf.ca From nobody Mon Sep 22 11:37:58 2014 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 0A89E1A1B4F for ; Mon, 22 Sep 2014 11:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpHlkcO0yD0e for ; Mon, 22 Sep 2014 11:37:55 -0700 (PDT) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FEE81A1B4B for ; Mon, 22 Sep 2014 11:37:55 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id e89so2947506qgf.12 for ; Mon, 22 Sep 2014 11:37:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=O3irgkA49c0FHmEKUI/AGyZtjCire4JJPD9kIQRDvwg=; b=O4C+1E+tHS47A9op0Cbp2vHrAwfWukcOTaFJ2OIHCzDWje5Z/0KoEnlE0bL5bRmUlo QR9agC4nffmUYtuHfqeBpFLDgYy/oCBP2XuP3Lz0ph7xQ9NVYE7WWRUI7ChpThsXIL7I dtUFD4UbcMegcZOTDlgOPndoJ4E/EGOZFYA/qiwCUoA2rNeDhR6QBWFwed4ur/fZz+jD yzH7n3duOLNArXpuduU04tt4nfTBMV4OSNyjtRqf+Qc6117AYlV+M6MgY9gi2yoCZjUh V+0sYbx2XSS4W0H08LNolZSDFt6DnqMYR7QEi+813juqDfr20kxBCtaADqDCyVHp7EZg RFSA== X-Gm-Message-State: ALoCoQndsi3+WRsnoFdeKNDy/oGS5S+AYZ23xHmrAbSGrUarpf6cdbPTN4JsjQOI1eod6xuu9nHq X-Received: by 10.140.32.102 with SMTP id g93mr5210182qgg.13.1411411074537; Mon, 22 Sep 2014 11:37:54 -0700 (PDT) Received: from Everready.local ([76.73.248.16]) by mx.google.com with ESMTPSA id s4sm8407221qay.36.2014.09.22.11.37.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Sep 2014 11:37:54 -0700 (PDT) Message-ID: <54206C80.90100@fletcherpenney.net> Date: Mon, 22 Sep 2014 14:37:52 -0400 From: "Fletcher T. Penney" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> <54181186.4030507@ninebynine.org> <541844C3.2030200@ninebynine.org> <541868BD.3040501@fletcherpenney.net> <5419466B.6080403@ninebynine.org> <542029B1.7080103@fletcherpenney.net> <68C2BA5D-32C4-4BA0-9911-C75D837AEF36@michelf.ca> In-Reply-To: <68C2BA5D-32C4-4BA0-9911-C75D837AEF36@michelf.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZHfOf5Oildvz88a_x9MFQyuJCSs Subject: Re: [apps-discuss] Request additional reviewer for Markdown X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 18:37:57 -0000 I would suggest that this is an argument for my original position of keeping this really simple. Specify a desired flavor of Markdown, and leave it at that. I suspect that practically speaking, if any further information is needed to correctly process a piece of text, an automated system of rule parsing is not going to get it right anyways.... F- On 9/22/14, 2:34 PM, Michel Fortin wrote: > Le 22-sept.-2014 à 9:52, Fletcher T. Penney a écrit : > >> If the processor is allowed to include command line arguments as a single string (as above), then that might be a necessary evil. But at least it should take care of allowing identification the author's intent. > > Well, command line arguments might for some implementations of Markdown. I can't claim to have surveyed them all, but many Markdown processors out there are actually libraries that often come with no command line syntax, but with a programatic API meant to be called in a specific language. This is the case of PHP Markdown for instance. To me, the whole part that deals with processor arguments just seems out of place. > > -- Fletcher T. Penney fletcher@fletcherpenney.net From nobody Mon Sep 22 12:20:10 2014 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 E21CF1A1BC7 for ; Mon, 22 Sep 2014 12:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 PUdvx4nnhSnY for ; Mon, 22 Sep 2014 12:20:06 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1FD1A1BBE for ; Mon, 22 Sep 2014 12:20:05 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D0D1F509B5 for ; Mon, 22 Sep 2014 15:20:04 -0400 (EDT) Message-ID: <5420765A.9070706@seantek.com> Date: Mon, 22 Sep 2014 12:19:54 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> <54181186.4030507@ninebynine.org> <541844C3.2030200@ninebynine.org> <541868BD.3040501@fletcherpenney.net> <5419466B.6080403@ninebynine.org> <542029B1.7080103@fletcherpenney.net> In-Reply-To: <542029B1.7080103@fletcherpenney.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/HcvQEVOb5ihJ7fGZ0Jy4O6Y0TDk Subject: Re: [apps-discuss] Request additional reviewer for Markdown X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 19:20:08 -0000 On 9/22/2014 6:52 AM, Fletcher T. Penney wrote: > > > On 9/17/14, 4:29 AM, Graham Klyne wrote: > >> We don't currently have enough experience to know how to best describe= >> Markdown flavours, particularly in a way that maximizes >> interoperability, so I'd argue for simplicity and flexibility, which I= >> think a list of "rules" can be. > > I absolutely agree with this sentiment, but I believe you and I have=20 > different definitions of the word simplicity. ;) > > > For example: > > Content-Type: text/markdown; charset=3DUTF-8; flavor=3DGitHub; > processor=3D"MultiMarkdown-3.0 -c" > > In my view, this is bordering on the edge of simplicity vs complexity. = > I'm already wondering, did you mean GFM or MMD? Why specify both?=20 > (This is a rhetorical question, BTW) [Yes, I know it's a rhetorical question, but...you asked... ;) ] In that particular case I wanted "real world" examples, and was not=20 inclined to provide two distinct examples in the draft, so I crammed=20 both into one header. A more real-world example (based on draft-02, which is forthcoming), is: Content-Type: text/markdown; flavor=3DOriginal; processor=3D"Markdown.pl-1.0.2b8 --html4tags" That is a real case. It is apparently widely known in the Markdown=20 community that Gruber's own implementations are at variance with his=20 syntax rules. Markdown.pl version 1.0.1 and 1.0.2b8 produce meaningfully = different results; in fact in a few cases the results are exactly=20 opposite by design. The Readme docs basically say that Gruber decided=20 some other way was better, so he changed it and bumped the version. Then there is the issue of --html4tags. With that argument you get
; = without it you get
(and other things). For people attempting to=20 output some kind of XHTML, this is a meaningful difference, even if the=20 implementation doesn't guarantee strict XHTML output. Fortunately in the case of Markdown.pl, there is only one argument that=20 matters, and it's a binary yes/no option. Thus the whole thing can be=20 documented and encapsulated without needing to deal with m x n x o=20 permutations. Sean From nobody Mon Sep 22 13:00:42 2014 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 0596D1A1B58 for ; Mon, 22 Sep 2014 13:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, 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 sxxuCY0on8ga for ; Mon, 22 Sep 2014 13:00:39 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2B24F1A1B51 for ; Mon, 22 Sep 2014 13:00:39 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PCVV80ANBK004J89@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 22 Sep 2014 12:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1411415748; bh=2A3TTtYvx2wUkhhI4wf8FEX/MRRsPvngup1xUXKCoCQ=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=CMbQ9xDqFM5Ndg+tXgwNo3IXsBNRbfvSo21WxGJh/nH1r5bCnAIHKu3PpB6KeUYH6 lqRa/MJ1+xehLIJCmngfClCLOr4GSRWKF2qMoio0VyrF5FjTmsA//AYcyl6F+zLNOL Vmo2RjSs/CjyBpSj6DW2cm+vVcvNu6fydMYo/R6A= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PCVUK8I1I8003X76@mauve.mrochek.com>; Mon, 22 Sep 2014 12:55:27 -0700 (PDT) Message-id: <01PCVV7VA7OC003X76@mauve.mrochek.com> Date: Mon, 22 Sep 2014 12:52:43 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 22 Sep 2014 10:42:08 -0700" References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> <54181186.4030507@ninebynine.org> <541844C3.2030200@ninebynine.org> <541868BD.3040501@fletcherpenney.net> <5419466B.6080403@ninebynine.org> <542029B1.7080103@fletcherpenney.net> To: "Murray S. Kucherawy" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/NKjDa4NRpEKaVM8VLuFgc9Llgrs Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Request additional reviewer for Markdown X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 20:00:41 -0000 > On Mon, Sep 22, 2014 at 6:52 AM, Fletcher T. Penney < > fletcher@fletcherpenney.net> wrote: > > The reality of the Markdown ecosystem is complex, messy, and still in > > flux. To try to create a complex schema to accurately classify the > > author's exact intention with this level of specificity seems to be a bit > > of a fool's errand at this time. Stick to the 50,000 foot view -- specify > > a "flavor/processor/whatever" and leave it at that. If the processor is > > allowed to include command line arguments as a single string (as above), > > then that might be a necessary evil. But at least it should take care of > > allowing identification the author's intent. > +1. Moreover, providing more direction than that, especially down to the > level of command line options and minimum package versions, smells a lot > like a security problem waiting to happen. +1. The point of registering things is to define an appropriate type label and registration data, including documenting any security issues. Cleaning up the media type itself in any sense is not a prerequisite to registration and in this case is not something the IETF should be doing. Ned From nobody Mon Sep 22 13:19:53 2014 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 8C6B31A1B51 for ; Mon, 22 Sep 2014 13:19:49 -0700 (PDT) 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_40=-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 7hUj_7VsVLoP for ; Mon, 22 Sep 2014 13:19:48 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D4AA1A1B2E for ; Mon, 22 Sep 2014 13:19:48 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8MKJf1d018274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 22 Sep 2014 13:19:44 -0700 Message-ID: <54208459.3090501@dcrocker.net> Date: Mon, 22 Sep 2014 13:19:37 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ned Freed , "Murray S. Kucherawy" References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> <54181186.4030507@ninebynine.org> <541844C3.2030200@ninebynine.org> <541868BD.3040501@fletcherpenney.net> <5419466B.6080403@ninebynine.org> <542029B1.7080103@fletcherpenney.net> <01PCVV7VA7OC003X76@mauve.mrochek.com> In-Reply-To: <01PCVV7VA7OC003X76@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 22 Sep 2014 13:19:46 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/iK5gVHgYGdGOt4LXYtRQvYvkIPU Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Request additional reviewer for Markdown X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 20:19:49 -0000 >>> Stick to the 50,000 foot view > +1. The point of registering things is to define an appropriate type label > and registration data, including documenting any security issues. > > Cleaning up the media type itself in any sense is not a prerequisite to > registration and in this case is not something the IETF should be doing. Yes, but... The 50,000 foot level rarely permits interoperability. My concern is that what gets registered needs to contain enough information for the recipient of the media type to be able to know what is needed to process what the author put there. To the extent that the world of this media type involves heuristics and other imprecisions, that's unfortunate; to the extent that that world suffers those hassles successfully, fine. No, it's not our job to fix their world. However the writeup needs to be clear/explicit about any lack of clarity in this... And to the extent that one use of the media type fits one version of the world and another fits a different one, and heuristics used in the field aren't generally successful, and the label doesn't distinguish, then we /added/ to the imprecision. It has sounded as if recent developments in that community have created some conflicting cases. At the least what we define for registration needs to permit easily distinguishing between them. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Sep 22 13:32:46 2014 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 4D50B1A6EF8 for ; Mon, 22 Sep 2014 13:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_g7mey_QhVv for ; Mon, 22 Sep 2014 13:32:40 -0700 (PDT) Received: from cp.hebergementsolutions.com (cp.hebergementsolutions.com [184.170.132.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0FE1A6EF1 for ; Mon, 22 Sep 2014 13:32:38 -0700 (PDT) Received: from [173.246.4.178] (port=55338 helo=minimi.michelf.ca) by cp.hebergementsolutions.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XWAJo-0001ZK-Sr for apps-discuss@ietf.org; Mon, 22 Sep 2014 16:34:44 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michel Fortin In-Reply-To: <5420765A.9070706@seantek.com> Date: Mon, 22 Sep 2014 16:32:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0D734B12-A66A-4D20-97B8-D79CAEB99519@michelf.ca> References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> <54181186.4030507@ninebynine.org> <541844C3.2030200@ninebynine.org> <541868BD.3040501@fletcherpenney.net> <5419466B.6080403@ninebynine.org> <542029B1.7080103@fletcherpenney.net> <5420765A.9070706@seantek.com> To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.1878.6) X-cPanel-MailScanner-Information: Please contact the ISP for more information X-cPanel-MailScanner-ID: 1XWAJo-0001ZK-Sr X-cPanel-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-cPanel-MailScanner-SpamCheck: X-cPanel-MailScanner-From: michel.fortin@michelf.ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cp.hebergementsolutions.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - michelf.ca X-Get-Message-Sender-Via: cp.hebergementsolutions.com: authenticated_id: michel.fortin@michelf.ca Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/uxQ8ZrCqvQP7Tf8kw2F_vpDHVEQ Subject: Re: [apps-discuss] Request additional reviewer for Markdown X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 20:32:42 -0000 Le 22-sept.-2014 =E0 15:19, Sean Leonard a =E9crit = : > Then there is the issue of --html4tags. With that argument you get =
; without it you get
(and other things). For people attempting = to output some kind of XHTML, this is a meaningful difference, even if = the implementation doesn't guarantee strict XHTML output. I'd question whether it is a good idea to say anything about the output. = Has the desired output format anything to do with the type of the = Markdown content? If you're going to specify output arguments for the sake of reproducing = the exact same output, wouldn't it be simpler and more robust to just = pass the HTML output around instead of the Markdown source? If you = really need to keep the Markdown source around, can't you standardize on = a workflow using multipart/alternative that includes both the Markdown = source and the resulting HTML? I can see why specify the flavor because this has something to do with = how the Markdown syntax is parsed. A small set of configuration = variables could be relevant if they affect how the document is = interpreted by the Markdown processor. But details in the output such as = XHTML/HTML termination of tags has little to do with the document = itself, and the output you want will actually change depending on the = context. --=20 Michel Fortin michel.fortin@michelf.ca http://michelf.ca From nobody Mon Sep 22 13:50:32 2014 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 7F6921A6F05 for ; Mon, 22 Sep 2014 13:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfDBx2h6n6rL for ; Mon, 22 Sep 2014 13:50:26 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C579D1A6F01 for ; Mon, 22 Sep 2014 13:50:25 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id z12so5065524lbi.9 for ; Mon, 22 Sep 2014 13:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=b5uRo+bW6aeFExxmlB9mKDPdSvHV5CzAQ4JsxiBE1VU=; b=Jt3fWxslkpQIAsOQiub69MgmG7ao39W2kx+OmaERl1XOIfgZj2GUqB2FJHnVwJGnso 2gJEuyLBgGOs2LlNO/TgYT90RbgxHQIgA21TT8i93HOYOjhBiWC/6pIDGcmVkEBlMViB GkHEMZdtdGMLo3tWrAqZP21Lx+P/T3nOKg1hpc9W34UsTj8yfWGmcNNM2il77/ylW0Pj DysK7Y2Nee4mLEqym/3YZz3Zo3XHwxCD3jKgQfEL6bOwYzo9wf0fMkKMKAIH2B3TZZbN GDKRrPECcJASL+b3DCXjo3pfI/y1qf13w4c4LjRUTpgh+cz51V6CWxM0vUoD2bf+38IX IplQ== MIME-Version: 1.0 X-Received: by 10.152.37.72 with SMTP id w8mr27754817laj.48.1411419024062; Mon, 22 Sep 2014 13:50:24 -0700 (PDT) Received: by 10.112.13.99 with HTTP; Mon, 22 Sep 2014 13:50:24 -0700 (PDT) Date: Mon, 22 Sep 2014 22:50:24 +0200 Message-ID: From: Melvin Carvalho To: Apps Discuss , Nick Jennings Content-Type: multipart/alternative; boundary=089e0160c1568efca90503ad994a Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/YaK5BrrAlzqViV1f826LFYj-JU0 Subject: [apps-discuss] IRC URIs to denote users X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 20:50:27 -0000 --089e0160c1568efca90503ad994a Content-Type: text/plain; charset=UTF-8 I was wondering if IRC URIs are standardized at all? The latest I found was : http://tools.ietf.org/html/draft-butcher-irc-url-04 I have a use case of marking reputation from one system (web chat room) to an IRC chat room, but I require an identifier for the user. The suggestions so far have been: irc://user@host irc://user@host/ -- trailing slash irc:user@host -- similar to xmpp irc://host/#user -- fragment could be problematic as per RFC 9386 I've gone with the second option for the moment Any pointers would be most welcome. --089e0160c1568efca90503ad994a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was wondering if IRC URIs are s= tandardized at all?

The latest I found was :

http://tools.ietf.= org/html/draft-butcher-irc-url-04

I have a use case of mar= king reputation from one system (web chat room) to an IRC chat room, but I = require an identifier for the user.

The suggestions so far hav= e been:

irc://user@host
irc://user@host/ -- trailing = slash
irc:user@host -- similar to xmpp
irc://host/#us= er -- fragment could be problematic as per RFC 9386

I'= ;ve gone with the second option for the moment

Any pointers would be= most welcome.


--089e0160c1568efca90503ad994a-- From nobody Mon Sep 22 14:45:48 2014 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 3F4CF1A1AA1 for ; Mon, 22 Sep 2014 14:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjZKNi7QRXVf for ; Mon, 22 Sep 2014 14:45:46 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5816C1A1A4A for ; Mon, 22 Sep 2014 14:45:46 -0700 (PDT) Received: (qmail 78423 invoked from network); 22 Sep 2014 21:45:43 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 22 Sep 2014 21:45:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=d502.54209887.k1409; i=johnl@user.iecc.com; bh=86i6ZXWNxfQtvPUBJu/6LSx13qVm6cvaGiQhjwmylAo=; b=0llDntQElmO9ON3Xb+xyjEBOKY7TZCwnLVh93xZehNBX+LY1fyDu4M84ypZfbT4toORKj6LFsLsiVirlh71bgbxTOFhp3Uskvg2gSB6bY0Kk389Ym/UAzFIogPABzTFcLU7VlTX7XWyLm2syF2is/39J1nJTHCuqSw/7sJJAxt3iqPlm3Z9gC3zgMfAP7go1u0ydMaMa4D6qMM4nLVnbNIaxXGhDLz/XK/ixp/GyIGb75m0pQGRCial7GMsHfZY1 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=d502.54209887.k1409; olt=johnl@user.iecc.com; bh=86i6ZXWNxfQtvPUBJu/6LSx13qVm6cvaGiQhjwmylAo=; b=zBPqUiB3g79Lsx+h2zfJX8aHtbzP+D7BPCnIBUDlntqjATVUee0tbRnBTjXF6vCI5K+hktJwA5Ju9wQNvMLCoxWmQY1+aPslK4N/ARrer1ObKO1PS+EAnESGM7dx/AvAZjWY+HODBR39uhsB/RfBFmdsVgWK4+j2n6eJMWRRUHbS7bgVRkiG4j5MFtddya+vqyJobEiolV9kpXbHxpNfSDz5EJiU43/tzGGhBeYLF8NU/nB5+/LM7xCHUkswmN14 Date: 22 Sep 2014 21:45:21 -0000 Message-ID: <20140922214521.54529.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <54208459.3090501@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/NMFTWOUokM72f6JKtX0RileRXJs Cc: dcrocker@bbiw.net Subject: Re: [apps-discuss] Request additional reviewer for Markdown X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 21:45:47 -0000 >My concern is that what gets registered needs to contain enough >information for the recipient of the media type to be able to know what >is needed to process what the author put there. This is sounding a lot like RFC 4263, for text/troff, where you can't usefully format the troff without knowing what options and pre- or postprocessors to use. So it has a process option to give people a hint of what flavor of troff it is: Content-Type: text/troff ; process="dformat | pic -n | troff -ms" I'm not saying this is a fabulous approach, but it's one we've used before. R's, John From nobody Mon Sep 22 15:42:27 2014 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 26B2E1A6F30; Mon, 22 Sep 2014 15:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sppzi3NaCZI; Mon, 22 Sep 2014 15:42:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F331A6F3C; Mon, 22 Sep 2014 15:42:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> Date: Mon, 22 Sep 2014 15:42:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XgtAJTJcK-Dpohq-OW0SfwsWVqo Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-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: Mon, 22 Sep 2014 22:42:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : The text/markdown Media Type Author : Sean Leonard Filename : draft-ietf-appsawg-text-markdown-02.txt Pages : 25 Date : 2014-09-22 Abstract: This document registers the text/markdown media type for use with Markdown, a family of plain text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-text-markdown-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 Mon Sep 22 16:45:31 2014 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 95FC01A6F5D for ; Mon, 22 Sep 2014 16:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dehDo5ID_elF for ; Mon, 22 Sep 2014 16:45:27 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D5291A02C0 for ; Mon, 22 Sep 2014 16:45:26 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id t60so3715672wes.22 for ; Mon, 22 Sep 2014 16:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RlrBRg+wFRay2pqdsaC3csNR5SGQ/G49JY7PG6Zavc4=; b=Jw6ZT+1PlR31gpXziNLG0b+yFFgFekoBqnV1LgxcIY+aZqBld/eW6mhqLhV1EWClLv mwVmmEemns4BRcNmWRrBPi8y7RZQYvO2eYq/5Ml9Ky/DIHoPz41L2x5Thybmkb8uj2mL ua2MyZ/YoNwc5kIAlmHcBcq7qAsPeOo5isEmshZq9iRcNNDL2SB3OmAmvBCy4UTNrLKl V6c/drsPscVNPcZdH2MvHYkMakIPU7pX3zhovCyNsr+kKVmNMVc7CSDL0ElkatzuGCz4 DO9i0UZyxp4lnAJDF2gIkYz6ItwDPQ7SSg8h4qKmgQ349nHNWaCDmH0XUZ6AT+HHAcGh 0H1A== X-Received: by 10.180.75.49 with SMTP id z17mr18220111wiv.3.1411429525585; Mon, 22 Sep 2014 16:45:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.77.136 with HTTP; Mon, 22 Sep 2014 16:45:05 -0700 (PDT) In-Reply-To: References: From: Ira McDonald Date: Mon, 22 Sep 2014 19:45:05 -0400 Message-ID: To: Melvin Carvalho Content-Type: multipart/alternative; boundary=f46d043895337f85bd0503b00b70 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/w2Szep8LDnBIFP6cW9p77EIHHck Cc: Apps Discuss Subject: Re: [apps-discuss] IRC URIs to denote users X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 23:45:29 -0000 --f46d043895337f85bd0503b00b70 Content-Type: text/plain; charset=UTF-8 Hi Melvin, The current IANA URI Schemes registry includes the following three schemes: irc prov/irc irc [ Dave_Thaler ] irc6 prov/irc6 irc6 [Dave_Thaler ] ircs prov/ircs ircs [Dave_Thaler ] All three of those are September 2012 provisional registrations (with references that include butcher and draft-mirashi-url-irc-01). Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Mon, Sep 22, 2014 at 4:50 PM, Melvin Carvalho wrote: > I was wondering if IRC URIs are standardized at all? > > The latest I found was : > > http://tools.ietf.org/html/draft-butcher-irc-url-04 > > I have a use case of marking reputation from one system (web chat room) to > an IRC chat room, but I require an identifier for the user. > > The suggestions so far have been: > > irc://user@host > irc://user@host/ -- trailing slash > irc:user@host -- similar to xmpp > irc://host/#user -- fragment could be problematic as per RFC 9386 > > I've gone with the second option for the moment > > Any pointers would be most welcome. > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --f46d043895337f85bd0503b00b70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Melvin,

The = current IANA URI Schemes registry includes the following
three schemes:=

i= rc prov/irc irc [Dave_Thaler]
irc6 prov/irc6 irc6 [Dave_Thaler]
ircs prov/ircs ircs [Dave_Thaler]

All three of those are September 2012 provisional registrations
(with references that include butcher and draft-mirashi-url-irc-01).
Cheers,
- Ira


Ira McDonald (Musician / Software Archi= tect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foun= dation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
C= o-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Ex= pert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
m= ailto: blueroo= fmusic@gmail.com
Winter=C2=A0 579 Park Place=C2=A0 Saline, MI=C2=A0 = 48176=C2=A0 734-944-0094
Summer=C2=A0 PO Box 221=C2=A0 Grand Marais, MI = 49839=C2=A0 906-494-2434


On Mon, Sep 22, 2014 at 4:50 PM, Melvin Carv= alho <melvincarvalho@gmail.com> wrote:
I was wonderi= ng if IRC URIs are standardized at all?

The latest I found was= :

http://tools.ietf.org/html/draft-butcher-irc-url-04
I have a use case of marking reputation from one system (web ch= at room) to an IRC chat room, but I require an identifier for the user.
=
The suggestions so far have been:

irc://user@host
irc://user@host/ -- trailing slash
irc:user@host -- similar = to xmpp
irc://host/#user -- fragment could be problematic as = per RFC 9386

I've gone with the second option for the= moment

Any pointers would be most welcome.



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


--f46d043895337f85bd0503b00b70-- From nobody Mon Sep 22 16:55:10 2014 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 DC72E1A6F3F for ; Mon, 22 Sep 2014 16:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 w8CJUx1b_eEw for ; Mon, 22 Sep 2014 16:55:06 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A871A02C0 for ; Mon, 22 Sep 2014 16:55:06 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 74158509B6 for ; Mon, 22 Sep 2014 19:55:05 -0400 (EDT) Message-ID: <5420B6CE.3030606@seantek.com> Date: Mon, 22 Sep 2014 16:54:54 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> In-Reply-To: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ibV-clZO_ZeNFsasKpzSn_a19K8 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 23:55:08 -0000 Colleagues, draft-02 incorporates a lot of public and private comments that were received over the last few weeks. Rather than reiterate all of the changes, I provided a change log in Appendix A. Best regards, Sean On 9/22/2014 3:42 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : The text/markdown Media Type > Author : Sean Leonard > Filename : draft-ietf-appsawg-text-markdown-02.txt > Pages : 25 > Date : 2014-09-22 > > Abstract: > This document registers the text/markdown media type for use with > Markdown, a family of plain text formatting syntaxes that optionally > can be converted to formal markup languages such as HTML. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-text-markdown-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 Mon Sep 22 18:24:45 2014 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 B6DBF1A6F66 for ; Mon, 22 Sep 2014 18:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, 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 CpNN-2aGBXfA for ; Mon, 22 Sep 2014 18:24:43 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4B48B1A1BD0 for ; Mon, 22 Sep 2014 18:24:43 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PCW6JT5JN4004C0H@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 22 Sep 2014 18:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1411435193; bh=hgkUyoQ810xm4wYl3ROzqUDHvbyvnG0N2GJpJEgPG2M=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=IvNqX5LPlNqru6FAaNhOVADsp6gOevXPB8Eyw6DHekrSJmnSwGepY9PZUQgMXi7e2 SppKPOZp7Q1Ov+bPvn2yi9TEFKXY2X87vhA4JV/mZtMxVDF4vvxkWs6RgSSIhE2H4s vcL/jWsuAcvx9AgYR/CKOS4mcfg7GxDchSOhIArc= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PCVRX4M2N40000SM@mauve.mrochek.com>; Mon, 22 Sep 2014 18:19:32 -0700 (PDT) Message-id: <01PCW6JOLASO0000SM@mauve.mrochek.com> Date: Mon, 22 Sep 2014 18:09:03 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 22 Sep 2014 13:19:37 -0700" <54208459.3090501@dcrocker.net> References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> <54181186.4030507@ninebynine.org> <541844C3.2030200@ninebynine.org> <541868BD.3040501@fletcherpenney.net> <5419466B.6080403@ninebynine.org> <542029B1.7080103@fletcherpenney.net> <01PCVV7VA7OC003X76@mauve.mrochek.com> <54208459.3090501@dcrocker.net> To: Dave Crocker Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZHroW0b34t238XAEFc12QG39HEo Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] Request additional reviewer for Markdown 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, 23 Sep 2014 01:24:44 -0000 > >>> Stick to the 50,000 foot view > > +1. The point of registering things is to define an appropriate type label > > and registration data, including documenting any security issues. > > > > Cleaning up the media type itself in any sense is not a prerequisite to > > registration and in this case is not something the IETF should be doing. > Yes, but... > The 50,000 foot level rarely permits interoperability. > My concern is that what gets registered needs to contain enough > information for the recipient of the media type to be able to know what > is needed to process what the author put there. Have you spent any time working with various markdown formats? I have, and one of the characteristics of it that I find most appealing is that it tends to produce something usable in almost all cases. It may not be exactly what the author intended, but if your representation needs are that exacting, you're shopping in the wrong market, and I suggest heading over to the one of the kiosks (PDF/Tex/Postscript/whatever) across the street. > To the extent that the world of this media type involves heuristics and > other imprecisions, that's unfortunate; to the extent that that world > suffers those hassles successfully, fine. No, it's not our job to fix > their world. > However the writeup needs to be clear/explicit about any lack of clarity > in this... Absolutely. > And to the extent that one use of the media type fits one version of the > world and another fits a different one, and heuristics used in the field > aren't generally successful, and the label doesn't distinguish, then we > /added/ to the imprecision. My personal preference would be to have a single parameterized type that covers a range of markdown formats. > It has sounded as if recent developments in that community have created > some conflicting cases. At the least what we define for registration > needs to permit easily distinguishing between them. Speaking as an outside observer who may not be aware of all the specifics, I think this really depends on what you mean by "conflict". If you mean "produces output that's not bit-for-bit compatible", then that's nothing new. If you mean "produces different and less than optimal output in some situations", then yeah, I think that's what's happened, and it's unfortunate but not fatal. But if you mean "produces indecipherable crap in some situations", then I really need to see some specific examples. Ned From nobody Tue Sep 23 01:58:03 2014 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 62E781A6F5A for ; Tue, 23 Sep 2014 01:58:01 -0700 (PDT) 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 HWH3SaddhVaC for ; Tue, 23 Sep 2014 01:58:00 -0700 (PDT) Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) by ietfa.amsl.com (Postfix) with ESMTP id EB87D1A1A5E for ; Tue, 23 Sep 2014 01:57:59 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1XWLuy-00007r-dv; Tue, 23 Sep 2014 09:57:52 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina-wl.atuin.ninebynine.org) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1XWLux-0002s1-3C; Tue, 23 Sep 2014 09:57:52 +0100 Message-ID: <5421360E.8060809@ninebynine.org> Date: Tue, 23 Sep 2014 09:57:50 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ned Freed , Sean Leonard References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> <54181186.4030507@ninebynine.org> <541844C3.2030200@ninebynine.org> <541868BD.3040501@fletcherpenney.net> <5419466B.6080403@ninebynine.org> <542029B1.7080103@fletcherpenney.net> <01PCVV7VA7OC003X76@mauve.mrochek.com> <54208459.3090501@dcrocker.net> <01PCW6JOLASO0000SM@mauve.mrochek.com> In-Reply-To: <01PCW6JOLASO0000SM@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/9GnXfsa_ExaIj46ZPrHGBtHzAEg Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Request additional reviewer for Markdown 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, 23 Sep 2014 08:58:01 -0000 On 23/09/2014 02:09, Ned Freed wrote: >> My concern is that what gets registered needs to contain enough >> >information for the recipient of the media type to be able to know what >> >is needed to process what the author put there. > Have you spent any time working with various markdown formats? I have, and one > of the characteristics of it that I find most appealing is that it tends to > produce something usable in almost all cases. > > It may not be exactly what the author intended, but if your representation > needs are that exacting, you're shopping in the wrong market, and I suggest > heading over to the one of the kiosks (PDF/Tex/Postscript/whatever) across the > street. +1. I have used Markdown in a context with exacting output format requirements, and those requirements were satisfied not by some "standard" specification, but by controlling the toolchain (using PanDoc to feed LaTeX). But in the document production process, Markdown provided a very useful tool for sharing and reviewing draft text without getting bogged down in formatting minutiae - IMO that's its value. Sean: I think that something missing from your introduction is that users may turn to Markdown for its "humane" qualities, even though (or even because) it requires surrendering a degree of fine control over the output generated. #g -- From nobody Tue Sep 23 04:55:08 2014 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 613781A710D for ; Tue, 23 Sep 2014 04:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIt4nMfT4pmw for ; Tue, 23 Sep 2014 04:55:05 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731961A1A9A for ; Tue, 23 Sep 2014 04:55:04 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id z12so8359589lbi.8 for ; Tue, 23 Sep 2014 04:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dk+KwgtvkLrWfB/sCYLPokeZV6IScwQXEotFhJUH1yw=; b=MM7ODfN1aP3N0ejdCMzzU1BodUWwq6GpD0b2dA29swprumDxAfVjn5Rujx2jtnw6sF jEGJ+HBqmDwV2BHMu5dC8wp9pSwT5pCru88Re2rT1wjxIeJNIYu8Mck69RsNPI0508mF 6mmBB0CpiP9crtbqCmWjpmG9ShDkEy0CEsPLjIbjb3kC33cXR5RXfCznG9x7Y9FB4Lcm OQ2WlXthTOSsgPtfHJ/R8rPkalMwikMtn5MPP82YhQ+r030qCprTrOSiUCJXpII5mKZV 35MnMdzowByWLQbD/SFamgi0irYKlryXyuRFg3R4pwpSGZ6ytub5TjXx4CriSn2fgCrV Sdmw== MIME-Version: 1.0 X-Received: by 10.112.161.70 with SMTP id xq6mr30990248lbb.49.1411473302621; Tue, 23 Sep 2014 04:55:02 -0700 (PDT) Received: by 10.112.13.99 with HTTP; Tue, 23 Sep 2014 04:55:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Sep 2014 13:55:02 +0200 Message-ID: From: Melvin Carvalho To: Ira McDonald , Benjamin Young Content-Type: multipart/alternative; boundary=001a11c25944d0154a0503ba3cea Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/xivtkdN3arMzhUR_zS51qD2VdzA Cc: Apps Discuss Subject: Re: [apps-discuss] IRC URIs to denote users 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, 23 Sep 2014 11:55:06 -0000 --001a11c25944d0154a0503ba3cea Content-Type: text/plain; charset=UTF-8 On 23 September 2014 01:45, Ira McDonald wrote: > Hi Melvin, > > The current IANA URI Schemes registry includes the following > three schemes: > > irc prov/irc irc [ > Dave_Thaler > > ] irc6 prov/irc6 > irc6 [Dave_Thaler > > ] ircs prov/ircs > ircs [Dave_Thaler > > ] > All three of those are September 2012 provisional registrations > (with references that include butcher and draft-mirashi-url-irc-01). > Thanks for the info! Both the referenced specs seem quite old. I think there was a time when Dave Thaler just put a ton of URI specs in the provisional queue, without necessarily major updates. It's still not 100% clear what the best pattern is, if any. Unless there's an objection may I propose: irc://user@host/ This is very much in line with the work of Ben Young (cc'd) http://userinfo.me/ Who proposes a neat way to get user profile info via HTTP as: http://user@host/ I believe the intention of this is to write an RFC, so I'd like to align future work with that if possible > > Cheers, > - Ira > > > Ira McDonald (Musician / Software Architect) > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music / High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto: blueroofmusic@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 > > > On Mon, Sep 22, 2014 at 4:50 PM, Melvin Carvalho > wrote: > >> I was wondering if IRC URIs are standardized at all? >> >> The latest I found was : >> >> http://tools.ietf.org/html/draft-butcher-irc-url-04 >> >> I have a use case of marking reputation from one system (web chat room) >> to an IRC chat room, but I require an identifier for the user. >> >> The suggestions so far have been: >> >> irc://user@host >> irc://user@host/ -- trailing slash >> irc:user@host -- similar to xmpp >> irc://host/#user -- fragment could be problematic as per RFC 9386 >> >> I've gone with the second option for the moment >> >> Any pointers would be most welcome. >> >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > --001a11c25944d0154a0503ba3cea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 23 September 2014 01:45, Ira McDonald <blueroofmusic@gmail.c= om> wrote:
Hi Melvin,

T= he current IANA URI Schemes registry includes the following
three schem= es:

irc prov/irc irc [Dave_Thaler]
irc6 prov/irc6 irc6 [Dave_Thaler]
ircs prov/ircs ircs [Dave_Thaler]

All three of those are September 2012 provisional regi= strations
(with references that include butcher and draft-mirashi-= url-irc-01).

Thanks f= or the info!

Both the referenced specs seem quite old.=C2= =A0 I think there was a time when Dave Thaler just put a ton of URI specs i= n the provisional queue, without necessarily major updates.

It's still not 100% clear what the best pattern is, if any.

<= /div>
Unless there's an objection may I propose:

irc://user@= host/

This is very much in line with the work of Ben Youn= g (cc'd)

http://userinfo.me/=

Who proposes a neat way to get user profile info via HTT= P as:

http://user@host/

I believe the i= ntention of this is to write an RFC, so I'd like to align future work w= ith that if possible
=C2=A0

Cheers,
- Ira


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

On Mon, Sep 22, 2014 = at 4:50 PM, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
<= div>
I was wonde= ring if IRC URIs are standardized at all?

The latest I found w= as :

http://tools.ietf.org/html/draft-butcher-irc-url-04=

I have a use case of marking reputation from one system (web = chat room) to an IRC chat room, but I require an identifier for the user.
The suggestions so far have been:

irc://user@host<= br>
irc://user@host/ -- trailing slash
irc:user@host -- simila= r to xmpp
irc://host/#user -- fragment could be problematic a= s per RFC 9386

I've gone with the second option for t= he moment

Any pointers would be most welcome.


=

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



--001a11c25944d0154a0503ba3cea-- From nobody Tue Sep 23 08:05:54 2014 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 18DA01A86E9 for ; Tue, 23 Sep 2014 08:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoBrUzeQnJtn for ; Tue, 23 Sep 2014 08:05:49 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE891A86ED for ; Tue, 23 Sep 2014 08:05:49 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x12so4609004wgg.32 for ; Tue, 23 Sep 2014 08:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CDGC7mc0I+WOqykWAxSF6s29sBpxc87NSMjwwte6E9o=; b=yLYQCaVuoVclbX3nzRXUwskjdzXOaaPJjCuHuCc8bGoi6rPU0MqIca491M3tNXunZi El9G38gMaZzA8+ionjA2gQYEzAS2YDuZ2gt9gGcvEBefF9xsSKZGMBX3st+IjjF2xn0n e99wu/vKapO54mUZIzi4W6HO4p9PDahGEYyZMZ/vhn1lDfEDcCsmVH21Tj7u/h371dK0 Yh1M9DGkfE0ZYfzfYgsL/Dz9Dp5NtFK7aeM1SRsDq5Grdt7plM/gayoVg7jTseezjIzA lqFrH92eT+e9uHrv80X8gZa3B2e75yHOxC342Qm8iZyby9LbQGYU1aSMer0lNwoAUso4 Kgdw== X-Received: by 10.180.105.41 with SMTP id gj9mr4123813wib.3.1411484747533; Tue, 23 Sep 2014 08:05:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.77.136 with HTTP; Tue, 23 Sep 2014 08:05:27 -0700 (PDT) In-Reply-To: References: From: Ira McDonald Date: Tue, 23 Sep 2014 11:05:27 -0400 Message-ID: To: Melvin Carvalho , Ira McDonald Content-Type: multipart/alternative; boundary=f46d04428262fb93b90503bce688 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wHzW0MMMNqgsw9S5nq0dTvMNGEs Cc: Benjamin Young , Apps Discuss Subject: Re: [apps-discuss] IRC URIs to denote users 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, 23 Sep 2014 15:05:53 -0000 --f46d04428262fb93b90503bce688 Content-Type: text/plain; charset=UTF-8 Hi Melvin, Note that the "user" production is NOT present in the IANA provisionally registered "irc" scheme. I suspect you'll receive quite a lot of pushback from the IETF and W3C URI review lists if you want to change the syntax. I respectfully suggest that you change the scheme name for your usage to "ircu" (for example) to avoid all that grief (and collisions with existing "irc" scheme parsing code). Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Tue, Sep 23, 2014 at 7:55 AM, Melvin Carvalho wrote: > > > On 23 September 2014 01:45, Ira McDonald wrote: > >> Hi Melvin, >> >> The current IANA URI Schemes registry includes the following >> three schemes: >> >> irc prov/irc irc [ >> Dave_Thaler >> >> ] irc6 prov/irc6 >> irc6 [Dave_Thaler >> >> ] ircs prov/ircs >> ircs [Dave_Thaler >> >> ] >> All three of those are September 2012 provisional registrations >> (with references that include butcher and draft-mirashi-url-irc-01). >> > > Thanks for the info! > > Both the referenced specs seem quite old. I think there was a time when > Dave Thaler just put a ton of URI specs in the provisional queue, without > necessarily major updates. > > It's still not 100% clear what the best pattern is, if any. > > Unless there's an objection may I propose: > > irc://user@host/ > > This is very much in line with the work of Ben Young (cc'd) > > http://userinfo.me/ > > Who proposes a neat way to get user profile info via HTTP as: > > http://user@host/ > > I believe the intention of this is to write an RFC, so I'd like to align > future work with that if possible > > >> >> Cheers, >> - Ira >> >> >> Ira McDonald (Musician / Software Architect) >> Co-Chair - TCG Trusted Mobility Solutions WG >> Chair - Linux Foundation Open Printing WG >> Secretary - IEEE-ISTO Printer Working Group >> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG >> IETF Designated Expert - IPP & Printer MIB >> Blue Roof Music / High North Inc >> http://sites.google.com/site/blueroofmusic >> http://sites.google.com/site/highnorthinc >> mailto: blueroofmusic@gmail.com >> Winter 579 Park Place Saline, MI 48176 734-944-0094 >> Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 >> >> >> On Mon, Sep 22, 2014 at 4:50 PM, Melvin Carvalho < >> melvincarvalho@gmail.com> wrote: >> >>> I was wondering if IRC URIs are standardized at all? >>> >>> The latest I found was : >>> >>> http://tools.ietf.org/html/draft-butcher-irc-url-04 >>> >>> I have a use case of marking reputation from one system (web chat room) >>> to an IRC chat room, but I require an identifier for the user. >>> >>> The suggestions so far have been: >>> >>> irc://user@host >>> irc://user@host/ -- trailing slash >>> irc:user@host -- similar to xmpp >>> irc://host/#user -- fragment could be problematic as per RFC 9386 >>> >>> I've gone with the second option for the moment >>> >>> Any pointers would be most welcome. >>> >>> >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> >>> >> > --f46d04428262fb93b90503bce688 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Melvin,

=
Note that the "user" production is NOT present in the IANA = provisionally
registered "irc" scheme.=C2=A0 I suspect y= ou'll receive quite a lot of pushback
from the IETF and W3C UR= I review lists if you want to change the syntax.

I respectfull= y suggest that you change the scheme name for your usage
to "= ircu" (for example) to avoid all that grief (and collisions with exist= ing
"irc" scheme parsing code).

Cheers,
=
- Ira


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


On Tue, Sep 23, 2014 at 7:55 AM, Melvin Carv= alho <melvincarvalho@gmail.com> wrote:


On 23 September 2014 01:45, Ira Mc= Donald <blueroofmusic@gmail.com> wrote:
Hi Melvin,

The current IANA URI Schemes registry in= cludes the following
three schemes:

= irc prov/irc irc [Dave_Thaler]
irc6 prov/irc6 irc6 [Dave_Thaler]
ircs prov/ircs ircs [Dave_Thaler]

All three of those are September 2012 provisional regi= strations
(with references that include butcher and draft-mirashi-= url-irc-01).

T= hanks for the info!

Both the referenced specs seem quite = old.=C2=A0 I think there was a time when Dave Thaler just put a ton of URI = specs in the provisional queue, without necessarily major updates.

<= /div>
It's still not 100% clear what the best pattern is, if any.
Unless there's an objection may I propose:

irc:= //user@host/

This is very much in line with the work of B= en Young (cc'd)

http://userinfo.me/

Who proposes a neat way to get = user profile info via HTTP as:

http://user@host/

<= /div>
I believe the intention of this is to write an RFC, so I'd li= ke to align future work with that if possible
=C2=A0

Cheers,
- Ira


Ira McDonald (M= usician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions = WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Pr= inter Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol = WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / H= igh North Inc
http://sites.google.com/site/= blueroofmusic
http://sites.google.com/si= te/highnorthinc
mailto: blueroofmusic@gmail.com
Winter=C2=A0 579 Park Place= =C2=A0 Saline, MI=C2=A0 48176=C2=A0 734-944-0094
Summer=C2=A0 PO Box 221= =C2=A0 Grand Marais, MI 49839=C2=A0 906-494-2434


On Mon, Sep 22, 2014 at 4:50 PM, M= elvin Carvalho <melvincarvalho@gmail.com> wrote:
<= /div>
I was wondering if IRC URIs are stand= ardized at all?

The latest I found was :

http:/= /tools.ietf.org/html/draft-butcher-irc-url-04

I have a use= case of marking reputation from one system (web chat room) to an IRC chat = room, but I require an identifier for the user.

The suggestion= s so far have been:

irc://user@host
irc://user@host/ = -- trailing slash
irc:user@host -- similar to xmpp
ir= c://host/#user -- fragment could be problematic as per RFC 9386

I've gone with the second option for the moment

Any point= ers would be most welcome.



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




--f46d04428262fb93b90503bce688-- From nobody Tue Sep 23 08:13:26 2014 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 961CA1A1AEF for ; Tue, 23 Sep 2014 08:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSQn18cW6rHD for ; Tue, 23 Sep 2014 08:13:23 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36591A1B0C for ; Tue, 23 Sep 2014 08:13:21 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id z11so3564251lbi.15 for ; Tue, 23 Sep 2014 08:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J0P0fKtiyqTo2PdK/T/7rRgKBL6s6a9fU23eRSU0zdU=; b=gOEVcHPi/I7o68vrNnVIGHM8GVYI/471yORPkOszXS8jZSTJg8oGANM61xHlpg3DRW 4UcRuWrzD9yI9MO3tVsGFwrLNkGC3Tv5r876FU6ifVfeKXwXq4jSo2URxOmEwlyOQcUM gxtAQwuKg22UiSyX75oDJT+/K+iLnu9cie0qPQzbpxWbWPfbYODcdrwRPomezKXgvWNx OdISrOXFK0ddrP5l6MiD96g678ubhST8K8I5TY1ScZClNdKjKmG+I9qDMd0jNquxnSDH 0EcyZM+gyoKTysql8jJLVow9L9QQB7dk12sCYnYwzkeV3xkf0uGPHy/srDgVwT3ysXa7 Uhtg== MIME-Version: 1.0 X-Received: by 10.112.161.70 with SMTP id xq6mr137533lbb.49.1411485200026; Tue, 23 Sep 2014 08:13:20 -0700 (PDT) Received: by 10.112.13.99 with HTTP; Tue, 23 Sep 2014 08:13:19 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Sep 2014 17:13:19 +0200 Message-ID: From: Melvin Carvalho To: Ira McDonald Content-Type: multipart/alternative; boundary=001a11c25944f412df0503bd018c Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/I3gwurCWWVZv1venPXK-TfS1euQ Cc: Benjamin Young , Apps Discuss Subject: Re: [apps-discuss] IRC URIs to denote users 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, 23 Sep 2014 15:13:24 -0000 --001a11c25944f412df0503bd018c Content-Type: text/plain; charset=UTF-8 On 23 September 2014 17:05, Ira McDonald wrote: > Hi Melvin, > > Note that the "user" production is NOT present in the IANA provisionally > registered "irc" scheme. I suspect you'll receive quite a lot of pushback > from the IETF and W3C URI review lists if you want to change the syntax. > > I respectfully suggest that you change the scheme name for your usage > to "ircu" (for example) to avoid all that grief (and collisions with > existing > "irc" scheme parsing code). > Thanks for the response. My issue is that I'm not even sure this work is on any kind of standards track. Going back to 1996 we have: http://www.w3.org/Addressing/draft-mirashi-url-irc-01.txt For example. The URL irc:///Mmmm!mandar@*uoknor.edu,isnick references a person with nickname Mmmm, and user@host matching mandar@*uoknor.edu on the default IRC server. Note: that this has been seemingly unresolved for 18 years. My intention is to try and gather a rough consensus here, to see if there's an obvious path to take, or an obvious path not to take, then implement through running code, which is already working. Minting a new URI scheme for these use case, seems perhaps overkill, but I'm open to that suggestion. I hope that makes sense! > > Cheers, > - Ira > > > Ira McDonald (Musician / Software Architect) > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music / High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto: blueroofmusic@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 > > > On Tue, Sep 23, 2014 at 7:55 AM, Melvin Carvalho > wrote: > >> >> >> On 23 September 2014 01:45, Ira McDonald wrote: >> >>> Hi Melvin, >>> >>> The current IANA URI Schemes registry includes the following >>> three schemes: >>> >>> irc prov/irc irc >>> [Dave_Thaler >>> >>> ] irc6 prov/irc6 >>> irc6 [ >>> Dave_Thaler >>> >>> ] ircs prov/ircs >>> ircs [ >>> Dave_Thaler >>> >>> ] >>> All three of those are September 2012 provisional registrations >>> (with references that include butcher and draft-mirashi-url-irc-01). >>> >> >> Thanks for the info! >> >> Both the referenced specs seem quite old. I think there was a time when >> Dave Thaler just put a ton of URI specs in the provisional queue, without >> necessarily major updates. >> >> It's still not 100% clear what the best pattern is, if any. >> >> Unless there's an objection may I propose: >> >> irc://user@host/ >> >> This is very much in line with the work of Ben Young (cc'd) >> >> http://userinfo.me/ >> >> Who proposes a neat way to get user profile info via HTTP as: >> >> http://user@host/ >> >> I believe the intention of this is to write an RFC, so I'd like to align >> future work with that if possible >> >> >>> >>> Cheers, >>> - Ira >>> >>> >>> Ira McDonald (Musician / Software Architect) >>> Co-Chair - TCG Trusted Mobility Solutions WG >>> Chair - Linux Foundation Open Printing WG >>> Secretary - IEEE-ISTO Printer Working Group >>> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG >>> IETF Designated Expert - IPP & Printer MIB >>> Blue Roof Music / High North Inc >>> http://sites.google.com/site/blueroofmusic >>> http://sites.google.com/site/highnorthinc >>> mailto: blueroofmusic@gmail.com >>> Winter 579 Park Place Saline, MI 48176 734-944-0094 >>> Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 >>> >>> >>> On Mon, Sep 22, 2014 at 4:50 PM, Melvin Carvalho < >>> melvincarvalho@gmail.com> wrote: >>> >>>> I was wondering if IRC URIs are standardized at all? >>>> >>>> The latest I found was : >>>> >>>> http://tools.ietf.org/html/draft-butcher-irc-url-04 >>>> >>>> I have a use case of marking reputation from one system (web chat room) >>>> to an IRC chat room, but I require an identifier for the user. >>>> >>>> The suggestions so far have been: >>>> >>>> irc://user@host >>>> irc://user@host/ -- trailing slash >>>> irc:user@host -- similar to xmpp >>>> irc://host/#user -- fragment could be problematic as per RFC 9386 >>>> >>>> I've gone with the second option for the moment >>>> >>>> Any pointers would be most welcome. >>>> >>>> >>>> >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> apps-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>> >>>> >>> >> > --001a11c25944f412df0503bd018c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 23 September 2014 17:05, Ira McDonald <blueroofmusic@gmail.c= om> wrote:
Hi Melvin,
<= br>
Note that the "user" production is NOT present in the IA= NA provisionally
registered "irc" scheme.=C2=A0 I suspec= t you'll receive quite a lot of pushback
from the IETF and W3C= URI review lists if you want to change the syntax.

I respectf= ully suggest that you change the scheme name for your usage
to &qu= ot;ircu" (for example) to avoid all that grief (and collisions with ex= isting
"irc" scheme parsing code).
=

Thanks for the response.

My issue is that I'm not even sure this work is on any kind of standar= ds track.

For example.=

=C2=A0 The URL

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ir= c:///Mmmm!mandar@*uoknor.edu,isnick
=C2=A0=C2=A0=C2=A0 references a person with nickname Mmmm, and user@host = matching
=C2=A0=C2=A0=C2=A0 mandar@*uoknor= .edu on the default IRC server.

Note: that this has b= een seemingly unresolved for 18 years.

My inte= ntion is to try and gather a rough consensus here, to see if there's an= obvious path to take, or an obvious path not to take, then implement throu= gh running code, which is already working.=C2=A0

Minting= a new URI scheme for these use case, seems perhaps overkill, but I'm o= pen to that suggestion.

I hope that makes sense!
=C2=A0

Cheers,
- Ira


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

<= /div>

On Tue, Sep 23= , 2014 at 7:55 AM, Melvin Carvalho <melvincarvalho@gmail.com>= ; wrote:


On 23 September 2014 01:45, Ira McDonald <blueroofmusic@gmail.c= om> wrote:
Hi Melvin,

T= he current IANA URI Schemes registry includes the following
three schem= es:

irc prov/irc irc [Dave_Thaler]
irc6 prov/irc6 irc6 [Dave_Thaler]
ircs prov/ircs ircs [Dave_Thaler]

All three of those are September 2012 provisional regi= strations
(with references that include butcher and draft-mirashi-= url-irc-01).

T= hanks for the info!

Both the referenced specs seem quite = old.=C2=A0 I think there was a time when Dave Thaler just put a ton of URI = specs in the provisional queue, without necessarily major updates.

<= /div>
It's still not 100% clear what the best pattern is, if any.
Unless there's an objection may I propose:

irc:= //user@host/

This is very much in line with the work of B= en Young (cc'd)

http://userinfo.me/

Who proposes a neat way to get = user profile info via HTTP as:

http://user@host/

<= /div>
I believe the intention of this is to write an RFC, so I'd li= ke to align future work with that if possible
=C2= =A0

Cheers,
- Ira


Ira McDonald (Musician / S= oftware Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair= - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Worki= ng Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF = Designated Expert - IPP & Printer MIB
Blue Roof Music / High North I= nc
http://sites.google.com/site/blueroofmus= ic
http://sites.google.com/site/highnort= hinc
mailto: blueroofmusic@gmail.com
Winter=C2=A0 579 Park Place=C2=A0 Sali= ne, MI=C2=A0 48176=C2=A0 734-944-0094
Summer=C2=A0 PO Box 221=C2=A0 Grand= Marais, MI 49839=C2=A0 906-494-2434


On Mon, Sep 22, 2014 at 4:50 PM, M= elvin Carvalho <melvincarvalho@gmail.com> wrote:
<= /div>
I was wondering if IRC URIs are stand= ardized at all?

The latest I found was :

http:/= /tools.ietf.org/html/draft-butcher-irc-url-04

I have a use= case of marking reputation from one system (web chat room) to an IRC chat = room, but I require an identifier for the user.

The suggestion= s so far have been:

irc://user@host
irc://user@host/ = -- trailing slash
irc:user@host -- similar to xmpp
ir= c://host/#user -- fragment could be problematic as per RFC 9386

I've gone with the second option for the moment

Any point= ers would be most welcome.



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





--001a11c25944f412df0503bd018c-- From nobody Tue Sep 23 10:24:20 2014 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 114721A8797 for ; Tue, 23 Sep 2014 10:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99jgDOkl5NTT for ; Tue, 23 Sep 2014 10:24:16 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21EDD1A87C6 for ; Tue, 23 Sep 2014 10:24:15 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id ey11so7754242pad.28 for ; Tue, 23 Sep 2014 10:24:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=h7C9RjHx2dJQT9EoiWWi58uAo0dh3mv6iDYB0rrasnQ=; b=EOLb1sAKLPwlq/yeBau2Y7ye3F5rdXF1wnncs2XYBxG93TyNtjSTVZ0njp8AVOJLRa RVQM044pcuXtRRRbGVd370RYs7vderCH3VXlOw4UbM8W06RsM2skMX8/l72Qi+qL5xOb 9x3q8rPJ7plgiRZNcZdbkGKeOQdWd98jK3K8Lj1jtSQdplKU08EUlTxU+LwzyQEBHe1U rc2e0HLQfEWm40+DGsCAdTJbYA4Q1EN7nuCRXhDc0IzEfVvZ1a1ELQiTBagQNMmre498 r5p0KczLtqLYZefFV3l6tNULW+x9d6CLw33c5tw1cCU/EWaUbk40Sq03Vip6uwq8AjTt qEvw== X-Gm-Message-State: ALoCoQknbNwTfT8uM42W+bMOq8qHHmpFBV9dlTcw8IcPOQ5vSADquQWgWzeyhq5lwdQX58RFSb3Q MIME-Version: 1.0 X-Received: by 10.66.179.140 with SMTP id dg12mr1538470pac.76.1411493055505; Tue, 23 Sep 2014 10:24:15 -0700 (PDT) Sender: mark@coactus.com Received: by 10.70.138.45 with HTTP; Tue, 23 Sep 2014 10:24:15 -0700 (PDT) X-Originating-IP: [192.0.216.13] In-Reply-To: References: <12DDB299-01C4-4B11-9D41-29E3E929443A@tzi.org> <54174A83.2020704@dcrocker.net> <54174CBB.7070007@dcrocker.net> <69EC01D7-0639-4DE6-8412-D4DCD42F1C10@tzi.org> <54176A00.3050905@dcrocker.net> <561C70B6-7D61-4ECA-92B4-0DB6F3BB50FD@mnot.net> <57604ECC-2DF0-480E-B2CA-929695EB8CA6@tzi.org> <6A03AF70-34AD-43B5-B4E8-15BAF39D1ADA@tzi.org> Date: Tue, 23 Sep 2014 13:24:15 -0400 X-Google-Sender-Auth: HJJluHgOQLhpzzwvEiJanoZBW5U Message-ID: From: Mark Baker To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/sVHGVmvkHQ7SJyVidi_Eq6wopDg Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RESTful definition 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, 23 Sep 2014 17:24:18 -0000 On Sun, Sep 21, 2014 at 1:51 AM, Murray S. Kucherawy wrote: > Have a look at > https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ While that draft is far better than the bulk of HTTP-using drafts I've seen over the years, I see no value in the mention of REST/RESTful. It doesn't even appear to be using hypermedia, as IIUC, the client is responsible for constructing URIs without explicit license from the server. From nobody Tue Sep 23 11:54:00 2014 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 AAA9A1A8839 for ; Tue, 23 Sep 2014 11:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 onBxh34_tWQe for ; Tue, 23 Sep 2014 11:53:56 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A101A8846 for ; Tue, 23 Sep 2014 11:53:56 -0700 (PDT) Received: from [10.0.44.217] (unknown [74.113.134.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0A98E50A89 for ; Tue, 23 Sep 2014 14:53:54 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <541844C3.2030200@ninebynine.org> Date: Tue, 23 Sep 2014 11:53:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> <54181186.4030507@ninebynine.org> <541844C3.2030200@ninebynine.org> To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Rtd9eyJ55O3MEjQ_XrATuGYhPqg Subject: Re: [apps-discuss] Request additional reviewer for Markdown 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, 23 Sep 2014 18:53:58 -0000 +1 to the concern. We should find out if an informational RFC can create an IANA registry. +1 also to the point about left-to-right processing of parameters to = resolve conflicts. The CSS resolution mechanism is also a good one. In Cascading Style = Sheets, if a style property (or whatever) is unrecognized, the whole = thing *and everything after it* is ignored, until a new thing is = encountered. (Note that this is from my own memory, and recent CSS = standards updates may have changed the behavior.) Sean On Sep 16, 2014, at 7:10 AM, Graham Klyne wrote: > Further to my previous review, I just noticed another thing. The = draft indicates it is intended to be informational. Is it allowed in = IETF process for an informational RFC to create an IANA registry? I = don't know, just asking. (I usually associate such actions with = standards track or BCP documents.) >=20 > Now that I've had a little time to reflect on this, Ill say: >=20 > 1. That I think it's a reasonable idea to define this media type, and = that the broad approach is OK, but ... >=20 > 2. I think the spec could do with some trimming and polishing, and >=20 > 3. I'd prefer to see the 'processor' and 'processor-args' parameters = dropped completely, and focus on creating a tabulation of rules to = capture information > about the varieties of Markdown that are actually used. >=20 > (And a thought: rather than requiring the rule definitions to resolve = any potential conflicts between themselves, have a simple left-to-right = processing of parameters such that where there is a conflict, parameters = appearing later in the list override earlier ones. That would provide a = well-defined way to say something like "github flavoured markdown, = except that newlines are not rendered as line breaks in the output".) >=20 > #g [SNIP] From nobody Tue Sep 23 12:05:34 2014 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 A2F8B1A8859 for ; Tue, 23 Sep 2014 12:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Z_A14fBYibBj for ; Tue, 23 Sep 2014 12:05:30 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 419741A8892 for ; Tue, 23 Sep 2014 12:05:30 -0700 (PDT) Received: from [10.0.44.217] (unknown [74.113.134.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1B009509B8 for ; Tue, 23 Sep 2014 15:05:28 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <541844C3.2030200@ninebynine.org> Date: Tue, 23 Sep 2014 12:05:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2D8AF589-0095-45EA-AAF1-7471598ADA00@seantek.com> References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> <54181186.4030507@ninebynine.org> <541844C3.2030200@ninebynine.org> To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/EWnnuEA_UPgWlzSY81VIzKBIrGo Subject: Re: [apps-discuss] Request additional reviewer for Markdown 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, 23 Sep 2014 19:05:33 -0000 On Sep 16, 2014, at 7:10 AM, Graham Klyne wrote: > Further to my previous review, I just noticed another thing. The = draft indicates it is intended to be informational. Is it allowed in = IETF process for an informational RFC to create an IANA registry? I = don't know, just asking. (I usually associate such actions with = standards track or BCP documents.) =46rom my read, the answer is yes. Sources: http://www.iana.org/protocols RFC 5226 Section 4.2. What To Put in Documents That Create A Registry: It is the working group and/or document author's job to formulate an appropriate policy and specify it in the appropriate document. In almost all cases, having an explicit "IANA Considerations" section is appropriate. Since a working group is not required, I don=92t think Standards Track = or BCP is required, either. In any event, a number of registries are created and updated with = Informational RFCs. For example, see Autonomous System (AS) Numbers: RFC 7249 (Informational) RFC 7020 (Informational) RFC 6996 (BCP) RFC 6793 (Standards Track) RFC 5398 (Informational) RFC 1930 (BCP) -Sean= From nobody Tue Sep 23 12:22:25 2014 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 00DB91A1B54 for ; Tue, 23 Sep 2014 12:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dLi3Pai_i6T for ; Tue, 23 Sep 2014 12:22:19 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3030B1A1B6A for ; Tue, 23 Sep 2014 12:22:19 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id r5so1103055qcx.0 for ; Tue, 23 Sep 2014 12:22:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=HylV5jtR64J5AbnJESWyNnXjDBxgJ+pRsowGIGsyfXY=; b=JTahesnTqwEfA4Uy5CD0Gfksu7RpCgVT528MlUzXK8Pke74CQi3EUecZmKHysaFRW7 rWijyoTMNGAjD4UJhL9JNUpJy3lg2s2z+qArySqYpglk8g/2Q3O5ijf/VCWMt645bFxn cAlBimPFJSv/N0uS+ENH2vTZlwx/J0qyTPyrCR2Q43WEuhSkVNprr6YaYuOHQ9ElFN/0 CnvZL9dJkaxsphM2EZ3Kl5fqr/4rHIPu3mbPAsFAxWOC5JcUg2obrYSsdrYwoE9d7Cl3 dw+IhlMe8M2Tk1CjmkGJDjRD4I15PIFyYe8HWJ0hYX/DPMk/uXWYXLktm+CC3y0+AZjE 5ziQ== X-Gm-Message-State: ALoCoQkJh9VxF1cEPG5a8uS4p/sONGleHBN4e79PaDqNyqlUU3hDv6X3xsRkk8piM/bSLKl48WGO X-Received: by 10.140.28.136 with SMTP id 8mr2596640qgz.37.1411500138318; Tue, 23 Sep 2014 12:22:18 -0700 (PDT) Received: from minime.private ([76.73.248.16]) by mx.google.com with ESMTPSA id a3sm7226597qaa.49.2014.09.23.12.22.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Sep 2014 12:22:17 -0700 (PDT) From: "Fletcher T. Penney" Content-Type: multipart/signed; boundary="Apple-Mail=_9CD46BC9-0E24-4F4C-B424-B8BA17A0B167"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <9B6F988F-9E8A-48E6-9399-78966F33D1AF@fletcherpenney.net> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Tue, 23 Sep 2014 15:22:16 -0400 References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> <54181186.4030507@ninebynine.org> <541844C3.2030200@ninebynine.org> <541868BD.3040501@fletcherpenney.net> <5419466B.6080403@ninebynine.org> <542029B1.7080103@fletcherpenney.net> <01PCVV7VA7OC003X76@mauve.mrochek.com> <54208459.3090501@dcrocker.net> To: IETF Apps Discuss In-Reply-To: <54208459.3090501@dcrocker.net> X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/PAgWhG_PKQVia9uILoeFuZAJ3gg Subject: Re: [apps-discuss] Request additional reviewer for Markdown 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, 23 Sep 2014 19:22:22 -0000 --Apple-Mail=_9CD46BC9-0E24-4F4C-B424-B8BA17A0B167 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 22, 2014, at 4:19 PM, Dave Crocker wrote: >=20 >>>> Stick to the 50,000 foot view=20 >> +1. The point of registering things is to define an appropriate type = label >> and registration data, including documenting any security issues. >>=20 >> Cleaning up the media type itself in any sense is not a prerequisite = to >> registration and in this case is not something the IETF should be = doing. >=20 >=20 > Yes, but... >=20 > The 50,000 foot level rarely permits interoperability. >=20 > My concern is that what gets registered needs to contain enough > information for the recipient of the media type to be able to know = what > is needed to process what the author put there. I expect that vast majority of use cases will fall into 1 of 2 camps: 1) The content is basic Markdown. Any flavor that didn't go off the = reservation will process it correctly, or close enough. (e.g. `This is = **really** important.`) 2) The content is really something else (e.g. MultiMarkdown). In this = case, the user will either have the desired software as part of their = installed software or not. But giving them a list of requirements is = unlikely to change what they do("Ok. You need to find this particular = flavor of Markdown. Yes, I know you'll never use it again, but you = need to install it now. Don't worry, I'll wait the 15 minutes while you = figure that out. And then you need to configure it this particular = way=85." At this point the user moves on to another web site and finds = the content in a .doc file, since that is now easier to use.) I think this discussion has forked into two separate discussions, though = we all think we're talking about the same thing. 1) How do we indicate that a piece of content is not plain text, but = instead Markdown, or something really close to Markdown? vs 2) How do we describe the exact series of steps that one person took in = order to convert plain text into a piece of HTML (or other formatted = information), so that another person can exactly replicate that process = without having to just read the directions. I would argue that the first is really important for the idea of a media = type. The second is only important in the context of a given piece of = software (e.g. a CMS, or whatever), and in that case whatever is decided = here is unlikely to be of much use. I mean, if it's that crucial that the output matches, just use the raw = HTML (as I believe Michel suggest), or include directions for those who = care. I suppose, ultimately the decision is not really up to me, but I = strongly feel that this project is heading off in a direction that will = result in a dead-end, or being incredibly useful for the five people on = the internet who care. If it's kept simple, e.g. "text/markdown" and **MAYBE** the ability to = specify a flavor (but even that is iffy and politically charged) then I = think it will gain a great deal of traction. I just worry that getting = into all this hair-splitting is likely to have more negative effects = than positive effects. FTP --=20 Fletcher T. Penney fletcher@fletcherpenney.net=20 --Apple-Mail=_9CD46BC9-0E24-4F4C-B424-B8BA17A0B167 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPOzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTgwggQgoAMC AQICEQDAX9LMQixpGwQOeQtHJ7TlMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTEwNDAwMDAwMFoXDTE0MTEwNDIzNTk1OVowLDEqMCgGCSqG SIb3DQEJARYbZmxldGNoZXJAZmxldGNoZXJwZW5uZXkubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAph1i3pN+Zt7You7JODIYgGIv82YJVkSxBp0i9zpw+IIADYI0grIW2G3lg/E9 i9MBwetn++K37I7Kt7SnYZcdrkZUBCwS3bDOobGlLXFTtcXJQI+GB1zPP1vM8kFilI3aZYdbCzgt cxW0WWwWxJ075nBvvHyBkLP2PWdzxSArKCpz5v79rDqdk0pTjuASGb2/VrSZ61BNxusaanmryDph Vcnnnkf+l9diwAW3NbC/99ApJTgqtrqnRs4Nene1w/+GXyeM72AmQPJT+coCyCC/0ss1Vu3j0BbC XaqsfTcVAuXOjbY6SM0aVwIbQ+g00v42zzj0GfaGLVg2OjlIpaww9QIDAQABo4IB6zCCAecwHwYD VR0jBBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFAyy5amhFrElryQn4HQCVgoU ozhZMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsr BgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEw KzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBM oEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25h bmRTZWN1cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8v Y3J0LmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWls Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEb ZmxldGNoZXJAZmxldGNoZXJwZW5uZXkubmV0MA0GCSqGSIb3DQEBBQUAA4IBAQAec1OL/CaNPcde mvbBBSRWg04qFvV/F4PNUNJgpKPu2z23U8FZJAn1RhCGb6dWYquCIDCCtyz5yP1Xdcv57dd9d/xR YJIPYK+iSSgB8xyVnraH5GfryRHx/5aIqIVSjZrrAhQAZ4Q8a16HuAkjYwmdKESn55eiYFUHioht 00xh4o6q0hPP24KfKPZLLN7jAeuqISR5bgrvsJGAjp4N9N0MbInDsZ5SEySKEB6RK3c9xd9f1bYV Xu+jhqV0GzIEbOWHiWGFvbQSqgK+6Az2eW0nSRZBanCEcb4NMhCF0kK7czCUo+YgNOQilx57gMwr OHtpBDRdKeXh2R4guFijK6e3MYIDrjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQI ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0ECEQDAX9LMQixpGwQOeQtHJ7TlMAkGBSsOAwIaBQCgggHZMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDkyMzE5MjIxN1owIwYJKoZIhvcNAQkE MRYEFDuxp7wHB+DM9QujvRd5cVm2hF7QMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDAX9LMQixpGwQOeQtHJ7TlMIG8BgsqhkiG9w0BCRAC CzGBrKCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9E TyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMBf0sxCLGkbBA55 C0cntOUwDQYJKoZIhvcNAQEBBQAEggEAnBZPPqr03hE0IzlUIbiYya1I7SVaVxJXi9xYR0nck6eh 5nWxdhL76HhuBg7PYRqZeEf6dxUCrxxDSRwIXTk3QAn8v6Ky1n2BfyIhK5KGyzQMkvOZujjUsVJG mw75kDcwxN9j5eosO/vE6PfFbu6DHweKX1ITA+wRBfejfIdiefJaJa4edWP6fybeqHD1TS8Mmsny 1+RV4A/BxAoQmr63zeXqRgwIipCZa2yKPPjdmvYuKlCdi1NUO7KVbQbzgRC1Dq/LuxE2VGOsYH5n KiH+n6JqzzjxTqVnH0tqo1CoNm+Z5cB5Maft2CQrmfZhSgXtZPT15RBuHKF0Nd0UQAMBxQAAAAAA AA== --Apple-Mail=_9CD46BC9-0E24-4F4C-B424-B8BA17A0B167-- From nobody Tue Sep 23 12:58:57 2014 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 888BE1A1B91 for ; Tue, 23 Sep 2014 12:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFuPnI6gikGN for ; Tue, 23 Sep 2014 12:58:54 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 028761A1B53 for ; Tue, 23 Sep 2014 12:58:53 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id fb4so5305872wid.1 for ; Tue, 23 Sep 2014 12:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EurQGAq3VMe/9fQd+7pyJTkLN5t4pXfpJJ7qpLXefYw=; b=VKwPwMjJbUtcJoNND1wiAuH6A3RfDVxCopROMCkGZAszgFgUMSzMslbwMuYYB2Vjlf l/mRw9drn7EBvW/4jIdckGwPLcsv1axME3Q8EozGJhYcYHKupsIu2TPvLy8BfHyUNoWA S4RhFGkXf4g5l10jOa37moQCbp7JH4qzERjB5xu9D8EADoahRougVF1ufk2Y4DJpMm7i sSgLjNEIchNB9+A7IWRmsgC+Vx9T3DFpLKhU3aD+yTQP0ohbCZMqifHiotjhg00OM6AI pavbIIAybEYZN31H6Fe2spD10KxJ5DhNXzLNtv1dHrAFALesLlhmFXUS90rD2+OFFOCg nmzA== MIME-Version: 1.0 X-Received: by 10.180.221.107 with SMTP id qd11mr6044712wic.61.1411502332602; Tue, 23 Sep 2014 12:58:52 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Tue, 23 Sep 2014 12:58:52 -0700 (PDT) In-Reply-To: <2D8AF589-0095-45EA-AAF1-7471598ADA00@seantek.com> References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> <54181186.4030507@ninebynine.org> <541844C3.2030200@ninebynine.org> <2D8AF589-0095-45EA-AAF1-7471598ADA00@seantek.com> Date: Tue, 23 Sep 2014 12:58:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: Sean Leonard Content-Type: multipart/alternative; boundary=001a113604ae226fdb0503c0ff28 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8Zw2MkcrCwR49hk86whLj1RIwfU Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Request additional reviewer for Markdown 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, 23 Sep 2014 19:58:55 -0000 --001a113604ae226fdb0503c0ff28 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On this one procedural point: On Tue, Sep 23, 2014 at 12:05 PM, Sean Leonard wrote= : > > Since a working group is not required, I don=E2=80=99t think Standards Tr= ack or > BCP is required, either. > It is possible for a non-WG document to get on the Standards Track, namely by being sponsored by an Area Director. Regardless, my understanding is also that an Informational document can create or update a registry, so we're fine here. I can't remember: Did we already discuss whether this draft should be Standards Track? -MSK --001a113604ae226fdb0503c0ff28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On this one procedural point:

On Tue, Sep 23, 2014 at 12:05 PM, Sean Leo= nard <dev+ietf@seantek.com> wrote:

Since a working group is not required, I don=E2=80=99t think Standards Trac= k or BCP is required, either.

It is pos= sible for a non-WG document to get on the Standards Track, namely by being = sponsored by an Area Director.

Regardless, my understandi= ng is also that an Informational document can create or update a registry, = so we're fine here.

I can't remember: Did we alre= ady discuss whether this draft should be Standards Track?

-MSK
--001a113604ae226fdb0503c0ff28-- From nobody Tue Sep 23 13:30:04 2014 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 E9BBD1A88CA for ; Tue, 23 Sep 2014 13:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 uRcc0OAogA-Z for ; Tue, 23 Sep 2014 13:29:57 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1001A88D6 for ; Tue, 23 Sep 2014 13:29:48 -0700 (PDT) Received: from [10.0.44.217] (unknown [74.113.134.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3A62750A86 for ; Tue, 23 Sep 2014 16:29:46 -0400 (EDT) From: Sean Leonard Content-Type: multipart/alternative; boundary="Apple-Mail=_BBC061CE-EF84-4188-9D76-AFC12B29CF67" Message-Id: <0B87FE4C-E63F-4CE7-A021-D53F19CF0465@seantek.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Tue, 23 Sep 2014 13:29:45 -0700 References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> <54181186.4030507@ninebynine.org> To: "apps-discuss@ietf.org" In-Reply-To: <54181186.4030507@ninebynine.org> X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/98XMHTMWA58cX_-0irXCXTy6AtE Subject: Re: [apps-discuss] Request additional reviewer for Markdown 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, 23 Sep 2014 20:30:01 -0000 --Apple-Mail=_BBC061CE-EF84-4188-9D76-AFC12B29CF67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for the review. Here is some feedback (now with reference to = draft-02). On Sep 16, 2014, at 3:31 AM, Graham Klyne wrote: > On 16/09/2014 07:15, Sean Leonard wrote: >> draft-ietf-appsawg-text-markdown-01.txt >=20 > Reviewing = https://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-01 >=20 >=20 > # 1. Introduction >=20 > First para (Nit): >=20 > This seems a bit bloated. I don't think anything relevant is lost by = deleting from "Compare with [RFC6838] Section 4.2.1." to the end of the = paragraph. I admit it=92s a bit academic/pedantic. At the same time, I occasionally wonder to myself, =93you know, there = are all these sad, lonely, unused control characters=85they=92re just = taking up space in the table. Why can=92t we use them to tag things or = signal other out-of-band information? It would solve a lot of the = escaping problems, which lead to security holes.=94 Then I remember: it=92s because you can=92t type them. They=92re not = printable. You can=92t represent them on paper as they are. And people = are lazy. Give me a over an ESC-sequence any day, they say. It is = the way it is. >=20 >=20 > Para starting "Markdown specifically is a family of syntaxes..." = (nit): >=20 > I would be inclined to remove the text >=20 > "Fed > up with the complexity and security pitfalls of formal markup > languages (e.g., HTML5) and proprietary binary formats (e.g., > commercial word processing software), yet unwilling to be confined = to > the restrictions of plain text," >=20 > and leave just "Many users have turned to Markdown for document = processing=94 I might remove that language prior to publication. However, I think that = the language captures the Zeitgeist. People don=92t want to deal with HTML directly anymore because it is = getting too complicated, and because you have to deal with =93tag = balancing=94. Who likes tag balancing by hand??? Tag balancing forces = you into the think of it, not the feel of it. As for word processors, see and = .= >=20 >=20 > # 2. Markdown Media Type Registration Applications >=20 >=20 > General: >=20 > I have my doubts about creating a registry of processors. Could the = required information for interoperability not be captured by capturing = the processor capabilities as rules? >=20 > For comparison, consider the example of HTTP feature negotiation = (type, language, encoding, etc.) vs UA string testing and/or user-agent = sniffing, which is frequently regarded as a poor way to do content = matching. This specification appears to be blessing an approach = analogous to UA string testing. >=20 > Maybe this was discussed and I missed it? First of all, draft-02 is much clearer about how the registry looks = (registries look) like. This should give us something concrete at which = to lob shells. It=92s an active question whether we need flavors (rules) and = processors, just one, just the other, or neither. Ignoring the flavors (rules) for the rest of this response: The issue is that in the Markdown world, people don=92t write specs at = first glance. They write implementations. If someone doesn=92t like how = MultiMarkdown or Markdown.pl do it, they=92ll just create their own = thing and do it =93better=94. (And in so doing, they=92ll probably throw = in a couple of kitchen sink items=85) Unlike undertaking the writing of = an entire modern web browser, any professional software engineer can = basically hack out a Markdown processor in a few hours. For that matter, = you can get most of the way on repeated applications of regular = expressions. Just because someone creates a spec (e.g., CommonMark) doesn=92t mean it = will get adopted. And people will sometimes deliberately disagree with = the spec and do their own thing. CommonMark itself is guilty of this: = there are a couple of places where they disagreed with Gruber=92s = writeup, and did something else. Referring to a concrete implementation = eliminates ambiguity. The other thing is that the vast majority of Markdown processors are = free and portable. PHP Markdown depends on PHP; Markdown.pl depends on = Perl; Python-Markdown needs Python. But PHP runs on all operating = systems; likewise with Perl; likewise with Python. And then the C = implementations, like stmd and MultiMarkdown, are more-or-less ISO or = POSIX compliant. >=20 >=20 > The description of "processor-args" seems odd to me - it seems to tie = the media type string to a particular form of implementation (posix = commands). Would it not be more flexible to use some kind of = attribute/value list (e.g. similar to media type parameters themselves), = and let the application turn them into command line options or = environment variables or whatever is needed? (As you plan to allow = references to web resources here, maybe use something like encoded JSON, = which can be a common representation for direct or indirect values?) >=20 > I think such an approach could also sidestep some of the unresolved = security concerns in the draft (e.g. [[TODO: discuss the implications of = processor-args, and safeguards.]], etc.) In draft-01, I thought that referring to the POSIX standard would make = things easier and well-specified, since =93Everyone Understands POSIX=AE=94= . Not actually the case! POSIX made things more complicated, not less. Too = many options. So I got rid of POSIX in draft-02. The central problem with an attribute/value list, or generally =93some = other syntax=94, is literally that it=92s some other syntax, and = therefore it imposes additional documentation burdens on implementers. I = wanted to stick with a command-line metaphor (i.e., an ordered, unnamed = argument list) because =93most=94 processors are command-line tools. I suppose that statement is not actually true=85for example, PHP = Markdown Lib 1.4.1 is a library, and as a library = , it expects = arguments to be named (because they are essentially named member = variables). Admittedly I did not seriously consider named arguments in = draft-02. On the other hand, it is pretty easy to map named arguments to = an unnamed list. For example, for PHP Markdown, the following Argument = Syntax (see draft-02 Section 5.2) could be used: --empty_element_suffix {suffix} --tab_width {width} --no_markup --no_entities --predef_urls_and_titles {urls_and_titles} where: urls_and_titles is a single argument; URIs are separated by = whitespace; if there is a title, the title is separated from the URI by = the | character and terminated with the | character (which is not a = valid URI character and therefore is safe to use as a delimiter) That is just an example. Of course, if Michel Fortin, the implementer of = PHP Markdown, does not want to permit this flexibility, it is his choice = to register =93PHPMarkdown=94 (or whatever identifier) and simply say = =93no arguments=94. Or only some arguments could be registered. For = example, empty_element_suffix and tab_width are not directly relevant to = HTML content=97users aren=92t going to see the difference when they open = the webpage in a web browser. But, they will see a difference with = no_entities; they will also get a qualitatively different experience if = predefined URLs are not passed. Basically we could introduce a name/value syntax into the processor = parameter, such as @NAME=3DVALUE or some such. But ultimately that = introduces more complexity (what are valid NAME characters? How do we = escape the VALUE characters? What if the option really is a boolean, = like no_markup=97aren=92t we being pedantic by insisting on VALUE all = the time?), and I thought that we want to reduce complexity. (Of course, = we could eliminate complexity by removing processor arguments from the = processor parameter entirely. But that also reduces precision, which = reduces interoperability.) In addressing these topics, draft-02 strikes a balance between processor = implementers and media type parsers. If the implementer (who is = registering the processor) wants interoperability and wants the swiss = army knives, the implementer can register them. If they don=92t want = interop, they don=92t have to register them. Maybe the implementer put = the options in the code, but in retrospect, thinks =93well this option = is stupid, nobody actually uses this/nobody is actually going to use = this=94. Or they put the option in for valid debugging reasons, but = debugging reasons are not interchange reasons. In this sense, you could = say that it gives the implementer a second bite at the apple. In retrospect, perhaps I should have written a stronger statement about = whether to honor processor arguments: =93A receiver that receives = unregistered arguments SHOULD NOT assume what those arguments mean, and = SHOULD NOT pass them to the processor=94. Security considerations are now fully fleshed out in draft-02. >=20 >=20 > Para "Interoperability considerations": >=20 > Contains the text: "When it is desirable to reflect the author's = intent in the output, stick with the flavor identified in the flavor = parameter." What is this "flavor" parameter? I'm not seeing it. >=20 > [later: looks like left over from a previous incarnation - maybe worth = a global search for changed names?] Yup, that missed draft-01. It=92s aligned in draft-02. >=20 >=20 > # 4. IANA Considerations >=20 > Is it really necessary to have "expert review" for these registries? = That requires a volunteer and may impose some additional overhead on = IANA. Would "First come first served" not work here? I spoke with Murray Kucherawy separately about the standard of review = off-list (thanks for the feedback). Draft-02 is clearer in lowering the = bar. In particular, processor registrations are First-Come, = First-Served. Flavor registrations are sort of First-Come, First-Served+ = (the + meaning =93sanity checking=94). > What are the requirements for updating a registry entry? I'd suggest = including an "escape" clause that allows IESG or an IETF-stream RFC to = update any entry. (I'd trust the community to not do this capriciously). Sorry that I missed this suggestion in draft-02. It=92s a good = suggestion, and I=92ll try to make a note of it for the next draft. Ok, = just made the note. :) >=20 > Rather than reserve some names for future use, why not just = pre-register them (even if the descriptions are vague for now, allowing = that they can be updated later)? Good point=97it should be done. In draft-02, I removed a lot of the reserved names. Cheers, Sean= --Apple-Mail=_BBC061CE-EF84-4188-9D76-AFC12B29CF67 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Thanks for the review. Here = is some feedback (now with reference to = draft-02).

On Sep 16, 2014, at 3:31 AM, Graham Klyne = <gk@ninebynine.org> = wrote:

On 16/09/2014 07:15, Sean = Leonard wrote:
draft-ietf-appsawg-text-markdown-01.txt

= Reviewing h= ttps://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-01

=
# 1. Introduction

First para (Nit):

This seems a bit = bloated.  I don't think anything relevant is lost by deleting from = "Compare with [RFC6838] Section 4.2.1." to the end of the = paragraph.

I admit it=92s a bit = academic/pedantic.

At the same time, I = occasionally wonder to myself, =93you know, there are all these sad, = lonely, unused control characters=85they=92re just taking up space in = the table. Why can=92t we use them to tag things or signal other = out-of-band information? It would solve a lot of the escaping problems, = which lead to security holes.=94

Then I = remember: it=92s because you can=92t type them. They=92re not printable. = You can=92t represent them on paper as they are. And people are lazy. = Give me a <tag> over an ESC-sequence any day, they say. It is the = way it is.



Para starting = "Markdown specifically is a family of syntaxes..." (nit):

I would = be inclined to remove the text

 "Fed
  up with the = complexity and security pitfalls of formal markup
  languages = (e.g., HTML5) and proprietary binary formats (e.g.,
  commercial = word processing software), yet unwilling to be confined to
  the = restrictions of plain text,"

and leave just "Many users have = turned to Markdown for document = processing=94

I might remove that = language prior to publication. However, I think that the language = captures the Zeitgeist.

People don=92t want to = deal with HTML directly anymore because it is getting too complicated, = and because you have to deal with =93tag balancing=94. Who likes tag = balancing by hand??? Tag balancing forces you into the think of it, not = the feel of it.




# 2. Markdown = Media Type Registration Applications


General:

I have = my doubts about creating a registry of processors.  Could the = required information for interoperability not be captured by capturing = the processor capabilities as rules?

For comparison, consider the = example of HTTP feature negotiation (type, language, encoding, etc.) vs = UA string testing and/or user-agent sniffing, which is frequently = regarded as a poor way to do content matching.  This = specification appears to be blessing an approach analogous to UA string = testing.

Maybe this was discussed and I missed = it?

First of all, draft-02 is much = clearer about how the registry looks (registries look) like. This should = give us something concrete at which to lob = shells.

It=92s an active question whether we = need flavors (rules) and processors, just one, just the other, or = neither.

Ignoring the flavors (rules) for the = rest of this response:

The issue is that in the = Markdown world, people don=92t write specs at first glance. They write = implementations. If someone doesn=92t like how MultiMarkdown or = Markdown.pl do it, they=92ll just create their own thing and do it = =93better=94. (And in so doing, they=92ll probably throw in a couple of = kitchen sink items=85) Unlike undertaking the writing of an entire = modern web browser, any professional software engineer can basically = hack out a Markdown processor in a few hours. For that matter, you can = get most of the way on repeated applications of regular = expressions.

Just because someone creates a = spec (e.g., CommonMark) doesn=92t mean it will get adopted. And people = will sometimes deliberately disagree with the spec and do their own = thing. CommonMark itself is guilty of this: there are a couple of places = where they disagreed with Gruber=92s writeup, and did something else. = Referring to a concrete implementation eliminates = ambiguity.

The other thing is that the vast = majority of Markdown processors are free and portable. PHP Markdown = depends on PHP; Markdown.pl depends on Perl; Python-Markdown needs = Python. But PHP runs on all operating systems; likewise with Perl; = likewise with Python. And then the C implementations, like stmd and = MultiMarkdown, are more-or-less ISO or POSIX = compliant.



The description of = "processor-args" seems odd to me - it seems to tie the media type string = to a particular form of implementation (posix commands).  Would it = not be more flexible to use some kind of attribute/value list (e.g. = similar to media type parameters themselves), and let the application = turn them into command line options or environment variables or whatever = is needed?  (As you plan to allow references to web resources = here, maybe use something like encoded JSON, which can be a common = representation for direct or indirect values?)

I think such an = approach could also sidestep some of the unresolved security concerns in = the draft (e.g. [[TODO: discuss the implications of processor-args, and = safeguards.]], etc.)

In draft-01, I = thought that referring to the POSIX standard would make things easier = and well-specified, since =93Everyone Understands = POSIX=AE=94.

Not actually the case! POSIX made = things more complicated, not less. Too many options. So I got rid of = POSIX in draft-02.

The central problem with an = attribute/value list, or generally =93some other syntax=94, is literally = that it=92s some other syntax, and therefore it imposes additional = documentation burdens on implementers. I wanted to stick with a = command-line metaphor (i.e., an ordered, unnamed argument list) because = =93most=94 processors are command-line tools.

I = suppose that statement is not actually true=85for example, PHP Markdown = Lib 1.4.1 is a library, and as a library <https://m= ichelf.ca/projects/php-markdown/configuration/>, it expects = arguments to be named (because they are essentially named member = variables). Admittedly I did not seriously consider named arguments in = draft-02. On the other hand, it is pretty easy to map named arguments to = an unnamed list. For example, for PHP Markdown, the following Argument = Syntax (see draft-02 Section 5.2) could be used:
 --empty_element_suffix = {suffix}
 --tab_width = {width}
 --no_markup
 --no_entities
 --predef_urls_and_titles = {urls_and_titles}
   where: urls_and_titles = is a single argument; URIs are separated by whitespace; if there is a = title, the title is separated from the URI by the | character and = terminated with the | character (which is not a valid URI character and = therefore is safe to use as a delimiter)

That = is just an example. Of course, if Michel Fortin, the implementer of PHP = Markdown, does not want to permit this flexibility, it is his choice to = register =93PHPMarkdown=94 (or whatever identifier) and simply say =93no = arguments=94. Or only some arguments could be registered. For example, = empty_element_suffix and tab_width are not directly relevant to HTML = content=97users aren=92t going to see the difference when they open the = webpage in a web browser. But, they will see a difference with no_entities; they will also get a = qualitatively different experience if predefined URLs are not = passed.

Basically we could introduce a = name/value syntax into the processor parameter, such as @NAME=3DVALUE or some such. But ultimately = that introduces more complexity (what are valid NAME characters? How do = we escape the VALUE characters? What if the option really is a boolean, = like no_markup=97aren=92t we being = pedantic by insisting on VALUE all the time?), and I thought that we = want to reduce complexity. (Of course, we could eliminate complexity by = removing processor arguments from the processor parameter entirely. But = that also reduces precision, which reduces = interoperability.)

In addressing these topics, = draft-02 strikes a balance between processor implementers and media type = parsers. If the implementer (who is registering the processor) wants = interoperability and wants the swiss army knives, the implementer can = register them. If they don=92t want interop, they don=92t have to = register them. Maybe the implementer put the options in the code, but in = retrospect, thinks =93well this option is stupid, nobody actually uses = this/nobody is actually going to use this=94. Or they put the option in = for valid debugging reasons, but debugging reasons are not interchange = reasons. In this sense, you could say that it gives the implementer a = second bite at the apple.

In retrospect, = perhaps I should have written a stronger statement about whether to = honor processor arguments: =93A receiver that receives unregistered = arguments SHOULD NOT assume what those arguments mean, and SHOULD NOT = pass them to the processor=94.

Security = considerations are now fully fleshed out in = draft-02.



Para = "Interoperability considerations":

Contains the text: "When it is = desirable to reflect the author's intent in the output, stick with the = flavor identified in the flavor parameter."  What is this "flavor" = parameter?  I'm not seeing it.

[later: looks like left over = from a previous incarnation - maybe worth a global search for changed = names?]

Yup, that missed draft-01. = It=92s aligned in draft-02.



# = 4.  IANA Considerations

Is it really necessary to have = "expert review" for these registries?  That requires a volunteer = and may impose some additional overhead on IANA.  Would "First come = first served" not work here?

I spoke = with Murray Kucherawy separately about the standard of review off-list = (thanks for the feedback). Draft-02 is clearer in lowering the bar. In = particular, processor registrations are First-Come, First-Served. Flavor = registrations are sort of First-Come, First-Served+ (the + meaning = =93sanity checking=94).

What are the = requirements for updating a registry entry?  I'd suggest including = an "escape" clause that allows IESG or an IETF-stream RFC to update any = entry. (I'd trust the community to not do = this capriciously).

Sorry that I = missed this suggestion in draft-02. It=92s a good suggestion, and I=92ll = try to make a note of it for the next draft. Ok, just made the note. = :)


Rather than reserve some names = for future use, why not just pre-register them (even if the descriptions = are vague for now, allowing that they can be updated = later)?

Good point=97it should be = done.

In draft-02, I removed a lot of the = reserved = names.

Cheers,

Sean
= --Apple-Mail=_BBC061CE-EF84-4188-9D76-AFC12B29CF67-- From nobody Tue Sep 23 13:48:18 2014 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 E3ACC1A88F5 for ; Tue, 23 Sep 2014 13:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 3LHSevgDBdDX for ; Tue, 23 Sep 2014 13:48:06 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884C01A88F3 for ; Tue, 23 Sep 2014 13:48:06 -0700 (PDT) Received: from [10.0.44.217] (unknown [74.113.134.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 254D050A86; Tue, 23 Sep 2014 16:48:04 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: Date: Tue, 23 Sep 2014 13:48:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> <54181186.4030507@ninebynine.org> <541844C3.2030200@ninebynine.org> <2D8AF589-0095-45EA-AAF1-7471598ADA00@seantek.com> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/9z--I6Bg4yC57suRALE5xMQ10t0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Request additional reviewer for Markdown 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, 23 Sep 2014 20:48:11 -0000 On Sep 23, 2014, at 12:58 PM, Murray S. Kucherawy = wrote: > I can't remember: Did we already discuss whether this draft should be = Standards Track? I don=92t know if the whole group as arrived at consensus on Standards = Track vs. Informational, but I think Ned Freed=92s response from July 10 = is a good summary: mid:01PA0C15S4GK0049PU@mauve.mrochek.com = http://mailarchive.ietf.org/arch/msg/apps-discuss/VMnuU25ZlBM1IN9_Kk0MYYmn= 1Cw To distill: the engineering aesthetic of Markdown differs from the IETF = aesthetic. If it were Standards Track, maybe all sorts of heavy lifting = would be required, including formally defining the syntax. =93But we're = not being asked to do that. We're being asked to publish a registration = of a name and set of parameters for something that already exists. = Nothing more.=94 Sean= From nobody Tue Sep 23 14:36:43 2014 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 D1CE51A01EF for ; Tue, 23 Sep 2014 14:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786] 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 yN-414PAV0WR for ; Tue, 23 Sep 2014 14:36:40 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 310D81A1BDA for ; Tue, 23 Sep 2014 14:36:39 -0700 (PDT) Received: from [192.168.80.56] (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id F02B08123C for ; Tue, 23 Sep 2014 14:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1411508199; bh=VibQyiz+IFlmRlkhoKKDPZSoXa/hTJsLP81ihhQHAcM=; h=From:Subject:Date:References:To:In-Reply-To:From; b=NkjqFewttww1L6A6inHVcaKGcC67tySxs3d9tSrxt3hBn7VNOw0XgMzytcJSAqLih O2M9B1XsmPR0nhpSw7lXqKl3d5h5wpvXsY63znT7OcLJ+y6R0ktSPErqvnI4rqpSgQ iyM8+fC3RAOoYCMBNpkVJE/YOILtl5yg/wk2Jtos= From: Steve Atkins Content-Type: multipart/signed; boundary="Apple-Mail=_E258967B-AB85-4CDC-A304-75703528BE25"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Tue, 23 Sep 2014 14:36:36 -0700 References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> <54181186.4030507@ninebynine.org> <541844C3.2030200@ninebynine.org> <541868BD.3040501@fletcherpenney.net> <5419466B.6080403@ninebynine.org> <542029B1.7080103@fletcherpenney.net> <01PCVV7VA7OC003X76@mauve.mrochek.com> <54208459.3090501@dcrocker.net> <9B6F988F-9E8A-48E6-9399-78966F33D1AF@fletcherpenney.net> To: IETF Apps Discuss In-Reply-To: <9B6F988F-9E8A-48E6-9399-78966F33D1AF@fletcherpenney.net> X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/34o4jMraPbqK9FLhK3s5uZRHbM4 Subject: Re: [apps-discuss] Request additional reviewer for Markdown 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, 23 Sep 2014 21:36:42 -0000 --Apple-Mail=_E258967B-AB85-4CDC-A304-75703528BE25 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 23, 2014, at 12:22 PM, Fletcher T. Penney = wrote: >=20 > On Sep 22, 2014, at 4:19 PM, Dave Crocker wrote: >=20 >>=20 >> The 50,000 foot level rarely permits interoperability. >>=20 >> My concern is that what gets registered needs to contain enough >> information for the recipient of the media type to be able to know = what >> is needed to process what the author put there. >=20 >=20 > I expect that vast majority of use cases will fall into 1 of 2 camps: >=20 > 1) The content is basic Markdown. Any flavor that didn't go off the = reservation will process it correctly, or close enough. (e.g. `This is = **really** important.`) That's not a particularly well-defined subset, unfortunately. Even = something as "basic" as this ... - basic markdown - rendering details 1. markdown-ish 2. rendering perfectly ... will render quite differently using different markdown renderers = (some will do the "right thing", others will render a single unordered = list). Is that level of uncertainty about the semantic meaning of simple = content acceptable? Maybe it is, but it'd lead to text/markdown = interoperating about as well as text/html in email did a decade ago (and = adding flavours won't help much with that, unless senders can assume = that recipients have multiple renderers integrated into their browsers = or MUAs). >=20 > 2) The content is really something else (e.g. MultiMarkdown). In this = case, the user will either have the desired software as part of their = installed software or not. But giving them a list of requirements is = unlikely to change what they do("Ok. You need to find this particular = flavor of Markdown. Yes, I know you'll never use it again, but you = need to install it now. Don't worry, I'll wait the 15 minutes while you = figure that out. And then you need to configure it this particular = way=85." At this point the user moves on to another web site and finds = the content in a .doc file, since that is now easier to use.) RFC 4263 ("text/troff") might be interesting reading there. Markdown is = roff for a new generation and seems to have all the same issues. Content-Type: text/troff ; process=3D"use pic -n then troff -ms" Cheers, Steve --Apple-Mail=_E258967B-AB85-4CDC-A304-75703528BE25 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUIefkAAoJELPnvViFbcu8WZIQAL8tVqvibXfYv9T/gkTJmcAC Dd1UAP2kNNT5MBuy67Ct5IZ4h0UuaZzRnpqiE+tMqD/nXzJ70vgl/gn9hfTfiOQC OBOrPtRaGPE729VuSXpV3kG5vf446dhaDPuq/UBhWlI39N1tlwv1i0qmW9j9anak ygLEcNiLyngF53+4YZo1WJjsJpvGjMokAL2TDE6xYrfVPve2ZgkQh81hUBmbJFmq v9DuCB36al39Jx7icbQjFiWGZObmFa/VDU6JAYUYDwfASn7v6QgOgXBjUvTKAGsv ybhGwwHax8G3v+HdZRAwNuqXRRjgU9aV2Q6855M7CygsHmJV2VTfZ6JgojLj4b+0 U8wv0BIuTQ907KcITBVjB2n+RLHy13GS/MEYBq3i1gEgNQnpS+SUmsOqsT+fGTm8 ZKuazlXNJkE7qUH+lKfSxcRG50BxiIIYByLJ+KwHJHt8BgHje8MFrvWPGJ6PHE9m qVG5B1aeZw0VMGn3JAxlnk0lcIM6c/BqcE5HyQYrV/5je+SJPj7h/etkvc8lxDW/ HFS1U2eYD9NT67kiemxxBErATZw2BCkj6zUaPHhoTDeP9Hy4fEbUoLUcqcrQSSON CfwyvENNwo0jZTM/9gK5Fk+e2PbRKtXYHwIRmAJ3vgAZinOaY5U79a/orUwCdEij 9Kaba+8K9oSJPho2rD9I =zimD -----END PGP SIGNATURE----- --Apple-Mail=_E258967B-AB85-4CDC-A304-75703528BE25-- From nobody Tue Sep 23 17:36:48 2014 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 153361A898B for ; Tue, 23 Sep 2014 17:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 o3sJutFsahh6 for ; Tue, 23 Sep 2014 17:36:44 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0657.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:657]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A3321A8981 for ; Tue, 23 Sep 2014 17:36:44 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Wed, 24 Sep 2014 00:36:21 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.1034.003; Wed, 24 Sep 2014 00:36:21 +0000 From: Larry Masinter To: Sean Leonard , "Murray S. Kucherawy" Thread-Topic: [apps-discuss] Request additional reviewer for Markdown Thread-Index: AQHP0XWyP+8Xx580tU2pA5gdN4fvH5wDj9oAgAA9FYCAC1LRgIAADu0AgAANvYCAAD0kEA== Date: Wed, 24 Sep 2014 00:36:21 +0000 Message-ID: <730b649961d44920bdfb7735719a5bba@BL2PR02MB307.namprd02.prod.outlook.com> References: <20140909161748.4607.39564.idtracker@ietfa.amsl.com> <54136795.2070500@seantek.com> <5417CF14.7040206@seantek.com> <5417D579.3010900@seantek.com> <54181186.4030507@ninebynine.org> <541844C3.2030200@ninebynine.org> <2D8AF589-0095-45EA-AAF1-7471598ADA00@seantek.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2601:9:8380:992:15e2:cd18:cf28:40b9] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR02MB307; x-forefront-prvs: 03449D5DD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(107046002)(106356001)(97736003)(15202345003)(21056001)(50986999)(15975445006)(92566001)(90102001)(106116001)(10300001)(95666004)(15395725005)(120916001)(105586002)(86362001)(54356999)(76176999)(20776003)(4396001)(101416001)(79102003)(76482002)(80022003)(108616004)(83322001)(74502003)(46102003)(74316001)(74662003)(99396002)(31966008)(77982003)(81542003)(2656002)(83072002)(85852003)(76576001)(19580395003)(64706001)(81342003)(85306004)(87936001)(93886004)(33646002)(3826002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR02MB307; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wyuSr5O-30rPaSffOprDqb5BYEM Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Request additional reviewer for Markdown 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, 24 Sep 2014 00:36:47 -0000 SWYgaXQncyBhdCBhbGwgcG9zc2libGUsIHB1dCB2ZXJzaW9uL3Byb2Nlc3NpbmcgaW5zdHJ1Y3Rp b25zL3Byb2ZpbGVzIGFzIGluLWJhbmQgY29tbWVudCAvIHByb2Nlc3NpbmcgaW5zdHJ1Y3Rpb25z LCByYXRoZXIgdGhhbiBNSU1FLXR5cGUgcGFyYW1ldGVycywgd2hpY2ggaW5ldml0YWJseSBhcmUg bG9zdA0KDQpTbywgaWYgSSBiZWxpZXZlIGh0dHA6Ly9zdGFja292ZXJmbG93LmNvbS9xdWVzdGlv bnMvNDgyMzQ2OC9zdG9yZS1jb21tZW50cy1pbi1tYXJrZG93bi1zeW50YXgNCkZvciBleGFtcGxl IHlvdSBjb3VsZCBpbmRpY2F0ZSB0aGUgZmxhdm9yIGFuZCBkZXNpcmVkIHByb2Nlc3NvciB3aXRo IHRoYXQgaW5mb3JtYXRpb24gaW4gYSBNYXJrZG93biBjb21tZW50Lg0KDQoNClsvL106ICMgKCAg e01hcmtkb3duLWZhdm9yOiAiT3JpZ2luYWwiLCBwcm9jZXNzb3I6ICJNYXJrZG93bi5wbC0xLjAu MmI4IC0taHRtbDR0YWdzIn0gKQ0KDQpNSU1FIHNob3VsZCBkaXNjb3VyYWdlIHBhcmFtZXRlcnMs IHNpbmNlIE9TJ3MgZG9uJ3Qgc2VlbSB0byBnZXQgdGhlbSBldmVuIGFmdGVyIGEgZmV3IGRlY2Fk ZXMuDQoNCkxhcnJ5DQotLQ0KaHR0cDovL2xhcnJ5Lm1hc2ludGVyLm5ldA0KDQo= From nobody Tue Sep 23 21:07:06 2014 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 7DE2A1A8A66 for ; Tue, 23 Sep 2014 21:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 WArC38qd-OTI for ; Tue, 23 Sep 2014 21:06:57 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6561A1B15 for ; Tue, 23 Sep 2014 21:06:57 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C59F7509B5; Wed, 24 Sep 2014 00:06:55 -0400 (EDT) Message-ID: <54224355.2070300@seantek.com> Date: Tue, 23 Sep 2014 21:06:45 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/MSoxKAoCuJTW53GhR7znY0whsNo Cc: Benjamin Young Subject: Re: [apps-discuss] IRC URIs to denote users 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, 24 Sep 2014 04:07:02 -0000 On 9/22/2014 1:50 PM, Melvin Carvalho wrote: > I was wondering if IRC URIs are standardized at all? > > The latest I found was : > > http://tools.ietf.org/html/draft-butcher-irc-url-04 > > I have a use case of marking reputation from one system (web chat=20 > room) to an IRC chat room, but I require an identifier for the user. > > The suggestions so far have been: > > irc://user@host > irc://user@host/ -- trailing slash > irc:user@host -- similar to xmpp > irc://host/#user -- fragment could be problematic as per RFC 9386 > > I've gone with the second option for the moment > > Any pointers would be most welcome. Based on the options presented, I think the third one, irc:user@host,=20 best captures the spirit of the URI syntax. RFC 3986 Section 3 and 4.3 define absolute URIs as scheme : hier-part;=20 hier-part can be one of: "//" authority path-abempty path-absolute path-rootless path-empty The first one is usually used for identifying resources accessible via=20 some Internet-related protocol where the authority is a host:port (plus=20 optional userinfo to log in to the host:port), followed by some=20 server-specific path to the resource (usually hierarchical). The second=20 one is for some server-specific path (usually hierarchical), where the=20 server's host:port are "obvious". For example,=20 means "an LDAP URL referr= ing=20 to the University of Michigan entry, available from an LDAP server of=20 the client's choosing" (RFC 4516 Section 4). URIs (URLs)=20 refer to the local file system. The fourth one, path-empty, isn't used much...but the gist (I suppose)=20 is if you want to skip right to the ? query or # fragment parts. magnet: = (provisional) URIs use this. Thus, we arrive at path-rootless, which is basically "Everything Else".=20 In this case, you are trying basically to identify an IRC object (a=20 user), and tag it in such a way that it's not an e-mail address.=20 looks like an e-mail address. =20 looks the best to me; it's obviously not an e-mail address. Similarly,=20 it's obviously not an address to an IRC channel. If you say=20 irc://host/user, you're sharing the channel namespace with the user=20 namespace...not a great idea. If you say irc://host/#user, you are=20 saying that the path is "/", which (in the context of users/nicknames)=20 doesn't make a whole lot of sense since users/nicknames are specific to=20 servers/hosts, not to sub-parts of servers/hosts. The telnet: URL/URI is the most analogous to irc URIs--and telnet URLs=20 go way back to Tim Berners-Lee's [original paper]. In the original, it's = telnet://userinfo@host:port -- with no trailing slash (i.e., authority=20 path-abempty). In RFC 1738 sec. 3.8, it's telnet://userinfo@host:port/=20 -- with trailing slash (i.e., authority path-abempty). The ssh URI proposal (draft-ietf-secsh-scp-sftp-ssh-uri-04) has no=20 trailing slash...but it also says that the path part is irrelevant. In=20 any event, the overall gist is that "//" at the beginning is sufficient=20 to distinguish "network paths" from "other things". Sean [original paper]:=20 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=3D10.1.1.45.1836=20 "Universal Document Identifiers on the Network" From nobody Tue Sep 23 22:20:57 2014 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 E8C5C1A8A93 for ; Tue, 23 Sep 2014 22:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9lch7syB5-F for ; Tue, 23 Sep 2014 22:20:52 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 148241A8A8A for ; Tue, 23 Sep 2014 22:20:51 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id q5so6461175wiv.1 for ; Tue, 23 Sep 2014 22:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=K8uBR/snWO5wyC0lM3Uyk9ncEDtmjmmaVZsXxzdMGgc=; b=swqa8B6bkH7PSh1vNPSN4Q9Nm3Y2/4FiHAFWxg96L5p6PF1XOehP+Dwf6OL8+uug6r 0gg5ULn6n2GttObbHeFOz+DIv2cCrxzS90zplmCfjr1WCcRi1N15coeWPcpjO57PIxod UO4YgEkphhwJ89fyvnq2XjgBa5Pgu3bAnkG4kj3gN8YpkUpdCEIvCuvmC+S3Up58jvgG x5YP+pr9OPDCRNSPRo9YbouQc34gAWXs+BmZQzV3PllwDgxquPFYjPwvVYjZh8AEV92s tvbjXO4ZGbZJRQLDbEzOUde0tRJlX/BOiXZPgPhiHAfyitCQ4G97XBxSW/ZGCZjTwr2h w3cA== MIME-Version: 1.0 X-Received: by 10.180.86.73 with SMTP id n9mr27857749wiz.30.1411536050649; Tue, 23 Sep 2014 22:20:50 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Tue, 23 Sep 2014 22:20:50 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Sep 2014 22:20:50 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d0442806ee301fc0503c8d874 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/EVNqjB_r4kFhTErxKPFyt4M5OVA Subject: [apps-discuss] Fwd: Request for input: text/markdown media type 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, 24 Sep 2014 05:20:55 -0000 --f46d0442806ee301fc0503c8d874 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Colleagues, As discussed, it's important to us that the text/markdown work not take place in a vacuum. Thus, in coordination with our supervising Area Director and with Sean, I have sent the following informal liaison statement to several participants in the Markdown community as well as one of their main mailing lists. If there are other participants in that community that didn't receive the statement and should have, or other mailing lists to which we should reach out, please let me know and I'll forward it there as well. -MSK, APPSAWG co-chair ---------- Forwarded message ---------- From: Murray S. Kucherawy Date: Tue, Sep 23, 2014 at 10:17 PM Subject: Request for input: text/markdown media type From: IETF Applications Area Working Group (APPSAWG) Response Contact: superuser@gmail.com Technical Contact: superuser@gmail.com dev+ietf@seantek.com Purpose: Request for input Attachments: (none) Body: The Applications Area Working Group (APPSAWG) of the Internet Engineering Task Force (IETF) has taken up a proposed work item to register a new Media Type, "text/markdown", for the purposes of identifying content in the Markdown format. The current version of the document can be viewed here: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ We know Sean Leonard approached the Markdown community about starting this work previously (see http://six.pairlist.net/pipermail/markdown-discuss/2014-July/thread.html) and some of the questions that were discussed in that thread are also being asked in the working group. In the interests of ensuring that any choices we make will not conflict with the positions and course of the Markdown community, APPSAWG would like to solicit feedback on a few important questions. Part of the impetus here is that an unregistered and unspecified media type =E2=80=9Ctext/x-markdown=E2=80=9D appears to be in use. This work seeks to= formalize this use and register the name. Our questions for the Markdown community: (1) We understand there is not a standard Markdown format, but rather a number of variants based on one original proposal. This leads us to wonder how a consumer would be expected to interpret this media type once it is registered. Typically, a media type registration includes a reference to a single, stable, definition document, but we are not aware of such a thing for Markdown. Can or should this work proceed without one? Note that the IETF has no intention to undertake the work of publishing an RFC that contains a Markdown syntax or otherwise blessing any particular Markdown variant, or calling one of them =E2=80=9Cstandard". Any Markdown definition document(s) would be referenced by this work and would be external to the IETF. (2) One proposal to address this issue is to include a parameter that indicates which flavor of Markdown should be applied in order to translate the input when the media type is encountered. For example: Content-Type: text/markdown; flavor=3D"foobar" This would likely necessitate a registry of known variants and their respective defining documents so that a consumer has implementation guidance. This puts some burden on the Markdown community to begin formally documenting and registering all of its variants that might use this media type. (3) The solution in (2) above further raises the question of whether there should be a default variant (i.e., what to do if no =E2=80=9Cflavor=E2=80= =9D clause is present), and if so, which one should be the default. If there is no default, then how should a consumer interpret the absence of the =E2=80=9Cf= lavor" tag? (4) At the same time, it has been observed that regardless of which variant is in use as input, any Markdown processor will generally produce something useful as output. Given this, is it necessary to know the =E2=80=9Cflavor= =E2=80=9D in use at all? Put another way: Rather than being concerned with variants, should "text/markdown" merely be a hint to consumers that the content is in some Markdown variant, and beyond that, caveat implementer? (5) Does the Markdown community have any alternative suggestions in response to any of these questions? We look forward to your replies, hopefully within the next several weeks, which can be sent to the response and technical contacts listed in the header of this liaison. Markdown community participants are also invited to subscribe and reply to apps-discuss@ietf.org in order to address the entire working group directly. M. Kucherawy for the Applications Area Working Group, IETF --f46d0442806ee301fc0503c8d874 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

As discussed, it's important t= o us that the text/markdown work not take place in a vacuum. Thus, in coord= ination with our supervising Area Director and with Sean, I have sent the f= ollowing informal liaison statement to several participants in the Markdown= community as well as one of their main mailing lists.

If there are = other participants in that community that didn't receive the statement = and should have, or other mailing lists to which we should reach out, pleas= e let me know and I'll forward it there as well.

-MSK, APP= SAWG co-chair

---------- Forwar= ded message ----------
From: Murray S. Kuc= herawy <sup= eruser@gmail.com>
Date: Tue, Sep 23, 2014 at 10:17 PM
S= ubject: Request for input: text/markdown media type

From: IETF Applications Area Working Group (APPSAWG)

Response = Contact: superuser= @gmail.com

Technical Contact: superuser@gmail.com
=C2=A0=C2=A0=C2=A0 dev+ietf@seantek.com<= /a>

Purpose: Request for input

Attachments: (none)=

Body:

The Applications Area Working Group (APPSAWG) of the I= nternet Engineering=C2=A0 Task Force (IETF) has taken up a proposed work it= em to register a new Media Type, "text/markdown", for the purpose= s of identifying content in the Markdown format.=C2=A0 The current version = of the document can be viewed here:

https://da= tatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/

We know= Sean Leonard approached the Markdown community about starting this work pr= eviously (see http://six.pairlist.net/pipermail= /markdown-discuss/2014-July/thread.html) and some of the questions that= were discussed in that thread are also being asked in the working group.= =C2=A0 In the interests of ensuring that any choices we make will not confl= ict with the positions and course of the Markdown community, APPSAWG would = like to solicit feedback on a few important questions.

Part of the i= mpetus here is that an unregistered and unspecified media type =E2=80=9Ctex= t/x-markdown=E2=80=9D appears to be in use.=C2=A0 This work seeks to formal= ize this use and register the name.

Our questions for the Markdown c= ommunity:

(1) We understand there is not a standard Markdown format,= but rather a number of variants based on one original proposal.=C2=A0 This= leads us to wonder how a consumer would be expected to interpret this medi= a type once it is registered.=C2=A0 Typically, a media type registration in= cludes a reference to a single, stable, definition document, but we are not= aware of such a thing for Markdown.=C2=A0 Can or should this work proceed = without one?

Note that the IETF has no intention to undertake the wo= rk of publishing an RFC that contains a Markdown syntax or otherwise blessi= ng any particular Markdown variant, or calling one of them =E2=80=9Cstandar= d".=C2=A0 Any Markdown definition document(s) would be referenced by t= his work and would be external to the IETF.

(2) One proposal to addr= ess this issue is to include a parameter that indicates which flavor of Mar= kdown should be applied in order to translate the input when the media type= is encountered.=C2=A0 For example:

Content-Type: text/markdown; fla= vor=3D"foobar"

This would likely necessitate a registry of= known variants and their respective defining documents so that a consumer = has implementation guidance.=C2=A0 This puts some burden on the Markdown co= mmunity to begin formally documenting and registering all of its variants t= hat might use this media type.

(3) The solution in (2) above further= raises the question of whether there should be a default variant (i.e., wh= at to do if no =E2=80=9Cflavor=E2=80=9D clause is present), and if so, whic= h one should be the default.=C2=A0 If there is no default, then how should = a consumer interpret the absence of the =E2=80=9Cflavor" tag?

(= 4) At the same time, it has been observed that regardless of which variant = is in use as input, any Markdown processor will generally produce something= useful as output.=C2=A0 Given this, is it necessary to know the =E2=80=9Cf= lavor=E2=80=9D in use at all?=C2=A0 Put another way: Rather than being conc= erned with variants, should "text/markdown" merely be a hint to c= onsumers that the content is in some Markdown variant, and beyond that, cav= eat implementer?

(5) Does the Markdown community have any alternativ= e suggestions in response to any of these questions?

We look forward= to your replies, hopefully within the next several weeks, which can be sen= t to the response and technical contacts listed in the header of this liais= on.=C2=A0 Markdown community participants are also invited to subscribe and= reply to apps-d= iscuss@ietf.org in order to address the entire working group directly.<= br>

M. Kucherawy
for the Applications Area Working Group, IETF

--f46d0442806ee301fc0503c8d874-- From nobody Tue Sep 23 23:22:20 2014 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 4068E1A7028 for ; Tue, 23 Sep 2014 23:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8W_X5gpTZa91 for ; Tue, 23 Sep 2014 23:22:15 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77E071A1B1C for ; Tue, 23 Sep 2014 23:22:15 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id n12so3816942wgh.11 for ; Tue, 23 Sep 2014 23:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=SY8ZiwOZ9uf/vCUhWwpby5AWJzihYSZrttFjaHgUync=; b=p3iWHONAQU80w/c5gCLJiYsxj4EgOFLF73I06i9jkulia2k5FPNYGjCzst8JzDO6XW 9AmL9fZYqvg+82djd0BCJTWnEIibmavC7hB4Q+AJ1LADc3wDbAw7xkuRgUgAeoDh7A4d nqhLQp5WKguUbZPYQjSlfRUNApyZvRwErQeGrC09hwRYxcNZ8KUPb1QSXvHb0hfnh8Zc QMMr/xe2ig26HazpsU1rfCnaMfPzKKKOGkVGLjUzKZnORlkOJ5Jx4v/yIxbyO7Ur0RXq hHvO/7MKtAJe6sw2wnH7kCNDXcTSI5qrPdTYJCr823ivun1Ae7EaxAiTplzuD1NCaZbM WX9Q== MIME-Version: 1.0 X-Received: by 10.194.237.2 with SMTP id uy2mr5219362wjc.89.1411539733560; Tue, 23 Sep 2014 23:22:13 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Tue, 23 Sep 2014 23:22:13 -0700 (PDT) In-Reply-To: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> References: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> Date: Tue, 23 Sep 2014 23:22:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e01493f6867d3020503c9b4cc Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Dhe07bGFHr55p8p-eYZFNFiTsl4 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 06:22:18 -0000 --089e01493f6867d3020503c9b4cc Content-Type: text/plain; charset=UTF-8 On Mon, Sep 22, 2014 at 3:42 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Applications Area Working Group Working > Group of the IETF. > > Title : The text/markdown Media Type > Author : Sean Leonard > Filename : draft-ietf-appsawg-text-markdown-02.txt > Pages : 25 > Date : 2014-09-22 > > Abstract: > This document registers the text/markdown media type for use with > Markdown, a family of plain text formatting syntaxes that optionally > can be converted to formal markup languages such as HTML. > This is my first time through the document, so I may lack some context. I'm still learning the history and politics; hopefully some of this review has not yet been tainted by them. 1) You can drop ".txt" from the filename. 2) The section numbering goes backwards after 1.4 somehow. Is there anything funny in the XML forcing this? Or are you editing these by hand? 3) There's an awful lot of context and history being established throughout Section 1. It's not clear to me that a document that's supposed to be just a media type registration needs all this stuff (material SM would call "marketing"). Based on a cursory review, it looks like Section 1.4, paragraphs 1, 3, and 4, would be an adequate and complete Section 1. If you're keen to have all this context published, you could move the rest to an appendix. 4) What is now Section 2 should go after what is now Section 4. 5) I'm not sure that I agree the charset should be mandatory. It seems to go against what I'm reading in RFC2046 Section 4.1 to not have "us-ascii" as a default since this is a subtype of the "text" media type. Why should this be different from how other text/* types do it? 6) The "flavor" tag itself seems to be a debatable point. I don't have an opinion on that yet (more discussion, please), but as defined the name is case-sensitive. Is that what we want? And does it need to be able to contain spaces or special characters such that it will need to be quoted? 7) The "processor" tag makes me very nervous indeed. It seems to me anything you might say as part of the processor argument should be inferred from the value of the flavor argument, obviating the need for this. I would not expect security reviewers or consumers to tolerate the idea that the author of a MIME header field can tell a consumer what command to run and with what arguments. If that were the case, we had better be prepared to come up with a lot of text or ABNF that hardens this against command injection attacks. 8) I'm unclear on what the "output-type" tag is for. Isn't the output format a function of the context in which the MIME part is being processed? For example, if I get this in a piece of email, wouldn't the markdown processor output in HTML if I'm using an HTML-enabled MUA, or in text otherwise? 9) Why is this a provisional registration? 10) In Section 4 you talk about private use or custom parameter values needing to be prefixed with "!". How is this different from the now-deprecated practice of prefixing private use header fields with "X-"? (See BCP 178.) 11) For the flavor parameter, I'm not clear on why it's a mandatory value that has a default. 12) The requirement to register tools that implement given flavors is unusual. What's the impetus here? I'm also not sure about having a Designated Expert that to validate every such registration. That seems like it could be quite a lot to ask of a volunteer. Is that necessary? 13) Security Considerations refers to the "template questions in Section 2", but Section 2 is an example section. Are you using "xref" tags, or setting section numbers manually? 14) Also in Security Considerations, I suggest at least having a summary of the Section 4 issues here, if not actually moving them here. 15) RFC1738 is obsoleted by RFCs 4248 and 4266. 16) Appendix A should include a notation like "[RFC Editor: Please delete this section prior to publication.]" -MSK --089e01493f6867d3020503c9b4cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 22, 2014 at 3:42 PM, <internet-drafts= @ietf.org> wrote:

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= The text/markdown Media Type
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Sean= Leonard
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-appsawg-text-markdown-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 25
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-09-22

Abstract:
=C2=A0 =C2=A0This document registers the text/markdown media type for use w= ith
=C2=A0 =C2=A0Markdown, a family of plain text formatting syntaxes that opti= onally
=C2=A0 =C2=A0can be converted to formal markup languages such as HTML.
<= /blockquote>

This is my first time through the document,= so I may lack some context.=C2=A0 I'm still learning the history and p= olitics; hopefully some of this review has not yet been tainted by them.
1) You can drop ".txt" from the filename.

=
2) The section numbering goes backwards after 1.4 somehow.=C2=A0= Is there anything funny in the XML forcing this?=C2=A0 Or are you editing = these by hand?

3) There's an awful lot of context and= history being established throughout Section 1.=C2=A0 It's not clear t= o me that a document that's supposed to be just a media type registrati= on needs all this stuff (material SM would call "marketing").=C2= =A0 Based on a cursory review, it looks like Section 1.4, paragraphs 1, 3, = and 4, would be an adequate and complete Section 1.=C2=A0 If you're kee= n to have all this context published, you could move the rest to an appendi= x.

4) What is now Section 2 should go after what is now S= ection 4.

5) I'm not sure that I agree the charset sh= ould be mandatory.=C2=A0 It seems to go against what I'm reading in RFC= 2046 Section 4.1 to not have "us-ascii" as a default since this i= s a subtype of the "text" media type.=C2=A0 Why should this be di= fferent from how other text/* types do it?

6) The "f= lavor" tag itself seems to be a debatable point.=C2=A0 I don't hav= e an opinion on that yet (more discussion, please), but as defined the name= is case-sensitive.=C2=A0 Is that what we want?=C2=A0 And does it need to b= e able to contain spaces or special characters such that it will need to be= quoted?

7) The "processor" tag makes me very n= ervous indeed.=C2=A0 It seems to me anything you might say as part of the p= rocessor argument should be inferred from the value of the flavor argument,= obviating the need for this.=C2=A0 I would not expect security reviewers o= r consumers to tolerate the idea that the author of a MIME header field can= tell a consumer what command to run and with what arguments.=C2=A0 If that= were the case, we had better be prepared to come up with a lot of text or = ABNF that hardens this against command injection attacks.

8) I'm unclear on what the "output-type" tag is for.=C2=A0 I= sn't the output format a function of the context in which the MIME part= is being processed?=C2=A0 For example, if I get this in a piece of email, = wouldn't the markdown processor output in HTML if I'm using an HTML= -enabled MUA, or in text otherwise?

9) Why is this a prov= isional registration?

10) In Section 4 you talk about pri= vate use or custom parameter values needing to be prefixed with "!&quo= t;.=C2=A0 How is this different from the now-deprecated practice of prefixi= ng private use header fields with "X-"?=C2=A0 (See BCP 178.)
<= br>
11) For the flavor parameter, I'm not clear on why it'= ;s a mandatory value that has a default.

12) The requirem= ent to register tools that implement given flavors is unusual.=C2=A0 What&#= 39;s the impetus here?=C2=A0 I'm also not sure about having a Designate= d Expert that to validate every such registration.=C2=A0 That seems like it= could be quite a lot to ask of a volunteer.=C2=A0 Is that necessary?
13) Security Considerations refers to the "template quest= ions in Section 2", but Section 2 is an example section.=C2=A0 Are you= using "xref" tags, or setting section numbers manually?

<= /div>
14) Also in Security Considerations, I suggest at least having a = summary of the Section 4 issues here, if not actually moving them here.
=
15) RFC1738 is obsoleted by RFCs 4248 and 4266.

16) Appendix A should include a notation like "[RFC Editor: Plea= se delete this section prior to publication.]"

-MSK<= br>
--089e01493f6867d3020503c9b4cc-- From nobody Tue Sep 23 23:53:25 2014 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 1256B1A1ACD for ; Tue, 23 Sep 2014 23:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEzuKI7SDkq5 for ; Tue, 23 Sep 2014 23:53:22 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFDF31A1A2F for ; Tue, 23 Sep 2014 23:53:22 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id z107so5405390qgd.7 for ; Tue, 23 Sep 2014 23:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HmJcHTpRDOneydRA8Zdny/cbASISskrdUyMeGwldQMg=; b=GfkGo8APjf2p3Z4eCSZjZGRkuHJjj6tVC62eoYxC4FkHJ2KO1CMvzOtTFEMGZ5w6ml FXW7yvnGtW3U7vn5fsKlmyPS8lU/svzaW88iDMy1pTfM9bPnvL7RjGHYrIQfxQNU7rXO BC31a5/avxNYTk7DVixtshdDSzdASPpLhtf5ISsdoRmXQqTwMsPY1/OwdPifY1tkdOOA XKF7Kf2Zzesk1vm7Th7w+aMaUgQdeVKSRFQ25J8jOE1W+YIsukhKcpWoj1QD+7QcX6ok ZOpGpUWpXGWkEu/bXIUhRnSbnJBuwqnIfiFagYi1qOsiDcgf9zwkhcmPe9N2WDwZNm5T 5UAw== MIME-Version: 1.0 X-Received: by 10.229.48.135 with SMTP id r7mr6022653qcf.9.1411541601860; Tue, 23 Sep 2014 23:53:21 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.140.25.150 with HTTP; Tue, 23 Sep 2014 23:53:21 -0700 (PDT) In-Reply-To: References: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> Date: Wed, 24 Sep 2014 16:53:21 +1000 X-Google-Sender-Auth: WPspGHlIjg0y2VdZH2P5wSR3BLg Message-ID: From: Matthew Kerwin To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a1133b512c3c00f0503ca232c Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/btUBBg-pyQF5edBjfqsB5Di058I Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 06:53:24 -0000 --001a1133b512c3c00f0503ca232c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 24 September 2014 16:22, Murray S. Kucherawy wrote= : > > 15) RFC1738 is obsoleted by RFCs 4248 and 4266. > > =E2=80=8B Actually it's RFC 3986 that matters; from RFC 3986, Section 1: | This document obsoletes [RFC2396], which merged "Uniform Resource | Locators" [RFC1738] and "Relative Uniform Resource Locators" | [RFC1808] in order to define a single, generic syntax for all URIs. I really wish the status of RFC 1738 could be fixed up. I've spent two years trying to work out how to resurrect the "file" scheme because RFC 1738 says it's obsoleted, even though the two RFCs that apparently obsoleted it only obsoleted a small part, and the one that really replaced the bulk only "updated" it, and some RFCs that usurped its schemes (looking at you, RFC 2068/2616) didn't update it at all, and some parts are probably meant to still be current (the schemes referenced from the IANA registry, like "file"). --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a1133b512c3c00f0503ca232c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 24 September 2014 16:22, Murray S. Kucherawy <superuser@gmail.com> wrote:
<= div class=3D"gmail_extra">

=
15) RFC1738 is obsoleted by RFCs 4248 and 4266.

=E2= =80=8B
Actually it's RFC 3986 that matters; from RFC 3986,= Section 1:

| This document obsoletes = [RFC2396], which merged "Uniform Resource
| Locators" [RFC1738= ] and "Relative Uniform Resource Locators"
| [RFC1808] in orde= r to define a single, generic syntax for all URIs.

=
I really wish the status of RFC 1738 could be fixed up. I've sp= ent two years trying to work out how to resurrect the "file" sche= me because RFC 1738 says it's obsoleted, even though the two RFCs that = apparently obsoleted it only obsoleted a small part, and the one that reall= y replaced the bulk only "updated" it, and some RFCs that usurped= its schemes (looking at you, RFC 2068/2616) didn't update it at all, a= nd some parts are probably meant to still be current (the schemes reference= d from the IANA registry, like "file").

--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.= au/
--001a1133b512c3c00f0503ca232c-- From nobody Wed Sep 24 00:01:07 2014 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 E567D1A88EA for ; Wed, 24 Sep 2014 00:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, 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 u0VI4O1h6Uda for ; Wed, 24 Sep 2014 00:01:01 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DAF61A70FD for ; Wed, 24 Sep 2014 00:01:00 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id l4so9968585lbv.5 for ; Wed, 24 Sep 2014 00:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=KN3dmSPIDsfj+y7HDhe1upbYnQo83xh6fzs+BU3K3ng=; b=tx6jLZpcxXISJfpZOZ9+wIKJmXfiJZRBmwWtLDAh5Oxm73N8UalwH1uGB0WsHaRmpi F1PVxqN+3ry6IJpq1ZV+3KPdKHVc2QMFwJ5EJT+I+XVAcwR/tjaoubz2SLYGR9f+u1jr kXt+xKEMgKpq1pu7BXBjdSBm3yH1JSoZs7uaESH128YasATA3gEXH2X/uVYK/EzXp9aG o0gS3S9xe50NfNJyHO0X4uChFmOmN7b8/2FAecVgETOcJXgsU/LfR4pjIcTUuI8cDmns pMznby2Zr9Fnpl8Dozn78ofV0w2MqN1Mqsw5Nzvy5Y4B93ckkOuLfYgrmARFDYLK69p3 lOSg== MIME-Version: 1.0 X-Received: by 10.152.42.209 with SMTP id q17mr3786405lal.43.1411542058968; Wed, 24 Sep 2014 00:00:58 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Wed, 24 Sep 2014 00:00:58 -0700 (PDT) Date: Wed, 24 Sep 2014 00:00:58 -0700 Message-ID: From: Martin Thomson To: Apps Discuss Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hFb01-Dw3vhJcTKmtBKxo0EnPlY Subject: [apps-discuss] Review of draft-ietf-appsawg-text-markdown 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, 24 Sep 2014 07:01:05 -0000 Like others, I think that this document is doing too much. I believe the following statement to be almost sufficient: https://imgflip.com/i/ceqvt The introduction is excessively long, and, as others have noted, too strongly opinionated. It merely needs to describe what markdown is and what identification provides. It does not need to include a history lesson (I'm sure that Wikipedia can cover that), or why it came about, and it especially doesn't need to make disparaging statement about alternatives. The flavor parameter is the only parameter that this needs to define. I do have some concerns with that though - The convention on title case is odd. I'd be interested in learning why that might be a good idea over a much easier to type all lowercase initial set of entries, without calling out the choice specially. - Flavor very much does not need to permit the range of characters that it currently does. - Please remove the '!' rule [RFC 6648] - The registration procedures in the "Standard of Review" section could be a lot simpler. Say "Expert Review" and then provide short guidance to the expert. I believe that the following would be sufficient guidance: "The expert is requested to ensure that entries do not duplicate others, and that a reasonable effort has been made to provide stable documentation. Entries with names that are confusing or misleading, such as those that differ from existing entries only in letter case, can be encouraged to find alternative names." The current text says one thing (almost FCFS), but then ends up implying a great deal more than that. If you want to avoid people using "md" or "Markdown", then create initial values for them. From nobody Wed Sep 24 00:14:36 2014 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 AAC971A88E1 for ; Wed, 24 Sep 2014 00:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 EgGnpCgABOra for ; Wed, 24 Sep 2014 00:14:33 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F32C51A88F6 for ; Wed, 24 Sep 2014 00:14:32 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id u10so10259947lbd.27 for ; Wed, 24 Sep 2014 00:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wwmDFSZrUAXtPNEpk5g9jaEAIn4ngJP72BFCZMcbWgo=; b=zvEmY+X0lYZCiUbYAO6BKFXqVsk6+mqn593jkTLHIBWQlreH3ev/gHYtkTLrnh4nfP WW5SkxEOWYpH+/3izq5gApFM6lxeg9N7myqoiVt5Ohx/Hz1S4Rr18UIgnYZJurEXmtUI XqKxoRsvsZrxvoKviuh7t12eeYvEem/yksQHWj4UWkabcd8w2FLVjvlY7pW6FtInKeo3 u/h8kANn3Od8p0BuDItyVxi7rkX+aKfbcHWyE3aVOeomk/908SX2Bnb2jHCMhl9visR2 0ofJm3dv4Fdue73i0QQbjO0T6cYjGXNYTeE2GXEaSOPuAaPVKiYk8uF7GyUi8TSpGjSi G9mw== MIME-Version: 1.0 X-Received: by 10.112.125.132 with SMTP id mq4mr1046104lbb.103.1411542871313; Wed, 24 Sep 2014 00:14:31 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Wed, 24 Sep 2014 00:14:31 -0700 (PDT) In-Reply-To: References: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> Date: Wed, 24 Sep 2014 00:14:31 -0700 Message-ID: From: Martin Thomson To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/xZpt92QLFoTLzsHUN60mG-PJito Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 07:14:34 -0000 On 23 September 2014 23:22, Murray S. Kucherawy wrote: > 2) The section numbering goes backwards after 1.4 somehow. Is there > anything funny in the XML forcing this? Or are you editing these by hand? It's Markdown, didn't you know? https://github.com/cabo/kramdown-rfc2629 Though that tool wouldn't do that. From nobody Wed Sep 24 00:29:23 2014 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 68A201A8BC1 for ; Wed, 24 Sep 2014 00:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 0AR82a6v17cj for ; Wed, 24 Sep 2014 00:29:18 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 289891A70FD for ; Wed, 24 Sep 2014 00:29:18 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C4EC7509B8 for ; Wed, 24 Sep 2014 03:29:16 -0400 (EDT) Message-ID: <542272C2.8030305@seantek.com> Date: Wed, 24 Sep 2014 00:29:06 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080504010007010704080800" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-Q1pH5ecHFfYTAo8RzatnzrdOek Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 07:29:21 -0000 This is a multi-part message in MIME format. --------------080504010007010704080800 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 9/23/2014 11:22 PM, Murray S. Kucherawy wrote: > On Mon, Sep 22, 2014 at 3:42 PM, > wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Applications Area Working Group > Working Group of the IETF. > > Title : The text/markdown Media Type > Author : Sean Leonard > Filename : draft-ietf-appsawg-text-markdown-02.txt > Pages : 25 > Date : 2014-09-22 > > Abstract: > This document registers the text/markdown media type for use wit= h > Markdown, a family of plain text formatting syntaxes that > optionally > can be converted to formal markup languages such as HTML. > > > This is my first time through the document, Yay! > so I may lack some context. I'm still learning the history and=20 > politics; hopefully some of this review has not yet been tainted by the= m. > > 1) You can drop ".txt" from the filename. No problem. > > 2) The section numbering goes backwards after 1.4 somehow. Is there=20 > anything funny in the XML forcing this? Or are you editing these by ha= nd? Good 'ol nroff (NroffEdit, specifically). I think for folks from the=20 security-area, nroff is the preferred tool. xml2rfc does not permit fine = enough control over spacing. > > 3) There's an awful lot of context and history being established=20 > throughout Section 1. It's not clear to me that a document that's=20 > supposed to be just a media type registration needs all this stuff=20 > (material SM would call "marketing"). Based on a cursory review, it=20 > looks like Section 1.4, paragraphs 1, 3, and 4, would be an adequate=20 > and complete Section 1. If you're keen to have all this context=20 > published, you could move the rest to an appendix. Noted. > > 4) What is now Section 2 should go after what is now Section 4. Originally I put the example at the end, but for draft-02 I felt like it = should be at the beginning. Especially given the lack of a *formal*=20 specification, I wanted to be clear with an example up-front. It can go=20 back, though. > > 5) I'm not sure that I agree the charset should be mandatory. It=20 > seems to go against what I'm reading in RFC2046 Section 4.1 to not=20 > have "us-ascii" as a default since this is a subtype of the "text"=20 > media type. Why should this be different from how other text/* types=20 > do it? See RFC 6657 (whole thing) and RFC 6838 Section 4.2.1. > > 6) The "flavor" tag itself seems to be a debatable point. I don't=20 > have an opinion on that yet (more discussion, please), but as defined=20 > the name is case-sensitive. Is that what we want? And does it need=20 > to be able to contain spaces or special characters such that it will=20 > need to be quoted? There are a few reasons for the case-sensitivity of the name. First, the = parameter value can be any Unicode string. The purpose was to enable=20 flavors (variants) to be named things in languages other than English.=20 See BCP 18 Section 2, "Where to do internationalization". Right now most = examples of Markdown-related flavors are in English, but it is perfectly = conceivable that someone can write some Markdown variant in some other=20 script. Actually, Markdown itself is starting to be iconized as M=E2=86=93= by=20 the community. Over the last couple of years, I have become very suspicious about=20 case-insensitivity and its interactions with Unicode. It's one thing to=20 map the US-ASCII characters U+0041-U+005A (uppercase) to U+0061-U+007A;=20 it's another thing to require huge tables of mappings for all sorts of=20 scripts out there. See=20 =20 for the case folding algorithm. Note that Unicode defines three cases:=20 uppercase, lowercase, and title case. Too. Much. Detail. BCP 18 frames the problem and states specifically that: "Names are a problem, because people feel strongly about them, many of=20 them are mostly for local usage, and all of them tend to leak out of the = local context at times. RFC 1958=20 recommends US-ASCII for all globally = visible names. This document does not mandate a policy on name=20 internationalization, but requires that all protocols describe whether=20 names are internationalized or US-ASCII." The compromise position I reached was that you can use Unicode, but you=20 SHOULD use US-ASCII. And since I wanted to obviate the case-folding=20 issue, I said case-sensitive. As a bonus: John Gruber is extremely sensitive to capitalization of=20 "Markdown". > > 7) The "processor" tag makes me very nervous indeed. It seems to me=20 > anything you might say as part of the processor argument should be=20 > inferred from the value of the flavor argument, obviating the need for = > this. I would not expect security reviewers or consumers to tolerate=20 > the idea that the author of a MIME header field can tell a consumer=20 > what command to run and with what arguments. If that were the case,=20 > we had better be prepared to come up with a lot of text or ABNF that=20 > hardens this against command injection attacks. I think the security risk is significantly mitigated (perhaps even=20 eliminated) by registration. Will write in separate e-mail. > > 8) I'm unclear on what the "output-type" tag is for. Isn't the output=20 > format a function of the context in which the MIME part is being=20 > processed? For example, if I get this in a piece of email, wouldn't=20 > the markdown processor output in HTML if I'm using an HTML-enabled=20 > MUA, or in text otherwise? First, thanks for the open discussion of output-type. I think the text=20 spells it out. text/html is what most people think of...but text/html is = not the way that Markdown is going. Markdown is slowly encroaching upon=20 every other format, because other formats are "too complicated". The use case of an e-mail client showing the HTML output of Markdown=20 inline, is not realistic. As someone else noted earlier, if you write an = e-mail in Markdown and want the recipient to see formatted text, the=20 expectation is that the sending mail client will do the formatting, so=20 in an e-mail, the received data will be text/html. Probably a better scenario (which is becoming a significant use case) is = authors collaborating on a document. The authors on disparate machines=20 *both* want to see the source, *and* the output, preferably at the same=20 time. Maybe one collaborator is the author and the other is an editor or = reviewer. > > 9) Why is this a provisional registration? Oh, just because it's an Internet-Draft. I sent a registration request=20 for a provisional registration back after draft-01 was published. I=20 think it's being held up by an IANA question of whether I-Ds can do=20 provisional registrations, or if it requires AD action. Anyway, that field should be changed to "No". > > 10) In Section 4 you talk about private use or custom parameter values = > needing to be prefixed with "!". How is this different from the=20 > now-deprecated practice of prefixing private use header fields with=20 > "X-"? (See BCP 178.) I was not aware of BCP 178 at the time. Also, several commenters asked=20 for a way to use unregistered identifiers...I don't want to quote them=20 directly but I recall that they expressed concerns that nobody would=20 bother registering identifiers. Now that I am aware of BCP 178, I agree=20 that the unregistered value mechanism should be removed. The right way=20 to fix this is to make registration very simple. I am less sure about=20 provisional registrations...that sounds more complicated (and moreover,=20 it sounds like an invitation to do a provisional registration and then=20 skip town). > > 11) For the flavor parameter, I'm not clear on why it's a mandatory=20 > value that has a default. It's optional. The text does say "Generators MUST NOT emit empty flavor=20 parameters"...but then it proceeds, "but parsers MUST treat empty flavor = parameters the same as if omitted." The whole parameter is optional. The = point is that there is a syntactic difference between: text/markdown; flavor=3D"" and text/markdown but there is no semantic difference--they mean the same thing. > > 12) The requirement to register tools that implement given flavors is=20 > unusual. What's the impetus here? Section 5.1.1.: "The purpose of the tool requirement is to ensure that the flavor is=20 actually used in practice." Due to the proliferation of processors, there have been very many calls=20 in the Markdown community to have "one true formalized syntax". So that=20 means that now there is a proliferation of syntax=20 specifications--several of which are not representative of any=20 implementation at all! > I'm also not sure about having a Designated Expert that to validate=20 > every such registration. That seems like it could be quite a lot to=20 > ask of a volunteer. Is that necessary? I tried to constrain the work that the DE would have to do. It's=20 definitely worth discussing. > > 13) Security Considerations refers to the "template questions in=20 > Section 2", but Section 2 is an example section. Are you using "xref" = > tags, or setting section numbers manually? nroff. Incidentally: Markdown has setext and atx header syntaxes, but Gruber's=20 Markdown syntax does not allow headers to be numbered. Numbered headers=20 (which would be very useful for IETF documents, wink wink) are an=20 extension in some Markdown variants. For example: |pandoc --number-sections| > 14) Also in Security Considerations, I suggest at least having a=20 > summary of the Section 4 issues here, if not actually moving them here.= Ok. Noted. > > 15) RFC1738 is obsoleted by RFCs 4248 and 4266. RFC 1738 is the latest reference for file:/// URLs. > > 16) Appendix A should include a notation like "[RFC Editor: Please=20 > delete this section prior to publication.]" Ok. Noted. Thanks! -Sean --------------080504010007010704080800 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 9/23/2014 11:22 PM, Murray S. Kucherawy wrote:
On Mon, Sep 22, 2014 at 3:42 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

        Title           : The text/markdown Media Type
        Author          : Sean Leonard
        Filename        : draft-ietf-appsawg-text-markdown-02.txt
        Pages           : 25
        Date            : 2014-09-22

Abstract:
   This document registers the text/markdown media type for use with
   Markdown, a family of plain text formatting syntaxes that optionally
   can be converted to formal markup languages such as HTML.

This is my first time through the document,

Yay!

so I may lack some context.  I'm still learning the history and politics; hopefully some of this review has not yet been tainted by them.

1) You can drop ".txt" from the filename.
No problem.


2) The section numbering goes backwards after 1.4 somehow.  Is there anything funny in the XML forcing this?  Or are you editing these by hand?

Good 'ol nroff (NroffEdit, specifically). I think for folks from the security-area, nroff is the preferred tool. xml2rfc does not permit fine enough control over spacing.


3) There's an awful lot of context and history being established throughout Section 1.  It's not clear to me that a document that's supposed to be just a media type registration needs all this stuff (material SM would call "marketing").  Based on a cursory review, it looks like Section 1.4, paragraphs 1, 3, and 4, would be an adequate and complete Section 1.  If you're keen to have all this context published, you could move the rest to an appendix.

Noted.


4) What is now Section 2 should go after what is now Section 4.

Originally I put the example at the end, but for draft-02 I felt like it should be at the beginning. Especially given the lack of a *formal* specification, I wanted to be clear with an example up-front. It can go back, though.


5) I'm not sure that I agree the charset should be mandatory.  It seems to go against what I'm reading in RFC2046 Section 4.1 to not have "us-ascii" as a default since this is a subtype of the "text" media type.  Why should this be different from how other text/* types do it?

See RFC 6657 (whole thing) and RFC 6838 Section 4.2.1.


6) The "flavor" tag itself seems to be a debatable point.  I don't have an opinion on that yet (more discussion, please), but as defined the name is case-sensitive.  Is that what we want?  And does it need to be able to contain spaces or special characters such that it will need to be quoted?

There are a few reasons for the case-sensitivity of the name. First, the parameter value can be any Unicode string. The purpose was to enable flavors (variants) to be named things in languages other than English. See BCP 18 Section 2, "Where to do internationalization". Right now most examples of Markdown-related flavors are in English, but it is perfectly conceivable that someone can write some Markdown variant in some other script. Actually, Markdown itself is starting to be iconized as M↓ by the community.

Over the last couple of years, I have become very suspicious about case-insensitivity and its interactions with Unicode. It's one thing to map the US-ASCII characters U+0041-U+005A (uppercase) to U+0061-U+007A; it's another thing to require huge tables of mappings for all sorts of scripts out there. See <http://en.wikipedia.org/wiki/Letter_case#Unicode_case_folding_and_script_identification> for the case folding algorithm. Note that Unicode defines three cases: uppercase, lowercase, and title case. Too. Much. Detail.

BCP 18 frames the problem and states specifically that:
"Names are a problem, because people feel strongly about them, many of them are mostly for local usage, and all of them tend to leak out of the local context at times. RFC 1958 recommends US-ASCII for all globally visible names. This document does not mandate a policy on name internationalization, but requires that all protocols describe whether names are internationalized or US-ASCII."

The compromise position I reached was that you can use Unicode, but you SHOULD use US-ASCII. And since I wanted to obviate the case-folding issue, I said case-sensitive.

As a bonus: John Gruber is extremely sensitive to capitalization of "Markdown".


7) The "processor" tag makes me very nervous indeed.  It seems to me anything you might say as part of the processor argument should be inferred from the value of the flavor argument, obviating the need for this.  I would not expect security reviewers or consumers to tolerate the idea that the author of a MIME header field can tell a consumer what command to run and with what arguments.  If that were the case, we had better be prepared to come up with a lot of text or ABNF that hardens this against command injection attacks.

I think the security risk is significantly mitigated (perhaps even eliminated) by registration. Will write in separate e-mail.


8) I'm unclear on what the "output-type" tag is for.  Isn't the output format a function of the context in which the MIME part is being processed?  For example, if I get this in a piece of email, wouldn't the markdown processor output in HTML if I'm using an HTML-enabled MUA, or in text otherwise?

First, thanks for the open discussion of output-type. I think the text spells it out. text/html is what most people think of...but text/html is not the way that Markdown is going. Markdown is slowly encroaching upon every other format, because other formats are "too complicated".

The use case of an e-mail client showing the HTML output of Markdown inline, is not realistic. As someone else noted earlier, if you write an e-mail in Markdown and want the recipient to see formatted text, the expectation is that the sending mail client will do the formatting, so in an e-mail, the received data will be text/html.

Probably a better scenario (which is becoming a significant use case) is authors collaborating on a document. The authors on disparate machines *both* want to see the source, *and* the output, preferably at the same time. Maybe one collaborator is the author and the other is an editor or reviewer.


9) Why is this a provisional registration?

Oh, just because it's an Internet-Draft. I sent a registration request for a provisional registration back after draft-01 was published. I think it's being held up by an IANA question of whether I-Ds can do provisional registrations, or if it requires AD action.

Anyway, that field should be changed to "No".


10) In Section 4 you talk about private use or custom parameter values needing to be prefixed with "!".  How is this different from the now-deprecated practice of prefixing private use header fields with "X-"?  (See BCP 178.)

I was not aware of BCP 178 at the time. Also, several commenters asked for a way to use unregistered identifiers...I don't want to quote them directly but I recall that they expressed concerns that nobody would bother registering identifiers. Now that I am aware of BCP 178, I agree that the unregistered value mechanism should be removed. The right way to fix this is to make registration very simple. I am less sure about provisional registrations...that sounds more complicated (and moreover, it sounds like an invitation to do a provisional registration and then skip town).


11) For the flavor parameter, I'm not clear on why it's a mandatory value that has a default.

It's optional.

The text does say "Generators MUST NOT emit empty flavor parameters"...but then it proceeds, "but parsers MUST treat empty flavor parameters the same as if omitted." The whole parameter is optional. The point is that there is a syntactic difference between:
 text/markdown; flavor=""
and
 text/markdown

but there is no semantic difference--they mean the same thing.


12) The requirement to register tools that implement given flavors is unusual.  What's the impetus here?
Section 5.1.1.:
"The purpose of the tool requirement is to ensure that the flavor is actually used in practice."

Due to the proliferation of processors, there have been very many calls in the Markdown community to have "one true formalized syntax". So that means that now there is a proliferation of syntax specifications--several of which are not representative of any implementation at all!

  I'm also not sure about having a Designated Expert that to validate every such registration.  That seems like it could be quite a lot to ask of a volunteer.  Is that necessary?

I tried to constrain the work that the DE would have to do. It's definitely worth discussing.


13) Security Considerations refers to the "template questions in Section 2", but Section 2 is an example section.  Are you using "xref" tags, or setting section numbers manually?
nroff.

Incidentally: Markdown has setext and atx header syntaxes, but Gruber's Markdown syntax does not allow headers to be numbered. Numbered headers (which would be very useful for IETF documents, wink wink) are an extension in some Markdown variants. For example: 
pandoc --number-sections
<http://stackoverflow.com/questions/19999696/are-numbered-headings-in-markdown-rdiscount-possible>

14) Also in Security Considerations, I suggest at least having a summary of the Section 4 issues here, if not actually moving them here.
Ok. Noted.


15) RFC1738 is obsoleted by RFCs 4248 and 4266.

RFC 1738 is the latest reference for file:/// URLs.


16) Appendix A should include a notation like "[RFC Editor: Please delete this section prior to publication.]"
Ok. Noted. Thanks!

-Sean

--------------080504010007010704080800-- From nobody Wed Sep 24 00:55:30 2014 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 1B6601A8F43 for ; Wed, 24 Sep 2014 00:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 TPwMIfhuiwSQ for ; Wed, 24 Sep 2014 00:55:28 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8AF31A8F48 for ; Wed, 24 Sep 2014 00:55:27 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id ty20so10310173lab.9 for ; Wed, 24 Sep 2014 00:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sk8EXUV3r51E7v3i/lBfdtQ5sFFb08wGAP+nfGoodW8=; b=f91uTZBdRYA2fhoOLG7S7YRbbXSJc4yckrAw1qPHbWfgA0fOrYmvaF/cEBoQDI0DuZ S/L1hjxs5/M204Ee6K8liM9HpV1N0uEBsUrW9s7c4ieMwMmrBrswJgNxmdGmybM/tBxx P9+B3MZ2tUvhoSaUihZtwNFR+AtbuS/lmXpNnm4NEH3l/TVb6ll/N/MkTV0EbJYVjJ5E TgbUYGe5iune5WyUwVoDD19POLmN9KzfuNPwhbQbqtPCDwGfV54gl/RBuAHOXU32FqRJ XPoSCEAad4Hn9G3UbXlgFEPtyl4+YdFdjjFOnFBOiIcy1Z87gfaPHEsbW0qM55xz7Bg8 cosw== MIME-Version: 1.0 X-Received: by 10.152.36.4 with SMTP id m4mr4654208laj.17.1411545326254; Wed, 24 Sep 2014 00:55:26 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Wed, 24 Sep 2014 00:55:26 -0700 (PDT) In-Reply-To: <542272C2.8030305@seantek.com> References: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> <542272C2.8030305@seantek.com> Date: Wed, 24 Sep 2014 00:55:26 -0700 Message-ID: From: Martin Thomson To: Sean Leonard Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ctpVbvnDdnlW56Zdo3L7TP04yD8 Cc: Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 07:55:29 -0000 On 24 September 2014 00:29, Sean Leonard wrote: > RFC 1738 is the latest reference for file:/// URLs. I think that the reference you are looking for is RFC 3986. From nobody Wed Sep 24 00:57:39 2014 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 BF51F1A8F4C for ; Wed, 24 Sep 2014 00:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, 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 Ex7_51uWpHyD for ; Wed, 24 Sep 2014 00:57:29 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 109531A8F4A for ; Wed, 24 Sep 2014 00:57:28 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id z11so4855524lbi.29 for ; Wed, 24 Sep 2014 00:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WNki9DMHjhla4Wyq813MFdnv+bPW4b2tPLNkxmDwZA4=; b=aLVJrUB3Gj3oW+bsBe5eIwhW0D6qoWIZsnAJ4L79w2C/7KGDqtAX9knhHkn8D4JjUX H+cK+CSHu1N/QzjWh2yRgm0wqRJ+X0aIPXWNtun6njVLdoCi48xL1b/83lVAIU8RIJzD CPflsX3Mnqsp+PKVljQtL3iXCPUxEEjzIoQLtD0pf1IZOkIqBBjblueAiUVqrnIVpREk +hemucsWSJdn8yet5a0AYrruNAcrV16MLvX0QlrhE8Lg7IL4zvqUHfGezap2O5rRK1Ah fAybMlj3e7RgO0FDxUDEy7vHPNIUeTpKGsLprzD7KYskX/eI1xSUVBILBSAY6Bjg/NX9 A31g== MIME-Version: 1.0 X-Received: by 10.152.36.4 with SMTP id m4mr4664077laj.17.1411545447390; Wed, 24 Sep 2014 00:57:27 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Wed, 24 Sep 2014 00:57:27 -0700 (PDT) In-Reply-To: <542272C2.8030305@seantek.com> References: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> <542272C2.8030305@seantek.com> Date: Wed, 24 Sep 2014 00:57:27 -0700 Message-ID: From: Martin Thomson To: Sean Leonard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/cp1MK1bMradxnyhTsJdbn3kMVH8 Cc: Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 07:57:34 -0000 On 24 September 2014 00:29, Sean Leonard wrote: > There are a few reasons for the case-sensitivity of the name. First, the > parameter value can be any Unicode string. The purpose was to enable flav= ors > (variants) to be named things in languages other than English. See BCP 18 > Section 2, "Where to do internationalization". Right now most examples of > Markdown-related flavors are in English, but it is perfectly conceivable > that someone can write some Markdown variant in some other script. Actual= ly, > Markdown itself is starting to be iconized as M=E2=86=93 by the community= . > > Over the last couple of years, I have become very suspicious about > case-insensitivity and its interactions with Unicode. It's one thing to m= ap > the US-ASCII characters U+0041-U+005A (uppercase) to U+0061-U+007A; it's > another thing to require huge tables of mappings for all sorts of scripts > out there. See > > for the case folding algorithm. Note that Unicode defines three cases: > uppercase, lowercase, and title case. Too. Much. Detail. > > BCP 18 frames the problem and states specifically that: > "Names are a problem, because people feel strongly about them, many of th= em > are mostly for local usage, and all of them tend to leak out of the local > context at times. RFC 1958 recommends US-ASCII for all globally visible > names. This document does not mandate a policy on name internationalizati= on, > but requires that all protocols describe whether names are internationali= zed > or US-ASCII." > > The compromise position I reached was that you can use Unicode, but you > SHOULD use US-ASCII. And since I wanted to obviate the case-folding issue= , I > said case-sensitive. > > As a bonus: John Gruber is extremely sensitive to capitalization of > "Markdown". It's not a name, it's a label. From nobody Wed Sep 24 01:23:37 2014 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 11B7F1A8F4D for ; Wed, 24 Sep 2014 01:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 IIpPXCIRsGJp for ; Wed, 24 Sep 2014 01:23:34 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D829A1A8F49 for ; Wed, 24 Sep 2014 01:23:34 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B3EFA50A86; Wed, 24 Sep 2014 04:23:33 -0400 (EDT) Message-ID: <54227F7B.3010803@seantek.com> Date: Wed, 24 Sep 2014 01:23:23 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Martin Thomson References: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> <542272C2.8030305@seantek.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QZsWXn9gA632-tfxQqNP2uXe0Mk Cc: Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 08:23:36 -0000 On 9/24/2014 12:57 AM, Martin Thomson wrote: > It's not a name, it's a label. What's the difference? (Citation please?) -Sean From nobody Wed Sep 24 01:25:21 2014 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 8EAD11A8F4E for ; Wed, 24 Sep 2014 01:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 2N4glUt1H6hF for ; Wed, 24 Sep 2014 01:25:16 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB8A1A8F4D for ; Wed, 24 Sep 2014 01:25:16 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BF3CB509B8; Wed, 24 Sep 2014 04:25:15 -0400 (EDT) Message-ID: <54227FE1.9060801@seantek.com> Date: Wed, 24 Sep 2014 01:25:05 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Martin Thomson References: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> <542272C2.8030305@seantek.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/jK26J2aTbyeRvzwkGaaoasZHLcQ Cc: Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 08:25:18 -0000 On 9/24/2014 12:55 AM, Martin Thomson wrote: > On 24 September 2014 00:29, Sean Leonard wrote: >> RFC 1738 is the latest reference for file:/// URLs. > I think that the reference you are looking for is RFC 3986. Uh, are you sure? RFC 3986 talks about file:/// URIs but does not define them. The IANA registry for URI schemes plainly points to RFC 1738 for file: see . -Sean From nobody Wed Sep 24 02:25:32 2014 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 0CABE1A87C0 for ; Wed, 24 Sep 2014 02:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 XwbviXpM2tsx for ; Wed, 24 Sep 2014 02:25:28 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA831A1BEA for ; Wed, 24 Sep 2014 02:25:28 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id q1so10256943lam.17 for ; Wed, 24 Sep 2014 02:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K6WCxWt2uYLoHQrnPad14Sz1oy9YLinnQtrep5xhZ9w=; b=POXpX2gUfYS6b4+UKJvun8Ag9iU9mZHEYg/EAQCQmywxHmsk0aiCyunizvONckezxy VPBcMYASLd5NSciVrb5L97H6bU4YakBcwHsz+Yiwq5ia2oCLdqVvCDzknORmIiUlIWXt z3pqhlyllYsf+Ck00jisNWj3+y20qjGmioDVLIVs8gRka47eKnaLTaCN1mV1aVJWHeBB 5QO5n26U4hHh/OkedLmQbnyDteSe5qUt6PHv1LyyvZX7H+XpLePV/7FD9dJoT1tcLySr QJ8Ix8oIJkf9SbXrDlgjB2SWLkEYLIl8DZXE6GXH9bZKaDk+N7polwRdHSUY7PYYhl3s Bgzg== MIME-Version: 1.0 X-Received: by 10.112.219.71 with SMTP id pm7mr4900812lbc.3.1411550726778; Wed, 24 Sep 2014 02:25:26 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Wed, 24 Sep 2014 02:25:26 -0700 (PDT) In-Reply-To: <54227F7B.3010803@seantek.com> References: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> <542272C2.8030305@seantek.com> <54227F7B.3010803@seantek.com> Date: Wed, 24 Sep 2014 02:25:26 -0700 Message-ID: From: Martin Thomson To: Sean Leonard Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/iQVO8i9Igsv8gESP_-WTMRZIvTk Cc: Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 09:25:30 -0000 On 24 September 2014 01:23, Sean Leonard wrote: > What's the difference? (Citation please?) My point was that the intent of the parameter is protocol identification. There is no value in permitting expressiveness through character choice. That's an purely for humans; computers don't need that. From nobody Wed Sep 24 02:49:35 2014 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 EA4E31A6F6F for ; Wed, 24 Sep 2014 02:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.567 X-Spam-Level: X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkogKu4QRabg for ; Wed, 24 Sep 2014 02:49:29 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABE91A6EE5 for ; Wed, 24 Sep 2014 02:49:28 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id D2D7A32E583; Wed, 24 Sep 2014 18:48:42 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 242f_fb4f_0fe92bee_03bf_4cbe_8815_1f923fe0b608; Wed, 24 Sep 2014 18:48:41 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id E5F84BF547; Wed, 24 Sep 2014 18:48:41 +0900 (JST) Message-ID: <54229379.5050400@it.aoyama.ac.jp> Date: Wed, 24 Sep 2014 18:48:41 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Sean Leonard , Martin Thomson References: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> <542272C2.8030305@seantek.com> <54227F7B.3010803@seantek.com> In-Reply-To: <54227F7B.3010803@seantek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Net4MOT4aBeeIKcxY8ohmcIuisY Cc: Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 09:49:33 -0000 On 2014/09/24 17:23, Sean Leonard wrote: > On 9/24/2014 12:57 AM, Martin Thomson wrote: >> It's not a name, it's a label. > > What's the difference? (Citation please?) There are usually three levels of stuff in protocols (in the wider sense), content, identifiers (or names as Martin Thomson calls them) and labels (or whatever you call them). It is usually clear to everybody that in content (e.g. the text in an email, HTML document, Markdown document, and so on), it must be possible to use not only ASCII, but (almost) the full range of Unicode characters. It's widely recognized these days that for identifiers/names (e.g. file names, domain names, email addresses, Web addresses), it is highly preferable to be able to use not only ASCII, but (almost) the full range of Unicode characters. For some background, see e.g. http://tools.ietf.org/html/rfc3987#section-1.1, in particular the second sentence of the second paragraph. It's also widely recognized that for labels (e.g. HTTP verbs, SMTP commands, HTML element and attribute names, media types,...), the cost of offering full Unicode support (as opposed to only allowing ASCII) is not justified. One core distinction between identifiers and labels is their number. The number of identifiers is huge; the number of labels in each category is very limited. We can go into more details in this discussion, but I agree with others that there is no need to allow Unicode for flavors, which then avoids the casing issues and allows to define it as case-insensitive. As for citations, what about the first paragraph of Section 2 of BCP 18 (http://tools.ietf.org/html/bcp18#section-2)? Internationalization is for humans. This means that protocols are not subject to internationalization; text strings are. Where protocol elements look like text tokens, such as in many IETF application layer protocols, protocols MUST specify which parts are protocol and which are text. What Martin Thomson calls labels is what this calls "protocol elements". Regards, Martin. From nobody Wed Sep 24 03:47:59 2014 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 7DBD71A6FCF for ; Wed, 24 Sep 2014 03:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.438 X-Spam-Level: X-Spam-Status: No, score=-0.438 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786, 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 Emy2zHKRChH2 for ; Wed, 24 Sep 2014 03:47:43 -0700 (PDT) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1040A1A6FD8 for ; Wed, 24 Sep 2014 03:47:42 -0700 (PDT) Received: from [192.168.1.26] (unknown [217.91.35.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 628E315A0A95 for ; Wed, 24 Sep 2014 12:47:41 +0200 (CEST) Message-ID: <5422A149.4040603@greenbytes.de> Date: Wed, 24 Sep 2014 12:47:37 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: IETF Apps Discuss References: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> In-Reply-To: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/alYobgsFf8jd7a13Sj0M9HSfxOA Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 10:47:49 -0000 Nit: > [XML1.0-3] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and > F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third > Edition)", World Wide Web Consortium Recommendation REC- > xml-20040204, February 2004, > . This reference is outdated; the latest would be: "[REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, “Extensible Markup Language (XML) 1.0 (Fifth Edition)”, W3C Recommendation REC-xml-20081126, November 2008, . Latest version available at ." From nobody Wed Sep 24 04:44:45 2014 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 BFFBD1A702C for ; Wed, 24 Sep 2014 04:44:42 -0700 (PDT) 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 KZVXl8HBJFjo for ; Wed, 24 Sep 2014 04:44:41 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1881D1A6FFA for ; Wed, 24 Sep 2014 04:44:41 -0700 (PDT) Received: from [192.168.49.8] (unknown [194.168.195.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2359E50A84; Wed, 24 Sep 2014 07:44:38 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Mark Nottingham In-Reply-To: Date: Wed, 24 Sep 2014 12:44:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <50F888FB-CD0D-4AF7-A860-66304C74D59B@mnot.net> References: To: Martin Thomson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/toJlvyKYXBJxh8Y19hivPmNvU1M Cc: Apps Discuss Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-text-markdown 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, 24 Sep 2014 11:44:43 -0000 +1 to every character in Martin=92s message. Please, let=92s not f this up. On 24 Sep 2014, at 8:00 am, Martin Thomson = wrote: > Like others, I think that this document is doing too much. >=20 > I believe the following statement to be almost sufficient: > https://imgflip.com/i/ceqvt >=20 > The introduction is excessively long, and, as others have noted, too > strongly opinionated. It merely needs to describe what markdown is > and what identification provides. It does not need to include a > history lesson (I'm sure that Wikipedia can cover that), or why it > came about, and it especially doesn't need to make disparaging > statement about alternatives. >=20 > The flavor parameter is the only parameter that this needs to define. > I do have some concerns with that though >=20 > - The convention on title case is odd. I'd be interested in learning > why that might be a good idea over a much easier to type all lowercase > initial set of entries, without calling out the choice specially. >=20 > - Flavor very much does not need to permit the range of characters > that it currently does. >=20 > - Please remove the '!' rule [RFC 6648] >=20 > - The registration procedures in the "Standard of Review" section > could be a lot simpler. Say "Expert Review" and then provide short > guidance to the expert. >=20 > I believe that the following would be sufficient guidance: "The > expert is requested to ensure that entries do not duplicate others, > and that a reasonable effort has been made to provide stable > documentation. Entries with names that are confusing or misleading, > such as those that differ from existing entries only in letter case, > can be encouraged to find alternative names." The current text says > one thing (almost FCFS), but then ends up implying a great deal more > than that. >=20 > If you want to avoid people using "md" or "Markdown", then create > initial values for them. >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From nobody Wed Sep 24 05:09:53 2014 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 C8B351A0011 for ; Wed, 24 Sep 2014 05:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 te4KuvGxEvLT for ; Wed, 24 Sep 2014 05:09:49 -0700 (PDT) Received: from cp.hebergementsolutions.com (cp.hebergementsolutions.com [184.170.132.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03861A0018 for ; Wed, 24 Sep 2014 05:09:49 -0700 (PDT) Received: from [173.246.4.178] (port=50570 helo=[10.0.0.100]) by cp.hebergementsolutions.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XWlQE-0006VO-KR for apps-discuss@ietf.org; Wed, 24 Sep 2014 08:11:50 -0400 From: Michel Fortin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 24 Sep 2014 08:09:45 -0400 To: IETF Apps Discuss Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-cPanel-MailScanner-Information: Please contact the ISP for more information X-cPanel-MailScanner-ID: 1XWlQE-0006VO-KR X-cPanel-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-cPanel-MailScanner-SpamCheck: X-cPanel-MailScanner-From: michel.fortin@michelf.ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cp.hebergementsolutions.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - michelf.ca X-Get-Message-Sender-Via: cp.hebergementsolutions.com: authenticated_id: michel.fortin@michelf.ca Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/SKsibivfoTK-OLtDpKUhwNOpp-s Subject: [apps-discuss] draft-ietf-appsawg-text-markdown-02 and the registry 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, 24 Sep 2014 12:09:52 -0000 It's pretty hard for me to do a meaningful review a document when I = disagree with so much of it. Those who use Markdown generally don't need a MIME type. Markdown is = rarely an interchange format, and it isn't meant to be one. There is a = small subset of Markdown users who want a MIME type, but it's not = entirely clear to me why. I'd guess some want it as a decorative = replacement to text/plain (text/markdown fells better) and I'd guess = some want it to try to bring some interoperability. The later use case, interoperability, is still an open problem with = Markdown. There are many reasons contributing to that: there's a low = barrier of entry for writing a new parser, there's no formal = specification and no single test suite, and most implementers want = something that works for their own need (official spec be damned) and = later acquire some more users. There is very little intensive for most = implementers of Markdown parsers to make things interoperable because = what we publish is not the document but the processed version of it. Add = to that that most parsers are written in people's spare time, or at = least that's my case. There is a small subset of users who want a MIME type, but I'm going to = bet most Markdown implementers do not care at all. I, author of PHP = Markdown, personally don't really care much about this spec. (I'm in = fact currently having second thoughts about accepting to be a reviewer = given the complexity of the proposal makes things more bothersome than I = expected.) John Gruber doesn't care much either. I bet it's the case of = most implementers out there. Hence, I think the requirement that parser implementers register = anything is deeply flawed. If there is a registry to be maintained, it = should be maintained by the subset of users who care about having a = things registered in a central place, which for the most part does not = include implementers of Markdown parsers. - - - My suggestion is to find a way to make the type descriptive enough = without prescribing any action on anyone's part. So register text/markdown. If we want a flavor parameter, I'd suggest = making it an informal list of comma-separated identifiers denoting = possible flavor candidates to use in order of preference: text/markdown; flavor=3D"Markdown Extra, MultiMarkdown, Maruku" Somewhat like the font-family directive in CSS, I think it'd work best = by not having a registry at all. If there is one, I'm pretty sure it's = going to be ignored by most users anyway. As for the "processor", "processor-arguments", and "output-type" = parameters, I don't think they have their place in a MIME type. --=20 Michel Fortin michel.fortin@michelf.ca http://michelf.ca From nobody Wed Sep 24 05:22:09 2014 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 D59C01A0033 for ; Wed, 24 Sep 2014 05:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPW7ynjxfgic for ; Wed, 24 Sep 2014 05:21:58 -0700 (PDT) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10531A000F for ; Wed, 24 Sep 2014 05:21:57 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id e89so5455623qgf.12 for ; Wed, 24 Sep 2014 05:21:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=ocwgnLV35QoVVb2n7W6y/fE82mwVwrcjqmCrjdgmNx8=; b=AwSWi3OMtpyLw+PgqwfhzuLXhqVTxyLc1p5kIHIWotVedhWNd6f6JMhDTQrAHL7iqq sBmOr8ASGpqJRrJm7M+jwH4riEDhc2iCxnlMrqv3CMg3sWkFP2102DZqWgvGS/QCR10j JSGYofZ/B9WhS4NGDcwHWA5Z7jP8LoiDruwWO9onh97CvCdyupeB/OESGHnfQcihkCpI QfwpqGHwBja8TejB1EJLEo054VCtj7EQv8+ojDiuCzl52x5dfjoyeUscNzA/K9bJkJil RfBraQlr6Xz0jWZzT5/DVEvNV0kgJKWfDkzs1iWwe2g8ziQ1996ghrLYRUrr9ztcR1gI ZkJA== X-Gm-Message-State: ALoCoQkUWImtUjyOottiIyGlW0qj39Snap7VA8KRmvTJhhBJZXZVWYPRgeGaoqYVE2tJyTNW6U50 X-Received: by 10.224.163.8 with SMTP id y8mr7304849qax.60.1411561316927; Wed, 24 Sep 2014 05:21:56 -0700 (PDT) Received: from minime.private ([76.73.248.16]) by mx.google.com with ESMTPSA id s8sm1478037qai.30.2014.09.24.05.21.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Sep 2014 05:21:56 -0700 (PDT) From: "Fletcher T. Penney" Content-Type: multipart/signed; boundary="Apple-Mail=_12E56101-B10A-43C3-BA4C-E838D37A99F2"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Wed, 24 Sep 2014 08:21:55 -0400 References: To: IETF Apps Discuss In-Reply-To: X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/vdzoTffo92l7IGZV09GW-IKwYIA Subject: Re: [apps-discuss] draft-ietf-appsawg-text-markdown-02 and the registry 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, 24 Sep 2014 12:22:05 -0000 --Apple-Mail=_12E56101-B10A-43C3-BA4C-E838D37A99F2 Content-Type: multipart/alternative; boundary="Apple-Mail=_B6DB0F4A-F918-403F-B9B2-17F490B169FC" --Apple-Mail=_B6DB0F4A-F918-403F-B9B2-17F490B169FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 24, 2014, at 8:09 AM, Michel Fortin = wrote: > There is a small subset of users who want a MIME type, but I'm going = to bet most Markdown implementers do not care at all. I, author of PHP = Markdown, personally don't really care much about this spec. (I'm in = fact currently having second thoughts about accepting to be a reviewer = given the complexity of the proposal makes things more bothersome than I = expected.) John Gruber doesn't care much either. I bet it's the case of = most implementers out there. ... > My suggestion is to find a way to make the type descriptive enough = without prescribing any action on anyone's part. >=20 > So register text/markdown. If we want a flavor parameter, I'd suggest = making it an informal list of comma-separated identifiers denoting = possible flavor candidates to use in order of preference: >=20 > text/markdown; flavor=3D"Markdown Extra, MultiMarkdown, Maruku" >=20 > Somewhat like the font-family directive in CSS, I think it'd work best = by not having a registry at all. If there is one, I'm pretty sure it's = going to be ignored by most users anyway. >=20 > As for the "processor", "processor-arguments", and "output-type" = parameters, I don't think they have their place in a MIME type. Agreed. I understand that this flies in the face of the OCD tendencies of many = of us to want something more precise, but I still believe this is an = area where precision is going to be wasted. FTP >=20 > --=20 > Michel Fortin > michel.fortin@michelf.ca > http://michelf.ca >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=20 Fletcher T. Penney fletcher@fletcherpenney.net=20 --Apple-Mail=_B6DB0F4A-F918-403F-B9B2-17F490B169FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Sep 24, 2014, at 8:09 AM, Michel = Fortin <michel.fortin@michelf.ca> = wrote:

<snipp'ed>

There = is a small subset of users who want a MIME type, but I'm going to bet = most Markdown implementers do not care at all. I, author of PHP = Markdown, personally don't really care much about this spec. (I'm in = fact currently having second thoughts about accepting to be a reviewer = given the complexity of the proposal makes things more bothersome than I = expected.) John Gruber doesn't care much either. I bet it's the case of = most implementers out = there.

...

My suggestion is to find a way to make the type = descriptive enough without prescribing any action on anyone's = part.

So register text/markdown. If we want a flavor parameter, = I'd suggest making it an informal list of comma-separated identifiers = denoting possible flavor candidates to use in order of = preference:

text/markdown; flavor=3D"Markdown = Extra, MultiMarkdown, Maruku"

Somewhat like the font-family = directive in CSS, I think it'd work best by not having a registry at = all. If there is one, I'm pretty sure it's going to be ignored by most = users anyway.

As for the "processor", "processor-arguments", and = "output-type" parameters, I don't think they have their place in a MIME = type.


Agreed.


I understand that this flies in the face = of the OCD tendencies of many of us to want something more precise, but = I still believe this is an area where precision is going to be = wasted.


FTP


--
Michel Fortin
michel.fortin@michelf.ca
h= ttp://michelf.ca

_______________________________________________apps-discuss mailing = list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/app= s-discuss

-- 
Flet= cher T. Penney

= --Apple-Mail=_B6DB0F4A-F918-403F-B9B2-17F490B169FC-- --Apple-Mail=_12E56101-B10A-43C3-BA4C-E838D37A99F2 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPOzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTgwggQgoAMC AQICEQDAX9LMQixpGwQOeQtHJ7TlMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTEwNDAwMDAwMFoXDTE0MTEwNDIzNTk1OVowLDEqMCgGCSqG SIb3DQEJARYbZmxldGNoZXJAZmxldGNoZXJwZW5uZXkubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAph1i3pN+Zt7You7JODIYgGIv82YJVkSxBp0i9zpw+IIADYI0grIW2G3lg/E9 i9MBwetn++K37I7Kt7SnYZcdrkZUBCwS3bDOobGlLXFTtcXJQI+GB1zPP1vM8kFilI3aZYdbCzgt cxW0WWwWxJ075nBvvHyBkLP2PWdzxSArKCpz5v79rDqdk0pTjuASGb2/VrSZ61BNxusaanmryDph Vcnnnkf+l9diwAW3NbC/99ApJTgqtrqnRs4Nene1w/+GXyeM72AmQPJT+coCyCC/0ss1Vu3j0BbC XaqsfTcVAuXOjbY6SM0aVwIbQ+g00v42zzj0GfaGLVg2OjlIpaww9QIDAQABo4IB6zCCAecwHwYD VR0jBBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFAyy5amhFrElryQn4HQCVgoU ozhZMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsr BgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEw KzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBM oEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25h bmRTZWN1cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8v Y3J0LmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWls Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEb ZmxldGNoZXJAZmxldGNoZXJwZW5uZXkubmV0MA0GCSqGSIb3DQEBBQUAA4IBAQAec1OL/CaNPcde mvbBBSRWg04qFvV/F4PNUNJgpKPu2z23U8FZJAn1RhCGb6dWYquCIDCCtyz5yP1Xdcv57dd9d/xR YJIPYK+iSSgB8xyVnraH5GfryRHx/5aIqIVSjZrrAhQAZ4Q8a16HuAkjYwmdKESn55eiYFUHioht 00xh4o6q0hPP24KfKPZLLN7jAeuqISR5bgrvsJGAjp4N9N0MbInDsZ5SEySKEB6RK3c9xd9f1bYV Xu+jhqV0GzIEbOWHiWGFvbQSqgK+6Az2eW0nSRZBanCEcb4NMhCF0kK7czCUo+YgNOQilx57gMwr OHtpBDRdKeXh2R4guFijK6e3MYIDrjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQI ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0ECEQDAX9LMQixpGwQOeQtHJ7TlMAkGBSsOAwIaBQCgggHZMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDkyNDEyMjE1NVowIwYJKoZIhvcNAQkE MRYEFFwtsJTKspxBMeeacJTOeJnob8+nMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDAX9LMQixpGwQOeQtHJ7TlMIG8BgsqhkiG9w0BCRAC CzGBrKCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9E TyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMBf0sxCLGkbBA55 C0cntOUwDQYJKoZIhvcNAQEBBQAEggEAZvEcrsZMkD8f5/67son0CkKwyObzpKvP3xWGcBW9tD+E aK0aKeSNxV5qgOpLO4fHW+KKCNljbDJtHG44thonAPNdamZgzFokfHQMbM3HeqxJISA/1RiI51RH MXMr3dZTZoM2t5nVT9uBAIYDOuhbA07QVSzAPEIW1Yt+pqpTiydxbu3Ravs8wFyXsSZKtRaAVyvC 7856N/6ltD/qsjmRLI0gNmkt/2xkrKK6w91FBcYMO68Xzf8QeO1wsqLzDtpX2qJyzELwUw9aAptJ 5ImcAczc+K6lnOhgwGR90XIwrnAZY0Su7zcJ52Aen+0mGFT3OeUZMQtlYGTDyFk7lPanpgAAAAAA AA== --Apple-Mail=_12E56101-B10A-43C3-BA4C-E838D37A99F2-- From nobody Wed Sep 24 06:23:08 2014 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 2740C1A0126 for ; Wed, 24 Sep 2014 06:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28hKqzLpDH3V for ; Wed, 24 Sep 2014 06:23:04 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DC91A0120 for ; Wed, 24 Sep 2014 06:23:04 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 346FEFA006D; Wed, 24 Sep 2014 13:23:00 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1411564979-20915-20914/12/237; Wed, 24 Sep 2014 13:22:59 +0000 From: Arnt Gulbrandsen To: IETF Apps Discuss Date: Wed, 24 Sep 2014 15:23:00 +0200 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.6; X11; Linux; Ubuntu 14.04.1 LTS Mime-Version: 1.0 Message-Id: <587301ed-384a-44e5-bd69-ff12abc3c4cc@gulbrandsen.priv.no> In-Reply-To: References: Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/NTeAPBDIUJ3Phgzo5DmceBClzj0 Subject: Re: [apps-discuss] draft-ietf-appsawg-text-markdown-02 and the registry 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, 24 Sep 2014 13:23:06 -0000 I don't see why this has to include much text at all. People do use MIME types, so registering one for such a widely used format makes sense. But why does it need to specify much? "Markdown is a family of mostly compatible formats, called flavours. This document does not define a canonical markdown. The flavour argument can be used to name the particular flavour, including..." and then list the flavours for which there is a convenient stable reference. "The flavour argument is optional. Note that some flavours are incompatible in minor ways." Registered and done. 95% of the benefit for 20% of the text. Arnt From nobody Wed Sep 24 07:47:56 2014 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 13EF81A010C for ; Wed, 24 Sep 2014 07:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 QaNgtdzqj78j for ; Wed, 24 Sep 2014 07:47:53 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B19D51A00BB for ; Wed, 24 Sep 2014 07:47:52 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8ABA5509B6 for ; Wed, 24 Sep 2014 10:47:51 -0400 (EDT) Message-ID: <5422D983.9090901@seantek.com> Date: Wed, 24 Sep 2014 07:47:31 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010909090706000302050605" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/tCrXHCSWDYqYhhVMpGTDHt3wdAI Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 14:47:55 -0000 This is a cryptographically signed message in MIME format. --------------ms010909090706000302050605 Content-Type: multipart/alternative; boundary="------------070900040806010103030303" This is a multi-part message in MIME format. --------------070900040806010103030303 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable [Note: this message was prerecorded last night.] On 9/23/2014 11:22 PM, Murray S. Kucherawy wrote: > 7) The "processor" tag makes me very nervous indeed. It seems to me=20 > anything you might say as part of the processor argument should be=20 > inferred from the value of the flavor argument, obviating the need for = > this. I would not expect security reviewers or consumers to tolerate=20 > the idea that the author of a MIME header field can tell a consumer=20 > what command to run and with what arguments. If that were the case,=20 > we had better be prepared to come up with a lot of text or ABNF that=20 > hardens this against command injection attacks. Actually I think that without a well-structured processor parameter (or=20 some equivalent), the security issues become much worse. Consider that in the current world of things, if an author wants someone = else to get the same output, the author is going to tell that person to=20 execute: =93pandoc -s -f markdown_strict+pandoc_title_block+tex_math_dollars -t=20 markdown_strict+mmd_title_block+tex_math_double_backslash=94, or say: =93here: just use this Makefile=94. That command line is real, by the way:=20 .=20 I didn=92t invent the media type parameters for the sake of complexity=97= I=20 was just reflecting what the Markdown community has already made. Someone elsewhere recently posted that what they really want is a=20 shebang #! on the first line of the Markdown, indicating the=20 command-line to execute. (Dennis E. Hamilton, see=20 .) Talk about a security nightmare! For trained users who =93know what they = are doing=94, it=92s no big deal. But Markdown is being used by users who= =20 don=92t know what they=92re doing=85and asking some user to =93run this=20 Makefile=94 is just about as good from a security standpoint as giving=20 them a loaded gun and saying =93point at foot=94. Think of the damage=20 someone can do by running an arbitrary batch script that they receive=20 from some random person or Internet site--particularly if they are being = spear-phished. I doubt that half of the folks on this list who use=20 Makefiles from other people go through the trouble to comb through every = line and look for hidden, malicious commands. (And even if you know what = a Makefile is, how do you know what all of the arbitrary command=20 programs are on your system, and how they might be invoked for=20 unpleasant purposes?) Maybe processor should go away=85it=92s a debate worth having (and is=20 actively being had), specifically to see if other parameters (namely the = flavor parameter or its successor) can satisfy the need. But I think=20 that kicking the security can down to some other part of the system will = make the security issues worse, rather than better. The purposes of having a controlled vocabulary for the processor=20 parameter are: 1. to promote interoperability, so that both the sender and receiver are going to get the same behavior; and 2. to provide security, by ensuring that arbitrary commands /can't/ be executed--the behaviors are circumscribed by the processor registry, and moreover, by the receiver's software making judgments about which processors are actually worth invoking. It is probably a failure of draft-02 that unregistered processor=20 identifiers are allowed. That, at least, should be reined in. Then=20 asking if the only processors are registered ones, (and flavors are=20 registered ones), can the flavors do the same work without putting=20 unrealistic burdens on the Markdown community. ("Unrealistic" of course=20 depends on one's perspective.) When I looked at the ways this could go down, I specifically looked at=20 the text/troff registration. In that registration, the problem is kicked = down the road because the process parameter is "human readable". So=20 basically the process parameter in text/troff amounts a glorified=20 comment. First: I doubt that much software is actually generating or=20 consuming these glorified comments (there is a Comment header anyway,=20 RFC 5322 Section 3.6.5). Second: these glorified comments aren't usable=20 by non-technical people, except as a loaded gun. -Sean --------------070900040806010103030303 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
[Note: this message was prerecorded last night.]

On 9/23/2014 11:22 PM, Murray S. Kucherawy wrote:
7) The "processor" tag makes me very nervous indeed.=A0 It seems to me anything you might say as part of the processor argument should be inferred from the value of the flavor argument, obviating the need for this.=A0 I would not expect security reviewers or consumers to tolerate the idea that the author of a MIME header field can tell a consumer what command to run and with what arguments.=A0 If that were the case,= we had better be prepared to come up with a lot of text or ABNF that hardens this against command injection attacks.
Actually I think that without a well-structured processor parameter (or some equivalent), the security issues become much worse.

Consider that in the current world of things, if an author wants someone else to get the same output, the author is going to tell that person to execute:
=93pandoc -s -f markdown_strict+pandoc_title_block+tex_math_dollars -t markdown_strict+mmd_title_block+tex_math_double_backslash=94,<= br> or say:
=93here: just use this Makefile=94.

That command line is real, by the way: <https://pairlist6.pair.net/pipermail/markdown-discuss/201= 4-July/003064.html>. I didn=92t invent the media type parameters for the sake of complexity=97I was just reflecting what the Markdown community has already made.

Someone elsewhere recently posted that what they really want is a shebang #! on the first line of the Markdown, indicating the command-line to execute. (Dennis E. Hamilton, see <https://pairlist6.pair.net/pipermail/markdown-discus= s/2014-September/003223.html>.)

Talk about a security nightmare! For trained users who =93know what they are doing=94, it=92s no big deal. But Markdown is being used by users who don=92t know what they=92re doing=85and asking some user to= =93run this Makefile=94 is just about as good from a security standpoint as giving them a loaded gun and saying =93point at foot=94. Think of the= damage someone can do by running an arbitrary batch script that they receive from some random person or Internet site--particularly if they are being spear-phished. I doubt that half of the folks on this list who use Makefiles from other people go through the trouble to comb through every line and look for hidden, malicious commands. (And even if you know what a Makefile is, how do you know what all of the arbitrary command programs are on your system, and how they might be invoked for unpleasant purposes?)

Maybe processor should go away=85it=92s a debate worth having (and is= actively being had), specifically to see if other parameters (namely the flavor parameter or its successor) can satisfy the need. But I think that kicking the security can down to some other part of the system will make the security issues worse, rather than better.

The purposes of having a controlled vocabulary for the processor parameter are:
  1. to promote interoperability, so that both the sender and receiver are going to get the same behavior; and
  2. to provide security, by ensuring that arbitrary commands can= 't be executed--the behaviors are circumscribed by the processor registry, and moreover, by the receiver's software making judgments about which processors are actually worth invoking.
It is probably a failure of draft-02 that unregistered processor identifiers are allowed. That, at least, should be reined in. Then asking if the only processors are registered ones, (and flavors are registered ones), can the flavors do the same work without putting unrealistic burdens on the Markdown community. ("Unrealistic" of course depends on one's perspective.)
When I looked at the ways this could go down, I specifically looked at the text/troff registration. In that registration, the problem is kicked down the road because the process parameter is "human readable". So basically the process parameter in text/troff amounts a glorified comment. First: I doubt that much software is actually generating or consuming these glorified comments (there is a Comment header anyway, RFC 5322 Section 3.6.5). Second: these glorified comments aren't usable by non-technical people, except as a loaded gun.

-Sean
--------------070900040806010103030303-- --------------ms010909090706000302050605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKTDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMx MTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkBFhRkZXYraWV0ZkBz ZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J9tKgDs1LQtaD c+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2guKi2R5xr f/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G53zv awQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia3 3JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaA FHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQ ME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcw AoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25h bmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMfWE2/5myX518DB+kTa5iQDbKYRuJp 3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmIH4kfI4LWrY8XrPhlX3JmHjD6 hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3jx9VF/gA3vqYpL+jNumI nz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d9ljRDEiAts5Oopke eFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYIEHDCCBBgCAQEw gakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggJHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE0MDkyNDE0NDczMVowIwYJKoZIhvcNAQkEMRYEFC0LnWrBLOgRRHhY ugtal+FZbeG2MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNV BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09N T0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwgbwGCyqGSIb3DQEJEAIL MYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMw Q09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAypM8 MbupbqbMkL4Skr0HfDANBgkqhkiG9w0BAQEFAASCAQAFu90zFbO1ppK3XUjbmHIS7B3ECSmU hZOXJttEBN/KkuEoP0T2a2MYdAeT8T8wROICzya8+5RCGpjJzgTjmEDM/zwVD7uOsYW6in/p xKEp24rfrA2Tf5dtnp4jHWxJzOkDtTsKY74X6ob11ObEiKIL42IeqJa+lowCch/4ajmpQD+z VJfUPsY7yb6fC93UJu8X3EyfBh8K/gxCCqpd3jQIB8bPmAcoAnzkFpCSEWNM6oQiqD2AVTsq FakyXWnavisGdTNE4vc6ftn6oBaZPqTq0iuVmn0ru6nxXpHTtQ7D9c/uFG8oQEZ7CCT/9XNe eL2xXw/JFayXRKwsYYI1LFgwAAAAAAAA --------------ms010909090706000302050605-- From nobody Wed Sep 24 08:02:58 2014 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 0ACED1A00E0 for ; Wed, 24 Sep 2014 08:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, 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 xIoSzX4Gs3v5 for ; Wed, 24 Sep 2014 08:02:55 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7F34B1A00DC for ; Wed, 24 Sep 2014 08:02:55 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PCYDENHQ5C004IQ9@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 24 Sep 2014 07:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1411570673; bh=IgsJ5dr8kJ5qxgVeyxvA4OHCNxddcYqa6E7LPQWNam8=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=fB5K+OlSF70p/wn/CdQ0KBhuqUsFeqD4BD7N9hwjx29Jwjr1XV3cbBASMOnGz6zAR iCfYZTEOzwzMJ+R4YJBm/HQhXZ8HMJmOXjI9/I4tfyMTJbHrOao4di0FnjeSx/bAoE ptVIqWixCz45pYuWCQOKbtypNCIAvcKguuEUKhCw= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PCVRX4M2N40000SM@mauve.mrochek.com>; Wed, 24 Sep 2014 07:57:50 -0700 (PDT) Message-id: <01PCYDELVGXO0000SM@mauve.mrochek.com> Date: Wed, 24 Sep 2014 07:57:29 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 24 Sep 2014 15:23:00 +0200" <587301ed-384a-44e5-bd69-ff12abc3c4cc@gulbrandsen.priv.no> References: <587301ed-384a-44e5-bd69-ff12abc3c4cc@gulbrandsen.priv.no> To: Arnt Gulbrandsen Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/EK8vvOOs_bP_8qPv-8iOQmu3CLQ Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-text-markdown-02 and the registry 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, 24 Sep 2014 15:02:57 -0000 > I don't see why this has to include much text at all. > People do use MIME types, so registering one for such a widely used format > makes sense. But why does it need to specify much? > "Markdown is a family of mostly compatible formats, called flavours. This > document does not define a canonical markdown. The flavour argument can be > used to name the particular flavour, including..." and then list the > flavours for which there is a convenient stable reference. "The flavour > argument is optional. Note that some flavours are incompatible in minor > ways." Registered and done. 95% of the benefit for 20% of the text. +1. Sometimes less is more. Ned From nobody Wed Sep 24 08:08:27 2014 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 61B681A0173 for ; Wed, 24 Sep 2014 08:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwx0sYaSst7P for ; Wed, 24 Sep 2014 08:08:16 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0F81A0179 for ; Wed, 24 Sep 2014 08:08:14 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id m8so6586958obr.6 for ; Wed, 24 Sep 2014 08:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u9sBh5ttx6/Ur5sKZi+7hwTI8nvcToDkCi5Pyrj3U+4=; b=TfhNytS92gTJxiVvEtG5T5U3gQ8D3v/nGpjvBbLm6az1in+004pWWHH+eLBNHJedZD 2gs+OPwNOAkN7lKkOe66RJdZOGV9bbjmD8vnId0onK3eItiDSledlOl4UGTiKCD5quLO YvRViHmw7+GwDy5QqOjk0V9OqhsSJNKfO+k8w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=u9sBh5ttx6/Ur5sKZi+7hwTI8nvcToDkCi5Pyrj3U+4=; b=ex3wwiFDiH1GAdLSVysx4Q+TnlZ7UKe0sMXFJQyuFp8LtjU8Edz/2IKYrIHvt+P+y6 WElNbGjEMOEQ3Wiuhsiw64oiqfhLcF5RbuHydO8t43SpUkvaJfv/EO33pwHmJyos2bs9 OAdoNwV+qmVRM4o9HzzCAgMxgTdSIcpmJ/v6epVIGG8pul7nPLKzgNWGREOaUphdMN3M lCkJIS5V2c+CUozF8l18N9hKk8LymdSFAspGn5htn4kvGY4/5pVwjOZ9jf74ur8j0Mvv zrW05btOZp/t8GCCFGnoCY6FnHdXOTQgoi4yjXVqCthM7crK+qnjF++EywylI4h/Bk6+ Jo6Q== X-Gm-Message-State: ALoCoQlgOQfV27T7OhktDMaGkbx8cC0+ggJ3Rf+lxN+2ZjMhFrpcPx3/bHs9+D6g4Dsi0kMd2BYu MIME-Version: 1.0 X-Received: by 10.182.20.242 with SMTP id q18mr7571041obe.52.1411571294060; Wed, 24 Sep 2014 08:08:14 -0700 (PDT) Received: by 10.60.150.238 with HTTP; Wed, 24 Sep 2014 08:08:14 -0700 (PDT) In-Reply-To: <587301ed-384a-44e5-bd69-ff12abc3c4cc@gulbrandsen.priv.no> References: <587301ed-384a-44e5-bd69-ff12abc3c4cc@gulbrandsen.priv.no> Date: Wed, 24 Sep 2014 16:08:14 +0100 Message-ID: From: Dave Cridland To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=e89a8f83a8838edae20503d10da4 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/EXkSwvrGqXXcXmjBKYEFzRvLPUw Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-text-markdown-02 and the registry 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, 24 Sep 2014 15:08:17 -0000 --e89a8f83a8838edae20503d10da4 Content-Type: text/plain; charset=UTF-8 On 24 September 2014 14:23, Arnt Gulbrandsen wrote: > I don't see why this has to include much text at all. > > People do use MIME types, so registering one for such a widely used format > makes sense. But why does it need to specify much? > > "Markdown is a family of mostly compatible formats, called flavours. This > document does not define a canonical markdown. The flavour argument can be > used to name the particular flavour, including..." and then list the > flavours for which there is a convenient stable reference. "The flavour > argument is optional. Note that some flavours are incompatible in minor > ways." Registered and done. 95% of the benefit for 20% of the text. I'm in agreement, with the additional note that if anyone tries to include arbitrary command line arguments in the parameters of a media type I may have to just send them mail saying the processor is "rf -rf /". Dave. --e89a8f83a8838edae20503d10da4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 2= 4 September 2014 14:23, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no<= /a>> wrote:
I don't see why= this has to include much text at all.

People do use MIME types, so registering one for such a widely used format = makes sense. But why does it need to specify much?

"Markdown is a family of mostly compatible formats, called flavours. T= his document does not define a canonical markdown. The flavour argument can= be used to name the particular flavour, including..." and then list t= he flavours for which there is a convenient stable reference. "The fla= vour argument is optional. Note that some flavours are incompatible in mino= r ways." Registered and done. 95% of the benefit for 20% of the text.<= /blockquote>

I'm in agreement, with the additional n= ote that if anyone tries to include arbitrary command line arguments in the= parameters of a media type I may have to just send them mail saying the pr= ocessor is "rf -rf /".

Dave.
=
--e89a8f83a8838edae20503d10da4-- From nobody Wed Sep 24 09:29:15 2014 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 5BB841A010E for ; Wed, 24 Sep 2014 09:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdHI2djTe_j7 for ; Wed, 24 Sep 2014 09:29:12 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B8861A01DD for ; Wed, 24 Sep 2014 09:28:24 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8OGSIq9018354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 24 Sep 2014 09:28:21 -0700 Message-ID: <5422F11A.9010408@dcrocker.net> Date: Wed, 24 Sep 2014 09:28:10 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ned Freed , Arnt Gulbrandsen References: <587301ed-384a-44e5-bd69-ff12abc3c4cc@gulbrandsen.priv.no> <01PCYDELVGXO0000SM@mauve.mrochek.com> In-Reply-To: <01PCYDELVGXO0000SM@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 24 Sep 2014 09:28:21 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/TQCDFFDJxRl8wZB_GBLmwwj8rJo Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-text-markdown-02 and the registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 16:29:13 -0000 On 9/24/2014 7:57 AM, Ned Freed wrote: >> I don't see why this has to include much text at all. > >> People do use MIME types, so registering one for such a widely used >> format >> makes sense. But why does it need to specify much? > >> "Markdown is a family of mostly compatible formats, called flavours. This >> document does not define a canonical markdown. The flavour argument >> can be >> used to name the particular flavour, including..." and then list the >> flavours for which there is a convenient stable reference. "The flavour >> argument is optional. Note that some flavours are incompatible in minor >> ways." Registered and done. 95% of the benefit for 20% of the text. > > +1. Sometimes less is more. In order to avoid an inherently contentious point, I suggest: mostly compatible -> related "Mostly compatible" also means "incompatible". (In the early days of Internet commercialization, vendors wishing to continue to sell proprietary solutions -- since those have higher profit margins -- would have data sheets that described their products as "based on open standards". "Based on" was a code phrase for "non-interoperable". The product only worked with products from that vendor...) Rather than invoke any of the compatibility issue, the suggested word change provides what's needed and not more. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Sep 24 10:20:34 2014 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 613FC1A026C for ; Wed, 24 Sep 2014 10:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 jBSQy6y9ePXt for ; Wed, 24 Sep 2014 10:20:26 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0694.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::694]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C2FB1A026A for ; Wed, 24 Sep 2014 10:20:26 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB308.namprd02.prod.outlook.com (10.141.91.24) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Wed, 24 Sep 2014 17:20:02 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.1034.003; Wed, 24 Sep 2014 17:20:02 +0000 From: Larry Masinter To: Apps Discuss Thread-Topic: [apps-discuss] IRC URIs to denote users Thread-Index: AQHP1qb5NgGyUAMMWUSAUP3eEhjQWpwN0SmAgADL8wCAADUzgIAAAjOAgAG01NA= Date: Wed, 24 Sep 2014 17:20:02 +0000 Message-ID: <109c98d4059d4c6c88eb0556a25f569d@BL2PR02MB307.namprd02.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2601:9:8380:992:15e2:cd18:cf28:40b9] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR02MB308; x-forefront-prvs: 03449D5DD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(189002)(199003)(108616004)(77982003)(46102003)(85306004)(15202345003)(76482002)(85852003)(15975445006)(106116001)(101416001)(74316001)(20776003)(105586002)(21056001)(106356001)(83072002)(16236675004)(90102001)(19617315012)(16601075003)(31966008)(93886004)(99396003)(120916001)(107886001)(110136001)(87936001)(76576001)(107046002)(2656002)(558084003)(86362001)(74502003)(4396001)(97736003)(79102003)(64706001)(19580395003)(95666004)(33646002)(83322001)(99286002)(92566001)(54356999)(76176999)(74662003)(19300405004)(81542003)(50986999)(10300001)(81342003)(19625215002)(80022003)(3826002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR02MB308; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_109c98d4059d4c6c88eb0556a25f569dBL2PR02MB307namprd02pro_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/oAq9u7k3_U6_8GwKftr_LqAXt-w Subject: Re: [apps-discuss] IRC URIs to denote users 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, 24 Sep 2014 17:20:28 -0000 --_000_109c98d4059d4c6c88eb0556a25f569dBL2PR02MB307namprd02pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEFueSBwb2ludGVycyDigKYNCg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1hcHBzYXdnLXVyaS1zY2hlbWUtcmVnLTAyI3NlY3Rpb24tMy4yDQoiLi4uZG91Ymxl IHNsYXNoZXMgaW4gdGhlIGZpcnN0IHBhcnQgb2YgYSBVUkkgaXMgbm90IGEgc3R5bGlzdGljIGlu ZGljYXRvciAuLi4uIg0KDQoNCkxhcnJ5DQotLQ0KaHR0cDovL2xhcnJ5Lm1hc2ludGVyLm5ldA0K DQo= --_000_109c98d4059d4c6c88eb0556a25f569dBL2PR02MB307namprd02pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5N c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEwNDU1NjU5MDc7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEyMDM3Njg0MzAg LTE2NzIwNjg5MzYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZl bC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFueSBwb2ludGVycyDigKY8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFwcHNhd2ctdXJpLXNj aGVtZS1yZWctMDIjc2VjdGlvbi0zLjIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWFwcHNhd2ctdXJpLXNjaGVtZS1yZWctMDIjc2VjdGlvbi0zLjI8L2E+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMyOTJGMzM7YmFja2dyb3VuZDojRkNGQ0ZDIj4mcXVvdDsuLi5kb3VibGUgc2xhc2hlcyBp biB0aGUgZmlyc3QgcGFydCBvZiBhIFVSSSBpcyBub3QgYSBzdHlsaXN0aWMgaW5kaWNhdG9yIC4u Li4mcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxhcnJ5PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPmh0dHA6Ly9sYXJyeS5tYXNpbnRlci5uZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_109c98d4059d4c6c88eb0556a25f569dBL2PR02MB307namprd02pro_-- From nobody Wed Sep 24 10:28:07 2014 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 85EFC1A02C0 for ; Wed, 24 Sep 2014 10:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylKiR7tyXHUg for ; Wed, 24 Sep 2014 10:27:58 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F6D71A02BC for ; Wed, 24 Sep 2014 10:27:58 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id u57so5682565wes.6 for ; Wed, 24 Sep 2014 10:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M/RZlPBkqOY4SC1gRhDYnG1nQOPX5beW/lPruV/o5IU=; b=shTwtaeYkf88nkOx70r3woWlTVwRefAm7TQiqO9vLMjR+UGgNXueWKwJFsDybmgyzb 882sAPxvUC9i5Hu2R4or20L0yn87Sfn1kD7P2CMgHFhHxCjK9aLkmiaY0FUFsKQnDvNm WLujNGW9sDRrIh0vuZSwt7y2HDxhm3ny1aGBDhu1Icf6borWyXbCBG4IGi0EYOTSbUd0 dCXvHgLthkYeH/U0AYai1gZYyqYo7Bv3GUDvj9kN53bc5oAwxRjxmCxzUmdjKK5lQ/hl XS4Qrt+uoaRS7Ietuvx9rchGQ9xXMvWOTt3EhoWL1Q0rmuT7KsGrnXW9NgbMYdvT7Rz1 GXVA== MIME-Version: 1.0 X-Received: by 10.194.79.35 with SMTP id g3mr9787935wjx.110.1411579677044; Wed, 24 Sep 2014 10:27:57 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Wed, 24 Sep 2014 10:27:56 -0700 (PDT) In-Reply-To: <5422D983.9090901@seantek.com> References: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> <5422D983.9090901@seantek.com> Date: Wed, 24 Sep 2014 10:27:56 -0700 Message-ID: From: "Murray S. Kucherawy" To: Sean Leonard Content-Type: multipart/alternative; boundary=047d7bf0c59a38f8ab0503d301ce Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Bs61ymx_4GTLhVc2OWIGRjrNtbI Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 17:28:01 -0000 --047d7bf0c59a38f8ab0503d301ce Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Sep 24, 2014 at 7:47 AM, Sean Leonard wrote: > [Note: this message was prerecorded last night.] > > On 9/23/2014 11:22 PM, Murray S. Kucherawy wrote: > > 7) The "processor" tag makes me very nervous indeed. It seems to me > anything you might say as part of the processor argument should be inferr= ed > from the value of the flavor argument, obviating the need for this. I > would not expect security reviewers or consumers to tolerate the idea tha= t > the author of a MIME header field can tell a consumer what command to run > and with what arguments. If that were the case, we had better be prepare= d > to come up with a lot of text or ABNF that hardens this against command > injection attacks. > > Actually I think that without a well-structured processor parameter (or > some equivalent), the security issues become much worse. > > Consider that in the current world of things, if an author wants someone > else to get the same output, the author is going to tell that person to > execute: > =E2=80=9Cpandoc -s -f markdown_strict+pandoc_title_block+tex_math_dollars= -t > markdown_strict+mmd_title_block+tex_math_double_backslash=E2=80=9D, > or say: > =E2=80=9Chere: just use this Makefile=E2=80=9D. > I don't believe using a registry to constrain possible processors and all of their various parameter combinations is practical. At a minimum it puts a burden on the Designated Expert to validate all of them, and on consumers to ensure they always have the latest dump of the registry. Among other things, the registration can't accommodate substitution parameters; what if, for example, the filename is supposed to be passed as a command line parameter? And what about ordering of the parameters? You could say order doesn't matter, but note that at least for "-f" and "-t" above, they have to at least be paired with their corresponding values. What about arguments that can repeat? All of that needs to appear in the registry if you really intend it to reflect a comprehensive list of what's allowed. I don't think we should have registry rules that amount to the man page for getopt(). What if there are two different processors that handle a particular markdown flavor identically, the message demands use of one of them, and I have the other one installed? What about the case where a critical security flaw is identified in a processor mandating release of a new version, or an entry is found to be seriously incorrect? Isn't there now a scramble to update the registry in some way? What if the DE isn't available for some period? To me, the complexity this introduces far outweighs the defenses you're trying to erect. I envision something more like Apache's handler construct, where there's a table mapping filename extensions to the module that knows how to parse them. These are not maintained in a registry, but are rather enumerated locally and map to the handlers available. For text/markdown, you would have something like a table mapping flavors and maybe some options over to the locally-available processor and whatever options you want to use for that flavor. There's some default you use for flavors you've never heard of. As you find out about new flavors and their processors, you install the processors and add them to the table accordingly. > Maybe processor should go away=E2=80=A6it=E2=80=99s a debate worth having= (and is actively > being had), specifically to see if other parameters (namely the flavor > parameter or its successor) can satisfy the need. But I think that kickin= g > the security can down to some other part of the system will make the > security issues worse, rather than better. > I don't believe the idea is to punt on security. I do believe the idea is to avoid unnecessary complexity, which by itself can introduce all kinds of security and interoperability problems. > > 1. > > When I looked at the ways this could go down, I specifically looked at th= e > text/troff registration. In that registration, the problem is kicked down > the road because the process parameter is "human readable". So basically > the process parameter in text/troff amounts a glorified comment. First: I > doubt that much software is actually generating or consuming these > glorified comments (there is a Comment header anyway, RFC 5322 Section > 3.6.5). Second: these glorified comments aren't usable by non-technical > people, except as a loaded gun. > I think text/troff (RFC4263 for those that want to look) skates through by saying the processor and version parameters are advisory text and not to be executed, because in fact they could be prose. Here, you're saying they are "the" commands that have to be used to render the intended content. The text/troff approach seems a lot more palatable to me. I'd be curious to hear about anyone that's implemented text/troff and encountered this. -MSK --047d7bf0c59a38f8ab0503d301ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 24, 2014 at 7:47 AM, Sean Leonard <dev+iet= f@seantek.com> wrote:
=20 =20 =20
[Note: this message was prerecorded last night.]

On 9/23/2014 11:22 PM, Murray S. Kucherawy wrote:
7) The "processor" tag makes me very nervo= us indeed.=C2=A0 It seems to me anything you might say as part of the processor argument should be inferred from the value of the flavor argument, obviating the need for this.=C2=A0 I would not expect security reviewers or consumers to tolerate the idea that the author of a MIME header field can tell a consumer what command to run and with what arguments.=C2=A0 If that were the case= , we had better be prepared to come up with a lot of text or ABNF that hardens this against command injection attacks.
 Actually I think that without a well-structured processor parameter (or some equivalent), the security issues become much worse.

Consider that in the current world of things, if an author wants someone else to get the same output, the author is going to tell that person to execute:
=E2=80=9Cpandoc -s -f markdown_strict+pandoc_title_block+tex_math_dollars -t markdown_strict+mmd_title_block+tex_math_double_backslash=E2=80= =9D,
or say:
=E2=80=9Chere: just use this Makefile=E2=80=9D.
<= div>
I don't believe using a registry to constrain possible pr= ocessors and all of their various parameter combinations is practical.=C2= =A0 At a minimum it puts a burden on the Designated Expert to validate all = of them, and on consumers to ensure they always have the latest dump of the= registry.=C2=A0 Among other things, the registration can't accommodate= substitution parameters; what if, for example, the filename is supposed to= be passed as a command line parameter?=C2=A0 And what about ordering of th= e parameters?=C2=A0 You could say order doesn't matter, but note that a= t least for "-f" and "-t" above, they have to at least = be paired with their corresponding values.=C2=A0 What about arguments that = can repeat?=C2=A0 All of that needs to appear in the registry if you really= intend it to reflect a comprehensive list of what's allowed.=C2=A0 I d= on't think we should have registry rules that amount to the man page fo= r getopt().

What if there are two d= ifferent processors that handle a particular markdown flavor identically, t= he message demands use of one of them, and I have the other one installed?<= br>

Wh= at about the case where a critical security flaw is identified in a process= or mandating release of a new version, or an entry is found to be seriously= incorrect?=C2=A0 Isn't there now a scramble to update the registry in = some way?=C2=A0 What if the DE isn't available for some period?

To me, th= e complexity this introduces far outweighs the defenses you're trying t= o erect.

I envision something more = like Apache's handler construct, where there's a table mapping file= name extensions to the module that knows how to parse them.=C2=A0 These are= not maintained in a registry, but are rather enumerated locally and map to= the handlers available.=C2=A0 For text/markdown, you would have something = like a table mapping flavors and maybe some options over to the locally-ava= ilable processor and whatever options you want to use for that flavor.=C2= =A0 There's some default you use for flavors you've never heard of.= =C2=A0 As you find out about new flavors and their processors, you install = the processors and add them to the table accordingly.
=C2=A0
Maybe processor should go away=E2=80=A6it=E2=80=99s a debate worth havi= ng (and is actively being had), specifically to see if other parameters (namely the flavor parameter or its successor) can satisfy the need. But I think that kicking the security can down to some other part of the system will make the security issues worse, rather than better.

I don't believe the idea is to punt = on security.=C2=A0 I do believe the idea is to avoid unnecessary complexity= , which by itself can introduce all kinds of security and interoperability = problems.
=20 When I looked at the ways this could go down, I specifically looked at the text/troff registration. In that registration, the problem is kicked down the road because the process parameter is "human readable". So basically the process parameter in text/troff amount= s a glorified comment. First: I doubt that much software is actually generating or consuming these glorified comments (there is a Comment header anyway, RFC 5322 Section 3.6.5). Second: these glorified comments aren't usable by non-technical people, except as a loaded gun.
=

I think text/troff (RFC4263 for those that= want to look) skates through by saying the processor and version parameter= s are advisory text and not to be executed, because in fact they could be p= rose.=C2=A0 Here, you're saying they are "the" commands that = have to be used to render the intended content.=C2=A0 The text/troff approa= ch seems a lot more palatable to me.

I'd be curious to hear abou= t anyone that's implemented text/troff and encountered this.

-MSK
--047d7bf0c59a38f8ab0503d301ce-- From nobody Wed Sep 24 10:51:06 2014 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 361471A02BD for ; Wed, 24 Sep 2014 10:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRLFSw9_SsdU for ; Wed, 24 Sep 2014 10:50:58 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 610A71A0127 for ; Wed, 24 Sep 2014 10:50:58 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id fb4so6940883wid.3 for ; Wed, 24 Sep 2014 10:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Hue56mswrgYMmyj3WbUK4l5YMSlztE46cuFq9mI57Vg=; b=YVe9ERI58zu74P2zSjZ5BV6s2pYQ2H2n90EVHCqpWCjN+TfCJHEzebKKp+NLXglXCZ sOQukUWedEqUQWzUJfAtJUQ1brYC+2zgUMuyAMJ/vy/7sOllNqQIKuqGxWPQFAAeCej6 RODYxJ4RXUgbecUbaktl/QVPoZP0l+K9xvJ+IbeiICOgRSrsit2lKlunfcUc13weNPIn EkQ+e+d3CJBVM1y21dtwCTiWuVe1Vr4nXTWhwjLsvMWUborsKE/iCLzxFn4xriKxq8uU TB/abzsJOZ/AONS7+cA3zlYAl3TIaD5ExGkvTy5BvKIGibPkgusZHXEUF3scXjVhv0+4 SgXA== MIME-Version: 1.0 X-Received: by 10.180.184.20 with SMTP id eq20mr32625437wic.61.1411581056972; Wed, 24 Sep 2014 10:50:56 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Wed, 24 Sep 2014 10:50:56 -0700 (PDT) In-Reply-To: <542272C2.8030305@seantek.com> References: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> <542272C2.8030305@seantek.com> Date: Wed, 24 Sep 2014 10:50:56 -0700 Message-ID: From: "Murray S. Kucherawy" To: Sean Leonard Content-Type: multipart/alternative; boundary=001a11c3536a78fe040503d3533d Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/d1RCWAGC47FCLDg725kkdz_dID4 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 17:51:02 -0000 --001a11c3536a78fe040503d3533d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Sep 24, 2014 at 12:29 AM, Sean Leonard wrote= : > > > 4) What is now Section 2 should go after what is now Section 4. > > > Originally I put the example at the end, but for draft-02 I felt like it > should be at the beginning. Especially given the lack of a *formal* > specification, I wanted to be clear with an example up-front. It can go > back, though. > It just seems strange to say "Here's what I'm trying to build, now here are all the pieces", versus "Here are the pieces, and here's how you would use them." The latter is much more common, except maybe on a box of Lego. :-) > > > 5) I'm not sure that I agree the charset should be mandatory. It seems > to go against what I'm reading in RFC2046 Section 4.1 to not have > "us-ascii" as a default since this is a subtype of the "text" media type. > Why should this be different from how other text/* types do it? > > > See RFC 6657 (whole thing) and RFC 6838 Section 4.2.1. > Ah right, I'd forgotten about that work. Disregard. > > > 6) The "flavor" tag itself seems to be a debatable point. I don't have > an opinion on that yet (more discussion, please), but as defined the name > is case-sensitive. Is that what we want? And does it need to be able to > contain spaces or special characters such that it will need to be quoted? > > > There are a few reasons for the case-sensitivity of the name. First, the > parameter value can be any Unicode string. The purpose was to enable > flavors (variants) to be named things in languages other than English. Se= e > BCP 18 Section 2, "Where to do internationalization". Right now most > examples of Markdown-related flavors are in English, but it is perfectly > conceivable that someone can write some Markdown variant in some other > script. Actually, Markdown itself is starting to be iconized as M=E2=86= =93 by the > community. > > Over the last couple of years, I have become very suspicious about > case-insensitivity and its interactions with Unicode. It's one thing to m= ap > the US-ASCII characters U+0041-U+005A (uppercase) to U+0061-U+007A; it's > another thing to require huge tables of mappings for all sorts of scripts > out there. See > > > for the case folding algorithm. Note that Unicode defines three cases: > uppercase, lowercase, and title case. Too. Much. Detail. > > BCP 18 frames the problem and states specifically that: > "Names are a problem, because people feel strongly about them, many of > them are mostly for local usage, and all of them tend to leak out of the > local context at times. RFC 1958 > recommends US-ASCII for all globally visible names. This document does no= t > mandate a policy on name internationalization, but requires that all > protocols describe whether names are internationalized or US-ASCII." > > The compromise position I reached was that you can use Unicode, but you > SHOULD use US-ASCII. And since I wanted to obviate the case-folding issue= , > I said case-sensitive. > OK, you said "internationalization" and that makes me cringe and back away. I'll yield to consensus here until I'm more of an expert on that topic. On the other hand, you say that the handling is case-sensitive yet you direct the Designated Expert not to allow new names that differ from registered names only by case. I'm left wondering if the latter really matters. > As a bonus: John Gruber is extremely sensitive to capitalization of > "Markdown". > I could be convinced that this is fine in prose, but when we get to talking about tokenizing a string for processing by a program, I'm less sure it should matter. > > 7) The "processor" tag makes me very nervous indeed. It seems to me > anything you might say as part of the processor argument should be inferr= ed > from the value of the flavor argument, obviating the need for this. I > would not expect security reviewers or consumers to tolerate the idea tha= t > the author of a MIME header field can tell a consumer what command to run > and with what arguments. If that were the case, we had better be prepare= d > to come up with a lot of text or ABNF that hardens this against command > injection attacks. > > > I think the security risk is significantly mitigated (perhaps even > eliminated) by registration. Will write in separate e-mail. > Replied separately as well. > > > 8) I'm unclear on what the "output-type" tag is for. Isn't the output > format a function of the context in which the MIME part is being > processed? For example, if I get this in a piece of email, wouldn't the > markdown processor output in HTML if I'm using an HTML-enabled MUA, or in > text otherwise? > > > First, thanks for the open discussion of output-type. I think the text > spells it out. text/html is what most people think of...but text/html is > not the way that Markdown is going. Markdown is slowly encroaching upon > every other format, because other formats are "too complicated". > > The use case of an e-mail client showing the HTML output of Markdown > inline, is not realistic. As someone else noted earlier, if you write an > e-mail in Markdown and want the recipient to see formatted text, the > expectation is that the sending mail client will do the formatting, so in > an e-mail, the received data will be text/html. > Email clients are not the only common consumers of media types. What about a web browser? Here, too, the output format is implicit from the environment. > Probably a better scenario (which is becoming a significant use case) is > authors collaborating on a document. The authors on disparate machines > *both* want to see the source, *and* the output, preferably at the same > time. Maybe one collaborator is the author and the other is an editor or > reviewer. > Why does the media type need to indicate to both authors what the output format is when they presumably already know that? Or wouldn't it be implicit in whatever editing environment they're using? Is it safe to assume they're always the same? > > 11) For the flavor parameter, I'm not clear on why it's a mandatory > value that has a default. > > > It's optional. > > The text does say "Generators MUST NOT emit empty flavor parameters"...bu= t > then it proceeds, "but parsers MUST treat empty flavor parameters the sam= e > as if omitted." The whole parameter is optional. The point is that there = is > a syntactic difference between: > text/markdown; flavor=3D"" > and > text/markdown > > but there is no semantic difference--they mean the same thing. > OK. However, the ABNF doesn't allow empty values in the first place, so I don't think this needs to be said at all. An empty flavor value is already a syntax error. > > > 12) The requirement to register tools that implement given flavors is > unusual. What's the impetus here? > > Section 5.1.1.: > "The purpose of the tool requirement is to ensure that the flavor is > actually used in practice." > > Due to the proliferation of processors, there have been very many calls i= n > the Markdown community to have "one true formalized syntax". So that mean= s > that now there is a proliferation of syntax specifications--several of > which are not representative of any implementation at all! > This is covered separately as well. > > 15) RFC1738 is obsoleted by RFCs 4248 and 4266. > > > RFC 1738 is the latest reference for file:/// URLs. > Actually you're right, it's listed as authoritative for "file" in the IANA URI scheme registry, even though it shows it's obsoleted. That should probably get fixed (but not by this document, obviously). -MSK --001a11c3536a78fe040503d3533d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 24, 2014 at 12:29 AM, Sean Leonard <dev+= ietf@seantek.com> wrote:
=20 =20 =20


4) What is now Section 2 should go after what is now Section 4.

 Originally I put the example at the end, but for draft-02 I felt like it should be at the beginning. Especially given the lack of a *formal* specification, I wanted to be clear with an example up-front. It can go back, though.

It just seems strange to say "Here's = what I'm trying to build, now here are all the pieces", versus &qu= ot;Here are the pieces, and here's how you would use them."=C2=A0 = The latter is much more common, except maybe on a box of Lego.=C2=A0 :-)=C2=A0


5) I'm not sure that I agree the charset should be mandatory.=C2=A0 It seems to go against what I'm reading = in RFC2046 Section 4.1 to not have "us-ascii" as a def= ault since this is a subtype of the "text" media type.= =C2=A0 Why should this be different from how other text/* types do it?

 See RFC 6657 (whole thing) and RFC 6838 Section 4.2.1.=

Ah right, I'd forgott= en about that work.=C2=A0 Disregard.
=C2=A0


6) The "flavor" tag itself seems to be a debatab= le point.=C2=A0 I don't have an opinion on that yet (more discussion, please), but as defined the name is case-sensitive.=C2=A0 Is that what we want?=C2=A0 And does it= need to be able to contain spaces or special characters such that it will need to be quoted?

 There are a few reasons for the case-sensitivity of the name. First, the parameter value can be any Unicode string. The purpose was to enable flavors (variants) to be named things in languages other than English. See BCP 18 Section 2, "Where to do internationalization&q= uot;. Right now most examples of Markdown-related flavors are in English, but it is perfectly conceivable that someone can write some Markdown variant in some other script. Actually, Markdown itself is starting to be iconized as M=E2=86=93 by the community.

Over the last couple of years, I have become very suspicious about case-insensitivity and its interactions with Unicode. It's one thin= g to map the US-ASCII characters U+0041-U+005A (uppercase) to U+0061-U+007A; it's another thing to require huge tables of mapping= s for all sorts of scripts out there. See <http://en.wikipedia.org/= wiki/Letter_case#Unicode_case_folding_and_script_identification> for the case folding algorithm. Note that Unicode defines three cases: uppercase, lowercase, and title case. Too. Much. Detail.

BCP 18 frames the problem and states specifically that:
"Names are a problem, because people feel strongly about them, many of them are mostly for local usage, and all of them tend to leak out of the local context at times. RFC 1958 recommends US-ASCII for all globally visible names. This document does not mandate a policy on name internationalization, but requires that all protocols describe whether names are internationalized or US-ASCII."

The compromise position I reached was that you can use Unicode, but you SHOULD use US-ASCII. And since I wanted to obviate the case-folding issue, I said case-sensitive.
<= br>
OK, you said "internationalization" and that makes = me cringe and back away.=C2=A0 I'll yield to consensus here until I'= ;m more of an expert on that topic.

On the other hand, yo= u say that the handling is case-sensitive yet you direct the Designated Exp= ert not to allow new names that differ from registered names only by case.= =C2=A0 I'm left wondering if the latter really matters.
= =C2=A0
As a bonus: John Gruber is extremely sensitive to capitalization of "Markdown".

I could be convinced that this is fine in prose, but when = we get to talking about tokenizing a string for processing by a program, I&= #39;m less sure it should matter.



7) The "processor" tag makes me very nervous ind= eed.=C2=A0 It seems to me anything you might say as part of the processor argument should be inferred from the value of the flavor argument, obviating the need for this.=C2=A0 I wou= ld not expect security reviewers or consumers to tolerate the idea that the author of a MIME header field can tell a consumer what command to run and with what arguments.=C2=A0 I= f that were the case, we had better be prepared to come up with a lot of text or ABNF that hardens this against command injection attacks.

 I think the security risk is significantly mitigated (perhaps even eliminated) by registration. Will write in separate e-mail.

Replied separately = as well.
=C2=A0


8) I'm unclear on what the "output-type" tag= is for.=C2=A0 Isn't the output format a function of the context in whic= h the MIME part is being processed?=C2=A0 For example, if I get this in a piece of email, wouldn't the markdown processor output in HTML if I'm using an HTML-enabled MUA, or in text otherwise?

 First, thanks for the open discussion of output-type. I think the text spells it out. text/html is what most people think of...but text/html is not the way that Markdown is going. Markdown is slowly encroaching upon every other format, because other formats are "to= o complicated".

The use case of an e-mail client showing the HTML output of Markdown inline, is not realistic. As someone else noted earlier, if you write an e-mail in Markdown and want the recipient to see formatted text, the expectation is that the sending mail client will do the formatting, so in an e-mail, the received data will be text/html.

Email clients are not the only common = consumers of media types.=C2=A0 What about a web browser?=C2=A0 Here, too, = the output format is implicit from the environment.
=C2=A0
Probably a better scenario (which is becoming a significant use case) is authors collaborating on a document. The authors on disparate machines *both* want to see the source, *and* the output, preferably at the same time. Maybe one collaborator is the author and the other is an editor or reviewer.

Why does the media type need to indicate to b= oth authors what the output format is when they presumably already know tha= t?=C2=A0 Or wouldn't it be implicit in whatever editing environment the= y're using?=C2=A0 Is it safe to assume they're always the same?
=


11) For the flavor parameter, I'm not clear on why it&= #39;s a mandatory value that has a default.

 It's optional.

The text does say "Generators MUST NOT emit empty flavor parameters"...but then it proceeds, "but parsers MUST treat e= mpty flavor parameters the same as if omitted." The whole parameter is optional. The point is that there is a syntactic difference between: =C2=A0text/markdown; flavor=3D""
and
=C2=A0text/markdown

but there is no semantic difference--they mean the same thing.

OK.=C2=A0 However= , the ABNF doesn't allow empty values in the first place, so I don'= t think this needs to be said at all.=C2=A0 An empty flavor value is alread= y a syntax error.
=C2=A0


12) The requirement to register tools that implement given flavors is unusual.=C2=A0 What's the impetus here?<= /div>
Section 5.1.1.:
"The purpose of the tool requirement is to ensure that the flavor = is actually used in practice."

Due to the proliferation of processors, there have been very many calls in the Markdown community to have "one true formalized syntax". So that means that now there is a proliferation of syntax specifications--several of which are not representative of any implementation at all!

This is covered separately as well.

15) RFC1738 is obsoleted by RFCs 4248 and 4266.

 RFC 1738 is the latest reference for file:/// URLs.

Actually you'= re right, it's listed as authoritative for "file" in the IANA= URI scheme registry, even though it shows it's obsoleted.=C2=A0 That s= hould probably get fixed (but not by this document, obviously).

-MSK
--001a11c3536a78fe040503d3533d-- From nobody Wed Sep 24 16:23:45 2014 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 2E0B11A1B38 for ; Wed, 24 Sep 2014 16:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 p96xtGsYVn7i for ; Wed, 24 Sep 2014 16:23:42 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70931A1A69 for ; Wed, 24 Sep 2014 16:23:41 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AD57C509B8; Wed, 24 Sep 2014 19:23:40 -0400 (EDT) Message-ID: <54235269.2060002@seantek.com> Date: Wed, 24 Sep 2014 16:23:21 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: media-types@iana.org, apps-discuss@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZRdVOZp-iZqdLb4X-VUTlxYEyvU Subject: [apps-discuss] A proposal for a new top-level media type: archive 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, 24 Sep 2014 23:23:44 -0000 Colleagues on media-types and apps-discuss: I would like to propose that the IETF create a new top-level media type: archive. Basically, archive would be a top-level type for all types of archive formats. https://en.wikipedia.org/wiki/Archive_file https://en.wikipedia.org/wiki/List_of_archive_formats I think it's important to register archive formats as a distinct type from application, because there are common semantics that apply. In fact, these semantics are very similar to multipart and message top-level types. The archive data types are all storage formats for *files*, as opposed to *content*. Each file has its own security implications, along with metadata that also has security implications (user and group permissions, access bits, executable bits, ACLs). At the highest level, an Internet-connected application ought to be able to identify that a particular piece of content is of this type (as opposed to the opaque application type), so it can make decisions about the content that are unique to archives, namely, dealing with the security issues, and presenting uniform user interfaces to handling such archives. Content bundling types like message (RFC 5322), multipart, and application/cms (CMS) are conceptually distinct. All those types can contain content that can get split off into files, but their purpose is not to replicate file system data. Archives are ubiquitous on the Internet. Even if archives are used "infrequently" across the Internet architecture, they are obviously used at the endpoints. Improper transmission of archives has become a major source of labeling and security issues. Remarkably, most archive formats have not been registered as media types (except for application/zip, which is an oldie). Therefore, it's pretty much a "clean field". Furthermore, there is a trend of a lot of widely available tools to support multiple formats, so the probability is good that if you pass some archive/* labeled content to an archive application, it will be able to do something intelligent with it. The following major sub-types of archives, all belong in a common top-level media type: [from Wikipedia] * archiving only (concatenate files): tar * multi-function (concatenate, compress, encrypt, etc.): zip, rar, 7z, arc, arj, the list goes on and on... * software packaging: cab, msi, pup, pet, apk, rpm... * disk image: ISO-9660 (CD/DVD/Blu-Ray), Apple Disk Image, virtual floppy disks, formerly-known-as-TrueCrypt, etc. * backup: (a large quantity of proprietary formats) I know that the TLMT matter has been brought up before with fonts. Where do we start? Maybe we should talk about it? I don't think it's as simple as drafting an Internet-Draft. Maybe there should be a BOF or working group. Experts with file system and archival experience should get involved. Sean From nobody Wed Sep 24 19:31:48 2014 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 0D2311A0109 for ; Wed, 24 Sep 2014 19:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMl2LJRvuLxR for ; Wed, 24 Sep 2014 19:31:43 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E001A00C5 for ; Wed, 24 Sep 2014 19:31:43 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id c9so4467166qcz.17 for ; Wed, 24 Sep 2014 19:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qrJuCSLs8uVsViHbRmuGu5SXJ2HxS54W7nR7ruIfgxg=; b=LHqEv9fmk15p7muFrdDeEEiCeoiHYkx8MQJffLenJEefNUR4axyq0ML2hPp90Gn6V1 erGCvdllRBbpMvDOtX/OzY+BKp5gpkZ/Odjmv6+OsM2xE31LtsclnIvmNjWXv2sTaGCR /CcSYO5bua00sL9lhOnk6O0JGAI4FrBm93Zi3HZ4dSsChth84ByTNeMqxDMgUzgQLBeI XNlWZfVQc0VxhTLiulnDTb1H9HCMg9okV5LjZ7Tli7cXfFVcX2zIKjCxDRNOjKqXQWz8 yDjMZKE9UDbshiYFnVEiyABghKa5qrqPvxLptuW+Jy8hzk72K9rjBtImS3hFfarWd4Rl Th6w== MIME-Version: 1.0 X-Received: by 10.140.20.151 with SMTP id 23mr12491886qgj.24.1411612302646; Wed, 24 Sep 2014 19:31:42 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.140.25.150 with HTTP; Wed, 24 Sep 2014 19:31:42 -0700 (PDT) In-Reply-To: <54235269.2060002@seantek.com> References: <54235269.2060002@seantek.com> Date: Thu, 25 Sep 2014 12:31:42 +1000 X-Google-Sender-Auth: 32Sl9MWAjzqL-Gk8LnUD2PpcT-U Message-ID: From: Matthew Kerwin To: Sean Leonard Content-Type: multipart/alternative; boundary=001a11c12392dca5cc0503da998d Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kW7DUA9OSpnqfVSKAO9WZpghH6I Cc: media-types@iana.org, IETF Apps Discuss Subject: Re: [apps-discuss] A proposal for a new top-level media type: archive X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 02:31:47 -0000 --001a11c12392dca5cc0503da998d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 25 September 2014 09:23, Sean Leonard wrote: > Colleagues on media-types and apps-discuss: > > I would like to propose that the IETF create a new top-level media type: > archive. > > Colour me interested. > > I think it's important to register archive formats as a distinct type fro= m > application, because there are common semantics that apply. > > +1 > Archives are ubiquitous on the Internet. Even if archives are used > "infrequently" across the Internet architecture, they are obviously used = at > the endpoints. Improper transmission of archives has become a major sourc= e > of labeling and security issues. > =E2=80=8B > =E2=80=8B > > Archives (of the single-file variety) are used a lot, but we usually call it Content-Encoding. However I digress; I can see there being a value in knowing the difference between a tarball and an ISO, instead of having my browser guess which handler to launch based on the final characters of the URL, or the first *n* bytes of the file. > =E2=80=8B > =E2=80=8B =E2=80=8B > Remarkably, most archive formats have not been registered as media types > (except for application/zip, which is an oldie). Therefore, it's pretty > much a "clean field". Furthermore, there is a trend of a lot of widely > available tools to support multiple formats, so the probability is good > that if you pass some archive/* labeled content to an archive application= , > it will be able to do something intelligent with it. > =E2=80=8B > =E2=80=8B > > =E2=80=8BActually there's a pretty decent list, pulled from a quick scan: - application/zip - application/gzip - application/zlib=E2=80=8B - application/vnd.dece-zip - application/vnd.easykaraoke.cdgdownload - application/vnd.google-earth.kmz - application/vnd.ms-cab-compressed - application/vnd.osgi.bundle - application/vnd.software602.filler.form-xml-zip ... and probably countless others. Some of them are closer to content-encodings than archives per se, and a good many are just zip files with a different extension, but they're still archives. And yes, I agree, if they were all "archive/*" instead of "application," I could probably pass them all to 7zip or winrar without a second thought. > =E2=80=8B > =E2=80=8B Where do we start? Maybe we should talk about it? I don't think it's as > simple as drafting an Internet-Draft. Maybe there should be a BOF or > working group. Experts with file system and archival experience should ge= t > involved. > > =E2=80=8BI think this conversation already the start. The immediate questio= ns I have, and my instinctive reactions (without having put any thought at all into it), are: 1. How much value is there in distinguishing tarball from an ISO image from ... (as opposed to bundling them all under application/octet-stream= ) -- my feeling is: quite a bit 2. How much value is there in grouping archives together in one registry, away from other application/* types -- again, I think: probably a fair bit 3. =E2=80=8BHow does this relate to content-encoding, if at all? -- a HTTP resource with Content-Type:archive/tar|Content-Encoding:gzip is a different beast from a Content-Type:application/gzip, so they can probably play together just fine. The real meaty starting point, though, would be to register a type (or types) in the new registry. No point setting it up with nothing in. Was there one in particular you wanted to see added? --=20 Matthew Kerwin http://matthew.kerwin.net.au/ On 25 September 2014 09:23, Sean Leonard wrote: > Colleagues on media-types and apps-discuss: > > I would like to propose that the IETF create a new top-level media type: > archive. > > Basically, archive would be a top-level type for all types of archive > formats. > https://en.wikipedia.org/wiki/Archive_file > https://en.wikipedia.org/wiki/List_of_archive_formats > > I think it's important to register archive formats as a distinct type fro= m > application, because there are common semantics that apply. In fact, thes= e > semantics are very similar to multipart and message top-level types. > > The archive data types are all storage formats for *files*, as opposed to > *content*. Each file has its own security implications, along with metada= ta > that also has security implications (user and group permissions, access > bits, executable bits, ACLs). At the highest level, an Internet-connected > application ought to be able to identify that a particular piece of conte= nt > is of this type (as opposed to the opaque application type), so it can ma= ke > decisions about the content that are unique to archives, namely, dealing > with the security issues, and presenting uniform user interfaces to > handling such archives. Content bundling types like message (RFC 5322), > multipart, and application/cms (CMS) are conceptually distinct. All those > types can contain content that can get split off into files, but their > purpose is not to replicate file system data. > > Archives are ubiquitous on the Internet. Even if archives are used > "infrequently" across the Internet architecture, they are obviously used = at > the endpoints. Improper transmission of archives has become a major sourc= e > of labeling and security issues. > > Remarkably, most archive formats have not been registered as media types > (except for application/zip, which is an oldie). Therefore, it's pretty > much a "clean field". Furthermore, there is a trend of a lot of widely > available tools to support multiple formats, so the probability is good > that if you pass some archive/* labeled content to an archive application= , > it will be able to do something intelligent with it. > > The following major sub-types of archives, all belong in a common > top-level media type: [from Wikipedia] > * archiving only (concatenate files): tar > * multi-function (concatenate, compress, encrypt, etc.): zip, rar, 7z, > arc, arj, the list goes on and on... > * software packaging: cab, msi, pup, pet, apk, rpm... > * disk image: ISO-9660 (CD/DVD/Blu-Ray), Apple Disk Image, virtual floppy > disks, formerly-known-as-TrueCrypt, etc. > * backup: (a large quantity of proprietary formats) > > I know that the TLMT matter has been brought up before with fonts. < > http://www6.ietf.org/mail-archive/web/apps-discuss/current/msg03447.html> > > Where do we start? Maybe we should talk about it? I don't think it's as > simple as drafting an Internet-Draft. Maybe there should be a BOF or > working group. Experts with file system and archival experience should ge= t > involved. > > Sean > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a11c12392dca5cc0503da998d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 25 September 2014 09:23, Sean Leonard <dev+ietf@seantek.com> wrote:
Colleagues= on media-types and apps-discuss:

I would like to propose that the IETF create a new top-level media type: ar= chive.


Colour me interested.
=C2=A0

I think it's important to register archive formats as a distinct type f= rom application, because there are common semantics that apply.


+1


Archives are ubiquitous on the Internet. Even if archives are used "in= frequently" across the Internet architecture, they are obviously used = at the endpoints. Improper transmission of archives has become a major sour= ce of labeling and security issues.
=E2=80=8B
=E2=80=8B<= /div>

Archives (of the single-file variety) are used a lot, but we usually = call it Content-Encoding. However I digress; I can see there being a value = in knowing the difference between a tarball and an ISO, instead of having m= y browser guess which handler to launch based on the final characters of th= e URL, or the first n=C2=A0bytes of the file.

= =C2=A0
=E2=80=8B
=E2=80=8B
=E2=80=8B
Remarkably,= most archive formats have not been registered as media types (except for a= pplication/zip, which is an oldie). Therefore, it's pretty much a "= ;clean field". Furthermore, there is a trend of a lot of widely availa= ble tools to support multiple formats, so the probability is good that if y= ou pass some archive/* labeled content to an archive application, it will b= e able to do something intelligent with it.
=E2=80=8B
=E2=80=8B<= /div>

=E2=80=8BActually there's a pretty decent list, pulled from a qui= ck scan:
  • application/zip
  • application/gzip=
  • application/zlib=E2=80=8B
  • application/vnd.dece-zip=
  • application/vnd.easykaraoke.cdgdownload
  • applicatio= n/vnd.google-earth.kmz
  • application/vnd.ms-cab-compressed
  • application/vnd.osgi.bundle
  • application/vnd.software602.f= iller.form-xml-zip
... and probably countless others. = Some of them are closer to content-encodings than archives per se, and a go= od many are just zip files with a different extension, but they're stil= l archives. And yes, I agree, if they were all "archive/*" instead of "ap= plication," I=C2=A0cou= ld=C2=A0probably pass them all to 7zip or winrar without a second thought.<= /font>

=C2=A0
=E2=80=8B
=E2=80=8B
Where do we start? Maybe we should talk about it? I don't think it'= s as simple as drafting an Internet-Draft. Maybe there should be a BOF or w= orking group. Experts with file system and archival experience should get i= nvolved.


=E2=80= =8BI think this conversation already the start. The immediate questions I h= ave, and my instinctive reactions (without having put any thought at all in= to it), are:
  1. How much value is there in distinguishin= g tarball from an ISO image from ... (as opposed to bundling them all under= application/octet-stream)
    -- my feeling is: quite a bit
  2. How muc= h value is there in grouping archives together in one registry, away from o= ther application/* types
    -- again, I think: probably a fair bit
  3. = =E2=80=8BHow does this relate to content-encoding, if at all?
    -- a HTTP = resource with Content-Type:archive/tar|Content-Encoding:gzip is a different= beast from a Content-Type:application/gzip, so they can probably play toge= ther just fine.
The real meaty starting point, though, would = be to register a type (or types) in the new registry. No point setting it u= p with nothing in. Was there one in particular you wanted to see added?

--
=C2=A0 Matthew Kerwin
=C2= =A0 http://matt= hew.kerwin.net.au/

On 25= September 2014 09:23, Sean Leonard <dev+ietf@seantek.com> wrote:
Colleagues on media-types and ap= ps-discuss:

I would like to propose that the IETF create a new top-level media type: ar= chive.

Basically, archive would be a top-level type for all types of archive forma= ts.
ht= tps://en.wikipedia.org/wiki/Archive_file
https://en.wikipedia.org/wiki/List_of_archive_formats
I think it's important to register archive formats as a distinct type f= rom application, because there are common semantics that apply. In fact, th= ese semantics are very similar to multipart and message top-level types.
The archive data types are all storage formats for *files*, as opposed to *= content*. Each file has its own security implications, along with metadata = that also has security implications (user and group permissions, access bit= s, executable bits, ACLs). At the highest level, an Internet-connected appl= ication ought to be able to identify that a particular piece of content is = of this type (as opposed to the opaque application type), so it can make de= cisions about the content that are unique to archives, namely, dealing with= the security issues, and presenting uniform user interfaces to handling su= ch archives. Content bundling types like message (RFC 5322), multipart, and= application/cms (CMS) are conceptually distinct. All those types can conta= in content that can get split off into files, but their purpose is not to r= eplicate file system data.

Archives are ubiquitous on the Internet. Even if archives are used "in= frequently" across the Internet architecture, they are obviously used = at the endpoints. Improper transmission of archives has become a major sour= ce of labeling and security issues.

Remarkably, most archive formats have not been registered as media types (e= xcept for application/zip, which is an oldie). Therefore, it's pretty m= uch a "clean field". Furthermore, there is a trend of a lot of wi= dely available tools to support multiple formats, so the probability is goo= d that if you pass some archive/* labeled content to an archive application= , it will be able to do something intelligent with it.

The following major sub-types of archives, all belong in a common top-level= media type: [from Wikipedia]
* archiving only (concatenate files): tar
*=C2=A0 multi-function (concatenate, compress, encrypt, etc.): zip, rar, 7z= , arc, arj, the list goes on and on...
* software packaging: cab, msi, pup, pet, apk, rpm...
* disk image: ISO-9660 (CD/DVD/Blu-Ray), Apple Disk Image, virtual floppy d= isks, formerly-known-as-TrueCrypt, etc.
* backup: (a large quantity of proprietary formats)

I know that the TLMT matter has been brought up before with fonts. <http://www6.ietf.org/mail-archive/web/apps-d= iscuss/current/msg03447.html>

Where do we start? Maybe we should talk about it? I don't think it'= s as simple as drafting an Internet-Draft. Maybe there should be a BOF or w= orking group. Experts with file system and archival experience should get i= nvolved.

Sean

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



--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a11c12392dca5cc0503da998d-- From nobody Wed Sep 24 19:44:37 2014 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 040F71A19F5 for ; Wed, 24 Sep 2014 19:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, 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 lC2EyAorMJ0s for ; Wed, 24 Sep 2014 19:44:33 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id B21CB1A6F2E for ; Wed, 24 Sep 2014 19:44:33 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PCZ1WJIY5C004WN5@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 24 Sep 2014 19:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1411612770; bh=1pNnoB3GfA30RWcqC2USStwiEYUaoP9SuPUQF8bZlNI=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=HYCsQQQOdvgmPkcw1t65TaQrtGc/Y6yynAFZ4d5i2sAx39Oo7x9BpnlJV5MiE58bD nlis6CDqoZSxENThDHux10MhJzWeNDcrMGX3/Y0TNq+X0N0T4tw6oSEVBVu3mHg688 uXFtVJjz+OBQfewdm5zb9S4c4VDdJ+EhR0Xzv8N4= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PCYTB9U3BK0000SM@mauve.mrochek.com>; Wed, 24 Sep 2014 19:39:26 -0700 (PDT) Message-id: <01PCZ1WHF6Q80000SM@mauve.mrochek.com> Date: Wed, 24 Sep 2014 19:38:06 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 25 Sep 2014 12:31:42 +1000" References: <54235269.2060002@seantek.com> To: Matthew Kerwin Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/S4aZ2wP5LNLP5RZoiK_4oDs2yJk Cc: IETF Apps Discuss , media-types@iana.org Subject: Re: [apps-discuss] A proposal for a new top-level media type: archive X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 02:44:35 -0000 > On 25 September 2014 09:23, Sean Leonard wrote: > > Colleagues on media-types and apps-discuss: > > > > I would like to propose that the IETF create a new top-level media type: > > archive. > > > > > Colour me interested. Yeah, me too. I'm surpised nobody has suggested this before. Ned From nobody Wed Sep 24 19:48:33 2014 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 633C31A6F47 for ; Wed, 24 Sep 2014 19:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoX1-RuzXFBr for ; Wed, 24 Sep 2014 19:48:28 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385821A1A05 for ; Wed, 24 Sep 2014 19:48:28 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id q5so8490004wiv.13 for ; Wed, 24 Sep 2014 19:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=h3O376mQ2KZal1guwj4ehuoqSZMhsNyrC/prommaLKM=; b=Vintl2VjWl/9s3uVXpBBJkVO2s049govSMk5ORIJ8BvcB2bHK+D3+jwekbcIvscPP+ GUHT7C+ES0k7MntcI5UiIhyL0l5j/Ul7cstDl2Ju4q0i1St0dwsAbZkKPBk4RyH5ooKH VxCJsSVAjdEJzWT5ALwfI1g4OCW1VdfrrkB8eNvIrOSHha9Bd6A+RWwk2TI5LRCJozUM KXavv2yIiM9DU5f5pZDl8CyjH3rCL4mjO8gOkPjtqcp2ViMhXpzTAS96PdfjhPkKewVS 2MqPts9ExkvXcbU9YNB3PDnmMDa1095ph1KbEB4wsCHQDf3nQvQzE+vgjsPJm7mBRIUT 0CzA== X-Received: by 10.180.105.41 with SMTP id gj9mr15529550wib.3.1411613306870; Wed, 24 Sep 2014 19:48:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.77.136 with HTTP; Wed, 24 Sep 2014 19:48:06 -0700 (PDT) In-Reply-To: <01PCZ1WHF6Q80000SM@mauve.mrochek.com> References: <54235269.2060002@seantek.com> <01PCZ1WHF6Q80000SM@mauve.mrochek.com> From: Ira McDonald Date: Wed, 24 Sep 2014 22:48:06 -0400 Message-ID: To: Ned Freed , Ira McDonald Content-Type: multipart/alternative; boundary=f46d04428262b762910503dad50a Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/rRhFVdIzLAPjwMoSlgOuASXlWaw Cc: IETF Apps Discuss , media-types@iana.org Subject: Re: [apps-discuss] A proposal for a new top-level media type: archive X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 02:48:30 -0000 --f46d04428262b762910503dad50a Content-Type: text/plain; charset=UTF-8 Hi, +1 Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Wed, Sep 24, 2014 at 10:38 PM, Ned Freed wrote: > > On 25 September 2014 09:23, Sean Leonard wrote: > > > > Colleagues on media-types and apps-discuss: > > > > > > I would like to propose that the IETF create a new top-level media > type: > > > archive. > > > > > > > > Colour me interested. > > Yeah, me too. I'm surpised nobody has suggested this before. > > Ned > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d04428262b762910503dad50a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

+1

Cheers,
- Ir= a


Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Tru= sted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
= Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Int= ernet Printing Protocol WG
IETF Designated Expert - IPP & Printer MI= B
Blue Roof Music / High North Inc
http:= //sites.google.com/site/blueroofmusic
ht= tp://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Win= ter=C2=A0 579 Park Place=C2=A0 Saline, MI=C2=A0 48176=C2=A0 734-944-0094Summer=C2=A0 PO Box 221=C2=A0 Grand Marais, MI 49839=C2=A0 906-494-2434

On Wed, Sep 24, 2014 at 10:38 PM, Ned Freed = <ned.freed@mrochek.com> wrote:
> On 25 September 2014 09:23, Sean Leonard <= ;dev+ietf@seantek.com> wro= te:

> > Colleagues on media-types and apps-discuss:
> >
> > I would like to propose that the IETF create a new top-level medi= a type:
> > archive.
> >
> >
> Colour me interested.

Yeah, me too. I'm surpised nobody has suggested this before.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ned

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

--f46d04428262b762910503dad50a-- From nobody Thu Sep 25 01:57:01 2014 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 1CA7E1A02F9 for ; Thu, 25 Sep 2014 01:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5gvC_h-LvvJE for ; Thu, 25 Sep 2014 01:56:57 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0755.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::755]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795961A1B7C for ; Thu, 25 Sep 2014 01:56:55 -0700 (PDT) Received: from pc6 (86.184.59.221) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Thu, 25 Sep 2014 08:56:31 +0000 Message-ID: <020401cfd89e$5d2a0120$4001a8c0@gateway.2wire.net> From: t.petch To: Matthew Kerwin , "Murray S. Kucherawy" References: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> Date: Thu, 25 Sep 2014 09:54:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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.184.59.221] X-ClientProxiedBy: DB4PR03CA0009.eurprd03.prod.outlook.com (25.160.39.147) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-Forefront-PRVS: 0345CFD558 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(377454003)(199003)(51704005)(24454002)(189002)(13464003)(90102001)(230783001)(62236002)(15202345003)(19580395003)(83072002)(19580405001)(33646002)(14496001)(62966002)(50466002)(31966008)(47776003)(50986999)(97736003)(77156001)(15975445006)(20776003)(44716002)(81816999)(229853001)(84392001)(61296003)(85852003)(64706001)(99396003)(66066001)(23676002)(120916001)(83322001)(21056001)(77982003)(88136002)(74662003)(89996001)(81542003)(80022003)(46102003)(79102003)(77096002)(4396001)(81342003)(50226001)(85306004)(74502003)(76176999)(10300001)(104166001)(42186005)(44736004)(92726001)(81686999)(102836001)(87976001)(106356001)(93916002)(76482002)(92566001)(95666004)(107046002)(116806002)(101416001)(86362001)(87286001)(105586002)(74416001)(7726001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/B1mUPripxNo4XmwEPu1ZTGdiBQc Cc: IETF Apps Discuss Subject: [apps-discuss] file:/// was Re: I-D Action:draft-ietf-appsawg-text-markdown-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 08:57:00 -0000 ----- Original Message ----- From: "Matthew Kerwin" To: "Murray S. Kucherawy" Cc: "IETF Apps Discuss" Sent: Wednesday, September 24, 2014 7:53 AM On 24 September 2014 16:22, Murray S. Kucherawy wrote: > > 15) RFC1738 is obsoleted by RFCs 4248 and 4266. > > Actually it's RFC 3986 that matters; from RFC 3986, Section 1: | This document obsoletes [RFC2396], which merged "Uniform Resource | Locators" [RFC1738] and "Relative Uniform Resource Locators" | [RFC1808] in order to define a single, generic syntax for all URIs. I really wish the status of RFC 1738 could be fixed up. I've spent two years trying to work out how to resurrect the "file" scheme because RFC Matthew Well, you write an I-D! But you know that because you have done that plenty of times already. I do notice that since the last post I saw from you on this, in 2013, you have asked people to discuss this on github. Following the link in the I-D, I get 'The page cannot be displayed' but really, that is irrelevant for me, since if I am going to discuss it, I want it to be here on the apps list, not on yet another list (the uri list would be an alternative). I do use file:/// most days of the week in the flavour used by IE and would be happy to work to see it standardised; which then requires a WG to show sufficient interest, or an AD to feel motivated to take it on (which you also know:-). Tom Petch 1738 says it's obsoleted, even though the two RFCs that apparently obsoleted it only obsoleted a small part, and the one that really replaced the bulk only "updated" it, and some RFCs that usurped its schemes (looking at you, RFC 2068/2616) didn't update it at all, and some parts are probably meant to still be current (the schemes referenced from the IANA registry, like "file"). -- Matthew Kerwin http://matthew.kerwin.net.au/ From nobody Thu Sep 25 02:58:53 2014 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 972BA1A1BEE for ; Thu, 25 Sep 2014 02:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.427 X-Spam-Level: X-Spam-Status: No, score=-0.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, 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 6cJz4wg78mGL for ; Thu, 25 Sep 2014 02:58:49 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1451A1BD8 for ; Thu, 25 Sep 2014 02:58:49 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id f51so7335111qge.16 for ; Thu, 25 Sep 2014 02:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=n4UOxmNFtYY8P/GRZ2cziQ05Wa2J8rt++jTtrcUpRzU=; b=dnohn3qIMeHbAcqJ4dubQR19raUfPqor9SLEXyuOqXhbXuY9RRFOLNA00FN0f0fesa AvmDUPn1xM1kBD2JE7vu0G+fOCrvmLME/oLMTdfv0cZr3ZNckzkxU+7QgtwxInFJGJbc 1hBhqpFfCxVTXiKOwG9C4pMfMBwxQrNaDnoYlJV6XebEdgYfr5BraiEdkXtoI5KGmbQR Eimx+4BgZOPjq8T+ecHfT0EGP3emvkIJVjy3kNoHe8RWkOW0fMc1c+t16PJ4E9giLmeL iF+8D06JhuE6TUrvqjTc/kZyBLk4Dz7eFMb2E2RtQa0jQ3ZtWfG12opCvD/N7DqXN0OM 976w== MIME-Version: 1.0 X-Received: by 10.140.101.205 with SMTP id u71mr18045238qge.48.1411639128526; Thu, 25 Sep 2014 02:58:48 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.140.25.150 with HTTP; Thu, 25 Sep 2014 02:58:48 -0700 (PDT) Date: Thu, 25 Sep 2014 19:58:48 +1000 X-Google-Sender-Auth: HCZNAj3krJKliUsQxNXjPGrka5Q Message-ID: From: Matthew Kerwin To: "t.petch" Content-Type: multipart/alternative; boundary=001a11c16530cecf350503e0d8d4 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JSoStq2bCPuTNG5yEdEvr0nEAHg Cc: uri@w3.org, IETF Apps Discuss Subject: Re: [apps-discuss] file:/// X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 09:58:51 -0000 --001a11c16530cecf350503e0d8d4 Content-Type: text/plain; charset=UTF-8 On 25 September 2014 18:54, t.petch wrote: > > I do notice that since the last post I saw > from you on this, in 2013, you have asked people to discuss this on > github. Following the link in the I-D, I get 'The page cannot be > displayed' but really, that is irrelevant for me, since if I am going to > discuss it, I want it to be here on the apps list, not on yet another > list (the uri list would be an alternative). > > To date it's actually mostly been discussed in private conversation via email. I recently did a major rewrite, so draft 12 is a bit skeletal, but I was planning on bringing it back to uri@w3.org once I figured it could stand up to a bit of serious scrutiny. Of course, it's a public document, so if people want to chew it up right now they're more than welcome. If there's a better place to discuss it, I can push out an update with a better link. Would anyone be upset if I said it should be discussed either on apps-discuss@ietf.org or uri@w3.org ? And is there a preference for one over the other? > I do use file:/// most days of the week in the flavour used by IE and > would be happy to work to see it standardised; which then requires a WG > to show sufficient interest, or an AD to feel motivated to take it on > (which you also know:-). > > The more people who can contribute, the better. (...I think.) Especially people who actually use the scheme. If, one day, we can get it pushed through the process, that would be brilliant. Cheers -- Matthew Kerwin http://matthew.kerwin.net.au/ --001a11c16530cecf350503e0d8d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 25 September 2014 18:54, t.petch <ietfc@btconnect.com> wrote:

I do notice that since the last post I saw
from you on this, in 2013, you have asked people to discuss this on
github.=C2=A0 Following the link in the I-D, I get 'The page cannot be<= br> displayed' but really, that is irrelevant for me, since if I am going t= o
discuss it, I want it to be here on the apps list, not on yet another
list (the uri list would be an alternative).


To date it's actually= mostly been discussed in private conversation via email. I recently did a = major rewrite, so draft 12 is a bit skeletal, but I was planning on bringin= g it back to uri@w3.org once I figured it= could stand up to a bit of serious scrutiny. Of course, it's a public = document, so if people want to chew it up right now they're more than w= elcome. If there's a better place to discuss it, I can push out an upda= te with a better link.

Would anyone be ups= et if I said it should be discussed either on apps-discuss@ietf.org or uri@= w3.org ? And is there a preference for one over the other?



I do u= se file:/// most days of the week in the flavour used by IE and
would be happy to work to see it standardised; which then requires a WG
to show sufficient interest, or an AD to feel motivated to take it on
(which you also know:-).


The more people who can contribute, the better. (...I think.) Especial= ly people who actually use the scheme. If, one day, we can get it pushed th= rough the process, that would be brilliant.

C= heers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.ke= rwin.net.au/
--001a11c16530cecf350503e0d8d4-- From nobody Thu Sep 25 06:57:39 2014 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 716E01A00D4 for ; Thu, 25 Sep 2014 06:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 BzbyubjpPA8l for ; Thu, 25 Sep 2014 06:57:31 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D001A6F91 for ; Thu, 25 Sep 2014 06:57:30 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6FE6E50A85; Thu, 25 Sep 2014 09:57:27 -0400 (EDT) Message-ID: <54241F33.5010500@seantek.com> Date: Thu, 25 Sep 2014 06:57:07 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: apps-discuss@ietf.org, matthew@kerwin.net.au, ietfc@btconnect.com References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040406070502020904040108" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/EiNN-TG1LlQxewQyncUEioBaWjI Subject: Re: [apps-discuss] file:/// X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 13:57:34 -0000 This is a cryptographically signed message in MIME format. --------------ms040406070502020904040108 Content-Type: multipart/alternative; boundary="------------090906010600020706060502" This is a multi-part message in MIME format. --------------090906010600020706060502 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 9/25/2014 2:58 AM, Matthew Kerwin wrote: > On 25 September 2014 18:54, t.petch >wrote: > > > I do notice that since the last post I saw > from you on this, in 2013, you have asked people to discuss this on= > github. Following the link in the I-D, I get 'The page cannot be > displayed' but really, that is irrelevant for me, since if I am > going to > discuss it, I want it to be here on the apps list, not on yet anoth= er > list (the uri list would be an alternative). > > > To date it's actually mostly been discussed in private conversation=20 > via email. I recently did a major rewrite, so draft 12 is a bit=20 > skeletal, but I was planning on bringing it back to uri@w3.org=20 > once I figured it could stand up to a bit of=20 > serious scrutiny. Of course, it's a public document, so if people want = > to chew it up right now they're more than welcome. If there's a better = > place to discuss it, I can push out an update with a better link. > > Would anyone be upset if I said it should be discussed either on=20 > apps-discuss@ietf.org or uri@w3.org=20 > ? And is there a preference for one over the other?= I would prefer it be discussed here on apps-discuss, thanks. :) It would be nice to have a modern reference to the file URI (URL). I=20 would veer towards documenting existing implementations (descriptive)=20 rather than saying the One True Way it SHOULD/MUST be (prescriptive). I=20 have not yet read any drafts on the topic. Sean > > > > I do use file:/// most days of the week in the flavour used by IE a= nd > would be happy to work to see it standardised; which then requires > a WG > to show sufficient interest, or an AD to feel motivated to take it = on > (which you also know:-). > > > The more people who can contribute, the better. (...I think.)=20 > Especially people who actually use the scheme. If, one day, we can get = > it pushed through the process, that would be brilliant. > > Cheers > --=20 > Matthew Kerwin > http://matthew.kerwin.net.au/ > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --------------090906010600020706060502 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On 9/25/2014 2:58 AM, Matthew Kerwin wrote:
On 25 September 2014 18:54, t.petch <ietfc@btconnect.com> wrote:

I do notice that since the last post I saw
from you on this, in 2013, you have asked people to discuss this on
github.=A0 Following the link in the I-D, I get 'The page cannot be
displayed' but really, that is irrelevant for me, since if I am going to
discuss it, I want it to be here on the apps list, not on yet another
list (the uri list would be an alternative).


To= date it's actually mostly been discussed in private conversation via email. I recently did a major rewrite, so draft 12 is a bit skeletal, but I was planning on bringing it back to uri@w3.org once I figure= d it could stand up to a bit of serious scrutiny. Of course, it's a public document, so if people want to chew it up right now they're more than welcome. If there's a better place to discuss it, I can push out an update with a better link.
Wo= uld anyone be upset if I said it should be discussed either on apps-discuss@ietf= =2Eorg or uri@w3.org ? And is there a preference for one over the other?
=

I would prefer it be discussed here on apps-discuss, thanks. :)

It would be nice to have a modern reference to the file URI (URL). I would veer towards documenting existing implementations (descriptive) rather than saying the One True Way it SHOULD/MUST be (prescriptive). I have not yet read any drafts on the topic.

Sean




I do use file:/// most days of the week in the flavour used by IE and
would be happy to work to see it standardised; which then requires a WG
to show sufficient interest, or an AD to feel motivated to take it on
(which you also know:-).


The more people who can contribute, the better. (...I think.) Especially people who actually use the scheme. If, one day, we can get it pushed through the process, that would be brilliant.

Chee= rs
--
=A0 Matthew Kerwin
=A0 ht= tp://matthew.kerwin.net.au/


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

--------------090906010600020706060502-- --------------ms040406070502020904040108 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKTDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMx MTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkBFhRkZXYraWV0ZkBz ZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J9tKgDs1LQtaD c+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2guKi2R5xr f/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G53zv awQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia3 3JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaA FHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQ ME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcw AoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25h bmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMfWE2/5myX518DB+kTa5iQDbKYRuJp 3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmIH4kfI4LWrY8XrPhlX3JmHjD6 hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3jx9VF/gA3vqYpL+jNumI nz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d9ljRDEiAts5Oopke eFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYIEHDCCBBgCAQEw gakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggJHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE0MDkyNTEzNTcwN1owIwYJKoZIhvcNAQkEMRYEFLXL8+Zlm8q1MgCs xQJG+NPxwyh7MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNV BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09N T0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwgbwGCyqGSIb3DQEJEAIL MYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMw Q09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAypM8 MbupbqbMkL4Skr0HfDANBgkqhkiG9w0BAQEFAASCAQADPjjF2huf0BjGGJgFQsreY80BdsJ9 A4Sv4WKMfv1niHXhsjAgBr1JHd5G2UxTvP3MpWyLduoZTmwO4p7epB0fVS0766X2si43lDAo yGwXJMBP+z6YorYBI+cf9aDWof6dpodhwUF0DD77wD397QDvcl4bjR1eKEKEuYlLZ4CujP/f dgXsFznJor4hvJ8PyqgjBcYpC6UTUCeBvegcxoUCRjw6f7l+04ZDCqBSafzchX3bPk/Pl2/n RLZAxS8L8EC+F4Iq4UOoePfVgHHBBtoE4Ev5YDyssJXn/1YxUcPSXHp6URzKaHdFwS+huQDX NP90eaop5nZ/RIuNaBfXsxawAAAAAAAA --------------ms040406070502020904040108-- From nobody Thu Sep 25 10:20:09 2014 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 ED7C61A028B for ; Thu, 25 Sep 2014 10:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.302 X-Spam-Level: X-Spam-Status: No, score=-101.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 U7mQ3SkCSVxW for ; Thu, 25 Sep 2014 10:20:06 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0127.outbound.protection.outlook.com [65.55.169.127]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62F091A871A for ; Thu, 25 Sep 2014 10:20:06 -0700 (PDT) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB410.namprd03.prod.outlook.com (10.141.141.16) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Thu, 25 Sep 2014 17:20:03 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.1034.003; Thu, 25 Sep 2014 17:20:03 +0000 From: Dave Thaler To: Matthew Kerwin , t.petch Thread-Topic: [apps-discuss] file:/// Thread-Index: AQHP2KdUu93qK178fk+9m3/5r0Miq5wSFu1g Date: Thu, 25 Sep 2014 17:20:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [98.237.193.222] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB410; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(24454002)(199003)(87936001)(19580395003)(120916001)(86612001)(19580405001)(15975445006)(108616004)(80022003)(79102003)(76176999)(99396003)(31966008)(85306004)(106116001)(54356999)(83072002)(83322001)(50986999)(105586002)(4396001)(15202345003)(106356001)(99286002)(85852003)(76482002)(33646002)(20776003)(81542003)(74502003)(46102003)(95666004)(92566001)(97736003)(101416001)(90102001)(66066001)(2656002)(107046002)(10300001)(81342003)(77982003)(74316001)(74662003)(76576001)(21056001)(64706001)(86362001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB410; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/gToeyeL44Ktv-GGC6KJrMI4BskE Cc: "uri@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] file:/// X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 17:20:08 -0000 T24gMjUgU2VwdGVtYmVyIDIwMTQgMTg6NTQsIHQucGV0Y2ggPGlldGZjQGJ0Y29ubmVjdC5jb20+ IHdyb3RlOg0KPiBJIGRvIHVzZSBmaWxlOi8vLyBtb3N0IGRheXMgb2YgdGhlIHdlZWsgaW4gdGhl IGZsYXZvdXIgdXNlZCBieSBJRSBhbmQNCj4gd291bGQgYmUgaGFwcHkgdG8gd29yayB0byBzZWUg aXQgc3RhbmRhcmRpc2VkOyB3aGljaCB0aGVuIHJlcXVpcmVzIGEgV0cNCj4gdG8gc2hvdyBzdWZm aWNpZW50IGludGVyZXN0LCBvciBhbiBBRCB0byBmZWVsIG1vdGl2YXRlZCB0byB0YWtlIGl0IG9u DQo+ICh3aGljaCB5b3UgYWxzbyBrbm93Oi0pLg0KDQpQZXJzb25hbGx5LCBJJ2QgbG92ZSB0byBz ZWUgaXQgZGVwcmVjYXRlZCBhbmQgcmVwbGFjZWQgYnkgc29tZXRoaW5nIG1vcmUNCnVzZWZ1bC9p bnRlcm9wZXJhYmxlLiAgZmlsZTogaGFzIHByb2JsZW1zIHdoZXJlIHRvZGF5IGl0IHdvbid0IGV2 ZW4NCmludGVyb3BlcmF0ZSBiZXR3ZWVuIHR3byBtYWNoaW5lcyAoYmVjYXVzZSBvZiBkaWZmZXJl bnQgaW50ZXJwcmV0YXRpb25zDQpvZiBwZXJjZW50LWVuY29kZWQgb2N0ZXRzKSwgc28gaXMgb25s eSBzYWZlIGZvciB1c2UgZm9yIGZpbGVzIG9uIHRoZSBsb2NhbA0Kc3lzdGVtIG9yIEFTQ0lJLW9u bHkgZmlsZSBwYXRocy4NCg0KSWYgc29tZW9uZSB3YW50cyB0byB3cml0ZSBhIGRyYWZ0IG9uIGZp bGU6IHVzYWdlIGFuZCB0aGUgcHJvYmxlbXMgd2l0aCBpdCwNCnNvbWUgdXNlZnVsIHNvdXJjZSBt YXRlcmlhbCBpcyBvbiBEYXZlIFJpc25leSdzIGJsb2cgYXQ6DQpodHRwOi8vYmxvZ3MubXNkbi5j b20vYi9pZS9hcmNoaXZlLzIwMDYvMTIvMDYvZmlsZS11cmlzLWluLXdpbmRvd3MuYXNweA0KKGFu ZCBhIGZldyBvZiB0aGUgY29tbWVudHMgYXQgdGhlIGJvdHRvbSBvZiBpdCkuDQpJIG1pZ2h0IGV2 ZW4gYmUgY29udmluY2VkIHRvIGhlbHAgY28tYXV0aG9yIHN1Y2ggYSBkcmFmdCBpZiBzb21lb25l IGVsc2UNCnRvb2sgdGhlIGxlYWQuDQoNCi1EYXZlDQo= From nobody Thu Sep 25 14:01:08 2014 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 0DE7C1A0351 for ; Thu, 25 Sep 2014 14:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6ApNnmvwnHP for ; Thu, 25 Sep 2014 14:01:01 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E6231A0396 for ; Thu, 25 Sep 2014 14:01:00 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id gi9so3072469lab.19 for ; Thu, 25 Sep 2014 14:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/dGCm7cv0GD5UumpThv/wfNEsqC5KsbUkvDFi+Tc4Uc=; b=WgIgKiKM1MiMMIKxjVFAtGYdozl60F36gog9WzMwzwsBAbMLhJRy1iCB+Hd8b7p70B XxovrITGdbK0sH2916DWj8QJYcM/jBX65HkiWFw8bMtw/ezocJsXuguU4jQC4PV0n8dQ YX+DzRStXMUlnRFvyn7bTSd23vt8IYCEDknO4AOidvb/RMDlD8LRy8lvozK2CkZu43n8 w6mftSa2keyt4IjaE5eU56YCf/oninFi9Ih+yLKVBTPoL9D5GcLIqQQTkf9aWbPM2vh1 nAg6Kky4pBcgIZd3bhJoUgqrpX59ZadjF1tIAMgQwpj4BzNQh/tsYS/2pNpt9IelOCGz 70Yg== MIME-Version: 1.0 X-Received: by 10.152.27.200 with SMTP id v8mr16029620lag.53.1411678859419; Thu, 25 Sep 2014 14:00:59 -0700 (PDT) Received: by 10.112.13.99 with HTTP; Thu, 25 Sep 2014 14:00:59 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Sep 2014 23:00:59 +0200 Message-ID: From: Melvin Carvalho To: Ira McDonald , Simon Butcher Content-Type: multipart/alternative; boundary=089e0160a3bef3e3b70503ea180b Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/C1mGg3Oyu9-rlHGIPlTZzglhTjg Cc: Apps Discuss Subject: Re: [apps-discuss] IRC URIs to denote users X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 21:01:07 -0000 --089e0160a3bef3e3b70503ea180b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 23 September 2014 01:45, Ira McDonald wrote: > Hi Melvin, > > The current IANA URI Schemes registry includes the following > three schemes: > > irc prov/irc irc [ > Dave_Thaler > > ] irc6 prov/irc6 > irc6 [Dave_Thaler > > ] ircs prov/ircs > ircs [Dave_Thaler > > ] > All three of those are September 2012 provisional registrations > (with references that include butcher and draft-mirashi-url-irc-01). > I got a note from one of the authors of the RFC on this: [[ Hi Melvin, Sorry for the delay=E2=80=A6 Wow, the IRC URI draft =E2=80=93 that=E2=80=99= s a blast from the past! That document never went anywhere due to arguments between established IRC URIs used by IRC client developers at the time, so the document never really became fully proofed. What a shame. But to get to the point: - A user can be specified logging in (i.e. *irc:myusername@some.irc.server.host*) but that was more intended to support authentication with the server. - A user can be targeted for a conversation directly by specifying the user as the target entity =E2=80=93 the flag =E2=80=9Cisuser=E2=80=9D i= s specified to make it clear it=E2=80=99s a user we=E2=80=99re seeking. Examples: o Simple form: *irc:some.irc.server.host/friendnickname,isuser* o Explicit form: *irc:some.irc.server.host/friendnickname%21theirusername,isuser* o Excessively explicit form: *irc:some.irc.server.host/friendnickname%21theirusername%40theirhostname,is= user* I doubt however this has been implemented anywhere, and the =E2=80=9Cisuser= =E2=80=9D stuff was an ugly result of some bitter arguments. I hope this has helped! Regards, - Simon ]] > > Cheers, > - Ira > > > Ira McDonald (Musician / Software Architect) > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music / High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto: blueroofmusic@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 > > > On Mon, Sep 22, 2014 at 4:50 PM, Melvin Carvalho > wrote: > >> I was wondering if IRC URIs are standardized at all? >> >> The latest I found was : >> >> http://tools.ietf.org/html/draft-butcher-irc-url-04 >> >> I have a use case of marking reputation from one system (web chat room) >> to an IRC chat room, but I require an identifier for the user. >> >> The suggestions so far have been: >> >> irc://user@host >> irc://user@host/ -- trailing slash >> irc:user@host -- similar to xmpp >> irc://host/#user -- fragment could be problematic as per RFC 9386 >> >> I've gone with the second option for the moment >> >> Any pointers would be most welcome. >> >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > --089e0160a3bef3e3b70503ea180b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 23 September 2014 01:45, Ira McDonald <blueroofmusic@gmail.c= om> wrote:
Hi Melvin,

T= he current IANA URI Schemes registry includes the following
three schem= es:

irc prov/irc irc [Dave_Thaler]
irc6 prov/irc6 irc6 [Dave_Thaler]
ircs prov/ircs ircs [Dave_Thaler]

All three of those are September 2012 provisional regi= strations
(with references that include butcher and draft-mirashi-= url-irc-01).

I got a = note from one of the authors of the RFC on this:

[[

Hi Melvin,

=C2=A0

Sorry for the delay=E2=80=A6 Wow, the IRC URI draft =E2=80=93 that=E2=80=99s a b= last from the past!=20 That document never went anywhere due to arguments between established=20 IRC URIs used by IRC client developers at the time, so the document=20 never really became fully proofed. What a shame.

=C2=A0

But to get to the point:

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 A user can be specified logging in (i.e. irc:myusername@some.irc.serv= er.host) but that was more intended to support authentication with the = server.

-=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A user can be targeted for a conversation directly by specifying the user as the target entity =E2=80=93 the flag =E2=80=9Cisuser=E2=80=9D is specif= ied to make it clear=20 it=E2=80=99s a user we=E2=80=99re seeking. Examples:

o=C2=A0=C2=A0 Simple form: irc:some.irc.server.host/friendnickname,isuser

o=C2=A0=C2=A0 Explicit form: irc:some.irc.server.h= ost/friendnickname%21theirusername,isuser

o=C2=A0=C2=A0 Excessively explicit form: irc:some.irc.server.host/friendnickname%2= 1theirusername%40theirhostname,isuser

= =C2=A0

I doubt however this has been implemented anywhere, and the =E2=80=9Cisuser= =E2=80=9D=20 stuff was an ugly result of some bitter arguments. I hope this has=20 helped!

= =C2=A0

Reg= ards,

=C2= =A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Simon
=
]]
=C2=A0

Cheers,
- Ira<= br>

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted= Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secr= etary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Interne= t Printing Protocol WG
IETF Designated Expert - IPP & Printer MIBBlue Roof Music / High North Inc
http://si= tes.google.com/site/blueroofmusic
http:/= /sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Winter= =C2=A0 579 Park Place=C2=A0 Saline, MI=C2=A0 48176=C2=A0 734-944-0094
Sum= mer=C2=A0 PO Box 221=C2=A0 Grand Marais, MI 49839=C2=A0 906-494-2434

=

On Mon, Sep 22, 2014 = at 4:50 PM, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
<= div>
I was wonde= ring if IRC URIs are standardized at all?

The latest I found w= as :

http://tools.ietf.org/html/draft-butcher-irc-url-04=

I have a use case of marking reputation from one system (web = chat room) to an IRC chat room, but I require an identifier for the user.
The suggestions so far have been:

irc://user@host<= br>
irc://user@host/ -- trailing slash
irc:user@host -- simila= r to xmpp
irc://host/#user -- fragment could be problematic a= s per RFC 9386

I've gone with the second option for t= he moment

Any pointers would be most welcome.


=

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



--089e0160a3bef3e3b70503ea180b-- From nobody Thu Sep 25 14:02:51 2014 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 7C7F11A03A0 for ; Thu, 25 Sep 2014 14:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, 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 rem44xtLcxg3 for ; Thu, 25 Sep 2014 14:02:47 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DE401A0394 for ; Thu, 25 Sep 2014 14:02:47 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id 10so12564581lbg.24 for ; Thu, 25 Sep 2014 14:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vksd6w8zFmKY2ni5AFXuTsOcXs417aoRKfTmkk0rT+E=; b=jIheQxYxrnSDpFfd+zA5L+7nI4fArf1IpJ/OQ0RbmG30quy4/vEmYxgAX5Co/3msHj Ku72uoU1CyHqOrKkpq6LeV5xMXJqPL9oVVK51MmbRVwTUwegt9ZVFcdNNOgFP+XSJnzV GRv47WUnwRPhx48w/ql3IG3arpKMy26tBlU61yGoLM7sL1HWmmCr5K5uIAsWQKj7go5G w6+LhWHtM5+99QX9t1ljnjyOne9XR29s5bherLp6HF/E7GCXhH/ePy7q44eVXnki1viz HjBWNkP3dFXvcffxmD/HKCdtVJUkjwk5s59gf0iiNolQaC4LeX/Wwn+sIDz6OgdB8btv r8kg== MIME-Version: 1.0 X-Received: by 10.112.75.233 with SMTP id f9mr5387442lbw.102.1411678965240; Thu, 25 Sep 2014 14:02:45 -0700 (PDT) Received: by 10.112.13.99 with HTTP; Thu, 25 Sep 2014 14:02:45 -0700 (PDT) In-Reply-To: <54224355.2070300@seantek.com> References: <54224355.2070300@seantek.com> Date: Thu, 25 Sep 2014 23:02:45 +0200 Message-ID: From: Melvin Carvalho To: Sean Leonard Content-Type: multipart/alternative; boundary=14dae9cfce76429ab60503ea1faa Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/19C2Xl20FCBYP6SR9_Oc6ZNiIaY Cc: Benjamin Young , Apps Discuss Subject: Re: [apps-discuss] IRC URIs to denote users X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 21:02:49 -0000 --14dae9cfce76429ab60503ea1faa Content-Type: text/plain; charset=UTF-8 On 24 September 2014 06:06, Sean Leonard wrote: > On 9/22/2014 1:50 PM, Melvin Carvalho wrote: > >> I was wondering if IRC URIs are standardized at all? >> >> The latest I found was : >> >> http://tools.ietf.org/html/draft-butcher-irc-url-04 >> >> I have a use case of marking reputation from one system (web chat room) >> to an IRC chat room, but I require an identifier for the user. >> >> The suggestions so far have been: >> >> irc://user@host >> irc://user@host/ -- trailing slash >> irc:user@host -- similar to xmpp >> irc://host/#user -- fragment could be problematic as per RFC 9386 >> >> I've gone with the second option for the moment >> >> Any pointers would be most welcome. >> > > Based on the options presented, I think the third one, irc:user@host, > best captures the spirit of the URI syntax. > > RFC 3986 Section 3 and 4.3 define absolute URIs as scheme : hier-part; > hier-part can be one of: > "//" authority path-abempty > path-absolute > path-rootless > path-empty > > The first one is usually used for identifying resources accessible via > some Internet-related protocol where the authority is a host:port (plus > optional userinfo to log in to the host:port), followed by some > server-specific path to the resource (usually hierarchical). The second one > is for some server-specific path (usually hierarchical), where the server's > host:port are "obvious". For example, > means "an LDAP URL referring to the University of Michigan entry, available > from an LDAP server of the client's choosing" (RFC 4516 Section 4). > URIs (URLs) refer to the local file system. > > The fourth one, path-empty, isn't used much...but the gist (I suppose) is > if you want to skip right to the ? query or # fragment parts. magnet: > (provisional) URIs use this. > > Thus, we arrive at path-rootless, which is basically "Everything Else". In > this case, you are trying basically to identify an IRC object (a user), and > tag it in such a way that it's not an e-mail address. > looks like an e-mail address. looks the best to > me; it's obviously not an e-mail address. Similarly, it's obviously not an > address to an IRC channel. If you say irc://host/user, you're sharing the > channel namespace with the user namespace...not a great idea. If you say > irc://host/#user, you are saying that the path is "/", which (in the > context of users/nicknames) doesn't make a whole lot of sense since > users/nicknames are specific to servers/hosts, not to sub-parts of > servers/hosts. > > The telnet: URL/URI is the most analogous to irc URIs--and telnet URLs go > way back to Tim Berners-Lee's [original paper]. In the original, it's > telnet://userinfo@host:port -- with no trailing slash (i.e., authority > path-abempty). In RFC 1738 sec. 3.8, it's telnet://userinfo@host:port/ -- > with trailing slash (i.e., authority path-abempty). > > The ssh URI proposal (draft-ietf-secsh-scp-sftp-ssh-uri-04) has no > trailing slash...but it also says that the path part is irrelevant. In any > event, the overall gist is that "//" at the beginning is sufficient to > distinguish "network paths" from "other things". > Thank you I like this alot. I think it makes most sense for my implementation, at this point in time. > > Sean > > [original paper]: http://citeseerx.ist.psu.edu/ > viewdoc/summary?doi=10.1.1.45.1836 "Universal Document Identifiers on the > Network" > > --14dae9cfce76429ab60503ea1faa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 24 September 2014 06:06, Sean Leonard <dev+ietf@seantek.com= > wrote:
On 9/22/2014 1:50 PM, Melvin Carvalho wrote:=
I was wondering if IRC URIs are standardized at all?

The latest I found was :

http://tools.ietf.org/html/draft-butcher-irc-url-04

I have a use case of marking reputation from one system (web chat room) to = an IRC chat room, but I require an identifier for the user.

The suggestions so far have been:

irc://user@host
irc://user@host/ -- trailing slash
irc:user@host -- similar to xmpp
irc://host/#user -- fragment could be problematic as per RFC 9386

I've gone with the second option for the moment

Any pointers would be most welcome.

Based on the options presented, I think the third one, irc:user@host, best = captures the spirit of the URI syntax.

RFC 3986 Section 3 and 4.3 define absolute URIs as scheme : hier-part; hier= -part can be one of:
"//" authority path-abempty
path-absolute
path-rootless
path-empty

The first one is usually used for identifying resources accessible via some= Internet-related protocol where the authority is a host:port (plus optiona= l userinfo to log in to the host:port), followed by some server-specific pa= th to the resource (usually hierarchical). The second one is for some serve= r-specific path (usually hierarchical), where the server's host:port ar= e "obvious". For example, <ldap:///o=3DUniversity%20of%= 20Michigan,c=3DUS> means "an LDAP URL referring to the University o= f Michigan entry, available from an LDAP server of the client's choosin= g" (RFC 4516 Section 4). <file:///> URIs (URLs) refer to the loc= al file system.

The fourth one, path-empty, isn't used much...but the gist (I suppose) = is if you want to skip right to the ? query or # fragment parts. magnet: (p= rovisional) URIs use this.

Thus, we arrive at path-rootless, which is basically "Everything Else&= quot;. In this case, you are trying basically to identify an IRC object (a = user), and tag it in such a way that it's not an e-mail address. <user@example.com>= ; looks like an e-mail address. <irc:user@example.com> looks the best to me; it&= #39;s obviously not an e-mail address. Similarly, it's obviously not an= address to an IRC channel. If you say irc://host/user, you're sharing = the channel namespace with the user namespace...not a great idea. If you sa= y irc://host/#user, you are saying that the path is "/", which (i= n the context of users/nicknames) doesn't make a whole lot of sense sin= ce users/nicknames are specific to servers/hosts, not to sub-parts of serve= rs/hosts.

The telnet: URL/URI is the most analogous to irc URIs--and telnet URLs go w= ay back to Tim Berners-Lee's [original paper]. In the original, it'= s telnet://userinfo@host:port -- with no trailing slash (i.e., authority pa= th-abempty). In RFC 1738 sec. 3.8, it's telnet://userinfo@host:port/ --= with trailing slash (i.e., authority path-abempty).

The ssh URI proposal (draft-ietf-secsh-scp-sftp-ssh-uri-04) has no t= railing slash...but it also says that the path part is irrelevant. In any e= vent, the overall gist is that "//" at the beginning is sufficien= t to distinguish "network paths" from "other things".

Thank you

<irc:user@example.com>
=
I like this alot.=C2=A0 I think it makes most sense for my i= mplementation, at this point in time.
=C2=A0

Sean

[original paper]: http://citeseerx.ist.psu.edu/= viewdoc/summary?doi=3D10.1.1.45.1836 "Universal Document Id= entifiers on the Network"


--14dae9cfce76429ab60503ea1faa-- From nobody Thu Sep 25 18:13:28 2014 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 B5DF81A010F for ; Thu, 25 Sep 2014 18:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUMX0XSVyYrH for ; Thu, 25 Sep 2014 18:13:24 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECAF81A00A3 for ; Thu, 25 Sep 2014 18:13:23 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id a108so8310363qge.41 for ; Thu, 25 Sep 2014 18:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=TNlyHcIuukYy/zbbVC1EUF1JMCVOYFr6lhd5zHBwDa4=; b=PNd24yhb7G15p/LRG1Xri0O+3ORzvdIWGq9ofKoEKMMjy76Gu2mnBW5BwCNE398PMF Yxs40ZkuUAcB73YnCR93jROdHrZxhYl8uLutMzXiS2UGdYnmBW6RSSWmemSgsyiSOew8 wnjUujgHKwY3gtZT4JwE25wh7kmb4/d2gyFUMgNH4OBRRz0dU00NY4khFIeWRvf2Vt1L PxBQMiBScN0vaQ6liLIbrdeHOFOX3jIfWiylzNw2Cx3ed3hpfThS22glwvlylQ6QVOq/ 8TR/aZR8Pkz8VZmrPQKh4hOV89On/i6nahXprVmPF4liOvEeIBuwMniSLLLfHQz4xM67 QJdw== MIME-Version: 1.0 X-Received: by 10.140.101.205 with SMTP id u71mr25991899qge.48.1411694002993; Thu, 25 Sep 2014 18:13:22 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.140.25.150 with HTTP; Thu, 25 Sep 2014 18:13:22 -0700 (PDT) In-Reply-To: References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> Date: Fri, 26 Sep 2014 11:13:22 +1000 X-Google-Sender-Auth: hToeFICQxxnWfG6Kec0Pl3sul8I Message-ID: From: Matthew Kerwin To: IETF Apps Discuss , uri@w3.org Content-Type: multipart/alternative; boundary=001a11c16530949ff70503ed9f23 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/D3M7151QXtTn_xsEOy0x4XLPCtQ Subject: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 01:13:25 -0000 --001a11c16530949ff70503ed9f23 Content-Type: text/plain; charset=UTF-8 FYI: this is my file URI draft, now listing apps-discuss as the official place for discussion. >>> A new version of I-D, draft-kerwin-file-scheme-13.txt has been successfully submitted by Matthew Kerwin and posted to the IETF repository. Name: draft-kerwin-file-scheme Revision: 13 Title: The file URI Scheme Document date: 2014-09-26 Group: Individual Submission Pages: 16 URL: http://www.ietf.org/internet-drafts/draft-kerwin-file-scheme-13.txt Status: https://datatracker.ietf.org/doc/draft-kerwin-file-scheme/ Htmlized: http://tools.ietf.org/html/draft-kerwin-file-scheme-13 Diff: http://www.ietf.org/rfcdiff?url2=draft-kerwin-file-scheme-13 Abstract: This document specifies the "file" Uniform Resource Identifier (URI) scheme, replacing the definition in RFC 1738. It attempts to document current practices, while at the same time defining a common core which is intended to interoperate across the broad spectrum of existing implementations. Note to Readers (To be removed by the RFC Editor) This draft should be discussed on the IETF Applications Area Working Group discussion list . Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Matthew Kerwin http://matthew.kerwin.net.au/ --001a11c16530949ff70503ed9f23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI: this is my file URI draft, now listing apps-discu= ss as the official place for discussion.

>>>= ;

A new version of I-D, draft-kerwin-file-scheme-13.txt
has been successfully submitted by Matthew Kerwin and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-kerwin-file-scheme
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A013
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The file URI Scheme
Document date:=C2=A0 2014-09-26
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 16
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http:/= /www.ietf.org/internet-drafts/draft-kerwin-file-scheme-13.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.= ietf.org/doc/draft-kerwin-file-scheme/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html/dr= aft-kerwin-file-scheme-13
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.= ietf.org/rfcdiff?url2=3Ddraft-kerwin-file-scheme-13

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

=C2=A0 =C2=A0It attempts to document current practices, while at the same t= ime
=C2=A0 =C2=A0defining a common core which is intended to interoperate acros= s the
=C2=A0 =C2=A0broad spectrum of existing implementations.

Note to Readers (To be removed by the RFC Editor)

=C2=A0 =C2=A0This draft should be discussed on the IETF Applications Area W= orking
=C2=A0 =C2=A0Group discussion list <apps-discuss@ietf.org>.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
=C2=A0 M= atthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a11c16530949ff70503ed9f23-- From nobody Fri Sep 26 00:19:26 2014 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 3DE581A1A69 for ; Fri, 26 Sep 2014 00:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.937 X-Spam-Level: X-Spam-Status: No, score=-0.937 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.786, 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 hSXCo0nqUZlf for ; Fri, 26 Sep 2014 00:19:22 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD891A1A70 for ; Fri, 26 Sep 2014 00:19:21 -0700 (PDT) Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id s8Q7JHR3001932 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Sep 2014 09:19:17 +0200 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id s8Q7JEfs001836; Fri, 26 Sep 2014 09:19:16 +0200 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Fri, 26 Sep 2014 09:19:14 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Matthew Kerwin In-Reply-To: Message-ID: References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wxGK_iH-JS8VX8oEkEzT95M9t5c Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 07:19:25 -0000 On Fri, 26 Sep 2014, Matthew Kerwin wrote: > http://www.ietf.org/internet-drafts/draft-kerwin-file-scheme-13.txt Hey, I too wouldn't mind seeing a refreshed and more accurate file: URI document. Around 9% of curl users say they use file:, which probably scales up to quite a large amount of people. I'm not convinced it is worth the trouble and the arguments to pull this draft into a real RFC. I have some problems with this draft as it currently stands. I would rather have a new spec straigten up and tighten the language somewhat so that we can get a stricter interpretation of how a file:// is supposed to work. Sure, there will then possibly be a few non-compliant parsers out there that accept a few non-standard formats but it should be clear to those who generates or writes file:// URIs which the correct way is. That way we could potentially move into a future with less file:// URI variations rather than more. The rest of my comments are based on this basic stand. This document rather opens up pandora's box for someone like me. Suddenly this claims that all sorts of horrid abuses (in my view) we've seen through the years are fine and should be supported by my parser (if I want to be compliant) and it would surprise me if not a few other parser authors don't feel the same. I also think that the 'host' part of the file: URI was a mistake to begin with. It was always a mystery to readers of RFC1738 and I think it should be better clarified here as well that it is useless and not interoperable. The query part. It didn't exist in 1738, so introducing that now will break a lot of old parsers (like mine) even if I recognize that 3986 says that it should be supported globally. This, for just a vague extension model without any clear purpose or use case. -- / daniel.haxx.se From nobody Fri Sep 26 01:10:47 2014 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 4901F1A1A9B for ; Fri, 26 Sep 2014 01:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.577 X-Spam-Level: X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786] 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 OEA_NcMoN9c0 for ; Fri, 26 Sep 2014 01:10:31 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id EF6441A1A9C for ; Fri, 26 Sep 2014 01:09:47 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 9C91C32E54A; Fri, 26 Sep 2014 17:09:02 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 1b90_f55a_321acc43_5add_4082_9fef_2075bf7ef5f9; Fri, 26 Sep 2014 17:09:02 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id CAFABBFBBA; Fri, 26 Sep 2014 17:09:01 +0900 (JST) Message-ID: <54251F1C.4030505@it.aoyama.ac.jp> Date: Fri, 26 Sep 2014 17:09:00 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Daniel Stenberg , Matthew Kerwin References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8KtJmjwRF0ghAhQcVFlyE81WLKw Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 08:10:35 -0000 On 2014/09/26 16:19, Daniel Stenberg wrote: > On Fri, 26 Sep 2014, Matthew Kerwin wrote: > >> http://www.ietf.org/internet-drafts/draft-kerwin-file-scheme-13.txt > > Hey, > > I too wouldn't mind seeing a refreshed and more accurate file: URI > document. Around 9% of curl users say they use file:, which probably > scales up to quite a large amount of people. I'm not convinced it is > worth the trouble and the arguments to pull this draft into a real RFC. > > I have some problems with this draft as it currently stands. > > I would rather have a new spec straigten up and tighten the language > somewhat so that we can get a stricter interpretation of how a file:// > is supposed to work. Sure, there will then possibly be a few > non-compliant parsers out there that accept a few non-standard formats > but it should be clear to those who generates or writes file:// URIs > which the correct way is. That way we could potentially move into a > future with less file:// URI variations rather than more. The rest of my > comments are based on this basic stand. I think this would be ideal, but there's really a lot of 'crap' out there in the case of the file: scheme. So it may make sense to: a) Document the core syntax for people creating new URIs, and parsers that want to be strict. b) Document frequently seen (and rather widely accepted) variations to help people who want (or have) to implement lenitent parsers. This should very clearly be labeled as optional. > This document rather opens up pandora's box for someone like me. > Suddenly this claims that all sorts of horrid abuses (in my view) we've > seen through the years are fine and should be supported by my parser (if > I want to be compliant) and it would surprise me if not a few other > parser authors don't feel the same. > > I also think that the 'host' part of the file: URI was a mistake to > begin with. It was always a mystery to readers of RFC1738 and I think it > should be better clarified here as well that it is useless and not > interoperable. > > The query part. It didn't exist in 1738, so introducing that now will > break a lot of old parsers (like mine) even if I recognize that 3986 > says that it should be supported globally. This, for just a vague > extension model without any clear purpose or use case. It is the first time that I have seen somebody claim that RFC 3986 says that all URI schemes have to support query parts. I'd like to know where in RFC 3986 you found that. Indeed my understanding is that most schemes don't understand or include query parts. The main (but very important) exceptions as far as I'm aware of are http:/https: and mailto:. Regards, Martin. From nobody Fri Sep 26 01:42:02 2014 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 58EC61A004D for ; Fri, 26 Sep 2014 01:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.037 X-Spam-Level: X-Spam-Status: No, score=-4.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.786, 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 Fg43r-b9b-M6 for ; Fri, 26 Sep 2014 01:41:58 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 763311A0016 for ; Fri, 26 Sep 2014 01:41:57 -0700 (PDT) Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id s8Q8fsXj030851 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Sep 2014 10:41:54 +0200 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id s8Q8fqG8030834; Fri, 26 Sep 2014 10:41:52 +0200 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Fri, 26 Sep 2014 10:41:52 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: =?ISO-8859-15?Q?Martin_J=2E_D=FCrst?= In-Reply-To: <54251F1C.4030505@it.aoyama.ac.jp> Message-ID: References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54251F1C.4030505@it.aoyama.ac.jp> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1129329158-728051283-1411720913=:23141" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/5bsUiQH_mQTPok053ovQJpDbNPU Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 08:42:00 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1129329158-728051283-1411720913=:23141 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 26 Sep 2014, "Martin J. Dürst" wrote: >> The query part. It didn't exist in 1738, so introducing that now will break >> a lot of old parsers (like mine) even if I recognize that 3986 says that it >> should be supported globally. This, for just a vague extension model >> without any clear purpose or use case. > > It is the first time that I have seen somebody claim that RFC 3986 says that > all URI schemes have to support query parts. I'd like to know where in RFC > 3986 you found that. Indeed my understanding is that most schemes don't > understand or include query parts. The main (but very important) exceptions > as far as I'm aware of are http:/https: and mailto:. Maybe this is just me, but that's my reading of RFC 3986 section 3: 3. Syntax Components The generic URI syntax consists of a hierarchical sequence of components referred to as the scheme, authority, path, query, and fragment. There exists language in 3986 suggesting that things differ between protocols but reading that section 3 doesn't make it obvious to me that the query part can be opted out (even if as I already mentioned by own parsers do). Not even 3.4 that details query mentions that. Section 2.2 also lists '?' as a "Reserved character" also in a generic way and it is listed as a delimiter but then goes on to rather mysteriously say: "URI producing applications should percent-encode data octets that correspond to characters in the reserved set unless these characters are specifically allowed by the URI scheme to represent data in that component." ... but the file: section of RFC1738 doesn't mention what letters that are legal in the path part so it's not clear to me if '?' is a delimiter or part of the path, spec-wise. -- / daniel.haxx.se --1129329158-728051283-1411720913=:23141-- From nobody Fri Sep 26 03:08:18 2014 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 E21161A02E1 for ; Fri, 26 Sep 2014 03:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imiB7KGrJwDQ for ; Fri, 26 Sep 2014 03:08:12 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3C721A1AD1 for ; Fri, 26 Sep 2014 03:07:40 -0700 (PDT) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MO7im-1XakDW0lM4-005coc; Fri, 26 Sep 2014 12:07:22 +0200 Message-ID: <54253AD4.7070400@gmx.de> Date: Fri, 26 Sep 2014 12:07:16 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Daniel Stenberg , =?windows-1252?Q?=22Martin_J=2E_?= =?windows-1252?Q?D=FCrst=22?= References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54251F1C.4030505@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:9XEiGGsJsu8icS0xQzfQyIqlmTzzuEs6jGmHrDUuftLZFPtrtlr qFHPMHHuZNKwBm2hnrKPmGYS8sf6TqJ9FcjbAYxLjczrfAoXPB0zQ5sHS0jnhaJYIKxbb7w 1jHAUMY+y60L42Z6mCRBuf26BECn4Z+sGx8H9HASmOidC/8W86T7fKrQsKkILTuzKns0qi/ wlOPnNldxjXJdj7FxVQwg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/II0ON_z3GvkXN6badNvoid_9Fek Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 10:08:15 -0000 On 2014-09-26 10:41, Daniel Stenberg wrote: > On Fri, 26 Sep 2014, "Martin J. Dürst" wrote: > >>> The query part. It didn't exist in 1738, so introducing that now will >>> break a lot of old parsers (like mine) even if I recognize that 3986 >>> says that it should be supported globally. This, for just a vague >>> extension model without any clear purpose or use case. >> >> It is the first time that I have seen somebody claim that RFC 3986 >> says that all URI schemes have to support query parts. I'd like to >> know where in RFC 3986 you found that. Indeed my understanding is that >> most schemes don't understand or include query parts. The main (but >> very important) exceptions as far as I'm aware of are http:/https: and >> mailto:. > > Maybe this is just me, but that's my reading of RFC 3986 section 3: > > 3. Syntax Components > > The generic URI syntax consists of a hierarchical sequence of > components referred to as the scheme, authority, path, query, and > fragment. > > There exists language in 3986 suggesting that things differ between > protocols but reading that section 3 doesn't make it obvious to me that > the query part can be opted out (even if as I already mentioned by own > parsers do). Not even 3.4 that details query mentions that. > > Section 2.2 also lists '?' as a "Reserved character" also in a generic > way and it is listed as a delimiter but then goes on to rather > mysteriously say: > > "URI producing applications should percent-encode data octets that > correspond to characters in the reserved set unless these characters > are specifically allowed by the URI scheme to represent data in that > component." > > ... but the file: section of RFC1738 doesn't mention what letters that > are legal in the path part so it's not clear to me if '?' is a delimiter > or part of the path, spec-wise. > ... Yes, RFC 3986 defines a generic syntax. Of course individual schemes can profile that (query is not allowed, or query will be ignored). What we be bad is to deviate from the generic syntax with respect to delimiters. Best regards, Julian From nobody Fri Sep 26 04:43:50 2014 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 D5E391A1B3C for ; Fri, 26 Sep 2014 04:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_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 5zZV2hfjWHA9 for ; Fri, 26 Sep 2014 04:43:47 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::706]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB2F1A1B41 for ; Fri, 26 Sep 2014 04:43:46 -0700 (PDT) Received: from pc6 (86.184.59.221) by DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Fri, 26 Sep 2014 11:43:23 +0000 Message-ID: <011f01cfd97e$d64cd560$4001a8c0@gateway.2wire.net> From: t.petch To: =?iso-8859-1?Q?Martin_J._D=C3=BCrst?= , Daniel Stenberg , Matthew Kerwin References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54251F1C.4030505@it.aoyama.ac.jp> Date: Fri, 26 Sep 2014 12:36:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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.184.59.221] X-ClientProxiedBy: DB4PR03CA0012.eurprd03.prod.outlook.com (25.160.39.150) To DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB057; X-Forefront-PRVS: 03468CBA43 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(2473001)(24454002)(479174003)(51704005)(189002)(199003)(50226001)(80022003)(50986999)(76176999)(84392001)(44716002)(4396001)(87286001)(77982003)(20776003)(83072002)(79102003)(15975445006)(47776003)(104166001)(81342003)(90102001)(64706001)(77096002)(46102003)(77156001)(101416001)(95666004)(62966002)(74502003)(74662003)(62236002)(92726001)(33646002)(99396003)(23756003)(85306004)(106356001)(50466002)(61296003)(83322001)(93886004)(81686999)(89996001)(97736003)(81816999)(44736004)(107046002)(92566001)(116806002)(86362001)(15202345003)(19580405001)(66066001)(31966008)(76482002)(120916001)(85852003)(81542003)(93916002)(87976001)(19580395003)(105586002)(42186005)(88136002)(102836001)(230783001)(10300001)(21056001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB057; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/EvE_4gaIMDK-c0AntBXcVG8HnIo Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 11:43:49 -0000 ----- Original Message ----- From: "Martin J. Dürst" To: "Daniel Stenberg" ; "Matthew Kerwin" Cc: "IETF Apps Discuss" Sent: Friday, September 26, 2014 9:09 AM > On 2014/09/26 16:19, Daniel Stenberg wrote: > > On Fri, 26 Sep 2014, Matthew Kerwin wrote: > > > >> http://www.ietf.org/internet-drafts/draft-kerwin-file-scheme-13.txt > > > > Hey, > > > > I too wouldn't mind seeing a refreshed and more accurate file: URI > > document. Around 9% of curl users say they use file:, which probably > > scales up to quite a large amount of people. I'm not convinced it is > > worth the trouble and the arguments to pull this draft into a real RFC. > > > > I have some problems with this draft as it currently stands. > > > > I would rather have a new spec straigten up and tighten the language > > somewhat so that we can get a stricter interpretation of how a file:// > > is supposed to work. Sure, there will then possibly be a few > > non-compliant parsers out there that accept a few non-standard formats > > but it should be clear to those who generates or writes file:// URIs > > which the correct way is. That way we could potentially move into a > > future with less file:// URI variations rather than more. The rest of my > > comments are based on this basic stand. > > I think this would be ideal, but there's really a lot of 'crap' out > there in the case of the file: scheme. So it may make sense to: > a) Document the core syntax for people creating new URIs, and parsers > that want to be strict. > b) Document frequently seen (and rather widely accepted) variations to > help people who want (or have) to implement lenitent parsers. This > should very clearly be labeled as optional. That approach would motivate me. I think that getting rough consensus will be hard, since there is so much out in the wild and there will be those, probably at IETF Last Call, who will want their variations included or not excluded or who will want a blow-by-blow history. If we did no more than Obsolete RFC1738 s3.10, then I would see that as a valuable step forward. Perhaps have the core syntax as Normative and the frequently seen variations as Informative appendices. Tom Petch > > This document rather opens up pandora's box for someone like me. > > Suddenly this claims that all sorts of horrid abuses (in my view) we've > > seen through the years are fine and should be supported by my parser (if > > I want to be compliant) and it would surprise me if not a few other > > parser authors don't feel the same. > > > > I also think that the 'host' part of the file: URI was a mistake to > > begin with. It was always a mystery to readers of RFC1738 and I think it > > should be better clarified here as well that it is useless and not > > interoperable. > > > > The query part. It didn't exist in 1738, so introducing that now will > > break a lot of old parsers (like mine) even if I recognize that 3986 > > says that it should be supported globally. This, for just a vague > > extension model without any clear purpose or use case. > > It is the first time that I have seen somebody claim that RFC 3986 says > that all URI schemes have to support query parts. I'd like to know where > in RFC 3986 you found that. Indeed my understanding is that most schemes > don't understand or include query parts. The main (but very important) > exceptions as far as I'm aware of are http:/https: and mailto:. > > Regards, Martin. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Fri Sep 26 07:30:49 2014 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 CA07D1A88E6 for ; Fri, 26 Sep 2014 07:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 CmwzChPZrd_g for ; Fri, 26 Sep 2014 07:30:45 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2231A88A6 for ; Fri, 26 Sep 2014 07:30:45 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 69C7D509B6 for ; Fri, 26 Sep 2014 10:30:44 -0400 (EDT) Message-ID: <54257881.5050407@seantek.com> Date: Fri, 26 Sep 2014 07:30:25 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54251F1C.4030505@it.aoyama.ac.jp> <011f01cfd97e$d64cd560$4001a8c0@gateway.2wire.net> In-Reply-To: <011f01cfd97e$d64cd560$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/shLB91tsDhA9iecwexZI967w8WU Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 14:30:48 -0000 On 9/26/2014 4:36 AM, t.petch wrote: > ----- Original Message ----- > From: "Martin J. D=C3=BCrst" > To: "Daniel Stenberg" ; "Matthew Kerwin" > > Cc: "IETF Apps Discuss" > Sent: Friday, September 26, 2014 9:09 AM >> On 2014/09/26 16:19, Daniel Stenberg wrote: >>> On Fri, 26 Sep 2014, Matthew Kerwin wrote: >>> >>>> http://www.ietf.org/internet-drafts/draft-kerwin-file-scheme-13.txt >>> Hey, >>> >>> I too wouldn't mind seeing a refreshed and more accurate file: URI >>> document. Around 9% of curl users say they use file:, which probably >>> scales up to quite a large amount of people. I'm not convinced it is >>> worth the trouble and the arguments to pull this draft into a real > RFC. >>> I have some problems with this draft as it currently stands. >>> >>> I would rather have a new spec straigten up and tighten the language >>> somewhat so that we can get a stricter interpretation of how a > file:// >>> is supposed to work. Sure, there will then possibly be a few >>> non-compliant parsers out there that accept a few non-standard > formats >>> but it should be clear to those who generates or writes file:// URIs >>> which the correct way is. That way we could potentially move into a >>> future with less file:// URI variations rather than more. The rest > of my >>> comments are based on this basic stand. >> I think this would be ideal, but there's really a lot of 'crap' out >> there in the case of the file: scheme. So it may make sense to: >> a) Document the core syntax for people creating new URIs, and parsers >> that want to be strict. >> b) Document frequently seen (and rather widely accepted) variations to= >> help people who want (or have) to implement lenitent parsers. This >> should very clearly be labeled as optional. > That approach would motivate me. > > I think that getting rough consensus will be hard, since there is so > much out in the wild and there will be those, probably at IETF Last > Call, who will want their variations included or not excluded or who > will want a blow-by-blow history. A significant reason for the variations is that operating=20 systems/platforms map network file paths in some way into the file=20 system namespace...such as UNC paths. For the sake of implementation, at a minimum, URIs (even if provisional) = for network file paths such as SMB / CIFS [draft-crhertel-smb-url-12],=20 NFS [RFC2224], and AFP [draft-ietf-svrloc-afp-service, see also=20 https://www.iana.org/assignments/uri-schemes/prov/afp and=20 http://support.apple.com/kb/ht4538] should advance. They should also be=20 referenced in draft-kerwin-file-scheme as the better or "other" way to=20 do that sort of thing. Otherwise, I guarantee you that people will=20 continue to use file: "in diverse ways" to represent network paths. (Of=20 course, it should always be acceptable to use file: to represent mounted = network paths, since mounted network paths are part of the local file=20 system.) I think a blow-by-blow history should be done, if for no other reason=20 than to placate those who want it. If in fact sufficient people want it. = That depends on what makes it into the file URI spec. The best way=20 forward would be a separate I-D that discusses the history, making it=20 informational or BCP. Sean From nobody Fri Sep 26 09:35:46 2014 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 AA32F1A8980 for ; Fri, 26 Sep 2014 09:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.386 X-Spam-Level: X-Spam-Status: No, score=-5.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786] 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 DSDoLaUMblxI for ; Fri, 26 Sep 2014 09:35:40 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75CDF1A1BCB for ; Fri, 26 Sep 2014 09:35:40 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XXYUd-0009DB-1R; Fri, 26 Sep 2014 12:35:39 -0400 Date: Fri, 26 Sep 2014 12:35:33 -0400 From: John C Klensin To: Daniel Stenberg Message-ID: <9E29A8FAC1906857724D1D7A@JcK-HP8200.jck.com> In-Reply-To: References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54251F1C.4030505@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0vSswo8zAgts7qXXIIgKdfvv6is Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 16:35:42 -0000 FWIW, This discussion of a series of connected questions such as: -- what elements of the RFC 3986 definition are expected to be used by all URI types,=20 -- whether 3968 specifies semantics for those elements or whether what appear to be its semantic definitions and restrictions are just examples that can be replaced on a per-scheme basis,=20 -- which elements can be eliminated by a per-scheme profile, and=20 -- under what circumstances delimiters that might be associated with a particular URI component (or element) type can be used for something else if that component is not used by that scheme, dominated the discussions in URNBIS for some months, exploded briefly onto the IETF list after the now-dead draft-ietf-urnbis-urns-are-not-uris draft was posted as an early attempt to deal with the disagreements, and has been the source of a great many "it means X, no, it means Y and maybe not-X" exchanges among normally reasonable people. May I suggest that it would be desirable to avoid repeating that discussion here, either for the specific case of "file://" or for the next URI proposal to come along that does not closely align with the "http:" UNL model? It seems to me that a review of the URNBIS discussion archive for the last nine months (there was less traffic there than one might have wished for) and minutes of the Toronto (IETF 90) WG meeting might be in order, as would be some leadership from WG Chairs and ADs? As a more or less rhetorical question, if we really can't agree on what 3986 says and means, is it time to freeze _all_ new and revised URI definitions and registrations until it is possible to develop and complete a clarification to that rather basic document? thanks, john --On Friday, September 26, 2014 10:41 +0200 Daniel Stenberg wrote: > On Fri, 26 Sep 2014, "Martin J. D=C3=BCrst" wrote: >=20 >>> The query part. It didn't exist in 1738, so introducing that >>> now will break a lot of old parsers (like mine) even if I >>> recognize that 3986 says that it should be supported >>> globally. This, for just a vague extension model without >>> any clear purpose or use case. >>=20 >> It is the first time that I have seen somebody claim that RFC >> 3986 says that all URI schemes have to support query parts. >> I'd like to know where in RFC 3986 you found that. Indeed my >> understanding is that most schemes don't understand or >> include query parts. The main (but very important) exceptions = >> as far as I'm aware of are http:/https: and mailto:. >=20 > Maybe this is just me, but that's my reading of RFC 3986 > section 3: >=20 > 3. Syntax Components >=20 > The generic URI syntax consists of a hierarchical sequence > of > components referred to as the scheme, authority, path, > query, and > fragment. >=20 > There exists language in 3986 suggesting that things differ > between protocols but reading that section 3 doesn't make it > obvious to me that the query part can be opted out (even if as > I already mentioned by own parsers do). Not even 3.4 that > details query mentions that. >=20 > Section 2.2 also lists '?' as a "Reserved character" also in a > generic way and it is listed as a delimiter but then goes on > to rather mysteriously say: >=20 > "URI producing applications should percent-encode data > octets that > correspond to characters in the reserved set unless these > characters > are specifically allowed by the URI scheme to represent > data in that > component." >=20 > ... but the file: section of RFC1738 doesn't mention what > letters that are legal in the path part so it's not clear to > me if '?' is a delimiter or part of the path, spec-wise. From nobody Fri Sep 26 11:49:58 2014 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 E89231A0208 for ; Fri, 26 Sep 2014 11:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCAVShz88DHY for ; Fri, 26 Sep 2014 11:49:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0739.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::739]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05BAD1A0024 for ; Fri, 26 Sep 2014 11:49:46 -0700 (PDT) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB410.namprd03.prod.outlook.com (10.141.141.16) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Fri, 26 Sep 2014 18:49:22 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.1034.003; Fri, 26 Sep 2014 18:49:22 +0000 From: Dave Thaler To: Melvin Carvalho , Ira McDonald , Benjamin Young Thread-Topic: [apps-discuss] IRC URIs to denote users Thread-Index: AQHP1qbd0t7CQ5V7h0mVwYstWWgPoZwN0SqAgADL8gCABSmWUA== Date: Fri, 26 Sep 2014 18:49:22 +0000 Message-ID: <03cbd1281c9646e594e47d934a565ebc@BY2PR03MB412.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e0:ee43::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB410; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(243025005)(377454003)(51914003)(199003)(24454002)(189002)(10300001)(106116001)(105586002)(120916001)(95666004)(19580405001)(19625215002)(83322001)(92566001)(99286002)(19580395003)(74316001)(21056001)(31966008)(76576001)(99396003)(106356001)(85306004)(15395725005)(64706001)(16236675004)(87936001)(20776003)(19300405004)(76176999)(4396001)(33646002)(108616004)(50986999)(90102001)(54356999)(107046002)(15202345003)(19609705001)(15975445006)(74502003)(97736003)(19273905006)(80022003)(101416001)(76482002)(19617315012)(83072002)(85852003)(2656002)(77982003)(46102003)(81342003)(81542003)(86362001)(86612001)(74662003)(79102003)(24736002)(16351025005)(3826002)(563064011); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB410; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_03cbd1281c9646e594e47d934a565ebcBY2PR03MB412namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3aLnTAvciFaiDHxLYOBalOHriTk Cc: Apps Discuss Subject: Re: [apps-discuss] IRC URIs to denote users X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 18:49:55 -0000 --_000_03cbd1281c9646e594e47d934a565ebcBY2PR03MB412namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhvc2UgcmVnaXN0cmF0aW9ucyB3ZXJlIHBhcnQgb2YgdGhlIOKAnFVSSSBCdWxrIFRoaXJkLVBh cnR5IFJlZ2lzdHJhdGlvbiBFeHBlcmltZW504oCdLg0KRm9yIG1vcmUgaW5mbyBvbiB0aGF0IGV4 cGVyaW1lbnQsIHNlZSB0aGUgc2xpZGVzIGZyb20gSUVURiA4NToNCmh0dHA6Ly93d3cuaWV0Zi5v cmcvcHJvY2VlZGluZ3MvODUvc2xpZGVzL3NsaWRlcy04NS1pcmktOC5wZGYNCg0KLURhdmUNCg0K RnJvbTogYXBwcy1kaXNjdXNzIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBNZWx2aW4gQ2FydmFsaG8NClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAy MywgMjAxNCA0OjU1IEFNDQpUbzogSXJhIE1jRG9uYWxkOyBCZW5qYW1pbiBZb3VuZw0KQ2M6IEFw cHMgRGlzY3Vzcw0KU3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3NdIElSQyBVUklzIHRvIGRlbm90 ZSB1c2Vycw0KDQoNCg0KT24gMjMgU2VwdGVtYmVyIDIwMTQgMDE6NDUsIElyYSBNY0RvbmFsZCA8 Ymx1ZXJvb2ZtdXNpY0BnbWFpbC5jb208bWFpbHRvOmJsdWVyb29mbXVzaWNAZ21haWwuY29tPj4g d3JvdGU6DQpIaSBNZWx2aW4sDQpUaGUgY3VycmVudCBJQU5BIFVSSSBTY2hlbWVzIHJlZ2lzdHJ5 IGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcNCnRocmVlIHNjaGVtZXM6DQoNCmlyYw0KDQpwcm92L2ly YzxodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3VyaS1zY2hlbWVzL3Byb3YvaXJjPg0K DQppcmMNCg0KW0RhdmVfVGhhbGVyPGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvdXJp LXNjaGVtZXMvdXJpLXNjaGVtZXMueGh0bWwjRGF2ZV9UaGFsZXI+XQ0KDQppcmM2DQoNCnByb3Yv aXJjNjxodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3VyaS1zY2hlbWVzL3Byb3YvaXJj Nj4NCg0KaXJjNg0KDQpbRGF2ZV9UaGFsZXI8aHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50 cy91cmktc2NoZW1lcy91cmktc2NoZW1lcy54aHRtbCNEYXZlX1RoYWxlcj5dDQoNCmlyY3MNCg0K cHJvdi9pcmNzPGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvdXJpLXNjaGVtZXMvcHJv di9pcmNzPg0KDQppcmNzDQoNCltEYXZlX1RoYWxlcjxodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2ln bm1lbnRzL3VyaS1zY2hlbWVzL3VyaS1zY2hlbWVzLnhodG1sI0RhdmVfVGhhbGVyPl0NCg0KDQpB bGwgdGhyZWUgb2YgdGhvc2UgYXJlIFNlcHRlbWJlciAyMDEyIHByb3Zpc2lvbmFsIHJlZ2lzdHJh dGlvbnMNCih3aXRoIHJlZmVyZW5jZXMgdGhhdCBpbmNsdWRlIGJ1dGNoZXIgYW5kIGRyYWZ0LW1p cmFzaGktdXJsLWlyYy0wMSkuDQoNClRoYW5rcyBmb3IgdGhlIGluZm8hDQpCb3RoIHRoZSByZWZl cmVuY2VkIHNwZWNzIHNlZW0gcXVpdGUgb2xkLiAgSSB0aGluayB0aGVyZSB3YXMgYSB0aW1lIHdo ZW4gRGF2ZSBUaGFsZXIganVzdCBwdXQgYSB0b24gb2YgVVJJIHNwZWNzIGluIHRoZSBwcm92aXNp b25hbCBxdWV1ZSwgd2l0aG91dCBuZWNlc3NhcmlseSBtYWpvciB1cGRhdGVzLg0KSXQncyBzdGls bCBub3QgMTAwJSBjbGVhciB3aGF0IHRoZSBiZXN0IHBhdHRlcm4gaXMsIGlmIGFueS4NClVubGVz cyB0aGVyZSdzIGFuIG9iamVjdGlvbiBtYXkgSSBwcm9wb3NlOg0KDQppcmM6Ly91c2VyQGhvc3Qv DQpUaGlzIGlzIHZlcnkgbXVjaCBpbiBsaW5lIHdpdGggdGhlIHdvcmsgb2YgQmVuIFlvdW5nIChj YydkKQ0KDQpodHRwOi8vdXNlcmluZm8ubWUvDQpXaG8gcHJvcG9zZXMgYSBuZWF0IHdheSB0byBn ZXQgdXNlciBwcm9maWxlIGluZm8gdmlhIEhUVFAgYXM6DQpodHRwOi8vdXNlckBob3N0Lw0KSSBi ZWxpZXZlIHRoZSBpbnRlbnRpb24gb2YgdGhpcyBpcyB0byB3cml0ZSBhbiBSRkMsIHNvIEknZCBs aWtlIHRvIGFsaWduIGZ1dHVyZSB3b3JrIHdpdGggdGhhdCBpZiBwb3NzaWJsZQ0KDQoNCkNoZWVy cywNCi0gSXJhDQoNCklyYSBNY0RvbmFsZCAoTXVzaWNpYW4gLyBTb2Z0d2FyZSBBcmNoaXRlY3Qp DQpDby1DaGFpciAtIFRDRyBUcnVzdGVkIE1vYmlsaXR5IFNvbHV0aW9ucyBXRw0KQ2hhaXIgLSBM aW51eCBGb3VuZGF0aW9uIE9wZW4gUHJpbnRpbmcgV0cNClNlY3JldGFyeSAtIElFRUUtSVNUTyBQ cmludGVyIFdvcmtpbmcgR3JvdXANCkNvLUNoYWlyIC0gSUVFRS1JU1RPIFBXRyBJbnRlcm5ldCBQ cmludGluZyBQcm90b2NvbCBXRw0KSUVURiBEZXNpZ25hdGVkIEV4cGVydCAtIElQUCAmIFByaW50 ZXIgTUlCDQpCbHVlIFJvb2YgTXVzaWMgLyBIaWdoIE5vcnRoIEluYw0KaHR0cDovL3NpdGVzLmdv b2dsZS5jb20vc2l0ZS9ibHVlcm9vZm11c2ljDQpodHRwOi8vc2l0ZXMuZ29vZ2xlLmNvbS9zaXRl L2hpZ2hub3J0aGluYw0KbWFpbHRvOiBibHVlcm9vZm11c2ljQGdtYWlsLmNvbTxtYWlsdG86Ymx1 ZXJvb2ZtdXNpY0BnbWFpbC5jb20+DQpXaW50ZXIgIDU3OSBQYXJrIFBsYWNlICBTYWxpbmUsIE1J ICA0ODE3NiAgNzM0LTk0NC0wMDk0PHRlbDo3MzQtOTQ0LTAwOTQ+DQpTdW1tZXIgIFBPIEJveCAy MjEgIEdyYW5kIE1hcmFpcywgTUkgNDk4MzkgIDkwNi00OTQtMjQzNDx0ZWw6OTA2LTQ5NC0yNDM0 Pg0KDQpPbiBNb24sIFNlcCAyMiwgMjAxNCBhdCA0OjUwIFBNLCBNZWx2aW4gQ2FydmFsaG8gPG1l bHZpbmNhcnZhbGhvQGdtYWlsLmNvbTxtYWlsdG86bWVsdmluY2FydmFsaG9AZ21haWwuY29tPj4g d3JvdGU6DQpJIHdhcyB3b25kZXJpbmcgaWYgSVJDIFVSSXMgYXJlIHN0YW5kYXJkaXplZCBhdCBh bGw/DQpUaGUgbGF0ZXN0IEkgZm91bmQgd2FzIDoNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtYnV0Y2hlci1pcmMtdXJsLTA0DQpJIGhhdmUgYSB1c2UgY2FzZSBvZiBtYXJraW5n IHJlcHV0YXRpb24gZnJvbSBvbmUgc3lzdGVtICh3ZWIgY2hhdCByb29tKSB0byBhbiBJUkMgY2hh dCByb29tLCBidXQgSSByZXF1aXJlIGFuIGlkZW50aWZpZXIgZm9yIHRoZSB1c2VyLg0KVGhlIHN1 Z2dlc3Rpb25zIHNvIGZhciBoYXZlIGJlZW46DQppcmM6Ly91c2VyQGhvc3QNCmlyYzovL3VzZXJA aG9zdC8gLS0gdHJhaWxpbmcgc2xhc2gNCmlyYzp1c2VyQGhvc3QgLS0gc2ltaWxhciB0byB4bXBw DQppcmM6Ly9ob3N0LyN1c2VyIC0tIGZyYWdtZW50IGNvdWxkIGJlIHByb2JsZW1hdGljIGFzIHBl ciBSRkMgOTM4Ng0KSSd2ZSBnb25lIHdpdGggdGhlIHNlY29uZCBvcHRpb24gZm9yIHRoZSBtb21l bnQNCg0KQW55IHBvaW50ZXJzIHdvdWxkIGJlIG1vc3Qgd2VsY29tZS4NCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KYXBwcy1kaXNjdXNzIG1haWxp bmcgbGlzdA0KYXBwcy1kaXNjdXNzQGlldGYub3JnPG1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vzcw0K DQoNCg== --_000_03cbd1281c9646e594e47d934a565ebcBY2PR03MB412namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjo3MC44 NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaG9z ZSByZWdpc3RyYXRpb25zIHdlcmUgcGFydCBvZiB0aGUg4oCcVVJJIEJ1bGsgVGhpcmQtUGFydHkg UmVnaXN0cmF0aW9uIEV4cGVyaW1lbnTigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkZvciBtb3JlIGluZm8gb24gdGhhdCBleHBlcmltZW50LCBzZWUgdGhlIHNsaWRlcyBmcm9tIElF VEYgODU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHA6Ly93d3cu aWV0Zi5vcmcvcHJvY2VlZGluZ3MvODUvc2xpZGVzL3NsaWRlcy04NS1pcmktOC5wZGYiPmh0dHA6 Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODUvc2xpZGVzL3NsaWRlcy04NS1pcmktOC5wZGY8 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4tRGF2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IGFwcHMtZGlzY3VzcyBbbWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NZWx2aW4gQ2FydmFsaG88YnI+DQo8Yj5TZW50Ojwv Yj4gVHVlc2RheSwgU2VwdGVtYmVyIDIzLCAyMDE0IDQ6NTUgQU08YnI+DQo8Yj5Ubzo8L2I+IEly YSBNY0RvbmFsZDsgQmVuamFtaW4gWW91bmc8YnI+DQo8Yj5DYzo8L2I+IEFwcHMgRGlzY3Vzczxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2FwcHMtZGlzY3Vzc10gSVJDIFVSSXMgdG8gZGVub3Rl IHVzZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIzIFNl cHRlbWJlciAyMDE0IDAxOjQ1LCBJcmEgTWNEb25hbGQgJmx0OzxhIGhyZWY9Im1haWx0bzpibHVl cm9vZm11c2ljQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJsdWVyb29mbXVzaWNAZ21haWwu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgTWVsdmluLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY3VycmVudCBJQU5BIFVSSSBTY2hl bWVzIHJlZ2lzdHJ5IGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcNCjxicj4NCnRocmVlIHNjaGVtZXM6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxs cGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1 cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aXJjPG86cD48L286cD48L3A+ DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVu dHMvdXJpLXNjaGVtZXMvcHJvdi9pcmMiIHRhcmdldD0iX2JsYW5rIj5wcm92L2lyYzwvYT4NCjxv OnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVw dCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pcmM8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+ DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+WzxhIGhyZWY9Imh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvdXJp LXNjaGVtZXMvdXJpLXNjaGVtZXMueGh0bWwjRGF2ZV9UaGFsZXIiIHRhcmdldD0iX2JsYW5rIj5E YXZlX1RoYWxlcjwvYT5dPG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBz dHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5pcmM2PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0 IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6 Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvdXJpLXNjaGVtZXMvcHJvdi9pcmM2IiB0YXJnZXQ9 Il9ibGFuayI+cHJvdi9pcmM2PC9hPg0KPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxl PSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmlyYzY8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1 cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WzxhIGhyZWY9Imh0dHA6Ly93 d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvdXJpLXNjaGVtZXMvdXJpLXNjaGVtZXMueGh0bWwjRGF2 ZV9UaGFsZXIiIHRhcmdldD0iX2JsYW5rIj5EYXZlX1RoYWxlcjwvYT5dPG86cD48L286cD48L3A+ DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVw dCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pcmNzPG86cD48L286cD48L3A+DQo8L3Rk Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvdXJp LXNjaGVtZXMvcHJvdi9pcmNzIiB0YXJnZXQ9Il9ibGFuayI+cHJvdi9pcmNzPC9hPg0KPG86cD48 L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43 NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmlyY3M8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8 dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+WzxhIGhyZWY9Imh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvdXJpLXNj aGVtZXMvdXJpLXNjaGVtZXMueGh0bWwjRGF2ZV9UaGFsZXIiIHRhcmdldD0iX2JsYW5rIj5EYXZl X1RoYWxlcjwvYT5dPG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3Rh YmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsbCB0aHJlZSBvZiB0aG9zZSBhcmUgU2VwdGVtYmVyIDIw MTIgcHJvdmlzaW9uYWwgcmVnaXN0cmF0aW9uczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4od2l0aCByZWZlcmVuY2VzIHRoYXQgaW5jbHVkZSBidXRjaGVyIGFu ZCBkcmFmdC1taXJhc2hpLXVybC1pcmMtMDEpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGFua3MgZm9yIHRoZSBpbmZvITxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij5Cb3RoIHRoZSByZWZlcmVuY2VkIHNwZWNzIHNlZW0gcXVpdGUgb2xk LiZuYnNwOyBJIHRoaW5rIHRoZXJlIHdhcyBhIHRpbWUgd2hlbiBEYXZlIFRoYWxlciBqdXN0IHB1 dCBhIHRvbiBvZiBVUkkgc3BlY3MgaW4gdGhlIHByb3Zpc2lvbmFsIHF1ZXVlLCB3aXRob3V0IG5l Y2Vzc2FyaWx5IG1ham9yIHVwZGF0ZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkl0J3Mgc3Rp bGwgbm90IDEwMCUgY2xlYXIgd2hhdCB0aGUgYmVzdCBwYXR0ZXJuIGlzLCBpZiBhbnkuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPlVubGVzcyB0aGVyZSdzIGFuIG9iamVjdGlvbiBtYXkgSSBwcm9w b3NlOjxicj4NCjxicj4NCmlyYzovL3VzZXJAaG9zdC88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ VGhpcyBpcyB2ZXJ5IG11Y2ggaW4gbGluZSB3aXRoIHRoZSB3b3JrIG9mIEJlbiBZb3VuZyAoY2Mn ZCk8YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwOi8vdXNlcmluZm8ubWUvIj5odHRwOi8vdXNlcmlu Zm8ubWUvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5XaG8gcHJvcG9zZXMgYSBuZWF0IHdh eSB0byBnZXQgdXNlciBwcm9maWxlIGluZm8gdmlhIEhUVFAgYXM6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxhIGhyZWY9Imh0dHA6Ly91c2VyQGhvc3QvIj5odHRwOi8vdXNlckBob3N0LzwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYmVs aWV2ZSB0aGUgaW50ZW50aW9uIG9mIHRoaXMgaXMgdG8gd3JpdGUgYW4gUkZDLCBzbyBJJ2QgbGlr ZSB0byBhbGlnbiBmdXR1cmUgd29yayB3aXRoIHRoYXQgaWYgcG9zc2libGU8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4tIElyYTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+SXJhIE1jRG9uYWxkIChNdXNpY2lhbiAvIFNvZnR3YXJlIEFyY2hp dGVjdCk8YnI+DQpDby1DaGFpciAtIFRDRyBUcnVzdGVkIE1vYmlsaXR5IFNvbHV0aW9ucyBXRzxi cj4NCkNoYWlyIC0gTGludXggRm91bmRhdGlvbiBPcGVuIFByaW50aW5nIFdHPGJyPg0KU2VjcmV0 YXJ5IC0gSUVFRS1JU1RPIFByaW50ZXIgV29ya2luZyBHcm91cDxicj4NCkNvLUNoYWlyIC0gSUVF RS1JU1RPIFBXRyBJbnRlcm5ldCBQcmludGluZyBQcm90b2NvbCBXRzxicj4NCklFVEYgRGVzaWdu YXRlZCBFeHBlcnQgLSBJUFAgJmFtcDsgUHJpbnRlciBNSUI8YnI+DQpCbHVlIFJvb2YgTXVzaWMg LyBIaWdoIE5vcnRoIEluYzxicj4NCjxhIGhyZWY9Imh0dHA6Ly9zaXRlcy5nb29nbGUuY29tL3Np dGUvYmx1ZXJvb2ZtdXNpYyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMzMz M0ZGIj5odHRwOi8vc2l0ZXMuZ29vZ2xlLmNvbS9zaXRlL2JsdWVyb29mbXVzaWM8L3NwYW4+PC9h Pjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9zaXRlcy5nb29nbGUuY29tL3NpdGUvaGlnaG5vcnRoaW5j IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiM2NjAwQ0MiPmh0dHA6Ly9zaXRl cy5nb29nbGUuY29tL3NpdGUvaGlnaG5vcnRoaW5jPC9zcGFuPjwvYT48YnI+DQptYWlsdG86IDxh IGhyZWY9Im1haWx0bzpibHVlcm9vZm11c2ljQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJs dWVyb29mbXVzaWNAZ21haWwuY29tPC9hPjxicj4NCldpbnRlciZuYnNwOyA1NzkgUGFyayBQbGFj ZSZuYnNwOyBTYWxpbmUsIE1JJm5ic3A7IDQ4MTc2Jm5ic3A7IDxhIGhyZWY9InRlbDo3MzQtOTQ0 LTAwOTQiIHRhcmdldD0iX2JsYW5rIj4NCjczNC05NDQtMDA5NDwvYT48YnI+DQpTdW1tZXImbmJz cDsgUE8gQm94IDIyMSZuYnNwOyBHcmFuZCBNYXJhaXMsIE1JIDQ5ODM5Jm5ic3A7IDxhIGhyZWY9 InRlbDo5MDYtNDk0LTI0MzQiIHRhcmdldD0iX2JsYW5rIj4NCjkwNi00OTQtMjQzNDwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIE1vbiwgU2VwIDIyLCAyMDE0IGF0IDQ6NTAgUE0sIE1lbHZpbiBDYXJ2YWxobyAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1lbHZpbmNhcnZhbGhvQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1l bHZpbmNhcnZhbGhvQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+SSB3YXMgd29uZGVyaW5nIGlmIElSQyBVUklzIGFyZSBzdGFuZGFy ZGl6ZWQgYXQgYWxsPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoZSBsYXRlc3QgSSBmb3VuZCB3YXMgOiA8 YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1idXRj aGVyLWlyYy11cmwtMDQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1idXRjaGVyLWlyYy11cmwtMDQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSBoYXZlIGEg dXNlIGNhc2Ugb2YgbWFya2luZyByZXB1dGF0aW9uIGZyb20gb25lIHN5c3RlbSAod2ViIGNoYXQg cm9vbSkgdG8gYW4gSVJDIGNoYXQgcm9vbSwgYnV0IEkgcmVxdWlyZSBhbiBpZGVudGlmaWVyIGZv ciB0aGUgdXNlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGUgc3VnZ2VzdGlvbnMgc28gZmFyIGhhdmUg YmVlbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aXJjOi8v dXNlckBob3N0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmly YzovL3VzZXJAaG9zdC8gLS0gdHJhaWxpbmcgc2xhc2g8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5pcmM6dXNlckBob3N0IC0tIHNpbWlsYXIgdG8geG1wcDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5pcmM6Ly9ob3N0LyN1c2VyIC0tIGZyYWdtZW50IGNvdWxkIGJl IHByb2JsZW1hdGljIGFzIHBlciBSRkMgOTM4NjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JJ3Zl IGdvbmUgd2l0aCB0aGUgc2Vjb25kIG9wdGlvbiBmb3IgdGhlIG1vbWVudDxicj4NCjxicj4NCkFu eSBwb2ludGVycyB3b3VsZCBiZSBtb3N0IHdlbGNvbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KYXBwcy1kaXNjdXNzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzphcHBzLWRp c2N1c3NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5hcHBzLWRpc2N1c3NAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBz LWRpc2N1c3MiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2FwcHMtZGlzY3VzczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_03cbd1281c9646e594e47d934a565ebcBY2PR03MB412namprd03pro_-- From nobody Sun Sep 28 22:36:12 2014 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 78F2B1A6FB8 for ; Sun, 28 Sep 2014 22:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.673 X-Spam-Level: X-Spam-Status: No, score=0.673 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 OYBOaAY9lZ4N for ; Sun, 28 Sep 2014 22:36:07 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675C41A3BA2 for ; Sun, 28 Sep 2014 22:36:07 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id z60so1713921qgd.25 for ; Sun, 28 Sep 2014 22:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=G8LilfuWx66TsZBeMuk+mmQy6pERbj08ARR84TUEjtg=; b=z8f78VLjr6zp89y2FKTaQq9coqYAcm0qnEuctzfo+fVmynly3ozHzs7Q51ntfrfIIl mWkCIqOuuooTvRVa9K9WBiPCNUJSpwwiXOA5/0huC2sLbDqPmacAIfXP2V/k1SUBEeM5 txGeFLPfIfGWCO1nCF+lmgm5vNY5t7TriUs32cHt9piZmuacJspTZmmnKSjI8JHxRKCp yWB+j63OwuEMC4eZTCf9ejYd9y1x+XSaS4wKA74cy9nM9zYPMzVUjk6D23nXowNNt2bU cXudMt9vvfBeI/PyBD6cUgX2Di+rD9VheiRY7BP8bh3GmHTwBnVYryXBnvLh009/YueD sw0g== MIME-Version: 1.0 X-Received: by 10.140.109.135 with SMTP id l7mr6559547qgf.82.1411968966531; Sun, 28 Sep 2014 22:36:06 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.140.25.150 with HTTP; Sun, 28 Sep 2014 22:36:06 -0700 (PDT) In-Reply-To: <54251F1C.4030505@it.aoyama.ac.jp> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54251F1C.4030505@it.aoyama.ac.jp> Date: Mon, 29 Sep 2014 15:36:06 +1000 X-Google-Sender-Auth: Ha9auKPKQOYcOu8F0ioWJasWfhs Message-ID: From: Matthew Kerwin To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=001a113a4eb2af20b405042da4a1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/qE6aYm0xl9-ZJ17cwN8pWhJePtw Cc: IETF Apps Discuss , Daniel Stenberg Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.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: Mon, 29 Sep 2014 05:36:10 -0000 --001a113a4eb2af20b405042da4a1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 26 September 2014 18:09, "Martin J. D=C3=BCrst" wrote: > On 2014/09/26 16:19, > =E2=80=8B=E2=80=8B > Daniel Stenberg wrote: > >> >> I would rather have a new spec straigten up and tighten the language >> somewhat so that we can get a stricter interpretation of how a file:// >> is supposed to work. Sure, there will then possibly be a few >> non-compliant parsers out there that accept a few non-standard formats >> but it should be clear to those who generates or writes file:// URIs >> which the correct way is. That way we could potentially move into a >> future with less file:// URI variations rather than more. The rest of my >> comments are based on this basic stand. >> > > I think this would be ideal, but there's really a lot of 'crap' out there > in the case of the file: scheme. So it may make sense to: > a) Document the core syntax for people creating new URIs, and parsers tha= t > want to be strict. > b) Document frequently seen (and rather widely accepted) variations to > help people who want (or have) to implement lenitent parsers. This should > very clearly be labeled as optional. > > =E2=80=8BI think that's where I would have ended up if I'd worked on it in isolation for a few more years. I always get nervous and back down when I get introspective and wonder if what I'm proposing is better, or just want I want to see. I suppose the best way forward is to canonise the common cases "file:///foo/bar" and "file://smb.example.com/foo/bar"=E2=80=8B, and = mark every other variant as an optional extension. Personally I'd like "file:/foo/bar" to be the standard for local files, because there's less guff. > =E2=80=8B > =E2=80=8B > =E2=80=8B=E2=80=8B > Daniel Stenberg > : > This document rather opens up pandora's box for someone like me. >> Suddenly this claims that all sorts of horrid abuses (in my view) we've >> seen through the years are fine and should be supported by my parser (if >> I want to be compliant) and it would surprise me if not a few other >> parser authors don't feel the same. >> =E2=80=8B >> >> You're right, and I didn't see that when I was writing it. My twofold goal was to document what currently happens, and highlight the bits I think are "ideal." I just didn't go far enough. Although I'm still a bit nervous about peoples' reactions when they find out their unique interpretations aren't enshrined as the One True Way. >> =E2=80=8B >> I also think that the 'host' part of the file: URI was a mistake to >> begin with. It was always a mystery to readers of RFC1738 and I think it >> should be better clarified here as well that it is useless and not >> interoperable. >> =E2=80=8B >> =E2=80=8B >> >> =E2=80=8B >> =E2=80=8B >> >> =E2=80=8BThey just didn't think about it enough. ;) From what I've heard, m= apping UNC paths into file URIs is a pretty common case, so it's one we'd do well to document. It's also one that results in a lot of interop issues (notably Firefox's fifth slash), so it's worth resolving one way or another. UNC has gotten more and more prominent in the text as I've iterated, in response to comments and suggestions. This is also the point where I've deviated the most from RFC 1738, taking my lead from Microsoft and Chrome, and using the host as "the samba server" instead of "the only machine that can dereference this URL." There's still the fact that this scheme is defined in isolation (without a protocol attached). The "methods" are necessarily vague, because they depend on the file system, and where one system might be perfectly happy supporting a URL with a host (e.g. Windows' CreateFile(PathCreateFromUrl()) stack) another might not. Because there aren't proper methods, this URI scheme is effectively an interchange format for exchanging filenames (i.e. a string), and as such I'm reluctant to say "some people can't do this thing when they interpret this part of this string this way, so no one can use that part of the string." I guess we could push to tighten up the methods, but I think that would sap my enthusiasm somewhat. I already referenced POSIX, that's enough for me for now. =E2=80=8B >> =E2=80=8B >> >> =E2=80=8B >> =E2=80=8B >> The query part. It didn't exist in 1738, so introducing that now will >> break a lot of old parsers (like mine) even if I recognize that 3986 >> says that it should be supported globally. This, for just a vague >> extension model without any clear purpose or use case. >> > > I'm happy drop it. If anyone using OpenVMS is desperate to refer to a particular version within a file URI, I guess they can use a semicolon. It's a reserved sub-delimiter, which is perfectly appropriate in this case. --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a113a4eb2af20b405042da4a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 26 September 2014 18:09, "Martin J. D=C3=BCrst" <duerst@it.aoyama.ac.jp= > wrote= :
On 2014/09/26 16:19,
=E2=80=8B=E2=80=8B
Daniel Stenberg wrote:

I would rather have a new spec straigten up and tighten the language
somewhat so that we can get a stricter interpretation of how a file://
is supposed to work. Sure, there will then possibly be a few
non-compliant parsers out there that accept a few non-standard formats
but it should be clear to those who generates or writes file:// URIs
which the correct way is. That way we could potentially move into a
future with less file:// URI variations rather than more. The rest of my comments are based on this basic stand.

 I think this would be ideal, but there's really a lot of 'crap'= out there in the case of the file: scheme. So it may make sense to:
a) Document the core syntax for people creating new URIs, and parsers that = want to be strict.
b) Document frequently seen (and rather widely accepted) variations to help= people who want (or have) to implement lenitent parsers. This should very = clearly be labeled as optional.


=E2=80=8BI think that&= #39;s where I would have ended up if I'd worked on it in isolation for = a few more years. I always get nervous and back down when I get introspecti= ve and wonder if what I'm proposing is better, or just want I want to s= ee. I suppose the best way forward is to canonise the common cases "fi= le:///foo/bar" and "file://smb.example.com/foo/bar"=E2=80=8B, and mark every other varia= nt as an optional extension. Personally I'd like "file:/foo/bar&qu= ot; to be the standard for local files, because there's less guff.
=C2=A0
=E2=80=8B
=E2= =80=8B
=E2=80=8B=E2=80=8B
Daniel Stenberg=
:
This document rather opens up pandora's box for someone like me.
Suddenly this claims that all sorts of horrid abuses (in my view) we've=
seen through the years are fine and should be supported by my parser (if I want to be compliant) and it would surprise me if not a few other
parser authors don't feel the same.
=E2=80=8B


You're right, and I didn't see that when I was writ= ing it. My twofold goal was to document what currently happens, and highlig= ht the bits I think are "ideal." I just didn't go far enough.= Although I'm still a bit nervous about peoples' reactions when the= y find out their unique interpretations aren't enshrined as the One Tru= e Way.



=E2=80=8B
I also think that the 'host' part of t= he file: URI was a mistake to
begin with. It was always a mystery to readers of RFC1738 and I think it should be better clarified here as well that it is useless and not
interoperable.
=E2=80=8B
=E2=80=8B

=E2=80=8B
=
=E2=80=8B


=E2=80=8BThey just didn't think abo= ut it enough. ;) From what I've heard, mapping UNC paths into file URIs= is a pretty common case, so it's one we'd do well to document. It&= #39;s also one that results in a lot of interop issues (notably Firefox'= ;s fifth slash), so it's worth resolving one way or another. UNC has go= tten more and more prominent in the text as I've iterated, in response = to comments and suggestions. This is also the point where I've deviated= the most from RFC 1738, taking my lead from Microsoft and Chrome, and usin= g the host as "the samba server" instead of "the only machin= e that can dereference this URL."

T= here's still the fact that this scheme is defined in isolation (without= a protocol attached). The "methods" are necessarily vague, becau= se they depend on the file system, and where one system might be perfectly = happy supporting a URL with a host (e.g. Windows' CreateFile(PathCreate= FromUrl()) stack) another might not. Because there aren't proper method= s, this URI scheme is effectively an interchange format for exchanging file= names (i.e. a string), and as such I'm reluctant to say "some peop= le can't do this thing when they interpret this part of this string thi= s way, so no one can use that part of the string."

<= /div>
I guess we could push to tighten up the methods, but I think = that would sap my enthusiasm somewhat. I already referenced POSIX, that'= ;s enough for me for now.



=
=E2=80=8B
=E2=80=8B

= =E2=80=8B
=E2=80=8B
The query part. It didn't exist in = 1738, so introducing that now will
break a lot of old parsers (like mine) even if I recognize that 3986
says that it should be supported globally. This, for just a vague
extension model without any clear purpose or use case.


I'm happy drop it. If anyone using OpenVMS is desperate to refer to a = particular version within a file URI, I guess they can use a semicolon. It&= #39;s a reserved sub-delimiter, which is perfectly appropriate in this case= .


--
=C2=A0 Matt= hew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a113a4eb2af20b405042da4a1-- From nobody Mon Sep 29 10:17:53 2014 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 CB42B1A8A10 for ; Mon, 29 Sep 2014 10:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, J_CHICKENPOX_14=0.6, J_CHICKENPOX_37=0.6, MANY_SPAN_IN_TEXT=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 Ay0d4QybhDGe for ; Mon, 29 Sep 2014 10:17:46 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422CD1A8915 for ; Mon, 29 Sep 2014 10:17:46 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C59CE50A84 for ; Mon, 29 Sep 2014 13:17:44 -0400 (EDT) Message-ID: <5429941C.6040808@seantek.com> Date: Mon, 29 Sep 2014 10:17:16 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050800080402090204090501" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/AU9gaqHi6Ur8poY07U3hk4CXs7w Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.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: Mon, 29 Sep 2014 17:17:47 -0000 This is a multi-part message in MIME format. --------------050800080402090204090501 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable In reviewing this draft, the history, and the comments, I noticed that=20 there is a lot of text devoted to Windows, but little on POSIX (the=20 interoperable standard for Unix), and none on Mac OS X. Mac OS X is=20 rooted in POSIX, but it is notable that a lot of Apple Frameworks use=20 the file:/// URL format. In particular, there is zero discussion of this fascinating tidbit from=20 the Apple Developer documentation: Specifying the Path to a File or Directory=20 For most URLs, you build the URL by concatenating directory and file names together using the appropriate|NSURL|methods until you have the path to the item. A URL built in that way is referred to as a*path-based URL*because it stores the names needed to traverse the directory hierarchy to locate the item. (You also build string-based paths by concatenating directory and file-names together, with the results stored in a slightly different format than that used by the|NSURL|class.) In addition to path-based URLs, you can also create a*file reference URL*, which identifies the location of the file or directory using a unique ID. All of the following entries are valid references to a file called|MyFile.txt|in a user=92s|Documents|directory: *Path-based URL:*|file://localhost/Users/steve/Documents/MyFile.txt| *File reference URL:*|file:///.file/id=3D6571367.2773272/| *String-based path:*|/Users/steve/Documents/MyFile.txt| Different file systems rely on different separator characters. Because of these changes, you should create your URL objects using the methods provided by the NSURL class. You create URL objects the|NSURL|methods and convert them to file reference URLs only when needed. Path-based URLs are easier to manipulate, easier to debug, and are generally preferred by classes such as|NSFileManager |. An advantage of file reference URLs is that they are less fragile than path-based URLs while your app is running. If the user moves a file in the Finder, any path-based URLs that refer to the file immediately become invalid and must be updated to the new path. However, as long as the file moved to another location on the same disk, its unique ID does not change and any file reference URLs remain valid. Other Refs: https://developer.apple.com/library/mac/documentation/FileManagement/Conc= eptual/FileSystemProgrammingGuide/ https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/UR= LLoadingSystem/ FWIW I don't think documenting legacy Mac OS is useful, so I am not=20 advocating for its inclusion. Otherwise you would have to talk about ":" = specifically as a path separator. But by the same token, I would=20 question why we are bothering with documenting legacy MS-DOS and Windows = (pre Windows 2000/Windows XP), except to the extent that those issues=20 survive in contemporary versions of Windows. -Sean On 9/25/2014 6:13 PM, Matthew Kerwin wrote: > FYI: this is my file URI draft, now listing apps-discuss as the=20 > official place for discussion. > > >>> > [SNIP] --------------050800080402090204090501 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
In reviewing this draft, the history, and the comments, I noticed that there is a lot of text devoted to Windows, but little on POSIX (the interoperable standard for Unix), and none on Mac OS X. Mac OS X is rooted in POSIX, but it is notable that a lot of Apple Frameworks use the file:/// URL format.

In particular, there is zero discussion of this fascinating tidbit from the Apple Developer documentation:
Specifying the Path to a File or Directory

For most URLs, you build the URL by concatenating directory and file names together using the appropriate NSURL methods until you have the path to the item. A URL built in that way is referred to as a path-based URL because it stores the names needed to traverse the directory hierarchy to locate the item. (You also build string-based paths by concatenating directory and file-names together, with the results stored in a slightly different format than that used by the NSURL class.) In addition to path-based URLs, you can also create a file reference URL, which identifies the location of the file or directory using a unique ID.

All of the following entries are valid references to a file called MyFile.txt in a user’s Documents directory:

Path-based URL: file://localhost/Users/steve/Documents/MyFile.txt

File reference URL: file:///.file/id=6571367.2773272/

String-based path: /Users/steve/Documents/MyFile.txt

Different file systems rely on different separator characters. Because of these changes, you should create your URL objects using the methods provided by the NSURL class.

You create URL objects the NSURL methods and convert them to file reference URLs only when needed. Path-based URLs are easier to manipulate, easier to debug, and are generally preferred by classes such as NSFileManager. An advantage of file reference URLs is that they are less fragile than path-based URLs while your app is running. If the user moves a file in the Finder, any path-based URLs that refer to the file immediately become invalid and must be updated to the new path. However, as long as the file moved to another location on the same disk, its unique ID does not change and any file reference URLs remain valid.


Other Refs:
https://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/URLLoadingSystem/

FWIW I don't think documenting legacy Mac OS is useful, so I am not advocating for its inclusion. Otherwise you would have to talk about ":" specifically as a path separator. But by the same token, I would question why we are bothering with documenting legacy MS-DOS and Windows (pre Windows 2000/Windows XP), except to the extent that those issues survive in contemporary versions of Windows.

-Sean

On 9/25/2014 6:13 PM, Matthew Kerwin wrote:
FYI: this is my file URI draft, now listing apps-discuss as the official place for discussion.

>>>

[SNIP]
--------------050800080402090204090501-- From nobody Mon Sep 29 11:36:30 2014 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 E10BD1A9154 for ; Mon, 29 Sep 2014 11:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, 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 gqoLFte_qZ1C for ; Mon, 29 Sep 2014 11:36:27 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF0F71A9152 for ; Mon, 29 Sep 2014 11:36:26 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C6129509B5 for ; Mon, 29 Sep 2014 14:36:25 -0400 (EDT) Message-ID: <5429A68D.6030606@seantek.com> Date: Mon, 29 Sep 2014 11:35:57 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/k80c33MWSWC2lxdGq0YmcrJi5Uw Subject: [apps-discuss] "local convention" in draft-kerwin-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 18:36:29 -0000 Colleagues: We ought to step back for a moment and ask ourselves what exactly the=20 goals are of getting a common file URI scheme through the IETF process. Ultimately we are all here to promote "interoperability". There is a lot = of software out there that needs to identify local resources in the OS=20 file system in the same data type (URI) as Internet resources. The way=20 to distinguish these local resources in the URI way is--at a minimum--to = tack on "file:". File system resources are normally addressed by the operating system's=20 convention. We can come up with all sorts of notations, but at the end=20 of the day the OS system call (POSIX open, Win32 CreateFile, etc.) is=20 what matters. The OS needs to be consistent with itself and with=20 applications on it; it's also important that two instances of the same=20 OS (or OS families) agree on things, so that applications and data=20 written with that OS (family) in mind can work on different machines. But from the perspective of Internet architecture, all those things are=20 a "local convention"--that magical escape that in IETF-speak means "do=20 whatever at the endpoints, it doesn't affect the network".=20 draft-kerwin-file-scheme talks about local conventions but the overall=20 gist is trying to stuff local conventions into a common format, and=20 flailing about by addressing these disparate use cases (mostly Windows,=20 but some OpenVMS) that have cropped up. It is not surprising, by the way, that Windows causes difficulties while = Unix/POSIX is less problematic, since the URI convention of "/" for path = separators and "/" as the root path directly descends from Unix/POSIX=20 (and from FTP [RFC 959]). I would like to suggest a totally different approach: 1. file: identifies local filesystem resources (this includes filesystem = resources accessible via network paths such as UNC, since the filesystem = facility of the OS accommodates them). 2. # is the fragment. 3. everything else (the RFC 3986 and productions) is = a local convention. The draft can still include all of the current content, but move it into = informative appendices. If an application encounters a file URI for a local filesystem resource, = it should deal with it using the local convention. If an application=20 encounters a file URI for some non-local filesystem resource, it should=20 *leave it alone*. The end. In other words: why bother parsing a file URI if you know it's not going = to refer to a resource that you can make use of? If you're on Ubuntu=20 14.04, why do you care about interpreting a file: URI that's meant for=20 Windows 7? The only thing this does is invite security problems, because = attackers will tell you (via the network) to perform operations on local = resources that they don't have the authority to say anything about. Another issue is the matter of non-ASCII character encoding, which has=20 always been dicey. [POSIX] is very clear that a paths as a sequence of=20 *bytes*, not characters. Other than "/", , and the relative=20 pathnames "." and "..", it's anything-goes. The mapping between bytes=20 and characters depends on the locale. In Windows NT, the kernel treats=20 pathnames as Unicode (specifically UCS-2/UTF-16); translations are done=20 in user-space. In Mac OS X, the HFS Plus file system converts all file=20 names to decomposed Unicode, i.e., Normalization Form D [HFSPLUSREF]. It is kind of seen as a moral imperative in the IETF to use UTF-8 (and=20 Normalization Form C), possibly because of [BCP18] and [RFC5198]. But=20 here, the only thing common is diversity--and each operating system=20 (vendor) has its own good reasons for its individual decisions. Since=20 file: URIs are always stored *in context*, context (the operating system = documentation, the LC_ALL environment variable, the declared encoding of = the text document, the identity of the local machine, etc.) provides all = the info that you need. Just say that the file: URI (outside of the=20 fragment component) encodes with local conventions--which are provided=20 by context--and be done with it. If you are taking things like file: URIs out of context...three suggestio= ns: 1. Translate the file URI into the destination context. For example: if=20 you are in an HTML editor and you really want to reference=20 , but you are saving the HTML document in a=20 workgroup share, change the reference to=20 , and ensure that D:\pics is=20 shared as \\mycomputername\pics with appropriate access. Better yet:=20 upload the resource to an Internet-accessible location such as=20 , which for purposes of Internet=20 architecture, provides a more universal context. 2. Dereference the file URI and put whatever content you need into the=20 context. For example: in an HTML e-mail, don't use ; use = =20 and put the cat pic in the e-mail per [RFC2392] and [RFC2387]. 3. Don't do that. It doesn't make sense. Best regards, Sean [RFC959]: https://tools.ietf.org/html/rfc959 [POSIX]: http://pubs.opengroup.org/onlinepubs/9699919799/ [BCP18]: http://tools.ietf.org/html/bcp18 [RFC5198]: http://tools.ietf.org/html/rfc5198 [HFSPLUSREF]: https://developer.apple.com/library/mac/qa/qa1235/_index.ht= ml [RFC2392]: http://tools.ietf.org/html/rfc2392 [RFC2387]: http://tools.ietf.org/html/rfc2387 From nobody Mon Sep 29 12:33:07 2014 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 7F02A1A930A for ; Mon, 29 Sep 2014 12:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 jgIw9tKBYfjd for ; Mon, 29 Sep 2014 12:33:03 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D38AC1A9308 for ; Mon, 29 Sep 2014 12:33:03 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CE10F509B6 for ; Mon, 29 Sep 2014 15:33:02 -0400 (EDT) Message-ID: <5429B3D3.5040900@seantek.com> Date: Mon, 29 Sep 2014 12:32:35 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> In-Reply-To: <20140922224217.25104.13357.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/xTU3W6vZleil0n1pibXGv67uR5w Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 19:33:05 -0000 Colleagues: Having taken everyone's feedback into consideration, it is clear that=20 the consensus is trending away from the processor parameter in=20 draft-ietf-appsawg-text-markdown. Sufficient technical arguments have=20 been advanced; thus I am going to do an about-face on the matter. It=20 will be removed from draft-03. Thanks. I have tried to gather the most salient feedback on draft-02 thus far,=20 which I have put in the IETF appsawg wiki: http://trac.tools.ietf.org/wg/appsawg/trac/wiki/TextMarkdown/Feedback-dra= ft-02 If you feel that your comments were not taken into consideration, by all = means post them to the wiki. The feedback page isn't a promise that any particular thing will or will = not happen, but at least it's a public comment board so that when=20 draft-03 appears in a few weeks, we can all see that key points were at=20 least noted. Best regards, Sean On 9/22/2014 3:42 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Applications Area Working Group Work= ing Group of the IETF. > > Title : The text/markdown Media Type > Author : Sean Leonard > Filename : draft-ietf-appsawg-text-markdown-02.txt > Pages : 25 > Date : 2014-09-22 > > Abstract: > This document registers the text/markdown media type for use with > Markdown, a family of plain text formatting syntaxes that optionall= y > can be converted to formal markup languages such as HTML. > From nobody Mon Sep 29 12:38:13 2014 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 B96AD1ABD3B for ; Mon, 29 Sep 2014 12:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.786] 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 PayggTiPUbo7 for ; Mon, 29 Sep 2014 12:38:02 -0700 (PDT) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA041ABD38 for ; Mon, 29 Sep 2014 12:38:02 -0700 (PDT) Received: by latimerie.flaska.net (Postfix, from userid 1000) id 3D21B619A9; Mon, 29 Sep 2014 21:37:59 +0200 (CEST) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Mon, 29 Sep 2014 21:37:59 +0200 User-Agent: Trojita/v0.4.1-334-ge433a03; Qt/4.8.5; X11; Linux; MIME-Version: 1.0 Message-ID: <8c556e8a-4786-4467-a7a6-63ab8dafb890@flaska.net> In-Reply-To: References: <54235269.2060002@seantek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/2d_MGmR3OlLOj3Cg7AEBsDPTMKI Subject: Re: [apps-discuss] A proposal for a new top-level media type: archive X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 19:38:08 -0000 On Thursday, 25 September 2014 04:31:42 CEST, Matthew Kerwin wrote: > - application/vnd.google-earth.kmz > - application/vnd.software602.filler.form-xml-zip Be careful here -- the ZIP encoding of these is just an implementation=20 detail. Bundling them under the proposed archive/* makes as much sense as=20 doing this for the ODT documents -- they, too, happen to use ZIP for=20 storing their XML bits. With kind regards, Jan --=20 Trojit=C3=A1, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From nobody Mon Sep 29 13:36:27 2014 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 3A0501ACC83 for ; Mon, 29 Sep 2014 13:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EO5_FY6SGqeP for ; Mon, 29 Sep 2014 13:36:25 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79701A1BD9 for ; Mon, 29 Sep 2014 13:36:24 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cc10so2005881wib.16 for ; Mon, 29 Sep 2014 13:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=nfY72OcqPNmkFTD/tmd+ddhE7w2EYavvgqJwNf5iTIg=; b=U/US81RJ5W1qgANLEVdAKfJdztTaPLrh5Aec60fHPNN7gNWof+wWv3gP7ysyB0VG7u oJhn3XjLx1SxJj7ocusIkOhhokLIymqo9m2Pe3SpU4ytmTxtH/gcIcVaZ+XdIo/PPtkU B0Qol7GGvBEL9odEtB3K3ZSTbX0BK8wHeIKNyHNPVpS9G4q2o+xQCBkckHVjWjAzsh4r hQVXle+WfBFkxDd4hliS2rgmCYD3E+xE5eOY9ERy7SMk56rMSK3q1ZZaGhXBaZVRxnPi RStRNLZs9biLsTsSqyaPk1LtFtRtKyz7NqVQ8VM/zqG+aXXHjI9eo7zO8jwrXCucTRgt 2qgg== MIME-Version: 1.0 X-Received: by 10.180.182.12 with SMTP id ea12mr407854wic.21.1412022983249; Mon, 29 Sep 2014 13:36:23 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Mon, 29 Sep 2014 13:36:23 -0700 (PDT) Date: Mon, 29 Sep 2014 13:36:23 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7b66f2e354d44705043a3818 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/m1KMUyMRqFoVt4hIbmJIJJ_k60w Subject: [apps-discuss] IETF 91 scheduling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 20:36:26 -0000 --047d7b66f2e354d44705043a3818 Content-Type: text/plain; charset=UTF-8 Colleagues, The window is closed for us to request a meeting slot for Toronto. We have requested our usual APPSAWG/APPAREA Monday morning 9:30 slot with the usual conflict set. Please propose agenda items for this meeting in response to this thread. We'll have our usual updates from the co-chairs and ADs and will be inviting chairs of BoFs and newly formed working groups to give short presentations on what's happening during the week. If you are working on a document in APPSAWG that requires face time to resolve some issues, or would like to make or request a presentation on a particular topic, please let us know ASAP. Our preliminary agenda is due to the Secretariat on Friday, October 27th, which is also the final date to be able to submit drafts to the datatracker before the meeting. -MSK, APPSAWG co-chair --047d7b66f2e354d44705043a3818 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

The window is clos= ed for us to=20 request a meeting slot for Toronto.=C2=A0 We have requested our usual=20 APPSAWG/APPAREA Monday morning 9:30 slot with the usual conflict set.

Please propose agenda items for this=20 meeting in response to this thread.=C2=A0 We'll have our usual updates = from=20 the co-chairs and ADs and will be inviting chairs of BoFs and newly=20 formed working groups to give short presentations on what's happening= =20 during the week.

If you are working on a document in APPSAWG that requires face time=20 to resolve some issues, or would like to make or request a presentation=20 on a particular topic, please let us know ASAP.=C2=A0 Our preliminary agenda is due to the Secretariat on Friday, October 27th= , which is also the final date to be able to submit drafts to the datatrack= er before the meeting.

-MSK, APPSAWG co-chair
--047d7b66f2e354d44705043a3818-- From nobody Mon Sep 29 13:39:42 2014 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 AC0AD1ACC91 for ; Mon, 29 Sep 2014 13:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zkvfnq8tIYch for ; Mon, 29 Sep 2014 13:39:40 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 058481ACAD8 for ; Mon, 29 Sep 2014 13:39:39 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id d1so1971293wiv.14 for ; Mon, 29 Sep 2014 13:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JeKM22/ZT/zBPBXjgJo6k07cRS5qdf4iDBsm3U6jqms=; b=LZ/vQ32PeQciGKdXa2JtnDl6L1ZRVXOY6sFSS4oaexmWb9496Dmvyha/k4fDt5s7VS DIzhO+MjGAyvzbnw/9OP64zzzIYqNDj96LE/dsBR1IpPVLqHCOFcnQ6evgnatvf9uX37 BHeuiardTOHBTX1oIB1W21jzQLJ+M3X64tHbM3Jt2cEEcWURlRlRqztbCIrMpxcQbKaT 09mvGilCuokcnMe4+9mPMPxkoZ2KkS4vNhmmCs15SdlwCkkXkmIcj2MzcoU+pIO2i9xF oepPPpximU14tebp+l1PVoFhW8Ke6sLTRFmbwtwl+LA3exOFaA/l0SqMKN/qiePRC1Uf GWyA== MIME-Version: 1.0 X-Received: by 10.180.182.12 with SMTP id ea12mr423591wic.21.1412023178552; Mon, 29 Sep 2014 13:39:38 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Mon, 29 Sep 2014 13:39:38 -0700 (PDT) In-Reply-To: <54235269.2060002@seantek.com> References: <54235269.2060002@seantek.com> Date: Mon, 29 Sep 2014 13:39:38 -0700 Message-ID: From: "Murray S. Kucherawy" To: Sean Leonard Content-Type: multipart/alternative; boundary=047d7b66f2e3f8ea1605043a43fd Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kqna_tXyWa_EdVJzXKaerasQeUY Cc: IETF Apps Discuss Subject: Re: [apps-discuss] A proposal for a new top-level media type: archive X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 20:39:42 -0000 --047d7b66f2e3f8ea1605043a43fd Content-Type: text/plain; charset=UTF-8 On Wed, Sep 24, 2014 at 4:23 PM, Sean Leonard wrote: > Colleagues on media-types and apps-discuss: > > I would like to propose that the IETF create a new top-level media type: > archive. > [...] I see a few expressions of support for this and no objections. Is there a draft APPSAWG should be thinking about adopting here? Does anyone disagree that this fits within our charter? -MSK --047d7b66f2e3f8ea1605043a43fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 24, 2014 at 4:23 PM, Sean Leonard <dev+iet= f@seantek.com> wrote:
Colleagues on media-types = and apps-discuss:

I would like to propose that the IETF create a new top-level media type: ar= chive.

[...]

I see a few express= ions of support for this and no objections.

Is there a draft APPSAWG= should be thinking about adopting here?=C2=A0 Does anyone disagree that th= is fits within our charter?

-MSK
--047d7b66f2e3f8ea1605043a43fd-- From nobody Mon Sep 29 13:49:34 2014 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 4FBE21ACCC7 for ; Mon, 29 Sep 2014 13:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.786, 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 ex6rCLcpEUdA for ; Mon, 29 Sep 2014 13:49:31 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 058271ACC88 for ; Mon, 29 Sep 2014 13:49:27 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PD5P457UW0005S9O@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 29 Sep 2014 13:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1412023713; bh=IQ1Q8zyoSzHPm8YNOnHFYBNGf6DbrYaMhgwtyYGErqg=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=JabwyJTu+vhCCMnhGNS6mSybForACY5Wljv3F4SOd7NOKHtj8bk/sQjpac9aCfQo3 3T0Zk8+xZ8JycBr806dYdFUq+YgadMLD1E87yY/Bo+h4mLLcY3xTVE/cphrcvUFUWC 2qGiBty6DWICnzMoQKkHIZmmjTf2K4nRCEil0nj8= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PD5LDIBFQO0000XZ@mauve.mrochek.com>; Mon, 29 Sep 2014 13:48:29 -0700 (PDT) Message-id: <01PD5P42RUJ80000XZ@mauve.mrochek.com> Date: Mon, 29 Sep 2014 13:47:34 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 29 Sep 2014 21:37:59 +0200" <8c556e8a-4786-4467-a7a6-63ab8dafb890@flaska.net> References: <54235269.2060002@seantek.com> <8c556e8a-4786-4467-a7a6-63ab8dafb890@flaska.net> To: =?iso-8859-1?Q?Jan_Kundr=E1t?= Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/jdl4d55x2o1K9gMWkOkGcqtTUqs Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] A proposal for a new top-level media type: archive X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 20:49:32 -0000 > On Thursday, 25 September 2014 04:31:42 CEST, Matthew Kerwin wrote: > > - application/vnd.google-earth.kmz > > - application/vnd.software602.filler.form-xml-zip > Be careful here -- the ZIP encoding of these is just an implementation > detail. Bundling them under the proposed archive/* makes as much sense as > doing this for the ODT documents -- they, too, happen to use ZIP for > storing their XML bits. Absolutely. application/zip should be/have been archive/zip, an application format that happens to employ zip at some level does not. Ned From nobody Mon Sep 29 14:10:22 2014 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 CDDF91ACCD8 for ; Mon, 29 Sep 2014 14:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1YWSZUiUoQa for ; Mon, 29 Sep 2014 14:10:17 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3081F1ACC85 for ; Mon, 29 Sep 2014 14:10:17 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8TLADZH014864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 29 Sep 2014 14:10:16 -0700 Message-ID: <5429CAB4.6030400@dcrocker.net> Date: Mon, 29 Sep 2014 14:10:12 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <54235269.2060002@seantek.com> <8c556e8a-4786-4467-a7a6-63ab8dafb890@flaska.net> <01PD5P42RUJ80000XZ@mauve.mrochek.com> In-Reply-To: <01PD5P42RUJ80000XZ@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 29 Sep 2014 14:10:16 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/WuqC6r325m1DZlTn4RHRg-fL5yA Subject: Re: [apps-discuss] A proposal for a new top-level media type: archive X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 21:10:19 -0000 >> > - application/vnd.google-earth.kmz >> > - application/vnd.software602.filler.form-xml-zip > >> Be careful here -- the ZIP encoding of these is just an implementation >> detail. Bundling them under the proposed archive/* makes as much sense as >> doing this for the ODT documents -- they, too, happen to use ZIP for >> storing their XML bits. > > Absolutely. application/zip should be/have been archive/zip, an application > format that happens to employ zip at some level does not. Color me confused. There is a wide -- possibly infinite -- range of interesting, context-specific domain semantics that we might choose to class as "top-level". After all these years, what makes 'archive' appropriate for special handling and others not? In other words, if we do want to go down this path, I suggest we do it with an enhanced meta-model of what top-level is about and be prepared to welcome many more additions. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Sep 29 14:21:28 2014 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 71A0A1ACCF2 for ; Mon, 29 Sep 2014 14:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 HVFSsVN3qazp for ; Mon, 29 Sep 2014 14:21:15 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43CE21ACCEB for ; Mon, 29 Sep 2014 14:21:12 -0700 (PDT) Received: from unk-426d045e.adelphiacom.net (unknown [107.14.56.128]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 45C10509B8; Mon, 29 Sep 2014 17:21:07 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <01PD5P42RUJ80000XZ@mauve.mrochek.com> Date: Mon, 29 Sep 2014 14:21:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <350E3CA0-3B20-470D-AF58-A66E40BB00ED@seantek.com> References: <54235269.2060002@seantek.com> <8c556e8a-4786-4467-a7a6-63ab8dafb890@flaska.net> <01PD5P42RUJ80000XZ@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/bsprQ0hyo62j9IWtKPnuXWgvX9M Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] A proposal for a new top-level media type: archive X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 21:21:18 -0000 On Sep 29, 2014, at 1:47 PM, Ned Freed wrote: >> On Thursday, 25 September 2014 04:31:42 CEST, Matthew Kerwin wrote: >> > - application/vnd.google-earth.kmz >> > - application/vnd.software602.filler.form-xml-zip >=20 >> Be careful here -- the ZIP encoding of these is just an = implementation >> detail. Bundling them under the proposed archive/* makes as much = sense as >> doing this for the ODT documents -- they, too, happen to use ZIP for >> storing their XML bits. >=20 > Absolutely. application/zip should be/have been archive/zip, an = application > format that happens to employ zip at some level does not. +1 Yes, that is my understanding as well. If someone wished to define a file archiving format in XML as the = structuring language (to separate files and metadata), it could be = archive/format+xml; similarly if someone wished to define a file = archiving format in the newly-minted CBOR [RFC7049], it could be = archive/format+cbor. In the case of application types like Word documents = (application/vnd.openxmlformats-officedocument.wordprocessingml.document),= it is not desirable for a system that does not understand that specific = format to do =93archive-like behavior=94 with it (i.e., show the user = the ZIP file contents). It=92s better to save it to the local filesystem = as one stream of bytes. Whether =93archive-like behavior=94 is desirable depends on the media = type registrant=92s intent, which is not really for us to judge. Some = use cases of ODT/Word documents will use a ZIP parser to manage = them..but those parsers are used in the context of manipulating the ZIP = archives in =93that sort of way=94 (not as a general-purpose archive, = but according to some specific format or protocol requirement). Sean >=20 > Ned >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Mon Sep 29 14:26:58 2014 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 376811ACCF5 for ; Mon, 29 Sep 2014 14:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 qWj922bynT8i for ; Mon, 29 Sep 2014 14:26:54 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F291AC7E8 for ; Mon, 29 Sep 2014 14:26:54 -0700 (PDT) Received: from unk-426d045e.adelphiacom.net (unknown [107.14.56.128]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C15A4509B8 for ; Mon, 29 Sep 2014 17:26:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: Date: Mon, 29 Sep 2014 14:26:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54235269.2060002@seantek.com> To: IETF Apps Discuss X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/sz3kKux-LCAKVQvL_P5RuR2jurs Subject: Re: [apps-discuss] A proposal for a new top-level media type: archive X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 21:26:55 -0000 On Sep 29, 2014, at 1:39 PM, Murray S. Kucherawy = wrote: > On Wed, Sep 24, 2014 at 4:23 PM, Sean Leonard = wrote: > Colleagues on media-types and apps-discuss: >=20 > I would like to propose that the IETF create a new top-level media = type: archive. >=20 > [...] >=20 > I see a few expressions of support for this and no objections. >=20 > Is there a draft APPSAWG should be thinking about adopting here? Does = anyone disagree that this fits within our charter? I think this work definitely fits within the Application area. However, = I am not sure if it should be cabined to APPSAWG. It may be wise to form = a new working group. If this is something that the IETF is going to pursue, there are = questions as to its scope. I requested that the Area Directors approve a = BoF for IETF 91. I will respond to this in detail on the APPSAWG IETF 91 = scheduling thread. Best regards, Sean From nobody Mon Sep 29 14:46:53 2014 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 21DDE1ACCF4 for ; Mon, 29 Sep 2014 14:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 i20f5Hcj_Tqm for ; Mon, 29 Sep 2014 14:46:49 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78B861ACCFA for ; Mon, 29 Sep 2014 14:46:49 -0700 (PDT) Received: from unk-426d045e.adelphiacom.net (unknown [107.14.56.128]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 54AD9509B8; Mon, 29 Sep 2014 17:46:46 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F7A8B0B9-7044-4351-9111-717AF7800AD9" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: Date: Mon, 29 Sep 2014 14:46:43 -0700 Message-Id: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JRYx35wgJ-BpvMxOeJtxchvCvdI Cc: IETF Apps Discuss Subject: Re: [apps-discuss] IETF 91 scheduling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 21:46:52 -0000 --Apple-Mail=_F7A8B0B9-7044-4351-9111-717AF7800AD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Topic: Archive TLMT Based on responses from last week (and the IETF 91 BoF deadline), I = requested that the Area Directors schedule a BoF. They have not = responded yet one way or another. This might be a good opportunity for = apps-discuss to consider whether it makes more sense to discuss it in = APPSAWG, to create a BoF, to create a new WG, or some combination of the = three. Additional TLMTs (top level media types) have been proposed *rarely* but = none have actually been registered in recent memory. Since they aren=92t = proposed very often, however, it doesn=92t seem to me that we need to = layer on additional process beyond the normal IETF processes that are in = place for new proposals in general. Here are some of the issues to be considered, which I put on the = proposed BoF agenda: Agenda Discuss proposal to make archive TLMT Identify use cases Identify types of archives and whether these types of archives should = all go in, e.g.: archiving only, multi-function, software packaging, = disk images, backup Identify formats in common use, and debate which ones should be = considered as exemplary for purposes of creating archive TLMT Identify commonalities between all formats Sketch how to represent commonalities (e.g., fragment identifiers), and = whether these commonalities should be mandated (e.g., all fragment = identifiers have the same syntax or the same (possibly extensible) base = syntax) Identify user interface considerations Identify security considerations Identify composite-type considerations (e.g., Content-Coding of bzip2 = vs. integrating into media type) Identify issues with interchange when sending and receiving systems do = not have the same settings (e.g., different code pages), and the failure = to coordinate these same settings result in interchange problems because = the archive does not take the differences into consideration (e.g., = interpreting file names in one character set/codepage vs. another = character set/codepage, where the character set/codepage is not = specified in the archive) Divide work up Overall I think that the archive TLMT can be defined in a single RFC, = which itself does not justify the creation of a working group. However, = it is not sufficient to define the archive TLMT=97we ought to take the = time to review and register a broad swath of the common formats that are = being exchanged on the Internet, including: zip (i.e., reconsider whether it should be reclassified, or = dual-classified) rar arj 7z tar tar.* (.tar.gz, .tar.bz2, etc.) iso bin/cue ace arc arj img/ima/imz (floppy disk images) dmg (Apple disk images) nrg rpm sit vmdk vhd vfd uif =20 The list goes on and on, and new formats continue to be invented. There = is a lot of specialized knowledge in this area (what formats can contain = hidden executable code [hint: many CD/optical disc images can=97with = serious consequences]? what formats can store NTFS alternate data = streams, POSIX extended attributes, Mac OS resource forks, etc.? do some = of these formats allow for generalized metadata? how do the formats = select code pages or character sets?), so it is not realistic for all = this registration activity to go on with one RFC. So=85shall we schedule APPSAWG time? BoF? Direct to new WG? Some of the = three? Best regards, Sean On Sep 29, 2014, at 1:36 PM, Murray S. Kucherawy = wrote: > Colleagues, >=20 > The window is closed for us to request a meeting slot for Toronto. We = have requested our usual APPSAWG/APPAREA Monday morning 9:30 slot with = the usual conflict set. >=20 > Please propose agenda items for this meeting in response to this = thread. We'll have our usual updates from the co-chairs and ADs and = will be inviting chairs of BoFs and newly formed working groups to give = short presentations on what's happening during the week. >=20 > If you are working on a document in APPSAWG that requires face time to = resolve some issues, or would like to make or request a presentation on = a particular topic, please let us know ASAP. Our preliminary agenda is = due to the Secretariat on Friday, October 27th, which is also the final = date to be able to submit drafts to the datatracker before the meeting. >=20 > -MSK, APPSAWG co-chair > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_F7A8B0B9-7044-4351-9111-717AF7800AD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Topic: Archive TLMT

Based = on responses from last week (and the IETF 91 BoF deadline), I requested = that the Area Directors schedule a BoF. They have not responded yet one = way or another. This might be a good opportunity for apps-discuss to = consider whether it makes more sense to discuss it in APPSAWG, to create = a BoF, to create a new WG, or some combination of the = three.

Additional TLMTs (top level media types) have = been proposed *rarely* but none have actually been registered in recent = memory. Since they aren=92t proposed very often, however, it doesn=92t = seem to me that we need to layer on additional process beyond the normal = IETF processes that are in place for new proposals in = general.

Here are some of the issues to be = considered, which I put on the proposed BoF agenda:
  • Agenda
    • Discuss proposal to make archive = TLMT
    • Identify use cases
    • Identify types of archives and = whether these types of archives should all go in, e.g.: archiving only, = multi-function, software packaging, disk images, backup
    • Identify = formats in common use, and debate which ones should be considered as = exemplary for purposes of creating archive TLMT
    • Identify = commonalities between all formats
    • Sketch how to represent = commonalities (e.g., fragment identifiers), and whether these = commonalities should be mandated (e.g., all fragment identifiers have = the same syntax or the same (possibly extensible) base = syntax)
    • Identify user interface considerations
    • Identify = security considerations
    • Identify composite-type considerations = (e.g., Content-Coding of bzip2 vs. integrating into media = type)
    • Identify issues with interchange when sending and = receiving systems do not have the same settings (e.g., different code = pages), and the failure to coordinate these same settings result in = interchange problems because the archive does not take the differences = into consideration (e.g., interpreting file names in one character = set/codepage vs. another character set/codepage, where the character = set/codepage is not specified in the archive)
    • Divide work = up
Overall I think that the archive TLMT can be = defined in a single RFC, which itself does not justify the creation of a = working group. However, it is not sufficient to define the archive = TLMT=97we ought to take the time to review and register a broad swath of = the common formats that are being exchanged on the Internet, = including:
 zip (i.e., reconsider whether it should be = reclassified, or = dual-classified)
 rar
 arj
 7= z
 tar
 tar.* (.tar.gz, .tar.bz2, = etc.)
 iso
 bin/cue
 ace
 arc
 arj
 img/ima/imz (floppy = disk images)
 dmg (Apple disk = images)
 nrg
 rpm
 sit
<= div> vmdk
 vhd
 vfd
 uif=
 
The list goes on and on, and new formats = continue to be invented. There is a lot of specialized knowledge in this = area (what formats can contain hidden executable code [hint: many = CD/optical disc images can=97with serious consequences]? what formats = can store NTFS alternate data streams, POSIX extended attributes, Mac OS = resource forks, etc.? do some of these formats allow for generalized = metadata? how do the formats select code pages or character sets?), so = it is not realistic for all this registration activity to go on with one = RFC.

So=85shall we schedule APPSAWG time? BoF? = Direct to new WG? Some of the three?

Best = regards,

Sean

On Sep 29, = 2014, at 1:36 PM, Murray S. Kucherawy <superuser@gmail.com> = wrote:

Colleagues,

The= window is closed for us to=20 request a meeting slot for Toronto.  We have requested our usual=20 APPSAWG/APPAREA Monday morning 9:30 slot with the usual conflict = set.

Please propose agenda items for this=20= meeting in response to this thread.  We'll have our usual updates = from=20 the co-chairs and ADs and will be inviting chairs of BoFs and newly=20 formed working groups to give short presentations on what's happening=20 during the week.

If you are working on a document in APPSAWG that requires face time=20= to resolve some issues, or would like to make or request a presentation=20= on a particular topic, please let us know ASAP.  Our preliminary = agenda is due to the Secretariat on Friday, = October 27th, which is also the final date to be able to submit drafts = to the datatracker before the meeting.

-MSK, APPSAWG co-chair
_______________________________________________
apps-discuss mailing = list
apps-discuss@ietf.org
https:/= /www.ietf.org/mailman/listinfo/apps-discuss

= --Apple-Mail=_F7A8B0B9-7044-4351-9111-717AF7800AD9-- From nobody Mon Sep 29 16:37:12 2014 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 A0B311A6F04 for ; Mon, 29 Sep 2014 16:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WH832Tx7hIyC for ; Mon, 29 Sep 2014 16:37:07 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F03E1ABC10 for ; Mon, 29 Sep 2014 16:37:07 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id pn19so3750051lab.0 for ; Mon, 29 Sep 2014 16:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1lYIgpgg69ArUJePDHmWHRwkbb3VuhGpjGt2G3Q0Mrk=; b=RyHhVU+V0+bwPj4vVkzsJD70ENVej+GU/9lFZJX+ZBug2EPJxvM1gPQm81aaRkwmYR 7hv1IqBbbEtwbFFKXvlfWHyzT5x9s4rDzZ8GAR8tW5Kn/IXafIlVr+51mopEL9FfT4pD bXt4ULkCpi+kC3MhNjB+U9MSUdqlJ0D3X9nWMQ0mGSfOPIRaBSBpEXramfo5y7/J5SnM 4xcaZH8OxVVytKzdbznUbkEy7HxETL989AwxzN6wcIHcl18z+w7849tMWVsVI6NRN+QN OdemPYdiTEXFde7Ce3HxMeQKAed19f9390aGdguE7Jp5xdOqyIlsGA80O4nnkzahsmZs VdjA== MIME-Version: 1.0 X-Received: by 10.112.169.37 with SMTP id ab5mr19170663lbc.27.1412033825386; Mon, 29 Sep 2014 16:37:05 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.152.147.8 with HTTP; Mon, 29 Sep 2014 16:37:05 -0700 (PDT) In-Reply-To: <5429941C.6040808@seantek.com> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <5429941C.6040808@seantek.com> Date: Tue, 30 Sep 2014 09:37:05 +1000 X-Google-Sender-Auth: nBjI0NEV9BYAgWC_HTbxOBl_8DM Message-ID: From: Matthew Kerwin To: Sean Leonard Content-Type: multipart/alternative; boundary=001a11c34b4a92b49405043cbee4 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-gxGBNVyYlg2P5XTPmOEMFIsmD8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.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: Mon, 29 Sep 2014 23:37:10 -0000 --001a11c34b4a92b49405043cbee4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 30 September 2014 03:17, Sean Leonard wrote: > In reviewing this draft, the history, and the comments, I noticed that > there is a lot of text devoted to Windows, but little on POSIX (the > interoperable standard for Unix), and none on Mac OS X. Mac OS X is roote= d > in POSIX, but it is notable that a lot of Apple Frameworks use the > file:/// URL format. > =E2=80=8B > =E2=80=8B > > =E2=80=8BThere's not much on POSIX because it's not exceptional (i.e. if yo= u start from a POSIX file path, you don't have to do much to get to a file URI). Windows is known to be exceptional, so those exceptions got some focus. > =E2=80=8B > =E2=80=8B > =E2=80=8B > In particular, there is zero discussion of this fascinating tidbit from > the Apple Developer documentation: > Specifying the Path to a File or Directory > > =E2=80=8B > =E2=80=8B > =E2=80=8B > =E2=80=8B > =E2=80=8B > =E2=80=8BThe biggest reason for that omission is that, quite simply, I'd no= t seen it. (I figured, right from the start, that people would be ready and willing to point out all my shortcomings and direct me to their favoured implementations' documentation and justifications.) >From what I see, the issues are: 1) the "Path-base URL" uses RFC 1738-style "localhost", which I've broken (and explicitly called out). And 2) the "File reference URL" ... er, I ... don't know; it's syntactically compatible with the generic syntax (barring a reserved sub-delimiter, which is probably alright), and to my eye it looks like it still works according to the "translating to/from file paths" idea. > FWIW I don't think documenting legacy Mac OS is useful, so I am not > advocating for its inclusion. Otherwise you would have to talk about ":" > specifically as a path separator. But by the same token, I would question > why we are bothering with documenting legacy MS-DOS and Windows (pre > Windows 2000/Windows XP), except to the extent that those issues survive = in > contemporary versions of Windows. > > I don't have to talk about ":" as a path separator in MacOS 8 for the same reason I didn't talk about "\" as a path separator in DOS, or the wonderful [FOO.BAR] thing in OpenVMS -- it's irrelevant. As long as the sequence of directories that comprise a file path is iterable, all you do to map that path to a file URI is concatenate the directory names together with "/", and in reverse you explode them on "/" and "translate to the local system's representation of file paths." Granted draft 13 doesn't have the "translate URI to file path" text yet -- there's a TODO in the kramdown source. Regarding the amount of text dedicated to Windows, all I said was: "they have drive letters, which you map this way," and: "some people actually map drive letters this way instead, but that's not good." I had to add a bit more text to justify the "|" because, as was pointed out to me, that isn't compatible with the generic syntax. If the "/C|/" pattern moves to an informational section the number of words it receives will matter even less= . UNC comes from Microsoft, but it's not what I'd call a Windows-specific tech, and it's definitely not legacy. It's also a legitimate alternative to file URIs, so it gets special mention.=E2=80=8B =E2=80=8BIs there somewhere else I've disproportionately represented legacy DOS/Windows cases to the exclusion of other systems? --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a11c34b4a92b49405043cbee4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 30 September 2014 03:17, Sean Leonard <dev+ietf@seantek.com> wrote:
=20 =20 =20
In reviewing this draft, the history, and the comments, I noticed that there is a lot of text devoted to Windows, but little on POSIX (the interoperable standard for Unix), and none on Mac OS X. Mac OS X is rooted in POSIX, but it is notable that a lot of Apple Frameworks use the file:/// URL format.
=E2=80=8B
=E2=80= =8B

=E2=80=8BThere's not much on POSIX because it'= ;s not exceptional (i.e. if you start from a POSIX file path, you don't= have to do much to get to a file URI). Windows is known to be exceptional,= so those exceptions got some focus.

=C2=A0
=E2=80=8B
=E2=80=8B
=E2=80=8B
I= n particular, there is zero discussion of this fascinating tidbit from the Apple Developer documentation:
Specifying the Path to a File or Directory
=E2=80= =8B
=E2=80=8B
=E2=80=8B
=E2=80=8B
=E2=80=8B
<= /div>

=E2=80=8BThe biggest reason = for that omission is that, quite simply, I'd not seen it. (I figured, r= ight from the start, that people would be ready and willing to point out al= l my shortcomings and direct me to their favoured implementations' docu= mentation and justifications.)

From what I= see, the issues are: 1) the "Path-base URL" uses RFC 1738-style = "localhost", which I've broken (and explicitly called out). A= nd 2) the "File reference URL" ... er, I ... don't know; it&#= 39;s syntactically compatible with the generic syntax (barring a reserved s= ub-delimiter, which is probably alright), and to my eye it looks like it st= ill works according to the "translating to/from file paths" idea.=



FWIW I don't think documenting legacy Mac OS is useful, so I am not advocating for its inclusion. Otherwise you would have to talk about ":" specifically as a path separator. But by the same= token, I would question why we are bothering with documenting legacy MS-DOS and Windows (pre Windows 2000/Windows XP), except to the extent that those issues survive in contemporary versions of Windows.


I don't have to talk about ":" as a path separato= r in MacOS 8 for the same reason I didn't talk about "\" as a= path separator in DOS, or the wonderful [FOO.BAR] thing in OpenVMS -- it&#= 39;s irrelevant. As long as the sequence of directories that comprise a fil= e path is iterable, all you do to map that path to a file URI is concatenat= e the directory names together with "/", and in reverse you explo= de them on "/" and "translate to the local system's repr= esentation of file paths." Granted draft 13 doesn't have the "= ;translate URI to file path" text yet -- there's a TODO in the kra= mdown source.

Regarding the amount of text= dedicated to Windows, all I said was: "they have drive letters, which= you map this way," and: "some people actually map drive letters = this way instead, but that's not good." I had to add a bit more te= xt to justify the "|" because, as was pointed out to me, that isn= 't compatible with the generic syntax. If the "/C|/" pattern = moves to an informational section the number of words it receives will matt= er even less.

UNC comes from Microsoft, bu= t it's not what I'd call a Windows-specific tech, and it's defi= nitely not legacy. It's also a legitimate alternative to file URIs, so = it gets special mention.=E2=80=8B

=E2=80=8BIs there somewhere else I've disproportionately repr= esented legacy DOS/Windows cases to the exclusion of other systems?

--
=C2=A0 Matthew Kerwi= n
=C2=A0 htt= p://matthew.kerwin.net.au/
--001a11c34b4a92b49405043cbee4-- From nobody Mon Sep 29 19:22:06 2014 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 AC38A1A00ED for ; Mon, 29 Sep 2014 19:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJhJwOo9digo for ; Mon, 29 Sep 2014 19:21:57 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B51081A00DD for ; Mon, 29 Sep 2014 19:21:56 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id p9so3462574lbv.7 for ; Mon, 29 Sep 2014 19:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Y67OLgV6tLn0SNYfjo+ld7d3MEO1ctVU7vrbyXFqQRg=; b=p3DdUD36IWjFZgpjCHhoCz/gsmKeCvKnTHhK7T2ysTidpajxkbs73QF9VQJDy2UWlb YnGcF1I49RUvqzVIe7ysyXAoB1WpjLFGl976t5J2QmeeeX8P808my0OztWCxSeuY3Y3o TDCSBlFPoppDd4OlNrbbs4wbX4N6wTjoDN1p0niPbFokYB9RFQMKHJaNuyADBOhu9imJ bkL/7o50KT8ED4ZwaK5TndhWvzRQIsathkPwnIkrSpdCDAYCalyYeqOHI9wVaHWryyl5 y3OGbPoSTUE54LQzQb38VVhCsllKkzaH5XLe6kg237e/7HKGDkIz3rjMheLyOfC5GJLa COKA== MIME-Version: 1.0 X-Received: by 10.112.167.194 with SMTP id zq2mr17459428lbb.18.1412043715016; Mon, 29 Sep 2014 19:21:55 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.152.147.8 with HTTP; Mon, 29 Sep 2014 19:21:54 -0700 (PDT) In-Reply-To: <5429A68D.6030606@seantek.com> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <5429A68D.6030606@seantek.com> Date: Tue, 30 Sep 2014 12:21:54 +1000 X-Google-Sender-Auth: PCPUd_8pWlvDJnyprdbaO06obp8 Message-ID: From: Matthew Kerwin To: Sean Leonard Content-Type: multipart/alternative; boundary=001a11c343b60a7da305043f0c80 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/LqsNwIadxSC_sRaGQv3WhPhg__A Cc: IETF Apps Discuss Subject: Re: [apps-discuss] "local convention" in draft-kerwin-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 02:22:01 -0000 --001a11c343b60a7da305043f0c80 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 30 September 2014 04:35, Sean Leonard wrote: > Colleagues: > > We ought to step back for a moment and ask ourselves what exactly the > goals are of getting a common file URI scheme through the IETF process. > > I agree. I can say, from the start, my original reason for taking on the draft was to address a single use-case: there are a bunch of really cool "URI access" libraries out there, and people like to use those to access local files[1]. So, the goal is: a means of specifying file names that is compatible with the generic syntax of RFC 3986, and can be common across all the "URI access" libraries and other similar consumers. [1]: https://bugs.ruby-lang.org/issues/8544 > =E2=80=8B > Ultimately we are all here to promote "interoperability". There is a lot > of software out there that needs to identify local resources in the OS fi= le > system in the same data type (URI) as Internet resources. The way to > distinguish these local resources in the URI way is--at a minimum--to tac= k > on "file:". > =E2=80=8B > =E2=80=8B > > =E2=80=8B=E2=80=8B > File system resources are normally addressed by the operating system's > convention. We can come up with all sorts of notations, but at the end of > the day the OS system call (POSIX open, Win32 CreateFile, etc.) is what > matters. The OS needs to be consistent with itself and with applications = on > it; it's also important that two instances of the same OS (or OS families= ) > agree on things, so that applications and data written with that OS > (family) in mind can work on different machines. > > But from the perspective of Internet architecture, all those things are a > "local convention"--that magical escape that in IETF-speak means "do > whatever at the endpoints, it doesn't affect the network". > draft-kerwin-file-scheme talks about local conventions but the overall gi= st > is trying to stuff local conventions into a common format, and flailing > about by addressing these disparate use cases (mostly Windows, but some > OpenVMS) that have cropped up. > > The apparent "flailing" could just be me not being able to express myself very well. The path-to-URI conversion is really simple, the only weirdness being the various conventions for file system roots. Converting back can be trickier to specify, so it's more tempting to hand-wave there. But aside from that detail, the interoperability I was aiming for only goes as far as the syntax. The only operations/methods I explicitly address are parsing, and converting to and from file paths (once you've done that it's not a file URI anymore, so of course the local system's syscalls are appropriate), and the conversions are necessarily system dependent. > I would like to suggest a totally different approach: > 1. file: identifies local filesystem resources (this includes filesystem > resources accessible via network paths such as UNC, since the filesystem > facility of the OS accommodates them). > 2. # is the fragment. > 3. everything else (the RFC 3986 and productions) is = a > local convention. > > 1. Yep. =E2=80=8B2. I originally removed the fragment because fragment semantics de= pend on the content-type of the addressed resource, and files don't have a content-type. I kept it off because as far as I'm aware no file system conventions include fragments (or equivalent semantics), and the as only operations are converting to/from file system conventions, any fragments would be immediately lost anyway. 3. Pretty sure this breaks the driving goal, which is: can be parsed by any generic URI parser. Unless you mean to introduce local URI conventions that, while compatible with RFC 3986, might not be compatible with other local URI conventions. That ... offends me in some way I can't well articulate. > The draft can still include all of the current content, but move it into > informative appendices. > > If an application encounters a file URI for a local filesystem resource, > it should deal with it using the local convention. If an application > encounters a file URI for some non-local filesystem resource, it should > *leave it alone*. The end. > > Again, this is all what happens after the conversion.=E2=80=8B It doubtless= comes across as a bit weak when I keep saying, "I don't care what you do with it once you've converted it to a file path", but this whole discussion reinforces to me the fact that we can't reasonably define any more methods. They all fall short. > In other words: why bother parsing a file URI if you know it's not going > to refer to a resource that you can make use of? If you're on Ubuntu 14.0= 4, > why do you care about interpreting a file: URI that's meant for Windows 7= ? > The only thing this does is invite security problems, because attackers > will tell you (via the network) to perform operations on local resources > that they don't have the authority to say anything about. > > Catch 22: how can you know it's not going to refer to a particular resource without parsing it? And I could try to tell you, on your Ubuntu 14.01 system, to dump /etc/passwd without resorting to Windows drive letters. > Another issue is the matter of non-ASCII character encoding, which has > always been dicey. [POSIX] is very clear that a paths as a sequence of > *bytes*, not characters. Other than "/", , and the relative pathname= s > "." and "..", it's anything-goes. The mapping between bytes and character= s > depends on the locale. In Windows NT, the kernel treats pathnames as > Unicode (specifically UCS-2/UTF-16); translations are done in user-space. > In Mac OS X, the HFS Plus file system converts all file names to decompos= ed > Unicode, i.e., Normalization Form D [HFSPLUSREF]. > =E2=80=8B > =E2=80=8B > > Yep, I'm on board here (arguments about how accurately OS X maps to NFD aside), and this is the bit I want most to get right. > It is kind of seen as a moral imperative in the IETF to use UTF-8 (and > Normalization Form C), possibly because of [BCP18] and [RFC5198]. But her= e, > the only thing common is diversity--and each operating system (vendor) ha= s > its own good reasons for its individual decisions. Since file: URIs are > always stored *in context*, context (the operating system documentation, > the LC_ALL environment variable, the declared encoding of the text > document, the identity of the local machine, etc.) provides all the info > that you need. Just say that the file: URI (outside of the fragment > component) encodes with local conventions--which are provided by > context--and be done with it. > > I think the moral imperative is to provide interoperability, and when all else fails, Unicode with NFC is a good (or at least convenient) fallback/default. Regarding encoding, I took=E2=80=8B my lead from Microsoft and went as far = as defining conversions to IRIs (which are NFC Unicode, and thus unambiguous and universal, but not necessarily UTF-8), and said that you /can/ go the next step and convert them to URIs (if you want.) In draft 13 there's the beginnings of a reason to leave it at IRIs, sketched out as examples. > If you are taking things like file: URIs out of context...three > suggestions: > > 1. Translate the file URI into the destination context. For example: if > you are in an HTML editor and you really want to reference > , but you are saving the HTML document in a > workgroup share, change the reference to , > and ensure that D:\pics is shared as \\mycomputername\pics with appropria= te > access. Better yet: upload the resource to an Internet-accessible locatio= n > such as , which for purposes of Internet > architecture, provides a more universal context. > > 2. Dereference the file URI and put whatever content you need into the > context. For example: in an HTML e-mail, don't use src=3D"file:///D:/catpic.jpg">; use = and > put the cat pic in the e-mail per [RFC2392] and [RFC2387]. > > 3. Don't do that. It doesn't make sense. > > =E2=80=8BThat's a different use-case: writing one URI that can be consumed anywhere. All I want is one syntax that can be used to write or parse a URI anywhere. I agree that if you *do* want to share a file you either make it accessible to everyone who will receive the URI (e.g. SMB), or use a different scheme (either n:1 like ftp/http/etc, or n:n like cid/data/...). At our university, central IT has set up lots of SMB shares and mapped drives, etc., so it's very convenient to email links to, e.g. because we all share the same I-drive, and because Outlook lets us interact with those links "properly." I just want to make sure that the one guy who insists on using Thunderbird doesn't miss out because Thunderbird has a different parser. --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a11c343b60a7da305043f0c80 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 30 September 2014 04:35, Sean Leonard <dev+ietf@seantek.com> wrote:
Colleagues= :

We ought to step back for a moment and ask ourselves what exactly the goals= are of getting a common file URI scheme through the IETF process.

<= div class=3D"gmail_default" style=3D"font-family:georgia,serif;color:rgb(7,= 55,99);display:inline">

I ag= ree. I can say, from the start, my original reason for taking on the draft = was to address a single use-case: there are a bunch of really cool "UR= I access" libraries out there, and people like to use those to access = local files[1]. So, the goal is: a means of specifying file names that is c= ompatible with the generic syntax of RFC 3986, and can be common across all= the "URI access" libraries and other similar consumers.

[1]:=C2=A0https://bugs.ruby-lang.org/issues/8544

<= br>

=E2=80=8B
Ultimately we are all here to promote "interop= erability". There is a lot of software out there that needs to identif= y local resources in the OS file system in the same data type (URI) as Inte= rnet resources. The way to distinguish these local resources in the URI way= is--at a minimum--to tack on "file:".
=E2=80=8B
=E2=80=8B<= /div>
=E2=80=8B=E2=80=8B
File system resour= ces are normally addressed by the operating system's convention. We can= come up with all sorts of notations, but at the end of the day the OS syst= em call (POSIX open, Win32 CreateFile, etc.) is what matters. The OS needs = to be consistent with itself and with applications on it; it's also imp= ortant that two instances of the same OS (or OS families) agree on things, = so that applications and data written with that OS (family) in mind can wor= k on different machines.

But from the perspective of Internet architecture, all those things are a &= quot;local convention"--that magical escape that in IETF-speak means &= quot;do whatever at the endpoints, it doesn't affect the network".= draft-kerwin-file-scheme talks about local conventions but the overall gis= t is trying to stuff local conventions into a common format, and flailing a= bout by addressing these disparate use cases (mostly Windows, but some Open= VMS) that have cropped up.


The apparent "flailing" could just be me not being able to expre= ss myself very well. The path-to-URI conversion is really simple, the only = weirdness being the various conventions for file system roots. Converting b= ack can be trickier to specify, so it's more tempting to hand-wave ther= e.

But aside from that detail, the i= nteroperability I was aiming for only goes as far as the syntax. The only o= perations/methods I explicitly address are parsing, and converting to and f= rom file paths (once you've done that it's not a file URI anymore, = so of course the local system's syscalls are appropriate), and the conv= ersions are necessarily system dependent.


=

I would like to suggest a totally different approach:
1. file: identifies local filesystem resources (this includes filesystem re= sources accessible via network paths such as UNC, since the filesystem faci= lity of the OS accommodates them).
2. # is the fragment.
3. everything else (the RFC 3986 <hier-part> and <query> produc= tions) is a local convention.


1. Yep.

= =E2=80=8B2. I originally removed the fragment because fragment semantics de= pend on the content-type of the addressed resource, and files don't hav= e a content-type. I kept it off because as far as I'm aware no file sys= tem conventions include fragments (or equivalent semantics), and the as onl= y operations are converting to/from file system conventions, any fragments = would be immediately lost anyway.

3. Pre= tty sure this breaks the driving goal, which is: can be parsed by any gener= ic URI parser. Unless you mean to introduce local URI conventions that, whi= le compatible with RFC 3986, might not be compatible with other local URI c= onventions. That ... offends me in some way I can't well articulate. &l= t;https://www.you= tube.com/watch?v=3D5tkM6Zfr47o>



The draft can still includ= e all of the current content, but move it into informative appendices.

If an application encounters a file URI for a local filesystem resource, it= should deal with it using the local convention. If an application encounte= rs a file URI for some non-local filesystem resource, it should *leave it a= lone*. The end.


=
Again, this is all what happens after the conversion.= =E2=80=8B It doubtless comes across as a bit weak when I keep saying, "= ;I don't care what you do with it once you've converted it to a fil= e path", but this whole discussion reinforces to me the fact that we c= an't reasonably define any more methods. They all fall short.

=


In = other words: why bother parsing a file URI if you know it's not going t= o refer to a resource that you can make use of? If you're on Ubuntu 14.= 04, why do you care about interpreting a file: URI that's meant for Win= dows 7? The only thing this does is invite security problems, because attac= kers will tell you (via the network) to perform operations on local resourc= es that they don't have the authority to say anything about.

=

Catch 22: how can you= know it's not going to refer to a particular resource without parsing = it? And I could try to tell you, on your Ubuntu 14.01 system, to dump /etc/= passwd without resorting to Windows drive letters.


=

Another issue is t= he matter of non-ASCII character encoding, which has always been dicey. [PO= SIX] is very clear that a paths as a sequence of *bytes*, not characters. O= ther than "/", <NUL>, and the relative pathnames ".&qu= ot; and "..", it's anything-goes. The mapping between bytes a= nd characters depends on the locale. In Windows NT, the kernel treats pathn= ames as Unicode (specifically UCS-2/UTF-16); translations are done in user-= space. In Mac OS X, the HFS Plus file system converts all file names to dec= omposed Unicode, i.e., Normalization Form D [HFSPLUSREF].
=E2=80=8B
=E2=80=8B<= /div>

Yep, I'm on board here (arguments about how accurately OS X maps = to NFD aside), and this is the bit I want most to get right.



It is ki= nd of seen as a moral imperative in the IETF to use UTF-8 (and Normalizatio= n Form C), possibly because of [BCP18] and [RFC5198]. But here, the only th= ing common is diversity--and each operating system (vendor) has its own goo= d reasons for its individual decisions. Since file: URIs are always stored = *in context*, context (the operating system documentation, the LC_ALL envir= onment variable, the declared encoding of the text document, the identity o= f the local machine, etc.) provides all the info that you need. Just say th= at the file: URI (outside of the fragment component) encodes with local con= ventions--which are provided by context--and be done with it.


I think the moral imperative is to prov= ide interoperability, and when all else fails, Unicode with NFC is a good (= or at least convenient) fallback/default.

= Regarding encoding, I took=E2=80=8B my lead from Microsoft and went as far = as defining conversions to IRIs (which are NFC Unicode, and thus unambiguou= s and universal, but not necessarily UTF-8), and said that you /can/ go the= next step and convert them to URIs (if you want.) In draft 13 there's = the beginnings of a reason to leave it at IRIs, sketched out as examples.


If you are taking things like file: URIs out of context...three sugges= tions:

1. Translate the file URI into the destination context. For example: if you= are in an HTML editor and you really want to reference <file:///D:/pics= /catpic.jpg>, but you are saving the HTML document in a workgroup share,= change the reference to <file://mycomputername/pics/catpic.jpg&g= t;, and ensure that D:\pics is shared as \\mycomputername\pics with appropr= iate access. Better yet: upload the resource to an Internet-accessible loca= tion such as <http://i.imgur.com/ziZNc2s.jpg>, which for purposes of Int= ernet architecture, provides a more universal context.

2. Dereference the file URI and put whatever content you need into the cont= ext. For example: in an HTML e-mail, don't use <img src=3D"file= :///D:/catpic.jpg">; use <img src=3D"cid:catpic93298@myemai= l"> and put the cat pic in the e-mail per [RFC2392] and [RFC2387].<= br>
3. Don't do that. It doesn't make sense.


=E2=80=8BT= hat's a different use-case: writing one URI that can be consumed anywhe= re. All I want is one syntax that can be used to write or parse a URI anywh= ere.

I agree that if you *do* want to shar= e a file you either make it accessible to everyone who will receive the URI= (e.g. SMB), or use a different scheme (either n:1 like ftp/http/etc, or n:= n like cid/data/...).

At our university, c= entral IT has set up lots of SMB shares and mapped drives, etc., so it'= s very convenient to email links to, e.g. <file:///i:/section/minutes/so= me-meeting.doc> because we all share the same I-drive, and because Outlo= ok lets us interact with those links "properly." I just want to m= ake sure that the one guy who insists on using Thunderbird doesn't miss= out because Thunderbird has a different parser.

--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a11c343b60a7da305043f0c80-- From nobody Mon Sep 29 19:52:03 2014 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 402811A0108 for ; Mon, 29 Sep 2014 19:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.577 X-Spam-Level: X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786] 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 SWpqbOHtuhBV for ; Mon, 29 Sep 2014 19:51:57 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3678D1A00FB for ; Mon, 29 Sep 2014 19:51:57 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 293AF32E574; Tue, 30 Sep 2014 11:51:11 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 13c7_213a_88e183e1_c82c_4b48_9f0d_98c43c6e182d; Tue, 30 Sep 2014 11:51:10 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 987C8BF547; Tue, 30 Sep 2014 11:51:10 +0900 (JST) Message-ID: <542A1A9E.1030809@it.aoyama.ac.jp> Date: Tue, 30 Sep 2014 11:51:10 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Sean Leonard , IETF Apps Discuss References: <54235269.2060002@seantek.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0YSJL_Adrm2ceVmvlTlHqmbw3l8 Subject: Re: [apps-discuss] A proposal for a new top-level media type: archive X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 02:51:59 -0000 I don't think we need a WG for this, and we also don't need a BOF. Before I support adoption in the appsa WG, I'd like to see an initial draft. It shouldn't be too difficult, the draft that introduces 'model' as a top-level type is 13 pages overall (see http://tools.ietf.org/html/rfc2077). Regards, Martin. P.S.: At one point in time (~5 years ago), I started trying to write a draft for a font/ top-level mime type. I abandoned it because except for "doing things right", there was not much practical motivation. Given that there haven't been too many problems until now with application/zip and friends, I'd assume that anybody who wants to write a draft for archive/ will have to have a very strong internal motivation for "doing things right". My strong guess is that such a thing might work in the appsa WG, but keeping a separate WG alive on such motivation isn't going to work. On 2014/09/30 06:26, Sean Leonard wrote: > > On Sep 29, 2014, at 1:39 PM, Murray S. Kucherawy wrote: > >> On Wed, Sep 24, 2014 at 4:23 PM, Sean Leonard wrote: >> Colleagues on media-types and apps-discuss: >> >> I would like to propose that the IETF create a new top-level media type: archive. >> >> [...] >> >> I see a few expressions of support for this and no objections. >> >> Is there a draft APPSAWG should be thinking about adopting here? Does anyone disagree that this fits within our charter? > > I think this work definitely fits within the Application area. However, I am not sure if it should be cabined to APPSAWG. It may be wise to form a new working group. > > If this is something that the IETF is going to pursue, there are questions as to its scope. I requested that the Area Directors approve a BoF for IETF 91. I will respond to this in detail on the APPSAWG IETF 91 scheduling thread. > > Best regards, > > Sean > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Mon Sep 29 22:03:41 2014 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 3C3A41A014C for ; Mon, 29 Sep 2014 22:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07IVdqBNSBSC for ; Mon, 29 Sep 2014 22:03:37 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65FBD1A014B for ; Mon, 29 Sep 2014 22:03:37 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id bs8so3409760wib.12 for ; Mon, 29 Sep 2014 22:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LMcGkMPBvhGXGhBbNu3McBlXuAFa7mRLQhmsPLAZd04=; b=MkMd/Vz0p/nDPIey4dXepiJVTYAgjLTcZj9kJEVLkkUvkY1iFr53ASxv88+R7eWDjP uLEa7j9ui7CHw04QUBoksXRQE8L/FMp/jJMjkWx8vapnQaooos7XhrKUhEHRJ6wqT/QO J6UlXSYJjHInYBeqJ0ndFtwcnssTyhnhIt1A+/BKGSeeciK5PVuUbLgWBAftyn/fEVPJ N0RMw/Cp7acpSZuUf7RcnPyVryOo6rtlmb+cEU9sHab/uZRA9bbnC0d1ezI7nk35m/Vg bLkXFMt7BlhP4ueE5dTkMTTXPRs4Psw+ibja2vqnOhgFxgywh8geHvVAo1cqFXNVZB4X k6Aw== MIME-Version: 1.0 X-Received: by 10.195.13.114 with SMTP id ex18mr23704860wjd.89.1412053416012; Mon, 29 Sep 2014 22:03:36 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Mon, 29 Sep 2014 22:03:35 -0700 (PDT) In-Reply-To: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> Date: Mon, 29 Sep 2014 22:03:35 -0700 Message-ID: From: "Murray S. Kucherawy" To: Sean Leonard Content-Type: multipart/alternative; boundary=047d7bfced1c43f40a0504414eb6 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ibKMpufh6jM5khMlfqGjLjiwoUg Cc: IETF Apps Discuss Subject: Re: [apps-discuss] IETF 91 scheduling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 05:03:39 -0000 --047d7bfced1c43f40a0504414eb6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 29, 2014 at 2:46 PM, Sean Leonard wrote: > > So=E2=80=A6shall we schedule APPSAWG time? BoF? Direct to new WG? Some of= the > three? > > I think we need to wait until the BoF decision is made before allocating APPAREA time (it's not APPSAWG, unless there's a draft up for consideration). -MSK --047d7bfced1c43f40a0504414eb6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 29, 2014 at 2:46 PM, Sean Leonard <dev+iet= f@seantek.com> wrote:

So=E2=80=A6shall we schedule APPSAWG time? BoF? Dir= ect to new WG? Some of the three?


I think we need to wait until the BoF decision is m= ade before allocating APPAREA time (it's not APPSAWG, unless there'= s a draft up for consideration).

-MSK
--047d7bfced1c43f40a0504414eb6-- From nobody Mon Sep 29 22:11:04 2014 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 E28FC1A015B for ; Mon, 29 Sep 2014 22:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 J7WpIFibV2Wo for ; Mon, 29 Sep 2014 22:11:01 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F8221A0151 for ; Mon, 29 Sep 2014 22:11:01 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so5514691wgh.34 for ; Mon, 29 Sep 2014 22:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qnImHJh1Uv6Kirfim/5WAhZTdrQdcYz2+Vq2yuugf9g=; b=v929QAz67u7orsLHWReqiFXBpgD7r3c67K2SSKOfeOhKktH3L4forb2zc7Ex1G1rLq Gign7InqIrfmuQeZamfEXbawaTe9PCFHeuXeGXoQnQqeBgDZdw4wjWXY+X0VicFjYCUj G7MrWz76rJ8c2VUg0eVMwSnkXYNH4oUJ43IuwlQWSTm6UPMO/5JH3j/FcNzzh2CQTGbP 2eIIv8p1zR/vBOveOlT7IDJ59gevaXVGOBz8xy+bxtcQ6Q43l7UCK93iy1jryV1sMsD+ VH3xUR+gICEMqNkqEZj/WVCh80PE9u2uXzqPLt9MmXpVTgoT+sgDCmyKQU1LXz2FAMXu bhiA== MIME-Version: 1.0 X-Received: by 10.194.219.193 with SMTP id pq1mr50525658wjc.5.1412053860007; Mon, 29 Sep 2014 22:11:00 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Mon, 29 Sep 2014 22:10:59 -0700 (PDT) In-Reply-To: <542A1A9E.1030809@it.aoyama.ac.jp> References: <54235269.2060002@seantek.com> <542A1A9E.1030809@it.aoyama.ac.jp> Date: Mon, 29 Sep 2014 22:10:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=001a11c28620baca490504416869 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/59G4PtljBUHla6Oln7cDyIg1VCk Cc: IETF Apps Discuss Subject: Re: [apps-discuss] A proposal for a new top-level media type: archive X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 05:11:03 -0000 --001a11c28620baca490504416869 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 29, 2014 at 7:51 PM, "Martin J. D=C3=BCrst" wrote: > I don't think we need a WG for this, and we also don't need a BOF. Before > I support adoption in the appsa WG, I'd like to see an initial draft. It > shouldn't be too difficult, the draft that introduces 'model' as a > top-level type is 13 pages overall (see http://tools.ietf.org/html/rfc207= 7 > ). > That's pretty much a necessary step for each of the two paths anyway. -MSK --001a11c28620baca490504416869 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 29, 2014 at 7:51 PM, "Martin J. D=C3=BCrs= t" <duerst@it.aoyama.ac.jp> wrote:
= I don't think we need a WG for this, and we also don't need a BOF. = Before I support adoption in the appsa WG, I'd like to see an initial d= raft. It shouldn't be too difficult, the draft that introduces 'mod= el' as a top-level type is 13 pages overall (see http://tools.ietf.org/html/rfc20= 77).

That's pretty much a necessary = step for each of the two paths anyway.

-MSK
--001a11c28620baca490504416869-- From nobody Tue Sep 30 00:05:24 2014 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 EB8D61A0264 for ; Tue, 30 Sep 2014 00:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, 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 4IzQWdZDTnUf for ; Tue, 30 Sep 2014 00:05:20 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF411A0263 for ; Tue, 30 Sep 2014 00:05:20 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PD6AHLILZK005IK7@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 30 Sep 2014 00:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1412060418; bh=hevRlE5I7s0bblueS59q96XAmh4WIZb93HZUuWKM9ec=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=R3Bi6NCdFFAGG+PkRj8yVqB/SuNA/OPM6JYrOUdMfOvsu/Aj8rl2g4EParA7k8adn VlkADWqjzTBUN7klqdWBcltykP5AmVSLb5LOM4RMIRO5Zxm//DMQPe/0cN23dsLcut FziSGOIxFPt5FQhJDvG7d+/3QXhgaeR9sOH9YeZg= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PD68NLDBAO0000XZ@mauve.mrochek.com>; Tue, 30 Sep 2014 00:00:15 -0700 (PDT) Message-id: <01PD6AHJQ2GY0000XZ@mauve.mrochek.com> Date: Mon, 29 Sep 2014 23:40:24 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 29 Sep 2014 14:10:12 -0700" <5429CAB4.6030400@dcrocker.net> References: <54235269.2060002@seantek.com> <8c556e8a-4786-4467-a7a6-63ab8dafb890@flaska.net> <01PD5P42RUJ80000XZ@mauve.mrochek.com> <5429CAB4.6030400@dcrocker.net> To: Dave Crocker Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/FjpICdMrm1lKq_adVoq3e1UegJs Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] A proposal for a new top-level media type: archive X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 07:05:22 -0000 > >> > - application/vnd.google-earth.kmz > >> > - application/vnd.software602.filler.form-xml-zip > > > >> Be careful here -- the ZIP encoding of these is just an implementation > >> detail. Bundling them under the proposed archive/* makes as much sense as > >> doing this for the ODT documents -- they, too, happen to use ZIP for > >> storing their XML bits. > > > > Absolutely. application/zip should be/have been archive/zip, an application > > format that happens to employ zip at some level does not. > Color me confused. > There is a wide -- possibly infinite -- range of interesting, > context-specific domain semantics that we might choose to class as > "top-level". Really? In the past ~25 years, I'm aware of exactly three serious proposals to create a new top-level type: Model, font, and now archive. (There have been a few others, e.g., iso for ISO-specified formats, but they did not meet the basic criteria for top-level types.) > After all these years, what makes 'archive' appropriate for special > handling and others not? Perhaps the fact that it makes sense as a top-level type in essentially the same way as multipart and message do has something to do with it. The better question is why, after all these years, does defining archive now make sense. The answer is: There used to be a strong reluctance to register media types for archive formats. But the use of media types has expanded and our model for how they are used has changed, and what didn't make sense then makes sense now. And the registration of these types, which taken as a group have semantics similar to multipart and message, means it also makes sense for them to have a top-level type. > In other words, if we do want to go down this path, I suggest we do it > with an enhanced meta-model of what top-level is about and be prepared > to welcome many more additions. Sounds like a hell of a lot of work to handle a process that seems to run about once every 8 years, and which already has a requirement of a standards-track RFC attached. I suggest we wait until the glut of proposals you seem to be anticipating actually materializes before we undertake such a project. Ned From nobody Tue Sep 30 00:44:35 2014 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 D44441A026A for ; Tue, 30 Sep 2014 00:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.907 X-Spam-Level: X-Spam-Status: No, score=-0.907 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, RP_MATCHES_RCVD=-0.786, 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 VuWn6q4hJ6Cv for ; Tue, 30 Sep 2014 00:44:31 -0700 (PDT) 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 DB1FC1A0267 for ; Tue, 30 Sep 2014 00:44:30 -0700 (PDT) Received: internal info suppressed Date: Tue, 30 Sep 2014 09:44:09 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.local To: Ned Freed In-Reply-To: <01PD6AHJQ2GY0000XZ@mauve.mrochek.com> Message-ID: References: <54235269.2060002@seantek.com> <8c556e8a-4786-4467-a7a6-63ab8dafb890@flaska.net> <01PD5P42RUJ80000XZ@mauve.mrochek.com> <5429CAB4.6030400@dcrocker.net> <01PD6AHJQ2GY0000XZ@mauve.mrochek.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) 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=1412063051; bh=9D5K/8pugrLYDuN555nwsy92/4AB9QCD5BXOd+DsWFo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=daLjhDAU7WJx2C8vCOtmaDN+lXE/s+ZjTSNeeODRO7nlJNsN7/QIuf9Ai4jpCHlZn gcYKqrnCy3tKCiHFnPUPWcFZzkNjWRdLbzEe0BhdFkI5+6Lh4noCOjLTAqGh5gqe0s pT13nFnr+Z8iVa9XVDGvUAZEWgMiy1blVgIQgzwM= Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hFuvH--FPAjedepfyMPqKhCJGhQ Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] A proposal for a new top-level media type: archive X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 07:44:33 -0000 > Sounds like a hell of a lot of work to handle a process that seems to run about > once every 8 years, and which already has a requirement of a standards-track > RFC attached. > > I suggest we wait until the glut of proposals you seem to be anticipating > actually materializes before we undertake such a project. +1 ! > > Ned > > _______________________________________________ > 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; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Tue Sep 30 02:49:56 2014 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 5A9C61A029D for ; Tue, 30 Sep 2014 02:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GAqf8qIn9rl4 for ; Tue, 30 Sep 2014 02:49:44 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0748.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::748]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338B91A0307 for ; Tue, 30 Sep 2014 02:49:43 -0700 (PDT) Received: from pc6 (86.184.59.221) by AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Tue, 30 Sep 2014 09:49:20 +0000 Message-ID: <026401cfdc93$8eb714a0$4001a8c0@gateway.2wire.net> From: t.petch To: Sean Leonard , References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <5429A68D.6030606@seantek.com> Date: Tue, 30 Sep 2014 10:46:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.184.59.221] X-ClientProxiedBy: DB4PR02CA0014.eurprd02.prod.outlook.com (10.242.174.142) To AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB051; X-Forefront-PRVS: 0350D7A55D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(51704005)(52034003)(377454003)(13464003)(199003)(51444003)(77156001)(64706001)(47776003)(18206015026)(116806002)(19627595001)(50986999)(77096002)(50226001)(61296003)(44736004)(101416001)(66066001)(62966002)(102836001)(42186005)(33646002)(4396001)(81816999)(20776003)(85306004)(62236002)(97736003)(230783001)(76176999)(93886004)(81686999)(88136002)(19580405001)(76482002)(89996001)(85852003)(50466002)(19580395003)(105586002)(31966008)(44716002)(10300001)(14496001)(23756003)(15975445006)(80022003)(87976001)(86362001)(99396003)(17760045003)(107046002)(15202345003)(107886001)(87286001)(106356001)(21056001)(84392001)(46102003)(120916001)(93916002)(104166001)(95666004)(92566001)(92726001)(15519875005)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB051; H:pc6; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/t_hjnB8QJLATSPBCRbH3YWj8lYE Subject: Re: [apps-discuss] "local convention" in draft-kerwin-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 09:49:47 -0000 ----- Original Message ----- From: "Sean Leonard" To: Sent: Monday, September 29, 2014 7:35 PM > Colleagues: > > We ought to step back for a moment and ask ourselves what exactly the > goals are of getting a common file URI scheme through the IETF process. > > Ultimately we are all here to promote "interoperability". There is a lot > of software out there that needs to identify local resources in the OS > file system in the same data type (URI) as Internet resources. The way > to distinguish these local resources in the URI way is--at a minimum--to > tack on "file:". Well, yes and no. My working life revolves around Windows (as it does for most of the world:-) so it is the Windows flavour of file: that concerns me, and I don't need an RFC for that. But in the IETF, we periodically stumble across the status of RFC1738 and so we do need an RFC to obsolete s3.10 of that, and that motivates me. Recall that it says "This scheme, unlike most other URL schemes, does not designate a resource that is universally accessible over the Internet." so that is where our standards currently stand; any movement forward from that would be welcome to me. And, as I said before, I think that there will not be much that we can achieve rough consensus on when it comes to IETF Last Call. Tom Petch > > File system resources are normally addressed by the operating system's > convention. We can come up with all sorts of notations, but at the end > of the day the OS system call (POSIX open, Win32 CreateFile, etc.) is > what matters. The OS needs to be consistent with itself and with > applications on it; it's also important that two instances of the same > OS (or OS families) agree on things, so that applications and data > written with that OS (family) in mind can work on different machines. > > But from the perspective of Internet architecture, all those things are > a "local convention"--that magical escape that in IETF-speak means "do > whatever at the endpoints, it doesn't affect the network". > draft-kerwin-file-scheme talks about local conventions but the overall > gist is trying to stuff local conventions into a common format, and > flailing about by addressing these disparate use cases (mostly Windows, > but some OpenVMS) that have cropped up. > > It is not surprising, by the way, that Windows causes difficulties while > Unix/POSIX is less problematic, since the URI convention of "/" for path > separators and "/" as the root path directly descends from Unix/POSIX > (and from FTP [RFC 959]). > > I would like to suggest a totally different approach: > 1. file: identifies local filesystem resources (this includes filesystem > resources accessible via network paths such as UNC, since the filesystem > facility of the OS accommodates them). > 2. # is the fragment. > 3. everything else (the RFC 3986 and productions) is > a local convention. > > The draft can still include all of the current content, but move it into > informative appendices. > > If an application encounters a file URI for a local filesystem resource, > it should deal with it using the local convention. If an application > encounters a file URI for some non-local filesystem resource, it should > *leave it alone*. The end. > > In other words: why bother parsing a file URI if you know it's not going > to refer to a resource that you can make use of? If you're on Ubuntu > 14.04, why do you care about interpreting a file: URI that's meant for > Windows 7? The only thing this does is invite security problems, because > attackers will tell you (via the network) to perform operations on local > resources that they don't have the authority to say anything about. > > Another issue is the matter of non-ASCII character encoding, which has > always been dicey. [POSIX] is very clear that a paths as a sequence of > *bytes*, not characters. Other than "/", , and the relative > pathnames "." and "..", it's anything-goes. The mapping between bytes > and characters depends on the locale. In Windows NT, the kernel treats > pathnames as Unicode (specifically UCS-2/UTF-16); translations are done > in user-space. In Mac OS X, the HFS Plus file system converts all file > names to decomposed Unicode, i.e., Normalization Form D [HFSPLUSREF]. > > It is kind of seen as a moral imperative in the IETF to use UTF-8 (and > Normalization Form C), possibly because of [BCP18] and [RFC5198]. But > here, the only thing common is diversity--and each operating system > (vendor) has its own good reasons for its individual decisions. Since > file: URIs are always stored *in context*, context (the operating system > documentation, the LC_ALL environment variable, the declared encoding of > the text document, the identity of the local machine, etc.) provides all > the info that you need. Just say that the file: URI (outside of the > fragment component) encodes with local conventions--which are provided > by context--and be done with it. > > If you are taking things like file: URIs out of context...three suggestions: > > 1. Translate the file URI into the destination context. For example: if > you are in an HTML editor and you really want to reference > , but you are saving the HTML document in a > workgroup share, change the reference to > , and ensure that D:\pics is > shared as \\mycomputername\pics with appropriate access. Better yet: > upload the resource to an Internet-accessible location such as > , which for purposes of Internet > architecture, provides a more universal context. > > 2. Dereference the file URI and put whatever content you need into the > context. For example: in an HTML e-mail, don't use src="file:///D:/catpic.jpg">; use > and put the cat pic in the e-mail per [RFC2392] and [RFC2387]. > > 3. Don't do that. It doesn't make sense. > > Best regards, > > Sean > > [RFC959]: https://tools.ietf.org/html/rfc959 > [POSIX]: http://pubs.opengroup.org/onlinepubs/9699919799/ > [BCP18]: http://tools.ietf.org/html/bcp18 > [RFC5198]: http://tools.ietf.org/html/rfc5198 > [HFSPLUSREF]: https://developer.apple.com/library/mac/qa/qa1235/_index.html > [RFC2392]: http://tools.ietf.org/html/rfc2392 > [RFC2387]: http://tools.ietf.org/html/rfc2387 > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Tue Sep 30 03:03:54 2014 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 8BA8D1A0305 for ; Tue, 30 Sep 2014 03:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.386 X-Spam-Level: X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786] 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 owVApxQ10aUe for ; Tue, 30 Sep 2014 03:03:50 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71C31A0312 for ; Tue, 30 Sep 2014 03:03:50 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XYuHa-000DDo-EC; Tue, 30 Sep 2014 06:03:46 -0400 Date: Tue, 30 Sep 2014 06:03:41 -0400 From: John C Klensin To: Sean Leonard , "Murray S. Kucherawy" , Ned Freed Message-ID: <9AD273B04D7CB4B07CE8D1C5@JcK-HP8200.jck.com> In-Reply-To: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/pr1W_UVcmW3HnpMs1XS9DyNSouI Cc: IETF Apps Discuss Subject: Re: [apps-discuss] IETF 91 scheduling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 10:03:52 -0000 --On Monday, September 29, 2014 14:46 -0700 Sean Leonard wrote: > Topic: Archive TLMT >... > Here are some of the issues to be considered, which I put on > the proposed BoF agenda: Agenda > Discuss proposal to make archive TLMT > Identify use cases > Identify types of archives and whether these types of archives > should all go in, e.g.: archiving only, multi-function, > software packaging, disk images, backup Identify formats in >... Hi. I had planned to sit this one out because I see some value in the general idea and probably little harm. I also agree with Ned that things have evolved in a way that probably makes this reasonable and that there is little justification for trying to invent a complex architectural process before adding one new type. However, unless my memory is failing me, there is one historical tidbit about which people should be aware. Ned wrote "There used to be a strong reluctance to register media types for archive formats". My recollection is that it was a bit more than that, that archives (particularly of the zip and tar persuasions) were explicitly discussed and believed to be orthogonal to Content-type and Content-transfer-encoding, inappropriate for top-level Content-types (now Media types) unless we expected email clients to actually take some action on them, e.g., by exploding them or having some other specific action routines for them. That is where the analogy to multipart/ (or even message/) breaks down a bit because we have precisely that expectation of those top level aggregate and potentially aggregate types. By contrast, archive/ would really be an aggregate identifier for components that, at least with the two or three most popular archive formats, do not have media types except by naming convention. If the intent is merely to identify the content, rather than expecting action and to create another top-level type that, like application/ is expected to be opaque to the mail system, perhaps we should be generalizing and considering "container/" or, to borrow a note from X.400, even "FileTransfer/", rather than thinking there is something extra-special about archives. On the other hand, there is something extra-special, which is frequency of use, and things have changed a lot since Content/Media types were first defined in the current contexts, so this is just something to think about rather than a strong alternate suggestion. john From nobody Tue Sep 30 09:41:18 2014 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 794EC1A1B0C for ; Tue, 30 Sep 2014 09:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dU7EwgaTvZiL for ; Tue, 30 Sep 2014 09:41:13 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86FF11A1B04 for ; Tue, 30 Sep 2014 09:41:06 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8UGf2tD016098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 30 Sep 2014 09:41:06 -0700 Message-ID: <542ADD1B.6040108@dcrocker.net> Date: Tue, 30 Sep 2014 09:40:59 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ned Freed References: <54235269.2060002@seantek.com> <8c556e8a-4786-4467-a7a6-63ab8dafb890@flaska.net> <01PD5P42RUJ80000XZ@mauve.mrochek.com> <5429CAB4.6030400@dcrocker.net> <01PD6AHJQ2GY0000XZ@mauve.mrochek.com> In-Reply-To: <01PD6AHJQ2GY0000XZ@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 30 Sep 2014 09:41:06 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_Za43cvZ97JeAQyI1uKW03eyzTc Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] A proposal for a new top-level media type: archive X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 16:41:15 -0000 On 9/29/2014 11:40 PM, Ned Freed wrote: >> There is a wide -- possibly infinite -- range of interesting, >> context-specific domain semantics that we might choose to class as >> "top-level". > > Really? In the past ~25 years, I'm aware of exactly three serious proposals to > create a new top-level type: Model, font, and now archive. (There have been a > few others, e.g., iso for ISO-specified formats, but they did not meet the > basic criteria for top-level types.) My memory is often terrible, of course, but I had the impression that: a) We've previously been rather resistant to proposals; this sets a tone that discourages proposals, and certainly the long history of not adding top-level types establishes a de facto sense of barrier b) On the average, making additions to the top of an infrastructure hierarchy that hasn't been getting changed for some decades disrupts the support infrastructure. I'll bet folk can think of a very recent (current) IETF-related example... >> After all these years, what makes 'archive' appropriate for special >> handling and others not? > > Perhaps the fact that it makes sense as a top-level type in essentially > the same way as multipart and message do has something to do with it. > > The better question is why, after all these years, does defining archive now > make sense. The answer is: There used to be a strong reluctance to register > media types for archive formats. Again, I had the impression that the reluctance was broader and deeper. > Sounds like a hell of a lot of work to handle a process that seems to run about > once every 8 years, and which already has a requirement of a standards-track > RFC attached. Well, yeah. That's one way to keep the barrier fairly high, in pragmatic terms, if not formal ones. I'll stress that I'm not saying that I think that we /should/ resist new top-level types, like this one, merely that as a practical matter, we have. Further I'm saying that the fact of that history means adding a new top-level type at this point should be treated as a strategic change to an important infrastructure mechanism. If we want it to succeed... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Sep 30 16:10:58 2014 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 064F61ACCF8; Tue, 30 Sep 2014 16:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZhINiW-hvTT; Tue, 30 Sep 2014 16:10:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 520C21ACD0E; Tue, 30 Sep 2014 16:10:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140930231054.11279.13974.idtracker@ietfa.amsl.com> Date: Tue, 30 Sep 2014 16:10:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/AHI7nby55j3HL-Lx-7uM0BEThDM Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-authres-ptypes-registry-04.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: Tue, 30 Sep 2014 23:10:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : A Property Types Registry for the Authentication-Results Header Field Author : Murray S. Kucherawy Filename : draft-ietf-appsawg-authres-ptypes-registry-04.txt Pages : 6 Date : 2014-09-30 Abstract: This document updates RFC7001 by creating a registry for property types in the Authentication-Results header field, used in email authentication work, rather than limiting participants to using the original, small set of fixed values. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-authres-ptypes-registry/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-authres-ptypes-registry-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-authres-ptypes-registry-04 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 Sep 30 23:14:40 2014 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 98B681A00E8 for ; Tue, 30 Sep 2014 23:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, 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 F1VTQEl8bUGD for ; Tue, 30 Sep 2014 23:14:37 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id A95081A0065 for ; Tue, 30 Sep 2014 23:14:36 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PD7N01FYTC0057AN@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 30 Sep 2014 23:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1412143773; bh=RkNHDCclNN5asd6seYF9UEdnoVVpeqQh7EVtSMx4BjA=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=INcd/suuX2GTtkUr4vYyB9FuC5mzDbJt8t3B38TfCvmPt2XPpWLGScg8EsVKi+OvZ uJF4JqAG367PGGUfH0xqTXuRl2PG+YAIQglqH5fBPDfSgW4CtyhUDJqLJq/H15SIb2 NjQRxXp3XrvXTYdHIjZUq49hqqPHGz/TJxJv5kjo= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PD6APO0TN4002P23@mauve.mrochek.com>; Tue, 30 Sep 2014 23:09:30 -0700 (PDT) Message-id: <01PD7MZYXD7S002P23@mauve.mrochek.com> Date: Tue, 30 Sep 2014 22:55:24 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 30 Sep 2014 09:40:59 -0700" <542ADD1B.6040108@dcrocker.net> References: <54235269.2060002@seantek.com> <8c556e8a-4786-4467-a7a6-63ab8dafb890@flaska.net> <01PD5P42RUJ80000XZ@mauve.mrochek.com> <5429CAB4.6030400@dcrocker.net> <01PD6AHJQ2GY0000XZ@mauve.mrochek.com> <542ADD1B.6040108@dcrocker.net> To: Dave Crocker Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3OGS1O0MW5klC5RIUjtenf_LhXY Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] A proposal for a new top-level media type: archive 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, 01 Oct 2014 06:14:38 -0000 > On 9/29/2014 11:40 PM, Ned Freed wrote: > >> There is a wide -- possibly infinite -- range of interesting, > >> context-specific domain semantics that we might choose to class as > >> "top-level". > > > > Really? In the past ~25 years, I'm aware of exactly three serious proposals to > > create a new top-level type: Model, font, and now archive. (There have been a > > few others, e.g., iso for ISO-specified formats, but they did not meet the > > basic criteria for top-level types.) > My memory is often terrible, of course, but I had the impression that: > a) We've previously been rather resistant to proposals; this sets a > tone that discourages proposals, and certainly the long history of not > adding top-level types establishes a de facto sense of barrier AFAIK the only proposals we've been resistant to have been ones that clearly didn't make sense. > b) On the average, making additions to the top of an infrastructure > hierarchy that hasn't been getting changed for some decades disrupts the > support infrastructure. I'll bet folk can think of a very recent > (current) IETF-related example... I have considerable familiarity with the support infrastructure in this particular case, and I can think of exactly one case where's there's an inherent problem adding top-level types: SDP. But in this case the bigger problem would be what an archive type means in the context of SDP, not how to represent it. > >> After all these years, what makes 'archive' appropriate for special > >> handling and others not? > > > > Perhaps the fact that it makes sense as a top-level type in essentially > > the same way as multipart and message do has something to do with it. > > > > The better question is why, after all these years, does defining archive now > > make sense. The answer is: There used to be a strong reluctance to register > > media types for archive formats. > Again, I had the impression that the reluctance was broader and deeper. Suppose that's true. Why does it matter? The issue at hand isn't the registration of archive formats as media types. That's a done deal. > > Sounds like a hell of a lot of work to handle a process that seems to run about > > once every 8 years, and which already has a requirement of a standards-track > > RFC attached. > Well, yeah. That's one way to keep the barrier fairly high, in > pragmatic terms, if not formal ones. > I'll stress that I'm not saying that I think that we /should/ resist new > top-level types, like this one, merely that as a practical matter, we > have. > Further I'm saying that the fact of that history means adding a new > top-level type at this point should be treated as a strategic change to > an important infrastructure mechanism. Whereas I think the history says something else entirely. Ned