From nobody Wed Jul 1 23:34:50 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FCD1B2CA5; Tue, 30 Jun 2015 12:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cc-gBDYNzVwe; Tue, 30 Jun 2015 12:59:16 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 CC0AE1B2CA2; Tue, 30 Jun 2015 12:59:15 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id A75FFFC6F2B8D; Tue, 30 Jun 2015 19:59:10 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t5UJxDbN023616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jun 2015 21:59:14 +0200 Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.246]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 30 Jun 2015 21:59:14 +0200 From: "Murray, Rob (Rob)" To: Carsten Bormann , "cdni@ietf.org" Thread-Topic: Appsdir review for draft-ietf-cdni-control-triggers-06 Thread-Index: AQHQs288+0Se9Q7wqEGDOy/Ug2IyeA== Date: Tue, 30 Jun 2015 19:59:13 +0000 Message-ID: References: <5523143E.3070503@tzi.org> In-Reply-To: <5523143E.3070503@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 01 Jul 2015 23:34:49 -0700 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Appsdir review for draft-ietf-cdni-control-triggers-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 19:59:18 -0000 Hi all, Thank you for your comments Carsten, I've published a -07 to address them as described below. As agreed in the Dallas meeting - I've also aligned the section about use of TLS with the latest logging draft, and added some words about privacy. Cheers, Rob. On 07/04/2015 00:18, "Carsten Bormann" wrote: >I have been selected as an Applications Area Directorate reviewer for >this draft (for background on appsdir, please see >http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate >), with a specific view on the JSON usage in this specification. > >Please resolve these comments along with any other comments you may >receive. Please wait for direction from your document shepherd or AD >before posting a new version of the draft. (Feel free to forward >these comments to the WG list if that helps in resolving the comments.) > >Document: draft-ietf-cdni-control-triggers-06 >Title: CDNI Control Interface / Triggers >Reviewer: Carsten Bormann >Review Date: 2015-04-06 > >* Summary: This draft is ready for publication as a standards track RFC, >after a few misphrasings and minor details in the usage of HTTP have >been corrected. > >* Major issues: None. > >* Minor issues: > >The protocol is REST-based in that it creates dCDN activities using a >POST-based interface, which then can be examined using GET on the >location returned (making good use of HTTP, e.g., for caching) and be >DELETEd for canceling them. It is not making use of the fact that the >subject of these activities are REST resources themselves. This >paragraph just takes note of this fact, without necessarily suggesting >a need (or even usefulness) for a change. >Is "authenticate" the right word in the 2nd para of 4.1? >(How do you authenticate a CI/T command? There is no authentication >information provided.) Good point, dropped "and authenticates". >For the benefit of the implementer, the last paragraph of section 4.1 >could say what is "an appropriate HTTP status code" here -- 405 Method >not allowed? Added. >4.2.1 could give a little additional guidance on how to use the ETag >for the collection (possibly pointing to the examples). Changed from: "When polling in this way, the uCDN SHOULD use HTTP Entity Tags to monitor for change, rather than repeatedly fetching the whole collection." to: "When polling in this way, the uCDN SHOULD use HTTP Entity Tags to monitor for change, rather than repeatedly fetching the whole collection. An example of this is given in section 6.2.4." >4.3 uses 403 forbidden to indicate that a feature is not implemented? Changed to "501 Not Implemented" ? >4.6 the phrasing "into the cdn-path key" used here is misleading: The >intent is to have one array element appended to the end of the array >under the entry named "cdn-path". Changed to ... In every CI/T Command it originates or cascades, each CDN MUST append an array element containing its CDN Provider ID to a JSON array under an entry named "cdn-path". >4.7 uses 401 for no permission, while section 8.1 correctly proposes >403 Forbidden (or 404 Not Found) for this case. Changed to "403 or 404". >5.1.2 uses the phrasing "list of" Error Descriptions, apparently with >the intention that this be an array of Error Descriptions. Prefer >making this explicit. Are empty lists allowed? (The whole entry is >non-mandatory.) Changed to ... An array of Error Description, as defined in . An empty array is allowed, and equivalent to omitting "errors" from the object. >(More generally, the spec could be explicit where empty arrays are >allowed and where not.) Made the following explicitly not allowed to be empty ... 5.5.1 "cancel", "cdn-path" And this one explicitly allowed to be empty ... 5.1.3 "triggers" >5.1.3: Is staleresourcetime allowed to be negative? zero? >(Note also that Absolute Time is a general JSON number, which includes >floating point, while this is an integer?) Changed to "A JSON number, which must be a positive integer, representing time in seconds.". >5.2.6 fails to say that Error Descriptions are JSON objects. Added "It is encoded as a JSON object with the following name/value pairs:". >Why is the third request in 6.2.4 not using an ETag, contrary to >its own recommendation? Oops, it is now. (And the fourth request.) >* Gratuitous formalization of the JSON data: > >(I have validated the examples against this formalization, using the >CDDL tool.) Oooh - nice, thank you! I've added it to the doc. >CIT-object =3D CIT-command / Trigger-Status-Resource / Trigger-Collection > >CIT-command ; use media type application/cdni.ci.TriggerCommand+json >=3D { > ? trigger: Triggerspec > ? cancel: [* URI] > cdn-path: [* Cdn-PID] >} > >Trigger-Status-Resource ; application/cdni.ci.TriggerStatus+json. >=3D { > trigger: Triggerspec > ctime: Absolute-Time > mtime: Absolute-Time > ? etime: Absolute-Time > status: Trigger-Status > ? errors: [* Error-Description] >} > >Trigger-Collection ; application/cdni.ci.TriggerCollection+json >=3D { > triggers: [* URI] > ? staleresourcetime: int ; time in seconds > ? coll-all: URI > ? coll-pending: URI > ? coll-active: URI > ? coll-complete: URI > ? coll-failed: URI > ? cdn-id: Cdn-PID >} > >Triggerspec =3D { ; 5.2.1 > type: Trigger-Type > ? metadata.urls: [* URI] > ? content.urls: [* URI] > ? content.ccid: [* Ccid] > ? metadata.patterns: [* Pattern-Match] > ? content.patterns: [* Pattern-Match] >} > >Trigger-Type =3D "preposition" / "invalidate" / "purge" ; 5.2.2 > >Trigger-Status =3D "pending" / "active" / "complete" / "processed" > / "failed" / "cancelling" / "cancelled" ; 5.2.3 > >Pattern-Match =3D { ; 5.2.4 > pattern: tstr > ? case-sensitive: bool > ? match-query-string: bool >} > >Absolute-Time =3D number ; seconds since UNIX epoch, 5.2.5 > >Error-Description =3D { ; 5.2.6 > error: Error-Code > ? metadata.urls: [* URI] > ? content.urls: [* URI] > ? metadata.patterns: [* Pattern-Match] > ? content.patterns: [* Pattern-Match] > ? description: tstr >} > >Error-Code =3D "emeta" / "econtent" / "eperm" / "ereject" > / "ecdn" / "ecancelled" ; 5.2.7 > >Ccid =3D tstr ; see I-D.ietf-cdni-metadata > >Cdn-PID =3D tstr .regexp "AS[0-9]+:[0-9]+" > >URI =3D tstr > From nobody Fri Jul 3 21:52:52 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5EF11A0404 for ; Fri, 3 Jul 2015 21:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 RHQr81LoWvdu for ; Fri, 3 Jul 2015 21:52: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 5F4751A039F for ; Fri, 3 Jul 2015 21:52:49 -0700 (PDT) Received: (qmail 32921 invoked from network); 4 Jul 2015 04:53:01 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 4 Jul 2015 04:53:01 -0000 Date: 4 Jul 2015 04:52:23 -0000 Message-ID: <20150704045223.1995.qmail@ary.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: Subject: [apps-discuss] EAI, SPF, DKIM, and DMARC X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jul 2015 04:52:51 -0000 Gosh, I love acronyms. I wrote a short draft describing how internationalized mail (EAI) interacts with SPF, DKIM, and DMARC. Nothing in it should be surprising. It just clarifies where you need U-labels vs. A-labels, and makes what I think is an obvious change to the DKIM-Signature header to allow U-labels (UTF-8 domain names) in the d= and i= fields when the message is EAI so it's got UTF-8 everywhere else. It also fixes some minor bugs in the DMARC spec that confuse U-labels with full domain names. https://datatracker.ietf.org/doc/draft-levine-appsarea-eaiauth/ If people find this of interest, I'd like to do it through appsarea. SPF and DKIM are standards track, DMARC currently is not, so I tried to finesse it. R's, John From nobody Sat Jul 4 00:10:18 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C091A88D2 for ; Sat, 4 Jul 2015 00:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoNC-YHQ5xLq for ; Sat, 4 Jul 2015 00:10:16 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD4D1A88D0 for ; Sat, 4 Jul 2015 00:10:16 -0700 (PDT) Received: from [192.168.1.46] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id A9E051FEAB; Sat, 4 Jul 2015 09:10:14 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "John Levine" Date: Sat, 04 Jul 2015 09:10:13 +0200 Message-ID: <304A9683-83D9-4058-A45F-073D666668D7@frobbit.se> In-Reply-To: <20150704045223.1995.qmail@ary.lan> References: <20150704045223.1995.qmail@ary.lan> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_B86AFB78-4B8E-4899-9B71-7303B6D49D70_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.1r5102) Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] EAI, SPF, DKIM, and DMARC X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jul 2015 07:10:17 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_B86AFB78-4B8E-4899-9B71-7303B6D49D70_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 4 Jul 2015, at 6:52, John Levine wrote: > Gosh, I love acronyms. I wrote a short draft describing how > internationalized mail (EAI) interacts with SPF, DKIM, and DMARC. > > Nothing in it should be surprising. It just clarifies where you need > U-labels vs. A-labels, and makes what I think is an obvious change to > the DKIM-Signature header to allow U-labels (UTF-8 domain names) in > the d=3D and i=3D fields when the message is EAI so it's got UTF-8 > everywhere else. It also fixes some minor bugs in the DMARC spec that > confuse U-labels with full domain names. > > https://datatracker.ietf.org/doc/draft-levine-appsarea-eaiauth/ > > If people find this of interest, I'd like to do it through appsarea. > SPF and DKIM are standards track, DMARC currently is not, so I tried > to finesse it. I like this. But, I see a number of "MUST", "must" and "That section is updated to say= that all U-labels in the domain are converted to A-labels before further= processing." etc. These things I think should be made clear in future ve= rsions exactly so that one know what the original text say. Maybe you hav= e quoted correctly and the unclarity exists in the source document? Maybe= you did in this first version "just wrote text" (like I do :-) ). So please continue with this! Patrik --=_MailMate_B86AFB78-4B8E-4899-9B71-7303B6D49D70_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlWXhtUACgkQrMabGguI18231ACfVuBa/6q6gCWfSwpKbnZLhDzP toIAnjg/tK7y1YAheY2hd5KBoWfv+GX1 =+1bm -----END PGP SIGNATURE----- --=_MailMate_B86AFB78-4B8E-4899-9B71-7303B6D49D70_=-- From nobody Sat Jul 4 01:40:13 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C5C1A9118 for ; Sat, 4 Jul 2015 01:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 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, 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 umCnac5_bLeV for ; Sat, 4 Jul 2015 01:40:11 -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 3337A1A9117 for ; Sat, 4 Jul 2015 01:40:11 -0700 (PDT) Received: (qmail 62924 invoked from network); 4 Jul 2015 08:40:24 -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=f5cb.55979bf8.k1507; bh=/HxAVT03I/K3/kJXf3FQ73SSeY529fu0acf9XkslOBI=; b=Jy2C1/l98zxu5cCThvbNs3EkQLjl99Nkv/DoR8rCpYtUZw2ufvVMh4Z6SizaUXbg/hMtDzHIZ5ShxyBR9bzxTwWIzOPKbxrfjsxqeNWvYvSELxWG0/8mVee6Wj02ZhfjKOor+KEji4mDZRmBSzpID8KnCgs0keg7bQr3U4nS3BQfebFTSyrka9IOZXBpwcUApUN5DA/Q0z/W2r6OWKXXcfJMYdGQ/2ePLjzL86eAQu3eZNiQYw7oMoAD0H97w8R5 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=f5cb.55979bf8.k1507; bh=/HxAVT03I/K3/kJXf3FQ73SSeY529fu0acf9XkslOBI=; b=IN/lxRSCXnnVkG3lscJ6UQYUXP6V6c/R38uJ5mXvqcWG9FdJz+uC883Tje8IURdD+M1Yr8VSmJnQiK50hVo8wEVH0srb/RXU+/uNccyGkob8ncObGdozzmwPeayLx9LNhXb6m/LBFRZHVcFPVysCrNBNgamZgnnHJCyl3ZKHW0UL0pqcOKjiI0FQb3a6C84lN18jqaqrIzoWyj5johel0iYqAfLNw7IeM7SLXe8mHkIdcvL/bM4bGPuNJ/Kdq69F 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; 04 Jul 2015 08:40:23 -0000 Date: 4 Jul 2015 20:40:07 +1200 Message-ID: From: "John R Levine" To: "=?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?=" In-Reply-To: <304A9683-83D9-4058-A45F-073D666668D7@frobbit.se> References: <20150704045223.1995.qmail@ary.lan> <304A9683-83D9-4058-A45F-073D666668D7@frobbit.se> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] EAI, SPF, DKIM, and DMARC X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jul 2015 08:40:12 -0000 > But, I see a number of "MUST", "must" and "That section is updated to say that all U-labels in the domain are converted to A-labels before further processing." etc. These things I think should be made clear in future versions exactly so that one know what the original text say. Maybe you have quoted correctly and the unclarity exists in the source document? Maybe you did in this first version "just wrote text" (like I do :-) ). As you surmised, I just wrote text. If people want to go ahead with this, I don't think that it will be a big problem to fix the requirements language. Keep in mind that DMARC is not standards track so as I understand it, 2119 doesn't apply. That's why the DMARC bits are phrased as advice, not requirements. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sat Jul 4 02:05:34 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D46F1ABD3F for ; Sat, 4 Jul 2015 02:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2gn7-2zoLtW for ; Sat, 4 Jul 2015 02:05:32 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [217.34.220.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9E21A8AEF for ; Sat, 4 Jul 2015 02:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1436000731; d=isode.com; s=selector; i=@isode.com; bh=TFtCYF4cSG1lx0ALnmoCb3cPWy3VL+pQrwzNBFT8XUU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=sIiWBsGaYlWORk3ZInYeJlIW1ZsLm9Nr8jZ1h4fkzARHjTuSidMQY6DHa89DLMbsWkZ9B4 v8iQ6l7HBWmkjWaiL/nfQnP4xkFy1lxrP/9SVADAKoNtJSUmZ5ea6bQQfFglJOu+G2wKuh S+AAELFrJHnCd2g7QRXf1JeTjg13sN8=; Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 4 Jul 2015 10:05:31 +0100 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (12F69) In-Reply-To: Date: Sat, 4 Jul 2015 10:07:47 +0100 Message-Id: References: <20150704045223.1995.qmail@ary.lan> <304A9683-83D9-4058-A45F-073D666668D7@frobbit.se> To: John R Levine MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] EAI, SPF, DKIM, and DMARC X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jul 2015 09:05:33 -0000 John, > On 4 Jul 2015, at 09:40, John R Levine wrote: >=20 > Keep in mind that DMARC is not standards track so as I understand it, 2119= doesn't apply. =20 It is perfectly Ok to use 2119 language for non Standards Track documents. > That's why the DMARC bits are phrased as advice, not requirements. From nobody Sat Jul 4 14:15:23 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618421A00B8; Sat, 4 Jul 2015 14:15:20 -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 IbEc6Gtg_ngP; Sat, 4 Jul 2015 14:15:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5684C1A1A10; Sat, 4 Jul 2015 14:15:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150704211518.18429.58496.idtracker@ietfa.amsl.com> Date: Sat, 04 Jul 2015 14:15:18 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-mdn-3798bis-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: Sat, 04 Jul 2015 21:15:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ART Area General Applications Working Group Working Group of the IETF. Title : Message Disposition Notification Authors : Tony Hansen Alexey Melnikov Filename : draft-ietf-appsawg-mdn-3798bis-03.txt Pages : 32 Date : 2015-07-04 Abstract: This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-mdn-3798bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-mdn-3798bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-mdn-3798bis-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 Sun Jul 5 09:07:24 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916141AC41C for ; Sun, 5 Jul 2015 09:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.3 X-Spam-Level: *** X-Spam-Status: No, score=3.3 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] 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 XrdfT9okaFTz for ; Sun, 5 Jul 2015 09:07:20 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923C21AC411 for ; Sun, 5 Jul 2015 09:07:20 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=P5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZBmRo-000NUy-Md; Sun, 05 Jul 2015 12:07:16 -0400 Date: Sun, 05 Jul 2015 12:07:11 -0400 From: John C Klensin To: John R Levine , =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Message-ID: <352CA55F92A56FDC275D4A28@P5> In-Reply-To: References: <20150704045223.1995.qmail@ary.lan> <304A9683-83D9-4058-A45F-073D666668D7@frobbit.se> 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 Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] EAI, SPF, DKIM, and DMARC X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jul 2015 16:07:23 -0000 --On Saturday, 04 July, 2015 20:40 +1200 John R Levine wrote: >> But, I see a number of "MUST", "must" and "That section is >> updated to say that all U-labels in the domain are converted >> to A-labels before further processing." etc. These things I >> think should be made clear in future versions exactly so that >> one know what the original text say. Maybe you have quoted >> correctly and the unclarity exists in the source document? >> Maybe you did in this first version "just wrote text" (like I >> do :-) ). > > As you surmised, I just wrote text. If people want to go > ahead with this, I don't think that it will be a big problem > to fix the requirements language. I don't either although some of those assertions are going to need careful checking with, and probably references to, the source documents. To take the first example I ran across, Section 2 includes a sentence that says "Since the EHLO command precedes the server response that identifies the SMTPUTF8 extension, an IDN domain name argument SHOULD be represented as an A-label." That MUST (sic) is a MUST; see Section 3.7.1 of RFC 6531. The draft uncovers two more serious problems: (1) The SMTPUTF8 ("EAI") specs are very clear in prohibiting encoding of local-parts or, more specifically, making any assumptions about anything that might resemble an encoding. So, unless whatever processes are involved with SPF, DKIM, and/or DMARC are fully UTF-8-capable (with all the disclaimers that go with that statement), there are certain to be problems. In particular, part of Section 5 says "Since a policy record can be used for both internationalized and conventional mail, those addresses have to be conventional addresses, not internationalized addresses" Because there is no "conventional" form of an address with a non-ASCII local part, that requirement appears to be equivalent to a prohibition on such addresses in the rua or ruf tags of DMARC policy records. (2) For a number of reasons, some associated with the "late conversion" advice of RFC 6055, the EAI WG was quite clear that addresses, as well as local-parts, be kept in native character form except when actually converted to/ treated as domain names to be looked up in the public DNS. Some of the advice in this document (presumably taken directly from the SPF, DKIM, and/or DMARC specifications themselves, seems counter to that principle. I think the draft performs the service of exposing more broadly something that the EAI WG was aware of and discussed: that SPF and DKIM were defined without real consideration of many i18n issues. From the above, the DMARC design may have given them even less consideration. It appears to me that some of these issues, especially those that involve handling of local parts or that might apply to mail being transmitted within an administrative domain [1], may require rethinking and updating the base SPF and DKIM Proposed Standard specifications and may be important input to the effort to standards DMARC. I am not convinced that APPSAWG has sufficient focus, much less an adequate concentration of i18n expertise, to do that job well. john [1] Administrative domains for email purposes need not have anything to do with either DNS zones or even DNS administrative hierarchy. From nobody Sun Jul 5 11:53:29 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9ECD1A009F; Sun, 5 Jul 2015 11:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 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, 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 2kqAboaHe0af; Sun, 5 Jul 2015 11:53:25 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450: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 7A8D51A0040; Sun, 5 Jul 2015 11:53:24 -0700 (PDT) Received: by wiwl6 with SMTP id l6so266673077wiw.0; Sun, 05 Jul 2015 11:53: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:cc:content-type; bh=FZ200kMJRZzi0tzhsmnDHAvE8n4HQtJ5CPAFQEaigkA=; b=AAcTYrbMCUifBATbT4CYQnSYCOS+oFcnVY3t3o/QV6yqy2KlSsULyMkuaBP2wi+lgs QkCu+esS+rNWuYv9PIZ/XNnMu3JxNNeZFJeALyFA6RgnLE3UoX8TwFB1p+7cf3r9SQg4 EvwQdtpGsQMs6asX2/0T4MM1JhwNJmPybSuyI9+97WBUtKc0AXVU8Be8Udh2jVcFlqya nvisWcLfZBa4EBrNPEIqxiRkfr2vDnz2ZMfjWaK2fGHP48x2syF5xJhcixfIjOKG7UAh efAL9WcTKXZ9jRQPF5z7cP2etmDi+djN26BkcXfUxgh8z8vF8G6FxACTFoEK2XSAcuip bTng== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=FZ200kMJRZzi0tzhsmnDHAvE8n4HQtJ5CPAFQEaigkA=; b=ERQHmp2OaxJbf9dKqHUSxjItcLWxQ6R0ypXIOAyivwSPqsIRA8pPrrBBY8SSZ9yPsq 6mnHsluWc3XFunIRBC/Fe5a2mokqJcN2Vne4ZH3vx2AleZRFoI01Zll5R1dguQFEGrMe PY5YwmDIOCUioCRGJQrdilyExtQo+J1Z3gaqg= MIME-Version: 1.0 X-Received: by 10.180.106.195 with SMTP id gw3mr47173851wib.25.1436122403234; Sun, 05 Jul 2015 11:53:23 -0700 (PDT) Sender: mglt.ietf@gmail.com Received: by 10.194.11.6 with HTTP; Sun, 5 Jul 2015 11:53:23 -0700 (PDT) In-Reply-To: <20150629160732.4169.50123.idtracker@ietfa.amsl.com> References: <20150629160732.4169.50123.idtracker@ietfa.amsl.com> Date: Sun, 5 Jul 2015 14:53:23 -0400 X-Google-Sender-Auth: cZ5OWiA6pGy_Y23By1Q0gjVPLdk Message-ID: From: Daniel Migault To: ietf-http-wg@w3.org, apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=e89a8f3bab71b2e6fa051a254d06 Archived-At: Cc: Time Zone Data Distribution Service , "tzdist-chairs@tools.ietf.org" Subject: [apps-discuss] Fwd: [Tzdist] I-D Action: draft-ietf-tzdist-service-09.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: Sun, 05 Jul 2015 18:53:26 -0000 --e89a8f3bab71b2e6fa051a254d06 Content-Type: text/plain; charset=UTF-8 Dear Friends and Colleagues, draft-ietf-tzdist-service-09.txt [1] addresses the comments we received during the last call. The tzdist WG has approved the changes, and we would like to check with you whether you also approve the changes. If you have any comments, please provide them by July 18. The most import changes seems: 3. GENART: ".well-known" MUST be present. 11. Removed list of HTTP response codes from error section. 12. Removed Status column from actions registry. 13. Reworked URN prefix registry. Full list of changes is available in appendix A [2] 1. Added June 30th 2015 leap second data into example. 2. GENART: clarify how "utc-offset" changes as leap seconds are added or removed. 3. GENART: ".well-known" MUST be present. 4. GENART: switch RFC5226 reference to 5226bis. 5. GENART: reference section 10 of 5226bis for appeals process. 6. GENART: change controller: IETF -> IESG. 7. GENART: Section 10.2 add "None" for related information. 8. GENART: Section 4.1.4 editorial. 9. GENART: Section 4.2.1.2 editorial. 10. GENART: Use RFCXXXX in all parts of IANA section. 11. Removed list of HTTP response codes from error section. 12. Removed Status column from actions registry. 13. Reworked URN prefix registry. [1] https://datatracker.ietf.org/doc/draft-ietf-tzdist-service/ [2] https://tools.ietf.org/html/draft-ietf-tzdist-service-09#appendix-A Best Regards, Daniel and Eliot ---------- Forwarded message ---------- From: Date: Mon, Jun 29, 2015 at 12:07 PM Subject: [Tzdist] I-D Action: draft-ietf-tzdist-service-09.txt To: i-d-announce@ietf.org Cc: tzdist@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Time Zone Data Distribution Service Working Group of the IETF. Title : Time Zone Data Distribution Service Authors : Michael Douglass Cyrus Daboo Filename : draft-ietf-tzdist-service-09.txt Pages : 62 Date : 2015-06-29 Abstract: This document defines a time zone data distribution service that allows reliable, secure and fast delivery of time zone data and leap second rules to client systems such as calendaring and scheduling applications or operating systems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tzdist-service/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tzdist-service-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tzdist-service-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/ _______________________________________________ Tzdist mailing list Tzdist@ietf.org https://www.ietf.org/mailman/listinfo/tzdist --e89a8f3bab71b2e6fa051a254d06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Friends and Colleagues,

draft-ietf-tzdist-ser= vice-09.txt [1] addresses the comments we received during the last call. The tzdist WG= has approved the=20 changes, and we would like to check with you whether you also approve=20 the changes. If you have any comments, please provide them by July 18.=20 The most import changes seems:

3. GENART: ".well-known" = MUST be present.
11. Removed list of HTTP response codes from error section.
12. Removed Status column from actions registry.
13. Reworked URN prefix registry.

Full list of changes is av= ailable in appendix A [2]

1. Added June 30th 2015 leap second= data into example.
2. GENART: clarify how "utc-offset" changes as leap seco= nds are added or removed.
3. GENART: ".well-known" MUST be present.
4. GENART: switch RFC5226 reference to 5226bis.
5. GENART: reference section 10 of 5226= bis for appeals process.
6. GENART: change controller: IETF -> IESG.
7. GENART: Section 10.2 add "Non= e" for related information.
8. GENART: Section 4.1.4 editorial.
9. GENART: Section 4.2.1.2 editori= al.
10. GENART: Use RFCXXXX in all parts of IANA section.
11. Removed list of HTTP response codes from error section.
12. Removed Status column from actions registry.
13. Reworked URN prefix registry.


[1] https://datatracker.ietf.org/doc/draft-ietf-tzdist-service/=
[2] https://tools.i= etf.org/html/draft-ietf-tzdist-service-09#appendix-A

Best Regards,

Daniel and Eliot
<= br>
---------- Forwarded message ---------= -
From: <internet-drafts@ietf.org>
Date: Mon, Jun 29, 2015 at 12:07 PM
Subject: [Tzdist] I-D Action: d= raft-ietf-tzdist-service-09.txt
To: i-d-announce@ietf.org
Cc: tz= dist@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Time Zone Data Distribution Service = Working 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:= Time Zone Data Distribution Service
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich= ael Douglass
=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 Cyrus Daboo
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-tzdist-service-09.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 62
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-06-29

Abstract:
=C2=A0 =C2=A0This document defines a time zone data distribution service th= at
=C2=A0 =C2=A0allows reliable, secure and fast delivery of time zone data an= d leap
=C2=A0 =C2=A0second rules to client systems such as calendaring and schedul= ing
=C2=A0 =C2=A0applications or operating systems.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ie= tf-tzdist-service/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tzdis= t-service-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3D= draft-ietf-tzdist-service-09


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.

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

_______________________________________________
Tzdist mailing list
Tzdist@ietf.org
https://www.ietf.org/mailman/listinfo/tzdist

--e89a8f3bab71b2e6fa051a254d06-- From nobody Sun Jul 5 12:28:05 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E0C1ACE59 for ; Sun, 5 Jul 2015 12:28: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 jsl71WjtjEza for ; Sun, 5 Jul 2015 12:28: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 C62E71ACE58 for ; Sun, 5 Jul 2015 12:28:02 -0700 (PDT) Received: (qmail 6093 invoked from network); 5 Jul 2015 19:28:15 -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=17cb.5599854f.k1507; bh=FvVm/was0JBLZKtKRuuYHSZFNYytKiABSNyLMHioLKQ=; b=GSGjJ3ncZ6PCzquZ+g82MndoYdSVEvpgHk871ScVqdy8rmTSvD8FKhIh0Q0qApK4zvjdhna6wuoBy23oRKPaJZDk1of5OTK4mXKDFkt5JJaSTyOocnODkJGyPHBXovl/IkW87UjpJHizZzz306Cp5FvMSl3n5FWBCIQCrukolFsK9gtnrwJ2D7gXAkFdIw6iJjt1+J1dtlBME3T87LL2cK0Pz46EduZ1R1vm9kqebNh+wxhSPeDWoHYjkVGULE9i 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=17cb.5599854f.k1507; bh=FvVm/was0JBLZKtKRuuYHSZFNYytKiABSNyLMHioLKQ=; b=tyN7rOUm7dBQjUndytqfTFBfGONpppSY1YqmhrDzWB71GuXID27Cpy6u6svX1XwijHt9biLmoH3KGkryD9yNm2RNvMwWTQEwBaUCvmV6JlFODQd9hvbz84vDS4WKZS8g3zlSFf6ftBk6n85w7b1fusn5oLtbuuFpwXsI2pUxft4P+3/D0ZqnyvVdydAe6EX+5WR1waaep2ZafaOzSC9KRPJ99rKTXxe93/K1BawcR7WULTCKhQ9Vg3bWAsRCqIn1 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 Jul 2015 19:28:15 -0000 Date: 6 Jul 2015 07:28:04 +1200 Message-ID: From: "John R Levine" To: "John C Klensin" In-Reply-To: <352CA55F92A56FDC275D4A28@P5> References: <20150704045223.1995.qmail@ary.lan> <304A9683-83D9-4058-A45F-073D666668D7@frobbit.se> <352CA55F92A56FDC275D4A28@P5> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] EAI, SPF, DKIM, and DMARC X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jul 2015 19:28:04 -0000 > name argument SHOULD be represented as an A-label." > That MUST (sic) is a MUST; see Section 3.7.1 of RFC 6531. OK. > Because there is no "conventional" form of an address with a > non-ASCII local part, that requirement appears to be equivalent > to a prohibition on such addresses in the rua or ruf tags of > DMARC policy records. That's how I read it. Given that those addresses are only used to send blobs of XML or ARF from one computer to another, I don't see it as a big deal that the local part has to be ASCII. EAI systems have to support ASCII addresses, or postmaster wouldn't work. > I think the draft performs the service of exposing more broadly > something that the EAI WG was aware of and discussed: that SPF > and DKIM were defined without real consideration of many i18n > issues. From the above, the DMARC design may have given them > even less consideration. No kidding. I don't think it's hard to fix, though. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Mon Jul 6 15:33:05 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17611A87CC; Mon, 6 Jul 2015 15:33:04 -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 grzMf6zpso5D; Mon, 6 Jul 2015 15:33:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB881A802D; Mon, 6 Jul 2015 15:33:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706223302.24689.11506.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 15:33:02 -0700 Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown@ietf.org, draft-ietf-appsawg-text-markdown.ad@ietf.org, n.brownlee@auckland.ac.nz, draft-ietf-appsawg-text-markdown.shepherd@ietf.org Subject: [apps-discuss] Benoit Claise's No Objection on draft-ietf-appsawg-text-markdown-08: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 22:33:04 -0000 Benoit Claise has entered the following ballot position for draft-ietf-appsawg-text-markdown-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. From Nevil's OPS DIR feedback: > 2. The markdown Example (Section 5) is helpful, but it doesn't seem > to have an obvious end marker - it just runs on into section 6. > Does markdown have something like an end-of-file marker you could > use to make that obvious? And answered by Alexey: > > Not really, it is a textual format with no special end marker. > > I suppose the whole example can be surrounded by some markers and a note added that they are not a part of the example? could we use the and ? 2. "A companion document [MDMTUSES] provides additional Markdown background and philosophy." There is more than that. See the draft-ietf-appsawg-text-markdown-use-cases abstract: "Background information, local storage strategies, and additional syntax registrations are supplied" 3. Editorial OLD: [fOo] NEW: [foo] From nobody Mon Jul 6 15:44:00 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3C31A875A; Mon, 6 Jul 2015 15:43: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 ejBYhoOdu4Gh; Mon, 6 Jul 2015 15:43:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C821A885B; Mon, 6 Jul 2015 15:43:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706224353.15970.20875.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 15:43:53 -0700 Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.shepherd@ietf.org, draft-ietf-appsawg-text-markdown-use-cases@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.ad@ietf.org Subject: [apps-discuss] Benoit Claise's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 22:43:57 -0000 Benoit Claise has entered the following ballot position for draft-ietf-appsawg-text-markdown-use-cases-02: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown-use-cases/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Easy to fix DISCUSS: The RFC 2119 boilerplate is missing: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - I was surprised by the RFC2119 keywords in a use cases document (which I first thought of as an applicability document") But, actually, according to the abstract, it's way more than a use cases document: "Background information, local storage strategies, and additional syntax registrations are supplied.", It's really the companion document of draft-ietf-appsawg-text-markdown. Maybe the title is wrong, and should be something such as text/markdown strategies and registrations? " [MDMTREG] (draft-05) only defines two parameters:" I guess there is nothing special about version 5. The latest version is v8 Editorial: - section 1, para 4. That confused me until I saw figure 1 OLD: On the formal end of the spectrum is markup NEW: On the formal end of the formatted text spectrum is markup - There are a couple of [CITE] reference, including this one: Character set interoperability is well-studied territory [NB: CITE?] To be completed I guess. From nobody Mon Jul 6 19:01:17 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FB41A1B98 for ; Mon, 6 Jul 2015 19:01:16 -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 W3hDWxYEHTfR for ; Mon, 6 Jul 2015 19:01:14 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 728211A1AF0 for ; Mon, 6 Jul 2015 19:01:14 -0700 (PDT) Received: by oiab3 with SMTP id b3so13190782oia.1 for ; Mon, 06 Jul 2015 19:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=0In5KG5GQrEpVbgbZsMHhIAhW/TDsrcbyrMJAyoPL+U=; b=gdTBbAD4SNytaLoJmYJYI0mmMdHbPwtk/7ycoEn6APD4TJsN51q3usnG9GOuJE1LCj 2KSg4Ms9wOByc+ybwuvxE9W4D9qYKrtw8MxlOMtcEWSZLvbwKhYgDcWOyNKdwTHeMeFX fPb9AbKax2QNWNqOThas0mL4qq+5DlI0cztNZVoeIxmKKufLIynZC1DplrH8086Yx2W1 0bAzSM2Vw6ApncYq8EdVUzcPV28CNkx93xBGUJw8fKI5tsBOzKPItODxellZlvN6ux9B 1vtPj0tCVV3RckURn2NDIZcL0OX/VhNk9iGSHE0bbRo6fMUBcmbB0NQUX6Rhq++uNeI/ gUFA== X-Received: by 10.182.131.226 with SMTP id op2mr1567678obb.19.1436234473823; Mon, 06 Jul 2015 19:01:13 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id lz12sm11002617oeb.4.2015.07.06.19.01.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2015 19:01:12 -0700 (PDT) To: apps-discuss@ietf.org References: <20150704045223.1995.qmail@ary.lan> <304A9683-83D9-4058-A45F-073D666668D7@frobbit.se> <352CA55F92A56FDC275D4A28@P5> From: Douglas Otis X-Enigmail-Draft-Status: N1110 Message-ID: <559B32E6.9050902@gmail.com> Date: Mon, 6 Jul 2015 19:01:10 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <352CA55F92A56FDC275D4A28@P5> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [apps-discuss] EAI, SPF, DKIM, and DMARC X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jul 2015 02:01:16 -0000 On 7/5/15 9:07 AM, John C Klensin wrote: --On Saturday, 04 July, 2015 20:40 +1200 John R Levine wrote: >>> But, I see a number of "MUST", "must" and "That section is >>> updated to say that all U-labels in the domain are converted >>> to A-labels before further processing." etc. These things I >>> think should be made clear in future versions exactly so that >>> one know what the original text say. Maybe you have quoted >>> correctly and the unclarity exists in the source document? >>> Maybe you did in this first version "just wrote text" (like I >>> do :-) ). >> As you surmised, I just wrote text. If people want to go >> ahead with this, I don't think that it will be a big problem >> to fix the requirements language. > I don't either although some of those assertions are going to > need careful checking with, and probably references to, the > source documents. To take the first example I ran across, > Section 2 includes a sentence that says > "Since the EHLO command precedes the server response > that identifies the SMTPUTF8 extension, an IDN domain > name argument SHOULD be represented as an A-label." > That MUST (sic) is a MUST; see Section 3.7.1 of RFC 6531. > > The draft uncovers two more serious problems: > > (1) The SMTPUTF8 ("EAI") specs are very clear in prohibiting > encoding of local-parts or, more specifically, making any > assumptions about anything that might resemble an encoding. So, > unless whatever processes are involved with SPF, DKIM, and/or > DMARC are fully UTF-8-capable (with all the disclaimers that go > with that statement), there are certain to be problems. In > particular, part of Section 5 says > "Since a policy record can be used for both > internationalized and conventional mail, those addresses > have to be conventional addresses, not internationalized > addresses" > Because there is no "conventional" form of an address with a > non-ASCII local part, that requirement appears to be equivalent > to a prohibition on such addresses in the rua or ruf tags of > DMARC policy records. > > (2) For a number of reasons, some associated with the "late > conversion" advice of RFC 6055, the EAI WG was quite clear that > addresses, as well as local-parts, be kept in native character > form except when actually converted to/ treated as domain names > to be looked up in the public DNS. Some of the advice in this > document (presumably taken directly from the SPF, DKIM, and/or > DMARC specifications themselves, seems counter to that principle. > > > I think the draft performs the service of exposing more broadly > something that the EAI WG was aware of and discussed: that SPF > and DKIM were defined without real consideration of many i18n > issues. From the above, the DMARC design may have given them > even less consideration. It appears to me that some of these > issues, especially those that involve handling of local parts or > that might apply to mail being transmitted within an > administrative domain [1], may require rethinking and updating > the base SPF and DKIM Proposed Standard specifications and may > be important input to the effort to standards DMARC. I am not > convinced that APPSAWG has sufficient focus, much less an > adequate concentration of i18n expertise, to do that job well. > > john > > > > [1] Administrative domains for email purposes need not have > anything to do with either DNS zones or even DNS administrative > hierarchy. Dear John, Your comments are on the mark. When DMARC asserts a restrictive policy it deprecates the role of Sender in a different domain to offer an extremely weak version of S/MIME or OpenPGP, which is otherwise well supported, particularly for mobile users. This scheme will also ossify needed improvements as it lacks a strategy for adopting alternatives or for providing reasonable methods to override needlessly disruptive policies related to third-party services. Regards, Douglas Otis From nobody Mon Jul 6 23:20:59 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024601A90C9 for ; Mon, 6 Jul 2015 23:20: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 OP-qj_of2kCt for ; Mon, 6 Jul 2015 23:20:54 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::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 85CF11A90AE for ; Mon, 6 Jul 2015 23:20:53 -0700 (PDT) Received: by obdbs4 with SMTP id bs4so122236668obd.3 for ; Mon, 06 Jul 2015 23:20:53 -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=GjK8ODJ6ghnKOocymU+Za5rQBoSCwXfLWHIqhrDgSl4=; b=ELQ/mJ/BFaCuVqRnVE6M4YJSTp6lJDDMqXcooZuEZlY2vCQr0B+BEU/sQJzF4b70Yi cQNetOsULEeZ+AEn5AYVlADPUnxA/1hFcXY0m+APbJsFi8WuFxpZQKu/BYFaZepk73bg +yJwuYfbMSR/TUGCW7BSktWkhRiWk2PMqvFZEIXrHGmwKkG8bfhp1n7adgL7v/ofBsft vmZtT+SONPtlRGQdO2TcNNuT8IHvEVrF0rXCCBvHjZlNK/65gFRlAXQBGkdu6KkPtMCb hbAzJYlvbn23QRFCNqmmZ/pplfaYUREPh1rJsx6CRPElp2exQepsqj3l7moM530QKauj TCbg== MIME-Version: 1.0 X-Received: by 10.60.35.98 with SMTP id g2mr692593oej.6.1436250053040; Mon, 06 Jul 2015 23:20:53 -0700 (PDT) Received: by 10.76.73.105 with HTTP; Mon, 6 Jul 2015 23:20:52 -0700 (PDT) In-Reply-To: <20150706062838.8342.96926.idtracker@ietfa.amsl.com> References: <20150706062838.8342.96926.idtracker@ietfa.amsl.com> Date: Tue, 7 Jul 2015 15:20:52 +0900 Message-ID: From: Kaoru Maeda To: Apps Discuss Content-Type: multipart/alternative; boundary=089e01182c103860f6051a430698 Archived-At: Subject: [apps-discuss] Fwd: I-D Action: draft-akagiri-mail-divide-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, 07 Jul 2015 06:20:58 -0000 --089e01182c103860f6051a430698 Content-Type: text/plain; charset=UTF-8 Hello, I submitted the following I-D. https://datatracker.ietf.org/doc/draft-akagiri-mail-divide/ It is about mail delivery. The basic idea is that the receiver prepare a first-class mailbox (or priority mailbox) for a certain category of mail. If you find this interesting, please give me feedbacks. If we have enough interests here, I'd like to have it in appsarea. Thanks and best regards, -- Kaoru Maeda ---------- Forwarded message ---------- From: Date: 2015-07-06 15:28 GMT+09:00 Subject: I-D Action: draft-akagiri-mail-divide-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mail Divide Framework Authors : Takehito Akagiri Kaoru Maeda Kouji Okada Tatsuya Hayashi Masaki Kase Filename : draft-akagiri-mail-divide-00.txt Pages : 19 Date : 2015-07-05 Abstract: Mail Divide Framework (MDF) is a recipient driven partitioning framework for E-Mail delivery. A protocol to divide mail delivery at the source of the message is defined in this draft. A mechanism called Reputation Service Provider is also introduced so that a third-party authority can assure senders' trust. With MDF, subdomaining is used for category-specific MTA designation. Senders decide which category the outgoing mail belongs. It then looks up DNS TXT record to find whether the recipient advertises a specific server for that category. The specified server puts the received mail into a corresponding per-category inbox for the user. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-akagiri-mail-divide/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-akagiri-mail-divide-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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --089e01182c103860f6051a430698 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I submitted the follo= wing I-D.


It is about mail delivery.=C2= =A0 The basic idea is that
the receiver prepare a first-class mai= lbox (or priority mailbox)
for a certain category of mail.
<= div>
If you find this interesting, please give me feedbacks.<= /div>
If we have enough interests here, I'd like to have it in apps= area.

Thanks and best regards,

--=C2=A0
Kaoru Maeda

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: 2015-07-06 15:28 = GMT+09:00
Subject: I-D Action: draft-akagiri-mail-divide-00.txt
To: <= a href=3D"mailto:i-d-announce@ietf.org">i-d-announce@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Mail Divide Framework
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Take= hito Akagiri
=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 Kaoru Maeda
=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 Kouji Okada
=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 Tatsuya Hayashi
=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 Masaki Kase
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-aka= giri-mail-divide-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 19
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-07-05

Abstract:
=C2=A0 =C2=A0Mail Divide Framework (MDF) is a recipient driven partitioning=
=C2=A0 =C2=A0framework for E-Mail delivery.=C2=A0 A protocol to divide mail= delivery at
=C2=A0 =C2=A0the source of the message is defined in this draft.=C2=A0 A me= chanism
=C2=A0 =C2=A0called Reputation Service Provider is also introduced so that = a
=C2=A0 =C2=A0third-party authority can assure senders' trust.=C2=A0 Wit= h MDF,
=C2=A0 =C2=A0subdomaining is used for category-specific MTA designation.=C2= =A0 Senders
=C2=A0 =C2=A0decide which category the outgoing mail belongs.=C2=A0 It then= looks up
=C2=A0 =C2=A0DNS TXT record to find whether the recipient advertises a spec= ific
=C2=A0 =C2=A0server for that category.=C2=A0 The specified server puts the = received
=C2=A0 =C2=A0mail into a corresponding per-category inbox for the user.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ak= agiri-mail-divide/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-akagiri-ma= il-divide-00


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.

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/m= ailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--089e01182c103860f6051a430698-- From nobody Tue Jul 7 01:49:22 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884871A6FCF for ; Tue, 7 Jul 2015 01:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LufjlvCc4V8g for ; Tue, 7 Jul 2015 01:49:19 -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 AD5BF1A6FBC for ; Tue, 7 Jul 2015 01:49:19 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZCOZ4-000JsU-Oo; Tue, 07 Jul 2015 04:49:18 -0400 Date: Tue, 07 Jul 2015 04:49:13 -0400 From: John C Klensin To: Douglas Otis , apps-discuss@ietf.org Message-ID: In-Reply-To: <559B32E6.9050902@gmail.com> References: <20150704045223.1995.qmail@ary.lan> <304A9683-83D9-4058-A45F-073D666668D7@frobbit.se> <352CA55F92A56FDC275D4A28@P5> <559B32E6.9050902@gmail.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: Subject: Re: [apps-discuss] EAI, SPF, DKIM, and DMARC X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jul 2015 08:49:21 -0000 --On Monday, July 06, 2015 19:01 -0700 Douglas Otis wrote: > Your comments are on the mark. When DMARC asserts a > restrictive policy it deprecates the role of Sender in a > different domain to offer an extremely weak version of > S/MIME or OpenPGP, which is otherwise well supported, > particularly for mobile users. This scheme will also ossify > needed improvements as it lacks a strategy for adopting > alternatives or for providing reasonable methods to override > needlessly disruptive policies related to third-party services. Doug, That is my impression. It is also my impression that DMARC's origins with, apparently, a small number of organizations with a narrow set of perceived needs and correspondingly small number of use cases, leading to the damage that we saw when it was first deployed. I hope the WG can solve most or all of those problems and that, if it cannot, that the IETF declines to standardize it, leaving at least a small door open for other options. The best may be the enemy of the good but when the effect of the good (or non-so-good) is to block the emergence of the best or even the better, the tradeoffs become more complicated than the slogan. On the other hand, I'm unsure about your comparison to PGP and S/MIME. While I personally prefer them, I've gotten very pessimistic over the years about the ability of ordinary users to maintain private keys in a secure way, I believe that models based on trusted third parties holding private keys are close to a contradiction, and that, however bad our experience with CA operators have been, depending on DNS registrars may be worse. So I'm not quite sure where we go from here. Simply denouncing DMARC or suggesting entirely different models for email are, fairly clearly, not going to be helpful. best, john From nobody Tue Jul 7 08:51:01 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5AD1ACE05 for ; Tue, 7 Jul 2015 08:50:59 -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, 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 Z-b4M_jyQABK for ; Tue, 7 Jul 2015 08:50:54 -0700 (PDT) Received: from smtp118.ord1c.emailsrvr.com (smtp118.ord1c.emailsrvr.com [108.166.43.118]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E241C1ACDD8 for ; Tue, 7 Jul 2015 08:50:07 -0700 (PDT) Received: from smtp15.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp15.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 63F5438023E for ; Tue, 7 Jul 2015 11:50:07 -0400 (EDT) Received: by smtp15.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id B4E8E3801A5 for ; Tue, 7 Jul 2015 11:50:06 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Tue, 07 Jul 2015 15:50:07 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4CEB3586-7C4C-47AE-ADFD-F579C81302E2@iii.ca> Date: Tue, 7 Jul 2015 09:50:06 -0600 To: apps-discuss@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [apps-discuss] Agenda time for draft-jennings-behave-rtcweb-firewall-00 ? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jul 2015 15:50:59 -0000 draft-jennings-behave-rtcweb-firewall-00 discussed how firewalls might = handle WebRTC traffic One particular part of it , Section 6 - see = https://tools.ietf.org/html/draft-jennings-behave-rtcweb-firewall-00#secti= on-6 is likely to have some impact on other apps protocols other than WebRTC = and I'd like to discuss that in the general apps area meeting. Would it be possible for me to get a short amount of agenda time to = discuss this.=20 Thanks, Cullen From nobody Tue Jul 7 15:48:21 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736221B2A13 for ; Tue, 7 Jul 2015 15:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ti1VhJpTEYv9 for ; Tue, 7 Jul 2015 15:48:17 -0700 (PDT) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72FDE1B2A0A for ; Tue, 7 Jul 2015 15:48:17 -0700 (PDT) Received: from 108-67-65-66.lightspeed.sntcca.sbcglobal.net ([108.67.65.66] helo=[192.168.1.76]) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1ZCbey-0003Dl-40; Tue, 07 Jul 2015 15:48:17 -0700 Message-ID: <559C5727.7020700@berkeley.edu> Date: Tue, 07 Jul 2015 15:48:07 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Melvin Carvalho References: <558ABA64.8050604@andrew.cmu.edu> <558ADE8E.1060407@berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Apps Discuss Subject: Re: [apps-discuss] returning something from http 402 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 22:48:19 -0000 hello melvin. On 2015-06-26 14:01 , Melvin Carvalho wrote: > On 24 June 2015 at 18:45, Erik Wilde > wrote: > On 24 June 2015 at 16:10, Ken Murchison > >> wrote: > Perhaps leverage > https://tools.ietf.org/html/draft-ietf-appsawg-http-problem-00 > It's great that RDFa is mentioned in the doc. I suspect the > serializations I would be working with would be JSON-LD and Turtle. > currently, the canonical model is defined in JSON. appendix a talks > about how to represent that model in XML. appendix b talks about > "other metamodels" and mentions RDF in passing, simply as one > example of those other metamodels. it would be possible to add more > details about how to use the canonical model in RDF-land, so that > there would be no doubt *how* to represent the canonical model in > RDF. if there's any interest, that's something that could be done in > an additional appendix, and talking about how that would look in > JSON-LD as one RDF representation then also would be pretty > straightforward. > > The document you made seems a good fit, do you have thoughts on: > 1. The RFC is 4xx and I'd like to do something 402 specific i'd say that media types and status codes are orthogonal. sure you can design something that's specific for a use case (such as payment info), but imho it would be strange to define media types in any way that ties them to specific status codes. > 2. Thoughts on redirecting to a machine readable representation vs > returning a machine readable representtion that's independent from the representation you want to return, right? redirect if that's what you want to do (i.e., telling clients about a different URI than the one they were requesting), or return something if the URI is the one clients should be using. in the general draft-ietf-appsawg-http-problem use case, you want to inform clients about a problem with that particular resource, so you probably won't redirect. however, i could easily imagine that a 402 response using draft-ietf-appsawg-http-problem might have a link in there that clients could use to initiate a payment process. that would not be one of the standard members, but an extension member. > 3. General thoughts on mime types -- I may be trying to request non JSON > paid media e.g. html or video, and the client may not be expecting the > mime type it gets -- I really need to think through this point more or > make a proof of concept i don't think there's anything special here. there are plenty services out there that return HTML 4xx pages when you request something else. afaict, http://tools.ietf.org/html/rfc7231#section-5.3.2 specifically allows a server to disregard an Accept header field if there is no match for the response it wants to send. > Would love to hear thoughts. If there's a better place to discuss this > e.g. the HTTP WG, pls let me know. my guess is that this list is fine, but it has many subscribers. so if there are specific issues around using draft-ietf-appsawg-http-problem, then maybe better use mark's github for raising issues: https://github.com/mnot/I-D/tree/master/http-problem 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 Jul 7 22:12:19 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE5E1B3025; Tue, 7 Jul 2015 22:12: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 ogKPz10dpOij; Tue, 7 Jul 2015 22:12:17 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::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 3FFC41B2FDD; Tue, 7 Jul 2015 22:12:11 -0700 (PDT) Received: by ykey15 with SMTP id y15so1736071yke.3; Tue, 07 Jul 2015 22:12: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=7NFNT8hccW/Z6/vASEqkYpl17z0rPyvs+AdFFIIqMos=; b=x5R8YlB/RXf0WUOzW51Haw0BlDsb6WqKXxrGFc1g5aOKiky9D+oMxS0WFMAsojcgx7 GgT4mBSzLXpSsBOu43UvDZszrJVePqNStJkEeOrywYVSSf7AJfzDmpxAa8Qev7+TYeAl 0kiHzVDCrVagvXMmFtrVQ8oXoRml4SkPzryFcZlLe2HI6weVhWy8c+OYywDfPFxI2rj5 dFEX5grpUWNY64Pj/H2L3iXnaB/R29/pLMVq1qlvuZLAzHnkhKNlBIGq3cToGhfYUhis j3seEiwumjCn/Z1DBTIfXmoWtoqcvDLZyRZ+L7A3KkgNsXQ45HGq19uKModsFJwwJr83 ITtg== MIME-Version: 1.0 X-Received: by 10.13.253.5 with SMTP id n5mr9647189ywf.24.1436332330445; Tue, 07 Jul 2015 22:12:10 -0700 (PDT) Received: by 10.129.46.86 with HTTP; Tue, 7 Jul 2015 22:12:10 -0700 (PDT) In-Reply-To: <20150708033255.10890.39705.idtracker@ietfa.amsl.com> References: <20150708033255.10890.39705.idtracker@ietfa.amsl.com> Date: Tue, 7 Jul 2015 22:12:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Manderson Content-Type: multipart/alternative; boundary=94eb2c06b83a55f40b051a562e1e Archived-At: Cc: appsawg-chairs@ietf.org, IETF Apps Discuss , draft-ietf-appsawg-text-markdown@ietf.org, The IESG , draft-ietf-appsawg-text-markdown.ad@ietf.org, draft-ietf-appsawg-text-markdown.shepherd@ietf.org Subject: Re: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-08: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jul 2015 05:12:18 -0000 --94eb2c06b83a55f40b051a562e1e Content-Type: text/plain; charset=UTF-8 Hi Terry, On Tue, Jul 7, 2015 at 8:32 PM, Terry Manderson wrote: > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I'm holding a discuss on this document given my discuss lodged for > draft-ietf-appsawg-text-markdown-use-cases-02 It was a working group choice to split the document that creates the registry from all of the initial registrations. The working group felt the original combined document was too large and opted for a split when it was discussed at IETF 91 in Honolulu. The "use cases" name is misleading, do you have something else in mind? Maybe something like "Registrations for Markdown Variants"? -MSK --94eb2c06b83a55f40b051a562e1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Terry,

On Tue, Jul 7, 2015 at 8:32 PM, Terry Manderson <terr= y.manderson@icann.org> wrote:

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm holding a discuss on this document given my discuss lodged for
draft-ietf-appsawg-text-markdown-use-cases-02

It was a working group choice to split the document that creates the reg= istry from all of the initial registrations.=C2=A0 The working group felt t= he original combined document was too large and opted for a split when it w= as discussed at IETF 91 in Honolulu.

The "= ;use cases" name is misleading, do you have something else in mind?=C2= =A0 Maybe something like "Registrations for Markdown Variants"?
-MSK
--94eb2c06b83a55f40b051a562e1e-- From nobody Wed Jul 8 05:30:57 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8F51A903F; Wed, 8 Jul 2015 05:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 FFSQ-9eInopH; Wed, 8 Jul 2015 05:30:56 -0700 (PDT) Received: from mail-vn0-x231.google.com (mail-vn0-x231.google.com [IPv6:2607:f8b0:400c:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ACAF1A9031; Wed, 8 Jul 2015 05:30:46 -0700 (PDT) Received: by vnbf62 with SMTP id f62so30768762vnb.9; Wed, 08 Jul 2015 05:30:45 -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=XKdOsP9CL0+HR3pOvRL91FgPCOeHSvPYTQwXVrlvMZE=; b=FWJEaOylkt9/T0tST613yGX/bsWYS+NJpMTcNsCl3WDVL01/RQD/57MuS4Jr5F6T3a 9U0tcLX1IYP4+foRRMLaUmRmibX3yrfRuNwXtmhL6KT97lm3s42m8yDsXoSYQrd93hzJ V5MjIvIF88TpH4wfIXySkR0E66ILkQIuh4UpOGBrn6w7+W9Tbyygan55+APaGnPyj/33 +nT93SyrygIMKGNhXbJa3ff7Qixc8HDuTXneSkiqL/aBlpO2pTpzz0IJ4Pd52w3Bp0zu 74G/ySuib1+v03/xRrOvrUbaT+6YSDiNhbflb7MNbirXOLkul76eloqOkwXxNYGmpfOX xxcw== MIME-Version: 1.0 X-Received: by 10.52.189.75 with SMTP id gg11mr9801040vdc.27.1436358645400; Wed, 08 Jul 2015 05:30:45 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Wed, 8 Jul 2015 05:30:45 -0700 (PDT) In-Reply-To: <20150708033129.16459.55993.idtracker@ietfa.amsl.com> References: <20150708033129.16459.55993.idtracker@ietfa.amsl.com> Date: Wed, 8 Jul 2015 08:30:45 -0400 X-Google-Sender-Auth: ZoT6VB2mnHvo5wOMjHWR9Xl7-Q0 Message-ID: From: Barry Leiba To: Terry Manderson Content-Type: multipart/alternative; boundary=001a1136b58cd44b35051a5c4e91 Archived-At: Cc: "appsawg-chairs@ietf.org" , "apps-discuss@ietf.org" , "draft-ietf-appsawg-text-markdown-use-cases.shepherd@ietf.org" , "draft-ietf-appsawg-text-markdown-use-cases@ietf.org" , "draft-ietf-appsawg-text-markdown-use-cases.ad@ietf.org" , The IESG Subject: Re: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jul 2015 12:30:57 -0000 --001a1136b58cd44b35051a5c4e91 Content-Type: text/plain; charset=UTF-8 > > This does not strike me as a 'use cases' document when you make IANA > requests to register identifiers with IANA. These seem more appropriate > in draft-ietf-appsawg-text-markdown-08. > I'm not sure why you think this is a problem -- maybe you can ekaborate -- but the working group thought it best to split this up, defining the media type and registry in one doc, and describing the variants and making the registrations in another. Barry --001a1136b58cd44b35051a5c4e91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This does not strike me as a 'use cases&= #39; document when you make IANA
requests to register identifiers with IANA. These seem more appropriate
in draft-ietf-appsawg-text-markdown-08.

I'm not sure why you think this is a p= roblem -- maybe you can ekaborate -- but the working group thought it best = to split this up, defining the media type and registry in one doc, and desc= ribing the variants and making the registrations in another.

=
Barry
=C2=A0
--001a1136b58cd44b35051a5c4e91-- From nobody Wed Jul 8 06:53:16 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34811B363D; Wed, 8 Jul 2015 06:53:13 -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 W94NDOOJeNjR; Wed, 8 Jul 2015 06:53:12 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::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 6916D1AC3BC; Wed, 8 Jul 2015 06:53:12 -0700 (PDT) Received: by ykeo3 with SMTP id o3so87051977yke.0; Wed, 08 Jul 2015 06:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=X4Xn7oz7zGicZoWGOx4Saowf/r9XzzqMTWTbUxH3lKI=; b=LSbQK1huP+DA6c/yEglJxAS5mrd8gxqi5iwG+xGf+fUVXqT/hamE9nVnhEmiJzPmLO hyZV/6dxryKPbO4gXm0pGcFFZuJvkNPLV5kopB/gNNbfVLh0wN6g9qW5C2CNAgOQ/GU4 pJaPnQfAiZVKKM5QQdTk4yrcwFyDEWNC+2DG4oWTaMgJlVLXP0uSoUrxOFT05xXNtnwB 8i8ijOBxnmnXL4wHb9j1zYiJRHilN/l3wHFY5naMjbITmsZcyVydcUc/nPO6h5rIxGPI m2oIx3dASIkZAOkjkoNxyUoCG48LgfB9kBz8Io5bM3VuFSYiqf9qD9eahb8FtwjL+rKF 3Qtg== MIME-Version: 1.0 X-Received: by 10.13.199.195 with SMTP id j186mr11458482ywd.112.1436363591735; Wed, 08 Jul 2015 06:53:11 -0700 (PDT) Received: by 10.129.46.86 with HTTP; Wed, 8 Jul 2015 06:53:11 -0700 (PDT) In-Reply-To: References: <20150708033255.10890.39705.idtracker@ietfa.amsl.com> Date: Wed, 8 Jul 2015 06:53:11 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Manderson Content-Type: multipart/alternative; boundary=001a114e61aea75eb0051a5d75e2 Archived-At: Cc: "appsawg-chairs@ietf.org" , IETF Apps Discuss , "draft-ietf-appsawg-text-markdown@ietf.org" , The IESG , "draft-ietf-appsawg-text-markdown.ad@ietf.org" , "draft-ietf-appsawg-text-markdown.shepherd@ietf.org" Subject: Re: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-08: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jul 2015 13:53:14 -0000 --001a114e61aea75eb0051a5d75e2 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 7, 2015 at 11:29 PM, Terry Manderson wrote: > Hi Murray, > > Thanks for the prompt reply. > > I think the name incorrectly positions the document, along with the text > in the entry to section 1. It's not just an informational document. > (despite the Intended RFC Status) And it doesn't read as a use-cases. > > I think "Strategies and Registrations for Markdown [identifiers|variants]" > perhaps? But not use-cases surely. :-) > > With that tone change please review some of the text in the doc (eg > section 3 where the reason for the registrations is they illustrate > interesting use cases. I would posit that the such text is superfluous in > light of the more important aspect of "broadly applicable to the Internet > community" > I can work with the author on these points and get back to you. Do you still want to hold a DISCUSS on the fact that this is two documents instead of one? -MSK --001a114e61aea75eb0051a5d75e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 7, 2015 at 11:29 PM, Terry Manderson <terry.manderson@icann.org> wrote:
Hi Murray,
Thanks for the prompt reply.

I think the name incorrectly positions the document, along with the text in the entry to section 1. It's not just an informational document.
(despite the Intended RFC Status) And it doesn't read as a use-cases.
I think "Strategies and Registrations for Markdown [identifiers|varian= ts]"
perhaps? But not use-cases surely. :-)

With that tone change please review some of the text in the doc (eg
section 3 where the reason for the registrations is they illustrate
interesting use cases. I would posit that the such text is superfluous in light of the more important aspect of "broadly applicable to the Inter= net
community"

I can work with the aut= hor on these points and get back to you.

Do you still wan= t to hold a DISCUSS on the fact that this is two documents instead of one?<= br>
-MSK
--001a114e61aea75eb0051a5d75e2-- From nobody Wed Jul 8 09:04:28 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6D31B2EB2; Tue, 7 Jul 2015 20:36:59 -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 7YLI9ffs1cIc; Tue, 7 Jul 2015 20:36:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 185B51B2EB4; Tue, 7 Jul 2015 20:31:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Terry Manderson" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150708033129.16459.55993.idtracker@ietfa.amsl.com> Date: Tue, 07 Jul 2015 20:31:29 -0700 Archived-At: X-Mailman-Approved-At: Wed, 08 Jul 2015 09:04:26 -0700 Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.shepherd@ietf.org, draft-ietf-appsawg-text-markdown-use-cases@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.ad@ietf.org Subject: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 03:36:59 -0000 Terry Manderson has entered the following ballot position for draft-ietf-appsawg-text-markdown-use-cases-02: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown-use-cases/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This does not strike me as a 'use cases' document when you make IANA requests to register identifiers with IANA. These seem more appropriate in draft-ietf-appsawg-text-markdown-08. From nobody Wed Jul 8 09:04:29 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1291B2DE0; Tue, 7 Jul 2015 20:37:20 -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 rnE0hv0GE0Qx; Tue, 7 Jul 2015 20:37:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E591B2EC3; Tue, 7 Jul 2015 20:32:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Terry Manderson" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150708033255.10890.39705.idtracker@ietfa.amsl.com> Date: Tue, 07 Jul 2015 20:32:55 -0700 Archived-At: X-Mailman-Approved-At: Wed, 08 Jul 2015 09:04:26 -0700 Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown@ietf.org, draft-ietf-appsawg-text-markdown.ad@ietf.org, draft-ietf-appsawg-text-markdown.shepherd@ietf.org Subject: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-08: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 03:37:21 -0000 Terry Manderson has entered the following ballot position for draft-ietf-appsawg-text-markdown-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm holding a discuss on this document given my discuss lodged for draft-ietf-appsawg-text-markdown-use-cases-02. From nobody Wed Jul 8 09:04:31 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B61E1B3126; Tue, 7 Jul 2015 23:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MB6lz_PibVc; Tue, 7 Jul 2015 23:29:43 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC9B1B3121; Tue, 7 Jul 2015 23:29:43 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 7 Jul 2015 23:29:41 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Tue, 7 Jul 2015 23:29:41 -0700 From: Terry Manderson To: "Murray S. Kucherawy" Thread-Topic: Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-08: (with DISCUSS) Thread-Index: AQHQuS9zPpyqC0oebEW6Sfb2A9cMnp3RfEIAgAC9SAA= Date: Wed, 8 Jul 2015 06:29:41 +0000 Message-ID: References: <20150708033255.10890.39705.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3519217778_116771593" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 08 Jul 2015 09:04:26 -0700 Cc: "appsawg-chairs@ietf.org" , IETF Apps Discuss , "draft-ietf-appsawg-text-markdown@ietf.org" , The IESG , "draft-ietf-appsawg-text-markdown.ad@ietf.org" , "draft-ietf-appsawg-text-markdown.shepherd@ietf.org" Subject: Re: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-08: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jul 2015 06:29:45 -0000 --B_3519217778_116771593 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Murray, Thanks for the prompt reply. I think the name incorrectly positions the document, along with the text in the entry to section 1. It's not just an informational document. (despite the Intended RFC Status) And it doesn't read as a use-cases. I think "Strategies and Registrations for Markdown [identifiers|variants]" perhaps? But not use-cases surely. :-) With that tone change please review some of the text in the doc (eg section 3 where the reason for the registrations is they illustrate interesting use cases. I would posit that the such text is superfluous in light of the more important aspect of "broadly applicable to the Internet community" Cheers Terry On 8/07/2015 3:12 pm, "Murray S. Kucherawy" wrote: >Hi Terry, > >On Tue, Jul 7, 2015 at 8:32 PM, Terry Manderson > wrote: > > >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >I'm holding a discuss on this document given my discuss lodged for >draft-ietf-appsawg-text-markdown-use-cases-02 > > > >It was a working group choice to split the document that creates the >registry from all of the initial registrations. The working group felt >the original combined document was too large and opted for a split when >it was discussed at IETF 91 in Honolulu. > > > >The "use cases" name is misleading, do you have something else in mind? >Maybe something like "Registrations for Markdown Variants"? > > >-MSK > > > > --B_3519217778_116771593 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFINq pUvdwNfalagV8PnWDORXFTKgMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE1MDcwODA2MjkzOFowDQYJKoZIhvcNAQEBBQAEggEADyX3SIOMmqZH4acwTiDd r65E05tvvbwI2DGzEfKP9ILKiGPBrCS6oIhZ2V+8AA9UnhUjZBCk8k7+rD1+E+oGD8NLDS6Y gflmErfEyxozR0VZfxj7oplYZ4iukDTS11+6Be4hKD2Bz1ioZq0Y1mAfKaMVmWMFIGa9enCZ c6UtmPntMm001VhNU+zfl1gFoEIhpTtwB6uPLL1UrUEfs7eWvhr694nuLZzI9ViQ8GAxSxzJ Xs4E74Aa9JKXthlPeRAzKLeUgP2jPloJ9v6Yo/S6OE/h3jBwvy2xQ0YAwzC2b0iptbyQ5vqO K7ziviUWa7GnqSgiKiS1jiB9leihJNS5dg== --B_3519217778_116771593-- From nobody Wed Jul 8 12:23:31 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E3F1A21B0; Wed, 8 Jul 2015 12:23:30 -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 DDNvoD8fp097; Wed, 8 Jul 2015 12:23:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3A81A1B6D; Wed, 8 Jul 2015 12:23:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150708192328.27464.51899.idtracker@ietfa.amsl.com> Date: Wed, 08 Jul 2015 12:23:28 -0700 Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.shepherd@ietf.org, draft-ietf-appsawg-text-markdown-use-cases@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.ad@ietf.org Subject: [apps-discuss] Ben Campbell's No Objection on draft-ietf-appsawg-text-markdown-use-cases-02: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 19:23:30 -0000 Ben Campbell has entered the following ballot position for draft-ietf-appsawg-text-markdown-use-cases-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Like others have commented, I find it a bit odd to mix the IANA registrations with the rest of the material in this draft. Some of the editorial comments (from myself below, from others, and from IDNits) makes me wonder if this draft was quite finished? While I don't think it makes sense to change course this late in the process for this draft, I am skeptical that the material in sections 1 and 2 will benefit from being in an RFC. I think that it might have made more sense to capture it in a working group wiki, or similar repository. (But again, no point in changing now.) -- 3.3, additional parameters: I’m not sure I understand why the list is broken in to “stuff to turn off” and “new stuff”. Editorial: IDNits has quite a bit to say, some of which might even be relevant. Please check. There are a number of words enclosed in /slashes/ or *asterisks*. I assume this is intended for emphasis. (Or perhaps as performance art when discussing methods for formatting text :-) ) But it seems odd for an RFC. If it stays, I suggest picking one method and sticking with it. (If it means something different, please mention that in the text.) -- section 4 refers to Appendix C, but the draft has no appendices. From nobody Wed Jul 8 12:51:13 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E801A8738; Wed, 8 Jul 2015 12:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 oDXznT7-rKxH; Wed, 8 Jul 2015 12:51:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D773D1A8760; Wed, 8 Jul 2015 12:50:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150708195047.15504.57095.idtracker@ietfa.amsl.com> Date: Wed, 08 Jul 2015 12:50:47 -0700 Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown@ietf.org, draft-ietf-appsawg-text-markdown.ad@ietf.org, draft-ietf-appsawg-text-markdown.shepherd@ietf.org Subject: [apps-discuss] Ben Campbell's No Objection on draft-ietf-appsawg-text-markdown-08: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 19:51:12 -0000 Ben Campbell has entered the following ballot position for draft-ietf-appsawg-text-markdown-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1.2, last paragraph: Is this document attempting to place normative requirements on existing markdown implementations? Or should the 2119 keywords in this section be more statements of fact (and use descriptive language?) 6.1.2, first paragraph, last sentence: Does this refer to section 6.1.2, or 6.1 and children? If the latter, and if there is no expert reviewer, who is expected to perform those checks (automatically or otherwise?) Editorial: IDNits reports a few missing or unused references, please check. There is at least one occurrence of a word inclosed in slashes like /so/. I assume that's intended for emphasis--but whether it's for that or some other reason it would be good to explicitly mention it. section 1.1, last paragraph: Does "author's intent" refer to the author of this draft, or of markdown? Figure 1: The continuation characters and some markup, impinge on the border. From nobody Wed Jul 8 16:37:30 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11E41A1DBE; Wed, 8 Jul 2015 16:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] 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 6nP7OwPv9boD; Wed, 8 Jul 2015 16:37:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AC51A1B7A; Wed, 8 Jul 2015 16:37:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150708233727.5325.46689.idtracker@ietfa.amsl.com> Date: Wed, 08 Jul 2015 16:37:27 -0700 Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown@ietf.org, draft-ietf-appsawg-text-markdown.ad@ietf.org, draft-ietf-appsawg-text-markdown.shepherd@ietf.org Subject: [apps-discuss] Alissa Cooper's No Objection on draft-ietf-appsawg-text-markdown-08: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 23:37:28 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-appsawg-text-markdown-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm not making this a DISCUSS because I think I've raised a similar issue before (with this same AD and doc shepherd, no less, I think) and lost the argument, but I don't get why this document is informational. It specifies a parameter syntax for fragment identifiers. If one implementation follows the syntax specified here and another implementation uses some other syntax defined somewhere else, how is this spec helping the two implementations interoperate? From nobody Wed Jul 8 16:51:24 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7F41A87BC; Wed, 8 Jul 2015 16:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 m8ZdV-GLuyjn; Wed, 8 Jul 2015 16:51:22 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1563C1A87B8; Wed, 8 Jul 2015 16:51:22 -0700 (PDT) Received: by pacgz10 with SMTP id gz10so66134692pac.3; Wed, 08 Jul 2015 16:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:subject:mime-version:content-type; bh=jO9WmpgRlo1g5siD3bXgwYubl2400BumgEHmTdTWEZA=; b=dS58YVUTY/gUE7VuxBuBWadU6jZgRh+HHs+pq4Y64hXlz/b/DoEP0WUSvOjofxf7fJ jHa/VJYfZraMJeJPE0erGrCyW+cTU9EUCvoEz5Nuum4fLeAMZqpencTcpZdp/FWt5BWt 2VHa9s3FOJfHjZL0j6Aix/KJPhzLWWphng90oBPZ79B7fbNL8IO1eihlk2IBzJKRmnou Ion/WBcS2nFz62ODXACXrT8MoonS7llHF8bZb6IoPQpQ/nebHDwqegxVCcJe73QOzt8a 9cofqnd6ULigWqCkMW67Apg2USNAV7eGKLSuw8R4u32fZAP6wxXziFd2hxmDPkJ3etmh bhOQ== X-Received: by 10.68.209.136 with SMTP id mm8mr14898770pbc.64.1436399481723; Wed, 08 Jul 2015 16:51:21 -0700 (PDT) Received: from clg8221.visto-mgmt.com ([206.124.114.135]) by smtp.gmail.com with ESMTPSA id je2sm3721365pbd.3.2015.07.08.16.51.20 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 08 Jul 2015 16:51:21 -0700 (PDT) Date: Wed, 8 Jul 2015 23:51:21 +0000 (GMT) From: cakaara99@gmail.com To: alissa@cooperw.in, The IESG Message-ID: <1328831881.9616.1436399481687.JavaMail.wibapp@clg8221.visto-mgmt.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_9615_501972071.1436399481686" Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-text-markdown.shepherd@ietf.org, draft-ietf-appsawg-text-markdown@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown.ad@ietf.org Subject: Re: [apps-discuss] Alissa Cooper's No Objection on draft-ietf-appsawg-text-markdown-08: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 23:51:23 -0000 ------=_Part_9615_501972071.1436399481686 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sent from my LG Mobile -----Original Message----- From: "Alissa Cooper" Date: Wed Jul 08 23:37:34 GMT 2015 To: "The IESG" CC: "appsawg-chairs@ietf.org" , "apps-discuss@ietf.org" , "draft-ietf-appsawg-text-markdown@ietf.org" , "draft-ietf-appsawg-text-markdown.ad@ietf.org" , "draft-ietf-appsawg-text-markdown.shepherd@ietf.org" Subject: [apps-discuss] Alissa Cooper's No Objection on draft-ietf-appsawg-text-markdown-08: (with COMMENT) Alissa Cooper has entered the following ballot position for draft-ietf-appsawg-text-markdown-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm not making this a DISCUSS because I think I've raised a similar issue before (with this same AD and doc shepherd, no less, I think) and lost the argument, but I don't get why this document is informational. It specifies a parameter syntax for fragment identifiers. If one implementation follows the syntax specified here and another implementation uses some other syntax defined somewhere else, how is this spec helping the two implementations interoperate? _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_Part_9615_501972071.1436399481686-- From nobody Wed Jul 8 19:24:44 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A71D1A89E0; Wed, 8 Jul 2015 19:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6dyfCltIwpn; Wed, 8 Jul 2015 19:24:42 -0700 (PDT) Received: from mail-vn0-x233.google.com (mail-vn0-x233.google.com [IPv6:2607:f8b0:400c:c0f::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46FED1A89C4; Wed, 8 Jul 2015 19:24:41 -0700 (PDT) Received: by vnav203 with SMTP id v203so14211829vna.5; Wed, 08 Jul 2015 19:24:40 -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=QaKFZIZj8+H1EwF4HSx6m3/I+XiJxwLxIgsHNonW7MI=; b=ZAzZzlv32p4Qiev49b8+fYZC/N03yeu1AHf7uefdcvYvr4dAYbQSUwPcTZsHg3Ybu8 JtnFFvo7PGckw099F1AMS1Ul3FEqGLHt0Ji0lMxnz8DDk5arJtDMJYvLjaswwjbAw9i5 zD87YZ3AqU6PNbhyuoVWGkjhh662dV1NckU8zQ17Vc5VwQFsy4l7mEP7vHC3/YzNxnyk foEzPcHS+A6+adukbYMFZ0RFGctahbreIp73FTPbQsj8qb7lc4TMoUPv3VV6TfodtjuX UYSj+QUN4CC7K2MlkyqwzB01LBeFkDhSd84EF6sN+28IzixlErWhIw+SRqyXg+MCwW6D 5vyQ== MIME-Version: 1.0 X-Received: by 10.52.245.8 with SMTP id xk8mr12709107vdc.63.1436408680513; Wed, 08 Jul 2015 19:24:40 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Wed, 8 Jul 2015 19:24:40 -0700 (PDT) In-Reply-To: <20150708233727.5325.46689.idtracker@ietfa.amsl.com> References: <20150708233727.5325.46689.idtracker@ietfa.amsl.com> Date: Wed, 8 Jul 2015 22:24:40 -0400 X-Google-Sender-Auth: -DwSoiLzRGKCRJKWbE2TVqGhAEc Message-ID: From: Barry Leiba To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "appsawg-chairs@ietf.org" , Apps Discuss , draft-ietf-appsawg-text-markdown@ietf.org, The IESG , draft-ietf-appsawg-text-markdown.ad@ietf.org, draft-ietf-appsawg-text-markdown.shepherd@ietf.org Subject: Re: [apps-discuss] Alissa Cooper's No Objection on draft-ietf-appsawg-text-markdown-08: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 02:24:43 -0000 > I'm not making this a DISCUSS because I think I've raised a similar issue > before (with this same AD and doc shepherd, no less, I think) Hi! > and lost > the argument, but I don't get why this document is informational. It > specifies a parameter syntax for fragment identifiers. If one > implementation follows the syntax specified here and another > implementation uses some other syntax defined somewhere else, how is this > spec helping the two implementations interoperate? In this case, it's Informational because it's registering things that are not controlled by IETF standards, following our general rule that having media types that are in use be registered is better than not. We can say anything we like with regard to markdown and its variants, but people will do what they like and not accept that we've declared a "standard". Our sense here is that the markdown "community", such as there is one, doesn't want us to try to set standards here. Instead, we're documenting what's in use and what interoperates, and putting it in the IANA registry. I think (and the working group thinks) that's Informational. I'm certainly happy to have further discussion about that, though, and perhaps be convinced otherwise. Barry From nobody Wed Jul 8 20:43:20 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2C01A8A86 for ; Wed, 8 Jul 2015 20:43:18 -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 INJppX1hYp5J for ; Wed, 8 Jul 2015 20:43:16 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B300F1A8A84 for ; Wed, 8 Jul 2015 20:43:16 -0700 (PDT) Received: by oibp128 with SMTP id p128so19500251oib.3 for ; Wed, 08 Jul 2015 20:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=lIePv3QcZjcsiDdZdNF0XXsVdOCnfNwZWLaW7WrybWY=; b=fLiOeRt5+Id7AjRSKJbnDBbmYL78DSnQvMs/ADOz9VhYBYeUWb2b+IKzOp775G3IMp 6xKTBCocR9imQmr+NYs6B8mi22iBpdGlzGDOl7pMOIj3S7QnX1KxMWWKt19q/vw3wxyC Z9fwHlDx65BC3qGtAahEAREP/z905U6vUklkVhQx6kxVQYzkBQgvhQgHHQxWdg39BfwS zZ4edkgn6tw1tRCWFMUUKWqVngn43689IghcBNqZGftRVrklNMM19VQebaeARmbp850N K6kUe4vUmx5FBGBc/m8Kr9lQYV4wj8Jax4l4EOIOqKrEUZjkzygfRbjE3fDMwGooGlDo mrsg== X-Received: by 10.182.186.2 with SMTP id fg2mr13096037obc.35.1436413396224; Wed, 08 Jul 2015 20:43:16 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by smtp.googlemail.com with ESMTPSA id g10sm2541611obw.2.2015.07.08.20.43.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jul 2015 20:43:15 -0700 (PDT) To: John C Klensin , apps-discuss@ietf.org References: <20150704045223.1995.qmail@ary.lan> <304A9683-83D9-4058-A45F-073D666668D7@frobbit.se> <352CA55F92A56FDC275D4A28@P5> <559B32E6.9050902@gmail.com> From: Douglas Otis X-Enigmail-Draft-Status: N1110 Message-ID: <559DEDD1.8000000@gmail.com> Date: Wed, 8 Jul 2015 20:43:13 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [apps-discuss] EAI, SPF, DKIM, and DMARC X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jul 2015 03:43:18 -0000 On 7/7/15 1:49 AM, John C Klensin wrote: > > > --On Monday, July 06, 2015 19:01 -0700 Douglas Otis > wrote: > >> Your comments are on the mark. When DMARC asserts a >> restrictive policy it deprecates the role of Sender in a >> different domain to offer an extremely weak version of >> S/MIME or OpenPGP, which is otherwise well supported, >> particularly for mobile users. This scheme will also ossify >> needed improvements as it lacks a strategy for adopting >> alternatives or for providing reasonable methods to override >> needlessly disruptive policies related to third-party services. > > Doug, > > That is my impression. It is also my impression that DMARC's > origins with, apparently, a small number of organizations with a > narrow set of perceived needs and correspondingly small number > of use cases, leading to the damage that we saw when it was > first deployed. I hope the WG can solve most or all of those > problems and that, if it cannot, that the IETF declines to > standardize it, leaving at least a small door open for other > options. > > The best may be the enemy of the good but when the effect of the > good (or non-so-good) is to block the emergence of the best or > even the better, the tradeoffs become more complicated than the > slogan. > > On the other hand, I'm unsure about your comparison to PGP and > S/MIME. While I personally prefer them, I've gotten very > pessimistic over the years about the ability of ordinary users > to maintain private keys in a secure way, I believe that models > based on trusted third parties holding private keys are close to > a contradiction, and that, however bad our experience with CA > operators have been, depending on DNS registrars may be worse. > > So I'm not quite sure where we go from here. Simply denouncing > DMARC or suggesting entirely different models for email are, > fairly clearly, not going to be helpful. Dear John, Deployment strategies for OpenPGP are getting much better. In fact, Facebook will make use of OpenPGP to encrypt web and mobile app user messages. Perhaps this might help at getting this goose off the ground. It seems iOS has issues with airdrop moving private keys for email onto the mobile device. I remain fairly confident things will improve in this much needed area. This draft details other alternatives to mitigate DMARC disruption in the following: https://tools.ietf.org/html/draft-otis-dmarc-escape-03 We offered to help any a large provider facilitate the scheme. As expected, they avoided having better control over abuse by pointing out how this would give them more responsibility. We were constantly notifying a large provider of ongoing exploits occurring with their "compliant" implementation of DKIM. About a year later they seemed confused about how malefactors were able to spoof their customers email. Heck, we published an article in ZDNet illustrating this exploit by using their service to spoof a message as being from the ZDNet reporter. A cynic might suspect there could be some type of click rate disincentive. What can be expected of a free service that just wants eyeballs? Regards, Douglas Otis From nobody Thu Jul 9 05:06:21 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE681A89C6; Thu, 9 Jul 2015 05:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUponqKMBrN4; Thu, 9 Jul 2015 05:06:15 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [217.34.220.150]) by ietfa.amsl.com (Postfix) with ESMTP id 456EA1A017C; Thu, 9 Jul 2015 05:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1436443574; d=isode.com; s=selector; i=@isode.com; bh=8XFOAb7VU5tac00ECXmf2KgKAKyuJsa1VzZljLLqsnE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=xAx54d4XbDtlUvvY8V1PFJHapQaMMpr0FtREMduqACUjqEKYwjpKMomyiKPXf11s6fmbI8 3HprR7wgwixqOCNbcxx2WKwsSdS3mynf0Si9DwottWLdrAcHq+LPHC6NnFh5RDogXodhOe k+qM0hk66vDY3ETB6a2rRZqG4L7IWig=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 9 Jul 2015 13:06:14 +0100 Message-ID: <559E639C.8030003@isode.com> Date: Thu, 09 Jul 2015 13:05:48 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 To: Benoit Claise , The IESG References: <20150706223302.24689.11506.idtracker@ietfa.amsl.com> In-Reply-To: <20150706223302.24689.11506.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown@ietf.org, n.brownlee@auckland.ac.nz, draft-ietf-appsawg-text-markdown.ad@ietf.org, draft-ietf-appsawg-text-markdown.shepherd@ietf.org Subject: Re: [apps-discuss] Benoit Claise's No Objection on draft-ietf-appsawg-text-markdown-08: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 12:06:16 -0000 Hi Benoit, On 06/07/2015 23:33, Benoit Claise wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1. From Nevil's OPS DIR feedback: >> 2. The markdown Example (Section 5) is helpful, but it doesn't seem >> to have an obvious end marker - it just runs on into section 6. >> Does markdown have something like an end-of-file marker you could >> use to make that obvious? > And answered by Alexey: >> Not really, it is a textual format with no special end marker. >> >> I suppose the whole example can be surrounded by some markers and a > note added that they are not a part of the example? > > could we use the and ? If you think this is Ok for something which is not a code fragment, I would personally be Ok with that. From nobody Thu Jul 9 05:35:52 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D05D1AD324; Thu, 9 Jul 2015 05:35:49 -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 nHyu4V7-j37K; Thu, 9 Jul 2015 05:35:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA61B1A89A5; Thu, 9 Jul 2015 05:35:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150709123547.10624.57521.idtracker@ietfa.amsl.com> Date: Thu, 09 Jul 2015 05:35:47 -0700 Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown@ietf.org, draft-ietf-appsawg-text-markdown.ad@ietf.org, draft-ietf-appsawg-text-markdown.shepherd@ietf.org Subject: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-text-markdown-08: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 12:35:49 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-appsawg-text-markdown-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 1.1: Who says that there's only a 1-dimensional continuum:-) And what's on the other end? You don't say. - The 2119 terms in the para after Figure 1 are bogus, except for the last SHOULD (on p5). - Please respond to the secdir review [1] which raised a couple of questions that deserve answers. (Apologies if I missed your answer to that.) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05830.html From nobody Thu Jul 9 05:38:54 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA3F1AD34F; Thu, 9 Jul 2015 05:38: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 Ygw7twCNyQgc; Thu, 9 Jul 2015 05:38:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 193C81AD2F2; Thu, 9 Jul 2015 05:38:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150709123851.10935.31581.idtracker@ietfa.amsl.com> Date: Thu, 09 Jul 2015 05:38:51 -0700 Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.shepherd@ietf.org, draft-ietf-appsawg-text-markdown-use-cases@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.ad@ietf.org Subject: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-text-markdown-use-cases-02: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 12:38:52 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-appsawg-text-markdown-use-cases-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (Sorry I included this in my comments for the other markdown doc but it relates to this one. I'll take this out of my ballot comment for that but not re-tx the mail.) - Please respond to the secdir review [1] which raised a couple of questions that deserve answers. (Apologies if I missed your answer to that.) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05830.html From nobody Thu Jul 9 09:02:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B8A1A870A; Wed, 8 Jul 2015 17:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTmsHdZ1MlOh; Wed, 8 Jul 2015 17:00:58 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066451A1B74; Wed, 8 Jul 2015 17:00:58 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 8 Jul 2015 17:00:55 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Wed, 8 Jul 2015 17:00:55 -0700 From: Terry Manderson To: "Murray S. Kucherawy" Thread-Topic: Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-08: (with DISCUSS) Thread-Index: AQHQuS9zPpyqC0oebEW6Sfb2A9cMnp3RfEIAgAC9SAD//9RKgIABUWgA Date: Thu, 9 Jul 2015 00:00:54 +0000 Message-ID: References: <20150708033255.10890.39705.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3519280848_117371038" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 09 Jul 2015 09:02:23 -0700 Cc: "appsawg-chairs@ietf.org" , IETF Apps Discuss , "draft-ietf-appsawg-text-markdown@ietf.org" , IESG , "draft-ietf-appsawg-text-markdown.ad@ietf.org" , "draft-ietf-appsawg-text-markdown.shepherd@ietf.org" Subject: Re: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-08: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jul 2015 00:00:59 -0000 --B_3519280848_117371038 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 8/07/2015 11:53 pm, "Murray S. Kucherawy" wrote: >On Tue, Jul 7, 2015 at 11:29 PM, Terry Manderson > wrote: > > >I can work with the author on these points and get back to you. > > >Do you still want to hold a DISCUSS on the fact that this is two >documents instead of one? Based on discussions, no - I'll drop the DISCUSS on markdown-08. Thanks Terry --B_3519280848_117371038 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFFcU F7GvwzDYiK/naEV4b8IIk1PwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE1MDcwOTAwMDA0OFowDQYJKoZIhvcNAQEBBQAEggEAR7wZT7Xh8poSlH+tOJD7 JIacoX0cvKZQtQRnBcAUJpGCP1rKHPUbXcSvtwOSF/8An7Vh/6rhhVw9BUcmbhnp/2s6PIbV S8jxOLM5PmwWKKXchXFeaKph8xnN4+rXb3Wagz4J5/KBjb8XXOk+kWaBOQOKtGt5pDODm5U8 ue7SHSL8MP9MI1mNBrtMfHsH58QJehuWecqFh2TYsMrTMtKiTqOSB2mkuyoVNUxt18cbZ40X eqxqGmRWT/quOdcbWAx8Jx//ol2i43fgicqBa9UxhzvI/S4iOAEvl4sLOewq8O1a9/fKB0JK GWd1uIPxuVs3rmOiIdkOpqMbwwrYyBdJtw== --B_3519280848_117371038-- From nobody Thu Jul 9 09:02:26 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B141A8853; Wed, 8 Jul 2015 17:13:41 -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 FQdYrS4LqSGb; Wed, 8 Jul 2015 17:13:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 096B11A87D7; Wed, 8 Jul 2015 17:13:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Terry Manderson" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150709001340.12544.48389.idtracker@ietfa.amsl.com> Date: Wed, 08 Jul 2015 17:13:40 -0700 Archived-At: X-Mailman-Approved-At: Thu, 09 Jul 2015 09:02:23 -0700 Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown@ietf.org, draft-ietf-appsawg-text-markdown.ad@ietf.org, draft-ietf-appsawg-text-markdown.shepherd@ietf.org Subject: [apps-discuss] Terry Manderson's No Objection on draft-ietf-appsawg-text-markdown-08: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 00:13:41 -0000 Terry Manderson has entered the following ballot position for draft-ietf-appsawg-text-markdown-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Cleared DISCUSS based on WG decision to separate. From nobody Thu Jul 9 09:02:28 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1C31A8904; Wed, 8 Jul 2015 17:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0ENrvTB5ZQY; Wed, 8 Jul 2015 17:47:48 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38FE31A890C; Wed, 8 Jul 2015 17:47:48 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 8 Jul 2015 17:47:44 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Wed, 8 Jul 2015 17:47:44 -0700 From: Terry Manderson To: Barry Leiba Thread-Topic: Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS) Thread-Index: AQHQuS9n6q+QKRTI4kq9y+fJ+vXm5J3R9syAgAF1iYA= Date: Thu, 9 Jul 2015 00:47:44 +0000 Message-ID: References: <20150708033129.16459.55993.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3519283661_117581516" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 09 Jul 2015 09:02:23 -0700 Cc: "appsawg-chairs@ietf.org" , IETF Apps Discuss , "draft-ietf-appsawg-text-markdown-use-cases.shepherd@ietf.org" , "draft-ietf-appsawg-text-markdown-use-cases@ietf.org" , "draft-ietf-appsawg-text-markdown-use-cases.ad@ietf.org" , IESG Subject: Re: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jul 2015 00:47:50 -0000 --B_3519283661_117581516 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Barry, This is a fairly simple problem to fix. My anxiety was cased by the incorrect targeting of the document as a use cases. It isn't. Lets call it what it is. If it was to be a use case document. I think Murray has already proposed to work with the authors on this and when I see that response I can clear the discuss. As a side: normally I would say put the registrations with the prime document, however as you say, the working group chose to split the document and that is fine. Cheers Terry On 8/07/2015 10:30 pm, "Barry Leiba" wrote: > >This does not strike me as a 'use cases' document when you make IANA >requests to register identifiers with IANA. These seem more appropriate >in draft-ietf-appsawg-text-markdown-08. > > > > >I'm not sure why you think this is a problem -- maybe you can ekaborate >-- but the working group thought it best to split this up, defining the >media type and registry in one doc, and describing the variants and >making the registrations in another. > > >Barry > --B_3519283661_117581516 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFEGU 3Wp7F97w6tAppIg5VpzTG30jMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE1MDcwOTAwNDc0MVowDQYJKoZIhvcNAQEBBQAEggEAn8535hIcIIGR+Xh6kgWc JB+WK4dxrcwnXBAPhXp32NMxDO4xz9E2cYeR52mjWSAG/5vzKzsKuYJNyUfju1Rb1Nus14wa vR3QFy+yXqoGcJigDrdB4anNtVOrPpmRWEDQSqy6mShy/MPXMp4hJtt9K069wbh22yWcEbGq bWPTDEpuq8nOlyau0JaKLntJIO15Ti1Eyxb9cVW4qR6O3vpyLaJ/gNxbo0xGblRpfRDQZWH0 V0vXjgcwp/eU/tLHNWKs2nK8UiuLPIQ5aTSY+cQ89FsASEK9UK7aXonxC76HvPm5F8Ize7F3 3b7Lc5z7aabw/w0jDcG04bBHbMvVKDeutQ== --B_3519283661_117581516-- From nobody Thu Jul 9 11:20:32 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00BC1B2B19 for ; Thu, 9 Jul 2015 11:20: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 3voeWoZYraYW for ; Thu, 9 Jul 2015 11:20:29 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40DD1B2B16 for ; Thu, 9 Jul 2015 11:20:29 -0700 (PDT) Received: by ykeo3 with SMTP id o3so122797574yke.0 for ; Thu, 09 Jul 2015 11:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=umDAI1WQcGM5gPoaiXeJtIzb8GUf1bTHRF2KdYM+8gg=; b=ZC2uwPiPPEPNPJxm2t2wJK9+EKyet+DvnQbHLck/Ig5HbQhHVOeGHspXiVwf55As1S FsdNTSTiQngtmnHDzO8qGx+wAY/IlT7K0z7+eQgF4MANygsCQUcJO0l8JTHZhjS8b445 fYlBpMC4X+cdNGoFSJ9Mt9Im7ctaUt8kuzNXeB5VIc+71mc7aGOCnQMU99EoJTJNRK+U XVhGN2qp7YQLnVmH1+toj319jme9GCBEUnoVzErlDEBVyC8e4fzrjDHR4TQ6l9ZVvxfY fVAN1oLkOOww+9moJSE1Gq9BY5WC4072VKwisbLgiRT7V50D5JVukrFhy3wpZRzM2/Qj TGCg== MIME-Version: 1.0 X-Received: by 10.13.224.7 with SMTP id j7mr18386528ywe.113.1436466029075; Thu, 09 Jul 2015 11:20:29 -0700 (PDT) Received: by 10.129.46.86 with HTTP; Thu, 9 Jul 2015 11:20:29 -0700 (PDT) Date: Thu, 9 Jul 2015 11:20:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=94eb2c07c790652433051a754fef Archived-At: Subject: [apps-discuss] Preliminary IETF 93 APPSAWG/ARTAREA agenda posted X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jul 2015 18:20:31 -0000 --94eb2c07c790652433051a754fef Content-Type: text/plain; charset=UTF-8 Colleagues, The preliminary APPSAWG/ARTAREA agenda for the Prague meeting has been posted: https://www.ietf.org/proceedings/93/agenda/agenda-93-appsawg Please contact appsawg-chairs@ietf.org with any questions, comment, requests, etc. -MSK, APPSAWG co-chair --94eb2c07c790652433051a754fef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

The preliminary AP= PSAWG/ARTAREA agenda for the Prague meeting has been posted:

https://w= ww.ietf.org/proceedings/93/agenda/agenda-93-appsawg

Please= contact appsawg-chairs@ietf.org= with any questions, comment, requests, etc.

-MSK, APPSAWG= co-chair
--94eb2c07c790652433051a754fef-- From nobody Thu Jul 9 19:19:21 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2C61A1F1D for ; Thu, 9 Jul 2015 19:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 4sBlNfM7COrE for ; Thu, 9 Jul 2015 19:19:19 -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 9BA4F1A86F6 for ; Thu, 9 Jul 2015 19:19:19 -0700 (PDT) Received: (qmail 72340 invoked from network); 10 Jul 2015 02:19:32 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Jul 2015 02:19:32 -0000 Date: 10 Jul 2015 02:18:55 -0000 Message-ID: <20150710021855.9888.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [apps-discuss] Preliminary IETF 93 APPSAWG/ARTAREA agenda posted X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jul 2015 02:19:20 -0000 If there's time, perhaps consider my draft-levine-appsarea-eaiauth-00 There seemed to be some interest, and I got at least one thing wrong which suggests the goal of clearing up EAI vs. mail auth is worth doing. I won't be there, could probably stay up late and talk remotely if need be. R's, John From nobody Fri Jul 10 20:04:32 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4BB1A1BCD; Fri, 10 Jul 2015 20:04:31 -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 T1I3EchaSSJk; Fri, 10 Jul 2015 20:04:29 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 8D0E81A1BCC; Fri, 10 Jul 2015 20:04:29 -0700 (PDT) Received: from smize.t-mobile.com (unknown [162.248.119.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 08229509BF; Fri, 10 Jul 2015 23:04:25 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_CD4B70E3-D596-48F5-97D6-9E04AC183CEA"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <20150709123547.10624.57521.idtracker@ietfa.amsl.com> Date: Fri, 10 Jul 2015 20:03:38 -0700 Message-Id: <8CD38C95-4B96-4E73-8833-4988332319E2@seantek.com> References: <20150709123547.10624.57521.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown@ietf.org, The IESG , draft-ietf-appsawg-text-markdown.ad@ietf.org, draft-ietf-appsawg-text-markdown.shepherd@ietf.org Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-text-markdown-08: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 03:04:31 -0000 --Apple-Mail=_CD4B70E3-D596-48F5-97D6-9E04AC183CEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Regarding these comments: > - 1.1: Who says that there's only a 1-dimensional continuum:-) > And what's on the other end? You don't say. Changed text: {{ On the one end is plain text: a linear sequence of characters in some = character set (code), possibly interrupted by line breaks, page breaks, = or other control characters. (On the other end is binary data, which = computer systems store and process with bit-for-bit accuracy.) The = repertoire of control characters (a form of in-band signaling) is = necessarily limited [=85] }} > - The 2119 terms in the para after Figure 1 are bogus, except > for the last SHOULD (on p5). This was discussed with prior reviewers (I believe Barry Leiba): the = sentences were rephrased to have the 2119 terms (SHOULD, etc.) be placed = on implementations, rather than what users SHOULD be able to do (i.e., = user capabilities). > - Please respond to the secdir review [1] which raised a couple > of questions that deserve answers. (Apologies if I missed your > answer to that.) secdir review response in reply of that specific e-mail; thanks. Sean On Jul 9, 2015, at 5:35 AM, Stephen Farrell = wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-appsawg-text-markdown-08: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - 1.1: Who says that there's only a 1-dimensional continuum:-) > And what's on the other end? You don't say. >=20 > - The 2119 terms in the para after Figure 1 are bogus, except > for the last SHOULD (on p5). >=20 > - Please respond to the secdir review [1] which raised a couple > of questions that deserve answers. (Apologies if I missed your > answer to that.) >=20 > [1] = https://www.ietf.org/mail-archive/web/secdir/current/msg05830.html >=20 >=20 --Apple-Mail=_CD4B70E3-D596-48F5-97D6-9E04AC183CEA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUwNzExMDMwNDEwWjAjBgkqhkiG9w0BCQQxFgQUtNM4Zjb9j1TGMqdDAYCKiszS7I4wgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAFSei4SLlPR6mf7fATZovZcHQ0MN4jAoy8FbkW//wbJz3OHfleB3OB4cTx2SQ0XVjoPQ SLXhw8ojjDgDAbIt7mbigsa76EBtO93PBwikE1pmP1bV9m4X8u//WW46mmuCQndX9tZNjCUcHoCz JwlIu7ttQTz5TtbhdF73JmZD164LZy1hBY4jvWgnVSlS9i9DXEp16I9jEZgBy/BVFPO8VWKnBgNz Ojp7HEpLvI5+AWMe0EhdGvKywe4SnnatUcpUYSD9mqWe76LuvuAYNndCApuWi81YLs/jh5or1/uO LaJpoiOMUUiz4cdqSdwzlSCdEM7iAJPIu0CdpsTlIx5Hl38AAAAAAAA= --Apple-Mail=_CD4B70E3-D596-48F5-97D6-9E04AC183CEA-- From nobody Fri Jul 10 20:10:37 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D844B1A1BD7; Fri, 10 Jul 2015 20:10:33 -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 SYBvTBTxPOLN; Fri, 10 Jul 2015 20:10:32 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 02A871A1BD1; Fri, 10 Jul 2015 20:10:31 -0700 (PDT) Received: from smize.t-mobile.com (unknown [162.248.119.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1DBAA509BB; Fri, 10 Jul 2015 23:10:27 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C0BE6008-FD9D-4E57-9DA4-51E317E35972"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <20150706223302.24689.11506.idtracker@ietfa.amsl.com> Date: Fri, 10 Jul 2015 20:10:00 -0700 Message-Id: References: <20150706223302.24689.11506.idtracker@ietfa.amsl.com> To: Benoit Claise X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown@ietf.org, The IESG , draft-ietf-appsawg-text-markdown.ad@ietf.org, n.brownlee@auckland.ac.nz, draft-ietf-appsawg-text-markdown.shepherd@ietf.org Subject: Re: [apps-discuss] Benoit Claise's No Objection on draft-ietf-appsawg-text-markdown-08: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 03:10:34 -0000 --Apple-Mail=_C0BE6008-FD9D-4E57-9DA4-51E317E35972 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 (This response takes Alexey Melnikov=92s comment into account.) On Jul 6, 2015, at 3:33 PM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-appsawg-text-markdown-08: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > 1. =46rom Nevil's OPS DIR feedback:=20 >> 2. The markdown Example (Section 5) is helpful, but it doesn't seem >> to have an obvious end marker - it just runs on into section 6. >> Does markdown have something like an end-of-file marker you could >> use to make that obvious? > And answered by Alexey: >>=20 >> Not really, it is a textual format with no special end marker. >>=20 >> I suppose the whole example can be surrounded by some markers and a > note added that they are not a part of the example? >=20 > could we use the and ? Actually the example in Section 5 is indented by one space. The final = line of example: {{ [fOo]: http://example.com/loc 'Will Not Work with Markdown.pl-1.0.1' }} goes right up to the edge, so it cannot be indented further than one = space, unless I change the example. (Note that it is difficult to say = 'Won't Work with=85' due to the use of ' as a delimiter.=20 I think it is fine as-is. It is clear (to me, anyway) that "6. IANA = Considerations" is a new section. >=20 > 2. "A companion document [MDMTUSES] provides additional Markdown > background and philosophy." >=20 > There is more than that. See the > draft-ietf-appsawg-text-markdown-use-cases abstract: "Background > information, local storage strategies, and additional syntax > registrations are supplied" Revised text: {{ A companion document [MDMTUSES] provides additional Markdown background, = philosophy, local storage strategies, and variant registrations = (including examples). }} >=20 > 3. Editorial > OLD: [fOo] > NEW: [foo] >=20 The spelling is intentional: link identifiers are not case-sensitive. = (The text =93(Remember that link identifiers are not case-sensitive.)=94 = appears in the example itself.)=20 Kind regards, Sean= --Apple-Mail=_C0BE6008-FD9D-4E57-9DA4-51E317E35972 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUwNzExMDMxMDMxWjAjBgkqhkiG9w0BCQQxFgQUpOaAhI+CRzfbzYnUL7VNAZUUUdwwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAHpKwdLAGzL0cHrLjlmPSnvX2LqjHpCsypiMicHP+B5nA8RpJGhJ2yqPTwILQbivZlI9 fo3DXfcbgclWJU9ocQv0bVib7Ulw8wUKMBZ9r+RoAo/evmldqq5LdRCjJM7sAMTicQ5f8yOXXdQZ qOr40GYJ0XWFvYoSzrLG5BX9r9RnSgfrM0+VCaBPGFo+LF4mmtLE2HHX4bAuJJMh80fvkXiG1LZT ciL2KBJc95S8RHqgMAxEF4b2CSnGqC4m9tOx1RUYsf3MhQ8n8BxW53BurRizowC9H1xeq5C7N6Vr dutxDHOKDTCR272V4MSYT8K//V7ha0lDVRahMZYJFQptMUsAAAAAAAA= --Apple-Mail=_C0BE6008-FD9D-4E57-9DA4-51E317E35972-- From nobody Fri Jul 10 20:20:04 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C64C1A1BDC; Fri, 10 Jul 2015 20:20:01 -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 kpZF-eAvrDw3; Fri, 10 Jul 2015 20:20:00 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 CC55E1A1DBE; Fri, 10 Jul 2015 20:19:59 -0700 (PDT) Received: from smize.t-mobile.com (unknown [162.248.119.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4C311509BE; Fri, 10 Jul 2015 23:19:55 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_5C2EF8E0-EF6B-43BD-ABE3-0DA63F0D6EE2"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: Date: Fri, 10 Jul 2015 20:19:35 -0700 Message-Id: <97A72BEB-8F09-4981-BDF7-2CFB2412EFA5@seantek.com> References: <20150708233727.5325.46689.idtracker@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "appsawg-chairs@ietf.org" , Apps Discuss , draft-ietf-appsawg-text-markdown@ietf.org, The IESG , draft-ietf-appsawg-text-markdown.ad@ietf.org, draft-ietf-appsawg-text-markdown.shepherd@ietf.org Subject: Re: [apps-discuss] Alissa Cooper's No Objection on draft-ietf-appsawg-text-markdown-08: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 03:20:01 -0000 --Apple-Mail=_5C2EF8E0-EF6B-43BD-ABE3-0DA63F0D6EE2 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Jul 8, 2015, at 7:24 PM, Barry Leiba wrote: >> I'm not making this a DISCUSS because I think I've raised a similar issue >> before (with this same AD and doc shepherd, no less, I think) > > Hi! > >> and lost >> the argument, but I don't get why this document is informational. It >> specifies a parameter syntax for fragment identifiers. If one >> implementation follows the syntax specified here and another >> implementation uses some other syntax defined somewhere else, how is this >> spec helping the two implementations interoperate? > > In this case, it's Informational because it's registering things that > are not controlled by IETF standards, following our general rule that > having media types that are in use be registered is better than not. > We can say anything we like with regard to markdown and its variants, > but people will do what they like and not accept that we've declared a > "standard". Our sense here is that the markdown "community", such as > there is one, doesn't want us to try to set standards here. > > Instead, we're documenting what's in use and what interoperates, and > putting it in the IANA registry. I think (and the working group > thinks) that's Informational. Yes. +1. Sean --Apple-Mail=_5C2EF8E0-EF6B-43BD-ABE3-0DA63F0D6EE2 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUwNzExMDMyMDAwWjAjBgkqhkiG9w0BCQQxFgQUipaAVBckVh7Ug7rkg8DxP13K6qQwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAB797H/6ZbRoU+qyIIwDR4et+YlfGdhLoIP0Y+vsUZTJzfZq/gIudubfQYaOEgOr5LOE 7gNZAhRIBUgMQlTyDmv61+/Ps2g/SBnh4PgzH8r3z8xK9aeIKjMNOImzan4ZyYTyauln5kEcMXRO N+wSlupJODXg7z7psjzPXAvc/XFeNZ5hKJ4Polgrhiu9K5jFicpOAvQ8cXmPwrbJVrpzriyNxjd0 du29CQGhvjrtFm/aBI2JoW9a3Tm8axFkWuYwxeDakz3HCY+L2QZuyipTJp68irhiPZOKzrpZ0nEb y20QfnQcNVwX38TYQupWTfsy8ByBSfFU5u6I+Jxq7CiTsqQAAAAAAAA= --Apple-Mail=_5C2EF8E0-EF6B-43BD-ABE3-0DA63F0D6EE2-- From nobody Fri Jul 10 20:26:22 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D191A1EF7; Fri, 10 Jul 2015 20:26:20 -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 V7EzWg0MmOzd; Fri, 10 Jul 2015 20:26:18 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 89E2E1A1EF5; Fri, 10 Jul 2015 20:26:18 -0700 (PDT) Received: from smize.t-mobile.com (unknown [162.248.119.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3B1BB509BE; Fri, 10 Jul 2015 23:26:14 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8041D31C-5C18-4FEE-8F57-1E15E4FBDD27"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: Date: Fri, 10 Jul 2015 20:25:45 -0700 Message-Id: <6475ED7E-017E-46CD-A1B9-2755AFC2F702@seantek.com> References: <20150708033129.16459.55993.idtracker@ietfa.amsl.com> To: Terry Manderson X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "appsawg-chairs@ietf.org" , IETF Apps Discuss , "draft-ietf-appsawg-text-markdown-use-cases.shepherd@ietf.org" , "draft-ietf-appsawg-text-markdown-use-cases@ietf.org" , "draft-ietf-appsawg-text-markdown-use-cases.ad@ietf.org" , IESG , Barry Leiba Subject: Re: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jul 2015 03:26:20 -0000 --Apple-Mail=_8041D31C-5C18-4FEE-8F57-1E15E4FBDD27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yes: the working group chose to split the document along those subject = matter lines. When I wrote the draft, I called it =93use-cases=94 because it was as = pithy a way as any to summarize and condense the subject matter, namely = (quoting from the abstract): Background information, local storage strategies, and additional syntax registrations [with examples] To my mind =93use cases=94 meant: here are all of these really = interesting use cases for Markdown (including =93cases where Markdown is = in use=94), either that motivated its creation, or that have cropped up = since its creation. Local storage strategies would be an example of a = case where Markdown is in use in a broader system, and needs to be = labeled in some systematic way. I suppose we could call it =93Markdown in Action=94 or =93The Many Uses = of Markdown=94 but those are a bit overwrought IMO. Sean On Jul 8, 2015, at 5:47 PM, Terry Manderson = wrote: > Hi Barry, >=20 > This is a fairly simple problem to fix. >=20 > My anxiety was cased by the incorrect targeting of the document as a = use > cases. It isn't. Lets call it what it is. > If it was to be a use case document. I think Murray has already = proposed > to work with the authors on this and when I see that response I can = clear > the discuss. >=20 > As a side: normally I would say put the registrations with the prime > document, however as you say, the working group chose to split the > document and that is fine. >=20 > Cheers > Terry >=20 >=20 > On 8/07/2015 10:30 pm, "Barry Leiba" wrote: >=20 >>=20 >> This does not strike me as a 'use cases' document when you make IANA >> requests to register identifiers with IANA. These seem more = appropriate >> in draft-ietf-appsawg-text-markdown-08. >>=20 >>=20 >>=20 >>=20 >> I'm not sure why you think this is a problem -- maybe you can = ekaborate >> -- but the working group thought it best to split this up, defining = the >> media type and registry in one doc, and describing the variants and >> making the registrations in another. >>=20 >>=20 >> Barry >>=20 --Apple-Mail=_8041D31C-5C18-4FEE-8F57-1E15E4FBDD27 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUwNzExMDMyNjE5WjAjBgkqhkiG9w0BCQQxFgQUK1wHle25ogaTRZsIcLDfhqkMdlwwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBABqn/SsWcjhQdMDYB3vi2hIG56RYyUlQmMhaJOYHC+EILqEjo5NYRPbkFjO6mtHL5eWW 9XDuP1wDGde5j8TetB8CO0v/M+xJjWyzRtxriY+NkIQQjTLCRhlDupXnBNvpq+v/D2W/L7VFmfi2 Sc7TE8JSIRwPZ81Hz6McCQ1JBRusO9iNFkbEAb4rpyG1ciI8xSZkGJfVy+g2CAPo6cxOVR56yXYA HTMfAeQgKpw+kwoCUY93ZvgQn1Q6Q8FMNpSf4dbbduvPcE/yhHjSJ7AaEGPgfQiRuFJB4khlAudI HOP+OF3R2js1Tv11WqEw9LL4e/iOZqN0XT53uItLAqZKIO4AAAAAAAA= --Apple-Mail=_8041D31C-5C18-4FEE-8F57-1E15E4FBDD27-- From nobody Fri Jul 10 20:38:04 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D261A0145; Fri, 10 Jul 2015 20:38:02 -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 rcseet7p93p1; Fri, 10 Jul 2015 20:38:01 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 3D0741A0155; Fri, 10 Jul 2015 20:38:01 -0700 (PDT) Received: from smize.t-mobile.com (unknown [162.248.119.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 11A63509C0; Fri, 10 Jul 2015 23:37:57 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_BACE2E69-356F-4C6B-9FAE-7EA8A2D49856"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <20150708195047.15504.57095.idtracker@ietfa.amsl.com> Date: Fri, 10 Jul 2015 20:37:28 -0700 Message-Id: <5959C2F1-CE58-49D7-8D88-B9585C2A70FC@seantek.com> References: <20150708195047.15504.57095.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown@ietf.org, The IESG , draft-ietf-appsawg-text-markdown.ad@ietf.org, draft-ietf-appsawg-text-markdown.shepherd@ietf.org Subject: Re: [apps-discuss] Ben Campbell's No Objection on draft-ietf-appsawg-text-markdown-08: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 03:38:03 -0000 --Apple-Mail=_BACE2E69-356F-4C6B-9FAE-7EA8A2D49856 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 (See below.) On Jul 8, 2015, at 12:50 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-appsawg-text-markdown-08: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > 1.2, last paragraph: >=20 > Is this document attempting to place normative requirements on = existing > markdown implementations? Or should the 2119 keywords in this section = be > more statements of fact (and use descriptive language?) The paragraph includes hortative statements that encourage Markdown = system implementations to include certain features. The hortative = (encouraging) statements are intended to be normative for = implementations in general, but in particular, for future = implementations of Markdown systems that process multiple variants, = because the point is that the systems interoperate. Basically it is like saying (when motivated by security): =93Server-side = implementations SHOULD check the client=92s input to avoid buffer = overruns when allocating memory.=94 That would be a normative statement: = it is not required (not MUST), but it is encouraged (SHOULD). In this = case, the IETF goal is interoperability: the normative text supports = this goal. >=20 > 6.1.2, first paragraph, last sentence: > Does this refer to section 6.1.2, or 6.1 and children? If the latter, = and > if there is no expert reviewer, who is expected to perform those = checks > (automatically or otherwise?) >=20 > Editorial: >=20 > IDNits reports a few missing or unused references, please check. Not sure I saw those; I will look at the IDNits report. >=20 > There is at least one occurrence of a word inclosed in slashes like = /so/. > I assume that's intended for emphasis--but whether it's for that or = some > other reason it would be good to explicitly mention it. Yes, it is intended for emphasis. It might have been an artifact of = xml2rfc before I switched to nroff; not sure. In any event, is it true = that published RFCs generally do not include those types of textual = markers? If so, they can be removed (when not in quoted text) without = significant loss of meaning. >=20 > section 1.1, last paragraph: Does "author's intent" refer to the = author > of this draft, or of markdown? The =93author's intent=94 refers to the author of the particular = Markdown content. (Not the author of the draft, and not the author of = Markdown, John Gruber.) >=20 > Figure 1: The continuation characters and some markup, impinge on the > border. Yes, it was written to go right to the edge. Sean= --Apple-Mail=_BACE2E69-356F-4C6B-9FAE-7EA8A2D49856 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUwNzExMDMzODAyWjAjBgkqhkiG9w0BCQQxFgQUsP2wXHeovnUUxtgdwDfc2yQlGSMwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAF6qrs8cNFb0S5/LH+ZBk4WcYyn1Na50HAlWMLDYjau2oZ9uRKSjF0V6vfqUdhn7Q+us gM+ifauhBvO4zEQTzOI+aenYKKwcE2lcAXNEw+q41YEvbJrL8oeJ1Jgqgc3nCuCdW4agQowPx1SZ tnnhceusjwhEdXH9Hxkn/S/byB+yx56aSUc5t++o8zAjPAwgBI7GOp9HyHtQlXNW5wVE3rpr2hoj clPE6noksswVUMhsCabSk10QLCRwZFo1tSvkcQVbeYd9VkcWeQWd+x+WVF2/zqpEEHous2FyThfq sIdMwORSqkbz+ZTTGeEv3g7m6T1AM7wigVDQACPhAl2+zf0AAAAAAAA= --Apple-Mail=_BACE2E69-356F-4C6B-9FAE-7EA8A2D49856-- From nobody Fri Jul 10 20:41:50 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFB91A1AC6; Fri, 10 Jul 2015 20:41:48 -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 AgCCA95c0xDU; Fri, 10 Jul 2015 20:41:47 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 E54391A1A03; Fri, 10 Jul 2015 20:41:46 -0700 (PDT) Received: from smize.t-mobile.com (unknown [162.248.119.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id EB426509BE; Fri, 10 Jul 2015 23:41:43 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_88A85107-D862-4B54-9F9E-62B6EBF9EA9C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <20150708192328.27464.51899.idtracker@ietfa.amsl.com> Date: Fri, 10 Jul 2015 20:41:14 -0700 Message-Id: <212B70E4-FE88-49C2-A4D4-EBB95505F0EE@seantek.com> References: <20150708192328.27464.51899.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.shepherd@ietf.org, draft-ietf-appsawg-text-markdown-use-cases@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.ad@ietf.org, The IESG Subject: Re: [apps-discuss] Ben Campbell's No Objection on draft-ietf-appsawg-text-markdown-use-cases-02: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 03:41:48 -0000 --Apple-Mail=_88A85107-D862-4B54-9F9E-62B6EBF9EA9C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 8, 2015, at 12:23 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-appsawg-text-markdown-use-cases-02: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown-use-case= s/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Like others have commented, I find it a bit odd to mix the IANA > registrations with the rest of the material in this draft. >=20 > Some of the editorial comments (from myself below, from others, and = from > IDNits) makes me wonder if this draft was quite finished? >=20 > While I don't think it makes sense to change course this late in the > process for this draft, I am skeptical that the material in sections 1 > and 2 will benefit from being in an RFC. I think that it might have = made > more sense to capture it in a working group wiki, or similar = repository. > (But again, no point in changing now.) >=20 > -- 3.3, additional parameters: > I=92m not sure I understand why the list is broken in to =93stuff to = turn > off=94 and =93new stuff=94. I suppose that is an inelegant way of saying: {{ Extensions to turn off (on by default): Extensions to turn on (off by default): }} That verbiage corresponds with the text that precedes it: =93+" preceding an extension token turns the extension on; "-" turns the = extension off. >=20 > Editorial: >=20 > IDNits has quite a bit to say, some of which might even be relevant. > Please check. OK. >=20 > There are a number of words enclosed in /slashes/ or *asterisks*. I > assume this is intended for emphasis. (Or perhaps as performance art = when > discussing methods for formatting text :-) ) But it seems odd for an > RFC. If it stays, I suggest picking one method and sticking with it. = (If > it means something different, please mention that in the text.) See prior comment about text-markdown. I can remove these slashes and = asterisks. >=20 > -- section 4 refers to Appendix C, but the draft has no appendices. >=20 Section 4, change text to: This section provides examples of the variants in Section 3. Sean= --Apple-Mail=_88A85107-D862-4B54-9F9E-62B6EBF9EA9C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUwNzExMDM0MTQ4WjAjBgkqhkiG9w0BCQQxFgQUqI4EX3t/7esKn2nwlj93y/lNwo8wgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAMEzmoSlLd2GDH9oRClZRi16jb0RJaKMjuK+/rt41bdVTcAz4y5hE3ZB/UP23FuHkWzd MY5eALHY+vTs4HQOkIGS+1d1ArQ+H18clkE8o/P7JeMllmOxYXJmFcdTZIB2UJV0Fvdg701/zzh/ RXO/cSmJSxHIelDQHNNcdz88muUc1OcBSrci6h+t+9dMbXud1e4ASq0SN2UCWhkRx9WITGg68Ht5 nNXcnA1NtJc7U+Ghqgo6pt3iP4VbT1gSsAinE21qjk41m58qxqO3YHpFpiDSdqanCDaWvegk/SGF WQS4qCvQRMpyX6stKTOVJkmF8jZkK/Ql4WuayuaYXkEsqloAAAAAAAA= --Apple-Mail=_88A85107-D862-4B54-9F9E-62B6EBF9EA9C-- From nobody Fri Jul 10 20:45:38 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCB91A1B62; Fri, 10 Jul 2015 20:45:34 -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 y2jxRnZta9Ju; Fri, 10 Jul 2015 20:45:32 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 6C1FF1A00EF; Fri, 10 Jul 2015 20:45:32 -0700 (PDT) Received: from smize.t-mobile.com (unknown [162.248.119.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C206B509BB; Fri, 10 Jul 2015 23:45:28 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_4917B0BF-4BAC-4891-84E7-2B2A9D6136A9"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <20150706224353.15970.20875.idtracker@ietfa.amsl.com> Date: Fri, 10 Jul 2015 20:45:06 -0700 Message-Id: References: <20150706224353.15970.20875.idtracker@ietfa.amsl.com> To: Benoit Claise X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.shepherd@ietf.org, draft-ietf-appsawg-text-markdown-use-cases@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.ad@ietf.org, The IESG Subject: Re: [apps-discuss] Benoit Claise's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 03:45:34 -0000 --Apple-Mail=_4917B0BF-4BAC-4891-84E7-2B2A9D6136A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 6, 2015, at 3:43 PM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-appsawg-text-markdown-use-cases-02: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown-use-case= s/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Easy to fix DISCUSS: The RFC 2119 boilerplate is missing: >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this > document are to be interpreted as described in [RFC2119]. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > - I was surprised by the RFC2119 keywords in a use cases document = (which > I first thought of as an applicability document") > But, actually, according to the abstract, it's way more than a use = cases > document: "Background information, local storage strategies, and > additional syntax registrations are supplied.",=20 > It's really the companion document of = draft-ietf-appsawg-text-markdown. > Maybe the title is wrong, and should be something such as = text/markdown > strategies and registrations? So to conclude here: the use-cases document needs RFC 2119 boilerplate = and reference. Right? >=20 > " [MDMTREG] (draft-05) only defines two parameters:" > I guess there is nothing special about version 5. The latest version = is > v8 Already noted. >=20 > Editorial: > - section 1, para 4. That confused me until I saw figure 1 > OLD: On the formal end of the spectrum is markup > NEW: On the formal end of the formatted text spectrum is markup Ok, agreed. {{ On the formal end of the formatted text spectrum is markup, a family of = languages [=85] }} >=20 > - There are a couple of [CITE] reference, including this one: = Character > set interoperability is well-studied territory [NB: CITE?] > To be completed I guess. I propose that those [CITE] / [NB: CITE?] pieces simply be removed, = since they are not that big of a deal. Sean --Apple-Mail=_4917B0BF-4BAC-4891-84E7-2B2A9D6136A9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUwNzExMDM0NTMzWjAjBgkqhkiG9w0BCQQxFgQUErCWC13vBBVSR2hRQcbhFHHb2JswgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBABFC8BbiCyd4UBuWvXJInmMdRIZM9L4eqpn+/w5eP7vlhkzBcUyxON9FsCg3WxAtXHEz yxyD+BA/dCOR09iwpyTF7BjKIny1+BtvGD/rYdL8MH5X3SQsDsfB9+CXNsjKz34jAs4wz/EHq6HU j9VHzknc1ZOfTkkcIGYCMT3JuvcpqHIX+5PKiC3x62nShIkofWsu5KYgS8ZfkW+wCgXasc28Fu51 Nc6MvgTlkl+E4iwupTug0j5TQKFA5JBdgW/fINvze1TuydPQpqzxZAttTyHiepMdZsWWKtgHdxGt +dxYIFWmcqEgPETym8vHKRLWr+CYfE/odLN5MEfq73H4Vc8AAAAAAAA= --Apple-Mail=_4917B0BF-4BAC-4891-84E7-2B2A9D6136A9-- From nobody Fri Jul 10 21:18:58 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F80A1A1BF2; Fri, 10 Jul 2015 21:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFkKPZx0Vr5r; Fri, 10 Jul 2015 21:18:55 -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 29D811A1BEC; Fri, 10 Jul 2015 21:18:55 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZDmFY-000Civ-9O; Sat, 11 Jul 2015 00:18:52 -0400 Date: Sat, 11 Jul 2015 00:18:47 -0400 From: John C Klensin To: Sean Leonard , Benoit Claise Message-ID: <859C4C350741D890E64B4B73@JcK-HP8200.jck.com> In-Reply-To: References: <20150706224353.15970.20875.idtracker@ietfa.amsl.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: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.shepherd@ietf.org, draft-ietf-appsawg-text-markdown-use-cases@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.ad@ietf.org, The IESG Subject: Re: [apps-discuss] Benoit Claise's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 04:18:57 -0000 --On Friday, July 10, 2015 20:45 -0700 Sean Leonard wrote: >> - There are a couple of [CITE] reference, including this one: >> Character set interoperability is well-studied territory [NB: >> CITE?] To be completed I guess. > > > I propose that those [CITE] / [NB: CITE?] pieces simply be > removed, since they are not that big of a deal. Sean, I'm not following these two documents in detail and don't intend to, but the above statement (with or without citations) is, for lack of a better word, offensive. It is almost like saying in another context "While this specification requires a universal solution to the PKI problem, that problem is well-studied territory" or, if you are optimistic about that one, "Having this work well depends on a solution to the halting problem, which is well-studied territory". If you have a character set problem, or, as usually turns out to be the case when people start talking about "character set interoperability", an i18n problem, you really need to say something specific (and probably provide references), not say something that sounds like "it is a problem that others have spent time on and therefore we can ignore". Back to lurking. john From nobody Fri Jul 10 21:59:20 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157981A3BA1; Fri, 10 Jul 2015 21:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYchZa7YQ6ai; Fri, 10 Jul 2015 21:59:14 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5632C1A21C5; Fri, 10 Jul 2015 21:59:14 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6B4x2Vl024692 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 10 Jul 2015 23:59:12 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Sean Leonard" Date: Fri, 10 Jul 2015 23:59:01 -0500 Message-ID: <188BCEFF-C8E7-40D8-AB4D-9A871CF730E5@nostrum.com> In-Reply-To: <5959C2F1-CE58-49D7-8D88-B9585C2A70FC@seantek.com> References: <20150708195047.15504.57095.idtracker@ietfa.amsl.com> <5959C2F1-CE58-49D7-8D88-B9585C2A70FC@seantek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown@ietf.org, The IESG , draft-ietf-appsawg-text-markdown.ad@ietf.org, draft-ietf-appsawg-text-markdown.shepherd@ietf.org Subject: Re: [apps-discuss] Ben Campbell's No Objection on draft-ietf-appsawg-text-markdown-08: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 04:59:16 -0000 On 10 Jul 2015, at 22:37, Sean Leonard wrote: > > On Jul 8, 2015, at 12:50 PM, Ben Campbell wrote: [...] >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> 1.2, last paragraph: >> >> Is this document attempting to place normative requirements on >> existing >> markdown implementations? Or should the 2119 keywords in this section >> be >> more statements of fact (and use descriptive language?) > > The paragraph includes hortative statements that encourage Markdown > system implementations to include certain features. The hortative > (encouraging) statements are intended to be normative for > implementations in general, but in particular, for future > implementations of Markdown systems that process multiple variants, > because the point is that the systems interoperate. > > Basically it is like saying (when motivated by security): > “Server-side implementations SHOULD check the client’s input to > avoid buffer overruns when allocating memory.” That would be a > normative statement: it is not required (not MUST), but it is > encouraged (SHOULD). In this case, the IETF goal is interoperability: > the normative text supports this goal. I guess the issue is that this draft does not specify markdown itself, and I did not get the impression it specified markdown implementations in general. Thus it seems like it's trying to put normative requirements on things that don't necessarily implement this draft (and implementers that may not even read this). In any case, it's not a show stopper--I just wanted to make sure it was intentional. > >> >> 6.1.2, first paragraph, last sentence: >> Does this refer to section 6.1.2, or 6.1 and children? If the latter, >> and >> if there is no expert reviewer, who is expected to perform those >> checks >> (automatically or otherwise?) I didn't see a response to this. (But again, I don't see it as a showstopper unless IANA does.) [...] > >> >> There is at least one occurrence of a word inclosed in slashes like >> /so/. >> I assume that's intended for emphasis--but whether it's for that or >> some >> other reason it would be good to explicitly mention it. > > Yes, it is intended for emphasis. It might have been an artifact of > xml2rfc before I switched to nroff; not sure. In any event, is it true > that published RFCs generally do not include those types of textual > markers? If so, they can be removed (when not in quoted text) without > significant loss of meaning. > I don't know that it's forbidden, although the RFC editor may have an opinion. If you prefer to keep it, it might be worth a sentence mentioning the convention. >> >> section 1.1, last paragraph: Does "author's intent" refer to the >> author >> of this draft, or of markdown? > > The “author's intent” refers to the author of the particular > Markdown content. (Not the author of the draft, and not the author of > Markdown, John Gruber.) Ah, that makes sense. Maybe "content author's intent" would be more obvious. [...] From nobody Fri Jul 10 22:36:41 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9131A6F15; Fri, 10 Jul 2015 22:36:37 -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 KWRX8uAH4rUE; Fri, 10 Jul 2015 22:36:35 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208D31A1BE0; Fri, 10 Jul 2015 22:36:35 -0700 (PDT) Received: by ykax123 with SMTP id x123so31406831yka.1; Fri, 10 Jul 2015 22:36:34 -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=/wMohm8nRw7Zde4D7t/zyjIFR54pMa9Rw4aP0KbEksc=; b=kaWimT96gdTqAygh4x/TTy2POgnNLq+yQTap4goei7fjohOtQaL2P3ZVY6qc12FQUa QZr2lTJLcohSfU2k5SnEt/jW0nSHUJI3ZRxk6YGCbkK6JZIOHNh7e/cZWEFOFvWrr5Sk 5fHcjqd4rQ8W02O6eNZ2Xd8JufLOP+lj0QZfnCWgNCYe7k+6EWzUg4EVAvhev0jSAtV5 zqaOAWPRmWaFbIUhZLfpv85YwIj7KKOIfFktMFfiBsShN3+T3WqobZe4r+xf6TDnzjP1 QAfar6H3PbaWO9N9uhKAUrM1IfnjdVCyz5pN5NQ4QC4L9GtlKHIWB9F5ozT34H3NKKpV Ic3Q== MIME-Version: 1.0 X-Received: by 10.13.194.198 with SMTP id e189mr26686937ywd.127.1436592994535; Fri, 10 Jul 2015 22:36:34 -0700 (PDT) Received: by 10.129.46.86 with HTTP; Fri, 10 Jul 2015 22:36:34 -0700 (PDT) In-Reply-To: <6475ED7E-017E-46CD-A1B9-2755AFC2F702@seantek.com> References: <20150708033129.16459.55993.idtracker@ietfa.amsl.com> <6475ED7E-017E-46CD-A1B9-2755AFC2F702@seantek.com> Date: Fri, 10 Jul 2015 22:36:34 -0700 Message-ID: From: "Murray S. Kucherawy" To: Sean Leonard Content-Type: multipart/alternative; boundary=001a114e7990205168051a92df42 Archived-At: Cc: "appsawg-chairs@ietf.org" , IETF Apps Discuss , "draft-ietf-appsawg-text-markdown-use-cases.shepherd@ietf.org" , "draft-ietf-appsawg-text-markdown-use-cases@ietf.org" , "draft-ietf-appsawg-text-markdown-use-cases.ad@ietf.org" , IESG , Barry Leiba , Terry Manderson Subject: Re: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jul 2015 05:36:37 -0000 --001a114e7990205168051a92df42 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How about "Registration of Markdown Variants"? On Fri, Jul 10, 2015 at 8:25 PM, Sean Leonard wrote: > Yes: the working group chose to split the document along those subject > matter lines. > > When I wrote the draft, I called it =E2=80=9Cuse-cases=E2=80=9D because i= t was as pithy a > way as any to summarize and condense the subject matter, namely (quoting > from the abstract): > Background information, > local storage strategies, and > additional syntax registrations [with examples] > > To my mind =E2=80=9Cuse cases=E2=80=9D meant: here are all of these reall= y interesting use > cases for Markdown (including =E2=80=9Ccases where Markdown is in use=E2= =80=9D), either > that motivated its creation, or that have cropped up since its creation. > Local storage strategies would be an example of a case where Markdown is = in > use in a broader system, and needs to be labeled in some systematic way. > > I suppose we could call it =E2=80=9CMarkdown in Action=E2=80=9D or =E2=80= =9CThe Many Uses of > Markdown=E2=80=9D but those are a bit overwrought IMO. > > Sean > > On Jul 8, 2015, at 5:47 PM, Terry Manderson > wrote: > > > Hi Barry, > > > > This is a fairly simple problem to fix. > > > > My anxiety was cased by the incorrect targeting of the document as a us= e > > cases. It isn't. Lets call it what it is. > > If it was to be a use case document. I think Murray has already propose= d > > to work with the authors on this and when I see that response I can cle= ar > > the discuss. > > > > As a side: normally I would say put the registrations with the prime > > document, however as you say, the working group chose to split the > > document and that is fine. > > > > Cheers > > Terry > > > > > > On 8/07/2015 10:30 pm, "Barry Leiba" wrote: > > > >> > >> This does not strike me as a 'use cases' document when you make IANA > >> requests to register identifiers with IANA. These seem more appropriat= e > >> in draft-ietf-appsawg-text-markdown-08. > >> > >> > >> > >> > >> I'm not sure why you think this is a problem -- maybe you can ekaborat= e > >> -- but the working group thought it best to split this up, defining th= e > >> media type and registry in one doc, and describing the variants and > >> making the registrations in another. > >> > >> > >> Barry > >> > > --001a114e7990205168051a92df42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How about "Registration of Markdown Variants"?

On Fri, J= ul 10, 2015 at 8:25 PM, Sean Leonard <dev+ietf@seantek.com> wrote:
Yes: the working group chose to= split the document along those subject matter lines.

When I wrote the draft, I called it =E2=80=9Cuse-cases=E2=80=9D because it = was as pithy a way as any to summarize and condense the subject matter, nam= ely (quoting from the abstract):
Background information,
local storage strategies, and
additional syntax registrations [with examples]

To my mind =E2=80=9Cuse cases=E2=80=9D meant: here are all of these really = interesting use cases for Markdown (including =E2=80=9Ccases where Markdown= is in use=E2=80=9D), either that motivated its creation, or that have crop= ped up since its creation. Local storage strategies would be an example of = a case where Markdown is in use in a broader system, and needs to be labele= d in some systematic way.

I suppose we could call it =E2=80=9CMarkdown in Action=E2=80=9D or =E2=80= =9CThe Many Uses of Markdown=E2=80=9D but those are a bit overwrought IMO.<= br>
Sean

On Jul 8, 2015, at 5:47 PM, Terry Manderson <terry.manderson@icann.org> wrote:

> Hi Barry,
>
> This is a fairly simple problem to fix.
>
> My anxiety was cased by the incorrect targeting of the document as a u= se
> cases. It isn't. Lets call it what it is.
> If it was to be a use case document. I think Murray has already propos= ed
> to work with the authors on this and when I see that response I can cl= ear
> the discuss.
>
> As a side: normally I would say put the registrations with the prime > document, however as you say, the working group chose to split the
> document and that is fine.
>
> Cheers
> Terry
>
>
> On 8/07/2015 10:30 pm, "Barry Leiba" <barryleiba@computer.org> wrote:
>
>>
>> This does not strike me as a 'use cases' document when you= make IANA
>> requests to register identifiers with IANA. These seem more approp= riate
>> in draft-ietf-appsawg-text-markdown-08.
>>
>>
>>
>>
>> I'm not sure why you think this is a problem -- maybe you can = ekaborate
>> -- but the working group thought it best to split this up, definin= g the
>> media type and registry in one doc, and describing the variants an= d
>> making the registrations in another.
>>
>>
>> Barry
>>


--001a114e7990205168051a92df42-- From nobody Sat Jul 11 08:20:34 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266221A8AD2; Sat, 11 Jul 2015 08:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNC5v_q5JeDm; Sat, 11 Jul 2015 08:20:32 -0700 (PDT) Received: from mail-vn0-x22e.google.com (mail-vn0-x22e.google.com [IPv6:2607:f8b0:400c:c0f::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 0A5D31A8AD1; Sat, 11 Jul 2015 08:20:32 -0700 (PDT) Received: by vnbg7 with SMTP id g7so40873631vnb.12; Sat, 11 Jul 2015 08:20:31 -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=MJlwEPqWw8r6MqXSncaV0CKin01PNE+3q4GSgydLglM=; b=gKLbO7VqkHPUr2rVB6ROcijKm+437naGSNktiN0+TxCQl7ZtRnq6+qaDDSb6A7xowH 78Q15rPEUhe/XXIf9RuOHY3qVm2HeaDj5NkmU4XI7dhCBWz4DW7SDq/JfjGJ62I7KOmG SQcIKuTpiJvLPZR8XPxwEernOZh1qw62vg2KKiPk+7+1IGRIfqnFJNoJfsihLQNNh5zT cOFRfqjuH3BqILBslcC7oBfp3oj9P5DSWnUiuVOCyk+2J0r8W3sKrDL/yWXA0FkN6BpL w+ARcX2q6JOIDpeZw5aVUwyQ4EVwLSjMixzkDoa3ztGZWVSIGGNmjS4+wv1Awpvuj2nE T+1Q== MIME-Version: 1.0 X-Received: by 10.52.71.203 with SMTP id x11mr23970090vdu.48.1436628031230; Sat, 11 Jul 2015 08:20:31 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Sat, 11 Jul 2015 08:20:31 -0700 (PDT) In-Reply-To: <8CD38C95-4B96-4E73-8833-4988332319E2@seantek.com> References: <20150709123547.10624.57521.idtracker@ietfa.amsl.com> <8CD38C95-4B96-4E73-8833-4988332319E2@seantek.com> Date: Sat, 11 Jul 2015 11:20:31 -0400 X-Google-Sender-Auth: 0M4mXoumnIlkDeb8sE5AskAonBw Message-ID: From: Barry Leiba To: Sean Leonard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ben Campbell , Apps Discuss , "appsawg-chairs@ietf.org" , draft-ietf-appsawg-text-markdown@ietf.org, The IESG Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-text-markdown-08: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 15:20:33 -0000 On one point in particular: >> - The 2119 terms in the para after Figure 1 are bogus, except >> for the last SHOULD (on p5). > > This was discussed with prior reviewers (I believe Barry Leiba): the > sentences were rephrased to have the 2119 terms (SHOULD, etc.) > be placed on implementations, rather than what users SHOULD be > able to do (i.e., user capabilities). It was discussed, and I left it for others to comment on. They have; Stephen and Ben both agree with me that this is wrong. My comment from the AD review, which you did not directly respond to, was this: --------------- In particular, I think Section 1.2 is entirely unnecessary. If you keep it, you'll absolutely have to take the 2119 "SHOULD"s out of it -- they're inappropriate use of 2119 key words. Incorrect use: "Users SHOULD have the option to do ." Correct use: "So that users have the option to do , implementations SHOULD ." --------------- The flavour of what Section 1.2 says is still very much on the incorrect side. I still think the section is entirely unnecessary for this document (the point here isn't to tell everyone what markdown is, which they can get from other sources; the point here is to explain enough to register the media type and to set up the variants registry). If you're going to keep this, please remove the 2119 language from that paragraph and re-word it as text that explains how to get the best results, and leave it at that. Barry From nobody Sat Jul 11 14:10:16 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746201ACD25; Sat, 11 Jul 2015 14:10:15 -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 74LJcE3B3V9h; Sat, 11 Jul 2015 14:10:13 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 68BA21A00EE; Sat, 11 Jul 2015 14:10:13 -0700 (PDT) Received: from [192.168.122.105] (unknown [72.199.176.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 77D3A509BB; Sat, 11 Jul 2015 17:10:08 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_4CEFA9F5-C5A6-4C4E-A3D8-0042C430A9E3"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <859C4C350741D890E64B4B73@JcK-HP8200.jck.com> Date: Sat, 11 Jul 2015 14:09:10 -0700 Message-Id: References: <20150706224353.15970.20875.idtracker@ietfa.amsl.com> <859C4C350741D890E64B4B73@JcK-HP8200.jck.com> To: John C Klensin X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.shepherd@ietf.org, draft-ietf-appsawg-text-markdown-use-cases@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.ad@ietf.org, The IESG , Benoit Claise Subject: Re: [apps-discuss] Benoit Claise's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 21:10:15 -0000 --Apple-Mail=_4CEFA9F5-C5A6-4C4E-A3D8-0042C430A9E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 10, 2015, at 9:18 PM, John C Klensin wrote: >=20 >=20 > --On Friday, July 10, 2015 20:45 -0700 Sean Leonard > wrote: >=20 >>> - There are a couple of [CITE] reference, including this one: >>> Character set interoperability is well-studied territory [NB: >>> CITE?] To be completed I guess. >>=20 >>=20 >> I propose that those [CITE] / [NB: CITE?] pieces simply be >> removed, since they are not that big of a deal. >=20 > Sean, >=20 > I'm not following these two documents in detail and don't intend > to, but the above statement (with or without citations) is, for > lack of a better word, offensive. It is almost like saying in > another context "While this specification requires a universal > solution to the PKI problem, that problem is well-studied > territory" or, if you are optimistic about that one, "Having > this work well depends on a solution to the halting problem, > which is well-studied territory". =20 >=20 > If you have a character set problem, or, as usually turns out to > be the case when people start talking about "character set > interoperability", an i18n problem, you really need to say > something specific (and probably provide references), not say > something that sounds like "it is a problem that others have > spent time on and therefore we can ignore=94. Okay, okay=85 The offending pieces are: {{ There are communities that are using Markdown for scholarly writing [CITE], for screenplays [FOUNTAIN], for mathematical formulae [CITE], and even for music annotation [CITE]. }} and: {{ Character set interoperability is well-studied territory [NB: CITE?] and so is not further covered here. }} Therefore, proposed changes are: {{ There are communities that are using Markdown for scholarly writing [OCCASION], for screenplays [FOUNTAIN], and even for mathematical formulae [MATHDOWN]. =85 [OCCASION] = http://blogs.law.harvard.edu/pamphlet/2014/08/29/switching-to-markdown-for= -scholarly-article-production/ [MATHDOWN] https://github.com/cben/mathdown/wiki/math-in-markdown }} (I searched for references for Markdown for musical notation, but was = not satisfied with the results, so I dropped that part of the sentence. = The references, of course, will be cleaned up when I insert them in the = draft.) {{ [RFC6657] provides guidance on character set parameter handling. }} Sean= --Apple-Mail=_4CEFA9F5-C5A6-4C4E-A3D8-0042C430A9E3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUwNzExMjExMDA4WjAjBgkqhkiG9w0BCQQxFgQUlcWMlD7X/y8kHNk8isZBrGSCc68wgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAIIrmFyOgBcd6mr8o6Ke2wz5b2QQZ0X6CSCMq97gNA1Cp7iNiP/H6nP1pcPr4ZhAndbD /GN9EdXHugHefCcsQLrGfYVa/enfFZ4UNWxBn2adyaKTQN+ooIpGrkoPKs17+t8pr7/OYrPwO3RK SIXQtYy+Tjb3Qm9c8L7eCMYR7CJ91KnRmEVopNNbmTkRl6ub2+S4T2/xq3oFlPS3Ei6w6eJ60mzA G7FCiheQELjxB4q6wvMuTDlLZUahCMTsxsFYwTkqpUz/tyjIPuSOYbyStQFwypWUeyPI2oPWxyCp rd2bFOA46trIMs3Gfrr6DjSd51QphtM3OjXPKBljeSYTSl8AAAAAAAA= --Apple-Mail=_4CEFA9F5-C5A6-4C4E-A3D8-0042C430A9E3-- From nobody Sun Jul 12 16:20:22 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7031A8F34; Sun, 12 Jul 2015 16:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNf9Wbk97jKH; Sun, 12 Jul 2015 16:20: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 AA3C21A8AD7; Sun, 12 Jul 2015 16:20:13 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZEQXb-000HrR-BT; Sun, 12 Jul 2015 19:20:11 -0400 Date: Sun, 12 Jul 2015 19:20:06 -0400 From: John C Klensin To: Sean Leonard , The IESG Message-ID: 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: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.shepherd@ietf.org, draft-ietf-appsawg-text-markdown-use-cases@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.ad@ietf.org, Benoit Claise Subject: [apps-discuss] Objection to processing draft-ietf-appsawg-text-markdown-* documents as WG drafts (was: Re: Benoit Claise's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS and COMMENT)) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2015 23:20:19 -0000 Hi. =20 With "normal" IETF WGs, we assume a very high level of internal WG review and resulting WG consensus (even if rough) before a draft goes into IETF Last Call. It is that assumption that justifies a two-week Last Call and maybe being relaxed about questions about whether or not a significant fraction of the community actually cares, etc. I don't have much experience with other area WGs, but there seems to be a tacit assumption in AppsAWG that, if a piece of work is worthwhile (in this case, getting Markdown well documents in an obvious place and reviewed through the IETF process) it is safe to assume that others who _really_ care will do the heavy lifting or, indeed, all of the lifting At least in retrospect, that didn't happen with this pair of documents. The kinds of problematic text (and a few actual errors) that are being found during and subsequent to IETF Last Call suggests strongly that the WG process failed to do an adequate review from several perspectives. It occurs to me that an IESG decision to initiate a Last Call is a decision that should be subject to appeal. I'm not going to do that in this case because I'm satisfied that diligent efforts by the IESG are turning up the issues that should have been caught and fixed earlier. However, I encourage the IESG (and document shepherds) to very carefully review the criteria that are being used to initiate IETF Last Calls on documents supposedly processed through (and carefully reviewed by) Area or other broad-focus WGs. =20 This might even be worth some discussion during the AppsAWG meeting on 20 July. More specifically, the issues raised by Beniot and Sean's response forced me into a quick read-through of these two documents for issues I care about and with which I'm familiar (e.g., Media Type definitions and character set and i18n issues and terminology). That reading strongly suggests that either no effective review occurred in AppsAWG or that it was inadequate enough to suggest that assigning these documents to that WG was inappropriate. I am not only concerned about the examples above and below; I am concerned that, if these issues have fallen through the cracks, there may be others in the two documents. For example, the first paragraph of Section 1.1 of draft-ietf-appsawg-text-markdown includes "a linear sequence of characters in some character set (code)". That just isn't acceptable terminology. Not only does it not conform to the recommendations of RFC 6365, but, in a slightly different environment, it would probably be read as meaning something entirely different from what was probably intended. That paragraph goes on to say "Because they are non-printing, these characters" (referring to "line breaks, page breaks, or other control characters) "are also hard to enter with standard keyboards." At least for European writing systems, that is plain silly unless one has a keyboard that lacks an "Enter" or "Return" function or is using a _very_ strange input method editor (IME). The next paragraph goes on to make a suggestion about "overload certain characters with additional meanings". At least for SGML (and its descendents), that is not the way what happens is described. I'd suggest it is even less true of LaTex, but YMMD. What might be intended is something like "certain characters or character sequences are treated as reserved delimiters, with the strings they delimit acting as processing, identification, or formatting directions". Continuing with this theme, the "charset" portion of Section 2 of draft-ietf-appsawg-text-markdown-06 says: "...will get along just fine by operating on character codes that lie in printable US-ASCII, blissfully oblivious to coded values outside of that range." I don't know what that means in spite of being regularly mistaken for an expert in the area. Given that you want to be CCS-independent (see RFC6365), I think the first part probably refers to "graphic characters in the ASCII repertoire", but I don't know what "blissfully oblivious..." is trying to tell me. Is it that each Markdown processor has, or assumes, a CCS and encoding and, if anything is encountered outside that range or is a non-graphic character in that range, it will be ignored? Noting that set of exclusions would ignore the character known as SP, I suggest that any such Markdown processor would be seriously broken. It is more likely that the sentence is wrong. In addition, the handwaving in the first paragraph of Security Considerations in Section 2 of draft-ietf-appsawg-text-markdown-06 is sufficient that an "Internationalization Considerations" section should be required in this document (see RFC 2277). As a final example, Content Disposition headers are orthogonal to Media Type. If draft-ietf-appsawg-text-markdown is about registration of a media type, as the title very strongly suggests and the abstract says explicitly, then Section 4 has no place in it. If it is intended as a general discussion of Markdown as it might be transmitted through systems that might use Content-Disposition headers, then the title and abstract need fixing and some language should be added to the Introduction that explains the scope of the document before it starts explaining the use and history of Markup/Down. It would be appropriate --and normal practice in the IETF and editorially-- for that actual introduction to also discuss the relationship between this document and draft-ietf-appsawg-text-markdown-use-cases. The comments below are about one specific set of examples of the above that follow up an exchange that has already occurred. These problems can be fixed, but they need, IMO, to be understood and taken seriously, not just responded to with a reference to something that might be relevant. I also suggest that this example demonstrates that the separation into two documents either was not wise or was not executed carefully enough. --On Saturday, July 11, 2015 14:09 -0700 Sean Leonard wrote: > On Jul 10, 2015, at 9:18 PM, John C Klensin > wrote: >... >> If you have a character set problem, or, as usually turns out >> to be the case when people start talking about "character set >> interoperability", an i18n problem, you really need to say >> something specific (and probably provide references), not say >> something that sounds like "it is a problem that others have >> spent time on and therefore we can ignore". >=20 > Okay, okay=E2=80=A6 >... > Therefore, proposed changes are: > {{ > There are communities that are using Markdown for > scholarly writing [OCCASION], for screenplays [FOUNTAIN], and > even for mathematical formulae [MATHDOWN]. Not in my area of competence (at least without careful study), but I assume ok. >... > {{ > [RFC6657] provides guidance on character set parameter > handling. }} This is more handwaving and is not helpful. I strongly suspect it doesn't belong here because it is either unnecssary or represents information without which draft-ietf-appsawg-text-markdown (aka [MDMTREG]) is not complete enough to conform to the letter and spirit of RFC 6838 (BCP 13). The information in draft-ietf-appsawg-text-markdown is, IMO, written in a confusing way and needs a detail or two, but it appears to be to be present. So, asking everyone's indulgence for commenting on both of these intertwined documents in the same note, a constructive suggestion in the spirit of "send text": (1) Drop the above sentence (and the reference) from draft-ietf-appsawg-text-markdown-use-cases. If you must say something in the "use cases" document, point back to MDMTREG and indicate that issues associated with charset parameters are discussed there. And say "charset" (in quotes if you think that is needed) and not "character set" because they do not mean the same thing and you are talking about the former (see elsewhere in this note). (2) In Section 2 of draft-ietf-appsawg-text-markdown, paragraph about "charset", add, probably after "no default value", "consistent with the requirements of RFC 6657 [RFC6657]". That should put the issue to rest. best, john From nobody Sun Jul 12 19:50:06 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8DD1ACD7C for ; Sun, 12 Jul 2015 19:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THsBQH5WQISo for ; Sun, 12 Jul 2015 19:50:03 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id BCEB31ACD7A for ; Sun, 12 Jul 2015 19:49:47 -0700 (PDT) Received: from CNNIC-PC (unknown [218.241.103.231]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0B5gZUyJ6NVUMCOBw--.5748S2; Mon, 13 Jul 2015 10:49:22 +0800 (CST) Date: Mon, 13 Jul 2015 10:49:14 +0800 From: "qinxiaowei@cnnic.cn" To: superuser , alexey.melnikov X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <2015071310491402733117@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart376318803555_=----" X-CM-TRANSID: AQAAf0B5gZUyJ6NVUMCOBw--.5748S2 X-Coremail-Antispam: 1UD129KBjvdXoWrtr4UZw4rGryfCF15CF4rZrb_yoWftrb_XF WUG3WUXw1DXFZ7Ga1UArWUJ34Ygr4vkw4UG34UXr47J34xZrZ7GFs3Jr48WryxWFyUtFn8 XFy3Xry7Ar4UXjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbpkFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8w A2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr0_ Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwVC2z280aVCY1x0267AKxVWxJr 0_GcWle2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG62kEwI0EY4vaYxAvb48xMc02F40E x7xS67I2xxkvbII20VAFz48EcVAYj21lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2js IE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACjI8F5VA0 II8E6IAqYI8I648v4I1lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07Mx 8GjcxK6IxK0xIIj40E5I8CrwCY1x0264kExVAvwVAq07x20xylc2xSY4AK67AK6r4UMxAI w28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_Jr Wlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxG rwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8Jw CI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY 6I8E87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa 7VUUOJ55UUUUU== X-CM-SenderInfo: xtlq5x5drzvxw6fq0xffof0/ Archived-At: Cc: apps-discuss Subject: Re: [apps-discuss] Preliminary IETF 93 APPSAWG/ARTAREA agenda posted X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jul 2015 02:50:05 -0000 This is a multi-part message in MIME format. ------=_001_NextPart376318803555_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBNdXJyYXkgJiBBbGV4ZXksIA0KSSdtIHZlcnkgc29ycnkgdGhhdCBpdCB3YXMgYSBib3Ro ZXIgZm9yIHlvdSB0byBkbyB0aGlzLiANCkJlY2F1c2Ugb2YgdGhlIGFpcnBsYW5lIGNvbXBhbnks dGhlIG9yaWdpbmFsIHBsYW4gZmxhdCB0byBQcmFndWUgYXQgU3VuZGF5LCBKdWx5IDE5LCAyMDE1 IChDRVNUKSBjaGFuZ2VzIHRvIDk6MDAsIE1vbmRheSBNb3JuaW5nLCBKdWx5IDIwLCAyMDE1IChD RVNUKSwgSSB3aWxsIGFycml2ZSBhdCB0aGUgbWVldGluZyBoYWxsIGFib3V0IGF0IDExOjAwLCBN b25kYXkgTW9ybmluZywgSnVseSAyMCwgMjAxNSAoQ0VTVCkuIFRoZXJlZm9yZSBJIHdvdWxkIGxp a2UgdG8gY2hhbmdlIG15IHRpbWUgc2xvdCB0byB0aGUgbGFzdCB0byBtYWtlIHN1cmUgdGhhdCBp IGNhbiBjYXRjaCB1cCB0aGUgbWVldGluZy4NCkNvdWxkIHlvdSBoZWxwIG1lIHRvIGRvIHRoYXQ/ IA0KDQpUaGUgZm9sbG93aW5nIGlzIHRoZSBvcmlnaW5hbKO6IA0KT3BlbiBNaWMgYW5kIEFueSBP dGhlciBCdXNpbmVzcyAodmFyaW91czsgYWxsIHJlbWFpbmluZyB0aW1lKSANCi0gVXBsb2FkIEFj Y2VsZXJhdGlvbiBUcmFuc3BvcnQgTmV0d29yayAoWGlhb3dlaSBRaW47IDEwIG1pbnMpIA0KLSBN YWlsIERpdmlkZSBGcmFtZXdvcmsgKEthb3J1IE1hZWRhOyA1IG1pbnMpIA0KLSBQZXJzb25hbCBD bG91ZCBTdG9yYWdlIFN5bmNocm9uaXphdGlvbiBTeXN0ZW0gKExpbmh1aSBTdW47IDE1IG1pbnMp DQoNCkkgd291bGQgbGlrZSBjaGFuZ2UgdG86DQpPcGVuIE1pYyBhbmQgQW55IE90aGVyIEJ1c2lu ZXNzICh2YXJpb3VzOyBhbGwgcmVtYWluaW5nIHRpbWUpIA0KLSBNYWlsIERpdmlkZSBGcmFtZXdv cmsgKEthb3J1IE1hZWRhOyA1IG1pbnMpIA0KLSBQZXJzb25hbCBDbG91ZCBTdG9yYWdlIFN5bmNo cm9uaXphdGlvbiBTeXN0ZW0gKExpbmh1aSBTdW47IDE1IG1pbnMpDQotIFVwbG9hZCBBY2NlbGVy YXRpb24gVHJhbnNwb3J0IE5ldHdvcmsgKFhpYW93ZWkgUWluOyAxMCBtaW5zKSANCg0KVGhhbmtz IGFnYWluLg0KUmVnYXJkcw0KWGlhb3dlaSBRaW4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KQ29sbGVhZ3VlcywKVGhlIHByZWxpbWluYXJ5IEFQUFNBV0cvQVJUQVJF QSBhZ2VuZGEgZm9yIHRoZSBQcmFndWUgbWVldGluZyBoYXMgYmVlbgpwb3N0ZWQ6Cmh0dHBzOi8v d3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkzL2FnZW5kYS9hZ2VuZGEtOTMtYXBwc2F3ZwpQbGVh c2UgY29udGFjdCBhcHBzYXdnLWNoYWlyc0BpZXRmLm9yZyB3aXRoIGFueSBxdWVzdGlvbnMsIGNv bW1lbnQsCnJlcXVlc3RzLCBldGMuCi1NU0ssIEFQUFNBV0cgY28tY2hhaXINCg== ------=_001_NextPart376318803555_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable Dear Murray & Alexey,=0A
I'm very sorry that it was a bother for y= ou to do this.=0A
Because of the airplane company,the original plan fla= t to Prague at Sunday, July 19, 2015 (CEST) changes to 9:00, Monday Mornin= g, July 20, 2015 (CEST), I will arrive at the meeting hall about at 11:00,= Monday Morning, July 20, 2015 (CEST). Therefore I would like to change my= time slot to the last to make sure that i can catch up the meeting.
Could you help m= e to do that?=0A

The following&= nbsp;is the original=A3=BA 
Op= en Mic and Any Other Business (various; all remaining time) 
- = Upload Acceleration Transport Network (Xiaowei Qin; 10 mins) 
= - Mail Divide Framework (Kaoru Maeda; 5 mins) 
- Personal Cloud St= orage Synchronization System (Linhui Sun; 15 mins)

I would like change to:
Open Mic and Any Other Bus= iness (various; all remaining time) 
- Mail Divide Framework (Kaor= u Maeda; 5 mins) 
- Personal Cloud Storage Synchronization System = (Linhui Sun; 15 mins)
- Upload Acceleration Transport Network= (Xiaowei Qin; 10 mins) 

Thanks again.
Regards
Xiaowei Qin

---------------------------------------------------= -------------------------------------------
Colleagues,=0AThe preliminary APPSAWG/ARTAREA agenda =
for the Prague meeting has been=0Aposted:=0Ahttps://www.ietf.org/proceedin=
gs/93/agenda/agenda-93-appsawg=0APlease contact appsawg-chairs@ietf.org wi=
th any questions, comment,=0Arequests, etc.=0A-MSK, APPSAWG co-chair
=
------=_001_NextPart376318803555_=------ From nobody Sun Jul 12 21:43:47 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375C01A90C8; Sun, 12 Jul 2015 21:43: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 ribBt8TxrmNd; Sun, 12 Jul 2015 21:43:45 -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 29A2E1A903E; Sun, 12 Jul 2015 21:43:45 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t6D4hUmj031862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 12 Jul 2015 21:43:35 -0700 Message-ID: <55A341EE.8000904@dcrocker.net> Date: Sun, 12 Jul 2015 21:43:26 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: John C Klensin , The IESG References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 12 Jul 2015 21:43:44 -0700 (PDT) Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Objection to processing draft-ietf-appsawg-text-markdown-* documents as WG drafts (was: Re: Benoit Claise's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS and COMMENT)) 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, 13 Jul 2015 04:43:46 -0000 On 7/12/2015 4:20 PM, John C Klensin wrote: > The kinds of problematic text (and a few actual > errors) that are being found during and subsequent to IETF Last > Call suggests strongly that the WG process failed to do an > adequate review from several perspectives. John, I'm confused. You appear to be saying that it is exceptional for a working group process to turn out documents for IESG processing that are seriously flawed. In contrast I believe it is a periodic occurrence across all areas and all working groups, and arguably always has been. While crappy drafts really are problematic, I do not understand what was supposedly exceptional in the AppsArea wg process that distinguishes it from various other working groups around the IETF over the years, including these days. In any event, absent very specific citations from you, that point to actions that need to have been done differently, there is no way to know what problems to correct, or requirements to impose, for this wg or any other. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jul 12 22:04:05 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBFC1A896C; Sat, 11 Jul 2015 07:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[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 aubx3gaVZR1o; Sat, 11 Jul 2015 07:07: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 762BF1A896B; Sat, 11 Jul 2015 07:07:19 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t6BDWFSH012621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 11 Jul 2015 06:32:18 -0700 Message-ID: <55A11ADE.1030204@dcrocker.net> Date: Sat, 11 Jul 2015 06:32:14 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Sean Leonard References: <20150708033129.16459.55993.idtracker@ietfa.amsl.com> <6475ED7E-017E-46CD-A1B9-2755AFC2F702@seantek.com> 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]); Sat, 11 Jul 2015 06:32:19 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Sun, 12 Jul 2015 22:04:04 -0700 Cc: "appsawg-chairs@ietf.org" , IETF Apps Discuss , "draft-ietf-appsawg-text-markdown-use-cases.shepherd@ietf.org" , "draft-ietf-appsawg-text-markdown-use-cases@ietf.org" , "draft-ietf-appsawg-text-markdown-use-cases.ad@ietf.org" , IESG , Barry Leiba , Terry Manderson Subject: Re: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS) 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: Sat, 11 Jul 2015 14:07:20 -0000 On 7/10/2015 10:36 PM, Murray S. Kucherawy wrote: > How about "Registration of Markdown Variants"? This might be overly fussy, but I suggest: Registration of Text Markdown Variants Markup is a term used for all sorts of data. Even though "markdown" is more distinctive than "markup" the explicit qualifier was avoid any other possible uses of markdown for other types of data. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jul 12 22:04:07 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13411ACC88; Sat, 11 Jul 2015 13:48:47 -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 yRz9dUmXJN-w; Sat, 11 Jul 2015 13:48:46 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 5E8441ACC81; Sat, 11 Jul 2015 13:48:46 -0700 (PDT) Received: from [192.168.122.105] (unknown [72.199.176.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0A1C9509BD; Sat, 11 Jul 2015 16:48:41 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_958405E0-6D4A-4138-941E-535A9A9EFD24"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <55A11ADE.1030204@dcrocker.net> Date: Sat, 11 Jul 2015 13:47:51 -0700 Message-Id: <8DC2EA7C-19BC-4B01-A99F-818345AA24C3@seantek.com> References: <20150708033129.16459.55993.idtracker@ietfa.amsl.com> <6475ED7E-017E-46CD-A1B9-2755AFC2F702@seantek.com> <55A11ADE.1030204@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Sun, 12 Jul 2015 22:04:04 -0700 Cc: "appsawg-chairs@ietf.org" , IETF Apps Discuss , "draft-ietf-appsawg-text-markdown-use-cases.shepherd@ietf.org" , "draft-ietf-appsawg-text-markdown-use-cases@ietf.org" , "draft-ietf-appsawg-text-markdown-use-cases.ad@ietf.org" , IESG , Barry Leiba , Terry Manderson Subject: Re: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jul 2015 20:48:48 -0000 --Apple-Mail=_958405E0-6D4A-4138-941E-535A9A9EFD24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 11, 2015, at 6:32 AM, Dave Crocker wrote: > On 7/10/2015 10:36 PM, Murray S. Kucherawy wrote: >> How about "Registration of Markdown Variants"? >=20 > This might be overly fussy, but I suggest: >=20 > Registration of Text Markdown Variants >=20 > Markup is a term used for all sorts of data. Even though "markdown" = is > more distinctive than "markup" the explicit qualifier was avoid any > other possible uses of markdown for other types of data. I am pretty sure that =93Markdown=94 (capitalized) is pretty commonly = understood as this technology area, and not lightweight markup languages = in general. Of course, being in a title, the true capitalization state = is ambiguous. Therefore I would say -1 to that, and +1 to Registration = of Markdown Variants. However I must also say -1 to Registration of Markdown Variants because = the document does a lot more than the registration of certain variants. = First of all =93Registration of Markdown Variants=94 can be interpreted = to refer to the *process* of how to register variants, which is covered = by the text-markdown draft (Section 6 IANA Considerations). Really it = should be =93Registrations of Markdown Variants=94 since we are talking = about several specific registrations (plural noun). But even then, we = are not registering all known Markdown variants, just those that are = interesting enough to warrant further comment as guidance for other = people who want to register other variants. So, it is more like = =93Registrations of Certain Exemplary Markdown Variants=94. I still think =93text/markdown Use Cases=94 is not so bad... Sean= --Apple-Mail=_958405E0-6D4A-4138-941E-535A9A9EFD24 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUwNzExMjA0ODQwWjAjBgkqhkiG9w0BCQQxFgQUKSaipinN71/ebmal6dmmreD/vikwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAIyFm6xHffUEdUcDLGgrYHoWGglv9qWMLYbvIty1ufLqbtJoj2EG/0iDaqgw+J4YO/yI 1eiDymtLwFtErn1Lp8MtpYXoxbb/tG11TS54ndFBfUM32WsE37MZKa8xYw2jcqlO3zFl5FSmTnUp g1nezHyLRgprO9PSU9K2yXbyAevR/S3SW9j8Q8TLsSmD23R2ZiYXW9K7xd1T/cs+Bf2QPg+vt59z UUf7C01qjsJpNBYetgECos4nDG4DMyefCKdprkthZXikckgbVUNfvFQXhGluCWPSnKh0r0jxGl3N 6grYjy3EsEk9NT4UYRUNcRGwAfMVsfdAAh9lCUYdjaqAiWoAAAAAAAA= --Apple-Mail=_958405E0-6D4A-4138-941E-535A9A9EFD24-- From nobody Sun Jul 12 22:04:08 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063821ACD7D; Sat, 11 Jul 2015 15:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOAGGbfb7K5g; Sat, 11 Jul 2015 15:06:59 -0700 (PDT) Received: from mail-vn0-x235.google.com (mail-vn0-x235.google.com [IPv6:2607:f8b0:400c:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D401ACD7C; Sat, 11 Jul 2015 15:06:58 -0700 (PDT) Received: by vnbf62 with SMTP id f62so41328244vnb.9; Sat, 11 Jul 2015 15:06:58 -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:content-transfer-encoding; bh=fIX37lBcofcvQT4d3funaTbJBzD+mMLx1l5lpYx16jA=; b=tO4kLX2LjXFvUKTPG0idp0SdYacQ3Urbh+MtxhXcDHDO45CkXIt1zaul+DcmNKbuB8 r5Op3Qyv10wG4uMd6YiHEZFPvFko87jLpquycDLQbnvlW/QCrJlB1rPW8qv1KjNeNAAX VToYH0W5Jy1PUT2cbpW4cR+DVaLLPmYq+6yrKP6S8Jz6Muz8N/nVDnGxMQHMFWhBr20w chSyX8lnPmJWPv+hpjID1mKLwlPrP2hVLtyL9XFQb8Sw9UDt3+HCHMbQ7ZKJBpxEelJe NgfdK0cyf/qYbZEUUMI7wAg5Ov8LTyUOdDndd45Wla/ryvMb/pTjsq1CvvbJs+typ4V4 knMg== MIME-Version: 1.0 X-Received: by 10.52.100.167 with SMTP id ez7mr400213vdb.80.1436652417997; Sat, 11 Jul 2015 15:06:57 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Sat, 11 Jul 2015 15:06:57 -0700 (PDT) In-Reply-To: <8DC2EA7C-19BC-4B01-A99F-818345AA24C3@seantek.com> References: <20150708033129.16459.55993.idtracker@ietfa.amsl.com> <6475ED7E-017E-46CD-A1B9-2755AFC2F702@seantek.com> <55A11ADE.1030204@dcrocker.net> <8DC2EA7C-19BC-4B01-A99F-818345AA24C3@seantek.com> Date: Sat, 11 Jul 2015 18:06:57 -0400 X-Google-Sender-Auth: zOI-mul712ieKMekYWq5OSh0g8Y Message-ID: From: Barry Leiba To: Sean Leonard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Sun, 12 Jul 2015 22:04:04 -0700 Cc: "appsawg-chairs@ietf.org" , IETF Apps Discuss , "draft-ietf-appsawg-text-markdown-use-cases.shepherd@ietf.org" , "draft-ietf-appsawg-text-markdown-use-cases@ietf.org" , "draft-ietf-appsawg-text-markdown-use-cases.ad@ietf.org" , Dave Crocker , Terry Manderson , IESG Subject: Re: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jul 2015 22:07:00 -0000 > However I must also say -1 to Registration of Markdown Variants > because the document does a lot more than the registration of certain > variants. Yeh, I don't think it does, unless you want to say "Description and Registration ...". And if you want to explain in the Abstract and Introduction what else you're aiming at, that's fine. > First of all =E2=80=9CRegistration of Markdown Variants=E2=80=9D can be > interpreted to refer to the *process* of how to register variants Really, I can't imagine that anyone would read it that way. > Really it should be =E2=80=9CRegistrations of Markdown > Variants=E2=80=9D since we are talking about several specific registratio= ns > (plural noun). Yes, or "Registration", collective noun; using the plural reads oddly to me. And I don't see that either one eliminates the possible (but, I think, unlikely) confusion you state above. > But even then, we are not registering all known Markdown variants So? I don't think anyone would expect that we are. I don't think that mat= ters. > So, it is more like =E2=80=9CRegistrations of Certain > Exemplary Markdown Variants=E2=80=9D. I don't think I'd say "Exemplary"; I might say "Registration of Some Markdown Variants", perhaps. But if you want to go in this direction, I have no objection. > I still think =E2=80=9Ctext/markdown Use Cases=E2=80=9D is not so bad... You're quite in the rough on this, I think; we have several comments about "use cases" being the wrong title, and I agree with them (though I wouldn't have worried about it). I do think we need to change it. Barry From nobody Mon Jul 13 00:48:58 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73091AD241; Mon, 13 Jul 2015 00:48:56 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2srHwbSMtuOB; Mon, 13 Jul 2015 00:48:54 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0139.outbound.protection.outlook.com [104.47.126.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17211AD23D; Mon, 13 Jul 2015 00:48:53 -0700 (PDT) Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none; Received: from [133.2.210.64] (133.2.210.64) by KAWPR01MB0131.jpnprd01.prod.outlook.com (10.161.27.12) with Microsoft SMTP Server (TLS) id 15.1.213.14; Mon, 13 Jul 2015 07:48:48 +0000 To: John C Klensin , Sean Leonard , The IESG References: From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <55A36D59.1010101@it.aoyama.ac.jp> Date: Mon, 13 Jul 2015 16:48:41 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR0201CA0009.apcprd02.prod.outlook.com (25.164.90.147) To KAWPR01MB0131.jpnprd01.prod.outlook.com (25.161.27.12) X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0131; 2:FBUwK3bhUVEkvu7dZpgPd2BqEnCUjzB6L3v0qxiwm9S3K7Sz8zJQx4/Q4TdTlbUr; 3:C2Q/GzKLU3m+M84ybvFZya03hmKOzOjbIt8g3WjardT69f5G2F+cy9yv3lX9wzLarYOQCF8biS6vO2/f3pmXcIVXl31lXsXvNeCbdfmwSEM7HF+/W8ZrOn1b1rDnb1qv0kp26UZ86e+mBYupmI0ajw==; 25:JfvXkrTfDXEQG+oGuDaIyZMdpXqVCVGrF0mQHbatwQrnJyyMJNW8mK95wuRoiVXHFb86B9NIywKFwSa5CK9gHdomHNdWA5G6OsTREUYC1HMsYhAZXaRzXm3fRB+hucCn5Uln02yydTsku0M7ZY2cbSkVCvP6TO4OX4vTfn0CC8hDz4tZ1kDUtZtbciIe7bRBsUHwqkVHhuHKmt/alNfF4Cw2cbEAJ29tEUTwbFbNINUUCCEOX3xOmNzpVM3dmbs2L3QAq93kC1Gq5L3oeMjUug==; 4:Qm8qHBLCXYs4pYaN4unhT+mzxOZmP1FKVlu/7NVsHyMGXx/Ukd3O/yB7WNOuJWu8q6re6HeHhGx1YzOGt6j7ovf0rwfvolzYBal1ezEaCeQE4WoKZo09keIzQKy6pL0o68024rlDBDbWfdmARXkltQrJq39sAyb2NKsjVtsV1OM8fqrjbsrofnomdONfG6RLniuwaoX41r1jY724n6bkBBnM51K1rWeSNSdUqex/+L62z5IGjEUB2tWcZbXRAUlmS9rs6UKTDBG3DupgLdmlRA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:KAWPR01MB0131; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5005006)(3002001); SRVR:KAWPR01MB0131; BCL:0; PCL:0; RULEID:; SRVR:KAWPR01MB0131; X-Forefront-PRVS: 0636271852 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(479174004)(24454002)(51704005)(66066001)(50466002)(230783001)(23676002)(46102003)(74482002)(33656002)(62966003)(47776003)(5001770100001)(92566002)(77096005)(122386002)(65956001)(189998001)(50986999)(86362001)(76176999)(2950100001)(77156002)(40100003)(5001960100002)(54356999)(87266999)(65816999)(87976001)(42186005)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:KAWPR01MB0131; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0131; 23:MMGNMiQsresk3j8HHamvXQetvdRTxZ6ILk33MxH4AzU/lV7cLT3DkkSjkjua6eeOBvAXiSqMFIOA2wW3PydWGMSTlcS10Cf95YU09FOV0N6srVtdtOIfKo5GRjQ3Xvh3asuenOAFNHAUrM1q0zwJbIMAbjs7MpSBCmfZIJtwsSNrPAhe9R0gw3B1PvVkCDMdWaPC1auTF+bYzefOlRslwFUH0UxNtkE/1eckFSPTOwnIh7L2YQhcSo5BD1ADZ04P0VBxoBtNLVebltWr6e6WsbRoi49fv8qh8EUsYSbn6JSEjXHIvdhX2IM+uritiyHuuU0NZkQFIYc8LReuxGHC1rHwvxrE6ABrZq2jOQeC2h+qHlPo3jle90CqhSAhEQSoTDEJx4BvtRuQjYotbHFPOQdorx3x2CotQyGv/BZOC0+0pOYXLXrFG3GMyBW5PutMZF9am/RNNskq7xJqRmG547pBSFwBywvVBFIySZJVJF7VZSHYVlMYUfem79JsMU7pWekUMDSabdTCbAPTm2HsSkPPLvVhcc/fXMPRLDm/Pcyig7WyJ4iWwwd6pY6JhS6HLBj+N697RZI36WxIF6lURzWDoyoHQEr0KkJIu08mhK4WKhvjGqDYa7ygxOoOfMB3I4zWdAGVr5JRN2xl5B2QS2enJ2zKYNTjKWOEAUHMwTtMqgxUotbCn24y5nbZ5Zbm3QnslN9Ssvxa9Iofs1wVpS7rgWMGf+yJVJIgjaaOcqopc0mnoYxiOvfSR1SnCFbEuKacEy9oFWIXMzIze15VcgMvD931ugzXNunEQqCiWYVf4H/A/U9oY4a82HH5BNrc8k1Sof7FtXcFgJHc5FCnQvUeu/UnZF2laMy1bxQG+n7uc3XiVITdk6xNsHpoXkjy X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0131; 5:pUx2Y3VIHW9FTD+H9sbyp8XbPYk2ZWSbR7tgE3Kbj4pR6ImCFaNJEMiA/deZ2RovAZ9xBSsES/n4y9dwoVhRTzBbzOEFOVJjDs48isI+HEdAsc+ZqN7njJpDnTrswFO3hYIKyKhjTSRZ8KM68g/bDw==; 24:hDP/9MW5BmvjVk0u9UMJ8UTj4NNtopyVrbzXzc8iptnao+Wron8K2Cs6B5MiVc2/FcpEFeUxJL8z4AOhy5v42RU6Ur6llglPWrqHy0dhWB0=; 20:mROGVlz1YfnaIUnsyhTasvcKapub469Ldq8YhsBvbjLpo2UC9u7ZEwPkz0VVigAJtkLixU+Q9k+zTSYXIADycw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jul 2015 07:48:48.1437 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: KAWPR01MB0131 Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.shepherd@ietf.org, draft-ietf-appsawg-text-markdown-use-cases@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.ad@ietf.org, Benoit Claise Subject: Re: [apps-discuss] Objection to processing draft-ietf-appsawg-text-markdown-* documents as WG drafts (was: Re: Benoit Claise's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS and COMMENT)) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 07:48:56 -0000 On 2015/07/13 08:20, John C Klensin wrote: > For example, the first paragraph of Section 1.1 of > draft-ietf-appsawg-text-markdown includes "a linear sequence of > characters in some character set (code)". That just isn't > acceptable terminology. Not only does it not conform to the > recommendations of RFC 6365, but, in a slightly different > environment, it would probably be read as meaning something > entirely different from what was probably intended. Agreed. "Character set" as used in RFC 2046 is not a term we want to use in 2015. > That > paragraph goes on to say "Because they are non-printing, these > characters" (referring to "line breaks, page breaks, or other > control characters) "are also hard to enter with standard > keyboards." At least for European writing systems, that is > plain silly unless one has a keyboard that lacks an "Enter" or > "Return" function or is using a _very_ strange input method > editor (IME). For line breaks, I'd argue that they are very easy to enter on pretty much any keyboard, because pretty much any keyboard has an Enter key (and because pretty much every modern language has line- or paragraph breaks). For page breaks and other control characters, I'd argue that they are difficult to enter with the average keyboard, in any language. So just remove "line breaks", and the problem should be fixed. > The next paragraph goes on to make a suggestion > about "overload certain characters with additional meanings". At > least for SGML (and its descendents), that is not the way what > happens is described. I'd suggest it is even less true of > LaTex, but YMMD. What might be intended is something like > "certain characters or character sequences are treated as > reserved delimiters, with the strings they delimit acting as > processing, identification, or formatting directions". I'd agree that this isn't how SGML or LaTeX would describe it, but it's not actually in any way wrong. In XML, depending on context, '>' means itself or "close tag" (or any of a few more obscure meanings). We are still in the introduction, after all. > Continuing with this theme, the "charset" portion of Section 2 > of draft-ietf-appsawg-text-markdown-06 says: > > "...will get along just fine by operating on character > codes that lie in printable US-ASCII, blissfully > oblivious to coded values outside of that range." > > I don't know what that means in spite of being regularly > mistaken for an expert in the area. Given that you want to be > CCS-independent (see RFC6365), I think the first part probably > refers to "graphic characters in the ASCII repertoire", but I > don't know what "blissfully oblivious..." is trying to tell me. > Is it that each Markdown processor has, or assumes, a CCS and > encoding and, if anything is encountered outside that range or > is a non-graphic character in that range, it will be ignored? > Noting that set of exclusions would ignore the character known > as SP, I suggest that any such Markdown processor would be > seriously broken. It is more likely that the sentence is wrong. I know what the sentence tries to refer to. It refers to the fact that, as long as the syntax you are looking at only uses 7-bit bytes values with ASCII semantics (including the usual control characters and space), a processor will work for a wide range of character encodings. The problem is that this applies to some encodings, but not to others. The criterion is a certain kind of strong ASCII-compatibility, namely that characters in the ASCII range (including C0) are always represented directly as 7-bit bytes, and that these 7-bit bytes always represent the corresponding characters and nothing else. Encodings that qualify are of course US-ASCII itself, straightforward 8-bit encodings starting with iso-8859-1 and including vendor encodings (Windows, Mac,...), some multibyte encodings such as GB2312 and EUC-JP, and UTF-8 (but beware of the BOM). However, it does not include some other encodings, in particular not iso-2022-jp, Shift_JIS, GBK, or GB18030, and of course not UTF-(16|32)(LE|BE). So the text should definitely be more careful here. Regards, Martin. From nobody Mon Jul 13 10:42:36 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C267E1B2CC6; Mon, 13 Jul 2015 10:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7oer3_LJmpG; Mon, 13 Jul 2015 10:42:30 -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 773DB1B2CC4; Mon, 13 Jul 2015 10:42:30 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZEhkK-000Jj7-Fr; Mon, 13 Jul 2015 13:42:28 -0400 Date: Mon, 13 Jul 2015 13:42:23 -0400 From: John C Klensin To: dcrocker@bbiw.net, The IESG Message-ID: <8A479E99713CFAABC4DE3200@JcK-HP8200.jck.com> In-Reply-To: <55A341EE.8000904@dcrocker.net> References: <55A341EE.8000904@dcrocker.net> 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: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Objection to processing draft-ietf-appsawg-text-markdown-* documents as WG drafts (was: Re: Benoit Claise's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS and COMMENT)) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 17:42:34 -0000 --On Sunday, July 12, 2015 21:43 -0700 Dave Crocker wrote: > On 7/12/2015 4:20 PM, John C Klensin wrote: >> The kinds of problematic text (and a few actual >> errors) that are being found during and subsequent to IETF >> Last Call suggests strongly that the WG process failed to do >> an adequate review from several perspectives. > > > John, > > I'm confused. You appear to be saying that it is exceptional > for a working group process to turn out documents for IESG > processing that are seriously flawed. In contrast I believe > it is a periodic occurrence across all areas and all working > groups, and arguably always has been. Dave, While I agree that there are periodic occurrences of seriously flawed documents that are independent of any particular procedural framework, I think there is a difference that is worth noting. I also wouldn't describe the text-markdown documents as "seriously flawed" or even "crappy", just poorly written and apparently unaware of some issues and established terminology that overlaps them. To be a little more specific, I'm unconvinced that there is anything wrong with the two of them that could not be straightened out by a pass or two from a good technical editor who understood the area of application. However, we've been told that we cannot expect that level of editing from the RFC Editor, which means that, if the author doesn't do it, someone else should notice the problem and do something about it, with relying on editing by the IESG post-Last-Call being a particularly unfortunate approach. I don't think that issue is unique to any particular type of WG or other structure either. > While crappy drafts really are problematic, I do not > understand what was supposedly exceptional in the AppsArea wg > process that distinguishes it from various other working > groups around the IETF over the years, including these days. With the understanding that there are "in between" cases, consider two scenarios: (1) We have a relatively classic-style IETF WG, chartered for a very specific topic and limited number of documents and typically expected to terminate when those are done. (2) We have a WG with a charter for "catch-all" work that may extend over a rather wide range of topics, with topics and documents being added to the workload by consensus (or, more often, especially if the WG leadership likes the proposals, absence of consensus objections). Now, as you point out, neither of those scenarios provides perfect protection about poor review, "crappy" drafts, or even technically-defective work (I believe the current work _not_ technically defective). However, under the first scenario, there are strong assumptions that everyone who is participating in the work is, indeed, participating. Those who get involved typically are relatively expert in the WG's topic area or at least care enough to become informed (or should). Mailing lists tend to be less noisy than the second case if only because the range of topics is narrower. Documents either get reviewed or engaged and alert WG Chairs engage in a good deal of exhortation and shepherds have some obligation to report to the IESG when there is an appearance of inadequate or indifferent reviews. Certainly, it doesn't always work, especially in "victory by attrition" cases, but the odds are in its favor. On the other hand, when one has a WG with a charter that is both very broad in terms of topics and presumes it will stay alive for a long time, adding new topics as it goes along, very few people "in the WG" are going to be expert on, or care about, every topic. While some people may try to carefully review every document that shows up, at least at WG LC, reactions similar to "glad someone is doing that, but not my problem or area of expertise" are almost certain (and, IMO, common and expected). So I think there really is a difference, at least in risk and expectations,... and that it does not require a catalog of "crappy drafts" to prove it. At the same time, I think that one of the remedies for the "crappy draft" problem would be for the IESG to be a lot more willing, when it becomes clear that a draft needs significantly more review and/or work, to bounce it back to the originator or originating WG and say "this is not of acceptable quality, take it back to the virtual drawing board and, when you resubmit its successor, be prepared to explain how something reached us in this state". I think it should be reasonable to do that as soon as "not of acceptable quality" (perhaps the same as what you mean by "crappy") is clear, whether that is before IETF LC, during it, or after LC is nominally completed. That suggestion is not specific to any particular WG organization model or even to the difference between WG and individual submissions but it seems to me that the IESG's trying to fix such documents after Last Call is not only a bad idea generally but reinforces bad behavior. Lest I be accused of being value, consider the difference in incentives for someone deciding to hand a draft off for Last Call between: (i) "I think maybe this is good enough to get by and, if it isn't, the IESG will fix it and it will get published". and (ii) "I think maybe this is good enough but, if I'm wrong and the IESG bounces it, it will result in loss of a lot more time and possibly reassignment of individual submissions to a WG or aggregate/area WG documents to a short-lived, document specific WG", losing even more time". Faced with the strategy suggested above, I suggest that many more authors, shepherds, and WG Chairs would adopt the second line of thinking and try to put a little more energy into being sure the document really is ready. I think that would be A Good Thing. YMMD. john best, john From nobody Mon Jul 13 14:24:02 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DB21A0055; Mon, 13 Jul 2015 14:23:57 -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 r80x_STn_kPM; Mon, 13 Jul 2015 14:23:54 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 751071A004E; Mon, 13 Jul 2015 14:23:54 -0700 (PDT) Received: from smize.t-mobile.com (unknown [162.248.119.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 082E5509C0; Mon, 13 Jul 2015 17:23:36 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_08B047B4-449F-4FDC-BFBF-5D36F0EC5D1E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: Date: Mon, 13 Jul 2015 14:22:58 -0700 Message-Id: <5D2E6DCF-6AFE-44EA-B367-DE30DDAC7CEF@seantek.com> References: To: Paul Wouters X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: secdir@ietf.org, The IESG , IETF Apps Discuss , draft-ietf-appsawg-text-markdown-use-cases.all@tools.ietf.org Subject: Re: [apps-discuss] Secdir review of draft-ietf-appsawg-text-markdown-use-cases (fwd) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jul 2015 21:23:57 -0000 --Apple-Mail=_08B047B4-449F-4FDC-BFBF-5D36F0EC5D1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thank you. Responses below. On Jul 1, 2015, at 3:17 PM, Paul Wouters wrote: >=20 > Sorry for the typo :) >=20 > Paul >=20 > ---------- Forwarded message ---------- > Date: Wed, 1 Jul 2015 18:15:10 > From: Paul Wouters > To: iesg@ietf.org, secdir@ietf.org, > draft-ietf-appsawg-text-markdown-use-casas.all@tools.ietf.org > Subject: Secdir review of draft-ietf-appsawg-text-markdown-use-cases >=20 >=20 > I have reviewed this document as part of the security directorate's > effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comment. >=20 > This document describes use cases and sometimes existing deployed code > on handling "markdown" text. As such, the document introduces no new > security considerations, and the Security Considerations section = points > to other documents that further document the respective markdown > variants and their own security considerations. >=20 > Recommendation: Ready with Issues >=20 > I wanted to point out two use cases (or existing deployed code?) > that uses some features that might be considered a security issue. >=20 > 2.1 talks about filesystem "extended attributes" and suggests to add a > resource named "variant". This name might be a little too generic = to > only apply to markdown and might cause a name spaec collision that > could potentially be a security risk. If this is a use case = without > deployed code, I would recommend renaming this resource to = something > more specific, eg "markdown-varient". If it describes actual code, > then I guess that ship has sailed. It does describe some actual code. I can change the text to: {{ The variant identifier itself should be stored in a resource with a name = including the term =93variant=94 (possibly including other decorations = to avoid namespace collisions). }} How is that? >=20 > 2.4 talks about MIME aware clients saving a "batch script" to disk for > later execution. These kind of "autorun" or "preview" features are > a security nightmare, so here too I would hope this has not yet = been > coded. And if not, to reconsider not supporting such a feature. The purpose of this section was to suggest that if, for example, = =93pandoc=94 is the recipient=92s preferred Markdown processor, and the = recipient receives Markdown content in some other variant that pandoc = supports (let=92s say original Markdown), then the recipient can send = the Markdown through pandoc with the markdown_strict option; the = recipient does not need to have or use Gruber=92s original Markdown.pl = implementation to get at what the sender wanted. It is not necessary for = the recipient to have millions of different Markdown implementations, = only that it has one (or a small handful) of implementations that are = good enough for the purpose. There was significant discussion on apps-discuss (see around October = 2014?) about how it is bad for the sender to be able to specify specific = processing instructions, e.g., command-line commands or options that get = sent directly to a command interpreter. So, that approach was jettisoned = at that time. The text in Section 2.4 says: This strategy is to **translate** the processing instructions **inferred = from** the [parameters] into a sequence of commands in the **local = convention**, storing those commands in a batch script [=85] that are = **appropriate (and safe) for the local system**. (Emphasis mine.) I think those emphasized parts capture the point that = whatever code gets executed has to be appropriate and safe for the local = system. I am happy to reword this paragraph somehow, but if that is seen as = necessary, I would appreciate a counterproposal. A parenthetical note: Section 2.5 of text-markdown-use-cases (=93Process = the Markdown=94) is a bit ambiguous. The point is to process the = Markdown before the recipient sees it. Thus if you are composing an = e-mail in Markdown, the point would be that your sending MUA (or an = intermediary) would convert it to HTML before recipients receive the = e-mail. However, your Markdown-aware sending MUA could save drafts in = Markdown before the message is sent. Proposed text: {{ 2.5. Process the Markdown In Advance This strategy is to process the Markdown into the formal markup, before = a recipient receives it, which eliminates ambiguities. Once the Markdown = is processed into (for example) valid XHTML, an application can save a = file as "doc.xhtml" or can send MIME content as application/xhtml+xml = with no further loss of metadata. While unambiguous, this process may = not be reversible. }} Thanks, Sean --Apple-Mail=_08B047B4-449F-4FDC-BFBF-5D36F0EC5D1E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUwNzEzMjEyMzMwWjAjBgkqhkiG9w0BCQQxFgQUGTEyxhlxbXsLPpAdJ8kQ35CykTAwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAFXPNKsbB6HoXH3C0vfGeaI4l6m6DNLHksUIv31AZKwwpMOz7HvSILKi7wZGNTifOS3b oodXa7P57rf40u9r8gIb2EZoZsLgpoGFXNZEzZDXJ77Ov7/6Xx1F26oXh6aZisYg28mnZvx8JrXF ifn3SZZNSG7bjrNk9kgRtdUHiPg5XEXQUJVggzkYPlujSoKkF5cOt56u1C1K6TEQiQV6HArVwjgo +vyXsboXaYZQ2XVFyQiTqZ9dxCjLaiP7EwoJvKEHMnMuonWbD7T/fcedpmyfyVUYigeM9iTcuSZ9 4p4uNISz8qIXW7jOnPKZLbbcqHi2rQ8HuVN/nZQ4InRkuYUAAAAAAAA= --Apple-Mail=_08B047B4-449F-4FDC-BFBF-5D36F0EC5D1E-- From nobody Tue Jul 14 03:25:07 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBEBA1A9234; Tue, 14 Jul 2015 03:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 R8BsE2Ky35v9; Tue, 14 Jul 2015 03:25:04 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8AD11A9233; Tue, 14 Jul 2015 03:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2794; q=dns/txt; s=iport; t=1436869504; x=1438079104; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=2LQAhXrRRW7XNMIWTcRMytLDHdroYU2dZtcsyTO0y+A=; b=DY0tnooGjT63JpzjtWlUNdhiLIvdHNzJ1XMXBK2ZJWlzLTZD4B5xo1kB Qd6l0DIYbdwNZnRLzhlLW220EicyGEsFWF8cVCbR5aCi+8STnI5HkVzJb 1HKZXdFQaIZkZXu1EamQV8em3XBH4MFiRZSTnZ8t/QkDmaEPpAFGeQdbA w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DwAgCX4qRV/xbLJq1bg2djBrMQiD8JgXSFdwKBfRQBAQEBAQEBgQqEJAEBBDIBBUEQCxgJDBkPAkYGDQYCAQGIKggFzHIBAQEBAQEBAQEBAQEBAQEBAQEBARiLTIE9gmYRAQhJBwqEIQEEhwmKP4JqhGuHG4FARYNTgm2JD4caJmOBNiSBQDwxAYEECBeBJwEBAQ X-IronPort-AV: E=Sophos;i="5.15,470,1432598400"; d="scan'208";a="565595757" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 14 Jul 2015 10:25:01 +0000 Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t6EAP0Z6011968; Tue, 14 Jul 2015 10:25:00 GMT To: Sean Leonard References: <20150706223302.24689.11506.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <55A4E37B.20304@cisco.com> Date: Tue, 14 Jul 2015 12:24:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown@ietf.org, The IESG , draft-ietf-appsawg-text-markdown.ad@ietf.org, n.brownlee@auckland.ac.nz, draft-ietf-appsawg-text-markdown.shepherd@ietf.org Subject: Re: [apps-discuss] Benoit Claise's No Objection on draft-ietf-appsawg-text-markdown-08: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 10:25:05 -0000 Thanks Sean. Regards, Benoit > (This response takes Alexey Melnikovs comment into account.) > > > On Jul 6, 2015, at 3:33 PM, Benoit Claise wrote: > >> Benoit Claise has entered the following ballot position for >> draft-ietf-appsawg-text-markdown-08: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> 1. From Nevil's OPS DIR feedback: >>> 2. The markdown Example (Section 5) is helpful, but it doesn't seem >>> to have an obvious end marker - it just runs on into section 6. >>> Does markdown have something like an end-of-file marker you could >>> use to make that obvious? >> And answered by Alexey: >>> Not really, it is a textual format with no special end marker. >>> >>> I suppose the whole example can be surrounded by some markers and a >> note added that they are not a part of the example? >> >> could we use the and ? > Actually the example in Section 5 is indented by one space. The final line of example: > > {{ > [fOo]: http://example.com/loc 'Will Not Work with Markdown.pl-1.0.1' > }} > > goes right up to the edge, so it cannot be indented further than one space, unless I change the example. (Note that it is difficult to say 'Won't Work with' due to the use of ' as a delimiter. > > I think it is fine as-is. It is clear (to me, anyway) that "6. IANA Considerations" is a new section. > >> 2. "A companion document [MDMTUSES] provides additional Markdown >> background and philosophy." >> >> There is more than that. See the >> draft-ietf-appsawg-text-markdown-use-cases abstract: "Background >> information, local storage strategies, and additional syntax >> registrations are supplied" > Revised text: > {{ > A companion document [MDMTUSES] provides additional Markdown background, philosophy, local storage strategies, and variant registrations (including examples). > }} > >> 3. Editorial >> OLD: [fOo] >> NEW: [foo] >> > The spelling is intentional: link identifiers are not case-sensitive. (The text (Remember that link identifiers are not case-sensitive.) appears in the example itself.) > > Kind regards, > > Sean From nobody Tue Jul 14 03:36:35 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166A41A92AB; Tue, 14 Jul 2015 03:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 Y3PvctpoJb-q; Tue, 14 Jul 2015 03:36:32 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646A31A92A9; Tue, 14 Jul 2015 03:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2171; q=dns/txt; s=iport; t=1436870192; x=1438079792; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=XEPg59+pzOyKz43pQZ6uuP4ojQpIjWJhyVK89+k0tZg=; b=OFQtn1szCEls3ttws6komBTV2kQonmO2rzq7syLjHIsVDl0RH+yMsPXc e/kyYL2IWPzSXWGdp8lBH+3QSO01PRCHWE41ZiUTIVCuMu3SugxcSpf/d 9C9z6qM+lokoz4wEvmIuBp3q4hi5P3JcQdMjImGEc8UuNXf512O8vcllE Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CdBAA95aRV/xbLJq1bg2dpvU+FdQKCEgEBAQEBAYELhCQBAQQ4QAEQCxgJFgQLCQMCAQIBRQYNBgIBAYgqDcxiAQEBAQEBAQEBAQEBAQEBAQEBARUEi0yEIxEBCEkHhCsBBIcJij+CaoRrhxuBQIQYgm2QKSZjgVqBQDwxAYEECBeBJwEBAQ X-IronPort-AV: E=Sophos;i="5.15,470,1432598400"; d="scan'208";a="560988209" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 14 Jul 2015 10:36:29 +0000 Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t6EAaSbj029990; Tue, 14 Jul 2015 10:36:28 GMT To: Sean Leonard References: <20150706224353.15970.20875.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <55A4E62B.5000008@cisco.com> Date: Tue, 14 Jul 2015 12:36:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.shepherd@ietf.org, draft-ietf-appsawg-text-markdown-use-cases@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.ad@ietf.org, The IESG Subject: Re: [apps-discuss] Benoit Claise's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 10:36:34 -0000 On 11/07/2015 05:45, Sean Leonard wrote: > On Jul 6, 2015, at 3:43 PM, Benoit Claise wrote: > >> Benoit Claise has entered the following ballot position for >> draft-ietf-appsawg-text-markdown-use-cases-02: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown-use-cases/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Easy to fix DISCUSS: The RFC 2119 boilerplate is missing: >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >> NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in >> this >> document are to be interpreted as described in [RFC2119]. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> - I was surprised by the RFC2119 keywords in a use cases document (which >> I first thought of as an applicability document") >> But, actually, according to the abstract, it's way more than a use cases >> document: "Background information, local storage strategies, and >> additional syntax registrations are supplied.", >> It's really the companion document of draft-ietf-appsawg-text-markdown. >> Maybe the title is wrong, and should be something such as text/markdown >> strategies and registrations? > > So to conclude here: the use-cases document needs RFC 2119 boilerplate and reference. Right? Right. And I understand, from some other email thread, that you plan on changing the document title. This is the right thing to do. Regards, Benoit From nobody Tue Jul 14 08:15:50 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE61F1ACEC5; Tue, 14 Jul 2015 08:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKE4YcZuoJeB; Tue, 14 Jul 2015 08:15:49 -0700 (PDT) Received: from mail-vn0-x232.google.com (mail-vn0-x232.google.com [IPv6:2607:f8b0:400c:c0f::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 E3D8F1ACEC3; Tue, 14 Jul 2015 08:15:48 -0700 (PDT) Received: by vnbf62 with SMTP id f62so1366052vnb.9; Tue, 14 Jul 2015 08:15:48 -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=Jzzqb7W4sCbb14f+qbVZoAPDHqTopI2PTL0eNIG9nyg=; b=BGmgA88SW7OqiKF8XU50SKhOyTMobCW3m15EFBRyeKSBio/FKza1C/2McpIJuYN0au 2oGvn9KdfwGdyAQ4I2Ssl14zVPq9NKHZuIXDrnkupbVjBjkQrY7NE4Xt+HWjyqFXCi43 sbi+VYpqAsIhaDJd+LJkViOnllowD/3wSDoMd0JIN3sL5Vegs9p6YR4iPPeuxvmuuUgJ g6VKzWH37Rm+i+VHUp+K49YswPftYlzeCNO5uLjW2295CQ9ptKegW87uXSAQ9jGvU99r 8U66eMyzwNllIMioaYQkQECO3NLeZWeJzFP99Nr6pc/WDVCl12e8GhFkYV0xIst5xEwZ FzDA== MIME-Version: 1.0 X-Received: by 10.52.71.203 with SMTP id x11mr36533185vdu.48.1436886948234; Tue, 14 Jul 2015 08:15:48 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Tue, 14 Jul 2015 08:15:48 -0700 (PDT) In-Reply-To: <55A512FD.3030506@seantek.com> References: <20150708033129.16459.55993.idtracker@ietfa.amsl.com> <6475ED7E-017E-46CD-A1B9-2755AFC2F702@seantek.com> <55A11ADE.1030204@dcrocker.net> <8DC2EA7C-19BC-4B01-A99F-818345AA24C3@seantek.com> <55A42EC4.9090002@dcrocker.net> <55A512FD.3030506@seantek.com> Date: Tue, 14 Jul 2015 11:15:48 -0400 X-Google-Sender-Auth: oYcPHuDHNyUl7YaMrTXhuL8pLUg Message-ID: From: Barry Leiba To: Sean Leonard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "appsawg-chairs@ietf.org" , IESG , IETF Apps Discuss , "draft-ietf-appsawg-text-markdown-use-cases@ietf.org" Subject: Re: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jul 2015 15:15:50 -0000 > "Guidance" is a good term to use. > > Guidance on Markdown: > Design Philosophies, Preservation Strategies, and Select Registrations That seems reasonable, with a question: What does "preservation strategies" mean? Barry From nobody Tue Jul 14 08:37:59 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05021A19EF; Tue, 14 Jul 2015 08:37:56 -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 NUhw2CtChLX4; Tue, 14 Jul 2015 08:37:55 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D56A41A1A5D; Tue, 14 Jul 2015 08:37:39 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2D6E222E200; Tue, 14 Jul 2015 11:37:34 -0400 (EDT) Message-ID: <55A52C90.3090402@seantek.com> Date: Tue, 14 Jul 2015 08:36:48 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Barry Leiba References: <20150708033129.16459.55993.idtracker@ietfa.amsl.com> <6475ED7E-017E-46CD-A1B9-2755AFC2F702@seantek.com> <55A11ADE.1030204@dcrocker.net> <8DC2EA7C-19BC-4B01-A99F-818345AA24C3@seantek.com> <55A42EC4.9090002@dcrocker.net> <55A512FD.3030506@seantek.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060207080009080605000804" Archived-At: Cc: "appsawg-chairs@ietf.org" , IESG , IETF Apps Discuss , "draft-ietf-appsawg-text-markdown-use-cases@ietf.org" Subject: Re: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jul 2015 15:37:56 -0000 This is a cryptographically signed message in MIME format. --------------ms060207080009080605000804 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 7/14/2015 8:15 AM, Barry Leiba wrote: >> "Guidance" is a good term to use. >> >> Guidance on Markdown: >> Design Philosophies, Preservation Strategies, and Select Registrations= > That seems reasonable, with a question: What does "preservation > strategies" mean? It means "how to preserve the text/markdown Content-Type along with its=20 parameters outside of MIME bodies", or, "how to preserve the author's intent when the author wrote the=20 Markdown content in a certain way, so that recipients know what kind of=20 Markdown (variant) the content actually is, along with the charset". (Covered in Section 2.) Sean --------------ms060207080009080605000804 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCC BK8wggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNV BAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJu YWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcN MTQxMjIyMDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAibEN2npTGU5wUh28VqYGJre4SeCW51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2 IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JDFnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9 KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUIkzqcKlOjENs9IGE8VQOO2U52JQIhKfqj fHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7AzaS1D6/rWpfGXd2dRjNnuJ+u8pQc4 doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZAP8vk4p+iIQIDAQABo4IBFzCC ARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYDVR0OBBYEFJJha4LhoqCq T+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0w OzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJv b3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRy dXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOc Uvi7BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc0 6HvgARClnMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLK hjQHuSzK5hxK2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6 H3kU9koQGib6fIr7mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcN AQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAyMDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRl ditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n2 0qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKPvku7E+utnLhcaNahAWr2oZgeCK9uhEqi jaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cUvZqY7YwzCG6jSfs4gwNh+29MS6fa Y6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/MwNAabNhDgxU2Tw1fl5w1Vt+6x RTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/syYhS1Ko4MSiJmR3ugKPk xEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQABo4IB8jCCAe4wHwYD VR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y8PBT6NqnIVbf NK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2 Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEE gYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1 NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGG GGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVr LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC 8IXwUmNxL7L5uE3tGlNJVoTKZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63r MlFPFrjqQCEA6rDgo9DlFO9/81P7ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3 gUs5xJT0koGVvli2wR18zecG3ib3ml+GnDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamq r3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEpqpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMC tqlHvF3YY2z55jGCBDEwggQtAgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecwCQYFKw4DAhoFAKCCAlUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwNzE0MTUzNjQ4 WjAjBgkqhkiG9w0BCQQxFgQUYejgYv+71H1zTC7zMJLReVceaGAwbAYJKoZIhvcNAQkPMV8w XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBwQYJKwYBBAGCNxAE MYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4 Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBpCSs8n+cQbczyWKtueyecwgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtue yecwDQYJKoZIhvcNAQEBBQAEggEArnjpP6IYUxgolDZqVrfVY3TpWLK6HJ5C935zcVp2cUTl eyjs0xooRc9TECkbJx4waebUSVwjfePBg/+JcLI925yQG6aFLfDOG4om6+Q0BfOZDph08JCX XDV2IZSVYYmFStoa4SUPvxq0SR11O2XfETqwoKBJuXt8BOTeUAVAf4qE+C82aPGrSfTwqNcf pB3Ii8HbciABa/Edy2+JMOx6wd1dNFkht7xIMigXNMCCQJHiyreOUh0Rn0tMmh7yO6Yt8mZB eV+0x6q1hPZSkXWZNTh+M+T4O5zjMEBSezr5J53Q28Olrtj2NGHNvsaCitrQ5Qb4aSziVtk3 YxuX/lgUAAAAAAAAAA== --------------ms060207080009080605000804-- From nobody Tue Jul 14 08:54:04 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B2C1A1B3C; Tue, 14 Jul 2015 08:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXTlnOzou8_N; Tue, 14 Jul 2015 08:53:55 -0700 (PDT) Received: from mail-vn0-x22d.google.com (mail-vn0-x22d.google.com [IPv6:2607:f8b0:400c:c0f::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 009EE1A1AB9; Tue, 14 Jul 2015 08:53:54 -0700 (PDT) Received: by vnbf62 with SMTP id f62so1506140vnb.8; Tue, 14 Jul 2015 08:53:54 -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=XMIZlft/f6VtkI877nIi3C7iLdw9l4f7QvyloVfvhIQ=; b=vqJxngO1wbd+SBIXifjRYF4TV50wQ+o0mN2DV8CnMSLuU/yAeCqbJQbjxK7ScqeZv4 iCT51pUMAle+sVLKqtxRKjt+/EvLxLtvq1iLtUwqKSgNbfqqMFzv6OyD+riT/v7F74Eg haPU8uu8IsuSKWx+zQGcSSrirDyjIp9iBquhUXDzcmT/dv7840shOtfLXWziLHKiRGOf X4WEiNyYi+Vv7NarXEeO8O9OPP3ONgt6TqxSfI15FPO19h1IurDl7jko+m7hO6lJx2IM k67fRiNXEr3mkmBqzjD+pDQNIDOQ4AvXEjx008+MuSAInKvQXW/1DI8aiRYQDXcSGWrR DXLw== MIME-Version: 1.0 X-Received: by 10.52.189.75 with SMTP id gg11mr36617873vdc.27.1436889234301; Tue, 14 Jul 2015 08:53:54 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Tue, 14 Jul 2015 08:53:54 -0700 (PDT) In-Reply-To: <55A52C90.3090402@seantek.com> References: <20150708033129.16459.55993.idtracker@ietfa.amsl.com> <6475ED7E-017E-46CD-A1B9-2755AFC2F702@seantek.com> <55A11ADE.1030204@dcrocker.net> <8DC2EA7C-19BC-4B01-A99F-818345AA24C3@seantek.com> <55A42EC4.9090002@dcrocker.net> <55A512FD.3030506@seantek.com> <55A52C90.3090402@seantek.com> Date: Tue, 14 Jul 2015 11:53:54 -0400 X-Google-Sender-Auth: wMYjouYDHJEsJYHEwN881_AOWNo Message-ID: From: Barry Leiba To: Sean Leonard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "appsawg-chairs@ietf.org" , IESG , IETF Apps Discuss , "draft-ietf-appsawg-text-markdown-use-cases@ietf.org" Subject: Re: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jul 2015 15:53:56 -0000 >>> "Guidance" is a good term to use. >>> >>> Guidance on Markdown: >>> Design Philosophies, Preservation Strategies, and Select Registrations >> >> That seems reasonable, with a question: What does "preservation >> strategies" mean? > > It means "how to preserve the text/markdown Content-Type along with its > parameters outside of MIME bodies", > or, "how to preserve the author's intent when the author wrote the Markdown > content in a certain way, so that recipients know what kind of Markdown > (variant) the content actually is, along with the charset". > > (Covered in Section 2.) Yes; I'm questioning whether anyone reading the title will have any idea what "preservation strategies" means. What's the point of putting words into the title that don't add to (and actually detract from) the understanding of what the title means? Barry From nobody Tue Jul 14 09:06:58 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1FC1A1C06; Tue, 14 Jul 2015 09:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfsg4TFWZWJF; Tue, 14 Jul 2015 09:06:45 -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 DAFBC1A1BCB; Tue, 14 Jul 2015 09:06:40 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZF2j7-000OeH-UX; Tue, 14 Jul 2015 12:06:37 -0400 Date: Tue, 14 Jul 2015 12:06:32 -0400 From: John C Klensin To: Barry Leiba , Sean Leonard Message-ID: <9F10ADD70C9FBE6A6889DC36@JcK-HP8200.jck.com> In-Reply-To: References: <20150708033129.16459.55993.idtracker@ietfa.amsl.com> <6475ED7E-017E-46CD-A1B9-2755AFC2F702@seantek.com> <55A11ADE.1030204@dcrocker.net> <8DC2EA7C-19BC-4B01-A99F-818345AA24C3@seantek.com> <55A42EC4.9090002@dcrocker.net> <55A512FD.3030506@seantek.com> <55A52C90.3090402@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@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: appsawg-chairs@ietf.org, IESG , IETF Apps Discuss , draft-ietf-appsawg-text-markdown-use-cases@ietf.org Subject: Re: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jul 2015 16:06:47 -0000 --On Tuesday, July 14, 2015 11:53 -0400 Barry Leiba wrote: >>>> Guidance on Markdown: >>>> Design Philosophies, Preservation Strategies, and Select >>>> Registrations >>> >>> That seems reasonable, with a question: What does >>> "preservation strategies" mean? >> >> It means "how to preserve the text/markdown Content-Type >> along with its parameters outside of MIME bodies", >> or, "how to preserve the author's intent when the author >> wrote the Markdown content in a certain way, so that >> recipients know what kind of Markdown (variant) the content >> actually is, along with the charset". >> >> (Covered in Section 2.) > > Yes; I'm questioning whether anyone reading the title will > have any idea what "preservation strategies" means. What's > the point of putting words into the title that don't add to > (and actually detract from) the understanding of what the > title means? Barry and Sean, short of just dropping that clause, how about "stability strategies" or "interoperability strategies"? Both terms are well-known in the community and give much more of a clue as to what is being discussed than "preservation". The use of either in this context is a bit unusual, but it seems to me that preserving interoperability and original intent as Markdown documents move through systems is precisely what Sean is talking about. john From nobody Tue Jul 14 09:10:07 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC991A1B6F; Tue, 14 Jul 2015 09:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 xITWVAkzQpHI; Tue, 14 Jul 2015 09:10:01 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0FDA1A1BC6; Tue, 14 Jul 2015 09:10:00 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B79C922E1F4; Tue, 14 Jul 2015 12:09:53 -0400 (EDT) Message-ID: <55A53423.5000003@seantek.com> Date: Tue, 14 Jul 2015 09:09:07 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , John C Klensin , The IESG References: <55A36D59.1010101@it.aoyama.ac.jp> In-Reply-To: <55A36D59.1010101@it.aoyama.ac.jp> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030909010906030605030704" Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.shepherd@ietf.org, draft-ietf-appsawg-text-markdown-use-cases@ietf.org, draft-ietf-appsawg-text-markdown-use-cases.ad@ietf.org, Benoit Claise Subject: Re: [apps-discuss] Objection to processing draft-ietf-appsawg-text-markdown-* documents as WG drafts (was: Re: Benoit Claise's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS and COMMENT)) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 16:10:06 -0000 This is a cryptographically signed message in MIME format. --------------ms030909010906030605030704 Content-Type: multipart/alternative; boundary="------------070700040406090601090901" This is a multi-part message in MIME format. --------------070700040406090601090901 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 7/13/2015 12:48 AM, Martin J. D=C3=BCrst wrote: > On 2015/07/13 08:20, John C Klensin wrote: > >> For example, the first paragraph of Section 1.1 of >> draft-ietf-appsawg-text-markdown includes "a linear sequence of >> characters in some character set (code)". That just isn't >> acceptable terminology. Not only does it not conform to the >> recommendations of RFC 6365, but, in a slightly different >> environment, it would probably be read as meaning something >> entirely different from what was probably intended. > > Agreed. "Character set" as used in RFC 2046 is not a term we want to=20 > use in 2015. To be clear, the drafts got a significant amount of discussion across=20 the board, which resulted in the documents submitted to the IESG. The key objections causing disgruntlement seem to be about terminology=20 in or related to the introductory matter. The introduction used to be=20 significantly longer (see draft-ietf-appsawg-text-markdown-02), but was=20 pared down after significant community input. If there is something=20 wrong with the history or the terminology then that is fine but it's=20 just an historical or factual error; it's not something that compromises = the technical integrity of the standard. The point of the first paragraph is to acknowledge a continuum between=20 textual data and binary data (binary data having been edited out, and=20 subsequently restored--see prior e-mail), and then to acknowledge the=20 limitations of in-band signaling with control characters that are part=20 of the (coded) character set. The raison d'=C3=AAtre for markup languages= is=20 that signaling with control characters has proven to be impractical or=20 nonextensible. There are many standards (ISO 2022, ISO 6429/ECMA-48,=20 etc.) that deal with control characters--even a family of standards for=20 word processing interchange with control characters for formatting and=20 whatnot. (I forgot that particular standard--does someone know it?) And=20 most people don't use them these days, because markup is just easier to=20 deal with. When I (re)wrote the introduction, I relied on the Unicode definition of = "plain text": /Plain Text /. Computer-encoded = text that consists/only/of a sequence of code points from a given=20 standard, with no other formatting or structural information. Plain text = interchange is commonly used between computer systems that do not share=20 higher-level protocols. (See also/rich text=20 /.) As well as the definitions of "text/plain" from RFC 2045/2046: 4.1.3 . Plain Subtype The simplest and most important subtype of "text" is "plain". This indicates plain text that does not contain any formatting commands or= directives. Plain text is intended to be displayed "as-is", that is, no interpretation of embedded formatting commands, font attribute specifications, processing instructions, interpretation directives, or content markup should be necessary for proper display. The default media type of "text/plain; charset=3Dus-ascii" for Internet mail describes existing Internet practice. That is, it is the type of body defined byRFC 822 . Those definitions conflate the distinction between a "character set"=20 (which is, literally, a set of abstract characters, or, Unicode:=20 /Character Set. /A=20 collection of elements used to represent textual information.), and a=20 "coded character set" [RFC 6365]. The sentence in the text-markdown=20 draft only mirrors what is already out there. Note that RFC 6365 does=20 not define character set: it only defines coded character set. So the=20 objection lacks basis. If we in the software industry are going to quibble about definitions,=20 it sure would be nice for the SDOs to come together and establish a=20 uniform set of definitions for these basic constructs, that are worded=20 exactly the same between the different SDOs. > >> That >> paragraph goes on to say "Because they are non-printing, these >> characters" (referring to "line breaks, page breaks, or other >> control characters) "are also hard to enter with standard >> keyboards." At least for European writing systems, that is >> plain silly unless one has a keyboard that lacks an "Enter" or >> "Return" function or is using a _very_ strange input method >> editor (IME). > > For line breaks, I'd argue that they are very easy to enter on pretty=20 > much any keyboard, because pretty much any keyboard has an Enter key=20 > (and because pretty much every modern language has line- or paragraph=20 > breaks). > > For page breaks and other control characters, I'd argue that they are=20 > difficult to enter with the average keyboard, in any language. > > So just remove "line breaks", and the problem should be fixed. Actually line breaking is and remains a persistent issue. When "Return"=20 or "Enter" is pressed on a keyboard, the keyboard generates scancodes,=20 typically 5A (MAKE) and F0 FA (RELEASE). It is up to the operating=20 system to interpret this, which may variously generate CR, LF, CRLF, or=20 something else entirely (activating a button, or for the under-35 crowd, = sending a text). If your *intent* on a Mac OS X machine is to generate=20 the control character CR, you are in for a tough time. We may make a general distinction between control characters and=20 non-control characters (which, variously, are referred to as printable=20 characters or graphic characters). Markup languages encode formatting=20 information in non-control characters, by overloading the meaning of=20 some non-control characters beyond the meaning assigned by the character = set. > > >> The next paragraph goes on to make a suggestion >> about "overload certain characters with additional meanings". At >> least for SGML (and its descendents), that is not the way what >> happens is described. I'd suggest it is even less true of >> LaTex, but YMMD. What might be intended is something like >> "certain characters or character sequences are treated as >> reserved delimiters, with the strings they delimit acting as >> processing, identification, or formatting directions". > > I'd agree that this isn't how SGML or LaTeX would describe it, but=20 > it's not actually in any way wrong. In XML, depending on context, '>'=20 > means itself or "close tag" (or any of a few more obscure meanings).=20 > We are still in the introduction, after all. Yes, exactly. According to Unicode, ISO 646, RFC 20, and USASI=20 X3.4-1968, ">" (code point 3/14) means "GREATER THAN SIGN". It has also=20 been the policy of the U.S. Government since Lyndon B. Johnson's=20 approval in 1968 (see=20 http://www.presidency.ucsb.edu/ws/index.php?pid=3D28724 ). Any meaning=20 other than "GREATER THAN SIGN", such as "close tag", is exactly that: an = additional meaning. > > >> Continuing with this theme, the "charset" portion of Section 2 >> of draft-ietf-appsawg-text-markdown-06 says: >> >> "...will get along just fine by operating on character >> codes that lie in printable US-ASCII, blissfully >> oblivious to coded values outside of that range." >> >> I don't know what that means in spite of being regularly >> mistaken for an expert in the area. Given that you want to be >> CCS-independent (see RFC6365), I think the first part probably >> refers to "graphic characters in the ASCII repertoire", but I >> don't know what "blissfully oblivious..." is trying to tell me. >> Is it that each Markdown processor has, or assumes, a CCS and >> encoding and, if anything is encountered outside that range or >> is a non-graphic character in that range, it will be ignored? >> Noting that set of exclusions would ignore the character known >> as SP, I suggest that any such Markdown processor would be >> seriously broken. It is more likely that the sentence is wrong. > > I know what the sentence tries to refer to. It refers to the fact=20 > that, as long as the syntax you are looking at only uses 7-bit bytes=20 > values with ASCII semantics (including the usual control characters=20 > and space), a processor will work for a wide range of character=20 > encodings. > > The problem is that this applies to some encodings, but not to others. = > The criterion is a certain kind of strong ASCII-compatibility, namely=20 > that characters in the ASCII range (including C0) are always=20 > represented directly as 7-bit bytes, and that these 7-bit bytes always = > represent the corresponding characters and nothing else. > > Encodings that qualify are of course US-ASCII itself, straightforward=20 > 8-bit encodings starting with iso-8859-1 and including vendor=20 > encodings (Windows, Mac,...), some multibyte encodings such as GB2312=20 > and EUC-JP, and UTF-8 (but beware of the BOM). However, it does not=20 > include some other encodings, in particular not iso-2022-jp,=20 > Shift_JIS, GBK, or GB18030, and of course not UTF-(16|32)(LE|BE). Many prominent Markdown processors operate on a text stream as input,=20 and output the same text stream. By "text stream", I mean that the bits=20 from disk (or memory or some other source) are interpreted by a software = library, such as Perl, Python, the C++ standard library, etc., and are=20 given to the Markdown processor in code units. A JavaScript-based=20 Markdown interpreter, for example, almost never operates on raw octets;=20 it always takes input from some other source that is dumped into=20 strings. Strings in JavaScript are (virtualized) to UCS-2 or UTF-16=20 16-bit code points. It doesn't matter if the source is in ISO-2022-JP,=20 GBK, ISO-8859-1, EBCDIC, or UTF-32BE. What matters is that the Markdown=20 processor looks for things like "*" and when it finds things like "*" in = certain configurations, will replace it with HTML bulleted list tags; in = other configurations, will replace it with tags; and in other=20 configurations, will not change the output at all. The common theme of Markdown processors is that Markdown operates on=20 "punctuation" : To this end, Markdown=E2=80=99s syntax is comprised entirely of punctuati= on=20 characters, which punctuation characters have been carefully chosen so=20 as to look like what they mean. =2E..which, by the way, is exactly what that part of the text-markdown=20 draft says, right before the quoted part about being "blissfully obliviou= s". Bear in mind that this discussion is being had in the context of the=20 "charset" parameter, which /combines/ the abstract character set with=20 the character encoding. It seems that folks are asking for separation in = a context where separation does not exist. > > So the text should definitely be more careful here. I suppose the text could be more careful, but when reading the whole=20 paragraph, I do not see a problem. In fact, to the extent that a=20 Markdown processor (or the input libraries upon which it relies)=20 misinterprets content as the wrong (coded) character set compared to the = author's intent, it is very likely that the Markdown processor will not=20 fail--it will just output something crazy. Markdown processors rarely=20 fail; they are not designed that way. That is why the text uses the=20 phrase "blissfully oblivious". Sean --------------070700040406090601090901 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 7/13/2015 12:48 AM, Martin J. D=C3=BC= rst wrote:
On 2015/07/13 08:20, John C Klensin wrote:

For example, the first paragraph of Section 1.1 of
draft-ietf-appsawg-text-markdown includes "a linear sequence of
characters in some character set (code)".=C2=A0 That just isn't
acceptable terminology.=C2=A0 Not only does it not conform to the=
recommendations of RFC 6365, but, in a slightly different
environment, it would probably be read as meaning something
entirely different from what was probably intended.

Agreed. "Character set" as used in RFC 2046 is not a term we want to use in 2015.

To be clear, the drafts got a significant amount of discussion across the board, which resulted in the documents submitted to the IESG.

The key objections causing disgruntlement seem to be about terminology in or related to the introductory matter. The introduction used to be significantly longer (see draft-ietf-appsawg-text-markdown-02), but was pared down after significant community input. If there is something wrong with the history or the terminology then that is fine but it's just an historical or factual error; it's not something that compromises the technical integrity of the standard.

The point of the first paragraph is to acknowledge a continuum between textual data and binary data (binary data having been edited out, and subsequently restored--see prior e-mail), and then to acknowledge the limitations of in-band signaling with control characters that are part of the (coded) character set. The raison d'=C3=AAtre for markup languages is that signaling with control characters has proven to be impractical or nonextensible. There are many standards (ISO 2022, ISO 6429/ECMA-48, etc.) that deal with control characters--even a family of standards for word processing interchange with control characters for formatting and whatnot. (I forgot that particular standard--does someone know it?) And most people don't use them these days, because markup is just easier to deal with.

When I (re)wrote the introduction, I relied on the Unicode definition of "plain text":
Plain Text. Computer-encoded text that consists=C2=A0only=C2=A0of a sequence of cod= e points from a given standard, with no other formatting or structural information. Plain text interchange is commonly used between computer systems that do not share higher-level protocols. (See also=C2=A0= rich text.)

As well as the definitions of "text/plain" from RFC 2045/2046:
4.1.3.  Plain Subtype


   The simplest and most important subtype of "text" is "plain".  This
   indicates plain text that does not contain any formatting commands or
   directives. Plain text is intended to be displayed "as-is", that is,
   no interpretation of embedded formatting commands, font attribute
   specifications, processing instructions, interpretation directives,
   or content markup should be necessary for proper display.  The
   default media type of "text/plain; charset=3Dus-ascii" for Internet
   mail describes existing Internet practice.  That is, it is the type
   of body defined by RFC 8=
22.


Those definitions conflate the distinction between a "character set" (which is, literally, a set of abstract characters, or, Unicode: Character Set.=C2=A0A collection of elements used to represent textual information.), and a "coded character set" [RFC 6365]. The sentence in the text-markdown draft only mirrors what is already out there. Note that RFC 6365 does not define character set: it only defines coded character set. So the objection lacks basis.

If we in the software industry are going to quibble about definitions, it sure would be nice for the SDOs to come together and establish a uniform set of definitions for these basic constructs, that are worded exactly the same between the different SDOs.


That
paragraph goes on to say "Because they are non-printing, these
characters" (referring to "line breaks, page breaks, or other
control characters) "are also hard to enter with standard
keyboards."=C2=A0=C2=A0 At least for European writing systems, th= at is
plain silly unless one has a keyboard that lacks an "Enter" or
"Return" function or is using a _very_ strange input method
editor (IME).

For line breaks, I'd argue that they are very easy to enter on pretty much any keyboard, because pretty much any keyboard has an Enter key (and because pretty much every modern language has line- or paragraph breaks).

For page breaks and other control characters, I'd argue that they are difficult to enter with the average keyboard, in any language.

So just remove "line breaks", and the problem should be fixed.

Actually line breaking is and remains a persistent issue. When "Return" or "Enter" is pressed on a keyboard, the keyboard generates scancodes, typically 5A (MAKE) and F0 FA (RELEASE). It is up to the operating system to interpret this, which may variously generate CR, LF, CRLF, or something else entirely (activating a button, or for the under-35 crowd, sending a text). If your *intent* on a Mac OS X machine is to generate the control character CR, you are in for a tough time.

We may make a general distinction between control characters and non-control characters (which, variously, are referred to as printable characters or graphic characters). Markup languages encode formatting information in non-control characters, by overloading the meaning of some non-control characters beyond the meaning assigned by the character set.



The next paragraph goes on to make a suggestion
about "overload certain characters with additional meanings". At
least for SGML (and its descendents), that is not the way what
happens is described.=C2=A0 I'd suggest it is even less true of
LaTex, but YMMD.=C2=A0 What might be intended is something like
"certain characters or character sequences are treated as
reserved delimiters, with the strings they delimit acting as
processing, identification, or formatting directions".

I'd agree that this isn't how SGML or LaTeX would describe it, but it's not actually in any way wrong. In XML, depending on context, '>' means itself or "close tag" (or any of a few more obscure meanings). We are still in the introduction, after all.

Yes, exactly. According to Unicode, ISO 646, RFC 20, and USASI X3.4-1968, ">" (code point 3/14) means "GREATER THAN SIGN". It has also been the policy of the U.S. Government since Lyndon B. Johnson's approval in 1968 (see http://www.presidency.ucsb.edu/ws/index.= php?pid=3D28724 ). Any meaning other than "GREATER THAN SIGN", such as "close tag", is exactly that: an additional meaning.



Continuing with this theme, the "charset"= portion of Section 2
of draft-ietf-appsawg-text-markdown-06 says:

=C2=A0=C2=A0=C2=A0=C2=A0"...will get along just fine by operating= on character
=C2=A0=C2=A0=C2=A0=C2=A0codes that lie in printable US-ASCII, bli= ssfully
=C2=A0=C2=A0=C2=A0=C2=A0oblivious to coded values outside of that= range."

I don't know what that means in spite of being regularly
mistaken for an expert in the area.=C2=A0 Given that you want to = be
CCS-independent (see RFC6365), I think the first part probably
refers to "graphic characters in the ASCII repertoire", but I
don't know what "blissfully oblivious..." is trying to tell me.
Is it that each Markdown processor has, or assumes, a CCS and
encoding and, if anything is encountered outside that range or
is a non-graphic character in that range, it will be ignored?
Noting that set of exclusions would ignore the character known
as SP, I suggest that any such Markdown processor would be
seriously broken.=C2=A0 It is more likely that the sentence is wr= ong.

I know what the sentence tries to refer to. It refers to the fact that, as long as the syntax you are looking at only uses 7-bit bytes values with ASCII semantics (including the usual control characters and space), a processor will work for a wide range of character encodings.

The problem is that this applies to some encodings, but not to others. The criterion is a certain kind of strong ASCII-compatibility, namely that characters in the ASCII range (including C0) are always represented directly as 7-bit bytes, and that these 7-bit bytes always represent the corresponding characters and nothing else.

Encodings that qualify are of course US-ASCII itself, straightforward 8-bit encodings starting with iso-8859-1 and including vendor encodings (Windows, Mac,...), some multibyte encodings such as GB2312 and EUC-JP, and UTF-8 (but beware of the BOM). However, it does not include some other encodings, in particular not iso-2022-jp, Shift_JIS, GBK, or GB18030, and of course not UTF-(16|32)(LE|BE).

Many prominent Markdown processors operate on a text stream as input, and output the same text stream. By "text stream", I mean that the bits from disk (or memory or some other source) are interpreted by a software library, such as Perl, Python, the C++ standard library, etc., and are given to the Markdown processor in code units. A JavaScript-based Markdown interpreter, for example, almost never operates on raw octets; it always takes input from some other source that is dumped into strings. Strings in JavaScript are (virtualized) to UCS-2 or UTF-16 16-bit code points. It doesn't matter if the source is in ISO-2022-JP, GBK, ISO-8859-1, EBCDIC, or UTF-32BE. What matters is that the Markdown processor looks for things like "*" and when it finds things like "*" in certain configurations, will replace it with HTML bulleted list tags; in other configurations, will replace it with <em> tags; and in other configurations, will not change the output at all.

The common theme of Markdown processors is that Markdow= n operates on "punctuation":
To this end, Markdown=E2=80= =99s syntax is comprised entirely of punctuation characters, which punctuation characters have been carefully chosen so as to look like what they mean.

...which, by the way, is exactly what that part of the text-markdown draft says, right before the quoted part about being "blissfully oblivious".

Bear in mind that this discussion is being had in the context of the "charset" parameter, which combines the abstract character set with the character encoding. It seems that folks are asking for separation in a context where separation does not exist.


So the text should definitely be more careful here.

I suppose the text could be more careful, but when reading the whole paragraph, I do not see a problem. In fact, to the extent that a Markdown processor (or the input libraries upon which it relies) misinterprets content as the wrong (coded) character set compared to the author's intent, it is very likely that the Markdown processor will not fail--it will just output something crazy. Markdown processors rarely fail; they are not designed that way. That is why the text uses the phrase "blissfully oblivious".

Sean

--------------070700040406090601090901-- --------------ms030909010906030605030704 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCC BK8wggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNV BAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJu YWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcN MTQxMjIyMDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAibEN2npTGU5wUh28VqYGJre4SeCW51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2 IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JDFnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9 KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUIkzqcKlOjENs9IGE8VQOO2U52JQIhKfqj fHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7AzaS1D6/rWpfGXd2dRjNnuJ+u8pQc4 doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZAP8vk4p+iIQIDAQABo4IBFzCC ARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYDVR0OBBYEFJJha4LhoqCq T+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0w OzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJv b3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRy dXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOc Uvi7BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc0 6HvgARClnMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLK hjQHuSzK5hxK2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6 H3kU9koQGib6fIr7mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcN AQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAyMDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRl ditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n2 0qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKPvku7E+utnLhcaNahAWr2oZgeCK9uhEqi jaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cUvZqY7YwzCG6jSfs4gwNh+29MS6fa Y6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/MwNAabNhDgxU2Tw1fl5w1Vt+6x RTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/syYhS1Ko4MSiJmR3ugKPk xEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQABo4IB8jCCAe4wHwYD VR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y8PBT6NqnIVbf NK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2 Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEE gYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1 NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGG GGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVr LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC 8IXwUmNxL7L5uE3tGlNJVoTKZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63r MlFPFrjqQCEA6rDgo9DlFO9/81P7ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3 gUs5xJT0koGVvli2wR18zecG3ib3ml+GnDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamq r3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEpqpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMC tqlHvF3YY2z55jGCBDEwggQtAgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecwCQYFKw4DAhoFAKCCAlUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwNzE0MTYwOTA3 WjAjBgkqhkiG9w0BCQQxFgQUNgjq+mXzqBdPHlrFi09LoHvYDYswbAYJKoZIhvcNAQkPMV8w XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBwQYJKwYBBAGCNxAE MYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4 Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBpCSs8n+cQbczyWKtueyecwgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtue yecwDQYJKoZIhvcNAQEBBQAEggEAL9pfGRzT04jW+CE43/2Ivk6al2Y3WnbfT6y+082i/5qP +kySIIVOWM9FaoRdvc5LgwvFKy0WzUsT2faNc7RInbdgCkVNUBSe6LbcrWghW5yZkKiVGi6c Dn+7sqg+Kn5nA4wQj/BdrHKL9t7uGfVOydxiCuqP1Mk7j5xOt3PanHwUdIGgSEuZ7SXB08Is VKTRR3TYu4yl5/BfCnUC8/cDyvwLL4vHwYk3qOUK4xUmGXhmnW97jZkHKv/vvZQZ5oKjmObX I28X7DUrNSK2juElj1KUFpwawRlER0tJFgJIzBd44JY88gfP+JuQjydhW7gpplzUBGMUm0ob FYZCfu11xQAAAAAAAA== --------------ms030909010906030605030704-- From nobody Tue Jul 14 11:35:22 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB8F1B2A22; Tue, 14 Jul 2015 11:35:15 -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 Wgsm4pujK66i; Tue, 14 Jul 2015 11:35:12 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D0601B2A19; Tue, 14 Jul 2015 11:34:48 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A4C2122E200; Tue, 14 Jul 2015 14:34:42 -0400 (EDT) Message-ID: <55A55614.3060403@seantek.com> Date: Tue, 14 Jul 2015 11:33:56 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: John C Klensin , Barry Leiba References: <20150708033129.16459.55993.idtracker@ietfa.amsl.com> <6475ED7E-017E-46CD-A1B9-2755AFC2F702@seantek.com> <55A11ADE.1030204@dcrocker.net> <8DC2EA7C-19BC-4B01-A99F-818345AA24C3@seantek.com> <55A42EC4.9090002@dcrocker.net> <55A512FD.3030506@seantek.com> <55A52C90.3090402@seantek.com> <9F10ADD70C9FBE6A6889DC36@JcK-HP8200.jck.com> In-Reply-To: <9F10ADD70C9FBE6A6889DC36@JcK-HP8200.jck.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070508080207070506040304" Archived-At: Cc: appsawg-chairs@ietf.org, IESG , IETF Apps Discuss , draft-ietf-appsawg-text-markdown-use-cases@ietf.org Subject: Re: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jul 2015 18:35:15 -0000 This is a cryptographically signed message in MIME format. --------------ms070508080207070506040304 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 7/14/2015 9:06 AM, John C Klensin wrote: > > --On Tuesday, July 14, 2015 11:53 -0400 Barry Leiba > wrote: > >>>>> Guidance on Markdown: >>>>> Design Philosophies, Preservation Strategies, and Select >>>>> Registrations >>>> That seems reasonable, with a question: What does >>>> "preservation strategies" mean? >>> It means "how to preserve the text/markdown Content-Type >>> along with its parameters outside of MIME bodies", >>> or, "how to preserve the author's intent when the author >>> wrote the Markdown content in a certain way, so that >>> recipients know what kind of Markdown (variant) the content >>> actually is, along with the charset". >>> >>> (Covered in Section 2.) >> Yes; I'm questioning whether anyone reading the title will >> have any idea what "preservation strategies" means. What's >> the point of putting words into the title that don't add to >> (and actually detract from) the understanding of what the >> title means? > Barry and Sean, short of just dropping that clause, how about > "stability strategies" or "interoperability strategies"? Both > terms are well-known in the community and give much more of a > clue as to what is being discussed than "preservation". The use > of either in this context is a bit unusual, but it seems to me > that preserving interoperability and original intent as Markdown > documents move through systems is precisely what Sean is talking > about. OK. Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations -Sean --------------ms070508080207070506040304 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCC BK8wggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNV BAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJu YWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcN MTQxMjIyMDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAibEN2npTGU5wUh28VqYGJre4SeCW51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2 IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JDFnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9 KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUIkzqcKlOjENs9IGE8VQOO2U52JQIhKfqj fHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7AzaS1D6/rWpfGXd2dRjNnuJ+u8pQc4 doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZAP8vk4p+iIQIDAQABo4IBFzCC ARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYDVR0OBBYEFJJha4LhoqCq T+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0w OzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJv b3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRy dXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOc Uvi7BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc0 6HvgARClnMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLK hjQHuSzK5hxK2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6 H3kU9koQGib6fIr7mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcN AQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAyMDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRl ditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n2 0qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKPvku7E+utnLhcaNahAWr2oZgeCK9uhEqi jaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cUvZqY7YwzCG6jSfs4gwNh+29MS6fa Y6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/MwNAabNhDgxU2Tw1fl5w1Vt+6x RTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/syYhS1Ko4MSiJmR3ugKPk xEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQABo4IB8jCCAe4wHwYD VR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y8PBT6NqnIVbf NK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2 Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEE gYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1 NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGG GGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVr LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC 8IXwUmNxL7L5uE3tGlNJVoTKZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63r MlFPFrjqQCEA6rDgo9DlFO9/81P7ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3 gUs5xJT0koGVvli2wR18zecG3ib3ml+GnDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamq r3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEpqpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMC tqlHvF3YY2z55jGCBDEwggQtAgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecwCQYFKw4DAhoFAKCCAlUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwNzE0MTgzMzU2 WjAjBgkqhkiG9w0BCQQxFgQUQVpYiVwFXK8ehzvszvjWAj7uIzgwbAYJKoZIhvcNAQkPMV8w XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBwQYJKwYBBAGCNxAE MYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4 Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBpCSs8n+cQbczyWKtueyecwgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtue yecwDQYJKoZIhvcNAQEBBQAEggEAIo6Bv8tP+Z+R6YZy7d1l5PDs9JAciTzxpX9C/asy913p lUxeHGTDh0ykzrOIJPy0Z17Lup9oAsN37A1CNaRl0xfVony3lOWJe3mBtp2PKzPF1SKlSZck eX4tH0KvJEtcUIMhg1HcFDYuoRKMm3m+9KVOenym1rnJl+2Gwgcmhvei3CCNHGkPjnaEM9V7 RmDN3mOj5JgX7kLyjVR/GWfE1AO7ItbE72RwNe47i1qHB4GsQLBO3IRPtyp5VWOwYgHyC8M+ isxEvbftxTzxqKGunSGeYpDYEHTtXp940ljMx1P7XPw46IUwUHXnU/X20XJpa+Hsu4fYCkA8 EObrqmtzBAAAAAAAAA== --------------ms070508080207070506040304-- From nobody Tue Jul 14 21:28:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6FE1A039C; Mon, 13 Jul 2015 14:34: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 kaCEeUEZetB7; Mon, 13 Jul 2015 14:34: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 1BBFB1A0276; Mon, 13 Jul 2015 14:34:08 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t6DLY0Pn010195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Jul 2015 14:34:04 -0700 Message-ID: <55A42EC4.9090002@dcrocker.net> Date: Mon, 13 Jul 2015 14:33:56 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Barry Leiba , Sean Leonard References: <20150708033129.16459.55993.idtracker@ietfa.amsl.com> <6475ED7E-017E-46CD-A1B9-2755AFC2F702@seantek.com> <55A11ADE.1030204@dcrocker.net> <8DC2EA7C-19BC-4B01-A99F-818345AA24C3@seantek.com> 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, 13 Jul 2015 14:34:05 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Tue, 14 Jul 2015 21:28:23 -0700 Cc: "appsawg-chairs@ietf.org" , IETF Apps Discuss , "draft-ietf-appsawg-text-markdown-use-cases.shepherd@ietf.org" , "draft-ietf-appsawg-text-markdown-use-cases@ietf.org" , "draft-ietf-appsawg-text-markdown-use-cases.ad@ietf.org" , Dave Crocker , Terry Manderson , IESG Subject: Re: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS) 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, 13 Jul 2015 21:34:09 -0000 On 7/11/2015 3:06 PM, Barry Leiba wrote: >> However I must also say -1 to Registration of Markdown Variants >> > because the document does a lot more than the registration of certain >> > variants. > Yeh, I don't think it does, unless you want to say "Description and > Registration ...". And if you want to explain in the Abstract and > Introduction what else you're aiming at, that's fine. > I looked a little more at the draft. "Use cases" is simply wrong. I think "registration" is too narrow and maybe misleading. My current best guess: Guidance on Developing and Registering Text Markdown Variants d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 14 21:28:27 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7A11A8908; Mon, 13 Jul 2015 19:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dydH4WXzt0Y6; Mon, 13 Jul 2015 19:02:26 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DCCF1A8901; Mon, 13 Jul 2015 19:02:26 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mVlTr51zgzpL; Tue, 14 Jul 2015 04:02:24 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=UiDUV7qH X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id l1FAwpm1W5bC; Tue, 14 Jul 2015 04:02:23 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 14 Jul 2015 04:02:23 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9BF3680042; Mon, 13 Jul 2015 22:02:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1436839342; bh=hbl2kFmOj1HtaZA8FPptKPZ5gZb+V1qI3mOHtaNypaA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=UiDUV7qHUXhTGSWhCd5JerSmq3yrj10rBNsEwIIbdLD1WsJGcVrDGX53+Mgw/fv0I IdZlBRouHRIIBXPjVsh/qWG4cwfS4/uHN4GEl0irNYB9y+sO0WzN4HaUrqgdlgQ9EL 83cigfOZhjw5lUik+l0LOeH386VfMjo8zzWuHMNA= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6E22LHJ024251; Mon, 13 Jul 2015 22:02:21 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 13 Jul 2015 22:02:21 -0400 (EDT) From: Paul Wouters To: Sean Leonard In-Reply-To: <5D2E6DCF-6AFE-44EA-B367-DE30DDAC7CEF@seantek.com> Message-ID: References: <5D2E6DCF-6AFE-44EA-B367-DE30DDAC7CEF@seantek.com> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: X-Mailman-Approved-At: Tue, 14 Jul 2015 21:28:23 -0700 Cc: secdir@ietf.org, The IESG , IETF Apps Discuss , draft-ietf-appsawg-text-markdown-use-cases.all@tools.ietf.org Subject: Re: [apps-discuss] Secdir review of draft-ietf-appsawg-text-markdown-use-cases (fwd) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jul 2015 02:02:29 -0000 On Mon, 13 Jul 2015, Sean Leonard wrote: >> 2.1 talks about filesystem "extended attributes" and suggests to add a >> resource named "variant". This name might be a little too generic to >> only apply to markdown and might cause a name spaec collision that >> could potentially be a security risk. If this is a use case without >> deployed code, I would recommend renaming this resource to something >> more specific, eg "markdown-varient". If it describes actual code, >> then I guess that ship has sailed. > > It does describe some actual code. > > I can change the text to: > {{ > The variant identifier itself should be stored in a resource with a name including the term variant (possibly including other decorations to avoid namespace collisions). > }} > > How is that? Perfect. >> 2.4 talks about MIME aware clients saving a "batch script" to disk for >> later execution. These kind of "autorun" or "preview" features are >> a security nightmare, so here too I would hope this has not yet been >> coded. And if not, to reconsider not supporting such a feature. > > The purpose of this section was to suggest that if, for example, pandoc is the recipients preferred Markdown processor, and the recipient receives Markdown content in some other variant that pandoc supports (lets say original Markdown), then the recipient can send the Markdown through pandoc with the markdown_strict option; the recipient does not need to have or use Grubers original Markdown.pl implementation to get at what the sender wanted. It is not necessary for the recipient to have millions of different Markdown implementations, only that it has one (or a small handful) of implementations that are good enough for the purpose. > > There was significant discussion on apps-discuss (see around October 2014?) about how it is bad for the sender to be able to specify specific processing instructions, e.g., command-line commands or options that get sent directly to a command interpreter. So, that approach was jettisoned at that time. > > The text in Section 2.4 says: > > This strategy is to **translate** the processing instructions **inferred from** the [parameters] into a sequence of commands in the **local convention**, storing those commands in a batch script [] that are **appropriate (and safe) for the local system**. > > > (Emphasis mine.) I think those emphasized parts capture the point that whatever code gets executed has to be appropriate and safe for the local system. > > I am happy to reword this paragraph somehow, but if that is seen as necessary, I would appreciate a counterproposal. No that's fine. If you already had that discussion, and this is the outcome of that, that is good enough for me. Although perhaps an additional warning in the Security Section could be used to clarify this a little more. > A parenthetical note: Section 2.5 of text-markdown-use-cases (Process the Markdown) is a bit ambiguous. The point is to process the Markdown before the recipient sees it. Thus if you are composing an e-mail in Markdown, the point would be that your sending MUA (or an intermediary) would convert it to HTML before recipients receive the e-mail. However, your Markdown-aware sending MUA could save drafts in Markdown before the message is sent. > > Proposed text: > {{ > 2.5. Process the Markdown In Advance > > This strategy is to process the Markdown into the formal markup, before a recipient receives it, which eliminates ambiguities. Once the Markdown is processed into (for example) valid XHTML, an application can save a file as "doc.xhtml" or can send MIME content as application/xhtml+xml with no further loss of metadata. While unambiguous, this process may not be reversible. > }} Sounds good too. Paul From nobody Tue Jul 14 21:28:28 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477A51ACD3E; Tue, 14 Jul 2015 06:48:39 -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 t8rlCoNH5K-w; Tue, 14 Jul 2015 06:48:37 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ABBF1ACD3B; Tue, 14 Jul 2015 06:48:37 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F169B22E200; Tue, 14 Jul 2015 09:48:26 -0400 (EDT) Message-ID: <55A512FD.3030506@seantek.com> Date: Tue, 14 Jul 2015 06:47:41 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dcrocker@bbiw.net, Barry Leiba References: <20150708033129.16459.55993.idtracker@ietfa.amsl.com> <6475ED7E-017E-46CD-A1B9-2755AFC2F702@seantek.com> <55A11ADE.1030204@dcrocker.net> <8DC2EA7C-19BC-4B01-A99F-818345AA24C3@seantek.com> <55A42EC4.9090002@dcrocker.net> In-Reply-To: <55A42EC4.9090002@dcrocker.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030501080608000208030104" Archived-At: X-Mailman-Approved-At: Tue, 14 Jul 2015 21:28:23 -0700 Cc: "appsawg-chairs@ietf.org" , IETF Apps Discuss , "draft-ietf-appsawg-text-markdown-use-cases.shepherd@ietf.org" , "draft-ietf-appsawg-text-markdown-use-cases@ietf.org" , "draft-ietf-appsawg-text-markdown-use-cases.ad@ietf.org" , IESG , Terry Manderson Subject: Re: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jul 2015 13:48:39 -0000 This is a cryptographically signed message in MIME format. --------------ms030501080608000208030104 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 7/13/2015 2:33 PM, Dave Crocker wrote: > On 7/11/2015 3:06 PM, Barry Leiba wrote: >>> However I must also say -1 to Registration of Markdown Variants >>>> because the document does a lot more than the registration of certai= n >>>> variants. >> Yeh, I don't think it does, unless you want to say "Description and >> Registration ...". And if you want to explain in the Abstract and >> Introduction what else you're aiming at, that's fine. >> > > I looked a little more at the draft. "Use cases" is simply wrong. I > think "registration" is too narrow and maybe misleading. > > My current best guess: > > Guidance on Developing and Registering Text Markdown Variants > "Guidance" is a good term to use. Guidance on Markdown: Design Philosophies, Preservation Strategies, and Select Registrations -Sean --------------ms030501080608000208030104 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCC BK8wggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNV BAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJu YWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcN MTQxMjIyMDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAibEN2npTGU5wUh28VqYGJre4SeCW51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2 IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JDFnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9 KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUIkzqcKlOjENs9IGE8VQOO2U52JQIhKfqj fHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7AzaS1D6/rWpfGXd2dRjNnuJ+u8pQc4 doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZAP8vk4p+iIQIDAQABo4IBFzCC ARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYDVR0OBBYEFJJha4LhoqCq T+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0w OzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJv b3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRy dXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOc Uvi7BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc0 6HvgARClnMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLK hjQHuSzK5hxK2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6 H3kU9koQGib6fIr7mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcN AQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAyMDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRl ditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n2 0qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKPvku7E+utnLhcaNahAWr2oZgeCK9uhEqi jaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cUvZqY7YwzCG6jSfs4gwNh+29MS6fa Y6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/MwNAabNhDgxU2Tw1fl5w1Vt+6x RTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/syYhS1Ko4MSiJmR3ugKPk xEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQABo4IB8jCCAe4wHwYD VR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y8PBT6NqnIVbf NK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2 Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEE gYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1 NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGG GGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVr LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC 8IXwUmNxL7L5uE3tGlNJVoTKZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63r MlFPFrjqQCEA6rDgo9DlFO9/81P7ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3 gUs5xJT0koGVvli2wR18zecG3ib3ml+GnDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamq r3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEpqpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMC tqlHvF3YY2z55jGCBDEwggQtAgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecwCQYFKw4DAhoFAKCCAlUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwNzE0MTM0NzQx WjAjBgkqhkiG9w0BCQQxFgQUscE4peMri4p/pyT+xgCaymF6GRwwbAYJKoZIhvcNAQkPMV8w XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBwQYJKwYBBAGCNxAE MYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4 Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBpCSs8n+cQbczyWKtueyecwgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtue yecwDQYJKoZIhvcNAQEBBQAEggEAXmSrM9+kaxmwmBIFM2pOCDHExRDyIizhNkTbulfZcpgs 9SSXnSyyU7afCVlagInm+dkY1S1wcENdR3OMd/+oQNM3CzR3kupeMAGxwO4fHoclXLom7q4G Ald4xEBytr68dCA7hP/2ESaHXBnOgkJqSnc2EPvTxKDkEc3FDMbZSHlbVhwmZNpeUhOQz56L BPg/wGWzDswxlQ9LprfsuWvGatqw1VAqUUVyoKjbOFRREz+xnq/baPFqei58vSqgHM1H6Du+ 1WtloeldA/G31i2WMqAuZFhwT+IisdeemNix1HGKq1joMvMprGMxQ32qZhsLT1YG+pEjvgQ5 acwS3+BBcgAAAAAAAA== --------------ms030501080608000208030104-- From nobody Tue Jul 14 22:06:49 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0891A0399; Tue, 14 Jul 2015 22:06: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 1xRZgpsQXsfD; Tue, 14 Jul 2015 22:06: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 5AF6A1A00C0; Tue, 14 Jul 2015 22:06:43 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t6F56cvA030707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 14 Jul 2015 22:06:41 -0700 Message-ID: <55A5EA59.7030700@dcrocker.net> Date: Tue, 14 Jul 2015 22:06:33 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Barry Leiba , Sean Leonard References: <20150708033129.16459.55993.idtracker@ietfa.amsl.com> <6475ED7E-017E-46CD-A1B9-2755AFC2F702@seantek.com> <55A11ADE.1030204@dcrocker.net> <8DC2EA7C-19BC-4B01-A99F-818345AA24C3@seantek.com> <55A42EC4.9090002@dcrocker.net> <55A512FD.3030506@seantek.com> <55A52C90.3090402@seantek.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 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, 14 Jul 2015 22:06:42 -0700 (PDT) Archived-At: Cc: "appsawg-chairs@ietf.org" , IESG , IETF Apps Discuss , "draft-ietf-appsawg-text-markdown-use-cases@ietf.org" Subject: Re: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS) 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, 15 Jul 2015 05:06:44 -0000 On 7/14/2015 8:53 AM, Barry Leiba wrote: >> It means "how to preserve the text/markdown Content-Type along with its >> > parameters outside of MIME bodies", >> > or, "how to preserve the author's intent when the author wrote the Markdown >> > content in a certain way, so that recipients know what kind of Markdown >> > (variant) the content actually is, along with the charset". >> > >> > (Covered in Section 2.) > Yes; I'm questioning whether anyone reading the title will have any > idea what "preservation strategies" means. What's the point of > putting words into the title that don't add to (and actually detract > from) the understanding of what the title means? They won't. The title language being considered now is frankly overblown, in my view. I think I understand the appeal of that language but it is mostly the kind of appeal that works well for an author and poorly for a reader. Unless I really didn't understand what I was reading, this is a document that says something along the lines of: "Here are some basic styles of markdown types and the templates for registering for them. You might have a markdown similar to one of these, in which case you can (easily) adapt the existing one and get yours registered (easily) too." This sort of document can provide very useful guidance for the next author trying to specify and register a new markdown type. But really, this is merely guidance for specifying and registering (some) text markdown media-types. Please keep the title simple and direct and concrete, so readers will understand how the document might help them. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 14 22:51:44 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506CE1A7014; Tue, 14 Jul 2015 22:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.457 X-Spam-Level: X-Spam-Status: No, score=-99.457 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 TwpOtBayjvtM; Tue, 14 Jul 2015 22:51:32 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 1829F1A6FFF; Tue, 14 Jul 2015 22:51:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3737E180478; Tue, 14 Jul 2015 22:47:56 -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: <20150715054756.3737E180478@rfc-editor.org> Date: Tue, 14 Jul 2015 22:47:56 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] RFC 7578 on Returning Values from Forms: 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: Wed, 15 Jul 2015 05:51:33 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7578 Title: Returning Values from Forms: multipart/form-data Author: L. Masinter Status: Standards Track Stream: IETF Date: July 2015 Mailbox: masinter@adobe.com Pages: 15 Characters: 30240 Obsoletes: RFC 2388 I-D Tag: draft-ietf-appsawg-multipart-form-data-11.txt URL: https://www.rfc-editor.org/info/rfc7578 DOI: http://dx.doi.org/10.17487/RFC7578 This specification defines the multipart/form-data media type, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. This document obsoletes RFC 2388. 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 Wed Jul 15 05:56:59 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F250B1A8AE3 for ; Wed, 15 Jul 2015 05:56:57 -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 vGpdf8EVBNqx for ; Wed, 15 Jul 2015 05:56:52 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2480B1A8ACC for ; Wed, 15 Jul 2015 05:56:52 -0700 (PDT) Received: from [37.9.98.236] (unknown [89.246.67.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9E00E22E2E1; Wed, 15 Jul 2015 08:56:50 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Mark Nottingham In-Reply-To: Date: Wed, 15 Jul 2015 14:56:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <37DD6E96-7FB1-4D87-925A-64AEC381E4BA@mnot.net> References: To: Martin Thomson X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Apps Discuss Subject: Re: [apps-discuss] Extension model for http-problem X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jul 2015 12:56:58 -0000 > On 23 Jun 2015, at 1:35 am, Mark Nottingham wrote: >=20 > A completely different way of doing it would be to require that a new = version that does that to use a different media type.=20 I'm kind of warming to this approach. Thoughts? -- Mark Nottingham https://www.mnot.net/ From nobody Wed Jul 15 06:33:12 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D437F1A905D for ; Wed, 15 Jul 2015 06:33:10 -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 ukEUYM3-c8HI for ; Wed, 15 Jul 2015 06:33:09 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::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 5D7701A9058 for ; Wed, 15 Jul 2015 06:33:09 -0700 (PDT) Received: by obbop1 with SMTP id op1so26352347obb.2 for ; Wed, 15 Jul 2015 06:33:08 -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=UySLMgvDrI9d7njgyxBrsEeXSs0Ysfz3GH6Zpi3Plac=; b=KtlMT0s5NQnWAfDQPv6FIPbNJOWnZkT7PXoe/HMZh75BELbZgXnv2rBqp3DV5iQ9G+ iFzkZFEbxRhA7L4X8m2RSeI2Ok6PTb0FhEGqdtBYtasPa/wnYOR+EUwuhHPAuFdsiMIK NtWggHRpMLnuYUBT6UI045T93BKJasXIidpMI= 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=UySLMgvDrI9d7njgyxBrsEeXSs0Ysfz3GH6Zpi3Plac=; b=iL7RxCIwowoZC4N9vv8owMboaK8mlCOMRz6HJQCmLiXOnrxK+20NcDA233uPSPukOL O9Ef8TTUp68Xmn90LwI+/ECO1JOwqoxmJecTF8++DjS9Z2qhxBIoAhxlIPi+To6xO9Os Ei+LdRIffRk0GL85H5b/ukmlqJLSTRQNWOfV0q7TMgcJG54/z2AF4Kx4rC2AM6UWQm3e hDiO4Jom1r15VSVMUZCwg1UZvt1ANZeiEodTyrOoH7ma2rXVcjmyfBPtK4fj1/Evyy98 rvfsnV0PNI4+CwMOA5cHvPYn2K89+g3nXiGqaYnk6i0NN7MPo3xFLiZd9EM7gPoZSDYn M5rw== X-Gm-Message-State: ALoCoQlFQQ1HZPRQa2c7dnxB5PnNIz6fo31f1bxYijxxbSnbma3DrQOnY146VNcC3klK7v/EnJMn MIME-Version: 1.0 X-Received: by 10.182.55.74 with SMTP id q10mr3980712obp.78.1436967188792; Wed, 15 Jul 2015 06:33:08 -0700 (PDT) Received: by 10.60.67.138 with HTTP; Wed, 15 Jul 2015 06:33:08 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Jul 2015 14:33:08 +0100 Message-ID: From: Dave Cridland To: Mark Nottingham Content-Type: multipart/alternative; boundary=089e01537a12d79f39051ae9fee9 Archived-At: Cc: Apps Discuss Subject: Re: [apps-discuss] Extension model for http-problem X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jul 2015 13:33:11 -0000 --089e01537a12d79f39051ae9fee9 Content-Type: text/plain; charset=UTF-8 On 23 June 2015 at 00:35, Mark Nottingham wrote: > The difference here is that extensions are explicitly name spaced by the > type URI; there is no concept of an extension that spans multiple types > (each type would have to "opt into" it explicitly). > > As such, the problem (see what I did there?) that needs to be addressed is > handling the case where a new version of the spec defines a new standard > extension, and we want to avoid conflicts with existing extensions. > > If I understand correctly, you're talking in terms of what happens where a future version of application/problem defines new top-level keys. A key issue here is that in your "account" case, the variables "balance" and "account" could get trampled on. These variables are indistinguishable from the extensions to the problem format itself from a syntactic point of view; I think this represents a long-term problem. Instead I think per-type variables need to be within a different container: { type: "http://...", vars: { balance: 30, accounts: [] } } In other words, I agree with your initial hunch as to the solution. > A completely different way of doing it would be to require that a new > version that does that to use a different media type. > This works, of course, but means you've got a clear compatibility break, which seems like a heavy penalty to pay (and one we'd likely try to work around as a result). Dave. --089e01537a12d79f39051ae9fee9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 23 June 2015 at 00:35, Mark Nottingham <mnot@mnot.net> wr= ote:
The difference here is that extensio= ns are explicitly name spaced by the type URI; there is no concept of an ex= tension that spans multiple types (each type would have to "opt into&q= uot; it explicitly).

As such, the problem (see what I did there?) that needs to be addressed is = handling the case where a new version of the spec defines a new standard ex= tension, and we want to avoid conflicts with existing extensions.


If I understand correctly, you're = talking in terms of what happens where a future version of application/prob= lem defines new top-level keys. A key issue here is that in your "acco= unt" case, the variables "balance" and "account" c= ould get trampled on. These variables are indistinguishable from the extens= ions to the problem format itself from a syntactic point of view; I think t= his represents a long-term problem.

Instead I thin= k per-type variables need to be within a different container:
{
=C2=A0 type: "http://...",
=C2= =A0 vars: {
=C2=A0 =C2=A0 =C2=A0balance: 30,
=C2=A0 =C2= =A0 =C2=A0accounts: []
=C2=A0 }
}

<= div>In other words, I agree with your initial hunch as to the solution.
=C2=A0
A completely different way of doing it would be to require that a new versi= on that does that to use a different media type.
=C2= =A0
This works, of course, but means you've got a clear compa= tibility break, which seems like a heavy penalty to pay (and one we'd l= ikely try to work around as a result).

Dave.
=
--089e01537a12d79f39051ae9fee9-- From nobody Wed Jul 15 07:16:49 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166E81A9168 for ; Wed, 15 Jul 2015 07:16:48 -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 KUI5qST4xlUD for ; Wed, 15 Jul 2015 07:16:45 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE9F1A9171 for ; Wed, 15 Jul 2015 07:16:40 -0700 (PDT) Received: from [37.9.98.236] (unknown [89.246.67.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0F31822E25F; Wed, 15 Jul 2015 10:16:38 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Mark Nottingham In-Reply-To: Date: Wed, 15 Jul 2015 16:16:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dave Cridland X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Apps Discuss Subject: Re: [apps-discuss] Extension model for http-problem X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jul 2015 14:16:48 -0000 > On 15 Jul 2015, at 3:33 pm, Dave Cridland wrote: >=20 > If I understand correctly, you're talking in terms of what happens = where a future version of application/problem defines new top-level = keys. Yes - although it's not certain that will happen. > A key issue here is that in your "account" case, the variables = "balance" and "account" could get trampled on. These variables are = indistinguishable from the extensions to the problem format itself from = a syntactic point of view; I think this represents a long-term problem. Indeed. > Instead I think per-type variables need to be within a different = container: >=20 > { > type: "http://...", > vars: { > balance: 30, > accounts: [] > } > } >=20 > In other words, I agree with your initial hunch as to the solution. > =20 >> A completely different way of doing it would be to require that a new = version that does that to use a different media type. > =20 > This works, of course, but means you've got a clear compatibility = break, which seems like a heavy penalty to pay (and one we'd likely try = to work around as a result). How so? The producer of a problem can opt into supporting the new format = depending upon its needs. It's true that you have to negotiate the = format, but we already have a way to do that in HTTP. My reluctance to make the change now is partially due to the desire to = avoid breaking existing users of the format; for better or worse, we = have a fair number of implementations as well as users (probably because = it's sat out there for so long). -- Mark Nottingham https://www.mnot.net/ From nobody Wed Jul 15 09:41:28 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972521A1B76 for ; Wed, 15 Jul 2015 09:41:26 -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 CoBd80homqyN for ; Wed, 15 Jul 2015 09:41:25 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F161AC410 for ; Wed, 15 Jul 2015 09:41:24 -0700 (PDT) Received: by ykay190 with SMTP id y190so41248323yka.3 for ; Wed, 15 Jul 2015 09:41:24 -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=TZa3g/duUWqwn1+Eyld08VnXuaEdBmXbt+ervkjCrGA=; b=v5uXAPpipvfsOiYC9fi2vZ70fqHQhz9H1wObM6myNMeFEGvebHwN4rGMwr741sWvMh CakwIdKkKUDh0ZUJMg3qdEZUtRFSDVBxhYPNP6erjJS1CJ/HCRTwJerqHqwpaUUpttH5 hHx5kqEgkbILm0rkTaoXYH5RpPcgsLtqe6Sgc75x1FvA2k7HsOlFhyv/OZ020JjMQBnL zYdyztzZblqfib6eeQhYLU97gseQsI3boxs7KyzqniCcZ2rx7nJmevsQGSqtA2pte3Kl NCfX4RD/c47iXiW6io/cF7f+N7x1nBOYOogoSi3GJ2slP5eph62ctb9ZrQImFl1cOT+n DX/g== MIME-Version: 1.0 X-Received: by 10.129.93.136 with SMTP id r130mr5430304ywb.52.1436978483999; Wed, 15 Jul 2015 09:41:23 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 15 Jul 2015 09:41:23 -0700 (PDT) In-Reply-To: <37DD6E96-7FB1-4D87-925A-64AEC381E4BA@mnot.net> References: <37DD6E96-7FB1-4D87-925A-64AEC381E4BA@mnot.net> Date: Wed, 15 Jul 2015 09:41:23 -0700 Message-ID: From: Martin Thomson To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Apps Discuss Subject: Re: [apps-discuss] Extension model for http-problem X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jul 2015 16:41:26 -0000 On 15 July 2015 at 05:56, Mark Nottingham wrote: >> A completely different way of doing it would be to require that a new version that does that to use a different media type. > > I'm kind of warming to this approach. Thoughts? As long as you don't attempt to proscribe ad-hoc additions I think that it's a fine idea. From nobody Wed Jul 15 13:18:30 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5031AD36F; Wed, 15 Jul 2015 13:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DzkaXPejV6v; Wed, 15 Jul 2015 13:18:26 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E44FB1AD364; Wed, 15 Jul 2015 13:18:24 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6FKIEIZ033936 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 15 Jul 2015 15:18:24 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: DISPATCH , "IETF Apps Discuss" Date: Wed, 15 Jul 2015 15:18:13 -0500 Message-ID: <521E2A2C-D25E-4B54-B038-CBA0A44D877B@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: [apps-discuss] draft-campbell-art-rfc5727-update-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: Wed, 15 Jul 2015 20:18:27 -0000 [oops, resending with the correct address for the appsawg.] Hi, RFC5727 describes the SIP Change process, part of which is the DISPATCH process. Much of the language in that RFC was "hard-coded" to RAI and its working group structure. While the concepts are still valid, some of the language has become obsolete since we've combined APP and RAI into ART. The ART ADs have written an draft that seeks to correct that, and also to generalize the dispatch process so it can be used by other working groups and areas. We wrote this as an update rather than a "bis" draft, in order focus on the organizational changes and keep the "good parts" of RFC 5727 intact. Please comment. https://tools.ietf.org/html/draft-campbell-art-rfc5727-update-02 Thanks! Ben. From nobody Thu Jul 16 11:35:24 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75A21B2DBC for ; Thu, 16 Jul 2015 11:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 mLvBceb3PXC4 for ; Thu, 16 Jul 2015 11:35:21 -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 E5DCF1B2D03 for ; Thu, 16 Jul 2015 11:35:20 -0700 (PDT) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1ZFo04-0002Bk-bx; Thu, 16 Jul 2015 19:35:16 +0100 Received: from client0939.vpn.ox.ac.uk ([129.67.119.171] helo=conina.local) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZFo04-0003jp-Le; Thu, 16 Jul 2015 19:35:16 +0100 Message-ID: <55A7F955.70906@ninebynine.org> Date: Thu, 16 Jul 2015 19:35:01 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , Dave Thaler Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: iana-prot-param-comment@iana.org Subject: [apps-discuss] Comments on new procedure for URI scheme registration (BCP35/RFC7595) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jul 2015 18:35:22 -0000 I've just responded in my role of DE to a first request to review a URI scheme registration under the new procedure defined by BCP35/RFC7595 [1], and I think this has uncovered a small problem. [1] https://tools.ietf.org/html/rfc7595 Strictly, the request did not need to come to me, since it was for a provisional registration, which should be treated thus: [[ 1. IANA checks the submission for completeness; if required sections of the scheme registration request are missing or any citations are not correct, IANA will reject the registration request. A registrant can resubmit a corrected request if desired. 2. If the request is for 'provisional' registration and no entry already exists in the current registry for the same name, IANA adds the registration to the registry under the First Come First Served policy. ]] -- https://tools.ietf.org/html/rfc7595#section-7.2 But the procedure document also says: [[ o The scheme definition SHOULD include clear security considerations (Section 3.7) or explain why a full security analysis is not available (e.g., in a third-party scheme registration). o If the scheme definition does not meet the guidelines laid out in Section 3, the differences and reasons SHOULD be noted. ]] -- https://tools.ietf.org/html/rfc7595#section-4 The problem I see is that there is no way to check the SHOULD requirements here (in sect 4), in particular with regard to security considerations, since these are no longer part of the registration template but are expected to be in the defining document: [[ The previous version of this specification required the following additional fields in a scheme registration request. These fields are no longer part of the template. The answers instead belong in the scheme specification. : Security considerations: See Section 3.7 for guidelines. ]] -- https://tools.ietf.org/html/rfc7595#section-7.4 My understanding is that IANA are not expected to read and understand the actual specification document, so they cannot check this, and the DE should not see these registration requests. ... My suggestion is that the apparently normative language in section 4 be treated as advice to be followed by the submitter, and that a future revision of the procedure makes this clearer. #g -- From nobody Thu Jul 16 11:36:47 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C141A1B66; Wed, 15 Jul 2015 12:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyUepqFQs28M; Wed, 15 Jul 2015 12:40:57 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203871A1B62; Wed, 15 Jul 2015 12:40:57 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 15 Jul 2015 12:40:55 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Wed, 15 Jul 2015 12:40:55 -0700 From: Terry Manderson To: "dcrocker@bbiw.net" , Barry Leiba , Sean Leonard Thread-Topic: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS) Thread-Index: AQHQuS9n6q+QKRTI4kq9y+fJ+vXm5J3R9syAgAF1iYCAAqkwgIAAJI0AgACE5gCAAHm2gIAAFhqAgAMbcACAARAQgIAAGJ4AgAAF3gCAAATHAIAA3XeAgAGb6wA= Date: Wed, 15 Jul 2015 19:40:54 +0000 Message-ID: References: <20150708033129.16459.55993.idtracker@ietfa.amsl.com> <6475ED7E-017E-46CD-A1B9-2755AFC2F702@seantek.com> <55A11ADE.1030204@dcrocker.net> <8DC2EA7C-19BC-4B01-A99F-818345AA24C3@seantek.com> <55A42EC4.9090002@dcrocker.net> <55A512FD.3030506@seantek.com> <55A52C90.3090402@seantek.com> <55A5EA59.7030700@dcrocker.net> In-Reply-To: <55A5EA59.7030700@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.35.1] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3519870052_5473815" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 16 Jul 2015 11:36:47 -0700 Cc: "appsawg-chairs@ietf.org" , The IESG , IETF Apps Discuss , "draft-ietf-appsawg-text-markdown-use-cases@ietf.org" Subject: Re: [apps-discuss] Terry Manderson's Discuss on draft-ietf-appsawg-text-markdown-use-cases-02: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jul 2015 19:40:58 -0000 --B_3519870052_5473815 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 15/07/2015 3:06 pm, "iesg on behalf of Dave Crocker" wrote: > > >They won't. The title language being considered now is frankly >overblown, in my view. > [..] I have to be frank here, I expected this to be a _very simple_ DISCUSS and easy to clear as it's about the document's use being 'clear and accurate for the reader'. That is all. > >But really, this is merely guidance for specifying and registering >(some) text markdown media-types. Please keep the title simple and >direct and concrete, so readers will understand how the document might >help them. Indeed. I'll leave consensus on the title/description in Barry's and Murray's hands and clear my DISCUSS. Cheers Terry --B_3519870052_5473815 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFE78 RHiHcH04N7967DupKOXVAsEzMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE1MDcxNTE5NDA1MlowDQYJKoZIhvcNAQEBBQAEggEAHEeMH2kHPFzq3lMp9C4q ODovxmkksHhEE0yXooLkSRORKoeQXpPxE7OpIokua/zdVEpqGcdwDdAiCanezKV/ZOrQ1vRn 0/wYJH8R9aY8OdDLHmcztoo80F2S0UPuHql8qsg2B98tGJC1UKdJNZ+mYKOEAOfJvFjFjHyP /cxadRGGJObP2qe+6vsFkSZ7sbs3HDAaHnV7E4uDj9KZelv70QmwvE5bXrSRRoBGn8E2H3dO HLvQvd/Ot3zQjUuzm4/fxKE7JQTPNJx4POdtVeqCF0yT6qM5Fwfvm/5S9d3HK3a0AiVK8K1H xdT2vK3aHfJclkJWQVLpfSYPwbNV0c3eXw== --B_3519870052_5473815-- From nobody Thu Jul 16 11:41:14 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046871B2E32 for ; Thu, 16 Jul 2015 11:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 w--roSwjZ9of for ; Thu, 16 Jul 2015 11:41:11 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0104.outbound.protection.outlook.com [65.55.169.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA9441B2E30 for ; Thu, 16 Jul 2015 11:41:10 -0700 (PDT) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) with Microsoft SMTP Server (TLS) id 15.1.213.10; Thu, 16 Jul 2015 18:41:08 +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.01.0213.000; Thu, 16 Jul 2015 18:41:08 +0000 From: Dave Thaler To: Graham Klyne , "apps-discuss@ietf.org" Thread-Topic: Comments on new procedure for URI scheme registration (BCP35/RFC7595) Thread-Index: AQHQv/Yss9mly9FOqU+BujNmVfjlgJ3ebNbQ Date: Thu, 16 Jul 2015 18:41:08 +0000 Message-ID: References: <55A7F955.70906@ninebynine.org> In-Reply-To: <55A7F955.70906@ninebynine.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ninebynine.org; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:ed31::3] x-microsoft-exchange-diagnostics: 1; BY2PR03MB412; 5:FZyucMlWGq131dqWqZN8hViEwCyyBnid6j1n3PCAVIoPMQ5Nxr4mBsO3La6XYqw6qij69gerYwcrbeGGwzwLCukqkG//eaG7unIpk7RqbMSBaTz4+AzZxlEOn+MD0IjYZWgmG6DZXnJdgR69Wu8F/g==; 24:qmCRkn3uoMndWIJDjpQafkmf+vLbYRzO/POEIbPotT0EEMb547i+QQxUQf8Daz8jHIbdtoYAUWAWLOl31pfjHDcxgVbiRWYHtkV2LeR91JQ=; 20:ujSF5e7TIaqb19rQXJWceP8KIqXIS9L9c3pAiaAxB6e49SVzfbxEpqIU6vBeQkkBK7ovH71wUOGbXw6ZR8s2fA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB412; by2pr03mb412: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB412; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB412; x-forefront-prvs: 0639027A9E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(40100003)(62966003)(77156002)(50986999)(46102003)(5001770100001)(122556002)(76576001)(74316001)(106116001)(99286002)(33656002)(92566002)(54356999)(87936001)(76176999)(86362001)(5003600100002)(2656002)(19580395003)(19580405001)(102836002)(2950100001)(2501003)(5001920100001)(15975445007)(77096005)(2900100001)(5001960100002)(5002640100001)(189998001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB412; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2015 18:41:08.4421 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB412 Archived-At: Cc: "iana-prot-param-comment@iana.org" Subject: Re: [apps-discuss] Comments on new procedure for URI scheme registration (BCP35/RFC7595) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jul 2015 18:41:13 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBHcmFoYW0gS2x5bmUgW21haWx0 bzpna0BuaW5lYnluaW5lLm9yZ10NCj4gU2VudDogVGh1cnNkYXksIEp1bHkgMTYsIDIwMTUgMTE6 MzUgQU0NCj4gVG86IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZzsgRGF2ZSBUaGFsZXINCj4gQ2M6IGlh bmEtcHJvdC1wYXJhbS1jb21tZW50QGlhbmEub3JnDQo+IFN1YmplY3Q6IENvbW1lbnRzIG9uIG5l dyBwcm9jZWR1cmUgZm9yIFVSSSBzY2hlbWUgcmVnaXN0cmF0aW9uDQo+IChCQ1AzNS9SRkM3NTk1 KQ0KPiANCj4gSSd2ZSBqdXN0IHJlc3BvbmRlZCBpbiBteSByb2xlIG9mIERFIHRvIGEgZmlyc3Qg cmVxdWVzdCB0byByZXZpZXcgYSBVUkkgc2NoZW1lDQo+IHJlZ2lzdHJhdGlvbiB1bmRlciB0aGUg bmV3IHByb2NlZHVyZSBkZWZpbmVkIGJ5IEJDUDM1L1JGQzc1OTUgWzFdLCBhbmQgSQ0KPiB0aGlu ayB0aGlzIGhhcyB1bmNvdmVyZWQgYSBzbWFsbCBwcm9ibGVtLg0KPiANCj4gWzFdIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTk1DQo+IA0KPiBTdHJpY3RseSwgdGhlIHJlcXVlc3Qg ZGlkIG5vdCBuZWVkIHRvIGNvbWUgdG8gbWUsIHNpbmNlIGl0IHdhcyBmb3IgYSBwcm92aXNpb25h bA0KPiByZWdpc3RyYXRpb24sIHdoaWNoIHNob3VsZCBiZSB0cmVhdGVkIHRodXM6DQo+IA0KPiBb Ww0KPiAgICAgMS4gIElBTkEgY2hlY2tzIHRoZSBzdWJtaXNzaW9uIGZvciBjb21wbGV0ZW5lc3M7 IGlmIHJlcXVpcmVkIHNlY3Rpb25zDQo+ICAgICAgICAgb2YgdGhlIHNjaGVtZSByZWdpc3RyYXRp b24gcmVxdWVzdCBhcmUgbWlzc2luZyBvciBhbnkgY2l0YXRpb25zDQo+ICAgICAgICAgYXJlIG5v dCBjb3JyZWN0LCBJQU5BIHdpbGwgcmVqZWN0IHRoZSByZWdpc3RyYXRpb24gcmVxdWVzdC4gIEEN Cj4gICAgICAgICByZWdpc3RyYW50IGNhbiByZXN1Ym1pdCBhIGNvcnJlY3RlZCByZXF1ZXN0IGlm IGRlc2lyZWQuDQo+IA0KPiAgICAgMi4gIElmIHRoZSByZXF1ZXN0IGlzIGZvciAncHJvdmlzaW9u YWwnIHJlZ2lzdHJhdGlvbiBhbmQgbm8gZW50cnkNCj4gICAgICAgICBhbHJlYWR5IGV4aXN0cyBp biB0aGUgY3VycmVudCByZWdpc3RyeSBmb3IgdGhlIHNhbWUgbmFtZSwgSUFOQQ0KPiAgICAgICAg IGFkZHMgdGhlIHJlZ2lzdHJhdGlvbiB0byB0aGUgcmVnaXN0cnkgdW5kZXIgdGhlIEZpcnN0IENv bWUgRmlyc3QNCj4gICAgICAgICBTZXJ2ZWQgcG9saWN5Lg0KPiBdXQ0KPiAtLSBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNzU5NSNzZWN0aW9uLTcuMg0KPiANCj4gQnV0IHRoZSBwcm9j ZWR1cmUgZG9jdW1lbnQgYWxzbyBzYXlzOg0KPiBbWw0KPiAgICAgbyAgVGhlIHNjaGVtZSBkZWZp bml0aW9uIFNIT1VMRCBpbmNsdWRlIGNsZWFyIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zDQo+ICAg ICAgICAoU2VjdGlvbiAzLjcpIG9yIGV4cGxhaW4gd2h5IGEgZnVsbCBzZWN1cml0eSBhbmFseXNp cyBpcyBub3QNCj4gICAgICAgIGF2YWlsYWJsZSAoZS5nLiwgaW4gYSB0aGlyZC1wYXJ0eSBzY2hl bWUgcmVnaXN0cmF0aW9uKS4NCj4gDQo+ICAgICBvICBJZiB0aGUgc2NoZW1lIGRlZmluaXRpb24g ZG9lcyBub3QgbWVldCB0aGUgZ3VpZGVsaW5lcyBsYWlkIG91dCBpbg0KPiAgICAgICAgU2VjdGlv biAzLCB0aGUgZGlmZmVyZW5jZXMgYW5kIHJlYXNvbnMgU0hPVUxEIGJlIG5vdGVkLg0KPiBdXQ0K PiAtLSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzU5NSNzZWN0aW9uLTQNCj4gDQo+ IFRoZSBwcm9ibGVtIEkgc2VlIGlzIHRoYXQgdGhlcmUgaXMgbm8gd2F5IHRvIGNoZWNrIHRoZSBT SE9VTEQgcmVxdWlyZW1lbnRzDQo+IGhlcmUgKGluIHNlY3QgNCksIGluIHBhcnRpY3VsYXIgd2l0 aCByZWdhcmQgdG8gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMsIHNpbmNlIHRoZXNlDQo+IGFyZSBu byBsb25nZXIgcGFydCBvZiB0aGUgcmVnaXN0cmF0aW9uIHRlbXBsYXRlIGJ1dCBhcmUgZXhwZWN0 ZWQgdG8gYmUgaW4gdGhlDQo+IGRlZmluaW5nIGRvY3VtZW50Og0KPiANCj4gW1sNCj4gICAgIFRo ZSBwcmV2aW91cyB2ZXJzaW9uIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiByZXF1aXJlZCB0aGUgZm9s bG93aW5nDQo+ICAgICBhZGRpdGlvbmFsIGZpZWxkcyBpbiBhIHNjaGVtZSByZWdpc3RyYXRpb24g cmVxdWVzdC4gIFRoZXNlIGZpZWxkcyBhcmUNCj4gICAgIG5vIGxvbmdlciBwYXJ0IG9mIHRoZSB0 ZW1wbGF0ZS4gIFRoZSBhbnN3ZXJzIGluc3RlYWQgYmVsb25nIGluIHRoZQ0KPiAgICAgc2NoZW1l IHNwZWNpZmljYXRpb24uDQo+IA0KPiAgICAgOg0KPiANCj4gICAgIFNlY3VyaXR5IGNvbnNpZGVy YXRpb25zOg0KPiAgICAgICBTZWUgU2VjdGlvbiAzLjcgZm9yIGd1aWRlbGluZXMuDQo+IF1dDQo+ IC0tIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTk1I3NlY3Rpb24tNy40DQo+IA0K PiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgSUFOQSBhcmUgbm90IGV4cGVjdGVkIHRvIHJlYWQg YW5kIHVuZGVyc3RhbmQgdGhlDQo+IGFjdHVhbA0KPiBzcGVjaWZpY2F0aW9uIGRvY3VtZW50LCBz byB0aGV5IGNhbm5vdCBjaGVjayB0aGlzLCBhbmQgdGhlIERFIHNob3VsZCBub3Qgc2VlDQo+IHRo ZXNlIHJlZ2lzdHJhdGlvbiByZXF1ZXN0cy4NCj4gDQo+IC4uLg0KPiANCj4gTXkgc3VnZ2VzdGlv biBpcyB0aGF0IHRoZSBhcHBhcmVudGx5IG5vcm1hdGl2ZSBsYW5ndWFnZSBpbiBzZWN0aW9uIDQg YmUNCj4gdHJlYXRlZA0KPiBhcyBhZHZpY2UgdG8gYmUgZm9sbG93ZWQgYnkgdGhlIHN1Ym1pdHRl ciwgYW5kIHRoYXQgYSBmdXR1cmUgcmV2aXNpb24gb2YgdGhlDQo+IHByb2NlZHVyZSBtYWtlcyB0 aGlzIGNsZWFyZXIuDQo+IA0KPiAjZw0KPiAtLQ0KDQpJIGFncmVlLiAgIEkgZG9uJ3QgdGhpbmsg dGhpcyB3YXMgaW50ZW50aW9uYWwuICAgVGhlIGxhc3QgdGhyZWUgYnVsbGV0cyBvZiBzZWN0aW9u IDQNCmZhbGwgaW50byB0aGlzIGNhdGVnb3J5Og0KPiAgIG8gIElmIG5vIHBlcm1hbmVudCwgY2l0 YWJsZSBzcGVjaWZpY2F0aW9uIGZvciB0aGUgc2NoZW1lIGRlZmluaXRpb24NCj4gICAgICBpcyBp bmNsdWRlZCwgY3JlZGlibGUgcmVhc29ucyBmb3Igbm90IHByb3ZpZGluZyBpdCBTSE9VTEQgYmUN Cj4gICAgICBnaXZlbi4NCj4NCj4gICBvICBUaGUgc2NoZW1lIGRlZmluaXRpb24gU0hPVUxEIGlu Y2x1ZGUgY2xlYXIgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMNCj4gICAgICAoU2VjdGlvbiAzLjcp IG9yIGV4cGxhaW4gd2h5IGEgZnVsbCBzZWN1cml0eSBhbmFseXNpcyBpcyBub3QNCj4gICAgICBh dmFpbGFibGUgKGUuZy4sIGluIGEgdGhpcmQtcGFydHkgc2NoZW1lIHJlZ2lzdHJhdGlvbikuDQo+ DQo+ICAgbyAgSWYgdGhlIHNjaGVtZSBkZWZpbml0aW9uIGRvZXMgbm90IG1lZXQgdGhlIGd1aWRl bGluZXMgbGFpZCBvdXQgaW4NCj4gICAgICBTZWN0aW9uIDMsIHRoZSBkaWZmZXJlbmNlcyBhbmQg cmVhc29ucyBTSE9VTEQgYmUgbm90ZWQuDQoNCkdyYWhhbSB3b3VsZCB5b3UgbGlrZSB0byBmaWxl IGFuIGVycmF0YT8NCg0KVGhlIG5vcm1hdGl2ZSBsYW5ndWFnZSBpbiBhbiBlYXJsaWVyIGJ1bGxl dCBzdGlsbCBhcHBsaWVzOg0KPiAgIG8gIENvbnRhY3QgaW5mb3JtYXRpb24gaWRlbnRpZnlpbmcg dGhlIHBlcnNvbiBzdXBwbHlpbmcgdGhlDQo+ICAgICAgcmVnaXN0cmF0aW9uIG11c3QgYmUgaW5j bHVkZWQuICBQcmV2aW91c2x5IHVucmVnaXN0ZXJlZCBzY2hlbWVzDQo+ICAgICAgZGlzY292ZXJl ZCBpbiB1c2UgY2FuIGJlIHJlZ2lzdGVyZWQgYnkgdGhpcmQgcGFydGllcyAoZXZlbiBpZiBub3QN Cj4gICAgICBvbiBiZWhhbGYgb2YgdGhvc2Ugd2hvIGNyZWF0ZWQgdGhlIHNjaGVtZSkuICBJbiB0 aGlzIGNhc2UsIGJvdGgNCj4gICAgICB0aGUgcmVnaXN0ZXJpbmcgcGFydHkgYW5kIHRoZSBzY2hl bWUgY3JlYXRvciBTSE9VTEQgYmUgaWRlbnRpZmllZC4NCg0KU28gdGhlIGVycmF0YSBzaG91bGQg cmVmZXIgb25seSB0aGUgbGFzdCB0aHJlZSBidWxsZXRzLCBub3QgYWxsIG9mIHNlY3Rpb24gNC4N Cg0KRGF2ZQ0KDQo= From nobody Thu Jul 16 15:31:22 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8956C1A9237 for ; Thu, 16 Jul 2015 15:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LycvIvpkzHQM for ; Thu, 16 Jul 2015 15:31:19 -0700 (PDT) Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65D5B1A9175 for ; Thu, 16 Jul 2015 15:31:19 -0700 (PDT) Received: from 108-67-65-66.lightspeed.sntcca.sbcglobal.net ([108.67.65.66] helo=[192.168.1.76]) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1ZFrgS-0003vs-9D; Thu, 16 Jul 2015 15:31:17 -0700 Message-ID: <55A830B1.3010103@berkeley.edu> Date: Thu, 16 Jul 2015 15:31:13 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Apps Discuss References: <37DD6E96-7FB1-4D87-925A-64AEC381E4BA@mnot.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Mark Nottingham Subject: Re: [apps-discuss] Extension model for http-problem X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jul 2015 22:31:20 -0000 hello. On 2015-07-15 9:41 , Martin Thomson wrote: > On 15 July 2015 at 05:56, Mark Nottingham wrote: >>> A completely different way of doing it would be to require that a new version that does that to use a different media type. >> I'm kind of warming to this approach. Thoughts? > As long as you don't attempt to proscribe ad-hoc additions I think > that it's a fine idea. just throwing it out as another possibility: extensions could also use a profile media type parameter (a la RFC 6906), identifying the specific flavor they are using. vanilla consumers could still look at the http-problem fields as usual, and those supporting the specific profile would know which rules to follow when looking at extensions. it's basically the same as the "namespace URI in the format" idea, only that this time, that URI can be exposed as part of the media type. for this to work, the profile media type parameter would have to be defined for the http-problem media type, and there probably would have to be a "SHOULD" saying that extensions should be exposed that way. 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 Jul 17 12:40:06 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3BE1A009D for ; Fri, 17 Jul 2015 12:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSHR7PWyL4ol for ; Fri, 17 Jul 2015 12:40:04 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id DBEA21A003B for ; Fri, 17 Jul 2015 12:40:04 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id EF72218046E; Fri, 17 Jul 2015 12:36:24 -0700 (PDT) To: pbryan@anode.ca, mnot@mnot.net, barryleiba@computer.org, superuser@gmail.com, alexey.melnikov@isode.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150717193624.EF72218046E@rfc-editor.org> Date: Fri, 17 Jul 2015 12:36:24 -0700 (PDT) Archived-At: Cc: apps-discuss@ietf.org, brettz9@yaho.com, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Technical Errata Reported] RFC6902 (4419) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jul 2015 19:40:06 -0000 The following errata report has been submitted for RFC6902, "JavaScript Object Notation (JSON) Patch". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6902&eid=4419 -------------------------------------- Type: Technical Reported by: Brett Zamir Section: A.14 Original Text ------------- An example target JSON document: { "/": 9, "~1": 10 } A JSON Patch document: [ {"op": "test", "path": "/~01", "value": 10} ] The resulting JSON document: { "/": 9, "~1": 10 } Corrected Text -------------- Proper JSON Pointer escaping should occur when resolving paths for application to the target document. An example target JSON document: { "/": 9, "~1": 10 } A JSON Patch document: [ {"op": "add", "path": "/~01", "value": 11} ] The resulting JSON document: { "/": 9, "~1": 11 } Notes ----- At http://tools.ietf.org/html/rfc6902#appendix-A.14 , I have a few issues: 1. Even though JSON Pointer is referenced elsewhere, I think reference ought to be made here to JSON Pointer in order to clarify what meaning "escape ordering" has here. 2. The operation indicated in this section is "test" which is not documented in its respective sections as returning any kind of document at all. I believe "add" or "replace" must have been the intended operation instead. And to make clear that the value of key "~1" would have actually been affected by such a modifying operation, the value in the result ought to differ from that in the original document. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6902 (draft-ietf-appsawg-json-patch-10) -------------------------------------- Title : JavaScript Object Notation (JSON) Patch Publication Date : April 2013 Author(s) : P. Bryan, Ed., M. Nottingham, Ed. Category : PROPOSED STANDARD Source : Applications Area Working Group APP Area : Applications Stream : IETF Verifying Party : IESG From nobody Fri Jul 17 13:50:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9095C1A1C04 for ; Fri, 17 Jul 2015 13:50:24 -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 6NlR-wGz3XXX for ; Fri, 17 Jul 2015 13:50:22 -0700 (PDT) Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) by ietfa.amsl.com (Postfix) with ESMTP id 42AF11A1BCF for ; Fri, 17 Jul 2015 13:50:22 -0700 (PDT) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1ZGCaK-000126-sS; Fri, 17 Jul 2015 21:50:20 +0100 Received: from gklyne38.plus.com ([81.174.129.24] helo=conina.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZGCaK-0004Rp-FK; Fri, 17 Jul 2015 21:50:20 +0100 Message-ID: <55A96A89.70109@ninebynine.org> Date: Fri, 17 Jul 2015 21:50:17 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Dave Thaler , "apps-discuss@ietf.org" References: <55A7F955.70906@ninebynine.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Subject: Re: [apps-discuss] Comments on new procedure for URI scheme registration (BCP35/RFC7595) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jul 2015 20:50:24 -0000 Erratum submitted. #g -- On 16/07/2015 19:41, Dave Thaler wrote: >> -----Original Message----- >> From: Graham Klyne [mailto:gk@ninebynine.org] >> Sent: Thursday, July 16, 2015 11:35 AM >> To: apps-discuss@ietf.org; Dave Thaler >> Cc: iana-prot-param-comment@iana.org >> Subject: Comments on new procedure for URI scheme registration >> (BCP35/RFC7595) >> >> I've just responded in my role of DE to a first request to review a URI scheme >> registration under the new procedure defined by BCP35/RFC7595 [1], and I >> think this has uncovered a small problem. >> >> [1] https://tools.ietf.org/html/rfc7595 >> >> Strictly, the request did not need to come to me, since it was for a provisional >> registration, which should be treated thus: >> >> [[ >> 1. IANA checks the submission for completeness; if required sections >> of the scheme registration request are missing or any citations >> are not correct, IANA will reject the registration request. A >> registrant can resubmit a corrected request if desired. >> >> 2. If the request is for 'provisional' registration and no entry >> already exists in the current registry for the same name, IANA >> adds the registration to the registry under the First Come First >> Served policy. >> ]] >> -- https://tools.ietf.org/html/rfc7595#section-7.2 >> >> But the procedure document also says: >> [[ >> o The scheme definition SHOULD include clear security considerations >> (Section 3.7) or explain why a full security analysis is not >> available (e.g., in a third-party scheme registration). >> >> o If the scheme definition does not meet the guidelines laid out in >> Section 3, the differences and reasons SHOULD be noted. >> ]] >> -- https://tools.ietf.org/html/rfc7595#section-4 >> >> The problem I see is that there is no way to check the SHOULD requirements >> here (in sect 4), in particular with regard to security considerations, since these >> are no longer part of the registration template but are expected to be in the >> defining document: >> >> [[ >> The previous version of this specification required the following >> additional fields in a scheme registration request. These fields are >> no longer part of the template. The answers instead belong in the >> scheme specification. >> >> : >> >> Security considerations: >> See Section 3.7 for guidelines. >> ]] >> -- https://tools.ietf.org/html/rfc7595#section-7.4 >> >> My understanding is that IANA are not expected to read and understand the >> actual >> specification document, so they cannot check this, and the DE should not see >> these registration requests. >> >> ... >> >> My suggestion is that the apparently normative language in section 4 be >> treated >> as advice to be followed by the submitter, and that a future revision of the >> procedure makes this clearer. >> >> #g >> -- > > I agree. I don't think this was intentional. The last three bullets of section 4 > fall into this category: >> o If no permanent, citable specification for the scheme definition >> is included, credible reasons for not providing it SHOULD be >> given. >> >> o The scheme definition SHOULD include clear security considerations >> (Section 3.7) or explain why a full security analysis is not >> available (e.g., in a third-party scheme registration). >> >> o If the scheme definition does not meet the guidelines laid out in >> Section 3, the differences and reasons SHOULD be noted. > > Graham would you like to file an errata? > > The normative language in an earlier bullet still applies: >> o Contact information identifying the person supplying the >> registration must be included. Previously unregistered schemes >> discovered in use can be registered by third parties (even if not >> on behalf of those who created the scheme). In this case, both >> the registering party and the scheme creator SHOULD be identified. > > So the errata should refer only the last three bullets, not all of section 4. > > Dave > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Fri Jul 17 14:03:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FF91A212D; Fri, 17 Jul 2015 14:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDXUJJ95ceoz; Fri, 17 Jul 2015 14:03:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id E41131A1EFE; Fri, 17 Jul 2015 14:03:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D5CB7180452; Fri, 17 Jul 2015 13:59:41 -0700 (PDT) To: gk-ietf@ninebynine.org, dthaler@microsoft.com, tony+urireg@maillennium.att.com, ted.ietf@gmail.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150717205941.D5CB7180452@rfc-editor.org> Date: Fri, 17 Jul 2015 13:59:41 -0700 (PDT) Archived-At: Cc: barryleiba@computer.org, iesg@ietf.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Errata Verified] RFC7595 (4420) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jul 2015 21:03:23 -0000 The following errata report has been verified for RFC7595, "Guidelines and Registration Procedures for URI Schemes". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7595&eid=4420 -------------------------------------- Status: Verified Type: Technical Reported by: Graham Klyne Date Reported: 2015-07-17 Verified by: Barry Leiba (IESG) Section: 4 Original Text ------------- o If no permanent, citable specification for the scheme definition is included, credible reasons for not providing it SHOULD be given. o The scheme definition SHOULD include clear security considerations (Section 3.7) or explain why a full security analysis is not available (e.g., in a third-party scheme registration). o If the scheme definition does not meet the guidelines laid out in Section 3, the differences and reasons SHOULD be noted. Corrected Text -------------- Submitters are also encouraged to provide the following information as appropriate: o If no permanent, citable specification for the scheme definition is included, credible reasons for not providing it. o Clear security considerations (cf. Section 3.7), or an explanation of why a security analysis is not available (e.g., in a third- party scheme registration). o A note of and reasons for any deviations from the guidelines for permanent registrations laid out in Section 3. Notes ----- The original text states a number of normative requirements on provisional registration of URI schemes, but the procedure for these ("first come first served") cannot reasonably be expected to check that they are satisfied. The revision proposed here changes the text to encourage submitters to provide this information, without giving it force of a normative requirement. For more details, see: https://mailarchive.ietf.org/arch/msg/apps-discuss/wsEAsWC1viE8YL1WfGkaW_NzMpg The document editor has agreed the original text does not reflect the intent of the registration procedure: https://mailarchive.ietf.org/arch/msg/apps-discuss/uPb33G9duZlrwNcdCFUJmvcPLgk -------------------------------------- RFC7595 (draft-ietf-appsawg-uri-scheme-reg-06) -------------------------------------- Title : Guidelines and Registration Procedures for URI Schemes Publication Date : June 2015 Author(s) : D. Thaler, Ed., T. Hansen, T. Hardie Category : BEST CURRENT PRACTICE Source : Applications Area Working Group Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Sun Jul 19 12:23:21 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B098B1A1BE0 for ; Fri, 17 Jul 2015 13:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1KAJEWGg9m5 for ; Fri, 17 Jul 2015 13:48:48 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 69B881A1BCF for ; Fri, 17 Jul 2015 13:48:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5A43A180452; Fri, 17 Jul 2015 13:45:08 -0700 (PDT) To: dthaler@microsoft.com, tony+urireg@maillennium.att.com, ted.ietf@gmail.com, ben@nostrum.com, alissa@cooperw.in, barryleiba@computer.org, superuser@gmail.com, alexey.melnikov@isode.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150717204508.5A43A180452@rfc-editor.org> Date: Fri, 17 Jul 2015 13:45:08 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Sun, 19 Jul 2015 12:23:19 -0700 Cc: gk-ietf@ninebynine.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Technical Errata Reported] RFC7595 (4420) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jul 2015 20:48:49 -0000 The following errata report has been submitted for RFC7595, "Guidelines and Registration Procedures for URI Schemes". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7595&eid=4420 -------------------------------------- Type: Technical Reported by: Graham Klyne Section: 4 Original Text ------------- o If no permanent, citable specification for the scheme definition is included, credible reasons for not providing it SHOULD be given. o The scheme definition SHOULD include clear security considerations (Section 3.7) or explain why a full security analysis is not available (e.g., in a third-party scheme registration). o If the scheme definition does not meet the guidelines laid out in Section 3, the differences and reasons SHOULD be noted. Corrected Text -------------- Submitters are also encouraged to provide the following information as appropriate: o If no permanent, citable specification for the scheme definition is included, credible reasons for not providing it. o Clear security considerations (cf. Section 3.7), or an explanation of why a security analysis is not available (e.g., in a third- party scheme registration). o A note of and reasons for any deviations from the guidelines for permanent registrations laid out in Section 3. Notes ----- The original text states a number of normative requirements on provisional registration of URI schemes, but the procedure for these ("first come first served") cannot reasonably be expected to check that they are satisfied. The revision proposed here changes the text to encourage submitters to provide this information, without giving it force of a normative requirement. For more details, see: https://mailarchive.ietf.org/arch/msg/apps-discuss/wsEAsWC1viE8YL1WfGkaW_NzMpg The document editor has agreed the original text does not reflect the intent of the registration procedure: https://mailarchive.ietf.org/arch/msg/apps-discuss/uPb33G9duZlrwNcdCFUJmvcPLgk Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7595 (draft-ietf-appsawg-uri-scheme-reg-06) -------------------------------------- Title : Guidelines and Registration Procedures for URI Schemes Publication Date : June 2015 Author(s) : D. Thaler, Ed., T. Hansen, T. Hardie Category : BEST CURRENT PRACTICE Source : Applications Area Working Group Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Sun Jul 19 12:34:31 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0761A8780 for ; Sun, 19 Jul 2015 12:34: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 iRgo19US5hfp for ; Sun, 19 Jul 2015 12:34:28 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33AAB1A877E for ; Sun, 19 Jul 2015 12:34:28 -0700 (PDT) Received: by ykay190 with SMTP id y190so125399703yka.3 for ; Sun, 19 Jul 2015 12:34:27 -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=426yk0r1rGW8DYcp7jC2V70bQREf+84ZzrRweocEZSA=; b=qgvCCR5DAA11+CtX3F1lC46pJa86J/fJwpIXJQysc/Ns5qFzDeCB5A6Tz1TKwTKXmF IivJG7gbRVfPGHl0nFd5hMhKQFObulYui8Dco40Xh9tJf4a7h2/aewyK8/58lLj62teA 06wAS6RyT563a4f0bRGjrbiEgP1ykpLdi3OzUApnYQu0GCGbxxmbIvTm5wcmN5bsf98c vvYrLi3OU1nKR4KYqkJwmlbVSHK1qwc5ul4/uHYKuRasUH0Jo+d9JkvvVYFXbJ4g5RsJ Es68uux9q99OflHbfE4JvWx7saUTQmSnzz3/oA51g7wx7AfGKVn+rU4gc2sO+Hb54IeS pDHw== MIME-Version: 1.0 X-Received: by 10.13.199.195 with SMTP id j186mr24707054ywd.112.1437334467572; Sun, 19 Jul 2015 12:34:27 -0700 (PDT) Received: by 10.13.212.1 with HTTP; Sun, 19 Jul 2015 12:34:27 -0700 (PDT) Date: Sun, 19 Jul 2015 12:34:27 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a114e61ae5cfa2e051b3f8201 Archived-At: Subject: [apps-discuss] Meeting materials uploaded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jul 2015 19:34:30 -0000 --001a114e61ae5cfa2e051b3f8201 Content-Type: text/plain; charset=UTF-8 Colleagues, All of the meeting materials we've received for the IETF 93 meeting of APPSAWG/ARTAREA have been uploaded and are available here: https://datatracker.ietf.org/meeting/93/materials.html If you are presenting something, please confirm your materials have been uploaded and that the version is correct. We will not be able to accept late submissions or USB sticks at the desk. Thanks, see you all in the morning! -MSK, APPSAWG co-chair --001a114e61ae5cfa2e051b3f8201 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

All of the me= eting materials we've received for the IETF 93 meeting of APPSAWG/ARTAR= EA have been uploaded and are available here:

https://datatracker.ietf.org/m= eeting/93/materials.html

If you are presenting something, = please confirm your materials have been uploaded and that the version is co= rrect.=C2=A0 We will not be able to accept late submissions or USB sticks a= t the desk.

Thanks, see you all in the morning!
= -MSK, APPSAWG co-chair

--001a114e61ae5cfa2e051b3f8201-- From nobody Mon Jul 20 05:53:40 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0405D1A8770 for ; Mon, 20 Jul 2015 05:53:33 -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 oDi7xjTF8I4q for ; Mon, 20 Jul 2015 05:53:26 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 2BD051A87AD for ; Mon, 20 Jul 2015 05:51:45 -0700 (PDT) Received: from dhcp-b0ef.meeting.ietf.org (unknown [31.133.176.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 96C03509BE; Mon, 20 Jul 2015 08:51:42 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Mark Nottingham In-Reply-To: <20150717193624.EF72218046E@rfc-editor.org> Date: Mon, 20 Jul 2015 14:51:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <02FCD555-BC2F-48DB-8D7D-C494FCAC202D@mnot.net> References: <20150717193624.EF72218046E@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.2102) Archived-At: Cc: apps-discuss@ietf.org, brettz9@yaho.com, barryleiba@computer.org, pbryan@anode.ca Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6902 (4419) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jul 2015 12:53:33 -0000 This seems reasonable to me, although it does seem more like a text = improvement than a strict errata - Barry, any thoughts? I've raised an issue here: https://github.com/json-patch/json-patch-tests/issues/22 =E2=80=A6 as that's where most of the JSON Patch implementer community = pays attention. Cheers, > On 17 Jul 2015, at 9:36 pm, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC6902, > "JavaScript Object Notation (JSON) Patch". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6902&eid=3D4419 >=20 > -------------------------------------- > Type: Technical > Reported by: Brett Zamir >=20 > Section: A.14 >=20 > Original Text > ------------- > An example target JSON document: >=20 > { > "/": 9, > "~1": 10 > } >=20 > A JSON Patch document: >=20 > [ > {"op": "test", "path": "/~01", "value": 10} > ] >=20 > The resulting JSON document: >=20 > { > "/": 9, > "~1": 10 > } >=20 > Corrected Text > -------------- > Proper JSON Pointer escaping should occur when resolving > paths for application to the target document. >=20 > An example target JSON document: >=20 > { > "/": 9, > "~1": 10 > } >=20 > A JSON Patch document: >=20 > [ > {"op": "add", "path": "/~01", "value": 11} > ] >=20 > The resulting JSON document: >=20 > { > "/": 9, > "~1": 11 > } >=20 > Notes > ----- > At http://tools.ietf.org/html/rfc6902#appendix-A.14 , I have a few = issues: >=20 > 1. Even though JSON Pointer is referenced elsewhere, I think reference = ought to be made here to JSON Pointer in order to clarify what meaning = "escape ordering" has here. > 2. The operation indicated in this section is "test" which is not = documented in its respective sections as returning any kind of document = at all. I believe "add" or "replace" must have been the intended = operation instead. And to make clear that the value of key "~1" would = have actually been affected by such a modifying operation, the value in = the result ought to differ from that in the original document. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6902 (draft-ietf-appsawg-json-patch-10) > -------------------------------------- > Title : JavaScript Object Notation (JSON) Patch > Publication Date : April 2013 > Author(s) : P. Bryan, Ed., M. Nottingham, Ed. > Category : PROPOSED STANDARD > Source : Applications Area Working Group APP > Area : Applications > Stream : IETF > Verifying Party : IESG >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Mon Jul 20 05:55:55 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471C11A871D for ; Mon, 20 Jul 2015 05:55:54 -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 ldxLnBq1NfZS for ; Mon, 20 Jul 2015 05:55:53 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BC671A7D83 for ; Mon, 20 Jul 2015 05:55:53 -0700 (PDT) Received: by pdjr16 with SMTP id r16so103401547pdj.3 for ; Mon, 20 Jul 2015 05:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=WRQpLrP578XUaHF9FL7P9eBEt/07UFwQm89UtoTcw5c=; b=VUExqmR95TtpGLZIHrF56RZQL2kt6llcYoKQCb7bMdL0ILajMVowR5ZmQBrcC8KFrN EPKVXfayEmrpg6nvlISSt8RKzM7v4LARBQS5LLDDelHHwR8NLB6Wh8soeEXA3YXAXdfa RnapL0Xoal/VnkSV710fzBhe0rCAVkDG8yox4= 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:content-type; bh=WRQpLrP578XUaHF9FL7P9eBEt/07UFwQm89UtoTcw5c=; b=lm1LV8kOrgY9vhgqxb0R9Vy4EI2k3mpbFPc5OcS7/M+rsc4KpkoCgt5z8GXCkuCfFc lGKE4CF5mbgm2AlBt/n9e51vhRRajt3AMJh3mtMlU3IVODC/+OO2MUx7svza9mhfweMR qh02Z9KdDyOR3lF3yrGf2PuXiJVLrembQYQOYHC+SjjhQqcpaCF7CnVCUVDdTWcOezTt jiexIeXn0GG3IuXZ+1Kjv91Ek8jil8kWP3aak59bysqT+tkd/SV+YiPSUOPoRcgLiZp/ /iBPbrMBBO21elu0hBAXV6QGsfXdZC99OyRNabmaADz52Bt/1AVLq1TSjOdZlOVB1rG5 adxw== X-Gm-Message-State: ALoCoQneTTZspKkOCcV0SBYZYRimlVPZmXRvCzVzGopbySHg4wncw5Nb2mNibPfQRoPyCz0vf6qg MIME-Version: 1.0 X-Received: by 10.70.133.98 with SMTP id pb2mr59211023pdb.2.1437396952630; Mon, 20 Jul 2015 05:55:52 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.66.183.200 with HTTP; Mon, 20 Jul 2015 05:55:52 -0700 (PDT) Date: Mon, 20 Jul 2015 14:55:52 +0200 X-Google-Sender-Auth: NicDeE1zPKpQs57lFm5z_7hLHNw Message-ID: From: "Kurt Andersen (b)" To: IETF Apps Discuss , takehito.akagiri@mail.rakuten.com Content-Type: multipart/alternative; boundary=001a11c3bc20c368e3051b4e0e6e Archived-At: Subject: [apps-discuss] Comments/questions about draft-akagiri-mail-divide-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jul 2015 12:55:54 -0000 --001a11c3bc20c368e3051b4e0e6e Content-Type: text/plain; charset=UTF-8 After the presentation about this proposal in APPSAWG this morning, I've read through the proposal and have the following questions: 1) What is the benefit to recipients (not the receivers) of this system? It seems that, at best, some coarse categorization of mail types can happen, but I don't see how it is useful to me as a recipient to rely on a sender's characterization of their email. 2) I don't see any benefit for receivers (the MSO/ISP who runs the mail system). This seems like it causes them to have to deploy a bunch (up to 8x) of receiving systems. 3) As a sender, I also don't see how this provides any benefit. If I am a good sender, then I will have a good reputation in any reliable reputation service and if I'm malicious, this system seems like it gives me a variety of options to try to subvert the process. Having different receivers specify individual reputation services that they want me to certify with does not seem scalable. How would a sender such as Yahoo even consider such a proposal? Even if this was limited to something like trying to automate/publicly publish a "trusted sender" channel such as some receivers have available, I'm not sure that scaling such a thing is compatible with the intent of limited access. --Kurt Andersen --001a11c3bc20c368e3051b4e0e6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
After the presentation about this= proposal in APPSAWG this morning, I've read through the proposal and h= ave the following questions:

1) What is the benefit to recipie= nts (not the receivers) of this system? It seems that, at best, some coarse= categorization of mail types can happen, but I don't see how it is use= ful to me as a recipient to rely on a sender's characterization of thei= r email.
2) I don't see any benefit for receivers (the MSO/IS= P who runs the mail system). This seems like it causes them to have to depl= oy a bunch (up to 8x) of receiving systems.
3) As a sender, I also= don't see how this provides any benefit. If I am a good sender, then I= will have a good reputation in any reliable reputation service and if I= 9;m malicious, this system seems like it gives me a variety of options to t= ry to subvert the process. Having different receivers specify individual re= putation services that they want me to certify with does not seem scalable.= How would a sender such as Yahoo even consider such a proposal?

Even if this was limited to something like trying to automate/publicly p= ublish a "trusted sender" channel such as some receivers have ava= ilable, I'm not sure that scaling such a thing is compatible with the i= ntent of limited access.

--Kurt Andersen
--001a11c3bc20c368e3051b4e0e6e-- From nobody Mon Jul 20 15:51:40 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F275C1A905C for ; Mon, 20 Jul 2015 15:51:38 -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 oBNUJHel1Nzo for ; Mon, 20 Jul 2015 15:51:36 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0EE1A9051 for ; Mon, 20 Jul 2015 15:51:36 -0700 (PDT) Received: by qgii95 with SMTP id i95so48907514qgi.2 for ; Mon, 20 Jul 2015 15:51: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=nu21CWCYHWuLdkp+7gRk5rD/2swunfLL6otMPWD4v+c=; b=qL5ZPTmnt04GKw4ad0xJ9PyHFSVm4sZEnpQsHiSdRfjBJwe7WXjDJGMTLCswNq32D4 CopVhcGbbCzzonAU3CMuP/d4flZa0xCDDuy1f78JVf2S6ab4QZhQvBa21ltaHQj8LeS8 w7r6VLft6jMgLtuDGG7NXLI0CkG9PhhkyhxLvDvciBARX86W3Cb/wayVrj9VAnePFo6J 6+QrZ19/IJTslQKQVywQ0AYKENRBRuv+6RSIRCjYbBbfZFh759efykn9/Tka6COChTNR 6Do4Lf/W8b8MS+W410hT1zh9nBqG+91GtyjvdVa0VHOHKkzISK+xU2cIADMkAox/DvhA 3ILA== MIME-Version: 1.0 X-Received: by 10.55.40.135 with SMTP id o7mr50415494qko.106.1437432695456; Mon, 20 Jul 2015 15:51:35 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.96.39.168 with HTTP; Mon, 20 Jul 2015 15:51:35 -0700 (PDT) Received: by 10.96.39.168 with HTTP; Mon, 20 Jul 2015 15:51:35 -0700 (PDT) In-Reply-To: <55715580.1090008@ninebynine.org> References: <20150528071826.3803.44025.idtracker@ietfa.amsl.com> <55707C14.5010507@ninebynine.org> <55715580.1090008@ninebynine.org> Date: Tue, 21 Jul 2015 08:51:35 +1000 X-Google-Sender-Auth: jZ1cWzw17M5FpbTlp-1BYRHdt-U Message-ID: From: Matthew Kerwin To: Graham Klyne Content-Type: multipart/alternative; boundary=001a1142a4a2338a77051b56612f Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 22:51:39 -0000 --001a1142a4a2338a77051b56612f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Graham, my apologies for leaving it so long to reply. On 05/06/2015 5:53 PM, "Graham Klyne" wrote: > > >> >>> ... >>> >>> Section 3.2: >>> >>> [[ >>> A file URI can only be translated to a local file path if it has a >>> blank or no authority. Note that this differs from the previous >>> specification in [RFC1738], in that previously an authority of >>> "localhost" was used to refer to the local file system, but in this >>> specification it equates to a UNC string with the host "localhost". >>> ]] >>> >>> I'm uneasy with this non-backwards-compatible change of specification. In >>> the past, I have actually used the "localhost" convention, so that software >>> would be rendered incorrect by this revised spec. >>> >>> >> =E2=80=8BThis point swayed back and forth several times in the earliest revisions. >> It eventually settled on the current version because most of the >> implementations I'd seen acted that way anyway. Which software supported >> the originally-specced localhost, if I may ask?=E2=80=8B >> > > It wasn't a public product, just software I wrote. > I guess all I have to go with here, at the moment, are anecdotes one way or the other. What would be the right way to move forward? A tech survey? > >> >>> Further, I'm not sure what it means to say "it equates to a UNC string >>> with the host "localhost"", expecially on systems that don't use UNC >>> strings. (The reference given for UNC strings, [MS-DTYP], is only >>> informative so I guess that means this whole section is non-normative? >>> >>> >> There are two points here which I'd be happy to have cleared up: >> >> 1. editorial: I need a better way to phrase this paragraph (in both its >> occurrences.) If someone can suggest some text I'd be most obliged. >> >> 2. substantive: I'm thinking I should move all mention of UNC (apart fro= m >> S1.2) to the optional appendices. Is that cool with everybody? It gives the >> above point a lower priority, too. > > > I think that moving to an appendix would go a long way to alleviating my concern here. > That's done in my github copy, modulo a bit of editorial cleaning up. > >> >>> ... >>> >>> Section 4: >>> >>> "When the file system's encoding is not known the file URI SHOULD be >>> transported as an Internationalized Resource Identifier (IRI) [RFC3987] to >>> avoid ambiguity." >>> >>> I'm not seeing how this helps. >>> >>> (1) are we talking about the source system or destination system file >>> system encoding being unknown? I'll assume the source. >>> >>> >> =E2=80=8BYes, the source. The issue arises at the time of interpreting t= he URI, and >> we assume the parser/interpreter and the destination file system share >> knowledge about things like encodings -- so that encoding is known. >> I should have said here: if the source filesystem's encoding is unknown to the recipient of the URI... I think, now, this isn't an issue: the URI author writes the URI for the recipient, so the author's filesystem has little relevance. If the recipient's encoding is unknown to the author, and the author is playing nicely, there's no practical difference between an IRI and a %-encoded URI. >> >>> (2) If the file system name encoding is unknown, how is one to achieve = a >>> mapping to IRIs, which are defined to be a sequence of characters? >>> >>> >> =E2=80=8BWhen I encode, I can (presumably) map my local encoding to Unic= ode, and >> thus create an unambiguous IRI. This is (local)character -> >> (unicode)codepoint, without needing a %-encoded intermediate. > > > I was coming from a viewpoint that there was No knowledge of the filename encoding used. Your text mentions "Note that many modern file systems encode directory and file names as arbitrary sequences of octets. In those cases, the representation as an encoded string often depends on the user's localization settings, or defaults to UTF-8" > Ah, yeah, it hadn't occurred to me that an app creating a URI could do so by looking at the name of a file created by some other user who happened to have an unpredictable l10n env. I... don't actually have a solution for this. What happens now, even in non-URI contexts, if an application encounters a filename that isn't valid utf-8? > > So yes, if the character encoding is known, it makes sense to use Unicode/UTF-8 for transmission, and the rest works as you suggest. On closer reading, your text does suggest a path forward, but I think it might be clearer ... > > I think part of my confusion here is that the section title (is it a verb or a noun?) combined with the first sentence pointed me in the wrong direction. And the final para seems to compound my confusion. > > Suggest: > > First para of section: > > [[ > To avoid ambiguity, 'file:' URIs SHOULD be transported as Internationalized Resource Identifiers (IRI) [RFC3987] or as URIs with non-ASCII characters UTF-8 encoded and %-escaped as needed (RFC3986, section 2.5). > ]] > > Then adjust what follows to fall in line with this. I think that's the intent of what you're trying to say here? > I lost track at some point of what I was trying to say. I think it was Dave Thaler who suggested I use IRIs instead of URIs wherever possible; I asked: "[...] are =E2=80=9Cfile URLs=E2=80=9D in Windows in fact not IRIs, but som= ething even more general (allowing non-Unicode code pages)?" And Dave answered: "URIs are not necessarily %HH-encoded UTF-8. They can be %HH-encoded . Sometimes the charset (code page) is known. Sometimes it isn=E2=80=99t known at the point you get a URI, and you cannot simply as= sume it=E2=80=99s in the system code page, since it may have come from outside t= he local system." So I guess Dave's argument was: %-encoded URIs aren't always UTF-8/Unicode, but IRIs are always Unicode, so use IRIs. If we could guarantee that all %-encoded URIs were UTF-8 I don't think there would be a problem. Cheers > #g > -- --001a1142a4a2338a77051b56612f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Graham, my apologies for leaving it so long to reply.

On 05/06/2015 5:53 PM, "Graham Klyne" <gk@ninebynine.org> wrote:
>

<snip>

>
>>
>>> ...
>>>
>>> Section 3.2:
>>>
>>> [[
>>> A file URI can only be translated to a local file path if it h= as a
>>> =C2=A0 =C2=A0 blank or no authority.=C2=A0 Note that this diff= ers from the previous
>>> =C2=A0 =C2=A0 specification in [RFC1738], in that previously a= n authority of
>>> =C2=A0 =C2=A0 "localhost" was used to refer to the l= ocal file system, but in this
>>> =C2=A0 =C2=A0 specification it equates to a UNC string with th= e host "localhost".
>>> ]]
>>>
>>> I'm uneasy with this non-backwards-compatible change of sp= ecification.=C2=A0 In
>>> the past, I have actually used the "localhost" conve= ntion, so that software
>>> would be rendered incorrect by this revised spec.
>>>
>>>
>> =E2=80=8BThis point swayed back and forth several times in the ear= liest revisions.
>> It eventually settled on the current version because most of the >> implementations I'd seen acted that way anyway. Which software= supported
>> the originally-specced localhost, if I may ask?=E2=80=8B
>>
>
> It wasn't a public product, just software I wrote.
>

I guess all I have to go with here, at the moment, are anecd= otes one way or the other. What would be the right way to move forward? A t= ech survey?

>
>>
>>> Further, I'm not sure what it means to say "it equate= s to a UNC string
>>> with the host "localhost"", expecially on syste= ms that don't use UNC
>>> strings.=C2=A0 (The reference given for UNC strings, [MS-DTYP]= , is only
>>> informative so I guess that means this whole section is non-no= rmative?
>>>
>>>
>> There are two points here which I'd be happy to have cleared u= p:
>>
>> 1. editorial: I need a better way to phrase this paragraph (in bot= h its
>> occurrences.) If someone can suggest some text I'd be most obl= iged.
>>
>> 2. substantive: I'm thinking I should move all mention of UNC = (apart from
>> S1.2) to the optional appendices. Is that cool with everybody? It = gives the
>> above point a lower priority, too.
>
>
> I think that moving to an appendix would go a long way to alleviating = my concern here.
>

That's done in my github copy, modulo a bit of editorial= cleaning up.

>
>>
>>> ...
>>>
>>> Section 4:
>>>
>>> "When the file system's encoding is not known the fil= e URI SHOULD be
>>> transported as an Internationalized Resource Identifier (IRI) = [RFC3987] to
>>> avoid ambiguity."
>>>
>>> I'm not seeing how this helps.
>>>
>>> (1) are we talking about the source system or destination syst= em file
>>> system encoding being unknown?=C2=A0 I'll assume the sourc= e.
>>>
>>>
>> =E2=80=8BYes, the source. The issue arises at the time of interpre= ting the URI, and
>> we assume the parser/interpreter and the destination file system s= hare
>> knowledge about things like encodings -- so that encoding is known= .
>>

I should have said here: if the source filesystem's enco= ding is unknown to the recipient of the URI...

I think, now, this isn't an issue: the URI author writes= the URI for the recipient, so the author's filesystem has little relev= ance. If the recipient's encoding is unknown to the author, and the aut= hor is playing nicely, there's no practical difference between an IRI a= nd a %-encoded URI.

>>
>>> (2) If the file system name encoding is unknown, how is one to= achieve a
>>> mapping to IRIs, which are defined to be a sequence of charact= ers?
>>>
>>>
>> =E2=80=8BWhen I encode, I can (presumably) map my local encoding t= o Unicode, and
>> thus create an unambiguous IRI. This is (local)character ->
>> (unicode)codepoint, without needing a %-encoded intermediate.
>
>
> I was coming from a viewpoint that there was No knowledge of the filen= ame encoding used.=C2=A0 Your text mentions "Note that many modern fil= e systems encode directory and file names as arbitrary sequences of octets.= =C2=A0 In those cases, the representation as an encoded string often depend= s on the user's localization settings, or defaults to UTF-8"
>

Ah, yeah, it hadn't occurred to me that an app creating = a URI could do so by looking at the name of a file created by some other us= er who happened to have an unpredictable l10n env.

I... don't actually have a solution for this. What happe= ns now, even in non-URI contexts, if an application encounters a filename t= hat isn't valid utf-8?

>
> So yes, if the character encoding is known, it makes sense to use Unic= ode/UTF-8 for transmission, and the rest works as you suggest.=C2=A0 On clo= ser reading, your text does suggest a path forward, but I think it might be= clearer ...
>
> I think part of my confusion here is that the section title (is it a v= erb or a noun?) combined with the first sentence pointed me in the wrong di= rection.=C2=A0 And the final para seems to compound my confusion.
>
> Suggest:
>
> First para of section:
>
> [[
> To avoid ambiguity, 'file:' URIs SHOULD be transported as Inte= rnationalized Resource Identifiers (IRI) [RFC3987] or as URIs with non-ASCI= I characters UTF-8 encoded and %-escaped as needed (RFC3986, section 2.5).<= br> > ]]
>
> Then adjust what follows to fall in line with this.=C2=A0 I think that= 's the intent of what you're trying to say here?
>

I lost track at some point of what I was trying to say. I th= ink it was Dave Thaler who suggested I use IRIs instead of URIs wherever po= ssible; I asked:

"[...] are =E2=80=9Cfile URLs=E2=80=9D in Windows in fa= ct not IRIs, but something even more general (allowing non-Unicode code pag= es)?"

And Dave answered:

"URIs are not necessarily %HH-encoded UTF-8.=C2=A0=C2= =A0 They can be %HH-encoded <something else>.=C2=A0=C2=A0 Sometimes t= he charset (code page) is known.=C2=A0 Sometimes it isn=E2=80=99t known at = the point you get a URI, and you cannot simply assume it=E2=80=99s in the s= ystem code page, since it may have come from outside the local system."= ;

So I guess Dave's argument was: %-encoded URIs aren'= t always UTF-8/Unicode, but IRIs are always Unicode, so use IRIs.

If we could guarantee that all %-encoded URIs were UTF-8 I d= on't think there would be a problem.

Cheers

> #g
> --

--001a1142a4a2338a77051b56612f-- From nobody Mon Jul 20 18:09:32 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C981ACD2F for ; Mon, 20 Jul 2015 18:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] 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 uDrK3MOXB-E9 for ; Mon, 20 Jul 2015 18:09:28 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 63D881ACD29 for ; Mon, 20 Jul 2015 18:09:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,511,1432562400"; d="scan'208";a="12396191" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 21 Jul 2015 11:09:25 +1000 X-IronPort-AV: E=McAfee;i="5700,7163,7868"; a="10770911" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcdvi.tcif.telstra.com.au with ESMTP; 21 Jul 2015 11:09:24 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Tue, 21 Jul 2015 11:09:24 +1000 From: "Manger, James" To: Mark Nottingham , RFC Errata System Date: Tue, 21 Jul 2015 11:09:22 +1000 Thread-Topic: [apps-discuss] [Technical Errata Reported] RFC6902 (4419) Thread-Index: AdDC6xzBT128W3TDS8Crie0xK5l+TwAY2quQ Message-ID: <255B9BB34FB7D647A506DC292726F6E129343E5801@WSMSG3153V.srv.dir.telstra.com> References: <20150717193624.EF72218046E@rfc-editor.org> <02FCD555-BC2F-48DB-8D7D-C494FCAC202D@mnot.net> In-Reply-To: <02FCD555-BC2F-48DB-8D7D-C494FCAC202D@mnot.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "pbryan@anode.ca" , "barryleiba@computer.org" , "brettz9@yaho.com" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6902 (4419) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2015 01:09:31 -0000 UkZDNjkwMiAiSlNPTiBQYXRjaCIgc2VjdGlvbiBBLjE0LiAifiBFc2NhcGUgT3JkZXJpbmciIGlz IGNvcnJlY3QsIGJ1dCBjb3VsZCBiZSB3b3JkZWQgbW9yZSBjbGVhcmx5Lg0KDQpTYXlpbmcgIlRo ZSB0ZXN0IHN1Y2NlZWRzIiB3b3VsZCBtYWtlIG1vcmUgc2Vuc2UgdGhhbiAiVGhlIHJlc3VsdGlu ZyBKU09OIFtpc10iLiBBLjgsIEEuOSwgYW5kIEEuMTUgYXJlIGJldHRlciB3b3JkZWQgd2l0aCB0 aGVpciB1c2Ugb2YgIm9wIjoidGVzdCIuDQoNCkNvbXBhcmUgQS4xNC4gdG8gQS4xNS4gIkNvbXBh cmluZyBTdHJpbmdzIGFuZCBOdW1iZXJzIi4gVGhleSBib3RoIHVzZSAib3AiOiJ0ZXN0IiB3aXRo IHRoZSBzYW1lIHRhcmdldCBhbmQgdmVyeSBzaW1pbGFyIHBhdGNoZXMuIEEuMTUgc2F5cyAiVGhp cyByZXN1bHRzIGluIGFuIGVycm9yLCBiZWNhdXNlIHRoZSB0ZXN0IGZhaWxzIi4gVGhhdCBjb250 cmFzdHMgd2VsbCB3aXRoIEEuMTQgd2VyZSB0aGUgdGVzdCBzdWNjZWVkcy4NCg0KDQpQZXJoYXBz IGEgYmV0dGVyIGVkaXRvcmlhbCBlcnJhdGEgd291bGQgYmU6DQoNCj4gU2VjdGlvbjogQS4xNA0K PiANCj4gT3JpZ2luYWwgVGV4dA0KPiAtLS0tLS0tLS0tLS0tDQo+IEFuIGV4YW1wbGUgdGFyZ2V0 IEpTT04gZG9jdW1lbnQ6DQo+IA0KPiAgIHsNCj4gICAgICIvIjogOSwNCj4gICAgICJ+MSI6IDEw DQo+ICAgfQ0KPiANCj4gICBBIEpTT04gUGF0Y2ggZG9jdW1lbnQ6DQo+IA0KPiAgIFsNCj4gICAg IHsib3AiOiAidGVzdCIsICJwYXRoIjogIi9+MDEiLCAidmFsdWUiOiAxMH0NCj4gICBdDQo+IA0K PiAgIFRoZSByZXN1bHRpbmcgSlNPTiBkb2N1bWVudDoNCj4gDQo+ICAgew0KPiAgICAgIi8iOiA5 LA0KPiAgICAgIn4xIjogMTANCj4gICB9DQo+IA0KPiBDb3JyZWN0ZWQgVGV4dA0KPiAtLS0tLS0t LS0tLS0tLQ0KPiBBbiBleGFtcGxlIHRhcmdldCBKU09OIGRvY3VtZW50Og0KPiANCj4gICB7DQo+ ICAgICAiLyI6IDksDQo+ICAgICAifjEiOiAxMA0KPiAgIH0NCj4gDQo+ICAgQSBKU09OIFBhdGNo IGRvY3VtZW50Og0KPiANCj4gICBbDQo+ICAgICB7Im9wIjogInRlc3QiLCAicGF0aCI6ICIvfjAx IiwgInZhbHVlIjogMTB9DQo+ICAgXQ0KPiANCj4gICBUaGUgdGVzdCBzdWNjZWVkcywgYXMgSlNP TiBQb2ludGVyIGVzY2FwaW5nIGFwcGxpZXMgb25jZSB0byB0aGUgInBhdGgiIHZhbHVlLg0KDQoN Cg0KLS0NCkphbWVzIE1hbmdlcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog YXBwcy1kaXNjdXNzIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBNYXJrIE5vdHRpbmdoYW0NClNlbnQ6IE1vbmRheSwgMjAgSnVseSAyMDE1IDEwOjUy IFBNDQpUbzogUkZDIEVycmF0YSBTeXN0ZW0NCkNjOiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmc7IGJy ZXR0ejlAeWFoby5jb207IGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnOyBwYnJ5YW5AYW5vZGUuY2EN ClN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0g UkZDNjkwMiAoNDQxOSkNCg0KVGhpcyBzZWVtcyByZWFzb25hYmxlIHRvIG1lLCBhbHRob3VnaCBp dCBkb2VzIHNlZW0gbW9yZSBsaWtlIGEgdGV4dCBpbXByb3ZlbWVudCB0aGFuIGEgc3RyaWN0IGVy cmF0YSAtIEJhcnJ5LCBhbnkgdGhvdWdodHM/DQoNCkkndmUgcmFpc2VkIGFuIGlzc3VlIGhlcmU6 DQogIGh0dHBzOi8vZ2l0aHViLmNvbS9qc29uLXBhdGNoL2pzb24tcGF0Y2gtdGVzdHMvaXNzdWVz LzIyDQrigKYgYXMgdGhhdCdzIHdoZXJlIG1vc3Qgb2YgdGhlIEpTT04gUGF0Y2ggaW1wbGVtZW50 ZXIgY29tbXVuaXR5IHBheXMgYXR0ZW50aW9uLg0KDQpDaGVlcnMsDQoNCg0KPiBPbiAxNyBKdWwg MjAxNSwgYXQgOTozNiBwbSwgUkZDIEVycmF0YSBTeXN0ZW0gPHJmYy1lZGl0b3JAcmZjLWVkaXRv ci5vcmc+IHdyb3RlOg0KPiANCj4gVGhlIGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVu IHN1Ym1pdHRlZCBmb3IgUkZDNjkwMiwgDQo+ICJKYXZhU2NyaXB0IE9iamVjdCBOb3RhdGlvbiAo SlNPTikgUGF0Y2giLg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gWW91IG1heSByZXZpZXcgdGhlIHJlcG9ydCBiZWxvdyBhbmQgYXQ6DQo+IGh0dHA6Ly93 d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/cmZjPTY5MDImZWlkPTQ0MTkNCj4g DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFR5cGU6IFRlY2hu aWNhbA0KPiBSZXBvcnRlZCBieTogQnJldHQgWmFtaXIgPGJyZXR0ejlAeWFoby5jb20+DQo+IA0K PiBTZWN0aW9uOiBBLjE0DQo+IA0KPiBPcmlnaW5hbCBUZXh0DQo+IC0tLS0tLS0tLS0tLS0NCj4g QW4gZXhhbXBsZSB0YXJnZXQgSlNPTiBkb2N1bWVudDoNCj4gDQo+ICAgew0KPiAgICAgIi8iOiA5 LA0KPiAgICAgIn4xIjogMTANCj4gICB9DQo+IA0KPiAgIEEgSlNPTiBQYXRjaCBkb2N1bWVudDoN Cj4gDQo+ICAgWw0KPiAgICAgeyJvcCI6ICJ0ZXN0IiwgInBhdGgiOiAiL34wMSIsICJ2YWx1ZSI6 IDEwfQ0KPiAgIF0NCj4gDQo+ICAgVGhlIHJlc3VsdGluZyBKU09OIGRvY3VtZW50Og0KPiANCj4g ICB7DQo+ICAgICAiLyI6IDksDQo+ICAgICAifjEiOiAxMA0KPiAgIH0NCj4gDQo+IENvcnJlY3Rl ZCBUZXh0DQo+IC0tLS0tLS0tLS0tLS0tDQo+IFByb3BlciBKU09OIFBvaW50ZXIgZXNjYXBpbmcg c2hvdWxkIG9jY3VyIHdoZW4gcmVzb2x2aW5nIHBhdGhzIGZvciANCj4gYXBwbGljYXRpb24gdG8g dGhlIHRhcmdldCBkb2N1bWVudC4NCj4gDQo+IEFuIGV4YW1wbGUgdGFyZ2V0IEpTT04gZG9jdW1l bnQ6DQo+IA0KPiAgIHsNCj4gICAgICIvIjogOSwNCj4gICAgICJ+MSI6IDEwDQo+ICAgfQ0KPiAN Cj4gICBBIEpTT04gUGF0Y2ggZG9jdW1lbnQ6DQo+IA0KPiAgIFsNCj4gICAgIHsib3AiOiAiYWRk IiwgInBhdGgiOiAiL34wMSIsICJ2YWx1ZSI6IDExfQ0KPiAgIF0NCj4gDQo+ICAgVGhlIHJlc3Vs dGluZyBKU09OIGRvY3VtZW50Og0KPiANCj4gICB7DQo+ICAgICAiLyI6IDksDQo+ICAgICAifjEi OiAxMQ0KPiAgIH0NCj4gDQo+IE5vdGVzDQo+IC0tLS0tDQo+IEF0IGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzY5MDIjYXBwZW5kaXgtQS4xNCAsIEkgaGF2ZSBhIGZldyBpc3N1ZXM6DQo+ IA0KPiAxLiBFdmVuIHRob3VnaCBKU09OIFBvaW50ZXIgaXMgcmVmZXJlbmNlZCBlbHNld2hlcmUs IEkgdGhpbmsgcmVmZXJlbmNlIG91Z2h0IHRvIGJlIG1hZGUgaGVyZSB0byBKU09OIFBvaW50ZXIg aW4gb3JkZXIgdG8gY2xhcmlmeSB3aGF0IG1lYW5pbmcgImVzY2FwZSBvcmRlcmluZyIgaGFzIGhl cmUuDQo+IDIuIFRoZSBvcGVyYXRpb24gaW5kaWNhdGVkIGluIHRoaXMgc2VjdGlvbiBpcyAidGVz dCIgd2hpY2ggaXMgbm90IGRvY3VtZW50ZWQgaW4gaXRzIHJlc3BlY3RpdmUgc2VjdGlvbnMgYXMg cmV0dXJuaW5nIGFueSBraW5kIG9mIGRvY3VtZW50IGF0IGFsbC4gSSBiZWxpZXZlICJhZGQiIG9y ICJyZXBsYWNlIiBtdXN0IGhhdmUgYmVlbiB0aGUgaW50ZW5kZWQgb3BlcmF0aW9uIGluc3RlYWQu IEFuZCB0byBtYWtlIGNsZWFyIHRoYXQgdGhlIHZhbHVlIG9mIGtleSAifjEiIHdvdWxkIGhhdmUg YWN0dWFsbHkgYmVlbiBhZmZlY3RlZCBieSBzdWNoIGEgbW9kaWZ5aW5nIG9wZXJhdGlvbiwgdGhl IHZhbHVlIGluIHRoZSByZXN1bHQgb3VnaHQgdG8gZGlmZmVyIGZyb20gdGhhdCBpbiB0aGUgb3Jp Z2luYWwgZG9jdW1lbnQuDQo+IA0KPiBJbnN0cnVjdGlvbnM6DQo+IC0tLS0tLS0tLS0tLS0NCj4g VGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgIlJlcG9ydGVkIi4gSWYgbmVjZXNz YXJ5LCBwbGVhc2UgDQo+IHVzZSAiUmVwbHkgQWxsIiB0byBkaXNjdXNzIHdoZXRoZXIgaXQgc2hv dWxkIGJlIHZlcmlmaWVkIG9yIHJlamVjdGVkLiANCj4gV2hlbiBhIGRlY2lzaW9uIGlzIHJlYWNo ZWQsIHRoZSB2ZXJpZnlpbmcgcGFydHkgKElFU0cpIGNhbiBsb2cgaW4gdG8gDQo+IGNoYW5nZSB0 aGUgc3RhdHVzIGFuZCBlZGl0IHRoZSByZXBvcnQsIGlmIG5lY2Vzc2FyeS4NCj4gDQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFJGQzY5MDIgKGRyYWZ0LWlldGYt YXBwc2F3Zy1qc29uLXBhdGNoLTEwKQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiBUaXRsZSAgICAgICAgICAgICAgIDogSmF2YVNjcmlwdCBPYmplY3QgTm90YXRp b24gKEpTT04pIFBhdGNoDQo+IFB1YmxpY2F0aW9uIERhdGUgICAgOiBBcHJpbCAyMDEzDQo+IEF1 dGhvcihzKSAgICAgICAgICAgOiBQLiBCcnlhbiwgRWQuLCBNLiBOb3R0aW5naGFtLCBFZC4NCj4g Q2F0ZWdvcnkgICAgICAgICAgICA6IFBST1BPU0VEIFNUQU5EQVJEDQo+IFNvdXJjZSAgICAgICAg ICAgICAgOiBBcHBsaWNhdGlvbnMgQXJlYSBXb3JraW5nIEdyb3VwIEFQUA0KPiBBcmVhICAgICAg ICAgICAgICAgIDogQXBwbGljYXRpb25zDQo+IFN0cmVhbSAgICAgICAgICAgICAgOiBJRVRGDQo+ IFZlcmlmeWluZyBQYXJ0eSAgICAgOiBJRVNHDQo+IA0KDQotLQ0KTWFyayBOb3R0aW5naGFtICAg aHR0cHM6Ly93d3cubW5vdC5uZXQvDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQphcHBzLWRpc2N1c3MgbWFpbGluZyBsaXN0DQphcHBzLWRp c2N1c3NAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBw cy1kaXNjdXNzDQo= From nobody Tue Jul 21 03:26:26 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E9C1B2D6F for ; Tue, 21 Jul 2015 03:26:24 -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 ysh2f6mU5cHT for ; Tue, 21 Jul 2015 03:26:21 -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 D21371B2D67 for ; Tue, 21 Jul 2015 03:26:20 -0700 (PDT) Received: from smtp5.mail.ox.ac.uk ([163.1.2.207]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1ZHUkc-0005No-aI; Tue, 21 Jul 2015 11:26:18 +0100 Received: from oerc-dynamic-223.oerc.ox.ac.uk ([129.67.194.223]) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZHUkc-0008Me-Gb; Tue, 21 Jul 2015 11:26:18 +0100 Message-ID: <55AE1E50.3090002@ninebynine.org> Date: Tue, 21 Jul 2015 11:26:24 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin References: <20150528071826.3803.44025.idtracker@ietfa.amsl.com> <55707C14.5010507@ninebynine.org> <55715580.1090008@ninebynine.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 10:26:24 -0000 On 20/07/2015 23:51, Matthew Kerwin wrote: > Hi Graham, my apologies for leaving it so long to reply. np > > On 05/06/2015 5:53 PM, "Graham Klyne" wrote: >> > > > >> >>> >>>> ... >>>> >>>> Section 3.2: >>>> >>>> [[ >>>> A file URI can only be translated to a local file path if it has a >>>> blank or no authority. Note that this differs from the previous >>>> specification in [RFC1738], in that previously an authority of >>>> "localhost" was used to refer to the local file system, but in this >>>> specification it equates to a UNC string with the host "localhost". >>>> ]] >>>> >>>> I'm uneasy with this non-backwards-compatible change of specification. > In >>>> the past, I have actually used the "localhost" convention, so that > software >>>> would be rendered incorrect by this revised spec. >>>> >>>> >>> ​This point swayed back and forth several times in the earliest > revisions. >>> It eventually settled on the current version because most of the >>> implementations I'd seen acted that way anyway. Which software supported >>> the originally-specced localhost, if I may ask?​ >>> >> >> It wasn't a public product, just software I wrote. >> > > I guess all I have to go with here, at the moment, are anecdotes one way or > the other. What would be the right way to move forward? A tech survey? My suggestion would be to start with a presumption of no incompatible changes, but to allow the change is there's a fairly strong consensus to apply it (e.g. if the change itself represents a significant body of actual use). > >> >>> >>>> Further, I'm not sure what it means to say "it equates to a UNC string >>>> with the host "localhost"", expecially on systems that don't use UNC >>>> strings. (The reference given for UNC strings, [MS-DTYP], is only >>>> informative so I guess that means this whole section is non-normative? >>>> >>>> >>> There are two points here which I'd be happy to have cleared up: >>> >>> 1. editorial: I need a better way to phrase this paragraph (in both its >>> occurrences.) If someone can suggest some text I'd be most obliged. >>> >>> 2. substantive: I'm thinking I should move all mention of UNC (apart from >>> S1.2) to the optional appendices. Is that cool with everybody? It gives > the >>> above point a lower priority, too. >> >> >> I think that moving to an appendix would go a long way to alleviating my > concern here. >> > > That's done in my github copy, modulo a bit of editorial cleaning up. Ack. Thanks. > >> >>> >>>> ... >>>> >>>> Section 4: >>>> >>>> "When the file system's encoding is not known the file URI SHOULD be >>>> transported as an Internationalized Resource Identifier (IRI) [RFC3987] > to >>>> avoid ambiguity." >>>> >>>> I'm not seeing how this helps. >>>> >>>> (1) are we talking about the source system or destination system file >>>> system encoding being unknown? I'll assume the source. >>>> >>>> >>> ​Yes, the source. The issue arises at the time of interpreting the URI, > and >>> we assume the parser/interpreter and the destination file system share >>> knowledge about things like encodings -- so that encoding is known. >>> > > I should have said here: if the source filesystem's encoding is unknown to > the recipient of the URI... > > I think, now, this isn't an issue: the URI author writes the URI for the > recipient, so the author's filesystem has little relevance. If the > recipient's encoding is unknown to the author, and the author is playing > nicely, there's no practical difference between an IRI and a %-encoded URI. I agree, and I _think_ (it's been a while) that's why I raised the point. > >>> >>>> (2) If the file system name encoding is unknown, how is one to achieve a >>>> mapping to IRIs, which are defined to be a sequence of characters? >>>> >>>> >>> ​When I encode, I can (presumably) map my local encoding to Unicode, and >>> thus create an unambiguous IRI. This is (local)character -> >>> (unicode)codepoint, without needing a %-encoded intermediate. >> >> >> I was coming from a viewpoint that there was No knowledge of the filename > encoding used. Your text mentions "Note that many modern file systems > encode directory and file names as arbitrary sequences of octets. In those > cases, the representation as an encoded string often depends on the user's > localization settings, or defaults to UTF-8" >> > > Ah, yeah, it hadn't occurred to me that an app creating a URI could do so > by looking at the name of a file created by some other user who happened to > have an unpredictable l10n env. > > I... don't actually have a solution for this. What happens now, even in > non-URI contexts, if an application encounters a filename that isn't valid > utf-8? I think that's a matter for the application, if the spec focuses on what actually gets exchanged. > >> >> So yes, if the character encoding is known, it makes sense to use > Unicode/UTF-8 for transmission, and the rest works as you suggest. On > closer reading, your text does suggest a path forward, but I think it might > be clearer ... >> >> I think part of my confusion here is that the section title (is it a verb > or a noun?) combined with the first sentence pointed me in the wrong > direction. And the final para seems to compound my confusion. >> >> Suggest: >> >> First para of section: >> >> [[ >> To avoid ambiguity, 'file:' URIs SHOULD be transported as > Internationalized Resource Identifiers (IRI) [RFC3987] or as URIs with > non-ASCII characters UTF-8 encoded and %-escaped as needed (RFC3986, > section 2.5). >> ]] >> >> Then adjust what follows to fall in line with this. I think that's the > intent of what you're trying to say here? >> > > I lost track at some point of what I was trying to say. I think it was Dave > Thaler who suggested I use IRIs instead of URIs wherever possible; I asked: > > "[...] are “file URLs” in Windows in fact not IRIs, but something even more > general (allowing non-Unicode code pages)?" > > And Dave answered: > > "URIs are not necessarily %HH-encoded UTF-8. They can be %HH-encoded > . Sometimes the charset (code page) is known. Sometimes > it isn’t known at the point you get a URI, and you cannot simply assume > it’s in the system code page, since it may have come from outside the local > system." > > So I guess Dave's argument was: %-encoded URIs aren't always UTF-8/Unicode, > but IRIs are always Unicode, so use IRIs. Ah, interesting point. Dave's right (cf RFC3986 sect 2). But my sense is that folks are trying to move away from that position; e.g. RFC3986 also says: [[ The URI producer will transform the local encoding to one that is suitable for a public interface and then transform the public interface encoding into the restricted set of URI characters (reserved, unreserved, and percent-encodings). ]] and [[ A system that internally provides identifiers in the form of a different character encoding, such as EBCDIC, will generally perform character translation of textual identifiers to UTF-8 [STD63] (or some other superset of the US-ASCII character encoding) at an internal interface, thereby providing more meaningful identifiers than those resulting from simply percent-encoding the original octets. ]] and [[ When a new URI scheme defines a component that represents textual data consisting of characters from the Universal Character Set [UCS], the data should first be encoded as octets according to the UTF-8 character encoding [STD63]; then only those octets that do not correspond to characters in the unreserved set should be percent- encoded. ]] -- http://tools.ietf.org/html/rfc3986#section-2.5 I think my suggested text is in the spirit of what you're trying to achieve, just more explicit that it's OK to %-encode the non-US-ASCII characters of an IRI. > > If we could guarantee that all %-encoded URIs were UTF-8 I don't think > there would be a problem. Yes indeed! (We maybe can't do that, but it seems reasonable to try and nudge people in that direction.) #g From nobody Tue Jul 21 07:25:54 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC071B2E55 for ; Tue, 21 Jul 2015 07:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-3lRTwB2J5x for ; Tue, 21 Jul 2015 07:25:51 -0700 (PDT) Received: from mail-ie0-x244.google.com (mail-ie0-x244.google.com [IPv6:2607:f8b0:4001:c03::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169641A886E for ; Tue, 21 Jul 2015 07:25:51 -0700 (PDT) Received: by ietj16 with SMTP id j16so12102507iet.1 for ; Tue, 21 Jul 2015 07:25:50 -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:content-transfer-encoding; bh=8xcGMsKg7yEzExjz2itE4yAjyyMog37FLpJ28WQlp4M=; b=fI4r0leSNWdRf1n9n0e7MQJefz8Xa/oxky4vK073quUHWI/l+HsmviXdcdJ9gFSe7/ FAreLFyo7OQmqeuCzzavQm8T17e2XBfdSgYq+VRCjJzhllPgCkxqkLSczWGXj0Yk5Psh kCoLF8N8iEZIjuApz3DmLXUsgMGSTuq3Baf1qn5RpEvpIj9XLBH1yeiaipoTYlyjnwSc uFAYdDiSipPVprlCIKwgtS8aanAUQO/49uh+1fi+h/UvpjntmWqFvIgL6pwEexhVdcyQ muHSguKPStFcOuJiw33aUfUUjmuY0kWYUYum2RYbgWb0PNIsqT/BeCuSsS4t7Wff/gCq s/YA== MIME-Version: 1.0 X-Received: by 10.50.1.79 with SMTP id 15mr25427345igk.68.1437488750577; Tue, 21 Jul 2015 07:25:50 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.133.95 with HTTP; Tue, 21 Jul 2015 07:25:50 -0700 (PDT) In-Reply-To: <02FCD555-BC2F-48DB-8D7D-C494FCAC202D@mnot.net> References: <20150717193624.EF72218046E@rfc-editor.org> <02FCD555-BC2F-48DB-8D7D-C494FCAC202D@mnot.net> Date: Tue, 21 Jul 2015 10:25:50 -0400 X-Google-Sender-Auth: wnEpnwB_3p3Tc2eacQO3y4CWAqg Message-ID: From: Barry Leiba To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Paul Bryan , brettz9@yaho.com, "apps-discuss@ietf.org" , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6902 (4419) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2015 14:25:52 -0000 > This seems reasonable to me, although it does seem more like a text > improvement than a strict errata - Barry, any thoughts? Was it an error in the spec that the example makes a patch that doesn't actually make any change to the JSON? If that was a mistake, then this report (or some edited version of it) should be "verified". If that was intentional, showing an example of a valid patch that makes no changes, then this report should be "rejected". In either case... > I've raised an issue here: > https://github.com/json-patch/json-patch-tests/issues/22 > =E2=80=A6 as that's where most of the JSON Patch implementer community > pays attention. ...that's a good thing to do, as that's the right place to record comments about the clarity of the document, which might be considered if we ever do another version. Barry >> On 17 Jul 2015, at 9:36 pm, RFC Errata System wrote: >> >> The following errata report has been submitted for RFC6902, >> "JavaScript Object Notation (JSON) Patch". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D6902&eid=3D4419 >> >> -------------------------------------- >> Type: Technical >> Reported by: Brett Zamir >> >> Section: A.14 >> >> Original Text >> ------------- >> An example target JSON document: >> >> { >> "/": 9, >> "~1": 10 >> } >> >> A JSON Patch document: >> >> [ >> {"op": "test", "path": "/~01", "value": 10} >> ] >> >> The resulting JSON document: >> >> { >> "/": 9, >> "~1": 10 >> } >> >> Corrected Text >> -------------- >> Proper JSON Pointer escaping should occur when resolving >> paths for application to the target document. >> >> An example target JSON document: >> >> { >> "/": 9, >> "~1": 10 >> } >> >> A JSON Patch document: >> >> [ >> {"op": "add", "path": "/~01", "value": 11} >> ] >> >> The resulting JSON document: >> >> { >> "/": 9, >> "~1": 11 >> } >> >> Notes >> ----- >> At http://tools.ietf.org/html/rfc6902#appendix-A.14 , I have a few issue= s: >> >> 1. Even though JSON Pointer is referenced elsewhere, I think reference o= ught to be made here to JSON Pointer in order to clarify what meaning "esca= pe ordering" has here. >> 2. The operation indicated in this section is "test" which is not docume= nted in its respective sections as returning any kind of document at all. I= believe "add" or "replace" must have been the intended operation instead. = And to make clear that the value of key "~1" would have actually been affec= ted by such a modifying operation, the value in the result ought to differ = from that in the original document. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6902 (draft-ietf-appsawg-json-patch-10) >> -------------------------------------- >> Title : JavaScript Object Notation (JSON) Patch >> Publication Date : April 2013 >> Author(s) : P. Bryan, Ed., M. Nottingham, Ed. >> Category : PROPOSED STANDARD >> Source : Applications Area Working Group APP >> Area : Applications >> Stream : IETF >> Verifying Party : IESG >> > > -- > Mark Nottingham https://www.mnot.net/ > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Tue Jul 21 07:28:10 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720EC1B2E85 for ; Tue, 21 Jul 2015 07:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAHoDdSe8TaK for ; Tue, 21 Jul 2015 07:28:08 -0700 (PDT) Received: from mail-ie0-x241.google.com (mail-ie0-x241.google.com [IPv6:2607:f8b0:4001:c03::241]) (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 CF4681A8847 for ; Tue, 21 Jul 2015 07:28:08 -0700 (PDT) Received: by iebmx2 with SMTP id mx2so12128784ieb.2 for ; Tue, 21 Jul 2015 07:28:08 -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:content-transfer-encoding; bh=bN3L0/P/0voQMstCEXVko+iboocz2iH81PZFWPO92oQ=; b=jn7ghPx4e4tIfB67mWewBSlFz1Xf67ROJokGfYQls+XXbIcmmQqI/V2bQ0sa7T0Nt5 I1dS/SMkbAYhig+MFq4R8wgxfI/ktL7yN81jZ5T34JGHnUrImcAykNnT2Z0MjJsMOf+y JmsXZEVqZMOFDUtjkHYIb3zEWCSuSrnO3oRBs0gMwSTHqyeC9RdJTi3FPdBYa3ekDNoj R8gyGBJlXAkY5G19PnFfA9L7Kf3vSZsw8AbwSxShgLSesmQ079srV3nNr8zNassWyR1h nYz4cyO3XgTu+U3RJ4XjuMPNrVbxgbxeqPEJWlG/72Sijh+q4kOc6NGV0O/UmzMGgHza IWag== MIME-Version: 1.0 X-Received: by 10.50.102.98 with SMTP id fn2mr23156398igb.55.1437488888254; Tue, 21 Jul 2015 07:28:08 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.133.95 with HTTP; Tue, 21 Jul 2015 07:28:08 -0700 (PDT) In-Reply-To: <02FCD555-BC2F-48DB-8D7D-C494FCAC202D@mnot.net> References: <20150717193624.EF72218046E@rfc-editor.org> <02FCD555-BC2F-48DB-8D7D-C494FCAC202D@mnot.net> Date: Tue, 21 Jul 2015 10:28:08 -0400 X-Google-Sender-Auth: Q1lJGKjZ9FtAqJB9ZOCbPiSPPmU Message-ID: From: Barry Leiba To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: brettz9@yahoo.com, Paul Bryan , "apps-discuss@ietf.org" , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6902 (4419) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2015 14:28:10 -0000 (Re-sending this with what I presume is the correct email address for Brett= .) > This seems reasonable to me, although it does seem more like a text > improvement than a strict errata - Barry, any thoughts? Was it an error in the spec that the example makes a patch that doesn't actually make any change to the JSON? If that was a mistake, then this report (or some edited version of it) should be "verified". If that was intentional, showing an example of a valid patch that makes no changes, then this report should be "rejected". In either case... > I've raised an issue here: > https://github.com/json-patch/json-patch-tests/issues/22 > =E2=80=A6 as that's where most of the JSON Patch implementer community > pays attention. ...that's a good thing to do, as that's the right place to record comments about the clarity of the document, which might be considered if we ever do another version. >> On 17 Jul 2015, at 9:36 pm, RFC Errata System wrote: >> >> The following errata report has been submitted for RFC6902, >> "JavaScript Object Notation (JSON) Patch". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D6902&eid=3D4419 >> >> -------------------------------------- >> Type: Technical >> Reported by: Brett Zamir >> >> Section: A.14 >> >> Original Text >> ------------- >> An example target JSON document: >> >> { >> "/": 9, >> "~1": 10 >> } >> >> A JSON Patch document: >> >> [ >> {"op": "test", "path": "/~01", "value": 10} >> ] >> >> The resulting JSON document: >> >> { >> "/": 9, >> "~1": 10 >> } >> >> Corrected Text >> -------------- >> Proper JSON Pointer escaping should occur when resolving >> paths for application to the target document. >> >> An example target JSON document: >> >> { >> "/": 9, >> "~1": 10 >> } >> >> A JSON Patch document: >> >> [ >> {"op": "add", "path": "/~01", "value": 11} >> ] >> >> The resulting JSON document: >> >> { >> "/": 9, >> "~1": 11 >> } >> >> Notes >> ----- >> At http://tools.ietf.org/html/rfc6902#appendix-A.14 , I have a few issue= s: >> >> 1. Even though JSON Pointer is referenced elsewhere, I think reference o= ught to be made here to JSON Pointer in order to clarify what meaning "esca= pe ordering" has here. >> 2. The operation indicated in this section is "test" which is not docume= nted in its respective sections as returning any kind of document at all. I= believe "add" or "replace" must have been the intended operation instead. = And to make clear that the value of key "~1" would have actually been affec= ted by such a modifying operation, the value in the result ought to differ = from that in the original document. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6902 (draft-ietf-appsawg-json-patch-10) >> -------------------------------------- >> Title : JavaScript Object Notation (JSON) Patch >> Publication Date : April 2013 >> Author(s) : P. Bryan, Ed., M. Nottingham, Ed. >> Category : PROPOSED STANDARD >> Source : Applications Area Working Group APP >> Area : Applications >> Stream : IETF >> Verifying Party : IESG >> > > -- > Mark Nottingham https://www.mnot.net/ > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Tue Jul 21 07:47:09 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A831B2E4E for ; Tue, 21 Jul 2015 07:47:08 -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 z0r1p2VTspsV for ; Tue, 21 Jul 2015 07:47:00 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F7951B2DD9 for ; Tue, 21 Jul 2015 07:47:00 -0700 (PDT) Received: from dhcp-b3db.meeting.ietf.org (unknown [31.133.179.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7594F22E272; Tue, 21 Jul 2015 10:46:55 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Mark Nottingham In-Reply-To: Date: Tue, 21 Jul 2015 16:46:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150717193624.EF72218046E@rfc-editor.org> <02FCD555-BC2F-48DB-8D7D-C494FCAC202D@mnot.net> To: Barry Leiba X-Mailer: Apple Mail (2.2102) Archived-At: Cc: brettz9@yahoo.com, Paul Bryan , "apps-discuss@ietf.org" , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6902 (4419) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2015 14:47:08 -0000 I think it's the case that it's a correct =E2=80=94 but not necessarily = the clearest =E2=80=94 example. > On 21 Jul 2015, at 4:28 pm, Barry Leiba = wrote: >=20 > (Re-sending this with what I presume is the correct email address for = Brett.) >=20 >> This seems reasonable to me, although it does seem more like a text >> improvement than a strict errata - Barry, any thoughts? >=20 > Was it an error in the spec that the example makes a patch that > doesn't actually make any change to the JSON? >=20 > If that was a mistake, then this report (or some edited version of it) > should be "verified". >=20 > If that was intentional, showing an example of a valid patch that > makes no changes, then this report should be "rejected". >=20 > In either case... >=20 >> I've raised an issue here: >> https://github.com/json-patch/json-patch-tests/issues/22 >> =E2=80=A6 as that's where most of the JSON Patch implementer = community >> pays attention. >=20 > ...that's a good thing to do, as that's the right place to record > comments about the clarity of the document, which might be considered > if we ever do another version. >=20 >>> On 17 Jul 2015, at 9:36 pm, RFC Errata System = wrote: >>>=20 >>> The following errata report has been submitted for RFC6902, >>> "JavaScript Object Notation (JSON) Patch". >>>=20 >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3D6902&eid=3D4419 >>>=20 >>> -------------------------------------- >>> Type: Technical >>> Reported by: Brett Zamir >>>=20 >>> Section: A.14 >>>=20 >>> Original Text >>> ------------- >>> An example target JSON document: >>>=20 >>> { >>> "/": 9, >>> "~1": 10 >>> } >>>=20 >>> A JSON Patch document: >>>=20 >>> [ >>> {"op": "test", "path": "/~01", "value": 10} >>> ] >>>=20 >>> The resulting JSON document: >>>=20 >>> { >>> "/": 9, >>> "~1": 10 >>> } >>>=20 >>> Corrected Text >>> -------------- >>> Proper JSON Pointer escaping should occur when resolving >>> paths for application to the target document. >>>=20 >>> An example target JSON document: >>>=20 >>> { >>> "/": 9, >>> "~1": 10 >>> } >>>=20 >>> A JSON Patch document: >>>=20 >>> [ >>> {"op": "add", "path": "/~01", "value": 11} >>> ] >>>=20 >>> The resulting JSON document: >>>=20 >>> { >>> "/": 9, >>> "~1": 11 >>> } >>>=20 >>> Notes >>> ----- >>> At http://tools.ietf.org/html/rfc6902#appendix-A.14 , I have a few = issues: >>>=20 >>> 1. Even though JSON Pointer is referenced elsewhere, I think = reference ought to be made here to JSON Pointer in order to clarify what = meaning "escape ordering" has here. >>> 2. The operation indicated in this section is "test" which is not = documented in its respective sections as returning any kind of document = at all. I believe "add" or "replace" must have been the intended = operation instead. And to make clear that the value of key "~1" would = have actually been affected by such a modifying operation, the value in = the result ought to differ from that in the original document. >>>=20 >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>>=20 >>> -------------------------------------- >>> RFC6902 (draft-ietf-appsawg-json-patch-10) >>> -------------------------------------- >>> Title : JavaScript Object Notation (JSON) Patch >>> Publication Date : April 2013 >>> Author(s) : P. Bryan, Ed., M. Nottingham, Ed. >>> Category : PROPOSED STANDARD >>> Source : Applications Area Working Group APP >>> Area : Applications >>> Stream : IETF >>> Verifying Party : IESG >>>=20 >>=20 >> -- >> Mark Nottingham https://www.mnot.net/ >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham https://www.mnot.net/ From nobody Wed Jul 22 20:54:39 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233921A0099 for ; Wed, 22 Jul 2015 05:05:36 -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 Yia-NcRodXco for ; Wed, 22 Jul 2015 05:05:34 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::752]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 972DC1A00E0 for ; Wed, 22 Jul 2015 05:05:32 -0700 (PDT) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from pc6 (81.151.167.91) by DB5PR07MB0888.eurprd07.prod.outlook.com (10.161.196.16) with Microsoft SMTP Server (TLS) id 15.1.219.17; Wed, 22 Jul 2015 12:05:16 +0000 Message-ID: <06aa01d0c476$31da00a0$4001a8c0@gateway.2wire.net> From: t.petch To: apps-discuss Date: Wed, 22 Jul 2015 13:01:41 +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: [81.151.167.91] X-ClientProxiedBy: AM3PR03CA044.eurprd03.prod.outlook.com (10.141.191.172) To DB5PR07MB0888.eurprd07.prod.outlook.com (25.161.196.16) X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB0888; 2:3ZesH4V+X+N+D3XIdPQDbMWvkya4PgYdWc8+76lmgE0LFpiSp6hbVaZKNdmgMk+6; 3:D8eZVkQsGKGiQZ0vTaxu7fXdyGEvsfQvnxiuWpBMxUZrvowFlwSdgGRbbto4QNUONOfuX4UxbmCQYYoaqz/6PZy0yBFHjfhsEDtTS74HVOJhyFMEqZDday5aQNXDlsw6zi78KAnv/pIW8/n2Gd/rTg==; 25:aJyMnCjGTol/sxkK3wPIboPV6q0wTcYGJ8mkfQQPhA9X1T2QNIOr2zoupV7zZZwB6IGBawHMD2g1FN3crZPIX0P983FzvRcK9T81eJMjl5HmeyRO0xd3dh7w2LeLboeCOVrNOS+4tBR8FlZVlOkBUHLF1MMpc5je7vAGj9oAiq3/rtZCfQxP/iepD2EO041vNrkmDVYSSgXS16IbOXn3MI/FfsQfcnnWS+IgCFwWOxHAjwuD0Cn1PCR4HwTddz4tiu9nz1vxVdKA3/TAkA0yrQ==; 4:jVmTtVqQLAB41jVjS9Iid+HQf7RUa18WPt7QH6o/7KTkbRuEAAf4jeuvPfX2FSvkokoQOMAAYpsAzG6mNd8fF7oZshdyNYpRyPy2ZHHYc628ndilctmZQSSadlyfStLpVA810iUgD+1194c5OE/h92yO4TIw5kcRcDxCsh/CZ8Yul5mrWgKE+v1kNajVsKUBpYW+xOOcjhXEACx26GARhGRkBXUCsH8+dex33cgonWiRfIY80bHes3RlVcw6ptKO4NqaI6hBBYEw9W/8wLS7VCpuu5cptTdoPgFusXhm3ds= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR07MB0888; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB5PR07MB0888; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB0888; X-Forefront-PRVS: 0645BEB7AA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(377454003)(44716002)(50986999)(92566002)(62236002)(81686999)(81816999)(47776003)(50466002)(50226001)(66066001)(42186005)(23756003)(46102003)(33646002)(62966003)(19580395003)(19580405001)(5001960100002)(122386002)(40100003)(61296003)(1456003)(1720100001)(87976001)(116806002)(110136002)(5001920100001)(15975445007)(1556002)(86362001)(84392001)(107886002)(44736004)(14496001)(450100001)(77156002)(189998001)(77096005)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB0888; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB5PR07MB0888; 23:lawlbbSgMFovwl/6kmfpTo7BTl3Ck7VqpjXHeLq?= =?iso-8859-1?Q?CCr4Kzw9THPtVeQbMlJJ6PntrpVkP31XA/891ydfUj9Vp/STnH/xOfijxI?= =?iso-8859-1?Q?x6rLN/xXpC8Z8cx/bSlCjGc2Ymg8B1b+5CTGDpMuGc4k91lrMHHms0ybjG?= =?iso-8859-1?Q?vKjYPWVpotjJ3tBV2Z5Rbi+icSMb8y/i3B40Xlw38cWbpbTUxB5GXHkOhw?= =?iso-8859-1?Q?el4cQgYUTSx/YVOowv2xBmZLzbvDAvGYAI/ecBeQ9Z7UHswK1bfIMQLkk/?= =?iso-8859-1?Q?IZqFH6VA1eNDMU6QEdwFvRK+gvcdppIxWyMJd6UCvbmoPjIGikVFu7JgZ7?= =?iso-8859-1?Q?7xxQ9Bqn6DkTleaMTc+KL1IZJ6dFVxz3ep8+sTNUIal1LQz6zhCQ1stwRV?= =?iso-8859-1?Q?8+Ko48TA5Y+OKDqfvc4l4XPjK7eKIXtuhPDetMlz9pdGizNG8DGRYzFkTr?= =?iso-8859-1?Q?PJS8kKBAxtDJ1PBEdr7armqEhMUlw37YiAeeDOQpvrkkNqWYhb7FB/Fj/d?= =?iso-8859-1?Q?xpS6Gne4UXbYTCqSiLPQZx5OS8w7Ccupt/f61mFzSe+B10UU9KwnO6zNoU?= =?iso-8859-1?Q?EdmYs1s+ULno5hsw/v/OtcLwP9CTn6TbLV0mdCqome5dM7KxGdNeys/0ml?= =?iso-8859-1?Q?tvMbGhPCNttqeR9Qc220xaINjtBXCReqzV6PyTD3i7ceKVNGOzykj5FmRg?= =?iso-8859-1?Q?ylshHlMYLbqfnai1IKRQbIUGy6FQyNVcGf+nOZXFnnaVQsMBfGj4MMJuHV?= =?iso-8859-1?Q?Q6WSJ5fzrYWmBEbPhWvRNEGVpDLmP0qkqPJxbEGVE6lJsCRHEBRgGTHhk6?= =?iso-8859-1?Q?Lu4WrCiQ5aDCy0F3tBEGhPBIRm1aGeusWt27bpNS4H0QpCauE7MUIUZJFa?= =?iso-8859-1?Q?7AvdJAFuJEkc1KLDUQPjfptNfYWOkPxCxaEzXF/m9qX7ciCPwLwaJbK9X6?= =?iso-8859-1?Q?OXOEo6+oUtA+9+ZpkTmcrcGOA5ODoT9wOMvA71qhwN6xDf41gFOk4ebRcL?= =?iso-8859-1?Q?mlOxxQSuNDJDU5E+Gk9TgulwazRfNJVcxn2+O/6sPzhSyabhxS499FlYRG?= =?iso-8859-1?Q?WFzZ+SQ+P6P98oJwADsZGD5uO7tJaLj623tWm+rEFVXnOVkoYRfHmCtf1Y?= =?iso-8859-1?Q?Sui6HxiTHaLmHs7lD7ZNo5rRHnIlNyII7LD7OUil8EfX4ZCMwTqM4JMrzT?= =?iso-8859-1?Q?QbUu8BseKh9?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB0888; 5:Q+C4rXOluoU+VtnJ3sLJho3tZVaxzHfL25Y86Twctv7IlRR4mo9giL7SHpfA12JF5FrDHiko4UrkHl0T7AsRNU7TuZo9JVFuqJBi41CdsFiVz4B0QGxMdvYi6b4QSL22LRrvUjg1MuwQoad5KUG33w==; 24:bJ4CxzjLbkhdhpv+rs21ikSOOAa4zFf6kJ2oQaMHo/OHJKr/cb23KjxzOuASrrPvkoi2QWIJJTyKdp2V1H1gxWk5J+yoF/nXmge+FEIUGx0=; 20:1kirlpR1DlGqbJ68NHJY8koeMK+OSvrjDylt3tm5E8G/wkP8gHhbmnEpkbxRhY2LVoGEPBZigXoO3maxlI6Q7w== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jul 2015 12:05:16.7393 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB0888 Archived-At: X-Mailman-Approved-At: Wed, 22 Jul 2015 20:54:37 -0700 Subject: [apps-discuss] Fw: Proposed IANA registration of "filesystem" historical URI 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: Wed, 22 Jul 2015 12:05:36 -0000 Saw this on URI and thought it might be an APPSy sort of thing. I did not know that the scheme existed! Tom Petch ----- Original Message ----- From: "Chris Rebert" To: Sent: Saturday, July 18, 2015 12:50 AM > On Mon, Jul 13, 2015, at 05:48 PM, Chris Rebert wrote: > > Hello, > > > > Per the advice of RFC 7595, and also since the relevant defunct > > specification is from the W3C, I hereby present the following proposed > > IANA registration of the "filesystem" historical URI scheme for review. > > Any feedback is greatly appreciated. Thanks. > > > > Chris > > > > ******** > > > > Scheme name: filesystem > > > > Status: Historical > > > The registration has been completed. See: > http://www.iana.org/assignments/uri-schemes/historic/filesystem > > Please CC me on any replies to this thread, as I will be unsubscribing > from this mailinglist shortly. > > Chris From nobody Wed Jul 22 22:39:49 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA49C1A1B2E for ; Wed, 22 Jul 2015 22:39: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 ZZ0zmmyUkRc2 for ; Wed, 22 Jul 2015 22:39:44 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37B861A702B for ; Wed, 22 Jul 2015 22:39:44 -0700 (PDT) Received: by oibn4 with SMTP id n4so158604908oib.3 for ; Wed, 22 Jul 2015 22:39:43 -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=JalP9Act0r8cUs+OI8umxnwiLJHhzABHEzKM0GmUpVI=; b=kaQPmm7FhE8zll3IASCNJkpUdMDe0H7g0Yux+PW/zaO+vn2ISh9AjROWgJuFbq6wDo sFPzfH4SXAwzfgwzN099DbMofLtOap0IRBa3sMbJ00eiY5U1WhwVSENFKpMHUlPdS4mv YxO8WZiBTNbZ1RaVYhlcFbZPGlIOtTNhQxUhRY06ljJUNEB08OQz8V8jIb5rq1gYpzBG HPQeR0kPIfiZTf0tcq/PcZunWy90SG83BNHO3viP2v2X8Cm8T4R+lrU0xhTempHfYEcl ASLk4EQXYFFx/ucW3LUoANSzwW98EmjHdW83Nl9XRs1arhcYp4vuilO4mksoGeB1rgqb niGA== MIME-Version: 1.0 X-Received: by 10.202.239.138 with SMTP id n132mr5450167oih.99.1437629983693; Wed, 22 Jul 2015 22:39:43 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.202.226.205 with HTTP; Wed, 22 Jul 2015 22:39:43 -0700 (PDT) In-Reply-To: <55AE1E50.3090002@ninebynine.org> References: <20150528071826.3803.44025.idtracker@ietfa.amsl.com> <55707C14.5010507@ninebynine.org> <55715580.1090008@ninebynine.org> <55AE1E50.3090002@ninebynine.org> Date: Thu, 23 Jul 2015 15:39:43 +1000 X-Google-Sender-Auth: 3M9nfs6MInWsObKL_94ksS_MQts Message-ID: From: Matthew Kerwin To: Graham Klyne Content-Type: multipart/alternative; boundary=94eb2c0912547f235a051b845018 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 05:39:48 -0000 --94eb2c0912547f235a051b845018 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 21 July 2015 at 20:26, Graham Klyne wrote: > On 20/07/2015 23:51, Matthew Kerwin wrote: > >> On 05/06/2015 5:53 PM, "Graham Klyne" wrote: > > >> >>> >>>> ... >>>>> >>>>> Section 3.2: >>>>> >>>>> [[ >>>>> A file URI can only be translated to a local file path if it has a >>>>> blank or no authority. Note that this differs from the previous >>>>> specification in [RFC1738], in that previously an authority of >>>>> "localhost" was used to refer to the local file system, but in >>>>> this >>>>> specification it equates to a UNC string with the host >>>>> "localhost". >>>>> ]] >>>>> >>>>> I'm uneasy with this non-backwards-compatible change of specification= . >>>>> >>>> In >> >>> the past, I have actually used the "localhost" convention, so that >>>>> >>>> software >> >>> would be rendered incorrect by this revised spec. >>>>> >>>>> >>>>> =E2=80=8BThis point swayed back and forth several times in the earli= est >>>> >>> revisions. >> >>> It eventually settled on the current version because most of the >>>> implementations I'd seen acted that way anyway. Which software support= ed >>>> the originally-specced localhost, if I may ask?=E2=80=8B >>>> >>>> >>> It wasn't a public product, just software I wrote. >>> >>> >> I guess all I have to go with here, at the moment, are anecdotes one way >> or >> the other. What would be the right way to move forward? A tech survey? >> > > My suggestion would be to start with a presumption of no incompatible > changes, but to allow the change is there's a fairly strong consensus to > apply it (e.g. if the change itself represents a significant body of actu= al > use). > > Actually, looking into it more, it seems Chrome on Windows is the only one that interprets "localhost" as a samba server, and then only sometimes. (IE11 doesn't seem to like the name "localhost" even in constructs like "file:////localhost/" ...) In that case I think I really should revert the change, and make "localhost" mean what it used to. I'll do that in the next revision. > >> >>> >>>> ... >>>>> >>>>> Section 4: >>>>> >>>>> "When the file system's encoding is not known the file URI SHOULD be >>>>> transported as an Internationalized Resource Identifier (IRI) [RFC398= 7] >>>>> >>>> to >> >>> avoid ambiguity." >>>>> >>>>> I'm not seeing how this helps. >>>>> >>>>> (1) are we talking about the source system or destination system file >>>>> system encoding being unknown? I'll assume the source. >>>>> >>>>> >>>>> =E2=80=8BYes, the source. The issue arises at the time of interpreti= ng the >>>> URI, >>>> >>> and >> >>> we assume the parser/interpreter and the destination file system share >>>> knowledge about things like encodings -- so that encoding is known. >>>> >>>> >> I should have said here: if the source filesystem's encoding is unknown = to >> the recipient of the URI... >> >> I think, now, this isn't an issue: the URI author writes the URI for the >> recipient, so the author's filesystem has little relevance. If the >> recipient's encoding is unknown to the author, and the author is playing >> nicely, there's no practical difference between an IRI and a %-encoded >> URI. >> > > I agree, and I _think_ (it's been a while) that's why I raised the point. > > >> >>>> (2) If the file system name encoding is unknown, how is one to achiev= e >>>>> a >>>>> mapping to IRIs, which are defined to be a sequence of characters? >>>>> >>>>> >>>>> =E2=80=8BWhen I encode, I can (presumably) map my local encoding to = Unicode, >>>> and >>>> thus create an unambiguous IRI. This is (local)character -> >>>> (unicode)codepoint, without needing a %-encoded intermediate. >>>> >>> >>> >>> I was coming from a viewpoint that there was No knowledge of the filena= me >>> >> encoding used. Your text mentions "Note that many modern file systems >> encode directory and file names as arbitrary sequences of octets. In >> those >> cases, the representation as an encoded string often depends on the user= 's >> localization settings, or defaults to UTF-8" >> >>> >>> >> Ah, yeah, it hadn't occurred to me that an app creating a URI could do s= o >> by looking at the name of a file created by some other user who happened >> to >> have an unpredictable l10n env. >> >> I... don't actually have a solution for this. What happens now, even in >> non-URI contexts, if an application encounters a filename that isn't val= id >> utf-8? >> > > I think that's a matter for the application, if the spec focuses on what > actually gets exchanged. > > > >> >>> So yes, if the character encoding is known, it makes sense to use >>> >> Unicode/UTF-8 for transmission, and the rest works as you suggest. On >> closer reading, your text does suggest a path forward, but I think it >> might >> be clearer ... >> >>> >>> I think part of my confusion here is that the section title (is it a ve= rb >>> >> or a noun?) combined with the first sentence pointed me in the wrong >> direction. And the final para seems to compound my confusion. >> >>> >>> Suggest: >>> >>> First para of section: >>> >>> [[ >>> To avoid ambiguity, 'file:' URIs SHOULD be transported as >>> >> Internationalized Resource Identifiers (IRI) [RFC3987] or as URIs with >> non-ASCII characters UTF-8 encoded and %-escaped as needed (RFC3986, >> section 2.5). >> >>> ]] >>> >>> Then adjust what follows to fall in line with this. I think that's the >>> >> intent of what you're trying to say here? >> >>> >>> >> I lost track at some point of what I was trying to say. I think it was >> Dave >> Thaler who suggested I use IRIs instead of URIs wherever possible; I >> asked: >> >> "[...] are =E2=80=9Cfile URLs=E2=80=9D in Windows in fact not IRIs, but = something even >> more >> general (allowing non-Unicode code pages)?" >> >> And Dave answered: >> >> "URIs are not necessarily %HH-encoded UTF-8. They can be %HH-encoded >> . Sometimes the charset (code page) is known. Sometim= es >> it isn=E2=80=99t known at the point you get a URI, and you cannot simply= assume >> it=E2=80=99s in the system code page, since it may have come from outsid= e the >> local >> system." >> >> So I guess Dave's argument was: %-encoded URIs aren't always >> UTF-8/Unicode, >> but IRIs are always Unicode, so use IRIs. >> > > Ah, interesting point. Dave's right (cf RFC3986 sect 2). But my sense i= s > that folks are trying to move away from that position; e.g. RFC3986 also > says: > > [[ > The URI producer will transform the > local encoding to one that is suitable for a public interface and > then transform the public interface encoding into the restricted set > of URI characters (reserved, unreserved, and percent-encodings). > ]] > > and > > [[ > A system that internally provides identifiers in the form of a > different character encoding, such as EBCDIC, will generally perform > character translation of textual identifiers to UTF-8 [STD63] (or > some other superset of the US-ASCII character encoding) at an > internal interface, thereby providing more meaningful identifiers > than those resulting from simply percent-encoding the original > octets. > ]] > > and > > [[ > When a new URI scheme defines a component that represents textual > data consisting of characters from the Universal Character Set [UCS], > the data should first be encoded as octets according to the UTF-8 > character encoding [STD63]; then only those octets that do not > correspond to characters in the unreserved set should be percent- > encoded. > ]] > > -- http://tools.ietf.org/html/rfc3986#section-2.5 > > I think my suggested text is in the spirit of what you're trying to > achieve, just more explicit that it's OK to %-encode the non-US-ASCII > characters of an IRI. > > =E2=80=8BOkay, fair enough, I'll take your text. Maybe with a friendly warn= ing along the lines of what Dave was saying. > >> If we could guarantee that all %-encoded URIs were UTF-8 I don't think >> there would be a problem. >> > > Yes indeed! (We maybe can't do that, but it seems reasonable to try and > nudge people in that direction.) > > #g > > =E2=80=8BCheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --94eb2c0912547f235a051b845018 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 21 July 2015 at 20:26, Graham Klyne <gk@ninebynine.o= rg> wrote:
On 20/07/2015= 23:51, Matthew Kerwin wrote:
On 05/06/2015 5:53 PM, "Graham Klyne" <gk@ninebynine.org> = wrote:



...

Section 3.2:

[[
A file URI can only be translated to a local file path if it has a
=C2=A0 =C2=A0 =C2=A0blank or no authority.=C2=A0 Note that this differs fro= m the previous
=C2=A0 =C2=A0 =C2=A0specification in [RFC1738], in that previously an autho= rity of
=C2=A0 =C2=A0 =C2=A0"localhost" was used to refer to the local fi= le system, but in this
=C2=A0 =C2=A0 =C2=A0specification it equates to a UNC string with the host = "localhost".
]]

I'm uneasy with this non-backwards-compatible change of specification.<= br>
In
the past, I have actually used the "localhost" convention, so tha= t
software
would be rendered incorrect by this revised spec.


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


It wasn't a public product, just software I wrote.


I guess all I have to go with here, at the moment, are anecdotes one way or=
the other. What would be the right way to move forward? A tech survey?

 My suggestion would be to start with a presumption of no incompatible chang= es, but to allow the change is there's a fairly strong consensus to app= ly it (e.g. if the change itself represents a significant body of actual us= e).


Actually, looking into= it more, it seems Chrome on Windows is the only one that interprets "= localhost" as a samba server, and then only sometimes. (IE11 doesn'= ;t seem to like the name "localhost" even in constructs like &quo= t;file:////localhost/" ...)

In that case I think I really should revert the change, and make "loc= alhost" mean what it used to. I'll do that in the next revision.






...

Section 4:

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

I'm not seeing how this helps.

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


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


I should have said here: if the source filesystem's encoding is unknown= to
the recipient of the URI...

I think, now, this isn't an issue: the URI author writes the URI for th= e
recipient, so the author's filesystem has little relevance. If the
recipient's encoding is unknown to the author, and the author is playin= g
nicely, there's no practical difference between an IRI and a %-encoded = URI.

 I agree, and I _think_ (it's been a while) that's why I raised the = point.



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


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


I was coming from a viewpoint that there was No knowledge of the filename
encoding used.=C2=A0 Your text mentions "Note that many modern file sy= stems
encode directory and file names as arbitrary sequences of octets.=C2=A0 In = those
cases, the representation as an encoded string often depends on the user= 9;s
localization settings, or defaults to UTF-8"


Ah, yeah, it hadn't occurred to me that an app creating a URI could do = so
by looking at the name of a file created by some other user who happened to=
have an unpredictable l10n env.

I... don't actually have a solution for this. What happens now, even in=
non-URI contexts, if an application encounters a filename that isn't va= lid
utf-8?

 I think that's a matter for the application, if the spec focuses on wha= t actually gets exchanged.




So yes, if the character encoding is known, it makes sense to use
Unicode/UTF-8 for transmission, and the rest works as you suggest.=C2=A0 On=
closer reading, your text does suggest a path forward, but I think it might=
be clearer ...

I think part of my confusion here is that the section title (is it a verb
or a noun?) combined with the first sentence pointed me in the wrong
direction.=C2=A0 And the final para seems to compound my confusion.

Suggest:

First para of section:

[[
To avoid ambiguity, 'file:' URIs SHOULD be transported as
Internationalized Resource Identifiers (IRI) [RFC3987] or as URIs with
non-ASCII characters UTF-8 encoded and %-escaped as needed (RFC3986,
section 2.5).
]]

Then adjust what follows to fall in line with this.=C2=A0 I think that'= s the
intent of what you're trying to say here?


I lost track at some point of what I was trying to say. I think it was Dave=
Thaler who suggested I use IRIs instead of URIs wherever possible; I asked:=

"[...] are =E2=80=9Cfile URLs=E2=80=9D in Windows in fact not IRIs, bu= t something even more
general (allowing non-Unicode code pages)?"

And Dave answered:

"URIs are not necessarily %HH-encoded UTF-8.=C2=A0 =C2=A0They can be %= HH-encoded
<something else>.=C2=A0 =C2=A0Sometimes the charset (code page) is kn= own.=C2=A0 Sometimes
it isn=E2=80=99t known at the point you get a URI, and you cannot simply as= sume
it=E2=80=99s in the system code page, since it may have come from outside t= he local
system."

So I guess Dave's argument was: %-encoded URIs aren't always UTF-8/= Unicode,
but IRIs are always Unicode, so use IRIs.

Ah, interesting point.=C2=A0 Dave's right (cf RFC3986 sect 2).=C2=A0 Bu= t my sense is that folks are trying to move away from that position; e.g. R= FC3986 also says:

[[
=C2=A0 =C2=A0The URI producer will transform the
=C2=A0 =C2=A0local encoding to one that is suitable for a public interface = and
=C2=A0 =C2=A0then transform the public interface encoding into the restrict= ed set
=C2=A0 =C2=A0of URI characters (reserved, unreserved, and percent-encodings= ).
]]

and

[[
=C2=A0 =C2=A0A system that internally provides identifiers in the form of a=
=C2=A0 =C2=A0different character encoding, such as EBCDIC, will generally p= erform
=C2=A0 =C2=A0character translation of textual identifiers to UTF-8 [STD63] = (or
=C2=A0 =C2=A0some other superset of the US-ASCII character encoding) at an<= br> =C2=A0 =C2=A0internal interface, thereby providing more meaningful identifi= ers
=C2=A0 =C2=A0than those resulting from simply percent-encoding the original=
=C2=A0 =C2=A0octets.
]]

and

[[
=C2=A0 =C2=A0When a new URI scheme defines a component that represents text= ual
=C2=A0 =C2=A0data consisting of characters from the Universal Character Set= [UCS],
=C2=A0 =C2=A0the data should first be encoded as octets according to the UT= F-8
=C2=A0 =C2=A0character encoding [STD63]; then only those octets that do not=
=C2=A0 =C2=A0correspond to characters in the unreserved set should be perce= nt-
=C2=A0 =C2=A0encoded.
]]

-- http://tools.ietf.org/html/rfc3986#section-2.5<= br>
I think my suggested text is in the spirit of what you're trying to ach= ieve, just more explicit that it's OK to %-encode the non-US-ASCII char= acters of an IRI.


=E2=80=8BOkay, fair en= ough, I'll take your text. Maybe with a friendly warning along the line= s of what Dave was saying.

=C2=A0

If we could guarantee that all %-encoded URIs were UTF-8 I don't think<= br> there would be a problem.

 Yes indeed!=C2=A0 (We maybe can't do that, but it seems reasonable to t= ry and nudge people in that direction.)

#g


=E2=80=8BCheers
--
=C2=A0 Matthe= w Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--94eb2c0912547f235a051b845018-- From nobody Thu Jul 23 05:45:35 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFB91A0155; Thu, 23 Jul 2015 05:45: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 FPinAHBHP0Ib; Thu, 23 Jul 2015 05:45:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B68641A90D5; Thu, 23 Jul 2015 05:45:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.1.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150723124530.2236.14488.idtracker@ietfa.amsl.com> Date: Thu, 23 Jul 2015 05:45:30 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-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: Thu, 23 Jul 2015 12:45:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ART Area General Applications Working Group Working Group of the IETF. Title : The file URI Scheme Author : Matthew Kerwin Filename : draft-ietf-appsawg-file-scheme-03.txt Pages : 20 Date : 2015-07-23 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-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-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 Thu Jul 23 06:36:28 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF991ACCEC for ; Thu, 23 Jul 2015 06:36:27 -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 zxJpRIwwIkKa for ; Thu, 23 Jul 2015 06:36:26 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8FF41A1A3B for ; Thu, 23 Jul 2015 06:36:25 -0700 (PDT) Received: by oihq81 with SMTP id q81so165421670oih.2 for ; Thu, 23 Jul 2015 06:36:25 -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=983NSGqGwJ12HRovCd4N7/CQ6FsFBefFGg4vwljQe84=; b=KhwloAxmRKOMm+pabdR9CmWo2E7FZKS1yqPShiWfdiEryhDwDystadY4oH8WztQBUu s9tiuzCorfyYxduL7iAjTrl7BgexD3LlrKLG9N/JagQKwZCXUsW6mXkn0XahnuIT7wON y/O2RZt5zVPZfjUASoMp9MyYgyRrNnY72Xivs17//bDz+rXgFv7+87xOB5xKv2mFgriM 7LBRoAB8XewX6OJtJIjfEI7bz8GLBM55xQcltRxVNdiGdaahUhkgUtFcmzpX6Of6nBat pD7Lwwca2snmfMo1ZMX+ByOLY0wAaInecFUc4ikctjhmpoWhnecl+SRuJEEBjsBPIPoD sqgw== MIME-Version: 1.0 X-Received: by 10.60.46.200 with SMTP id x8mr8539191oem.73.1437658585369; Thu, 23 Jul 2015 06:36:25 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.202.226.205 with HTTP; Thu, 23 Jul 2015 06:36:25 -0700 (PDT) In-Reply-To: <20150723124530.2236.14488.idtracker@ietfa.amsl.com> References: <20150723124530.2236.14488.idtracker@ietfa.amsl.com> Date: Thu, 23 Jul 2015 23:36:25 +1000 X-Google-Sender-Auth: 7oD5_Qm87n2itMsxHutEVoGsfTY Message-ID: From: Matthew Kerwin To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e0149bfd44a12cb051b8af9b3 Archived-At: Cc: Julian Reschke Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-03.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, 23 Jul 2015 13:36:28 -0000 --089e0149bfd44a12cb051b8af9b3 Content-Type: text/plain; charset=UTF-8 Hi folks, I've published a new version of the file: URI draft. I think it addresses most of the comments received over the course of the exercise. If we could get some reviews at this stage it'd be greatly appreciated. I'd like to think we're on the way towards WGLC; so if you have any issues, now would be a great time to raise them. Cheers On 23 July 2015 at 22:45, 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-03.txt > Pages : 20 > Date : 2015-07-23 > > 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-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-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/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Matthew Kerwin http://matthew.kerwin.net.au/ --089e0149bfd44a12cb051b8af9b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,

I've published a = new version of the file: URI draft. I think it addresses most of the commen= ts received over the course of the exercise.

If we = could get some reviews at this stage it'd be greatly appreciated. I'= ;d like to think we're on the way towards WGLC; so if you have any issu= es, now would be a great time to raise them.

Cheers=

On 23= July 2015 at 22:45, <internet-drafts@ietf.org> wrot= e:

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= The file URI Scheme
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Matt= hew Kerwin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-appsawg-file-scheme-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-07-23

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

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

=C2=A0 =C2=A0*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>.


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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-appsawg-file-scheme-03


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.

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=



--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwi= n.net.au/
--089e0149bfd44a12cb051b8af9b3-- From nobody Fri Jul 24 15:37:51 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A4C1AC3B0 for ; Fri, 24 Jul 2015 15:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWFjcuVJw9qd for ; Fri, 24 Jul 2015 15:37: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 55C511A90A7 for ; Fri, 24 Jul 2015 15:37:49 -0700 (PDT) Received: (qmail 38712 invoked from network); 24 Jul 2015 22:38:04 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 24 Jul 2015 22:38:04 -0000 Date: 24 Jul 2015 22:37:26 -0000 Message-ID: <20150724223726.72685.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [apps-discuss] [appsdir] Cultivating I18N expertise X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jul 2015 22:37:50 -0000 >There's been talk of considering creation of an I18N directorate since >that's an important aspect of recent applications work without enough >diligent review and focused expertise. There's already an apps area directorate, and when I look at the Expertise column, ten of us list i18n or internationalization. I can see places where we're still weak, only three read Chinese and I think none that read Arabic or south Asian languages, but it seems to me we already have a place for this. R's, John From nobody Sat Jul 25 11:32:14 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403421A8888 for ; Sat, 25 Jul 2015 11:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 hQ3qOENPD3W1 for ; Sat, 25 Jul 2015 11:32:12 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::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 702981A879C for ; Sat, 25 Jul 2015 11:32:12 -0700 (PDT) Received: by pabkd10 with SMTP id kd10so29929420pab.2 for ; Sat, 25 Jul 2015 11:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:subject:mime-version:content-type; bh=ADcYzQYSLTunKgCyeqX4nq/VwvAf0/asnPDBeaUAYyc=; b=X5xEkgkjOMZNcozK+Vsf0vbN2VhA0VwABK8nia/sHl4nj2EgAa/AP/UFZLBtgFjrL3 gXJ0xzWbjp0yzUengvfAzXGfG6q5O5Oaa3Jtq/DbPonPCs+R1Lyql0IYMmOl/c17+jLo zupeuwcmkjM5UPl+R3zNosGqPCTL0t/HsV0BXzzWQNeWhcswO3WX/3Fg3imLf5DU3jvw BDh9aO23N2bAJwIE4/aHDCGmIwNFoSwS8ME2ZTbJJfs2PmC6x02BnzqtZIqzxqjog1Sh KhlLXVXh4os6WFigJ5VVCQzkXo0xUvOOI0Cq6XXVMckj2HNYelAD6n0bAECsyqoYNeug qD6w== X-Received: by 10.66.139.193 with SMTP id ra1mr46088211pab.131.1437849132005; Sat, 25 Jul 2015 11:32:12 -0700 (PDT) Received: from clg8223.visto-mgmt.com ([206.124.114.135]) by smtp.gmail.com with ESMTPSA id fk5sm21173434pab.40.2015.07.25.11.32.10 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 25 Jul 2015 11:32:11 -0700 (PDT) Date: Sat, 25 Jul 2015 18:32:11 +0000 (GMT) From: cakaara99@gmail.com To: apps-discuss@ietf.org Message-ID: <2145647269.18304.1437849131401.JavaMail.wibapp@clg8223.visto-mgmt.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_18303_2071202956.1437849131400" Archived-At: Subject: [apps-discuss] Comferm http message X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jul 2015 18:32:13 -0000 ------=_Part_18303_2071202956.1437849131400 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subscript my message senders my account is a cakaara99@gmail.com and my mobile modern is a lg-c199 /version1 and my phone-number is a +252634204733 ------=_Part_18303_2071202956.1437849131400-- From nobody Thu Jul 30 13:08:18 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2156D1A023E; Thu, 30 Jul 2015 13:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4nC_BNmghrF; Thu, 30 Jul 2015 13:08:15 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA491A044F; Thu, 30 Jul 2015 13:08:12 -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=1438286895; x=1469822895; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=+B0R1Rm1sa8y5MAryaP0SrP054M0Q1zMWM7Z/myI61A=; b=mvtlfFGigftyioDuMAqs9vNMewKs3hhgTgp0QgY5zzYyvO+kpu5E3BRp K5Odmb/Snb32JMwk+/lHAIOpGh+0RxrTrk17ZUBaTSK6ZniEE5fdO7N0b 8ZtZ5DOoBsNkY6OMnlqQWAYpm8mkU3ZumooxqoQHlzOnaZX4uES+qMcfM s=; X-IronPort-AV: E=McAfee;i="5700,7163,7878"; a="130556084" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jul 2015 13:08:12 -0700 X-IronPort-AV: E=Sophos;i="5.15,578,1432623600"; d="scan'208";a="945868458" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 30 Jul 2015 13:08:11 -0700 Received: from [10.64.164.175] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 30 Jul 2015 13:08:10 -0700 From: Pete Resnick To: , Date: Thu, 30 Jul 2015 15:08:07 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate Trial (1.9.2r5107) X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: iesg@ietf.org Subject: [apps-discuss] Appdir Review of draft-ietf-httpbis-cice-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2015 20:08:17 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see ​http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-httpbis-cice Title: Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding Reviewer: Pete Resnick Review Date: 2015-07-30 IETF Last Call Date: 2015-07-21 IESG Telechat Date: Unknown Summary: This draft is basically ready for publication as a Proposed Standard, but there are a few minor issues that might need to be addressed. Comments: No major issues at all in this document, but a couple of things to consider. Minor Issues: Section 3 of this document seems to change the MAY in RFC 7231 section 3.1.2.2 regarding the 415 response to a SHOULD. I don't see any particular justification for that. It seems simpler to leave that alone and make the following change: OLD Servers that fail a request due to an unsupported content coding SHOULD respond with a 415 status and SHOULD include an "Accept- Encoding" header field in that response, allowing clients to distinguish between content coding related issues and media type related issues. NEW Servers that fail a request due to an unsupported content coding and respond with a 415 status SHOULD include an "Accept-Encoding" header field in that response, allowing clients to distinguish between content coding related issues and media type related issues. If you are going to change the MAY to a SHOULD, I’m guessing this document would end up updating 7231. Again, I don’t suggest you do that. Section 6: This may be completely off the wall, but is there any way that a server could convince a client to do something stupid and/or dangerous by asking it for a different suggested encoding? Unlike using it for requests, putting an Accept-Encoding in a response is telling the client, "Please try again, this time using encoding X". If it blindly does so, could a client get itself in trouble? Like I said, this might be completely silly, but someone who knows HTTP better than I should probably say, "No, this isn't going to cause a problem." Nits: In the Abstract and in section 1: to indicate that content codings are supported in requests. Don't you mean "to indicate the content codings that are supported in requests" or "to indicate which content codings are supported in requests"? Section 5: OLD 6.5.13 of [RFC7231] recommends using the status code 415 (Unsupported Media Type) NEW 6.5.13 of [RFC7231] defines the status code 415 (Unsupported Media Type) for this purpose No other issues that I can find or invent; looking generally fine. pr From nobody Fri Jul 31 02:48:10 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C0D1ACC87 for ; Tue, 28 Jul 2015 08:16:24 -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 YhkCKoB7YVMX for ; Tue, 28 Jul 2015 08:16:23 -0700 (PDT) Received: from mail-yk0-f179.google.com (mail-yk0-f179.google.com [209.85.160.179]) (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 E103F1ACC7F for ; Tue, 28 Jul 2015 08:16:22 -0700 (PDT) Received: by ykax123 with SMTP id x123so98319071yka.1 for ; Tue, 28 Jul 2015 08:16:22 -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:from:date:message-id:subject :to:content-type; bh=nN30IL8ba7z2myJEhKZTPmxTjVm+QD/fDie6NbPUe+M=; b=TGS0YqrYC1e5rUGHu13bLLWTjafBYW1uOrNaSyld5VlQVUvOviREICKMLpXRC98pq0 u69CFyVVS/AYYsNflyhCSq64s9xJiVSdt/jroQ/kRKV2Sw+8l40UvX6E7lcJ3msCkAz+ uxaOrsX9mqib6EgBgeldQxK2cYtydpgEtDt03UGdcSMI6DS1QW+Tn72D7V75P28g0slO 2qST1YXbkvmurU2CRrJUkHx5WEqfcuX6GhX9I1Qlp4NobBP/rpav8lo+tvFr8lWR+HsW DVqCrjvdOhpSO7JqEXiyTNFveHQLAzqsFjhq75/uemCQC9/1saLg/bbnx1l9+YGbHEe5 CQCA== X-Gm-Message-State: ALoCoQnjoGOcDt7Qy8TCAwjV6iiIH/51PLJhKKcjhM+PREHPJ5KZEHjn8xEEwdDu7Gc5qsl6oYe8 X-Received: by 10.170.99.196 with SMTP id q187mr37208304yka.123.1438096582113; Tue, 28 Jul 2015 08:16:22 -0700 (PDT) MIME-Version: 1.0 Sender: yakov@shaftek.org Received: by 10.37.69.213 with HTTP; Tue, 28 Jul 2015 08:15:52 -0700 (PDT) X-Originating-IP: [108.15.50.95] From: Yakov Shafranovich Date: Tue, 28 Jul 2015 11:15:52 -0400 X-Google-Sender-Auth: wFDoCkv9Ar7n4ahBxkYxKaFHwvM Message-ID: To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Fri, 31 Jul 2015 02:48:09 -0700 Subject: [apps-discuss] fwd: Four CSVW documents are W3C candidate recommendations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jul 2015 15:16:24 -0000 W3C's CSV on the Web (CSVW) group has published several candidate recommendations and is looking for feedback. Details are here: http://www.w3.org/blog/news/archives/4830 Feedback can be sent here: Email - public-csv-wg-comments@w3.org Web - https://github.com/w3c/csvw/issues The work is built on RFC 4180 which was originally approved through the IETF (I am the author of that RFC). Thanks, Yakov From nobody Fri Jul 31 03:41:18 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C6A1A0127; Fri, 31 Jul 2015 03:41:13 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXULc0PM7qFH; Fri, 31 Jul 2015 03:41:11 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FA4A1A011D; Fri, 31 Jul 2015 03:41:11 -0700 (PDT) Received: from [192.168.1.197] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M85r3-1Yyu0L1TQP-00vbtM; Fri, 31 Jul 2015 12:41:08 +0200 To: Pete Resnick , apps-discuss@ietf.org, draft-ietf-httpbis-cice.all@ietf.org References: From: Julian Reschke Message-ID: <55BB50BF.1010805@gmx.de> Date: Fri, 31 Jul 2015 12:41:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:pblfXDNeTMjc5DXsXjuwDr+U254jMeu35de5VmQQms9ZiunYutd bA+Tlp4cPW2Ca1ZxGbfEaEZsnr/tLCI0ta6q8uk2xint8eIW1OW6TxPLN2TeiSYlB1Ryeu7 0yN2wIfRbl7ABLKlT3pluaGerLOdeILSuyLhCh4++BHk9uJrUkqyyvfj8nkMBDbnQO6aaD4 SbSZu2ZIHfe2P5EExI5Hg== X-UI-Out-Filterresults: notjunk:1;V01:K0:A4DrWnmLEFc=:CSXVn+VXeNTwz6YUBo7j+l NWwnkdWLiodoFByOsPtwKu+rkhe97cJEpM/vG+i5a1teGtFG7hjeGyFF70Pj1EHsTAJrJCeV2 7MEHvryRC1Eirak4fuA4QemGqzdhXHP6uqEk711o3UsOtUPPKRgZY9JuxPy10ra2X2jdZUHZJ 8fBLd/9L8aTt4dJVEPWoQPkcE9PH6HwpTIOCiyVU+CeIhrxGOnXr7F8GNp459/3Yao3s0Wwaq GDBvKVKGD3x1sm1KBrchEgw8manMal5zXVxp554E3KFW6nDA7WO12DpBrHVtKMWtcFAr8Va5C 0X719AnIg3CGwnjXVCzV7OjsxZI1A36MW0TArzh7l4emfKQhGgdd3pCtyj2BnGU6ZQYHOgMul kT/q1Uv620OAOm/c0MON1SWiCuhr9QPvCA8obYNyvDQWhNCJkbD8mC/XMCmsGpVoS4jNpIR2y IgAg49ruZ1K6pFpXJC9bhg7Df7D8ukKOpICO4am8d/oO3YQo0Sg+6zTXNnRjtEduUC2MZRsy0 RJmaBgeeIZcrwu9JmoYcIjzBhsGSr8Cy7zjgvTHSvEKgS35fkNB3duJxJeQ+XMEV8tf/7CHC6 nVJQUvir8eZkNz1hXqp0FPavSfLT/jRtApSAdD5MeJP/YBnc4LyPyz/aXo4pgpTqribIfDY8l uxtx8Gmz2+pulLFJ2jrC2boMESonFld8+q/2Jbu1XbnSjU34ZVCZGzgC4LvmSc4Tyag8= Archived-At: Cc: iesg@ietf.org, HTTP Working Group Subject: Re: [apps-discuss] Appdir Review of draft-ietf-httpbis-cice-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2015 10:41:13 -0000 Hi Pete, thanks for the feedback. I'm ccing the WG.... On 2015-07-30 22:08, Pete Resnick wrote: > ... > Comments: > > No major issues at all in this document, but a couple of things to > consider. > > Minor Issues: > > Section 3 of this document seems to change the MAY in RFC 7231 section > 3.1.2.2 regarding the 415 response to a SHOULD. I don't see any > particular justification for that. It seems simpler to leave that alone > and make the following change: I'd say that this is intentional. We really *want* people conforming to this spec to sue 415 in this cases, so a SHOULD seems to be justified. > OLD > Servers that fail a request due to an unsupported content coding > SHOULD respond with a 415 status and SHOULD include an "Accept- > Encoding" header field in that response, allowing clients to > distinguish between content coding related issues and media type > related issues. > NEW > Servers that fail a request due to an unsupported content coding and > respond with a 415 status SHOULD include an "Accept-Encoding" header > field in that response, allowing clients to distinguish between > content coding related issues and media type related issues. > > If you are going to change the MAY to a SHOULD, I’m guessing this > document would end up updating 7231. Again, I don’t suggest you do that. IMHO we should avoid using the "updates" hammer for minor changes like these; we have the IANA registries for a reason. This spec already updates the entry for "Content-Encoding"; one could argue we need to update the one for 415 as well. Feedback appreciated. > Section 6: This may be completely off the wall, but is there any way > that a server could convince a client to do something stupid and/or > dangerous by asking it for a different suggested encoding? Unlike using > it for requests, putting an Accept-Encoding in a response is telling the > client, "Please try again, this time using encoding X". If it blindly > does so, could a client get itself in trouble? Like I said, this might > be completely silly, but someone who knows HTTP better than I should > probably say, "No, this isn't going to cause a problem." > > > Nits: > > In the Abstract and in section 1: > > to indicate that content codings are supported in requests. > > Don't you mean "to indicate the content codings that are supported in > requests" or "to indicate which content codings are supported in requests"? The first proposal sounds good to me. > Section 5: > > OLD > 6.5.13 of [RFC7231] recommends using the status code 415 (Unsupported > Media Type) > NEW > 6.5.13 of [RFC7231] defines the status code 415 (Unsupported Media > Type) for this purpose > > No other issues that I can find or invent; looking generally fine. Yep; yet another good improvement. Best regards, Julian From nobody Fri Jul 31 05:22:46 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634631A1A6F; Fri, 31 Jul 2015 05:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lT8laVgAuvpk; Fri, 31 Jul 2015 05:22:40 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57D11A1A00; Fri, 31 Jul 2015 05:22:40 -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=1438345360; x=1469881360; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Cwdaj7PQviPXm4nJ7qAKLy7T6DfT8ggRKtcmmj09I68=; b=vFNFp+mvxleCbPiQulZ510Qn4ssyTLcbJIBfdtN+/Rc0wD3Nh9PYoL6n QXqGVcMrkAOOVADaQ5orEyc638+yzHMQDH++h3rtXzihY5RCYOd7P5UFo ElipfocX2YtcqIVcqbszZDrtI3dF7hlWLxUps9kz4+ScDmmOzCwGOHPTG g=; X-IronPort-AV: E=McAfee;i="5700,7163,7878"; a="93833030" Received: from unknown (HELO Ironmsg04-R.qualcomm.com) ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Jul 2015 05:22:40 -0700 X-IronPort-AV: E=Sophos;i="5.15,584,1432623600"; d="scan'208";a="1027719886" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 31 Jul 2015 05:22:35 -0700 Received: from [10.64.160.186] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 31 Jul 2015 05:22:32 -0700 From: Pete Resnick To: Julian Reschke Date: Fri, 31 Jul 2015 07:22:28 -0500 Message-ID: In-Reply-To: <55BB50BF.1010805@gmx.de> References: <55BB50BF.1010805@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate Trial (1.9.2r5107) X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.85.0.33) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: draft-ietf-httpbis-cice.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org, HTTP Working Group Subject: Re: [apps-discuss] Appdir Review of draft-ietf-httpbis-cice-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2015 12:22:42 -0000 On 31 Jul 2015, at 5:41, Julian Reschke wrote: > On 2015-07-30 22:08, Pete Resnick wrote: >> ... >> Comments: >> >> No major issues at all in this document, but a couple of things to >> consider. >> >> Minor Issues: >> >> Section 3 of this document seems to change the MAY in RFC 7231 >> section >> 3.1.2.2 regarding the 415 response to a SHOULD. I don't see any >> particular justification for that. > > I'd say that this is intentional. We really *want* people conforming > to this spec to sue 415 in this cases, so a SHOULD seems to be > justified. Well, “want” is not a reason to make a protocol requirement :-) , but I think I get your meaning: It *is* important for better interoperability for people to use this. >> If you are going to change the MAY to a SHOULD, I’m guessing this >> document would end up updating 7231. Again, I don’t suggest you do >> that. > > IMHO we should avoid using the "updates" hammer for minor changes like > these; we have the IANA registries for a reason. > > This spec already updates the entry for "Content-Encoding"; one could > argue we need to update the one for 415 as well. Feedback appreciated. Barry should weigh in on this, but here’s my take: IANA registries are not meant to impose protocol requirements; IANA registry entries are just meant to define code points. If there’s a requirement that the implementer needs to know about, that belongs in the spec. And in this case, you *are* really saying, “We had this optional thing in 7231, but we’ve found that there’s good interoperability reason for implementers to do this in a particular way, so we’re letting you know that we’ve made a change.” I don’t think “Updates” is a big hammer; it’s a document reference mechanism. (Yes, I wish we had a more surgical tool for this kind of thing, but I think “Updates” is OK for this.) >> Section 6: This may be completely off the wall, but is there any way >> that a server could convince a client to do something stupid and/or >> dangerous by asking it for a different suggested encoding? Unlike >> using >> it for requests, putting an Accept-Encoding in a response is telling >> the >> client, "Please try again, this time using encoding X". If it blindly >> does so, could a client get itself in trouble? Like I said, this >> might >> be completely silly, but someone who knows HTTP better than I should >> probably say, "No, this isn't going to cause a problem." Should I take your silence on the above to mean, “Pete, you’re a goofball” or simply “No comment”? ;-) >> Nits: >> >> In the Abstract and in section 1: >> >> to indicate that content codings are supported in requests. >> >> Don't you mean "to indicate the content codings that are supported in >> requests" or "to indicate which content codings are supported in >> requests"? > > The first proposal sounds good to me. > >> Section 5: >> >> OLD >> 6.5.13 of [RFC7231] recommends using the status code 415 (Unsupported >> Media Type) >> NEW >> 6.5.13 of [RFC7231] defines the status code 415 (Unsupported Media >> Type) for this purpose >> >> No other issues that I can find or invent; looking generally fine. > > Yep; yet another good improvement. Thanks. Glad they helped. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Fri Jul 31 05:40:45 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170E91A1AAE; Fri, 31 Jul 2015 05:40:40 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQPwz1JdStw6; Fri, 31 Jul 2015 05:40:38 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 082B91A1A86; Fri, 31 Jul 2015 05:40:22 -0700 (PDT) Received: from [192.168.1.197] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M6wWn-1Z03x11kft-00wi1x; Fri, 31 Jul 2015 14:40:18 +0200 To: Pete Resnick References: <55BB50BF.1010805@gmx.de> From: Julian Reschke Message-ID: <55BB6CB1.6010909@gmx.de> Date: Fri, 31 Jul 2015 14:40:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:K43SyFlwXrHNS2swX6ZgtDFPWEeZCIKokoFmEIqZvwUyb7nL17M Bhxm9xwRJpfl/r82sWX2o48hpu8PVc2sqQGOBhnZQBOvDPex5Au9ShnuURAVEQYoD/6Wn3c Ui5NQ6aCum4tTgXfCesUeSe0osDigZNOn4UAptpbbeAduJ5+SZNp0GU6iAd5zmVKzVXIeMU UjpVJQInF5sSvGd1iS3Wg== X-UI-Out-Filterresults: notjunk:1;V01:K0:V7j34iCvNcI=:irB0ZNftBcTgEccUZwkc2q mT42CyZXilmWMKsrwCF2DXOy3YkXFINu7yRaGV3sVYJhSGMaPDynGwa7IXpwPSYADi3hsQLJl CbvZJ4Bm++QsyZWt8xbnWBd2Zspz0MKYRnV8RuBXe6fjYx8ul/hRQzT5GYyjTeViFwaJq+hVI 1p1SJ6QQym8QhunfZ1NpfQVt4QwFCbNYVEFpeGfTSGKjkOFTNWB74Iw5w4wh2+s53j5a6Noen oNA8oe55faSwyyakeAhwigJzadjpdaf+ho7/rXCfyDAWy44mBqm0anLD5OlMiUOnIRDamuSAu 0niG23XDw5UXYYEHCvotHAbFOZNki94SnRYJrGjC6d9taxHcWyjFByKl28clKm9jqCnA+NzYU Kz6YnI9QJQxjAAPXzSNobAKzofb/hcWCvaR02M7weMfzR5RgQVm/Hhl0ZQCP5Ko69enqFY6El zmxvIsDFR61Fe91O8/UcZXNs2g+N6WaMy1sfqNs3r0li1cMc3qf55sOM2x5gi+wX6ODCJ0Uij lY1JGg59RuTkGLz3Mk5Whji266lfU+Iwt2EM2QVRcXNjeU22D6pVtyVtyms3Uqq0hdC4zL9Z5 hVnwRgjZbXOANW7c7PwrqSMAI+Sxaxf6XFAmCxNkLU2MMkDlTKwE7lFN/qlHLT7LkRNbWONv/ 0fjAozUAEqiWA+iwYG/zHlMA36wRNT7FSaRVmVQumsSkFBpsILyx6Zf38NONThUENbX0= Archived-At: Cc: draft-ietf-httpbis-cice.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org, HTTP Working Group Subject: Re: [apps-discuss] Appdir Review of draft-ietf-httpbis-cice-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2015 12:40:40 -0000 On 2015-07-31 14:22, Pete Resnick wrote: > On 31 Jul 2015, at 5:41, Julian Reschke wrote: > >> On 2015-07-30 22:08, Pete Resnick wrote: >>> ... >>> Comments: >>> >>> No major issues at all in this document, but a couple of things to >>> consider. >>> >>> Minor Issues: >>> >>> Section 3 of this document seems to change the MAY in RFC 7231 section >>> 3.1.2.2 regarding the 415 response to a SHOULD. I don't see any >>> particular justification for that. >> >> I'd say that this is intentional. We really *want* people conforming >> to this spec to sue 415 in this cases, so a SHOULD seems to be justified. > > Well, “want” is not a reason to make a protocol requirement :-) , but I > think I get your meaning: It *is* important for better interoperability > for people to use this. The whole point of this protocol is to expose this information, so saying "MAY" here would be contrary to that goal. >>> If you are going to change the MAY to a SHOULD, I’m guessing this >>> document would end up updating 7231. Again, I don’t suggest you do that. >> >> IMHO we should avoid using the "updates" hammer for minor changes like >> these; we have the IANA registries for a reason. >> >> This spec already updates the entry for "Content-Encoding"; one could >> argue we need to update the one for 415 as well. Feedback appreciated. > > Barry should weigh in on this, but here’s my take: IANA registries are > not meant to impose protocol requirements; IANA registry entries are > just meant to define code points. If there’s a requirement that the To define them, but also to have a way to find the current definition of that protocol point. So the main question here really is whether this is an optional protocol extension or not. The intent was to make this optional (we don't want to break existing servers that do not do this), but also to encourage people to implement this. > implementer needs to know about, that belongs in the spec. And in this > case, you *are* really saying, “We had this optional thing in 7231, but > we’ve found that there’s good interoperability reason for implementers > to do this in a particular way, so we’re letting you know that we’ve > made a change.” I don’t think “Updates” is a big hammer; it’s a document > reference mechanism. (Yes, I wish we had a more surgical tool for this > kind of thing, but I think “Updates” is OK for this.) > >>> Section 6: This may be completely off the wall, but is there any way >>> that a server could convince a client to do something stupid and/or >>> dangerous by asking it for a different suggested encoding? Unlike using >>> it for requests, putting an Accept-Encoding in a response is telling the >>> client, "Please try again, this time using encoding X". If it blindly >>> does so, could a client get itself in trouble? Like I said, this might >>> be completely silly, but someone who knows HTTP better than I should >>> probably say, "No, this isn't going to cause a problem." > > Should I take your silence on the above to mean, “Pete, you’re a > goofball” or simply “No comment”? ;-) No, it means I forgot to reply. And no, I don't think there's a problem here. >>> Nits: >>> >>> In the Abstract and in section 1: >>> >>> to indicate that content codings are supported in requests. >>> >>> Don't you mean "to indicate the content codings that are supported in >>> requests" or "to indicate which content codings are supported in >>> requests"? >> >> The first proposal sounds good to me. >> >>> Section 5: >>> >>> OLD >>> 6.5.13 of [RFC7231] recommends using the status code 415 (Unsupported >>> Media Type) >>> NEW >>> 6.5.13 of [RFC7231] defines the status code 415 (Unsupported Media >>> Type) for this purpose >>> >>> No other issues that I can find or invent; looking generally fine. >> >> Yep; yet another good improvement. > > Thanks. Glad they helped. > > pr Best regards, Julian From nobody Fri Jul 31 18:59:22 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23A21A87B3; Fri, 31 Jul 2015 18:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDC24vr8wov4; Fri, 31 Jul 2015 18:59:21 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 3CC6D1A87B8; Fri, 31 Jul 2015 18:59:12 -0700 (PDT) Received: by vkgc186 with SMTP id c186so26867839vkg.0; Fri, 31 Jul 2015 18:59:11 -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:content-transfer-encoding; bh=DJY+XZo/EWfJncmt/X6AnZw5360H2IkB932ZFCGQ0Ag=; b=pzJFVclCBcBVU6D2K9J3nQEnUhtfGH7HSFOUAZATWbNANAFg8upGNFz3XPCqWToxya iMEVzBBC7ts4k0Pi8dxB1KBvAsL7U9STJv57dbnwqlDKGNWsBDXMBUleWWZ1RbgVvKWe FljrvQy7fFs0NyRvVCr9RHHoGdFiOaMG20PJgCyyNw8G+BF3Q6A/MCGlOSbEVwG4xaPP DOSuEZ/0trJgkrGh4WEeri0XNW7OC49Wv8JEkdWKGlRHoVB3YI7YEJ6WzmhKxvBP2jCE ZGxgkqzR82jialNKP4eyZGBd/EYl5YbI/siRrKk/OaS1aZJooQZNE2SxrXcdsxUBO2MF K10g== MIME-Version: 1.0 X-Received: by 10.52.122.52 with SMTP id lp20mr9220521vdb.64.1438394351585; Fri, 31 Jul 2015 18:59:11 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Fri, 31 Jul 2015 18:59:11 -0700 (PDT) In-Reply-To: <55BB6CB1.6010909@gmx.de> References: <55BB50BF.1010805@gmx.de> <55BB6CB1.6010909@gmx.de> Date: Sat, 1 Aug 2015 03:59:11 +0200 X-Google-Sender-Auth: mR0EUzTkbSREAA_S_LhwzjC9Fo4 Message-ID: From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-httpbis-cice.all@ietf.org, Pete Resnick , IESG , Apps Discuss , HTTP Working Group Subject: Re: [apps-discuss] Appdir Review of draft-ietf-httpbis-cice-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2015 01:59:22 -0000 >>>> If you are going to change the MAY to a SHOULD, I=E2=80=99m guessing t= his >>>> document would end up updating 7231. Again, I don=E2=80=99t suggest yo= u do that. >>> >>> This spec already updates the entry for "Content-Encoding"; one could >>> argue we need to update the one for 415 as well. Feedback appreciated. >> >> Barry should weigh in on this, but here=E2=80=99s my take: IANA registri= es are >> not meant to impose protocol requirements; IANA registry entries are >> just meant to define code points. If there=E2=80=99s a requirement that = the > > To define them, but also to have a way to find the current definition of > that protocol point. Right. The best way to handle this particular situation isn't to make this "update" 7231, but to add this to [RFC7231] in the reference field for status code 415 in the registry. On the other hand, let me probe Pete's point a bit: Someone reads 7231 and sees the definition for 415. That someone doesn't read this, perhaps because she doesn't know about it. She also doesn't look at the registry entry, and thus doesn't see the reference, because, after all, it's clear that 7231 defines 415, so why would one need to look at the registry entry for 415? In a case such as that, "updates" could be useful. I'm ambivalent about whether we should do that, though -- we are trying to avoid using "updates" for optional extensions. Barry From nobody Fri Jul 31 23:06:48 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02ADA1B2A77; Fri, 31 Jul 2015 23:06:47 -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 r8kT2XpwQOIy; Fri, 31 Jul 2015 23:06:45 -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 618CA1B2A76; Fri, 31 Jul 2015 23:06:45 -0700 (PDT) Received: from [192.168.2.177] ([93.217.93.149]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M9aX9-1ZA7fo1JOR-00Cz7a; Sat, 01 Aug 2015 08:06:11 +0200 To: Barry Leiba References: <55BB50BF.1010805@gmx.de> <55BB6CB1.6010909@gmx.de> From: Julian Reschke Message-ID: <55BC61D3.4060600@gmx.de> Date: Sat, 1 Aug 2015 08:06:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:s87/4wW4y/2CHCrjx+cE2L3evwTQE9lcZvAWHOQxmHGYJyJK+Id WnWSPGv9I6rU58iPrUhyFGqyWlKZB6x8HKbg4KtcAGpTjdrZjlUNhY4TZVqcZYx2sdW5zgd 5GhDBXoZR1A+rfhVIbGgJfVnj+ZotWso4euuB+ANWTcS2ql/NjcrbQ/dOCOZrhEF76Opbnu mPn56p5C/+qsowsdlXP0A== X-UI-Out-Filterresults: notjunk:1;V01:K0:6cd+9G50bMM=:sCFYuLWgxaQ/vQe3j6lTA7 AkstkyWN12mH95zvSpQ3jMAFW4rig+EJzRzAdsTNGVSKL6NTlNh8BJFgIJQ2eC1u6QLu7vpTe tUcEl8oo15dC7Cct/bxAyimUbrXyoayv0StJQkcYKdiJyn5MhtvqMq9R5zHPnou1muS5IXeqV mXz+lGll8AhZ3hUxpC8pEYqwomd2US7M/QaN1epyAoirNbGXDmnCsC3mOCb+vcM2IKasNLBG2 EXRR1LvShpLxVNX/AgZ0Tov9G9aPnrRV1iXK0UI1VYd94pnDGBmplGe3kYaSGhXPT2K2TXjuH pYM654m91+Nm9Y/ezwlH11kI/Ltlg+1oK4Af/EfvSIkluWMSVnSS+lnxGWKlJ735/ZGQA90D7 /Md70oXzgFeqABzezQV5xFuPOHjwBnq0ass+u7gHwP00QSOIWup2MxxVQb/fAZppnuh7gLm6X sJxU6KVSlx8uGutCM32+LV+iPZJI4RY+xN3fmC2NZpYcBJbUpMdcln4K/cQejCQdE5csVfi/C 0K7Jd2ymeJQtwCp+aFwsGCTjgbAzviS6KF9DLbWVvfNpX02h6fpS6vTMrCekSdF5d4rA3qbHh GnG5kVVxRDycXjKhZdSCuw5sblaQG+/kvFVIzxyUVjk7gaxVoSr4WmYCIMP14UhK+o/fOAgWX MgSVlx4QKHPuU7iFuOLgqdMLTS+HMVmKI7/vZexlz/lkAPlwKpVgtuQVbLvZretyZln0= Archived-At: Cc: draft-ietf-httpbis-cice.all@ietf.org, Pete Resnick , IESG , Apps Discuss , HTTP Working Group Subject: Re: [apps-discuss] Appdir Review of draft-ietf-httpbis-cice-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2015 06:06:47 -0000 On 2015-08-01 03:59, Barry Leiba wrote: > ... > Right. The best way to handle this particular situation isn't to make > this "update" 7231, but to add this to [RFC7231] in the reference > field for status code 415 in the registry. > > On the other hand, let me probe Pete's point a bit: > Someone reads 7231 and sees the definition for 415. That someone > doesn't read this, perhaps because she doesn't know about it. She > also doesn't look at the registry entry, and thus doesn't see the > reference, because, after all, it's clear that 7231 defines 415, so > why would one need to look at the registry entry for 415? > ... That is true. But would that person actually *find* the document updating RFC 7231 in the first place? It's not like we're changing the RFC 7231, we'd just be changing the RFC database. (And yes, if the user would read 7231 through tools.ietf.com or greenbytes.de, that information would actually appear on the RFC; but how good does this scale once we have 10 documents "updating" 7231?) > In a case such as that, "updates" could be useful. I'm ambivalent > about whether we should do that, though -- we are trying to avoid > using "updates" for optional extensions. Agreed. Best regards, Julian