From nobody Sun Mar 6 21:10:26 2016 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C40861A8AE1; Sun, 6 Mar 2016 21:10:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160307051024.5620.50852.idtracker@ietfa.amsl.com> Date: Sun, 06 Mar 2016 21:10:24 -0800 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-seantek-windows-image-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, 07 Mar 2016 05:10:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ART Area General Applications Working Group of the IETF. Title : Windows Image Media Types Author : Sean Leonard Filename : draft-seantek-windows-image-02.txt Pages : 11 Date : 2016-03-06 Abstract: This document registers media types for certain image formats promulgated in Microsoft Windows, namely image/wmf, image/x-wmf, image/emf, image/x-emf, and image/bmp for use with Windows Metafile, Enhanced Metafile, and Windows Bitmap formats. Originally designed for Microsoft Windows 2.0 and 3.0, these image files are intended to be portable between applications and devices, and may contain both vector and raster graphics. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-seantek-windows-image/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-seantek-windows-image-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-seantek-windows-image-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 Wed Mar 9 11:07:03 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B047D12D93F for ; Wed, 9 Mar 2016 11:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0X1Ka9lSs3r for ; Wed, 9 Mar 2016 11:06:54 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E0612D941 for ; Wed, 9 Mar 2016 11:05:38 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id e185so67715039vkb.1 for ; Wed, 09 Mar 2016 11:05:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=wPmHyBujc2hGP3CMFI/upvzDUA3jeNBwNHk4Fa2O/J8=; b=qpVKYIlktluama5iFngicVcKeGwzKo1P95sTf5DYG4tx35h9+Qvk2VJwecTh9kW1K+ +DSHfNLYcmqxOxYAFAZ1lyOEz82+77U3VJlG3WPWvTAADfY8AKaVH2IislsOb2NvDB3f d9tNUssFyK8dfUcFHpQCcuWAGaW8qyhF/4qYqxfF4Z3Vr6+fKhhb6zOtkeO7XI1n/RPn u5GQUexhZmdYomXS5TWR88QoOe+CaBOq9eRo+7ScqCtMJgdjpIAWZCOoqCx9uc1228bj jC1xG4XoFpejmgAyHG435nlAzSi2SEbGXOnvmBIpqrzQlumxtxNfW31g/yhx/+eQdHf1 YF3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=wPmHyBujc2hGP3CMFI/upvzDUA3jeNBwNHk4Fa2O/J8=; b=b9OlMuoAHv6N5nwd/eUc4jzvoQ2GXCdkq5jK1zYwGI5yF+zanKBlp43TYqLgSQoI3s H/Y3rhDE4yt0FoA3iY5szvJMO3PdG/PbcPqvWrjoEloKKizP4ZYMMZ3RIIY2FZReuY8m +s85h/JEu8Cy92E6mLWC3q4TvTQPtGr+sRbtO61D2Qq+SEYEVYtMxBNBhR1bwT35na6b BzXd+VTp7TnqVk8MlUENTu166doKtfhO0P+OQul7I+q9xBO9du8Qj7m25o1Sa16J+ayW /1D/qhxPJ2HnTQxLB8hv2VryEHL/8M9vA7SBOZg+Fzf5I52qjgOXHtcawU3WTRumwGbQ eZEQ== X-Gm-Message-State: AD7BkJJ558G9CiI5oA+jMWoWs+eNb6HGvCG3HjY4rlPkbsjs4XQIeD1aTQa+FrGh5sZodZangZo5k5/yybsAiQ== MIME-Version: 1.0 X-Received: by 10.31.171.143 with SMTP id u137mr34229570vke.88.1457550337700; Wed, 09 Mar 2016 11:05:37 -0800 (PST) Received: by 10.103.43.5 with HTTP; Wed, 9 Mar 2016 11:05:37 -0800 (PST) Date: Wed, 9 Mar 2016 11:05:37 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a1143e99c1ef829052da262a7 Archived-At: Subject: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-mdn-3798bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2016 19:07:00 -0000 --001a1143e99c1ef829052da262a7 Content-Type: text/plain; charset=UTF-8 Colleagues, This message initiates an extended Working Group Last Call for draft-ietf-appsawg-mdn-3798bis, ending Friday, March 25. 2016. Please submit substantive comments of support or other review feedback to apps-discuss@ietf.org (preferably on this thread), or privately to the authors or to appsawg-chairs@tools.ietf.org, prior to that date. We will need to see enough of these to be able to judge rough consensus of the working group before it can be sent to our Area Director to start the formal publication process. I will be acting as document shepherd for this document. Thank you, -MSK, APPSAWG co-chair --001a1143e99c1ef829052da262a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

This message initiates a= n extended Working Group Last Call for draft-ietf-appsawg-mdn-3798bis, endi= ng Friday, March 25. 2016.=C2=A0 Please submit substantive comments of supp= ort or other review feedback to apps-discuss@ietf.org (preferably on this thread), or p= rivately to the authors or to appsawg-chairs@tools.ietf.org, prior to that date.=C2=A0 We will need to see enough of these to be able t= o=20 judge rough consensus of the working group before it can be sent to our=20 Area Director to start the formal publication process.

I will be acting as document shepherd for this document.

<= br>
Thank you,

-MSK, APPSAWG co-chair
--001a1143e99c1ef829052da262a7-- From nobody Wed Mar 9 17:30:06 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6358A12D6B0; Wed, 9 Mar 2016 17:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 jGvVWRFCYER5; Wed, 9 Mar 2016 17:29:57 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 481AF12D6AA; Wed, 9 Mar 2016 17:29:57 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E30D9509B8; Wed, 9 Mar 2016 20:29:55 -0500 (EST) To: Darrel Miller , media-types@ietf.org References: <56DE624C.6020700@seantek.com> <56E0C35B.9@seantek.com> From: Sean Leonard Message-ID: <56E0CDBA.3050301@seantek.com> Date: Wed, 9 Mar 2016 17:28:26 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: dispatch@ietf.org, "apps-discuss@ietf.org" Subject: [apps-discuss] text/yaml Re: [media-types] OpenApi media type registration questions X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 01:29:59 -0000 [adding apps-discuss and dispatch] On 3/9/2016 5:20 PM, Darrel Miller wrote: > Sean, > >> -----Original Message----- >> From: media-types [mailto:media-types-bounces@ietf.org] On Behalf Of >> Sean Leonard >> RFC 6838 Section 6 >> https://tools.ietf.org/html/rfc6838#section-6 >> >> RFC 6839 has examples of the template actually instantiated in the tex= t. >> > Thanks. So this is where I find myself in a catch-22 situation. In ord= er to > register the +yaml suffix, it needs to there a reference to a specifica= tion > for YAML. However, there is no such specification that is managed by a= SDO. > I searched in the YAML Core mailing list and back in 2003 they discusse= d > their plan to use text/yaml as the media type. There has been no furth= er > discussion of registering a media type since then on the list. > > So it seems that, without a spec under an SDO, it would not be possible= to > register text/yaml or register the suffix. > > It seems that the only option available would be for someone to convinc= e the > YAML team to allow a variant of their spec (it has images in it) to be > created as an IETF spec. > > Does that reasoning appear sound? Not exactly. First of all, it's the same situation as Markdown (see the text/markdown = discussion over time on the apps-discuss mailing list). The most important hurdle has been passed: some people actually *want*=20 text/yaml. The second hurdle has also (likely) been passed: people are actually=20 using text/yaml for YAML stuff. This turns out to be more useful than=20 the registration itself. Deploy first, register later. ;-) The next hurdle is overcoming developer laziness, since it requires some = modicum of effort to do the registration. Sounds like we have a willing=20 victim...er...volunteer. ;-) Getting text/yaml just requires an Informational independent-stream or=20 IETF stream RFC. First write an Internet-Draft. The Internet-Draft can=20 reference the yaml.org specification, without changing control over the=20 specification to the IETF. Then submit the draft to the dispatch mailing = list. (Maybe also a couple of other mailing lists, for places in IETF=20 that use YAML.) Depending on the outcome of the discussion, either the IETF will take it = up, or not. If they do, then the media type registration will be=20 published with IETF Consensus (see text/markdown). If not, then it can=20 still be published an the independent stream by submitting it to the=20 Independent Submissions Editor (see image/bmp, aka=20 draft-seantek-windows-image)=20 . I have not tried to register a structured syntax suffix before.=20 Superficially, the process appears to be simpler, as it only needs=20 Expert Review. For that, just follow what RFC 6838 Section 6 says. Best of luck! Sean From nobody Wed Mar 9 21:41:36 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F07012D50D for ; Wed, 9 Mar 2016 21:41:34 -0800 (PST) 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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3j3xYbeJwrWv for ; Wed, 9 Mar 2016 21:41:32 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B2A12D50B for ; Wed, 9 Mar 2016 21:41:32 -0800 (PST) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 6F256C4017C for ; Wed, 9 Mar 2016 23:41:30 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1457588490; bh=e0or8sRi2ddXE5SqQ9aqGujnmh7IfRUJLIk5rb+2n2s=; h=From:To:Subject:Date:In-Reply-To:References:From; b=KTpbn1o+xsXlIod8jSuWzHWuAzeSJTrm9DZlrT9wAauuowERn3/HhlNchj0wHJIXP Io/GewWnwDQQV2yB5b/SZntuvecvTKk/9LV0Mp39eRxiO13RBqmprcrc850YpIiRwi TSscz+lNyUqhmVP5NQQzEnO18mSeNtXZUcRHXJmM= From: Scott Kitterman To: apps-discuss@ietf.org Date: Thu, 10 Mar 2016 00:41:32 -0500 Message-ID: <4354120.g6DGuWIEuT@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-77-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <56E0CDBA.3050301@seantek.com> References: <56E0CDBA.3050301@seantek.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [apps-discuss] text/yaml Re: [media-types] OpenApi media type registration questions X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 05:41:34 -0000 On Wednesday, March 09, 2016 05:28:26 PM Sean Leonard wrote: > [adding apps-discuss and dispatch] > > On 3/9/2016 5:20 PM, Darrel Miller wrote: > > Sean, > > > >> -----Original Message----- > >> From: media-types [mailto:media-types-bounces@ietf.org] On Behalf Of > >> Sean Leonard > >> RFC 6838 Section 6 > >> https://tools.ietf.org/html/rfc6838#section-6 > >> > >> RFC 6839 has examples of the template actually instantiated in the text. > > > > Thanks. So this is where I find myself in a catch-22 situation. In order > > to register the +yaml suffix, it needs to there a reference to a > > specification for YAML. However, there is no such specification that is > > managed by a SDO. I searched in the YAML Core mailing list and back in > > 2003 they discussed their plan to use text/yaml as the media type. There > > has been no further discussion of registering a media type since then on > > the list. > > > > So it seems that, without a spec under an SDO, it would not be possible to > > register text/yaml or register the suffix. > > > > It seems that the only option available would be for someone to convince > > the YAML team to allow a variant of their spec (it has images in it) to > > be created as an IETF spec. > > > > Does that reasoning appear sound? > > Not exactly. > > First of all, it's the same situation as Markdown (see the text/markdown > discussion over time on the apps-discuss mailing list). > > The most important hurdle has been passed: some people actually *want* > text/yaml. > > The second hurdle has also (likely) been passed: people are actually > using text/yaml for YAML stuff. This turns out to be more useful than > the registration itself. Deploy first, register later. ;-) > > The next hurdle is overcoming developer laziness, since it requires some > modicum of effort to do the registration. Sounds like we have a willing > victim...er...volunteer. ;-) > > Getting text/yaml just requires an Informational independent-stream or > IETF stream RFC. First write an Internet-Draft. The Internet-Draft can > reference the yaml.org specification, without changing control over the > specification to the IETF. Then submit the draft to the dispatch mailing > list. (Maybe also a couple of other mailing lists, for places in IETF > that use YAML.) > > Depending on the outcome of the discussion, either the IETF will take it > up, or not. If they do, then the media type registration will be > published with IETF Consensus (see text/markdown). If not, then it can > still be published an the independent stream by submitting it to the > Independent Submissions Editor (see image/bmp, aka > draft-seantek-windows-image) > . > > > I have not tried to register a structured syntax suffix before. > Superficially, the process appears to be simpler, as it only needs > Expert Review. For that, just follow what RFC 6838 Section 6 says. Are we talking YAML 1.0, YAML 1.1, or the draft YAML 2.0 that's currently being specified? Does it matter? Scott K From nobody Thu Mar 10 02:02:02 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9552E12D63C for ; Thu, 10 Mar 2016 02:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 F0VCPYJ-f0Os for ; Thu, 10 Mar 2016 02:01:58 -0800 (PST) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E4212D62E for ; Thu, 10 Mar 2016 02:01:57 -0800 (PST) Received: from mfilter21-d.gandi.net (mfilter21-d.gandi.net [217.70.178.149]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 83E1D41C0E9; Thu, 10 Mar 2016 11:01:55 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter21-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter21-d.gandi.net (mfilter21-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 8EyASTcRgZKL; Thu, 10 Mar 2016 11:01:53 +0100 (CET) X-Originating-IP: 93.204.214.47 Received: from nar.local (p5DCCD62F.dip0.t-ipconnect.de [93.204.214.47]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 9D07B41C11E; Thu, 10 Mar 2016 11:01:33 +0100 (CET) Message-ID: <56E145FB.5010303@tzi.org> Date: Thu, 10 Mar 2016 11:01:31 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Scott Kitterman References: <56E0CDBA.3050301@seantek.com> <4354120.g6DGuWIEuT@kitterma-e6430> In-Reply-To: <4354120.g6DGuWIEuT@kitterma-e6430> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] text/yaml Re: [media-types] OpenApi media type registration questions X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 10:02:01 -0000 I missed the YAML 2.0 activity -- do you have a pointer? What's out there is mainly YAML 1.2, and that would be the target. (I'm interested in this not only because most software I use has some YAML component to it, but also because YAML and CBOR have a pretty good feature match -- CBOR already has its JSON-based "diagnostic notation", but YAML as a human-oriented extension of JSON brings a lot to the table.) Grüße, Carsten Scott Kitterman wrote: > On Wednesday, March 09, 2016 05:28:26 PM Sean Leonard wrote: >> [adding apps-discuss and dispatch] >> >> On 3/9/2016 5:20 PM, Darrel Miller wrote: >>> Sean, >>> >>>> -----Original Message----- >>>> From: media-types [mailto:media-types-bounces@ietf.org] On Behalf Of >>>> Sean Leonard >>>> RFC 6838 Section 6 >>>> https://tools.ietf.org/html/rfc6838#section-6 >>>> >>>> RFC 6839 has examples of the template actually instantiated in the text. >>> Thanks. So this is where I find myself in a catch-22 situation. In order >>> to register the +yaml suffix, it needs to there a reference to a >>> specification for YAML. However, there is no such specification that is >>> managed by a SDO. I searched in the YAML Core mailing list and back in >>> 2003 they discussed their plan to use text/yaml as the media type. There >>> has been no further discussion of registering a media type since then on >>> the list. >>> >>> So it seems that, without a spec under an SDO, it would not be possible to >>> register text/yaml or register the suffix. >>> >>> It seems that the only option available would be for someone to convince >>> the YAML team to allow a variant of their spec (it has images in it) to >>> be created as an IETF spec. >>> >>> Does that reasoning appear sound? >> Not exactly. >> >> First of all, it's the same situation as Markdown (see the text/markdown >> discussion over time on the apps-discuss mailing list). >> >> The most important hurdle has been passed: some people actually *want* >> text/yaml. >> >> The second hurdle has also (likely) been passed: people are actually >> using text/yaml for YAML stuff. This turns out to be more useful than >> the registration itself. Deploy first, register later. ;-) >> >> The next hurdle is overcoming developer laziness, since it requires some >> modicum of effort to do the registration. Sounds like we have a willing >> victim...er...volunteer. ;-) >> >> Getting text/yaml just requires an Informational independent-stream or >> IETF stream RFC. First write an Internet-Draft. The Internet-Draft can >> reference the yaml.org specification, without changing control over the >> specification to the IETF. Then submit the draft to the dispatch mailing >> list. (Maybe also a couple of other mailing lists, for places in IETF >> that use YAML.) >> >> Depending on the outcome of the discussion, either the IETF will take it >> up, or not. If they do, then the media type registration will be >> published with IETF Consensus (see text/markdown). If not, then it can >> still be published an the independent stream by submitting it to the >> Independent Submissions Editor (see image/bmp, aka >> draft-seantek-windows-image) >> . >> >> >> I have not tried to register a structured syntax suffix before. >> Superficially, the process appears to be simpler, as it only needs >> Expert Review. For that, just follow what RFC 6838 Section 6 says. > > Are we talking YAML 1.0, YAML 1.1, or the draft YAML 2.0 that's currently > being specified? Does it matter? > > Scott K > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Thu Mar 10 06:07:46 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D6612D89C for ; Thu, 10 Mar 2016 06:07:45 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 oRnD4UyR6xIw for ; Thu, 10 Mar 2016 06:07:43 -0800 (PST) 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 4F99212D909 for ; Thu, 10 Mar 2016 06:01:04 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 48483FA0082; Thu, 10 Mar 2016 14:01:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1457618462; bh=Ob/5KkDA2DTw5v6hI+vFJ87lEH4QNSDOZDCnpLfHoq0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=HTu4csWp/aK/pXgITamiccZ2xF/ZYRuzXK3XYqapzk80EeBYQP5VAp+KyyQJDpUtO dyZofyzhyBxFOkPovnFgkEZAfTXa6fe5NC54rQ/jRrLg1uwBP9wt13ElGfD92VLBtI k8xSGK+GC+q9jq6WcVvNavH/xbnc7o9zKoBaAv5s= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1457618461-637-19604/11/13; Thu, 10 Mar 2016 14:01:01 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Thu, 10 Mar 2016 14:01:00 +0000 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Debian GNU/Linux 8.2 (jessie) Mime-Version: 1.0 Message-Id: In-Reply-To: <56E145FB.5010303@tzi.org> References: <56E0CDBA.3050301@seantek.com> <4354120.g6DGuWIEuT@kitterma-e6430> <56E145FB.5010303@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [apps-discuss] text/yaml Re: [media-types] OpenApi media type registration questions X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 14:07:45 -0000 Why should the registration be specific to one version? I think the most widely used type with significantly different versions is HTML. AFAICT, the text/html media type is used for all versions of HTML in practice, https://www.iana.org/assignments/media-types/text/html seems to permit that, and if it's been a major problem, I haven't noticed. Why is versioning more important to YAML than to HTML? Arnt From nobody Thu Mar 10 09:36:06 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C6512D558 for ; Thu, 10 Mar 2016 09:36:04 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjGpxNSvTMIo for ; Thu, 10 Mar 2016 09:36:00 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B3DE12DAE6 for ; Thu, 10 Mar 2016 09:36:00 -0800 (PST) Received: from [10.133.70.129] (unknown [166.170.29.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 35FDAC40228; Thu, 10 Mar 2016 11:35:59 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1457631359; bh=fY/kWRMyCmHhX9tN9NcB0WUs5fdWUFYMJE5uV8gLimQ=; h=In-Reply-To:References:Subject:From:Date:To:CC:From; b=bJStYD8PJ6kyKFqp2Sk6gfxygZi0ueV+Me/npDKPC2ush5VAhNR+g6cgYWikKlEYf qXnk1KXXaXUftRXfQMFQ9lUYe91+ZaiHpaZiS3aWKpOe4gPA3a/tAXLq/hasaoqtyo jgcrgbkV+f7UnMpqcQRxeTHdm8NnpAhSUqODkQnI= User-Agent: K-9 Mail for Android In-Reply-To: <56E145FB.5010303@tzi.org> References: <56E0CDBA.3050301@seantek.com> <4354120.g6DGuWIEuT@kitterma-e6430> <56E145FB.5010303@tzi.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Thu, 10 Mar 2016 12:35:56 -0500 To: Carsten Bormann Message-ID: <3D41BF2D-F1D3-486C-B71E-3135D1817FE0@kitterman.com> Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] text/yaml Re: [media-types] OpenApi media type registration questions X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 17:36:04 -0000 I've seen the discussions on Yaml Core . Scott K On March 10, 2016 5:01:31 AM EST, Carsten Bormann wrote: >I missed the YAML 2.0 activity -- do you have a pointer? > >What's out there is mainly YAML 1.2, and that would be the target. > >(I'm interested in this not only because most software I use has some >YAML component to it, but also because YAML and CBOR have a pretty good >feature match -- CBOR already has its JSON-based "diagnostic notation", >but YAML as a human-oriented extension of JSON brings a lot to the >table.) > >Grüße, Carsten > > >Scott Kitterman wrote: >> On Wednesday, March 09, 2016 05:28:26 PM Sean Leonard wrote: >>> [adding apps-discuss and dispatch] >>> >>> On 3/9/2016 5:20 PM, Darrel Miller wrote: >>>> Sean, >>>> >>>>> -----Original Message----- >>>>> From: media-types [mailto:media-types-bounces@ietf.org] On Behalf >Of >>>>> Sean Leonard >>>>> RFC 6838 Section 6 >>>>> https://tools.ietf.org/html/rfc6838#section-6 >>>>> >>>>> RFC 6839 has examples of the template actually instantiated in the >text. >>>> Thanks. So this is where I find myself in a catch-22 situation. In >order >>>> to register the +yaml suffix, it needs to there a reference to a >>>> specification for YAML. However, there is no such specification >that is >>>> managed by a SDO. I searched in the YAML Core mailing list and back >in >>>> 2003 they discussed their plan to use text/yaml as the media type. >There >>>> has been no further discussion of registering a media type since >then on >>>> the list. >>>> >>>> So it seems that, without a spec under an SDO, it would not be >possible to >>>> register text/yaml or register the suffix. >>>> >>>> It seems that the only option available would be for someone to >convince >>>> the YAML team to allow a variant of their spec (it has images in >it) to >>>> be created as an IETF spec. >>>> >>>> Does that reasoning appear sound? >>> Not exactly. >>> >>> First of all, it's the same situation as Markdown (see the >text/markdown >>> discussion over time on the apps-discuss mailing list). >>> >>> The most important hurdle has been passed: some people actually >*want* >>> text/yaml. >>> >>> The second hurdle has also (likely) been passed: people are actually >>> using text/yaml for YAML stuff. This turns out to be more useful >than >>> the registration itself. Deploy first, register later. ;-) >>> >>> The next hurdle is overcoming developer laziness, since it requires >some >>> modicum of effort to do the registration. Sounds like we have a >willing >>> victim...er...volunteer. ;-) >>> >>> Getting text/yaml just requires an Informational independent-stream >or >>> IETF stream RFC. First write an Internet-Draft. The Internet-Draft >can >>> reference the yaml.org specification, without changing control over >the >>> specification to the IETF. Then submit the draft to the dispatch >mailing >>> list. (Maybe also a couple of other mailing lists, for places in >IETF >>> that use YAML.) >>> >>> Depending on the outcome of the discussion, either the IETF will >take it >>> up, or not. If they do, then the media type registration will be >>> published with IETF Consensus (see text/markdown). If not, then it >can >>> still be published an the independent stream by submitting it to the >>> Independent Submissions Editor (see image/bmp, aka >>> draft-seantek-windows-image) >>> . >>> >>> >>> I have not tried to register a structured syntax suffix before. >>> Superficially, the process appears to be simpler, as it only needs >>> Expert Review. For that, just follow what RFC 6838 Section 6 says. >> >> Are we talking YAML 1.0, YAML 1.1, or the draft YAML 2.0 that's >currently >> being specified? Does it matter? >> >> Scott K >> >> _______________________________________________ >> 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 Thu Mar 10 09:44:17 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA9612DAAD for ; Thu, 10 Mar 2016 09:44:16 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9r2JSYYl4tW for ; Thu, 10 Mar 2016 09:44:14 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BC4C12D6FF for ; Thu, 10 Mar 2016 09:44:13 -0800 (PST) Received: from [10.133.70.129] (unknown [166.170.29.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B8ECCC40228; Thu, 10 Mar 2016 11:44:10 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1457631851; bh=rvKzWr29LuN43klxhbwdLD0X77wrR7PENQ0w5eA71B0=; h=In-Reply-To:References:Subject:From:Date:To:From; b=bSBiqk0Ma4RzClzOJ7lDY4KTC1FZqgsM5729PuoB7dQ+6C5GVGbrg3m0MTm8qvstl FZPkCPUjMasU3hNNWFdPuK3lJ5CMxfjyXDzolz4otO6Ny5SWkfry+spDbedzLAkHrE uPilKnDQ3plSxkXSicnhIon4Ria5X+AnnpGUMxXg= User-Agent: K-9 Mail for Android In-Reply-To: References: <56E0CDBA.3050301@seantek.com> <4354120.g6DGuWIEuT@kitterma-e6430> <56E145FB.5010303@tzi.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Thu, 10 Mar 2016 12:37:06 -0500 To: Arnt Gulbrandsen ,apps-discuss@ietf.org Message-ID: Archived-At: Subject: Re: [apps-discuss] text/yaml Re: [media-types] OpenApi media type registration questions X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 17:44:17 -0000 On March 10, 2016 9:01:00 AM EST, Arnt Gulbrandsen wrote: >Why should the registration be specific to one version? > >I think the most widely used type with significantly different versions >is >HTML. AFAICT, the text/html media type is used for all versions of HTML >in >practice, https://www.iana.org/assignments/media-types/text/html seems >to >permit that, and if it's been a major problem, I haven't noticed. > >Why is versioning more important to YAML than to HTML? I wasn't sure if it was important or not. Scott K From nobody Wed Mar 16 07:24:51 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D2C12D78A for ; Wed, 16 Mar 2016 07: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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 0BoznrvD-ZEn for ; Wed, 16 Mar 2016 07:24:41 -0700 (PDT) Received: from sogo.guto.nl (guto.nl [178.21.117.49]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59F6912D722 for ; Wed, 16 Mar 2016 07:24:29 -0700 (PDT) Received: from wlan018160.mobiel.utwente.nl ([130.89.18.160]) by sogo.guto.nl with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1agCN6-0000Ys-BC; Wed, 16 Mar 2016 15:24:25 +0100 To: Matthew Kerwin , IETF Apps Discuss References: <20151201004350.6084.94598.idtracker@ietfa.amsl.com> From: Stephan Bosch Message-ID: <56E96C95.1020106@rename-it.nl> Date: Wed, 16 Mar 2016 15:24:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090300000202030402070205" X-SA-Exim-Connect-IP: 130.89.18.160 X-SA-Exim-Mail-From: stephan@rename-it.nl X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on sogo.guto.nl) Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-05.txt (relative URIs) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 14:24:50 -0000 This is a multi-part message in MIME format. --------------090300000202030402070205 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi, I have a question about relative URI resolution with respect to the file URI. I know I am a bit late to the party, but this work hasn't caught my eye before; I only read this draft in a moment of boredom in my coffee break. I quickly skimmed the mailing list, but I haven't seen any recent discussions on this topic. There is only a very specific Windows case described in Appendix C of the draft. I am not an expert, but I find RFC 3986 Section 5 rather confusing. When is reference resolution applied? According to Section 5.2.2, absolute URIs can be subject to the resolution algorithm as well. The main effect of that is the application of the remove_dot_segments() algorithm, which removes all "../" and "./" instances from the path. So, is this always applied before a URI is interpreted? Does it apply to an absolute file URI? This leads to the following concrete questions: - Does the OS file system path extracted from an absolute file URI like "file:/frop/./friep/../frml" include the dot segments? Or is the remove_dot_segments() normalization always applied? So, is "/frop/frml" or "/frop/./friep/../frml" going to be passed to e.g. the open() system call on a POSIX system? Does that matter? It might: when the path contains symbolic links on a POSIX system, the use of ".." can cause semantic differences between the URI-based normalization and what POSIX systems do. Here's the GLibC implementation of the stdlib realpath() function that performs the POSIX equivalent of remove_dot_segments(): https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/canonicalize.c;h=58bb8de949bc8cc705de7c0840c859fed7b06c01;hb=HEAD#l43 - In that regard, how are relative URIs handled when the base is a file URI? In any case, I think these concerns need to be addressed explicitly in the document, so that the semantics are always as clear as possible. Regards, Stephan. Op 1-12-2015 om 1:56 schreef Matthew Kerwin: > Hi folks, > > I've pushed out a new version of the file URI draft which I believe > addresses most of the feedback received over the past couple of weeks. > Looking at the rfcdiff[1] the biggest changes were: being more clear > about how we're using/overriding components like "authority" from RFC > 3986, and rearranging the examples throughout the appendices to be > "description - example" (from "example - description".) > > I also misspelled "ooperation." :\ > > Cheers > > [1]: > https://tools.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-05.txt > > > On 1 December 2015 at 10:43, > wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the ART Area General Applications > Working Group Working Group of the IETF. > > Title : The file URI Scheme > Author : Matthew Kerwin > Filename : draft-ietf-appsawg-file-scheme-05.txt > Pages : 20 > Date : 2015-11-30 > > Abstract: > This document specifies the "file" Uniform Resource Identifier > (URI) > scheme, obsoleting the definition in RFC 1738. > > It attempts to define a common core which is intended to > interoperate > across the broad spectrum of existing implementations, while at the > same time documenting other current practices. > > Note to Readers (To be removed by the RFC Editor) > > This draft should be discussed on the IETF Applications Area > Working > Group discussion list >. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-05 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at > tools.ietf.org . > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > -- > Matthew Kerwin > http://matthew.kerwin.net.au/ > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --------------090300000202030402070205 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi,

I have a question about relative URI resolution with respect to the file URI. I know I am a bit late to the party, but this work hasn't caught my eye before; I only read this draft in a moment of boredom in my coffee break. I quickly skimmed the mailing list, but I haven't seen any recent discussions on this topic. There is only a very specific Windows case described in Appendix C of the draft.

I am not an expert, but I find RFC 3986 Section 5 rather confusing. When is reference resolution applied? According to Section 5.2.2, absolute URIs can be subject to the resolution algorithm as well. The main effect of that is the application of the remove_dot_segments() algorithm, which removes all "../" and "./" instances from the path. So, is this always applied before a URI is interpreted? Does it apply to an absolute file URI? This leads to the following concrete questions:

- Does the OS file system path extracted from an absolute file URI like "file:/frop/./friep/../frml" include the dot segments? Or is the remove_dot_segments() normalization always applied? So, is "/frop/frml" or "/frop/./friep/../frml" going to be passed to e.g. the open() system call on a POSIX system?

Does that matter? It might: when the path contains symbolic links on a POSIX system, the use of ".." can cause semantic differences between the URI-based normalization and what POSIX systems do. Here's the GLibC implementation of the stdlib realpath() function that performs the POSIX equivalent of remove_dot_segments():

https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/canonicalize.c;h=58bb8de949bc8cc705de7c0840c859fed7b06c01;hb=HEAD#l43

- In that regard, how are relative URIs handled when the base is a file URI?

In any case, I think these concerns need to be addressed explicitly in the document, so that the semantics are always as clear as possible.

Regards,

Stephan.

 

Op 1-12-2015 om 1:56 schreef Matthew Kerwin:
Hi folks,

I've pushed out a new version of the file URI draft which I believe addresses most of the feedback received over the past couple of weeks. Looking at the rfcdiff[1] the biggest changes were: being more clear about how we're using/overriding components like "authority" from RFC 3986, and rearranging the examples throughout the appendices to be "description - example" (from "example - description".)

I also misspelled "ooperation."  :\

Cheers

[1]: https://tools.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-05.txt


On 1 December 2015 at 10:43, <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 ART Area General Applications Working Group Working Group of the IETF.

        Title           : The file URI Scheme
        Author          : Matthew Kerwin
        Filename        : draft-ietf-appsawg-file-scheme-05.txt
        Pages           : 20
        Date            : 2015-11-30

Abstract:
   This document specifies the "file" Uniform Resource Identifier (URI)
   scheme, obsoleting the definition in RFC 1738.

   It attempts to define a common core which is intended to interoperate
   across the broad spectrum of existing implementations, while at the
   same time documenting other current practices.

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

   This draft should be discussed on the IETF Applications Area Working
   Group discussion list <apps-discuss@ietf.org>.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-05


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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



--
  Matthew Kerwin
  http://matthew.kerwin.net.au/


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

--------------090300000202030402070205-- From nobody Wed Mar 16 15:05:03 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E5D12D728 for ; Wed, 16 Mar 2016 15:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9-2Iad3tFxn for ; Wed, 16 Mar 2016 15:04:52 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3234D12D72B for ; Wed, 16 Mar 2016 15:04:52 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id n190so76849062iof.0 for ; Wed, 16 Mar 2016 15:04:52 -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; bh=AX2Z1KBbEY1kY4XGSJDJpjGRKBTW1nv/vHdIThEbyhE=; b=GEP666GShKmIagWrbJAuNezjgrDU7tFEzqvgToR9dqSG6XAvNUxDJFRujZbq3ezFCV axjSFSTx7v6WhdHulBB0jJzx7+1Ou89SY6tVsBgdBcbM/AuujpUQRZJe46aLgSnaof3w mt1S+ZklvjJeEsRqZOefB1g7gs+M8dtKOxgwFMGf2U8yS2xE1Y2vcbCCs1TC0mXZOYlS zQOA2N0ehzI0OZ2WUi0QkzdAzaMcCL1FkUmXb3iJxwJhLcIRqzh/A8iJBCReKQ+7lqxB acN8IhVh4jm0FHefhINKQFN9ncRuPL//Zk3/5tb1xq15LSqBe2PZfkum1mY8FAVt7Mhi xk4g== 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; bh=AX2Z1KBbEY1kY4XGSJDJpjGRKBTW1nv/vHdIThEbyhE=; b=agb9O/3yOlPooFGs1injCl+H5B5AIhKdrCYeHtZI760pMQ8bkDk8/sMuooRyyJq594 T7ffWd7v25meqbBrW2D/zqCimZ3eUTODMavlx/fUPb7ZsdfDXoxZcyiSsP7+/aBdpQWG IoD1zsSfea1jGD7kTh0on0hiXmvhvaJm3QzJPfmzXdJTvEfZd5bZ1nF69Dw7uV0oFat1 QhN2GfR4L/uIWIarSiVlKq2pPwLQjHV+Q4QP8MD2hQpKO5Hd7ifIV9W8qmL23NAyVbGS avScaIJVt+vANBFkfmNuC6Qc94NT3HAHM0rjbvUyG+a2mZB+G+gnBFPe1qLhtcqk4k9I LsqQ== X-Gm-Message-State: AD7BkJJ2NBaOIw0YiYRsVqyxn2QIqoVgJ8eKjlwzais6wkoJOByIz+y/YsXXwVssrn0if30SrFGoBS/9oa1L5A== MIME-Version: 1.0 X-Received: by 10.107.11.10 with SMTP id v10mr6049979ioi.188.1458165891356; Wed, 16 Mar 2016 15:04:51 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.181.136 with HTTP; Wed, 16 Mar 2016 15:04:51 -0700 (PDT) Received: by 10.107.181.136 with HTTP; Wed, 16 Mar 2016 15:04:51 -0700 (PDT) In-Reply-To: <56E96C95.1020106@rename-it.nl> References: <20151201004350.6084.94598.idtracker@ietfa.amsl.com> <56E96C95.1020106@rename-it.nl> Date: Thu, 17 Mar 2016 08:04:51 +1000 X-Google-Sender-Auth: njg9d-UWxaSmOAs2zSustK47tM8 Message-ID: From: Matthew Kerwin To: Stephan Bosch Content-Type: multipart/alternative; boundary=001a113f9232fa5cb8052e31b347 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-05.txt (relative URIs) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 22:05:00 -0000 --001a113f9232fa5cb8052e31b347 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 17/03/2016 12:25 AM, "Stephan Bosch" wrote: > > Hi, > > I have a question about relative URI resolution with respect to the file URI. I know I am a bit late to the party, but this work hasn't caught my eye before; I only read this draft in a moment of boredom in my coffee break. I quickly skimmed the mailing list, but I haven't seen any recent discussions on this topic. There is only a very specific Windows case described in Appendix C of the draft. > > I am not an expert, but I find RFC 3986 Section 5 rather confusing. When is reference resolution applied? According to Section 5.2.2, absolute URIs can be subject to the resolution algorithm as well. The main effect of that is the application of the remove_dot_segments() algorithm, which removes all "../" and "./" instances from the path. So, is this always applied before a URI is interpreted? Does it apply to an absolute file URI? > Quoting from RFC 3986: =C2=A74.1 "A URI-reference is either a URI or a relative reference." This i= s a confusing and somewhat isolated statement, but it suggests to me that all URIs can be subject to normalisation as part of resolution. ---8<--- 5.2.4. Remove Dot Segments The pseudocode also refers to a "remove_dot_segments" routine for interpreting and removing the special "." and ".." complete path segments from a referenced path. This is done after the path is extracted from a reference, **whether or not the path was relative**, in order to remove any invalid or extraneous dot-segments prior to forming the target URI. --->8--- (My emphasis added.) Note that it says "from a reference", which includes 'URIs' per =C2=A74.1. ---8<--- 6.2.2.3. Path Segment Normalization The complete path segments "." and ".." are intended only for use within relative references (Section 4.1) and are removed as part of the reference resolution process (Section 5.2). However, some deployed implementations incorrectly assume that reference resolution is not necessary when the reference is already a URI and thus fail to remove dot-segments when they occur in non-relative paths. URI normalizers should remove dot-segments by applying the remove_dot_segments algorithm to the path, as described in Section 5.2.4. --->8--- This is the bit that gets me. A relative reference is clearly defined in the spec as: not starting with a scheme. The term 'URI' is fuzzy, but seems to be the complement (i.e. it does start with a scheme). So perhaps what we think of as an "absolute URI" is actually just a "URI" until it's been through remove_dot_segments and co. The quoted section also says "intended only for use within relative references", but doesn't outright forbid use elsewhere (i.e. in "URIs"). > This leads to the following concrete questions: > > - Does the OS file system path extracted from an absolute file URI like "file:/frop/./friep/../frml" include the dot segments? Or is the remove_dot_segments() normalization always applied? So, is "/frop/frml" or "/frop/./friep/../frml" going to be passed to e.g. the open() system call on a POSIX system? > According to =C2=A76.2.2.3, if you normalise the URI then the dots are remo= ved before the URI is converted to a file system path. It doesn't mandate said normalisation, so I guess that's between you and the OS. > [snip] > > - In that regard, how are relative URIs handled when the base is a file URI? > No different from any other URI scheme, except that in Windows/DOS you have this weird sub-authority/drive letter issue (C:/a/../../b =3D> C:/b). Which is quirky and hard to reconcile, hence the appendix. > In any case, I think these concerns need to be addressed explicitly in the document, so that the semantics are always as clear as possible. > Maybe. I think I might be missing some text in the appendix saying that a non-normalised URI passed to a DOS-based OS is likely to treat dot-segments a particular way. Maybe it's time to update 3986 itself; although I don't know that there's enough energy in the community to undertake such a feat. > Regards, > > Stephan. > Cheers --001a113f9232fa5cb8052e31b347 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 17/03/2016 12:25 AM, "Stephan Bosch" <stephan@rename-it.nl> wrote:
>
> Hi,
>
> I have a question about relative URI resolution with respect to the fi= le URI. I know I am a bit late to the party, but this work hasn't caugh= t my eye before; I only read this draft in a moment of boredom in my coffee= break. I quickly skimmed the mailing list, but I haven't seen any rece= nt discussions on this topic. There is only a very specific Windows case de= scribed in Appendix C of the draft.
>
> I am not an expert, but I find RFC 3986 Section 5 rather confusing. Wh= en is reference resolution applied? According to Section 5.2.2, absolute UR= Is can be subject to the resolution algorithm as well. The main effect of t= hat is the application of the remove_dot_segments() algorithm, which remove= s all "../" and "./" instances from the path. So, is th= is always applied before a URI is interpreted? Does it apply to an absolute= file URI?
>

Quoting from RFC 3986:

=C2=A74.1 "A URI-reference is either a URI or a relativ= e reference." This is a confusing and somewhat isolated statement, but= it suggests to me that all URIs can be subject to normalisation as part of= resolution.

---8<---
5.2.4.=C2=A0 Remove Dot Segments

=C2=A0=C2=A0 The pseudocode also refers to a "remove_do= t_segments" routine for
=C2=A0=C2=A0 interpreting and removing the special "." and "= .." complete path
=C2=A0=C2=A0 segments from a referenced path.=C2=A0 This is done after the = path is
=C2=A0=C2=A0 extracted from a reference, **whether or not the path was rela= tive**, in
=C2=A0=C2=A0 order to remove any invalid or extraneous dot-segments prior t= o
=C2=A0=C2=A0 forming the target URI.
--->8---

(My emphasis added.) Note that it says "from a referenc= e", which includes 'URIs' per =C2=A74.1.

---8<---
6.2.2.3.=C2=A0 Path Segment Normalization

=C2=A0=C2=A0 The complete path segments "." and &q= uot;.." are intended only for use
=C2=A0=C2=A0 within relative references (Section 4.1) and are removed as pa= rt of
=C2=A0=C2=A0 the reference resolution process (Section 5.2).=C2=A0 However,= some
=C2=A0=C2=A0 deployed implementations incorrectly assume that reference res= olution
=C2=A0=C2=A0 is not necessary when the reference is already a URI and thus = fail to
=C2=A0=C2=A0 remove dot-segments when they occur in non-relative paths.=C2= =A0 URI
=C2=A0=C2=A0 normalizers should remove dot-segments by applying the
=C2=A0=C2=A0 remove_dot_segments algorithm to the path, as described in
=C2=A0=C2=A0 Section 5.2.4.
--->8---

This is the bit that gets me. A relative reference is clearl= y defined in the spec as: not starting with a scheme. The term 'URI'= ; is fuzzy, but seems to be the complement (i.e. it does start with a schem= e). So perhaps what we think of as an "absolute URI" is actually = just a "URI" until it's been through remove_dot_segments and = co.

The quoted section also says "intended only for use wit= hin relative references", but doesn't outright forbid use elsewher= e (i.e. in "URIs").

<confused-shrug.gif>

> This leads to the following concrete questions:
>
> - Does the OS file system path extracted from an absolute file URI lik= e "file:/frop/./friep/../frml" include the dot segments? Or is th= e remove_dot_segments() normalization always applied? So, is "/frop/fr= ml" or "/frop/./friep/../frml" going to be passed to e.g. th= e open() system call on a POSIX system?
>

According to =C2=A76.2.2.3, if you normalise the URI then th= e dots are removed before the URI is converted to a file system path. It do= esn't mandate said normalisation, so I guess that's between you and= the OS.

> [snip]
>
> - In that regard, how are relative URIs handled when the base is a fil= e URI?
>

No different from any other URI scheme, except that in Windo= ws/DOS you have this weird sub-authority/drive letter issue (C:/a/../../b = =3D> C:/b). Which is quirky and hard to reconcile, hence the appendix.

> In any case, I think these concerns need to be addresse= d explicitly in the document, so that the semantics are always as clear as = possible.
>

Maybe. I think I might be missing some text in the appendix = saying that a non-normalised URI passed to a DOS-based OS is likely to trea= t dot-segments a particular way.

Maybe it's time to update 3986 itself; although I don= 9;t know that there's enough energy in the community to undertake such = a feat.

> Regards,
>
> Stephan.
>

Cheers

--001a113f9232fa5cb8052e31b347-- From nobody Tue Mar 22 12:48:21 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DE812D899 for ; Tue, 22 Mar 2016 12:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtxXk0rTA9vn for ; Tue, 22 Mar 2016 12:48:17 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9466C12D881 for ; Tue, 22 Mar 2016 12:48:17 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id o73so4374475lfe.0 for ; Tue, 22 Mar 2016 12:48:17 -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; bh=NpkGIKoy/ybgIqU9y5KCtkwhFDxQGqkJLQiORLKAAmU=; b=mtcDalgNDpIdYaOrgbJmtdm0fWq/aasZak2YOoCP/Nht2UjZIo/FEy4K8dmlHY/s9c P7cvw/rl1kK8IbE1B4kPilLiN5MePHLVIOK6Z29QUUnut2oOUCbBihdiveWxqnR7iuT0 XUP6yBZdqeDMrphpQzFRd8dvyJiOEKblFt8rKnR2IlpJV/vKfKM7dlgaNKipvy6UfnbX hMiRKZRwgFwsArQeueDUMf2+DU3m6ttoEq8619zKCRvG6QDGbJn1Pxg0iva7HjhY3Hd+ wG42YG8d5CADm/PjIH8qMfh33ntGNCZo8uytSOoQnYTTA7J20l3Dx3xj8VzA4rGFj5eo DiGA== 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:date:message-id:subject:from :to; bh=NpkGIKoy/ybgIqU9y5KCtkwhFDxQGqkJLQiORLKAAmU=; b=d0Ue+RV9wpOeL6jfn1mmMBt2NkQjq8g295Ljt0U2OZ1CmINwdiaWdgxaN3jyHb1U9Z MqAnnW+bWUg4M9p5P2WRMovAuflbCQgwNOmzv+oLDk5PPM7dM8kAvXPa+kzj2bgR4T8e W4+FGTTrjPJvUrqj76v8TEmMOkKNFm8vvynmULs/LlUExbtEcHVlbUuKoqctuPo51uUL DAR5ROMfIvK0knIuDUsSw8ySUUFk1xBj1e1s5k+8P74XFnulgitwga6F4NNwjW2jTIVN 0043q2wOpMg6h8bbxJU6xkR9KMqv5zEDvgILRrPkRUjIOlXnd+7BinE8j4jqXkistEwO PfKw== X-Gm-Message-State: AD7BkJKtdIEXfl1eZC5USIaaxcaFmDqZi6AiKqPu8HE44286ccJyidzRmILdoI4fs1Afqtl/n+APLzdn/LjGWQ== MIME-Version: 1.0 X-Received: by 10.25.91.76 with SMTP id p73mr1060781lfb.67.1458676095763; Tue, 22 Mar 2016 12:48:15 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.151.67 with HTTP; Tue, 22 Mar 2016 12:48:15 -0700 (PDT) Date: Tue, 22 Mar 2016 15:48:15 -0400 X-Google-Sender-Auth: GUPsyNTu2M4thcLAt-jek1UiKWk Message-ID: From: Phillip Hallam-Baker To: General discussion of application-layer protocols Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [apps-discuss] Automated specification generation tools X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 19:48:20 -0000 A while back I described a tool that I have been using as a code generator for JSON based applications. I have extended the tool since to the point where it almost (but not quite) writes the specification for you. The tool bundle itself is open source (MIT license, GitHub) and available from here: http://www.prismproof.org/downloads.html I am now working on some documentation and an example of a spec produced using the tool chain. This is one of the specs I have produced: https://tools.ietf.org/html/draft-hallambaker-lurk-01 Normally when you write a specification, there is a huge amount of back and forth as changes to the spec cause examples to be out of sync. Or you change the text in one place but not another. And of course it all gets worse if someone else writes stuff that has to be merged in. So what tends to happen is that the editor spends a lot of time checking the spec for consistency after each change and then reviewers do the same and then the spec goes out with some last minute change and you end up with errata. Alternatively, the spec is 100% right but someone's implementation is wrong. And because that is the implementation everyone has to interop with you end up with two specs, the one that was written and the defacto one you have to implement. The Protogen toolset is a suite of code building tools. They allow you to build specifications, examples and reference code from a single source. So any changes to that source automatically ripple through the spec. And anyone who does interop testing against the reference implementation can be fairly sure that they have done it right. Right now the tool set is (mostly) targeted at writing JSON specs but I have developed tools that I use with RFC 821 and RFC 822 style encodings, TLS schema and ASN.1 as well. These are only intended to support existing IETF specs though rather than develop more of the same. So the way I developed the LURK spec above in three days (i.e 24 man hours, not pulling three all nighters in a row) was that I started off describing the protocol in Word, then I roughed out the set of examples I wanted to produce to describe the spec, then I developed the schema from those. The second day, I worked on the Word documentation again, got the examples running with only request messages being generated. The third day I implemented the server dispatch function to give me the responses. If you prefer, you can use Markdown instead of Word. I am just in the middle of converting to Carsten's particular variant of the markup. This isn't just a quicker and less error prone way to write specs. The same tools generate C so you can integrate with existing implementations. The resulting specifications are a lot better than those you get writing by hand as well. Instead of different parts of the spec being written in a variety of styles, there is one consistent style applied throughout. The question now is what should that style be? From nobody Tue Mar 22 16:53:50 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE46112D0E6; Tue, 22 Mar 2016 16:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.923 X-Spam-Level: X-Spam-Status: No, score=-106.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 Y-xFtUeybZPr; Tue, 22 Mar 2016 16:53:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75CA412D11B; Tue, 22 Mar 2016 16:53:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7A6BC18046D; Tue, 22 Mar 2016 16:53:36 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160322235336.7A6BC18046D@rfc-editor.org> Date: Tue, 22 Mar 2016 16:53:36 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] RFC 7763 on The text/markdown Media Type X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 23:53:46 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7763 Title: The text/markdown Media Type Author: S. Leonard Status: Informational Stream: IETF Date: March 2016 Mailbox: dev+ietf@seantek.com Pages: 15 Characters: 34580 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-appsawg-text-markdown-12.txt URL: https://www.rfc-editor.org/info/rfc7763 DOI: http://dx.doi.org/10.17487/RFC7763 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 document is a product of the ART Area General Application Working Group Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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/retrieve/bulk 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 Tue Mar 22 16:54:08 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5E712D172; Tue, 22 Mar 2016 16:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.903 X-Spam-Level: X-Spam-Status: No, score=-106.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 wchp6rUw09HO; Tue, 22 Mar 2016 16:53:58 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DEA512D156; Tue, 22 Mar 2016 16:53:57 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E5A41180478; Tue, 22 Mar 2016 16:53:48 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160322235348.E5A41180478@rfc-editor.org> Date: Tue, 22 Mar 2016 16:53:48 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] RFC 7764 on Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 23:54:05 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7764 Title: Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations Author: S. Leonard Status: Informational Stream: IETF Date: March 2016 Mailbox: dev+ietf@seantek.com Pages: 28 Characters: 50910 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-appsawg-text-markdown-use-cases-07.txt URL: https://www.rfc-editor.org/info/rfc7764 DOI: http://dx.doi.org/10.17487/RFC7764 This document elaborates upon 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. Background information, local storage strategies, and additional syntax registrations are supplied. This document is a product of the ART Area General Application Working Group Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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/retrieve/bulk 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 Sun Mar 27 17:32:19 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED4A12D52E for ; Sun, 27 Mar 2016 17:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPZhy9Nz-7my for ; Sun, 27 Mar 2016 17:32:17 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503DA12D51C for ; Sun, 27 Mar 2016 17:32:17 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id e185so139194482vkb.1 for ; Sun, 27 Mar 2016 17:32:17 -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; bh=J+Jr2lW/J8R5XFWSW90ulqhq1bdsZ4zbIonHlNP9YBI=; b=R7pr2lT11qXSny1PZwou+K2QcBwRxWP9ABReqhbWsCmpNunh0vBMtT6YLsT9sSu9Ud aG4lcNfTVOZ0ouOPfrKIvBELvox9dPTZ5HhDG2YFM5ZBFV7m/Ua/UatMGkLJzuELfPPh 3LeqA89Ozps6vkZ7Sc6BgNGYY94IRd6NCMJtGN7v/k2NXUNLngEKwfpZCz1EaLNN+WFo Lum2sD4lM7lsRlP+uCzzg1KSj9xEFywfRQ1tBV8GwsVwhVrcC+U6YAxCWtSbduaKmAGY Paax2NikxNEqlNQPtKbt08R5uT78CDA76GjHl/QQD6xOdVqFZrmioi6JmkIbvMQefvEy EkVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=J+Jr2lW/J8R5XFWSW90ulqhq1bdsZ4zbIonHlNP9YBI=; b=fRVsXf8C2mhjVd1kfsK0uuncF+yRwIMaxq6noGHnbaMEjztXgOe0k/MiZVAJw5C1PJ m7FTyv751xgciJVnesdNr++wqrElMbiHwhOPUoPNjpQKXmnlNby7xmHYYFvRwatf4zv/ IZT47AjmQDaBMg4lLwVVHT6Nr5MXvBefrbv4L63Ow9uQ0jyrrq1BCdP68nm6Cm6l2LLV Q8Ma7bPkt35fFfiXKqRtLFZrXY2+HY05wPgx0panLW7R9xU6KJwO7I8ewcZj9WLz5WF0 Qi2XHlafiFO2fEpH36gtrRmYWvgUgAe3vcz0FVuH8qxWeCQhuftoN8R3J9B+hpfAazQ6 gdqQ== X-Gm-Message-State: AD7BkJK7y3R73GZ1LZB6o+A6xUpshuHVfnLnV2claCMg8VlEGMWMuiqZyq2YyG6Jmxe+r7aPHecvsVj6J2J2lA== MIME-Version: 1.0 X-Received: by 10.31.8.17 with SMTP id 17mr11117177vki.139.1459125136426; Sun, 27 Mar 2016 17:32:16 -0700 (PDT) Received: by 10.31.45.71 with HTTP; Sun, 27 Mar 2016 17:32:16 -0700 (PDT) Date: Sun, 27 Mar 2016 21:32:16 -0300 Message-ID: From: "Cristian F. Perez Monte" To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=001a11441d82708cd6052f110b68 Archived-At: Subject: [apps-discuss] new draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 00:32:19 -0000 --001a11441d82708cd6052f110b68 Content-Type: text/plain; charset=UTF-8 Hi all, Recently, I submitted a new draft , draft-appsawg-perez-sdcp-00 https://datatracker.ietf.org/doc/draft-appsawg-perez-sdcp/?include_text=1 I hope your suggestions and comments. Thank you very much. Regards, Cristian PS: The draft name should be draft-perez-appsawg-sdcp-00. I will fix this error as soon as possible. --001a11441d82708cd6052f110b68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Recently, I submitted a new draft , draft-a= ppsawg-perez-sdcp-00 https://datatracker.ietf.org/doc/draft-ap= psawg-perez-sdcp/?include_text=3D1

I hope your suggestions and c= omments.=C2=A0Thank you very much.

Regards,

Cristian

<= br>PS: The draft name should be draft-perez-appsawg-sdcp-00. I will fix thi= s error as soon as possible.
--001a11441d82708cd6052f110b68-- From nobody Sun Mar 27 21:10:09 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AEC12D0F1 for ; Sun, 27 Mar 2016 21:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: 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-1xJUCbbOU6 for ; Sun, 27 Mar 2016 21:10:06 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5B912D0F4 for ; Sun, 27 Mar 2016 21:10:05 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id e6so142809355vkh.2 for ; Sun, 27 Mar 2016 21:10:05 -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; bh=/kjGK2wbcMV4QESfS4brvvfrgHiVmKFrNSuAKwojHHk=; b=sWQJqH+CEtFPkI/n4GTwtIdlvyXJRUStdLFVKud4be9+UTeNrWSwExmlYzHJvc0oUj w+QMVsrQXn0PVIbIPfWKq6/yRMur6TtiqjGXDVbnEInhsWw3qJe95Y9K9LYwl52fp5Pp oMjx0Ad5kIW7ch9LYYM9oRNP7caDcSXUuPkDwVdvceCJOBS0BXHlogyYJAjmHLhaIyWV PZMUpTenFONAnOl8vxlRXsGlB/iQLt4G2nb68I4gtDRFYeHKpmGjV/jBxITWv2rkeuRe mPyjwsnbMEwgsS4WuNQGO5FJGzqNHNTW49dXck70FfA5SmzJsBNEumy7LPZPTHzCijrO ezcw== 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; bh=/kjGK2wbcMV4QESfS4brvvfrgHiVmKFrNSuAKwojHHk=; b=RWaC7awQf2ngnoMrB2jnoPDzrCHu0n+EinAJtKEzffwSuRB3MldbGunOW+5FyNLBQf O2+wT+dnBFN6I1RsrsKQBq/9NkuLFZmqRN9Y5rLmUgwH2m8sUYbAM+bt9i2Jv7Ecq9U+ oXNU8wA0SPcExQcQohGlqol4T5hZ3JllUwat994t8CSIMDPkQVFeV6CAUFPTVkJPZcMF CqDxIe10ds5DsBvroBwM/K5ytVyoFCdg46G7oyG8HX0vM1gO8YUBlo7iqk/+TezppmgL /82pNd4iEhQQLIOEKrl3ZLDtga6VsP0HK/g/1w5Us+JttbUiRJVoP9vaU0XLXJKrfl6F u4DA== X-Gm-Message-State: AD7BkJIT99atx8T5Apc5huZLvepL2qUzZ6DONwDAVCnS+Du/jpX653z+BkyuKUe1SB6jTsotuBqziS7PPMHZtg== MIME-Version: 1.0 X-Received: by 10.31.151.11 with SMTP id z11mr13247298vkd.131.1459138204902; Sun, 27 Mar 2016 21:10:04 -0700 (PDT) Received: by 10.103.43.5 with HTTP; Sun, 27 Mar 2016 21:10:04 -0700 (PDT) In-Reply-To: References: Date: Sun, 27 Mar 2016 21:10:04 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Cristian F. Perez Monte" Content-Type: multipart/alternative; boundary=001a1140f86a61ad82052f14168d Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] new draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 04:10:08 -0000 --001a1140f86a61ad82052f14168d Content-Type: text/plain; charset=UTF-8 On Sun, Mar 27, 2016 at 5:32 PM, Cristian F. Perez Monte wrote: > Recently, I submitted a new draft , draft-appsawg-perez-sdcp-00 > https://datatracker.ietf.org/doc/draft-appsawg-perez-sdcp/?include_text=1 > > I hope your suggestions and comments. Thank you very much. > > Regards, > > Cristian > > > PS: The draft name should be draft-perez-appsawg-sdcp-00. I will fix this > error as soon as possible. > I believe that this is still the general ART area discussion list, and so this is the right forum to talk about it. Given the name you chose for the draft, however, please note that APPSAWG is in the process of shutting down and will not be accepting any new documents for processing. -MSK, APPSAWG chair --001a1140f86a61ad82052f14168d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Mar 27, 2016 at 5:32 PM, Cristian F. Perez Monte <= span dir=3D"ltr"><= cdlt23@gmail.com> wrote:
Recent= ly, I submitted a new draft , draft-appsawg-perez-sdcp-00 https://datatracker.ietf.org/doc/draft-appsawg-perez-sdcp/?in= clude_text=3D1

I hope your suggestions and comments.=C2=A0Thank = you very much.

Regards,

Cristian


PS: The draft nam= e should be draft-perez-appsawg-sdcp-00. I will fix this error as soon as p= ossible.

I believe that this is still= the general ART area discussion list, and so this is the right forum to ta= lk about it.=C2=A0 Given the name you chose for the draft, however, please = note that APPSAWG is in the process of shutting down and will not be accept= ing any new documents for processing.

-MSK, APPSAWG chair=
--001a1140f86a61ad82052f14168d-- From nobody Mon Mar 28 18:36:28 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13B312D0FC for ; Mon, 28 Mar 2016 18:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4f_SA42vort for ; Mon, 28 Mar 2016 18:36:25 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5480E12D1A4 for ; Mon, 28 Mar 2016 18:36:25 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id e6so1870000vkh.2 for ; Mon, 28 Mar 2016 18:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=dJHMQN779FMkY/k/1gXznXiNrE8W9IQ01KRQL6s/hFs=; b=XZ77OmtEcCHTCMZ7PSR4d3xXqVlfDoXK3gcLP13DooPGeXwO1IP/TU7v3AXKSS4hoJ Pt5UQnSqNlFTPF06fPHmKqydVATKfbbeteljwn2nekljo773x2FD197eA11f2/7yiIgp EuCxUAC2LpTC1KSuJrlHtMrP2oWuMPSTTIYOc55MCSFtGH65G6h/dFer974wwihMDAQE m//nClmpacez4iXRV5PJTQ0sTlg3Mnep6sL02lBOupz/CJCfTtuInxuAZQpwIcgH9a0r tuAjK7QNelzZJ6CHTn3hPGdrN7hFFTpykQ5CSGT0MGJ++fZNmxw2D7E+TVCswOAgTgBu qokQ== 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; bh=dJHMQN779FMkY/k/1gXznXiNrE8W9IQ01KRQL6s/hFs=; b=LClCu7Y/EJEWcmiPp0rrmFF48fNfXYUY0ia0Z7hRobeLzKybg86vGKua6WZmXcyUbO W/CQgubhx+6o9Kb2poSqXh36rxu6yZqnFpQqpaoDAKcEkQ6EkCqCbL7iWf7YuziLKYHu U1COIXzVXCEpdJJlhkU0JVyf8BcBg24T5sS7SJ+Qjzz6CVoYFgucJWEG/noAhR5RP0nm aWoJ1i6BO+TgeOGvNrDWXaxKiFG0cP0bMHg5ejoIX0WmOUaL88FJNY6gezrJnFTBWOzU Ib90UMqoWzeW6zUFHvINyQ/g5+ZQjE7tUzJpi0xFWke569cCDZp6+4n4IBwrLlt6Gzd2 UiNA== X-Gm-Message-State: AD7BkJKH7p2UWHAlPzF83lJVbaZlKJRHlCr414Rur9QTPvIDHn/+3gtGn3c1ilc1Zfdm2x7Pjhox/ZT1ovOMgw== MIME-Version: 1.0 X-Received: by 10.159.40.170 with SMTP id d39mr14982259uad.89.1459215384392; Mon, 28 Mar 2016 18:36:24 -0700 (PDT) Received: by 10.31.45.71 with HTTP; Mon, 28 Mar 2016 18:36:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Mar 2016 22:36:24 -0300 Message-ID: From: "Cristian F. Perez Monte" To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=94eb2c123e20a33b8b052f260ebe Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] new draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 01:36:27 -0000 --94eb2c123e20a33b8b052f260ebe Content-Type: text/plain; charset=UTF-8 On Mon, Mar 28, 2016 at 1:10 AM, Murray S. Kucherawy wrote: > On Sun, Mar 27, 2016 at 5:32 PM, Cristian F. Perez Monte > wrote: > >> Recently, I submitted a new draft , draft-appsawg-perez-sdcp-00 >> https://datatracker.ietf.org/doc/draft-appsawg-perez-sdcp/?include_text=1 >> >> I hope your suggestions and comments. Thank you very much. >> >> Regards, >> >> Cristian >> >> >> PS: The draft name should be draft-perez-appsawg-sdcp-00. I will fix this >> error as soon as possible. >> > > I believe that this is still the general ART area discussion list, and so > this is the right forum to talk about it. Given the name you chose for the > draft, however, please note that APPSAWG is in the process of shutting down > and will not be accepting any new documents for processing. > > -MSK, APPSAWG chair > Thank you very much! --94eb2c123e20a33b8b052f260ebe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 28, 2016 at 1:10 AM, Murray S. Kucherawy = <superuser@gmai= l.com> wrote:
On Sun, Mar 27, 2016 at 5:32 PM, Cristian F. Perez Mon= te <cdlt23@gmail.com> wrote:
Recently, I submitted a new draft , draft-appsawg-per= ez-sdcp-00 https://datatracker.ietf.org/doc/= draft-appsawg-perez-sdcp/?include_text=3D1

I hope your suggestio= ns and comments.=C2=A0Thank you very much.

Regards,

Cristian<= br>

PS: The draft name should be draft-perez-appsawg-sdcp-00. I will= fix this error as soon as possible.

I believe that this is still the general ART area discussion list, a= nd so this is the right forum to talk about it.=C2=A0 Given the name you ch= ose for the draft, however, please note that APPSAWG is in the process of s= hutting down and will not be accepting any new documents for processing.
-MSK, APPSAWG chair


Thank you very much!


--94eb2c123e20a33b8b052f260ebe-- From nobody Thu Mar 31 17:28:10 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C28012D915; Thu, 31 Mar 2016 17:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 E61Xp4Waribj; Thu, 31 Mar 2016 17:28:07 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AAE712D889; Thu, 31 Mar 2016 17:28:07 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E31D2180094; Thu, 31 Mar 2016 17:27:31 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160401002731.E31D2180094@rfc-editor.org> Date: Thu, 31 Mar 2016 17:27:31 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] RFC 7807 on Problem Details for HTTP APIs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 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, 01 Apr 2016 00:28:09 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7807 Title: Problem Details for HTTP APIs Author: M. Nottingham, E. Wilde Status: Standards Track Stream: IETF Date: March 2016 Mailbox: mnot@mnot.net, erik.wilde@dret.net Pages: 16 Characters: 31210 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-appsawg-http-problem-03.txt URL: https://www.rfc-editor.org/info/rfc7807 DOI: http://dx.doi.org/10.17487/RFC7807 This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs. This document is a product of the ART Area General Application 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/retrieve/bulk 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