From nobody Wed Oct 1 06:38:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF871ACDA7 for ; Wed, 1 Oct 2014 06:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 ufZ4sxuD6Q3P for ; Wed, 1 Oct 2014 06:38:25 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 251621A19E9 for ; Wed, 1 Oct 2014 06:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=772; q=dns/txt; s=iport; t=1412170690; x=1413380290; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qdotS1EF5gZbHSEljTkobgko7aoayySGdZgiz22wdAA=; b=mrbGdMiqbQ0NzCP2QQZ9On7Z7BxnvJi/rNGT0pyCs6Y4FGfYjTGRaLCD e6iDNM6QJMKkqYUtv9YaXHUlixM8By1SL+j5e+6M5Mxj9a+z3JRAJhKUu 0QUBvP3WhTFH3Vg1bYZwJZFOE01SE2TOukZNh5+stFO6NNAq9ess3STxd M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAIoDLFStJV2a/2dsb2JhbABggw6BLASCfs8HAhlyFgF7hAQBAQQjEUUQAgEIGgImAgICMBUQAgQBDQWIPqg7lXABF4EsjkczB4J4NoEdAQSRbYtGlXODY2yBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,632,1406592000"; d="scan'208";a="83068684" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP; 01 Oct 2014 13:38:09 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s91Dc9Wt022432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Oct 2014 13:38:09 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Wed, 1 Oct 2014 08:38:09 -0500 From: "Joe Hildebrand (jhildebr)" To: John C Klensin , Sean Leonard , "Murray S. Kucherawy" , Ned Freed Thread-Topic: [apps-discuss] IETF 91 scheduling Thread-Index: AQHP3CUNiOxAqlRxXEaz22swIFnVrJwY+T+AgADN54CAAYszgA== Date: Wed, 1 Oct 2014 13:38:08 +0000 Message-ID: <7D73F05D-28A9-4564-9663-F5DA956EBBA9@cisco.com> References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> <9AD273B04D7CB4B07CE8D1C5@JcK-HP8200.jck.com> In-Reply-To: <9AD273B04D7CB4B07CE8D1C5@JcK-HP8200.jck.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.3.0.140829 x-originating-ip: [10.21.66.26] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/qNUvYGnrwlV_9uZLalQWtD2Zsfw Cc: IETF Apps Discuss Subject: Re: [apps-discuss] IETF 91 scheduling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 13:38:34 -0000 T24gOS8zMC8xNCwgMTA6MDMgQU0sICJKb2huIEMgS2xlbnNpbiIgPGpvaG4taWV0ZkBqY2suY29t PiB3cm90ZToNCg0KPk9uIHRoZSBvdGhlciBoYW5kLCB0aGVyZSBpcyBzb21ldGhpbmcgZXh0cmEt c3BlY2lhbCwgd2hpY2ggaXMNCj5mcmVxdWVuY3kgb2YgdXNlLCBhbmQgdGhpbmdzIGhhdmUgY2hh bmdlZCBhIGxvdCBzaW5jZQ0KPkNvbnRlbnQvTWVkaWEgdHlwZXMgd2VyZSBmaXJzdCBkZWZpbmVk IGluIHRoZSBjdXJyZW50IGNvbnRleHRzLA0KPnNvIHRoaXMgaXMganVzdCBzb21ldGhpbmcgdG8g dGhpbmsgYWJvdXQgcmF0aGVyIHRoYW4gYSBzdHJvbmcNCj5hbHRlcm5hdGUgc3VnZ2VzdGlvbi4N Cg0KVmlydXMgc2Nhbm5pbmcgc2VlbXMgbGlrZSBhIHJlYXNvbmFibGUgdGhpbmcgdGhhdCB5b3Ug d291bGQgd2FudCB0byBkbyB0byANCmFsbCBhcmNoaXZlcywgcmVnYXJkbGVzcyBvZiBzdWJ0eXBl LiAgVGhlIGNvbnRlbnQgdHlwZSBpcyB1c2VkIGJ5IHNldmVyYWwgDQptb3JlIGFjdG9ycyB0aGFu IGp1c3QgdGhlIE1VQSBub3cuDQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0KDQoNCg== From nobody Wed Oct 1 06:45:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BB61A19E4 for ; Wed, 1 Oct 2014 06:45:47 -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 E3H-GJwsq-8A for ; Wed, 1 Oct 2014 06:45:46 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F2281A0AFE for ; Wed, 1 Oct 2014 06:45:46 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id uz6so315639obc.1 for ; Wed, 01 Oct 2014 06:45:45 -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=pcXJxiA/6g8PFmhOvnFRfy+0kmtPmjB7Ws5UjNXasbs=; b=cc50QivOEFaC2QTo/90tL/sHta0Hp3mLphekeX6hEuETil+rL5bVNhgZLaFFOr+7YT sBqErRCIJXGkgXDGtVamdVfzh7ocUfYtT2aqPjTaN1BB0zqMxNBChgAAVBgeoWtFDPnE tYwZZ5MWwBcmKKTXGYMnio8t3l4IxKEEX6BmI= 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=pcXJxiA/6g8PFmhOvnFRfy+0kmtPmjB7Ws5UjNXasbs=; b=Xt1Xf2+ZWKA9Wnj3TODznTTe+A87Jw7huc8vO/SpV0VMQDTk2JZpuBoF/Nsrr+T0I6 /Zfv3NjkhllJu4uFh/EksarjUAaBPXg3L9UnskUEQXOfmOkgKYDuIaNLE9g2Rx27SA4/ RfqrGdwwIN8U4Q7JpyUNRGq3DTaWbDDno9JYi8qJsixxtF6mFiYi2DXJl70G8fBvuUKm B2IMKIPPq2epXMJlklUdG4LIMKBwa3pDaUoPGFGb/2XuzzBxmhqEIzLr0zKkF3jSlv5W /YUouuC25dUCq84rde3VstAfvty6A5PFtJp2L0ZCw6NIbX3g59c/7jzR/gDPzlUUdWAT PlyQ== X-Gm-Message-State: ALoCoQl+OCB5nOFMLnD+7YRBXFZWk4G2ZpUg5SKLLtYr06C4KlASCH6FIEnFYUx4kZpm0+3vGgIF MIME-Version: 1.0 X-Received: by 10.182.72.197 with SMTP id f5mr55106232obv.54.1412171145394; Wed, 01 Oct 2014 06:45:45 -0700 (PDT) Received: by 10.60.150.238 with HTTP; Wed, 1 Oct 2014 06:45:45 -0700 (PDT) In-Reply-To: <7D73F05D-28A9-4564-9663-F5DA956EBBA9@cisco.com> References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> <9AD273B04D7CB4B07CE8D1C5@JcK-HP8200.jck.com> <7D73F05D-28A9-4564-9663-F5DA956EBBA9@cisco.com> Date: Wed, 1 Oct 2014 14:45:45 +0100 Message-ID: From: Dave Cridland To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=001a11c2eea67bd4d205045cb775 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/9f73PsKq7UZoDPp1vfruJePyzPc Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] IETF 91 scheduling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 13:45:47 -0000 --001a11c2eea67bd4d205045cb775 Content-Type: text/plain; charset=UTF-8 On 1 October 2014 14:38, Joe Hildebrand (jhildebr) wrote: > On 9/30/14, 10:03 AM, "John C Klensin" wrote: > > >On the other hand, there is something extra-special, which is > >frequency of use, and things have changed a lot since > >Content/Media types were first defined in the current contexts, > >so this is just something to think about rather than a strong > >alternate suggestion. > > Virus scanning seems like a reasonable thing that you would want to do to > all archives, regardless of subtype. The content type is used by several > more actors than just the MUA now. > Would a virus scanner forego scanning anything that didn't mark itself as an archive? Are we expecting viruses in archives to be clearly marked as archives? If media types are reliable, then a top-level media type of malware would solve all our problems. I'm not against archive as a top-level type, it seems generally reasonable, but I don't see any security advantage in it. Dave. --001a11c2eea67bd4d205045cb775 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= October 2014 14:38, Joe Hildebrand (jhildebr) <jhildebr@cisco.com>= ; wrote:
On 9/30/= 14, 10:03 AM, "John C Klensin" <john-ietf@jck.com> wrote:

>On the other hand, there is something extra-special, which is
>frequency of use, and things have changed a lot since
>Content/Media types were first defined in the current contexts,
>so this is just something to think about rather than a strong
>alternate suggestion.

Virus scanning seems like a reasonable thing that you would want to = do to
all archives, regardless of subtype.=C2=A0 The content type is used by seve= ral
more actors than just the MUA now.

Woul= d a virus scanner forego scanning anything that didn't mark itself as a= n archive? Are we expecting viruses in archives to be clearly marked as arc= hives?

If media types are reliable, then a top-lev= el media type of malware would solve all our problems.

=
I'm not against archive as a top-level type, it seems generally re= asonable, but I don't see any security advantage in it.

<= /div>
Dave.
--001a11c2eea67bd4d205045cb775-- From gannon_dick@yahoo.com Mon Sep 29 15:26:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BB61ACD61 for ; Mon, 29 Sep 2014 15:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.887 X-Spam-Level: X-Spam-Status: No, score=-0.887 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1nYNrfiR2eb for ; Mon, 29 Sep 2014 15:26:03 -0700 (PDT) Received: from nm13-vm3.bullet.mail.ne1.yahoo.com (nm13-vm3.bullet.mail.ne1.yahoo.com [98.138.91.143]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 901D51ACD5E for ; Mon, 29 Sep 2014 15:26:03 -0700 (PDT) Received: from [98.138.100.112] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 29 Sep 2014 22:26:02 -0000 Received: from [98.138.89.249] by tm103.bullet.mail.ne1.yahoo.com with NNFMP; 29 Sep 2014 22:26:02 -0000 Received: from [127.0.0.1] by omp1041.mail.ne1.yahoo.com with NNFMP; 29 Sep 2014 22:26:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 785649.63634.bm@omp1041.mail.ne1.yahoo.com Received: (qmail 76634 invoked by uid 60001); 29 Sep 2014 22:26:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1412029562; bh=U9ZoFccbAOFvUELqcgvpapzAV3+7seRmjcyBzt3Il2I=; h=Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vegetwIzMbX8QEaC0tPgVx1+2OBH7PRJS/4QgZ2Hyq/g/IfSUm31rvU7pVRoa5nxyUtwB+M0miIAbl/+AOpo7MI1McwEtM8EMRDYbMNIn2cMDBHq7FnSwcdjM4XLd2Mi3Ktkh7xMbS5wqYEEmJddxr37bCJ1sI25kpApB6wEE8I= X-YMail-OSG: lU.JD1MVM1mHTgYZBS3QI5rdSlUpL3zwOwTH69jwO5iDhbd 3aDhrYCrgat.KGKTal6PiQWThRmhE7Vy2SulSnNf2Y5WHoM_2rRPd2bUiSfq Ol5rhxcDvMz_CYdf_ACfL0sQPHApQ1frw8r00yj7tDiF6mIoO6Q0MG0Eefr5 SqpopBxatWy7EMRq6n7iipyyUuUwIKWU.kQBYl9cg6brnm3d.YiEG7.MLShh 7Wy2ncQflvRvbxeWF9HWLFAyUB_K8bgiL9Ntjw8PfonDcNR8mJd1Ry0MDZuu a3UDbrGyyTc261pa6vxWEtF4DewrDOE7KCOcVLnAl4MVyEV3NTNxIaTx5it_ sDTLrOiNQfg3ikd3axfMYjM368ZF2zc44bqry94TC4J6oYiGc25W.xRLsKKj KBUeRDHKv7TqmQPY6Pyzo0TBOauigDK0nLX1QE8Wb_0fhJmjxgouuLYGseBc UJE3jBVoYhlXbOxzY.gjSFUKzFO236Yb8ewhQ34dvvQ1XC0a1eQI4fE3gdkn PRU8RgPrxLwJ7OoICnqNngv5xVPHeuBbE7tH5eyWemYA.JzITwZVfbL9zHJJ uoz2GJd4W55SsJI.rlp2Ni6gzcbZG8d8yvkFI1mM2yBrrMJnPg0g41famKFk gNFazE5y9 Received: from [68.184.191.198] by web122906.mail.ne1.yahoo.com via HTTP; Mon, 29 Sep 2014 15:26:02 PDT X-Rocket-MIMEInfo: 002.001, VGhlcmUgYXJlIHNvbWUgdGhpbmdzIHRoYXQganVzdCBkb24ndCBsb29rIG5pY2UgdW5kZXIgQmVzdCBQcmFjdGljZXMuDQpCdXQgSSdsbCB0YWtlIEJlc3QgUHJhY3RpY2VzIG92ZXIgUGlnIExpcHN0aWNrIGFueSBkYXkgb2YgdGhlIHdlZWsuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoyLjEgUHJpdmFjeSBDb25zaWRlcmF0aW9ucw0KDQpUaGlzIHNlY3Rpb24gaXMgbm9uLW5vcm1hdGl2ZS4NCg0KVXNpbmcgdW5pcXVlIGlkZW50aWZpZXJzIChlLmcuLCABMAEBAQE- X-Mailer: YahooMailClassic/786 YahooMailWebService/0.8.203.696 Message-ID: <1412029562.42632.YahooMailBasic@web122906.mail.ne1.yahoo.com> Date: Mon, 29 Sep 2014 15:26:02 -0700 From: Gannon Dick To: Dave Thaler , Matthew Kerwin , "t.petch" , Marcos Caceres In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/CpA9jnMZvvukrKNdZmB3puH2G_g X-Mailman-Approved-At: Wed, 01 Oct 2014 06:47:48 -0700 Cc: "uri@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] file:/// X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 22:34:02 -0000 There are some things that just don't look nice under Best Practices. But I'll take Best Practices over Pig Lipstick any day of the week. ---------------------------------------------------- 2.1 Privacy Considerations This section is non-normative. Using unique identifiers (e.g., a UUID) as an instance identifier can be ex= ploited by an adversary as a digital finger print. This can allow a develop= er to, for example, restore cookies even if the user has cleared cookies fr= om a user agent. As such, if the user agent relies on unique identifiers as= the host component, then it should provide end-users with a means of regen= erating the authority component. For instance, A user agent can the regener= ate the instance identifier when the user clears the user agent's private d= ata. ------------------------------------------------------- --Gannon -------------------------------------------- On Mon, 9/29/14, Marcos Caceres wrote: Subject: RE: [apps-discuss] file:/// To: "Dave Thaler" , "Matthew Kerwin" , "t.petch" Cc: "IETF Apps Discuss" , "uri@w3.org" Date: Monday, September 29, 2014, 4:02 PM =20 =20 =20 =20 On September 27, 2014 at 5:27:14 AM, Dave Thaler (dthaler@microsoft.com) wrote: > > Personally, I'd love to see it deprecated and replaced by something=A0=20 > more useful/interoperable. =20 We've tried a few times, e.g.,: http://app-uri.sysapps.org/ =20 However, never seems to catch on.=A0 =A0 From nobody Wed Oct 1 07:29:23 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9B21ACDC3 for ; Wed, 1 Oct 2014 07:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 IrVayJUrPInf for ; Wed, 1 Oct 2014 07:29:18 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509561ACDE8 for ; Wed, 1 Oct 2014 07:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1294; q=dns/txt; s=iport; t=1412173724; x=1413383324; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GEjJISZbazEG/bBp1b/cs8HY1vsWsefhrQcZDTO+Ubk=; b=LcmpHtrGlVsSXUPVYgfqPnRhBMzQB2GFTADAv0qparCc2QjHDovvlO1Z T/M0mPMLffmKabZP4J1hU6JtxD3cneRxVwvLJfrXRANQse9Vnl8e05alB OcgFQmh2t1zic5ZMsWMX4u0bmEyXCy8E3uxjmmWVerPeeWacCZBOvhZwd Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAAIPLFStJA2N/2dsb2JhbABggw6BLASCfs8HAhlzFgF7hAQBAQQjEUUQAgEIGgImAgICMBUQAgQOBYg+qFOVbgEXgSyORzMHgng2gR0BBJFti0aVc4NjbIFIgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,632,1406592000"; d="scan'208";a="359894439" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP; 01 Oct 2014 14:28:43 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s91ESh3M008750 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Oct 2014 14:28:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Wed, 1 Oct 2014 09:28:43 -0500 From: "Joe Hildebrand (jhildebr)" To: Dave Cridland Thread-Topic: [apps-discuss] IETF 91 scheduling Thread-Index: AQHP3CUNiOxAqlRxXEaz22swIFnVrJwY+T+AgADN54CAAYszgIAARS6A///I9YA= Date: Wed, 1 Oct 2014 14:28:42 +0000 Message-ID: <1126C135-8FEC-4CB5-A947-53FB9BF83201@cisco.com> References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> <9AD273B04D7CB4B07CE8D1C5@JcK-HP8200.jck.com> <7D73F05D-28A9-4564-9663-F5DA956EBBA9@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.3.0.140829 x-originating-ip: [10.21.66.26] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/pnO2AOCehaOFAuoUyGAsEkxOpOI Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] IETF 91 scheduling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 14:29:20 -0000 T24gMTAvMS8xNCwgMTo0NSBQTSwgIkRhdmUgQ3JpZGxhbmQiIDxkYXZlQGNyaWRsYW5kLm5ldD4g d3JvdGU6DQoNCj5Xb3VsZCBhIHZpcnVzIHNjYW5uZXIgZm9yZWdvIHNjYW5uaW5nIGFueXRoaW5n IHRoYXQgZGlkbid0IG1hcmsgaXRzZWxmIGFzIA0KPmFuIGFyY2hpdmU/IEFyZSB3ZSBleHBlY3Rp bmcgdmlydXNlcyBpbiBhcmNoaXZlcyB0byBiZSBjbGVhcmx5IG1hcmtlZCBhcyANCj5hcmNoaXZl cz8NCg0KSXQgbWlnaHQgYmxvY2sgY29udGVudCB0aGF0IHdhcyBhbiBhcmNoaXZlLyB0eXBlIHRo YXQgaXQgZGlkbid0IGtub3cgaG93IA0KdG8gZXhwbG9kZS4NCg0KPklmIG1lZGlhIHR5cGVzIGFy ZSByZWxpYWJsZSwgdGhlbiBhIHRvcC1sZXZlbCBtZWRpYSB0eXBlIG9mIG1hbHdhcmUgd291bGQg DQo+c29sdmUgYWxsIG91ciBwcm9ibGVtcy4NCg0KU3VyZS4gIFRoYXQncyBqdXN0IGEgc3RyYWln aHRmb3J3YXJkIGV4dGVuc2lvbiBvZiBSRkMgMzUxNC4gIFdlIGNvdWxkIA0KcHJvYmFibHkgZ2V0 IHN1Y2ggYW4gUkZDIHB1Ymxpc2hlZCBieSB0aGUgZW5kIG9mIE1hcmNoLg0KDQo+SSdtIG5vdCBh Z2FpbnN0IGFyY2hpdmUgYXMgYSB0b3AtbGV2ZWwgdHlwZSwgaXQgc2VlbXMgZ2VuZXJhbGx5IA0K PnJlYXNvbmFibGUsIGJ1dCBJIGRvbid0IHNlZSBhbnkgc2VjdXJpdHkgYWR2YW50YWdlIGluIGl0 Lg0KDQpJJ20gbm90IGNsYWltaW5nIGFueSBzZWN1cml0eSBhZHZhbnRhZ2UuICBKdXN0IHBvaW50 aW5nIG91dCBzb21lIGNoYW5nZXMgDQp0byB0aGUgdW5kZXJseWluZyBhc3N1bXB0aW9ucyBvZiB0 aGUgc3lzdGVtIHNpbmNlIHRoZSBsYXN0IHRpbWUgd2UgaGFkIA0KdGhpcyBjb252ZXJzYXRpb24u ICBOYW1lbHksIG1vcmUgdGhpbmdzIG9uLXBhdGggcHJvY2VzcyB0aGUgbWVkaWEgdHlwZSBub3cu DQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0KDQoNCg== From nobody Wed Oct 1 08:40:27 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6463C1ACE28 for ; Wed, 1 Oct 2014 08:40:26 -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 HccbSCUsJrP0 for ; Wed, 1 Oct 2014 08:40:24 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FDA81ACE4A for ; Wed, 1 Oct 2014 08:40:21 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A331F50A84; Wed, 1 Oct 2014 11:40:19 -0400 (EDT) Message-ID: <542C203D.3050504@seantek.com> Date: Wed, 01 Oct 2014 08:39:41 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: John C Klensin , "Murray S. Kucherawy" , Ned Freed References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> <9AD273B04D7CB4B07CE8D1C5@JcK-HP8200.jck.com> In-Reply-To: <9AD273B04D7CB4B07CE8D1C5@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wMxT-YvnZvq08fJd26A7Kqs3Rr0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] IETF 91 scheduling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 15:40:26 -0000 On 9/30/2014 3:03 AM, John C Klensin wrote: > [SNIP] > However, unless my memory is failing me, there is one historical > tidbit about which people should be aware. Ned wrote "There > used to be a strong reluctance to register media types for > archive formats". My recollection is that it was a bit more > than that, that archives (particularly of the zip and tar > persuasions) were explicitly discussed and believed to be > orthogonal to Content-type and Content-transfer-encoding, > inappropriate for top-level Content-types (now Media types) > unless we expected email clients to actually take some action on > them, e.g., by exploding them or having some other specific > action routines for them. A lot has changed with the world since RFC 2045 in '96. MIME types ->=20 Internet media types are not limited to e-mail; essentially they have=20 become the de-facto, vendor neutral way to identify formats that ever=20 might be destined for Internet transport. They are used in HTTP, and=20 therefore affect how HTTP clients and servers behave; they are also used = by lots of applications that touch HTTP in some way, such as content=20 management systems (CMSes). They are used by "online" file systems such=20 as Dropbox and Google Drive to manipulate behavior. Some "offline" file=20 systems (such as Apple Mac OS X / HFS+) use media types directly, or=20 have provisions for their use (Uniform Type Identifier=20 public.mime-type). Some version control systems (e.g., Subversion=20 svn:mime-type) also use them directly. Additionally, some modern e-mail clients provide facilities to view=20 archives directly. Outlook 2007+ has attachment previewers=20 =20 and there are preview handlers for ZIP files specifically=20 , not to mention other=20 types. Since filename extensions are not standardized (and there are many=20 instances of content that are not file-oriented), the overall gist is=20 that media types are becoming the de-facto vendor-neutral way to=20 identify different types of content. Sean From nobody Wed Oct 1 08:56:52 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0982D1ACE8B for ; Wed, 1 Oct 2014 08:56:51 -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 2PWQRH7wBVkk for ; Wed, 1 Oct 2014 08:56:50 -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 029911ACE75 for ; Wed, 1 Oct 2014 08:56:50 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s91FugAH023189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Oct 2014 08:56:45 -0700 Message-ID: <542C2436.5090906@dcrocker.net> Date: Wed, 01 Oct 2014 08:56:38 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" , John C Klensin , Sean Leonard , "Murray S. Kucherawy" , Ned Freed References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> <9AD273B04D7CB4B07CE8D1C5@JcK-HP8200.jck.com> <7D73F05D-28A9-4564-9663-F5DA956EBBA9@cisco.com> In-Reply-To: <7D73F05D-28A9-4564-9663-F5DA956EBBA9@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 01 Oct 2014 08:56:45 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/eR9gZadTMeD6ARwsLIvuHbQ58T0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] IETF 91 scheduling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 01 Oct 2014 15:56:51 -0000 On 10/1/2014 6:38 AM, Joe Hildebrand (jhildebr) wrote: > Virus scanning seems like a reasonable thing that you would want to do to > all archives, regardless of subtype. The content type is used by several > more actors than just the MUA now. Not just regardless of subtype. Also regardless of top-level type. Problematic archives are /less/ likely to be located in a place that explicitly identifies the data as an archive. This line of issue is probably similar to the concern for placing adult content under hosts with .xxx domain names... That is, there might be benefit for good actors in the system, but there's not likely to be any benefit in identifying bad actors (who have an incentive to hide their presence.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Oct 1 10:47:20 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB4D1A1AA6 for ; Wed, 1 Oct 2014 10:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYtuhxf9keXA for ; Wed, 1 Oct 2014 10:47:18 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B40421A1AA4 for ; Wed, 1 Oct 2014 10:47:18 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 7DB5010062 for ; Wed, 1 Oct 2014 10:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:mime-version:content-type; s= cryptonector.com; bh=3hyMF5XzTPZNx3AMGJ5l/YyGUDw=; b=cctnkzmdhaT GdgrfM3EqM6HkVAYIXmKsMu800Q832tiXCnx0aN8QwlocaQCnW3NjPVKJSd99/ZJ jlhX3uzqacM9kxZywKwooJuOArHVdBc+n+XJJknw26/JbAzKzzmN/hDYMqAzzCmX x1xHfQNflcuumMuRq8QnZz8Kt862lXYY= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPA id 4028E10059 for ; Wed, 1 Oct 2014 10:47:18 -0700 (PDT) Date: Wed, 1 Oct 2014 12:47:17 -0500 From: Nico Williams To: apps-discuss@ietf.org Message-ID: <20141001174716.GB2630@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hnEdcJrjfIGBnky_n8U49Hm-k-Q Subject: [apps-discuss] Profiling RFC5424 for easy use from clients X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 17:47:19 -0000 The state of structured data logging from applications is... sad. The obvious thing to do would be to encode the typical syslog(3C) function's format string as the MSGID and the varargs as the structured data. For various reasons this is a difficult thing to do (in C anyways, and anywhere where a printf-like format string is used) and thus, to my knowledge, no syslog client does it. But it is doable, so the thought occurs that we should standardize parameter names for syslog()'s printf format arguments -- call it a profile if you wish. On a related note, I *wish* RFC5424 had used JSON, not a horrible ad-hoc structured data encoding. Finally, if someone would kindly clue me in as to the status of RFC5424 clients with structured data support, I'd greatly appreciate it. A decent C RFC5424 client would be super convenient, though I'm afraid if I really want it then I'll have to write it. Nico -- From nobody Wed Oct 1 11:33:08 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FA91A6D3F for ; Wed, 1 Oct 2014 11:33:06 -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 jqjrzzguVHY8 for ; Wed, 1 Oct 2014 11:33:04 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C7071A1B82 for ; Wed, 1 Oct 2014 11:33:04 -0700 (PDT) Received: from [10.0.44.217] (unknown [74.113.134.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CA09850A88; Wed, 1 Oct 2014 14:33:01 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_75CD2F5C-F908-45E9-9762-494B1391FD9C"; 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: Wed, 1 Oct 2014 11:32:34 -0700 Message-Id: References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> <9AD273B04D7CB4B07CE8D1C5@JcK-HP8200.jck.com> <7D73F05D-28A9-4564-9663-F5DA956EBBA9@cisco.com> To: Dave Cridland X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/MQqHphRgfth7luqXBxx6XZW9ttE Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] IETF 91 scheduling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 18:33:06 -0000 --Apple-Mail=_75CD2F5C-F908-45E9-9762-494B1391FD9C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 1, 2014, at 6:45 AM, Dave Cridland wrote: > On 1 October 2014 14:38, Joe Hildebrand (jhildebr) = wrote: >=20 > Virus scanning seems like a reasonable thing that you would want to do = to > all archives, regardless of subtype. The content type is used by = several > more actors than just the MUA now. >=20 > Would a virus scanner forego scanning anything that didn't mark itself = as an archive? Are we expecting viruses in archives to be clearly marked = as archives? The intuition about malware is correct=85but one should add a bit of = finesse. First of all any scanner worth its salt should be scanning all things = saved to disk (that includes inline content) for viruses and things. The issue comes down to properly labeling different types of content = between security domains, namely the Internet domain (where file = extensions are not reliable or are not supplied) and the local computer = (where file extensions usually determine some default action). In the Before Time, =93everybody" said: command file.dat Now, people say: I.e., acting upon the content, such as double-clicking a file, launching = a file, clicking a link, touching a button, etc. does the default = thing=97the computer figures out what to do by context. It=92s been this = way since the first GUIs were invented. I have noticed that a lot of the time, when you send photos in Apple=92s = iOS Mail, the photo received simply has the name =93photo=94. The = recipient mail client might display the photo; it might also save the = photo to disk. Should it save the photo as =93photo=94, or as = =93photo.jpg=94? Answer: photo.jpg, because the Content-Type should be image/jpg (this is = also a tip to pass it to the image-processor, so that the recipient can = see the photo in the message). In the local computing environment, JPEG = images are distinguished by .jpg. If the data is GIF and is labeled = =93photo.jpg=94, the most appropriate thing is to name it = =93photo.jpg.gif=94 (or =93photo.gif=94) locally. (In the case of Mac OS = X/iOS, it=92s acceptable to name it =93photo=94 because the Uniform Type = Identifier should be set as =93public.jpeg=94.) Now consider a more malicious case, some executable or shell script. = This executable or script may be specifically targeted to infect the = recipient=92s computer, i.e., a spear-phishing attack where the = recipient is some corporate executive, FCC commissioner, judge, district = attorney, or operator of a nuclear facility in Iran. No matter how good = your virus scanner is, it=92s unlikely to detect such a specifically and = uniquely-crafted executable. A naive mail client will take the purported name =93www.example.com=94 = (or =93instructions=94 with no extension, or =93instructions.sh=94) and = save it to disk=97omitting the critical metadata about the media type. = If the media type is text/plain, for example, the RIGHT thing to do is = to change it to =93www.example.com.txt=94. Thus if a user launches the = file, he=92s going to get Notepad, TextEdit, gedit, or emacs; not some = shell script execution. Of course if the sender is malicious, he will not want that behavior=97he = will want (some/executable) media type. But then an intervening virus = scanner can apply extra scrutiny because the media is mislabeled, and = use that as a heuristic to reject the message as spam or phishing. Currently we are in a regime where a lot of archives are transmitted as = application/octet-stream. This gives no hint whatsoever to the recipient = (or any intervening virus scanner) on how to handle the content. Thus a = malicious sender can send something that LOOKS like an archive as = =93critical-FDA-drug-applicationZIP=94, as application/octet-stream, and = then when the recipient saves it to disk and tries to use it, they are = going to get non-ZIP archive behavior. Conclusion: setting everything to application/octet-stream is bad = because it is information-lossy and requires content-sniffing or user = intervention to do the right thing. Unregistered media types = (application/x-7z) are as good as application/octet-stream for = interoperability. Let=92s register things. Sean= --Apple-Mail=_75CD2F5C-F908-45E9-9762-494B1391FD9C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO7TCCBJ0w ggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsG AQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlfsXzw PlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1ctxE +2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj2iC0 o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRowggQCoAMCAQICEG0Z 6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAw NTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdC lOD5J3EHxcZppLkyxPFAGpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh3 37EXrMLaggLW1DJq1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJA AVtIaN3FSrTg7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJy ZCaRTqWSD//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOC AUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEE aDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF0q0bc24+6SZ85kyY wTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6L566k3nK/uKRHlZ0sviN 0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6 PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrR eTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqT PDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0EwHhcNMTMxMTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J 9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2g uKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G 53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia33JN+ oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5j b20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50 ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMf WE2/5myX518DB+kTa5iQDbKYRuJp3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmI H4kfI4LWrY8XrPhlX3JmHjD6hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3 jx9VF/gA3vqYpL+jNumInz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d 9ljRDEiAts5OopkeeFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYID rjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggHZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MTAwMTE4MzI1OVowIwYJKoZIhvcNAQkEMRYEFBi+nx6Uo7ILVxYxAHZY83GT B3bzMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQDKkzwxu6lupsyQvhKSvQd8MIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEBBQAE ggEAzflRIy4itlbNJ6fcI7hSfTIRTOiiXaPqr3SpFsdfwgGVesCsqJgyDRhObC+YBkuPFlaOnFzC EuZGIs8XLKsTPFz5Dx3LVyJShwLa7eKlc1GTuGvWXW279mWLIDXb9KCDgZ9xlgMlQjM9uH0xZ7ZD ie27yNOEDUn9WrzA5+m5KdclwScs1XW/hKLK1dQHtSbQ1gil6Snzh9J6sPifxNByk3mvJvEGA4h1 KNSzMv4hwBUWYcqJCAd3YReNmVVjWDXtcOHe1KrNtBey1uaFMAybAAVhko9rOGYVg/JViuNnPvoh 6bxPme5Cqakqk0YCvA3DkxH7Qhi8zJKOnYCMrehlPQAAAAAAAA== --Apple-Mail=_75CD2F5C-F908-45E9-9762-494B1391FD9C-- From nobody Wed Oct 1 12:37:55 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F721A8706 for ; Wed, 1 Oct 2014 12:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 HFw9QIg3Yvja; Wed, 1 Oct 2014 12:37:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F111A8777; Wed, 1 Oct 2014 12:37:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-authres-ptypes-registry@tools.ietf.org, scott@kitterman.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141001193751.8062.11002.idtracker@ietfa.amsl.com> Date: Wed, 01 Oct 2014 12:37:51 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-bEaXC1Je-vCeOUF6wYIm6b05k0 Subject: [apps-discuss] ID Tracker State Update Notice: 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, 01 Oct 2014 19:37:54 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-authres-ptypes-registry/ From nobody Wed Oct 1 12:41:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB75A1A874A for ; Wed, 1 Oct 2014 12:41:44 -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 OJQu2MVCfa1P for ; Wed, 1 Oct 2014 12:41:43 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F47F1A1A5E for ; Wed, 1 Oct 2014 12:41:43 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id f15so983077lbj.25 for ; Wed, 01 Oct 2014 12:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s3anBNPVgROq8OcN6o+DsWylPYWJ03Slv/3FCZZh4Iw=; b=MYsz1Q1w9DLYr2cLkvKndDTa68EBUxeN5s8z02leBoWfUrbiAZGhmu2BDt+kcHWTHJ r5jkQ6ejTuRVM3vIUkW15kECTp+wbLFeTFa2On+jKoXHz3UgXriv2rXIRxt7TZDuhrE7 e6SumZd1NPweJjNFkL3Lvwrf3qw3c2t3cIQHV7sBmziPfxrLzlnG9KG9Buv8jjXcCTP4 sFR4PcENh6UxpsnZxvuCRnlUraS2nm7c/jL9GRaBfgx77MtwTzBRIc/OjMgwAsZLxH1L a9gsldLUtNQuuUFEUeRep4Aiuf/rcjuNUnyfDHqJXg69HuXg9Qed993Qvvz6YPHOX2xg N8AQ== MIME-Version: 1.0 X-Received: by 10.112.148.170 with SMTP id tt10mr55710050lbb.61.1412192501571; Wed, 01 Oct 2014 12:41:41 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Wed, 1 Oct 2014 12:41:41 -0700 (PDT) In-Reply-To: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> Date: Wed, 1 Oct 2014 12:41:41 -0700 Message-ID: From: Martin Thomson To: Sean Leonard Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_njMz6OLhCcz93YWO9dTQslTi3Q Cc: IETF Apps Discuss Subject: Re: [apps-discuss] IETF 91 scheduling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 19:41:44 -0000 On 29 September 2014 14:46, Sean Leonard wrote: > Topic: Archive TLMT A topic that would interest me more is whether top level media types should be abandoned. I see almost everything ending up in 'application', with occasional exceptions for 'text' if the content happens to not be binary (or some other equally inane reason). The only place I'm aware of that the top-level distinction takes on special meaning is in describing real-time media ('audio' and 'video') in SDP. It could have used other signals equally. Treating media type as an opaque blob works best anyway. From nobody Wed Oct 1 12:47:34 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9241A87B1 for ; Wed, 1 Oct 2014 12:47:33 -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 AdEj26AFhkJS for ; Wed, 1 Oct 2014 12:47:32 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073881A874A for ; Wed, 1 Oct 2014 12:47:32 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 1B8A0FA00CD; Wed, 1 Oct 2014 19:47:28 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1412192847-20915-20914/12/313; Wed, 1 Oct 2014 19:47:27 +0000 From: Arnt Gulbrandsen To: IETF Apps Discuss Date: Wed, 1 Oct 2014 21:47:28 +0200 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.6; X11; Linux; Ubuntu 14.04.1 LTS Mime-Version: 1.0 Message-Id: <5c037851-946b-4305-b147-be7c98ffeb62@gulbrandsen.priv.no> In-Reply-To: References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/iIam94hKfipyURBwpk4mgsl5H_M Subject: Re: [apps-discuss] IETF 91 scheduling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 19:47:33 -0000 On Wednesday, October 1, 2014 9:41:41 PM CEST, Martin Thomson wrote: > I see almost everything ending up in 'application', with occasional > exceptions for 'text' if the content happens to not be binary (or some > other equally inane reason). I thought application/x-foo is code for "I heard publishing RFC makes you spend six months with idnits and discussing the wording of relative clauses". If you see what I mean and I think you do. And the whole point is perfectly orthogonal to archive/*. Armt From nobody Wed Oct 1 12:52:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2BB1A87B3 for ; Wed, 1 Oct 2014 12:52:22 -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 xoQGpa9YNaQI for ; Wed, 1 Oct 2014 12:52:21 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 373731A1C04 for ; Wed, 1 Oct 2014 12:52:21 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id l13so255439iga.5 for ; Wed, 01 Oct 2014 12:52:20 -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=AyPIOcREdhuKLctJj86Nwex3+Zi00/YE+BDDKV/E/js=; b=j3kkZfOwlhYjfWwPKlN9N/lfe+zEhK/xyCaRie1Xbl6poDejWNfarikXa/6ZKoXVK7 otAWPNO+/kvp+jD16MEp7e03/yV+uXp8TZWQYaYmX4wkXzKFOkaxc80109nIDpE4YI99 DCXeyZ1auFGAhdJvQGi+BbLuNE4/ECl1NN+V3rpfEytUbGCAkeot/g7E3ajq1pl7rk4v 7r8F+4wX1i84j8D3dyzq+0Ox4BsVcpLPWdqbe5gUY+4OooTJ64z1IQdgS3vDLCtCGqUC AmW13GCi6BIUT/WgeCAOAXjaJ36gJS133LY8+a7wclDUM49MHh/P7kKVLsMZK0cNuP3o /clA== MIME-Version: 1.0 X-Received: by 10.50.80.116 with SMTP id q20mr23238496igx.22.1412193140569; Wed, 01 Oct 2014 12:52:20 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.153.66 with HTTP; Wed, 1 Oct 2014 12:52:20 -0700 (PDT) In-Reply-To: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> Date: Wed, 1 Oct 2014 20:52:20 +0100 X-Google-Sender-Auth: CDHyqLDkQTlk6YD_XJVxOSgAgYo Message-ID: From: Barry Leiba To: Sean Leonard Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_FXESVhurXMZ4mvy5tbLSOItEYY Cc: IETF Apps Discuss Subject: Re: [apps-discuss] IETF 91 scheduling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 19:52:22 -0000 > Based on responses from last week (and the IETF 91 BoF deadline), I > requested that the Area Directors schedule a BoF. They have not responded > yet one way or another. Actually, I did respond one way or another: You requested the BoF *on the day of the deadline*, and I responded that I was in the air that day, and that I'd make sure it got into the wiki. I did, and it did, and we approved the BoF today, for a one hour slot -- that should be plenty of time. Of course, it's fine to continue discussing it on this list between now and then, and I encourage that -- but please use a separate thread, rather than hijacking Murray's call for agenda items. Carry on... Barry From nobody Wed Oct 1 21:07:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2491A0060 for ; Wed, 1 Oct 2014 21:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 hxph9dlSWQ3F; Wed, 1 Oct 2014 21:06:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D05E81A006D; Wed, 1 Oct 2014 21:06:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-authres-ptypes-registry@tools.ietf.org, scott@kitterman.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141002040650.24019.28333.idtracker@ietfa.amsl.com> Date: Wed, 01 Oct 2014 21:06:50 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7KZhZ-WF-mFbWUvJ2Y3W9v_EQQE Subject: [apps-discuss] ID Tracker State Update Notice: 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, 02 Oct 2014 04:06:54 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-authres-ptypes-registry/ From nobody Wed Oct 1 23:33:08 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44811A00FE; Wed, 1 Oct 2014 23:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.907 X-Spam-Level: X-Spam-Status: No, score=-0.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKI_Qp6Xpnu4; Wed, 1 Oct 2014 23:33:04 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 046931A00FF; Wed, 1 Oct 2014 23:33:03 -0700 (PDT) Received: internal info suppressed Date: Thu, 2 Oct 2014 08:32:57 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@synx02.dir.garr.it To: apps-discuss@ietf.org, Barry Leiba Message-ID: User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1412231580; bh=UVM0ic15Gd9M2gYhTTB0MbD0KrUJKLhKP+V7gpwDPPE=; h=Date:From:To:cc:Subject; b=i8i2x4Rt2BWVxsWB3W1pKQpIptbT7W27Crkn52t9ZrAmQtnN19wYD0qNlTUA7b9tZ 3O5zAOYEEEGWzYRPmqb7D2amjm1eK0HjW8eU/x5zMC8p3dCX0p7QAyC8pJ+HsNDThK Gv+bnhFUSa6zeJbayuEZsDBlEp2+YsxMw5tuzjyQ= Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ndskNEfx6wimzbNIgJMjbq-kgAU Cc: iesg@ietf.org, draft-ietf-jose-json-web-signature.all@tools.ietf.org Subject: [apps-discuss] AppsDir reviews of draft-ietf-jose-json-web-signature-32 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2014 06:33:07 -0000 Helo Ray, many thanks! the template and instructions are here: http://trac.tools.ietf.org/area/app/trac/wiki/template I'm doing the distrubion as said in the template, thanks again! ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca ---------- Forwarded message ---------- Date: Wed, 1 Oct 2014 20:21:42 -0700 (PDT) From: Ray Polk To: Claudio.Allocchio@garr.it Cc: Michael.Jones@microsoft.com Subject: Re: URGENT AppsDir reviews of the JOSE document set - asigned drafts Hi Claudio (and Mike), I've finished reviewing draft-ietf-jose-json-web-signature-32 for AppsDir. I could not find another AppsDir review on the jose mailing list to use as a model. So, I don't know to whom I should send my review, the format it should take, or the severity of the issues to include (include Nits? include minor, non-blocking issues?). For now, I'll include all of my notes. If you can advise me of proper format/protocol/procedure, I'll craft an email to the jose list. Major: None Minor: 4.1.1. & 4.1.2. The links to Section 4.1 and Section 5.1 of JWA are incorrect. They link to JWE instead of JWA. In 4.1.1. the link is: https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-32#section-4.1 ...but it should be: https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-33#section-4.1 In 4.1.2. the link is: https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-32#section-5.1 ...but it should be: https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-33#section-5 (JWA doesn't seem to have an anchor for 5.1) 9. saying "separated by X period ('.') characters" is ambiguous: JWSs have three segments separated by two period ('.') characters. This means: segment..segment..segment JWEs have five segments separated by four period ('.') characters. This means: segment....segment....segment....segment....segment Say instead: ___s have X segments. Each segment is separated from the next by a single period ('.') for a total of X-1 delimiting periods ('.'). Nit: 3.2 change "of these eight values," to "...values:", remove commas and the 'and', change "...with the six" to a complete sentence. 3.3 remove the and from "...to produce the JWE Encrypted Key and" and the period from the next bullet 4.1.3. fix comma splicing in: "This Header Parameter MUST be integrity protected, and therefore MUST occur only within the JWE Protected Header, when used." For example, "When used, this Header Parameter MUST be integrity protected; therefore, it MUST occur only within the JWE Protected Header." Sections 4.1.4. through 4.1.10. are almost entirely redundant. Combine them like so: The following parameters have the same meaning, syntax, and processing rules as those defined in JWS, except that the certificate referenced by the thumbprint contains the public key to which the JWE was encrypted; this can be used to determine the private key needed to decrypt the JWE. jku defined in Section 4.1.2. of [JWS] jwk defined in Section 4.1.3. of [JWS] etc. ----- Original Message ----- From: Claudio.Allocchio@garr.it To: ray.polk@oracle.com Cc: Claudio.Allocchio@garr.it Sent: Saturday, September 27, 2014 1:42:40 PM GMT -07:00 US/Canada Mountain Subject: Re: URGENT AppsDir reviews of the JOSE document set - asigned drafts On Sat, 27 Sep 2014, Ray wrote: > What is the goal review date? Literally as soon as possible? I won't be able > to start on mine till Monday at the earliest. the IESG telechat is on Oct 2nd, thus Oct 1st max :-) Sorry again for the late call... my original message never got to the list (but I sent it from an airport...). thanks Ray! > > -Ray > > On 9/27/2014 12:17 AM, Claudio Allocchio wrote: >> >> apart from Tobias, who said NAK :-( ... where are the others? >> >> this yar we had less pressure (less drafts to review) than the previous >> one, but it does not mean we do not have to do the work. >> >> We all committed to do in average at least a review per month, is it? >> >> I know we are not so many and need new people, too... but at least let's do >> the best we can, e.g. at lease say ACK or NAK ... >> >> many thanks! >> >> >> >> On Thu, 25 Sep 2014, Claudio Allocchio wrote: >> >>> >>> Hello, >>> >>> as I did not get any answer to the message below, let's ask directly: >>> >>> draft-ietf-jose-json-web-algorithms-32 >>> - assigned to Carsten Bormann >>> >>> draft-ietf-jose-json-web-encryption-32 >>> - assigned to Tobias Gondrom >>> >>> draft-ietf-jose-json-web-key-32 >>> - assigned to Tony Hansen >>> >>> draft-ietf-jose-json-web-signature-32 >>> - assigned to Ray Polk >>> >>> Could you please ACK ? >>> >>> I know it is a very short time available (telechat on Oct 2nd!) and it's >>> my late request... but let's try to do it. >>> >>> many thanks! >>> >>> >>> ------------------------------------------------------------------------------ >>> Claudio Allocchio G A R R Claudio.Allocchio@garr.it >>> Senior Technical Officer >>> tel: +39 040 3758523 Italian Academic and G=Claudio; >>> S=Allocchio; >>> fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; >>> >>> PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca >>> >>> ---------- Forwarded message ---------- >>> Date: Wed, 24 Sep 2014 18:15:13 +0200 (CEST) >>> From: Claudio Allocchio >>> To: appsdir@ietf.org >>> Subject: [appsdir] URGENT AppsDir reviews of the JOSE document set >>> >>> >>> Hi folks, >>> >>> due to my fault (thanks Barry for discovering that and sorry!), a request >>> for AppsDir review of the JOSE document set never made it to this list! >>> >>> :-( >>> >>> draft-ietf-jose-json-web-algorithms-32 >>> draft-ietf-jose-json-web-encryption-32 >>> draft-ietf-jose-json-web-key-32 >>> draft-ietf-jose-json-web-signature-32 >>> >>> Can we make an effort to take them on and try to make the reviews ASAP? >>> >>> Any volunteer (by tonght!) ? >>> >>> many thanks and sorry again! >>> >>> >>> ------------------------------------------------------------------------------ >>> Claudio Allocchio G A R R Claudio.Allocchio@garr.it >>> Senior Technical Officer >>> tel: +39 040 3758523 Italian Academic and G=Claudio; >>> S=Allocchio; >>> fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; >>> >>> PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca >>> >>> _______________________________________________ >>> appsdir mailing list >>> appsdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/appsdir >>> >>> _______________________________________________ >>> appsdir mailing list >>> appsdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/appsdir >>> >> >> >> ------------------------------------------------------------------------------ >> Claudio Allocchio G A R R Claudio.Allocchio@garr.it >> Senior Technical Officer >> tel: +39 040 3758523 Italian Academic and G=Claudio; >> S=Allocchio; >> fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; >> >> PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca > > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Thu Oct 2 00:22:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD481A0115; Thu, 2 Oct 2014 00:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmZOJngdhVIE; Thu, 2 Oct 2014 00:22:00 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6F71A005A; Thu, 2 Oct 2014 00:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s927Luns007314; Thu, 2 Oct 2014 09:21:56 +0200 (CEST) Received: from [172.20.10.6] (ip-2-202-98-49.web.vodafone.de [2.202.98.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3D05468A; Thu, 2 Oct 2014 09:21:55 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann Date: Thu, 2 Oct 2014 09:22:00 +0200 X-Mao-Original-Outgoing-Id: 433927320.462797-7c0401a104923a2324fc09e849936de8 Content-Transfer-Encoding: quoted-printable Message-Id: <805301AA-4E04-410D-A451-7A2175792CB0@tzi.org> To: apps-discuss@ietf.org, draft-ietf-jose-json-web-algorithms.all@tools.ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Ku2JLELr8ODnma-W7GC0UJWMDzQ Cc: iesg@ietf.org, jose@ietf.org Subject: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-algorithms-33 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2014 07:22:01 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see = =E2=80=8Bhttp://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDir= ectorate ). 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-jose-json-web-algorithms-33 Title: JSON Web Algorithms (JWA) Reviewer: Carsten Bormann Review Date: 2014-10-02 IESG Telechat date: 2014-10-02 Summary: This draft is ready for publication as a standards track RFC, with a few nits corrected. However, some additional editorial improvements might improve the security outcome when it is referenced by application developers. Major issues: None. Minor issues: 5.2: Add a reference that defines PKCS #7 padding. 5.2.2.2 Does "the PKCS #7 padding is removed" entail checking all of its bytes? 6.2.1 Is the intention that the sentence containing "point compression is not supported" also applies to any future registered value of "crv"? A similar comment applies to other specifications in 6.2.1.x, e.g., the reference to SEC1 representation to x and y. 6.2.1.1 =C2=BBAdditional "crv" values MAY be used, provided they are understood by implementations using that Elliptic Curve key.=C2=AB How are conflicts between such implementation defined values and future registered values handled? 6.3.2: The MAY accept partially overrides the MUST include? Is the latter thus really a SHOULD? 7.1: It is interesting that a mere registration (vetted only by a DE) can change the IETF consensus base specifications by making an algorithm "Required". 8. I am unable to find a "security considerations" section in NIST SP = 800-38A. 800-38D at least has a "practical considerations" section, is that = meant? (Etc., I haven't checked all the references.) In general, I believe a security considerations section is most useful where it provides more directed guidance instead of saying the equivalent of "here is a textbook". 8.7 is not clear: is it NOT RECOMMENDED to reuse an entire set of key material (including IV), or to reuse any part of it? Nits/editorial comments: 6.3.2.x: The constant repetition of =C2=BBIt is represented as the base64url = encoding of the value's unsigned big endian representation as an octet sequence. The octet sequence MUST utilize the minimum number of octets to represent the value.=C2=AB almost ensures that an implementer will stop reading the details (well, I did, and I did not write a program to verify the same phrase is used everywhere; if any parameter were using a different encoding, that sure would be missed). Why not define another abstraction like base64url and use this? 6.2.3.1: This is not a positive integer? 6.2.3.x mentions this = otherwise. 7.1.1 =C2=BBExample description=C2=AB is not a useful example for an = "Algorithm Description". (Same comment for 7.x.1.) 8.3: s/because it/because it is/ [sec1] (Given the date, this is probably referencing V2.0 of this spec.) [usascii] The reference to ANSI X3.4:1986 should probably be replaced by a reference to RFC 20. There is little reason to reference a somewhat hard to obtain external document ($60!) when we have an RFC about the same subject. (Tables in Appendix A need some formatting.) From nobody Thu Oct 2 00:33:40 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29311A0149; Thu, 2 Oct 2014 00:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnleZlr7iaTy; Thu, 2 Oct 2014 00:33:31 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECA431A0125; Thu, 2 Oct 2014 00:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s927XPXZ003469; Thu, 2 Oct 2014 09:33:25 +0200 (CEST) Received: from [172.20.10.6] (ip-2-202-98-49.web.vodafone.de [2.202.98.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 354D86B1; Thu, 2 Oct 2014 09:33:24 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <805301AA-4E04-410D-A451-7A2175792CB0@tzi.org> Date: Thu, 2 Oct 2014 09:33:29 +0200 X-Mao-Original-Outgoing-Id: 433928009.536839-32aac54bc403064e0bc75f8bb2bd716a Content-Transfer-Encoding: quoted-printable Message-Id: References: <805301AA-4E04-410D-A451-7A2175792CB0@tzi.org> To: apps-discuss@ietf.org, draft-ietf-jose-json-web-algorithms.all@tools.ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hcof3n4h8ZHYy3OeWx6KZBEQyUA Cc: iesg@ietf.org, jose@ietf.org Subject: Re: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-algorithms-33 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2014 07:33:32 -0000 On 02 Oct 2014, at 09:22, Carsten Bormann wrote: > 6.3.2.x: > The constant repetition of =BBIt is represented as the base64url = encoding of > the value's unsigned big endian representation as an octet sequence. > The octet sequence MUST utilize the minimum number of octets to > represent the value.=AB almost ensures that an implementer will stop > reading the details (well, I did, and I did not write a program to > verify the same phrase is used everywhere; if any parameter were using = a > different encoding, that sure would be missed). Why not define > another abstraction like base64url and use this? Just read Richard=92s DISCUSS: > Section 6.3.2.6. > This section defines the wrong parameter. Priceless corroboration. Gr=FC=DFe, Carsten From nobody Thu Oct 2 07:13:21 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56631A03A9 for ; Thu, 2 Oct 2014 07:13:15 -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 QVVKsylOTcli for ; Thu, 2 Oct 2014 07:13:13 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0796.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::796]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9676E1A03A0 for ; Thu, 2 Oct 2014 07:13:06 -0700 (PDT) Received: from pc6 (86.184.59.221) by AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Thu, 2 Oct 2014 14:12:43 +0000 Message-ID: <01c601cfde4a$ac89ec60$4001a8c0@gateway.2wire.net> From: t.petch To: Nico Williams , References: <20141001174716.GB2630@localhost> Date: Thu, 2 Oct 2014 15:10:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.184.59.221] X-ClientProxiedBy: DB4PR05CA0028.eurprd05.prod.outlook.com (25.160.40.38) To AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055; X-Forefront-PRVS: 03524FBD26 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(189002)(199003)(51704005)(50986999)(76176999)(99396003)(101416001)(81686999)(102836001)(87286001)(81816999)(95666004)(107046002)(107886001)(116806002)(77096002)(85306004)(105586002)(97736003)(106356001)(44736004)(84392001)(19580405001)(42186005)(19580395003)(80022003)(104166001)(50226001)(46102003)(4396001)(14496001)(33646002)(31966008)(21056001)(120916001)(10300001)(85852003)(62966002)(87976001)(88136002)(89996001)(23756003)(93916002)(50466002)(86362001)(92566001)(61296003)(20776003)(92726001)(44716002)(47776003)(66066001)(64706001)(62236002)(76482002)(77156001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB055; H:pc6; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/xbdCgC-XZLc0sQ1Cd6i7ruKgqVU Subject: Re: [apps-discuss] Profiling RFC5424 for easy use from clients X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2014 14:13:16 -0000 Nico There is a syslog mailing list, which might be the place to ask; on the other hand, the last syslog query I saw came up on OPSAWG - I am unsure how many of those involved would see a post to apps-discuss. At the time of writing RFC5424, JSON had yet to be the beam in anyone's eye. Tom Petch ----- Original Message ----- From: "Nico Williams" To: Sent: Wednesday, October 01, 2014 6:47 PM > The state of structured data logging from applications is... sad. > > The obvious thing to do would be to encode the typical syslog(3C) > function's format string as the MSGID and the varargs as the structured > data. For various reasons this is a difficult thing to do (in C > anyways, and anywhere where a printf-like format string is used) and > thus, to my knowledge, no syslog client does it. But it is doable, so > the thought occurs that we should standardize parameter names for > syslog()'s printf format arguments -- call it a profile if you wish. > > On a related note, I *wish* RFC5424 had used JSON, not a horrible ad-hoc > structured data encoding. > > Finally, if someone would kindly clue me in as to the status of RFC5424 > clients with structured data support, I'd greatly appreciate it. A > decent C RFC5424 client would be super convenient, though I'm afraid if > I really want it then I'll have to write it. > > Nico From nobody Thu Oct 2 08:48:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9B41A1C03 for ; Thu, 2 Oct 2014 08:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.334 X-Spam-Level: X-Spam-Status: No, score=0.334 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3G34I_wV2G0Z for ; Thu, 2 Oct 2014 08:48:23 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1392E1A03A0 for ; Thu, 2 Oct 2014 08:48:23 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id D90AB20058D81; Thu, 2 Oct 2014 08:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=8KZ+KXweaRj+ya DfOdlxHRm7uEs=; b=BdZqU6BqkdO7jKR0gXtDDQMktWQ787Vy0e1Qt5o8lpMJkz p5VAgmDpcYiOwk6PoUgje8hd8B6muDGAr5UI6JYUxCt4QV4AlnOh6spwTMVmyNkO U/OYrL2XYondoQVSZpU+QotRtp8Fm2udiB4jBTTDpAW6D1tTtNXmwDW8QuijY= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPA id 90A212005D82D; Thu, 2 Oct 2014 08:48:22 -0700 (PDT) Date: Thu, 2 Oct 2014 10:48:22 -0500 From: Nico Williams To: "t.petch" Message-ID: <20141002154820.GD12143@localhost> References: <20141001174716.GB2630@localhost> <01c601cfde4a$ac89ec60$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c601cfde4a$ac89ec60$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wVc9wFo-F693MigtN5pXYoIRscA Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Profiling RFC5424 for easy use from clients X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2014 15:48:23 -0000 On Thu, Oct 02, 2014 at 03:10:44PM +0100, t.petch wrote: > There is a syslog mailing list, which might be the place to ask; on the > other hand, the last syslog query I saw came up on OPSAWG - I am unsure > how many of those involved would see a post to apps-discuss. Aha, thanks. I'll ask there. > At the time of writing RFC5424, JSON had yet to be the beam in anyone's > eye. Well, numerically the first JSON RFC predates RFC5424... But what I really meant by that is that if there's not a lot of use of RFC5424 structured data then we might consider using JSON in the text payload of syslog messages. Since RFC5424 seems to be well supported by servers, that's probably a non-starter, thus my lament: it's ETOOLATE. Nico -- From nobody Thu Oct 2 10:17:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656DA1A89A5; Thu, 2 Oct 2014 10:17:07 -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 kRAuI-SxB2D8; Thu, 2 Oct 2014 10:17:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D27991A8A04; Thu, 2 Oct 2014 10:17:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141002171704.25230.90870.idtracker@ietfa.amsl.com> Date: Thu, 02 Oct 2014 10:17:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/VTIt42XktssxRHDQwXxUCOLHvbI Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-nottingham-safe-hint-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 17:17:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : The "safe" HTTP Preference Author : Mark Nottingham Filename : draft-nottingham-safe-hint-05.txt Pages : 8 Date : 2014-10-02 Abstract: This specification defines a "safe" preference for HTTP requests, expressing a desire to avoid "objectionable" content. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-nottingham-safe-hint/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-nottingham-safe-hint-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-nottingham-safe-hint-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 2 10:18:16 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8321A893F for ; Thu, 2 Oct 2014 10:18:14 -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 ggLNs5rcG4kq for ; Thu, 2 Oct 2014 10:18:10 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::703]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E49A1A89A5 for ; Thu, 2 Oct 2014 10:18:10 -0700 (PDT) Received: from pc6 (86.184.59.221) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Thu, 2 Oct 2014 17:17:46 +0000 Message-ID: <006301cfde64$86afd580$4001a8c0@gateway.2wire.net> From: t.petch To: Sean Leonard References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> <9AD273B04D7CB4B07CE8D1C5@JcK-HP8200.jck.com> <542C203D.3050504@seantek.com> Date: Thu, 2 Oct 2014 18:00:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.184.59.221] X-ClientProxiedBy: DB3PR05CA0018.eurprd05.prod.outlook.com (25.160.41.146) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB052; X-Forefront-PRVS: 03524FBD26 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(479174003)(11905935001)(377454003)(189002)(199003)(13464003)(24454002)(42186005)(85306004)(84392001)(104166001)(110136001)(76482002)(87286001)(31966008)(102836001)(50466002)(33646002)(89996001)(15202345003)(4396001)(87976001)(50226001)(93886004)(93916002)(50986999)(88136002)(66066001)(92566001)(81686999)(81816999)(86362001)(80022003)(46102003)(19580395003)(19580405001)(85852003)(44736004)(14496001)(62966002)(21056001)(64706001)(47776003)(116806002)(44716002)(15975445006)(20776003)(62236002)(95666004)(97736003)(107046002)(101416001)(77096002)(105586002)(76176999)(61296003)(120916001)(23756003)(92726001)(106356001)(99396003)(10300001)(77156001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB052; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/g8GlNDdyuZhKP6cVdi3GpC9xH0k Cc: IETF Apps Discuss Subject: Re: [apps-discuss] IETF 91 scheduling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 17:18:15 -0000 ----- Original Message ----- From: "Sean Leonard" To: "John C Klensin" ; "Murray S. Kucherawy" ; "Ned Freed" Cc: "IETF Apps Discuss" Sent: Wednesday, October 01, 2014 4:39 PM > On 9/30/2014 3:03 AM, John C Klensin wrote: > > [SNIP] > > However, unless my memory is failing me, there is one historical > > tidbit about which people should be aware. Ned wrote "There > > used to be a strong reluctance to register media types for > > archive formats". My recollection is that it was a bit more > > than that, that archives (particularly of the zip and tar > > persuasions) were explicitly discussed and believed to be > > orthogonal to Content-type and Content-transfer-encoding, > > inappropriate for top-level Content-types (now Media types) > > unless we expected email clients to actually take some action on > > them, e.g., by exploding them or having some other specific > > action routines for them. > > A lot has changed with the world since RFC 2045 in '96. MIME types -> > Internet media types are not limited to e-mail; essentially they have > become the de-facto, vendor neutral way to identify formats that ever > might be destined for Internet transport. They are used in HTTP, and > therefore affect how HTTP clients and servers behave; they are also used > by lots of applications that touch HTTP in some way, such as content > management systems (CMSes). They are used by "online" file systems such > as Dropbox and Google Drive to manipulate behavior. Some "offline" file > systems (such as Apple Mac OS X / HFS+) use media types directly, or > have provisions for their use (Uniform Type Identifier > public.mime-type). Some version control systems (e.g., Subversion > svn:mime-type) also use them directly. > > Additionally, some modern e-mail clients provide facilities to view > archives directly. Outlook 2007+ has attachment previewers > > and there are preview handlers for ZIP files specifically > , not to mention other > types. > > Since filename extensions are not standardized (and there are many > instances of content that are not file-oriented), the overall gist is > that media types are becoming the de-facto vendor-neutral way to > identify different types of content. which is fine when the storage mechanism caters for metadata and makes it accessible in a standard way. Sadly, the DOS directory was not designed in that way, which is why the vast majority of computer systems in the world (Windows!) continue to use file extensions:-( The problem keeps recurring - character sets, i18n, etc - but we do not progress towards a solution. Tom Petch > Sean > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Fri Oct 3 09:56:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD27B1A1BF0 for ; Fri, 3 Oct 2014 09:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 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, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBmg4P1Q4H7d for ; Fri, 3 Oct 2014 09:56:39 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B4E41A1A52 for ; Fri, 3 Oct 2014 09:56:35 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id ij19so917646vcb.32 for ; Fri, 03 Oct 2014 09:56: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=DKgQbSGklJE3GLdCQmWkStqZ3MTT/NJc/pQRLkZ8NRc=; b=bkl/M99UWnnTkRz4SR3vuMKoKmX1EKLUYd3rCOVqbsecaMDaICk61QC4UW1nugxQyQ tvw4xuAdpMN31vRkzGqlkoxxp5JJ6u/HCmq0bwoWGU2I5ibK4Xu6GUwF1ruPVWwj9Nvb A8aGy5ktMx4orTSnce5qXSK/yxA1yNAGbeh4FqrDTPxGF85ny6CUljIDpwflWRyZn2cr 5oyOjoZTHmEbSAKDxBTS9OZ/pS4OjQMotA+vA8/r8YzPe9xGBVPV77cqM75oE671ZHpO ttCpAMgkTcOOjW1+crVwUApaJ86wKaVQrX3Qsk1PhPGLJIAQiVqL9eAqaV5vrJ//Ckmj Zg5Q== MIME-Version: 1.0 X-Received: by 10.220.6.7 with SMTP id 7mr5118353vcx.1.1412355394725; Fri, 03 Oct 2014 09:56:34 -0700 (PDT) Received: by 10.220.85.211 with HTTP; Fri, 3 Oct 2014 09:56:34 -0700 (PDT) In-Reply-To: <20141002154820.GD12143@localhost> References: <20141001174716.GB2630@localhost> <01c601cfde4a$ac89ec60$4001a8c0@gateway.2wire.net> <20141002154820.GD12143@localhost> Date: Sat, 4 Oct 2014 00:56:34 +0800 Message-ID: From: Cabdirisaaq Mahamuud To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/UGDKu1qcxPCelTcgF82xJn8lmXc Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Profiling RFC5424 for easy use from clients X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Oct 2014 16:56:41 -0000 Discuss On 10/2/14, Nico Williams wrote: > On Thu, Oct 02, 2014 at 03:10:44PM +0100, t.petch wrote: >> There is a syslog mailing list, which might be the place to ask; on the >> other hand, the last syslog query I saw came up on OPSAWG - I am unsure >> how many of those involved would see a post to apps-discuss. > > Aha, thanks. I'll ask there. > >> At the time of writing RFC5424, JSON had yet to be the beam in anyone's >> eye. > > Well, numerically the first JSON RFC predates RFC5424... But what I > really meant by that is that if there's not a lot of use of RFC5424 > structured data then we might consider using JSON in the text payload of > syslog messages. Since RFC5424 seems to be well supported by servers, > that's probably a non-starter, thus my lament: it's ETOOLATE. > > Nico > -- > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Fri Oct 3 10:02:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802C01A6F85 for ; Fri, 3 Oct 2014 10:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 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, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQi_8hq7QpDI for ; Fri, 3 Oct 2014 10:02:39 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4569A1A6F84 for ; Fri, 3 Oct 2014 10:02:39 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id hq12so936608vcb.33 for ; Fri, 03 Oct 2014 10:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UYx/geVvyLY1q48pg/OUTuCo6htsDsJ7KjyLgf7Al2A=; b=PZTpe5m67oD1t3pkpl1UThUDxyvz17vD6kdhDUqsAO5OKcrxvgOpLBfHCRfkyrjBxA 1GaPpkGI2U6Pa2YWjKt+Ug/qg/nf5uAthX72qFi0e2zZVyxbZVnv3r+NabS3nyMsdPZz P+GcawEtybKXUkvCYbxAym88h35oDsRCDVwdscObEHfCCiJ5xvNTjf2dk1FsE1DlnfCS Z7hhJg5BrV4zYw/ctsytLf1lp96DvBW6YqxIrf5fId8X1suasOrb3OwECSpn/TJ8uF47 C+re1oM1cGfyVs/kEP37YGdksEbRkFVW1fAbeNzkRBwfbcgc8nY0Ud5S25MstRpxMQd9 NQkQ== MIME-Version: 1.0 X-Received: by 10.220.97.5 with SMTP id j5mr5293854vcn.16.1412355758205; Fri, 03 Oct 2014 10:02:38 -0700 (PDT) Received: by 10.220.85.211 with HTTP; Fri, 3 Oct 2014 10:02:38 -0700 (PDT) In-Reply-To: References: <20141001174716.GB2630@localhost> <01c601cfde4a$ac89ec60$4001a8c0@gateway.2wire.net> <20141002154820.GD12143@localhost> Date: Sat, 4 Oct 2014 01:02:38 +0800 Message-ID: From: Cabdirisaaq Mahamuud To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/a5pQLWNsfyDKHMR68J-XhOW7GDc Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Profiling RFC5424 for easy use from clients X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Oct 2014 17:02:40 -0000 ietfc.5424: Discuss.248x178 On 10/4/14, Cabdirisaaq Mahamuud wrote: > Discuss > > On 10/2/14, Nico Williams wrote: >> On Thu, Oct 02, 2014 at 03:10:44PM +0100, t.petch wrote: >>> There is a syslog mailing list, which might be the place to ask; on the >>> other hand, the last syslog query I saw came up on OPSAWG - I am unsure >>> how many of those involved would see a post to apps-discuss. >> >> Aha, thanks. I'll ask there. >> >>> At the time of writing RFC5424, JSON had yet to be the beam in anyone's >>> eye. >> >> Well, numerically the first JSON RFC predates RFC5424... But what I >> really meant by that is that if there's not a lot of use of RFC5424 >> structured data then we might consider using JSON in the text payload of >> syslog messages. Since RFC5424 seems to be well supported by servers, >> that's probably a non-starter, thus my lament: it's ETOOLATE. >> >> Nico >> -- >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > From nobody Fri Oct 3 12:33:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5163D1A1AF4 for ; Fri, 3 Oct 2014 12:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTzrUZcMvw_w for ; Fri, 3 Oct 2014 12:33:42 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC4F1A1A15 for ; Fri, 3 Oct 2014 12:33:42 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 17FE8509B6; Fri, 3 Oct 2014 15:33:40 -0400 (EDT) Message-ID: <542EF9EF.4010804@seantek.com> Date: Fri, 03 Oct 2014 12:33:03 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "t.petch" References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> <9AD273B04D7CB4B07CE8D1C5@JcK-HP8200.jck.com> <542C203D.3050504@seantek.com> <006301cfde64$86afd580$4001a8c0@gateway.2wire.net> In-Reply-To: <006301cfde64$86afd580$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3ztfC2vyb72l-48OL6e3b0wZB7k Cc: IETF Apps Discuss Subject: Re: [apps-discuss] IETF 91 scheduling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 19:33:44 -0000 On 10/2/2014 10:00 AM, t.petch wrote: > Sean Leonard wrote: >> Since filename extensions are not standardized (and there are many >> instances of content that are not file-oriented), the overall gist is >> that media types are becoming the de-facto vendor-neutral way to >> identify different types of content. > which is fine when the storage mechanism caters for metadata and makes > it accessible in a standard way. Sadly, the DOS directory was not > designed in that way, which is why the vast majority of computer system= s > in the world (Windows!) continue to use file extensions:-( > > The problem keeps recurring - character sets, i18n, etc - but we do not= > progress towards a solution. Correct. It is a significant industry-wide problem that nobody wants to=20 take charge of. Apple has addressed the problem well-enough by using extended attributes = to store a wide range of metadata. For example, OS X uses that for=20 Uniform Type Identifiers; for text files, the content encoding is stored = in the "com.apple.TextEncoding" attribute [1]. Unfortunately, that is=20 specific to Apple's use. (Technically "xattr" is from BSD though.)=20 Extended attributes are not standardized in POSIX, and other OSes treat=20 them differently. In Linux (specifically ext2/3/4 and btrfs=20 filesysetms), I believe that extended attributes are limited to one=20 filesystem block. As for Windows...NTFS has alternate data streams (ADS) which are used=20 for storing a lot of metadata. Ironically ADS is used "less" (in the=20 popular conception) for legitimate purposes, even though compared to the = Unix world, ADS is considerably more versatile, i.e.: arbitrary data=20 streams, can identify the stream as an appendage to the filename. It=20 doesn't help that the most common filesystem family for removable media=20 is still FAT/FAT32/exFAT, though (which offers no support for extended=20 attributes). It would be nice if there were a universal way to store metadata once it = leaves the domain of Internet protocols, but that is sort of where the=20 IETF's jurisdiction ends. Some folks insist that formats should or must=20 include all relevant metadata in the content stream. That is punting the = problem. Besides, there are formats that were never designed for=20 interchange that are now being foisted into the Internet infrastructure, = and those formats need the extra metadata as "help". Text encoding is a=20 prominent example. I thought about writing an I-D on how to store such metadata in a common = way by having Internet message header data stored alongside the file,=20 either in extended attributes or in an adjacent file, as:=20 document.markdown -> document.markdown.headers ([RFC6522] Section 4) or=20 document.markdown.u8hdr ([RFC6533] Section 6.3). I still might write it, = but it's low on the list. The issues then become: 1. what makes one particular metadata format (Internet message/MIME=20 headers) "better" than other metadata formats (RDF, Dublin Core, JSON,=20 YAML, Microdata format, blah blah), 2. what about all the corner cases (encoded words), 3. what happens when there are conflicts between other sources of=20 metadata (conflict between headers file and extended attributes;=20 conflict between HTTP server's desired headers and explicitly set=20 headers), and ultimately, 4. "will anybody actually use this". Sean [1]:=20 http://www.araxis.com/merge/documentation-os-x/working-with-character-enc= odings.en From nobody Sat Oct 4 04:23:19 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F981A026A for ; Sat, 4 Oct 2014 04:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_72=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfqXbUCfcB_x for ; Sat, 4 Oct 2014 04:23:16 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0781.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::781]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43FA71A026C for ; Sat, 4 Oct 2014 04:23:16 -0700 (PDT) Received: from pc6 (31.49.54.177) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Sat, 4 Oct 2014 11:22:52 +0000 Message-ID: <001f01cfdfc5$45e32860$4001a8c0@gateway.2wire.net> From: t.petch To: Sean Leonard References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> <9AD273B04D7CB4B07CE8D1C5@JcK-HP8200.jck.com> <542C203D.3050504@seantek.com> <006301cfde64$86afd580$4001a8c0@gateway.2wire.net> <542EF9EF.4010804@seantek.com> Date: Sat, 4 Oct 2014 12:20:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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: [31.49.54.177] X-ClientProxiedBy: DB3PR05CA0035.eurprd05.prod.outlook.com (25.160.41.163) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-Forefront-PRVS: 0354B4BED2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(54094003)(479174003)(377454003)(51704005)(189002)(199003)(33646002)(110136001)(77096002)(31966008)(61296003)(229853001)(46102003)(87286001)(95666004)(93886004)(106356001)(85306004)(97736003)(105586002)(62966002)(42186005)(107046002)(81686999)(19580395003)(85852003)(15202345003)(80022003)(19580405001)(87976001)(88136002)(50466002)(40100001)(89996001)(15975445006)(84392001)(93916002)(104166001)(76482002)(14496001)(92726001)(92566001)(102836001)(47776003)(64706001)(20776003)(66066001)(21056001)(62236002)(86362001)(50986999)(101416001)(44716002)(116806002)(81816999)(120916001)(50226001)(76176999)(99396003)(4396001)(44736004)(10300001)(23746002)(77156001)(122386002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hRt1EVQx2hohkK4RVXoMM3d0EYg Cc: IETF Apps Discuss Subject: [apps-discuss] metadata for files was Re: IETF 91 scheduling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 11:23:18 -0000 ----- Original Message ----- From: "Sean Leonard" To: "t.petch" Cc: "IETF Apps Discuss" Sent: Friday, October 03, 2014 8:33 PM On 10/2/2014 10:00 AM, t.petch wrote: > Sean Leonard wrote: >> Since filename extensions are not standardized (and there are many >> instances of content that are not file-oriented), the overall gist is >> that media types are becoming the de-facto vendor-neutral way to >> identify different types of content. > which is fine when the storage mechanism caters for metadata and makes > it accessible in a standard way. Sadly, the DOS directory was not > designed in that way, which is why the vast majority of computer systems > in the world (Windows!) continue to use file extensions:-( > > The problem keeps recurring - character sets, i18n, etc - but we do not > progress towards a solution. Correct. It is a significant industry-wide problem that nobody wants to take charge of. Apple has addressed the problem well-enough by using extended attributes to store a wide range of metadata. For example, OS X uses that for Uniform Type Identifiers; for text files, the content encoding is stored in the "com.apple.TextEncoding" attribute [1]. Unfortunately, that is specific to Apple's use. (Technically "xattr" is from BSD though.) Extended attributes are not standardized in POSIX, and other OSes treat them differently. In Linux (specifically ext2/3/4 and btrfs filesysetms), I believe that extended attributes are limited to one filesystem block. As for Windows...NTFS has alternate data streams (ADS) which are used for storing a lot of metadata. Ironically ADS is used "less" (in the popular conception) for legitimate purposes, even though compared to the Unix world, ADS is considerably more versatile, i.e.: arbitrary data streams, can identify the stream as an appendage to the filename. It doesn't help that the most common filesystem family for removable media is still FAT/FAT32/exFAT, though (which offers no support for extended attributes). It would be nice if there were a universal way to store metadata once it leaves the domain of Internet protocols, but that is sort of where the IETF's jurisdiction ends. Some folks insist that formats should or must include all relevant metadata in the content stream. That is punting the problem. Besides, there are formats that were never designed for interchange that are now being foisted into the Internet infrastructure, and those formats need the extra metadata as "help". Text encoding is a prominent example. I thought about writing an I-D on how to store such metadata in a common way by having Internet message header data stored alongside the file, either in extended attributes or in an adjacent file, as: document.markdown -> document.markdown.headers ([RFC6522] Section 4) or document.markdown.u8hdr ([RFC6533] Section 6.3). I still might write it, but it's low on the list. The issues then become: 1. what makes one particular metadata format (Internet message/MIME headers) "better" than other metadata formats (RDF, Dublin Core, JSON, YAML, Microdata format, blah blah), 2. what about all the corner cases (encoded words), 3. what happens when there are conflicts between other sources of metadata (conflict between headers file and extended attributes; conflict between HTTP server's desired headers and explicitly set headers), and ultimately, 4. "will anybody actually use this". Sean Thank you for a comprehensive survey to my mildly facetious post. I could add one or two more proprietary schemes but think you have covered the field. The first step to doing anything is to get enough energy here on this list to do something (the issue of conflicts between file extensions and media types has surfaced on this list before). If something, then I would start with a problem description I-D, before looking for a solution. I have somewhere a list of some 98 different interpretations of .dat which I always think sums it up well. And I wonder if Microsoft or Apple or ... have IPR in this field, but that is a topic for the future. Tom Petch Sean [1]: http://www.araxis.com/merge/documentation-os-x/working-with-character-en codings.en From nobody Thu Oct 9 12:03:19 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CB91A1AB4 for ; Thu, 9 Oct 2014 12:03:16 -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, 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 oGIY5k1h41_H for ; Thu, 9 Oct 2014 12:03:12 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0736.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::736]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D383A1A1A8B for ; Thu, 9 Oct 2014 12:03:09 -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.0.1044.10; Thu, 9 Oct 2014 19:02:40 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.1044.008; Thu, 9 Oct 2014 19:02:40 +0000 From: Dave Thaler To: Apps Discuss Thread-Topic: [appsawg] #31 (uri-scheme-reg): Remove paragraph on nonconfirming registration proposals Thread-Index: AQHP4+00EMkjnhVxsUaWya0vftPUE5woG7Lg Date: Thu, 9 Oct 2014 19:02:40 +0000 Message-ID: References: <063.835ef85327c7a7c518eca78f25530f0e@trac.tools.ietf.org> In-Reply-To: <063.835ef85327c7a7c518eca78f25530f0e@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e8:ee31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB412; x-forefront-prvs: 0359162B6D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(199003)(189002)(50986999)(97736003)(21056001)(76176999)(54356999)(99396003)(2656002)(561944003)(85306004)(92566001)(86362001)(85852003)(31966008)(76482002)(46102003)(80022003)(120916001)(33646002)(64706001)(74316001)(87936001)(20776003)(101416001)(106116001)(105586002)(99286002)(106356001)(107046002)(122556002)(110136001)(230783001)(40100002)(76576001)(108616004)(95666004)(4396001)(24736002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB412; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/HAzeCsypD4rg125b9CVLQbQlKAE Cc: "fielding@gbiv.com" Subject: Re: [apps-discuss] [appsawg] #31 (uri-scheme-reg): Remove paragraph on nonconfirming registration proposals X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 19:03:17 -0000 Um95IEZpZWxkaW5nIHdyb3RlLCBkdXJpbmcgV0dMQzoNCj4gIFRoaXMgcGFyYWdyYXBoIHNob3Vs ZCBiZSByZW1vdmVkOg0KPiANCj4gICAgIElmIHBhcnRpZXMgYWNoaWV2ZSBjb25zZW5zdXMgb24g YSByZWdpc3RyYXRpb24gcHJvcG9zYWwgdGhhdCBkb2VzIG5vdA0KPiAgICAgZnVsbHkgY29uZm9y bSB0byB0aGUgc3RyaWN0IHdvcmRpbmcgb2YgdGhpcyBwcm9jZWR1cmUsIHRoaXMgc2hvdWxkIGJl DQo+ICAgICBkcmF3biB0byB0aGUgYXR0ZW50aW9uIG9mIGEgcmVsZXZhbnQgbWVtYmVyIG9mIHRo ZSBJRVNHLg0KPiANCj4gIGJlY2F1c2UgaXQncyBsYW1lLCBhbmQgYWxzbyBiZWNhdXNlIGl0IGlz IGltcGxpZWQgYnkgdGhlIHByaW9yIHBhcmFncmFwaC4NCj4gIEEgInJlbGV2YW50IG1lbWJlciI/ IFRoYXQncyBqdXN0IGJlZ2dpbmcgZm9yIHJlaW50ZXJwcmV0YXRpb24uDQoNCkknbSB1cGRhdGlu ZyBkcmFmdC1pZXRmLWFwcHNhd2ctdXJpLXNjaGVtZS1yZWcgdG8gYWRkcmVzcyBjb21tZW50cw0K cmVjZWl2ZWQgZHVyaW5nIFdHTEMuDQoNCkkgYWdyZWUgd2l0aCBSb3kncyBwcm9wb3NhbCB0byBk ZWxldGUgdGhlIHF1b3RlZCBwYXJhZ3JhcGgsIGFsdGhvdWdoDQpJIGRpc2FncmVlIHRoYXQgaXQn cyBpbXBsaWVkIGJ5IHRoZSBwcmlvciBwYXJhZ3JhcGggd2hpY2ggaXM6DQo+ICAgSW4gZXhjZXB0 aW9uYWwgY2FzZXMsIHdoZXJlIHRoZSBuZWdvdGlhdGluZyBwYXJ0aWVzIGNhbm5vdCBmb3JtIGEN Cj4gICBjb25zZW5zdXMsIHRoZSBmaW5hbCBhcmJpdGVyIG9mIGFueSBjb250ZXN0ZWQgcmVnaXN0 cmF0aW9uIHNoYWxsIGJlDQo+ICAgdGhlIElFU0cuDQoNClRoYXQgcGFyYWdyYXBoIGlzIGFib3V0 IHRoZSBjYXNlIHdoZXJlIHRoZSByZXZpZXdlciBhbmQgdGhlIGFwcGxpY2FudA0KY2Fubm90IGFn cmVlLiAgVGhlIGZvbGxvd2luZyBwYXJhZ3JhcGggUm95IHF1b3RlcyBpcyBhYm91dCBhIGNhc2UN CndoZXJlIHRoZSByZXZpZXdlciBhbmQgdGhlIGFwcGxpY2FudCBhZ3JlZSB0byBub3QgZm9sbG93 IHRoZSBSRkMuDQpJZiAicmVsZXZhbnQgbWVtYmVyIiB3ZXJlIHRoZSBvbmx5IHByb2JsZW0sIEkn ZCBjaGFuZ2UgaXQgdG8NCiIuLi4gdG8gdGhlIGF0dGVudGlvbiBvZiB0aGUgSUVTRyIgZm9yIGNv bnNpc3RlbmN5IHdpdGggdGhlIHByaW9yIHBhcmFncmFwaC4NCg0KSG93ZXZlciwgdGhlIHJlYXNv bnMgSSBhZ3JlZSB3aXRoIFJveSdzIHJlY29tbWVuZGF0aW9uIGFyZToNCjEpIER1cmluZyBXRyBk aXNjdXNzaW9uLCB0aGUgV0cgYWdyZWVkIHRvIGxvd2VyIHRoZSBsb2FkIG9uIHRoZSBJRVNHDQog ICAgYW5kIGVtcG93ZXIgdGhlIEV4cGVydCBtb3JlLCBzbyB3ZSB3YW50IHRvIHJlZHVjZSBjYXNl cyB0aGF0IG5lZWQNCiAgICBJRVNHIGludm9sdmVtZW50Lg0KMikgVGhlIHByb2JsZW1hdGljIHBh cmFncmFwaCBpbXBsaWVzIHRoYXQgaXQncyBvayBmb3IgdGhlIHJldmlld2VyDQogICAgdG8gZGV2 aWF0ZSBmcm9tIHRoZSBSRkMsIHdoaWNoIEkgdGhpbmsgdGhlIFJGQyBzaG91bGQgbm90IGV4cGxp Y2l0bHkNCiAgICBzdWdnZXN0Lg0KMykgTm93IHRoYXQgd2UgbG93ZXJlZCB0aGUgYmFyIGZvciBQ cm92aXNpb25hbCB0byBiZSBGQ0ZTLCBpdCBzZWVtcw0KICAgIHVubGlrZWx5IHRoZSBwYXJhZ3Jh cGggY291bGQgZXZlciBhcHBseSB0byBQcm92aXNpb25hbCwgYW5kIHJhdGhlcg0KICAgIHRoYW4g YWxsb3dpbmcgZGV2aWF0aW9uIGZyb20gdGhlIFJGQyBmb3IgUGVybWFuZW50LCBkZWxldGluZw0K ICAgIHRoZSBwYXJhZ3JhcGggaW1wbGllcyB0aGF0IFBlcm1hbmVudCBzaG91bGQgbm93IGFsd2F5 cyBhZGhlcmUNCiAgICB0byB0aGUgUkZDLiAgQSByZWdpc3RyYXRpb24gY2FuIHVzZSBQcm92aXNp b25hbCBpbnN0ZWFkIGlmIHRoYXQncyBhIHByb2JsZW0uDQoNCkhlbmNlIEkgdGhpbmsgcmVtb3Zp bmcgdGhlIHBhcmFncmFwaCBSb3kgY29tcGxhaW5zIGFib3V0IGlzIHRoZQ0KcmlnaHQgdGhpbmcs IGFuZCBpcyBjb25zaXN0ZW50IHdpdGggcHJldmlvdXMgV0cgYWdyZWVtZW50Lg0KDQpJIHdpbGwg cmVtb3ZlIHRoZSBwYXJhZ3JhcGgsIGJ1dCB3YW50ZWQgdG8gZ2l2ZSB0aGlzIGxvbmdlciBleHBs YW5hdGlvbiBmb3IgdGhlIHJlY29yZC4NCg0KLURhdmUNCg== From nobody Thu Oct 9 12:15:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CBD1A1ABF for ; Thu, 9 Oct 2014 12:15:47 -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, 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 mZTSW56RB_qL for ; Thu, 9 Oct 2014 12:15:45 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0788.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:788]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 075C41A1A8B for ; Thu, 9 Oct 2014 12:15:44 -0700 (PDT) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB411.namprd03.prod.outlook.com (10.141.141.22) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Thu, 9 Oct 2014 19:15:20 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.1044.008; Thu, 9 Oct 2014 19:15:20 +0000 From: Dave Thaler To: Apps Discuss Thread-Topic: [appsawg] #31 (uri-scheme-reg): Remove paragraph on nonconfirming registration proposals Thread-Index: AQHP4+00EMkjnhVxsUaWya0vftPUE5woG7LggAAEQ2A= Date: Thu, 9 Oct 2014 19:15:20 +0000 Message-ID: References: <063.835ef85327c7a7c518eca78f25530f0e@trac.tools.ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e8:ee31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB411; x-forefront-prvs: 0359162B6D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(24454002)(51694002)(51704005)(54356999)(80022003)(46102003)(33646002)(20776003)(64706001)(31966008)(74316001)(15202345003)(76176999)(50986999)(101416001)(561944003)(76576001)(21056001)(95666004)(99286002)(85852003)(15975445006)(120916001)(87936001)(76482002)(2656002)(105586002)(97736003)(110136001)(92566001)(86362001)(106116001)(106356001)(99396003)(4396001)(108616004)(230783001)(40100002)(107046002)(85306004)(122556002)(19580395003)(24736002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB411; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3zPf2pOaZroe5ZvsrCgW3BMFnMc Cc: "fielding@gbiv.com" , Graham Klyne Subject: Re: [apps-discuss] [appsawg] #31 (uri-scheme-reg): Remove paragraph on nonconfirming registration proposals X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 19:15:47 -0000 I wrote: > Roy Fielding wrote, during WGLC: > > This paragraph should be removed: > > > > If parties achieve consensus on a registration proposal that does n= ot > > fully conform to the strict wording of this procedure, this should = be > > drawn to the attention of a relevant member of the IESG. > > > > because it's lame, and also because it is implied by the prior paragra= ph. > > A "relevant member"? That's just begging for reinterpretation. >=20 > I'm updating draft-ietf-appsawg-uri-scheme-reg to address comments receiv= ed > during WGLC. >=20 > I agree with Roy's proposal to delete the quoted paragraph, although I di= sagree > that it's implied by the prior paragraph which is: > > In exceptional cases, where the negotiating parties cannot form a > > consensus, the final arbiter of any contested registration shall be > > the IESG. >=20 > That paragraph is about the case where the reviewer and the applicant can= not > agree. The following paragraph Roy quotes is about a case where the revi= ewer > and the applicant agree to not follow the RFC. > If "relevant member" were the only problem, I'd change it to "... to the = attention > of the IESG" for consistency with the prior paragraph. >=20 > However, the reasons I agree with Roy's recommendation are: > 1) During WG discussion, the WG agreed to lower the load on the IESG > and empower the Expert more, so we want to reduce cases that need > IESG involvement. > 2) The problematic paragraph implies that it's ok for the reviewer > to deviate from the RFC, which I think the RFC should not explicitly > suggest. > 3) Now that we lowered the bar for Provisional to be FCFS, it seems > unlikely the paragraph could ever apply to Provisional, and rather > than allowing deviation from the RFC for Permanent, deleting > the paragraph implies that Permanent should now always adhere > to the RFC. A registration can use Provisional instead if that's a p= roblem. >=20 > Hence I think removing the paragraph Roy complains about is the right thi= ng, > and is consistent with previous WG agreement. >=20 > I will remove the paragraph, but wanted to give this longer explanation f= or the > record. Here's Graham's comment on this topic from http://www.ietf.org/mail-archive/web/apps-discuss/current/msg11444.html > > Section 7.1: > > > > [[CREF9: TODO: We don't want this. --??]] > > > > I think it is useful that the IESG can be final arbiter, as it provides= some room > > for making decisions that are not in strict accordance with the process > > requirements, without kicking the door open to making arbitrary and > > capricious decisions. There have been a few cases (I forget details) w= here > > the specific drafting of the process has seemed to be at odds with a co= mmon > > sense "do the right thing" approach - having a way to accommodate these > > within a clearlhy documented framework seems useful to me. I agree with Roy that the prior paragraph (which I quoted above) already gi= ves sufficient room to accommodate Graham's point. That is, if the reviewer j= udges that the request and the RFC are not in agreement, the reviewer can treat i= t as a "contested registration" and ask the IESG to be the arbiter. So removin= g the paragraph still leave a clearly documented framework to accommodate unusual requests. Just wanted to point out that I have taken Graham's previous feedback into account, I haven't forgotten it :) -Dave From nobody Thu Oct 9 12:31:55 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0DE1A7017 for ; Thu, 9 Oct 2014 12:31:54 -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 x3F57-T76lZL for ; Thu, 9 Oct 2014 12:31:52 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09C81A7015 for ; Thu, 9 Oct 2014 12:31:52 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so14137654igb.8 for ; Thu, 09 Oct 2014 12:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=nrOpt51Dk7Iysq5LMHJ1kAKujzpLG6nUk86cRAA7l7U=; b=I7ndbPtzapBpy1exjEFkxk4fwmobttzQctAM0PIWfWNB9FBN59OqqW31WkxeoUwGMv NEmWZXY2gVDgUIgy8kRdko0DP6mid4bbifFarwR6eRpNroEogugBU5bg56jfJ1hLc7PC owu//fjjEXca1e07pJxM/sDzfBvqeWeWm//Rb/D3C6/JzG1ETVoq50ZtCBRoHPOrX5st mf59JmzmQDSW0NVlpUJpw4CbKwxZxXwfQ3zUBz/fKXDt2ta0I4tNtS6VG4bd6MW7xNjG EtRVi5tyUljDagujx0KNapo1THCxlzgwpweuO6ypMRU1wULyocR+b8Pr2S+hpDF5bluk j0HA== MIME-Version: 1.0 X-Received: by 10.50.22.101 with SMTP id c5mr184305igf.29.1412883112142; Thu, 09 Oct 2014 12:31:52 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.163.3 with HTTP; Thu, 9 Oct 2014 12:31:52 -0700 (PDT) In-Reply-To: <44462BFE-B5E1-4944-82F4-06CD89DFAC12@ietf.org> References: <44462BFE-B5E1-4944-82F4-06CD89DFAC12@ietf.org> Date: Thu, 9 Oct 2014 15:31:52 -0400 X-Google-Sender-Auth: kANvIEhy5K10Ve9zmZEm4Ss98r8 Message-ID: From: Barry Leiba To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/K_9e2swI5I5Ev6ZP5GCcTxfNMWI Subject: [apps-discuss] Fwd: Proposed IESG structure change X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 19:31:54 -0000 For any who didn't see this on ietf-announce. Discussion on , please, not here. Barry ---------- Forwarded message ---------- From: IETF Chair Date: Tue, Oct 7, 2014 at 6:24 PM Subject: Proposed IESG structure change To: IETF Announcement List Cc: IETF Discussion Dear Community: The IESG is considering a change in structure, with the intent to increase flexibility as IETF work evolves, to ensure that all IETF work is covered by an AD, and to balance and reduce the workload across the ADs. A significant amount of the work that is going on in the APP area pertains to the web protocols, but that has a good deal of crossover with work in RAI. There is also some crossover work between the APP and TSV areas. While the specific amount of work in any IETF area fluctuates over time, we have noticed that the number of WGs in the APP area, particularly on the non-web protocols, is currently shrinking. So we are starting to think about reorganizing the areas a bit, possibly merging parts (or all) of the APP and RAI areas into a single area, possibly redistributing work in other ways between all of the areas, but in any event changing the load balance among the areas and the ADs, while continuing the work that the WGs are currently doing. It is explicitly not our intention to bar any existing or new work from the IETF with these changes. We are committing to coming up with a proposal to the community for that by May 2015. We believe the end result of that could be to reduce the number of areas by one. In the short term, however, we would like to advise the NomCom to *not* fill the APP AD vacancy in this NomCom cycle. We believe the current load can be handled by the one remaining APP AD, and the RAI and TSV ADs are committed to helping out if need be. We believe that it is unreasonable to have the NomCom find a new AD and ask them to commit to two years only to discover later that we may want to eliminate or significantly change the responsibilities for that position within a year. Whether the end result is that we end up with a combined larger RAI/APP area that requires three ADs, or recombining in some other way, we think reducing down to 14 ADs in this NomCom cycle is the right thing to do. We want and need community consultation on this topic. We believe this is the correct path, but we need to hear if there are any concerns from the rest of the community before we tell the NomCom to do this. Please send your comments toietf@ietf.org, or alternatively to iesg@ietf.org if you prefer, by 13 October 2014. We need to let the NomCom know ASAP if we decide to move forward with this. Jari Arkko for the IESG From nobody Fri Oct 10 17:17:20 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B716B1A02EB; Fri, 10 Oct 2014 17:17:17 -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 TWCi4MT52z7n; Fri, 10 Oct 2014 17:17:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EC11A02F5; Fri, 10 Oct 2014 17:17:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141011001713.19527.66060.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 17:17:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/r27wGar-gzKO-H6CQimTGQUnSBk Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-uri-scheme-reg-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, 11 Oct 2014 00:17:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Guidelines and Registration Procedures for URI Schemes Authors : Dave Thaler Tony Hansen Ted Hardie Larry Masinter Filename : draft-ietf-appsawg-uri-scheme-reg-03.txt Pages : 18 Date : 2014-10-10 Abstract: This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-uri-scheme-reg-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 Fri Oct 10 17:31:13 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89DE1A02FE for ; Fri, 10 Oct 2014 17:31:11 -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, 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 cm2zr3NWXbDS for ; Fri, 10 Oct 2014 17:31:08 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::737]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE491A0052 for ; Fri, 10 Oct 2014 17:31:08 -0700 (PDT) Received: from DM2PR03MB413.namprd03.prod.outlook.com (10.141.84.142) by DM2PR03MB320.namprd03.prod.outlook.com (10.141.54.23) with Microsoft SMTP Server (TLS) id 15.0.1049.13; Sat, 11 Oct 2014 00:30:45 +0000 Received: from DM2PR03MB414.namprd03.prod.outlook.com (10.141.84.145) by DM2PR03MB413.namprd03.prod.outlook.com (10.141.84.142) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Sat, 11 Oct 2014 00:30:43 +0000 Received: from DM2PR03MB414.namprd03.prod.outlook.com ([10.141.84.145]) by DM2PR03MB414.namprd03.prod.outlook.com ([10.141.84.145]) with mapi id 15.00.1044.008; Sat, 11 Oct 2014 00:30:43 +0000 From: Dave Thaler To: Graham Klyne , Alexey Melnikov , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] WGLC on draft-ietf-appsawg-uri-scheme-reg Thread-Index: AQHPwu1livNbbT889kGb6hibzuLr6ZvnVtEAgEL2qZA= Date: Sat, 11 Oct 2014 00:30:42 +0000 Message-ID: <6b0d63e5933c413bb73ea32c656a4b47@DM2PR03MB414.namprd03.prod.outlook.com> References: <53FF740D.5060305@isode.com> <54004C58.6020406@ninebynine.org> In-Reply-To: <54004C58.6020406@ninebynine.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [131.107.192.203] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR03MB413;UriScan:; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-forefront-prvs: 0361212EA8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(15454003)(24454002)(51704005)(2656002)(230783001)(15975445006)(31966008)(101416001)(85306004)(85852003)(33646002)(108616004)(86362001)(86612001)(87936001)(64706001)(76576001)(107046002)(107886001)(122556002)(20776003)(105586002)(19580395003)(561944003)(46102003)(80022003)(76482002)(76176999)(4396001)(50986999)(54356999)(15202345003)(21056001)(106356001)(99286002)(95666004)(92566001)(106116001)(66066001)(99396003)(74316001)(97736003)(120916001)(40100003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR03MB413; H:DM2PR03MB414.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR03MB320; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/sWs1ZbyN9XSBqI_6euVnmFKFVVA Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-uri-scheme-reg X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 00:31:11 -0000 Graham Klyne wrote: > I have one possibly substantive comment: >=20 > Section 4.1 sets out normative requirements on provisional registrations, > mostly SHOULD, but some REQUIRED. Yet section 7.1 removes the requirement > for any review (which I support). Thus, while I'm all for encouraging tha= t > various desiderata in section 4.1 are satisfied, I'm not sure if it works > for these be be normative in a specification that may be not reviewed. My > thoughts are to either: >=20 > (a) tone down the normative language in section 4.1, while leaving > everything strongly encouraged. E.g. >=20 > Current: >=20 > For a provisional registration, the following are REQUIRED: >=20 > Propose: >=20 > For a provisional registration, submitters are strongly encouraged to > ensure their proposal satisfies the following criteria: >=20 >=20 > (b) [...] >=20 >=20 > On balance, as the purpose of provisional registration is to facilitate > access to even rudimentary information about proposed and in-use schemes, > I favour option (a) or similar. Agreed, and I believe (a) is already consistent with existing WG consensus, so it is purely editorial in my view. Accepted proposed text to replace the REQUIRED. And there were uses of SHOULD in the text for each of the criteria. I changed 'SHOULD' to 'should= ' in each case, since they're all under the intro text Graham quotes. > Related to this. It's never been a problem to date, but should there be > some defined possibility for frivolous or disruptive registrations to be > removed (e.g. at request of DE)? I don't think it's a good idea to use up WG effort to design a process for something that's never been a problem and we hope never will be, as long as it's not catastrophic if it does occur. For URI schemes, it's not catastrop= hic and there are already other recourses such as reclassifying as Historic or adding info to the Notes column. And as no one else brought it up and Graham only asks it as a question, I'll treat this as addressed unless someone raises it as a blocking issue during IETF Last Call. > ... >=20 >=20 > The following comments are mostly editorial, and don't substantively affe= ct the spec. >=20 > # 3.4. Definition of Operations >=20 > Final paragraph (dereferencing). I think the spec should say something ab= out=20 > dereferencing a URI being "safe", in the sense of=20 > http://www.w3.org/TR/2004/REC-webarch-20041215/#safe-interaction >=20 > E.g., include something like this: >=20 > The default invocation, or dereferencing, of a URI should be "safe" > (in the sense described by [W3CWebArch] section 3.4); i.e. an agent > performing such an interaction should not incur any additional > obligations by doing so. Done, with=20 s/should be/SHOULD be/ > # 3.7. Clear Security Considerations >=20 > Current: >=20 > The definition of an individual scheme should note which of these apply > to the specified scheme. >=20 > Suggest: >=20 > The definition of an individual scheme should note which of these apply > to the specified scheme, in addition to any more scheme-specific concern= s. Done as suggested. > # 3.8. Scheme Name Considerations >=20 > Para 5. The text introduces protocols and applications, then describes a= =20 > requirement in terms of services. I find this reads oddly. >=20 > Current: >=20 > If a scheme name has a one-to-one correspondence with a service name > (see section 5 of [RFC6335]), then the names SHOULD be the same. >=20 > Suggest: >=20 > If a scheme name has a one-to-one correspondence with a protocol or > application name (see section 5 of [RFC6335]), then the names SHOULD > be the same. Agree with the problem, though the text suggested above just moves the problem around since that text doesn't match what section 5 of RFC 6335 actually talks about. Reworded instead as: A scheme name is not a "protocol" although, like a service name as defined in section 5 of [RFC6335], it often identifies a particular protocol or application. If a scheme name has a one-to-one correspondence with a service name, then the names SHOULD be the same. > Final para: I note there is still a problem reference CREF1...? in this=20 > last-call document. Roy Fielding mentioned the same thing in his review. Yes, it was to be removed at end of WGLC as the cref implied. I have now done so in -03 and will close the two relevant tickets (#17 for this one). -Dave From nobody Mon Oct 13 02:04:34 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E966E1A8903; Mon, 13 Oct 2014 02:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TOOL=2.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 K8lgzmkE-PnT; Mon, 13 Oct 2014 02:04:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F070D1A8900; Mon, 13 Oct 2014 02:04:29 -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: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141013090429.7983.2844.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 02:04:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/L-yVPkdNa9JEVn7Ujh-fyv-08s8 Cc: scott@kitterman.com, draft-ietf-appsawg-authres-ptypes-registry@tools.ietf.org, appsawg-chairs@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-authres-ptypes-registry-04: (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, 13 Oct 2014 09:04:31 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-appsawg-authres-ptypes-registry-04: 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 http://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: http://datatracker.ietf.org/doc/draft-ietf-appsawg-authres-ptypes-registry/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I wondered if it'd be worthwhile asking that the designated expert try ensure that the security and privacy consequences of new entries also be documented? That's assuming there are cases where the header field is likely to transit between ADMDs. I'm not sure if that's really needed though, but 7001 does have a fairly significant set of security considerations, so presumably new entries might also deserve a similar level of documentation. OTOH, I could buy that experience with 7001 means that this isn't really needed or that demanding that level of documentation might be counterproductive. From nobody Mon Oct 13 05:35:35 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8AD81A8A1A for ; Mon, 13 Oct 2014 05:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lytw154Y_Znl for ; Mon, 13 Oct 2014 05:35:30 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B3F1A8A12 for ; Mon, 13 Oct 2014 05:35:30 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.150.51]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s9DCZA83004987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2014 05:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1413203722; x=1413290122; bh=v5EiJclTjjaHSTiacx98jzKg3V2of+WQzHs1lwBnUk4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xKGZ85T2gZEklQuUGpVT8zU6Lb0m2ZvLiWqd1ijF5Djosn6wPCMpmZIVho6t/tLwf GbR/gr11pmL1e92/xqrcgnu74iA5Kv+0U8qDbdaqvtcjqND6/UrZLNzy1aLNlZyt3K RWjxvmws184xYwcH2a41L7pIOCofHuOxcUgYgEqU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1413203722; x=1413290122; i=@elandsys.com; bh=v5EiJclTjjaHSTiacx98jzKg3V2of+WQzHs1lwBnUk4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=hjMKZh9TeR2w0qUZd8DFwhfYFF6SdpSsWbcuqhlN+O4Y+hA2mO6PdA/r0OX9F1BbP MjrF6vC+Cx/XsP5w+04jps1Wae1+NiX6Wjh+PV7w/ywXXzXwDjWUH4oiZ1iicrRPpr a0x5SHgtcUPf7mRBZfTcCiiuJqxDAv8lDR/DhCG4= Message-Id: <6.2.5.6.2.20141013045218.0d320cd8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 13 Oct 2014 05:10:47 -0700 To: apps-discuss@ietf.org From: S Moonesamy In-Reply-To: <20140916204131.23593.40644.idtracker@ietfa.amsl.com> References: <20140916204131.23593.40644.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/F0KeEKjf-_Ceh4LCjdlyGagOMT8 Subject: Re: [apps-discuss] Last Call: (A Property Types Registry for the Authentication-Results Header Field) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 12:35:32 -0000 At 13:41 16-09-2014, The IESG wrote: >The IESG has received a request from the Applications Area Working Group >WG (appsawg) to consider the following document: >- 'A Property Types Registry for the Authentication-Results Header Field' > as Proposed >Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2014-09-30. Exceptionally, comments may be These are late comments. I'll defer to Murray on what to do. The "ptype" allows for information extracted by the body to be included in the Authentication-Results header field. That goes well beyond conveying the results of a message authentication effort in a machine-readable format. According to Section 1, it is because: "There has emerged a desire to report types of properties about a message through this mechanism." It looks like the Authentication-Results header field is being used as a matter of convenience because it has already been specified and it is possible to extend the mechanism. Why does the sort of information which will be conveyed within the administrative boundary have to be registered? What should the Expert Review do for information which is conveyed outside the administrative boundary? Regards, S. Moonesamy From nobody Mon Oct 13 11:07:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6284A1A874D for ; Mon, 13 Oct 2014 11:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKKR_oY812WF for ; Mon, 13 Oct 2014 11:06:57 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F54A1A8742 for ; Mon, 13 Oct 2014 11:06:55 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id p9so6874482lbv.19 for ; Mon, 13 Oct 2014 11:06: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 :cc:content-type; bh=XxFDQhliVgj1NktvnKvHzV3oAuTvArxA4ttBnpIaj3g=; b=hkID+7gkksAbeJAgmHXIuSl1rXw48gRlhMJ563RP+oAUhQQL8ARHYUkXfu+O/OFbfM mZjteUSLuTuCE+tP1X2tO/fUneadeX12Zco9hCQQJpH2uTfDdCjEuPTXtRxqi8xfTQUQ Zjdr7qmg23J/35gt1J30dkRwehJ1Gjv8qceVkhHeEqzFgbu1X4zPTiU94pImE1oZzHmz 6jabWA1AESJdj9QYKREqOB5pEHsKxrNE3fbX83Yo9ZjI1hzwUZ/hopU9g+2bGlAQI+xm 7jMBaTlblOA3U+KLRz3u5YmbEiF83P5OMsyZVlHP8g5ouuhDb6TWm2tdeqDNpIDBUbEn J+UA== MIME-Version: 1.0 X-Received: by 10.152.7.7 with SMTP id f7mr76408laa.57.1413223613556; Mon, 13 Oct 2014 11:06:53 -0700 (PDT) Received: by 10.25.211.11 with HTTP; Mon, 13 Oct 2014 11:06:53 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20141013045218.0d320cd8@resistor.net> References: <20140916204131.23593.40644.idtracker@ietfa.amsl.com> <6.2.5.6.2.20141013045218.0d320cd8@resistor.net> Date: Mon, 13 Oct 2014 11:06:53 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=001a11c2870a796fae050551c373 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/lvmIDtRMTEcgLx4weKP_4Sa9sO0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Last Call: (A Property Types Registry for the Authentication-Results Header Field) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 18:06:59 -0000 --001a11c2870a796fae050551c373 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 13, 2014 at 5:10 AM, S Moonesamy wrote: > The "ptype" allows for information extracted by the body to be included in > the Authentication-Results header field. That goes well beyond conveying > the results of a message authentication effort in a machine-readable > format. According to Section 1, it is because: > > "There has emerged a desire to report types of properties about > a message through this mechanism." > > It looks like the Authentication-Results header field is being used as a > matter of convenience because it has already been specified and it is > possible to extend the mechanism. Why does the sort of information which > will be conveyed within the administrative boundary have to be registered? > What should the Expert Review do for information which is conveyed outside > the administrative boundary? > That's an excellent point. Unfortunately, your point is really more about RFC7001 itself, which defined the "body" ptype, than it is about the guts of this particular document, so I don't know what (if any) action is appropriate here. I don't think it qualifies as an erratum against RFC7001 either, other than as a reminder to deal with it if there's ever an RFC7001bis. There are ample protections against leaking information across ADMD boundaries in RFC7001 itself. The question then is really about what happens when someone doesn't follow that advice. But I seem to recall that the Security Considerations in RFC7001 is already pretty thorough about that. -MSK --001a11c2870a796fae050551c373 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 13, 2014 at 5:10 AM, S Moonesamy <sm+ietf@= elandsys.com> wrote:
The "ptype" allow= s for information extracted by the body to be included in the Authenticatio= n-Results header field.=C2=A0 That goes well beyond conveying the results o= f a message authentication effort in a machine-readable format.=C2=A0 Accor= ding to Section 1, it is because:

=C2=A0 "There has emerged a desire to report types of properties about=
=C2=A0 =C2=A0a message through this mechanism."

It looks like the Authentication-Results header field is being used as a ma= tter of convenience because it has already been specified and it is possibl= e to extend the mechanism.=C2=A0 Why does the sort of information which wil= l be conveyed within the administrative boundary have to be registered?=C2= =A0 What should the Expert Review do for information which is conveyed outs= ide the administrative boundary?

That&#= 39;s an excellent point.=C2=A0 Unfortunately, your point is really more abo= ut RFC7001 itself, which defined the "body" ptype, than it is abo= ut the guts of this particular document, so I don't know what (if any) = action is appropriate here.=C2=A0 I don't think it qualifies as an erra= tum against RFC7001 either, other than as a reminder to deal with it if the= re's ever an RFC7001bis.

There are ample protections = against leaking information across ADMD boundaries in RFC7001 itself.=C2=A0= The question then is really about what happens when someone doesn't fo= llow that advice.=C2=A0 But I seem to recall that the Security Consideratio= ns in RFC7001 is already pretty thorough about that.

-MSK
--001a11c2870a796fae050551c373-- From nobody Mon Oct 13 11:07:43 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691461A8928 for ; Mon, 13 Oct 2014 02:35:31 -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, 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 PYcCsNyNdsBW for ; Mon, 13 Oct 2014 02:35:29 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B548E1A8927 for ; Mon, 13 Oct 2014 02:35:29 -0700 (PDT) Received: by mail-oi0-f53.google.com with SMTP id v63so12416881oia.40 for ; Mon, 13 Oct 2014 02:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mygrid.org.uk; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=CoQSP65m4scgUT1JwBz4umBVfMTRvEz9QEHNLx+oPtU=; b=htPULKSCGOH0Y3nJoil2LUXA+wOG5no4fG25HV+wkUEBjlNXvLz4c3o+Aip4IvOMxT LNMF/AOtt75EiGsoBvNaUwSRb9zwyePzoNQsSHiP2ds5545ESKXmJkBfsWWv6wgLlxtf lqeRWmzEJbkACHP9hhSDGkDtxpU1h8HkDHdoQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CoQSP65m4scgUT1JwBz4umBVfMTRvEz9QEHNLx+oPtU=; b=VrbPEiYV7Lphn9WF3BcKpghXaxzy/8jsYPVZ4XYh416XYxMIiFde4Hv2ScMB7fAXPF qN6ijchwyk8LLAdVtTz297m8vOtvzu2nm6mQXKuQqsPUviZ6mhVNQ9bRBFHwThAddbLA 0LwMuVThr0PumOrXZv5+juqeMBGuPBP8lih4xEKlmXB034+CC+QiQizOKlV6V7gPopiT hpB/9lDJ+0Hwg5V00HU5eASGpnYHMCIMuZHqT2T9IVaix8dDU3o6rCwpv0Lf3l5IaXGQ /QR6NTZOrtz9FSy2J7o5zGjvGX+x1he4u2SI1zWaZLAcI11hAK2s99OMcBjI1kaCw/Qf yPNg== X-Gm-Message-State: ALoCoQnUu66PBD2urPBdkU3SbPeXSP5i1M1G3PpXewCen/8zQu2D+PVkryl+zPxKQ+uVFcouXq4U MIME-Version: 1.0 X-Received: by 10.202.196.214 with SMTP id u205mr6795977oif.48.1413192929079; Mon, 13 Oct 2014 02:35:29 -0700 (PDT) Sender: stian@mygrid.org.uk Received: by 10.76.153.229 with HTTP; Mon, 13 Oct 2014 02:35:28 -0700 (PDT) Received: by 10.76.153.229 with HTTP; Mon, 13 Oct 2014 02:35:28 -0700 (PDT) In-Reply-To: References: <54235269.2060002@seantek.com> <01PCZ1WHF6Q80000SM@mauve.mrochek.com> Date: Mon, 13 Oct 2014 10:35:28 +0100 X-Google-Sender-Auth: dPfJ8RVU1qrDsMaIg5l1P1WfSyE Message-ID: From: Stian Soiland-Reyes To: Ira McDonald Content-Type: multipart/alternative; boundary=001a113e4c36899a5005054a9e5e Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8j_kGdW1OHX-z133C0bv_PDCPVw X-Mailman-Approved-At: Mon, 13 Oct 2014 11:07:27 -0700 Cc: IETF Apps Discuss , Ned Freed , media-types@iana.org Subject: Re: [apps-discuss] [media-types] A proposal for a new top-level media type: archive X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 09:35:31 -0000 --001a113e4c36899a5005054a9e5e Content-Type: text/plain; charset=UTF-8 +1 as well, specially on the general handling. For instance any archive/* could go through antivirus check. We have an archive type we have been meaning to get out of draft status and register with IANA as well, we currently call it application/vnd.wf4ever.robundle+zip but archive/robundle+zip would be a much better fit. https://w3id.org/bundle On 25 Sep 2014 06:06, "Ira McDonald" wrote: > Hi, > > +1 > > Cheers, > - Ira > > > Ira McDonald (Musician / Software Architect) > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music / High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto: blueroofmusic@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 > > > On Wed, Sep 24, 2014 at 10:38 PM, Ned Freed wrote: > >> > On 25 September 2014 09:23, Sean Leonard wrote: >> >> > > Colleagues on media-types and apps-discuss: >> > > >> > > I would like to propose that the IETF create a new top-level media >> type: >> > > archive. >> > > >> > > >> > Colour me interested. >> >> Yeah, me too. I'm surpised nobody has suggested this before. >> >> Ned >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types > > --001a113e4c36899a5005054a9e5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

+1 as well, specially on the general handling. For instance = any archive/* could go through antivirus check.

We have an archive type we have been meaning to get out of d= raft status and register with IANA as well, we currently call it=C2=A0 appl= ication/vnd.wf4ever.robundle+zip but archive/robundle+zip would be a much b= etter fit.

https://w3id.org/bundle<= /a>

On 25 Sep 2014 06:06, "Ira McDonald" &= lt;blueroofmusic@gmail.com&g= t; wrote:
Hi,

+1

Cheers,
- Ira

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

<= div style=3D"display:inline">

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

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

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

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

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


_______________________________________________
media-types mailing list
media-types@ietf.org
https://www.ietf.org/mailman/listinfo/media-types

--001a113e4c36899a5005054a9e5e-- From nobody Mon Oct 13 11:17:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CAA1A1BC4 for ; Mon, 13 Oct 2014 11:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sET_zWRmejA for ; Mon, 13 Oct 2014 11:17:27 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2931B1A1BC0 for ; Mon, 13 Oct 2014 11:17:27 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.150.51]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s9DIHCAK010402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2014 11:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1413224244; x=1413310644; bh=5dYzxCe/Ftg0UCNpLEw75TMUmyM3BX5fUeZuTaXTKgs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=BCcarAYe9t3gdvX3u7YVlbhHzS7GUt6cjZpRK2uyiacHqVcrYJp1ToscfvjoI5C3E l42Kc4wS8w6SzIw99mEsIrfOdc+zXWtn3uB1+U26h/BOHmYSgRzGn8TCBp01Lig5el IyGeRGfFR0FJYVLOVx53DmCQCNnet+olPFW+fYUY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1413224244; x=1413310644; i=@elandsys.com; bh=5dYzxCe/Ftg0UCNpLEw75TMUmyM3BX5fUeZuTaXTKgs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NfEqPPD6Ag2x4zgPpr30eT2m1vZOElqD4rjdtbj0fhuVvb/JQ1QX67RfvQzaId/Gm pdNxMm4M0S6fHacpLXXE9Qov7pUIYsbyT9u3EwBfODoQSQXNX4XpYbhBG/hL462v7c GUcBgmDpUqBRpfGlMe1zdrK80kyqdjIJnNRT1DzU= Message-Id: <6.2.5.6.2.20141013111153.0e111880@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 13 Oct 2014 11:15:50 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <20140916204131.23593.40644.idtracker@ietfa.amsl.com> <6.2.5.6.2.20141013045218.0d320cd8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mV-0-SUG1e30AqBn6uxw5HIApWc Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (A Property Types Registry for the Authentication-Results Header Field) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 18:17:28 -0000 Hi Murray, At 11:06 13-10-2014, Murray S. Kucherawy wrote: >That's an excellent point. Unfortunately, your point is really more >about RFC7001 itself, which defined the "body" ptype, than it is >about the guts of this particular Thanks for the feedback. Regards, S. Moonesamy From nobody Mon Oct 13 16:15:16 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D151A1A45; Mon, 13 Oct 2014 16:15:10 -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 rxKoxVp-pekV; Mon, 13 Oct 2014 16:15:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D961A1A4F; Mon, 13 Oct 2014 16:14:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141013231458.9701.63555.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 16:14:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ivBcSebTNSyZJV_lb6t0NQ0hPsw Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-multipart-form-data-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 23:15:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Returning Values from Forms: multipart/form-data Author : Larry Masinter Filename : draft-ietf-appsawg-multipart-form-data-05.txt Pages : 12 Date : 2014-10-13 Abstract: This specification (re)defines the multipart/form-data Internet Media Type, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. It replaces RFC 2388. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-multipart-form-data-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-multipart-form-data-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 13 16:19:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71ED81A1A46; Mon, 13 Oct 2014 16:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.688 X-Spam-Level: X-Spam-Status: No, score=-107.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, 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 lxNulzLIpNLk; Mon, 13 Oct 2014 16:19:03 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 20AC11A1A34; Mon, 13 Oct 2014 16:19:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2BFCC181C79; Mon, 13 Oct 2014 16:17:58 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20141013231758.2BFCC181C79@rfc-editor.org> Date: Mon, 13 Oct 2014 16:17:58 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/iPgAr530P3skf-J3HG7zjRgmtZU Cc: drafts-update-ref@iana.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] RFC 7377 on IMAP4 Multimailbox SEARCH Extension X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 23:19:04 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7377 Title: IMAP4 Multimailbox SEARCH Extension Author: B. Leiba, A. Melnikov Status: Standards Track Stream: IETF Date: October 2014 Mailbox: barryleiba@computer.org, alexey.melnikov@isode.com Pages: 11 Characters: 24711 Obsoletes: RFC 6237 Updates: RFC 4466 I-D Tag: draft-ietf-appsawg-multimailbox-search-04.txt URL: https://www.rfc-editor.org/rfc/rfc7377.txt The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the delays caused by many round trips and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX, UIDVALIDITY, and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466 and obsoletes RFC 6237. This document is a product of the Applications Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Oct 13 16:19:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511E41A1A5C; Mon, 13 Oct 2014 16:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.688 X-Spam-Level: X-Spam-Status: No, score=-102.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 6AWFiSSMD40e; Mon, 13 Oct 2014 16:19:17 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id BFCCE1A1A34; Mon, 13 Oct 2014 16:19:17 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8ABB8181C82; Mon, 13 Oct 2014 16:18:12 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20141013231812.8ABB8181C82@rfc-editor.org> Date: Mon, 13 Oct 2014 16:18:12 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zBOXieDtszw4IPHVVLrX8GWPdxY Cc: drafts-update-ref@iana.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] RFC 7386 on JSON Merge Patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 23:19:24 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7386 Title: JSON Merge Patch Author: P. Hoffman, J. Snell Status: Standards Track Stream: IETF Date: October 2014 Mailbox: paul.hoffman@vpnc.org, jasnell@gmail.com Pages: 9 Characters: 12930 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-appsawg-json-merge-patch-07.txt URL: https://www.rfc-editor.org/rfc/rfc7386.txt This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target resource's content. This document is a product of the Applications Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Oct 13 17:43:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A691A033B for ; Mon, 13 Oct 2014 17:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, 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 w5_7TcCP3UaU for ; Mon, 13 Oct 2014 17:43:26 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id CE6081A0040 for ; Mon, 13 Oct 2014 17:43:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,714,1406556000"; d="scan'208";a="232471420" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 14 Oct 2014 11:29:52 +1100 X-IronPort-AV: E=McAfee;i="5600,1067,7590"; a="253113360" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcbni.tcif.telstra.com.au with ESMTP; 14 Oct 2014 11:43:21 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Tue, 14 Oct 2014 11:43:19 +1100 From: "Manger, James" To: "rfc-editor@rfc-editor.org" , "paul.hoffman@vpnc.org" , "jasnell@gmail.com" , "apps-discuss@ietf.org" Date: Tue, 14 Oct 2014 11:43:19 +1100 Thread-Topic: [apps-discuss] RFC 7386 on JSON Merge Patch -- ruined by format error Thread-Index: Ac/nPEH7B2IIaSusSLyWdVDhuhdXAgACSlGQ Message-ID: <255B9BB34FB7D647A506DC292726F6E127CF021CE0@WSMSG3153V.srv.dir.telstra.com> References: <20141013231812.8ABB8181C82@rfc-editor.org> In-Reply-To: <20141013231812.8ABB8181C82@rfc-editor.org> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/1irdGcV5EbdTCxtSMDvMnNmIx8s Subject: Re: [apps-discuss] RFC 7386 on JSON Merge Patch -- ruined by format error X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 00:43:28 -0000 It is great to see JSON Merge Patch become an RFC! But the indenting for the function in section 2 (which is the core of the w= hole doc) was been screwed up. It is no longer comprehensible! https://tool= s.ietf.org/html/rfc7386#section-2 It was correct in draft-ietf-appsawg-json-merge-patch-07. Indenting indicat= ed the scope of "if", "for", "else" clauses. define MergePatch(Target, Patch): if Patch is an Object: if Target is not an Object: Target =3D {} # Ignore the contents and set it to an empty Object for each Name/Value pair in Patch: if Value is null: if Name exists in Target: remove the Name/Value pair from Target else: Target[Name] =3D MergePatch(Target[Name], Value) return Target else: return Patch It is wrong in RFC 7386. You cannot tell what is in the "for" loop, for ins= tance. define MergePatch(Target, Patch): if Patch is an Object: if Target is not an Object: Target =3D {} # Ignore the contents and set it to an empty Object for each Name/Value pair in Patch: if Value is null: if Name exists in Target: remove the Name/Value pair from Target else: Target[Name] =3D MergePatch(Target[Name], Value) return Target else: return Patch -- James Manger -----Original Message----- From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of rfc-= editor@rfc-editor.org Sent: Tuesday, 14 October 2014 10:18 AM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: drafts-update-ref@iana.org; apps-discuss@ietf.org; rfc-editor@rfc-edito= r.org Subject: [apps-discuss] RFC 7386 on JSON Merge Patch A new Request for Comments is now available in online RFC libraries. =20 RFC 7386 Title: JSON Merge Patch=20 Author: P. Hoffman, J. Snell Status: Standards Track Stream: IETF Date: October 2014 Mailbox: paul.hoffman@vpnc.org,=20 jasnell@gmail.com Pages: 9 Characters: 12930 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-appsawg-json-merge-patch-07.txt URL: https://www.rfc-editor.org/rfc/rfc7386.txt This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target resource's content. This document is a product of the Applications Area Working Group Working G= roup 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 suggestion= s for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the= =20 standardization state and status of this protocol. Distribution of this=20 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 _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Mon Oct 13 23:11:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C0A1A6FA0 for ; Mon, 13 Oct 2014 23:11:15 -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 hvmvI5ZWpS2k for ; Mon, 13 Oct 2014 23:11:14 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C040B1A6F9F for ; Mon, 13 Oct 2014 23:11:13 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id w7so7405990lbi.8 for ; Mon, 13 Oct 2014 23:11:12 -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=GWPRFQvORVQqQGgSLLHhlGwECIkKKgd3XyPRqSDWvr0=; b=gZK2P74K5R8WfDdkJ7rA+7weUa+JCjPi2Uy/wcBzhk2xySklbv8b8SXUx0RkOQ9K+Q FuSHgVz+jdEhm00GB82ZmyQlgIBT/xL1I0FjpjzAjE9Dzdmc6rBnncSO0afozEKZpxur aGOdF8hK/WNRqZ8L9ROauhxHaXhkhJ4Thrp4qURGrqtxW9TCzifFmNXXXVJVgaqlMDEy jeanzPt1LoE6gxIqEqClsMGeuJjNvhFh1YiBlI1SOMAla3IZOWzRiPCg7LIVcc+f7H5M 4J9GfGCbmOT347OI9mv5FyWWkylY2og7gSohp+kV/i9WKRlLt8sCtBFHPzkINGujHU9g 9ewA== MIME-Version: 1.0 X-Received: by 10.112.63.70 with SMTP id e6mr759391lbs.93.1413267072027; Mon, 13 Oct 2014 23:11:12 -0700 (PDT) Received: by 10.25.215.217 with HTTP; Mon, 13 Oct 2014 23:11:11 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E127CF021CE0@WSMSG3153V.srv.dir.telstra.com> References: <20141013231812.8ABB8181C82@rfc-editor.org> <255B9BB34FB7D647A506DC292726F6E127CF021CE0@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 13 Oct 2014 23:11:11 -0700 Message-ID: From: Martin Thomson To: "Manger, James" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Yu7DwFvdMyqTeIS4YG0Jl27by-U Cc: "paul.hoffman@vpnc.org" , "apps-discuss@ietf.org" , "rfc-editor@rfc-editor.org" Subject: Re: [apps-discuss] RFC 7386 on JSON Merge Patch -- ruined by format error X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 06:11:16 -0000 On 13 October 2014 17:43, Manger, James wrote: > the indenting for the function in section 2 (which is the core of the whole doc) was been screwed up best argument against use of python I've seen From nobody Tue Oct 14 01:10:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D721A6FCB for ; Tue, 14 Oct 2014 01:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BymD5_LlIZQK for ; Tue, 14 Oct 2014 01:10:17 -0700 (PDT) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE2C1A6FCD for ; Tue, 14 Oct 2014 01:10:17 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1XdxBP-0000Fo-iW; Tue, 14 Oct 2014 09:10:15 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.atuin.ninebynine.org) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1XdxBP-00007x-7S; Tue, 14 Oct 2014 09:10:15 +0100 Message-ID: <543CDA93.5020101@ninebynine.org> Date: Tue, 14 Oct 2014 09:10:59 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sean Leonard , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <5429A68D.6030606@seantek.com> In-Reply-To: <5429A68D.6030606@seantek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/CujVeBdj3tnns9Y9zm1ButcGvco Subject: Re: [apps-discuss] "local convention" in draft-kerwin-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 08:10:23 -0000 Hi Sean, Something I make a lot of use of in code I've written over the past few years is using relative URI references that can be resolved with respect to either file: or http: base URIs. I often seem to find myself creating cross-linked resources in a local file system which are destined for web publication. Using Python, the problem of "/" vs "\" is largely resolved for me - Python allows "/" for file path construction, even on Windows. Non-US-ASCII characters can be problematic, but assuming UTF-8 filenames and applying %-escaping often seems to work. Windows device names often don't arise in this context, but when they do treating (say) "C:\file" as "file:///C:/file" often works, though the original looks to a URI resolver like a relative URI reference, which can cause problems. The high order bit of my comment here is to say that local resources and "Internet" resources are not disjoint classes - there is also some need for mapping between them. So the suggestion "do whatever at the endpoints, it doesn't affect the network" doesn't entirely work. And for my work, I absolutely do need to be able to parse a file: URI (often without code knowing it's actually a filename.) One thing that has not proven to be an issue for me is contextualization file file: URIs - i.e. URIs file file://computername/file - in my work, the context is implicitly the localhost (I sometimes resolve against file://localhost/) - that's part of what the file: scheme gives me. I'm not sure how well this can all sit with what you're proposing, but its a datum for your consideration. I'd love to see a regularization of the file: scheme that put my practices on a firmer foundation, but past attempts have floundered on the details. I'm sympathetic to the idea of focusing on the common cases and treating the rest as extensions (as someone here suggested) if that helps get an updated file: scheme specification through the gate. #g -- On 29/09/2014 19:35, Sean Leonard wrote: > Colleagues: > > We ought to step back for a moment and ask ourselves what exactly the goals are > of getting a common file URI scheme through the IETF process. > > Ultimately we are all here to promote "interoperability". There is a lot of > software out there that needs to identify local resources in the OS file system > in the same data type (URI) as Internet resources. The way to distinguish these > local resources in the URI way is--at a minimum--to tack on "file:". > > File system resources are normally addressed by the operating system's > convention. We can come up with all sorts of notations, but at the end of the > day the OS system call (POSIX open, Win32 CreateFile, etc.) is what matters. The > OS needs to be consistent with itself and with applications on it; it's also > important that two instances of the same OS (or OS families) agree on things, so > that applications and data written with that OS (family) in mind can work on > different machines. > > But from the perspective of Internet architecture, all those things are a "local > convention"--that magical escape that in IETF-speak means "do whatever at the > endpoints, it doesn't affect the network". draft-kerwin-file-scheme talks about > local conventions but the overall gist is trying to stuff local conventions into > a common format, and flailing about by addressing these disparate use cases > (mostly Windows, but some OpenVMS) that have cropped up. > > It is not surprising, by the way, that Windows causes difficulties while > Unix/POSIX is less problematic, since the URI convention of "/" for path > separators and "/" as the root path directly descends from Unix/POSIX (and from > FTP [RFC 959]). > > I would like to suggest a totally different approach: > 1. file: identifies local filesystem resources (this includes filesystem > resources accessible via network paths such as UNC, since the filesystem > facility of the OS accommodates them). > 2. # is the fragment. > 3. everything else (the RFC 3986 and productions) is a local > convention. > > The draft can still include all of the current content, but move it into > informative appendices. > > If an application encounters a file URI for a local filesystem resource, it > should deal with it using the local convention. If an application encounters a > file URI for some non-local filesystem resource, it should *leave it alone*. The > end. > > In other words: why bother parsing a file URI if you know it's not going to > refer to a resource that you can make use of? If you're on Ubuntu 14.04, why do > you care about interpreting a file: URI that's meant for Windows 7? The only > thing this does is invite security problems, because attackers will tell you > (via the network) to perform operations on local resources that they don't have > the authority to say anything about. > > Another issue is the matter of non-ASCII character encoding, which has always > been dicey. [POSIX] is very clear that a paths as a sequence of *bytes*, not > characters. Other than "/", , and the relative pathnames "." and "..", it's > anything-goes. The mapping between bytes and characters depends on the locale. > In Windows NT, the kernel treats pathnames as Unicode (specifically > UCS-2/UTF-16); translations are done in user-space. In Mac OS X, the HFS Plus > file system converts all file names to decomposed Unicode, i.e., Normalization > Form D [HFSPLUSREF]. > > It is kind of seen as a moral imperative in the IETF to use UTF-8 (and > Normalization Form C), possibly because of [BCP18] and [RFC5198]. But here, the > only thing common is diversity--and each operating system (vendor) has its own > good reasons for its individual decisions. Since file: URIs are always stored > *in context*, context (the operating system documentation, the LC_ALL > environment variable, the declared encoding of the text document, the identity > of the local machine, etc.) provides all the info that you need. Just say that > the file: URI (outside of the fragment component) encodes with local > conventions--which are provided by context--and be done with it. > > If you are taking things like file: URIs out of context...three suggestions: > > 1. Translate the file URI into the destination context. For example: if you are > in an HTML editor and you really want to reference , > but you are saving the HTML document in a workgroup share, change the reference > to , and ensure that D:\pics is shared as > \\mycomputername\pics with appropriate access. Better yet: upload the resource > to an Internet-accessible location such as , > which for purposes of Internet architecture, provides a more universal context. > > 2. Dereference the file URI and put whatever content you need into the context. > For example: in an HTML e-mail, don't use ; use > and put the cat pic in the e-mail per > [RFC2392] and [RFC2387]. > > 3. Don't do that. It doesn't make sense. > > Best regards, > > Sean > > [RFC959]: https://tools.ietf.org/html/rfc959 > [POSIX]: http://pubs.opengroup.org/onlinepubs/9699919799/ > [BCP18]: http://tools.ietf.org/html/bcp18 > [RFC5198]: http://tools.ietf.org/html/rfc5198 > [HFSPLUSREF]: https://developer.apple.com/library/mac/qa/qa1235/_index.html > [RFC2392]: http://tools.ietf.org/html/rfc2392 > [RFC2387]: http://tools.ietf.org/html/rfc2387 > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Tue Oct 14 01:26:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8023D1A6FDE for ; Tue, 14 Oct 2014 01:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AHAyQfhEpSm for ; Tue, 14 Oct 2014 01:25:52 -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 2F7661A6FDD for ; Tue, 14 Oct 2014 01:25:52 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1XdxQM-0000jg-bh; Tue, 14 Oct 2014 09:25:42 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.atuin.ninebynine.org) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1XdxQM-0000TW-7E; Tue, 14 Oct 2014 09:25:42 +0100 Message-ID: <543CDE33.4030402@ninebynine.org> Date: Tue, 14 Oct 2014 09:26:27 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John C Klensin , Sean Leonard , "Murray S. Kucherawy" , Ned Freed References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> <9AD273B04D7CB4B07CE8D1C5@JcK-HP8200.jck.com> In-Reply-To: <9AD273B04D7CB4B07CE8D1C5@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/u4qwwFGvI1_M83_DRAg9gbvAuY0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] IETF 91 scheduling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 08:25:57 -0000 John, all, One thing that *could* be associated with an archive media type is a fragment syntax for URIs to reference components within an archive... I think that possibility is new since the old days of being mainly email focused. (I'm wondering if this could dovetail with the file scheme work...) (FWIW, there's a URI scheme proposal out there called app: which also wades in these waters - http://www.w3.org/TR/app-uri/, and also a W3C community group interested in packaged content - http://www.w3.org/community/rosc/, and some activity in the W3C TAG - http://w3ctag.github.io/packaging-on-the-web/) #g -- On 30/09/2014 11:03, John C Klensin wrote: > > > --On Monday, September 29, 2014 14:46 -0700 Sean Leonard > wrote: > >> Topic: Archive TLMT >> ... >> Here are some of the issues to be considered, which I put on >> the proposed BoF agenda: Agenda >> Discuss proposal to make archive TLMT >> Identify use cases >> Identify types of archives and whether these types of archives >> should all go in, e.g.: archiving only, multi-function, >> software packaging, disk images, backup Identify formats in >> ... > > Hi. > > I had planned to sit this one out because I see some value in > the general idea and probably little harm. I also agree with > Ned that things have evolved in a way that probably makes this > reasonable and that there is little justification for trying to > invent a complex architectural process before adding one new > type. > > However, unless my memory is failing me, there is one historical > tidbit about which people should be aware. Ned wrote "There > used to be a strong reluctance to register media types for > archive formats". My recollection is that it was a bit more > than that, that archives (particularly of the zip and tar > persuasions) were explicitly discussed and believed to be > orthogonal to Content-type and Content-transfer-encoding, > inappropriate for top-level Content-types (now Media types) > unless we expected email clients to actually take some action on > them, e.g., by exploding them or having some other specific > action routines for them. That is where the analogy to > multipart/ (or even message/) breaks down a bit because we have > precisely that expectation of those top level aggregate and > potentially aggregate types. By contrast, archive/ would really > be an aggregate identifier for components that, at least with > the two or three most popular archive formats, do not have media > types except by naming convention. > > If the intent is merely to identify the content, rather than > expecting action and to create another top-level type that, like > application/ is expected to be opaque to the mail system, > perhaps we should be generalizing and considering "container/" > or, to borrow a note from X.400, even "FileTransfer/", rather > than thinking there is something extra-special about archives. > > On the other hand, there is something extra-special, which is > frequency of use, and things have changed a lot since > Content/Media types were first defined in the current contexts, > so this is just something to think about rather than a strong > alternate suggestion. > > john > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Tue Oct 14 02:52:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A041A7009 for ; Tue, 14 Oct 2014 02:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=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 wGucAXhJIRUJ for ; Tue, 14 Oct 2014 02:52:27 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C65E1A7007 for ; Tue, 14 Oct 2014 02:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=In-Reply-To:To:References:Date:Subject:Mime-Version:Message-Id:Content-Type:From; bh=EPB9umaTx1603MEHHTSUZ5uuUZ9J7MwZT39EjPi33bs=; b=AqghAmTllFQFmzja96Pm+9vLZBXD7Ch90HITle1+FK0dFD2y6GjnYKOuu9RPb+CXB/EjuEu7kAGOkgJT30NQJxyUCRo7t+XE1Duo8UtTiHcZfbzvkwPTIahOnBiAWA2WfrNwMqXknL/dlcq5u8Ei0FeanbnOZ0+6vlv4sRdKyOE=; Received: from [216.214.38.194] (port=9518 helo=[10.128.5.64]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XdymA-0006C3-OD for apps-discuss@ietf.org; Tue, 14 Oct 2014 02:52:26 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_402D5FC5-C74C-47CB-97CF-3CA7DD2540F3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <52E76DE8-76F6-4F97-9FA2-E7682116438B@standardstrack.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Tue, 14 Oct 2014 05:52:17 -0400 References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <5429A68D.6030606@seantek.com> <543CDA93.5020101@ninebynine.org> To: IETF Apps Discuss In-Reply-To: <543CDA93.5020101@ninebynine.org> X-Mailer: Apple Mail (2.1878.6) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/FAEloi6AwhXTkQLfpxC8QxkyRz4 Subject: Re: [apps-discuss] "local convention" in draft-kerwin-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 09:52:29 -0000 --Apple-Mail=_402D5FC5-C74C-47CB-97CF-3CA7DD2540F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Rather than trying to force fit new semantics on file:, is there any = reason not to create a new, different scheme, that does what people = want? Today=92s file: is pretty much a local matter. Perhaps there is justification for a =91nfile:=92 scheme, with a = network-normalized-but-local-OS access method? On Oct 14, 2014, at 4:10 AM, Graham Klyne wrote: > Hi Sean, >=20 > Something I make a lot of use of in code I've written over the past = few years is using relative URI references that can be resolved with = respect to either file: or http: base URIs. I often seem to find myself = creating cross-linked resources in a local file system which are = destined for web publication. >=20 > Using Python, the problem of "/" vs "\" is largely resolved for me - = Python allows "/" for file path construction, even on Windows. = Non-US-ASCII characters can be problematic, but assuming UTF-8 filenames = and applying %-escaping often seems to work. Windows device names often = don't arise in this context, but when they do treating (say) "C:\file" = as "file:///C:/file" often works, though the original looks to a URI = resolver like a relative URI reference, which can cause problems. >=20 > The high order bit of my comment here is to say that local resources = and "Internet" resources are not disjoint classes - there is also some = need for mapping between them. So the suggestion "do whatever at the = endpoints, it doesn't affect the network" doesn't entirely work. And = for my work, I absolutely do need to be able to parse a file: URI (often = without code knowing it's actually a filename.) >=20 > One thing that has not proven to be an issue for me is = contextualization file file: URIs - i.e. URIs file = file://computername/file - in my work, the context is implicitly the = localhost (I sometimes resolve against file://localhost/) - that's part = of what the file: scheme gives me. >=20 > I'm not sure how well this can all sit with what you're proposing, but = its a datum for your consideration. >=20 > I'd love to see a regularization of the file: scheme that put my = practices on a firmer foundation, but past attempts have floundered on = the details. I'm sympathetic to the idea of focusing on the common = cases and treating the rest as extensions (as someone here suggested) if = that helps get an updated file: scheme specification through the gate. >=20 > #g > -- >=20 > On 29/09/2014 19:35, Sean Leonard wrote: >> Colleagues: >>=20 >> We ought to step back for a moment and ask ourselves what exactly the = goals are >> of getting a common file URI scheme through the IETF process. >>=20 >> Ultimately we are all here to promote "interoperability". There is a = lot of >> software out there that needs to identify local resources in the OS = file system >> in the same data type (URI) as Internet resources. The way to = distinguish these >> local resources in the URI way is--at a minimum--to tack on "file:". >>=20 >> File system resources are normally addressed by the operating = system's >> convention. We can come up with all sorts of notations, but at the = end of the >> day the OS system call (POSIX open, Win32 CreateFile, etc.) is what = matters. The >> OS needs to be consistent with itself and with applications on it; = it's also >> important that two instances of the same OS (or OS families) agree on = things, so >> that applications and data written with that OS (family) in mind can = work on >> different machines. >>=20 >> But from the perspective of Internet architecture, all those things = are a "local >> convention"--that magical escape that in IETF-speak means "do = whatever at the >> endpoints, it doesn't affect the network". draft-kerwin-file-scheme = talks about >> local conventions but the overall gist is trying to stuff local = conventions into >> a common format, and flailing about by addressing these disparate use = cases >> (mostly Windows, but some OpenVMS) that have cropped up. >>=20 >> It is not surprising, by the way, that Windows causes difficulties = while >> Unix/POSIX is less problematic, since the URI convention of "/" for = path >> separators and "/" as the root path directly descends from Unix/POSIX = (and from >> FTP [RFC 959]). >>=20 >> I would like to suggest a totally different approach: >> 1. file: identifies local filesystem resources (this includes = filesystem >> resources accessible via network paths such as UNC, since the = filesystem >> facility of the OS accommodates them). >> 2. # is the fragment. >> 3. everything else (the RFC 3986 and productions) = is a local >> convention. >>=20 >> The draft can still include all of the current content, but move it = into >> informative appendices. >>=20 >> If an application encounters a file URI for a local filesystem = resource, it >> should deal with it using the local convention. If an application = encounters a >> file URI for some non-local filesystem resource, it should *leave it = alone*. The >> end. >>=20 >> In other words: why bother parsing a file URI if you know it's not = going to >> refer to a resource that you can make use of? If you're on Ubuntu = 14.04, why do >> you care about interpreting a file: URI that's meant for Windows 7? = The only >> thing this does is invite security problems, because attackers will = tell you >> (via the network) to perform operations on local resources that they = don't have >> the authority to say anything about. >>=20 >> Another issue is the matter of non-ASCII character encoding, which = has always >> been dicey. [POSIX] is very clear that a paths as a sequence of = *bytes*, not >> characters. Other than "/", , and the relative pathnames "." and = "..", it's >> anything-goes. The mapping between bytes and characters depends on = the locale. >> In Windows NT, the kernel treats pathnames as Unicode (specifically >> UCS-2/UTF-16); translations are done in user-space. In Mac OS X, the = HFS Plus >> file system converts all file names to decomposed Unicode, i.e., = Normalization >> Form D [HFSPLUSREF]. >>=20 >> It is kind of seen as a moral imperative in the IETF to use UTF-8 = (and >> Normalization Form C), possibly because of [BCP18] and [RFC5198]. But = here, the >> only thing common is diversity--and each operating system (vendor) = has its own >> good reasons for its individual decisions. Since file: URIs are = always stored >> *in context*, context (the operating system documentation, the LC_ALL >> environment variable, the declared encoding of the text document, the = identity >> of the local machine, etc.) provides all the info that you need. Just = say that >> the file: URI (outside of the fragment component) encodes with local >> conventions--which are provided by context--and be done with it. >>=20 >> If you are taking things like file: URIs out of context...three = suggestions: >>=20 >> 1. Translate the file URI into the destination context. For example: = if you are >> in an HTML editor and you really want to reference = , >> but you are saving the HTML document in a workgroup share, change the = reference >> to , and ensure that D:\pics = is shared as >> \\mycomputername\pics with appropriate access. Better yet: upload the = resource >> to an Internet-accessible location such as = , >> which for purposes of Internet architecture, provides a more = universal context. >>=20 >> 2. Dereference the file URI and put whatever content you need into = the context. >> For example: in an HTML e-mail, don't use ; use >> and put the cat pic in the = e-mail per >> [RFC2392] and [RFC2387]. >>=20 >> 3. Don't do that. It doesn't make sense. >>=20 >> Best regards, >>=20 >> Sean >>=20 >> [RFC959]: https://tools.ietf.org/html/rfc959 >> [POSIX]: http://pubs.opengroup.org/onlinepubs/9699919799/ >> [BCP18]: http://tools.ietf.org/html/bcp18 >> [RFC5198]: http://tools.ietf.org/html/rfc5198 >> [HFSPLUSREF]: = https://developer.apple.com/library/mac/qa/qa1235/_index.html >> [RFC2392]: http://tools.ietf.org/html/rfc2392 >> [RFC2387]: http://tools.ietf.org/html/rfc2387 >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_402D5FC5-C74C-47CB-97CF-3CA7DD2540F3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJUPPJRAAoJEDY/T2tCIPW3DloP/Re3LdLGOcNZm/n1VgR0ALCz tMhygHrKidKDbMOpaL4jcLQAy10XbK8Bwo6LC4QXGU2xY3eglcD9y2bawVQbF7mn B+sSPvyFUaegNwCwW0xfiqK5CunS6ufu+In4bDkoY0oIrxLcyv6fUc5tK2Ev1d7P tbdftuUeOkbxt3+6F+cUz9cfhr7qfT5vIvOkX7ans//06I9ITS74Wm2S6SQ4DHPX OeAlq06TjmoCHdD7rmx8sZPC2ZfmS/9oMb+T88tisq0t9k60UF1fED0WMM4c4TI3 IVWfr8G5YN0PSiyl2cdWtFmJDW3ShEm/NT65tDFMtshHKffQw7GO2a1PfF+fQ8uJ 1yMDfKCQaxGEZo7Wzsv23MroSA+t4YXRwubXUfUHP66JZSJZxkzbZhdkd8dCCQBt +SUq35Pu7JHg3J9W7/dOBBYftihCy+3iQWby0fwzvdvOVaBnXRngm0beReVYTZwf 35OpzfsIFj5KL9vd2IwtSROv6xHNu93y7BN/BTVctxAXbBoTmDOoTm/XjzzTWUsV LxUUiV7N5mat2J9NkvmEQs5ZDxN+2pO6oTjluNUllQo3etnfAYy73YzQJFQu6W2a NWuOreEBohI8Yt4M1Z/IW6XSzlVbqh0rkTEy9g0xDS5CqxcJdH80K4Ch1xaHWzZB 8sxQD2OL58YV6rW97DCu =jDKw -----END PGP SIGNATURE----- --Apple-Mail=_402D5FC5-C74C-47CB-97CF-3CA7DD2540F3-- From nobody Tue Oct 14 04:42:33 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302401A6FA7 for ; Tue, 14 Oct 2014 04:42:33 -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 0Yaf5Jz00_i9 for ; Tue, 14 Oct 2014 04:42:30 -0700 (PDT) Received: from relay14.mail.ox.ac.uk (relay14.mail.ox.ac.uk [163.1.2.162]) by ietfa.amsl.com (Postfix) with ESMTP id 6538C1A86F3 for ; Tue, 14 Oct 2014 04:42:30 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay14.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Xe0Un-00077U-l6; Tue, 14 Oct 2014 12:42:29 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.atuin.ninebynine.org) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Xe0Un-0006Ag-6k; Tue, 14 Oct 2014 12:42:29 +0100 Message-ID: <543D0C51.8070005@ninebynine.org> Date: Tue, 14 Oct 2014 12:43:13 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Eric Burger , IETF Apps Discuss References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <5429A68D.6030606@seantek.com> <543CDA93.5020101@ninebynine.org> <52E76DE8-76F6-4F97-9FA2-E7682116438B@standardstrack.com> In-Reply-To: <52E76DE8-76F6-4F97-9FA2-E7682116438B@standardstrack.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/NoNTU9t0XriaIVNbdze7TPlyHp8 Subject: Re: [apps-discuss] "local convention" in draft-kerwin-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 11:42:33 -0000 On 14/10/2014 10:52, Eric Burger wrote: > Rather than trying to force fit new semantics on file:, is there any reason not to create a new, different scheme, that does what people want? I don't think anyone is trying to force fit new semantics, just reflect existing semantics (and syntax) more consistently. I think use of file: is pretty deeply embedded in a number of existing applications, so IMO making a replacement would be more confusing than helpful. > Today’s file: is pretty much a local matter. The point I was making in my comments is that it's not just a local matter, but that file: also mediates some interactions between local storage and web access. #g -- > > Perhaps there is justification for a ‘nfile:’ scheme, with a network-normalized-but-local-OS access method? > > On Oct 14, 2014, at 4:10 AM, Graham Klyne wrote: > >> Hi Sean, >> >> Something I make a lot of use of in code I've written over the past few years is using relative URI references that can be resolved with respect to either file: or http: base URIs. I often seem to find myself creating cross-linked resources in a local file system which are destined for web publication. >> >> Using Python, the problem of "/" vs "\" is largely resolved for me - Python allows "/" for file path construction, even on Windows. Non-US-ASCII characters can be problematic, but assuming UTF-8 filenames and applying %-escaping often seems to work. Windows device names often don't arise in this context, but when they do treating (say) "C:\file" as "file:///C:/file" often works, though the original looks to a URI resolver like a relative URI reference, which can cause problems. >> >> The high order bit of my comment here is to say that local resources and "Internet" resources are not disjoint classes - there is also some need for mapping between them. So the suggestion "do whatever at the endpoints, it doesn't affect the network" doesn't entirely work. And for my work, I absolutely do need to be able to parse a file: URI (often without code knowing it's actually a filename.) >> >> One thing that has not proven to be an issue for me is contextualization file file: URIs - i.e. URIs file file://computername/file - in my work, the context is implicitly the localhost (I sometimes resolve against file://localhost/) - that's part of what the file: scheme gives me. >> >> I'm not sure how well this can all sit with what you're proposing, but its a datum for your consideration. >> >> I'd love to see a regularization of the file: scheme that put my practices on a firmer foundation, but past attempts have floundered on the details. I'm sympathetic to the idea of focusing on the common cases and treating the rest as extensions (as someone here suggested) if that helps get an updated file: scheme specification through the gate. >> >> #g >> -- >> >> On 29/09/2014 19:35, Sean Leonard wrote: >>> Colleagues: >>> >>> We ought to step back for a moment and ask ourselves what exactly the goals are >>> of getting a common file URI scheme through the IETF process. >>> >>> Ultimately we are all here to promote "interoperability". There is a lot of >>> software out there that needs to identify local resources in the OS file system >>> in the same data type (URI) as Internet resources. The way to distinguish these >>> local resources in the URI way is--at a minimum--to tack on "file:". >>> >>> File system resources are normally addressed by the operating system's >>> convention. We can come up with all sorts of notations, but at the end of the >>> day the OS system call (POSIX open, Win32 CreateFile, etc.) is what matters. The >>> OS needs to be consistent with itself and with applications on it; it's also >>> important that two instances of the same OS (or OS families) agree on things, so >>> that applications and data written with that OS (family) in mind can work on >>> different machines. >>> >>> But from the perspective of Internet architecture, all those things are a "local >>> convention"--that magical escape that in IETF-speak means "do whatever at the >>> endpoints, it doesn't affect the network". draft-kerwin-file-scheme talks about >>> local conventions but the overall gist is trying to stuff local conventions into >>> a common format, and flailing about by addressing these disparate use cases >>> (mostly Windows, but some OpenVMS) that have cropped up. >>> >>> It is not surprising, by the way, that Windows causes difficulties while >>> Unix/POSIX is less problematic, since the URI convention of "/" for path >>> separators and "/" as the root path directly descends from Unix/POSIX (and from >>> FTP [RFC 959]). >>> >>> I would like to suggest a totally different approach: >>> 1. file: identifies local filesystem resources (this includes filesystem >>> resources accessible via network paths such as UNC, since the filesystem >>> facility of the OS accommodates them). >>> 2. # is the fragment. >>> 3. everything else (the RFC 3986 and productions) is a local >>> convention. >>> >>> The draft can still include all of the current content, but move it into >>> informative appendices. >>> >>> If an application encounters a file URI for a local filesystem resource, it >>> should deal with it using the local convention. If an application encounters a >>> file URI for some non-local filesystem resource, it should *leave it alone*. The >>> end. >>> >>> In other words: why bother parsing a file URI if you know it's not going to >>> refer to a resource that you can make use of? If you're on Ubuntu 14.04, why do >>> you care about interpreting a file: URI that's meant for Windows 7? The only >>> thing this does is invite security problems, because attackers will tell you >>> (via the network) to perform operations on local resources that they don't have >>> the authority to say anything about. >>> >>> Another issue is the matter of non-ASCII character encoding, which has always >>> been dicey. [POSIX] is very clear that a paths as a sequence of *bytes*, not >>> characters. Other than "/", , and the relative pathnames "." and "..", it's >>> anything-goes. The mapping between bytes and characters depends on the locale. >>> In Windows NT, the kernel treats pathnames as Unicode (specifically >>> UCS-2/UTF-16); translations are done in user-space. In Mac OS X, the HFS Plus >>> file system converts all file names to decomposed Unicode, i.e., Normalization >>> Form D [HFSPLUSREF]. >>> >>> It is kind of seen as a moral imperative in the IETF to use UTF-8 (and >>> Normalization Form C), possibly because of [BCP18] and [RFC5198]. But here, the >>> only thing common is diversity--and each operating system (vendor) has its own >>> good reasons for its individual decisions. Since file: URIs are always stored >>> *in context*, context (the operating system documentation, the LC_ALL >>> environment variable, the declared encoding of the text document, the identity >>> of the local machine, etc.) provides all the info that you need. Just say that >>> the file: URI (outside of the fragment component) encodes with local >>> conventions--which are provided by context--and be done with it. >>> >>> If you are taking things like file: URIs out of context...three suggestions: >>> >>> 1. Translate the file URI into the destination context. For example: if you are >>> in an HTML editor and you really want to reference , >>> but you are saving the HTML document in a workgroup share, change the reference >>> to , and ensure that D:\pics is shared as >>> \\mycomputername\pics with appropriate access. Better yet: upload the resource >>> to an Internet-accessible location such as , >>> which for purposes of Internet architecture, provides a more universal context. >>> >>> 2. Dereference the file URI and put whatever content you need into the context. >>> For example: in an HTML e-mail, don't use ; use >>> and put the cat pic in the e-mail per >>> [RFC2392] and [RFC2387]. >>> >>> 3. Don't do that. It doesn't make sense. >>> >>> Best regards, >>> >>> Sean >>> >>> [RFC959]: https://tools.ietf.org/html/rfc959 >>> [POSIX]: http://pubs.opengroup.org/onlinepubs/9699919799/ >>> [BCP18]: http://tools.ietf.org/html/bcp18 >>> [RFC5198]: http://tools.ietf.org/html/rfc5198 >>> [HFSPLUSREF]: https://developer.apple.com/library/mac/qa/qa1235/_index.html >>> [RFC2392]: http://tools.ietf.org/html/rfc2392 >>> [RFC2387]: http://tools.ietf.org/html/rfc2387 >>> >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Tue Oct 14 04:48:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588671A86FF for ; Tue, 14 Oct 2014 04:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 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, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xpE496eL-5S for ; Tue, 14 Oct 2014 04:48:23 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D6D21A86FA for ; Tue, 14 Oct 2014 04:48:23 -0700 (PDT) Received: by mail-oi0-f49.google.com with SMTP id a3so15834467oib.8 for ; Tue, 14 Oct 2014 04:48:23 -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=w2quRU8K1EIPggTeFGcIgMloZkYkoJaubeMMCxuJwlI=; b=Y5gSnWPvzGbDCcCrDuisuAqa/yTHI6IWhfkNrmpTXwvGT5Mix+Fztitu6KdMEjuPwH 9tm8Ur7JwzXe4zkuToMyKx4aD1WyPnz3zpBnLVl85+XQ9PfBY1IxMIMSReRFOx8RmLmu d59cj+rBSYki3E0A/tegm+w4tt0zWOsERHJ50= 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=w2quRU8K1EIPggTeFGcIgMloZkYkoJaubeMMCxuJwlI=; b=mBoi6ZociokJTIaBYrURRBHgLk2LRTkn7rtd7LigoL0Nd1Oqp0KlfbSMqNHrUwVV6D GhjYW+WXRk/yCiU5xjuEJH4TBTYEyvokhYgLKB8MbQDxGZ8AXJpLu3xU100KudZ9bteo /2cOMK884slt152prW9x5jGzwmc3KGThibgOoWn0AU+fvGQNFRrXFb8zT7uG3A6U27zP QbKSXb77x6OmqZRQwpQ+q2oOEtz/sPeMGthpVWOPZAjG0xb7MUZoRdOo80stO+jRpXdd jOrGab1iFNcEKIvR9iIRALn9ZhsQeDwwFtKe7uPYZtOAnirW5c0BGbdXqcQRPZQhoFqN YKkA== X-Gm-Message-State: ALoCoQnJ7izc5vFV6kIjX0VwL8igR2dUHsguPhns8kjzjMugekULXB23UOyUbLlGCVFIWdu5LEkk MIME-Version: 1.0 X-Received: by 10.202.97.86 with SMTP id v83mr4066182oib.38.1413287302814; Tue, 14 Oct 2014 04:48:22 -0700 (PDT) Received: by 10.60.150.238 with HTTP; Tue, 14 Oct 2014 04:48:22 -0700 (PDT) In-Reply-To: <543CDA93.5020101@ninebynine.org> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <5429A68D.6030606@seantek.com> <543CDA93.5020101@ninebynine.org> Date: Tue, 14 Oct 2014 12:48:22 +0100 Message-ID: From: Dave Cridland To: Graham Klyne Content-Type: multipart/alternative; boundary=001a113d3fb8a675c30505609774 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mni293x_n9upwjFPIQrTYpQx-tA Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "local convention" in draft-kerwin-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 11:48:24 -0000 --001a113d3fb8a675c30505609774 Content-Type: text/plain; charset=UTF-8 On 14 October 2014 09:10, Graham Klyne wrote: > Using Python, the problem of "/" vs "\" is largely resolved for me - > Python allows "/" for file path construction, even on Windows. Windows, since NT I think, allows "/" as a directory separator, even though the canonical one is "\". More info is here: http://superuser.com/questions/176388/why-does-windows-use-backslashes-for-paths-and-unix-forward-slashes But the TL;DR is that this isn't a Python thing. Even if a particular OS allows "/" in file or directory names, the solution is straightforward - encode them in URIs and (optionally) replace the separator. IMAP already has to do this at times. Dave. --001a113d3fb8a675c30505609774 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 4 October 2014 09:10, Graham Klyne <gk@ninebynine.org> wrote= :
Using Python, the problem of=C2=A0 "/" vs &= quot;\" is largely resolved for me - Python allows "/" for f= ile path construction, even on Windows.

Win= dows, since NT I think, allows "/" as a directory separator, even= though the canonical one is "\".

More i= nfo is here:


But t= he TL;DR is that this isn't a Python thing. Even if a particular OS all= ows "/" in file or directory names, the solution is straightforwa= rd - encode them in URIs and (optionally) replace the separator. IMAP alrea= dy has to do this at times.

Dave.
--001a113d3fb8a675c30505609774-- From nobody Tue Oct 14 07:15:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C801A87B2 for ; Tue, 14 Oct 2014 07:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.386 X-Spam-Level: X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyqS1biywYJ2 for ; Tue, 14 Oct 2014 07:15:24 -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 73D3B1A87C6 for ; Tue, 14 Oct 2014 07:15:24 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xe2sb-0008Gf-5K; Tue, 14 Oct 2014 10:15:13 -0400 Date: Tue, 14 Oct 2014 10:15:12 -0400 From: John C Klensin To: Graham Klyne Message-ID: In-Reply-To: <543CDE33.4030402@ninebynine.org> References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> <9AD273B04D7CB4B07CE8D1C5@JcK-HP8200.jck.com> <543CDE33.4030402@ninebynine.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/uleygjUQqYJZ6P521WjxRpgORj4 Cc: Ned Freed , IETF Apps Discuss Subject: [apps-discuss] Archive media type (was: Re: IETF 91 scheduling) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 14:15:27 -0000 (note change of subject; should have been done earlier) --On Tuesday, 14 October, 2014 09:26 +0100 Graham Klyne wrote: > John, > all, > > One thing that *could* be associated with an archive media > type is a fragment syntax for URIs to reference components > within an archive... I think that possibility is new since the > old days of being mainly email focused. Probably true. Doesn't seem to have much, if anything, to do with my comments below. At the risk of replaying some of the URNBIS discussions, one could also imagine queries to find things in an archive by content rather than by name, etc. Whether that would be a good idea or not is an open question on which I really don't have much opinion. > (I'm wondering if this could dovetail with the file scheme > work...) > > (FWIW, there's a URI scheme proposal out there called app: > which also wades in these waters - > http://www.w3.org/TR/app-uri/, and also a W3C community group > interested in packaged content - > http://www.w3.org/community/rosc/, and some activity in the > W3C TAG - http://w3ctag.github.io/packaging-on-the-web/) ack john > On 30/09/2014 11:03, John C Klensin wrote: >> >> >> --On Monday, September 29, 2014 14:46 -0700 Sean Leonard >> wrote: >> >>> Topic: Archive TLMT >>> ... >>> Here are some of the issues to be considered, which I put on >>> the proposed BoF agenda: Agenda >>> Discuss proposal to make archive TLMT >>> Identify use cases >>> Identify types of archives and whether these types of >>> archives should all go in, e.g.: archiving only, >>> multi-function, software packaging, disk images, backup >>> Identify formats in ... >> >> Hi. >> >> I had planned to sit this one out because I see some value in >> the general idea and probably little harm. I also agree with >> Ned that things have evolved in a way that probably makes this >> reasonable and that there is little justification for trying >> to invent a complex architectural process before adding one >> new type. >> >> However, unless my memory is failing me, there is one >> historical tidbit about which people should be aware. Ned >> wrote "There used to be a strong reluctance to register media >> types for archive formats". My recollection is that it was >> a bit more than that, that archives (particularly of the zip >> and tar persuasions) were explicitly discussed and believed >> to be orthogonal to Content-type and >> Content-transfer-encoding, inappropriate for top-level >> Content-types (now Media types) unless we expected email >> clients to actually take some action on them, e.g., by >> exploding them or having some other specific action routines >> for them. That is where the analogy to multipart/ (or even >> message/) breaks down a bit because we have precisely that >> expectation of those top level aggregate and potentially >> aggregate types. By contrast, archive/ would really be an >> aggregate identifier for components that, at least with the >> two or three most popular archive formats, do not have media >> types except by naming convention. >> >> If the intent is merely to identify the content, rather than >> expecting action and to create another top-level type that, >> like application/ is expected to be opaque to the mail system, >> perhaps we should be generalizing and considering "container/" >> or, to borrow a note from X.400, even "FileTransfer/", rather >> than thinking there is something extra-special about archives. >> >> On the other hand, there is something extra-special, which is >> frequency of use, and things have changed a lot since >> Content/Media types were first defined in the current >> contexts, so this is just something to think about rather >> than a strong alternate suggestion. >> >> john >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> From nobody Tue Oct 14 08:43:20 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3D11A88F7 for ; Tue, 14 Oct 2014 08:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDA0Gy1Ifp_k for ; Tue, 14 Oct 2014 08:43:16 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2C50F1A87B0 for ; Tue, 14 Oct 2014 08:43:16 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PDQCNJADR40012R6@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 14 Oct 2014 08:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1413301093; bh=yUTd1FW7QewYtHqXxqL8tUK/OBn1tsGDRT/bp+++M1I=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=hKOxr2Tq2KhUEBxGFQEsdbujSlQ6+oek/A4pDbW0zjbfoPd/nJlm5+WJSJal5V0sA c6LvGsJfK/YmsNdhUP3QvZpQ9fL0/y/fBhmtc7c1EAqMZ+g9cPpflD+7BoVlIgzM09 3vglK9teYNODJoDCYeE6xfZgJPjAwAAcMvMvKBUI= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PDOX7AHQU800005K@mauve.mrochek.com>; Tue, 14 Oct 2014 08:38:09 -0700 (PDT) Message-id: <01PDQCNHFSIM00005K@mauve.mrochek.com> Date: Tue, 14 Oct 2014 08:37:31 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 14 Oct 2014 09:26:27 +0100" <543CDE33.4030402@ninebynine.org> References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> <9AD273B04D7CB4B07CE8D1C5@JcK-HP8200.jck.com> <543CDE33.4030402@ninebynine.org> To: Graham Klyne Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QEr_ngQ1wZiip64xK8jDcyTQIKI Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] IETF 91 scheduling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 15:43:18 -0000 Very good point. Do you think it would make sense to define a generic syntax (which of course could be overridden in specific cases)? Ned > John, > all, > One thing that *could* be associated with an archive media type is a fragment > syntax for URIs to reference components within an archive... I think that > possibility is new since the old days of being mainly email focused. > (I'm wondering if this could dovetail with the file scheme work...) > (FWIW, there's a URI scheme proposal out there called app: which also wades in > these waters - http://www.w3.org/TR/app-uri/, and also a W3C community group > interested in packaged content - http://www.w3.org/community/rosc/, and some > activity in the W3C TAG - http://w3ctag.github.io/packaging-on-the-web/) > #g > -- > On 30/09/2014 11:03, John C Klensin wrote: > > > > > > --On Monday, September 29, 2014 14:46 -0700 Sean Leonard > > wrote: > > > >> Topic: Archive TLMT > >> ... > >> Here are some of the issues to be considered, which I put on > >> the proposed BoF agenda: Agenda > >> Discuss proposal to make archive TLMT > >> Identify use cases > >> Identify types of archives and whether these types of archives > >> should all go in, e.g.: archiving only, multi-function, > >> software packaging, disk images, backup Identify formats in > >> ... > > > > Hi. > > > > I had planned to sit this one out because I see some value in > > the general idea and probably little harm. I also agree with > > Ned that things have evolved in a way that probably makes this > > reasonable and that there is little justification for trying to > > invent a complex architectural process before adding one new > > type. > > > > However, unless my memory is failing me, there is one historical > > tidbit about which people should be aware. Ned wrote "There > > used to be a strong reluctance to register media types for > > archive formats". My recollection is that it was a bit more > > than that, that archives (particularly of the zip and tar > > persuasions) were explicitly discussed and believed to be > > orthogonal to Content-type and Content-transfer-encoding, > > inappropriate for top-level Content-types (now Media types) > > unless we expected email clients to actually take some action on > > them, e.g., by exploding them or having some other specific > > action routines for them. That is where the analogy to > > multipart/ (or even message/) breaks down a bit because we have > > precisely that expectation of those top level aggregate and > > potentially aggregate types. By contrast, archive/ would really > > be an aggregate identifier for components that, at least with > > the two or three most popular archive formats, do not have media > > types except by naming convention. > > > > If the intent is merely to identify the content, rather than > > expecting action and to create another top-level type that, like > > application/ is expected to be opaque to the mail system, > > perhaps we should be generalizing and considering "container/" > > or, to borrow a note from X.400, even "FileTransfer/", rather > > than thinking there is something extra-special about archives. > > > > On the other hand, there is something extra-special, which is > > frequency of use, and things have changed a lot since > > Content/Media types were first defined in the current contexts, > > so this is just something to think about rather than a strong > > alternate suggestion. > > > > john > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Tue Oct 14 09:35:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A441A8A9B; Tue, 14 Oct 2014 09:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORu6bKNjYCFg; Tue, 14 Oct 2014 09:35:46 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 185C51A8986; Tue, 14 Oct 2014 09:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9EGZgoX023579; Tue, 14 Oct 2014 18:35:42 +0200 (CEST) Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 12EFCF46; Tue, 14 Oct 2014 18:35:41 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <805301AA-4E04-410D-A451-7A2175792CB0@tzi.org> Date: Tue, 14 Oct 2014 18:35:40 +0200 X-Mao-Original-Outgoing-Id: 434997340.7554-038588822f6bf661768115a91d96d379 Content-Transfer-Encoding: quoted-printable Message-Id: <7CEA60C1-BC9D-43BE-84B4-128D08F111F5@tzi.org> References: <805301AA-4E04-410D-A451-7A2175792CB0@tzi.org> To: apps-discuss@ietf.org, draft-ietf-jose-json-web-algorithms.all@tools.ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/V_T390-2eTSevHvxwVUmDIM18JA Cc: iesg@ietf.org, jose@ietf.org Subject: Re: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-algorithms-33 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 16:35:47 -0000 Here is a quick re-check of my review against -34. I=E2=80=99m not sure any of the necessary fixes made it into -34. Gr=C3=BC=C3=9Fe, Carsten On 02 Oct 2014, at 09:22, Carsten Bormann wrote: > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see > = =E2=80=8Bhttp://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDir= ectorate > ). >=20 > 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. >=20 > Document: draft-ietf-jose-json-web-algorithms-33 > Title: JSON Web Algorithms (JWA) > Reviewer: Carsten Bormann > Review Date: 2014-10-02 > IESG Telechat date: 2014-10-02 >=20 > Summary: This draft is ready for publication as a standards track RFC, > with a few nits corrected. >=20 > However, some additional editorial improvements might improve the > security outcome when it is referenced by application developers. >=20 > Major issues: None. >=20 > Minor issues: >=20 > 5.2: > Add a reference that defines PKCS #7 padding. No change. (Note that there is a reference behind =E2=80=9CPKCS #7 padding=E2=80=9D, = it just happens to define CBC and not PKCS #7). > 5.2.2.2 > Does "the PKCS #7 padding is removed" entail checking all of its = bytes? No change. > 6.2.1 > Is the intention that the sentence containing "point compression is = not > supported" also applies to any future registered value of "crv"? > A similar comment applies to other specifications in 6.2.1.x, e.g., > the reference to SEC1 representation to x and y. No change. > 6.2.1.1 > =C2=BBAdditional "crv" values MAY be > used, provided they are understood by implementations using that > Elliptic Curve key.=C2=AB > How are conflicts between such implementation defined values and > future registered values handled? No change. And so on. > 6.3.2: > The MAY accept partially overrides the MUST include? > Is the latter thus really a SHOULD? >=20 > 7.1: > It is interesting that a mere registration (vetted only by a DE) can > change the IETF consensus base specifications by making an algorithm > "Required". >=20 > 8. > I am unable to find a "security considerations" section in NIST SP = 800-38A. > 800-38D at least has a "practical considerations" section, is that = meant? > (Etc., I haven't checked all the references.) > In general, I believe a security considerations section is most useful > where it provides more directed guidance instead of saying the > equivalent of "here is a textbook". >=20 > 8.7 is not clear: is it NOT RECOMMENDED to reuse an entire set of key > material (including IV), or to reuse any part of it? >=20 >=20 > Nits/editorial comments: >=20 > 6.3.2.x: > The constant repetition of =C2=BBIt is represented as the base64url = encoding of > the value's unsigned big endian representation as an octet sequence. > The octet sequence MUST utilize the minimum number of octets to > represent the value.=C2=AB almost ensures that an implementer will = stop > reading the details (well, I did, and I did not write a program to > verify the same phrase is used everywhere; if any parameter were using = a > different encoding, that sure would be missed). Why not define > another abstraction like base64url and use this? >=20 > 6.2.3.1: This is not a positive integer? 6.2.3.x mentions this = otherwise. >=20 > 7.1.1 > =C2=BBExample description=C2=AB is not a useful example for an = "Algorithm Description". > (Same comment for 7.x.1.) >=20 > 8.3: > s/because it/because it is/ >=20 > [sec1] > (Given the date, this is probably referencing V2.0 of this spec.) >=20 > [usascii] > The reference to ANSI X3.4:1986 should probably be replaced by a > reference to RFC 20. There is little reason to reference a somewhat > hard to obtain external document ($60!) when we have an RFC about the > same subject. >=20 > (Tables in Appendix A need some formatting.) >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 From nobody Wed Oct 15 00:13:19 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5451A038F; Wed, 15 Oct 2014 00:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1QRMG7QILed; Wed, 15 Oct 2014 00:13:16 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:723]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D0091A03A2; Wed, 15 Oct 2014 00:13:16 -0700 (PDT) Received: from BN3PR0301CA0047.namprd03.prod.outlook.com (25.160.152.143) by BY1PR0301MB1206.namprd03.prod.outlook.com (25.161.203.155) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 15 Oct 2014 07:12:52 +0000 Received: from BN1AFFO11FD058.protection.gbl (2a01:111:f400:7c10::155) by BN3PR0301CA0047.outlook.office365.com (2a01:111:e400:401e::15) with Microsoft SMTP Server (TLS) id 15.0.1049.19 via Frontend Transport; Wed, 15 Oct 2014 07:12:52 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD058.mail.protection.outlook.com (10.58.53.73) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Wed, 15 Oct 2014 07:12:52 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.193]) with mapi id 14.03.0210.003; Wed, 15 Oct 2014 07:12:28 +0000 From: Mike Jones To: Ray Polk , Claudio Allocchio , "apps-discuss@ietf.org" , Barry Leiba Thread-Topic: AppsDir reviews of draft-ietf-jose-json-web-signature-32 Thread-Index: AQHP3gq8ooW0Hna0tkS7mc30NBGUc5wwzZ4Q Date: Wed, 15 Oct 2014 07:12:27 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB0F8CD@TK5EX14MBXC286.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(43784003)(15374003)(51704005)(199003)(21056001)(86612001)(84676001)(64706001)(107046002)(66066001)(20776003)(47776003)(31966008)(230783001)(50466002)(95666004)(26826002)(104016003)(85306004)(99396003)(50986999)(120916001)(33656002)(76482002)(106116001)(54356999)(76176999)(87936001)(85852003)(2656002)(46406003)(97736003)(85806002)(23726002)(55846006)(81156004)(86362001)(106466001)(92566001)(80022003)(46102003)(77096002)(19580395003)(15975445006)(19580405001)(97756001)(92726001)(44976005)(4396001)(6806004)(68736004)(69596002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1206; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1206; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0365C0E14B Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/RaEksx9Z-bK7-_uG2LizOYAlt5c Cc: "jose@ietf.org" , "iesg@ietf.org" , "draft-ietf-jose-json-web-signature.all@tools.ietf.org" Subject: Re: [apps-discuss] AppsDir reviews of draft-ietf-jose-json-web-signature-32 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 07:13:18 -0000 Thanks for your review Ray. My apologies for not responding to it until no= w. It had gotten sorted into a mail folder and I hadn't seen it until Kath= leen brought it to my attention. Responses are inline below... > Date: Wed, 1 Oct 2014 20:21:42 -0700 (PDT) > From: Ray Polk > To: Claudio.Allocchio@garr.it > Cc: Michael.Jones@microsoft.com > Subject: Re: URGENT AppsDir reviews of the JOSE document set - asigned dr= afts >=20 > Hi Claudio (and Mike), >=20 > I've finished reviewing draft-ietf-jose-json-web-signature-32 for AppsDir= . I could > not find another AppsDir review on the jose mailing list to use as a mode= l. So, I > don't know to whom I should send my review, the format it should take, or= the > severity of the issues to include (include Nits? include minor, non-bloc= king > issues?). >=20 > For now, I'll include all of my notes. If you can advise me of proper > format/protocol/procedure, I'll craft an email to the jose list. >=20 > Major: None >=20 > Minor: >=20 > 4.1.1. & 4.1.2. The links to Section 4.1 and Section 5.1 of JWA are incor= rect. > They link to JWE instead of JWA. >=20 > In 4.1.1. the link is: > https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-32#sectio= n-4.1 > ...but it should be: > https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-33#sectio= n-4.1 >=20 > In 4.1.2. the link is: > https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-32#sectio= n-5.1 > ...but it should be: > https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-33#sectio= n-5 > (JWA doesn't seem to have an anchor for 5.1) These link URLs are actually created by the IETF tools - not in the draft i= tself. (You'll see "Html markup produced by rfcmarkup 1.109, available fro= m https://tools.ietf.org/tools/rfcmarkup/" at the bottom of the drafts.) I= 'm not sure who to file a bug on this with. > 9. saying "separated by X period ('.') characters" is ambiguous: >=20 > JWSs have three segments separated by two period ('.') characters. > This means: segment..segment..segment >=20 > JWEs have five segments separated by four period ('.') characters. > This means: segment....segment....segment....segment....segment >=20 > Say instead: ___s have X segments. Each segment is separated from the n= ext by > a single period ('.') for a total of X-1 delimiting periods ('.'). Thanks - I'll plan to make this correction. > Nit: >=20 > 3.2 change "of these eight values," to "...values:", remove commas and th= e > 'and', change "...with the six" to a complete sentence. The "values" correction is already present in the -34 draft. I agree that = not trying to include the list in a sentence structure would make it easier= to read. > 3.3 remove the and from "...to produce the JWE Encrypted Key and" and the > period from the next bullet OK > 4.1.3. fix comma splicing in: "This Header Parameter MUST be integrity > protected, and therefore MUST occur only within the JWE Protected Header, > when used." For example, "When used, this Header Parameter MUST be > integrity protected; therefore, it MUST occur only within the JWE Protect= ed > Header." OK > Sections 4.1.4. through 4.1.10. are almost entirely redundant. Combine t= hem > like so: >=20 > The following parameters have the same meaning, syntax, and processing ru= les > as those defined in JWS, except that the certificate referenced by the th= umbprint > contains the public key to which the JWE was encrypted; this can be used = to > determine the private key needed to decrypt the JWE. >=20 > jku defined in Section 4.1.2. of [JWS] > jwk defined in Section 4.1.3. of [JWS] > etc. I understand this suggestion but disagree because there's value to implemen= ters and other readers to having each of the header parameters listed as a = section header in the table of contents. It makes it easy to see all of th= em in one place. Combining them would lose this benefit. Thanks again, -- Mike From nobody Wed Oct 15 01:52:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B061A19E7; Wed, 15 Oct 2014 01:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaiHAsoSitoq; Wed, 15 Oct 2014 01:52:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0740.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::740]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55091A0673; Wed, 15 Oct 2014 01:52:24 -0700 (PDT) Received: from CO2PR03CA0020.namprd03.prod.outlook.com (10.141.194.147) by BLUPR03MB391.namprd03.prod.outlook.com (10.141.78.21) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Wed, 15 Oct 2014 08:52:01 +0000 Received: from BN1AFFO11FD022.protection.gbl (2a01:111:f400:7c10::166) by CO2PR03CA0020.outlook.office365.com (2a01:111:e400:1414::19) with Microsoft SMTP Server (TLS) id 15.0.1054.13 via Frontend Transport; Wed, 15 Oct 2014 08:52:00 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD022.mail.protection.outlook.com (10.58.52.82) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Wed, 15 Oct 2014 08:52:00 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0210.003; Wed, 15 Oct 2014 08:51:21 +0000 From: Mike Jones To: Carsten Bormann , "apps-discuss@ietf.org" , "draft-ietf-jose-json-web-algorithms.all@tools.ietf.org" , Matt Miller Thread-Topic: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-algorithms-33 Thread-Index: Ac/oVSxcdPW/TNiPTRiX1p7gtScCIg== Date: Wed, 15 Oct 2014 08:51:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB0FB8B@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(51704005)(189002)(43784003)(199003)(377454003)(243025005)(377424004)(13464003)(54356999)(86612001)(44976005)(99396003)(69596002)(2656002)(85806002)(50466002)(84676001)(15975445006)(106466001)(87936001)(107046002)(15395725005)(85852003)(77096002)(50986999)(95666004)(81156004)(31966008)(2201001)(86362001)(92726001)(92566001)(104016003)(33656002)(26826002)(66066001)(97736003)(47776003)(230783001)(55846006)(20776003)(64706001)(85306004)(76482002)(80022003)(19580405001)(6806004)(19580395003)(23676002)(68736004)(120916001)(4396001)(46102003)(21056001)(15202345003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB391; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB391; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0365C0E14B Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ORYbOp3btrp_obIrvZYt6bt7gaU Cc: "iesg@ietf.org" , "jose@ietf.org" Subject: Re: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-algorithms-33 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 08:52:28 -0000 VGhhbmtzIGZvciB5b3VyIHJldmlldywgQ2Fyc3Rlbi4gIEkgYXBvbG9naXplIGZvciBub3QgcmVz cG9uZGluZyB0byBpdCB1bnRpbCBub3cuICBJdCBoYWQgZ290dGVuIHNvcnRlZCBpbnRvIGEgZm9s ZGVyIGFuZCBJIHdhc24ndCBhd2FyZSBvZiBpdCB1bnRpbCBLYXRobGVlbiBicm91Z2h0IGl0IHRv IG15IGF0dGVudGlvbi4gIFJlcGxpZXMgYXJlIGlubGluZSBiZWxvdy4uLg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGFwcHMtZGlzY3VzcyBbbWFpbHRvOmFwcHMtZGlz Y3Vzcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gQ2Fyc3RlbiBCb3JtYW5uDQo+ IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDAyLCAyMDE0IDEyOjIyIEFNDQo+IFRvOiBhcHBzLWRp c2N1c3NAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi0NCj4gYWxnb3JpdGhtcy5h bGxAdG9vbHMuaWV0Zi5vcmcNCj4gQ2M6IGllc2dAaWV0Zi5vcmc7IGpvc2VAaWV0Zi5vcmcNCj4g U3ViamVjdDogW2FwcHMtZGlzY3Vzc10gQXBwc2RpciByZXZpZXcgZm9yIGRyYWZ0LWlldGYtam9z ZS1qc29uLXdlYi1hbGdvcml0aG1zLQ0KPiAzMw0KPiANCj4gSSBoYXZlIGJlZW4gc2VsZWN0ZWQg YXMgdGhlIEFwcGxpY2F0aW9ucyBBcmVhIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRy YWZ0DQo+IChmb3IgYmFja2dyb3VuZCBvbiBhcHBzZGlyLCBwbGVhc2Ugc2VlIA0KPiBodHRwOi8v dHJhYy50b29scy5pZXRmLm9yZy9hcmVhL2FwcC90cmFjL3dpa2kvQXBwbGljYXRpb25zQXJlYURp cmVjdG9yYXRlDQo+ICkuDQo+IA0KPiBQbGVhc2UgcmVzb2x2ZSB0aGVzZSBjb21tZW50cyBhbG9u ZyB3aXRoIGFueSBvdGhlciBMYXN0IENhbGwgY29tbWVudHMgeW91DQo+IG1heSByZWNlaXZlLiBQ bGVhc2Ugd2FpdCBmb3IgZGlyZWN0aW9uIGZyb20geW91ciBkb2N1bWVudCBzaGVwaGVyZCBvciBB RA0KPiBiZWZvcmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCj4gDQo+IERv Y3VtZW50OiAgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMtMzMNCj4gVGl0bGU6 IEpTT04gV2ViIEFsZ29yaXRobXMgKEpXQSkNCj4gUmV2aWV3ZXI6IENhcnN0ZW4gQm9ybWFubg0K PiBSZXZpZXcgRGF0ZTogMjAxNC0xMC0wMg0KPiBJRVNHIFRlbGVjaGF0IGRhdGU6IDIwMTQtMTAt MDINCj4gDQo+IFN1bW1hcnk6IFRoaXMgZHJhZnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIGFz IGEgc3RhbmRhcmRzIHRyYWNrIFJGQywgd2l0aCBhIGZldw0KPiBuaXRzIGNvcnJlY3RlZC4NCj4g DQo+IEhvd2V2ZXIsIHNvbWUgYWRkaXRpb25hbCBlZGl0b3JpYWwgaW1wcm92ZW1lbnRzIG1pZ2h0 IGltcHJvdmUgdGhlIHNlY3VyaXR5DQo+IG91dGNvbWUgd2hlbiBpdCBpcyByZWZlcmVuY2VkIGJ5 IGFwcGxpY2F0aW9uIGRldmVsb3BlcnMuDQo+IA0KPiBNYWpvciBpc3N1ZXM6IE5vbmUuDQo+IA0K PiBNaW5vciBpc3N1ZXM6DQo+IA0KPiA1LjI6DQo+IEFkZCBhIHJlZmVyZW5jZSB0aGF0IGRlZmlu ZXMgUEtDUyAjNyBwYWRkaW5nLg0KDQpJJ2xsIHBsYW4gb24gYWRkaW5nIGEgcmVmZXJlbmNlIHRv IFJGQyAyMzE1IGZvciB0aGlzLg0KDQo+IDUuMi4yLjINCj4gRG9lcyAidGhlIFBLQ1MgIzcgcGFk ZGluZyBpcyByZW1vdmVkIiBlbnRhaWwgY2hlY2tpbmcgYWxsIG9mIGl0cyBieXRlcz8NCg0KU2hv dWxkIHRoaXMgYmUgY2hhbmdlZCB0byAidGhlIFBLQ1MgIzcgcGFkZGluZyBieXRlcyBhcmUgY2hl Y2tlZCBhbmQgdGhlbiByZW1vdmVkIj8NCg0KPiA2LjIuMQ0KPiBJcyB0aGUgaW50ZW50aW9uIHRo YXQgdGhlIHNlbnRlbmNlIGNvbnRhaW5pbmcgInBvaW50IGNvbXByZXNzaW9uIGlzIG5vdA0KPiBz dXBwb3J0ZWQiIGFsc28gYXBwbGllcyB0byBhbnkgZnV0dXJlIHJlZ2lzdGVyZWQgdmFsdWUgb2Yg ImNydiI/DQo+IEEgc2ltaWxhciBjb21tZW50IGFwcGxpZXMgdG8gb3RoZXIgc3BlY2lmaWNhdGlv bnMgaW4gNi4yLjEueCwgZS5nLiwgdGhlIHJlZmVyZW5jZQ0KPiB0byBTRUMxIHJlcHJlc2VudGF0 aW9uIHRvIHggYW5kIHkuDQoNCkl0IHdvdWxkIGFwcGx5IHRvIGFueSBmdXR1cmUgY3VydmVzIHJl Z2lzdGVyZWQgdGhhdCB1c2UgdGhlICJ4IiwgInkiIHBvaW50IHJlcHJlc2VudGF0aW9uLiAgT3Ro ZXJzIGNvdWxkIGRlZmluZSBuZXcga2V5IHR5cGVzIHRoYXQgdXNlIGEgZGlmZmVyZW50IHJlcHJl c2VudGF0aW9uIG9yIHdlIGNvdWxkIHJlZmluZSB0aGUgZGVmaW5pdGlvbiBvZiAia3R5IjoiRUMi IHRvIG1ha2UgdGhlIHJlcHJlc2VudGF0aW9uIHNwZWNpZmljIHRvIHRoZSAiY3J2IiB2YWx1ZS4N Cg0KQSBkaXNjdXNzaW9uIGhhcHBlbmVkIG9uIHRoZSBKT1NFIHRocmVhZCAiSldLIEVsbGlwdGlj IEN1cnZlIGtleSByZXByZXNlbnRhdGlvbnMgYW5kIG5ldyBjdXJ2ZXMiLiAgVGhlIGNvbmNsdXNp b24gc3VnZ2VzdGVkIGJ5IFJpY2hhcmQgQmFybmVzIGFuZCBzZWNvbmRlZCBieSBTdGVwaGVuIEZh cnJlbGwgd2FzIHRvIHRhYmxlIGRlZmluaW5nIGFueSBuZXcga2V5IHJlcHJlc2VudGF0aW9ucyBm b3IgbmV3IGVsbGlwdGljIGN1cnZlcyB1bnRpbCB0aGUgQ1JGRyByZWNvbW1lbmRhdGlvbnMgdG8g VExTIGhhdmUgYmVlbiBtYWRlLiAgVGhhdCBlbmRlZCB0aGUgZGlzY3Vzc2lvbiBmb3Igbm93Lg0K DQo+IDYuMi4xLjENCj4gwrtBZGRpdGlvbmFsICJjcnYiIHZhbHVlcyBNQVkgYmUNCj4gdXNlZCwg cHJvdmlkZWQgdGhleSBhcmUgdW5kZXJzdG9vZCBieSBpbXBsZW1lbnRhdGlvbnMgdXNpbmcgdGhh dCBFbGxpcHRpYyBDdXJ2ZQ0KPiBrZXkuwqsgSG93IGFyZSBjb25mbGljdHMgYmV0d2VlbiBzdWNo IGltcGxlbWVudGF0aW9uIGRlZmluZWQgdmFsdWVzIGFuZCBmdXR1cmUNCj4gcmVnaXN0ZXJlZCB2 YWx1ZXMgaGFuZGxlZD8NCg0KQ29uZmxpY3RzIGFyZSBhdm9pZGVkIHVzaW5nIHRoZSBJQU5BIEpT T04gV2ViIEtleSBFbGxpcHRpYyBDdXJ2ZSByZWdpc3RyeSBkZWZpbmVkIGluIFNlY3Rpb24gNy42 Lg0KDQo+IDYuMy4yOg0KPiBUaGUgTUFZIGFjY2VwdCBwYXJ0aWFsbHkgb3ZlcnJpZGVzIHRoZSBN VVNUIGluY2x1ZGU/DQo+IElzIHRoZSBsYXR0ZXIgdGh1cyByZWFsbHkgYSBTSE9VTEQ/DQoNCiJk IiBpcyBSRVFVSVJFRC4gIFRoZSBvdGhlcnMgU0hPVUxEIGJlIGluY2x1ZGVkLCBhbmQgaWYgYW55 IGFyZSBpbmNsdWRlZCwgdGhlIG90aGVycyBNVVNUIGJlIGluY2x1ZGVkLiAgVGhvc2UgYXJlIHJl cXVpcmVtZW50cyBvbiBwcm9kdWNlcnMuDQoNCkNvbnN1bWVycyBtYXkgY2hvb3NlIHRvIGFjY2Vw dCBrZXlzIHRoYXQgZG9uJ3QgaW5jbHVkZSBhbGwgdGhlIENSVCBwYXJhbWV0ZXJzLiAgR2l2ZW4g dGhhdCB0aGV5IGNhbiBiZSBjb21wdXRlZCBmcm9tICJuIiwgImUiLCBhbmQgImQiIGFuZCBzb21l dGltZXMgdGhleSdyZSBub3QgYXZhaWxhYmxlLCBhIHByZXZpb3VzIHJldmlld2VyIGhhZCBhc2tl ZCB0aGlzIGxhbmd1YWdlIGFib3V0IGNvbnN1bWVycyB0byBiZSBpbmNsdWRlZC4gIEl0J3MgYSBj YXNlIG9mICJCZSBjb25zZXJ2YXRpdmUgaW4gd2hhdCB5b3Ugc2VuZCwgYmUgbGliZXJhbCBpbiB3 aGF0IHlvdSBhY2NlcHQiLiAgSXQncyBub3QgY2xlYXIgdG8gbWUgdGhhdCB0aGVyZSdzIGFueSB2 YWx1ZSBpbiByZWxheGluZyB0aGUgcmVxdWlyZW1lbnRzIG9uIHByb2R1Y2Vycy4NCg0KPiA3LjE6 DQo+IEl0IGlzIGludGVyZXN0aW5nIHRoYXQgYSBtZXJlIHJlZ2lzdHJhdGlvbiAodmV0dGVkIG9u bHkgYnkgYSBERSkgY2FuIGNoYW5nZSB0aGUNCj4gSUVURiBjb25zZW5zdXMgYmFzZSBzcGVjaWZp Y2F0aW9ucyBieSBtYWtpbmcgYW4gYWxnb3JpdGhtICJSZXF1aXJlZCIuDQoNCkl0IGlzIGV4cGVj dGVkIHRoYXQgdGhlIGRlc2lnbmF0ZWQgZXhwZXJ0cyB3aWxsIGJlIGFwcG9pbnRlZCwgaW4gcGFy dCwgZm9yIHRoZWlyIGNyeXB0b2dyYXBoaWMgZXhwZXJ0aXNlLg0KDQo+IDguDQo+IEkgYW0gdW5h YmxlIHRvIGZpbmQgYSAic2VjdXJpdHkgY29uc2lkZXJhdGlvbnMiIHNlY3Rpb24gaW4gTklTVCBT UCA4MDAtMzhBLg0KPiA4MDAtMzhEIGF0IGxlYXN0IGhhcyBhICJwcmFjdGljYWwgY29uc2lkZXJh dGlvbnMiIHNlY3Rpb24sIGlzIHRoYXQgbWVhbnQ/DQo+IChFdGMuLCBJIGhhdmVuJ3QgY2hlY2tl ZCBhbGwgdGhlIHJlZmVyZW5jZXMuKSBJbiBnZW5lcmFsLCBJIGJlbGlldmUgYSBzZWN1cml0eQ0K PiBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGlzIG1vc3QgdXNlZnVsIHdoZXJlIGl0IHByb3ZpZGVz IG1vcmUgZGlyZWN0ZWQgZ3VpZGFuY2UNCj4gaW5zdGVhZCBvZiBzYXlpbmcgdGhlIGVxdWl2YWxl bnQgb2YgImhlcmUgaXMgYSB0ZXh0Ym9vayIuDQoNClRoZXJlIGFyZSAxNCBzdWJzZWN0aW9ucyB3 aXRoIGRpcmVjdGVkIGd1aWRhbmNlLCBwbHVzIG1vcmUgaW4gdGhlIEpXUywgSldFLCBhbmQgSldL IHNwZWNpZmljYXRpb25zLiAgSWYgdGhlcmUgaXMgb3RoZXIgZGlyZWN0ZWQgZ3VpZGFuY2UgeW91 J2QgbGlrZSB0byBzZWUgYWRkZWQsIHBsZWFzZSBzdXBwbHkgcHJvcG9zZWQgdGV4dC4NCg0KSGF2 aW5nIHNraW1tZWQgdGhyb3VnaCBpdCwgSSBhZ3JlZSB0aGF0IDgwMC0zMEEgZG9lc24ndCBjb250 YWluIGNsZWFyIGVub3VnaCBzZWN1cml0eSBndWlkYW5jZSB0byBtZXJpdCBpbmNsdXNpb24gaW4g dGhlIGxpc3QuICBJJ2xsIHJlbW92ZSBpdC4gIElmIHRoZXJlIGFyZSBvdGhlciBzcGVjaWZpY2F0 aW9ucyB0aGF0IHlvdSdkIGxpa2UgdG8gc2VlIGFkZGVkIG9yIHJlbW92ZWQsIHBsZWFzZSBsZXQg bWUga25vdy4NCg0KPiA4LjcgaXMgbm90IGNsZWFyOiBpcyBpdCBOT1QgUkVDT01NRU5ERUQgdG8g cmV1c2UgYW4gZW50aXJlIHNldCBvZiBrZXkgbWF0ZXJpYWwNCj4gKGluY2x1ZGluZyBJViksIG9y IHRvIHJldXNlIGFueSBwYXJ0IG9mIGl0Pw0KDQpJIGFncmVlIHRoYXQgdGhpcyBpcyBhbWJpZ3Vv dXMsIGFzIHdvcmRlZC4gIEl0cyBhZHZpY2Ugc2VlbXMgdG8gYmUgc28gYnJvYWQgYXMgdG8gYmUg aW1wcmFjdGljYWwsIGFzIG5ldmVyIHJldXNpbmcgYSBrZXkgbWVhbnMgdGhhdCBhIG5ldyBrZXkg d291bGQgaGF2ZSB0byBiZSByZWRpc3RyaWJ1dGVkIGZvciBlYWNoIGVuY3J5cHRpb24sIHdoaWNo IHRoZW4gcmVxdWlyZXMgYSBrZXkgdG8gdXNlIGZvciB0aGUgZGlzdHJpYnV0aW9uLi4uICBUaGlz IHRleHQgY2FtZSBmcm9tIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1pbGxlci1q b3NlLWp3ZS1wcm90ZWN0ZWQtandrLTAyI3NlY3Rpb24tOC4xLCB3aGljaCB3YXMgaW5jb3Jwb3Jh dGVkIGludG8gdGhlIGRvY3VtZW50IGFmdGVyIGEgd29ya2luZyBncm91cCBkZWNpc2lvbiB0byBk byBzby4gIE1hdHQgTWlsbGVyLCB5b3Ugd2VyZSB0aGUgYXV0aG9yIG9mIHRoaXMgdGV4dC4gIENv dWxkIHlvdSBjbGFyaWZ5IHdoYXQgdGhlIGludGVudCB3YXM/ICBUaGFua3MuDQoNCj4gTml0cy9l ZGl0b3JpYWwgY29tbWVudHM6DQo+IA0KPiA2LjMuMi54Og0KPiBUaGUgY29uc3RhbnQgcmVwZXRp dGlvbiBvZiDCu0l0IGlzIHJlcHJlc2VudGVkIGFzIHRoZSBiYXNlNjR1cmwgZW5jb2Rpbmcgb2Yg dGhlDQo+IHZhbHVlJ3MgdW5zaWduZWQgYmlnIGVuZGlhbiByZXByZXNlbnRhdGlvbiBhcyBhbiBv Y3RldCBzZXF1ZW5jZS4NCj4gVGhlIG9jdGV0IHNlcXVlbmNlIE1VU1QgdXRpbGl6ZSB0aGUgbWlu aW11bSBudW1iZXIgb2Ygb2N0ZXRzIHRvIHJlcHJlc2VudA0KPiB0aGUgdmFsdWUuwqsgYWxtb3N0 IGVuc3VyZXMgdGhhdCBhbiBpbXBsZW1lbnRlciB3aWxsIHN0b3AgcmVhZGluZyB0aGUgZGV0YWls cw0KPiAod2VsbCwgSSBkaWQsIGFuZCBJIGRpZCBub3Qgd3JpdGUgYSBwcm9ncmFtIHRvIHZlcmlm eSB0aGUgc2FtZSBwaHJhc2UgaXMgdXNlZA0KPiBldmVyeXdoZXJlOyBpZiBhbnkgcGFyYW1ldGVy IHdlcmUgdXNpbmcgYSBkaWZmZXJlbnQgZW5jb2RpbmcsIHRoYXQgc3VyZSB3b3VsZA0KPiBiZSBt aXNzZWQpLiAgV2h5IG5vdCBkZWZpbmUgYW5vdGhlciBhYnN0cmFjdGlvbiBsaWtlIGJhc2U2NHVy bCBhbmQgdXNlIHRoaXM/DQoNCkkgZGlkIGp1c3QgdmVyaWZ5IHRoYXQgdGhleSBhcmUgYWxsIGNv bnNpc3RlbnQuICBZZXMsIGlmIHlvdSdyZSByZWFkaW5nIHRoZSBzcGVjIGxpbmVhcmx5IEknbSBz dXJlIGl0IGZlZWxzIHJlcGV0aXRpdmUsIGJ1dCBpZiB5b3UncmUgYW4gaW1wbGVtZW50ZXIgZ29p bmcgc3RyYWlnaHQgdG8gYSBkZWZpbml0aW9uIHRvIGltcGxlbWVudCBpdCwgaGF2aW5nIGEgY29t cGxldGUgZGVzY3JpcHRpb24gYWxsIGluIG9uZSBwbGFjZSBpcyB2YWx1YWJsZS4gIEkgdW5kZXJz dGFuZCB5b3VyIHJlcXVlc3QgYnV0IGl0J3Mgbm90IGNsZWFyIHRvIG1lIHRoYXQgdGhpcyByaXNl cyB0byB0aGUgbGV2ZWwgdGhhdCBhIHNlcGFyYXRlIGRlZmluaXRpb24gdGhhdCB0aGUgZGV2ZWxv cGVyIHRoZW4gaGFzIHRvIGdvIGZpbmQgaXMgd2FycmFudGVkLg0KDQo+IDYuMi4zLjE6IFRoaXMg aXMgbm90IGEgcG9zaXRpdmUgaW50ZWdlcj8gIDYuMi4zLnggbWVudGlvbnMgdGhpcyBvdGhlcndp c2UuDQoNCkkgbWF5IG5vdCB1bmRlcnN0YW5kIHRoaXMgcmVtYXJrLiAgSSdtIGd1ZXNzaW5nIHlv dSdyZSByZWZlcnJpbmcgdG8gNi4zLjIuMSBhbmQgdGhlIGZhY3QgdGhhdCB0aGUgZGVzY3JpcHRp b24gaW5jbHVkZXMgdGhlIHdvcmQgInVuc2lnbmVkIi4gIFRoaXMgaXMgdGhlcmUgdG8gbWFrZSBp dCBjbGVhciB0aGF0IG5vIHNpZ24gYml0IHdpbGwgYmUgcHJlc2VudCBpbiB0aGUgcmVwcmVzZW50 YXRpb24gLSB3aGljaCBpcyBlc3BlY2lhbGx5IGltcG9ydGFudCBzaW5jZSB0aGUgaGlnaC1vcmRl ciBiaXQgaXMgYWx3YXlzIHNldCBmb3IgIm4iIGFuZCAiZCIgZm9yIGNvcnJlY3RseSBnZW5lcmF0 ZWQga2V5cy4NCg0KPiA3LjEuMQ0KPiDCu0V4YW1wbGUgZGVzY3JpcHRpb27CqyBpcyBub3QgYSB1 c2VmdWwgZXhhbXBsZSBmb3IgYW4gIkFsZ29yaXRobSBEZXNjcmlwdGlvbiIuDQo+IChTYW1lIGNv bW1lbnQgZm9yIDcueC4xLikNCg0KU2VlIHRoZSBhY3R1YWwgcmVnaXN0cmF0aW9ucyBpbiBTZWN0 aW9uIDcuMS4yIGZvciBtb3JlIHVzZWZ1bCBleGFtcGxlcy4NCg0KPiA4LjM6DQo+IHMvYmVjYXVz ZSBpdC9iZWNhdXNlIGl0IGlzLw0KDQpHb29kIGNhdGNoDQoNCj4gW3NlYzFdDQo+IChHaXZlbiB0 aGUgZGF0ZSwgdGhpcyBpcyBwcm9iYWJseSByZWZlcmVuY2luZyBWMi4wIG9mIHRoaXMgc3BlYy4p DQoNCkhtbW0gLSB0aGUgdmVyc2lvbiBJIGhhdmUgY2FjaGVkIGxvY2FsbHkgY2FtZSBmcm9tIGh0 dHA6Ly93d3cuc2VjZy5vcmcvY29sbGF0ZXJhbC9zZWMxX2ZpbmFsLnBkZiBhbmQgaXMgZGF0ZWQg U2VwdGVtYmVyIDIwLCAyMDAwLiAgQnV0IHRoZSBzaXRlIGFwcGVhcnMgdG8gYmUgZG93biBhdCBw cmVzZW50LiAgVGhlIHZlcnNpb24gcmVmZXJlbmNlZCBieSBXaWtpcGVkaWEgYXQgaHR0cDovL3d3 dy5zZWNnLm9yZy9kb3dubG9hZC9haWQtMzg1L3NlYzFfZmluYWwucGRmIGlzIG1pc3NpbmcgdG9v LiBodHRwOi8vc2VjZy5vcmcvZG93bmxvYWQvYWlkLTc4MC9zZWMxLXYyLnBkZiBpcyBtaXNzaW5n IHRvby4gIENhbiB5b3UgcG9pbnQgbWUgdG8gYSBnb29kIGxpbms/DQoNClJGQyA1OTE1IGluY2x1 ZGVzIHRoaXMgcmVmZXJlbmNlOg0KDQogICBbU0VDRzFdICAgIFN0YW5kYXJkcyBmb3IgRWZmaWNp ZW50IENyeXB0b2dyYXBoeSBHcm91cCAoU0VDRyksICJTRUMgMToNCiAgICAgICAgICAgICAgRWxs aXB0aWMgQ3VydmUgQ3J5cHRvZ3JhcGh5IiwgVmVyc2lvbiAyLjAsIE1heSAyMDA5Lg0KDQpXb3Jz dCBjb21lcyB0byB3b3JzdCwgSSdsbCBlaXRoZXIgcmVmZXJlbmNlIHRoYXQgb3IgZXhwbGljaXRs eSByZWZlcmVuY2UgdGhlIDEuMCB2ZXJzaW9uLiAgQnV0IGlmIEknbSBnb2luZyB0byByZWZlcmVu Y2UgdGhlIDIuMCB2ZXJzaW9uLCBJJ2QgbGlrZSB0byBiZSBhYmxlIHRvIHJlYWQgYSBjb3B5IHNv IHRoYXQgSSBjYW4gdmVyaWZ5IHRoYXQgdGhlIHdheSB3ZSdyZSB1c2luZyBpdCBpcyBjb25zaXN0 ZW50IHdpdGggdGhlIGFjdHVhbCBzcGVjLCBpbmNsdWRpbmcgdGhlIHNlY3Rpb24gbnVtYmVycy4N Cg0KPiBbdXNhc2NpaV0NCj4gVGhlIHJlZmVyZW5jZSB0byBBTlNJIFgzLjQ6MTk4NiBzaG91bGQg cHJvYmFibHkgYmUgcmVwbGFjZWQgYnkgYSByZWZlcmVuY2UgdG8NCj4gUkZDIDIwLiAgVGhlcmUg aXMgbGl0dGxlIHJlYXNvbiB0byByZWZlcmVuY2UgYSBzb21ld2hhdCBoYXJkIHRvIG9idGFpbiBl eHRlcm5hbA0KPiBkb2N1bWVudCAoJDYwISkgd2hlbiB3ZSBoYXZlIGFuIFJGQyBhYm91dCB0aGUg c2FtZSBzdWJqZWN0Lg0KDQpPSw0KDQo+IChUYWJsZXMgaW4gQXBwZW5kaXggQSBuZWVkIHNvbWUg Zm9ybWF0dGluZy4pDQoNCkFncmVlZC4gIEl0J3Mgb24gbXkgdG8tZG8gbGlzdC4gIEppbSBTY2hh YWQgcmVjZW50bHkgdG9sZCBtZSB0byAiQWRkIGEgd2lkdGggYXR0cmlidXRlIHRvIHRoZSB0dGNv bCB3aXRoIGVpdGhlciAiZGlnaXRzIiAoZm9yIGZpeGVkIHdpZHRoKSBvciAiZGlnaXRzJSIgKGZv ciBwZXJjZW50IHdpZHRoKSB0byB0aGUgY29sdW1uIGluIHF1ZXN0aW9uIi4gIEkgcGxhbiB0byBn aXZlIGl0IGEgdHJ5Lg0KDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IGFwcHMtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCj4gYXBwcy1kaXNjdXNzQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNj dXNzDQoNCgkJCQlUaGFua3MgYWdhaW4sDQoJCQkJLS0gTWlrZQ0KDQo= From nobody Wed Oct 15 02:55:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B811A1A09; Wed, 15 Oct 2014 02:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZImZP2GwHzZ; Wed, 15 Oct 2014 02:55:02 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAB701A017A; Wed, 15 Oct 2014 02:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9F9sqDg011709; Wed, 15 Oct 2014 11:54:52 +0200 (CEST) Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6BC4A454; Wed, 15 Oct 2014 11:54:51 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BB0FB8B@TK5EX14MBXC286.redmond.corp.microsoft.com> Date: Wed, 15 Oct 2014 11:54:50 +0200 X-Mao-Original-Outgoing-Id: 435059690.215576-4340ed5a8f9a8e839addc9341a9a568d Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B16804296739439BB0FB8B@TK5EX14MBXC286.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/N-OVErdfahXdMwQPsBk3KlABQ0I Cc: "draft-ietf-jose-json-web-algorithms.all@tools.ietf.org" , "jose@ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-algorithms-33 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 09:55:04 -0000 Hi Mike, thanks for getting to this review =97 I don=92t envy you for this = herculean job. A few more comments/clarifications inline below. Gr=FC=DFe, Carsten On 15 Oct 2014, at 10:51, Mike Jones = wrote: > Thanks for your review, Carsten. I apologize for not responding to it = until now. It had gotten sorted into a folder and I wasn't aware of it = until Kathleen brought it to my attention. Replies are inline below... >=20 >> -----Original Message----- >> From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf = Of >> Carsten Bormann >> Sent: Thursday, October 02, 2014 12:22 AM >> To: apps-discuss@ietf.org; draft-ietf-jose-json-web- >> algorithms.all@tools.ietf.org >> Cc: iesg@ietf.org; jose@ietf.org >> Subject: [apps-discuss] Appsdir review for = draft-ietf-jose-json-web-algorithms- >> 33 >>=20 >> I have been selected as the Applications Area Directorate reviewer = for this draft >> (for background on appsdir, please see=20 >> = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate >> ). >>=20 >> 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. >>=20 >> Document: draft-ietf-jose-json-web-algorithms-33 >> Title: JSON Web Algorithms (JWA) >> Reviewer: Carsten Bormann >> Review Date: 2014-10-02 >> IESG Telechat date: 2014-10-02 >>=20 >> Summary: This draft is ready for publication as a standards track = RFC, with a few >> nits corrected. >>=20 >> However, some additional editorial improvements might improve the = security >> outcome when it is referenced by application developers. >>=20 >> Major issues: None. >>=20 >> Minor issues: >>=20 >> 5.2: >> Add a reference that defines PKCS #7 padding. >=20 > I'll plan on adding a reference to RFC 2315 for this. That would work (section reference would be 10.3) Alternatively, you could reference RFC 5652 (section 6.3), which is an = Internet Standard (STD70). >> 5.2.2.2 >> Does "the PKCS #7 padding is removed" entail checking all of its = bytes? >=20 > Should this be changed to "the PKCS #7 padding bytes are checked and = then removed=94? I think it is good to alert the reader to this need. >> 6.2.1 >> Is the intention that the sentence containing "point compression is = not >> supported" also applies to any future registered value of "crv"? >> A similar comment applies to other specifications in 6.2.1.x, e.g., = the reference >> to SEC1 representation to x and y. >=20 > It would apply to any future curves registered that use the "x", "y" = point representation. Others could define new key types that use a = different representation or we could refine the definition of "kty":"EC" = to make the representation specific to the "crv" value. >=20 > A discussion happened on the JOSE thread "JWK Elliptic Curve key = representations and new curves". The conclusion suggested by Richard = Barnes and seconded by Stephen Farrell was to table defining any new key = representations for new elliptic curves until the CRFG recommendations = to TLS have been made. That ended the discussion for now. Right, I didn=92t want to anticipate that discussion; I would be happy = if it didn=92t appear that the avenue for any evolution on point = compression/compact points were closed. >> 6.2.1.1 >> =BBAdditional "crv" values MAY be >> used, provided they are understood by implementations using that = Elliptic Curve >> key.=AB How are conflicts between such implementation defined values = and future >> registered values handled? >=20 > Conflicts are avoided using the IANA JSON Web Key Elliptic Curve = registry defined in Section 7.6. Oh, but that=92s not what the text says. I read this as a general = license to use random locally defined crv values. Maybe the need for = registration needs to be clarified. >> 6.3.2: >> The MAY accept partially overrides the MUST include? >> Is the latter thus really a SHOULD? >=20 > "d" is REQUIRED. The others SHOULD be included, and if any are = included, the others MUST be included. Those are requirements on = producers. >=20 > Consumers may choose to accept keys that don't include all the CRT = parameters. Given that they can be computed from "n", "e", and "d" and = sometimes they're not available, a previous reviewer had asked this = language about consumers to be included. It's a case of "Be = conservative in what you send, be liberal in what you accept=94. =20 [I=92m not inserting my usual rant here that this bon mot may apply to = implementations, but never to specifications.] > It's not clear to me that there's any value in relaxing the = requirements on producers. Well, if the producer MUST send =93all of the others=94 if =93any of the = other=94 parameters are present, it is not clear to me what the point of = "MAY choose to accept an RSA private key that does not contain a complete set of the private key parameters other than =93d=94=94 is other than = enabling producers to send just that. (More importantly, it is not clear when a producer should be taking that = license.) >=20 >> 7.1: >> It is interesting that a mere registration (vetted only by a DE) can = change the >> IETF consensus base specifications by making an algorithm "Required". >=20 > It is expected that the designated experts will be appointed, in part, = for their cryptographic expertise. There has been more discussion about the requirements levels here that I = don=92t want to repeat. My comment here was that a DE (even with the best crypto knowledge) is = in a hard place updating the consensus about *desirability of = implementation* =97 there are more aspects to this than the technical = ones. >=20 >> 8. >> I am unable to find a "security considerations" section in NIST SP = 800-38A. >> 800-38D at least has a "practical considerations" section, is that = meant? >> (Etc., I haven't checked all the references.) In general, I believe a = security >> considerations section is most useful where it provides more directed = guidance >> instead of saying the equivalent of "here is a textbook". >=20 > There are 14 subsections with directed guidance, plus more in the JWS, = JWE, and JWK specifications. If there is other directed guidance you'd = like to see added, please supply proposed text. >=20 > Having skimmed through it, I agree that 800-30A doesn't contain clear = enough security guidance to merit inclusion in the list. I'll remove = it. If there are other specifications that you'd like to see added or = removed, please let me know. This was more of a general comment that =93Here is a reference to a = textbook=94 type security considerations are less useful than specific, = directed references. I haven=92t checked all those referenced = documents, so I=92m not in a position to recommend changes here. Maybe = something for a checklist to apply to the next security spec. >=20 >> 8.7 is not clear: is it NOT RECOMMENDED to reuse an entire set of key = material >> (including IV), or to reuse any part of it? >=20 > I agree that this is ambiguous, as worded. Its advice seems to be so = broad as to be impractical, as never reusing a key means that a new key = would have to be redistributed for each encryption, which then requires = a key to use for the distribution... This text came from = http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-02#section-= 8.1, which was incorporated into the document after a working group = decision to do so. Matt Miller, you were the author of this text. = Could you clarify what the intent was? Thanks. >=20 >> Nits/editorial comments: >>=20 >> 6.3.2.x: >> The constant repetition of =BBIt is represented as the base64url = encoding of the >> value's unsigned big endian representation as an octet sequence. >> The octet sequence MUST utilize the minimum number of octets to = represent >> the value.=AB almost ensures that an implementer will stop reading = the details >> (well, I did, and I did not write a program to verify the same phrase = is used >> everywhere; if any parameter were using a different encoding, that = sure would >> be missed). Why not define another abstraction like base64url and = use this? >=20 > I did just verify that they are all consistent. Yes, if you're = reading the spec linearly I'm sure it feels repetitive, but if you're an = implementer going straight to a definition to implement it, having a = complete description all in one place is valuable. I understand your = request but it's not clear to me that this rises to the level that a = separate definition that the developer then has to go find is warranted. My point was corroborated by the tiny error Richard found. Repeating = the same information again and again drowns out the important = information. A single paragraph at the end of 6.3=92s intro of the = form: Each of the positive integer parameters defined in this section=20 is represented as the base64url encoding of the value's unsigned big endian representation as an octet sequence. The octet sequence MUST utilize the minimum number of octets to represent the value. Note that the repetitive text already has a reference that needs to be = looked up in that it uses the term "base64url encoding=94, which has a = slightly refined meaning here from that in RFC 4648. So an even better = way to handle this would be to add a new term =93posint encoding=94 or = some such to section 1.1, turning e.g. the entirety of 6.3.2.2 into The "p" (first prime factor) member contains the first prime = factor, in POSINT encoding. >=20 >> 6.2.3.1: This is not a positive integer? 6.2.3.x mentions this = otherwise. >=20 > I may not understand this remark. I'm guessing you're referring to = 6.3.2.1 and the fact that the description includes the word "unsigned". = This is there to make it clear that no sign bit will be present in the = representation - which is especially important since the high-order bit = is always set for "n" and "d" for correctly generated keys. (Sorry, this is indeed about 6.3.2.x, not 6.2.3.x.) That was not what I meant: All 6.3.2.x have the form =BBThe "p" (first = prime factor) member contains the first prime factor, a positive = integer.=AB 6.3.2.1 does not have the =93, a positive integer=94, but I can=92t see = a reason for that (d clearly cannot be zero, and it is still an unsigned = value). This is likely to confuse an implementer that reads this text closely. (And I=92m offering the fact that you are overlooking that inconsistency = as another corroboration of my previous point=85) >> 7.1.1 >> =BBExample description=AB is not a useful example for an "Algorithm = Description". >> (Same comment for 7.x.1.) >=20 > See the actual registrations in Section 7.1.2 for more useful = examples. Maybe just take out the not so useful examples in 7.x.1? >> 8.3: >> s/because it/because it is/ >=20 > Good catch >=20 >> [sec1] >> (Given the date, this is probably referencing V2.0 of this spec.) >=20 > Hmmm - the version I have cached locally came from = http://www.secg.org/collateral/sec1_final.pdf and is dated September 20, = 2000. But the site appears to be down at present. The version = referenced by Wikipedia at = http://www.secg.org/download/aid-385/sec1_final.pdf is missing too. = http://secg.org/download/aid-780/sec1-v2.pdf is missing too. Can you = point me to a good link? I just had a look and embarrassingly found that the copy I=92m using = comes from the personal space of a researcher: = http://perso.univ-rennes1.fr/sylvain.duquesne/master/standards/sec1-v2.pdf= Not very satisfying as a reference. >=20 > RFC 5915 includes this reference: >=20 > [SECG1] Standards for Efficient Cryptography Group (SECG), "SEC = 1: > Elliptic Curve Cryptography", Version 2.0, May 2009. That looks good: We don=92t need a URL, as long as we are certain which = version we are referencing. > Worst comes to worst, I'll either reference that or explicitly = reference the 1.0 version. But if I'm going to reference the 2.0 = version, I'd like to be able to read a copy so that I can verify that = the way we're using it is consistent with the actual spec, including the = section numbers. >=20 >> [usascii] >> The reference to ANSI X3.4:1986 should probably be replaced by a = reference to >> RFC 20. There is little reason to reference a somewhat hard to = obtain external >> document ($60!) when we have an RFC about the same subject. >=20 > OK >=20 >> (Tables in Appendix A need some formatting.) >=20 > Agreed. It's on my to-do list. Jim Schaad recently told me to "Add a = width attribute to the ttcol with either "digits" (for fixed width) or = "digits%" (for percent width) to the column in question". I plan to = give it a try. >=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > Thanks again, > -- Mike >=20 >=20 >=20 From nobody Wed Oct 15 05:54:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8E31A6F5D; Wed, 15 Oct 2014 05:54:35 -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 cXJqHQHKVSyO; Wed, 15 Oct 2014 05:54:34 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798BD1A6F61; Wed, 15 Oct 2014 05:54:33 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id mc6so995990lab.2 for ; Wed, 15 Oct 2014 05:54: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=tCJ/D4waFMxDT9g9GPMx6ofwUV4/IsQAHUjLtSttQNk=; b=x4IKGcQor296VXbtsM1i39nS3h6ClAAjhP9HM4QIXCHNj2od+uJU/a2pa78sWaZMwG 3A+6pPQCaoM3b2Thiw2ctAdPLCuwV3mvtwENzfrh4ACnEvCqXwsqNNqDWmxe/CTIynkM F44JkiDN8mMUj1OIzLYv71wFAXJ9NvU6b7VrMF22UHxj8UOS9/FXnNKkIQAlX2jWC5jB p8S9tpffsog9D9eupwYU8+DzjQY7/q1Tb7OW7wigQrussAcAJT/+uDk6SGosrVkrjiMb 20mVertnvgqzc5tTUDCEQU0jCvV5HHIstxz7Dt1HfRepihQF9kaM8SK+g4ON7hwLymMB co+A== MIME-Version: 1.0 X-Received: by 10.112.146.5 with SMTP id sy5mr2622083lbb.97.1413377671580; Wed, 15 Oct 2014 05:54:31 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Wed, 15 Oct 2014 05:54:31 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BB0F8CD@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439BB0F8CD@TK5EX14MBXC286.redmond.corp.microsoft.com> Date: Wed, 15 Oct 2014 08:54:31 -0400 X-Google-Sender-Auth: Nh607jtMVQFvVN_1j64UvxIl7nU Message-ID: From: Barry Leiba To: Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Sx1UdbmxpiWHrzjGbruqwvOZal0 Cc: "apps-discuss@ietf.org" , "iesg@ietf.org" , "jose@ietf.org" , "draft-ietf-jose-json-web-signature.all@tools.ietf.org" Subject: Re: [apps-discuss] AppsDir reviews of draft-ietf-jose-json-web-signature-32 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 12:54:35 -0000 >> 4.1.1. & 4.1.2. The links to Section 4.1 and Section 5.1 of JWA are incorrect. >> They link to JWE instead of JWA. >> >> In 4.1.1. the link is: >> https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-32#section-4.1 >> ...but it should be: >> https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-33#section-4.1 >> >> In 4.1.2. the link is: >> https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-32#section-5.1 >> ...but it should be: >> https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-33#section-5 >> (JWA doesn't seem to have an anchor for 5.1) > > These link URLs are actually created by the IETF tools - not in the > draft itself. (You'll see "Html markup produced by rfcmarkup 1.109, > available from https://tools.ietf.org/tools/rfcmarkup/" at the bottom > of the drafts.) I'm not sure who to file a bug on this with. Ray is looking at the HTML generated by tools.ietf.org, which creates the HTML by analyzing the text, not by looking at the markup. When the section name is separated from the reference, it can't figure it out, and assumes that the section reference is to the current document. So, in JWE, for example, this: the initial contents of this registry are the values defined in Section 4.1 of the JSON Web Algorithms (JWA) [JWA] specification. ...doesn't work, and makes "Section 4.1" link to Section 4.1 of the current document, JWE, and then gives a link to the top of JWA at "[JWA]". You can make it work as desired by doing this: OLD the initial contents of this registry are the values defined in Section 4.1 of the JSON Web Algorithms (JWA) [JWA] specification. NEW the initial contents of this registry are the values defined in the JSON Web Algorithms specification (JWA) [JWA], Section 4.1. END That will cause "[JWA], Section 4.1" to link as you'd expect. (I also suggest that you don't need "(JWA) [JWA]" and can just use "[JWA]" there, but perhaps that is an artifact of your markup tool.) There are many places where this is an issue -- it's a tools issue, not a document issue. If you're willing to "fix" this in the documents, please go through and try to find all the places where that sentence structure is used. Barry From nobody Wed Oct 15 10:05:08 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98A01A8A92 for ; Wed, 15 Oct 2014 10:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOGPzRupHCbD for ; Wed, 15 Oct 2014 10:05:05 -0700 (PDT) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id BDCFA1A8A58 for ; Wed, 15 Oct 2014 10:04:23 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1XeRzf-0006oH-j8; Wed, 15 Oct 2014 18:04:12 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.atuin.ninebynine.org) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1XeRzf-000406-8R; Wed, 15 Oct 2014 18:04:11 +0100 Message-ID: <543EA941.6030704@ninebynine.org> Date: Wed, 15 Oct 2014 18:05:05 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ned Freed References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> <9AD273B04D7CB4B07CE8D1C5@JcK-HP8200.jck.com> <543CDE33.4030402@ninebynine.org> <01PDQCNHFSIM00005K@mauve.mrochek.com> In-Reply-To: <01PDQCNHFSIM00005K@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/NAfNN1Ojci2U8EzjFCpP_9JNfpI Cc: IETF Apps Discuss Subject: [apps-discuss] Fragement identifiers for archives (was: IETF 91 scheduling) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 17:05:07 -0000 On 14/10/2014 16:37, Ned Freed wrote: > Very good point. Do you think it would make sense to define a generic > syntax (which of course could be overridden in specific cases)? I think it _could_ be useful and sensible - I've been involved in design discussions where URI mechanisms to delve inside a composite package have been raised, and it's been tricky to figure out what would also play well in a wider web landscape. I think this could be a challenge to get right, so I wouldn't rush into it without some careful thought. Maybe it's the sort of thing that might usefully start out as being experimental. (*) The challenges are compounded by this being a (sometimes) "level breaking" requirement w.r.t. URI usage on the web: fragment IDs identify "secondary resources": with reference some main resource; the fragment is never presented to the server when retrieving the main resource. OTOH, the secondary resources are sometimes also directly accessible as individual web resources in their own right, and it would (sometimes) be most useful to be able to relate (sub)resources in an archive to free standing ones. I think any such design attempt should probably also engage with people involved in the W3C web applications group (who are proposing the app: scheme mentioned previously, which AIUI addresses some similar concerns). #g -- (*) a possible approach that occurs to me is to adopt relative URI reference syntax (**) for archive fragments, %-escaped as needed; e.g. in a simple case "sub1/sub2/file.type" (but also not prohibiting query or even further fragment components). Such a fragment might then be used as a relative reference w.r.t. an absolute file: URI base to access components within an archived that has been unpacked. Or, if the unpacked archive is also (effectively) presented by a server (a situation I have been involved in discussing), the same relative reference could be resolved against an http: base URI. On a quick look, I think this approach could play well with the proposed app: scheme, in that the fragment used as a relative reference w.r.t a (specified or implied) app: base URI could mean something like "this resource within the current package/archive object" (a bit like file: operates w.r.t. the current hosts file system). (**) e.e. something like path-noscheme [ "?" query ] [ "%23" fragment ] using elements defined at http://tools.ietf.org/html/rfc3986#section-4.2 > >> John, >> all, > >> One thing that *could* be associated with an archive media type is a fragment >> syntax for URIs to reference components within an archive... I think that >> possibility is new since the old days of being mainly email focused. > >> (I'm wondering if this could dovetail with the file scheme work...) > >> (FWIW, there's a URI scheme proposal out there called app: which also wades in >> these waters - http://www.w3.org/TR/app-uri/, and also a W3C community group >> interested in packaged content - http://www.w3.org/community/rosc/, and some >> activity in the W3C TAG - http://w3ctag.github.io/packaging-on-the-web/) > >> #g >> -- > >> On 30/09/2014 11:03, John C Klensin wrote: >> > >> > >> > --On Monday, September 29, 2014 14:46 -0700 Sean Leonard >> > wrote: >> > >> >> Topic: Archive TLMT >> >> ... >> >> Here are some of the issues to be considered, which I put on >> >> the proposed BoF agenda: Agenda >> >> Discuss proposal to make archive TLMT >> >> Identify use cases >> >> Identify types of archives and whether these types of archives >> >> should all go in, e.g.: archiving only, multi-function, >> >> software packaging, disk images, backup Identify formats in >> >> ... >> > >> > Hi. >> > >> > I had planned to sit this one out because I see some value in >> > the general idea and probably little harm. I also agree with >> > Ned that things have evolved in a way that probably makes this >> > reasonable and that there is little justification for trying to >> > invent a complex architectural process before adding one new >> > type. >> > >> > However, unless my memory is failing me, there is one historical >> > tidbit about which people should be aware. Ned wrote "There >> > used to be a strong reluctance to register media types for >> > archive formats". My recollection is that it was a bit more >> > than that, that archives (particularly of the zip and tar >> > persuasions) were explicitly discussed and believed to be >> > orthogonal to Content-type and Content-transfer-encoding, >> > inappropriate for top-level Content-types (now Media types) >> > unless we expected email clients to actually take some action on >> > them, e.g., by exploding them or having some other specific >> > action routines for them. That is where the analogy to >> > multipart/ (or even message/) breaks down a bit because we have >> > precisely that expectation of those top level aggregate and >> > potentially aggregate types. By contrast, archive/ would really >> > be an aggregate identifier for components that, at least with >> > the two or three most popular archive formats, do not have media >> > types except by naming convention. >> > >> > If the intent is merely to identify the content, rather than >> > expecting action and to create another top-level type that, like >> > application/ is expected to be opaque to the mail system, >> > perhaps we should be generalizing and considering "container/" >> > or, to borrow a note from X.400, even "FileTransfer/", rather >> > than thinking there is something extra-special about archives. >> > >> > On the other hand, there is something extra-special, which is >> > frequency of use, and things have changed a lot since >> > Content/Media types were first defined in the current contexts, >> > so this is just something to think about rather than a strong >> > alternate suggestion. >> > >> > john >> > >> > >> > _______________________________________________ >> > apps-discuss mailing list >> > apps-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/apps-discuss >> > > >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Wed Oct 15 10:11:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAD21ABD35 for ; Wed, 15 Oct 2014 10:11:49 -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 JFmVxPU6Sr2s for ; Wed, 15 Oct 2014 10:11:44 -0700 (PDT) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 324161A89EF for ; Wed, 15 Oct 2014 10:10:42 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1XeS5s-00083l-g3; Wed, 15 Oct 2014 18:10:36 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.atuin.ninebynine.org) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1XeS5r-0004BM-8J; Wed, 15 Oct 2014 18:10:35 +0100 Message-ID: <543EAAC1.1@ninebynine.org> Date: Wed, 15 Oct 2014 18:11:29 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John C Klensin References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> <9AD273B04D7CB4B07CE8D1C5@JcK-HP8200.jck.com> <543CDE33.4030402@ninebynine.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/xcIAC94F1lLRhVIZcPzMWaIDdKE Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] Archive media type X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 17:11:49 -0000 John, I read your comments as saying, in part, there was previously seen to be no value in treating archives as different from any other application/... type. I'm suggesting that circumstances may have changed; also that there is now an increased level of interest for having better ways to handle composite objects. Beyond that, I wasn't attempting to address your more detailed comments. #g -- On 14/10/2014 15:15, John C Klensin wrote: > (note change of subject; should have been done earlier) > > --On Tuesday, 14 October, 2014 09:26 +0100 Graham Klyne > wrote: > >> John, >> all, >> >> One thing that *could* be associated with an archive media >> type is a fragment syntax for URIs to reference components >> within an archive... I think that possibility is new since the >> old days of being mainly email focused. > > Probably true. Doesn't seem to have much, if anything, to do > with my comments below. At the risk of replaying some of the > URNBIS discussions, one could also imagine queries to find > things in an archive by content rather than by name, etc. > Whether that would be a good idea or not is an open question on > which I really don't have much opinion. > >> (I'm wondering if this could dovetail with the file scheme >> work...) >> >> (FWIW, there's a URI scheme proposal out there called app: >> which also wades in these waters - >> http://www.w3.org/TR/app-uri/, and also a W3C community group >> interested in packaged content - >> http://www.w3.org/community/rosc/, and some activity in the >> W3C TAG - http://w3ctag.github.io/packaging-on-the-web/) > > ack > john > > > >> On 30/09/2014 11:03, John C Klensin wrote: >>> >>> >>> --On Monday, September 29, 2014 14:46 -0700 Sean Leonard >>> wrote: >>> >>>> Topic: Archive TLMT >>>> ... >>>> Here are some of the issues to be considered, which I put on >>>> the proposed BoF agenda: Agenda >>>> Discuss proposal to make archive TLMT >>>> Identify use cases >>>> Identify types of archives and whether these types of >>>> archives should all go in, e.g.: archiving only, >>>> multi-function, software packaging, disk images, backup >>>> Identify formats in ... >>> >>> Hi. >>> >>> I had planned to sit this one out because I see some value in >>> the general idea and probably little harm. I also agree with >>> Ned that things have evolved in a way that probably makes this >>> reasonable and that there is little justification for trying >>> to invent a complex architectural process before adding one >>> new type. >>> >>> However, unless my memory is failing me, there is one >>> historical tidbit about which people should be aware. Ned >>> wrote "There used to be a strong reluctance to register media >>> types for archive formats". My recollection is that it was >>> a bit more than that, that archives (particularly of the zip >>> and tar persuasions) were explicitly discussed and believed >>> to be orthogonal to Content-type and >>> Content-transfer-encoding, inappropriate for top-level >>> Content-types (now Media types) unless we expected email >>> clients to actually take some action on them, e.g., by >>> exploding them or having some other specific action routines >>> for them. That is where the analogy to multipart/ (or even >>> message/) breaks down a bit because we have precisely that >>> expectation of those top level aggregate and potentially >>> aggregate types. By contrast, archive/ would really be an >>> aggregate identifier for components that, at least with the >>> two or three most popular archive formats, do not have media >>> types except by naming convention. >>> >>> If the intent is merely to identify the content, rather than >>> expecting action and to create another top-level type that, >>> like application/ is expected to be opaque to the mail system, >>> perhaps we should be generalizing and considering "container/" >>> or, to borrow a note from X.400, even "FileTransfer/", rather >>> than thinking there is something extra-special about archives. >>> >>> On the other hand, there is something extra-special, which is >>> frequency of use, and things have changed a lot since >>> Content/Media types were first defined in the current >>> contexts, so this is just something to think about rather >>> than a strong alternate suggestion. >>> >>> john >>> >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Wed Oct 15 11:01:58 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017AE1A90E2; Tue, 14 Oct 2014 10:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, NORMAL_HTTP_TO_IP=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 EkVK5pOUZsX7; Tue, 14 Oct 2014 10:48:01 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEC411A90C4; Tue, 14 Oct 2014 10:48:00 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id pn19so9025760lab.14 for ; Tue, 14 Oct 2014 10:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sHoexLWwz9wCYDpR/XQejffTsq9YBu0S74Vz8vqc1JI=; b=R5QuTMGKiCjyI9032+wISO2uFke/ECZCSizy6Be3qG7tuq3+cWpMnyYs7ywALcWJMs CQnvHonsvkRKUCvX+mXnn5km1q9Ccc6q0a10fi+hFH83Htp+P5FsVRKZoSYDfhL8jCCL E4WgxO3YEzXNtxLiy5uPBKE1Bc1EwMY/FiE8+DB+scnAs3jtQ7rfb/Rhk9gFrSCIQgGz fwC2fPye4tRqjK9vBBGbGMZDIAVplhbam7ZqoLMg3EhDiwrcMSSADoPRnNP/S5eMq7Xu Nm1ragRFWMe/2Dw+RClLBX0ue2POxTkklV9U8nrF3oLOGRBppiC6lZbWiQKP4cRbBZWg gVow== MIME-Version: 1.0 X-Received: by 10.152.198.204 with SMTP id je12mr6983833lac.61.1413308879178; Tue, 14 Oct 2014 10:47:59 -0700 (PDT) Received: by 10.112.95.36 with HTTP; Tue, 14 Oct 2014 10:47:59 -0700 (PDT) In-Reply-To: <7CEA60C1-BC9D-43BE-84B4-128D08F111F5@tzi.org> References: <805301AA-4E04-410D-A451-7A2175792CB0@tzi.org> <7CEA60C1-BC9D-43BE-84B4-128D08F111F5@tzi.org> Date: Tue, 14 Oct 2014 13:47:59 -0400 Message-ID: From: Kathleen Moriarty To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11348e2ab3910e0505659d17 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zb3uDt9nCJy5dsRZsU1KZxEwKAw X-Mailman-Approved-At: Wed, 15 Oct 2014 11:01:55 -0700 Cc: draft-ietf-jose-json-web-algorithms.all@tools.ietf.org, "jose@ietf.org" , "iesg@ietf.org" , Apps Discuss Subject: Re: [apps-discuss] [jose] Appsdir review for draft-ietf-jose-json-web-algorithms-33 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 17:48:05 -0000 --001a11348e2ab3910e0505659d17 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Carsten, Thanks for the re-check. I asked Mike to do a few iterations of the draft to remove what comments/discusses he could and we will make sure your comments get addressed before the draft can move forward. I'd appreciate another check once Mike thinks your comments have been addressed to make sure you agree. Thanks. On Tue, Oct 14, 2014 at 12:35 PM, Carsten Bormann wrote: > Here is a quick re-check of my review against -34. > I=E2=80=99m not sure any of the necessary fixes made it into -34. > > Gr=C3=BC=C3=9Fe, Carsten > > On 02 Oct 2014, at 09:22, Carsten Bormann wrote: > > > I have been selected as the Applications Area Directorate reviewer for > > this draft (for background on appsdir, please see > > =E2=80=8B > 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-jose-json-web-algorithms-33 > > Title: JSON Web Algorithms (JWA) > > Reviewer: Carsten Bormann > > Review Date: 2014-10-02 > > IESG Telechat date: 2014-10-02 > > > > Summary: This draft is ready for publication as a standards track RFC, > > with a few nits corrected. > > > > However, some additional editorial improvements might improve the > > security outcome when it is referenced by application developers. > > > > Major issues: None. > > > > Minor issues: > > > > 5.2: > > Add a reference that defines PKCS #7 padding. > > No change. > (Note that there is a reference behind =E2=80=9CPKCS #7 padding=E2=80=9D,= it just happens > to define CBC and not PKCS #7). > > > 5.2.2.2 > > Does "the PKCS #7 padding is removed" entail checking all of its bytes? > > No change. > > > 6.2.1 > > Is the intention that the sentence containing "point compression is not > > supported" also applies to any future registered value of "crv"? > > A similar comment applies to other specifications in 6.2.1.x, e.g., > > the reference to SEC1 representation to x and y. > > No change. > > > 6.2.1.1 > > =C2=BBAdditional "crv" values MAY be > > used, provided they are understood by implementations using that > > Elliptic Curve key.=C2=AB > > How are conflicts between such implementation defined values and > > future registered values handled? > > No change. > > And so on. > > > 6.3.2: > > The MAY accept partially overrides the MUST include? > > Is the latter thus really a SHOULD? > > > > 7.1: > > It is interesting that a mere registration (vetted only by a DE) can > > change the IETF consensus base specifications by making an algorithm > > "Required". > > > > 8. > > I am unable to find a "security considerations" section in NIST SP > 800-38A. > > 800-38D at least has a "practical considerations" section, is that mean= t? > > (Etc., I haven't checked all the references.) > > In general, I believe a security considerations section is most useful > > where it provides more directed guidance instead of saying the > > equivalent of "here is a textbook". > > > > 8.7 is not clear: is it NOT RECOMMENDED to reuse an entire set of key > > material (including IV), or to reuse any part of it? > > > > > > Nits/editorial comments: > > > > 6.3.2.x: > > The constant repetition of =C2=BBIt is represented as the base64url enc= oding > of > > the value's unsigned big endian representation as an octet sequence. > > The octet sequence MUST utilize the minimum number of octets to > > represent the value.=C2=AB almost ensures that an implementer will stop > > reading the details (well, I did, and I did not write a program to > > verify the same phrase is used everywhere; if any parameter were using = a > > different encoding, that sure would be missed). Why not define > > another abstraction like base64url and use this? > > > > 6.2.3.1: This is not a positive integer? 6.2.3.x mentions this > otherwise. > > > > 7.1.1 > > =C2=BBExample description=C2=AB is not a useful example for an "Algorit= hm > Description". > > (Same comment for 7.x.1.) > > > > 8.3: > > s/because it/because it is/ > > > > [sec1] > > (Given the date, this is probably referencing V2.0 of this spec.) > > > > [usascii] > > The reference to ANSI X3.4:1986 should probably be replaced by a > > reference to RFC 20. There is little reason to reference a somewhat > > hard to obtain external document ($60!) when we have an RFC about the > > same subject. > > > > (Tables in Appendix A need some formatting.) > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --=20 Best regards, Kathleen --001a11348e2ab3910e0505659d17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Carsten,

Thanks for the re-check.=C2=A0= I asked Mike to do a few iterations of the draft to remove what comments/d= iscusses he could and we will make sure your comments get addressed before = the draft can move forward.=C2=A0 I'd appreciate another check once Mik= e thinks your comments have been addressed to make sure you agree.

Thanks.

On Tue, Oct 14, 2014 at 12:35 PM, Carsten Bormann <cabo@tzi.= org> wrote:
Here is a quick= re-check of my review against -34.
I=E2=80=99m not sure any of the necessary fixes made it into -34.

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

On 02 Oct 2014, at 09:22, Carsten Bormann <cabo@tzi.org> wrote:

> I have been selected as the Applications Area = Directorate reviewer for
> this draft (for background on appsdir, please see
> =E2=80=8Bhttp://trac.tools.ietf.org/area/= app/trac/wiki/ApplicationsAreaDirectorate
> ).
>
> Please resolve these comments along with any other Last Call comments<= br> > you may receive. Please wait for direction from your document shepherd=
> or AD before posting a new version of the draft.
>
> Document:=C2=A0 draft-ietf-jose-json-web-algorithms-33
> Title: JSON Web Algorithms (JWA)
> Reviewer: Carsten Bormann
> Review Date: 2014-10-02
> IESG Telechat date: 2014-10-02
>
> Summary: This draft is ready for publication as a standards track RFC,=
> with a few nits corrected.
>
> However, some additional editorial improvements might improve the
> security outcome when it is referenced by application developers.
>
> Major issues: None.
>
> Minor issues:
>
> 5.2:
> Add a reference that defines PKCS #7 padding.

No change.
(Note that there is a reference behind =E2=80=9CPKCS #7 padding=E2=80=9D, i= t just happens to define CBC and not PKCS #7).

> 5.2.2.2
> Does "the PKCS #7 padding is removed" entail checking all of= its bytes?

No change.

> 6.2.1
> Is the intention that the sentence containing "point compression = is not
> supported" also applies to any future registered value of "c= rv"?
> A similar comment applies to other specifications in 6.2.1.x, e.g., > the reference to SEC1 representation to x and y.

No change.

> 6.2.1.1
> =C2=BBAdditional "crv" values MAY be
> used, provided they are understood by implementations using that
> Elliptic Curve key.=C2=AB
> How are conflicts between such implementation defined values and
> future registered values handled?

No change.

And so on.

> 6.3.2:
> The MAY accept partially overrides the MUST include?
> Is the latter thus really a SHOULD?
>
> 7.1:
> It is interesting that a mere registration (vetted only by a DE) can > change the IETF consensus base specifications by making an algorithm > "Required".
>
> 8.
> I am unable to find a "security considerations" section in N= IST SP 800-38A.
> 800-38D at least has a "practical considerations" section, i= s that meant?
> (Etc., I haven't checked all the references.)
> In general, I believe a security considerations section is most useful=
> where it provides more directed guidance instead of saying the
> equivalent of "here is a textbook".
>
> 8.7 is not clear: is it NOT RECOMMENDED to reuse an entire set of key<= br> > material (including IV), or to reuse any part of it?
>
>
> Nits/editorial comments:
>
> 6.3.2.x:
> The constant repetition of =C2=BBIt is represented as the base64url en= coding of
> the value's unsigned big endian representation as an octet sequenc= e.
> The octet sequence MUST utilize the minimum number of octets to
> represent the value.=C2=AB almost ensures that an implementer will sto= p
> reading the details (well, I did, and I did not write a program to
> verify the same phrase is used everywhere; if any parameter were using= a
> different encoding, that sure would be missed).=C2=A0 Why not define > another abstraction like base64url and use this?
>
> 6.2.3.1: This is not = a positive integer?=C2=A0 6.2.3.x mentions this otherwise.
>
> 7.1.1
> =C2=BBExample description=C2=AB is not a useful example for an "A= lgorithm Description".
> (Same comment for 7.x.1.)
>
> 8.3:
> s/because it/because it is/
>
> [sec1]
> (Given the date, this is probably referencing V2.0 of this spec.)
>
> [usascii]
> The reference to ANSI X3.4:1986 should probably be replaced by a
> reference to RFC 20.=C2=A0 There is little reason to reference a somew= hat
> hard to obtain external document ($60!) when we have an RFC about the<= br> > same subject.
>
> (Tables in Appendix A need some formatting.)
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



--

Best regards,
Kathleen
--001a11348e2ab3910e0505659d17-- From nobody Wed Oct 15 11:19:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB5F1A90A1; Wed, 15 Oct 2014 11:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 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, MANGLED_TOOL=2.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 3KRHRPNXoGax; Wed, 15 Oct 2014 11:19:03 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08F11A9093; Wed, 15 Oct 2014 11:19:02 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id p9so1542874lbv.35 for ; Wed, 15 Oct 2014 11:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qFNPYQ95+JdP1ZXpPZK+z7Macu0KmSqOhUo9Y+Yy3TE=; b=CRZRAiR1Qc2k9NVUFTzLDx0sD4r59m2FVy9uavuz/51jP5uT3BrsVZ00djegK9GE0g 96g4NStQ+Pv1Yia2pmTSgiH3uLxSFiIh6zvCpU4ucIzs/8MAbTLiUvpgfdTZeCFYFgTH U7/u5V0DrY/yl5aEzHZ/X7qk47DeK3okY7jLKclEtx4EH13BD1Ib2HZiocl6w5F/pzbx EpGMP7eHOZFtts227hcqq93YSMRVs2P3sYItSmowaa/fmlW5WGg7hdCc/YjKiIdoKFYp WT8jilEuK38MlMxWNu9y3LmyyiK94ztL3RM15HJ8jYARRqrbcyALNeur0o9j0nmNrZr3 o2mg== MIME-Version: 1.0 X-Received: by 10.112.93.231 with SMTP id cx7mr4812283lbb.89.1413397140904; Wed, 15 Oct 2014 11:19:00 -0700 (PDT) Received: by 10.25.211.11 with HTTP; Wed, 15 Oct 2014 11:19:00 -0700 (PDT) In-Reply-To: <20141013090429.7983.2844.idtracker@ietfa.amsl.com> References: <20141013090429.7983.2844.idtracker@ietfa.amsl.com> Date: Wed, 15 Oct 2014 11:19:00 -0700 Message-ID: From: "Murray S. Kucherawy" To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11348be8829f6005057a2a0e Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Ni9htIEFg_qVuasrkv4UhQSvzhk Cc: Scott Kitterman , draft-ietf-appsawg-authres-ptypes-registry@tools.ietf.org, "appsawg-chairs@tools.ietf.org" , The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-authres-ptypes-registry-04: (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, 15 Oct 2014 18:19:04 -0000 --001a11348be8829f6005057a2a0e Content-Type: text/plain; charset=UTF-8 On Mon, Oct 13, 2014 at 2:04 AM, Stephen Farrell wrote: > > I wondered if it'd be worthwhile asking that the > designated expert try ensure that the security and privacy > consequences of new entries also be documented? That's > assuming there are cases where the header field is likely > to transit between ADMDs. I'm not sure if that's really > needed though, but 7001 does have a fairly significant set > of security considerations, so presumably new entries > might also deserve a similar level of documentation. OTOH, > I could buy that experience with 7001 means that this > isn't really needed or that demanding that level of > documentation might be counterproductive. > > Actually, RFC7001 doesn't talk about the risks (if any) of this header field "leaking" outside of ADMDs that will consume it. They should ignore it by the rules in RFC7001, but it doesn't say how they could leak interesting details. That would be a useful thing to add if we ever do an RFC7001bis. Unfortunately, I think this is the kind of thing RFC7001 itself should talk about, because it's a general thing to be considered and not something specific to new ptypes. Things referenced by this new registry are probably the wrong place to put that responsibility. -MSK --001a11348be8829f6005057a2a0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 13, 2014 at 2:04 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

I wondered if it'd be worthwhile asking that the
designated expert try ensure that the security and privacy
consequences of new entries also be documented?=C2=A0 That's
assuming there are cases where the header field is likely
to transit between ADMDs. I'm not sure if that's really
needed though, but 7001 does have a fairly significant set
of security considerations, so presumably new entries
might also deserve a similar level of documentation. OTOH,
I could buy that experience with 7001 means that this
isn't really needed or that demanding that level of
documentation might be counterproductive.


Actually, RFC7001 doesn't talk abo= ut the risks (if any) of this header field "leaking" outside of A= DMDs that will consume it.=C2=A0 They should ignore it by the rules in RFC7= 001, but it doesn't say how they could leak interesting details.=C2=A0 = That would be a useful thing to add if we ever do an RFC7001bis.

Unf= ortunately, I think this is the kind of thing RFC7001 itself should talk ab= out, because it's a general thing to be considered and not something sp= ecific to new ptypes.=C2=A0 Things referenced by this new registry are prob= ably the wrong place to put that responsibility.

-MSK
=
--001a11348be8829f6005057a2a0e-- From nobody Wed Oct 15 11:38:00 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E30D1A8F49 for ; Wed, 15 Oct 2014 11:37:58 -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 Avbc5mH6RuSS for ; Wed, 15 Oct 2014 11:37:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 10F3D1A1AB2 for ; Wed, 15 Oct 2014 11:37:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 37123181C73; Wed, 15 Oct 2014 11:37:52 -0700 (PDT) To: paul.hoffman@vpnc.org, jasnell@gmail.com, barryleiba@computer.org, presnick@qti.qualcomm.com, superuser@gmail.com, alexey.melnikov@isode.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141015183752.37123181C73@rfc-editor.org> Date: Wed, 15 Oct 2014 11:37:52 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/UM8aSnZOrgRTJK0JdEPq0eXw3EA Cc: apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 18:37:58 -0000 The following errata report has been submitted for RFC7386, "JSON Merge Patch". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7386&eid=4132 -------------------------------------- Type: Editorial Reported by: Stéphane Bortzmeyer Section: 2 Original Text ------------- define MergePatch(Target, Patch): if Patch is an Object: if Target is not an Object: Target = {} # Ignore the contents and set it to an empty Object for each Name/Value pair in Patch: if Value is null: if Name exists in Target: remove the Name/Value pair from Target else: Target[Name] = MergePatch(Target[Name], Value) return Target else: return Patch Corrected Text -------------- define MergePatch(Target, Patch): if Patch is an Object: if Target is not an Object: Target = {} # Ignore the contents and set it to an empty Object for each Name/Value pair in Patch: if Value is null: if Name exists in Target: remove the Name/Value pair from Target else: Target[Name] = MergePatch(Target[Name], Value) return Target else: return Patch Notes ----- Indentation of the pseudo-code example was correct in the Internet-Drafts but was messed up in the final version. For instance, "Target = {}" should be under the two ifs. (Reported by James H. Manger on the appsawg mailing list.) 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. -------------------------------------- RFC7386 (draft-ietf-appsawg-json-merge-patch-07) -------------------------------------- Title : JSON Merge Patch Publication Date : October 2014 Author(s) : P. Hoffman, J. Snell Category : PROPOSED STANDARD Source : Applications Area Working Group Area : Applications Stream : IETF Verifying Party : IESG From nobody Wed Oct 15 13:43:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E3B1ACD1E; Wed, 15 Oct 2014 13:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TOOL=2.3, 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 wYA17yK_Ntmy; Wed, 15 Oct 2014 13:43:18 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4901A88F3; Wed, 15 Oct 2014 13:43:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 35307BED4; Wed, 15 Oct 2014 21:43:17 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFi4Wo0KAdQQ; Wed, 15 Oct 2014 21:43:16 +0100 (IST) Received: from [10.87.48.12] (unknown [86.46.19.135]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D7910BEB6; Wed, 15 Oct 2014 21:43:15 +0100 (IST) Message-ID: <543EDC63.7090107@cs.tcd.ie> Date: Wed, 15 Oct 2014 21:43:15 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20141013090429.7983.2844.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/jYIo3YlcGpQgUnN_NmBrByZ6CzA Cc: Scott Kitterman , draft-ietf-appsawg-authres-ptypes-registry@tools.ietf.org, "appsawg-chairs@tools.ietf.org" , The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-authres-ptypes-registry-04: (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, 15 Oct 2014 20:43:20 -0000 On 15/10/14 19:19, Murray S. Kucherawy wrote: > On Mon, Oct 13, 2014 at 2:04 AM, Stephen Farrell > wrote: > >> >> I wondered if it'd be worthwhile asking that the >> designated expert try ensure that the security and privacy >> consequences of new entries also be documented? That's >> assuming there are cases where the header field is likely >> to transit between ADMDs. I'm not sure if that's really >> needed though, but 7001 does have a fairly significant set >> of security considerations, so presumably new entries >> might also deserve a similar level of documentation. OTOH, >> I could buy that experience with 7001 means that this >> isn't really needed or that demanding that level of >> documentation might be counterproductive. >> >> > Actually, RFC7001 doesn't talk about the risks (if any) of this header > field "leaking" outside of ADMDs that will consume it. They should ignore > it by the rules in RFC7001, but it doesn't say how they could leak > interesting details. That would be a useful thing to add if we ever do an > RFC7001bis. > > Unfortunately, I think this is the kind of thing RFC7001 itself should talk > about, because it's a general thing to be considered and not something > specific to new ptypes. Things referenced by this new registry are > probably the wrong place to put that responsibility. Fair 'nuff. Cheers, S. > > -MSK > From nobody Wed Oct 15 16:00:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60DF1ACDFB for ; Wed, 15 Oct 2014 16:00:26 -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 hNqXtFg7Qg3L for ; Wed, 15 Oct 2014 16:00:25 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AEE91ACDD6 for ; Wed, 15 Oct 2014 16:00:25 -0700 (PDT) Received: from [192.168.1.120] (unknown [74.113.134.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 099EA509B6 for ; Wed, 15 Oct 2014 19:00:23 -0400 (EDT) From: Sean Leonard Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <768BCB0B-5B09-4297-8C0A-735C15BD657C@seantek.com> Date: Wed, 15 Oct 2014 16:00:21 -0700 To: IETF Apps Discuss Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JYB4op7pXIEqa0FRCxdv225FmdM Subject: [apps-discuss] text/markdown progress: recommended split X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 23:00:27 -0000 Hi apps-discuss: I finished the content of draft-03 of the text-markdown spec = (draft-ietf-appsawg-text-markdown-03). However, before posting, I would like to see how people feel about a = proposed split in the document. Murray requested WG discussion and = consensus on this before actually doing it. I seriously tried to shorten the document, which has been shrunk about = 25% (~18 pages instead of ~25 pages). However, adding additional = registrations and Markdown-handling strategies would be beneficial. = These additional registrations and strategies are NOT normative, but = they help illustrate the diversity of use cases that we are *trying* to = unify under the common text/markdown media type. The additional registrations (7) and discussion are an additional 18 = pages or so, including boilerplate. Thus I propose that the subsidiary = content be split into draft-ietf-appsawg-text-markdown-use-cases-00 (for = =93use cases=94). RFC 2119 key words will not be used in that document. Thoughts folks? Sean= From nobody Wed Oct 15 16:06:59 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078FF1ACE0C for ; Wed, 15 Oct 2014 16:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, 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 vRrzV_dFkGZn for ; Wed, 15 Oct 2014 16:06:44 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id ED5B21ACE0F for ; Wed, 15 Oct 2014 16:06:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,728,1406556000"; d="scan'208";a="45356767" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 16 Oct 2014 09:49:35 +1100 X-IronPort-AV: E=McAfee;i="5600,1067,7592"; a="267585682" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcdvi.tcif.telstra.com.au with ESMTP; 16 Oct 2014 10:06:38 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Thu, 16 Oct 2014 10:06:38 +1100 From: "Manger, James" To: Stephane Bortzmeyer , RFC Errata System , "paul.hoffman@vpnc.org" , "jasnell@gmail.com" , "barryleiba@computer.org" , "presnick@qti.qualcomm.com" , "superuser@gmail.com" , "alexey.melnikov@isode.com" Date: Thu, 16 Oct 2014 10:06:37 +1100 Thread-Topic: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) Thread-Index: Ac/opzu+W2YDdLLNRk6rzRX7NGqo4QAIft1Q Message-ID: <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com> References: <20141015183752.37123181C73@rfc-editor.org> In-Reply-To: <20141015183752.37123181C73@rfc-editor.org> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hk305cnw80dZLAmR2O-FfNOwlW4 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 23:06:54 -0000 Thanks for reporting this as an errata Stephane. "Editorial" is the wrong c= lassification however; it is "Technical". The indentation is critical to un= derstanding the function. The function isn't merely to reinforce normative = text -- the function is the only normative specification of the Merge-Patch= processing rules. The other text only gives a casual description of some r= ules (in the introduction), calls attention to some corner cases, and provi= des examples. If the RFC editors cannot correct the indentation, we need a new RFC. Personally I don't think an accepted errata is sufficient. The doc is too u= nusable in its current state. Can this sort of critical typo be fixed without a new RFC number? P.S. Curiously, the "Diff2" format on tools.ietf.org [https://tools.ietf.or= g/rfcdiff?url2=3Drfc7386] shows the indentation as being correct in rfc7386= .txt and draft-ietf-appsawg-json-merge-patch-07. Probably a tools glitch. -- James Manger -----Original Message----- From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of RFC = Errata System Sent: Thursday, 16 October 2014 5:38 AM To: paul.hoffman@vpnc.org; jasnell@gmail.com; barryleiba@computer.org; pres= nick@qti.qualcomm.com; superuser@gmail.com; alexey.melnikov@isode.com Cc: apps-discuss@ietf.org; rfc-editor@rfc-editor.org Subject: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) The following errata report has been submitted for RFC7386, "JSON Merge Pat= ch". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D7386&eid=3D4132 -------------------------------------- Type: Editorial Reported by: St=C3=A9phane Bortzmeyer Section: 2 Original Text ------------- define MergePatch(Target, Patch): if Patch is an Object: if Target is not an Object: Target =3D {} # Ignore the contents and set it to an empty Object for each Name/Value pair in Patch: if Value is null: if Name exists in Target: remove the Name/Value pair from Target else: Target[Name] =3D MergePatch(Target[Name], Value) return Target else: return Patch Corrected Text -------------- define MergePatch(Target, Patch): if Patch is an Object: if Target is not an Object: Target =3D {} # Ignore the contents and set it to an empty Object for each Name/Value pair in Patch: if Value is null: if Name exists in Target: remove the Name/Value pair from Target else: Target[Name] =3D MergePatch(Target[Name], Value) return Target else: return Patch Notes ----- Indentation of the pseudo-code example was correct in the Internet-Drafts b= ut was messed up in the final version. For instance, "Target =3D {}" shoul= d be under the two ifs. (Reported by James H. Manger on the appsawg mailing= list.) Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "R= eply All" to discuss whether it should be verified or rejected. When a deci= sion is reached, the verifying party (IESG) can log in to change the status= and edit the report, if necessary.=20 -------------------------------------- RFC7386 (draft-ietf-appsawg-json-merge-patch-07) -------------------------------------- Title : JSON Merge Patch Publication Date : October 2014 Author(s) : P. Hoffman, J. Snell Category : PROPOSED STANDARD Source : Applications Area Working Group Area : Applications Stream : IETF Verifying Party : IESG From nobody Wed Oct 15 16:39:49 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0961ACE79 for ; Wed, 15 Oct 2014 16:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.15 X-Spam-Level: X-Spam-Status: No, score=-0.15 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35] 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 aV-if-We9ruW for ; Wed, 15 Oct 2014 16:39:45 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 850A71ACC82 for ; Wed, 15 Oct 2014 16:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9FNddx8011431; Thu, 16 Oct 2014 01:39:40 +0200 (CEST) Received: from [192.168.217.145] (p5489134F.dip0.t-ipconnect.de [84.137.19.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B829BB45; Thu, 16 Oct 2014 01:39:38 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <306B15D1-D5F5-46B8-8473-599B3B4667EE@tzi.org> Date: Thu, 16 Oct 2014 01:39:37 +0200 X-Mao-Original-Outgoing-Id: 435109176.937935-20bcc2b09e45aa53a9739204ac0085d6 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141015183752.37123181C73@rfc-editor.org> <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com> <306B15D1-D5F5-46B8-8473-599B3B4667EE@tzi.org> To: "apps-discuss@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/yXas0zcO3vmrp3P7Oj57wJjp8-w Cc: "presnick@qti.qualcomm.com" , Paul Hoffman , "barryleiba@computer.org" , RFC Errata System Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 23:39:46 -0000 (Trimming cc list:) This is now also http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/276 Gr=FC=DFe, Carsten On 16 Oct 2014, at 01:16, Carsten Bormann wrote: > On 16 Oct 2014, at 01:06, Manger, James = wrote: >=20 >> P.S. Curiously, the "Diff2" format on tools.ietf.org = [https://tools.ietf.org/rfcdiff?url2=3Drfc7386] shows the indentation as = being correct in rfc7386.txt and draft-ietf-appsawg-json-merge-patch-07. = Probably a tools glitch. >=20 > This looks like the canonical tab-width confusion. > The correct text had a tab-width of 8, but the RFC text was converted = to spaces applying a tab-width of 4. >=20 > Yep, the copy of rfc7386.xml I have has been tabified, while = draft-ietf-appsawg-json-merge-patch-07.xml is clean. >=20 > NEVER, EVER, tabify documents. > THROW OUT ALL TOOLS THAT DO THIS. > (Sorry for shouting, but this TAB nonsense has cost too much time in = my life already.) >=20 > Gr=FC=DFe, Carsten >=20 >=20 >=20 From nobody Wed Oct 15 16:51:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD9A1ACE73 for ; Wed, 15 Oct 2014 16:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 Izt2P0Br7O_g for ; Wed, 15 Oct 2014 16:51:14 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B5C41ACE7B for ; Wed, 15 Oct 2014 16:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9FNpA8p009083; Thu, 16 Oct 2014 01:51:10 +0200 (CEST) Received: from [192.168.217.145] (p5489134F.dip0.t-ipconnect.de [84.137.19.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7BD6FB4B; Thu, 16 Oct 2014 01:51:09 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Thu, 16 Oct 2014 01:51:07 +0200 X-Mao-Original-Outgoing-Id: 435109867.01515-1fb750fd2000ef646e39caad755be69b Content-Transfer-Encoding: quoted-printable Message-Id: <04D4269D-E0D8-416B-942E-C757534A4BC7@tzi.org> References: <20141015183752.37123181C73@rfc-editor.org> <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com> <306B15D1-D5F5-46B8-8473-599B3B4667EE@tzi.org> To: "apps-discuss@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Sie6gDO1L2OCjqz4FHTU30JhwUE Cc: "presnick@qti.qualcomm.com" , Paul Hoffman , "barryleiba@computer.org" , RFC Errata System Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 23:51:15 -0000 On 16 Oct 2014, at 01:39, Carsten Bormann wrote: > Yep, the copy of rfc7386.xml I have has been tabified, while = draft-ietf-appsawg-json-merge-patch-07.xml is clean. One more data point: Appendix A has *not* been tabified (and thus is the = only artwork that isn=92t munged). There are also lines of XML in the = front matter (James=92 email address, abstract) that haven=92t been = tabified (which has no consequence either way). Gr=FC=DFe, Carsten From nobody Wed Oct 15 16:57:23 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076EF1ACE95 for ; Wed, 15 Oct 2014 16:57:15 -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 tcXNYmfCHkEB for ; Wed, 15 Oct 2014 16:57:11 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10CD01ACE8D for ; Wed, 15 Oct 2014 16:57:10 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id x19so2388103ier.34 for ; Wed, 15 Oct 2014 16:57: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:from:date:message-id:subject:to :cc:content-type; bh=/xubXsA7cbiX5EkEPuNvPV9mAe12jvIPAGYtZwlgVsk=; b=OBY1KTZpvYNW4V5OWwQR5Afw1uzBE7VAC9DVs+mzIBesBo6BScVULPWKd5ISdatn96 1nF9Wr21zZOQW5Jk0kcBEyGzPIlvGxL7F9VgSFsQgjU9ZooX+k7tFYSdCzhac90KkXM5 6+MMhZ5wdleUZ7w7plKB9qFP27270RtM3elU0lEz6aW+KjxTxqyFLiF8F7r7UwKfV4Hd V5hKSo0xWjQTQt99fAseMpgDf3jI94Q1UU8e6WGwreszwGFiOAdwgITOiP/dh7oCiwD1 Dj6w5N9lrud9HjjRyUsGNUy46Nni3HgVIqVvA0rZT5791t2zzuWhH2rf/Ulgb+dyjsu1 GpEA== X-Received: by 10.50.25.71 with SMTP id a7mr18122852igg.48.1413417430298; Wed, 15 Oct 2014 16:57:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.172.212 with HTTP; Wed, 15 Oct 2014 16:56:50 -0700 (PDT) In-Reply-To: <768BCB0B-5B09-4297-8C0A-735C15BD657C@seantek.com> References: <768BCB0B-5B09-4297-8C0A-735C15BD657C@seantek.com> From: Ira McDonald Date: Wed, 15 Oct 2014 19:56:50 -0400 Message-ID: To: Sean Leonard , Ira McDonald Content-Type: multipart/alternative; boundary=047d7bd74a1cda385305057ee375 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Ekg5CtqTqkRSpIqiDrJq9bNbG3Q Cc: IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown progress: recommended split X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 23:57:15 -0000 --047d7bd74a1cda385305057ee375 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Sean, +1 to the split. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Wed, Oct 15, 2014 at 7:00 PM, Sean Leonard wrote: > Hi apps-discuss: > > I finished the content of draft-03 of the text-markdown spec > (draft-ietf-appsawg-text-markdown-03). > > However, before posting, I would like to see how people feel about a > proposed split in the document. Murray requested WG discussion and > consensus on this before actually doing it. > > I seriously tried to shorten the document, which has been shrunk about 25= % > (~18 pages instead of ~25 pages). However, adding additional registration= s > and Markdown-handling strategies would be beneficial. These additional > registrations and strategies are NOT normative, but they help illustrate > the diversity of use cases that we are *trying* to unify under the common > text/markdown media type. > > The additional registrations (7) and discussion are an additional 18 page= s > or so, including boilerplate. Thus I propose that the subsidiary content = be > split into draft-ietf-appsawg-text-markdown-use-cases-00 (for =E2=80=9Cus= e cases=E2=80=9D). > RFC 2119 key words will not be used in that document. > > Thoughts folks? > > Sean > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --047d7bd74a1cda385305057ee375 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sean,

+1 to the split.
<= br>
Cheers,
- Ira

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


On Wed, Oct 15, 2014 at 7:00 PM, Sean Leonar= d <dev+ietf@seantek.com> wrote:
Hi apps-discuss:

I finished the content of draft-03 of the text-markdown spec (draft-ietf-ap= psawg-text-markdown-03).

However, before posting, I would like to see how people feel about a propos= ed split in the document. Murray requested WG discussion and consensus on t= his before actually doing it.

I seriously tried to shorten the document, which has been shrunk about 25% = (~18 pages instead of ~25 pages). However, adding additional registrations = and Markdown-handling strategies would be beneficial. These additional regi= strations and strategies are NOT normative, but they help illustrate the di= versity of use cases that we are *trying* to unify under the common text/ma= rkdown media type.

The additional registrations (7) and discussion are an additional 18 pages = or so, including boilerplate. Thus I propose that the subsidiary content be= split into draft-ietf-appsawg-text-markdown-use-cases-00 (for =E2=80=9Cuse= cases=E2=80=9D). RFC 2119 key words will not be used in that document.

Thoughts folks?

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

--047d7bd74a1cda385305057ee375-- From nobody Wed Oct 15 20:35:23 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA041A014A; Wed, 15 Oct 2014 20:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2QZT2S6_UFLL; Wed, 15 Oct 2014 20:35:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FEC81A0149; Wed, 15 Oct 2014 20:35:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNR79706; Thu, 16 Oct 2014 03:35:17 +0000 (GMT) Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Oct 2014 04:35:17 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Thu, 16 Oct 2014 11:35:11 +0800 From: Bert Greevenbosch To: "apps-discuss@ietf.org" , "iesg@ietf.org" , "draft-ietf-weirds-using-http@ietf.org" Thread-Topic: Applications Area Directorate Review of draft-ietf-weirds-using-http-13 Thread-Index: Ac5oDNerh7dhbvRBRF2N44qjOGB5Zwqdp3dwVXWGgCA= Date: Thu, 16 Oct 2014 03:35:11 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63E774986@SZXEMA510-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.174.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XjbtP2c2T5OpJ2bgszuXQjyTSIw Subject: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-13 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 03:35:21 -0000 Document: draft-ietf-weirds-using-http-13 Title: HTTP usage in the Registration Data Access Protocol (RDAP) Reviewer: Bert Greevenbosch Review Date: 15 October 2014 IETF Last Call Date: 24 October 2014 IESG Telechat Date: 30 October 2014 Summary: Needs edits and maybe removals. Major Issues: (M1) Section 5 is written in an extremely optional way. In addition, it doe= sn't use RFC 2119 conventions. Since section 5 seems to be the main reason = of the draft, I suggest to make it more formal by using RFC 2119 convention= s. This also holds for other parts of the draft. (M2) Section 5.5: "When a server declines to answer a query due to rate lim= its, it returns a 429 response code as described in [RFC6585]." If the clie= nt is really annoying the server with sending many requests, the server sho= uld be allowed to not respond at all. (M3) Section 6: "ABNF for JSON names" Why is this in the "RDAP over HTTP" d= raft? It seems more suitable to go into the "RDAP JSON response" draft, the= "Query" draft or maybe the "Bootstrap" draft. (M4) Appendix C "In some cases, particularly sub-delegations made between R= IRs known as "ERX space" and transfers of networks, multiple HTTP redirects= will be issued.". In addition, section 5.2 states that "If a server wishes= to inform a client that the answer to a given query can be found elsewhere= , it returns either a 301 response code ... and it includes an HTTP(S) URL = in the Location: header field. The client is expected to issue a subsequent= request to satisfy the original query using the given URL without any proc= essing of the URL...". This seems to cater for interesting infinite loops, = when e.g. one server points at another and that other server points at the = first. Maybe something for the security considerations section? Minor Issues: (m1) Section 3: "clients are not expected to fork multiple paths of executi= on to satisfy a query." What does this mean? Please clarify. (m2) Section 5: Maybe add textual descriptions of HTTP errors 302, 303 and = 307, as well as a reference to RFC 7231. (m3) Section 5.4: "If a server receives a query which it cannot interpret a= s an RDAP query, it returns a 400 response code." This makes sense, as long= as the server only supports RDAP. Otherwise, it should be allowed to handl= e non-RDAP requests in another way. (m4) Section 8.1, "RDAP extensions registry". Does this belong in the HTTP = document, or would another RDAP document be more suitable? See also comment= M3. Nits: (n1) In the abstract: "describe" -> "describes". From nobody Wed Oct 15 21:41:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD03C1A01C6; Wed, 15 Oct 2014 21:41:30 -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 7OqAD78wqsfa; Wed, 15 Oct 2014 21:41:28 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840721A01AE; Wed, 15 Oct 2014 21:41:28 -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=1413434488; x=1444970488; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=hZgvQqjeZJ+BymwpxPbAopv2lg7UDfsadalKuEoUxnA=; b=HviFxvYrMJ1vLcUiHrAIjuAkN6svLIcR27xV2GrqlwUgc67lQnCn0GIH WePyYDr68luH+4qSk4WOrn3EwIAB9KkcsTXKICpCTSNxSBgYMSTu1hULC KcQAibcpXVQ4Iga7kCe2YbuCC5iOl8AxNUPg650mbEjU79Cr/iObpPxNj w=; X-IronPort-AV: E=McAfee;i="5600,1067,7592"; a="76815158" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Oct 2014 21:41:27 -0700 X-IronPort-AV: E=Sophos;i="5.04,729,1406617200"; d="scan'208";a="770820611" Received: from nasanexhc11.na.qualcomm.com ([172.30.39.6]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Oct 2014 21:41:27 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc11.na.qualcomm.com (172.30.39.6) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 15 Oct 2014 21:41:27 -0700 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 15 Oct 2014 21:41:08 -0700 Message-ID: <543F4C61.6080207@qti.qualcomm.com> Date: Wed, 15 Oct 2014 23:41:05 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Bert Greevenbosch References: <46A1DF3F04371240B504290A071B4DB63E774986@SZXEMA510-MBX.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63E774986@SZXEMA510-MBX.china.huawei.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.46.200.111) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/VF6Gh6fYWvqSCGLcex3TSDK0b8I Cc: "draft-ietf-weirds-using-http@ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-13 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 04:41:30 -0000 I'll leave it to the authors to answer the other comments, but just on this one. On 10/15/14 10:35 PM, Bert Greevenbosch wrote: > (M1) Section 5 is written in an extremely optional way. In addition, it doesn't use RFC 2119 conventions. Since section 5 seems to be the main reason of the draft, I suggest to make it more formal by using RFC 2119 conventions. This also holds for other parts of the draft. > In general, I disagree with this. If there are places where you see there will be a failure to interoperate, please do point that out and a MUST or MUST NOT can be put in. But if you're talking about things like 5.4 where it says: If a server receives a query which it cannot interpret as an RDAP query, it returns a 400 response code. and you instead want: If a server receives a query which it cannot interpret as an RDAP query, it MUST return a 400 response code. then I disagree completely. There is no interoperability problem with returning a different response code if the server determines that it is doing something special or different. These are describing what *is* done in particular circumstances, defining the circumstances in which some return codes are used, not what is "required for interoperation or to limit behavior which has potential for causing harm". pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Oct 15 21:48:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFBD1A01C6; Wed, 15 Oct 2014 21:48:48 -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 GDOc8NQ_snHC; Wed, 15 Oct 2014 21:48:46 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CE1D1A0187; Wed, 15 Oct 2014 21:48:45 -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=1413434928; x=1444970928; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=qTNTHULQVwsv1LbWIHetSXlEBAjhLllBq5n76vyF+Ww=; b=ESVAJ7y5x5hZ9PQSLYbW0J2Ef1QVN8WLSZEwSALQhDO98KkC+01onPSP 1K8XW6jnqM68JM13hwITBn6HfKyP+KiWbDfoLY7RAOJgKa+5zYBswwLnn HCfWdy05BiFpKk5mCRJAz2qAz239mJe3oLm5FeCQLz/PbPtBQLPxJauMH Q=; X-IronPort-AV: E=McAfee;i="5600,1067,7592"; a="75209044" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine01.qualcomm.com with ESMTP; 15 Oct 2014 21:48:46 -0700 X-IronPort-AV: E=Sophos;i="5.04,729,1406617200"; d="scan'208";a="31538808" Received: from nasanexhc11.na.qualcomm.com ([172.30.39.6]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Oct 2014 21:48:44 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc11.na.qualcomm.com (172.30.39.6) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 15 Oct 2014 21:48:43 -0700 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 15 Oct 2014 21:48:36 -0700 Message-ID: <543F4E17.8050806@qti.qualcomm.com> Date: Wed, 15 Oct 2014 23:48:23 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Bert Greevenbosch References: <46A1DF3F04371240B504290A071B4DB63E774986@SZXEMA510-MBX.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63E774986@SZXEMA510-MBX.china.huawei.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.46.200.111) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hQkaO8ovc85ylfRWfdxrobyx9EE Cc: "iesg@ietf.org" , "apps-discuss@ietf.org" , "draft-ietf-weirds-using-http@tools.ietf.org" Subject: Re: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-13 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 04:48:48 -0000 [Resending to the proper draft address; I'll forward the original as well.] I'll leave it to the authors to answer the other comments, but just on this one. On 10/15/14 10:35 PM, Bert Greevenbosch wrote: > (M1) Section 5 is written in an extremely optional way. In addition, it doesn't use RFC 2119 conventions. Since section 5 seems to be the main reason of the draft, I suggest to make it more formal by using RFC 2119 conventions. This also holds for other parts of the draft. > In general, I disagree with this. If there are places where you see there will be a failure to interoperate, please do point that out and a MUST or MUST NOT can be put in. But if you're talking about things like 5.4 where it says: If a server receives a query which it cannot interpret as an RDAP query, it returns a 400 response code. and you instead want: If a server receives a query which it cannot interpret as an RDAP query, it MUST return a 400 response code. then I disagree completely. There is no interoperability problem with returning a different response code if the server determines that it is doing something special or different. These are describing what *is* done in particular circumstances, defining the circumstances in which some return codes are used, not what is "required for interoperation or to limit behavior which has potential for causing harm". pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Oct 15 22:06:28 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EE81ACECC for ; Wed, 15 Oct 2014 22:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYEku6iPutKE for ; Wed, 15 Oct 2014 22:06:17 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53521A6F0A for ; Wed, 15 Oct 2014 22:06:13 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id pn19so2223895lab.14 for ; Wed, 15 Oct 2014 22:06: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=G2KLPxMy/ctj+vGZC3RBHojgX5mH5JcqQ2NcmzSgKDA=; b=T7PYdXw3tY6jlIz/OgOXwendiiWOEp1BNNhUj37GMDEoI+lrdCwbNzv5JSoWsLfZ8I gdCIcaugMyXNqZZb3IopSftqiLk4usVd0URAc7M3heL2e1JPhQzRuThmZqJSgCd4UrqH ivBXhDRZHKt87otN8if8GFtPmyC6KFwkxJvGgC7/AVrkN6f4b+bTLCNOKdRgxSO+sWoO IY6UQV7iTAgZc05AtK5aDTLjjLMBIk3YKY2C6mw64GszmMeiev+uVk1YKR+RTqLgXVC/ k+5jFwscgdHv7FZxTvMGGMCHyhuwy+ohdDJfOchgIESpNFe8CD6r3i/i6Dt5MJ+wKZov k5fw== MIME-Version: 1.0 X-Received: by 10.112.93.231 with SMTP id cx7mr412561lbb.89.1413435971857; Wed, 15 Oct 2014 22:06:11 -0700 (PDT) Received: by 10.25.211.11 with HTTP; Wed, 15 Oct 2014 22:06:11 -0700 (PDT) In-Reply-To: <768BCB0B-5B09-4297-8C0A-735C15BD657C@seantek.com> References: <768BCB0B-5B09-4297-8C0A-735C15BD657C@seantek.com> Date: Wed, 15 Oct 2014 22:06:11 -0700 Message-ID: From: "Murray S. Kucherawy" To: Sean Leonard Content-Type: multipart/alternative; boundary=001a11348be803f40005058335e6 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/OVPuAzTvRGMYkDqtWvaQvXZjrI0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown progress: recommended split X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 05:06:26 -0000 --001a11348be803f40005058335e6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Oct 15, 2014 at 4:00 PM, Sean Leonard wrote: > I finished the content of draft-03 of the text-markdown spec > (draft-ietf-appsawg-text-markdown-03). > > However, before posting, I would like to see how people feel about a > proposed split in the document. Murray requested WG discussion and > consensus on this before actually doing it. > > I seriously tried to shorten the document, which has been shrunk about 25= % > (~18 pages instead of ~25 pages). However, adding additional registration= s > and Markdown-handling strategies would be beneficial. These additional > registrations and strategies are NOT normative, but they help illustrate > the diversity of use cases that we are *trying* to unify under the common > text/markdown media type. > > The additional registrations (7) and discussion are an additional 18 page= s > or so, including boilerplate. Thus I propose that the subsidiary content = be > split into draft-ietf-appsawg-text-markdown-use-cases-00 (for =E2=80=9Cus= e cases=E2=80=9D). > RFC 2119 key words will not be used in that document. > > Thoughts folks? > My preference would be to focus on the reduced document first and make sure it's self-sufficient. I'm unclear just from your description here what would go into a second document. If it's ready, please post it as draft-leonard-text-markdown-use-cases-00 so the WG can see what you have in mind and then decide if we want to do both of them. (The datatracker won't let you post something as draft-ietf-appsawg-*.) -MSK --001a11348be803f40005058335e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 15, 2014 at 4:00 PM, Sean Leonard <dev+iet= f@seantek.com> wrote:
I finished the content of = draft-03 of the text-markdown spec (draft-ietf-appsawg-text-markdown-03).
However, before posting, I would like to see how people feel about a propos= ed split in the document. Murray requested WG discussion and consensus on t= his before actually doing it.

I seriously tried to shorten the document, which has been shrunk about 25% = (~18 pages instead of ~25 pages). However, adding additional registrations = and Markdown-handling strategies would be beneficial. These additional regi= strations and strategies are NOT normative, but they help illustrate the di= versity of use cases that we are *trying* to unify under the common text/ma= rkdown media type.

The additional registrations (7) and discussion are an additional 18 pages = or so, including boilerplate. Thus I propose that the subsidiary content be= split into draft-ietf-appsawg-text-markdown-use-cases-00 (for =E2=80=9Cuse= cases=E2=80=9D). RFC 2119 key words will not be used in that document.

Thoughts folks?

My preference would be = to focus on the reduced document first and make sure it's self-sufficie= nt.=C2=A0 I'm unclear just from your description here what would go int= o a second document.=C2=A0 If it's ready, please post it as draft-leona= rd-text-markdown-use-cases-00 so the WG can see what you have in mind and t= hen decide if we want to do both of them.=C2=A0 (The datatracker won't = let you post something as draft-ietf-appsawg-*.)

-MSK
=
--001a11348be803f40005058335e6-- From nobody Wed Oct 15 23:54:15 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AC01A0372; Wed, 15 Oct 2014 23:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lBocTdixV3nP; Wed, 15 Oct 2014 23:54:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98BD01A1AE8; Wed, 15 Oct 2014 23:54:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKP31836; Thu, 16 Oct 2014 06:54:08 +0000 (GMT) Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Oct 2014 07:54:07 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Thu, 16 Oct 2014 14:54:00 +0800 From: Bert Greevenbosch To: Pete Resnick Thread-Topic: Applications Area Directorate Review of draft-ietf-weirds-using-http-13 Thread-Index: Ac5oDNerh7dhbvRBRF2N44qjOGB5Zwqdp3dwVXWGgCAAF/MpgAASVGYA Date: Thu, 16 Oct 2014 06:53:59 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63E774BB9@SZXEMA510-MBX.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB63E774986@SZXEMA510-MBX.china.huawei.com> <543F4E17.8050806@qti.qualcomm.com> In-Reply-To: <543F4E17.8050806@qti.qualcomm.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.174.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/dYU5Qm9_OY82lGQ9L1Sfh_X7ss4 Cc: "iesg@ietf.org" , "apps-discuss@ietf.org" , "draft-ietf-weirds-using-http@tools.ietf.org" Subject: Re: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-13 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 06:54:13 -0000 Hi Pete, Thank you for your feedback. I am not a dogmatic RFC 2119 follower, but I think using the keywords from = that RFC has some value. It gives a nice and clean interpretation of used s= tatements. But I admit that there is a certain matter of taste in their usa= ge. In your example, without reading the introduction of section 5, I wouldn't = know whether to rephrase > If a server receives a query which it cannot interpret as an RDAP > query, it returns a 400 response code. to > If a server receives a query which it cannot interpret as an RDAP > query, it MUST return a 400 response code. or to > If a server receives a query which it cannot interpret as an RDAP > query, it SHOULD return a 400 response code. So when we implement an RDAP server, we wouldn't know for certain what we s= hould do in this case. Does the server have to respond with a 400 response = code? Or can it do something else as well, for example sending another erro= r code or not responding at all? If the sentence had a SHOULD, we know we c= an deviate. If it was a MUST, we know we can't. But since the sentence does= n't say either, we can only guess which it is. Safest for client would inde= ed be interpreting the sentence as a SHOULD. However, the introduction of section 5 says: "This section describes the va= rious types of responses a server may send to a client. While no standard H= TTP response code is forbidden in usage, this section defines the minimal s= et of response codes in common use by servers that a client will need to un= derstand." So the alert reader can now that the client needs to be able to = handle at least the rest of section 5, but that the server can deviate from= it when it wishes. In other words, most sentences about the server imply S= HOULDs and MAYs. As I said, I am not dogmatic about this. But I see value in being precise a= nd explicit where we can. :-) Best regards, Bert > -----Original Message----- > From: Pete Resnick [mailto:presnick@qti.qualcomm.com] > Sent: 16 October 2014 12:48 > To: Bert Greevenbosch > Cc: draft-ietf-weirds-using-http@tools.ietf.org; iesg@ietf.org; apps- > discuss@ietf.org > Subject: Re: Applications Area Directorate Review of draft-ietf-weirds- > using-http-13 >=20 > [Resending to the proper draft address; I'll forward the original as > well.] >=20 > I'll leave it to the authors to answer the other comments, but just on > this one. >=20 > On 10/15/14 10:35 PM, Bert Greevenbosch wrote: > > (M1) Section 5 is written in an extremely optional way. In addition, > it doesn't use RFC 2119 conventions. Since section 5 seems to be the > main reason of the draft, I suggest to make it more formal by using RFC > 2119 conventions. This also holds for other parts of the draft. > > >=20 > In general, I disagree with this. If there are places where you see > there will be a failure to interoperate, please do point that out and a > MUST or MUST NOT can be put in. But if you're talking about things like > 5.4 where it says: >=20 > If a server receives a query which it cannot interpret as an RDAP > query, it returns a 400 response code. >=20 > and you instead want: >=20 > If a server receives a query which it cannot interpret as an RDAP > query, it MUST return a 400 response code. >=20 > then I disagree completely. There is no interoperability problem with > returning a different response code if the server determines that it is > doing something special or different. These are describing what *is* > done in particular circumstances, defining the circumstances in which > some return codes are used, not what is "required for interoperation or > to limit behavior which has potential for causing harm". >=20 > pr >=20 > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Oct 16 00:37:40 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B751A038C; Thu, 16 Oct 2014 00:37:38 -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 9BD4ioJLXoUD; Thu, 16 Oct 2014 00:37:34 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FCF21A038B; Thu, 16 Oct 2014 00:37:34 -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=1413445054; x=1444981054; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=WYO3xh3zGn/xTMAwWucwe1S+dz/R31c+98vnj99nJEc=; b=IcqlfuJfJpcjxuPbfR3rDhUCAouSdyhjq6Rqooxrjnlvm+rjZNDw0QZa H2lq5lp3tpXrBVjPMRLVNvFXzjSaPewz0NPR/W2FreapMzEGIUFke1XvQ 7aZCFVZlWxpPcRW1M8Utf0jNXBiJbhBa5RQVoPOGOsWqLZf2VYqu409qp k=; X-IronPort-AV: E=McAfee;i="5600,1067,7592"; a="75251553" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Oct 2014 00:37:33 -0700 X-IronPort-AV: E=Sophos;i="5.04,730,1406617200"; d="scan'208";a="825497958" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Oct 2014 00:37:33 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc08.na.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 16 Oct 2014 00:37:32 -0700 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 16 Oct 2014 00:37:27 -0700 Message-ID: <543F75B4.3010600@qti.qualcomm.com> Date: Thu, 16 Oct 2014 02:37:24 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Bert Greevenbosch References: <46A1DF3F04371240B504290A071B4DB63E774986@SZXEMA510-MBX.china.huawei.com> <543F4E17.8050806@qti.qualcomm.com> <46A1DF3F04371240B504290A071B4DB63E774BB9@SZXEMA510-MBX.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63E774BB9@SZXEMA510-MBX.china.huawei.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (129.46.53.226) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/92iOIf45MRmA1iXLuR8qbEwwaTc Cc: "iesg@ietf.org" , "apps-discuss@ietf.org" , "draft-ietf-weirds-using-http@tools.ietf.org" Subject: Re: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-13 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 07:37:39 -0000 On 10/16/14 1:53 AM, Bert Greevenbosch wrote: > Hi Pete, > > Thank you for your feedback. > > I am not a dogmatic RFC 2119 follower, but I think using the keywords from that RFC has some value. It gives a nice and clean interpretation of used statements. But I admit that there is a certain matter of taste in their usage. > > In your example, without reading the introduction of section 5, Well, that's an interesting premise. :-) > I wouldn't know whether to rephrase > > >> If a server receives a query which it cannot interpret as an RDAP >> query, it returns a 400 response code. >> > to > > >> If a server receives a query which it cannot interpret as an RDAP >> query, it MUST return a 400 response code. >> > or to > > >> If a server receives a query which it cannot interpret as an RDAP >> query, it SHOULD return a 400 response code. >> So, "MUST return a 400" means that if you don't return 400, something bad will happen. "SHOULD return a 400" means that if you don't return 400, something bad will probably happen, but if you understand the ramifications and have good reasons to not return a 400, you might get away with it. "MAY return a 400" means that 400 is one choice (among other unspecified choices) that you can feel free to send. I'd argue that none of those are right. Because of the intro to section 5, we know that nothing bad is going to happen if you send other than 400. The client has to be prepared for anything anyway. So MUST and SHOULD are clearly wrong; no interoperability problem here. But MAY also seems wrong. We're not saying that 400 is as good a choice as anything else you might choose. We're saying that, if you want to be nice and convey a useful message, one that means "I can't interpret the query as an RDAP query", 400 is the right choice. So we say, "If you can't interpret the query, send back a 400." No interoperability requirement there; just telling you what 400 is intended to mean. See section 6 of RFC 7231. It doesn't specify that the server MUST or SHOULD respond with a particular status code; it defines what the codes mean. > So when we implement an RDAP server, we wouldn't know for certain what we should do in this case. Why not? Did you get a query that you couldn't interpret? Send a 400. > Does the server have to respond with a 400 response code? No, of course not. That's why there's no requirement language there. > Or can it do something else as well, for example sending another error code Of course. > or not responding at all? That's probably a violation of HTTP. > If the sentence had a SHOULD, we know we can deviate. No you don't. You only know you can deviate if you have outside knowledge that allows you to deviate. If the spec says SHOULD, it means "that there may exist valid reasons in particular circumstances to ignore" the instruction, but you're doing so at your own peril, and something might blow up if you ignore it. MAY means you can deviate. > If it was a MUST, we know we can't. Right, that there's going to be an interoperability problem or some sort of harm if you don't. > But since the sentence doesn't say either, we can only guess which it is. It's neither. It's simply saying, "If you want to express 'couldn't interpret', send back a 400". > Safest for client would indeed be interpreting the sentence as a SHOULD. > No, the client should be interpreting this as, "If he says 400, he means 'couldn't interpret'". > However, the introduction of section 5 says: "This section describes the various types of responses a server may send to a client. While no standard HTTP response code is forbidden in usage, this section defines the minimal set of response codes in common use by servers that a client will need to understand." So the alert reader can now that the client needs to be able to handle at least the rest of section 5, but that the server can deviate from it when it wishes. Yep. And that's standard behavior for HTTP clients. > In other words, most sentences about the server imply SHOULDs and MAYs. > I disagree. > As I said, I am not dogmatic about this. But I see value in being precise and explicit where we can. :-) > I may or may not be dogmatic about this. :-) But I see value in being precise and explicit where we need to. We are not the protocol police. pr >> -----Original Message----- >> From: Pete Resnick [mailto:presnick@qti.qualcomm.com] >> Sent: 16 October 2014 12:48 >> To: Bert Greevenbosch >> Cc: draft-ietf-weirds-using-http@tools.ietf.org; iesg@ietf.org; apps- >> discuss@ietf.org >> Subject: Re: Applications Area Directorate Review of draft-ietf-weirds- >> using-http-13 >> >> [Resending to the proper draft address; I'll forward the original as >> well.] >> >> I'll leave it to the authors to answer the other comments, but just on >> this one. >> >> On 10/15/14 10:35 PM, Bert Greevenbosch wrote: >> >>> (M1) Section 5 is written in an extremely optional way. In addition, >>> >> it doesn't use RFC 2119 conventions. Since section 5 seems to be the >> main reason of the draft, I suggest to make it more formal by using RFC >> 2119 conventions. This also holds for other parts of the draft. >> >>> >> In general, I disagree with this. If there are places where you see >> there will be a failure to interoperate, please do point that out and a >> MUST or MUST NOT can be put in. But if you're talking about things like >> 5.4 where it says: >> >> If a server receives a query which it cannot interpret as an RDAP >> query, it returns a 400 response code. >> >> and you instead want: >> >> If a server receives a query which it cannot interpret as an RDAP >> query, it MUST return a 400 response code. >> >> then I disagree completely. There is no interoperability problem with >> returning a different response code if the server determines that it is >> doing something special or different. These are describing what *is* >> done in particular circumstances, defining the circumstances in which >> some return codes are used, not what is "required for interoperation or >> to limit behavior which has potential for causing harm". >> >> pr >> >> -- >> Pete Resnick >> Qualcomm Technologies, Inc. - +1 (858)651-4478 >> > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Oct 16 01:04:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2861A0396 for ; Thu, 16 Oct 2014 01:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 96Bvj8bQgVPE for ; Thu, 16 Oct 2014 01:04:34 -0700 (PDT) Received: from BAY004-OMC3S7.hotmail.com (bay004-omc3s7.hotmail.com [65.54.190.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65EC1A0398 for ; Thu, 16 Oct 2014 01:04:34 -0700 (PDT) Received: from BAY405-EAS418 ([65.54.190.188]) by BAY004-OMC3S7.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 16 Oct 2014 01:04:34 -0700 X-TMN: [WsuA/i3d67alPqzr4Z1iUqWQFeOm8tjU] X-Originating-Email: [wongvarit@outlook.co.th] Message-ID: MIME-Version: 1.0 To: From: =?utf-8?B?4Lin4LiH4Lio4LmM4Lin4Lij4Li04LioIOC5gOC4mOC4teC4ouC4o+C5gg==?= =?utf-8?B?4LiK4LiV4Li0?= Date: Thu, 16 Oct 2014 15:04:29 +0700 Content-Type: multipart/alternative; boundary="_9EE578D4-9BD6-43F8-8426-5BC1288B9201_" X-OriginalArrivalTime: 16 Oct 2014 08:04:34.0839 (UTC) FILETIME=[D2DF1A70:01CFE917] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/F4DFI6EgG-yfmxDz-UB6mHF2rRU Subject: [apps-discuss] (no subject) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 08:04:35 -0000 --_9EE578D4-9BD6-43F8-8426-5BC1288B9201_ Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="windows-874" DQoNCsrop6jSoSBXaW5kb3dzIFBob25lIA== --_9EE578D4-9BD6-43F8-8426-5BC1288B9201_ Content-Transfer-Encoding: base64 Content-Type: text/html; charset="windows-874" PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5PjxkaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENh bGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMXB0OyI+PGJyPjxicj7K6Keo0qEgV2luZG93 cyBQaG9uZSA8L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_9EE578D4-9BD6-43F8-8426-5BC1288B9201_-- From nobody Thu Oct 16 02:20:19 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846651A6F9C for ; Thu, 16 Oct 2014 02:20:17 -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 UMFP-66-hUu3 for ; Thu, 16 Oct 2014 02:20:14 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4772C1A6FA3 for ; Thu, 16 Oct 2014 02:20:14 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id s9G9KCUj023015; Thu, 16 Oct 2014 10:20:12 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s9G9KCcL003228; Thu, 16 Oct 2014 10:20:13 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s9G9KBHB025575; Thu, 16 Oct 2014 10:20:11 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id s9G9KAtV025571; Thu, 16 Oct 2014 10:20:10 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Graham Klyne References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> <9AD273B04D7CB4B07CE8D1C5@JcK-HP8200.jck.com> <543CDE33.4030402@ninebynine.org> <01PDQCNHFSIM00005K@mauve.mrochek.com> <543EA941.6030704@ninebynine.org> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 16 Oct 2014 10:20:10 +0100 In-Reply-To: <543EA941.6030704@ninebynine.org> (Graham Klyne's message of "Wed\, 15 Oct 2014 18\:05\:05 +0100") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/euhaaaWDXNlvWhf6qe-mAuSi-lE Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] Fragement identifiers for archives X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 09:20:17 -0000 Graham Klyne writes: > On 14/10/2014 16:37, Ned Freed wrote: >> Very good point. Do you think it would make sense to define a generic >> syntax (which of course could be overridden in specific cases)? > > I think it _could_ be useful and sensible - I've been involved in > design discussions where URI mechanisms to delve inside a composite > package have been raised, and it's been tricky to figure out what > would also play well in a wider web landscape. There has been, and I believe continues to be, _extensive_ discussion of this topic in the W3C TAG. A quick search suggests the most recent discussion was at the F2F in January 2014 [1], which resulted in a writeup from Jeni Tennison which in turn provoked various comments [2] [3]. Please review this record and then coordinate any further substantive work in this area directly with the TAG (of which I am no longer a member). ht [1] http://www.w3.org/2001/tag/2014/01/08-minutes.html#item07 [2] http://lists.w3.org/Archives/Public/www-tag/2014Jan/0133.html [3] http://lists.w3.org/Archives/Public/www-tag/2014Feb/0030.html -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Thu Oct 16 03:39:53 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2051ACFE2 for ; Thu, 16 Oct 2014 03:39:50 -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 LLlndaHxeMW4 for ; Thu, 16 Oct 2014 03:39:49 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F22A1ACFE5 for ; Thu, 16 Oct 2014 03:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1865; q=dns/txt; s=iport; t=1413455985; x=1414665585; h=from:to:cc:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=askLYcFt+V74l6SP/1KcYkM6jGiDQyOBvQ0CvTF1Iuk=; b=KFOCHV5eiKAIG+Veo7yhGBObbRnFACTtvwSO4dZbq4ImIUysP/pGM6Tc T4rd0sKbnxxIINkZwgKLpLygK5/uXyEflaHYoiTwjLHfC09E43AmQ8Xcz QIdIW5Inhfm2wAQILToDu6S1kEHJ0JH8UNQr0FILuqJ8ommxMMoqROfqR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAF2fP1StJV2P/2dsb2JhbABbgmsjU1gEzBiHS4EUFgFyC4QCAQEBAwE6PwULAgEZAwECHxAyHQgCBA4FCRCIHQgBDMoOAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5AsIg2DJ4EeBZF/hESHEoEwPIMKjSeDfoN3bAGBR4ECAQEB X-IronPort-AV: E=Sophos;i="5.04,731,1406592000"; d="scan'208";a="363763510" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP; 16 Oct 2014 10:39:44 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s9GAdiPi026451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Oct 2014 10:39:44 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 05:39:44 -0500 From: "Ali C. Begen (abegen)" To: "apps-discuss@ietf.org" Thread-Topic: URLs and HTTP Response Forms for Multicast Thread-Index: AQHP6S1/v7yRBVVcekyn0Hi62iBDvA== Date: Thu, 16 Oct 2014 10:39:44 +0000 Message-ID: References: <20141016102921.21727.35677.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.148.29.165] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Q-ZBmw5cbTUuayCALW-r7g8LPB0 Subject: [apps-discuss] URLs and HTTP Response Forms for Multicast X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 10:39:50 -0000 Hi everyone, Dave and I submitted a new draft. The idea is make file delivery over multi= cast simple where the delivery protocol has a URL form. We have nice use ca= ses for this where our life could get a lot easier with a multicast URL. The draft is short. While it is still missing some information, the core id= ea is in the draft. http://datatracker.ietf.org/doc/draft-singer-appsawg-mcast-url/ We would certainly welcome your feedback. Time permitting, we also would li= ke to present this in Hawaii. Thanks. -acbegen Begin forwarded message: > From: > Subject: New Version Notification for draft-singer-appsawg-mcast-url-00.t= xt > Date: October 16, 2014 at 12:29:21 PM GMT+2 > To: Dave Singer , David Singer , Ali = Begen , "Ali C. Begen" >=20 >=20 > A new version of I-D, draft-singer-appsawg-mcast-url-00.txt > has been successfully submitted by Ali Begen and posted to the > IETF repository. >=20 > Name: draft-singer-appsawg-mcast-url > Revision: 00 > Title: URLs and HTTP Response Forms for Multicast > Document date: 2014-10-16 > Group: Individual Submission > Pages: 12 > URL: http://www.ietf.org/internet-drafts/draft-singer-appsawg-= mcast-url-00.txt > Status: https://datatracker.ietf.org/doc/draft-singer-appsawg-mca= st-url/ > Htmlized: http://tools.ietf.org/html/draft-singer-appsawg-mcast-url= -00 >=20 >=20 > Abstract: > This document motivates the need for defining a URL for multicast > delivery and provides a proposal for this purpose. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Thu Oct 16 07:53:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CB01A1BE1 for ; Thu, 16 Oct 2014 07:53:24 -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 ghFoMSKAZwxu for ; Thu, 16 Oct 2014 07:53:22 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0118E1A1BDD for ; Thu, 16 Oct 2014 07:53:21 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id pv20so2984919lab.20 for ; Thu, 16 Oct 2014 07:53:20 -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=HFXyYBeisf5ZGxyBtjJXgCFmZBo4k+WbN5nGfr+7dCw=; b=paLMJadQBGjFZdLDlXbTamtzVeywjAZ168maoxvBfoVsGZ4kmVhN9J9OCCDBxQE1hf gjBBnuImfE+uj9+KVqVlFNt72eGS2tGk6N+F384Vocr3Nld1AHiZhOAh6Kb2a6ROVVEU SR8G/XXvXEwaGsFu07iyDsZ1mzPbv3D3cf8wikPNWcIMi9xg1HrvId6mW4fJkzR1ndan EXwDm/XaEBGrO2u5qjygPlbBgR2Ep8Bcbkt1PG5CDLpd+6ReTXzjmhFBCo01RQgqUfO6 VcdGecUkBMoEofwYkLPAHWhRszwnsHQF1AC1R80pz5D9cCJvdiovSOupl2ETewk56La0 8p+w== MIME-Version: 1.0 X-Received: by 10.112.132.104 with SMTP id ot8mr2175032lbb.3.1413471200058; Thu, 16 Oct 2014 07:53:20 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Thu, 16 Oct 2014 07:53:20 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com> References: <20141015183752.37123181C73@rfc-editor.org> <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 16 Oct 2014 10:53:20 -0400 X-Google-Sender-Auth: DRTwXXVxAGhznevoPlzgc9W3VpM Message-ID: From: Barry Leiba To: "Manger, James" Content-Type: multipart/alternative; boundary=047d7b3a7ffec7a3a105058b6824 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/KZA3erl7ZSHowqFQBaqntn4nJzM Cc: "apps-discuss@ietf.org" , "presnick@qti.qualcomm.com" , "paul.hoffman@vpnc.org" , RFC Errata System Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 14:53:24 -0000 --047d7b3a7ffec7a3a105058b6824 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I will mark the report as Verified (and will change it to Technical), but there is no way to have the RFC fixed without a new RFC that obsoletes it. This is all stuff that should be checked in AUTH48, and is why the RFC Editor recommends not relying only on the diff. James, if you want to get it updated tout de suite, you can submit a 7386bis draft, which I will immediately last call. To do the draft, get the final 7386.xml from the RFC Editor, add an "obsoletes=3D7386" at the to= p (and take off the special RFC Editor attributes), make sure all the tabs are replaced by spaces and everything lines up correctly, and add a paragraph to the Abstract and Introduction that says that this is a replacement to RFC 7386 that corrects indentation errors. Make no other changes, and I'll note in the last call note that no other changes are in scope. The replacement RFC will have a new RFC number. Barry On Wednesday, October 15, 2014, Manger, James < James.H.Manger@team.telstra.com> wrote: > Thanks for reporting this as an errata Stephane. "Editorial" is the wrong > classification however; it is "Technical". The indentation is critical to > understanding the function. The function isn't merely to reinforce > normative text -- the function is the only normative specification of the > Merge-Patch processing rules. The other text only gives a casual > description of some rules (in the introduction), calls attention to some > corner cases, and provides examples. > > If the RFC editors cannot correct the indentation, we need a new RFC. > Personally I don't think an accepted errata is sufficient. The doc is too > unusable in its current state. > Can this sort of critical typo be fixed without a new RFC number? > > P.S. Curiously, the "Diff2" format on tools.ietf.org [ > https://tools.ietf.org/rfcdiff?url2=3Drfc7386] shows the indentation as > being correct in rfc7386.txt and draft-ietf-appsawg-json-merge-patch-07. > Probably a tools glitch. > > -- > James Manger > > > -----Original Message----- > From: apps-discuss [mailto:apps-discuss-bounces@ietf.org ] > On Behalf Of RFC Errata System > Sent: Thursday, 16 October 2014 5:38 AM > To: paul.hoffman@vpnc.org ; jasnell@gmail.com ; > barryleiba@computer.org ; presnick@qti.qualcomm.com > ; superuser@gmail.com ; > alexey.melnikov@isode.com > Cc: apps-discuss@ietf.org ; rfc-editor@rfc-editor.org > > Subject: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) > > The following errata report has been submitted for RFC7386, "JSON Merge > Patch". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D7386&eid=3D4132 > > -------------------------------------- > Type: Editorial > Reported by: St=C3=A9phane Bortzmeyer > > > Section: 2 > > Original Text > ------------- > define MergePatch(Target, Patch): > if Patch is an Object: > if Target is not an Object: > Target =3D {} # Ignore the contents and set it to an empty Object > for each Name/Value pair in Patch: > if Value is null: > if Name exists in Target: > remove the Name/Value pair from Target > else: > Target[Name] =3D MergePatch(Target[Name], Value) > return Target > else: > return Patch > > Corrected Text > -------------- > define MergePatch(Target, Patch): > if Patch is an Object: > if Target is not an Object: > Target =3D {} # Ignore the contents and set it to an empty Objec= t > for each Name/Value pair in Patch: > if Value is null: > if Name exists in Target: > remove the Name/Value pair from Target > else: > Target[Name] =3D MergePatch(Target[Name], Value) > return Target > else: > return Patch > > Notes > ----- > Indentation of the pseudo-code example was correct in the Internet-Drafts > but was messed up in the final version. For instance, "Target =3D {}" sh= ould > be under the two ifs. (Reported by James H. Manger on the appsawg mailing > list.) > > 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. > > -------------------------------------- > RFC7386 (draft-ietf-appsawg-json-merge-patch-07) > -------------------------------------- > Title : JSON Merge Patch > Publication Date : October 2014 > Author(s) : P. Hoffman, J. Snell > Category : PROPOSED STANDARD > Source : Applications Area Working Group > Area : Applications > Stream : IETF > Verifying Party : IESG > > --047d7b3a7ffec7a3a105058b6824 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I will mark the report as Verified (and will change it to Technical), but t= here is no way to have the RFC fixed without a new RFC that obsoletes it.= =A0 This is all stuff that should be checked in AUTH48, and is why the RFC = Editor recommends not relying only on the diff.

James, i= f you want to get it updated tout de suite, you can submit a 7386bis draft,= which I will immediately last call.=A0 To do the draft, get the final 7386= .xml from the RFC Editor, add an "obsoletes=3D7386" at the top (a= nd take off the special RFC Editor attributes), make sure all the tabs are = replaced by spaces and everything lines up correctly, and add a paragraph t= o the Abstract and Introduction that says that this is a replacement to RFC= 7386 that corrects indentation errors.=A0 Make no other changes, and I'= ;ll note in the last call note that no other changes are in scope.

The replacement RFC will have a new RFC number.
=
Barry

On Wednesday, October 15, 2014, Manger, James &= lt;James.H.Manger@team.t= elstra.com> wrote:
Thanks for repo= rting this as an errata Stephane. "Editorial" is the wrong classi= fication however; it is "Technical". The indentation is critical = to understanding the function. The function isn't merely to reinforce n= ormative text -- the function is the only normative specification of the Me= rge-Patch processing rules. The other text only gives a casual description = of some rules (in the introduction), calls attention to some corner cases, = and provides examples.

If the RFC editors cannot correct the indentation, we need a new RFC.
Personally I don't think an accepted errata is sufficient. The doc is t= oo unusable in its current state.
Can this sort of critical typo be fixed without a new RFC number?

P.S. Curiously, the "Diff2" format on tools.ietf.org [https://tools.ietf.org/rfcdif= f?url2=3Drfc7386] shows the indentation as being correct in rfc7386.txt= and draft-ietf-appsawg-json-merge-patch-07. Probably a tools glitch.

--
James Manger


-----Original Message-----
From: apps-discuss [mailto:apps-discuss-bounce= s@ietf.org] On Behalf Of RFC Errata System
Sent: Thursday, 16 October 2014 5:38 AM
To: paul.hoffman@vpnc.org; jasnel= l@gmail.com; barryleiba@computer.org; presnick@qti.qualcomm.com; superu= ser@gmail.com; alexey.melnikov@isode.com Cc: apps-discuss@ietf.org; http://www.rfc-editor.org/errata_search.php?rfc= =3D7386&eid=3D4132

--------------------------------------
Type: Editorial
Reported by: St=C3=A9phane Bortzmeyer <bortzmeyer@nic.= fr>

Section: 2

Original Text
-------------
define MergePatch(Target, Patch):
=A0 =A0 =A0 =A0if Patch is an Object:
=A0 =A0 =A0 =A0 =A0if Target is not an Object:
=A0 =A0 =A0 =A0Target =3D {} # Ignore the contents and set it to an empty O= bject
=A0 =A0 =A0 =A0 =A0for each Name/Value pair in Patch:
=A0 =A0 =A0 =A0if Value is null:
=A0 =A0 =A0 =A0 =A0if Name exists in Target:
=A0 =A0 =A0 =A0 =A0 =A0remove the Name/Value pair from Target
=A0 =A0 =A0 =A0else:
=A0 =A0 =A0 =A0 =A0Target[Name] =3D MergePatch(Target[Name], Value)
=A0 =A0 =A0 =A0 =A0return Target
=A0 =A0 =A0 =A0else:
=A0 =A0 =A0 =A0 =A0return Patch

Corrected Text
--------------
=A0 =A0define MergePatch(Target, Patch):
=A0 =A0 =A0if Patch is an Object:
=A0 =A0 =A0 =A0if Target is not an Object:
=A0 =A0 =A0 =A0 =A0Target =3D {} # Ignore the contents and set it to an emp= ty Object
=A0 =A0 =A0 =A0for each Name/Value pair in Patch:
=A0 =A0 =A0 =A0 =A0if Value is null:
=A0 =A0 =A0 =A0 =A0 =A0if Name exists in Target:
=A0 =A0 =A0 =A0 =A0 =A0 =A0remove the Name/Value pair from Target
=A0 =A0 =A0 =A0 =A0else:
=A0 =A0 =A0 =A0 =A0 =A0Target[Name] =3D MergePatch(Target[Name], Value)
=A0 =A0 =A0 =A0return Target
=A0 =A0 =A0else:
=A0 =A0 =A0 =A0return Patch

Notes
-----
Indentation of the pseudo-code example was correct in the Internet-Drafts b= ut was=A0 messed up in the final version. For instance, "Target =3D {}= " should be under the two ifs. (Reported by James H. Manger on the app= sawg mailing list.)

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase use "Reply All" to discuss whether it should be verified or r= ejected. When a decision is reached, the verifying party (IESG) can log in = to change the status and edit the report, if necessary.

--------------------------------------
RFC7386 (draft-ietf-appsawg-json-merge-patch-07)
--------------------------------------
Title=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: JSON Merge Patch
Publication Date=A0 =A0 : October 2014
Author(s)=A0 =A0 =A0 =A0 =A0 =A0: P. Hoffman, J. Snell
Category=A0 =A0 =A0 =A0 =A0 =A0 : PROPOSED STANDARD
Source=A0 =A0 =A0 =A0 =A0 =A0 =A0 : Applications Area Working Group
Area=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Applications
Stream=A0 =A0 =A0 =A0 =A0 =A0 =A0 : IETF
Verifying Party=A0 =A0 =A0: IESG

--047d7b3a7ffec7a3a105058b6824-- From nobody Thu Oct 16 07:56:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE861A1BA7; Thu, 16 Oct 2014 07:56:38 -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 NIy4xj76JnGV; Thu, 16 Oct 2014 07:56:35 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id A488F1A1BED; Thu, 16 Oct 2014 07:56:35 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 11DB9181C6B; Thu, 16 Oct 2014 07:56:31 -0700 (PDT) To: bortzmeyer@nic.fr, paul.hoffman@vpnc.org, jasnell@gmail.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20141016145631.11DB9181C6B@rfc-editor.org> Date: Thu, 16 Oct 2014 07:56:31 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_ac3b27emv1Ssov-0aRXfgMo6W0 Cc: barryleiba@computer.org, iesg@ietf.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Errata Verified] RFC7386 (4132) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 14:56:38 -0000 The following errata report has been verified for RFC7386, "JSON Merge Patch". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7386&eid=4132 -------------------------------------- Status: Verified Type: Technical Reported by: Stéphane Bortzmeyer Date Reported: 2014-10-15 Verified by: Barry Leiba (IESG) Section: 2 Original Text ------------- define MergePatch(Target, Patch): if Patch is an Object: if Target is not an Object: Target = {} # Ignore the contents and set it to an empty Object for each Name/Value pair in Patch: if Value is null: if Name exists in Target: remove the Name/Value pair from Target else: Target[Name] = MergePatch(Target[Name], Value) return Target else: return Patch Corrected Text -------------- define MergePatch(Target, Patch): if Patch is an Object: if Target is not an Object: Target = {} # Ignore the contents and set it to an empty Object for each Name/Value pair in Patch: if Value is null: if Name exists in Target: remove the Name/Value pair from Target else: Target[Name] = MergePatch(Target[Name], Value) return Target else: return Patch Notes ----- Indentation of the pseudo-code example was correct in the Internet-Drafts but was messed up in the final version. For instance, "Target = {}" should be under the two ifs. (Reported by James H. Manger on the appsawg mailing list.) This is a technical erratum, rather than editorial, because the correct indentation is essential to understanding the pseudocode. -------------------------------------- RFC7386 (draft-ietf-appsawg-json-merge-patch-07) -------------------------------------- Title : JSON Merge Patch Publication Date : October 2014 Author(s) : P. Hoffman, J. Snell Category : PROPOSED STANDARD Source : Applications Area Working Group Area : Applications Stream : IETF Verifying Party : IESG From nobody Thu Oct 16 07:58:21 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01551A1BA7 for ; Thu, 16 Oct 2014 07:58:19 -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 Bw0zr8g59Z4G for ; Thu, 16 Oct 2014 07:58:11 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725F21A1A75 for ; Thu, 16 Oct 2014 07:58:11 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id hy10so2828762vcb.2 for ; Thu, 16 Oct 2014 07:58:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=MQ0Dza/FiaUS3l57NHwZtrj9oVEnjz92cuy6iLOrJME=; b=TQVcdyAh9S9YiQJczBrcyvzcE8FI2WHFN0okmj6Ei/+KhlZWgF7cPU9Jzry3reBVcH aKDmpyKmUIVJVY8FpbcqwHk3dq0hJxpSBoUDiDODieIgDwhgwkjjfk4XEHS/ajntJUAM zxBHKtsD4V3q4bt26YOlQjtKqzM03Y7RAuXCvvjwYhYL8WpPOvO2y7ElY3urmzdE4E5P xfF2CRQgodMh+2NXmJSwbbtdKqtIBgRlPZQzNSm01gfhdj/rlrXFvtrapuJojN5GaD81 IRDTkQllmCLa4vZvAc851JCyBKPPnzqgvz7aXq94FM/5MEBkK07BcnnhPVZ1QZbRTz/f 1i/w== X-Gm-Message-State: ALoCoQm1S9JwYsyEL4vVukLPOrunfDvGmcZwmrqRC8rFBOUetmXZmeLlR/Vh3Zo6dcD3oewWATww X-Received: by 10.52.87.142 with SMTP id ay14mr1099746vdb.76.1413471490629; Thu, 16 Oct 2014 07:58:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.160.135 with HTTP; Thu, 16 Oct 2014 07:57:50 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <20141015183752.37123181C73@rfc-editor.org> <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com> From: Tim Bray Date: Thu, 16 Oct 2014 07:57:50 -0700 Message-ID: To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/YNAmifIni5mkHFsQt89KcG0me9U Cc: "presnick@qti.qualcomm.com" , "paul.hoffman@vpnc.org" , "apps-discuss@ietf.org" , RFC Errata System Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 14:58:19 -0000 Yep, what Barry said; this one needs to be re-issued under a new number. On Thu, Oct 16, 2014 at 7:53 AM, Barry Leiba wrot= e: > I will mark the report as Verified (and will change it to Technical), but > there is no way to have the RFC fixed without a new RFC that obsoletes it= . > This is all stuff that should be checked in AUTH48, and is why the RFC > Editor recommends not relying only on the diff. > > James, if you want to get it updated tout de suite, you can submit a 7386= bis > draft, which I will immediately last call. To do the draft, get the fina= l > 7386.xml from the RFC Editor, add an "obsoletes=3D7386" at the top (and t= ake > off the special RFC Editor attributes), make sure all the tabs are replac= ed > by spaces and everything lines up correctly, and add a paragraph to the > Abstract and Introduction that says that this is a replacement to RFC 738= 6 > that corrects indentation errors. Make no other changes, and I'll note i= n > the last call note that no other changes are in scope. > > The replacement RFC will have a new RFC number. > > Barry > > On Wednesday, October 15, 2014, Manger, James > wrote: >> >> Thanks for reporting this as an errata Stephane. "Editorial" is the wron= g >> classification however; it is "Technical". The indentation is critical t= o >> understanding the function. The function isn't merely to reinforce norma= tive >> text -- the function is the only normative specification of the Merge-Pa= tch >> processing rules. The other text only gives a casual description of some >> rules (in the introduction), calls attention to some corner cases, and >> provides examples. >> >> If the RFC editors cannot correct the indentation, we need a new RFC. >> Personally I don't think an accepted errata is sufficient. The doc is to= o >> unusable in its current state. >> Can this sort of critical typo be fixed without a new RFC number? >> >> P.S. Curiously, the "Diff2" format on tools.ietf.org >> [https://tools.ietf.org/rfcdiff?url2=3Drfc7386] shows the indentation as= being >> correct in rfc7386.txt and draft-ietf-appsawg-json-merge-patch-07. Proba= bly >> a tools glitch. >> >> -- >> James Manger >> >> >> -----Original Message----- >> From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of R= FC >> Errata System >> Sent: Thursday, 16 October 2014 5:38 AM >> To: paul.hoffman@vpnc.org; jasnell@gmail.com; barryleiba@computer.org; >> presnick@qti.qualcomm.com; superuser@gmail.com; alexey.melnikov@isode.co= m >> Cc: apps-discuss@ietf.org; rfc-editor@rfc-editor.org >> Subject: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) >> >> The following errata report has been submitted for RFC7386, "JSON Merge >> Patch". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D7386&eid=3D4132 >> >> -------------------------------------- >> Type: Editorial >> Reported by: St=C3=83=C2=A9phane Bortzmeyer >> >> Section: 2 >> >> Original Text >> ------------- >> define MergePatch(Target, Patch): >> if Patch is an Object: >> if Target is not an Object: >> Target =3D {} # Ignore the contents and set it to an empty Object >> for each Name/Value pair in Patch: >> if Value is null: >> if Name exists in Target: >> remove the Name/Value pair from Target >> else: >> Target[Name] =3D MergePatch(Target[Name], Value) >> return Target >> else: >> return Patch >> >> Corrected Text >> -------------- >> define MergePatch(Target, Patch): >> if Patch is an Object: >> if Target is not an Object: >> Target =3D {} # Ignore the contents and set it to an empty Obje= ct >> for each Name/Value pair in Patch: >> if Value is null: >> if Name exists in Target: >> remove the Name/Value pair from Target >> else: >> Target[Name] =3D MergePatch(Target[Name], Value) >> return Target >> else: >> return Patch >> >> Notes >> ----- >> Indentation of the pseudo-code example was correct in the Internet-Draft= s >> but was messed up in the final version. For instance, "Target =3D {}" s= hould >> be under the two ifs. (Reported by James H. Manger on the appsawg mailin= g >> list.) >> >> 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. >> >> -------------------------------------- >> RFC7386 (draft-ietf-appsawg-json-merge-patch-07) >> -------------------------------------- >> Title : JSON Merge Patch >> Publication Date : October 2014 >> Author(s) : P. Hoffman, J. Snell >> Category : PROPOSED STANDARD >> Source : Applications Area Working Group >> Area : Applications >> Stream : IETF >> Verifying Party : IESG >> > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) From nobody Thu Oct 16 09:54:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEBF1A0204; Thu, 16 Oct 2014 09:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQqyIByMMInv; Thu, 16 Oct 2014 09:54:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::762]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5AB81A0181; Thu, 16 Oct 2014 09:53:55 -0700 (PDT) Received: from BN3PR0301CA0076.namprd03.prod.outlook.com (25.160.152.172) by BN3PR0301MB1203.namprd03.prod.outlook.com (25.161.207.156) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Thu, 16 Oct 2014 16:53:32 +0000 Received: from BY2FFO11FD038.protection.gbl (2a01:111:f400:7c0c::116) by BN3PR0301CA0076.outlook.office365.com (2a01:111:e400:401e::44) with Microsoft SMTP Server (TLS) id 15.0.1054.13 via Frontend Transport; Thu, 16 Oct 2014 16:53:32 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD038.mail.protection.outlook.com (10.1.14.223) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Thu, 16 Oct 2014 16:53:31 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0210.003; Thu, 16 Oct 2014 16:52:38 +0000 From: Mike Jones To: Carsten Bormann Thread-Topic: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-algorithms-33 Thread-Index: Ac/oVSxcdPW/TNiPTRiX1p7gtScCIgACOMIAAD/dNXA= Date: Thu, 16 Oct 2014 16:52:37 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB137D2@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439BB0FB8B@TK5EX14MBXC286.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(24454002)(189002)(13464003)(377454003)(377424004)(199003)(51704005)(43784003)(52604005)(243025005)(106466001)(81156004)(50986999)(54356999)(76176999)(23756003)(6806004)(19580395003)(69596002)(19580405001)(21056001)(15975445006)(68736004)(44976005)(84676001)(55846006)(95666004)(107046002)(77096002)(26826002)(99396003)(33656002)(85852003)(87936001)(2656002)(86362001)(4396001)(110136001)(31966008)(120916001)(230783001)(85306004)(15395725005)(15202345003)(104016003)(76482002)(86612001)(50466002)(46102003)(80022003)(66066001)(92726001)(97736003)(92566001)(20776003)(47776003)(64706001)(85806002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1203; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1203; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 036614DD9C Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zROkajyy7lbrKh8PCLRg6kPdO-o Cc: "draft-ietf-jose-json-web-algorithms.all@tools.ietf.org" , "jose@ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-algorithms-33 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 16:54:23 -0000 Replies to your replies are inline below. Thanks again for your thoughtful= and detailed review. -- Mike > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Wednesday, October 15, 2014 2:55 AM > To: Mike Jones > Cc: apps-discuss@ietf.org; draft-ietf-jose-json-web- > algorithms.all@tools.ietf.org; Matt Miller; iesg@ietf.org; jose@ietf.org > Subject: Re: [apps-discuss] Appsdir review for draft-ietf-jose-json-web- > algorithms-33 >=20 > Hi Mike, >=20 > thanks for getting to this review - I don't envy you for this herculean j= ob. > A few more comments/clarifications inline below. >=20 > Gr=FC=DFe, Carsten >=20 > On 15 Oct 2014, at 10:51, Mike Jones wrote: >=20 > > Thanks for your review, Carsten. I apologize for not responding to it = until > now. It had gotten sorted into a folder and I wasn't aware of it until K= athleen > brought it to my attention. Replies are inline below... > > > >> -----Original Message----- > >> From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf > >> Of Carsten Bormann > >> Sent: Thursday, October 02, 2014 12:22 AM > >> To: apps-discuss@ietf.org; draft-ietf-jose-json-web- > >> algorithms.all@tools.ietf.org > >> Cc: iesg@ietf.org; jose@ietf.org > >> Subject: [apps-discuss] Appsdir review for > >> draft-ietf-jose-json-web-algorithms- > >> 33 > >> > >> 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/ApplicationsAreaDirecto > >> rate > >> ). > >> > >> 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-jose-json-web-algorithms-33 > >> Title: JSON Web Algorithms (JWA) > >> Reviewer: Carsten Bormann > >> Review Date: 2014-10-02 > >> IESG Telechat date: 2014-10-02 > >> > >> Summary: This draft is ready for publication as a standards track > >> RFC, with a few nits corrected. > >> > >> However, some additional editorial improvements might improve the > >> security outcome when it is referenced by application developers. > >> > >> Major issues: None. > >> > >> Minor issues: > >> > >> 5.2: > >> Add a reference that defines PKCS #7 padding. > > > > I'll plan on adding a reference to RFC 2315 for this. >=20 > That would work (section reference would be 10.3) Alternatively, you coul= d > reference RFC 5652 (section 6.3), which is an Internet Standard (STD70). >=20 > >> 5.2.2.2 > >> Does "the PKCS #7 padding is removed" entail checking all of its bytes= ? > > > > Should this be changed to "the PKCS #7 padding bytes are checked and th= en > removed"? >=20 > I think it is good to alert the reader to this need. >=20 > >> 6.2.1 > >> Is the intention that the sentence containing "point compression is > >> not supported" also applies to any future registered value of "crv"? > >> A similar comment applies to other specifications in 6.2.1.x, e.g., > >> the reference to SEC1 representation to x and y. > > > > It would apply to any future curves registered that use the "x", "y" po= int > representation. Others could define new key types that use a different > representation or we could refine the definition of "kty":"EC" to make th= e > representation specific to the "crv" value. > > > > A discussion happened on the JOSE thread "JWK Elliptic Curve key > representations and new curves". The conclusion suggested by Richard Bar= nes > and seconded by Stephen Farrell was to table defining any new key > representations for new elliptic curves until the CRFG recommendations to= TLS > have been made. That ended the discussion for now. >=20 > Right, I didn't want to anticipate that discussion; I would be happy if i= t didn't > appear that the avenue for any evolution on point compression/compact poi= nts > were closed. I can add language saying that future curve registrations may use different= parameters to represent the curve value. That may get a little convoluted= because currently it's the "kty" that determines which parameters are used= . But I agree with trying to accommodate new key representations for new c= urves. > >> 6.2.1.1 > >> =BBAdditional "crv" values MAY be > >> used, provided they are understood by implementations using that > >> Elliptic Curve key.=AB How are conflicts between such implementation > >> defined values and future registered values handled? > > > > Conflicts are avoided using the IANA JSON Web Key Elliptic Curve regist= ry > defined in Section 7.6. >=20 > Oh, but that's not what the text says. I read this as a general license = to use > random locally defined crv values. Maybe the need for registration needs= to be > clarified. I'll delete the sentence "Additional 'crv' values MAY be used, provided the= y are understood by implementations using that Elliptic Curve key." The re= gistry is already talked about in the previous sentences. > >> 6.3.2: > >> The MAY accept partially overrides the MUST include? > >> Is the latter thus really a SHOULD? > > > > "d" is REQUIRED. The others SHOULD be included, and if any are include= d, the > others MUST be included. Those are requirements on producers. > > > > Consumers may choose to accept keys that don't include all the CRT > parameters. Given that they can be computed from "n", "e", and "d" and > sometimes they're not available, a previous reviewer had asked this langu= age > about consumers to be included. It's a case of "Be conservative in what = you > send, be liberal in what you accept". >=20 > [I'm not inserting my usual rant here that this bon mot may apply to > implementations, but never to specifications.] >=20 > > It's not clear to me that there's any value in relaxing the requirement= s on > producers. >=20 > Well, if the producer MUST send "all of the others" if "any of the other" > parameters are present, it is not clear to me what the point of "MAY choo= se > to accept an RSA private key that does not contain a complete set of > the private key parameters other than "d"" is other than enabling prod= ucers to > send just that. > (More importantly, it is not clear when a producer should be taking that = license.) I can delete the sentence " The consumer of a JWK MAY choose to accept an R= SA private key that does not contain a complete set of the private key para= meters..." > >> 7.1: > >> It is interesting that a mere registration (vetted only by a DE) can > >> change the IETF consensus base specifications by making an algorithm > "Required". > > > > It is expected that the designated experts will be appointed, in part, = for their > cryptographic expertise. >=20 > There has been more discussion about the requirements levels here that I = don't > want to repeat. > My comment here was that a DE (even with the best crypto knowledge) is in= a > hard place updating the consensus about *desirability of implementation* = - > there are more aspects to this than the technical ones. Thinking about this some more, I agree that "Required" is a special case. = I'm thinking that a reasonable safeguard for this case is to require that a= pproval of both a designated expert and a sitting security area director be= required to make an algorithm "Required" or to change it from "Required" t= o something else. Kathleen and Carsten, would that work for you? > >> 8. > >> I am unable to find a "security considerations" section in NIST SP 800= -38A. > >> 800-38D at least has a "practical considerations" section, is that mea= nt? > >> (Etc., I haven't checked all the references.) In general, I believe a > >> security considerations section is most useful where it provides more > >> directed guidance instead of saying the equivalent of "here is a textb= ook". > > > > There are 14 subsections with directed guidance, plus more in the JWS, = JWE, > and JWK specifications. If there is other directed guidance you'd like t= o see > added, please supply proposed text. > > > > Having skimmed through it, I agree that 800-30A doesn't contain clear e= nough > security guidance to merit inclusion in the list. I'll remove it. If th= ere are other > specifications that you'd like to see added or removed, please let me kno= w. >=20 > This was more of a general comment that "Here is a reference to a textboo= k" > type security considerations are less useful than specific, directed refe= rences. I > haven't checked all those referenced documents, so I'm not in a position = to > recommend changes here. Maybe something for a checklist to apply to the = next > security spec. >=20 > > > >> 8.7 is not clear: is it NOT RECOMMENDED to reuse an entire set of key > >> material (including IV), or to reuse any part of it? > > > > I agree that this is ambiguous, as worded. Its advice seems to be so b= road as > to be impractical, as never reusing a key means that a new key would have= to be > redistributed for each encryption, which then requires a key to use for t= he > distribution... This text came from http://tools.ietf.org/html/draft-mil= ler-jose- > jwe-protected-jwk-02#section-8.1, which was incorporated into the documen= t > after a working group decision to do so. Matt Miller, you were the autho= r of > this text. Could you clarify what the intent was? Thanks. > > > >> Nits/editorial comments: > >> > >> 6.3.2.x: > >> The constant repetition of =BBIt is represented as the base64url > >> encoding of the value's unsigned big endian representation as an octet > sequence. > >> The octet sequence MUST utilize the minimum number of octets to > >> represent the value.=AB almost ensures that an implementer will stop > >> reading the details (well, I did, and I did not write a program to > >> verify the same phrase is used everywhere; if any parameter were > >> using a different encoding, that sure would be missed). Why not defin= e > another abstraction like base64url and use this? > > > > I did just verify that they are all consistent. Yes, if you're reading= the spec > linearly I'm sure it feels repetitive, but if you're an implementer going= straight to > a definition to implement it, having a complete description all in one pl= ace is > valuable. I understand your request but it's not clear to me that this r= ises to the > level that a separate definition that the developer then has to go find i= s > warranted. >=20 > My point was corroborated by the tiny error Richard found. Repeating the= same > information again and again drowns out the important information. A sing= le > paragraph at the end of 6.3's intro of the form: >=20 > Each of the positive integer parameters defined in this section > is represented as the base64url encoding > of the value's unsigned big endian representation as an octet > sequence. The octet sequence MUST utilize the minimum number of > octets to represent the value. OK - I'll see what I can do in this regard. Editorially, it's a little bit= complicated because there are different subsections for public and private= key parameters. > Note that the repetitive text already has a reference that needs to be lo= oked up > in that it uses the term "base64url encoding", which has a slightly refin= ed > meaning here from that in RFC 4648. So an even better way to handle this > would be to add a new term "posint encoding" or some such to section 1.1, > turning e.g. the entirety of 6.3.2.2 into >=20 > The "p" (first prime factor) member contains the first prime f= actor, in > POSINT encoding. >=20 >=20 > > > >> 6.2.3.1: This is not a positive integer? 6.2.3.x mentions this otherw= ise. > > > > I may not understand this remark. I'm guessing you're referring to 6.3= .2.1 and > the fact that the description includes the word "unsigned". This is ther= e to make > it clear that no sign bit will be present in the representation - which i= s especially > important since the high-order bit is always set for "n" and "d" for corr= ectly > generated keys. >=20 > (Sorry, this is indeed about 6.3.2.x, not 6.2.3.x.) That was not what I m= eant: All > 6.3.2.x have the form =BBThe "p" (first prime factor) member contains the= first > prime factor, a positive integer.=AB > 6.3.2.1 does not have the ", a positive integer", but I can't see a reaso= n for that > (d clearly cannot be zero, and it is still an unsigned value). > This is likely to confuse an implementer that reads this text closely. > (And I'm offering the fact that you are overlooking that inconsistency as= another > corroboration of my previous point.) I can delete the unnecessary phrase "a positive integer", subject to how it= does or doesn't fit into the edit above that you asked for. > >> 7.1.1 > >> =BBExample description=AB is not a useful example for an "Algorithm De= scription". > >> (Same comment for 7.x.1.) > > > > See the actual registrations in Section 7.1.2 for more useful examples. >=20 > Maybe just take out the not so useful examples in 7.x.1? All other registration templates that I have seen include examples of all p= arameters. This is only one of the parameters in the template, and all nee= d to be retained. Would you be happier with the e.g. text "Example algorit= hm"? > >> 8.3: > >> s/because it/because it is/ > > > > Good catch > > > >> [sec1] > >> (Given the date, this is probably referencing V2.0 of this spec.) > > > > Hmmm - the version I have cached locally came from > http://www.secg.org/collateral/sec1_final.pdf and is dated September 20, > 2000. But the site appears to be down at present. The version reference= d by > Wikipedia at http://www.secg.org/download/aid-385/sec1_final.pdf is missi= ng > too. http://secg.org/download/aid-780/sec1-v2.pdf is missing too. Can yo= u > point me to a good link? >=20 > I just had a look and embarrassingly found that the copy I'm using comes = from > the personal space of a researcher: > http://perso.univ-rennes1.fr/sylvain.duquesne/master/standards/sec1-v2.pd= f > Not very satisfying as a reference. >=20 > > > > RFC 5915 includes this reference: > > > > [SECG1] Standards for Efficient Cryptography Group (SECG), "SEC 1: > > Elliptic Curve Cryptography", Version 2.0, May 2009. >=20 > That looks good: We don't need a URL, as long as we are certain which ver= sion > we are referencing. >=20 > > Worst comes to worst, I'll either reference that or explicitly referenc= e the 1.0 > version. But if I'm going to reference the 2.0 version, I'd like to be a= ble to read a > copy so that I can verify that the way we're using it is consistent with = the actual > spec, including the section numbers. > > > >> [usascii] > >> The reference to ANSI X3.4:1986 should probably be replaced by a > >> reference to RFC 20. There is little reason to reference a somewhat > >> hard to obtain external document ($60!) when we have an RFC about the > same subject. > > > > OK > > > >> (Tables in Appendix A need some formatting.) > > > > Agreed. It's on my to-do list. Jim Schaad recently told me to "Add a = width > attribute to the ttcol with either "digits" (for fixed width) or "digits%= " (for > percent width) to the column in question". I plan to give it a try. > > > >> _______________________________________________ > >> apps-discuss mailing list > >> apps-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > Thanks again, > > -- Mike > > > > > > From nobody Thu Oct 16 09:59:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806731A0130 for ; Thu, 16 Oct 2014 09:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 LESzqFZLEbwM; Thu, 16 Oct 2014 09:59:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A20001A0162; Thu, 16 Oct 2014 09:59:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-authres-ptypes-registry@tools.ietf.org, scott@kitterman.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141016165934.10259.52125.idtracker@ietfa.amsl.com> Date: Thu, 16 Oct 2014 09:59:34 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/G59N2zsOnJ_u8Sg6cAKqq2LMud8 Subject: [apps-discuss] ID Tracker State Update Notice: 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, 16 Oct 2014 16:59:43 -0000 IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-authres-ptypes-registry/ From nobody Thu Oct 16 10:01:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4521ACDFB for ; Wed, 15 Oct 2014 16:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35] 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 Wb86xIIVVr9m for ; Wed, 15 Oct 2014 16:17:09 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3201ACDFA for ; Wed, 15 Oct 2014 16:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9FNH3lM020603; Thu, 16 Oct 2014 01:17:03 +0200 (CEST) Received: from [192.168.217.145] (p5489134F.dip0.t-ipconnect.de [84.137.19.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 855B8B3D; Thu, 16 Oct 2014 01:17:01 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 16 Oct 2014 01:16:59 +0200 X-Mao-Original-Outgoing-Id: 435107819.678575-08f58fbb3aa9be3f06c605c2515e9501 Content-Transfer-Encoding: quoted-printable Message-Id: <306B15D1-D5F5-46B8-8473-599B3B4667EE@tzi.org> References: <20141015183752.37123181C73@rfc-editor.org> <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/oLLodRpPGT0wyBKQz2Mi58x6Bbg X-Mailman-Approved-At: Thu, 16 Oct 2014 10:01:06 -0700 Cc: "apps-discuss@ietf.org" , "presnick@qti.qualcomm.com" , Paul Hoffman , "barryleiba@computer.org" , RFC Errata System Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 23:17:11 -0000 On 16 Oct 2014, at 01:06, Manger, James = wrote: > P.S. Curiously, the "Diff2" format on tools.ietf.org = [https://tools.ietf.org/rfcdiff?url2=3Drfc7386] shows the indentation as = being correct in rfc7386.txt and draft-ietf-appsawg-json-merge-patch-07. = Probably a tools glitch. This looks like the canonical tab-width confusion. The correct text had a tab-width of 8, but the RFC text was converted to = spaces applying a tab-width of 4. Yep, the copy of rfc7386.xml I have has been tabified, while = draft-ietf-appsawg-json-merge-patch-07.xml is clean. NEVER, EVER, tabify documents. THROW OUT ALL TOOLS THAT DO THIS. (Sorry for shouting, but this TAB nonsense has cost too much time in my = life already.) Gr=FC=DFe, Carsten From nobody Thu Oct 16 10:10:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E271A19EA; Thu, 16 Oct 2014 10:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18n-TU-mcLGi; Thu, 16 Oct 2014 10:10:28 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::729]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9BF21A1A2D; Thu, 16 Oct 2014 10:10:12 -0700 (PDT) Received: from DM2PR03CA0036.namprd03.prod.outlook.com (10.141.96.35) by CY1PR0301MB1212.namprd03.prod.outlook.com (25.161.212.146) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Thu, 16 Oct 2014 17:09:48 +0000 Received: from BL2FFO11FD060.protection.gbl (2a01:111:f400:7c09::117) by DM2PR03CA0036.outlook.office365.com (2a01:111:e400:2428::35) with Microsoft SMTP Server (TLS) id 15.0.1054.13 via Frontend Transport; Thu, 16 Oct 2014 17:09:47 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD060.mail.protection.outlook.com (10.173.161.188) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Thu, 16 Oct 2014 17:09:47 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.193]) with mapi id 14.03.0210.003; Thu, 16 Oct 2014 17:09:06 +0000 From: Mike Jones To: Carsten Bormann Thread-Topic: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-algorithms-33 Thread-Index: Ac/oVSxcdPW/TNiPTRiX1p7gtScCIgACOMIAAD/dNXAAAX+S8A== Date: Thu, 16 Oct 2014 17:09:05 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB139D6@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439BB0FB8B@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(51704005)(52604005)(199003)(377424004)(13464003)(189002)(243025005)(377454003)(24454002)(43784003)(92726001)(15202345003)(87936001)(15975445006)(2656002)(50466002)(86362001)(50986999)(21056001)(99396003)(6806004)(44976005)(4396001)(97736003)(92566001)(85852003)(76176999)(54356999)(69596002)(55846006)(15395725005)(19580405001)(19580395003)(76482002)(85806002)(31966008)(68736004)(64706001)(106466001)(81156004)(66066001)(80022003)(46102003)(20776003)(47776003)(104016003)(26826002)(230783001)(120916001)(85306004)(95666004)(86612001)(84676001)(23756003)(77096002)(33656002)(107046002)(110136001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB1212; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB1212; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 036614DD9C Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/H8Q8RrfQdck3z8GMW3sd1NKtmZA Cc: "draft-ietf-jose-json-web-algorithms.all@tools.ietf.org" , "jose@ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-algorithms-33 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 17:10:33 -0000 Adding one more reply below - this time new proposed text from Matt Miller.= .. -----Original Message----- From: Mike Jones=20 Sent: Thursday, October 16, 2014 9:53 AM To: 'Carsten Bormann' Cc: apps-discuss@ietf.org; draft-ietf-jose-json-web-algorithms.all@tools.ie= tf.org; Matt Miller; iesg@ietf.org; jose@ietf.org Subject: RE: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-alg= orithms-33 Replies to your replies are inline below. Thanks again for your thoughtful= and detailed review. -- Mike > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Wednesday, October 15, 2014 2:55 AM > To: Mike Jones > Cc: apps-discuss@ietf.org; draft-ietf-jose-json-web-=20 > algorithms.all@tools.ietf.org; Matt Miller; iesg@ietf.org;=20 > jose@ietf.org > Subject: Re: [apps-discuss] Appsdir review for=20 > draft-ietf-jose-json-web- > algorithms-33 >=20 > Hi Mike, >=20 > thanks for getting to this review - I don't envy you for this herculean j= ob. > A few more comments/clarifications inline below. >=20 > Gr=FC=DFe, Carsten >=20 > On 15 Oct 2014, at 10:51, Mike Jones wrote: >=20 > > Thanks for your review, Carsten. I apologize for not responding to=20 > > it until > now. It had gotten sorted into a folder and I wasn't aware of it=20 > until Kathleen brought it to my attention. Replies are inline below... > > > >> -----Original Message----- > >> From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf=20 > >> Of Carsten Bormann > >> Sent: Thursday, October 02, 2014 12:22 AM > >> To: apps-discuss@ietf.org; draft-ietf-jose-json-web-=20 > >> algorithms.all@tools.ietf.org > >> Cc: iesg@ietf.org; jose@ietf.org > >> Subject: [apps-discuss] Appsdir review for > >> draft-ietf-jose-json-web-algorithms- > >> 33 > >> > >> I have been selected as the Applications Area Directorate reviewer=20 > >> for this draft (for background on appsdir, please see=20 > >> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirec > >> to > >> rate > >> ). > >> > >> Please resolve these comments along with any other Last Call=20 > >> comments you may receive. Please wait for direction from your=20 > >> document shepherd or AD before posting a new version of the draft. > >> > >> Document: draft-ietf-jose-json-web-algorithms-33 > >> Title: JSON Web Algorithms (JWA) > >> Reviewer: Carsten Bormann > >> Review Date: 2014-10-02 > >> IESG Telechat date: 2014-10-02 > >> > >> Summary: This draft is ready for publication as a standards track=20 > >> RFC, with a few nits corrected. > >> > >> However, some additional editorial improvements might improve the=20 > >> security outcome when it is referenced by application developers. > >> > >> Major issues: None. > >> > >> Minor issues: > >> > >> 5.2: > >> Add a reference that defines PKCS #7 padding. > > > > I'll plan on adding a reference to RFC 2315 for this. >=20 > That would work (section reference would be 10.3) Alternatively, you=20 > could reference RFC 5652 (section 6.3), which is an Internet Standard (ST= D70). >=20 > >> 5.2.2.2 > >> Does "the PKCS #7 padding is removed" entail checking all of its bytes= ? > > > > Should this be changed to "the PKCS #7 padding bytes are checked and=20 > > then > removed"? >=20 > I think it is good to alert the reader to this need. >=20 > >> 6.2.1 > >> Is the intention that the sentence containing "point compression is=20 > >> not supported" also applies to any future registered value of "crv"? > >> A similar comment applies to other specifications in 6.2.1.x, e.g.,=20 > >> the reference to SEC1 representation to x and y. > > > > It would apply to any future curves registered that use the "x", "y"=20 > > point > representation. Others could define new key types that use a=20 > different representation or we could refine the definition of=20 > "kty":"EC" to make the representation specific to the "crv" value. > > > > A discussion happened on the JOSE thread "JWK Elliptic Curve key > representations and new curves". The conclusion suggested by Richard=20 > Barnes and seconded by Stephen Farrell was to table defining any new=20 > key representations for new elliptic curves until the CRFG=20 > recommendations to TLS have been made. That ended the discussion for now= . >=20 > Right, I didn't want to anticipate that discussion; I would be happy=20 > if it didn't appear that the avenue for any evolution on point=20 > compression/compact points were closed. I can add language saying that future curve registrations may use different= parameters to represent the curve value. That may get a little convoluted= because currently it's the "kty" that determines which parameters are used= . But I agree with trying to accommodate new key representations for new c= urves. > >> 6.2.1.1 > >> =BBAdditional "crv" values MAY be > >> used, provided they are understood by implementations using that=20 > >> Elliptic Curve key.=AB How are conflicts between such implementation=20 > >> defined values and future registered values handled? > > > > Conflicts are avoided using the IANA JSON Web Key Elliptic Curve=20 > > registry > defined in Section 7.6. >=20 > Oh, but that's not what the text says. I read this as a general=20 > license to use random locally defined crv values. Maybe the need for=20 > registration needs to be clarified. I'll delete the sentence "Additional 'crv' values MAY be used, provided the= y are understood by implementations using that Elliptic Curve key." The re= gistry is already talked about in the previous sentences. > >> 6.3.2: > >> The MAY accept partially overrides the MUST include? > >> Is the latter thus really a SHOULD? > > > > "d" is REQUIRED. The others SHOULD be included, and if any are=20 > > included, the > others MUST be included. Those are requirements on producers. > > > > Consumers may choose to accept keys that don't include all the CRT > parameters. Given that they can be computed from "n", "e", and "d"=20 > and sometimes they're not available, a previous reviewer had asked=20 > this language about consumers to be included. It's a case of "Be=20 > conservative in what you send, be liberal in what you accept". >=20 > [I'm not inserting my usual rant here that this bon mot may apply to=20 > implementations, but never to specifications.] >=20 > > It's not clear to me that there's any value in relaxing the=20 > > requirements on > producers. >=20 > Well, if the producer MUST send "all of the others" if "any of the other" > parameters are present, it is not clear to me what the point of "MAY choo= se > to accept an RSA private key that does not contain a complete set of > the private key parameters other than "d"" is other than enabling=20 > producers to send just that. > (More importantly, it is not clear when a producer should be taking=20 > that license.) I can delete the sentence " The consumer of a JWK MAY choose to accept an R= SA private key that does not contain a complete set of the private key para= meters..." > >> 7.1: > >> It is interesting that a mere registration (vetted only by a DE)=20 > >> can change the IETF consensus base specifications by making an=20 > >> algorithm > "Required". > > > > It is expected that the designated experts will be appointed, in=20 > > part, for their > cryptographic expertise. >=20 > There has been more discussion about the requirements levels here that=20 > I don't want to repeat. > My comment here was that a DE (even with the best crypto knowledge) is=20 > in a hard place updating the consensus about *desirability of=20 > implementation* - there are more aspects to this than the technical ones. Thinking about this some more, I agree that "Required" is a special case. = I'm thinking that a reasonable safeguard for this case is to require that a= pproval of both a designated expert and a sitting security area director be= required to make an algorithm "Required" or to change it from "Required" t= o something else. Kathleen and Carsten, would that work for you? > >> 8. > >> I am unable to find a "security considerations" section in NIST SP 800= -38A. > >> 800-38D at least has a "practical considerations" section, is that mea= nt? > >> (Etc., I haven't checked all the references.) In general, I believe=20 > >> a security considerations section is most useful where it provides=20 > >> more directed guidance instead of saying the equivalent of "here is a = textbook". > > > > There are 14 subsections with directed guidance, plus more in the=20 > > JWS, JWE, > and JWK specifications. If there is other directed guidance you'd=20 > like to see added, please supply proposed text. > > > > Having skimmed through it, I agree that 800-30A doesn't contain=20 > > clear enough > security guidance to merit inclusion in the list. I'll remove it. If=20 > there are other specifications that you'd like to see added or removed, p= lease let me know. >=20 > This was more of a general comment that "Here is a reference to a textboo= k" > type security considerations are less useful than specific, directed=20 > references. I haven't checked all those referenced documents, so I'm=20 > not in a position to recommend changes here. Maybe something for a=20 > checklist to apply to the next security spec. >=20 > > > >> 8.7 is not clear: is it NOT RECOMMENDED to reuse an entire set of=20 > >> key material (including IV), or to reuse any part of it? > > > > I agree that this is ambiguous, as worded. Its advice seems to be=20 > > so broad as > to be impractical, as never reusing a key means that a new key would=20 > have to be redistributed for each encryption, which then requires a=20 > key to use for the distribution... This text came from=20 > http://tools.ietf.org/html/draft-miller-jose- > jwe-protected-jwk-02#section-8.1, which was incorporated into the=20 > document after a working group decision to do so. Matt Miller, you=20 > were the author of this text. Could you clarify what the intent was? Th= anks. Matt proposed the following revised text. I agree that this is significant= ly clearer and more actionable than the previous version: It is NOT RECOMMENDED to reuse the same entire set of key material (Key Enc= ryption Key, Content Encryption Key, Initialization Vector, etc.) to encrypt multiple JWK or JWK Set objects, or to encrypt the same JW= K or JWK Set object multiple times. One suggestion for preventing re-use i= s to always generate at least one piece of key material for each encryption= operation (e.g., a new Content Encryption Key, a new Initialization Vector= , and/or a new PBES2 Salt), based on the considerations noted in this docum= ent as well as from RFC 4086 [RFC4086]. > >> Nits/editorial comments: > >> > >> 6.3.2.x: > >> The constant repetition of =BBIt is represented as the base64url=20 > >> encoding of the value's unsigned big endian representation as an=20 > >> octet > sequence. > >> The octet sequence MUST utilize the minimum number of octets to=20 > >> represent the value.=AB almost ensures that an implementer will stop=20 > >> reading the details (well, I did, and I did not write a program to=20 > >> verify the same phrase is used everywhere; if any parameter were=20 > >> using a different encoding, that sure would be missed). Why not=20 > >> define > another abstraction like base64url and use this? > > > > I did just verify that they are all consistent. Yes, if you're=20 > > reading the spec > linearly I'm sure it feels repetitive, but if you're an implementer=20 > going straight to a definition to implement it, having a complete=20 > description all in one place is valuable. I understand your request=20 > but it's not clear to me that this rises to the level that a separate=20 > definition that the developer then has to go find is warranted. >=20 > My point was corroborated by the tiny error Richard found. Repeating=20 > the same information again and again drowns out the important=20 > information. A single paragraph at the end of 6.3's intro of the form: >=20 > Each of the positive integer parameters defined in this section > is represented as the base64url encoding > of the value's unsigned big endian representation as an octet > sequence. The octet sequence MUST utilize the minimum number of > octets to represent the value. OK - I'll see what I can do in this regard. Editorially, it's a little bit= complicated because there are different subsections for public and private= key parameters. > Note that the repetitive text already has a reference that needs to be=20 > looked up in that it uses the term "base64url encoding", which has a=20 > slightly refined meaning here from that in RFC 4648. So an even=20 > better way to handle this would be to add a new term "posint encoding"=20 > or some such to section 1.1, turning e.g. the entirety of 6.3.2.2 into >=20 > The "p" (first prime factor) member contains the first=20 > prime factor, in POSINT encoding. >=20 >=20 > > > >> 6.2.3.1: This is not a positive integer? 6.2.3.x mentions this otherw= ise. > > > > I may not understand this remark. I'm guessing you're referring to=20 > > 6.3.2.1 and > the fact that the description includes the word "unsigned". This is=20 > there to make it clear that no sign bit will be present in the=20 > representation - which is especially important since the high-order=20 > bit is always set for "n" and "d" for correctly generated keys. >=20 > (Sorry, this is indeed about 6.3.2.x, not 6.2.3.x.) That was not what=20 > I meant: All 6.3.2.x have the form =BBThe "p" (first prime factor)=20 > member contains the first prime factor, a positive integer.=AB > 6.3.2.1 does not have the ", a positive integer", but I can't see a=20 > reason for that (d clearly cannot be zero, and it is still an unsigned va= lue). > This is likely to confuse an implementer that reads this text closely. > (And I'm offering the fact that you are overlooking that inconsistency=20 > as another corroboration of my previous point.) I can delete the unnecessary phrase "a positive integer", subject to how it= does or doesn't fit into the edit above that you asked for. > >> 7.1.1 > >> =BBExample description=AB is not a useful example for an "Algorithm De= scription". > >> (Same comment for 7.x.1.) > > > > See the actual registrations in Section 7.1.2 for more useful examples. >=20 > Maybe just take out the not so useful examples in 7.x.1? All other registration templates that I have seen include examples of all p= arameters. This is only one of the parameters in the template, and all nee= d to be retained. Would you be happier with the e.g. text "Example algorit= hm"? > >> 8.3: > >> s/because it/because it is/ > > > > Good catch > > > >> [sec1] > >> (Given the date, this is probably referencing V2.0 of this spec.) > > > > Hmmm - the version I have cached locally came from > http://www.secg.org/collateral/sec1_final.pdf and is dated September=20 > 20, 2000. But the site appears to be down at present. The version=20 > referenced by Wikipedia at=20 > http://www.secg.org/download/aid-385/sec1_final.pdf is missing too.=20 > http://secg.org/download/aid-780/sec1-v2.pdf is missing too. Can you poi= nt me to a good link? >=20 > I just had a look and embarrassingly found that the copy I'm using=20 > comes from the personal space of a researcher: > http://perso.univ-rennes1.fr/sylvain.duquesne/master/standards/sec1-v2 > .pdf > Not very satisfying as a reference. >=20 > > > > RFC 5915 includes this reference: > > > > [SECG1] Standards for Efficient Cryptography Group (SECG), "SEC 1: > > Elliptic Curve Cryptography", Version 2.0, May 2009. >=20 > That looks good: We don't need a URL, as long as we are certain which=20 > version we are referencing. >=20 > > Worst comes to worst, I'll either reference that or explicitly=20 > > reference the 1.0 > version. But if I'm going to reference the 2.0 version, I'd like to=20 > be able to read a copy so that I can verify that the way we're using=20 > it is consistent with the actual spec, including the section numbers. > > > >> [usascii] > >> The reference to ANSI X3.4:1986 should probably be replaced by a=20 > >> reference to RFC 20. There is little reason to reference a=20 > >> somewhat hard to obtain external document ($60!) when we have an=20 > >> RFC about the > same subject. > > > > OK > > > >> (Tables in Appendix A need some formatting.) > > > > Agreed. It's on my to-do list. Jim Schaad recently told me to "Add=20 > > a width > attribute to the ttcol with either "digits" (for fixed width) or=20 > "digits%" (for percent width) to the column in question". I plan to give= it a try. > > > >> _______________________________________________ > >> apps-discuss mailing list > >> apps-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > Thanks again, > > -- Mike > > > > > > From nobody Thu Oct 16 10:21:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B0C1A1AC1 for ; Thu, 16 Oct 2014 10:21:03 -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 RHS6NscmRFlJ; Thu, 16 Oct 2014 10:21:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA9A1A1AE5; Thu, 16 Oct 2014 10:20:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-authres-ptypes-registry@tools.ietf.org, scott@kitterman.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141016172053.30473.35297.idtracker@ietfa.amsl.com> Date: Thu, 16 Oct 2014 10:20:53 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/H5BD7jvZIspZ_7Qd9f0xhnbZgK0 Subject: [apps-discuss] ID Tracker State Update Notice: 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, 16 Oct 2014 17:21:03 -0000 IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-authres-ptypes-registry/ From nobody Thu Oct 16 12:35:44 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB4E1A8880 for ; Thu, 16 Oct 2014 12:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.299 X-Spam-Level: X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, 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 f9fJ7D7JIRLL for ; Thu, 16 Oct 2014 12:35:42 -0700 (PDT) Received: from BAY004-OMC3S9.hotmail.com (bay004-omc3s9.hotmail.com [65.54.190.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E9781A8876 for ; Thu, 16 Oct 2014 12:35:42 -0700 (PDT) Received: from BAY405-EAS16 ([65.54.190.187]) by BAY004-OMC3S9.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 16 Oct 2014 12:35:41 -0700 X-TMN: [6v+he57czzTsVQ5yBVmPMy8SBgGUXAcU] X-Originating-Email: [wongvarit@outlook.co.th] Message-ID: MIME-Version: 1.0 To: From: =?utf-8?B?4Lin4LiH4Lio4LmM4Lin4Lij4Li04LioIOC5gOC4mOC4teC4ouC4o+C5gg==?= =?utf-8?B?4LiK4LiV4Li0?= Date: Fri, 17 Oct 2014 02:35:38 +0700 Content-Type: multipart/alternative; boundary="_DC591CC6-8457-4594-808B-2AE5C8739B77_" X-OriginalArrivalTime: 16 Oct 2014 19:35:41.0973 (UTC) FILETIME=[5F359C50:01CFE978] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/LVdVwHuuVx2kE4qdQXwu-dVS4XM Subject: [apps-discuss] (no subject) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 19:35:43 -0000 --_DC591CC6-8457-4594-808B-2AE5C8739B77_ Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="windows-874" DQoNCsrop6jSoSBXaW5kb3dzIFBob25lIA== --_DC591CC6-8457-4594-808B-2AE5C8739B77_ Content-Transfer-Encoding: base64 Content-Type: text/html; charset="windows-874" PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5PjxkaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENh bGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMXB0OyI+PGJyPjxicj7K6Keo0qEgV2luZG93 cyBQaG9uZSA8L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_DC591CC6-8457-4594-808B-2AE5C8739B77_-- From nobody Thu Oct 16 15:28:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549731A8ABB; Thu, 16 Oct 2014 15:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 tFXffnSskFpS; Thu, 16 Oct 2014 15:27:56 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EEE11A8AA6; Thu, 16 Oct 2014 15:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9GMRn2c022319; Fri, 17 Oct 2014 00:27:49 +0200 (CEST) Received: from [192.168.217.113] (p5489167A.dip0.t-ipconnect.de [84.137.22.122]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DA05D444; Fri, 17 Oct 2014 00:27:45 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BB139D6@TK5EX14MBXC286.redmond.corp.microsoft.com> Date: Fri, 17 Oct 2014 00:27:41 +0200 X-Mao-Original-Outgoing-Id: 435191261.752858-76a098b7c358f819acd388a04e12b7b9 Content-Transfer-Encoding: quoted-printable Message-Id: <51142F75-BB77-4177-9206-9DE9FE040617@tzi.org> References: <4E1F6AAD24975D4BA5B16804296739439BB0FB8B@TK5EX14MBXC286.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439BB139D6@TK5EX14MBXC286.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kkQUMYq68W6ANsHLMBt0EE_FozI Cc: "apps-discuss@ietf.org" , "draft-ietf-jose-json-web-algorithms.all@tools.ietf.org" , "iesg@ietf.org" , "jose@ietf.org" Subject: Re: [apps-discuss] [jose] Appsdir review for draft-ietf-jose-json-web-algorithms-33 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 22:27:57 -0000 Hi Mike, without going into a line-by-line, these look like good ways forward. Re the registration example descriptions: What would, for somebody = registering a new algorithm, help most in understanding your intentions = for this field? I think just picking one of the descriptions from the = initial registrations would work here, say "HMAC using SHA-256=94 (or = even "RSAES OAEP using SHA-256 and MGF1 with SHA-256=94). Gr=FC=DFe, Carsten From nobody Thu Oct 16 21:35:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6FD1A90AA for ; Thu, 16 Oct 2014 21:35:45 -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 sBGE6z5rXIGm for ; Thu, 16 Oct 2014 21:35:43 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4506A1A90A8 for ; Thu, 16 Oct 2014 21:35:43 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5382E509B6 for ; Fri, 17 Oct 2014 00:35:42 -0400 (EDT) Message-ID: <54409C51.2030306@seantek.com> Date: Thu, 16 Oct 2014 21:34:25 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: IETF Apps Discuss References: <768BCB0B-5B09-4297-8C0A-735C15BD657C@seantek.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Bdo2AadP5IL6cn45iy9cqJxIqps Subject: Re: [apps-discuss] text/markdown progress: recommended split X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 04:35:45 -0000 On 10/15/2014 4:56 PM, Ira McDonald wrote: > Hi Sean, > > +1 to the split. > > Cheers, > - Ira Ok. To elaborate, the subsidiary document has (will have) the following=20 sections: 1. Dive Into Markdown 1.1. On Formats 1.2. Markdown Design Philosophy 1.3. Uses of Markdown 1.4. Uses of Labeling Markdown Content as text/markdown 2. Strategies for Preserving Media Type and Parameters =E2=80=A6 This section covers strategies for how an application might preserve this metadata= information when it leaves the domain of IETF protocols. 3. Registration Templates for Common Markdown Syntaxes The purpose of this section is to register certain syntaxes because they illustrate particularly interesting use cases or are broadly applicable to the Internet community; thus, these syntaxes would benefit from the level of review associated with publication as IETF documents. 3.1. MultiMarkdown 3.2. GitHub Flavored Markdown 3.3. Pandoc 3.4. Fountain (Fountain.io) 3.5. CommonMark 3.6. kramdown-rfc2629 (Markdown for RFCs) 3.7. rfc7328 (Pandoc2rfc) 4. Examples for Common Markdown Syntaxes This section provides examples of the syntaxes registered in Section = 3. -Sean From nobody Fri Oct 17 07:07:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36EBD1ACD62 for ; Fri, 17 Oct 2014 07:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5W6Fqz4AX8Qb for ; Fri, 17 Oct 2014 07:07:45 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF8E1A0123 for ; Fri, 17 Oct 2014 07:07:45 -0700 (PDT) Received: from [10.0.0.122] (rrcs-67-52-105-34.west.biz.rr.com [67.52.105.34]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s9HE7e9X012091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Oct 2014 07:07:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host rrcs-67-52-105-34.west.biz.rr.com [67.52.105.34] claimed to be [10.0.0.122] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: Date: Fri, 17 Oct 2014 07:07:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <296D4B39-32CA-4F1D-A790-008F87DF8794@vpnc.org> References: <20141015183752.37123181C73@rfc-editor.org> <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com> To: Barry Leiba X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/qHNmCdMY52qgqEIf90L5dMOgNTA Cc: Pete Resnick , "apps-discuss@ietf.org" , RFC Errata System Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 14:07:47 -0000 On Oct 16, 2014, at 7:53 AM, Barry Leiba = wrote: > I will mark the report as Verified (and will change it to Technical), = but there is no way to have the RFC fixed without a new RFC that = obsoletes it. This is all stuff that should be checked in AUTH48, and = is why the RFC Editor recommends not relying only on the diff. I will investigate when the changes happened, and how. I can believe I = missed the changes, but I can also believe that they were introduced = after the AUTH48 review that James and I did. > James, if you want to get it updated tout de suite, you can submit a = 7386bis draft, which I will immediately last call. =20 Barry: this feels terribly inappropriate. We don't need a third author = on the draft to make this one change. James and I can do it. --Paul Hoffman= From nobody Fri Oct 17 07:37:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D761A008A for ; Fri, 17 Oct 2014 07:37:44 -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 768T22rI4aOO for ; Fri, 17 Oct 2014 07:37:43 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 703331A0079 for ; Fri, 17 Oct 2014 07:37:43 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id gm9so824478lab.13 for ; Fri, 17 Oct 2014 07:37:41 -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=dYtGV+RsW34GQvv8l/RLBfd+83sFd7uju27qgpWPkO0=; b=mg41j92FWXNDg/BV31B7UQxHvsDPKUpb3e52lBzWiEyijElDGR4/uw92nUon+FhhjT ShRKze4neNcjgbylUhzWlcKbQgVgh2yMSaKAFPSm9xPQ65eypQAphNMwtZObBh+YIdS4 M/IdXNowSWYhEpOyNTL2jNgIo0QEOBqH3uSwCzOhi2dhC0qyiy1IHNYSdVhaUpMUm/on umSe8lt/DrYmhZ2E3arn+C/ylGzcku/ixdRhiUQQuGbxWmY9U7+qlPZSX33wBcwjB0Ca 59ehj1VEcPrWSCDDdZnD9r6AbaOmR/YhUHDjfalR6INSRRBqDoWcrYMBDrrK09RgjYJv /JNA== MIME-Version: 1.0 X-Received: by 10.152.43.197 with SMTP id y5mr9405491lal.82.1413556661697; Fri, 17 Oct 2014 07:37:41 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Fri, 17 Oct 2014 07:37:41 -0700 (PDT) In-Reply-To: <296D4B39-32CA-4F1D-A790-008F87DF8794@vpnc.org> References: <20141015183752.37123181C73@rfc-editor.org> <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com> <296D4B39-32CA-4F1D-A790-008F87DF8794@vpnc.org> Date: Fri, 17 Oct 2014 10:37:41 -0400 X-Google-Sender-Auth: Cx-Z60F7kL2ao6EclEaVOCKqy8U Message-ID: From: Barry Leiba To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c27e34b0c0d905059f4ef4 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8ErzI0zHWX2xz-4nHqiHplIOH6U Cc: Pete Resnick , "apps-discuss@ietf.org" , RFC Errata System Subject: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 14:37:45 -0000 --001a11c27e34b0c0d905059f4ef4 Content-Type: text/plain; charset=ISO-8859-1 > > I will investigate when the changes happened, and how. I can believe I > missed the changes, but I can also believe that they were introduced after > the AUTH48 review that James and I did. Certainly possible. It's hard to tell, because there's no iterative record of the versions during and after AUTH48. > > James, if you want to get it updated tout de suite, you can submit a > 7386bis draft, which I will immediately last call. > > Barry: this feels terribly inappropriate. We don't need a third author on > the draft to make this one change. James and I can do it. > Of course you're right about that. I was just confused about which James was which -- I'm travelling, iPad only, and didn't look closely enough at who the 7386 authors are. So, yes, of course one of the 7386 authors should do this, not James Manger. Barry --001a11c27e34b0c0d905059f4ef4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I will investigate when the changes happened= , and how. I can believe I missed the changes, but I can also believe that = they were introduced after the AUTH48 review that James and I did.

Certainly possible.=A0 It's hard to tell, becau= se there's no iterative record of the versions during and after AUTH48.=
=A0
> James, if you want = to get it updated tout de suite, you can submit a 7386bis draft, which I wi= ll immediately last call.

Barry: this feels terribly inappropriate. We don't need a third author = on the draft to make this one change. James and I can do it.

Of course you're right about that.=A0 I was just = confused about which James was which -- I'm travelling, iPad only, and = didn't look closely enough at who the 7386 authors are.=A0 So, yes, of = course one of the 7386 authors should do this, not James Manger.
=
Barry

--001a11c27e34b0c0d905059f4ef4-- From nobody Fri Oct 17 09:44:49 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8729A1A6F11 for ; Fri, 17 Oct 2014 09:44:46 -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 wPbUPCXz6Fec for ; Fri, 17 Oct 2014 09:44:43 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id EF1B61A6F01 for ; Fri, 17 Oct 2014 09:44:42 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 6000) id D3337181C99; Fri, 17 Oct 2014 09:44:34 -0700 (PDT) Date: Fri, 17 Oct 2014 09:44:34 -0700 From: RFC Editor To: Barry Leiba Message-ID: <20141017164434.GA9526@rfc-editor.org> References: <20141015183752.37123181C73@rfc-editor.org> <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com> <296D4B39-32CA-4F1D-A790-008F87DF8794@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/L5T3qxzlCJzkMKF3O6XThzSm5Sk Cc: Pete Resnick , Paul Hoffman , "apps-discuss@ietf.org" , RFC Editor Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 16:44:46 -0000 Greetings All, We've been investigating how this error crept in on our end so we can explain and understand how to avoid a similar issue in the future. After reviewing the files and running a copy of the .xml through xml2rfc, we think there may be an error with xml2rfc. In the XML file we have archived, we see the following:
define MergePatch(Target, Patch): if Patch is an Object: if Target is not an Object: Target = {} # Ignore the contents and set it to an empty Object for each Name/Value pair in Patch: if Value is null: if Name exists in Target: remove the Name/Value pair from Target else: Target[Name] = MergePatch(Target[Name], Value) return Target else: return Patch
which produces the following text: define MergePatch(Target, Patch): if Patch is an Object: if Target is not an Object: Target = {} # Ignore the contents and set it to an empty Object for each Name/Value pair in Patch: if Value is null: if Name exists in Target: remove the Name/Value pair from Target else: Target[Name] = MergePatch(Target[Name], Value) return Target else: return Patch and also produces the following .nroff: define MergePatch(Target, Patch): if Patch is an Object: if Target is not an Object: Target = {} # Ignore the contents and set it to an empty Object for each Name/Value pair in Patch: if Value is null: if Name exists in Target: remove the Name/Value pair from Target else: Target[Name] = MergePatch(Target[Name], Value) return Target else: return Patch We believe Carsten has submitted a ticket to have this corrected; see . Until a fix has been implemented, we will be careful to checkthe indentation of artwork. Thank you, RFC Editor/sg On Fri, Oct 17, 2014 at 10:37:41AM -0400, Barry Leiba wrote: > > > > I will investigate when the changes happened, and how. I can believe I > > missed the changes, but I can also believe that they were introduced after > > the AUTH48 review that James and I did. > > > Certainly possible. It's hard to tell, because there's no iterative record > of the versions during and after AUTH48. > > > > > James, if you want to get it updated tout de suite, you can submit a > > 7386bis draft, which I will immediately last call. > > > > Barry: this feels terribly inappropriate. We don't need a third author on > > the draft to make this one change. James and I can do it. > > > > Of course you're right about that. I was just confused about which James > was which -- I'm travelling, iPad only, and didn't look closely enough at > who the 7386 authors are. So, yes, of course one of the 7386 authors > should do this, not James Manger. > > Barry From nobody Fri Oct 17 09:48:44 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBB31A3B9C for ; Fri, 17 Oct 2014 09:48:43 -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 hHpSUn3Z5-1C for ; Fri, 17 Oct 2014 09:48:41 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E871A1B68 for ; Fri, 17 Oct 2014 09:48:41 -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=1413564521; x=1445100521; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lzTX7377OBeaNz/cihy9jVGu+bu0XoQPGKVf4KbwcXU=; b=bnxLLtkuehZ6PV7Nv1b3lZT6/qqHuH7c0wugZZS3IvSNaZGMqumticNJ LIFOdXe60l7cbuxrRlGi5t5oh0o4JOMzax9lSf3JWebIdc3z8Y/nmF3ao DMX+2pDR2zGhuK0tnnzh/yGxeNT46JGKPBuQ64OL4cCQKih0g1fkBiI+A Y=; X-IronPort-AV: E=McAfee;i="5600,1067,7594"; a="76297102" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth01.qualcomm.com with ESMTP; 17 Oct 2014 09:48:41 -0700 X-IronPort-AV: E=Sophos;i="5.04,740,1406617200"; d="scan'208";a="31552027" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 17 Oct 2014 09:48:40 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc08.na.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 17 Oct 2014 09:48:39 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 17 Oct 2014 09:48:39 -0700 Message-ID: <54414865.4020207@qti.qualcomm.com> Date: Fri, 17 Oct 2014 11:48:37 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <20141015183752.37123181C73@rfc-editor.org> <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.46.201.192) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/FvU-Lu6EhECMDXmO-dpyvIb6InI Cc: "apps-discuss@ietf.org" , "paul.hoffman@vpnc.org" , RFC Errata System Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 16:48:43 -0000 On 10/16/14 9:53 AM, Barry Leiba wrote: > To do the draft, get the final 7386.xml from the RFC Editor, add an > "obsoletes=7386" at the top (and take off the special RFC Editor > attributes), make sure all the tabs are replaced by spaces and > everything lines up correctly, and add a paragraph to the Abstract and > Introduction that says that this is a replacement to RFC 7386 that > corrects indentation errors. Make no other changes, and I'll note in > the last call note that no other changes are in scope. There are examples where the spacing also go screwed up. I hope you didn't mean to put those into the "no other changes" category. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Fri Oct 17 09:53:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAFC1A1BD6 for ; Fri, 17 Oct 2014 09:53:02 -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 WpQxpCPcNID3 for ; Fri, 17 Oct 2014 09:53:01 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B36F61A1AEA for ; Fri, 17 Oct 2014 09:53:00 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id p9so998795lbv.5 for ; Fri, 17 Oct 2014 09:52: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; bh=s0LG65C6dA64WGtfI4PY6awshYj4jMK/XBtUnwf+uYA=; b=IRBoUQewowM7nKSD1EDJ5E0zN5+pYeGov4dazh2qhYcdzZwqf8luUYyMyk7uHSdgYe hSAQhLlzJnh9d4Nwv1ZG5KEa8mSC2H5gPakR7kLl2snf4HeOW3sUeXzCrZFTLiL9XAHI 61IsJey5/v3Z81FTLpEs2onVZKhgft0CKR1FoKvx/GCrVeodz+PSOIYmvkEiLAJQlIYN jPimuEbp6DG3CtK9df3HinZRlPfS7T63D0u7rU8GOp3rnbhp26fyj7ze9JIQEo2taYYu JOV8xviaRvb+nVyLu1hfHWM2zfoLSu8J4+fhAQ/L9UzvtaFvUHXXwYneyIEiWxp7Ipha LvGQ== MIME-Version: 1.0 X-Received: by 10.152.4.132 with SMTP id k4mr10109701lak.1.1413564778582; Fri, 17 Oct 2014 09:52:58 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Fri, 17 Oct 2014 09:52:58 -0700 (PDT) In-Reply-To: <54414865.4020207@qti.qualcomm.com> References: <20141015183752.37123181C73@rfc-editor.org> <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com> <54414865.4020207@qti.qualcomm.com> Date: Fri, 17 Oct 2014 12:52:58 -0400 X-Google-Sender-Auth: g71nnJLJD57Q7Ti3n3g5vK9deIo Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: multipart/alternative; boundary=089e013d1b5e7e99bf0505a132e9 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/CwabVVwAG3YUDvOB_3ETCGy9qpo Cc: "apps-discuss@ietf.org" , "paul.hoffman@vpnc.org" , RFC Errata System Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 16:53:02 -0000 --089e013d1b5e7e99bf0505a132e9 Content-Type: text/plain; charset=ISO-8859-1 No: I meant to correct all the indentation/spacing issues, but only those. On Friday, October 17, 2014, Pete Resnick wrote: > On 10/16/14 9:53 AM, Barry Leiba wrote: > >> To do the draft, get the final 7386.xml from the RFC Editor, add an >> "obsoletes=7386" at the top (and take off the special RFC Editor >> attributes), make sure all the tabs are replaced by spaces and everything >> lines up correctly, and add a paragraph to the Abstract and Introduction >> that says that this is a replacement to RFC 7386 that corrects indentation >> errors. Make no other changes, and I'll note in the last call note that no >> other changes are in scope. >> > > There are examples where the spacing also go screwed up. I hope you didn't > mean to put those into the "no other changes" category. > > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > --089e013d1b5e7e99bf0505a132e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No: I meant to correct all the indentation/spacing issues, but only those.<= span>

On Friday, October 17, 2014, Pete Resnick <presnick@qti.qualcomm.com> wro= te:
On 10/16/14 9:53 AM, Barry Leiba wrot= e:
To do the draft, get the final 7386.xml from the RFC Editor, add an "o= bsoletes=3D7386" at the top (and take off the special RFC Editor attri= butes), make sure all the tabs are replaced by spaces and everything lines = up correctly, and add a paragraph to the Abstract and Introduction that say= s that this is a replacement to RFC 7386 that corrects indentation errors.= =A0 Make no other changes, and I'll note in the last call note that no = other changes are in scope.

There are examples where the spacing also go screwed up. I hope you didn= 9;t mean to put those into the "no other changes" category.

pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

--089e013d1b5e7e99bf0505a132e9-- From nobody Fri Oct 17 11:03:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019EB1A0077 for ; Fri, 17 Oct 2014 11:03:06 -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 QSfeHZu08gcL for ; Fri, 17 Oct 2014 11:03:04 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9BE1A0007 for ; Fri, 17 Oct 2014 11:03:04 -0700 (PDT) Received: from [192.168.123.119] (unknown [23.240.242.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7E8EF50A86; Fri, 17 Oct 2014 14:03:01 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_CE63ED5B-632A-4DB2-B511-A17195FE1674"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: internet-drafts@ietf.org Resent-From: Sean Leonard Date: Fri, 17 Oct 2014 10:40:51 -0700 Resent-Date: Fri, 17 Oct 2014 11:02:28 -0700 Resent-To: media-types@iana.org, IETF Apps Discuss Message-Id: <20141017174051.17749.68412.idtracker@ietfa.amsl.com> To: Sean Leonard , "Sean Leonard" X-Mailer: Apple Mail (2.1878.6) Resent-Message-Id: <20141017180302.7E8EF50A86@mxout-08.mxes.net> Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/arMnwGHF754_sbchFe3_mHO7uIU Subject: [apps-discuss] New Version Notification for draft-seantek-image-wmf-emf-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:03:06 -0000 --Apple-Mail=_CE63ED5B-632A-4DB2-B511-A17195FE1674 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Colleagues: An Internet-Draft to register image/wmf and image/emf has been posted. Thanks to Alexey Melnikov and Dave Thaler, who provided advice on these = drafts prior to submission. Feedback welcome. Regards, Sean ******************* A new version of I-D, draft-seantek-image-wmf-emf-00.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-seantek-image-wmf-emf Revision: 00 Title: The Windows Metafile and Enhanced Metafile Media Types Document date: 2014-10-17 Group: Individual Submission Pages: 8 URL: = http://www.ietf.org/internet-drafts/draft-seantek-image-wmf-emf-00.txt Status: = https://datatracker.ietf.org/doc/draft-seantek-image-wmf-emf/ Htmlized: = http://tools.ietf.org/html/draft-seantek-image-wmf-emf-00 Abstract: This document registers the image/wmf and image/emf media types for use with Windows Metafile and Enhanced Metafile formats. Originally designed for Microsoft Windows 3.0, these image files are intended to be portable between applications and devices, and may contain both vector and raster graphics. Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --Apple-Mail=_CE63ED5B-632A-4DB2-B511-A17195FE1674 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO7TCCBJ0w ggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsG AQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlfsXzw PlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1ctxE +2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj2iC0 o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRowggQCoAMCAQICEG0Z 6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAw NTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdC lOD5J3EHxcZppLkyxPFAGpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh3 37EXrMLaggLW1DJq1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJA AVtIaN3FSrTg7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJy ZCaRTqWSD//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOC AUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEE aDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF0q0bc24+6SZ85kyY wTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6L566k3nK/uKRHlZ0sviN 0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6 PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrR eTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqT PDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0EwHhcNMTMxMTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J 9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2g uKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G 53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia33JN+ oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5j b20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50 ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMf WE2/5myX518DB+kTa5iQDbKYRuJp3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmI H4kfI4LWrY8XrPhlX3JmHjD6hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3 jx9VF/gA3vqYpL+jNumInz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d 9ljRDEiAts5OopkeeFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYID rjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggHZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MTAxNzE4MDMwMlowIwYJKoZIhvcNAQkEMRYEFIaE0QPmQh815h+0FnDD6MTq RiKOMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQDKkzwxu6lupsyQvhKSvQd8MIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEBBQAE ggEAoqqQWATAckBb7zsR2raSDEw1Cv+t5ZMiP3QYrNRiF0zRMb6JQCMOs4OIxAFyHR+SPM0vklsV I3Cg6ZTQ+C6latR/9m6ypbxSSnjlSl7Isk2xXmcl+G+RE95yXu4XfM1M38G3m0KnRcbhHQw585hU QkQHWkWAL40JsbK3qYFeFe3pfuE/LI9UR/t3HP/ERfDXe9rP4plB74iU+6EmJYZXfJKEZ/dZ0yWz DTr5dGDFKq1JC8CVH7rF2CzjAfwPZaDqUTXs2T0DKVJLf2UzzI5n+oVxkF61yEYrJZtAeXyGGk25 fHyNC9yUKI/D0bi3+N4IGbx1BAJja3VEADPFz6jpsAAAAAAAAA== --Apple-Mail=_CE63ED5B-632A-4DB2-B511-A17195FE1674-- From nobody Fri Oct 17 11:10:50 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535741A004B for ; Fri, 17 Oct 2014 11:10:42 -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 n3KcLT_Imd7z for ; Fri, 17 Oct 2014 11:10:35 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9287B1A0037 for ; Fri, 17 Oct 2014 11:10:10 -0700 (PDT) Received: from [192.168.123.119] (unknown [23.240.242.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DDA0950A73; Fri, 17 Oct 2014 14:10:08 -0400 (EDT) From: Sean Leonard Content-Type: multipart/signed; boundary="Apple-Mail=_86E7A1B7-79CD-4A9A-8B88-DEF6C9641D41"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <17250A28-F165-4F31-B65F-9E78CC73D74E@seantek.com> Date: Fri, 17 Oct 2014 11:08:25 -0700 To: media-types@iana.org, IETF Apps Discuss Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/E4GiWuRxYrEfzXpf-l0RGuGzRpE Subject: [apps-discuss] image/wmf and image/emf: New Version Notification for draft-seantek-image-wmf-emf-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:10:42 -0000 --Apple-Mail=_86E7A1B7-79CD-4A9A-8B88-DEF6C9641D41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Colleagues: An Internet-Draft to register image/wmf and image/emf has been posted. Thanks to Alexey Melnikov and Dave Thaler, who provided advice on these = drafts prior to submission. Feedback welcome. Regards, Sean ******************* A new version of I-D, draft-seantek-image-wmf-emf-00.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-seantek-image-wmf-emf Revision: 00 Title: The Windows Metafile and Enhanced Metafile Media Types Document date: 2014-10-17 Group: Individual Submission Pages: 8 URL: = http://www.ietf.org/internet-drafts/draft-seantek-image-wmf-emf-00.txt Status: = https://datatracker.ietf.org/doc/draft-seantek-image-wmf-emf/ Htmlized: = http://tools.ietf.org/html/draft-seantek-image-wmf-emf-00 Abstract: This document registers the image/wmf and image/emf media types for use with Windows Metafile and Enhanced Metafile formats. Originally designed for Microsoft Windows 3.0, these image files are intended to be portable between applications and devices, and may contain both vector and raster graphics. Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat= --Apple-Mail=_86E7A1B7-79CD-4A9A-8B88-DEF6C9641D41 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO7TCCBJ0w ggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsG AQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlfsXzw PlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1ctxE +2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj2iC0 o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRowggQCoAMCAQICEG0Z 6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAw NTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdC lOD5J3EHxcZppLkyxPFAGpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh3 37EXrMLaggLW1DJq1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJA AVtIaN3FSrTg7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJy ZCaRTqWSD//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOC AUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEE aDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF0q0bc24+6SZ85kyY wTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6L566k3nK/uKRHlZ0sviN 0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6 PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrR eTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqT PDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0EwHhcNMTMxMTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J 9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2g uKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G 53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia33JN+ oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5j b20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50 ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMf WE2/5myX518DB+kTa5iQDbKYRuJp3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmI H4kfI4LWrY8XrPhlX3JmHjD6hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3 jx9VF/gA3vqYpL+jNumInz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d 9ljRDEiAts5OopkeeFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYID rjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggHZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MTAxNzE4MTAwOFowIwYJKoZIhvcNAQkEMRYEFD3ZjzaThQ+AZ/MtaulpFAGs 9U4vMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQDKkzwxu6lupsyQvhKSvQd8MIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEBBQAE ggEAHihUfTRvEAN92Go+hYHlhhdxVx1bLlju7xXz/bXeSKGGIOGCFmef1ILWhVMECMLDwfwN5G0P 2qSFJ0aLUBh/yAUZiKqYneQ1QEfJJSG+F2aXDGNxU9XNiBATcYzTS47Zj+pMJsoubh0BdpvfhlST 9zWGw/pH0UkkDu5N64QpoWMBzb7HVDzfGMxMzy3UCI513vxS1kVR2F+HMSKKMW6wh0XIvTRcoCa1 X5dmbpP0bA44mL5/Z8D/1jnLPtg4BZjJQeSOtkaKZXggEhLEMmmPYlzsFmQxEmrqp6oAxKPki0G6 gWRu/jhhIuS9mHI2a+tDD2IfA5FKw6gAGMweK8GopgAAAAAAAA== --Apple-Mail=_86E7A1B7-79CD-4A9A-8B88-DEF6C9641D41-- From nobody Fri Oct 17 11:11:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AA81A0030 for ; Fri, 17 Oct 2014 11:11:35 -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 gNqESpwaln9W for ; Fri, 17 Oct 2014 11:11:28 -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 D9AFD1A0024 for ; Fri, 17 Oct 2014 11:11:27 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XfBzk-000GMS-VB; Fri, 17 Oct 2014 14:11:20 -0400 Date: Fri, 17 Oct 2014 14:11:15 -0400 From: John C Klensin To: RFC Editor , Barry Leiba , Pete Resnick Message-ID: In-Reply-To: <20141017164434.GA9526@rfc-editor.org> References: <20141015183752.37123181C73@rfc-editor.org> <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com> <296D4B39-32CA-4F1D-A790-008F87DF8794@vpnc.org> <20141017164434.GA9526@rfc-editor.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zzSvbKyoUXAWr0l-HKeOmkB9I-w Cc: Paul Hoffman , apps-discuss@ietf.org Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 18:11:35 -0000 --On Friday, October 17, 2014 09:44 -0700 RFC Editor wrote: > We've been investigating how this error crept in on our end so > we can explain and understand how to avoid a similar issue in > the future. After reviewing the files and running a copy of > the .xml through xml2rfc, we think there may be an error with > xml2rfc. >... On 10/16/14 9:53 AM, Barry Leiba wrote: > To do the draft, get the final 7386.xml from the RFC Editor, add an > "obsoletes=7386" at the top (and take off the special RFC Editor > attributes), make sure all the tabs are replaced by spaces and > everything lines up correctly, and add a paragraph to the Abstract and > Introduction that says that this is a replacement to RFC 7386 that > corrects indentation errors. Make no other changes, and I'll note in > the last call note that no other changes are in scope. Folks, I don't know whether it is less painful to do a narrow Last Call or to risk opening a can of worms, but my recollection is that there have been a few times in which the RFC Editor has simply issued a replacement document with a new number to correct editing or formatting problems with the earlier document. The principle that justified that action would seem to apply here, so maybe the right solution is Just Do It with the "Obsoletes" field as above and a status note from the RFC Editor explaining the change. No need to waste community or IESG time on a vacuous LC and the further advantage of getting the replacement document up a lot sooner. I also observe that 7386 appears to be the highest-numbered RFC issued to date. If other things are not already well along in the pipe, it would be nice to reserve 7387 for this revised version, leaving them consecutive in various indices. john p.s. to RFC Editor: you can incorporate several years of comments about the use of generic markup (e.g., xml2rfc) as a final formatting specification in lieu of observations about the causes and history of this problem. From nobody Fri Oct 17 11:18:15 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5916D1A0069 for ; Fri, 17 Oct 2014 11:18:13 -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 FlmGh8SUR4Iw for ; Fri, 17 Oct 2014 11:18:11 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4955C1A0007 for ; Fri, 17 Oct 2014 11:18:11 -0700 (PDT) Received: from [192.168.123.119] (unknown [23.240.242.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C49BA50A86; Fri, 17 Oct 2014 14:18:09 -0400 (EDT) From: Sean Leonard Content-Type: multipart/signed; boundary="Apple-Mail=_3991B61C-8D59-4C75-B6AB-5AB505E827EB"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <469C8ADC-97AF-49FA-AEE0-15F59EC39A6F@seantek.com> Date: Fri, 17 Oct 2014 11:17:37 -0700 To: media-types@iana.org, IETF Apps Discuss Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/2iaiW88Qw3ayr7l_1c7sJg0LQzY Subject: [apps-discuss] image/bmp: New Version Notification for draft-seantek-image-bmp-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:18:13 -0000 --Apple-Mail=_3991B61C-8D59-4C75-B6AB-5AB505E827EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Colleagues: An Internet-Draft to register image/bmp has been posted. Thanks to Alexey Melnikov and Dave Thaler, who provided advice on these = drafts prior to submission. Feedback welcome. Regards, Sean ******************* A new version of I-D, draft-seantek-image-bmp-00.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-seantek-image-bmp Revision: 00 Title: The Windows Bitmap Media Type Document date: 2014-10-17 Group: Individual Submission Pages: 5 URL: = http://www.ietf.org/internet-drafts/draft-seantek-image-bmp-00.txt Status: = https://datatracker.ietf.org/doc/draft-seantek-image-bmp/ Htmlized: http://tools.ietf.org/html/draft-seantek-image-bmp-00 Abstract: This document registers the image/bmp media type for use with the Windows Bitmap format (BMP), also known as Device-Independent Bitmap (DIB). Originally designed for Microsoft Windows 2.0 and OS/2, these bitmaps contain a single raster graphic in a variety of compressed or uncompressed formats. Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat= --Apple-Mail=_3991B61C-8D59-4C75-B6AB-5AB505E827EB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO7TCCBJ0w ggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsG AQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlfsXzw PlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1ctxE +2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj2iC0 o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRowggQCoAMCAQICEG0Z 6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAw NTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdC lOD5J3EHxcZppLkyxPFAGpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh3 37EXrMLaggLW1DJq1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJA AVtIaN3FSrTg7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJy ZCaRTqWSD//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOC AUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEE aDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF0q0bc24+6SZ85kyY wTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6L566k3nK/uKRHlZ0sviN 0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6 PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrR eTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqT PDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0EwHhcNMTMxMTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J 9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2g uKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G 53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia33JN+ oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5j b20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50 ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMf WE2/5myX518DB+kTa5iQDbKYRuJp3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmI H4kfI4LWrY8XrPhlX3JmHjD6hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3 jx9VF/gA3vqYpL+jNumInz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d 9ljRDEiAts5OopkeeFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYID rjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggHZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MTAxNzE4MTgwOVowIwYJKoZIhvcNAQkEMRYEFLld4uS6SDqn/pv+kdPmZXXK oyOhMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQDKkzwxu6lupsyQvhKSvQd8MIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEBBQAE ggEAkSTd/WUwIk3jsMIBEUYYDbw3aYI4zSQoJp7wmvAuAWxR2BS7CvJJ9t5CJ9DFEBcK6F1GnJov SyngYvsRn0+5aC1IjHEsdFg3AP0ZJXIPYya72IfVHUmr4jT1GdmJ9P8fGw2kZmR+XGe6piJCd5mN qbzo0NQcZD70sy+Ep/ZGrJyO2NPqUYuY5P58xaqAyNCQ3yRmNGitJQaZTDWxMO2uwSyKmLvHtYZj CG7NDBro2oU7h7XsPQWXXO374rPVwmWN/fHbXW/+L/stChnPjrM/eAlJo2wdIx0SGZdwx4lcTd0Z LG6ispwokku28KavhcFoOdeGFYrP9582Jj/7N1csSAAAAAAAAA== --Apple-Mail=_3991B61C-8D59-4C75-B6AB-5AB505E827EB-- From nobody Fri Oct 17 11:21:34 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A4F1ABD3B; Fri, 17 Oct 2014 02:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Qvj5WrFVc_EI; Fri, 17 Oct 2014 02:29:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9011A00E1; Fri, 17 Oct 2014 02:29:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNT14194; Fri, 17 Oct 2014 09:29:13 +0000 (GMT) Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 17 Oct 2014 10:29:12 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Fri, 17 Oct 2014 17:29:09 +0800 From: Bert Greevenbosch To: "draft-ietf-weirds-using-http.all@tools.ietf.org" , "'apps-discuss@ietf.org'" <'apps-discuss@ietf.org'>, "'iesg@ietf.org'" <'iesg@ietf.org'> Thread-Topic: Applications Area Directorate Review of draft-ietf-weirds-rdap-query-15 Thread-Index: AQHP6ezN4HdV4CJNoUO96AW+bzTL1Q== Date: Fri, 17 Oct 2014 09:29:09 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63E775B84@SZXEMA510-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.174.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7Fq2PS3rvopI5MAYo0ucSCAtwa4 X-Mailman-Approved-At: Fri, 17 Oct 2014 11:21:27 -0700 Subject: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-rdap-query-15 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 09:29:16 -0000 Document: draft-ietf-weirds-rdap-query-15 Title: Registration Data Access Protocol Query Format Reviewer: Bert Greevenbosch Review Date: 17 October 2014 IETF Last Call Date: 24 October 2014 IESG Telechat Date: 30 October 2014 Summary: Needs some edits. Major Issues: (M1) 3.2.3: "/entities?fn=3DXXXX where XXXX is a search pattern representin= g an entity name as specified in Section 6.1 of [I-D.ietf-weirds-json-respo= nse]". I couldn't find the definition of entity name in that document. I ha= ve the strong feeling that it corresponds to the "fn" element in the jCard.= Is this true? Then specify that. (See also comment m1.) Minor Issues: (m1) 3.2.3: "Section 6.1 of [I-D.ietf-weirds-json-response]." doesn't exist= in draft-ietf-weirds-json-10. I have the feeling that it should be section= 5.1. There is another reference in the second line below "/entities?handle= =3DXXXX". (m2) 3.2.3, last sentence on page 11: "The following URL would be used to f= ind information for entity names matching the "CID-40*" pattern." I think i= t should be "entity handles", not "entity names". (m3) Adding an example to section 4.2 "Associated Records" would make it ea= sier to understand what is meant. Nits: (n1) 4.1, it would be nice to replace "HTTP 422 [RFC4918]" by "HTTP 422 (Un= processable Entity) [RFC4918]". (n2) 6.1, it would be nice to replace "HTTP 400" by "HTTP 400 (Bad Request)= ". From nobody Fri Oct 17 11:21:35 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0371A8951; Thu, 16 Oct 2014 13:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, NORMAL_HTTP_TO_IP=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 UmZ_m-8gXmDF; Thu, 16 Oct 2014 13:27:20 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447FB1A892E; Thu, 16 Oct 2014 13:27:19 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id mc6so3639186lab.16 for ; Thu, 16 Oct 2014 13:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sZkGr7qtcPzNlKgyyqL2K2ThLw1IaCPq6ldIqWnQXqQ=; b=gkzZUJBZrFk8hR7qUm8F55QXr0ujkNoeHpLTjwL/6EJPveCOpzIUbSPqsuZfQG/UrB EqH3MRi6HijBBI1G5XpUo1O5BqnmEoyW2Ino22jcfiK3DF/3pNhm1GwdyaleNU/eFuiW 4/ZHqpiZf8ISzc/BNA9YSxgMAuYZTH0KlHLYYtW2Rv1QzZP2sckWTQg1FoRzdj+eMnoY EAVmro0K6m84b1bOEWfqXAnXjK5C4X+GBtugYCj8B8iwZZXRxa5T3US6HWVd9G1JtmBU /I/Krs57vsN1odUDBw+oPWW6EMAxuN07FpprUdIqy77yjQzp/vNwiJ3CYN+zafAp2f/u caug== MIME-Version: 1.0 X-Received: by 10.152.115.131 with SMTP id jo3mr4223668lab.20.1413491237524; Thu, 16 Oct 2014 13:27:17 -0700 (PDT) Received: by 10.112.95.36 with HTTP; Thu, 16 Oct 2014 13:27:17 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BB139D6@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439BB0FB8B@TK5EX14MBXC286.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439BB139D6@TK5EX14MBXC286.redmond.corp.microsoft.com> Date: Thu, 16 Oct 2014 16:27:17 -0400 Message-ID: From: Kathleen Moriarty To: Mike Jones Content-Type: multipart/alternative; boundary=001a11c366b21b1aa105059013fe Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/iHAWvuloHQD6EFI4cnMVewrVQMQ X-Mailman-Approved-At: Fri, 17 Oct 2014 11:21:28 -0700 Cc: "apps-discuss@ietf.org" , "draft-ietf-jose-json-web-algorithms.all@tools.ietf.org" , "iesg@ietf.org" , "jose@ietf.org" Subject: Re: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-algorithms-33 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 20:27:27 -0000 --001a11c366b21b1aa105059013fe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm just chiming in on one section, the designated review requirements right now. On Thu, Oct 16, 2014 at 1:09 PM, Mike Jones wrote: > Adding one more reply below - this time new proposed text from Matt > Miller... > > -----Original Message----- > From: Mike Jones > Sent: Thursday, October 16, 2014 9:53 AM > To: 'Carsten Bormann' > Cc: apps-discuss@ietf.org; > draft-ietf-jose-json-web-algorithms.all@tools.ietf.org; Matt Miller; > iesg@ietf.org; jose@ietf.org > Subject: RE: [apps-discuss] Appsdir review for > draft-ietf-jose-json-web-algorithms-33 > > Replies to your replies are inline below. Thanks again for your > thoughtful and detailed review. > > -- Mike > > > -----Original Message----- > > From: Carsten Bormann [mailto:cabo@tzi.org] > > Sent: Wednesday, October 15, 2014 2:55 AM > > To: Mike Jones > > Cc: apps-discuss@ietf.org; draft-ietf-jose-json-web- > > algorithms.all@tools.ietf.org; Matt Miller; iesg@ietf.org; > > jose@ietf.org > > Subject: Re: [apps-discuss] Appsdir review for > > draft-ietf-jose-json-web- > > algorithms-33 > > > > Hi Mike, > > > > thanks for getting to this review - I don't envy you for this herculean > job. > > A few more comments/clarifications inline below. > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > On 15 Oct 2014, at 10:51, Mike Jones > wrote: > > > > > Thanks for your review, Carsten. I apologize for not responding to > > > it until > > now. It had gotten sorted into a folder and I wasn't aware of it > > until Kathleen brought it to my attention. Replies are inline below... > > > > > >> -----Original Message----- > > >> From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf > > >> Of Carsten Bormann > > >> Sent: Thursday, October 02, 2014 12:22 AM > > >> To: apps-discuss@ietf.org; draft-ietf-jose-json-web- > > >> algorithms.all@tools.ietf.org > > >> Cc: iesg@ietf.org; jose@ietf.org > > >> Subject: [apps-discuss] Appsdir review for > > >> draft-ietf-jose-json-web-algorithms- > > >> 33 > > >> > > >> 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/ApplicationsAreaDirec > > >> to > > >> rate > > >> ). > > >> > > >> 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-jose-json-web-algorithms-33 > > >> Title: JSON Web Algorithms (JWA) > > >> Reviewer: Carsten Bormann > > >> Review Date: 2014-10-02 > > >> IESG Telechat date: 2014-10-02 > > >> > > >> Summary: This draft is ready for publication as a standards track > > >> RFC, with a few nits corrected. > > >> > > >> However, some additional editorial improvements might improve the > > >> security outcome when it is referenced by application developers. > > >> > > >> Major issues: None. > > >> > > >> Minor issues: > > >> > > >> 5.2: > > >> Add a reference that defines PKCS #7 padding. > > > > > > I'll plan on adding a reference to RFC 2315 for this. > > > > That would work (section reference would be 10.3) Alternatively, you > > could reference RFC 5652 (section 6.3), which is an Internet Standard > (STD70). > > > > >> 5.2.2.2 > > >> Does "the PKCS #7 padding is removed" entail checking all of its > bytes? > > > > > > Should this be changed to "the PKCS #7 padding bytes are checked and > > > then > > removed"? > > > > I think it is good to alert the reader to this need. > > > > >> 6.2.1 > > >> Is the intention that the sentence containing "point compression is > > >> not supported" also applies to any future registered value of "crv"? > > >> A similar comment applies to other specifications in 6.2.1.x, e.g., > > >> the reference to SEC1 representation to x and y. > > > > > > It would apply to any future curves registered that use the "x", "y" > > > point > > representation. Others could define new key types that use a > > different representation or we could refine the definition of > > "kty":"EC" to make the representation specific to the "crv" value. > > > > > > A discussion happened on the JOSE thread "JWK Elliptic Curve key > > representations and new curves". The conclusion suggested by Richard > > Barnes and seconded by Stephen Farrell was to table defining any new > > key representations for new elliptic curves until the CRFG > > recommendations to TLS have been made. That ended the discussion for > now. > > > > Right, I didn't want to anticipate that discussion; I would be happy > > if it didn't appear that the avenue for any evolution on point > > compression/compact points were closed. > > I can add language saying that future curve registrations may use > different parameters to represent the curve value. That may get a little > convoluted because currently it's the "kty" that determines which > parameters are used. But I agree with trying to accommodate new key > representations for new curves. > > > >> 6.2.1.1 > > >> =C2=BBAdditional "crv" values MAY be > > >> used, provided they are understood by implementations using that > > >> Elliptic Curve key.=C2=AB How are conflicts between such implementat= ion > > >> defined values and future registered values handled? > > > > > > Conflicts are avoided using the IANA JSON Web Key Elliptic Curve > > > registry > > defined in Section 7.6. > > > > Oh, but that's not what the text says. I read this as a general > > license to use random locally defined crv values. Maybe the need for > > registration needs to be clarified. > > I'll delete the sentence "Additional 'crv' values MAY be used, provided > they are understood by implementations using that Elliptic Curve key." T= he > registry is already talked about in the previous sentences. > > > >> 6.3.2: > > >> The MAY accept partially overrides the MUST include? > > >> Is the latter thus really a SHOULD? > > > > > > "d" is REQUIRED. The others SHOULD be included, and if any are > > > included, the > > others MUST be included. Those are requirements on producers. > > > > > > Consumers may choose to accept keys that don't include all the CRT > > parameters. Given that they can be computed from "n", "e", and "d" > > and sometimes they're not available, a previous reviewer had asked > > this language about consumers to be included. It's a case of "Be > > conservative in what you send, be liberal in what you accept". > > > > [I'm not inserting my usual rant here that this bon mot may apply to > > implementations, but never to specifications.] > > > > > It's not clear to me that there's any value in relaxing the > > > requirements on > > producers. > > > > Well, if the producer MUST send "all of the others" if "any of the othe= r" > > parameters are present, it is not clear to me what the point of "MAY > choose > > to accept an RSA private key that does not contain a complete set of > > the private key parameters other than "d"" is other than enabling > > producers to send just that. > > (More importantly, it is not clear when a producer should be taking > > that license.) > > I can delete the sentence " The consumer of a JWK MAY choose to accept an > RSA private key that does not contain a complete set of the private key > parameters..." > > > >> 7.1: > > >> It is interesting that a mere registration (vetted only by a DE) > > >> can change the IETF consensus base specifications by making an > > >> algorithm > > "Required". > > > > > > It is expected that the designated experts will be appointed, in > > > part, for their > > cryptographic expertise. > > > > There has been more discussion about the requirements levels here that > > I don't want to repeat. > > My comment here was that a DE (even with the best crypto knowledge) is > > in a hard place updating the consensus about *desirability of > > implementation* - there are more aspects to this than the technical one= s. > > Thinking about this some more, I agree that "Required" is a special case. > I'm thinking that a reasonable safeguard for this case is to require that > approval of both a designated expert and a sitting security area director > be required to make an algorithm "Required" or to change it from "Require= d" > to something else. Kathleen and Carsten, would that work for you? > The AD is in the appeals line, so that doesn't quite work: http://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-08#section-5.2.1 I think you need to leave it as-is with a set of DEs. Thanks, Kathleen > > >> 8. > > >> I am unable to find a "security considerations" section in NIST SP > 800-38A. > > >> 800-38D at least has a "practical considerations" section, is that > meant? > > >> (Etc., I haven't checked all the references.) In general, I believe > > >> a security considerations section is most useful where it provides > > >> more directed guidance instead of saying the equivalent of "here is = a > textbook". > > > > > > There are 14 subsections with directed guidance, plus more in the > > > JWS, JWE, > > and JWK specifications. If there is other directed guidance you'd > > like to see added, please supply proposed text. > > > > > > Having skimmed through it, I agree that 800-30A doesn't contain > > > clear enough > > security guidance to merit inclusion in the list. I'll remove it. If > > there are other specifications that you'd like to see added or removed, > please let me know. > > > > This was more of a general comment that "Here is a reference to a > textbook" > > type security considerations are less useful than specific, directed > > references. I haven't checked all those referenced documents, so I'm > > not in a position to recommend changes here. Maybe something for a > > checklist to apply to the next security spec. > > > > > > > >> 8.7 is not clear: is it NOT RECOMMENDED to reuse an entire set of > > >> key material (including IV), or to reuse any part of it? > > > > > > I agree that this is ambiguous, as worded. Its advice seems to be > > > so broad as > > to be impractical, as never reusing a key means that a new key would > > have to be redistributed for each encryption, which then requires a > > key to use for the distribution... This text came from > > http://tools.ietf.org/html/draft-miller-jose- > > jwe-protected-jwk-02#section-8.1, which was incorporated into the > > document after a working group decision to do so. Matt Miller, you > > were the author of this text. Could you clarify what the intent was? > Thanks. > > Matt proposed the following revised text. I agree that this is > significantly clearer and more actionable than the previous version: > > It is NOT RECOMMENDED to reuse the same entire set of key material (Key > Encryption Key, Content Encryption Key, Initialization Vector, > etc.) to encrypt multiple JWK or JWK Set objects, or to encrypt the same > JWK or JWK Set object multiple times. One suggestion for preventing re-u= se > is to always generate at least one piece of key material for each > encryption operation (e.g., a new Content Encryption Key, a new > Initialization Vector, and/or a new PBES2 Salt), based on the > considerations noted in this document as well as from RFC 4086 [RFC4086]. > > > >> Nits/editorial comments: > > >> > > >> 6.3.2.x: > > >> The constant repetition of =C2=BBIt is represented as the base64url > > >> encoding of the value's unsigned big endian representation as an > > >> octet > > sequence. > > >> The octet sequence MUST utilize the minimum number of octets to > > >> represent the value.=C2=AB almost ensures that an implementer will s= top > > >> reading the details (well, I did, and I did not write a program to > > >> verify the same phrase is used everywhere; if any parameter were > > >> using a different encoding, that sure would be missed). Why not > > >> define > > another abstraction like base64url and use this? > > > > > > I did just verify that they are all consistent. Yes, if you're > > > reading the spec > > linearly I'm sure it feels repetitive, but if you're an implementer > > going straight to a definition to implement it, having a complete > > description all in one place is valuable. I understand your request > > but it's not clear to me that this rises to the level that a separate > > definition that the developer then has to go find is warranted. > > > > My point was corroborated by the tiny error Richard found. Repeating > > the same information again and again drowns out the important > > information. A single paragraph at the end of 6.3's intro of the form: > > > > Each of the positive integer parameters defined in this section > > is represented as the base64url encoding > > of the value's unsigned big endian representation as an octet > > sequence. The octet sequence MUST utilize the minimum number of > > octets to represent the value. > > OK - I'll see what I can do in this regard. Editorially, it's a little > bit complicated because there are different subsections for public and > private key parameters. > > > Note that the repetitive text already has a reference that needs to be > > looked up in that it uses the term "base64url encoding", which has a > > slightly refined meaning here from that in RFC 4648. So an even > > better way to handle this would be to add a new term "posint encoding" > > or some such to section 1.1, turning e.g. the entirety of 6.3.2.2 into > > > > The "p" (first prime factor) member contains the first > > prime factor, in POSINT encoding. > > > > > > > > > >> 6.2.3.1: This is not a positive integer? 6.2.3.x mentions this > otherwise. > > > > > > I may not understand this remark. I'm guessing you're referring to > > > 6.3.2.1 and > > the fact that the description includes the word "unsigned". This is > > there to make it clear that no sign bit will be present in the > > representation - which is especially important since the high-order > > bit is always set for "n" and "d" for correctly generated keys. > > > > (Sorry, this is indeed about 6.3.2.x, not 6.2.3.x.) That was not what > > I meant: All 6.3.2.x have the form =C2=BBThe "p" (first prime factor) > > member contains the first prime factor, a positive integer.=C2=AB > > 6.3.2.1 does not have the ", a positive integer", but I can't see a > > reason for that (d clearly cannot be zero, and it is still an unsigned > value). > > This is likely to confuse an implementer that reads this text closely. > > (And I'm offering the fact that you are overlooking that inconsistency > > as another corroboration of my previous point.) > > I can delete the unnecessary phrase "a positive integer", subject to how > it does or doesn't fit into the edit above that you asked for. > > > >> 7.1.1 > > >> =C2=BBExample description=C2=AB is not a useful example for an "Algo= rithm > Description". > > >> (Same comment for 7.x.1.) > > > > > > See the actual registrations in Section 7.1.2 for more useful example= s. > > > > Maybe just take out the not so useful examples in 7.x.1? > > All other registration templates that I have seen include examples of all > parameters. This is only one of the parameters in the template, and all > need to be retained. Would you be happier with the e.g. text "Example > algorithm"? > > > >> 8.3: > > >> s/because it/because it is/ > > > > > > Good catch > > > > > >> [sec1] > > >> (Given the date, this is probably referencing V2.0 of this spec.) > > > > > > Hmmm - the version I have cached locally came from > > http://www.secg.org/collateral/sec1_final.pdf and is dated September > > 20, 2000. But the site appears to be down at present. The version > > referenced by Wikipedia at > > http://www.secg.org/download/aid-385/sec1_final.pdf is missing too. > > http://secg.org/download/aid-780/sec1-v2.pdf is missing too. Can you > point me to a good link? > > > > I just had a look and embarrassingly found that the copy I'm using > > comes from the personal space of a researcher: > > http://perso.univ-rennes1.fr/sylvain.duquesne/master/standards/sec1-v2 > > .pdf > > Not very satisfying as a reference. > > > > > > > > RFC 5915 includes this reference: > > > > > > [SECG1] Standards for Efficient Cryptography Group (SECG), "SEC = 1: > > > Elliptic Curve Cryptography", Version 2.0, May 2009. > > > > That looks good: We don't need a URL, as long as we are certain which > > version we are referencing. > > > > > Worst comes to worst, I'll either reference that or explicitly > > > reference the 1.0 > > version. But if I'm going to reference the 2.0 version, I'd like to > > be able to read a copy so that I can verify that the way we're using > > it is consistent with the actual spec, including the section numbers. > > > > > >> [usascii] > > >> The reference to ANSI X3.4:1986 should probably be replaced by a > > >> reference to RFC 20. There is little reason to reference a > > >> somewhat hard to obtain external document ($60!) when we have an > > >> RFC about the > > same subject. > > > > > > OK > > > > > >> (Tables in Appendix A need some formatting.) > > > > > > Agreed. It's on my to-do list. Jim Schaad recently told me to "Add > > > a width > > attribute to the ttcol with either "digits" (for fixed width) or > > "digits%" (for percent width) to the column in question". I plan to > give it a try. > > > > > >> _______________________________________________ > > >> apps-discuss mailing list > > >> apps-discuss@ietf.org > > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > Thanks again, > > > -- Mike > > > > > > > > > > > --=20 Best regards, Kathleen --001a11c366b21b1aa105059013fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm just chiming in on one section, the designated rev= iew requirements right now.

On Thu, Oct 16, 2014 at 1:09 PM, Mike Jones <= ;Michael.J= ones@microsoft.com> wrote:
Adding one mor= e reply below - this time new proposed text from Matt Miller...

-----Original Message-----
From: Mike Jones
Sent: Thursday, October 16, 2014 9:53 AM
To: 'Carsten Bormann'
Cc: apps-discuss@ietf.org; draf= t-ietf-jose-json-web-algorithms.all@tools.ietf.org; Matt Miller; iesg@ietf.org; jose@ietf.org
Subject: RE: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-alg= orithms-33

Replies to your replies are inline below.=C2=A0 Tha= nks again for your thoughtful and detailed review.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike

> -----Original Message-----
> From: Carsten Bormann [mailto:cabo@tzi= .org]
> Sent: Wednesday, October 15, 2014 2:55 AM
> To: Mike Jones
> Cc: apps-discuss@ietf.org= ; draft-ietf-jose-json-web-
> algorithms.all@tools.= ietf.org; Matt Miller; iesg@ietf.org;
> jose@ietf.org
> Subject: Re: [apps-discuss] Appsdir review for=
> draft-ietf-jose-json-web-
> algorithms-33
>
> Hi Mike,
>
> thanks for getting to this review - I don't envy you for this herc= ulean job.
> A few more comments/clarifications inline below.
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> On 15 Oct 2014, at 10:51, Mike Jones <Michael.Jones@microsoft.com> wrote:
>
> > Thanks for your review, Carsten.=C2=A0 I apologize for not respon= ding to
> > it until
> now.=C2=A0 It had gotten sorted into a folder and I wasn't aware o= f it
> until Kathleen brought it to my attention.=C2=A0 Replies are inline be= low...
> >
> >> -----Original Message-----
> >> From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf
> >> Of Carsten Bormann
> >> Sent: Thursday, October 02, 2014 12:22 AM
> >> To: apps-discuss@iet= f.org; draft-ietf-jose-json-web-
> >> algorithms.a= ll@tools.ietf.org
> >> Cc: iesg@ietf.org; jose@ietf.org
> >> Subject: [apps-discuss] Appsdir review for
> >> draft-ietf-jose-json-web-algorithms-
> >> 33
> >>
> >> I have been selected as the Applications Area Directorate rev= iewer
> >> for this draft (for background on appsdir, please see
> >> http://trac.tools.ietf.org/area/app/tr= ac/wiki/ApplicationsAreaDirec
> >> to
> >> rate
> >> ).
> >>
> >> Please resolve these comments along with any other Last Call<= br> > >> comments you may receive. Please wait for direction from your=
> >> document shepherd or AD before posting a new version of the d= raft.
> >>
> >> Document:=C2=A0 draft-ietf-jose-json-web-algorithms-33
> >> Title: JSON Web Algorithms (JWA)
> >> Reviewer: Carsten Bormann
> >> Review Date: 2014-10-02
> >> IESG Telechat date: 2014-10-02
> >>
> >> Summary: This draft is ready for publication as a standards t= rack
> >> RFC, with a few nits corrected.
> >>
> >> However, some additional editorial improvements might improve= the
> >> security outcome when it is referenced by application develop= ers.
> >>
> >> Major issues: None.
> >>
> >> Minor issues:
> >>
> >> 5.2:
> >> Add a reference that defines PKCS #7 padding.
> >
> > I'll plan on adding a reference to RFC 2315 for this.
>
> That would work (section reference would be 10.3) Alternatively, you > could reference RFC 5652 (section 6.3), which is an Internet Standard = (STD70).
>
> >> 5.2.2.2
> >> Does "the PKCS #7 padding is removed" entail checki= ng all of its bytes?
> >
> > Should this be changed to "the PKCS #7 padding bytes are che= cked and
> > then
> removed"?
>
> I think it is good to alert the reader to this need.
>
> >> 6.2.1
> >> Is the intention that the sentence containing "point com= pression is
> >> not supported" also applies to any future registered val= ue of "crv"?
> >> A similar comment applies to other specifications in 6.2.1.x,= e.g.,
> >> the reference to SEC1 representation to x and y.
> >
> > It would apply to any future curves registered that use the "= ;x", "y"
> > point
> representation.=C2=A0 Others could define new key types that use a
> different representation or we could refine the definition of
> "kty":"EC" to make the representation specific to = the "crv" value.
> >
> > A discussion happened on the JOSE thread "JWK Elliptic Curve= key
> representations and new curves".=C2=A0 The conclusion suggested b= y Richard
> Barnes and seconded by Stephen Farrell was to table defining any new > key representations for new elliptic curves until the CRFG
> recommendations to TLS have been made.=C2=A0 That ended the discussion= for now.
>
> Right, I didn't want to anticipate that discussion; I would be hap= py
> if it didn't appear that the avenue for any evolution on point
> compression/compact points were closed.

I can add language saying that future curve registrations may u= se different parameters to represent the curve value.=C2=A0 That may get a = little convoluted because currently it's the "kty" that deter= mines which parameters are used.=C2=A0 But I agree with trying to accommoda= te new key representations for new curves.

> >> 6.2.1.1
> >> =C2=BBAdditional "crv" values MAY be
> >> used, provided they are understood by implementations using t= hat
> >> Elliptic Curve key.=C2=AB How are conflicts between such impl= ementation
> >> defined values and future registered values handled?
> >
> > Conflicts are avoided using the IANA JSON Web Key Elliptic Curve<= br> > > registry
> defined in Section 7.6.
>
> Oh, but that's not what the text says.=C2=A0 I read this as a gene= ral
> license to use random locally defined crv values.=C2=A0 Maybe the need= for
> registration needs to be clarified.

I'll delete the sentence "Additional '= crv' values MAY be used, provided they are understood by implementation= s using that Elliptic Curve key."=C2=A0 The registry is already talked= about in the previous sentences.

> >> 6.3.2:
> >> The MAY accept partially overrides the MUST include?
> >> Is the latter thus really a SHOULD?
> >
> > "d" is REQUIRED.=C2=A0 The others SHOULD be included, a= nd if any are
> > included, the
> others MUST be included.=C2=A0 Those are requirements on producers. > >
> > Consumers may choose to accept keys that don't include all th= e CRT
> parameters.=C2=A0 Given that they can be computed from "n", = "e", and "d"
> and sometimes they're not available, a previous reviewer had asked=
> this language about consumers to be included.=C2=A0 It's a case of= "Be
> conservative in what you send, be liberal in what you accept". >
> [I'm not inserting my usual rant here that this bon mot may apply = to
> implementations, but never to specifications.]
>
> > It's not clear to me that there's any value in relaxing t= he
> > requirements on
> producers.
>
> Well, if the producer MUST send "all of the others" if "= ;any of the other"
> parameters are present, it is not clear to me what the point of "= MAY choose
>=C2=A0 =C2=A0 to accept an RSA private key that does not contain a comp= lete set of
>=C2=A0 =C2=A0 the private key parameters other than "d""= is other than enabling
> producers to send just that.
> (More importantly, it is not clear when a producer should be taking > that license.)

I can delete the sentence " The consumer of a JWK MAY choose to= accept an RSA private key that does not contain a complete set of the priv= ate key parameters..."

> >> 7.1:
> >> It is interesting that a mere registration (vetted only by a = DE)
> >> can change the IETF consensus base specifications by making a= n
> >> algorithm
> "Required".
> >
> > It is expected that the designated experts will be appointed, in<= br> > > part, for their
> cryptographic expertise.
>
> There has been more discussion about the requirements levels here that=
> I don't want to repeat.
> My comment here was that a DE (even with the best crypto knowledge) is=
> in a hard place updating the consensus about *desirability of
> implementation* - there are more aspects to this than the technical on= es.

Thinking about this some more, I agree that "R= equired" is a special case.=C2=A0 I'm thinking that a reasonable s= afeguard for this case is to require that approval of both a designated exp= ert and a sitting security area director be required to make an algorithm &= quot;Required" or to change it from "Required" to something = else.=C2=A0 Kathleen and Carsten, would that work for you?

The AD is in the appeals line, so that doesn'= ;t quite work:

I t= hink you need to leave it as-is with a set of DEs.

Thanks,
Kathleen



> >> 8.
> >> I am unable to find a "security considerations" sec= tion in NIST SP 800-38A.
> >> 800-38D at least has a "practical considerations" s= ection, is that meant?
> >> (Etc., I haven't checked all the references.) In general,= I believe
> >> a security considerations section is most useful where it pro= vides
> >> more directed guidance instead of saying the equivalent of &q= uot;here is a textbook".
> >
> > There are 14 subsections with directed guidance, plus more in the=
> > JWS, JWE,
> and JWK specifications.=C2=A0 If there is other directed guidance you&= #39;d
> like to see added, please supply proposed text.
> >
> > Having skimmed through it, I agree that 800-30A doesn't conta= in
> > clear enough
> security guidance to merit inclusion in the list.=C2=A0 I'll remov= e it.=C2=A0 If
> there are other specifications that you'd like to see added or rem= oved, please let me know.
>
> This was more of a general comment that "Here is a reference to a= textbook"
> type security considerations are less useful than specific, directed > references.=C2=A0 I haven't checked all those referenced documents= , so I'm
> not in a position to recommend changes here.=C2=A0 Maybe something for= a
> checklist to apply to the next security spec.
>
> >
> >> 8.7 is not clear: is it NOT RECOMMENDED to reuse an entire se= t of
> >> key material (including IV), or to reuse any part of it?
> >
> > I agree that this is ambiguous, as worded.=C2=A0 Its advice seems= to be
> > so broad as
> to be impractical, as never reusing a key means that a new key would > have to be redistributed for each encryption, which then requires a > key to use for the distribution...=C2=A0 This text came from
> http://tools.ietf.org/html/draft-miller-jose-
> jwe-protected-jwk-02#section-8.1, which was incorporated into the
> document after a working group decision to do so.=C2=A0 Matt Miller, y= ou
> were the author of this text.=C2=A0 Could you clarify what the intent = was?=C2=A0 Thanks.

Matt proposed the following revised text.=C2=A0 I agree that th= is is significantly clearer and more actionable than the previous version:<= br>
It is NOT RECOMMENDED to reuse the same entire set of key material (Key Enc= ryption Key, Content Encryption Key, Initialization Vector,
etc.) to encrypt multiple JWK or JWK Set objects, or to encrypt the same JW= K or JWK Set object multiple times.=C2=A0 One suggestion for preventing re-= use is to always generate at least one piece of key material for each encry= ption operation (e.g., a new Content Encryption Key, a new Initialization V= ector, and/or a new PBES2 Salt), based on the considerations noted in this = document as well as from RFC 4086 [RFC4086].

> >> Nits/editorial comments:
> >>
> >> 6.3.2.x:
> >> The constant repetition of =C2=BBIt is represented as the bas= e64url
> >> encoding of the value's unsigned big endian representatio= n as an
> >> octet
> sequence.
> >> The octet sequence MUST utilize the minimum number of octets = to
> >> represent the value.=C2=AB almost ensures that an implementer= will stop
> >> reading the details (well, I did, and I did not write a progr= am to
> >> verify the same phrase is used everywhere; if any parameter w= ere
> >> using a different encoding, that sure would be missed).=C2=A0= Why not
> >> define
> another abstraction like base64url and use this?
> >
> > I did just verify that they are all consistent.=C2=A0 Yes, if you= 're
> > reading the spec
> linearly I'm sure it feels repetitive, but if you're an implem= enter
> going straight to a definition to implement it, having a complete
> description all in one place is valuable.=C2=A0 I understand your requ= est
> but it's not clear to me that this rises to the level that a separ= ate
> definition that the developer then has to go find is warranted.
>
> My point was corroborated by the tiny error Richard found.=C2=A0 Repea= ting
> the same information again and again drowns out the important
> information.=C2=A0 A single paragraph at the end of 6.3's intro of= the form:
>
>=C2=A0 =C2=A0 Each of the positive integer parameters defined in this s= ection
>=C2=A0 =C2=A0 is represented as the base64url encoding
>=C2=A0 =C2=A0 of the value's unsigned big endian representation as = an octet
>=C2=A0 =C2=A0 sequence.=C2=A0 The octet sequence MUST utilize the minim= um number of
>=C2=A0 =C2=A0 octets to represent the value.

OK - I'll see what I can do in this regard= .=C2=A0 Editorially, it's a little bit complicated because there are di= fferent subsections for public and private key parameters.

> Note that the repetitive text already has a re= ference that needs to be
> looked up in that it uses the term "base64url encoding", whi= ch has a
> slightly refined meaning here from that in RFC 4648.=C2=A0 So an even<= br> > better way to handle this would be to add a new term "posint enco= ding"
> or some such to section 1.1, turning e.g. the entirety of 6.3.2.2 into=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The "p" (first prim= e factor) member contains the first
> prime factor, in POSINT encoding.
>
>
> >
> >> 6.2.3.1: Thi= s is not a positive integer?=C2=A0 6.2.3.x mentions this otherwise.
> >
> > I may not understand this remark.=C2=A0 I'm guessing you'= re referring to
> > 6.3.2.1 and
> the fact that the description includes the word "unsigned".= =C2=A0 This is
> there to make it clear that no sign bit will be present in the
> representation - which is especially important since the high-order > bit is always set for "n" and "d" for correctly ge= nerated keys.
>
> (Sorry, this is indeed about 6.3.2.x, not 6.2.3.x.) That was not what<= br> > I meant:=C2=A0 All 6.3.2.x have the form =C2=BBThe "p" (firs= t prime factor)
> member contains the first prime factor, a positive integer.=C2=AB
> 6.3.2.1 does not have the ", a positive integer", but I can&= #39;t see a
> reason for that (d clearly cannot be zero, and it is still an unsigned= value).
> This is likely to confuse an implementer that reads this text closely.=
> (And I'm offering the fact that you are overlooking that inconsist= ency
> as another corroboration of my previous point.)

I can delete the unnecessary phrase "a positive integer", subject= to how it does or doesn't fit into the edit above that you asked for.<= br>
> >> 7.1.1
> >> =C2=BBExample description=C2=AB is not a useful example for a= n "Algorithm Description".
> >> (Same comment for 7.x.1.)
> >
> > See the actual registrations in Section 7.1.2 for more useful exa= mples.
>
> Maybe just take out the not so useful examples in 7.x.1?

All other registration templates that I have seen= include examples of all parameters.=C2=A0 This is only one of the paramete= rs in the template, and all need to be retained.=C2=A0 Would you be happier= with the e.g. text "Example algorithm"?

> >> 8.3:
> >> s/because it/because it is/
> >
> > Good catch
> >
> >> [sec1]
> >> (Given the date, this is probably referencing V2.0 of this sp= ec.)
> >
> > Hmmm - the version I have cached locally came from
> http://www.secg.org/collateral/sec1_final.pdf and is dated Septem= ber
> 20, 2000.=C2=A0 But the site appears to be down at present.=C2=A0 The = version
> referenced by Wikipedia at
> http://www.secg.org/download/aid-385/sec1_final.pdf is miss= ing too.
> http://secg.org/download/aid-780/sec1-v2.pdf is missing too.=C2=A0= Can you point me to a good link?
>
> I just had a look and embarrassingly found that the copy I'm using=
> comes from the personal space of a researcher:
> http://perso.univ-rennes1.fr/sylvain.duquesn= e/master/standards/sec1-v2
> .pdf
> Not very satisfying as a reference.
>
> >
> > RFC 5915 includes this reference:
> >
> >=C2=A0 =C2=A0[SECG1]=C2=A0 =C2=A0 Standards for Efficient Cryptogr= aphy Group (SECG), "SEC 1:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Elliptic Curve Cr= yptography", Version 2.0, May 2009.
>
> That looks good: We don't need a URL, as long as we are certain wh= ich
> version we are referencing.
>
> > Worst comes to worst, I'll either reference that or explicitl= y
> > reference the 1.0
> version.=C2=A0 But if I'm going to reference the 2.0 version, I= 9;d like to
> be able to read a copy so that I can verify that the way we're usi= ng
> it is consistent with the actual spec, including the section numbers.<= br> > >
> >> [usascii]
> >> The reference to ANSI X3.4:1986 should probably be replaced b= y a
> >> reference to RFC 20.=C2=A0 There is little reason to referenc= e a
> >> somewhat hard to obtain external document ($60!) when we have= an
> >> RFC about the
> same subject.
> >
> > OK
> >
> >> (Tables in Appendix A need some formatting.)
> >
> > Agreed.=C2=A0 It's on my to-do list.=C2=A0 Jim Schaad recentl= y told me to "Add
> > a width
> attribute to the ttcol with either "digits" (for fixed width= ) or
> "digits%" (for percent width) to the column in question"= ;.=C2=A0 I plan to give it a try.
> >
> >> _______________________________________________
> >> apps-discuss mailing list
> >> apps-discuss@ietf.or= g
> >> https://www.ietf.org/mailman/listinfo/apps-discuss<= br> > >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks again,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
> >
> >
> >




--
=

Best regards,
Kathleen
--001a11c366b21b1aa105059013fe-- From nobody Fri Oct 17 11:21:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A5B1A87AC; Thu, 16 Oct 2014 14:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, NORMAL_HTTP_TO_IP=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 xxM_PWbNA4lA; Thu, 16 Oct 2014 14:15:08 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F521A87A0; Thu, 16 Oct 2014 14:15:06 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id mc6so3704156lab.16 for ; Thu, 16 Oct 2014 14:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Pqz3aCOh4/pehJk/ysCyg977XVhyPcw9vbbMkum2hnw=; b=IuzGj6laAESwMHA1CMHXgImUr35W9snbkRnvZSezWw6TReEmQhwK/tXyiwRZfsdtbN E/X2B7BBWSqIhGFGwdXRQgHuVxpeydjKOx6Znm1GIKlcBri5AIj4BmFk803IltNppt24 8Og76fWHc41LELwAP0vX1m89wSdw03wRFxx91rHx3aImGmWWpeMC+PggNhq7M4ra50Qk 6WnDB3sGe6TwEi3R5f88eTSG6gPwwUhLkHLukg0+zlhMUlfNQRn4rFUR94pfeyD1BiGI ITHb980pomCrTmiqkzv7x2qMXOTN/lobdC0hJ3Q5wT8vThdAeNTMZ1P4D0jW9Fip5jh2 eqAA== MIME-Version: 1.0 X-Received: by 10.152.87.171 with SMTP id az11mr4142474lab.97.1413494105076; Thu, 16 Oct 2014 14:15:05 -0700 (PDT) Received: by 10.112.95.36 with HTTP; Thu, 16 Oct 2014 14:15:04 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739439BB0FB8B@TK5EX14MBXC286.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439BB139D6@TK5EX14MBXC286.redmond.corp.microsoft.com> Date: Thu, 16 Oct 2014 17:15:04 -0400 Message-ID: From: Kathleen Moriarty To: Mike Jones Content-Type: multipart/alternative; boundary=001a11c238ae067a8e050590be14 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7Rmc6WuAOq-_BBLtpUz92Yf2qaM X-Mailman-Approved-At: Fri, 17 Oct 2014 11:21:28 -0700 Cc: "apps-discuss@ietf.org" , "draft-ietf-jose-json-web-algorithms.all@tools.ietf.org" , "iesg@ietf.org" , "jose@ietf.org" Subject: Re: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-algorithms-33 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 21:15:14 -0000 --001a11c238ae067a8e050590be14 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 16, 2014 at 4:27 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > I'm just chiming in on one section, the designated review requirements > right now. > > On Thu, Oct 16, 2014 at 1:09 PM, Mike Jones > wrote: > >> Adding one more reply below - this time new proposed text from Matt >> Miller... >> >> -----Original Message----- >> From: Mike Jones >> Sent: Thursday, October 16, 2014 9:53 AM >> To: 'Carsten Bormann' >> Cc: apps-discuss@ietf.org; >> draft-ietf-jose-json-web-algorithms.all@tools.ietf.org; Matt Miller; >> iesg@ietf.org; jose@ietf.org >> Subject: RE: [apps-discuss] Appsdir review for >> draft-ietf-jose-json-web-algorithms-33 >> >> Replies to your replies are inline below. Thanks again for your >> thoughtful and detailed review. >> >> -- Mike >> >> > -----Original Message----- >> > From: Carsten Bormann [mailto:cabo@tzi.org] >> > Sent: Wednesday, October 15, 2014 2:55 AM >> > To: Mike Jones >> > Cc: apps-discuss@ietf.org; draft-ietf-jose-json-web- >> > algorithms.all@tools.ietf.org; Matt Miller; iesg@ietf.org; >> > jose@ietf.org >> > Subject: Re: [apps-discuss] Appsdir review for >> > draft-ietf-jose-json-web- >> > algorithms-33 >> > >> > Hi Mike, >> > >> > thanks for getting to this review - I don't envy you for this herculea= n >> job. >> > A few more comments/clarifications inline below. >> > >> > Gr=C3=BC=C3=9Fe, Carsten >> > >> > On 15 Oct 2014, at 10:51, Mike Jones >> wrote: >> > >> > > Thanks for your review, Carsten. I apologize for not responding to >> > > it until >> > now. It had gotten sorted into a folder and I wasn't aware of it >> > until Kathleen brought it to my attention. Replies are inline below..= . >> > > >> > >> -----Original Message----- >> > >> From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf >> > >> Of Carsten Bormann >> > >> Sent: Thursday, October 02, 2014 12:22 AM >> > >> To: apps-discuss@ietf.org; draft-ietf-jose-json-web- >> > >> algorithms.all@tools.ietf.org >> > >> Cc: iesg@ietf.org; jose@ietf.org >> > >> Subject: [apps-discuss] Appsdir review for >> > >> draft-ietf-jose-json-web-algorithms- >> > >> 33 >> > >> >> > >> 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/ApplicationsAreaDirec >> > >> to >> > >> rate >> > >> ). >> > >> >> > >> 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-jose-json-web-algorithms-33 >> > >> Title: JSON Web Algorithms (JWA) >> > >> Reviewer: Carsten Bormann >> > >> Review Date: 2014-10-02 >> > >> IESG Telechat date: 2014-10-02 >> > >> >> > >> Summary: This draft is ready for publication as a standards track >> > >> RFC, with a few nits corrected. >> > >> >> > >> However, some additional editorial improvements might improve the >> > >> security outcome when it is referenced by application developers. >> > >> >> > >> Major issues: None. >> > >> >> > >> Minor issues: >> > >> >> > >> 5.2: >> > >> Add a reference that defines PKCS #7 padding. >> > > >> > > I'll plan on adding a reference to RFC 2315 for this. >> > >> > That would work (section reference would be 10.3) Alternatively, you >> > could reference RFC 5652 (section 6.3), which is an Internet Standard >> (STD70). >> > >> > >> 5.2.2.2 >> > >> Does "the PKCS #7 padding is removed" entail checking all of its >> bytes? >> > > >> > > Should this be changed to "the PKCS #7 padding bytes are checked and >> > > then >> > removed"? >> > >> > I think it is good to alert the reader to this need. >> > >> > >> 6.2.1 >> > >> Is the intention that the sentence containing "point compression is >> > >> not supported" also applies to any future registered value of "crv"= ? >> > >> A similar comment applies to other specifications in 6.2.1.x, e.g., >> > >> the reference to SEC1 representation to x and y. >> > > >> > > It would apply to any future curves registered that use the "x", "y" >> > > point >> > representation. Others could define new key types that use a >> > different representation or we could refine the definition of >> > "kty":"EC" to make the representation specific to the "crv" value. >> > > >> > > A discussion happened on the JOSE thread "JWK Elliptic Curve key >> > representations and new curves". The conclusion suggested by Richard >> > Barnes and seconded by Stephen Farrell was to table defining any new >> > key representations for new elliptic curves until the CRFG >> > recommendations to TLS have been made. That ended the discussion for >> now. >> > >> > Right, I didn't want to anticipate that discussion; I would be happy >> > if it didn't appear that the avenue for any evolution on point >> > compression/compact points were closed. >> >> I can add language saying that future curve registrations may use >> different parameters to represent the curve value. That may get a littl= e >> convoluted because currently it's the "kty" that determines which >> parameters are used. But I agree with trying to accommodate new key >> representations for new curves. >> >> > >> 6.2.1.1 >> > >> =C2=BBAdditional "crv" values MAY be >> > >> used, provided they are understood by implementations using that >> > >> Elliptic Curve key.=C2=AB How are conflicts between such implementa= tion >> > >> defined values and future registered values handled? >> > > >> > > Conflicts are avoided using the IANA JSON Web Key Elliptic Curve >> > > registry >> > defined in Section 7.6. >> > >> > Oh, but that's not what the text says. I read this as a general >> > license to use random locally defined crv values. Maybe the need for >> > registration needs to be clarified. >> >> I'll delete the sentence "Additional 'crv' values MAY be used, provided >> they are understood by implementations using that Elliptic Curve key." = The >> registry is already talked about in the previous sentences. >> >> > >> 6.3.2: >> > >> The MAY accept partially overrides the MUST include? >> > >> Is the latter thus really a SHOULD? >> > > >> > > "d" is REQUIRED. The others SHOULD be included, and if any are >> > > included, the >> > others MUST be included. Those are requirements on producers. >> > > >> > > Consumers may choose to accept keys that don't include all the CRT >> > parameters. Given that they can be computed from "n", "e", and "d" >> > and sometimes they're not available, a previous reviewer had asked >> > this language about consumers to be included. It's a case of "Be >> > conservative in what you send, be liberal in what you accept". >> > >> > [I'm not inserting my usual rant here that this bon mot may apply to >> > implementations, but never to specifications.] >> > >> > > It's not clear to me that there's any value in relaxing the >> > > requirements on >> > producers. >> > >> > Well, if the producer MUST send "all of the others" if "any of the >> other" >> > parameters are present, it is not clear to me what the point of "MAY >> choose >> > to accept an RSA private key that does not contain a complete set o= f >> > the private key parameters other than "d"" is other than enabling >> > producers to send just that. >> > (More importantly, it is not clear when a producer should be taking >> > that license.) >> >> I can delete the sentence " The consumer of a JWK MAY choose to accept a= n >> RSA private key that does not contain a complete set of the private key >> parameters..." >> >> > >> 7.1: >> > >> It is interesting that a mere registration (vetted only by a DE) >> > >> can change the IETF consensus base specifications by making an >> > >> algorithm >> > "Required". >> > > >> > > It is expected that the designated experts will be appointed, in >> > > part, for their >> > cryptographic expertise. >> > >> > There has been more discussion about the requirements levels here that >> > I don't want to repeat. >> > My comment here was that a DE (even with the best crypto knowledge) is >> > in a hard place updating the consensus about *desirability of >> > implementation* - there are more aspects to this than the technical >> ones. >> >> Thinking about this some more, I agree that "Required" is a special >> case. I'm thinking that a reasonable safeguard for this case is to requ= ire >> that approval of both a designated expert and a sitting security area >> director be required to make an algorithm "Required" or to change it fro= m >> "Required" to something else. Kathleen and Carsten, would that work for >> you? >> > > The AD is in the appeals line, so that doesn't quite work: > http://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-08#section-5.2= .1 > > I think you need to leave it as-is with a set of DEs. > Please do change the text to require more than one DE. > > Thanks, > Kathleen > > > >> > >> 8. >> > >> I am unable to find a "security considerations" section in NIST SP >> 800-38A. >> > >> 800-38D at least has a "practical considerations" section, is that >> meant? >> > >> (Etc., I haven't checked all the references.) In general, I believe >> > >> a security considerations section is most useful where it provides >> > >> more directed guidance instead of saying the equivalent of "here is >> a textbook". >> > > >> > > There are 14 subsections with directed guidance, plus more in the >> > > JWS, JWE, >> > and JWK specifications. If there is other directed guidance you'd >> > like to see added, please supply proposed text. >> > > >> > > Having skimmed through it, I agree that 800-30A doesn't contain >> > > clear enough >> > security guidance to merit inclusion in the list. I'll remove it. If >> > there are other specifications that you'd like to see added or removed= , >> please let me know. >> > >> > This was more of a general comment that "Here is a reference to a >> textbook" >> > type security considerations are less useful than specific, directed >> > references. I haven't checked all those referenced documents, so I'm >> > not in a position to recommend changes here. Maybe something for a >> > checklist to apply to the next security spec. >> > >> > > >> > >> 8.7 is not clear: is it NOT RECOMMENDED to reuse an entire set of >> > >> key material (including IV), or to reuse any part of it? >> > > >> > > I agree that this is ambiguous, as worded. Its advice seems to be >> > > so broad as >> > to be impractical, as never reusing a key means that a new key would >> > have to be redistributed for each encryption, which then requires a >> > key to use for the distribution... This text came from >> > http://tools.ietf.org/html/draft-miller-jose- >> > jwe-protected-jwk-02#section-8.1, which was incorporated into the >> > document after a working group decision to do so. Matt Miller, you >> > were the author of this text. Could you clarify what the intent was? >> Thanks. >> >> Matt proposed the following revised text. I agree that this is >> significantly clearer and more actionable than the previous version: >> >> It is NOT RECOMMENDED to reuse the same entire set of key material (Key >> Encryption Key, Content Encryption Key, Initialization Vector, >> etc.) to encrypt multiple JWK or JWK Set objects, or to encrypt the same >> JWK or JWK Set object multiple times. One suggestion for preventing re-= use >> is to always generate at least one piece of key material for each >> encryption operation (e.g., a new Content Encryption Key, a new >> Initialization Vector, and/or a new PBES2 Salt), based on the >> considerations noted in this document as well as from RFC 4086 [RFC4086]= . >> >> > >> Nits/editorial comments: >> > >> >> > >> 6.3.2.x: >> > >> The constant repetition of =C2=BBIt is represented as the base64url >> > >> encoding of the value's unsigned big endian representation as an >> > >> octet >> > sequence. >> > >> The octet sequence MUST utilize the minimum number of octets to >> > >> represent the value.=C2=AB almost ensures that an implementer will = stop >> > >> reading the details (well, I did, and I did not write a program to >> > >> verify the same phrase is used everywhere; if any parameter were >> > >> using a different encoding, that sure would be missed). Why not >> > >> define >> > another abstraction like base64url and use this? >> > > >> > > I did just verify that they are all consistent. Yes, if you're >> > > reading the spec >> > linearly I'm sure it feels repetitive, but if you're an implementer >> > going straight to a definition to implement it, having a complete >> > description all in one place is valuable. I understand your request >> > but it's not clear to me that this rises to the level that a separate >> > definition that the developer then has to go find is warranted. >> > >> > My point was corroborated by the tiny error Richard found. Repeating >> > the same information again and again drowns out the important >> > information. A single paragraph at the end of 6.3's intro of the form= : >> > >> > Each of the positive integer parameters defined in this section >> > is represented as the base64url encoding >> > of the value's unsigned big endian representation as an octet >> > sequence. The octet sequence MUST utilize the minimum number of >> > octets to represent the value. >> >> OK - I'll see what I can do in this regard. Editorially, it's a little >> bit complicated because there are different subsections for public and >> private key parameters. >> >> > Note that the repetitive text already has a reference that needs to be >> > looked up in that it uses the term "base64url encoding", which has a >> > slightly refined meaning here from that in RFC 4648. So an even >> > better way to handle this would be to add a new term "posint encoding" >> > or some such to section 1.1, turning e.g. the entirety of 6.3.2.2 into >> > >> > The "p" (first prime factor) member contains the first >> > prime factor, in POSINT encoding. >> > >> > >> > > >> > >> 6.2.3.1: This is not a positive integer? 6.2.3.x mentions this >> otherwise. >> > > >> > > I may not understand this remark. I'm guessing you're referring to >> > > 6.3.2.1 and >> > the fact that the description includes the word "unsigned". This is >> > there to make it clear that no sign bit will be present in the >> > representation - which is especially important since the high-order >> > bit is always set for "n" and "d" for correctly generated keys. >> > >> > (Sorry, this is indeed about 6.3.2.x, not 6.2.3.x.) That was not what >> > I meant: All 6.3.2.x have the form =C2=BBThe "p" (first prime factor) >> > member contains the first prime factor, a positive integer.=C2=AB >> > 6.3.2.1 does not have the ", a positive integer", but I can't see a >> > reason for that (d clearly cannot be zero, and it is still an unsigned >> value). >> > This is likely to confuse an implementer that reads this text closely. >> > (And I'm offering the fact that you are overlooking that inconsistency >> > as another corroboration of my previous point.) >> >> I can delete the unnecessary phrase "a positive integer", subject to how >> it does or doesn't fit into the edit above that you asked for. >> >> > >> 7.1.1 >> > >> =C2=BBExample description=C2=AB is not a useful example for an "Alg= orithm >> Description". >> > >> (Same comment for 7.x.1.) >> > > >> > > See the actual registrations in Section 7.1.2 for more useful >> examples. >> > >> > Maybe just take out the not so useful examples in 7.x.1? >> >> All other registration templates that I have seen include examples of al= l >> parameters. This is only one of the parameters in the template, and all >> need to be retained. Would you be happier with the e.g. text "Example >> algorithm"? >> >> > >> 8.3: >> > >> s/because it/because it is/ >> > > >> > > Good catch >> > > >> > >> [sec1] >> > >> (Given the date, this is probably referencing V2.0 of this spec.) >> > > >> > > Hmmm - the version I have cached locally came from >> > http://www.secg.org/collateral/sec1_final.pdf and is dated September >> > 20, 2000. But the site appears to be down at present. The version >> > referenced by Wikipedia at >> > http://www.secg.org/download/aid-385/sec1_final.pdf is missing too. >> > http://secg.org/download/aid-780/sec1-v2.pdf is missing too. Can you >> point me to a good link? >> > >> > I just had a look and embarrassingly found that the copy I'm using >> > comes from the personal space of a researcher: >> > http://perso.univ-rennes1.fr/sylvain.duquesne/master/standards/sec1-v2 >> > .pdf >> > Not very satisfying as a reference. >> > >> > > >> > > RFC 5915 includes this reference: >> > > >> > > [SECG1] Standards for Efficient Cryptography Group (SECG), "SEC >> 1: >> > > Elliptic Curve Cryptography", Version 2.0, May 2009. >> > >> > That looks good: We don't need a URL, as long as we are certain which >> > version we are referencing. >> > >> > > Worst comes to worst, I'll either reference that or explicitly >> > > reference the 1.0 >> > version. But if I'm going to reference the 2.0 version, I'd like to >> > be able to read a copy so that I can verify that the way we're using >> > it is consistent with the actual spec, including the section numbers. >> > > >> > >> [usascii] >> > >> The reference to ANSI X3.4:1986 should probably be replaced by a >> > >> reference to RFC 20. There is little reason to reference a >> > >> somewhat hard to obtain external document ($60!) when we have an >> > >> RFC about the >> > same subject. >> > > >> > > OK >> > > >> > >> (Tables in Appendix A need some formatting.) >> > > >> > > Agreed. It's on my to-do list. Jim Schaad recently told me to "Add >> > > a width >> > attribute to the ttcol with either "digits" (for fixed width) or >> > "digits%" (for percent width) to the column in question". I plan to >> give it a try. >> > > >> > >> _______________________________________________ >> > >> apps-discuss mailing list >> > >> apps-discuss@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > >> > > Thanks again, >> > > -- Mike >> > > >> > > >> > > >> >> > > > -- > > Best regards, > Kathleen > --=20 Best regards, Kathleen --001a11c238ae067a8e050590be14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 16, 2014 at 4:27 PM, Kathleen Moriarty &l= t;kat= hleen.moriarty.ietf@gmail.com> wrote:
I'm just chiming in on one section, the des= ignated review requirements right now.

On Thu, Oct 16, 2014 at 1:09 PM= , Mike Jones <Michael.Jones@microsoft.com> wrote:<= br>
Adding one more reply below - this time new proposed te= xt from Matt Miller...

-----Original Message-----
From: Mike Jones
Sent: Thursday, October 16, 2014 9:53 AM
To: 'Carsten Bormann'
Cc: apps-discuss= @ietf.org; draft-ietf-jose-json-web-algorithms.all@too= ls.ietf.org; Matt Miller; iesg@ietf.org; jose@ietf.org
Subject: RE: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-alg= orithms-33

Replies to your replies are inline below.=C2=A0 Thanks again f= or your thoughtful and detailed review.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike

> -----Original Message-----
> From: Carsten Bormann [mailto:cabo@tzi.org]
> Sent: Wednesday, October 15, 2014 2:55 AM
> To: Mike Jones
> Cc: apps-di= scuss@ietf.org; draft-ietf-jose-json-web-
> alg= orithms.all@tools.ietf.org; Matt Miller; iesg@ietf.org;
> jose@ietf.org > Subject: Re: [apps-discuss] Appsdir review for
> draft-ietf-jose-json-web-
> algorithms-33
>
> Hi Mike,
>
> thanks for getting to this review - I don't envy you for this herc= ulean job.
> A few more comments/clarifications inline below.
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> On 15 Oct 2014, at 10:51, Mike Jones <Michael.Jones@microsoft.com> wro= te:
>
> > Thanks for your review, Carsten.=C2=A0 I apologize for not respon= ding to
> > it until
> now.=C2=A0 It had gotten sorted into a folder and I wasn't aware o= f it
> until Kathleen brought it to my attention.=C2=A0 Replies are inline be= low...
> >
> >> -----Original Message-----
> >> From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Beha= lf
> >> Of Carsten Bormann
> >> Sent: Thursday, October 02, 2014 12:22 AM
> >> To: apps-discuss@ietf.org; draft-ietf-jose-json-web-
> >> algorithms.all@tools.ietf.org
> >> Cc: iesg@i= etf.org; jose@ietf.o= rg
> >> Subject: [apps-discuss] Appsdir review for
> >> draft-ietf-jose-json-web-algorithms-
> >> 33
> >>
> >> I have been selected as the Applications Area Directorate rev= iewer
> >> for this draft (for background on appsdir, please see
> >> http://trac.tools.ietf.org/area/app/tr= ac/wiki/ApplicationsAreaDirec
> >> to
> >> rate
> >> ).
> >>
> >> Please resolve these comments along with any other Last Call<= br> > >> comments you may receive. Please wait for direction from your=
> >> document shepherd or AD before posting a new version of the d= raft.
> >>
> >> Document:=C2=A0 draft-ietf-jose-json-web-algorithms-33
> >> Title: JSON Web Algorithms (JWA)
> >> Reviewer: Carsten Bormann
> >> Review Date: 2014-10-02
> >> IESG Telechat date: 2014-10-02
> >>
> >> Summary: This draft is ready for publication as a standards t= rack
> >> RFC, with a few nits corrected.
> >>
> >> However, some additional editorial improvements might improve= the
> >> security outcome when it is referenced by application develop= ers.
> >>
> >> Major issues: None.
> >>
> >> Minor issues:
> >>
> >> 5.2:
> >> Add a reference that defines PKCS #7 padding.
> >
> > I'll plan on adding a reference to RFC 2315 for this.
>
> That would work (section reference would be 10.3) Alternatively, you > could reference RFC 5652 (section 6.3), which is an Internet Standard = (STD70).
>
> >> 5.2.2.2
> >> Does "the PKCS #7 padding is removed" entail checki= ng all of its bytes?
> >
> > Should this be changed to "the PKCS #7 padding bytes are che= cked and
> > then
> removed"?
>
> I think it is good to alert the reader to this need.
>
> >> 6.2.1
> >> Is the intention that the sentence containing "point com= pression is
> >> not supported" also applies to any future registered val= ue of "crv"?
> >> A similar comment applies to other specifications in 6.2.1.x,= e.g.,
> >> the reference to SEC1 representation to x and y.
> >
> > It would apply to any future curves registered that use the "= ;x", "y"
> > point
> representation.=C2=A0 Others could define new key types that use a
> different representation or we could refine the definition of
> "kty":"EC" to make the representation specific to = the "crv" value.
> >
> > A discussion happened on the JOSE thread "JWK Elliptic Curve= key
> representations and new curves".=C2=A0 The conclusion suggested b= y Richard
> Barnes and seconded by Stephen Farrell was to table defining any new > key representations for new elliptic curves until the CRFG
> recommendations to TLS have been made.=C2=A0 That ended the discussion= for now.
>
> Right, I didn't want to anticipate that discussion; I would be hap= py
> if it didn't appear that the avenue for any evolution on point
> compression/compact points were closed.

I can add language saying that future curve registrations may u= se different parameters to represent the curve value.=C2=A0 That may get a = little convoluted because currently it's the "kty" that deter= mines which parameters are used.=C2=A0 But I agree with trying to accommoda= te new key representations for new curves.

> >> 6.2.1.1
> >> =C2=BBAdditional "crv" values MAY be
> >> used, provided they are understood by implementations using t= hat
> >> Elliptic Curve key.=C2=AB How are conflicts between such impl= ementation
> >> defined values and future registered values handled?
> >
> > Conflicts are avoided using the IANA JSON Web Key Elliptic Curve<= br> > > registry
> defined in Section 7.6.
>
> Oh, but that's not what the text says.=C2=A0 I read this as a gene= ral
> license to use random locally defined crv values.=C2=A0 Maybe the need= for
> registration needs to be clarified.

I'll delete the sentence "Additional 'crv' va= lues MAY be used, provided they are understood by implementations using tha= t Elliptic Curve key."=C2=A0 The registry is already talked about in t= he previous sentences.

> >> 6.3.2:
> >> The MAY accept partially overrides the MUST include?
> >> Is the latter thus really a SHOULD?
> >
> > "d" is REQUIRED.=C2=A0 The others SHOULD be included, a= nd if any are
> > included, the
> others MUST be included.=C2=A0 Those are requirements on producers. > >
> > Consumers may choose to accept keys that don't include all th= e CRT
> parameters.=C2=A0 Given that they can be computed from "n", = "e", and "d"
> and sometimes they're not available, a previous reviewer had asked=
> this language about consumers to be included.=C2=A0 It's a case of= "Be
> conservative in what you send, be liberal in what you accept". >
> [I'm not inserting my usual rant here that this bon mot may apply = to
> implementations, but never to specifications.]
>
> > It's not clear to me that there's any value in relaxing t= he
> > requirements on
> producers.
>
> Well, if the producer MUST send "all of the others" if "= ;any of the other"
> parameters are present, it is not clear to me what the point of "= MAY choose
>=C2=A0 =C2=A0 to accept an RSA private key that does not contain a comp= lete set of
>=C2=A0 =C2=A0 the private key parameters other than "d""= is other than enabling
> producers to send just that.
> (More importantly, it is not clear when a producer should be taking > that license.)

I can delete the sentence " The consumer of a JWK MAY choose to= accept an RSA private key that does not contain a complete set of the priv= ate key parameters..."

> >> 7.1:
> >> It is interesting that a mere registration (vetted only by a = DE)
> >> can change the IETF consensus base specifications by making a= n
> >> algorithm
> "Required".
> >
> > It is expected that the designated experts will be appointed, in<= br> > > part, for their
> cryptographic expertise.
>
> There has been more discussion about the requirements levels here that=
> I don't want to repeat.
> My comment here was that a DE (even with the best crypto knowledge) is=
> in a hard place updating the consensus about *desirability of
> implementation* - there are more aspects to this than the technical on= es.

Thinking about this some more, I agree that "Required&quo= t; is a special case.=C2=A0 I'm thinking that a reasonable safeguard fo= r this case is to require that approval of both a designated expert and a s= itting security area director be required to make an algorithm "Requir= ed" or to change it from "Required" to something else.=C2=A0= Kathleen and Carsten, would that work for you?

The AD is in the appeals line, so that doesn= 9;t quite work:

I think you need to leave it as-is with a set of DEs.
=

Please do change the tex= t to require more than one DE.
=C2=A0

Thanks,
Kathleen



> >> 8.
> >> I am unable to find a "security considerations" sec= tion in NIST SP 800-38A.
> >> 800-38D at least has a "practical considerations" s= ection, is that meant?
> >> (Etc., I haven't checked all the references.) In general,= I believe
> >> a security considerations section is most useful where it pro= vides
> >> more directed guidance instead of saying the equivalent of &q= uot;here is a textbook".
> >
> > There are 14 subsections with directed guidance, plus more in the=
> > JWS, JWE,
> and JWK specifications.=C2=A0 If there is other directed guidance you&= #39;d
> like to see added, please supply proposed text.
> >
> > Having skimmed through it, I agree that 800-30A doesn't conta= in
> > clear enough
> security guidance to merit inclusion in the list.=C2=A0 I'll remov= e it.=C2=A0 If
> there are other specifications that you'd like to see added or rem= oved, please let me know.
>
> This was more of a general comment that "Here is a reference to a= textbook"
> type security considerations are less useful than specific, directed > references.=C2=A0 I haven't checked all those referenced documents= , so I'm
> not in a position to recommend changes here.=C2=A0 Maybe something for= a
> checklist to apply to the next security spec.
>
> >
> >> 8.7 is not clear: is it NOT RECOMMENDED to reuse an entire se= t of
> >> key material (including IV), or to reuse any part of it?
> >
> > I agree that this is ambiguous, as worded.=C2=A0 Its advice seems= to be
> > so broad as
> to be impractical, as never reusing a key means that a new key would > have to be redistributed for each encryption, which then requires a > key to use for the distribution...=C2=A0 This text came from
> http://tools.ietf.org/html/draft-miller-jose-
> jwe-protected-jwk-02#section-8.1, which was incorporated into the
> document after a working group decision to do so.=C2=A0 Matt Miller, y= ou
> were the author of this text.=C2=A0 Could you clarify what the intent = was?=C2=A0 Thanks.

Matt proposed the following revised text.=C2=A0 I agree that th= is is significantly clearer and more actionable than the previous version:<= br>
It is NOT RECOMMENDED to reuse the same entire set of key material (Key Enc= ryption Key, Content Encryption Key, Initialization Vector,
etc.) to encrypt multiple JWK or JWK Set objects, or to encrypt the same JW= K or JWK Set object multiple times.=C2=A0 One suggestion for preventing re-= use is to always generate at least one piece of key material for each encry= ption operation (e.g., a new Content Encryption Key, a new Initialization V= ector, and/or a new PBES2 Salt), based on the considerations noted in this = document as well as from RFC 4086 [RFC4086].

> >> Nits/editorial comments:
> >>
> >> 6.3.2.x:
> >> The constant repetition of =C2=BBIt is represented as the bas= e64url
> >> encoding of the value's unsigned big endian representatio= n as an
> >> octet
> sequence.
> >> The octet sequence MUST utilize the minimum number of octets = to
> >> represent the value.=C2=AB almost ensures that an implementer= will stop
> >> reading the details (well, I did, and I did not write a progr= am to
> >> verify the same phrase is used everywhere; if any parameter w= ere
> >> using a different encoding, that sure would be missed).=C2=A0= Why not
> >> define
> another abstraction like base64url and use this?
> >
> > I did just verify that they are all consistent.=C2=A0 Yes, if you= 're
> > reading the spec
> linearly I'm sure it feels repetitive, but if you're an implem= enter
> going straight to a definition to implement it, having a complete
> description all in one place is valuable.=C2=A0 I understand your requ= est
> but it's not clear to me that this rises to the level that a separ= ate
> definition that the developer then has to go find is warranted.
>
> My point was corroborated by the tiny error Richard found.=C2=A0 Repea= ting
> the same information again and again drowns out the important
> information.=C2=A0 A single paragraph at the end of 6.3's intro of= the form:
>
>=C2=A0 =C2=A0 Each of the positive integer parameters defined in this s= ection
>=C2=A0 =C2=A0 is represented as the base64url encoding
>=C2=A0 =C2=A0 of the value's unsigned big endian representation as = an octet
>=C2=A0 =C2=A0 sequence.=C2=A0 The octet sequence MUST utilize the minim= um number of
>=C2=A0 =C2=A0 octets to represent the value.

OK - I'll see what I can do in this regard.=C2=A0 Edi= torially, it's a little bit complicated because there are different sub= sections for public and private key parameters.

> Note that the repetitive text already has a reference tha= t needs to be
> looked up in that it uses the term "base64url encoding", whi= ch has a
> slightly refined meaning here from that in RFC 4648.=C2=A0 So an even<= br> > better way to handle this would be to add a new term "posint enco= ding"
> or some such to section 1.1, turning e.g. the entirety of 6.3.2.2 into=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The "p" (first prim= e factor) member contains the first
> prime factor, in POSINT encoding.
>
>
> >
> >> 6.2.3.1: Thi= s is not a positive integer?=C2=A0 6.2.3.x mentions this otherwise.
> >
> > I may not understand this remark.=C2=A0 I'm guessing you'= re referring to
> > 6.3.2.1 and
> the fact that the description includes the word "unsigned".= =C2=A0 This is
> there to make it clear that no sign bit will be present in the
> representation - which is especially important since the high-order > bit is always set for "n" and "d" for correctly ge= nerated keys.
>
> (Sorry, this is indeed about 6.3.2.x, not 6.2.3.x.) That was not what<= br> > I meant:=C2=A0 All 6.3.2.x have the form =C2=BBThe "p" (firs= t prime factor)
> member contains the first prime factor, a positive integer.=C2=AB
> 6.3.2.1 does not have the ", a positive integer", but I can&= #39;t see a
> reason for that (d clearly cannot be zero, and it is still an unsigned= value).
> This is likely to confuse an implementer that reads this text closely.=
> (And I'm offering the fact that you are overlooking that inconsist= ency
> as another corroboration of my previous point.)

I can delete the unnecessary phrase "a positive integer", subject= to how it does or doesn't fit into the edit above that you asked for.<= br>
> >> 7.1.1
> >> =C2=BBExample description=C2=AB is not a useful example for a= n "Algorithm Description".
> >> (Same comment for 7.x.1.)
> >
> > See the actual registrations in Section 7.1.2 for more useful exa= mples.
>
> Maybe just take out the not so useful examples in 7.x.1?

All other registration templates that I have seen include exam= ples of all parameters.=C2=A0 This is only one of the parameters in the tem= plate, and all need to be retained.=C2=A0 Would you be happier with the e.g= . text "Example algorithm"?

> >> 8.3:
> >> s/because it/because it is/
> >
> > Good catch
> >
> >> [sec1]
> >> (Given the date, this is probably referencing V2.0 of this sp= ec.)
> >
> > Hmmm - the version I have cached locally came from
> http://www.secg.org/collateral/sec1_final.pdf and is dated Septem= ber
> 20, 2000.=C2=A0 But the site appears to be down at present.=C2=A0 The = version
> referenced by Wikipedia at
> http://www.secg.org/download/aid-385/sec1_final.pdf is miss= ing too.
> http://secg.org/download/aid-780/sec1-v2.pdf is missing too.=C2=A0= Can you point me to a good link?
>
> I just had a look and embarrassingly found that the copy I'm using=
> comes from the personal space of a researcher:
> http://perso.univ-rennes1.fr/sylvain.duquesn= e/master/standards/sec1-v2
> .pdf
> Not very satisfying as a reference.
>
> >
> > RFC 5915 includes this reference:
> >
> >=C2=A0 =C2=A0[SECG1]=C2=A0 =C2=A0 Standards for Efficient Cryptogr= aphy Group (SECG), "SEC 1:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Elliptic Curve Cr= yptography", Version 2.0, May 2009.
>
> That looks good: We don't need a URL, as long as we are certain wh= ich
> version we are referencing.
>
> > Worst comes to worst, I'll either reference that or explicitl= y
> > reference the 1.0
> version.=C2=A0 But if I'm going to reference the 2.0 version, I= 9;d like to
> be able to read a copy so that I can verify that the way we're usi= ng
> it is consistent with the actual spec, including the section numbers.<= br> > >
> >> [usascii]
> >> The reference to ANSI X3.4:1986 should probably be replaced b= y a
> >> reference to RFC 20.=C2=A0 There is little reason to referenc= e a
> >> somewhat hard to obtain external document ($60!) when we have= an
> >> RFC about the
> same subject.
> >
> > OK
> >
> >> (Tables in Appendix A need some formatting.)
> >
> > Agreed.=C2=A0 It's on my to-do list.=C2=A0 Jim Schaad recentl= y told me to "Add
> > a width
> attribute to the ttcol with either "digits" (for fixed width= ) or
> "digits%" (for percent width) to the column in question"= ;.=C2=A0 I plan to give it a try.
> >
> >> _______________________________________________
> >> apps-discuss mailing list
> >> ap= ps-discuss@ietf.org
> >> https://www.ietf.org/mailman/listinfo/apps-discuss<= br> > >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks again,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
> >
> >
> >




--

Best regards,
Kathleen



--

Best regards,
Kathleen
--001a11c238ae067a8e050590be14-- From nobody Fri Oct 17 11:46:17 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37E41A1A89 for ; Fri, 17 Oct 2014 11:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_f6jO7FJQvB for ; Fri, 17 Oct 2014 11:46:15 -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 97A531A1A93 for ; Fri, 17 Oct 2014 11:46:05 -0700 (PDT) Received: (qmail 38552 invoked from network); 17 Oct 2014 18:46:04 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 17 Oct 2014 18:46:04 -0000 Date: 17 Oct 2014 18:45:41 -0000 Message-ID: <20141017184541.1079.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <469C8ADC-97AF-49FA-AEE0-15F59EC39A6F@seantek.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/pThd5_t5qsWy-ag7L4ZotZymE3g Subject: Re: [apps-discuss] image/bmp: New Version Notification for draft-seantek-image-bmp-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:46:16 -0000 In article <469C8ADC-97AF-49FA-AEE0-15F59EC39A6F@seantek.com> you write: >-=-=-=-=-=- >-=-=-=-=-=- > >Colleagues: > >An Internet-Draft to register image/bmp has been posted. > >Thanks to Alexey Melnikov and Dave Thaler, who provided advice on these >drafts prior to submission. > >Feedback welcome. BMP files can in fact contain text, inside embedded JPEG and PNG. I don't know as there's much to say about it, other than that image manipulation software wil do what it does. From nobody Fri Oct 17 11:52:43 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14F81A1B03 for ; Fri, 17 Oct 2014 11:52:40 -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 tFKf8F-6n6Ih for ; Fri, 17 Oct 2014 11:52:38 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FDE81A1A0E for ; Fri, 17 Oct 2014 11:52:38 -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=1413571959; x=1445107959; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rtf24I/CvSc5MbRG9+//EYm1JBpqz+3w6Vxoo+lbvQI=; b=YaKRcoqLA4tguCuoyrmi1L3pjPXL6F9sKE2EOZq9Wxi3Rl2Z//c+yT9l d7qIZblYegOGa+FI3s+hWAXtjLAUNraOVkb5OFlUzCnqvfdpmpNWZAAom t6FmIKDaMj4JWc7WwzP3K8BfhEU6Wen2fIONwYreR5u/BBNmpxtH9wm5+ o=; X-IronPort-AV: E=McAfee;i="5600,1067,7594"; a="76304264" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 17 Oct 2014 11:52:36 -0700 X-IronPort-AV: E=Sophos;i="5.04,740,1406617200"; d="scan'208";a="30809846" Received: from nasanexhc06.na.qualcomm.com ([172.30.48.21]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 17 Oct 2014 11:52:31 -0700 Received: from NASANEXM01F.na.qualcomm.com (172.30.48.1) by nasanexhc06.na.qualcomm.com (172.30.48.21) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 17 Oct 2014 11:52:30 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 17 Oct 2014 11:52:30 -0700 Message-ID: <5441656C.3080509@qti.qualcomm.com> Date: Fri, 17 Oct 2014 13:52:28 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: John C Klensin References: <20141015183752.37123181C73@rfc-editor.org> <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com> <296D4B39-32CA-4F1D-A790-008F87DF8794@vpnc.org> <20141017164434.GA9526@rfc-editor.org> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (129.46.53.226) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_NJZU8s_E9G6aesNLPOXCBqWXlo Cc: Barry Leiba , Paul Hoffman , apps-discuss@ietf.org, RFC Editor Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 18:52:41 -0000 On 10/17/14 1:11 PM, John C Klensin wrote: > > --On Friday, October 17, 2014 09:44 -0700 RFC Editor > wrote: > > >> We've been investigating how this error crept in on our end so >> we can explain and understand how to avoid a similar issue in >> the future. After reviewing the files and running a copy of >> the .xml through xml2rfc, we think there may be an error with >> xml2rfc. >> ... >> > On 10/16/14 9:53 AM, Barry Leiba wrote: > >> To do the draft, get the final 7386.xml from the RFC Editor, add an >> "obsoletes=7386" at the top (and take off the special RFC Editor >> attributes), make sure all the tabs are replaced by spaces and >> everything lines up correctly, and add a paragraph to the Abstract and >> Introduction that says that this is a replacement to RFC 7386 that >> corrects indentation errors. Make no other changes, and I'll note in >> the last call note that no other changes are in scope. >> > Folks, > > I don't know whether it is less painful to do a narrow Last Call > or to risk opening a can of worms, but my recollection is that > there have been a few times in which the RFC Editor has simply > issued a replacement document with a new number to correct > editing or formatting problems with the earlier document. The > principle that justified that action would seem to apply here, > so maybe the right solution is Just Do It with the "Obsoletes" > field as above and a status note from the RFC Editor explaining > the change. No need to waste community or IESG time on a > vacuous LC and the further advantage of getting the replacement > document up a lot sooner. > We have done it once recently, with RFC 7158/7159, so I wouldn't be opposed to doing so in this case. There is a small tooling issue in that the datatracker doesn't have history on the latter RFC, but I suspect that's something that the tools team can fix at some point. Barry should make the call on this, but I'm OK with the idea. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Fri Oct 17 11:58:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A8B1A1AD2 for ; Fri, 17 Oct 2014 11:58:00 -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 zBF2y4Wai_ga for ; Fri, 17 Oct 2014 11:57:58 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D14C11A0069 for ; Fri, 17 Oct 2014 11:57:57 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gi9so1186433lab.7 for ; Fri, 17 Oct 2014 11:57:56 -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=f1j+3k+ybKf2YBB274e9QTZcWJ++5ib5/YDG1eKhQCQ=; b=SJGNFxPj2dudx1B8pX84gK+4URUkYyyxIZoshLOO3iVp/aZhBkSOeh5t8Z5h/Vor60 jYe5YhdtgGr5nqqbS0iJXNo13si5OUe98+35V+hTWaWbREQVb0jXfoBJN8lJkmFYish4 UYFUsKcS5C380DIr3RD/jVXtPZXTKO4fI+Fy8lwQxWFHri3eU7vkxmQhIwE+PdBFu8tn Gv5CTrJUoNtSIBzxr9Q6K7bRwooOiibI8OdnyL9qbgaDWU//1iKoEzL/RQvgv0DdtmRW za/huABXmXgHXw+F9kmtKuPvoYGe7ZbXL3g8HxPku7m/EilWUy1FRFFg/bXfCsHLlBHk X39w== MIME-Version: 1.0 X-Received: by 10.112.162.41 with SMTP id xx9mr499864lbb.21.1413572276115; Fri, 17 Oct 2014 11:57:56 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Fri, 17 Oct 2014 11:57:55 -0700 (PDT) In-Reply-To: <5441656C.3080509@qti.qualcomm.com> References: <20141015183752.37123181C73@rfc-editor.org> <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com> <296D4B39-32CA-4F1D-A790-008F87DF8794@vpnc.org> <20141017164434.GA9526@rfc-editor.org> <5441656C.3080509@qti.qualcomm.com> Date: Fri, 17 Oct 2014 14:57:55 -0400 X-Google-Sender-Auth: hO2CmPSSWmpljNxbUg7F5ntXeOo Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: multipart/alternative; boundary=089e0116062261de490505a2f1f0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/KlkxirkcSrBDp4b3Z1QwyAWWwik Cc: Paul Hoffman , "apps-discuss@ietf.org" , RFC Editor Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 18:58:00 -0000 --089e0116062261de490505a2f1f0 Content-Type: text/plain; charset=ISO-8859-1 Yes, OK by me as well: Sandy, can you guys fix this, with a check by the authors? Barry On Friday, October 17, 2014, Pete Resnick wrote: > On 10/17/14 1:11 PM, John C Klensin wrote: > >> >> --On Friday, October 17, 2014 09:44 -0700 RFC Editor >> wrote: >> >> >> >>> We've been investigating how this error crept in on our end so >>> we can explain and understand how to avoid a similar issue in >>> the future. After reviewing the files and running a copy of >>> the .xml through xml2rfc, we think there may be an error with >>> xml2rfc. >>> ... >>> >>> >> On 10/16/14 9:53 AM, Barry Leiba wrote: >> >> >>> To do the draft, get the final 7386.xml from the RFC Editor, add an >>> "obsoletes=7386" at the top (and take off the special RFC Editor >>> attributes), make sure all the tabs are replaced by spaces and >>> everything lines up correctly, and add a paragraph to the Abstract and >>> Introduction that says that this is a replacement to RFC 7386 that >>> corrects indentation errors. Make no other changes, and I'll note in >>> the last call note that no other changes are in scope. >>> >>> >> Folks, >> >> I don't know whether it is less painful to do a narrow Last Call >> or to risk opening a can of worms, but my recollection is that >> there have been a few times in which the RFC Editor has simply >> issued a replacement document with a new number to correct >> editing or formatting problems with the earlier document. The >> principle that justified that action would seem to apply here, >> so maybe the right solution is Just Do It with the "Obsoletes" >> field as above and a status note from the RFC Editor explaining >> the change. No need to waste community or IESG time on a >> vacuous LC and the further advantage of getting the replacement >> document up a lot sooner. >> >> > > We have done it once recently, with RFC 7158/7159, so I wouldn't be > opposed to doing so in this case. There is a small tooling issue in that > the datatracker doesn't have history on the latter RFC, but I suspect > that's something that the tools team can fix at some point. > > Barry should make the call on this, but I'm OK with the idea. > > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > --089e0116062261de490505a2f1f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, OK by me as well: Sandy, can you guys fix this, with a check by the au= thors?

Barry

On Friday, October 17, = 2014, Pete Resnick <presnic= k@qti.qualcomm.com> wrote:
On 10/1= 7/14 1:11 PM, John C Klensin wrote:

--On Friday, October 17, 2014 09:44 -0700 RFC Editor
<rfc-editor@rfc-editor.org>=A0 wrote:

=A0 =A0
We've been investigating how this error crept in on our end so
we can explain and understand how to avoid a similar issue in
the future. After reviewing the files and running a copy of
the .xml through xml2rfc,=A0 we think there may be an error with
xml2rfc.
...
=A0 =A0 =A0
On 10/16/14 9:53 AM, Barry Leiba wrote:
=A0 =A0
To do the draft, get the final 7386.xml from the RFC Editor, add an
"obsoletes=3D7386" at the top (and take off the special RFC Edito= r
attributes), make sure all the tabs are replaced by spaces and
everything lines up correctly, and add a paragraph to the Abstract and
Introduction that says that this is a replacement to RFC 7386 that
corrects indentation errors.=A0 Make no other changes, and I'll note in=
the last call note that no other changes are in scope.
=A0 =A0 =A0
Folks,

I don't know whether it is less painful to do a narrow Last Call
or to risk opening a can of worms, but my recollection is that
there have been a few times in which the RFC Editor has simply
issued a replacement document with a new number to correct
editing or formatting problems with the earlier document.=A0 The
principle that justified that action would seem to apply here,
so maybe the right solution is Just Do It with the "Obsoletes" field as above and a status note from the RFC Editor explaining
the change.=A0 No need to waste community or IESG time on a
vacuous LC and the further advantage of getting the replacement
document up a lot sooner.
=A0 =A0

We have done it once recently, with RFC 7158/7159, so I wouldn't be opp= osed to doing so in this case. There is a small tooling issue in that the d= atatracker doesn't have history on the latter RFC, but I suspect that&#= 39;s something that the tools team can fix at some point.

Barry should make the call on this, but I'm OK with the idea.

pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

--089e0116062261de490505a2f1f0-- From nobody Fri Oct 17 13:44:17 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FABD1A1BFF for ; Fri, 17 Oct 2014 13:44:16 -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 3L5ZXPvXAPLF for ; Fri, 17 Oct 2014 13:44:14 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 677621A1BED for ; Fri, 17 Oct 2014 13:44:14 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 345C8509B5; Fri, 17 Oct 2014 16:44:12 -0400 (EDT) Message-ID: <54417F50.2010003@seantek.com> Date: Fri, 17 Oct 2014 13:42:56 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Paul Libbrecht References: <17250A28-F165-4F31-B65F-9E78CC73D74E@seantek.com> <2EEB08DD-9ADB-422F-8ABE-0AB2C152A547@hoplahup.net> In-Reply-To: <2EEB08DD-9ADB-422F-8ABE-0AB2C152A547@hoplahup.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kD34P6ZnQrg325k1KiZoKtqhCNU Cc: media-types@iana.org, IETF Apps Discuss Subject: Re: [apps-discuss] [media-types] image/wmf and image/emf: New Version Notification for draft-seantek-image-wmf-emf-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 20:44:16 -0000 On 10/17/2014 1:38 PM, Paul Libbrecht wrote: > Sean, > > I believe the etiquette of this lists asks you that you copy the content of the media-type registration into here. Ok. I did not want to be spammy. But, I'll do that..in two separate e-mails. The I-D includes two registrations. > > I see in the links you provided that the wmf and emf registration indicate an amount of question marks as Macintosh file types and Uniform types… it seems unfinished or is that a question? > (as of today, many agree that Macintosh file types are not useful anymore, so that can probably be ignored, but not UTIs!) They are questions. I did some research but was unable to find file types or UTIs. I did not want to propose something new unless we are 100% sure that there are no other file types or UTIs in use for WMF/EMF. > > Also I see that you attempted to include Macintosh UTIs for all formats, that is a good and desirable thing. > Any reason you do not also mention (just besides that , I would say) the Windows clipboard names for each of these formats? I am pretty sure something can be found in some MicroSoft documentation about it. I was not aware of the Windows clipboard names either. It is a good point, however, to include. If you find something let me know; otherwise I'll make it a point for draft-01 to research more. Thanks, Sean > > thanks > > paul > > > > On 17 oct. 2014, at 20:08, Sean Leonard wrote: > >> Colleagues: >> >> An Internet-Draft to register image/wmf and image/emf has been posted. >> >> Thanks to Alexey Melnikov and Dave Thaler, who provided advice on these drafts prior to submission. >> >> Feedback welcome. >> >> Regards, >> >> Sean >> >> ******************* >> A new version of I-D, draft-seantek-image-wmf-emf-00.txt >> has been successfully submitted by Sean Leonard and posted to the >> IETF repository. >> >> Name: draft-seantek-image-wmf-emf >> Revision: 00 >> Title: The Windows Metafile and Enhanced Metafile Media Types >> Document date: 2014-10-17 >> Group: Individual Submission >> Pages: 8 >> URL: http://www.ietf.org/internet-drafts/draft-seantek-image-wmf-emf-00.txt >> Status: https://datatracker.ietf.org/doc/draft-seantek-image-wmf-emf/ >> Htmlized: http://tools.ietf.org/html/draft-seantek-image-wmf-emf-00 >> >> >> Abstract: >> This document registers the image/wmf and image/emf media types for >> use with Windows Metafile and Enhanced Metafile formats. Originally >> designed for Microsoft Windows 3.0, these image files are intended to >> be portable between applications and devices, and may contain both >> vector and raster graphics. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat_______________________________________________ >> media-types mailing list >> media-types@ietf.org >> https://www.ietf.org/mailman/listinfo/media-types From nobody Fri Oct 17 13:46:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235721A6FE5 for ; Fri, 17 Oct 2014 13:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZgwU8sP6J8u for ; Fri, 17 Oct 2014 13:46:26 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3950D1A6FE8 for ; Fri, 17 Oct 2014 13:46:26 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9354A50A84; Fri, 17 Oct 2014 16:46:24 -0400 (EDT) Message-ID: <54417FD5.9050109@seantek.com> Date: Fri, 17 Oct 2014 13:45:09 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: media-types@iana.org, IETF Apps Discuss References: <17250A28-F165-4F31-B65F-9E78CC73D74E@seantek.com> <2EEB08DD-9ADB-422F-8ABE-0AB2C152A547@hoplahup.net> In-Reply-To: <2EEB08DD-9ADB-422F-8ABE-0AB2C152A547@hoplahup.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ghkKOsk2joHHfZsbPMG87hA3-Hw Subject: [apps-discuss] image/wmf Application X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 20:46:28 -0000 2. Windows Metafile Media Type Registration Application Type name: image Subtype name: wmf Required parameters: None. Optional parameters: DEFAULT_CHARSET: The character set intended when the CharacterSet Enumeration (see [MS-WMF]) specifies DEFAULT_CHARSET. The value of this parameter is a charset name defined in accordance to the procedures laid out in [RFC2978]. When this parameter is not specified, DEFAULT_CHARSET has the following meaning in [MS-WMF]: "a character set based on the current system locale; for example, when the system locale is United States English, the default character set is ANSI_CHARSET" (which is Windows-1252, more-or- less). I.e., when not specified, the default character set is system-dependent. As this optional parameter is novel, content producers embedding text SHOULD use EMF instead of WMF (or if absolutely necessary, SHOULD embed EMF within WMF). Encoding considerations: Binary. Security considerations: The Windows Metafile format's security history is punctuated in 2005-2006 with the disclosure of the Metafile Image Code Execution vulnerability, codenamed MICE. MICE won the 2007 Pwnie Award for "Mass 0wnage" and "Breaking the Internet" [PWNIES07]. The official Microsoft security bulletin [MICE] describes that the flaw occurs because Windows Metafiles can set the SETABORTPROC value of the MetafileEscapes enumeration (accessible via the META_ESCAPE record), allowing for arbitrary code execution. Windows Metafiles can contain Enhanced Metafiles using the META_ESCAPE_ENHANCED_METAFILE record; thus, the security considerations of EMF apply to WMF. Windows Metafiles are historically very buggy. As the original intent was to replicate Windows GDI calls, flaws in GDI, or in a display or printer driver implementing the back-end to GDI, could be exploitable. WMF implementations not backed by Windows GDI have different risks: namely, while a malicious WMF author may not consider the non-Windows GDI implementation as a primary target, WMF has many "corner case" records for which an implementation's processing may not have received the same level of scrutiny as the Windows implementation. "Fuzzing" the implementation is appropriate. Interoperability considerations: Windows Metafile is the original 16-bit metafile format; it was released in 1990 at what some computer historians might consider the "zenith" of the desktop publishing revolution. Accordingly, there is a large body of free and commercially available clip art that is still in use, either independently or embedded in productivity documents (word processing documents, desktop publishing documents, slideshows and presentations, and spreadsheets and workbooks). For example, references to WMF content appear (non-normatively) in Office Open XML [OOXML]. To say that support for this format is necessary for interoperability would not be an understatement. Accommodations for comments or arbitrary data storage in Windows Metafiles are virtually non-existent. However, Windows Metafiles can contain Enhanced Metafiles using the META_ESCAPE_ENHANCED_METAFILE record; an implementation SHOULD be able to handle both types. Windows Metafiles can store and output text strings (see META_TEXTOUT and META_EXTTEXTOUT records), but the encodings of the strings may be ambiguous. Unicode encodings are not possible without the DEFAULT_CHARSET parameter defined in this registration. The previously unregistered type "image/x-wmf" is also in wide use. Accordingly, it is registered as a deprecated alias. See Appendix A and Section 4.2.9 of [RFC6838]. Published specification: [MS-WMF]. Applications that use this media type: Office productivity applications; clip art applications; desktop publishing applications; some Web browsers (e.g., Internet Explorer). Fragment identifier considerations: None. Additional information: Deprecated alias names for this type: image/x-wmf Magic number(s): D7 CD C6 9A (little-endian DWORD 0x9AC6CDD7) File extension(s): .wmf Macintosh file type code(s): ????. A uniform type identifier (UTI) of "????" is RECOMMENDED. Person & email address to contact for further information: Sean Leonard Restrictions on usage: None. Author/Change controller: Sean Leonard Intended usage: COMMON Provisional registration? No From nobody Fri Oct 17 13:48:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD9A1A6FF1 for ; Fri, 17 Oct 2014 13:48:37 -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 nH-53GlESTlp for ; Fri, 17 Oct 2014 13:48:35 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68F861A6FD2 for ; Fri, 17 Oct 2014 13:48:35 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4C9D6509B5; Fri, 17 Oct 2014 16:48:34 -0400 (EDT) Message-ID: <54418056.7090005@seantek.com> Date: Fri, 17 Oct 2014 13:47:18 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: media-types@iana.org, IETF Apps Discuss References: <17250A28-F165-4F31-B65F-9E78CC73D74E@seantek.com> <2EEB08DD-9ADB-422F-8ABE-0AB2C152A547@hoplahup.net> In-Reply-To: <2EEB08DD-9ADB-422F-8ABE-0AB2C152A547@hoplahup.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Vpq1YBSJrH3BY6cl-yUC9ONn86Y Subject: Re: [apps-discuss] [media-types] image/wmf and image/emf: New Version Notification for draft-seantek-image-wmf-emf-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 20:48:37 -0000 3. Enhanced Metafile Media Type Registration Application Type name: image Subtype name: emf Required parameters: None. Optional parameters: None. Encoding considerations: Binary. Security considerations: Enhanced Metafiles are not afflicted with [MICE]. There has been no public disclosure of vulnerabilities specific to EMF or EMF+ to date. Nonetheless: Enhanced Metafiles can contain Encapsulated PostScript (EPS) data; thus the security considerations of PostScript processing may also apply to EMF. As the original intent was to replicate Windows GDI calls, flaws in GDI, or in a display or printer driver implementing the back-end to GDI, could be exploitable with maliciously crafted EMF content. EMF implementations not backed by Windows GDI have different risks: namely, while a malicious EMF author may not consider the non- Windows GDI implementation as a primary target, EMF has many "corner case" records for which an implementation's processing may not have received the same level of scrutiny as the Windows implementation. "Fuzzing" the implementation is appropriate. It is also possible that EMF+ data is "safe" while EMF data contains an exploit (or vice-versa); the EMF+-aware implementation (such as an application designed for GDI+ on Windows XP or above) would skip the "unsafe" data while another implementation would fall prey to the exploit. Interoperability considerations: Enhanced Metafile is the 32-bit metafile format; it was released in 1992 along with Windows NT 3.1. There is a large body of free and commercially available clip art that is still in use, either independently or embedded in productivity documents (word processing documents, desktop publishing documents, slideshows and presentations, and spreadsheets and workbooks). To say that support for this format is necessary for interoperability would not be an understatement. Enhanced Metafiles have extensive accommodations for comments and arbitrary data storage. Enhanced Metafiles can store and output text strings. Mercifully, the encodings of these strings are well- defined. Record examples include EMR_EXTTEXTOUTA (US-ASCII), EMR_EXTTEXTOUTW (UTF16-LE), EMR_POLYTEXTOUTA (US-ASCII), EMR_POLYTEXTOUTW (UTF16-LE), and EMR_SMALLTEXTOUT (UTF16-LE or the low-order 8 bits of UTF16-LE--effectively ISO-8859-1--depending on ETO_SMALL_CHARS). Enhanced Metafiles can contain Encapsulated PostScript (EPS) data in the EpsData object [MS-EMF]. The FormatSignature EPS_SIGNATURE (0x46535045, in little-endian) is used instead of ENHMETA_SIGNAUTRE (0x464D4520, in little-endian) in such a case. Windows XP introduced the GDI+ API, along with EMF+ [MS-EMF+]. EMF+ is actually an embedded format in which GDI+ commands are stored as EMF comment records (EMR_COMMENT_EMFPLUS record type). Content containing EMF+ data can be identified as "EMF+ Only" (only EMF+; the EMF records are not sufficient to reconstitute the drawing) or "EMF+ Dual" (both EMF records alone or EMF+ records alone, when played back, are sufficient to reconstitute the drawing) [MS-EMF+]. Support for EMF+ records may not be as extensive as support for the original EMF records. The previously unregistered type "image/x-emf" is also in wide use. Accordingly, it is registered as a deprecated alias. See Appendix A and Section 4.2.9 of [RFC6838]. Published specification: [MS-EMF] and [MS-EMF+]. Applications that use this media type: Office productivity applications; clip art applications; desktop publishing applications; some Web browsers (e.g., Internet Explorer). Fragment identifier considerations: None. Additional information: Deprecated alias names for this type: image/x-emf Magic number(s): 01 00 00 00 (little-endian DWORD 0x00000001), corresponding to the EMR_HEADER Type field. The next field (EMR_HEADER Size) should be at least 88 (little-endian DWORD 0x00000050). File extension(s): .emf (for both EMF and EMF+ content) Macintosh file type code(s): ????. A uniform type identifier (UTI) of "????" is RECOMMENDED. Person & email address to contact for further information: Sean Leonard Restrictions on usage: None. Author/Change controller: Sean Leonard Intended usage: COMMON Provisional registration? No From nobody Fri Oct 17 14:20:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362F31A000F for ; Fri, 17 Oct 2014 14:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eofc92CmAa8C for ; Fri, 17 Oct 2014 14:20:19 -0700 (PDT) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 862171A6FE8 for ; Fri, 17 Oct 2014 14:20:19 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1XfEwV-0002p4-ig; Fri, 17 Oct 2014 22:20:11 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina-wl.atuin.ninebynine.org) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1XfEwV-0005yU-7w; Fri, 17 Oct 2014 22:20:11 +0100 Message-ID: <54418809.6040404@ninebynine.org> Date: Fri, 17 Oct 2014 22:20:09 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Henry S. Thompson" References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> <9AD273B04D7CB4B07CE8D1C5@JcK-HP8200.jck.com> <543CDE33.4030402@ninebynine.org> <01PDQCNHFSIM00005K@mauve.mrochek.com> <543EA941.6030704@ninebynine.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/o5UArMJG8r20Vm-b1fJggBb7Ik8 Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] Fragement identifiers for archives X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 21:20:22 -0000 Henry, While we agree that any move in this direction should take account of W3C interests, I'm uncertain that the TAG is the best group to engage: - They are an *architecture* group, and it seems to me this is a design detail not architecture. Jeni's draft (http://w3ctag.github.io/packaging-on-the-web/), which I cited previously, addresses a specific issue (delivery of composite web content), and provides a fairly comprehensive specification for fragment identifiers. But I'd be concerned that this structure is very biased to the particular requirements of packaged web pages, and might be over-complex or difficult to apply to other archive formats. Maybe a subset of that proposal could be used? - I've not been aware of any further TAG discussion since the publication of http://w3ctag.github.io/packaging-on-the-web/ in April. - My sense is that the TAG are currently heavily concerned with browser-as-platform issues, and aren't giving much attention to other topics. The possible web communities of interest that I'm aware of that might have a stake in any archive type and/or fragment proposal are: - W3C TAG, subject to reservations noted above - web applications: http://www.w3.org/2012/sysapps/ (with what appears to be a focus on applications that run in a web browser). This group produced the app: URI scheme proposal, which appears to be a way to define a URI that accesses components of an archive in much the same way file: URIs access files in a file system. - a research objects community group, who are interested in composite objects on the web as a way of bundling information about research results. My take is that the technical substrate to support this work would be quite similar to that which would support the TAG's composite web page objects work. - parts of the library community who have been working on resource packaging and synchronization, notably http://www.openarchives.org. ORE is specification to describe composite archive content, and ResourceSync describes a form of packaging for bulk synchronization of web resources. As far as I can tell, introduction of a top-level archive type would complement, not compromise, the work of most of these groups (but the TAG draft currently proposes an application/package type). It would probably need to coexist with e.g. application/zip for the foreseeable future, but I don't think that's been a problem for (say) XML applications being application/... or text/... A common default fragment identifier syntax is less obviously independent - as noted, there's a proposal for this in the TAG web packaging note. The app: scheme addresses access to archive contents from a different start point and in a different way, with which I think any common fragment syntax should aim to provide a route to interoperability. I don't see any conflict with the Research Objects work. There would be some overlap (but not conflict that I can see) with aspects of the ResourceSync specification, #g -- On 16/10/2014 10:20, Henry S. Thompson wrote: > Graham Klyne writes: > >> On 14/10/2014 16:37, Ned Freed wrote: >>> Very good point. Do you think it would make sense to define a generic >>> syntax (which of course could be overridden in specific cases)? >> >> I think it _could_ be useful and sensible - I've been involved in >> design discussions where URI mechanisms to delve inside a composite >> package have been raised, and it's been tricky to figure out what >> would also play well in a wider web landscape. > > There has been, and I believe continues to be, _extensive_ discussion > of this topic in the W3C TAG. A quick search suggests the most recent > discussion was at the F2F in January 2014 [1], which resulted in a > writeup from Jeni Tennison which in turn provoked various > comments [2] [3]. > > Please review this record and then coordinate any further substantive > work in this area directly with the TAG (of which I am no longer a > member). > > ht > > [1] http://www.w3.org/2001/tag/2014/01/08-minutes.html#item07 > [2] http://lists.w3.org/Archives/Public/www-tag/2014Jan/0133.html > [3] http://lists.w3.org/Archives/Public/www-tag/2014Feb/0030.html > From nobody Fri Oct 17 16:29:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229871A1AE1 for ; Fri, 17 Oct 2014 16:29:03 -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 BY77hvydfIqL for ; Fri, 17 Oct 2014 16:29:02 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF94E1A1A02 for ; Fri, 17 Oct 2014 16:29:01 -0700 (PDT) Received: from [192.168.123.119] (unknown [23.240.242.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B18E7509B6 for ; Fri, 17 Oct 2014 19:29:00 -0400 (EDT) From: Sean Leonard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> Date: Fri, 17 Oct 2014 16:28:58 -0700 To: IETF Apps Discuss Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Su1rsRTphAWK5yllFHdCcO3UPHM Subject: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 23:29:03 -0000 The following documents are about to be posted: draft-ietf-appsawg-text-markdown-03 draft-seantek-text-markdown-use-cases-00 As discussed in the last couple of posts: to make the drafts shorter yet = more informative, I split them in two. The secondary document has seven = additional syntax registrations, background information, and = preservation strategies. The main registration document registers the = media type. They are meant to be read together; however, the secondary = document makes no normative statements (no RFC 2119 key words). draft-ietf-appsawg-text-markdown-03 1. Introduction 2. Markdown Media Type Registration Application 3. Optional Parameters 3.1. syntax 3.2. output-type 4. Fragment Identifiers 5. Example draft-seantek-text-markdown-use-cases-00 1. (Introduction) 1.1. On Formats 1.2. Markdown Design Philosophy 1.3. Uses of Markdown 1.4. Uses of Labeling Markdown Content as text/markdown 2. Strategies for Preserving Media Type and Parameters 3. Registration Templates for Common Markdown Syntaxes 3.1. MultiMarkdown 3.2. GitHub Flavored Markdown 3.3. Pandoc 3.4. Fountain (Fountain.io) 3.5. CommonMark 3.6. kramdown-rfc2629 (Markdown for RFCs) 3.7. rfc7328 (Pandoc2rfc) 4. Examples for Common Markdown Syntaxes Thank you, Sean= From nobody Fri Oct 17 16:32:57 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E951A1A02 for ; Fri, 17 Oct 2014 16:32: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 C2FmSsrsPZXX for ; Fri, 17 Oct 2014 16:32:54 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7E831A0111 for ; Fri, 17 Oct 2014 16:32:54 -0700 (PDT) Received: from [192.168.123.119] (unknown [23.240.242.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9B033509B5 for ; Fri, 17 Oct 2014 19:32:53 -0400 (EDT) From: Sean Leonard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Oct 2014 16:32:52 -0700 References: <20141017232121.29395.95978.idtracker@ietfa.amsl.com> To: IETF Apps Discuss Message-Id: <400A546F-B225-432D-B285-F088F4D6AF8D@seantek.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/RtNOnN8Gjr2_io82XyElup-ZC9I Subject: [apps-discuss] New Version Notification for draft-seantek-text-markdown-use-cases-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 23:32:56 -0000 Here is one. ******* From: internet-drafts@ietf.org Subject: New Version Notification for = draft-seantek-text-markdown-use-cases-00.txt Date: October 17, 2014 at 4:21:21 PM PDT A new version of I-D, draft-seantek-text-markdown-use-cases-00.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-seantek-text-markdown-use-cases Revision: 00 Title: text/markdown Use Cases Document date: 2014-10-17 Group: Individual Submission Pages: 20 URL: = http://www.ietf.org/internet-drafts/draft-seantek-text-markdown-use-cases-= 00.txt Status: = https://datatracker.ietf.org/doc/draft-seantek-text-markdown-use-cases/ Htmlized: = http://tools.ietf.org/html/draft-seantek-text-markdown-use-cases-00 Abstract: This document elaborates upon the text/markdown media type for use with Markdown, a family of plain text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. Background information, local storage strategies, and additional syntax registrations are supplied. Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat= From nobody Fri Oct 17 16:33:59 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626DD1A1B5B; Fri, 17 Oct 2014 16:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSn5ZeuTpWSG; Fri, 17 Oct 2014 16:33:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 266651A6FA8; Fri, 17 Oct 2014 16:33:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141017233352.18234.3690.idtracker@ietfa.amsl.com> Date: Fri, 17 Oct 2014 16:33:52 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/qsK8NQRRKTokZu4Ap7vJzcy_-1Q Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-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: Fri, 17 Oct 2014 23:33:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : The text/markdown Media Type Author : Sean Leonard Filename : draft-ietf-appsawg-text-markdown-03.txt Pages : 22 Date : 2014-10-17 Abstract: This document registers the text/markdown media type for use with Markdown, a family of plain text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-text-markdown-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 Fri Oct 17 17:47:33 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652EF1A00BF for ; Fri, 17 Oct 2014 17:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 gkE4hZM0EIRu for ; Fri, 17 Oct 2014 17:47:29 -0700 (PDT) Received: from cp.hebergementsolutions.com (cp.hebergementsolutions.com [184.170.132.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A1761A03A7 for ; Fri, 17 Oct 2014 17:47:29 -0700 (PDT) Received: from [96.127.249.215] (port=61506 helo=minimi.michelf.ca) by cp.hebergementsolutions.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1XfIC7-0007dT-Ew; Fri, 17 Oct 2014 20:48:31 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_E392FB19-064D-4F39-9224-004032D19B97"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michel Fortin In-Reply-To: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> Date: Fri, 17 Oct 2014 20:46:59 -0400 Message-Id: <150B87D9-F747-4B89-87C0-F1F15A337476@michelf.ca> References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.1990.1) X-cPanel-MailScanner-Information: Please contact the ISP for more information X-cPanel-MailScanner-ID: 1XfIC7-0007dT-Ew X-cPanel-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-cPanel-MailScanner-SpamCheck: X-cPanel-MailScanner-From: michel.fortin@michelf.ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cp.hebergementsolutions.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - michelf.ca X-Get-Message-Sender-Via: cp.hebergementsolutions.com: authenticated_id: michel.fortin@michelf.ca Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/J4SkvytTQPqlBPzXej8Mn5rv524 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Oct 2014 00:47:31 -0000 --Apple-Mail=_E392FB19-064D-4F39-9224-004032D19B97 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Last draft, I wrote those two comments on the list: > Hence, I think the requirement that parser implementers register = anything is deeply flawed. If there is a registry to be maintained, it = should be maintained by the subset of users who care about having a = things registered in a central place, which for the most part does not = include implementers of Markdown parsers. That comment still stands. Having a registry won't help you if no one = bothers registering anything. And I don't see why I'd bother. I'm sure = it'll be the same for other implementers (Fletcher seems to be of the = same opinion already). Who do you plan is going to maintain that = registry exactly? > I'd question whether it is a good idea to say anything about the = output. Has the desired output format anything to do with the type of = the Markdown content? I still think the "output type" shouldn't be part of the document type. = It's weird. - - - About the new section 4 (Fragment Identifiers), I don't understand why = it's been added or how those predefined fragments identifiers are useful = at all. It is potentially conflicting with the author's intent. Many = Markdown processors accept this syntax: Orchids {#o} =3D=3D=3D=3D=3D=3D=3D where {#o} in HTML becomes id=3D"o", the intent being to make "o" a = valid fragment identifier referring to the header. - - - In your second document: > 1.4. Uses of Labeling Markdown Content as text/markdown >=20 > [...] One CMS [RAILFROG] uses media types to select appropriate = processing, so a media type is necessary for the safe and interoperable = use of Markdown. I think the core of the problem is this *requirement* you seem to be = trying to satisfy. Because some CMS (Railfrog, others?) uses media types to select the = appropriate processing doesn't necessarily mean it is appropriate to put = all the details about the parsing algorithm and the expected output type = in the media type. Perhaps the CMS lacks a place to put this extra = metadata, but that doesn't necessarily mean the standardized media type = is the right place either. You seem to be seeking interoperability by cataloging various Markdown = implementations and then selecting the most appropriate one depending on = what's available and what's known about the content and the expected = output type. I believe this is a noble goal and that it'd make a good = experiment or research project. It doesn't justify however dumping all = this data in a media type. For my part, I don't think it'll work so great as a way to achieve = interoperability. I expect it'll work well in some cases and badly in = others. Perhaps it'll fail a little less than using one or the other of = the commonly used Markdown parsers for everything, but does this small = improvement justify all this added complexity for everyone? And does = your niche use case justify asking others to selflessly maintain a = registry? I have my doubts. Please, scale it down. --=20 Michel Fortin michel.fortin@michelf.ca https://michelf.ca --Apple-Mail=_E392FB19-064D-4F39-9224-004032D19B97 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMjTCCBjQw ggQcoAMCAQICAR8wDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAI6ByrMlixq5 piBb1m3JRDRfINXQII5OT8TWqeZz8zse9vt7fUZHaPVLFeWYlj8B9BA2uHhGfyZtPtyf0nYtnFPK g7xiSXX/apE16bFfYdtHka3qupMggZp1+OZmtAdRO/TRij5C2bV2o+kIf+53LfWav2tw6pICxfJO 9Hrjl7HbYo3+l3ul9YVB5SVKG8WLmMCkpm7ti1Z4LOYF0Y5AG3d8AqYS3/5aUWQN/ZQN4BMruXSJ GFYFYBDxu7jTBbBW9l2m4u/s80e+jkJ9P9XDXeOsclCsdAtY4F2C/kOH76j6fwiABKLx454BkTMt ukts/PLtzrIy37oV0UTiykmcFCXSmc1gQk+xz25vGs/D36Ve8L+2A+J7idUYP83A1wS4JLgb4Q7J Fzl/lqLO+IDM+AGH9cujofg7Pjl2HdyDq3FOn7eAz2ZPN+zGzes5/E8rK1QnTsk9tIsi7QRIPdAB TnhC8ImOaNjVkB9JGUJ2BAXwVLB5Dq9SEdnGiyWdS7a9fb+Tfy8D2wuOA9metV0hUlrPMHCmJtZR bFZAjOlQrKhMM5hE31Qal2HF6OkfVhtE0nvqgj6dLt3871yxSYh13c0OBF6kZPR9Sgij3GZhAwEN sESI065Wg0BRSoCtWB6RxATzwIyIGgD/Gm8uPp+cv9OtSrDRwNjGphN+MQ81oVh5MIIGUTCCBTmg AwIBAgIDCZgGMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTQwNDEwMDkzMjE4WhcNMTUwNDEyMDIxMjUzWjBnMRkwFwYDVQQNExBZbjhVdjUyNmNnNGJjcmlR MSEwHwYDVQQDDBhtaWNoZWwuZm9ydGluQG1pY2hlbGYuY2ExJzAlBgkqhkiG9w0BCQEWGG1pY2hl bC5mb3J0aW5AbWljaGVsZi5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM1xHBAc 28F84D5D/ITRvjBwB3dwI7osaLizqSCZhMRpXg4zWsxIoaDy6H9OTQdpaqY431ypMGiwd7vddirK pEn/DEVb0SItTb73touChfuVVE5LHYPKcL1CfRa0XJF4KhryeP/m9sPA4N4zLb7IR4HFioOkF/XL Hkh9bv12yXUK+6jWpSNaQNf/kUz2AlKUSSx4pW2kBH72EW4xreuRs30Qqft1rqwkL4LRhipd3GA9 0Pni7mOaNSKu3kGCHKz+/4+h4SUdNuD13nhZLwLFHyHhk4I+IpFyq5/vPFr/dFRg3rdpMxhgd+M/ H4rfaUm2Kb0ODq+7FXccjDSbhCFEc08CAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQD AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUu56gBRTHUtBmsqyG mqCVXtMAz9cwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYbWlj aGVsLmZvcnRpbkBtaWNoZWxmLmNhMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCC ASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRp b24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFy dHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29t L2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3Nw LnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2Fp YS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqG GGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAJjgunxV0rh494ufL ch4bvYfoewNrW9OIZjpyS3GTzjD+a8aUIctmXo5HilIew8NwaYzRRKhQ3V4uy3rPmpIGddZfXlxm jlejMlWCVcgBBuB2CziegUCWvJbpSjz4eM0dQX6nU0zAGV1iqWkdrIxMgkgeeGWZaWV+m2Qu/oWw 9EbgegPaz+cFJNbrZEjA06d9CKQJTn2MP7POPPSwDTlTHZ/b6/X1MckAfCeEm96CRCEEzBo06Yki UMJMOdqVggAyP7huNxo7TpnNfe7ylve4vsHBSxpW7NElcMaXIgFalFVmpxZICOvxcncajCmYOzJp cb+YJuJwkeYf5CMjGsBshzGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAwmYBjAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNDEwMTgwMDQ3MDBaMCMGCSqGSIb3DQEJBDEWBBTVzOWfesBZfSWac+g9bXy0FCpW dzCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwmYBjCB pwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCZgGMA0G CSqGSIb3DQEBAQUABIIBACS6ykbCY3svsdpczrzQ34oMK+D/hk5G2YOkeE4xnj9MUlGGqiDIWDrS lIXin9gOiDrB+T11F8S81NLZ55dux9s+22GakrbKOdQy7DZx33ikeHrCPApP5dlV2r5mv4rW5z02 TRPPybEVYxKMIcqpuvEjpzF++9RQQB9Ddw97gP4hB5cPZWboPi28z67NzF6qUMZAKLZoTnNwbyYW mpIKDQJZzDVJjQMhbqiT5yG7Z81dzki58d1wjMutrDio5BezJU3WchDXcj/6vdNj6NEt9pmXuTTU VKGYVTIXA/XFDXeDiM8nxXIo3pjpjH3uqQxa2slqxSZZAVHUJS1hi1a3/qsAAAAAAAA= --Apple-Mail=_E392FB19-064D-4F39-9224-004032D19B97-- From nobody Fri Oct 17 18:34:15 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A131A0075; Fri, 17 Oct 2014 18:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXvZGviwQF3W; Fri, 17 Oct 2014 18:34:11 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:720]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F7E1A0166; Fri, 17 Oct 2014 18:34:11 -0700 (PDT) Received: from DM2PR03CA0034.namprd03.prod.outlook.com (10.141.96.33) by DM2PR0301MB1215.namprd03.prod.outlook.com (25.160.219.16) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Sat, 18 Oct 2014 01:33:48 +0000 Received: from BN1BFFO11FD025.protection.gbl (2a01:111:f400:7c10::1:164) by DM2PR03CA0034.outlook.office365.com (2a01:111:e400:2428::33) with Microsoft SMTP Server (TLS) id 15.0.1054.13 via Frontend Transport; Sat, 18 Oct 2014 01:33:48 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD025.mail.protection.outlook.com (10.58.144.88) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Sat, 18 Oct 2014 01:33:48 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0210.003; Sat, 18 Oct 2014 01:33:36 +0000 From: Mike Jones To: Ray Polk , Claudio Allocchio , "apps-discuss@ietf.org" , Barry Leiba Thread-Topic: [apps-discuss] AppsDir reviews of draft-ietf-jose-json-web-signature-32 Thread-Index: Ac/qc4EuaJQNc52BTkiXtdq34fuvyA== Date: Sat, 18 Oct 2014 01:33:36 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB17AC8@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(199003)(51704005)(15374003)(189002)(377454003)(43784003)(13464003)(86362001)(4396001)(97756001)(50466002)(31966008)(76482002)(86612001)(44976005)(20776003)(80022003)(68736004)(69596002)(46102003)(54356999)(50986999)(92726001)(92566001)(21056001)(15975445006)(66066001)(26826002)(6806004)(55846006)(33656002)(230783001)(23726002)(95666004)(77096002)(2656002)(120916001)(85806002)(64706001)(104016003)(19580405001)(47776003)(85852003)(19580395003)(99396003)(107046002)(97736003)(46406003)(87936001)(84676001)(85306004)(81156004)(106466001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB1215; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1215; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0368E78B5B Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wUrcPmDO9ZsSYVwUguzgRSbL7PU Cc: "iesg@ietf.org" , "jose@ietf.org" , "draft-ietf-jose-json-web-signature.all@tools.ietf.org" Subject: Re: [apps-discuss] AppsDir reviews of draft-ietf-jose-json-web-signature-32 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Oct 2014 01:34:14 -0000 The resolutions below have been applied in the -35 drafts. Thanks again, -- Mike -----Original Message----- From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Mike= Jones Sent: Wednesday, October 15, 2014 12:12 AM To: Ray Polk; Claudio Allocchio; apps-discuss@ietf.org; Barry Leiba Cc: jose@ietf.org; iesg@ietf.org; draft-ietf-jose-json-web-signature.all@to= ols.ietf.org Subject: Re: [apps-discuss] AppsDir reviews of draft-ietf-jose-json-web-sig= nature-32 Thanks for your review Ray. My apologies for not responding to it until no= w. It had gotten sorted into a mail folder and I hadn't seen it until Kath= leen brought it to my attention. Responses are inline below... > Date: Wed, 1 Oct 2014 20:21:42 -0700 (PDT) > From: Ray Polk > To: Claudio.Allocchio@garr.it > Cc: Michael.Jones@microsoft.com > Subject: Re: URGENT AppsDir reviews of the JOSE document set - assigned=20 > drafts >=20 > Hi Claudio (and Mike), >=20 > I've finished reviewing draft-ietf-jose-json-web-signature-32 for=20 > AppsDir. I could not find another AppsDir review on the jose mailing=20 > list to use as a model. So, I don't know to whom I should send my=20 > review, the format it should take, or the severity of the issues to=20 > include (include Nits? include minor, non-blocking issues?). >=20 > For now, I'll include all of my notes. If you can advise me of proper=20 > format/protocol/procedure, I'll craft an email to the jose list. >=20 > Major: None >=20 > Minor: >=20 > 4.1.1. & 4.1.2. The links to Section 4.1 and Section 5.1 of JWA are incor= rect. > They link to JWE instead of JWA. >=20 > In 4.1.1. the link is: > https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-32#sec > tion-4.1 > ...but it should be: > https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-33#sec > tion-4.1 >=20 > In 4.1.2. the link is: > https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-32#sec > tion-5.1 > ...but it should be: > https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-33#sec > tion-5 (JWA doesn't seem to have an anchor for 5.1) These link URLs are actually created by the IETF tools - not in the draft i= tself. (You'll see "Html markup produced by rfcmarkup 1.109, available fro= m https://tools.ietf.org/tools/rfcmarkup/" at the bottom of the drafts.) I= 'm not sure who to file a bug on this with. > 9. saying "separated by X period ('.') characters" is ambiguous: >=20 > JWSs have three segments separated by two period ('.') characters. > This means: segment..segment..segment >=20 > JWEs have five segments separated by four period ('.') characters. > This means: segment....segment....segment....segment....segment >=20 > Say instead: ___s have X segments. Each segment is separated from=20 > the next by a single period ('.') for a total of X-1 delimiting periods (= '.'). Thanks - I'll plan to make this correction. > Nit: >=20 > 3.2 change "of these eight values," to "...values:", remove commas and=20 > the 'and', change "...with the six" to a complete sentence. The "values" correction is already present in the -34 draft. I agree that = not trying to include the list in a sentence structure would make it easier= to read. > 3.3 remove the and from "...to produce the JWE Encrypted Key and" and=20 > the period from the next bullet OK > 4.1.3. fix comma splicing in: "This Header Parameter MUST be=20 > integrity protected, and therefore MUST occur only within the JWE=20 > Protected Header, when used." For example, "When used, this Header=20 > Parameter MUST be integrity protected; therefore, it MUST occur only=20 > within the JWE Protected Header." OK > Sections 4.1.4. through 4.1.10. are almost entirely redundant. =20 > Combine them like so: >=20 > The following parameters have the same meaning, syntax, and processing=20 > rules as those defined in JWS, except that the certificate referenced=20 > by the thumbprint contains the public key to which the JWE was=20 > encrypted; this can be used to determine the private key needed to decryp= t the JWE. >=20 > jku defined in Section 4.1.2. of [JWS] jwk defined in Section 4.1.3.=20 > of [JWS] etc. I understand this suggestion but disagree because there's value to implemen= ters and other readers to having each of the header parameters listed as a = section header in the table of contents. It makes it easy to see all of th= em in one place. Combining them would lose this benefit. Thanks again, -- Mike _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Fri Oct 17 18:34:33 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3E11A0195; Fri, 17 Oct 2014 18:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZTKTVoq_ypLl; Fri, 17 Oct 2014 18:34:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0140.outbound.protection.outlook.com [65.55.169.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBAC1A01E1; Fri, 17 Oct 2014 18:34:18 -0700 (PDT) Received: from BN3PR0301CA0057.namprd03.prod.outlook.com (25.160.152.153) by DM2PR0301MB1214.namprd03.prod.outlook.com (25.160.219.155) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Sat, 18 Oct 2014 01:34:15 +0000 Received: from BN1BFFO11FD040.protection.gbl (2a01:111:f400:7c10::1:164) by BN3PR0301CA0057.outlook.office365.com (2a01:111:e400:401e::25) with Microsoft SMTP Server (TLS) id 15.0.1054.13 via Frontend Transport; Sat, 18 Oct 2014 01:34:14 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD040.mail.protection.outlook.com (10.58.144.103) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Sat, 18 Oct 2014 01:34:14 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0210.003; Sat, 18 Oct 2014 01:34:04 +0000 From: Mike Jones To: Carsten Bormann Thread-Topic: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-algorithms-33 Thread-Index: Ac/oVSxcdPW/TNiPTRiX1p7gtScCIgACOMIAAD/dNXAAAX+S8AASuv6g Date: Sat, 18 Oct 2014 01:34:04 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB17AEF@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439BB0FB8B@TK5EX14MBXC286.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439BB139D6@TK5EX14MBXC286.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BB139D6@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(243025005)(24454002)(43784003)(199003)(13464003)(52604005)(189002)(377424004)(51704005)(377454003)(6806004)(86612001)(66066001)(19580405001)(107046002)(110136001)(68736004)(31966008)(85306004)(15395725005)(15975445006)(46102003)(84676001)(54356999)(80022003)(106466001)(15202345003)(95666004)(19580395003)(44976005)(104016003)(50986999)(77096002)(81156004)(69596002)(97736003)(4396001)(76482002)(85852003)(2656002)(92566001)(87936001)(55846006)(47776003)(23756003)(26826002)(64706001)(86362001)(76176999)(33656002)(20776003)(120916001)(92726001)(50466002)(85806002)(230783001)(21056001)(99396003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB1214; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1214; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0368E78B5B Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/IHVcH6LFu6aW1PHsktdQpq1tz2M Cc: "draft-ietf-jose-json-web-algorithms.all@tools.ietf.org" , "jose@ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-algorithms-33 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Oct 2014 01:34:24 -0000 The proposed resolutions below have been applied to the -35 draft. Thanks again, -- Mike -----Original Message----- From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 Sent: Thursday, October 16, 2014 10:09 AM To: Carsten Bormann Cc: apps-discuss@ietf.org; draft-ietf-jose-json-web-algorithms.all@tools.ie= tf.org; Matt Miller; iesg@ietf.org; jose@ietf.org Subject: RE: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-alg= orithms-33 Adding one more reply below - this time new proposed text from Matt Miller.= .. -----Original Message----- From: Mike Jones Sent: Thursday, October 16, 2014 9:53 AM To: 'Carsten Bormann' Cc: apps-discuss@ietf.org; draft-ietf-jose-json-web-algorithms.all@tools.ie= tf.org; Matt Miller; iesg@ietf.org; jose@ietf.org Subject: RE: [apps-discuss] Appsdir review for draft-ietf-jose-json-web-alg= orithms-33 Replies to your replies are inline below. Thanks again for your thoughtful= and detailed review. -- Mike > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Wednesday, October 15, 2014 2:55 AM > To: Mike Jones > Cc: apps-discuss@ietf.org; draft-ietf-jose-json-web-=20 > algorithms.all@tools.ietf.org; Matt Miller; iesg@ietf.org;=20 > jose@ietf.org > Subject: Re: [apps-discuss] Appsdir review for > draft-ietf-jose-json-web- > algorithms-33 >=20 > Hi Mike, >=20 > thanks for getting to this review - I don't envy you for this herculean j= ob. > A few more comments/clarifications inline below. >=20 > Gr=FC=DFe, Carsten >=20 > On 15 Oct 2014, at 10:51, Mike Jones wrote: >=20 > > Thanks for your review, Carsten. I apologize for not responding to=20 > > it until > now. It had gotten sorted into a folder and I wasn't aware of it=20 > until Kathleen brought it to my attention. Replies are inline below... > > > >> -----Original Message----- > >> From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf=20 > >> Of Carsten Bormann > >> Sent: Thursday, October 02, 2014 12:22 AM > >> To: apps-discuss@ietf.org; draft-ietf-jose-json-web-=20 > >> algorithms.all@tools.ietf.org > >> Cc: iesg@ietf.org; jose@ietf.org > >> Subject: [apps-discuss] Appsdir review for > >> draft-ietf-jose-json-web-algorithms- > >> 33 > >> > >> I have been selected as the Applications Area Directorate reviewer=20 > >> for this draft (for background on appsdir, please see=20 > >> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirec > >> to > >> rate > >> ). > >> > >> Please resolve these comments along with any other Last Call=20 > >> comments you may receive. Please wait for direction from your=20 > >> document shepherd or AD before posting a new version of the draft. > >> > >> Document: draft-ietf-jose-json-web-algorithms-33 > >> Title: JSON Web Algorithms (JWA) > >> Reviewer: Carsten Bormann > >> Review Date: 2014-10-02 > >> IESG Telechat date: 2014-10-02 > >> > >> Summary: This draft is ready for publication as a standards track=20 > >> RFC, with a few nits corrected. > >> > >> However, some additional editorial improvements might improve the=20 > >> security outcome when it is referenced by application developers. > >> > >> Major issues: None. > >> > >> Minor issues: > >> > >> 5.2: > >> Add a reference that defines PKCS #7 padding. > > > > I'll plan on adding a reference to RFC 2315 for this. >=20 > That would work (section reference would be 10.3) Alternatively, you=20 > could reference RFC 5652 (section 6.3), which is an Internet Standard (ST= D70). >=20 > >> 5.2.2.2 > >> Does "the PKCS #7 padding is removed" entail checking all of its bytes= ? > > > > Should this be changed to "the PKCS #7 padding bytes are checked and=20 > > then > removed"? >=20 > I think it is good to alert the reader to this need. >=20 > >> 6.2.1 > >> Is the intention that the sentence containing "point compression is=20 > >> not supported" also applies to any future registered value of "crv"? > >> A similar comment applies to other specifications in 6.2.1.x, e.g.,=20 > >> the reference to SEC1 representation to x and y. > > > > It would apply to any future curves registered that use the "x", "y"=20 > > point > representation. Others could define new key types that use a=20 > different representation or we could refine the definition of=20 > "kty":"EC" to make the representation specific to the "crv" value. > > > > A discussion happened on the JOSE thread "JWK Elliptic Curve key > representations and new curves". The conclusion suggested by Richard=20 > Barnes and seconded by Stephen Farrell was to table defining any new=20 > key representations for new elliptic curves until the CRFG=20 > recommendations to TLS have been made. That ended the discussion for now= . >=20 > Right, I didn't want to anticipate that discussion; I would be happy=20 > if it didn't appear that the avenue for any evolution on point=20 > compression/compact points were closed. I can add language saying that future curve registrations may use different= parameters to represent the curve value. That may get a little convoluted= because currently it's the "kty" that determines which parameters are used= . But I agree with trying to accommodate new key representations for new c= urves. > >> 6.2.1.1 > >> =BBAdditional "crv" values MAY be > >> used, provided they are understood by implementations using that=20 > >> Elliptic Curve key.=AB How are conflicts between such implementation=20 > >> defined values and future registered values handled? > > > > Conflicts are avoided using the IANA JSON Web Key Elliptic Curve=20 > > registry > defined in Section 7.6. >=20 > Oh, but that's not what the text says. I read this as a general=20 > license to use random locally defined crv values. Maybe the need for=20 > registration needs to be clarified. I'll delete the sentence "Additional 'crv' values MAY be used, provided the= y are understood by implementations using that Elliptic Curve key." The re= gistry is already talked about in the previous sentences. > >> 6.3.2: > >> The MAY accept partially overrides the MUST include? > >> Is the latter thus really a SHOULD? > > > > "d" is REQUIRED. The others SHOULD be included, and if any are=20 > > included, the > others MUST be included. Those are requirements on producers. > > > > Consumers may choose to accept keys that don't include all the CRT > parameters. Given that they can be computed from "n", "e", and "d"=20 > and sometimes they're not available, a previous reviewer had asked=20 > this language about consumers to be included. It's a case of "Be=20 > conservative in what you send, be liberal in what you accept". >=20 > [I'm not inserting my usual rant here that this bon mot may apply to=20 > implementations, but never to specifications.] >=20 > > It's not clear to me that there's any value in relaxing the=20 > > requirements on > producers. >=20 > Well, if the producer MUST send "all of the others" if "any of the other" > parameters are present, it is not clear to me what the point of "MAY choo= se > to accept an RSA private key that does not contain a complete set of > the private key parameters other than "d"" is other than enabling=20 > producers to send just that. > (More importantly, it is not clear when a producer should be taking=20 > that license.) I can delete the sentence " The consumer of a JWK MAY choose to accept an R= SA private key that does not contain a complete set of the private key para= meters..." > >> 7.1: > >> It is interesting that a mere registration (vetted only by a DE)=20 > >> can change the IETF consensus base specifications by making an=20 > >> algorithm > "Required". > > > > It is expected that the designated experts will be appointed, in=20 > > part, for their > cryptographic expertise. >=20 > There has been more discussion about the requirements levels here that=20 > I don't want to repeat. > My comment here was that a DE (even with the best crypto knowledge) is=20 > in a hard place updating the consensus about *desirability of > implementation* - there are more aspects to this than the technical ones. Thinking about this some more, I agree that "Required" is a special case. = I'm thinking that a reasonable safeguard for this case is to require that a= pproval of both a designated expert and a sitting security area director be= required to make an algorithm "Required" or to change it from "Required" t= o something else. Kathleen and Carsten, would that work for you? > >> 8. > >> I am unable to find a "security considerations" section in NIST SP 800= -38A. > >> 800-38D at least has a "practical considerations" section, is that mea= nt? > >> (Etc., I haven't checked all the references.) In general, I believe=20 > >> a security considerations section is most useful where it provides=20 > >> more directed guidance instead of saying the equivalent of "here is a = textbook". > > > > There are 14 subsections with directed guidance, plus more in the=20 > > JWS, JWE, > and JWK specifications. If there is other directed guidance you'd=20 > like to see added, please supply proposed text. > > > > Having skimmed through it, I agree that 800-30A doesn't contain=20 > > clear enough > security guidance to merit inclusion in the list. I'll remove it. If=20 > there are other specifications that you'd like to see added or removed, p= lease let me know. >=20 > This was more of a general comment that "Here is a reference to a textboo= k" > type security considerations are less useful than specific, directed=20 > references. I haven't checked all those referenced documents, so I'm=20 > not in a position to recommend changes here. Maybe something for a=20 > checklist to apply to the next security spec. >=20 > > > >> 8.7 is not clear: is it NOT RECOMMENDED to reuse an entire set of=20 > >> key material (including IV), or to reuse any part of it? > > > > I agree that this is ambiguous, as worded. Its advice seems to be=20 > > so broad as > to be impractical, as never reusing a key means that a new key would=20 > have to be redistributed for each encryption, which then requires a=20 > key to use for the distribution... This text came from > http://tools.ietf.org/html/draft-miller-jose- > jwe-protected-jwk-02#section-8.1, which was incorporated into the=20 > document after a working group decision to do so. Matt Miller, you=20 > were the author of this text. Could you clarify what the intent was? Th= anks. Matt proposed the following revised text. I agree that this is significant= ly clearer and more actionable than the previous version: It is NOT RECOMMENDED to reuse the same entire set of key material (Key Enc= ryption Key, Content Encryption Key, Initialization Vector, etc.) to encrypt multiple JWK or JWK Set objects, or to encrypt the same JW= K or JWK Set object multiple times. One suggestion for preventing re-use i= s to always generate at least one piece of key material for each encryption= operation (e.g., a new Content Encryption Key, a new Initialization Vector= , and/or a new PBES2 Salt), based on the considerations noted in this docum= ent as well as from RFC 4086 [RFC4086]. > >> Nits/editorial comments: > >> > >> 6.3.2.x: > >> The constant repetition of =BBIt is represented as the base64url=20 > >> encoding of the value's unsigned big endian representation as an=20 > >> octet > sequence. > >> The octet sequence MUST utilize the minimum number of octets to=20 > >> represent the value.=AB almost ensures that an implementer will stop=20 > >> reading the details (well, I did, and I did not write a program to=20 > >> verify the same phrase is used everywhere; if any parameter were=20 > >> using a different encoding, that sure would be missed). Why not=20 > >> define > another abstraction like base64url and use this? > > > > I did just verify that they are all consistent. Yes, if you're=20 > > reading the spec > linearly I'm sure it feels repetitive, but if you're an implementer=20 > going straight to a definition to implement it, having a complete=20 > description all in one place is valuable. I understand your request=20 > but it's not clear to me that this rises to the level that a separate=20 > definition that the developer then has to go find is warranted. >=20 > My point was corroborated by the tiny error Richard found. Repeating=20 > the same information again and again drowns out the important=20 > information. A single paragraph at the end of 6.3's intro of the form: >=20 > Each of the positive integer parameters defined in this section > is represented as the base64url encoding > of the value's unsigned big endian representation as an octet > sequence. The octet sequence MUST utilize the minimum number of > octets to represent the value. OK - I'll see what I can do in this regard. Editorially, it's a little bit= complicated because there are different subsections for public and private= key parameters. > Note that the repetitive text already has a reference that needs to be=20 > looked up in that it uses the term "base64url encoding", which has a=20 > slightly refined meaning here from that in RFC 4648. So an even=20 > better way to handle this would be to add a new term "posint encoding" > or some such to section 1.1, turning e.g. the entirety of 6.3.2.2 into >=20 > The "p" (first prime factor) member contains the first=20 > prime factor, in POSINT encoding. >=20 >=20 > > > >> 6.2.3.1: This is not a positive integer? 6.2.3.x mentions this otherw= ise. > > > > I may not understand this remark. I'm guessing you're referring to > > 6.3.2.1 and > the fact that the description includes the word "unsigned". This is=20 > there to make it clear that no sign bit will be present in the=20 > representation - which is especially important since the high-order=20 > bit is always set for "n" and "d" for correctly generated keys. >=20 > (Sorry, this is indeed about 6.3.2.x, not 6.2.3.x.) That was not what=20 > I meant: All 6.3.2.x have the form =BBThe "p" (first prime factor)=20 > member contains the first prime factor, a positive integer.=AB > 6.3.2.1 does not have the ", a positive integer", but I can't see a=20 > reason for that (d clearly cannot be zero, and it is still an unsigned va= lue). > This is likely to confuse an implementer that reads this text closely. > (And I'm offering the fact that you are overlooking that inconsistency=20 > as another corroboration of my previous point.) I can delete the unnecessary phrase "a positive integer", subject to how it= does or doesn't fit into the edit above that you asked for. > >> 7.1.1 > >> =BBExample description=AB is not a useful example for an "Algorithm De= scription". > >> (Same comment for 7.x.1.) > > > > See the actual registrations in Section 7.1.2 for more useful examples. >=20 > Maybe just take out the not so useful examples in 7.x.1? All other registration templates that I have seen include examples of all p= arameters. This is only one of the parameters in the template, and all nee= d to be retained. Would you be happier with the e.g. text "Example algorit= hm"? > >> 8.3: > >> s/because it/because it is/ > > > > Good catch > > > >> [sec1] > >> (Given the date, this is probably referencing V2.0 of this spec.) > > > > Hmmm - the version I have cached locally came from > http://www.secg.org/collateral/sec1_final.pdf and is dated September=20 > 20, 2000. But the site appears to be down at present. The version=20 > referenced by Wikipedia at=20 > http://www.secg.org/download/aid-385/sec1_final.pdf is missing too. > http://secg.org/download/aid-780/sec1-v2.pdf is missing too. Can you poi= nt me to a good link? >=20 > I just had a look and embarrassingly found that the copy I'm using=20 > comes from the personal space of a researcher: > http://perso.univ-rennes1.fr/sylvain.duquesne/master/standards/sec1-v2 > .pdf > Not very satisfying as a reference. >=20 > > > > RFC 5915 includes this reference: > > > > [SECG1] Standards for Efficient Cryptography Group (SECG), "SEC 1: > > Elliptic Curve Cryptography", Version 2.0, May 2009. >=20 > That looks good: We don't need a URL, as long as we are certain which=20 > version we are referencing. >=20 > > Worst comes to worst, I'll either reference that or explicitly=20 > > reference the 1.0 > version. But if I'm going to reference the 2.0 version, I'd like to=20 > be able to read a copy so that I can verify that the way we're using=20 > it is consistent with the actual spec, including the section numbers. > > > >> [usascii] > >> The reference to ANSI X3.4:1986 should probably be replaced by a=20 > >> reference to RFC 20. There is little reason to reference a=20 > >> somewhat hard to obtain external document ($60!) when we have an=20 > >> RFC about the > same subject. > > > > OK > > > >> (Tables in Appendix A need some formatting.) > > > > Agreed. It's on my to-do list. Jim Schaad recently told me to "Add=20 > > a width > attribute to the ttcol with either "digits" (for fixed width) or=20 > "digits%" (for percent width) to the column in question". I plan to give= it a try. > > > >> _______________________________________________ > >> apps-discuss mailing list > >> apps-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > Thanks again, > > -- Mike > > > > > > From nobody Fri Oct 17 21:28:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D851A0264 for ; Fri, 17 Oct 2014 21:28:46 -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 Ow7cB0kxT2dw for ; Fri, 17 Oct 2014 21:28:44 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D33861A0263 for ; Fri, 17 Oct 2014 21:28:43 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id ge10so1631487lab.24 for ; Fri, 17 Oct 2014 21:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zx3jcYcHQpumWJ38D9r/cnCJMpw00rKdRElNWA3fvJ0=; b=wEW5gzJsX9ce+umfolfgs17gSgmiTAsLjrckdfZE73GoKRW0kw46FqgmSCGOXJwHOn m5teuXRrpbY2Lp/eg2PX9I44wM5lIX/yI6vLFJN6FpgZ/qlMmjhB1spNizWocjFg81O6 vaHYq1I+O2YbaXFlSAJeOAKrUATMnBbH9TOw+AQ9T/HhmNyFnjGaWEKAdqBiAP7B3BmY cEv4fWQ0z+Y6l8+DT3GcMeEJ2BTjrZoBMS6M5uT41SoUQwP+jjiURaAdSOFHLe2F66Pn VB1/1N5QGPHtvgtVKqbqktulsKyu8zACQEQY14v9ORzVyS0e9ZJnEh1wyGW7tTtkEXaZ VVNg== MIME-Version: 1.0 X-Received: by 10.152.45.105 with SMTP id l9mr13012242lam.69.1413606521109; Fri, 17 Oct 2014 21:28:41 -0700 (PDT) Received: by 10.25.211.11 with HTTP; Fri, 17 Oct 2014 21:28:40 -0700 (PDT) In-Reply-To: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> Date: Fri, 17 Oct 2014 21:28:40 -0700 Message-ID: From: "Murray S. Kucherawy" To: Sean Leonard Content-Type: multipart/alternative; boundary=001a11c292488b00fc0505aaeaff Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/LTSfgczCgTufue1-utS6oFplibM Cc: IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Oct 2014 04:28:47 -0000 --001a11c292488b00fc0505aaeaff Content-Type: text/plain; charset=UTF-8 Speaking purely as a participant, except as noted: On Fri, Oct 17, 2014 at 4:28 PM, Sean Leonard wrote: > As discussed in the last couple of posts: to make the drafts shorter yet > more informative, I split them in two. The secondary document has seven > additional syntax registrations, background information, and preservation > strategies. The main registration document registers the media type. They > are meant to be read together; however, the secondary document makes no > normative statements (no RFC 2119 key words). > > draft-ietf-appsawg-text-markdown-03 > 1. Introduction > 2. Markdown Media Type Registration Application > 3. Optional Parameters > 3.1. syntax > 3.2. output-type > 4. Fragment Identifiers > 5. Example > This draft also contains all the IANA stuff except for what's been moved to the other document. My preference would be to keep them together (and Section 4.2 of RFC5226/BCP26 appears to indicate the same preference); why create the registry in one document, and populate it in another if you already know what you're going to put there? I guess there's nothing "wrong" with doing it that way, it just seems unconventional. Another alternative would be to move the registry creation to the second document so they're together, but then you have a document with a lot of introduction about what Markdown is mixed with these registry actions, and then I think we're heading in the direction of it being too big again. Along the same lines, the working group will need to decide on adopting this second document. So far I've seen a couple of people in favor only, which is good, but I'd like to see more discussion before doing a Call For Adoption. The question I really want to know is about all the stuff you have in Section 1 now: Does the WG feel that it wants to publish all of this, perhaps as a basis choices made in the rest of these two documents? My own feeling is that doing so isn't necessary, and that it really belongs elsewhere, somewhere outside of the RFC series. Having given it only a cursory glance so far, I'd also say Section 1.2 could move to the new document, and Section 1.3 should be in its own "Definitions" section. I remain skeptical about the "output-type" parameter. It seems to me the consumer of the media type knows what output form it will need to produce; this isn't context the generator can really impose. I guess that means I either didn't understand or don't agree with your previous response on this point. I understand that, for example, you don't envision email readers or browsers as consumers of this media type, but what happens if such a thing does land in one's inbox or on a web page? Should browsers and MUAs ignore them, return errors, what? I'm also skeptical about what's at the end of Section 6.4, in terms of insisting on prior authorization to make changes or updates to existing names. BCP26 doesn't seem to preclude it, but is there precedent for operating a registry this way? Finally, the syntax registry definition in the first document looks sort of complex to me. I browsed a random selection of existing IANA tables at http://www.iana.org/protocols just now and all of them are pretty much in a simple row-column format. In contrast, the registry being created for syntaxes here seems to be a lot more complex than what one could create with a purely linear schema. I can't speak for IANA but I have to wonder if they can or would handle a registry that has a bunch of values, some of which themselves contain a bunch of values. You might want to ping someone from IANA to ask about that. -MSK --001a11c292488b00fc0505aaeaff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Speaking purely as a participant, except as noted:

= On Fri, Oct 17, 2014 at 4:28 PM, Sean Leonard <dev+ietf@seantek.com= > wrote:
As discussed in the last= couple of posts: to make the drafts shorter yet more informative, I split = them in two. The secondary document has seven additional syntax registratio= ns, background information, and preservation strategies. The main registrat= ion document registers the media type. They are meant to be read together; = however, the secondary document makes no normative statements (no RFC 2119 = key words).

draft-ietf-appsawg-text-markdown-03
=C2=A0 =C2=A01. Introduction
=C2=A0 =C2=A02. Markdown Media Type Registration Application
=C2=A0 =C2=A03.=C2=A0 Optional Parameters
=C2=A0 =C2=A0 =C2=A03.1. syntax
=C2=A0 =C2=A0 =C2=A03.2. output-type
=C2=A0 =C2=A04. Fragment Identifiers
=C2=A0 =C2=A05.=C2=A0 Example

This draf= t also contains all the IANA stuff except for what's been moved to the = other document.=C2=A0 My preference would be to keep them together (and Sec= tion 4.2 of RFC5226/BCP26 appears to indicate the same preference); why cre= ate the registry in one document, and populate it in another if you already= know what you're going to put there?=C2=A0 I guess there's nothing= "wrong" with doing it that way, it just seems unconventional.=C2= =A0 Another alternative would be to move the registry creation to the secon= d document so they're together, but then you have a document with a lot= of introduction about what Markdown is mixed with these registry actions, = and then I think we're heading in the direction of it being too big aga= in.

<co-chair>
Along the same lines, the working= group will need to decide on adopting this second document.=C2=A0 So far I= 've seen a couple of people in favor only, which is good, but I'd l= ike to see more discussion before doing a Call For Adoption.=C2=A0 The ques= tion I really want to know is about all the stuff you have in Section 1 now= : Does the WG feel that it wants to publish all of this, perhaps as a basis= choices made in the rest of these two documents?=C2=A0 My own feeling is t= hat doing so isn't necessary, and that it really belongs elsewhere, som= ewhere outside of the RFC series.
</co-chair>
=

Having given it only a cursory glance so far, I'd a= lso say Section 1.2 could move to the new document, and Section 1.3 should = be in its own "Definitions" section.

I remain s= keptical about the "output-type" parameter.=C2=A0 It seems to me = the consumer of the media type knows what output form it will need to produ= ce; this isn't context the generator can really impose.=C2=A0 I guess t= hat means I either didn't understand or don't agree with your previ= ous response on this point.=C2=A0 I understand that, for example, you don&#= 39;t envision email readers or browsers as consumers of this media type, bu= t what happens if such a thing does land in one's inbox or on a web pag= e?=C2=A0 Should browsers and MUAs ignore them, return errors, what?

=
I'm also skeptical about what's at the end of Section 6.= 4, in terms of insisting on prior authorization to make changes or updates = to existing names.=C2=A0 BCP26 doesn't seem to preclude it, but is ther= e precedent for operating a registry this way?

Finally, t= he syntax registry definition in the first document looks sort of complex t= o me.=C2=A0 I browsed a random selection of existing IANA tables at http://www.iana.org/protocols just n= ow and all of them are pretty much in a simple row-column format.=C2=A0 In = contrast, the registry being created for syntaxes here seems to be a lot mo= re complex than what one could create with a purely linear schema.=C2=A0 I = can't speak for IANA but I have to wonder if they can or would handle a= registry that has a bunch of values, some of which themselves contain a bu= nch of values.=C2=A0 You might want to ping someone from IANA to ask about = that.

-MSK
--001a11c292488b00fc0505aaeaff-- From nobody Fri Oct 17 21:30:33 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19831A028A for ; Fri, 17 Oct 2014 21:30:31 -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 wOaqGVBGOCYb for ; Fri, 17 Oct 2014 21:30:30 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50AB61A0264 for ; Fri, 17 Oct 2014 21:30:30 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id w7so1578679lbi.22 for ; Fri, 17 Oct 2014 21:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fI3TgfeCcJQOlEZQWOSJyQbxdI54e6IiKHUdDDnyXsk=; b=Ftkt+l6hd4p1RUvo5U1k49u/eju0xj5i4e8YBF7269Mbhf8iQKL1jDayxmKVcc1O1V oeztTA7u2nnJRs2PBQNs0/rUvyT87Qny2qTsjLgOpM9DDNTps7imhq/gMkxHf6PXLzRI 31nP7jTk/LGmzcT2GC93kHdljgkcTcW/fzF3r4NkkFDBf4p8T9KDfC3rFY4olK3bpp3z yti+FXJjZNhmb5hYxcjzNbzOJrS/DJONku8GYHv/zDDbbDrnFZkReVRm1eDwkd5cO2cn fu3Qpc9LSLebf5UBZ8ca9klvzR1ppyB0QzqCiieisAOfI6vxq58C39cQFLBR0Mrm5KbJ GtnA== MIME-Version: 1.0 X-Received: by 10.112.234.201 with SMTP id ug9mr13215598lbc.14.1413606628680; Fri, 17 Oct 2014 21:30:28 -0700 (PDT) Received: by 10.25.211.11 with HTTP; Fri, 17 Oct 2014 21:30:28 -0700 (PDT) In-Reply-To: <150B87D9-F747-4B89-87C0-F1F15A337476@michelf.ca> References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <150B87D9-F747-4B89-87C0-F1F15A337476@michelf.ca> Date: Fri, 17 Oct 2014 21:30:28 -0700 Message-ID: From: "Murray S. Kucherawy" To: Michel Fortin Content-Type: multipart/alternative; boundary=001a11c3c832f46bdc0505aaf0e4 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/rsonePaiU4coQZqs2WGymQYOz9o Cc: IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Oct 2014 04:30:32 -0000 --001a11c3c832f46bdc0505aaf0e4 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 17, 2014 at 5:46 PM, Michel Fortin wrote: > Last draft, I wrote those two comments on the list: > > > Hence, I think the requirement that parser implementers register > anything is deeply flawed. If there is a registry to be maintained, it > should be maintained by the subset of users who care about having a things > registered in a central place, which for the most part does not include > implementers of Markdown parsers. > > That comment still stands. Having a registry won't help you if no one > bothers registering anything. And I don't see why I'd bother. I'm sure > it'll be the same for other implementers (Fletcher seems to be of the same > opinion already). Who do you plan is going to maintain that registry > exactly? > Assuming you're referring to the registry of Markdown processors, I think this was removed in -03. > > I'd question whether it is a good idea to say anything about the output. > Has the desired output format anything to do with the type of the Markdown > content? > > I still think the "output type" shouldn't be part of the document type. > It's weird. > +1'd this in another post. -MSK --001a11c3c832f46bdc0505aaf0e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 17, 2014 at 5:46 PM, Michel Fortin <= michel.fortin@michelf.ca> wrote:
Last draft, I w= rote those two comments on the list:

> Hence, I think the requirement that parser implementers register anyth= ing is deeply flawed. If there is a registry to be maintained, it should be= maintained by the subset of users who care about having a things registere= d in a central place, which for the most part does not include implementers= of Markdown parsers.

That comment still stands. Having a registry won't help you if no one b= others registering anything. And I don't see why I'd bother. I'= m sure it'll be the same for other implementers (Fletcher seems to be o= f the same opinion already). Who do you plan is going to maintain that regi= stry exactly?

Assuming you're refer= ring to the registry of Markdown processors, I think this was removed in -0= 3.
=C2=A0
> I'd question whether it is a good idea to say anything about the o= utput. Has the desired output format anything to do with the type of the Ma= rkdown content?

I still think the "output type" shouldn't be part of the docu= ment type. It's weird.

+1'd thi= s in another post.

-MSK
--001a11c3c832f46bdc0505aaf0e4-- From nobody Sat Oct 18 05:37:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FCE1A702C for ; Sat, 18 Oct 2014 05:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gggS87ZybH98 for ; Sat, 18 Oct 2014 05:37:26 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA4D1A6FF0 for ; Sat, 18 Oct 2014 05:37:25 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id k15so1619794qaq.10 for ; Sat, 18 Oct 2014 05:37:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jwj8Pz+vDxCVfzl3clj0XaY7LXSj9jKRJL1CRBfaibw=; b=X5is3cgxRxZzn1SXI0IjVcDO+raHbGKhlBbLQKrUfiUZ0iJqQzeREFrMo+QoPq8cnE 27NFySNpy6LZbcoS2TamxQN03pld/iFDgJ+BbHBJBIBRzAfBAT6z7OxZpitNmoyjKIfL 1Sjggz05+DPz5LrSbpxVCQE9pgXmN9z4ss8BrWeK3Ua3cJze9488eqq2KxRvk2/WZG7L gKdGfwOgImUw7ubaHuPP5gkLQGUZjAS0WAlWSGFaPpjIkTlszzdnNCDY6J4dl0YqJau6 p/AJjV1RhFZS6m1cyK7HVcPIuSnrL/5yaueXx69etWP90VQVtR7dK9CJg955aMDa58hi ItLQ== X-Gm-Message-State: ALoCoQmPWVgVWwpxMmEKOE+O9HEckEtWT/IPwd7AM9zcmun5h1LKhk+QUwzmMo2GIbkh6y8GBVN4 X-Received: by 10.140.98.36 with SMTP id n33mr18972750qge.79.1413635844923; Sat, 18 Oct 2014 05:37:24 -0700 (PDT) Received: from Everready.local ([76.73.248.16]) by mx.google.com with ESMTPSA id 18sm3176685qgl.5.2014.10.18.05.37.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 18 Oct 2014 05:37:24 -0700 (PDT) Message-ID: <54425EFF.10501@fletcherpenney.net> Date: Sat, 18 Oct 2014 08:37:19 -0400 From: "Fletcher T. Penney" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michel Fortin , Sean Leonard References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <150B87D9-F747-4B89-87C0-F1F15A337476@michelf.ca> In-Reply-To: <150B87D9-F747-4B89-87C0-F1F15A337476@michelf.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/y49Y6KnJSvzn9UQEmrp3_h9-Lw4 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Oct 2014 12:37:28 -0000 On 10/17/14, 8:46 PM, Michel Fortin wrote: > Last draft, I wrote those two comments on the list: > >> Hence, I think the requirement that parser implementers register anything is deeply flawed. If there is a registry to be maintained, it should be maintained by the subset of users who care about having a things registered in a central place, which for the most part does not include implementers of Markdown parsers. > > That comment still stands. Having a registry won't help you if no one bothers registering anything. And I don't see why I'd bother. I'm sure it'll be the same for other implementers (Fletcher seems to be of the same opinion already). Who do you plan is going to maintain that registry exactly? Agreed. >> I'd question whether it is a good idea to say anything about the output. Has the desired output format anything to do with the type of the Markdown content? > > I still think the "output type" shouldn't be part of the document type. It's weird. Agreed. > I think the core of the problem is this *requirement* you seem to be trying to satisfy. > > Because some CMS (Railfrog, others?) uses media types to select the appropriate processing doesn't necessarily mean it is appropriate to put all the details about the parsing algorithm and the expected output type in the media type. Perhaps the CMS lacks a place to put this extra metadata, but that doesn't necessarily mean the standardized media type is the right place either. > > You seem to be seeking interoperability by cataloging various Markdown implementations and then selecting the most appropriate one depending on what's available and what's known about the content and the expected output type. I believe this is a noble goal and that it'd make a good experiment or research project. It doesn't justify however dumping all this data in a media type. > > For my part, I don't think it'll work so great as a way to achieve interoperability. I expect it'll work well in some cases and badly in others. Perhaps it'll fail a little less than using one or the other of the commonly used Markdown parsers for everything, but does this small improvement justify all this added complexity for everyone? And does your niche use case justify asking others to selflessly maintain a registry? I have my doubts. > > Please, scale it down. Agreed. I firmly believe this is headed down the path of being an overly complicated solution to what is actually a simple problem. Additionally, to be pedantic about the whole thing.... If the media type is to be "text/markdown" then there really are no flavors. Everything that is not Markdown is, well, *not* Markdown. This includes MultiMarkdown, PHP Markdown Extra, Github Flavored Markdown, CommonMark, etc. If your goal is to allow a media type to accurately distinguish between all of these different, but related, syntaxes, then in my opinion there are two options: 1) "text/markdown", "text/multimarkdown", etc. Just like "image/jpeg" is not "image/bmp", the current proposal is conflating multiple distinct things into a single media type. 2) rename this proposal to "text/markdown-like" (or something less ridiculous) and then include a "flavor" or "parser" option. While just as cumbersome as the current proposal, it would be a more accurate representation of reality. I think Michel's comments about Railfrog are on point -- I believe that part of the difference of opinion over this matter seems to be that the *stated purpose* of this effort (at least as I understood it) is to officially sanction a "text/markdown" media type to be a more universal identifier than "text/x-markdown". I think this is totally fine. I personally don't really care (I have no problem typing the two extra characters should I ever need to use this), but I also have no reason to object to it. The *actual purpose* seems to be to create a complex method of identifying which of a long list of programs was used by one person to convert something that is sort of Markdown, but sort of not Markdown, into HTML, or something that is not HTML, so that another person can then wonder in frustration why a different piece of software can't replicate what the first person was doing. (Because you *know* this isn't going to work as well in practice as you hope it will in theory.) If the goal is to get Railfrog to accurately choose a Markdown parser, then simply add support to Railfrog for "text/x-markdown", "text/x-php-markdown-extra", etc. and be done with it. Problem solved. The difficult part is not *specifying* which Markdown variant to use. The difficult part is the code to match the specified variant with which programs are installed, and passing the appropriate variables to that program to get the output one desires. This process is no more or less difficult regardless of which approach to media type one is using (though, if anything, I bet using distinct media types would actually be easier to code and to understand as a user.) Therefore, I truly don't understand what the current proposal, in it's complex form, accomplishes. I understand that Gruber has, in his way, consented to the concept of "text/markdown." Has he consented to the idea of using "text/markdown" to refer to a bunch of things that are not Markdown? Based on past history, I would bet not -- but you never know and clearly I cannot speak for him. I would recommend asking him. I would not support the idea of using "text/multimarkdown" to refer to things that are not MultiMarkdown. Please. Simplify this. Create "text/markdown". No options. No parameters. Everyone can get behind it. If Railfrog, or someone else really needs more detail, they can use "text/x-multimarkdown", etc. until there is enough use to justify a separate IETF proposal. Fletcher -- Fletcher T. Penney fletcher@fletcherpenney.net From nobody Sat Oct 18 06:31:52 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BC71A87BE for ; Sat, 18 Oct 2014 06:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eP3G5c-I3ZdA for ; Sat, 18 Oct 2014 06:31:47 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1ACC1A87A8 for ; Sat, 18 Oct 2014 06:31:45 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 33769509B5; Sat, 18 Oct 2014 09:31:43 -0400 (EDT) Message-ID: <54426B74.9090006@seantek.com> Date: Sat, 18 Oct 2014 06:30:28 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------070206090309060903070807" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/9xs88jbEsinvTX9ZwM7Hg-0yNjY Cc: IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Oct 2014 13:31:50 -0000 This is a multi-part message in MIME format. --------------070206090309060903070807 Content-Type: multipart/alternative; boundary="------------020307090903010204060501" --------------020307090903010204060501 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 10/17/2014 9:28 PM, Murray S. Kucherawy wrote: > Speaking purely as a participant, except as noted: > > On Fri, Oct 17, 2014 at 4:28 PM, Sean Leonard > wrote: > > As discussed in the last couple of posts: to make the drafts > shorter yet more informative, I split them in two. The secondary > document has seven additional syntax registrations, background > information, and preservation strategies. The main registration > document registers the media type. They are meant to be read > together; however, the secondary document makes no normative > statements (no RFC 2119 key words). > > draft-ietf-appsawg-text-markdown-03 > 1. Introduction > 2. Markdown Media Type Registration Application > 3. Optional Parameters > 3.1. syntax > 3.2. output-type > 4. Fragment Identifiers > 5. Example > > > This draft also contains all the IANA stuff except for what's been=20 > moved to the other document. My preference would be to keep them=20 > together (and Section 4.2 of RFC5226/BCP26 appears to indicate the=20 > same preference); why create the registry in one document, and=20 > populate it in another if you already know what you're going to put=20 > there? I guess there's nothing "wrong" with doing it that way, it=20 > just seems unconventional. Another alternative would be to move the=20 > registry creation to the second document so they're together, but then = > you have a document with a lot of introduction about what Markdown is=20 > mixed with these registry actions, and then I think we're heading in=20 > the direction of it being too big again. Splitting the document had two goals in mind: 1) The text in the secondary document is not "as normative" as the first = document. In the first document, it says that the original [MDSYNTAX],=20 "Original", MUST be supported. The others do not have to be supported. 2) If we include seven additional registrations in the first document,=20 it becomes "too long". People thought the first document was getting too = long. > I remain skeptical about the "output-type" parameter. It seems to me=20 > the consumer of the media type knows what output form it will need to=20 > produce; this isn't context the generator can really impose. As the document revision went on, it became clear to me that a primary=20 consumer of this media type is **Markdown editors**, not Markdown=20 processors. When I picture a Markdown editor, I envision something like=20 the attached puc.png. Just [Google it][] and you will see many prominent = examples. [Google it]: https://www.google.com/search?q=3Dmarkdown+editor Markup formats like HTML are publishing formats. Markdown is a writing=20 format. People exchange Markdown content because they are=20 collaboratively writing something. When they are done, it gets converted = to text/html, application/pdf, text/plain (RFCs), e-Book, etc. Markdown is a format of record only in the same way that shorthand is to = a news article, Adobe InDesign (or Quark) files are to magazines, or=20 nroff (or xml2rfc) files are to RFCs. It's the historical building=20 block, and therefore is interesting to historians, as well as to people=20 during the creative process. We could rename the "output-type" parameter to "output", or simply,=20 "preview". I could even rewrite Section 3.2 so that it more explicitly=20 calls this "live preview" aspect out. That would capture all of the same = semantics without confusing people about "forcing" the Markdown into one = particular thing. Of course once a receiver gets the Markdown content,=20 the receiver can choose how to turn it into whatever output format the=20 receiver wants. So maybe I should address the WG on this point: what is the feeling=20 about renaming "output-type" to "preview", with refers to the live=20 preview, or "right-hand side", of the Markdown editor? > I guess that means I either didn't understand or don't agree with=20 > your previous response on this point. I understand that, for example, = > you don't envision email readers or browsers as consumers of this=20 > media type, but what happens if such a thing does land in one's inbox=20 > or on a web page? With the prior explanation (and Section 1.2) in mind, easy: pass it to a = Markdown editor. The Markdown editor could be desktop-based=20 (MarkdownPad, emacs, vi), or could be some web app (Dillinger,=20 StackEdit, Google Docs+Markdown). Markdown is not a publishing format. Having a web browser or e-mail=20 client merely render it to HTML and displaying the HTML would do no=20 good. (If that's what the sender wanted, the sender ought to send it as=20 HTML in the first place.) You want to open Markdown in such a way that=20 you can edit it, or at least, see the source text with some syntax=20 highlighting. It's just like a forum post, where you click "Edit". You expect the same = kinds of widgets to pop-up. Sean --------------020307090903010204060501 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 10/17/2014 9:28 PM, Murray S. Kucherawy wrote:
Speaking purely as a participant, except as noted:

On Fri, Oct 17, 2014 at 4:28 PM, Sean Leonard <dev+ietf@seantek.com> wrote:
As discussed in the last couple of posts: to make the drafts shorter yet more informative, I split them in two. The secondary document has seven additional syntax registrations, background information, and preservation strategies. The main registration document registers the media type. They are meant to be read together; however, the secondary document makes no normative statements (no RFC 2119 key words).

draft-ietf-appsawg-text-markdown-03
   1. Introduction
   2. Markdown Media Type Registration Application
   3.  Optional Parameters
     3.1. syntax
     3.2. output-type
   4. Fragment Identifiers
   5.  Example

This draft also contains all the IANA stuff except for what's been moved to the other document.  My preference would be to keep them together (and Section 4.2 of RFC5226/BCP26 appears to indicate the same preference); why create the registry in one document, and populate it in another if you already know what you're going to put there?  I guess there's nothing "wrong" with doing it that way, it just seems unconventional.  Another alternative would be to move the registry creation to the second document so they're together, but then you have a document with a lot of introduction about what Markdown is mixed with these registry actions, and then I think we're heading in the direction of it being too big again.

Splitting the document had two goals in mind:
1) The text in the secondary document is not "as normative" as the first document. In the first document, it says that the original [MDSYNTAX], "Original", MUST be supported. The others do not have to be supported.

2) If we include seven additional registrations in the first document, it becomes "too long". People thought the first document was getting too long.

I remain skeptical about the "output-type" parameter.  It seems to me the consumer of the media type knows what output form it will need to produce; this isn't context the generator can really impose.

As the document revision went on, it became clear to me that a primary consumer of this media type is **Markdown editors**, not Markdown processors. When I picture a Markdown editor, I envision something like the attached puc.png. Just [Google it][] and you will see many prominent examples.

[Google it]: https://www.google.com/search?q=markdown+editor

Markup formats like HTML are publishing formats. Markdown is a writing format. People exchange Markdown content because they are collaboratively writing something. When they are done, it gets converted to text/html, application/pdf, text/plain (RFCs), e-Book, etc.

Markdown is a format of record only in the same way that shorthand is to a news article, Adobe InDesign (or Quark) files are to magazines, or nroff (or xml2rfc) files are to RFCs. It's the historical building block, and therefore is interesting to historians, as well as to people during the creative process.

We could rename the "output-type" parameter to "output", or simply, "preview". I could even rewrite Section 3.2 so that it more explicitly calls this "live preview" aspect out. That would capture all of the same semantics without confusing people about "forcing" the Markdown into one particular thing. Of course once a receiver gets the Markdown content, the receiver can choose how to turn it into whatever output format the receiver wants.

So maybe I should address the WG on this point: what is the feeling about renaming "output-type" to "preview", with refers to the live preview, or "right-hand side", of the Markdown editor?

  I guess that means I either didn't understand or don't agree with your previous response on this point.  I understand that, for example, you don't envision email readers or browsers as consumers of this media type, but what happens if such a thing does land in one's inbox or on a web page? 

With the prior explanation (and Section 1.2) in mind, easy: pass it to a Markdown editor. The Markdown editor could be desktop-based (MarkdownPad, emacs, vi), or could be some web app (Dillinger, StackEdit, Google Docs+Markdown).

Markdown is not a publishing format. Having a web browser or e-mail client merely render it to HTML and displaying the HTML would do no good. (If that's what the sender wanted, the sender ought to send it as HTML in the first place.) You want to open Markdown in such a way that you can edit it, or at least, see the source text with some syntax highlighting.

It's just like a forum post, where you click "Edit". You expect the same kinds of widgets to pop-up.

Sean

--------------020307090903010204060501-- --------------070206090309060903070807 Content-Type: image/png; name="puc.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="puc.png" iVBORw0KGgoAAAANSUhEUgAABN0AAAHKCAIAAAC426pYAAAAAXNSR0IArs4c6QAAAARnQU1B AACxjwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAP+lSURBVHhezP11eCNZnif8up67u+/0 NFR3VRdXMjrJzJbFzMwsy8yQzOgEJ4Od6WRmZqikYmamrsbq6d0d7pl333u/v3NCspxZ3TN7 7/5x/XwfZTgkRYRCIWV8/DvnRJbJVVZYMb6geFxu6aixU575+S9/mZEnKE888QsWTFDYzEd/ +ctHH0ce/9ljPI/99BcP5xc//fkvfpIZzOF3PfZY6omZwczB4DHpDHkYVkqrZsFmPBT2AJbH Hv8pJb2cwYUI81Obig0bsp1sU9OhF8K3XNgYtj3ptQyuiz0gvcDMpBb7Y8rPf/zokPwt5dG/ /RnlRyx8mmay0MPwrJ///CcUYZnpTaLtefxxvBcPh2+YEPYrzedvbuptfezJJ3noV3pzf/nz Ie+skEeR1G4XDozMpA4PvsxfPIGlUX6OPPBInsefSC+NbxhWIezAxx77CZLadT+mCC8f+dt0 sNOEmeyRwk5g24ZV4xU99dTjTz39+NPP/PKZZ5949rknn3v+qeeHPf388GeGjXh2+MjnRiCj kOeRkaN/MOwBI58dPuKZYcOffn7Yk88+98Qzz2KZjz35FJZPr44+CJl58FBkeeLRJyipXfTk z/FcIVgOWxRf2kML/PkvMYeF35t6AI7/HwxfI5sefOvZoS6EzfnlYPBINv8n7Iilg1PY4cLO x3zhTeELZMl4aYNvHy2fFvJY6iD/xY8f/QU7sCk/elQ4sCmYZuHvo7Cux+gdZCui9/EvRdgY OjweOEJSK/1PJrVtwib99NG/ofwsFfYZpAfQg3/yc1pdxg5MbQ+bpu154IU/FLa17JuBL4S/ WfR+8XeZHRX8I/PkUzi6HnvyaTp0hTzDJ9hR91T6qOPvHdsAIcJiUwv8xRP0eL40CpYwuEy2 QFomD38YPxqxClpL6oAUVick/bHNnPlwHsfm0Rb+9DEEB4aQn/AJmsmOPXoJwmNwF3bRj3+O 4K35xY/orfn53yDCW/Po/4X8BPnZfzL/7T8KPeynGRm866f/6Qyuji+ENlU4yOnoEg4Afnik wg7g9FsmvGuDYe9pOhl7L7UE2kX/YYQD72/ZzhQOdbZLKexXNp/uSs9n+zm9H3763348NPz1 Zr7GwUUJS6OVCosdXDIeLLx96V2dWghbzoMLwTYPbj9bzl8Iu2twy+nYwBb+1x//9IH8tx/T fPYe0WbwBw+GHWa0GT/jqxsM5vD8zU+xiiH5v4Tw1yUktcyf/wgRlvkXM/SF/H+THz8qvN0/ +Tn/ZLGPlZAnWNiHC/Px4fr54/TgRx8Tno4Xm3p1NJ252MGjaGgyHpMO3wbaANoGti5h1T8c 3DuYXzyBp/D8mDbv8b+lzRMi7Hz6KsCKBuf/rbA9fI2plbL1smXSdOYy2Ut+OHz7hV+FBfKl 8b1HX19PPvpLFkw8/iR+pbC1pJfPn843cnBThaXRY/hW8aUN2QPp1/7z1HZiacJLE7bnx2x7 fkJvIl+IsA2PPv4U5ZepsF9/RuFb+OTg8tnChY3kRzKFfa/SQcg3OL3NbKWpCO+psFtSYXNS jxH2XmpnPpD0vamwVWTMSW0P/yj95NH/9pNH/+uP8fn92X/58U//y98K+X8J+QlPev5g8OAh YU/PDHuYsIQfPZwfC/mbh5K+K+Px/wWhzeB54KvmZ/8V3z9/IfQtlJkH7h0S2hWUwe8W9rWT /qYacqTRuzbkPXo4Q9+19JcAOyT4t1l6RYPfirSiwW8GehZb118MnSYJK0rNFN5l/p1Ji33w f/D0Gn/26GMjnnluwsgxBZOG5U9+Njc7S6QpKJUWlEsLwInnhg9buWbN7//4xwfyB5YhM7// 4+++/17IHyi//cMfHszveX7Pkv418zF41l947l8LPYuS3oCM/Pb7wUf+5vfp/J4lc05q5u9+ /2vK7/43w571+1RS879Dfov8ludXyG94fvMtz6+RX3/D8x3l6+++o/yK51f/2+FP/+67bx6a GFzgt7/6iif9LCTj8cKW8MfTI7/96ptvv/zmmy+//uYLFkxQaKYQ9oBv6ZF/MbSczKd88fW3 n3/9TWY++/rrz76ifPrVV59++dUnX36ZyhcffzGYj774/KPPhXyYzmef4ZbN5A/Ds7769Kuv aclY17e/+vJXeL14gdjV2PO//fa3v/vV737/3e//8Ovff/+bP/zxt9//Hc/v/vinvxT2gD/+ 5g/f//r3f/jud7/HQrAoLPPLb3/1xbfffvENvZzPHszXQ/PNZ99QPk8HTxSChbDl8EWll0Z7 g/LZV4OL5btr6APwYh/O4HzsjcFg53wxdA72FQub/hJ7j/bz5xlJ7//0mzK4FpavM9dFD6CF 8Od+hndnMB98+hnP+6mJDz6j8PdRWNGXX7BVUNKL5fmMkloX21phXeyJQ7b5P5cHN+yTz97/ 5NMHw+5iD6OnfPw5rZF240O7DjN/YO/xl5b6lT2ALYE/nV4LvYmDby47AHAYfPENHRU4wL78 9rsvf/UdDjYe+hVHC3sMHQb8GBC2QQhtVXqZfGnCotjSfjh0r3AoYtUUdijSWjIO76++4Rv8 cLAl6Txw1ydfIl99/MUPhB2NDzzgy48+R/DufPEBvTWf4y14/5PP3uP5+FPk3XQ+4vnkfzsf Z4YW9d4nQ5c85AH/ybDlsEVhgyl0hNMBJhwAdKAKBwAdA6nDgN6yh3aaEP5upkIPZjstczks wq7jYTtQ2I08H7L9KRztbK9ShONfuCs1n+/t9N74wf3Gdhd/gZT0ojIXKCyWlsxWl/E+8qen dpTwhcA2IHMhbLMf2PgfCt01ZBVsy9/56JOHkn6DaDNo1Zmhp/Pl8NUNBnN43v/k83TeS+dj rHFoBhdLj+Tb9pcy9IX8R0ltCSaEsPkffUZv98ef02HAP1OfDuYb3NJH7AvkKzyGDozPvkwv cMgy+Uy+zMGjKCPpJw7N4AbQNrB10Xr/YnBvZvAUno9o8776kNYi5AO+/+nbACsanP+hsEl8 jbTS1Hr5KxUWyF7vg8tMJfMl0BxhgWxp2CraVPrG+/azr1P56lv8imRuNi38c3o638jBTRWW xjaMPZ4/l5KxE9IL4eFbwp8++Bp/cCGUX32WCqZZ+PKxhbSRH39By08v+QMEhzGFjnY6PoXD PrUfBtf4cIQdmw7bKnaXsPH8ufR0noznUoQnCl/4LBnL4U/he5JtKtuTqYNzMMLuFd6yzL30 UXpdX37NM2RdDyXjM8KC95q943TGlRH2P2BG6L/FXyHCf5Tp/1WF/6N//Q//9E9ef+D//j/9 s279emHq/9DPlqZqYer/D378avk//fO/LF7R88Qzz/7o0Z8/OeL5x8eO+GX2uCxHXGSPSH/y 6KNr1q179+OPDp07u2H3rg270tm9cTeyh7JrD35dvxPZtXbHzt7tO1b3bV/V17dya1/P1m09 W7at2LwVtyu3bFu1lWauxK+btvZs3tKzhc/vQ3DXqm3b8cQ1/TuwhDXb6ZZlO8/qvr50Vm1j oacg/av6hCeu2T7Qiw1ABnau3TmY3oEda3bsWL19+6r+/p5t21Zs3bpiy9blm38gyzZtWbYR 2bxkw6Yl6zcuXr9x0boNi9atT2fhYNalQr8uWr9+8YYNyBJk40aE/4r5eMz8devm9vbOXdM7 e/UaZNbK1TNXrpqxYuV0ZHlP59JlHUuXtS9e0rpwcfP8hU3zFjTOXdA4Z17d7Dl1s5DZNTNn J6fPTM6Yhdvq7hnVuJ0+IzljZs2MWTUzhdTOmlUza1bt7Nl1qdTPmd0wZ07j3LkIJngwHw/D chLd0+Nd03Eb6+qOdXfHu6cnZsxIzpzJFjKnfs7chrnzsCVI/ey5NTNmV3fNiHdMj7R0BJra ffXNXqSh2dfY6mtsQ/xN7cHmjmBLR6i1M9TWyW/D7Z2h9s5wR2eooyvU2RXqoDnh9q5Qe1ew tdPf3OFravM2tLrrWpw1Tc6aRnt1g6263hKvMcWqdZGEJhxTBsJyf1Dm9Um9XrHbXeVyVbqc FU5HucNeZreV2qwlNmuRxVxkMRWaTQUmU77JmG805ptMRRZriRWPcYncXlkgpIkmjMk6W0OT q7nNhw3onhmbNbdm3qLGxSvalq/pXr1h9rqtCzbtWNq3Z8WOAz0DB1fuPLR615HVu5GjD2TV 7iM9A4eW9u1duHlg7vpt01evb1nSUzN3YaRrhq+1w9XYaq9rMifrjYlaxJCoQfSUpI5STalO 6pM1hpoaY22tqa7eXN9gbWi0NTY5mlpcza3uljbE1dTqaGi20aIaDPFaTbRaGYorgjFFMK4M JVThak0kqY3W6ONYRZ0hUauLJtXhuDIYlWOPBSMKnlBEGYqowlF1JKqKRDEtD4SkvqDEGxC7 A1Uuv8hJqXIFxe6Q1BuW+iIyxB+R+yNSX0jsCVS6vNiHpTZHiRB7qd1R5nBW4I1we6o8XrHP J/H7ZcGgPBRShELKcFgVieBWHgxJ/QGx1ydyecuxBIujyGgr0FvzdZZcrTlHY5qmNk5RGyar 9NlKbbZKO0mtm6TRTdbqp+qNuSZzodVa4nCUu10ir0fs98lCAUU4qIyEVJGwJhrRRKPaaAzR RePaSEwdiigCIZkvIPH6qtyeSqer3O7ENpda7TgGSiz2YpYiig0ptNgHY2Yx2QuMtnw93zbj VJVhskKXLdNMkKjGi5XjUhkvUWXLtVOUhhyNOV9vLTJhFa4Ku6fK6RO7/VJPQO4LITJvQOLx i10+kdNTYXeXWZ0lZnuRKSNmR4nFWWZzVziwtdhmbHlQ5gsrAlFVKK6JVOti9M4aE/WmZIOl psla2+yob3U1tnuaO70tXf7W7kDr9GDbDNx6mzvdDW2OumZrssEYq9WGE8oA3sSQ1BOUsLdY 7MaSI8ogFpvUx+tMyUYszdmAA6zD3dRBC2zuyoynqdPd2OFqaHfWY7E4mFtstUiztQaHYqOp ugFbpY/V6aI1WKAKq2OHpTwQlWG9ARxgUUUQiSlDPDhcWYJ4WFwRiMv9UYknLHIFK+z+Mpuv 1OortXhLzN4Si7fM6q+wByodwUpnsMIRKLf7Sm3eYou70OTMM9in6axT1OZspXG8TDdWohld pRpZqRxRoRheJh9WKnu+RPpcMSJ5tohH/EwhCyYokmeKhTybmnimWCykRPJsqeTZMslz5dLn K2TDK+UjRIqRVQrc8gwXyTFzWKUc9z5XIcPt85jmwXS5DE98rmwwz5dJh5XLhlfQs0aKlKPF qrFSzQS5LltpmKo15xlwEOKj5CrFsWF3lzs8FU6vyMUOA08QH0N8+pTBmDqc0OA7kL4G4/ho q0NITI35CI4Tf1TpiyjwYE9Y5g5JXMEqZ1DkDIjoNsTDdiPfk9jV3lKrp8TqLra4Cs3OApMj 32jLM1hz9ZZpWstUjRnBRI7eil2N5OptOTrrNI1lsso0Ua4fJ9GyHa6gHV4uH1Yme75Mhtc4 DK+xgr1GiXqcTDtRqZ+MzzU+3fgc6S15tDRbvsFewJKnt+XqbDla61S1ZbLSNFFhoLdSqsW7 OQYRq3FLC1HoJ6kMU9Qm7KscnQUbiU0tMNoLTPicOhBMY06+wYrlY/tzdZYcPFJLE3k6a77e loe1aCxTVebJCuMEmX5MlWZEhfK5UtkzJdKnWZ4qkT5TindNMbxSNapKO0aMI0o/TqqfIDNM kBknylkUpmylebIKO8Geq3Pm6lwUrStH65qmdk5ROSYpbBPl1glSy3iJZZzEPFZsGlOFGFkM o6sMuB1ThbVTxon14yWGCVLjRJkxW26chChM2AmTlUaeKSrTVLUZOzxXa83V0ktgsfOw/SZk GqJBrNPU2JPWqSoh01Q2JEdtz9c6C/XuYqO3zOKvsIWqnBGpOy73JhTeaoUvqfTXKH1JuSch dcXEjkilLVRm9uPBBTpXntaZq3Hkqu1YCJKLF6515Gkd+TpnocFVZPQUm9hHNZVik6fI6C7Q u/CAPJ0TtzwFeneR0Vti8pdZgpW2cJUjJnFXy701Cn+dwl+vDNQrgw2qYIMyIEQRqMd8OeKr l3nrJJ4asSspciYq7LEya6TYHCo0BvIN/jy9N1fnmaZ1T9O4cJujc+PXPL0n3+AtMPqKTP5i S6DUGiq3RyodUZEzLnYlsF6pJ4mIXdVVjnilPVZujZSaQ8XGQIHel6/z5mMJWncuhd7cdPL1 ngKDt8jkK7HgmypS5Y5LfUlFoE4VatBEmnSxVh5ttFUTaVGFmrDxYk9NpTNRZosWmUP5Bl+O 1j1V40LY1rpydJ4Co78Em4dtw4Z5k3J/He2HUCNuFYEGLEHqrRO7k5UOLCRWYgkXmYJ4Cl51 HnuZFAMW4qOXaQtXOGNVbiynRuarw9OVwSZVqFkValGHWxFMIMpQiyLYLPc3ynwNEm9dlaum wpEotUaLTKF8vT9H65micmYrbBNkFmS8zDROahwnxQfTMglHFDvs8w34+vUWW/2ltiBSZguW 28MVCI4c2slIrApxROnWGa10RHBvuTVYZg2U0tvhL7H42USgHM+14d0JVTrw7RTBYVnliiJi N/5HwBESF7tjVa6YyBHFEspsoRJroNDkyzd68apzdNiTjslqO0Vlz1Zas1W2SSrbZLVtisaO TNM5c/AhNbjzjJ58k7fA4iuyBoptwRJ7sNwVqXBHKj2xSm9M5I1X+eJVuKXExN64hEXKIkM8 cYUPn5SE0let8lerfNXqQI0mWMujC9fpw/X6SL0x2mCKNZrjTZZEiznRbKtptdW02evwn2aH s6HT09ztbZnua53hb58Z7Jj18lvvjM/Je/fjTy/cvJ3KHeTirXTuIpd4XriXmcu3H8j9K3fu X71z/+0PP+6cOeur73597d5L1++9dOP+y8hN5MVXbr306gsvvXr75deQO6+8jtx99Y27r/C8 zjL4K3/AnZdf/+DTzzfUhD578e5bu/vf3NX/zu7+d/b0Ie/v6fuAsu0Tls/39H2J7N36zd6t 3+7d+qu924ZkH+U7lvRE+tdv9/V9vW/b1/v6v9rX/8Xe/s/29n2yt+/DPZT32LqQt3f3vbGr 76MbVzzyKrzGDbsPYO+tWL3mb378k8dGDf/FuNFZemPeL554onf9+uv3723YvXM9sotlJ88u ZANZVBDpOlCQo7QfKO1fua0PIXZuFUS6elv/mr7+Ndv6V2/twwT7dTvS2w92wp8DeDoWsg6L YgsXsotP7Fw/gAysQ3bgkTtY6CmUAXoKPWvX7g0MyRug5T17Nu3ZCzxvSGXdrl3wKgEVW8g2 kkybTsav2GCEi3rF5i3LWWhi02YEal2G202bl+J2M2U5u0VWbNnSs3XLCp4t9Cufv3jjxkUb NixcvwGCXbB2/fzedfPXrJ23Zu2cVWtmr1ozc9WqGStXTV/R07VsRceSZR2Ll7YthFEXURaA qQub5s5vnMMzT8hclnnzm9KZP5jmBQuaFy5oWbgQaV20sG0hpRW/Yv78BU1z5zXMnls/a07t rNm1M2bVgrUgLjNtAxCLJdDTF7YtWty2aAm2pAVUnrugYda82pROo21d4dZOnkhrV6StO9rR He+cjsRw2zU93j0jPn06y4zEdD6N21S6Z0Q7p4fbukItnVCuv6nNB53WNrtqmxxJ0LTOGK8x RBPqUFQZwIl+gKNU5AZKXRUuZ1kGSkusFri08AGXGvGrpdgKRDkhK5k/pI7GBZe2tPmA5Okz 47Pn1c5f3LR4RfuK3umrN85Zvw3OXNa/t2fHgZUDh1btOgyUrnkIpQi5dOehpf17F24ZmLdh 24zV61uX9NTOYS5taXc1ttjqGs3JujRK/0OXWhoarI2N9qZmR3OLq6XV09oOlzqbWu31zdZa SKBOFwMA4jjpl/px6h+VQ6c40Q8n1KApA4wuXgO4qkLgAVQZlgUoDKhhomk4ApSqwpBqGLtC 4gtUefw4D4aIKhzeCgcm/FXuoNgTlnjBUYGmgy514ATaWWJP0dTuKHU4y52uCre70uOpwlvj 90sCAWkwwHUqD4dwKw0ExD6/yOOtcLrLbM5i2M+IU0acOOIM0jQN9ku7VKXjLp2s0XOX5pFL bSVO5lKfRxJgLo2ElJGwOhOlsTiCCTW9tJDMn3apW3ApttaKCC5N0XQQpQVmG8WEs152msu3 TW2YotRPkmsnytSAKDg6tgpRIOPEqokyzWSlfprGlKezFBqBXme5zS1yeiFAiScg8wXhUil3 qRsu9TKXukrMDuwBpIil2EygZS4lkIjJpdj+QZem/uJQDwdCg5aaZltdi4NhkkvSB522dPua u9yN7Y66FmtNoylRp4tUAy3YAGwJnFzF3mIRbVgIGlSFElisIVGHBdLS6luhUwJqIw7adoKo YNE2ey3+lwV0myzJRnM1WdSUqDfG6/SxWnBUG0mqwzjYEopATOaPSn04bEJib7DKg+MqgAlE gp1ACUv9PDicwhJ6ZLjKAy8FwKRis7vI5Co0OgsMzny9Ayk0uopN7hKLB6F7zTglcuUbHTAS yMRRCt2BMaOqVAxIsudLpeRMUmjV00iB6Kl8pPJJJK+ChU3zFIiGpFDIU0VVTxdXPV0ifqZU oCkIShZlHOUhlFYSSsmllSmX4legtEwK05JsSyXPlEK5YkyQTsulw0i5CmwtxAWDcZfmGqyF FkexzZVJ00qiKY4ZOhL+mks5TXGcEE0jaZpKGU3FlFAVJYyIXIymzkC5w1/GkD/UpfCnLVdv naZLuRTAe8ClWstkNc5TYTbuUuWISgUgOgw0TaEUL3BklXKMRD0eH5lMl+osWDgsioCm+Xr4 ygZxTWMunTTEpVrsn9FDXEoLIZdy2QKl5FJCadql8Cq5FNusA63xyTUPuhQbT2sxk35lhrFi 7chK1XNl8gdc+jy5VE0ulXCXYnvIpRPkQrJBRxV2DpbmwDl6jpYyTeOcqnZMVtrZCb11vHQQ paOrjBSRYRRFz6JDRot0Y6p0Y8XgPXSqH88APFFuyEYUhkkK4yTQNOVSbDmnaTqYA4VO1eAj QJ8CZDLIjSjNwC1FjlsgHLFMVVoFmhrcJSZfuTUgcoQlrpjMk5D/FZcCPHCpgFLyLUUN3pNO 83T4eDKamkDTwQClmIm7YNdcrR23LE4sqsjgwdrh0oqhLiWUBgilqmAjD1SW0mkD6dRXJ/XW gmfkUkeszBYpsXCX+iA06A7GS0nPnStQzQvAFJlBIMApBDIRllxxjlIZ5OapwXSVU3BpiTlY ZPADpSRSjQvJUTuRaRTHNI0jRwNmu/INnkLo2hKAxOClB10ab9XCpZEWTaRZGQT8oL7qcnus 2BICJgHmKWrHJBUhisUxFcvUe4vMRMpKRkopdkiAdgh/1RzkeNXlDKWFxmC+3per9WCrcLwh 2DAce7m0YWw5VuAQxAXnkthjMh9gD9w2ygMInNwoY5FCpJ66KnetyJWssKdR6svRuKeoHBPl VkB0jNiAjBbrR1XpcDtWioPflK3EwYZPqyNPj29pTxF0aobSsZPx7R2CMFM6FSLCLUTK7gJK yaUIodQPnSJlNqJphR1P5DQNE02ZTsUMqMBqpTNMC7GHsJYisw/vbJ7BPYhSlS1bZclWWCBn HgCV6xTBpoKmOTgaDW5otsDsLYSK7cFSB2gaLndFodMKTxQ0FQGoHkoVAgy7Y7Ax8dgdlbrx SYnJPXG5N850miCa+pNpmmpDpFMDp2mcaAqXWqpbLMkWuNRRTzR1NTGatk73tc0ItM986a13 xk2DSz85f/M2kqFTAupFngygklFf4PlhnYKmMFv79Jlf/erX1+6+mKIp6fTm/VdupWnKdApz cnmmCfrANBcsXLo+Efz03u03t29m2fTW9k3v7EA2vL9jwwc7Nny0Y8MnAxs+HdjwxcDGL3dS vhGy6Qfz7a4H83UqX+3a9NnOTZ/u3Pjxjo0f7tiI5WMtb7M1vsHywZWLDim5dHpP74yVa49f ugqa/ujRnz828pms50Y+8dywYe9+9JHAURLpwDpkYAfhkMIYyTgKIvbuoCLnmv4dBLy+vp5t ECnRNCVS+HPHuu0DyPodAwyZOzcM7Fo/QLjduGvPpl17Nu9JZy9l774tPHv2psPuSj9mn5C9 +7fsO7Bl/8GtByjbDh5C+g6lgumDh7YeOLBl3348GF6FUdPV3XQyXgvPAKicWbBd009ZzWqz q+FqFrxY5vC+NXgAS++OwfA5K/uxH6hIy31LUt0EqSKbFm3YtHD9Rnh1Xu/aOWt656xZM4vV UWes6EG6l63oWrqsa8myzsVLOxYtQdqFLOa/di5Z2rkYt0u6liztWjo0y5Z1L1/WvWL59BUr cNu9nGXpMjwFT2xbBPEuapnHmEqsndc0nxzbumhR25LFHUuXdOHBK1awLVmJzehctIyoPG9R 05wF9bPn1EyfneyeWTN9FpKcPrtmxhye2plU4K2fPbduzrz6OXN/MHUISDxzTjVwCMe2T4+2 d4UB1OZ2b32bG2fMNY3WRK2RSqY4CcNZGs7yPVUeD1BaCas4HXBpGqXFmS41k0vz0i612OCo CpdHylxqSNZaBZd2h6fPSsClC5Y0Lel50KWsWJp26QM0XYXsYvXS/r2L/pJLGSZJpNB1HMBA kjpKtRYhl1brk8mHXeokl7bBpZ6WdubSJkttg7G6ThtLKkMxnN+L6USf0zSuCCdUkWpNrEbH XKqmgiq5FC92kKYZLsUtfpX6qVjKXVrh9JbbKXCpKNOlWAUggdUxl5Y73HApoynTKaadrjKX uwIC9HhEXm+VzycOcJoGpaGgLBQCUCX+QJXXV+n20NNtTmCsgM4jLbmCS01TNcylapyD6lix FCg1TNEZphlMeWZLkc1e6nRWeNwin1cS9MvCwUyXaphLtVGglOqljNwZLnXhRN9ZZqdg1eli bzGP1VFkdRRamUs5TU048WW1I7ZtU4e4VDlWTCIdwzJWrJwg00yCS9VGnAQXGm3cpZWOQZdS rRIwS8vQ4SmHQCyQOWiaisUJl5bbPdyl6XqpPBBVgh9h5tJYrSFeRyVT0JSVTO11rURTYiQr dVJhk6E0SSjVR5NAi8IfxqqxXiIxVm0n+tK2QTuEXkbTONHUWkvLtNFi8R8qVUTJojXNlmQT WTRRj4dhG/RRwaKaFEeVwbgcIvVFCJnuoMiFg8Rf4fSVO3CoeMuxXrxqN4KDCgmIPCyYcOOR MBKA5Cky4+yKV4HYObfaMk1twSl4ng7HiVPAqsHBgQTJTNGYYRUBSGIq3MFFz4GCxeKnAcsC xs68iieQ3PJfIjllyOPp5CJsfh5SMZh8yhN4epHoqYdomhkGUdlzGcEcGPXZckIpOIrnsgwS 99kyKdQKvIFtqXKiAdwil+IYsDrhUqKpzZWiKf0RQewJwvD8LxTE0XBcFY6pQizBKIVQGlEy lCrxSHJpiFyKj3DapW6g9C+41OoqtDgLzI58U4ZLtWaEudSWB68a7bkGculUwaUGttvVI0Vw qRIQxYsilJLYFcOptqwaI9WMl+smqvCJTpGSuZTTFChFeNFPcKmKLZa5dAx3KauaYg65lOOW y9aITyhDqRlxPoDqXL3g0rSEuUtBOxxRU1Qm2A/uHSlSPV8uf6YUHJU+zfJMmfz5CuUIkXq0 GGvHufgPuHQiyEdn5/C5HTTFiS/ZQO2gYilcKrdOkDGUSsxjxIRSxlHDSIp+ZCWiG0GBirEB WgB4NNVm4XDdOKluvFQ3QaafKNdjP2QrDZNBcTW+GAWX4pZ/NDCHgK3C8Q8qGIUosG0kWyrw QrkUw0RWjJ0kN4OmwGQ+cGj0lFn8lfYQzvtldKpNLlXBpf4aTEvdcTEkwFwKRoKyAC04OlVl nYJXrbSwGix2o20ITWFRCqziSqHUngO6U4QSK6uvAq5waeBhlwKl6lCjOtTEbikqhIDaSDr1 18u8tRAamFfpiA91qQcWBUphvJRL3dBjgYBS8lKFHSiFMeIST7XMm5T7WJHWV8tKpgmRI1bB XFqIpWndOWoS6TSgUWXPDN7iXK0zX+8uMHqKzX64VEQurVYEatMu1cdbdTGgtEUdhksbJN6a SmccVkyjdKICh4d5gtwyEVFYJilx5BMpixl0IWdsIds8kLIWRuUvucIeK02hlCqurCyfLQfG rJNYpqjwIcK2AYp4ySHsH+gdT4ROxeC3p1YC33rrYVExC0Ra6UxWOGDmeIkliiXn6X3TNO7J SvtEmWWsBActDlENDlHcDq9Q45b9pUY/ToZjDEeddarGlot33+AqMOB9HwRqKV4IKRSMTIV+ pUopK5aSSNk0bllseIPw2oMVDnIpj8gZqiKgYoeE8WsFlWSpylps8RWaPPkGNxyOz91UjR1b AoViT06Qm8fLTOPpc2qaKDcjkCruBU3xsGk4jPXOXByZrGoKmhZjvc5QGdEUodoplU8RV0Tk jiKVThwzrHjrjIidUYkrKkXcUZmbgKrwxlWk04TaX60JCrVTbbgWNDVEG4yxBriUaJpssda0 2mrbiKaNjKYtXUTT9hkvvTnEpUN1eid1m6Yp1ym7/cs0feuDj5o7ur761XdX797nNEVAU6Fk +iK5NE3T/yAvIa9+8MlnayOej2/fenXz2lc3977B8tbW3re39r6ztff9rb0fbFvz0bY1n1J6 v+jr/bIfWfONkN6H81V/79fbe79NBdNfb1/71fa1X/av/bx/7ad9az/q6/1wW+8HbPlYy1ub et/Y1Pv65t5XNvd+cOGsXVz+1ocfdePknNH05bfeefKZZ3/2zC+zfv74z3rWrDlw+jRZlLJj 7QDLju0srGIpNLWFSLeDZ5mVUkhs1TYm0v7ta/uptrlhYOfGXbs37yZVbt2zD9m2d9+2ffv7 9h/oP3Cw/8Ch7QdZDvEc3nGYMiDkCLKT3Q4cPko5ghzbeZTn+K5jJ1hO7jp+cveJU3tODsnu E5h/YuexYzuOHMWS+4HVA4e27Tuwdd/+rfv2bdm3j02kg1+FcBhv3r2XZxMPUzReC8+m3Sx7 dm/au2fT3t2b9+7ZvG8vC/26cc/uDbuo6svcO8C4Sy2KaXdRa+ftPdv6VmzbtnzLtqWbNy/Z tGnxhk2LIFUqq66bx2qqc1evmbNq9ZyVq+mWZTamV7Np3K5ePZfdzluzBpmL295eFkysmb+2 F1mwDsuhu/iiZvesnEnuXQFwdi9bjnQSYkmwM1b2zFy1ajYWuAbPXbcAm7FuPdV1V/fO6Vk9 c/nK7iUriLULFrctWNg6H7Jd2DJ/YfP8hS0LAF3MpPpqG+S8mNKxREh7OouXtCFUB17UNG9h w+z5dTPn1U6fU901K9Y+I9za5W9q89Q3O2sbrNWgaUIbjioCOFHzVXk9IpcLKC0HSh22Urut 2GYFSlMuNT/s0iLuUqdH4g+qImmXtvs7u8MzZiXmzK/7QZdSvfTgKtaOdw2146XAopmBXZf2 7cHj561Pu3RBpJO5tCHlUgGlyQyUJnjSJVPm0jrm0iZ7c7OzpdXd2uZp6wBNnc2t9oZmS22j 4NJwXBqISPxhaSAqC8bk4EGkWh1NarGKRJ0uwRr6CjVV4BMPS9E0FFFwl0ai8hDmp+qlbriU W8IHLVR54FXWjtcfBWDkQWqWKfEFRR4/YF/mdFPV1OEqcQgoLXe7KzyeSq9XhLfG768K+MWB gCQo0BS3Yr9f5PXBrnhiCXepkblUoCnOIxlNNYbJFP0UQqlxqt6YYzTnW6xFdnupy1Xh9VT5 fVisHC6NhpXRiCoaUTOXDmawfbJfTC71wqUVThejKc74KaUU5mqbsxgbY2M0Tbk0n1xqzTPQ htFWQctKfbZCO0GmHsdcOgapUowedKluKrnUXGC0AZllzKXgJRgvTbvUGxB7eMWScFhqdRZb wNEhLoVGUu14uUYGC2XaaFIHE8brDIk6Y3W9KdnIaWqra7XXtzrq8Z8flToFlMbrdNFqjlIp BEgidWOlZTCPFSx3EU15IY5pBwuHOU1YLMSbiinBi6L1hhiIW0sQDWOZCQ5RaoUbiMn9UZkv KvVGJB4SaSWBx1dm98KZJTYCj2AtvF4HDhgcNsTUchxmLGUOL1Ji84AWACdOu3HCPYXKPlTz wS24ArfkwTAGKp9iAhGKpZkurVKNgBLLpM/CgUVVTxZUgqMEztxyQaHTSh+jlLDw6dLHcnjK KLkUjtXH8UTQtDBF01IxNejljXWF0uhgMl1KYS4FQQFRPFdIEd0KxC0DceUjBpu5Ci4FC4tw SCA2OiYZTT34MKYadYdk/shgW2hqF42vwQjFH6aAo76QAm8oQigNcpRWOYNVriA4SiIVUBos dwbKHP5Su6/E5i22uYsyXWq0YWMGXQrmGTJcqk+5VAlAMpdiz4vIpURTdguUjqhSjhQzlyp0 2XApPtT4EOGjJLhUqJcK7yaj6VQNziPNExXGcTKAUDuGaMpcKtWMA26VBnIpbY8Fm4HtxNbi mClCLC7cCiVTbCprh/ygSzGfGgwz0alwzmoEAkeJ1HDps6WyZ1iexm3apRLYmLlURi4VIqdQ yZSa8uLwo1NeitoOckxW2Xkj3vFSnNkPopREWqkfQdENp2gpFZrhlRqc7tPZvwgn/ZrRVZox Yg20jIN5vEw3gdGUSqZqfCXiu5Foio1nIqUC6WQVeEwQncAj149HZPgs6MZh4wFdsXacWIeM lwCoxskKM3iZp3UUGtylZl+FLYSzbdaUl7k0UAOaCi5l9dJSk69Q7wYpodCpSgueTgVYuQkT U5T4hFqmqa1gZ57Ojk9lgYH+ZlSgp+DXXIZS1pyYHsZLrFh1gd5dbPKCLuRSGAwu9dUOojTc pBlMM24ZU5tUoSbQlEqm1JSXXFouuNSfzxrx5mgJpQgmIJY8uNToKTT5iqEg1sSUo1TqFcin CtSrWZthgabORKU9WspcmqtxcZFOUdomK6xClJSpsJ/GkaeDxOBSfMXhA8VcGqxVhRs00Sag NOXSZrwWRaBe7EmW26NFZqjPO1XtBCN5HXKsBMERCEThfcTxD89T2+ByewS7RcrwTBvmrq5y JfB6S62RIhNDKatnZtMxZhqHJUiM4xH60wO+KnF44OsRSvQVs8IpVl3hiFc6EpXOaii00pWk W85RR3WZDYuNFlsihFKdb6raNUlhnwCUio2jcJSWq54vVT5fpnyuTPFcqQK3wytUOFBH47iS 6vlHYAoOAC02HvsE77sLxxU16jZj7ayZrjWIlNnottQaYGTFa/RRjZSlnCqlqdipW0GFPSB0 2bCzOIJ8TjkDLY4cABgMztO7crSOKVQpBUrBe0Gk2A9C2K8TGVDxgEkqGz6qU7TUrDfX6M4z ufPN3iKbv9geKHWESqFTZ4ho6orAqBWIM1wOD6fjoEbvQLKE69RNQJW5o3JPTOnjtdOEOsBq p1Q1rdUzmhpiDcZ4oyVJNIVLbXVtjgbQtNPd0uVp6fa2TX/xzbfHTst98/0PT1y+djIzV64j px7MDeQ0z9V0biJnkGuUs9duvfbOe/UtbZ9++fX56y+cv/ECVy40e+mFu3MXrbK7kn8l8xav vnbn/gN5+4OP1vptH9649uLa5S+vXfYKsm7Z6+uWvbFu2Vvrl73D8gHLJ+uXf7p+2efrl32x YdmXLGta2tMLX9PS8dWG5bgdnNPa8fXG5ciXG5d/TlnxycYVH21Y8eGG5e+uR2j5WMtrfKW9 y15au+ydMyetlSVwadeKNd09vdNXrl2/Z//iFT0/evTHWY8+/suPv/gCIiWLcpTyMmC6fjhY QqQC6ar+/tX9/auIo9tW4lfqCNqPx3CRsnLoXii0f/+B7QcO7Th4GAEydx05tvvo8T3Hju8+ Rrd7jiMn9iInTuyjnNx/8tT+U+mcPnDqzIHTZ5GDZ84eOnue5cKhc5TD5y8eOX/pyAUhRy9e 5hHmnL+IBx84c3b/qTN7AdfjJ3YdPb7zyDHm26M7U7eZGThyBNlxiOcwD2dz/8FU+K+CpQ9t P3xox5HDO47glqYphw72HzrYd+DAtv37AeDNUO6efdTAmNoY71m/azdrgUwdYtcwr9Ke7Ovr 2bqN9YCllsNLN25eumEjZSO7TYf1YqWZmzYhvMEwb1G8fMvmZVs2IZhIhx7GHr+ImhOvW7B2 7fxeyrw1vWTa3t7569YtXL9u0cb1i9kyl2/Zgm1YsWXbss1blm7ctARa7l0/H05etWbWilUz lvfMWNYznQfTy2HdVQjumrUSWT2bCE2daSmwLsusVatmrlw1sydVhl28rG3+4pa5ixpnLwBQ k92z4x3TQ60dvqZWV32TJVmjj8XVIfgKZ/zeKg815S13OcrsthK4lImUh1xqyXSpsYC71Ooo d7qHurQt7dLaBYublqxow6G/ev3sdVtY/9LdK7bvz6Dp4VU8Ow+vzMiKHQeXboNLd8yFS1et b13cUzNnQbhzhrc55dIEuVQfSyK6WLWWktBQ4og2kRBKpql6qa2piRrxtra529q97Z3etk5s p6OxxVrfZKqp1ydq1dFqeSgmC8KWVClVRpPqWI0mXqvDiqrr9dV1mlhSFUnAkxBpOrIgdynr XBqJAqiYI/UHxaCpNyBy+ytdFAGlJNIYdWHFqXA4jlssQewNVLp95S4PAo7ylLs95R5Phddb 6fWlXBrgLpUwl+KWudRLpuUuhQCFpnecpjibZAjUmqZocQ5qnKozTtObphlMuSZLgdVW7HCU ud1wL8QrDQXkkZAyw6VCIkhMFcZZO46QoMSXdqmnwukud4CmCCZgJOZqO8iEAAODLs1nLs0z 4oycbxJvXaxLuVQ1RqyES4FSBNPjZZpspW6K2ogHQ7NFZgdQQcUulw/al3jBS4ZS5lKGfw/8 WcJdCo2kgjm8UEY0pZIpNp4KZZyOvCnvEJpSg94mS02zpbYZQOWlTkuy0QiURpKqINBIlVLW m5cYjCMfa6Q2wxZsIW8wzKqm/ojQhZVKsqwqy6LH6iKsLhpOEkfTECWLUhWdt8IVe0JVbpyl ATxUggMyi61uaIFRB36wF2KljFvUThUvnIzqodg9JSxwUb7JkaPHCQQ74Wbn3MDDpJRL6dzX 6ETyKVQyxYMJSBpTthJmoHrpCLhIcKnoiXxCKQkT2oQ5mUJ/Ma3kF1NTwbQQzC/9RRqoTKeP 4blYAnBbJHqSufSZMgm0KTTZHUJT+XODIZc+WwHeSJ8ulTxVIsZzKVgIX06qZPqwS3NSLhVo yjDPGvQymvLPoy8kh0Kpu3hEaJyPUNflkMwTRKSIO4BIXAGxK1Dl9Isc/kpKoIKlnAUiLbOn UYqd/0Mu1VumgqbQ3VCX4lfMxG5nLtXhJQguTdEUE0ApMkqiHiNjLsVnR4NPNHMpxJhyKbUN pj8xpF1qzXCpDi4dLR3iUiwES6BGvEYb7SsLvkDwCXLR3z5SNGUlU6rHPuDSvEyXqs2TFDh/ 1Y2qUg+rUDxbJkOeKUu5tBIbj/UOupTTlE9g20BT6mWqAs6tU9Q2ispGKFXahGKp1DxWAn4Y R1UZgVImUj1EOqwC0bJoWLB29fBKyohK9UiRGtvD2y2D5ePlugkKPSuZmqDQaVrq8cs3fihK iaPYP3gvUnVmzRhsP2hN0YxBqgBU/USZcYrSkqO2gxA4xS+3BnG2DYXKPAnuUqFe6opVOSIV 1mCJ0ZuvA9JsU5hIs3GiT9VXAyaoK6zCBJ3SZ1NjzU31d+XBr5hJeGaNiiFYABU6BVbz9a4i 46BLATBSYrBeFSKXAqLaSDNLSyrQKQU6BfOoZEpNeZlLwUhyqSdX52YudSA5Wmeu3pVncBeY PEVmEAjaCVU6I2J3DChV+GtUwTp1qEETbtRhLeEmrJpo6q4WOWJlgC5zaRqlVJBkmUSFTbwc G+AHQ7J6qQ9LFmGxzKXqcIM22qxPtBoSbax/qeDSKjf4Fykw+qdp3ZOU9vEy86gqPRXJRTj2 dKOr9IBltsKCLYcni0y+MiswFhG74hJ3ggq5TqgSLzZabA4VGPy5vOen3DZeaqa+yqwpOIW1 Bp8gwyFBNMUOYZ1gQcEQQFtqi5bZYmX2eJk9gdtScNQWL7HGii0Ac7iQ9SmdpvFMVjoyUKp+ rkT+TLHs6WIp8lSR5JkSGWg6jP3JZpQYx6cOn4JsJWvQjjeX106ZTql8asLavdj/qSa+PL5i FuiUhg+w+spt/jKbn0RKNAVTMU2pYNOCSPEYKxbiLTZ7C03uAqM7V+/M0TngzMlqG17vBI5S KYhuwEFOoSbxhvESA2ZS6wY5vlKowDtZg/8vHFN1jlyjK8/k4TQtsQdLSKdBqp1Cp+k4KGX2 IG9jTCVc0imVcEFTilOgKdcppymiDQltevWsagqampPN1ppWa12bvb7d3tjhpJJpt6dVcOkr b7974PT5g2d4LvAQXvhtxsThs6DKRdxm5si5S8jR85d5XnrjreqGpo8+/+L4xSsnLl49cenq yUvXTl2+dvrKdVDw//1Xf/CA89dvUa6xsOnX332/12n84MrFeyvm318xj+cVpGfe6z3z3uiZ 93bPvHd65r3XM+/Dnrkf98z7pGfepz1zKSvnZq4R06saWx6Y8/mqeSzzP101/+NV8z9cNf+9 lfPfXTn/7Z75b/bMe62H1vLy8nn3ls+9T7fz3j5xxFySz1y6uqunt3tl76xV69756OMf/ezn cOnjv//+eyqK8jLpgNA29W+ljX8ra/jPRtq4Yeeuzbv3bIVIDxwcOHR41+Gju48e23vs+N7j ZM6Dp04fPI2cOXjmzKEzZw6fOXv47LnD587x26OU88cuXECOX7h4/OKlE5eunLx89eSVa6eu XD997Qb9/eD6rTPXX0DO3kBun71x59zNO+dupYLpm7fP0V0v4PF44vFLV46CqXDs2XNYL5jK cnpoUhI+iY08CR7zYJtZTjA/C9mbnjh5fN/Jk3spJzCduj2++/jxXUeP7jzKoHv4yI7DwO1h mLbv4MFtBw5u239wC5F1P8jKsboBWB3YtW5goJcVV3uBf2o5zMd86k9N8Gn6W8Ca7eR/hP5e sGNHL94pIZjmERoV0x8O+qiUvVIY+SnVrphrduuWFdu20t8UtvdDyL0DA2sHdiK92wforw/b +ldCy5u3Lt2wadG6DQt71/FQX1mWBb3rF6yFeOHejZDtYlB242Y+BBSNAsWS7mS7cO36eat7 56wk4k5f2kPthOcvaZ6zsG7m3OrumZH2rkBzm6u+0ZrEqXlcHcb5ekDi9Yo87krWv7SEFUvT LmU0FVzK+pcaC82YaS2x2VMujWW04+0Kz5gZnzOvdv6ixsXLW5ev6lq1btbazfM39i/eumtZ /94V2/f17NhPNB04uHLgEE9PRpZv379k6+4Fm7bPXbd1+sp1LYtX1MxeEO4glzobWqw1DcZE LRNpUhcFMBIaShxRR2NquJSVTLlLzfX11IiXF0sJpR3+zi5soaetI01TY029LlGrilYrI9Uq EmmtJlGnA0eTDYaaRlNNo7GmAQ+AXYFJWRD4jEiRtEsjUVU0hgzSNBCS+ENiXxBnwOwkGK6j tsHKcEJFzYMTWBQkLw9F8bAqr7/S46vweCvcXkGkmPb6Kn1AqV8ElKZcKh50aQAzH3Qp+AeX PkBTHWg6iNIcgznPZCm02kucznLWiFdMLg3KI4RS7lIVEyn1mKVOs1QsFRrx+nBC7xVRO960 SwmlaZpSvdfuKrZTvRSr4CjNM+Hcl6FUTxszRWOcrDZMUukmKrTjZeqxUtUYiXK0WDlKrBgF moqV42SaiUodHjNNZ8ZrKQT8rE7ipROrBk2ZSFlLaQTgLHeCZFRIhEVZQ0TsBxppqQhMTdG0 3AmNEE2pNa8/ogzF1ORS6jzMaaqnoa3qjdUNxupGEw0+JMQYr4ckCaVAI6uUAqVMpPYis62Q +s1acTtIU1oFq8piFeGEhnowVmtZeHVUHRwUKVnUyyxKCVV5cHIWRCpdgUGUWtyFFpeAHLy/ Jls+XqAF5mfusrnSOi1GbJRCK84VmEu1lklgA6MpO+/BGTlE4cBJSZHZU2QBdymFZqGLKa/d 4ex8rEQzUqTk7Xh5vfSXeRWPM5oK5dAc5k+uU2GCOMozBKW5ZfREuLRQcOlTQ11KESqlmSh9 2KUMpWmaYjmZLhXa8ZK4YLaHXcqqpoymNAaSD28T/ZGCLMqaP/hCYCqODQkby0rs8lOclCqH D6m0+yps3nKbt0yIr5SlRAhE6i22cpTy98uZP8Sl5M9Bl5rsuUZ7TsqlkzSmCUrDWHKphlxa pSKX8gClYkQ1SqoeI9eOV+qz1cbJ9Jcm8xCXUmFTcGmOzoZ3mbt0gtI4Tq4fI+MuJZpiYpxC T42ByaUWbBs2EopmpXhXidWNw5h3kcWnCZ8jan4/6FLTgy7VMpcqf8iluC3nLqV66Rjm0rEy 0FQIpulXuX6CgupFkxhNJ6usOD9GshXWiXILzDCOUCoUS7lIhzORPk/RpKLmGVaholSqhleC 9yrszFGgKSgu04L0VCVmTXmnasilUzUplKqwASmUgqMyLaswU5vn0VXqUVhOpXJkBYIJ9ahK NWiKM3VqzUslUydryhsQOSK8i6nCV039S/01mMYckT2Me4sMnlyNY4rCwkU6QYIzfqrEsn6w +oly6gGLjyf7s5E1h429NNjxVUAppGRK0RSCtZFLeb2Ud870ss6ZrFgqoDTaohPSmpEW0BQP k/vqJJ5k1aBLqREvNemkzr1UuKYev3o+Kg++hXxlQAUs4Y5KvQm5P6kK1WnCDbpIkz7abIy3 GmIt2nCjKlAv99aIsUxrqIhc6uQonSS3TJSZkWzeIlRhEQa7Ar3gUosfbqlyx2T+pDJUp440 aGPNBuZSfRwubVFHmrlLS22RfKNvqsY5UWEdKzGOEGnZHyN4nVw7Bp6U41sOR6ZT6LbKxA6a MpTGqAVvqljK2tk6Jsqs48QmyHZkhUZIpWaUSAuYwWBYFOtu6s43+ApNgSJzqNgSLrZEiq1R IRZKkSVSaAoXGEP5hkAuK5ZmK2zjJebRIv0IHJylymeKpE8VSp4sFCNP4LYIX1ygKW9NgEOU aDpBoCkVTommWqFdN9Mp7SW8CyxeLtJi8NLiK4EzrRB4KkyegkttvnKaQ6EJllJCqafI5AFK 8wxAqX2a1o7PHT59ExUm7L3xMqAU3//6sWLqsM0ztkpHg4pRI3zWsldpycbnlFdN9axqavYU WH2sagqdEk2pdopbe6DEFsBtKW5ZG+NUD1gq4RJNGVC5TlmzXtIpNev105BIVDgN1WjDrLtp jFVNE01E09pWW30bXOpo7HS1UNWUu/T2K69t23+YcuBw34Ejg9mP26OY6D9wFME0TRxM3SKH jm6nHNuBHD42QDl+4/5LgXj12x98uOvIid1HT+4+dnLPMcDk1L4TZzJN+IM/eMDh0+eH5Mz5 e6++vsIof+fc6euz22+y3JrdfmdO+905bffntr00t/XVua2vzW19c17rW/Na35vX9j6l9UOW lTV1D0BUmGLTK2vrP17Q9tGCtg8XtH+woP3dBe3vLGh/a3776/PaXp3b9vLcViz/7ty2O7Pa b85quzGrHXnt4B5D3mS4tHO54NIZK9d+97vf/4BLU7bphzZ/1nT6Pxk8eMuevX37qEa68/BR cBS6OwCLnjpz+OxZsPPYeQLniYs8l05e4rl86jLLlSunr1w9cxW5du7ajXM3bl249cLFF+5c vnP/yt0Xr9576eq9V67df+Xai68h11+i3HjpdcrL7FYIZuIBr1y599LF2/cuAKs3Xjhz9cap K9dOXLxy7MLFjBCAj57nOY8cOZfOOZ7DZyiHzrKcOcty5tDZs1A03Yvb84M5fA7z6QEHzpw+ cOoU1EpwPUHV4N3HT+w+Bq8eZ16lbD98BF6l3rBUXKU2xkIr4j17N9Ggx7s3Ukfc3ZtYNvLG w0IT4j2b9uzevHfvlr176XYfZTO73UKtlNmve/duQvbswRPX01BSBM61RN8dawaQAVLoThrd ikZdpgbJ9Nyt+/dv3X8A27Bp916sev3ArrUwat/2VVv72LhQW2lcqE00jjGrrPb1YD7C2iev BqeZlqnRMssqrmJWDe7Zsm35pi1LNmxa2Lth/uq1s3vWzFy2qmvx8rYFSxrmzE/OmBXt7PID ZvUN5iTOzmOqFE0r3S5yKbXjFRrxpl3Khj5iLjVl9C9NuVSfrLHUNzqbW73tnaHpM2Kz5iTn LWhYtLRlaU9HT++MNRvnrt+2aPOOpdt2L+vbs7x/bw8rnPZsp6wYmmV9+xZv2Tl/Q/+c3s3d PWubFy5Pzpof7pjubWp31jeTS+O1TKQ448epf1wdgTRi2AZQCjRlJVNyqTHt0hYqlnraO3yd XYGubmSQpk0tFqJpg666Vpuo1VXX6asb9ElYtMlU22Sua7bUNZtrm3jJVMkwKQsxl8KfcGmY uRQ7ECGaxpThqCIEhdLoqazRb0QexJy4ihoGV2uiSSxHG8dttTIM5YbF/qDIC2T6K2FRr4+L tJKJNIVSoR0vc2kg7dLKv+RS1vqOGuARBUmDFD2hNNdoyTNbC6lzKTXiFfl9WKYsHKJGvLGU SyMsYQpQqgzhwMBJPDQIFnKXQnq8WDpYLwVKWb2UDFBodaRRmmu05hgt0ww4k6bK7WSNYZKa hmKaoNCOk+NEWTVaohyFiJUjQVOJcqxMM0Gpm6Q24PE5Bku+yVZkdYC7JAqXV+Txp0OYp1Gj PLgXAgFKqaKIk2mWNE0BEmweWFvJWIt3RBGEtxP0RqRoyroQ1zGg1lPiCP2qi9aoQjgPi4g9 wUqnjyqlbFeTSE3WfCNiYUVdewk1G2ZthqmxMVVlQVPqwUidGBMUqpESSpU0ZG5MaK/LUFrF BisSMZdWuoIVrkB5yqXcjQ+7lGgquJREyiulxRRvkc2Tb3HlGh1TQVOddYqWRQMC2fKM2Eue Epy+8EIfSwmeYnHnm5wgE2iarTKwNqU4uaemvM+U4HRK9ARoSlVTQadC7XRoWKtd1nCXB4+k sC6maZSWiJ8ukzxTLgU4uTxZMjgqYmEufXaIS1P1UhYwFTNx17Pl1E8VlgPqqBKogkvN5FLu dtpFqdrygyXTgJhz1EdjSuH9rUoPoO3wifAYu7fS5q2weSqsnjKAzeIuMbuLWUj1BHtP4WDA USZSClDqzDc5mD9taX9yl+LX3JRLp+qtU9IuletGSTQgKLm0SkDpcDBVrBopUY+SasYqtONV +mwNc6nOPFWPpVnwSvGukXUFl9q4S6do8D6SS8cylzKUarGQ0TLuUlpIuhEvVUqBUhuhFPuH Go1T1dRZyMbQxpdJuuUFvkw4TYUiqgaUYi6VCS59rlxwKfJsyqWjJGAeaKrD+TfXKQsEiLCS qdKErcXJ8SSc8iIK6jE4QWYeJzWNlZhGU7GUOpSyMinVSJ8v1zxHUQ+mQoU8T1EiwyoF2I8U 48BQj8Gr5iVT6p1LTXkJpRozpuHSbKURZMW9eAzbpFSzZ7GaRv/ComgAMEQ5ApCoUI2q1OA0 PVtmmkK9TB2FBk8pdTENi+ncmjXl9ScVviSmq5zRCluo1OyHLqapbdk475cY6LxfrB1TRZVY ah4MnXKa0shM2DCYGeCn8MbG2MO8okt2FeiCPQ+XOsml1kCFIyx2x2W+pDJYn0YpcTTWoo+1 UuIAXps+JgR34WEKf500w6UFBm8eFUud0+BntW0qDXKDwwkuddE3BrRjD4pcYbEHeqxWBmsJ pdEmQ6zZmGg1V7eZYMhosybUoPDXStwJgLDI6MthLp1ExVKg1DRBxtqCKnDAMJey8X4KgF4r XIovwLgsQC7VRBp18RZDdZuxuh2brYu1auDSYEPapVOYS8dIjBDp8+UqXicHTUdXYU9i/2C/ OVnzYH+ZLSRyRvEaRQyl5TbBpan+n44JMutYsZF6KVdQz09KuQo0BXGxqGyldYoacnPl6j35 Rn+BKVBoChaaQ4XmcKE5krqliQJTKN8YzDMEcnTeKSrnRLltnIS4y4ulQOkTBVU8v8RtIb7B JGy0ajkO1JFV6jES7TgcA9QLmt5fXjVlf54gnebhXeAxUpGzwMT/UgCXwt5evDW8ZMrHXaek JphFcctn4sHYJ0Ap9V7OJ5Q68BaDwaxbqZmh1ACRjoFIxbrRIg2Fd9jmOhXrWP9w43i5aYLC nI0ngqaQLaNprhn/6XgLrT4EOi22B4iptgBSZPUXWwMlbNxgaoFMrY6JphU20qnIEYROxc5I WqdyL9GUCqeBanUQNKW+prpoPXNpo6m62VLbApraG9sdjR2uZnLpfeZSSHL9zr0bdu1LZ+Pu fRvT05T9G3fvp1sKTrn3P5DNew4gW/Ye3Lrv4NXb93zR+Bvvvd+3/1Df/sP9Bw5vP3hk+8Gj A4eOpVmIiQeSnr+XO/bYKUzw3H7plRVa8dtnTlztakSudTXe6Gq81d34QnfdC93197vrX5pe /8qM+tdm1r8xs/7tmfXvzmxA3ueZ1dBTXZNefvoHc3qSNR/MbvxwduP7LO/Nbnx7duNbsxtf m9X46syGl2c0vDi94fb0+hem19/qbLze2Xi1s/FKV+Mr+3bqpk0kl6bqpTNW/Z926bb9+7cf PLTryNG9x09ApIfPnD1y9tyxcxc4RIFPyPP0lStnBH9ePctzDRC9fu769fPXb1y4cevirRcu vXDnyp171+69eOPFV269/PoLr751+9W377z+zt033ruHvPk+5a0P7j+Ue2/hrvfuvvEunnLz 5dev33/1yt2XLr1w78LN22ev3Th99frpq9dOXbnKcuXkZcqJy5dPXGK5eAk5fvEi5cKQcMSm c/wiz8UTly4eR4RfKUcvgLjMqGfPHjxz5uDp0wdOU0l230mS6t4TJ/fAqMepJTPvLkuNh1lN Ffut78BBhHeF3caylTrlUt9X3GLfbjtwAI7tO4gc7EdYs2HK4YPbU8E07mXl2QOgJjUn3rcP 8twIpu7l2U3DF0Ow+/dtObB/28ED27AoapN8ZPthVtpl27BlDz4tezYM7KIhkXm/4n4WmsYc PqLyLoSGRGajIqcHQ6bsohbLbHAp6me7pn87EAvWLt2wZdFa6HTdnJVrpi/raV+0tHHu/JoZ s0FTX3OLva7eWF2tjcWUoZAUFnK7KpyOUl4ytWWWTLlLiaa4LbJYSqy2UrujksY9Yi6thksb HE3NnrZ2wC9CTXnn1c1f1LR4WdvyVd2r1s3mJdMtA0u27lq2bffyvr0r+vYu79uXDjjKsnfJ 1t0LN+2Yu27brNUbO5f3Ni1YVj1zXqh9uqepzQEoJusN8Roqk0KkYWpoCgqyCEMQUck0kdCl XEqNeFta3G1t3o4Of1dXaPp0sBlb6O/o8rZ1uFvaHU2t1oZmUy3VRY21jabaZnMdsEqx1rfY GlpBU2OyQZuoUUUTinAsRdOwNBSRQ6FRoDSujsexXko0rorGIVh6ZKrVLg2hxBSkjdfoqM8q bpN4pALLCYTEfjgzUAWL8nCOYk6AZ5CmrClvQIKZsKvHW+4iEBIF4cCUSzlKyaVplMJ43KUm C+tc6qDOpT5qxCsJBWWRkAIo5WEu5XsSIkVYsTQodC6lwbGEYmmZwwkSZ/QvFVDKi6X5FhsA nGtKoVRvnqIzTdYaJ2kM2WrDRJV+vJK5VKYeLVWNkuDkWzVSDKCqxsg145W6bI0Bj59msEBi ZAy4Avp1eSvceNW8vEwpd3lLncAYuRR4g0vJb0acbdtSTV4d2CQCiVNgLWvAiUMlro5UqyNE U020ht6XWO2QRJEadbhaEYhJvWGRy1/h8GI5gC4ryVrzmUvzmEsxp4SKulgFuVRYBXMp0ZS7 lNOUepMm6GouNNZuTOqLSnwRMcJ0ymgaIpoKXRZZFU5oxOuASFkyUMrKpCXUjhf7AfGVOv0l Dh+jqTvX5Mwx4qRBSJ7JXYRTFkeg0o0VRUQe3IYr3SEwuNTuK7KCpo4cvXUymKTQj5FqRlYp h1XInyuVPl0MmlYxnRJQyajEVCbV/IonKDTzL0T0RKHoySIS6VOlkqcBXQGl8udFQyKINOVS Qmml7Bm4tFwKyj5VKqYlpDNYdJUPEyl498tBlxr5MSPUk3mowTPFU+aggaNEbn8VG9kYt3jL aNQol7/S6avEvXZvuc1TDo5a3GUWV6nZVWyCAdhgUUYHa/yMuCgmFnNmGErNhNIHXQpJwnhG waXTmEsn6yzZGtN4pWGMXDeSXKoeLoZLhRBTJeqRUvVoGVyqm6AykEt1D7iUSqY8hFIaSwlv IlxqGq/AYvWwKEPpD7mUPikPurTM5illLi3iLuVfIxrjVI2RlUxpVF5kmpbpTm3KZoM2Dbq0 /CGXiqkpL6dpSqc6quIymlIvU1YyBU3pVkHjrACl4wmlxjFi42iGUupQCpSWgyIk0mfLENWz 5ZTnhCifq+BRYL044x/GWkFD9aOherl2PF4471jLUDpFY4JLqViqIpfiXu5SIBbH0miJZhTv 7ovllCt4uE5HVqpxjs56mVpyNPYCvbuEdTGtonPrmNSTkPuqoVNeLC23BouN3jwthGbFU1gZ Cuf6mlEiNUL9YIVOsKwHLGtmDJryii5PuqUxS8qlWhtoUWT2ltkC1LbWE5f7a1Shek0EKG3S RZsFlMZbDfE2QwJpp8QpmA+7Kqkpb02VK15hh0sDzKUu5lKyCh+JKlePoz3lUgdcGpF4Y/JA tQpUiDbo40BpC1BqSbabq9t5yVQZAHerKwZdap2ksMClQGmmS2kcWojL4C40e0tsgQq8BC++ EmtU4XrWubTFmGw3JjsMjKbaWKsy1CT21pTZo8DhVK1rotI2RmocLtI+TxVy5lLqrkkuhbLI pdQ8OFBmo9GP8Bp5I94KGuSJGtzmc0CqXQDkWAIkFTapl3KFelg53nE1FjVOapyosEym0jEI 584z+EDTfFMg3xSEQgtg0XRM4fxMl6ozXap6llwqfiIfIhUhj+MW36VF+BKT4DPyfKVC+Jsa 9YKGS43sGMABAJriLSCa5lJzbuiUAdXAdMpoWmRO6RTmtNIEBW8WG26d07TU4hFcSojFPqER 2gvwxWVwwKVTqQWvhaHUOB4Hp8QA24+iptFa3jQAt4hAU/Iqa42PByvM45XmiSrLZMhW75hm cOaaiKZ5lpRObf5CGxlViMVXxMIqvWz0YAt0GuA6JZo6Q1yniNTFqqa+OKL0p2gaqdPHcMg1 GKubzDUtltpWK5VM253NVDK9/8ZbY6bmXLl9d1XfDpaB1X0D/PbhrOnftaZ/Jwumd/Zu34Ws 5dlBWbdj97qBPRduvuAKRl59+92Nu/YyxJJjt+w5sHXvQWjwf7AfTAxAqqn8pfk8N+69uExZ /tbJo5dakhdbkpdbkldbktdbkzda4zdb43da4/fbEi+1JV7pSLzWkXizI/FWR+Ltjup30+ms XhGvTq8CP5jGnPe6ksj7Xcl3Wd7uSr7ZlXyjK/lKZ/LljuoX26vvtSVutSVutCWuNyevNCcv NdPaX9rdr5k8jrl0zRCXPspc+rvvv+/9/9mlwNXOw4f3HDu+/+TJQ6fPHD23b7YoKytLNOcg iRQEPXetL/lIVnU//Hnjws2bF3lu3brEcvmF21fv3L129971ey/efOmV26++eff1d1586/2X 3/3olfc+efX9z1778PMrfXosMf2j6HvljY+/evPjr3D7xkdfvv7RF8hrH3z28rsfv/jWBwDq bQD1pdev3Xv58u17bOSrFy7cvHXu+k0w+Cxy7fqZa9fOXBVy+upV5NRlymmWU5evgNMneUWX Qr9SoOurV04P5jJy6goeeYmwelEQ7FFeWT179hACplI19Qwx9dSpTXPKsf2+NdROeBcZlbX+ 7QlhZuH0rcKgUBmjQ+04dGjg8KGBI4ephfDRI2tnlmWVzVx77OjOH0ovu3cNpyYNU3wQ+IRU mUIJon2k2UP9Rw5tP3pkgJ5ybBc247hQ0d1x6AgBdf9BwHjz7r0zvWxf8x/v4k27heGRt7Cx kbfupybKqVVwD29uKM7K79xElds9FFZ9XVtdICwjK8tWu2bdrJ7VXUuXty5Y3DBnXvWMGaH2 Tndjk7W21pjAqTOVTMVeb6XLSaMfPehSCmiKFJnNxVZrqd1e7nCy65fCpVF9ddJcW2dvbHS1 tPraO4Jd3bGZs5Nz5tcvWNy8ZEXHijUzVm+Yu27rgo39izbtWLx551LodOvupUL2sOyGSJFF m3fOX0/F0hkr13csXd0wb0lixtxgW7ebX7y0Gl9SSQGlId7QNKyAoFiIptGYJp7QVbN2vKxz qbO11dPe7uvsDHZ3h2fMiMyYCZpiCwOQOfZAiqaWeoQsam1oBUd57A34Emw2UVPeGjV3aTjt 0jCmlYJLE1ipho0JrIlV45GqSEJFo30mQCChNAeUCle14S7F0qLSYEjiD4opTKeMo1QdZSGX CkyFS/1DXOr1lrvdpU6cdlNnznQ3znSxdIhLqVjKXWorBind7kofFUulYdaINxZRxQWXKtn1 UUmkDKXygNCIV5wqllY4YVE2GG86bHQZVpgiCvJiaa7ZmmOyTDNapnKX6k2TdcZJWmO21jBR Y5ig0o9T6sYqNIDoaJl6lBTn36pRMrVQF9IaJ+vN0/ByzLYCK7m02OEudeH1gqN+jlJyqVtw KZwGigh4Y/VSTKe6YrJCWcqlYl9IFgC5hfeFwgqn0OmQgKzs8qEQpsQbAlrK0y5ND+bEmihT RdfiAHuotbDQQJTG1MFbD4tq8NZTO94kjyZSQ/1Lw0llqFoRTMiDCVkgLgV9AzGJPwqgstqp wEVOU6qaWql1bgF0anFykRalRer0ljl9ZS5/mdtf7g6Ue4Jl7mCpK1Ds8BfavQU2byEFJwr0 Z+wyV6jSExH7scaExB+X+GNiX1TkDZe7AiV2byFVWe2sZGrEedJoMc72lM9XyJ8FTUskTxcj 4qcQnFSlw+Zg/l9LiZjXNp8BWgSRKoYBvRRMUDAnTdNnkXSxdNClQrAotjShJfDzdL0Z3v2S tdVUGWE25lK2l4juFN7UmVzqgEs95TSgsV/kCQClfChjNuKxv8LhowG0bekCKROpESJ18IGF qAOn3p5DceTg3M7gENhvAvtZzAhQyoulGS7Vw6VWWJS7NIe5dApz6USNaRx3qVQznFzKo0IY SjWjZPiMaMcp9RPUhklafIjwUWKNeA0PupSjdIqG2m9jV4wjl+pGyThKH3QpNukH66VlmIBL zQ5yqYE6BeTgwXTdKYNAU8ifUIoTaDBJGCtrVJVqWKXgUk5T5lLFcJFqJLlUi1AdksKACv7J tMylvCmvCefHExWmVHtCutLjWDFOlPXEhkGUqp/jIi1TPVOmfBYpHwxHKaUSNKWDajgbMopa QfOSqVKPY5vKpBylD7hUoR9LNKWNBGW5S4eTS+XPl1G4TkdUqKgpr9QwSWGepqb2tMUmXzmd XkfErqjEHZd5E9BpulhaaPDkaBx48DiJHqf4o0SakSL1iEr4RzUy1QmWsUQPlmCrYGaiacql wD/3MyuoCnDN0dkgRjikjMqY4GJCEeA9M9MobUmj1Jhoz0gHZmrpyisNMl+N2JUgl1oChYJL HRkuxRFFf4UpNLsFl7rDgkvD5FJD2qU1HaBpqikvc6ldcOlk5lL2hwbmUgUfOweHqI0uN2J0 QywltmCFKyL24cuwVsUa8eoTraaaDlNNJ6Nphz7ero60SP11Fc54oSWYo/dMUtnHykwjqnTD qEexBihlwwhhH+JtteXo4FIgLVBuj4hc8Soa8aha5KqudFaXO+Il1mihKZRn8E/VerKVjvEy y+gqw4jUYLnDKvCOq0eJdXQpFwU+R7YpGuc0nTsX+8fozzMG8kxB0JQgakYEmgouNQZy9D7i ruJhl4p+iQguFT1Bf6ejr8TnyqmtB76+cNThg8BG5xL+9MD+PEFD9eKNoNGqBZ0ymlLLXlch dGr2IFykQiMOeNUEfLqL8fVFOqXQhFAvpXGeC4xOLAcLnKKxTlJTC95xMsNYqX6UGJ9iQilk PrxCheOcd9UmnVKHbXyEdWwYYQPRFJpVWbI1+AazTzU4QdMckyvX7M61CDodjNlbYPYg1A6Z mpn4qLssdY6l0ZtIp6xwSjRlkbgi1KbXwwqnvoQyUK0O4T9NHHJ1cKmBOto0m2tbLPVttgaB pnDp6Kk5W/YeMMZqTPEac7zWHK+x0C3F7qNK41+Jw1frqG5wJBsdNRRnTaO7tqm3f6BILAdJ fA0t/sbWQGNboKk91NwRaenCU37HfjBR2zW7vnsOUtc9+4H5td0ZmT57294DM4b/7PaG1X3F E7cXT9xRMnFXycQ9xRP2FY8/WDr+SOm4E6VjzpSNOVc+9lLF2GsVY29UjH2BMk5I5bgFBl16 FfjB9AKD/rZoPHKH5QXR+Bui8ddE46+Ixl+oHH+6YtzJ8nHHyiYcKpuwv2TC7pKJA2y9WPul Od2lv/gbcmkPd+naGasfcinrsojbQZc+3nq2YMn10TMvcXw+2X6uaOmN4dMvPN91oWz5TaRo yY1nOs9zl8JOrFh6/CArlh47z12alZXcBpSev379wo3+mkeykjvSEH3h8m3k9hXKHaD0+r37 N++/dOvlV++8+sb9N999+Z2PgMw3P/ryrU++fuezb9/94rtbO01Zun03v/zNe8grB9RY+Jzr 73/5W/oV+eLX737+3Tuf/QpSff2DL6DZF9/68O7r79565Y0b91+5evfFK3fuXb4Nnd6GTs/f uImcu3Hj3PUbZFTk6nUOVEywaSrqcqwK01eE6bPXrp29hturZ6+zievItvgjWbGtV0inl7hO Lx6HTs9Dp0LbYAGoZ88eOH1687wK2jPlczaeSNVRjx1fFKZ5RTP7drLuqSwMokeOYA63K7Lr +LH1syHP2euPH999QsiekycQPr2O3Qu1DrCerqRTIYd4tsO3EOnxozuPH9uVfjprcszGiDo6 kKLptn37Z/mysvzLSKEbu/KzAM7N28iih/pouOPD26kbLW3hdloRrWv74W3NpVkF3Vup9IpH 7j8AxG5Y6MtyLVzTN7Byy6pIXlaWZfrc1b0zV6zsWLy0ad6CmlmzIoBZK2vNW53URqPKYFDi 84ncbu5S1ssUBGWxCIFOiy2WUhuhFEoRe32gixouTVSbamqt9Q2OxiZ3S6u/vSPcPSM+c07N 3AWNC5e2Ll3ZtXLtrN7N89Zvm7+hf+HG7Ys3DUCnD2TR5gFkwcbtc9dunbl6Y/eKtW2Le+rn Lop3zwm0dqUGParVRaFoQqkiGJEHwjLYCYJCQKmHXdrc5Gpr9XS0+7s6Q9OnR2bOjM6cGZkx I9w9PQSasqqpq5n6mtqwfAZReyO+8ljYrzbmUmASklRGYsAkuTQ0xKVplNJlVONQKKjD2COg FDOB0lqOUgNzqSYaV2JR8G0gKElFLITwKdCUUOpD2NViGE0fcKk906UIdymjKevVOdiI12Rl gx45yz2sEW8ILg3JWSNecimhFDsQIg1BpCmUUrGUrhBDLk2PxEsXL2UhlGa4FB5I10txCp6m qWWKwYxMhk71pkk640StYYJaP06lG6vUjVFoRyMAqkI7TqWfoDFOwsm3Ac+15UGbWCZc4fSQ S4FSL1zKA5f6Sl2eEocbAgHYqK7IdMpQyroXUqHMVeogNFKVLOVSoYgtdPetTiXJoxZSrQwx l/rCoEsFDXjrKYF2BocaJqDyS2XiLlAHzpH6w3KhnTB1YdWx69/yVsEs1EhYF6vTRmvVUZyH 1SgjSUW4Wo4VheJkVH9M4ouKvRGRJ1Tp5mO9+kodXhrQyIaXCY7i9XpKqDrqLXNhDxBHKzzB Sm+oEtvpi1T6IhWgpidc5g6VuijgaJk7XOGJiHwxSQArwhqT8lC1LJiAh4HhClDWIZRMgSic r1MvU2BDoCm8IX+OdR1MB78KKac8j3N3NjE4Px3MrABRUhwVK7m4WKAv/EpAfb5KkUIpufQZ Hu5SoikilFuFiitD6TA2XG3KpdT9corOQi6F3u1pvVOE0aH4IMYpl4q8dIkdTFcIV+Ihl1LB cBCljgIau5iNJ0Q9KgE/21Qdj32aHrxkQDUCqI5c4qgQXhQVXMq6mFLIpXY8LAf72WCHSyeR S83jVMbRcv1IqXa4RMPCdo5Uw1CKz4UWn5HxKsNE+lyYgFJ8mqYxlAouZTTNoQvSsAF+NWZ6 B5VwqX60THApFoXApWMV+gkq8u1U7KiM/qUlVhe5lKUUc+BS7Ea4lAb3JpROgUvVhmmMpnQZ KjWYBCwZJsJy2E5yqXzQpXTLXFpFLh3FXDpacCnLEJdSC0aEXCoHYKh6M05iGCMG5HQj6TIb NL4RQymJFBx9ppQFE5k0rVAg3KWcplQyhUslrODMS6Z47WojiVRtxNFCKFUZJsClSnLpOIUO NMWGkUvxFpBLFTi2qTegEMXwCuXoKg2QmS03TVVh/1B72jJroNIRppKpOyb1xKFTMJWKpSYf 4DpVbcPrGiPGayGRDq9UDatQQrysE6x6dGpwJlbOhZnN1H8YKNVRpmqF0m6arDgIc/X2AhPn Yoj6fPpY29pIow6oI5G2GIBS1kXTiFS3IyZKB4KZ2mizKtQgZ21uKx3RUmuw0OjN17tzdU7W thMYS9dLmUttKZf6Ml3aNFgvfdilJrjUMehSvK1y5lLWkXgqoAViASrwiT1Y6Y6SS0P4SmzQ xpsN1W2m2k5zXZeptstU02VMdmpjbfJgg8idLLFF8oy+yRrneIVllFg/XASUakdWUUCmCQqI DpyG2Xwl1mC5I1rlTog9SaQKcddUupJl9nixNVJgCuUyQ05Q2MbAkDSEkg6L4qVXLHmszDgB hFbbJmudU3XuHIM31+jPNcGlRNM8QulQl2LmX3epUC+tHOLSCvlwkSLTpfS3CfbXBxYL3gjS aYqmOamqKVxKocKpkAITk2oqpFMiKyIYtRi/8gtWG5wgLi+WTlCYxsuNY2UGmHNklQYvHwcn Dw5ROkqZTgmoVRpkFO8rLjeMU4CmpglqoukkfCWCpkYK6dTiyTUj1O80z+TOpUtku1k8rKMs tgGEBqRBZejUx8cTrrAF0joVO8M0VK8nKgNN/QkFDrlgjTZCNNXFG4zJJlMN0dRKLm1zNHeQ S6dM27BzjyYYUwej7DaGWy0L/CY0e/0LP3iAMVxtiiYRcyxpodT0bOnLrxSfuHDZkWxw1jS4 GVa9dc1gKh7/K/aDiQeSnh9v60YSbdPjLLG26Zt37+t+9kcvrO3ZnDt6W+7ovrzRO/JG78wd tTt35P78kYfyRxzLH3aqYNjpwmEXCodfKRp+rWj4jaLhNykjkPlaTXr56R/MWaDT3CoZibxQ MvJmychrJSOvlIy8VDLyXPGIU0UjjheOOFIw6kDBqD15owZyR2/Po/Vi7Rdmthf/7L8KLl35 H7l0zY7tq5lLJ8y9/MY3//3Cu7+dMOcyjDrjxHvf/emfI7tec2176Tf/458//t3ff/b7fzjw yrcjZ1xkLj2868ixvcdPHDp1+sjZc8fPH5hTlVWRrIHAEn3XLly/cfHmdu5SEukLL1zht8yl V+/cuXb33o37L9566ZUXXnnt3utvvfT2+6+9/ymECWe+98VvPvjqdx9+8/29PZYs/eG73/7x 418hf/fxm0e0Wea+N/4Ov3707R8/+ub7D7/5Ax757ue/fvvTb9/48KtX3//spbc/pJa9r7xx 88VXr9176cqd+5deuHOBFU7PM50STW/cOHvtOtMmQhOk04xSKgsTKZvgjzwHlF5nt9eunrnG XLqN11fh0kvUxJe6sFLnVeQw65LKaXrwzBnBpVkVXTtPCS7dMbuIzSqa2S+MEnwYHMUEu+Ui Rai2OcSlex6k6Qm6t3z2uuPHdx47Bn/uOIKAiwihlK7Kc/QwK5Myl9JCCKXMpcd3HzvGV413 k9N0rh8uXQ5eInMCWVmBFeAoLLoDD6MNO7bzGFZE62Krw8z+ltKswhl922kJFOh08579+Liu 3b5zdd+OOQ0FWXn1HWvWzVq5unPJsuYFC+tmz411Tw+0tblYydSQSKgjERkU5HFXOp2ldhsf /YinZDDWUput3OGodLmq3B6gBYAhl8YTpmSNpbbOVt/gbGzytLSCfJHumYlZ8+rmLW5evKJj OZVMZ6/dMnfdtvnr+0DThRt3IIs2IQMLN9E0ZgKlsOvsNZtmrFzfuWxNy8IVtbMXRrtm+Vs6 hc6lCXxJxTNRKoWdICiu01BYGY2q43FtdbWhpsbcUM9d6hVc2g2UxmbNjM6YEZk+PdzVHYTM 2zo87IqmjsZ0wFSETQOr9U1mGra3RkNVUHKpPBSRhcIIpuFSNXMpRynJEwSNCTSlclnapXG6 i9NUF4dXmUux/QFsPyWtUxZGU78fgUIRTGCOlLlUGI/XjfNsakBLVUrqz0k0FcKBSjEjeQyl +WYrG/TIBZcKjXhTLuXFUgVcGmLCDwQp/qDMF5B4hUa8osErxDCU4lYomaab8lKKWBfTfIs9 z2LPpcKpLcdsnWaiTEWMlilGyyS9OVtnmqg1jtcYxqsN4OhYFZiaiVI8HSglXXCUlrl9Fd5A KgJQy4SSKdGUYhWSbrpJ9bHUNT95I9vUNULilHBqMCoKTrnSRqVp3CUPxqT+iNiL0zLohdHU joWD37TP8TIxAe1QC15vUDKIUnq79Ql8pvh1aBpoOKVkoxn/pyabjNWNhuoGfaJBF6/Xxus0 sVpVdBCosiBVUCWsdgqdAo3lrkCZy8+a6cLhVB0ljnrA0UAlNswbEvnCVdjIQFQcjImDcaQq EBP5KVX+OEsCIpWRSGtU0TpEGalhNI2L/dFKT6jM6S+2efLNTjgKp8VUbZPr4YdRYg07O6fT 6MGIaFwZIYAHhYpL1O6RZuKEO/PBrKskFQCJW7wAOErOIgOWmE4l8KriuSoFXCqINO3SFE2Z SKmIKhRdGUrZyEAq6n7J1CG41GRnLnUXOdzFZHgKDhIe7tIK7lLswJRL6Vo7Di9dlcfqKcHJ nNnF2u5SpZQ1kSXyTdHQmeIUrXUy9dq1TYFOOU1/0KW8Ha8RLmU0ZY14B11qhEttk3RWwaUK /UiZdrhUA47y4NdRcu1ohW6MUsc/F9la0+Q0SqnbNnXeFlzKrjqTdmk2udQAggKiWA5HKdvz KZdqTLSjwE5yKeuGTS51MZfyqwHbyaV6S57OlKMxTlXpp6j0VDJlNKULUJFLcRqtn8BcSq2+ 4VK8NSmaPkt/jOAuVY+iq9QMcSkNLzTEpVQynagwTpQbmUtZVzdqVagbya4EM6xc/XyZ6jko lESqEFLGUq54loe5lGjKXEo0xREipqa8OEKo5qygkikgSiJNoZRcqoJLBZqSS7HbcYgylw7D QirI26ApD07WR4k0YyU6bOoUlTVX6yg0esil9pDIyUqm5NIYmIqZICvgiofhRY2u0qZR+nwF FsvHW04NzkTlXNowNt6ymf5qwP62mKYpdYslrFrZJXAdRRZPqc1f6eR9PmkgIi1rAWtASKSt TKQ8HKXMpckOY6Jd6GLKDClyxspsIfi5wOChq4YwsQBCVKAzZLo0MNSl9fp4kyHRbKputSTb oFNDrFkbbmDteBNDXMquPiK4lA9wRX3d7TkG5lKrr8QRrIBL/dyljbpEi7Gm3VzXba2fbqmb bkZqp+urO5XhZrGvtswRKzAHp+ncE5W20RIDiVSsG8UyVmrA8qdosNnuQrOv1BaqcEarPNUS bw0LXXe0ylNb6armNM03YjmebJVjnMwyWmKERUdWgab4utOOlujHYYPTLtWnXcppSi5N05Ru CaXcpd7JamFYJhy6w8ilMnIpQ2napdRDnjUh4S4VrgKVGjWaF8ZZzJPTOk1XTfWOXCqZcpry y1CnuhUYnHnC/DRNhYCmuAVKaRh2NuIRlpmtNA+iVKwdLlIPq1RTJ+1y5fPlCnYLmvKBxMB1 NR4zSoLoxsjwMSGXjleZJmos2VrbZD2+zexTDfha4zoloFKMlFwegyvPgI1kvWSN2DzSaTE1 ME7r1A+dCs16oVNXROaNynxxuFQZxBFeg6MOLtUlGtjYH82W+lYbKx7cYy5dv3O3OkAoZYkj WtwG4sDbn/7qDx5gjFBMsVrEEq+1xutWbunPg0svwqW8gtrsqWv21rUEgGFX8su/+oMHJNpn 8FSnJrbApc/97e11K7fmje3LG9ufP3agYOyu/DG780fvLxh9uGDkscIRp4tGnCkecaF4xJVi EuYNFmhzvk6budIHphfotLfKRiM3y0ZfKxt9tWz0pbLR50pHnSwZdbxo1JHC0QcKx+wpGLMz f+z2fFo1cnFWe/Gj/23Qpat6B136s0GXUqWUF0tXb+8DNbPnXfny+3/89//1/+x/+ZuWw2// 8R///L/+1/9Ts++NwI5X/vs//Vts9+sLzn7wP//l30yb7uPBA4cO7z56bN+Jk4dOnSGXXtg/ R5RVsfjwnqXiLPGyAzdvXrq1o/aRrJoBViAdaHyEMQw/tbvuXt/V9EhW8/aXXr79yuVViqys jmOvvvfxm3d3qrPmn/zqdx9984dPvvu7z37zP146YM0yHnvxt//z89/+/ReUzwZMWdr9n37+ 2//50n6rsLisLM3u997/8rfvfv7dW6fnpdai6rl4bYU8S7z6/NW79y/fPrNYmiVacfLirZML JVmVdfWV/FF1289f70+w51QuPXru+o1z14/OF7O78FO1dM+16+eOLKvMEifqhLmVy/CwPv4U +qlavOsKtfVN6fQSVU154VQYYImGIN42vzKrYn53PCsrtm7/qdP7Tp3aOKc8KzK7oyyraNYO 4HAxq53yH++qY8KcSMSH38tnL2by3Hjy5N61Ucwonrtz76mdnZy6+LW8PKt8zgZg9bhQg+U/ 7lVHB46udGdleVYRSqmsmhVZjIXgueVZ/rWnlkRoFal2u+EFTKfzyKI9mIBFF4Qwe9XOY9vb 8FThp7xz16m9p07t2TmnODWniL0KNtQTlHts+6EjffsPbdl7AJ9Y0LTNkZVlm7Vg7frZK9d0 L1vesmBR3ew5sa7pobYOd2OTvbbOlICgqJcpjX7kgj1sVDLNECl+ZbGV2+2Aa5XbLfH6ZP6A MhTWMJcaq5PmZK21ts5e3+BqbPa1doQ6p8emz6mZs7BxwbK2pau6V66fuWbT7F5O0/4FG7Zn Zv6Gfnh1/vptc9dumblqQ/eKtR1LVzUvWFYza36kc6avud1B17apN8STmgi2MyKn65cQSiUs RLtgiKxIAxGxoY/gUupf2uhsbfG0t/m7OphLZ8Rmzki7NNTZ5W/v9LS2u5panVAodEppo6Rc amcuNcDDMXIpG9koAgCny7ODLo1Xs0uqMpeCo7wZZ7SauZTTlC64StdcjSXU/FUIrv6BEE2Z S8VAqc+HaSm5FC8z5VKPh3UxpQa0rH3p0FCLVmpuikCtBRYbHlMET4KXdIUYGkJJFhl0KaEU TA0GZQEWfwCRcpd6vFVuj8jtrky5lIW6mAqjHzkRCBDn/VTApLa1NmcBS77VkceSa7XnWuw5 iNkGoA7qlIBqwpk3bifpLVONoKwj34olkCuAMWqkSgYLiHzBzGAOaApmABvUxzIjxA/GUSZS GieJhrrho7DSBUKw51M0FYCaSIXpNEyFbghTQWXMKJ4lBv9AQVqXp5SV4BhQSb/l1EIY7xR2 HfVc1URxGNQaquuM4GhNo6W2Sbj2TF2Lta4VsdS2mGubTTVNhmSjvrpBV12vTdRp4jgtq1FF ktgAptPBlr2QZ6UnCIUyi+JVByt9sCjnqCBSCfyMTQ1XyyJIUhZOSsN0KwvXyEHQSK0iUquM 1qlj9Zp4gyZWr4rWKnBvMIG1QL/kUrungDfl1bGSqdJANKVxYkmng+HGEJplUptM6IKH5tBd mtHCg3Eqw8I4OhLn+qz6N4ZZC7eYJprKiKbDxMrnh7r0aYS7NBVCKQ2JJH+O2v1S9ZWpQ8U6 EOrgiolwKc7m4VKbq8jhQYoZSjNc6i1LtQanw8lLLoVRuUvpArAZLi004STPQc13aTAhah87 OR1OU7jUYJ9mhEtTTXmpHS9vystcSk120zQVUJprdiJ41hSDbZLeOlFrGac2jVEaRsp1I2Ra hCSJPSPXMZTSH2vGqw3so8FQykSaY6LO27kmG+hLYaMf/bBLUyjNdGn2UJcWPexSzDdaH3Bp iqZGVizFCbQ+m4axxWGAdznlUv420QRVyH/YpQJKqW1thkuNzKWGCTLDeKl+LCuWslaF1MDy +XKOUgUCkT5dIn+6VP4MkqKpoFNO0wyX4rjC0SX00eU0VRFN08HeIJcymo5T6sdin2PPU5GZ hqEaJlLihYDZRFNWOB1WoRgpUsOloOZkpSWHXOoutfgr4FJHuIqa8sbE7hh+xUyQNVfnnKyy jJcZRlE9Cmf5rAECdg7rGk09YMX8AE6Nt8xcCo7SYMsGKJQXTlNz2DWBCkyuYqu3DFZ0hSXU MzOpDtfrYoAiodSICCKlkEiT6cClbXRd0HCjMlgn8yXF1MU0TE15TV5ogdOU+ycPhjG5Ci0e cqmT+qWL4YRAQhmq0UAIsUbQlJVMW02JVn2sSUMurR10qRYvnFyaDZcqTAi5VI3jk9oagCv5 5pRLPXBptTyMb6dGXXWrsbbT2jDd1jjT1jDTitTPNNV0a2Kt0kB9hStRZA1DiZPU9rEyYJKh VEKBrzJdWpJ2qa9G6quV+uqk/nqJr07krqlwJkptsUIzlUzByPFy6xipCcrFooBS6Gu0FF99 JtZOlVw6Re+eZvDmGH05Jn+OKZBrCqZDRsWEMZBr8OcYfFN1nkkqxwS5ZYzEOFKk5S6lYXgf cil1RiiXsm4Iqe7xVDLVTZDrQFP+ceA9iidBpyrLFDVv0ztIUxCUQRRfUEJyDQ66C9NMp+na aSFEaqaCaj6+oNhjoFwag1dJLXiFSqlIw4YNo1BX7TLFs2WK56BT+hsKPto4btUjqoB2zUh8 kGX6MXJ8UkBT4wS1GTSdRDS1TTHYEU7TqQaEMdXgnKYXQvVe0im2nOnUwHXqKR6snfr4ZVdF RNOw2BWWZtBUHanVROv0iQZDNdHUXNdsbWi1N8Glb8KlG3ft04Wr9eFq3BoiSUM0iVt9mMqY 3/3VHzzAGq+3Jii2RIO9GhBtWtU3UFAlO3npKkTqrW/1NbT5G9uDTR1h1o7307/6gwfUdM5J p7ZrTk3XnK17D3YN/9ntTb19ZZP6KibtQMqzd1dk76vMPliZfbgy+3hl9unK7LOV2eersi9X Tbwmzr4hmciTuUZMLzAZHphzSzYJuSmbfE02+Yp0yiXplHNVk09XTT4hmnxUNPmAaNI+0aQ9 bI3by7O3VWRfXtBd/IsfMZeu7gIHVj7sUrr0CEMpK5au7h906atf/elXf/rn//HP/3bn0+// /l/+nbv0n/78f1/94PdvfPPfP/rt3xcuuS649Nix/SdOHqTOpXDpgblVWRVLjpxn3UpFK45f uT0Al9YO3Ll6eqU4S7rk9N1rd+9e2w2RNvXd213/iGzF+VfuXNogI9t0HXz/0+s7DFlzrn/8 7feffvcnyPPL3//Dq4fsWaZTr37/z18L+WqXOUt38MuvbvU8kmUbePcfv/jdP3z+znFdVtaM y3/84OKiR7IMG+9+/RpVTT+6/8atlYosSe/l6/dfvnbv7FJZlqjn9KVbpxZJsDrJgmO3zvc3 cF0m+m+y6bqNN25sqMO//QyoxxaICavnjy0nxIqX7b1xY99yPLluw43r524QTeN9rLnvVWrN y2h6GTSlXLzEe5ymddq3oDKrcsHW9YBpfPnpMwdOraOqZC/5sHj2AJUu6RKvVMBcDCuCoCdO 0ATrkrr3xAlCbPmcjb1AKVh4ct+pk0sxWTF3E3VeXYtF0b0nT1LhNCu88Bj1Xx1YBaGWtfYf WRAGGvt3Hd/eTl1cs3y9J/ftAimjS0+dWkLIBYOP7zq6ypNFNU+8p/ODWVmhlaw0ugpkxb1U XyXNYl27CMOg9Wna/uJ5uwDsfZzKs3fuPnFy97ETu46d2Hn0eP/BI1v3Hdi4e9/6BViGq3nT 1oXrNsxZtaZr2fLWhYvq58xNdFMXU09TMxuYF1iKsV6mfpHLVeF0lDOapgOpIkBphcOBB8Aq Up9fHgiqmEt1sbghUW1K0dRR3+hpbgu0d0W6ZlXPml8/f0nL4pWdK9ZOX7Vx5prNs9dunbuu b956QLSfOMpEOg9Zt23uuq2zWc/SruVr2havbJy/NDlzXoRdJMZR12ROUudSdTjGi6VSP3XO lPihAqoxZrg0pkkk9Mmkqa7O2tjgaGn2tLX6OtqDXZ3gaHTGdNxGurvTLvW2trub25ygaRNu 04FUWxC41FJTT3Vahkl+9RTuUmGkJT4IcCwhuJSuYZMeLjhBE5ymbD6PNhpXYzmgNVDqBwJT GkyF0ZRcSn07M1wqgxuDeMlURK1kLqUheVnJtIidYhZb2VUfbHRbbGXz07E5ShxOPKXS6xPD peEQDXrEXcqKpfJQiNbORMpRyhvxkks9zKW8ZOp0IpiowKJcnko3jXZb6eGDEvlx3o+zf2AA qix2UNmqkKXA4SqwI858mxNGTet0isEyGdFjwjqNyqTQLESKJVBtUKgK+kJVvpAYPgyExX5M hKoQ6BRI47RgqXTj/IkCKAKi3KKIxEeXrOQopeGR0/XSh1yaRilvystpiqdIAxExKAgJ0/Vm 4V7mHAf1XIV7xT68WdQ8WI23O1ZDZdJkg5mh1FrXbKtvsdW32hvaeDBtqWM0rW3G/6+CThNC 7VQdTSoj1YowteylwmkAJ20R4BMKzYAoSxAcpUhDMWk4DpHKo0lFrEYRq1VS6pTwZ7xeHW9A NPFGbYKiwy3mCCVTuDQ22MWUXWNmmh5nY9w21BaUgTMVgaB0hY9xcsN4hRAoCLqAMWg+HsD4 wfhKjsUpPhcpQUtBLbfHsvL4GCXm4C71CCmVTJ8XM5cSTeVPUx6kKWviy7uhUrtf5lJqEgzc MpcaJuKcXm/NMadciiMQKMWh6PKW0hBZVFp/yKXsyKELDpFLS+2eUqsbLi3KcCkb5DblUsCP oXRyulhqAkpdeXzcIwtCQx8RTc1C1RROTlVK7bk0n7nU5JhitONkbqLOMl5jHqMyjlToR8h1 0OlIhW4U0K7Uj6EWBNSaYKKWteDlKOUcNVM7eYqJt5Kg4b5YydQC1dCfFVQPuZTK1KxJsNqQ rcWOGlovtT1YL/1Bl7LWvPwSxFQsnZjpUhEVsWmAZe5SKmjTkMKsHS+NJPRDLh28uChzqSHD pTrqjVmpGcFGSX2+TPkcUFqieKZEjpBLOU3LWJhLKTAkwo8TOlSEg4T3XR+Dl6+gv1+ApiwZ KGUZh8MSu53/xWSoS58txy0FqoRLx9A4upA5XGrH6TXOqsttwXRTXrErCpeWkEvdgCseNk6m H1mlptGYWKUUy0R4wZ/3gB3iUiiUev8KxXC8rax2SlVxvNHQhVDDdAar3BEpztqDNepIPQ1E BNRRYNE2U/KBCDTFvXq4NNKoCtXL/TUST6LSGSmzBYuxtSZvvtEN8+RS508a06vA7C6CS+2D LpX644oQvhjrtLEGXbzRkKBepogumnKpt7rCESk2+wDyKWobaJpNJVOglC5UO0mDzw4+OI4H XRqolkfq1PEmPTa1rgsodTTPtjcJsdTN0CXaFaHGKk+yxB7JM/kmaxyg42iJPpWUS7VwKTab udQVFXurpf5aqb9OFqiXBxpk/gaxt7bSnSx3UMk0z+ifwkZRGiszjZEaR0n0QOlIMb7lDOOw weRS+2S8CrjU6J0GaZNLiaY5piDdGoVMM/in6YFS72SNeyJdW9UyRmwYWakZVq5k9dIqNmIc 9SxljXhFT7JhyfEZIZdSNwS4VD1WxmhK0U2U61no4zBRQU0JUp1O2WBIrEEvJyh1dKc/nFFo PlcroykvohZQE1+GUqpY4rvdPlVnw/fYRJV5vMI4RqYH6aFNyPO5CiX9ZYeJ9JlSOZ8gnfKB xESq4SL1cObSUVIdaDpWwVrzquBS8ySdFcFXYlqnUwwOClZHcdBFZXQOHr6FCHWUZWF9Yj2c pqzTqb+CaBqESyXuiAQ0xVEXrFaHa9TRWk2MaGqsaTTh/1bW8ere62+OmjJ1277DlkSDKd5g TjSa443W6kZLgmLzDWlq+3Ac/lpnbSviqmtD3PUdnsaOtTv2lEiVp69cDzR1BZq7Qy3TI20z ou0zEx2z/fHmB5bwQILVbQ0zFw3Nwv79RztHPXanb8MORfGAsniXsni3omifomi/ovCwovCY uuC4Ju+0Ju+cJu+SLu+yLu+qLu+GLv+GnjLfZkkvHNM3DQULMuYssFtuGQuRm8bCayyX9IUX dAVndAUnNQXH1YWHlUUHlFgXrXGnomiHoujykrmlj/+UjXu0uqtn0KV/k3Ypv9QHUMqLpav6 tqVd2nv108aDb+198Wvblhf/+I9/5i79h3/99x13v5px4j3xyhd+3nyGXHr4yB52eRg26NG5 E9yli+HS6xf66h/Jkiw+uZNcuvPO4ZVSAtDgj2zZ2fvbWx6R9F48vV6Z1d7R8oh6w+0XN+uy 1Lve4ZVSgBMQff2II8t8+rW/+9dvKX/+5u9enfdI1tzb/3p5ySNZi1/BA776wz9/8bt/PLfw kaz5d0/NfyRrzo13PvvuzY++evW9T196+85qZZZ03bWbL712/f4FuLRq5ZnLt08vBi3rBy7e vHXh5g4almn7TWrie2yFKEu84Oj26nQhlP/U9TOX4i5q/cun5x+9zkum8T42eNIVuJQ36N0S TT29bOH+YxeFS9QcPX+Bu3Tb2b3TK7JK5u0+sC6eVT5vE5hHLt1JV0Zdw4zIf8pSLo2s4dee 2TibmRIo3XmCrp56qpdYu5aAinC1bjg50E51y+28DfDAkb7WsqzCmX0E1LKZ67bPKsqKeCNZ xXMG2OPJtOTSyJrdx47tOnpsYYhxlNdIUz9FswaAUmzeprl8A9hPfB1tf1Z82Zkz+08j7FXM 2bX35Kk9oOnxk7uOHd9+6Mi2/Qc3LcZmFiVW7VjOXDprJR/6CC6dl5hOLvU2tTjrGyw1Nfp4 XBOJKIKBKreLjX4EiIKjPCTScgehVCiWerwyn1+R6dJ4wphImqprLMlaW12Dq6nV19oZ6pwZ nzGvdu7ipkUr2pf3dq9cP2P1xlm9m+es2zqXWzSVuUDp2q1z1m6etWbj9J51HctWty5a0TBv SfWMueEOGozXXtfIBj3CNxRcyoulfNAgwaUSwaURcmlcGJLX0lBvb25ytbZ429sCnR3h7i6I lKOUuzTQ3ulr7XC3tLmah4QxFS5tttc3Wmrq8NJ0Ueyf9FU9w8igS6NxUJNoKrAzQSgNxymw SlqnmB9N6OjeuJqaIjOX+oDAh2kakEKGbMwhCVDq82Ma80FHeZDICqmK6KqnnnInjcpbknGR xnKHl7dLLGcDvQjXccFjHM4yYNLtEWGB8G04JA+HwFElaBoNYxripZIsAIzVsUi8mS5lNCWd unBLv2I+tfLFxiDQcojhTbAiAdXtK2UpcRMPil0epMjpZjp15LKGvgBqjsk2zYQJez5rgZkW qciLBYYlfiQC+LHL87CJQFiCgKlsjVVeCiYk7MFSfl1KFhlZlCcip0pplDqXEkTTSYuUoZSJ lLoEswGQiKYR3IuzsRijKV3Uh2jq9nKdsmKpH5shC0bwMDUVS2sM1XWmmgZzCqWslzLrDNPY jlv8V2olmpJL8Z8r/os1JBv01fW6RJ02jv938b/vIE1lwZg0GCN/AqhUF01BNCMyQmmCo1QZ r1XF69SJenWiQZNo0FY36qqbEH11M2Jg0ScaqWTKmvJKArEqb7jCFSjlXUx5U14dziCpNS+v mqau7aEfy+XJRDpBgXspExEaPMZINCWo6DJoylDKejYKLgVKWcPUsSpMU7/iUXIqmQourWIu FXGXDtJU0CnVUTlNBZcOS7kUlhBcivN4s6PA7gZKuUtxvJUgg1VTuNRb4fFV0sWZBJfyknvq Kin8Ap7OQpOjAN5j7Xin0RV3UihlZ2A45eIoJZFa3EgBYkXoajGkUwvRlHRqFmqnHKV5FkqO yTEVLjXYsnXW8VrzWLVxlNIAmo5SUhhKDWPVhvEaI7Xg1bEWvEYLoZQ1jIdI8y0IH6JZGOuL SqZ6KplO0uCsGmeNVPdLo/QHXGq05sGfvBu2cB0d6l9agjnkUlu+AS41k0vVgy6dkulSJXep BrgaXoXzV05TIWxEXNVI9rcJoJQnTdMxMg1oyl06kVyKU3DDhKEuxck9XDqMuZQqpQJKZUJK kTRNWSoo3KXPpv5+MTxdMpXjONGOwx7AZqt4MlBKvQkMgy6VaaiMX6XECyHr8rBOs/yirMyl 5mlaO06vi5lLKxysKa87WuWKVNiDOM8uIJfa8bBxUu5SQik1DEaGNET/YZfy69+mw1DqKDA7 qRGv3V/hClV5AEVewGzQg4jMpQ+I1MjCplMujbdoo03qUIOCMbLKFauwh0utAbwKTlOGUjdQ WmjxFFm9JXZ/GbkU37ERiT8uD1arwrWaaD1oylvzGuLNumijJlyvDNICAV2YPM/gxs6ZorFN UlshRkAom4qlvJWBg7odWjyFNl+JM1jpxXdaUhGp12BRNe3mhm5782xn61xnC0vzXGvDLH2y Uxlppqa8zliBOTBV5xyvMI+RGkZL9SyEyQkq82StPYe71A6XxsTepDRQSygNNihCTfJgo9Rf XwWauqpL7VHWJNiTrbKPk5vHyoyjpQZeeiWXKk0T1dZsLXOpwT2VuXSayY9ApNMQcJSJdCqi 903ReadoPZM0rglK2ziZebTYMGLQpVQvfQIihUuLRE/wazizYduoYM5HoafPAgU0HSflQzTj AKOwK9wasxWscJpJU1bWnpZKjo4uLcPushFT9XYqd/NQpdSFX4FYhlJrNkPpWDm93hFizbAq 9fOVqmcrFPQJKpM9Qx8r+nzhYyW0kC9nNK1SDROrR4DuVDLVjcF/BEp8cEwT1OZsfOeApnoK aDoYrE5nm6SlPqhTtLTqKazr8lQNayjOyrycpoVGNxu3yV1CV7VJFU6dwSpXCC7lNFWGcODh v+Za/EdJJdPaRksdaNoMl47Nydtx8JivudtV30Gpw20nm8atEHd9N+JpoHiRxm5f03Q/ZQYS aJkRbJ0Zap2FhNtmb9x1sFSpO3/9drxzXqKLkuyaXztjYd3MxY2zlzTPWdYyd3nrvBVt83s6 FqzsXLAKt+3ze9rn9bSxtM9f2UbpobA5Ow+fmjHu6Xu7tu22yvZYZfussv0W6WGb9LBdetwu PemQnHZIzjkkF92Sy27xdbfoukd00yN6wVN12yvkDkVM8Qm5K0Ry1y+545fcYrnmk13zyi55 ZOddsrNO2Umn9LhDdsQuw7r2WaR7EYfy6trllU889uYHH3UsX9XVs7p75Zrpq3rJpT97NOtn j2W4lK4/2beqv29lhktXXv7k8dazz3ae9+949e//5d+XXvgouuu1v/vHPyt67/DxkPi4R6wd L7n04KkzR8+SS6l/6eLDZ69eu3Dj5uaGR7IaGmrSLpWuPHL37vV795Ab9+8jx9fIs+RrV7Y/ 0nTo7X1djyi2DXQ/ot/22u8//TUvlv7j13/81zeOwqVnXv/Tn7/9079R7qx+JMu++8M/X176 SNaSV7/+/l+//v5fvvz9P59f9EjWgvun4dK5t9774rdvffLt6x9++ep793tVWdINN6iv6UuX l5FLz15JNei9dOuFSzcHmEsB1FsXjg+6NNHPCMpChdOjy3HXfLgU08yl845eP3u9Lw6XbiOX EkrpOjSXT1y+TO14eahk+qBLt549t3VeRVZFPEA63UXlRxLdzr2sTSwbrZcRtGz2huPcpav3 HD+ObKBCKP0Uz96x++TxPSdX+1jlk0B78uQGcubs9cd3kEtn9vORk8ilpcylfTOLssraZoaz wqt2r47gkR1RttKTJ2kV4dV8fOAhLg2vwpxdx47txtpPnNwr1GlP7zt9ehmBVHDpcubSfdyl c7lLT+05fnLn0ePbDx/dtiyA7a3p3bVy2/Zlm7Yu6F3P+pcub1mwuG723ET3zHBHp6+51dnQ YK2pMSYScKk84Bd7YA9nhRMQtaUyiFIqlro91IjXFxBcGo5CZfpYwhCvNiWS5upaa229s6HF 29IR7JgenT4nOWdhw8LlrUtXd/as6161gVrzrt0yh6qj2+au38ZcSpXSOWu3zO7dPHP1hu6e te1LV7UsXF4/d3Fixlx2kZhWGvSouhbqgwyZS8PSgDCYbdqlbCyiCPX5THcxrauzNTY4m5s8 rS2+9rZgZ2e4q4vSSQl1MJe2dXha20FTHpdg1B9yaTiqCkWUhNIQuTQUVoUj6khUEwFNY0RT JAKLkkjVoRglpVMNwyrupQfQuE0RBbzkYy59mKa8YklFSyqZ4hZShUjZsMNU1cTMKrrerKfC RTSlc0q7hy7USZdnZJdkpAREVEX0VbroYqfU2tblqQQm/f5MlyqiwDx3KaGUSZhEKiWUpl1K NCWdsmDVrIQbYHVdPDEMmNFVW4MRiJHqmdTOlsJ7hJYjHn+ZB0YFUAEGd6HdWWBz5NMgSRTq TWohlEIOFVTwDIKacKY0EJUFovLgkGAtcCYDKgtTK3sYuzDPYKKIgvzPwmbyQZJptOQhEUTK UEpXjqHrmtI1Y3DOl4Q2+aVr8dKqfAwzbDTgMuxSuBS7SHBpDI/UDroU/3GmXTo4mJaVrjzE 66UMpTUND7sUG6OMJBRhrDQugzwfhKgQaThOlVI8LFqtiCWV8RpVglCqqa7XUgvhRl2ySZ9s NiSbjckWFkyApk2sZEpNeaWBeBUf+shJF5jBWS9ryvuAS3mZNKNYCn+mK6UQBQGVLgKZgVIq kY2SsEa8rIMfTvRZh0ktbAAdAaU03hV1NKWhmFMuVTzoUobSdJhO0zSlQX2Hp13Km6fiDB4H UsqlAk0pboRaX6dKplTb539i4Ch14FzfUwKVWVzFOPUHbk2OfHKpLZd13YRLKZhA9NSCN43S AqunELF5sAOLbO5CG9Op1ZmPQKcW0JSCCYg03+rKs7jw6zSTfYqRmvJO0FrGaUyjVYZRKgNu kTFqoNQ4DijVssbtcKmBudRMLs1jIqWRtyjsukG4xfLpsqhUMp3M3ju8R7w9KnOpGhkl12DP T8hwKUxLLmVDFsOl9GcsTNB1Yhx0kV5YSJ8a90hAqWEK61w6CQtR4X3HYYDzeLzRdNlVnGc/ TyF08YbWI6gVN+6lnmkZNNXgKdyl1K+SuZTyQy4dXqHC+T0rlgKljKPFsqeKpU+laPpXXSqn v1+IcZCQS3Gc4PCjP4uw1tHUQBoiBf5TAU1ZGZ9aUGNfjZCq8VwcabQ0gaZ0gk4ulerGybEH zFNTLi2zBZhLw9yl5fZgscWLE25QIVtpGivVjRCpeLF0qEu5TNjIN+RSwwMuTdMUxyGOxgIq lrqKrXib/JU/6NIkc2kNi8DRtEsRwaVCeZM35XXHKx1UMi2x+gvNvnyTh0apIZfStXnTLq1w h0SeiMQXkwUSilCNihpVCjTVx5q0kUY1uZQWKHLRWEoFRk+Ozon9M5loagFKebGULnrJriyS b/UW2f2lrlClLyYJJZXRBm11i7G2w9I4w9Eyx9U2z9XKM9/eNMdY06WOtkgDdRUuGpV3mh4C tACTMOQYGdEUyprArlySY3QVWJhL3TGJPykL1slDDcpwkyrSogw3g6YSomlNuTNeZA3lGryT NA4sapzcNIZoyhfFy4DWSTr7ZL1zqtFNxVKzP8ccYAki00xBuHQqYvBPYS6dnOHSMRIDteOt UD0L4BXx62xVPVGECI14n+WNeKuoEe9oGi9acOlYKWWMhIJv0bF0GSHo9AGaUoPetEhpJLbB cLXiKwtfXNQSG6Gu7wYqq07T24HDSaxYOk5hHCOl+vBwXiytpGIp+yhxl0qfLpGyv/vQ54tG uq5EVAJN8XGWCSXT8fg/Qk29TCdqLUynFtKpDtNQvTVbYxGCA0BlnqS2TqbwZsn8Mq1U6U3p 1FlkdBWZXEVmd6pNr58a9LrDYg9cGlMEcahXq+l/51p9op6VTImmd19/Y3JJ2b7jpxvmLAUp kRBLuH1uqG1OsG0OJihtlEjHPCTaMT/GEu+cn+hekOhemOhelJxBqZmxpGbmkr79x0Va8+UX 7jfOXd40d3kzMq+nFfJctLpr8ZrpS3tnLF03c9n6Wcs3zF6xcc6KjbOXU2Yt24A5qWzkmbl8 A7LvxIWZk0a+fGD3obDtMBKxHg5bj0csJyOWUxHLmZj5YsJ8KWG+ljBeTxpv1RhfQGqNdymm e3VC7lPMlHrKixm532C5i9RbbtVRbiStV5PWy9XW83HLmaj1RITWhTUix2qDl7dt1o1+/s0P PmxftrJzBacpXPq7B11KLXgzXDpm1qXjb3zXePAtjs/Qzlf/5z//W8/lT4wb719+/3cly24+ 5NJj+06cOHSaj3u0n7n0EFxKg/EeW1HFKEX9S0+tFGeBhaeoHS+j6XXQ9NwaalGb1b779bde OjqdCo3a3be/gUv/++e//fsv//BP3/zxzymXplGapT/yzTd/+rdvbtP03Nt//ur7f/3y/dO6 rKxZ1//+k6vLMLPrwu/f+ezXb378zWsffLmv+5Es5dZTr79zYq0Si69ade7K7bOpjqYvXLg5 QArdfuv8jVvnmUvnH725oR7LqNuQGraXLjBzlPqXzjuC6RtnjyytzKqad/ja6Ss07lF0awZH MyCauiWRsi6m57fBpRULtpw5e+D0OnAtKyu29OSpvSd3drB2vMTFrMji48d3M1vSEEd8tN7w Khr36OhR4Tox2yFM6iy661g/dfgsm7Xu+LFd1F6XptcePdo7szQrq7Rl66H+Q4f6VwSzskqa txzsP7S1BbNZd9Odx6i9Lh7dtoOuE7MQTw2tAmJ3HD48HxwN9uCJ86gdbw9mUt2VXVGGj6tE vVt5m+HYun275gHSrB3vad4YWGjHe5za8Q4cOda3HIsrqV23p3fHzp6t/Us3bpnfS5eK6Viy rHk+jXsUZ+140y41JMAnascr8XlEblelywGapoJpQmnapdK0S4NhNVwaiemYS4WSaU29o6HZ 09weaO+OdM+unr2gfv7SliUr21f0dq1cN52VTGcDouu2cpoic9Ztmb128+zeTTNWre9a0du2 ZGXzwmV1cxbFp+PLhS4SY6ttSLmU2vE+5NJQhkupKa+WN+WtrbXW19MFbJqbva2t/vb2YAe0 3BlCOjsx4W/v8LW1e1oFlKZc2uoarJc2WJK1eGl4jepQBK9XEeAjA3GaRjhN1aBpKmoQJRRV BVmIpjE1xyrLEJfCon/ZpQJN/VQsxRqBYX4RFyqZ+mk4IpEHNIVFIVJCaZU7IPHS0D5ycE4o G0J3MJ5f5PEBsYgIzsQC4dIQuVQeYTSNhOQhrDfAWg77YFEhHkIpC6GUOEoi9Yr9Pgk1KhbG QFaEo4pwDDBjV22lVq9UzGSNb1lPyGCljwPVX+7x0WBFLnexw8UG702FNUIusQPPeFEBMUcp eyEKaFOAJd0ymjIDU6NcHnoMN6c6khBCV2oBQRHsakGqqSv3ILyxLhviCBNRBP5MoVQYRLdW F8evSQ0OOSgxhNdFLqWS6VCX4giES/HaVdEEHq9P1BqT9UTTuiZrfbONmhtRiyNWKW0BVs2p MikX6SBK4zWaGG3GoEvpernk0geSyVTWiDehiDKXxmvViTpNQnCpHkk2MZdSTMkWxFjdrI83 aKJ1VDJNdTEtH9LFlNfcjOOFdryDqGCu0PIGvUAFK58CJ1ykWhIpNdpUs86lNCrSCFYRGiFh kTIdgQdyCkQ6iryE+YJLaeijwZKp7CmkApE+VZ5KCqhpmg4XZ7hUSyNmMZe6GEqpDTmLS4id XXAINGUlU3oTeZNsGmnZXUIeI5HySmkBFQxteXprDhsZdQoWjujoii+8W2muCeyEQnF6TSlO pcjuKbK7CxGboFMmUgcVUa1OkBU0zRVKprbJBis15dWaxqiNo9UQqXGshgKUjtfCpaZsnWmS Ht42TzNacs1WhlLmUitIibDBtyzgioOXTHP0ILQ5m713JEZ4DLud7/mUSyfBpQZzjsmK5RTZ 8KFzU4t0NkIYaFrKSqZFZuyB9HViDJM5SplLJ2secCn0q4avhKv+CBf+oQJLpktHDR5CmtHM pQg15VXosJxBl8qZSyXMpSJ+VUnq8CZUSjlKeR5waYUCebaS5wGXKnGMYQ+MVmioYq+iij0U yjhqpGBvY5+TS1nJVAmXarHThotVeC3pgZRYn1Ucz5oMl9ryDK4ii7fUFih3BCudYaBUBJfa AsVmL8g6xKV8FCUKb+dMMkm5VMMudMRcqh3iUkZTusX7W2AedCmrl+IbPg4lgojkUkJpK0Rq rmlHHtBpul5qgEtjTawpb53cnxR74pXOaJk9VGINFFl8BXApwq/tkXJpqTNQ7gpWevDtR015 5cFqYJiqppF6LTwZbdREGtShOmWwlrk0VmYLFZq9eQZ3DlzHaZpCKWvE68zD8q2+IkegzB0W +ePScK0q1qjDxtd3WptmOlvnutvnu9uEOJrnmmqna+JtsmBDpae62BbKMXiy1bZxChMMOUZO NB2rME4EeHT4VHoKrdjgiMibkAZqFeB3pAmm1cTa1LFWZUSgaSVrEpxv8k/RObEooqkCNMWi qFhKI81Sn0l8Ql3TTN4ciz/XGsi1BnNBWWuYYgnlmEOCTqlq6puiB03d2SrHBIV1rNQ0Wqwb Ual+HsdtsYRdVasKIqURj0ro2stULGVvPXWPl1G1nIJPBKFUje/P0WIWupKQBjodL+MNelN9 TdkwSNixaZFO0dJ4bDxTdfgSwFdBKnp7TkYLXhBxAg5IuQHH8EixZphI/Ty7wBL/HPFKKbk0 HUi1jP1FRqR6vko9rAou1YzEpxj/BSiwr2B440T8Z6GhqinXKb6HkQka7EbTRLV5gsqMNU5k wWeBgCp0mrVMVdOVWnk75HzoVO9EQFN2IVZvuY2qpqCpmFrzxuSBONE0zGhKIziw/2FrGw+f v6j1+LyxeN/B451Le2tnL03OWpycsbgamckyY3Fy5tKaWctqZrLMWlY7GyeWy5H6OSuQhnkr Guf1NM1fiTQvXNWycPXuY2flJsf1e690LOntWrq2e9m67uXrZ6zYMKtn45xVm+etxon0toW9 fYvW9i9ev33x+h2L121ftBbpX9jbvxC3D+Xo+atz88a9cuzgiYbIicbIycbg6cbg2cbg+ebg xebgpZbgtdbgjdbArfbAnY7AvU4/8lKn92Uhvle6KK8K8b/aTXktnelI4CVK6H536G53+E57 6CbSFr7aGrrcErrQGMLqTrdEz3U33Nq4euPixR0GDbl0aU/HspVdK1Z396x+0KUMpUNc+mjz 6ac7zv2y7SzH57Nd53sufzx1wdXHWs4803H+Fy1nMl1K4/EepfF4D54+nb5ODHPp1XPXrl+4 cePgCoJnzcCdq3fuHF7FupHyH9nqo/fv33zpfI8iK6vt0L033n75xjbAUbXjjY+++f7T3/yP z3/3D199/8/f/B1c6hSewn7m3fn3b/9E+eZP/05NfFM/ugNffv7bf/j0139/b296MCTjhrvf vnpnp5z/puisl2eJ11y8evfcEri05/TlF+5cvMXrpQDqC6xeKllw9Ob5G0Oa8sb7Ui49yq4u c3RZRVbV3MNXT125umsJc7do8XaG0qNQKA8sym6PQKQMpYfPCeMebT5N14xZCshF19KovCcG 2suzimbvgP3YoESpH4bMNBoRAmfpzN4jhwdWsla24ZUDR1cyYeKHrsuAe9fQALyHSZWpH+dy utBo36FDq6cDpqH5WNTRPgbamVg+2MlrpECp8MTgCjx+LnMp5nCasgGBWa/X9A82/tSpvaxb Kf2UR730Ksilu5hLdxzubyoR7hR+8urbVq+duWJVO10nZmHtLBqPl9rxkksbzUnm0ii145X6 IByXyO0ETYWkUep0VnGXephL/UElXBqKkEupZFptiCdNCbi0zl7f5G5u87V1hbtmJWbNr523 pGlxT9vyNZ09a6lkCpdSyZTRlFyKCXLpLObSzhVr2pb0NC3A18fC+PTZwbYud2PLEJeycY+4 S4ViKaYDISmkBCbxLqbxuL662shLpg0NzqYmd0uLr60t0A4tg6akU9zCpd7Wdg+JtJU4ysJF 6mhoctQ32mrrIW19DJiMKIMhQinHpGBFKpkSTcNRBODErYpQGlEGWIimuGuQpqygCixR/1Ja VDpplAoZpGm6WIoVgaZyCNwPvNHlW6rcXhFVRH0it1/ixXKwRiw8ThIjsPGOuEEx0dRLLW95 nZNcGiSXUsk0pAiHZKGAlP4k4SN5IgJHM1Dq8WSg1C8LBjlKlZGoEi8nEqewJq98rCDAktOU dQQNUHmKMOAtd3tKqXhFwzUVWe0UnB9b7MVWZ6ndDV2L3NQvlHqE+uB2oqmctcIVFErTQutc NpOwmkYpby/NRkJOYFendEo0pfxvuJSS4VKql3KXVnqFV1HmcoOmlR4fZuIuPECJNcaoZKqv rjNwmtY2WeoGg19NQsPdOlhUl6jFf7FDRBolA6eKpRylUURKEVoySzIixi3uopJpQiiZgqZx 0LROmwB3G/QJ0qmhuom71FwDmjYbEo26eL06Wov/5qWpprzUxZS5FPoSxs6R60bjLISQSc5M RY0zadY4k0LnUiyMo6pRNDAvG5JXpMCJOIVKZyxcCFS8GgzAMEJC82lIXqIpiUJwKUPpk+XS J8skQjDNdEpVU4CB9R7MdOnUtEupS7Or0I44KbZU7M40TekvC3yYLhrJ2VlkcRQSxuz5JFKQ zEqXAgZK6bod7HIddA0P7lJbjtGRZwY7PUU2WNRX7PCVIE4eb7ED8dA22N0FKZ3ilqbpVxc1 5aWSqQ2QztZbJmjNgKggUi1iglQnsCHBeCPeKUbLNNOgS4HStEtpy2njnQUmB/QCl2JrJ8Fa GS7lNB1NLtVOUOsn6YxTM13KrqNDjdLZaGH4DDKXOgpMQJclR2cii6qJppMBVKBUY8xWp0ey 1eOUmnpjSuiqP3iLh1UphVK2WHAp9UljLk3RlFzKaUrtV/kwuaxkSo3DFcbxcrqgIs7sR9EY tnRVSXJpKbkUFoVIn3zApXzco0GUUkdlSpX8OSBZrBjGXSpXjxJcCpQylzKOZmawZAqXUvNy nIsriaY85FK8KMGlE1U4HoBGZyG51F9uh0tDQKnIGS6zBYrIpc5Bl1ap6KqqP+xSasnJXYp9 O0VrSrl0kKZDXeoutfsqnEFWwGQdPsml+ICnXFrbTknTlIJpNifZZki06mLN2swupi64NFxi CxZZ/Pkmb17KpQUWGM9bbPOVOgZLpmJfTBogmlLVNFyrjtSrw/UgLlCqCMCl1VXuGJRLizJ6 ciFzvXOK1o5MZShlxVJXvsVbaPeXOIPlnkgV71yaaNKzRry25lmutnmejgWe9gVupG2Bo2Wu uW6GNtGuCDdVeZMlDupiOklrBybHK82kU4URmMzW0AVL8szeInuw3B2t8iXloXpVtEkda9HG 23TVHbpEB3SqjLTIQ41iX225K15oDeYY3JO1jmy1dQItyojAUcKVOQmlnlyLL88WzLeH8+2R AsQRLbDH8m3RfFskzxrJtYRzzSHqcUrNen2Tta5slX2CwjJWasTRO5yXTEskT5eIIdInccsa 8QrFUgm/uK5mnIJG5BpL184V/qhHqaLv0lFV6jGsajpBTi6dlBoDKY1SHIGco0K/d0zrbNP0 tpyUSzFBxVK6tBVzKW/ES0VmGoaXu/TZcibSUny++CeLwl1Kl54GTdnn6zkR1UvpQlbUBEM7 mkY/4k15GUGZTieSSM1sDpF1PF0cOBX6q5NxAu80q2CjOilNU1TmqWrLNLU1V2tHoNNCfKCM nKaeMquvkv7cExJ7IlIvTgNi1JqXXXtPT4M4ULukjuUrj52/MD43z+YPHDp15uz128cuXjt2 8TpyNDXBc/zSDZ4Tl5GbJ68M5tTVW6evvcBy+8x1isHp+/Srb87fvItcuHX34gv3Lr1w//Lt F6/cefHq3Zeu3X0Zar1x/9Wb919DblBevXFPyPXUbTrX7r2yrHTyRy/df2X/wGvIvu2v76e8 sW/7m/u3v3Vw+1sH+t87tO29w30fHO778HDfR4f7Ph5M/ydHhHyKHN3O81k6x3bwfMryEXJ0 +4dHtr97eODdAzvePrDjjf07aHWH91zevb13zizdpHEXb9zasHt/29IV7UtXdi5f+aBLV/fD pTwCTUHNNDvTear9HLD6wEwED95+6NDOI0f3HDt+4OQp1sX0/IkLF09eunz6ytWz166fv37j 4o2bl27xK8TcvnKHdHr17l1EqJq++OJNukjM63dff+vFt99/7YPP3v702w++/v3H3/3p09/8 /Re//6evvv/Xr//uz1//3b8NyR+RP3+FfP/nL7//1y//8K9f/OFfPv/dP336m3/45Nd//9Gv /vsH3/zx/a/+8M7nv33rk+9e+/Drl9/7/MW3P7rz+nsvvPLWjRdfw/t6GW8z3uxbty/efIEq pTdunbt+k+fs9Rtnrl1P5drpq5QzuL1C1zKFRU8il6+cuHQZEGUWvXgE/mTypJw9xy9YehA5 w3MGgUVpDN6TCCzKi4rH2ei1dLnRHUye7EIsVLcECOn20OHtBw8h/QcPIn0HD7AIE/3IoYN0 GZhD/N6DfQcQurLL1n37t+zbNyT792/FXQf40w/iXeOrYGuh5eMuZCsetn8/Hpx+PO6iR9Lm sYvWYJuPp3OCT+yki9McH0COIsd2HD2648jR/oOHt+w7sGnPvnUDu1f1bV+2edvCdRvnrF47 ffnKtkVLGuYuqJk5J9Y1A0hzN1FJ0Ez9S2GnMFwq8/vEHneVx1VJNB0MUJp2KfUv9frJpYEQ uTTMXZqAS41ULx10aahrZnzmvNp5i5sWr2hdtrqjp7d71fqZvdSUd/Y6oilQKjTiXbtpVu9G cunyNa3k0qW1sxfEumcF2jpdDS3WGviQXKqOZLqU0ZRcSiGXAksRfhXTuI67lJVMHY2NbiqZ tvnb4FKBpgG4tK0dM1MobSGRNrU4GpvtDU12oLSugTXipWIpVUr9QTmU6KM2rtS21s9qmIyL KuZSHmZOKocimOAuFVDKuphqadwjfMniMbz0yjM4PUSnlCAsSiuKwKURrJRqmz5+BRcKUCr2 4I3D6gDjBBsKmGqGIBnWIqMdFajCg70+sY9fb4a5lNEUKFWEg7wRL7GTQ9SdjlsIudSDB0j8 PgiWu1SJ7YlEVeRSoimVTINRWQAnTCE+5lAVv0qkh5oTV1C3TJwB0xjCJYRSW5HFVmhmMdmK zHacEJfb3TB2FXs5YLZU0CkSyoyUTzCa/oBLB1GaLpZSm16aoH1COh1MZlNeoikgSjqlRrxA KZE1gddFTZT9rH9pqlgKXSN4UaxkGoIY6Xq2KZrqqmv1yTpDTb2xpgHBBKSKsNKooFAWrmLi KImU9XqlsjMXKe9SG2T9aQMhMUJjPgVTCYnwK+7CI9OteWNJVawGUcdolAhtrA4EZRclb4JI LTVEU2N1kz7RgLtUkaQ8GBf7IpXsKqaFVsGlEzlspFpAlK71IqJWmhyZ/NIvQiF0EKusNEr3 4mFyhJ2C0yg4/CycIpI/L5IDqMPFqRBTCaXDJVArESJdMmUupRrpk+WSJ8okT5Sy25ROUyVT 6mIKFLFhZo2TuEvN9kIa94iJlEaEZm3FUymwOhhNXaX09gGl7LJG1A6WDV5NFULOUXOOFmHX 6iSVGdl1L41EUyqZ2qalXUooxRm2vxRx+emKPhQfjbdEQOU6ZRxlwbZxl2I7uUsn6S0Tdebx 4ChDKRcpoVRvytYLxVLWuTTTpUTTlEtp4CLuUog6l7tUBeDpx4J/4KhAU6rMjMtwaS53qd0F l3KU0vjVrEkzXacX+8Rkz6OGwTB52qWEUuZS40R1yqUK3SgZtXqF4hC8IzzsykCE0kyXMpqm XAonCy7lo+OyvspKGrsV6htD1/rng7KonytXDrq0hFxKNCWX8mKpMBIvtTYUAaU8zKXsoIJL hz/sUo2BV6QzYqTWvEJTXrhU6GLKyr8CTVm9FDtTO1aOQ84EBpBLcQ5t9ZXZWVNeVxin0WBq kdmTZ3BO1VrxisakXYqD9i+4dJxcC59PUhvg0qk4/AwWug5QBk1ZL2Lev9RdYvOysYjwHRsF EdURfMabDNUtRNO0S1lMCBMpS4cp2Q6X6uPN2qjgUrFXcGmxLVhooXa8eSY3AppSF1AL/eWl xE40pZIpaOplNPXHZYFqRTCpDNVSgjWKQI3cn+QdVssd4WKrvwAyT9GUi5SuGkKDhFHP0mJH oNQVrvDGqHNptEFT3WKo67A0Tre3zHa3z/d2LPTwtC90ts6zNMykLqbRZrG/tswVy7cEpuic E4FJlWW8ykwVTpUZkswxuqkRryNU4YlLArWKSKM63qJNtOG5xppuQ003dKqJt6miLULp1R4G cafqnZO1diyNrn2ipFapk3T2KQbnNJMbKM23BQqd4SJXtMgVK3bFi93VFFeiyJkocsQL7Uis wBYtsEbyzVCub6rOPVntYDQ1jBRpnsfBCd2R8SSgKTXirZDia5Ded/pI0kcAKMWnABM4DNIu 5VfeIpeKtWOpNa+Bu5QuAJtyKUepIFJsNhuYbYrOSl9QXKSpsEa81klqfLGb8Rqpcykdk5rh cClrxMtR+mSxJJ0UTelyxNRCvhLHv/K5KtUwiWY4/l+gC1npxigMYyFPKFTDwnSKWy7ScTQ2 UmqEAuo0qx/PmiUjE2SGiXhFcuMkhXGy0jRVDZ2ap6ktuVpbvs5eYCCdFpncZRZvudVX4QhU ucISD84BcHZB/3fTABAx6i/DaFrfsmjpyctXdT7/5NLykZOm/FCmjuKZPHX05Gmjp1DGTJk2 dmouZRpl3LS88Tl543PzJyB5+flllQXllEKkQlRUISqurCoWiUtE4tIqSVnV/4e9t4CS4loX cFlvvbXuPfeek+ScEJKgwW2QgYFxGHd3dx9mkGFwdxsY3J3gMLi7M1jQ4O4EiJ/cc++79/3/ 3ruqq7qrenqAJMj/rX811bu2VXX19P7YJa4OHV0dXdwcXdxZwIKbQ0fdsO/omtTgi8C6IoLq fRFU/8uQ+tVD6tcIbVAjrGHNsMa1wxvXiWhaJ6JZ3cjmdaOb14u2qs+iQYxVA3gV0UIsRFo1 iFK/hYiwqh/RvH5Ys3qhTeuGNKkT3KROUKPagQ1r+Teo6Ve/OkRKy/pDQn12HDg0dta8LkNH dh0GXjoaxL77yLH3H5mcx4v3PWL349XzUr1AL126FGxqwcqVi9esWVq2bvmGDSs3bVq9eXPZ 1m3rt+OUKajp5t17t+zZu2Xv3q3s4aXoqAfQUVFTD4KaHt17rHxf+alDp88fP3/l9JU75289 vnTv+ZUHP1x7/AsIJ/rnd/91E+NfLP7rBsQzFk//6/rT364/+ee1J79effTLlYc/XX7w46V7 31+8+/L87e/O3Xh65tqjk5fvHr9w48g3Vw6curD3+De7DpdvP3Bky96Dm3fv37hr78adezbs 2L1+x+51O3bx4Oa5BswTA0/QZefoshA3MdqyYiMTUVBQ0M51G9hDX0A4yxbxYLcpWrRmLQvp GaGgcCiiq0Dw0D+XrwDt5DKJTrhkCfokCCFq5BIUy0WLIaZiLJq6aCHElEULJy9cAK9TFi6Y uggCE1lAhkVTF2JMXrBg0vwFE+fPL53HAhZYTJo/H1ZBWcy5eBGXVWiUtwiJkxcuxLJYfD4U l/JDZnRaLrSzmM3KMYvFTAjYkGXLZ0AshVgGMf3rpVMXL5kMUjpvQcnsuaOmzRg2aepAvLi0 pPvwUYUDh+T0HZDRq3dy9+LYzl0j8zuF5sA3PMsvDQQDvdQ1Ic4lFjwk2jk6EoN7KZsvdYqI YGoa7cKmTN3jEjzjE70T8RJTUy+NKgAv7Q5emtZ7QPaAoZ3QS8cqvHSqwUvFfCl6ac+xpd1H jusybFSnQcOy+w5M7dE7vkv3yPxC8FKoWemlTLfYfKmkptxLQZa8UlPBS3G+NEvppZ2NvZSd xCt5qUFKI/LB1QtASkNz8oLxJN4M2EAwcNheLqUusXHw6hafwM6tZXc/EiHmSyUvTWEn+rKz fPHq0ww/dtteeIW3kBNUE2oQkQSdZ48PxQARxVvvCjVFCcSTeNFLU1LYjXOFl3aMje8AwSwO JM0rCVrBe/+yacMMb5zDhLGLmDKVvRRrZl4KRoqBJ/HGg3CCeYKCOkNERTtHRmFEScHUFE/l NcyXgtCy+VLYEAyUUugDyCRe4Bodj1e34sNaYMgLAym8wNUelCAcpDScGWlI26CQtoEQwW0D gm0CQ9oHh9txNY2MdZbsFCMWts4k4kCkwU4NagoiyowU7zjFjBQ+Bf5B8FlWyIY5+Um/HqpI x5AfZypNqArTxh2YAlrILi4FKcWZUrtIvI8UiI08ZQoZ3OCwTE7zhN2elumTnuWbgXYK4ZsB kS3pKJsRxYllDPmewHJn3JPwXGW8hhZv8oRGynQULDTBOQ6CXRgZGyce4hqb4BSXKNQ0Jd0D 1DQFwxMjyyuF3cMwNcc3LS8goxN6aU5niOCswsDMTv4ZeT6p2R54V95U5xi8xJR7KQxu8AJF NlkKtonnHyo8E5fZ1XE8YGzNg4krrHKrybKxu5i6inDkAcNxDLRTFFR3g6CCPLBgamrwUj5Z +pldR0Wgmn4OQyX0UigivBREurlvcMsAdi+fsEjQLZRS8RxdvCYTojVenGlQU3YmOcsD6fgs UPbQSL/glnjmKj4NBU9b9Qpo7uWPz0SBgAXWCoz8YNjHz+PF+VLupVEJ9tEJDtH4ah8dD4G3 +4qKbR8p1FQEs9M2IXg/JPBSEGnmpUHcS9GUhJEGQzQLCG4eEGwVGNwyiF1cGiKdx6v2Unm+ tA2/GtY3pDn3Ujb9wtQU9pLw0iYKL4VKYEfZwbeS3cGLP1eJeWl0ezw3OBx2i+yl3EgVXhrI b2YLXspmF7maYtRCQWXzKtxLJSNlUspC9lIYkeMNcgOgtibsrL+m3niPnEbsFM16eAmcX21n nxqOXl/aw9DZHVy0momX4q1ZhJTKgWoKB5LSS+vIXipNloKIiv8CYAFqyqZM/RswL0XZVnqp dB4vnjrOTmVv7BkIMtDKH1wxun1oHE6ZsrkdsFN2rSYoWaSVj5GXQiVMTdk3qDZ7VAy/Iyvz Ur+meCpvoNJLW3MvxRsvo5e2CY6wCYlqHxYDougYldghNsUtAf5e5fimdwrILAzM6hyU3QV0 NCTXoKZSFGFkdwvM5F5aAF7qBl4ak+EYlWoXntQ+NAGkzjoopnVgdGumptbBeDcvG3ZSAKpp JFfTZD5r6hKX7haf4Z6Q5ZGQBa8gpW5xmS6xGc5RqeCl0lnBsdZMTVsFwB8WXmdMW7yyNME2 MskhOgVP4k3iJ/F2DcorDi3oFdGlX0zRoNjuQzCKMKK6Dgzt1Ccgu9g7rYtrYp5jTIZNWFLL gOhmvuFNfcLQJ/Fy0BArf3YSbxjobopzXKZrUq5XWqFvJpPSnB7Beb0gYME/s7tPejePlAKu uG1DEsBmQU2b+UJVoG341BOrgIiWQVGtQ2K5lLaPTrWLybCLzbSPzXKIy8GIxbCPgci2j86y i8q0i8xoH57aNiTJOjCupV90M+/wRu54Nm9tR88acIjaMy+143fidYW/fnVcwEu94SvQ0AMv LYaAv7f13XwlL0Up/coZXtmpvMxL+TNgwUutfJiR+uCdhCCaYaCUNuVqqvBSeG0J2xIQ0YJd XAoZQODx4lI3f/RSPI9X3IlX6aWfteuIC7ZcTd3wVF7mpdX5V4ypaR03vHl4PQ//+p7+DfBe 1oHCTsVMqT976pI/u8MZPj8Mg52T3JBFIxffxmin/k3c/JuBnboHWnkGt8C50+DWPqHWvmFt /cNBTdsHRduFxLALTRNdopNdY5Pd4vgPfQb8kvqlZwVkZnM1LR49du32nQdPnORxgL+Ww+sp ZRw6cfrQydOHT545fArjCMTpb3gcPXMW4tg3545DnMUoP3u+/Nz5E+cunDx/4eSFi6cuXDx9 8dKZS99+c+ny2W8hrpy7fOX8lasYlzHOQXzLgi9LATkhvoG4dPnMxW+hktMXLkFtJ8+zOHcB mhBx/iIEJsLaC5cgTl3EOA2lLn17BopfugyVQFW8zrOXWR+gdd4NjGtST1ijrEVsFFvERiEm LlhSOHiEqZf+298+Mr0fL/PS2ZX2UjCoWUuXzl2+fP7KleBgS9aWLV3HHmS6afOaLVvLtm1f v33nxl1op5t279m8Z88WCCaoPLYdOLDz0OFdR47tOXbywMmzR89dOXn5ztmbjy/eff7tgx+u PPoZtFMo6Hf/grgO8ey/MNBIMa49/e3ak9+uPv7nlUe/Xn70y7cPfr50/8cLd384f+fludvP z1x/evLKg+MXbx85e+3AqUt7jp/defjEln2HN+0+sGHXvg0795Rt21W2befarTvWbN2xeuv2 1VtwFnQVmwXlgXOhmzYtx+lQJqJsFvTrdesXl4F/li1cjQ93AeGct3LVnBUr5y5fiROe3Dz5 AlvGmc9ly2ctXTbz62Uzvl46ffHXIJ/gnCB+wgYXoEyKmDePR+ncuRPmzMGYO4c9aRYD3spP neWrMHji7Dnsc5w9btbsMTNnspg1dubMcbNmQWIJL84rB/M0tDsPEmGVdBiIgPyYmeWcvHAR dJU7Mw/QTogpGIsnQyzCmISxaNLCRZMWLJowbz4Y6RicKZ0+ZOKU/iWlvUaN7T58ZOGgobn9 Bmb06pPcvUdcF5wsDcvLC8rK9s8AU0rFJ1iin8R2kL1UTJayU3kjIMLhtUNkVEdU01i32DiP eLzEVOGlmez6UualhV1ju3ZPVMyXdh05rvvoCT3HTezD5kvBRSHYfCksTJW9tAi8dOjITgOH ZvcdkFrcK75LUSQ+rCU3EAb67GEtspeCbrnw+/HyB64kiEk879RUX+alQdnZIeI83sKYzl3A QsFF5fN4hZd27gLKChnw3F0upfkgpaDrOFnKT+L1Tk6BLWVSCkYK3m7wUsP1pXhjXn59qVBT lZTyB8lk4B/TgAz4qwo7PA0KslNzIZIhPHhwQQX5ZGrqihqZwBwyyTMFs8EqSOwYH98B734E kQDhEgc2mwrOA1IqPUMV1BSnTD24l2Jm9FI8MRgqRLFEIwUvdRcn8cbCh463242MdIyAiHAI j4BXDP6/EtFRzjHRXE1Zr3Bvw2eBgcqHZ9i6xiWCSYJVOkbGOuLNgfk9mVBHmZFGtMcTd0Nt 0EiD2/gHWfsHWvux8A+S1RTyQ0HHyBinKBRU52iMDhBschiiIwT+70ACNGdQ08Q076R0CJwj hbeQmJDszudacd6Vz7VCSgoPNznwtkk80Anx3GBQRHYhq3wZM+xnp5hYfGAsM9L24ZHtYFtg oyKjHaJjwRU7wEEIx2RSqkcKqqlXGkSmd3oWRlqmV2oGJHqCOrJLcBUtcmcGn2fBrpuFACNl UsqMVNZR6URoe4xYDEiJjXeOT+oIBZPT3VMyIDySeUhqCsNWvL0+emlobpew3K6gpkHZBYGZ +X7p/FTeVOfYJHv00mjmpcGgCg3c/eqCY8CgnBkpPpdSSCbXS5z85MEElS3jmFs8KQRyfmkS MCarAQFq6uRmrKYunuAPoKY4ZWrwUrRQ0NGqth2rwiuLz9BLXWGoBPqB5/G6wtiOeSmM5tm9 fMA2mZdGgHehkYLRBYeC17UKglempmER7SIgjxBXMDTQgFb+weBgLXyCpFvOgo76QTT18Gvi 4dsYtEGcaRkE3g4jv1YgCez6UtlLHaITHWIgEjBiE+xjhJrixa4R0eyiU1RTfKgv99LA0Bb4 hCR8im9jPI80AG905MemSZmRNg/EM3hbgJTinXiZlIZyKTWcyoteGoInIePzihVe2sTDvyG4 n/BSVNP67movDRZeait7abTCS0MlL/UPsfINUkkpC/RSHIDiBZn1PGCQCkNVpqZS4Ml+rlxK /dRSqvZSL/zsmvgENfUJZgNrvF0KGz0H1XcPrOvqX7ujb01n7y8dPL+wd//cDrzU7TMYQNu6 wjKkiDMM2YiZXQKHZ97CISTC4KWe3Evrefmil/LJUmGkwRBN8RU/BTyVl5/HC5uAXsomOVlU R5/0wIffuPjAaLuRBxwMIS39QRfxElPbsHicMgXdiki0DY0DWW0dEGHlG9oYvNQNvNQbnJZ5 Kaop/58dnC/twJ/By27JiweYP+xhK78glZcyKWVeGg5eiveHC40GUbSPTHCOgT/s6Z7J2b7p +f6yl8IXPJepqcpOi0KEl4pb8nol57klZHeIRS+1DU9qF5rQJjgO1A5nNfnEZlBUG0lN24fH 2kZgiyDDoKYdQE1juZpmiojD4F7qGJFsF5bYPjQe1TQ4ls3BsnODQ2LxstKweNuIRPvoZKfY NPGEmIxC+STeyK79Y4oGxxUPjeuOEdt9aHS3wWEF/QJze/pkdHNL7uQUm9U+IrlVUGxzkEm/ 8Ka+YY1ByXzZSbwheBKvfXRqh/gs9+R87/Qu/llFgTnFYKRgthBCTbO6y4rbLizJOjgW1BS0 lt+tB2+1HRjZOiSmTVicDXyU0Sn2sekO8VmO8dlOCbnOiXkdEvMxEljE5zvH5TrF5jjFZDtE ZdqGp9qEJIKatvCNbOKJU6Z1nL1xyhSv0gTHQy+FP4/cS+vhs4vgbxc+U7cxeCm7VBvPbuAX TXTwquPsWcfZq25H+Bb7NXQLaOQOX+ogMWsKUuqN8594SyH+vzks4EvUjE2ZMiNVeWlzvzCw d+6l9dz84YtZuyMck97gpV/CN4udu8v+04epqTxrauf6OXopPz0evlNeNaGUC3zBfUFN63r4 1/NkV2Wza7OZnWI09Ayoj5rth990V3yWdd0OXvXBsTt41+/g06CDd8OOPhBop65+EE3RTgOa e4CdBrXEidNgUNM2TE3tgqNxyjQcRhSJHaPhRxx+K9M84Vc+hd/KASMwMwftNCs3GKcuYJSY G5gJC3n4wLbMfIigzE7BWTCALAzL7RyW2yU8r2tEp67RBd2jC7vHdC6O6VIc361nQlGvxOI+ ScV9knv2S+vdP73PwIy+A7P6D84ZMDhv4ND8wcMKh44AkQOF6zVmfJ+xpX3HTew/ftKg0imD S6cNmjBl0PgpAyBKJvdnAcv9x0/px5b7jpvUZ9zEnmMm9BhV0n3EWFBBGNwWDB6eP3BY3oCh uRD9h+b0H5LdfwguDxyWO2hY3qDhnYaM7ATZho0qHDa6y/Ax3UaOLRpVUjy6pOfo8T3HjO89 rrRvycR+JZOgDwMmTBlYOnUQxrTBE6fBAmt6Up+xE3uNnlA8oqRo+NguQ0d3HjyyEGNEweAR 8Np56MguQw1eeo976cf8+aXMVUrmzsZgU6agmpWJvKmLFoGazvz6a3ZC74oFq/BaU7RTPne6 cdOqTVtAUNds3bp26zbQ1HXbt6/fsWP9ToidG3bu3Lh79+a9+7YeOLT90LHdx04dPHPp2MWb p649PHvru/N3X1588NNlEM4n/6WKx3L8dvnxb98++ifGw39eevjLxfu/XLj/8/m7P527+8PZ 2y/P3Hxx6vqz8ssPj5y/feCb63tPXNxx5MzmfcfW7zywdtvu1Vt3rty0ffnGLcvXb16KsfHr dRuXQJStX7QWYt2itWsX8mATnnjO6kqMuStRNWctXT4TDJOdNDsFDHMhGObCyfMXstcF+Aqx EGIRJs5fCIKHE5hz542fOxcEEtQRjBHUcfSMmaOmTx81bTq8jpg6VY7hU6ZADJsyZejkyeqY xAKXh02ejHnkVZMmD5k0eXDppMGlEwdNKMUohZg4eOLEISwDZIaaR06bhi1KwZuTKxkyadLg SZMgPzSNmSHPjBnQz7HilO85coydPWfM7NkQo2fNHjVzlipmzBwxbfqwKdMGT5rcf3xpH3xm 6eiuQ0d0Gjg4u2//9J69k4qKQUqj2Bm8TEpBYFLRi5JA8EC6YtBPxEm8eH0p3vcI78cb7hge 5hge7iypqWtMrEdcgldiEvPSNPBS+b5HoHYGL+0zIGcgeCm7vnQMeOmkPhOmcinlXsoWVF4K X5v8gUOz+gxIKe4V17lbRF6nkKwcflNcvB8v3vsnCSwUFAuvlpQCUvAizJQUn7Q0v4yMwKws fnFpBF5cyqQUb3dULAfe96hrN/BV2BWRnQoiOhXg6bsgpXmdQvEMXpws5Y16g3pB/UxKhZey x7d6JiWDW0JzvvgI03TQZnjFudCUNOgnhMFIM9FIg7JygrNzgrJzAjKzoIdQEBQawis1BcIT Au9CBHaKV366JbHTa1nwy0HxBkUs3UV4aRyqaVwCztfFg8qCA0Nb8IHm+KVn+abxKVPQeHB4 MV/qgl6Kd/dFq5TU1B1P4sXJUmd8dG2kQ0SEfXi4XViYXWiYfVgYLENAItopqmlMBzyblz9P FWSYfxbs9FpJStm9PfGhiLZhkbZ4qiHqKIswLqVtAtFIW/sFtPYNaOXr38rHv5VvAKhp28CQ diHhUMQuDO3UPiLaASda2Y2dokBTMZzxklpQaLBTWU2TwD9xdhrtVDZS1FG84zGfX8Up5QTX WHibxMNFER0xYBfhAhg+D5aS0CEG7xrFb2iMZyCHR+CVsWHMCsLC+ZSpY2ycc1xCx4QkV5wy RTX1SE33xEAd9UjBOxiJ83LBNtlNofg1tBCueIcnDDxdGaUUjZRlY2ftCik1GKkduLGIGDtI iYlzgt0ONYPxgpcmY6i8FOdLcwPgtzmnc1he1/D8bmCnITmFQVmd/DNyvVIywcY7CC+NasW9 FAcWvjBihtGzkWfiMvNSfl4ueqm42w0u8xlRzOPoJusoCxcIqAS91NFV7aX8VF52lan8wJhK eKkveGlTkEk/do9Zds1ke9lL8cEqQkqlWcewNmE4ZQrRJjQCMkCplgEgGMEtfMW1lM28/Jui kfo2cfdp7O7TCIaPbvCKZ1qCRDXzCbYC/eOn8oaBc8YJL41JdMQbULNbfMWBmuINqOUpU6am Si8NE14KIgqOBKbEvJTf6IhNk6KRtkSXxj4zKeWnIhsCp0xD8MHFNng5qHT3YIOXspvfunpD 8EFwI/BSH6WXRjAvZReXmnhpW/TSMPDS5kov9YXegkPyy8lwbqShV0B9Txih+go1RTsVUZGX sqe2eAU0AdH1xfE0fwpiMxxA4yRYA8+geu4BdVz8anXwqe7k9YWDx+f27tXsTL0U7xcKUsru F8quCJXUFI6lmuyg0vRSlFI2Ly3CLxj/d0DhpXBksplS+f9l8P9c4BsB2gCj7YbucNQFt/AD aYyyCYnBKdPwBIfIRPsIULK4tkHRrQIimvtIXooOwKZeVV6K58MLL2XXGYKiNPMJAC+F3Q6H JXopf0Qt81Jr+ESC8QZaNqHRIIo4ZRqd5BKf5pGc5ZOW559ZEGDqpcJOUUqZlxYpvDSfe6mD 7KUh4KXR4KX8hFt2zi3ecZpNmeKDTPnZvPxC0w6xqeClrvEZXEpdWYCXdohOw2eihiehmoYl tAuNtwmJg4AFMNL24QkopVHJjjFgj+muSdniTry53UM79YrAk3gHxHYfEt9jWHzxsDgWMUVD wgv7B+X18s0s8kgpdI7Pto1MbR0SZxUQxdW0iS8cMyCTUW1C49pHJDnEgO5me6R08s3sGoBS 2hOMNLywH1Qiq6lvRjf35E7OcVm2kSltQ+NbB8eAizb3Q3lrERjZKhhvF2wTntA+Ktk+Js0x PtMZdlRibsekfJfkAtfkQh5ufCGpwCWxk0sCPoHGISrDNjzFJjihdUBMM++whm6BX3XwqQXH p4OYMhVeyi4u5Xc8gq9AY3aptuSl7Hp+lFKv2k7opVBDPTyVF77OgY3cgxp7BDfxDManwnqK +wnBKwv24C4v/P+d5r5iylThpRE4IewT0tAruD7z0jouvrU6eNdw8gLn/MJeTJaCjspGWs2W B3zRhJp+6QRfK88a8BVz8anl6lPbzbeOuy+oaX2vwAZe+B86Itj/VTXgz092YfcmwLlfzzpO Hl85edZ19qzn7FXP2bOBs3dDENQO3kZ2auUZ2MIruJV3CKipTUBEu8Ao+5AYh7A4JzybN9El Fn4lUzzwYiUYZcHwKRPGOfh//RnZ+N/9mTkBGezeEGnZ/mnwmuOXiq8B6XmBGfmoplkFoTkw 6EU1jewEA+Ci6M6gpt1ju/YAL03o3jupB3hp39Re/WDImgle2m9QzoAh4KWdwEuHjACLA4Xr Obqk77jSfiUTB4yfPBCMlEnpQMlLWcDCFC6o/cZNAi8Fie01ZkLxqHHopeCZwkvBSIeAkcJr dr/BGEJNh+aBmkIGcMihI4WXjhgLo2KDl46dgF46Hrx08sBS4aUgpYMngZdOA1PlXtp79IQe I9FLu4KXDhlVOETy0iHMS9l8aXfw0lHSfOnHn1Z98uzZhDlzx8+dw0NW07HsQlO0JhCS6Rij p0+H17EzZo6bMbNk5qyS2bPBrKAsWNakefPAvqYuXDRt0aIZS5bMZnOn85avmL9y5cLV+PyY r8vWLV23ftn6DaCpKzZs5PcBWsluVLt6y+bVW7eW7di5Yfe+TfsObjt4fM+JcwfPXjv27f1T 15+eufXi3N0fLzz45dKj30zj4kOMCw/+iXH/1/MYv5y998vZuz+fvfPjmds/nr71/ambL09c ++7opYcHz93ee/rajmMXNh88uW7X4dVbdy/bsHXpus2L125YuHrd/JVr561cM2/FmrkrVs9Z sWr28pWzQTuXrZi5bJkIvPwSFJRNFS5aAgo6acHC0nkLYPNLhGHOGj19xih1gHBCoNHNBPOE mAHyOWLatOFTQAKngEAOmThx4IRSjPET+peM719SwqPf2LF9x47tgzFGjt5jRvUaParn6FG9 YGHMaHjbe/So3rgAq1iMHtNz1GiMkaN6jBhZPGJkd3iF5VGjeo6CsqNZhWP7lYzDVsZjQwPG jx/AFnhzrJLRkBMq4fn7jYO146GHKLfQYRTXKUOkGDx58qDJkwdOnDRw4sQBEKWG6D8Bvjbj QUd7jhpbNHxklyHDCwYOzuk3gE2T9ozvVhRd2DUivyAkNy8wK9svPQO8CGfhcGouHs/kxJnS KEeuoxj4kBgHfIQpWEqoQxhX00hQU5foGPe4eM8E8NIU8FLxCNOs7JAcUy8dVsjvxzu2tFfJ 5L4TpvafCEaK0Q+CncTbd8LkPuMnMS8d23noiPwBQ7J690/p3jO2sGt4Tn4w/OkB6wPfw9m5 JHcUIXzICgaX0nicA4QN4ZOlAVmZwTk5OFNaWBjTpUtct6LE7sUpPXul9uwNryk9erLnl8pe WhCR3ykcIq+TkFI8gxcnSwPSM31T07yTktFL4+LlcI9P8ExM8k5J8QUHTs/wz4DIDMjIhFd4 Cy7KjDQdV2VmwX4GFw3OyYV9HpqHAX2DHvplpPump/mkg9mmeqeleqVxO5Ue3JKU6JqU4JIY DyGrqVsyyA96aYf4eGellyYwL03N8MtAL2VTpvjEVD69LHspnscrvJRNmeLtlNBL+WQpSikz UtvQ0PYhECG2IaGwjI7K1TQK1DTaGS80xfsnQbWgpmziGqUUxM8ZRrd4V88ofBAiDprDbYIh 2EWkIRChNsGhbQKDrQOCQErBSFv6+Lf09mvh7dfS27+1X6B1QHDboFB2G6Rw0D9bnGXFh6/a swAzdISIinaCwOepQp8NV6K6xclzoclqI43vyKZbO0bDAkQCjw7R8R2iMJxZOEXh7aNYsDOQ xfN1YkGJmZFGQWfah6GLtgsNswkNawvbEhrWPjzSPioapBHssWMCmzJNTnVPAUVM43YqSyne skh6iI4z2HsMGC+7wxMGF1TYjSioYKQsEjvG4WSp8k5LoKO2keASLGA5Ckw1DiyoA6isGS9N zwuAX+WcziClEZ26heUxL802eKlzTKJ9ZCzz0jBwj0aeeAqW7KViXM5Px2XmyW52yu53ijc0 YqGyUxRUbqdYhHlpdclLa0peyq+vq8OuMq3jiidbGrzUGR9eimrKvVQRxl7qxr00iHkp3qtW 7aVsspRJKQZ3vLDwtuGR+BDdUPRDXBsQ0sI/2ErppR5+YKSNQUfxuYLs6YI4o+XfxCsQR35+ 4KXhraVLTMFL8SRe7qVxPFBNwUvtomUv5efx4iStNU7Sgpdio7KXQjQBL1VKKfQ8hHUYp0nD 20K3echeCl8uDHZ9LHuqTSs/fISpykvBANEDmZd6+TXxCWgOXhoIXgp1RkCv8MmuUbEOUXFK L8UTg4PDwYtUXgoLLFBNfYOa+OKZew29YVTqX0+oqcpOJS9VSKnwUryUjnmpf2NvfMBPM1/Y DyH4XH7/8Ob+4U19QxtLY+iv3PxrdfSt4ez9paOnrKYQMFb+Aob7bLIUlA+ktHZHMElvdnUr HEUicBIevVQ6j1fyUmlqmp0vjRGCU6YGL4XOe4M38lMA4LgFr/jSHl9rOrrXccab6DZ082vq FdTCN9Q6MJJ5aaxdOJ7Kax8BMhbbJiiqlT94aQjYgsJLhZrCq/BSflNW6f434KVN8QMKggPS 4KWoo3IYe2nH+DT3pCzvtDw/9FL4Umt4aUhuEYvuIKiBWV39Mzr7phV6peS7J+Z0jMt0jE6z i0huF8a9FOdLWzEplb20bWg0eClvUboBUrLKS6UpU1DTjjHpztFpjpEpDhHJ9hFJdhFJtuGJ ELBgF5lkj6fvJjvFopS6JLLJ0vQC/+yuwXnFYYW9I9lJvPHFQxN6DIeIZxHTfWhE5wHB+b39 srt7pnXukJBjF51mHZrQIiiGqWlEU3ygS0SroOi2YfG2kcmOsVBzjmdagV9Wt6DcHiH5vcMK +0V2GQABdsrVlF2tWgD6ah+V2i48ETYcircIiLDChxJHWYfEtA2Lax+ZaBed4hCX7pyQ1TEp 1yU53zWlwC21s3tqFw+Mrp5pXT1Tu3qkdHYHRwU7Tchzjsmyj0xrH5pkHRhr5RMBDlm3o29t J6+ajh7VHdw0vJQ9UBe+Auilnn7wjcAHO7l414GDmXkpxFfO3lBJfRf/Bq4BTE0DG6OdBsFC Q/cA/mRpWOAXczbyxPPhm/mE4HNi/cMxAiAi4GsFXtrYO4T9X0/gV/w0hA7e1Z08QTjhq1TN zvUzW1fupcJOwVTtMGDt59B5R/fqzp7VO3ihl7p61xRe6veVhx9/3jJ75DK3U3aFNntIVV28 EoRtiKMHRB0WdcFOnTzqOXnWd/YystMmbn6ymlr7hFr7hbcLjLQLjrEPi8WzecFLY+AnEk8v 8uR3lEA1hbEW2in+R7x4SnymbwqL1CzflCy/1Gz/VFDTXFTTzE5cTcNyO0fkczWF4V/32C7F cd1gYNwzqbgPqGlqz35pffpn9BnAvHRw3iDhpV2HjwKL6zmmBLSwf8kk8FKU0glcSrmRGrwU FvqPE2raZ2xpb5wvHVc0Ygx6KfjhoOH5A4bmgZf2G5zTl0kpC9RUSEc1BS8d3gkcctioLsNH g5d2By8dhV7ai3vpuFJpsnTKoInTIEBKh0yaPnjS9IEwui6ZzOdLe4wqKRqBXtpl6CihpkPQ S+Et3vdoBL8lr8pLv5swdy4PpZfyGyCBTY1lXgpSijEN1RQC7HTMDFg7a9zM2SWzZuOpobPn lM6di4K6YMHUBQunL1o8Y/GSmYu/nv310jnLls1dtmLeipXzV65asAofwrlozZrFa9cuLsNY Ula2dP365Zu2rNq6Y+2OPRv3Ht525PSeU5cPXbhz/OrjE9e/O337B1DNcw/+yeI3Efch/glx 9t6vLH755u4vZ1icvvPz6ds/n7r904mbP0CUX3959Op3By8+3Hvm1o7yK1sOnyvbc2zV1n2L y7bOX7Vh7oq1s5etnrF4+fTFS6ctXjpl4ZLJCxdDTJy/aOL8hfyyzAnzIObx/YOzhbPYKbI4 wzlj5LQZOJk5acrg0kmDJpT2L5kAJgavEAMgxk9AnZMmLQeWlkIKBOTpO25c7zFje6FGjgJv 7D5iRNGwYRDdhg3rOmQoiyGdBw/uPHgQROHgQQWDBhYMHCBiEHsd0F96O7Bg0KDCQYMKBg4s GDCwU/8BnfoNyO/XPxejH7zm9eufD4mwCjIMggoHdx06BKLbsKHQHG+361BocXBnuZ6BAyF/ wUB4O7jLEMzWffiI7ui3IKtjekHPWfQcO7bnmLHFo0d3HzVKGUUjMboNH9l16PDOg4cWDBqc 229gZp9+aT17Jxf1iO/aHY20U2FIbn5gdo5fZpZPWrpnSqo7zqclgGngjBnOlEaBjjpwHcUI swcjDQ8FKbULw1dQF3ahKd4ACQzNMyGRe6m/kZcWdInp0j2xe680yUuLRo3vAV9R+K6WCi9l UjpVniztjV46Ab10yIi8AYMze/eDbscWdAnLzgtKz/RnTxDFx4cmJLI72TIpxfsPMSllT1Lh ouifmRGUkx2WnwdSGtu1a0L37kk9eqb26p3Rp19m337pvfum9eqd2rNXcnFxfDf4w9Q5shMY aX4YRG6+kNLs3OCsHOGlKcxLsVHUUR7w1js5BZQVjDQwMzOQyycLWA7IREFFU83KQiPNzQUX BUkO79QpoqBTeKf80LzcoGzIBhqZ5ssC7NQ7HdXUEwLVFBTU4KUuiQmgo5AC4ZKU0DEhvkN8 HHipM9hpPDgq89JkkFtoNCcgM9c/I1tMmaaks1sfoZd2ZPOlONWJSgleioF3ukqId4mNdY6O AvOUpDTEJigYol1wCCy3Dw21DQuzj4CjItJRTJmCl8a74uWvSa78hOo4nF0Er3OIYLf05Dc4 DQ6DaBMc2hYCRC4EFkLaBIGXBrbyC2iJXopSauXlawVq6hvQ2j+oTVAIZAaJxVv1huHkZPuw SHBCdNSISGanGMxOY5yj8HbEhvskxYpTdtm8KPNSIaWxHaJ4xGFExjljxDpFYIBIO4bHOITH 2Ivg5x7z04/5BbFsjhRPm2RqDVvBNqRtCHhphB10hnkpfgpg6WzKFIOpKbyCqaqkFPYS3ggK 7RfV1GCnYgYV9yQLvGsUnj8s3WmJSWl7KWwj0Uvt0EvxElPwUjd2Hq97SqZSSn3Scv0y4PsO 3/ouEZ2KIgqKwvJh5GrspXYRsTYhka0CQpv5qLyUncfIXFR5Bi/TUX7+LRdLnPDEO7IyQVXM nTKnFReaiplShZR+5eIpbszrhgH+UNPFs0ZHfJCp8FIHVxBRvO+R4tZHX0jXl4KXwgAI9Aa8 tIVfSOvAsLYhESClEHDkoJfiZaU45QiO1xL8U3hphPDSsIjWIeGtQBEDQlv4h7TAaymD8C5H Xv5NmJeClKq8lM2XNgWJwvlS5qXSfCl6qSSlThhKL2XPqmFSKrwUlE+SYe6loIsQTf0Cm/sH WQUGS1KKRmodGt4GdRT6HGEDAQuymobA9wujDdgLe0gMPtLGR9z3iF+xxgwQAwbBeNKsbwA0 0QKfOoPzxmovjVd5aZDaS7mU+gXLwc59DW6EagqjUoOaci/9CkLHS3mv8MxV9FI2WYpSGmoV EGYVEA6BU6a+oY28g+t7Bn3lHlDbxbdGB+8vnby+cPT83MG9Ggyjcazs/oV0u6OabKaUX9TK L3DlOirC1bO2G7vvkSd4KV5fKqam2XW8XEqb+4fAQhN26yP0Uui8ixcconC4SlLq8qWdC7zW dHSr7exRt6NXAzffJp6BVr5gj3iJqXjUZ0SCHfNS66ColiADPiGgCtxLa8leygJvWcxuHgYN wQgeLZ2d0tnUJ9DgpSil6KVt8CHPYKQYbcFLw5iXRkpemmzw0sDsztxLZSllXsrVtHtIDrv1 UWYXv/TO3qmdPEC34rOcYtLtI1Pahye2DY23Do4BQ2sNERwFIXupjfBSdiqvwktRRxOyIMQl pvFZLpKaOkWnOkJEpTpEpUA4Rqc4xqRCOMemdYjPcEnMckvO9kzLY5OlRaGdekZ07hvVdUBs 98HxPYYl9hyRIEVs8bDILgNDOvXxzyn2Su/SMTHXPia9TVhiy+DYFkHRVoFRzfzBJyNb4z1+ 0STx4tLkPK/0zv453YPze4UW9I3o3D+q6yAI8Nuwgr5gqgHZxV5pnV0Scx1j0ttHJNmExVuH xLaEjywI6oluE4bPsLGNSrKPSXWKz+iQmO2SnOea0sk9tdAjrYtnelev9G7e6UXeGUXw6oV2 2sUzpbMbu82vYzROmbYNjm/hh6fy1nPxq+PsXcsJp0y/gKPIwQX+JMJxBX/x8P7Y7CuJXgo6 B39y3fEWYuilcDDDIY1e6gXF63bwhXq4mnI7hYCF+q7+9V396rFAQcUnS4PiBjX1xilTg5rC /vELb+oDXyj00rruAXVcTf+vh3mprWtVfHURoZDSL5zgbzJ4Kfxx9q4JXzHwUvime/jW9YQv PvdSfzyblwWeQAFr2ZnwuC1OnrUc3Ws6uNWyd6/t4F7HwQMC7LSes6fBTjuCmvo0QjX1b+YR AF7a0jsEvNQmMLJ9UJR9aKxDOPxew685/DjCYBWvtfFMFk8B8GaBVy3hvR4xvBLTIbyTMnwS M3ySMn2Ts0BN/VNRTYMy80Oy2Tm9OVxNu4KaxnbpHteVnc3bvVdyjz4pPfum9e4HXprZb2A2 O48XvXQo89JRePdapoUT+4OXghNyLy2Z1H8cxgAIkFJM4WqKiThfOnp8TzyPd0xX8EyDlw5m Xjooq89ACPRSVNPBuf2H5g8alj9oOJvbHNll2Gh249yxzEtLhJeWlPZjXiob6ZDJEDOGTJox qHRa//FT+o6b1Gt0KTt5eFy3YWNARFFNh4KXjuSTpcxLx4CXgmxLXlqVzZdKXopXMKKXMimF mDkDYswMYaSGYJN+o6exV/RVtFbQV5xKnTmzZNas8bNmTZiDmjpx7tzJ8+ZPmb9g6kIwVbyR z4wleLov3t912TKIOfgMkuXzVq5atLZsybpNyzZtW7V934b95duPXdj7za1Dlx4evfK0/MbL U7d/Pn3vVx5n4PWuiFN3pLj9y0mIWxA/n8D4qfzmj8du/HD02vdHr748+O3Tvefu7zh5Y/PR S2X7T6/cfnjx+p1zVq6fsWTllIVLJ81bMmHO/JJZ88bNnDt2xpwxM2aPmjFr1PSZI6bPGMHn NqdNA/nkJ9MOmTQJYtDESYNKJ/YfB3pZ0mfMuJ5wlICJDR/RbejwrkPA8cAtMboNHVY0fDg4 ZzFOXcLrCFjuPnx4t2GQDbUTLBFcMa8/qGO/3D59sntjZPXuk9mrF0RGr54Q6T2L04q7Q6Sy SCkuSi0uSuleBAspmAJri8Vr9+4QKUXdk4u6J3WDKEoU0S2pqCgZVkG2HsXpPYqh2szevbL6 9Mru0zsb2u3TOwua69kTVvHaUrsXp4j8PTJ69YIuZffpi4oLcgt9xhicP2iQHHmDBuUOGpg7 kMWAgbn9B+b0H5Ddtz+4aEavPqk9eoHXJXQtii3sGplfGJbXKTgnLyAz2y8j0ysVBs2pbknJ 7IzQBDwjNCbGKRovL3SIjLCPCGcuKozUDoJJqV1oCLw6hIc5RuCTYzpGR7vGxXkkoqH5gQ0q vDQsryASvLRzUUJRr7TezEuHjykSNz2aDDraf9J02UtRSnGydHLvEvRS+LYUDh6e139QZq++ SV2LY/ILQzNzAlMz/JLTvBNTPOL5/YcwQEq5lzIpTfRKSvZJTQVRBOUD8YssLAApTSwuTunV K71P38x+/XMGDModMCi73wBmp71TevRI6FYEXhqRD0aaFwqRkwedD0EpzQ2SvNQPfTjFKzEJ DBwDFkCAk5J9oa30jKDMrODs7ODsnJAciFx4Dc7JCcrODszK4ncDDgEj7ZQfXtAporAAuhTV uTCqsCA8Py8kF/Jk+Gem+2VyNU31yQA1TWFqmuyRmuSeovDSJO6lKKvopYlgQWCk6KWgQ/zi RrAgH/BSdrlFQGYOqilOmaZ7JaW6JyS5yF7KLzFNMKgpeGnH2Fj46O3DI2xDw1BKg4PbBgZB oJ0Gh7QLQS/FKVPupbEKL03kXspsinmpfQS7Po1N43Ap5QEWZ8O8rk1wsHVgUCv/gJZ+/i18 /MBIm6OX+oKmtvIPtA4KZpl5fnG6LAQT1Ahb8MBwsNNIByaoOH0qXYYq7DQGp23l6BgT3wEv T4UMLCIxnCJiIMBFHcOiHcKi7cPgly/KLjQSdFoO2AR2+jHTUXySjWSkoKMs2qCXhrYPCwcv dYiOcYqNY/87AB9ZsluyrKb4CqZq7KVsPpZ5qaSmkp2Kk4cx4p1BX2Ok+xjjpa1KL41uz+ZL JS9NcWEPMgUpRS/l9z1iUuqbnuef2Skop3NoXtfIgu4Q4fldQ/M6B+UIL3VNSHGOgfF0DEgd 89JAEAYwsbpiaI6nHbLA60JBOOXzb0FHuVWKwOeU4hQQrMV5VLRTVgTt1CCltZ3d63ApdfWq i0809a7r7g3aAFHHDUY8XjU6wgDI4wtn98+d3KrJaipuxouTpfIjTLmXQm+b+gSBWMpeym+0 q/RSoabwFjQvPKJtRGTbiKg2YZE4dRksTuUFL23hG4R3nfUKaOoJXurbiJ/EywMGkUZeGsK9 NNY2Ms4epI7dg4pLKXopnscbCx8Q3mBJujkwv6JVOnk4uIV/EEhIM3AkkFKfgGZ+gXj3Xel8 Y5wmBQWF3nIjjWCvqKZcSuGbxU7yBIEJCG3lL56z2tw7iD+/tAH3UncWHr4NPH0beYOXovpC E1A/81I4otBL7dl8Kdgpe5or3o+XPRBV8lJf9NLmfrDhEGhxzQNCmgWENJVuJoyDUYOaMinV 8VKhypKX4nnRYrIUvbRFIPNSf+6lIfW9mJe6+tXo6POls9cXTp6fO3pUQzV1By9ll7151mCX lbLb/3rjUNiV2ymoKf43B4866KU+9Tx9wUsb+vg38g3gk6WwCRCwLRj+IU19g5ghGLyUT5Zy Kf3CriO8wvC6tpPHVx286rv6NvYMsPINaR3AvRT2G+w99FIb5qWgBNxL6+l5KXyD0Eu95bOa ofWmvoFW/sEtmZS2ZnOkspHiI3BD4KiGwynGNgJvROQYY+KlOdxLu8KrFLKX4qm8QfwSU5wy LfAE3eKXmEan2kUksSnT2NbBMa2D8aZHIKXWIcZe6qB8YEx8BhppYjYPj8Qc94RspqZZHeMy oVoRcVKA48VndEzIcE3Kck/O8UjN9c7o5J+Njy0NK+zFJksHxhUPSeg5PLHXSDniegyP6jYI 9DIgt4d3RleX5HyH2AybiKTWoXGymsKrdVh8+8hkh9h00Ej31E4+mV0D83qGFvQJRykdGFM0 BAIWwFFBTYPwatWubsn5ILH2USntIxLbhsW1DolBKcUzeKEqVFxHNlnqkpTrxqTUM72Ld0Y3 n8zuvlnFfhDZPfyyevhmdvdBQcUn0Lgm5jnH4pRpO/YEmqbeYQ3cAr7C29564TNC8ca2eDNe +NzZ03ThK+nXyBvPY8eJei92CzE3+Mr4wJFcu4M3Tpk6e9Xp4FO3I3ipf32XAAympiilLv4g q7CqbkfxiGD25fJjU6bCSzGYlzbnXuoVUt8DvDRQ4aV4ejx8m1BKQU3tXKtKAcvV7CHcqjm4 fe7ozqW0ekc2Xwpe6uYLXlrbaL5Uivqe/vgEYDcf/E8iZ3bnPEf3Wg6opjXtJTt1RDv9ytGD ndaLV582QDX1xZshuQc08wzEeyD5hbUJiGgfHG0HXhoR7xSZ0AHvQZ3sireE4LeBQDtFQU3G m0rgHQ0T0zwSUj0T0nhwQUU1Tclm5/RKairNmoKXQkQXwiCwe1y3HglFPRO7907p2ScNT+Xt z700d+AQ4aUjRhXhfCl4KQgIXl86kKkp81KhoKimJZMhRT6zl02ZTuwzppR7abdhozsPGVEw cBh6KZ8sBS/tPRCjz0D00n7gpUPyBgzthF46HL0ULwTlXjoOvBRa78OuL8UOgBiDlE6ZMXTK jGFTZkIMnTKTT5n2wylT8NLx7KJW4aVcTbvINz0CKWVeKl1fqvJSLqWzS8RkKUgp185po6dN GyXFyClTIUZMmTJyKi7wZYzJ+AqJLBtY67QxaLPTxrLJVZRV+aTf+fPZtZcLpuCpv3hv2OlL vp69fMW8VWUL1m5cumnXmt1HNh4+u/Pk9b3n7x+89PjItRfHb/504vYvGHd+PXEbo/wWxC88 jt/6+dhNFjcgfjp2/aejGD8cvvb9oavfH7z8ct+FpzvP3Nt8/Pr6gxdW7j6xaOO+2as2T1m0 cvycRWNnzR89bfawydOG4KXDUwZPgM9y4oCSUoh+48bziU08uxVjTK8xo3uOGdNzNJ4lC6rZ bfgIkE8+H5gPMtZvQFbvvlm9+kCgXvbqnd2rTw7qXL/8/gMg0D/74xxmdt8+WX16Mw/sARII BpjcrVtily4JnbskdOkS37lzHEZhbGFBTEGnmIL8aIhOeVH5uZF5ORAR+JobiW/hFdOj8/Oi 8/MjIfLyIiBy88IhcnJDs3MgwnJyw3MhoGBuVCeorRPUHNu5IA6jMJ5FbEEBRHSn/Kj8/Ki8 PKwnF6uK6gQdKIgt7BzfpSsoLsot9LlnTx5pLPhyCkaP5B492ImpxYlFxQndukMpvJ1Pp8JI vIVPPl4nCTqanumdKiZIXRMTmY7GO4GQRMc4Rkc7RkVB2MvXFnIRZWErB/NSfrWhU1QkqKzw Uul01oCMTGgoODs3NLdTRKfOUYXd4Nue2qt/9oChhcNG8/N4JS9lUjpxat/SqX2kydLeJRN7 jJkA3yLw0tx+gzJ69kns0j06rzAkIzsgJd03KdUrIdkjLtEtNp4H3nwoTsxeoiuCHqenBWZl hsA+75QfA58s7Dcw/779sgcMzBs0uGDIMIi8gYOz+w/I7NMX9l5CEXopWGKosMpcnCmVJksh AjMy/dPSfVNSQUTlAE2FFEgPyswMyc4OzYXtzQ3LgwAhzwMlhg4E52QH5+aE5ueClKKRgo52 KYzu0jmma+fozoXQvdDc7CD00jQIpqaSl6ZzL012Z1OmYKFssjQBJ0shJQXP4+2YmNABp0zj 8TUhoSPoUGKyJ3hpelYAGDW7AUBARrZ/epZfagbekhe8NA7Mh19fKq7FheCn8iq8NNw2NLQd 3ik3uE1gUJvAwLZBQeCo7UJC2sMhEcG9FM/jRS9lF6niebySmqKXRuOUS3v++I2QcBw6Y4Ty 51vAkNomDOQhxDooqDVOmfq39PWz8vFr7u0L0YJ5aevAYGtmfWizzE6F0IbiDCp4oC0E2ikc qOwOSdJNklBNo8BC+dyp5KWxIH4GL3UCiYXgUhqOUuoQyqQ0JNIWlCY4oh1GOA/DGcjBePox TvkapDS4TVAwbAgIs11kpEN0NHyP4NvEbwrtBmqKs6bCTpmXsjvrSl6Kwsm8FBa4msp2ypaZ kUbHQUhSKh5Lg3OkYKSSlNpGx9rFxIOXOoOXJim9NMszlT0qJh2fYhqQVRCc0yUsv1tkYTFE eKduoXldgnMK/DOFlzqBl4ZHtw2OAL0BL22Mz9NDLwWBxAtBeYiHW/CpTg821cmfdgADawi8 6SsEpMNaKAg5WUF00ZpOIKWusMyl9KuOHnVdPMFI67n71PfwqefhU9fD5ysPnzru3rXdcMq0 ekePLzu4f+HsJqspBBgpl1I+WVqzA4ix8NJm3EuDFF4ajh6IXsqiVQh6aStYDgMvRSm1iYhq Gx5pjafy4pQpCDk4mDRlil7KbneEXtoInAEkCqezYBAZ1Az0T8yXgiREtwsXXuoQAy6K06Qs 8J7J9tGwCjKAlAojhW8BnloM5smvaPULsvIDMUMvbeYbYIUzmcFGUoo6GhGJN2piIXlpGHw1 rINCWweKqtBIoW9MSsGXGnrg9AvsnHruLMQgWPJSab4UdkJ78NJIOMBwypQ/v5Tf9KhNIOwT 3CHCS9mTVMHfrDBCrQIxmgey56/64Z1shZoqvRTP5avYS8EGZS8FKW0eEN7UL7Sxb0hD7+D6 XoFfufvXcvWt0dFb5aUO7rDwpZNndX6DUMNjFfmlrcxOJSPF4BeXevo28EYv5SfxNmObw7YI mg6FBdlL67sb/lOGT/WDmn7B5kvxPEzhpT6wn5v7wv6Hv3JR7OZA6KW2EfGw3Frlpb7gnzhA l6TU4KX4OF/+LfBryKbOYD/DHm6pkFJ88q0IaCUKJ0sjYu3gkItKcIqFvyrp8GX3hq+5wUvx VF4ROSwUasqfYhqIU6aF3uxUXpf4TKeYNKFnoXHWITEsoiGElCq9NErlpe6JWR5gpEk5LHI9 EnOhQreEHNBdEYmKSILAaVL3lBzP1Dyv9HzfzMKAnG4hnXqEd+4T1a1/bPdB8T2GJvYakdR7 FI/E3qPiew6PLhoc1rlfUF4vn6xuoIhO8VntolLahCWAmrYKiW0ZHAOvNhGJdjGpTglZril5 Xhk4WRpS0Du8i5BS+VJVrqYh+OCZIs/UApfEHMfYdPtooaZtwqAeLqWguGnOCZkuSTluqfke 6YVeGV19sorARf1zewbk9grM6x2U3ycor09gbq+AnJ7+WcU+Gd08UgpdEnKdYjJtw/Ehq819 IxqCB7r41enoUxO8Do4lJ3f8qwV/J+ET9/Rr6O3fGKRUnHcQCEZXD5+6hP+bU8fFp3ZHH5DS r8A8Xfzq4eyoFCioQkpBejFATZmdyk/WbebDvVSaL8W7OoU19g5t4BlcD700oJaLX40OPuIc BHuPz+zcqtpKUmqP8RmEAwRKqWGy1EVMltYC53TH60u/AgWFb70XqCkG/yNQF2+E5lvb1Ru+ mLXYnahrOLjXsHdDL0U7RUfFM3sd8LRevOi0g1c9dlekhq6+jdz9G3sENPMKauET0sovrG1g ZPuQGPBS+4h4x8gE5+jEjvikIjjs4ScVxrEs2H0K2d0EU/GB53EpbnHwmsrDA+00wxvVNMcX T+jNC8jI47OmTE0LI/K7RBV0ZWfzdk/oBl7aM7lHn9RefdFL+w7M7j8IvDR/8FA+XwpeyuZL 0Qz7l0wEL+UKytRUeOnAErzidNCEqYPGT+Wr8KzaMaW9Ro8vxqlLPI+3YNCwfJBP7qV9mJQy LwVHlb00f+Aw8NLOQ0Z25TcoGjG2x6gSdhbx+D58slRI6XRw0WHTZg6fNms4KNXUWUPAS9nd j6RbH/FGR0E9TE3RS7spvLRYy0vnTJg72zBZKqR0GgTzzKmjwEKnGhR0+OTJwydNHjZp0tCJ E4dOxNchpbAgXiFg1bCJGJBt+OQpIydjcX4a8Dh2b9jxs/Hs39K5YKpzJ85fMHXx1zO+XjF7 RdnCsq3Ltx0o239qa/nVXd/c2Xvh0cHLz4/e+Ok4+qeIYzcNcfTmz0duYBy+jnHo+k+HrmEc vPrDgSs/7Pv25b5vX+w6/3jryTvrj1xdve/skm1H567bNeXrspK5S0ZOmzNs0oxBEyb3Gzeh z+iS3qPG9oLPe+To4uGjug8fWTRsRLeheGJtlyFDWAxm59PiKbWdBg5kIto/u2/fzN59M3r1 Tu3RM7l7j8Ru3RK6QHSFSGSR1LVbSlH3lO44mYn+WVQEkdita0LXLnGFhaB86JO5uRHgjdk5 4dnZPMLAMbKzQkBssjKCszKCMtMC01MD0lP80zACWARCpKcGpqUGggJlQKQHpGP4p6VB+KWk grH4orekwKtfSopfaopfGlSSFpiZDnWGZIPJZIZiZIVmZQZnZgSlpwempQWkpvqnpkJxHgHg PBmZwVnQn2yUW1DWTp2ioNt4tWTn2K5dMLpAdIa3YFaQLm7egxdJ5oMehzK5AlHEp5LgwzxS 3MEfuIvGxIJdOERF24OKREJE2kXgQN+OX1vIzuSUIgQjDMJgp/boJ+ClUeClLvFxIDb8VkN4 C9yMjIDMrKCsnJCc/LD8gogC6Gdxcs++Wf2HdBo6quuokuKxE3qNnwQ6yrxUktIJKKW9Sib2 GjexePT4rvjw0mG5fQem9+iT2LkoKrcgJD3LPznNJzHFKz7JPTbBLUZIqeSlKKVeScmw5wMy MoLhcwSxLyyML+qW3LNnRt++OQMG5g8eUjh0eJfho7oMH8nUdFBW335pPXslgpcWFoJSgl7i tGdWDhqpJKXMS7MC0jP8UlFNmY6ikTIphY8eDpIsEFooDh8QyC2PMLBcqDAvJwRMtVNeRGGn qM7CSGO7do7rBp9aYWRBflheTlA27K504aWZzEszUviUqcpLpclS9xRMdIXERHYqL/gkSimI ayK4kFdqul9GFkhpcE5+cBY+7jUQ1DQt0yc5zTMx2TUOPC2eX47LrgvFUHqpY1QUHADtQ8HB 0EutAwIhwE7bBgfboJeGopdGRTrGRDvH8afFJLglMQeDypmadoxLdIqJt4+EQQwMoWAgJcbi KKVgpOHh7SIi2oWH24SyKdOgwFYBbMoU1NTb18rHt4Uf99Iga2g9OETYaQi3UwybkFB86mlo mLDTMLw9Er9DkkN4tGMEOGecYeIUthdVHJbjOsTgrZIMagpeimoazeZLwUtlKQ1vFxRug4GP VJWllBmpQUphh4CUopcGg5eCrjMvjQEvjevIp0zR1UFNk93BTpPwiS+4i/C+vriL8OxcZp5K KVVEPL+6FS9tRVvA29LgQ18VXopGyqTUNjqOeWkS91LX5Aw32UtTwEtzmZd2ggErjFbDOhVF FvaI6twjoqAoNB8Gr4X+mXleqZlufL5U8tLm3uilDd186sGgGUbPzh4gkxDgpbjQQYgl+Gdd V0+80aubNw9YxkeSgK9CoJoyiZXUFKVUKgt5wGPru3s38PBp4Olb3xPEiampuw/3UjyVF68y FWfz8vgCA6TUrTo/kZh5aX2mNwYvDeVeijbIH17K1RSMtCV7bQ2JIIqRUTaR0W3D+ZQpU9NA PJu3pV8ITpmCLOGpvHgbXpDSRh4s2B1K8GJIlZfyyatYO5A6+CDAS8Xze+AtJOJkKb/SVTJS bpLBLUEOmZQ2B1HE2Uh22WdAED6nFA74UP59YfcNZtE+EoN7KayCDFAbZG4ZEGwFxgg1+ECf A8CUGnn4y1IKY1zZS2EczLw0oJlkv9ah0ATUibvLLgIPM3htHxZlg5OlYezBOXjNLZ7Ey87j BS9FKWVG2iIIIswqKIzNmgY39g1q6BPQgD38E8bc4Id1MbADBi+Fzkgn8XIvxRlCsUvFlGnz gDCIJn6hjXyDG3gH1TP1UiePao7uENJYGW8QWgtvECpMWFJinHuHVxHu3nCAsYtLwUvFxaXs psfS5sBrQCh0g81c+UPf6oLcdvTE09FxypTdxMveBV5rOMLx7AGeWc/Vp5FnQDOf4BYB0v9Q hMWClLaPiG+LXhrZwj+sqU8w5EEvBXlm15SKUw/QS/kZB3jKAHxAYuoMPkf/YOhMK5BSNkEK OspcNKpdGNQPRzVIaQyXUoeYROc4GJ2Dl2bj1zyrICDbyEu7BOdAoJoyL8UIxieaduVXmfqk dvJMznVNyOoQl45TppFJNuHQ+bg2obFtQmNYyF4a3T4cDg9sF71UPMWUeWkSeqlnUi6LPHhF QU3KdYfX5DyPFGXkuqfkeqTmeqahlPpkFPhldw7KKwot6BnZpW80TpYOTug5LKn3yOQ+oyCS MEYn9BoR031IeJcBwZ3wElOPtMIOiTl2MWk2kUltIxLbhMe3Bp8MT2gfneIYn9kxORcc0je7 KCi/V1jn/lHdBkHZuB7DwHUTe46ILx4WWzQ4uuvA8MK+Qbk9fDK6uKfkd0zIdopjahqZ2C6S n76b4hCX6pyQ4ZKMUuoJOyqrm19OcUBer6BOfUIK+oUW9g/rPCC880AIWA7p1Dc4v09ADlQo nkDjEJ1uE5rYMiC6sVdIffeAr1z9anf0Zg9Z8ajl4lUH/rSy5xWBizb2C27Kzjto7Bvc0Cew Pqqpf113/6/c/PB0A5BPV/96bgEN3AIbuAfBa31XiIB6Lvh0X1BWENc6HbwhQE2/cvGBb1kD d/gjENTUOwSnTPH6UnxybIuAyOZ+EU18wxp5h9b3DJamTIWafu7oiVOmdm6f2btVleIzRzf8 ojm5f+7s8UUHD5wpdfFGL2Vn8PKTeL8Ci/bE+dJ60G2vgPogpd6w4A+Jddx84VtZE0rBVoOX OnpUt3evbu/G7NS9piObQQU1xXs7YdRlT8Sp7+LbyM0PvLSpF/wRDmntH94mMLIdeGlYnH14 vGMU/G4mdYhN7hiX0jE+haupawJEikt8iitEHAxykl1i5Uhxi011QzVN90rMRDVNzfFLy/FP z2M36c0P5mqa1xnUNLoQLzRlZ/P2SC5mU6a9+2X2HQBemjNwMHrpkOFdwU1AUsBWxpT0GTeh /3j00kGlXD6FgkKAjg4uncZjSOl0eMXZy3GTeo/Bs2pBBbsOGVU4eDh4KUgp81LDfCl6aV/0 0vwBQzsxLy0ELx02uojdcgnnS8eO7w3SBF46YdKAiVMGTZ42dCpI6axh02aDlI6YPgdeh0ye qTiVd0LxyJKiYaNBSqFdpqZcdEdhnSClLOT78VYV9+MVUjq7ZPbMgyfKT547ewLiLI9vyr+R 48zxM4Y4BnH6NMRRiFMQpxTBU3AtizPlZyB4Jazac+dOsjh1/jzE6YuX8IE8l6+ev3rz25v3 rt17cvPh89tPfrj73U/3n//68MVvD1/+l2Y8eGGI+y9+E/H8t3sY/4S4+92vt5/9fPPx99cf PL9y9+mlWw/PXb19+tK18nMXj505e/TUmcMnTx0qP3GgvPzA8fL9EMeO74M4emzv0aMQe44c kWP3kcO7D4vYeegQxI5Dh7YfPLjtwIFt+/dv2bd/y959m/fsZYGPwzE8EWcvPg4HFnhs3our Nu3evXHXrg0QO3euV4a4UzHGuh3by3ZsK9u+ba0c27au3QavUrDEsu3bIdbykFbhM1e34j2Q YUFOxMxQ4Y7tULMysLicZysU5GV5EVgLPcGbJ6+H3kK39+zeBP2HrcBtUQQksti4G2L3hl27 IT8ULNuxAyrBJ8HiA2DxATwrNm9evgli0zKIjRAblbFc/VYZsErEJnb3rM2bV27ZsmrLFqh2 De4K2F3YXNnOnet4b3ftxs7s2btl34FtBw/tPHx0Dz4m9+SBk6cOwkd/+pvDZ77B19NnDp1i cfLMwZOnIQ6cOLXv+Im9R4/vPnx054FD2/Yd2Lx774Ydu9Zt31G2bfvardvXbNm6Whmwx3Dv 4Z7EfbVrF+wB2EVb2GOQ4DjZdQSaPrb3+PH9cLCxp1rtO16+5+ixXYePwIEEeeDAYDuNHRKm sXPXeogdO6Fy6AO+itgJa+FAwub4/t8rYiPEHvyw8PPiH9a+vVv274PYygIW4FCEtVDD+l2w u3asY1G2k8f2tTsw1mzfvnr7Njng7RqRyNK3bV21bevqbbAAgell0EnoMB4DsEV74CPAI2Hn rrLtO+EDEg8BhuD5RbDnA2/bBh8lOzbwkFi6YSM+jWn9eghYWLphw1J+DMif+9YtomnoEgvs 0jaMlVu2rdiyZfmmLcs2bV66EWKTCHbILYcmNsPCRqgQqoX6l6xbB7G4rAwDlrHRDV/DKkNs hMAu8YCChsNSeoIUPtB484pNWyBWbobDEg91vrF8GQK6jSE9gGoly4yxEZ+HDDUs27CJh6Et 3WD7BEO1W9g3YuuqraxptpONA/qDXcJerRQd42/lwPSVm+F7Ch+HFJtwf2JsVgfs5y1bIVZs 3b5y2/ZV23euxti1hsVaiB27y3buWbdz7/pdezfs3r9p74HN+w5CwMLGPfs37t63fteesh27 Vm/bAZ8a1A8f09frNy4uW79w7boFq8vmry6bt2rt3JVrpFjNYs3cVWvmsZi/ei0E5OTB30LM g2AZIKcIKMgW5q2GYNnWlC2AWCtiPsSasnlryuauXgsxZ9Wa2RArIVbPWiEClnnMYX2Yuwob glLQ20VlGxavY8cJ/E1jOwoPPzwCN32NsXGJCHyL6Zu3YIg8mzHPhk1L1uMN4Rev2wB7YNHa 9QvXrFsIlfN+YlfXLVy7HhribUFmKMKOcGgLW1wBH4QqIHEz+xbgEYWHMdS/fsMSqB9jPbSi inXrYS3bBNwKtiEQm5dBJYbA7xH/CkBOyA9VLYLe8o8MYg0EfnD42ckBKRCwtmzdQsgMTUM3 +NcKG9q8jAX8LsCr6C3uCtwPEIvKYPdiE9AWFFwMRwjEBinWb1y0bsNCiLL1UD+0wj9HQ+ss eJeUgccM7GHcpWyvwobgzofaNi5ct3FB2QaIeWvXz12zbu7qstmr1s5aCbEGYuYKDHgLiXMg VsMxg4GN6gceYGwPLIB9tQ52woZFfEPkzYFXaL1sA3QJOgY9hKMLDjM42CBmw+HHgh17kA7H HhwS6xfCwQD7agMcQvD1gSNhKwQsLNmwidcGeaAqLMK+RLw2Vok4gHHn8KOL7Qf1oYWxjB1g PNgfAfjjAH9jt63csn3V1h3wlV+7Yxd+zXfh13z97n0bNGI/xEYWuLwLY/2ufWU7967dvgf+ YqzaunPllh0rNm9ftmnb0o3Qf9wEo4BuLN+kbnrbztXb+F+b3Wsx9qhix14e0Ao2BLEDEjF4 Stmuvet27duw58DGvYc27z+85cDRrQeObTt4fPvh8u2HT8ix7VD5lgPHN+8/unHv4fV7Dq7d uW/19j0rtu5cvmX7Mujw5u1LN22DV0hZtX33GmgONm3PQcgMRaDg1oPHoQa5KngLrWzedwQa Xb/rAHRjDeyBbbtWbt25Yst2qHMF7IetO1Zug9p2rYbewl7adWDdnoMb9h6COjftP7p5/7HN B45BzTxgGRrahBUeXr/7YNnO/Wu27125ddeyTdu/3rBlUdmmBWs3zF+zHo5POFDn4B83OBrX zRfHIR6EizZshNeF6zcuWIfH/Hw4YCDWrJ/HAhYWrIGjaAO+QqzeMH81HFHr5kGsguOqbO5K 9roK/lbjF20B5F8LfxPgzzgcz5sWr9+0ZAMcjVsWr9+8eN3mhdCfso0L1m6ct2bD3NXQq3Vz VpXNhm8W+04ZB3zdVkHgF202/E2Wvmhz4a80fKfWruOBX3keZesxIJFlwE2GgvA9hVgB3yBD zGExdyV8KXiwzq9ifxbwLxj8NYM/PvAnCP4s4/G/fOPWFZu2wbGHBx4eeyzgJ4/FavYWX/la RayGwCdQ7lizDYZAMBDaVbZj9zr8TdwDv30b4GdxF4yU9m7asw9iy94DMFjduh+04uD2g4d3 HDoMQ8Rdh4/uPnoMhot7wU1AUtgY8tDJU4dPnj5y6szR099AHDvzzTF4PX1WxJmzx8+cU8ax M+eOwFgXhrgnTsH4cz+Ob8v3HIEhLoxCj4o4xBeOQeLuI9DicWhxL4yZj0OAJeHAFZ/LCtJ0 6jQ+f/X0mSPQ7jdn2dNWz0OUn4O4UA7L35w7eubskVPY4iEYVJefOnAcG8U4hq+b9+5XeSmb L/135qX4nBjUUQg2WQpSOnjkSKv27aza2zRvZ9PcBqOZTVuIpm15tGnaBqMJhLV1Yx6trRu1 bi2iFUQrRbSGtZCniTWUgnqwQqt2UH/7FhC2ti1tbVvZ2Vs7OLV1dmnf0d3ew7ejX6hHSKxv VGpgfHZIUn5YSmFkereozO4akYERmVEkIp1HN4gIiLSu4WldwlO7hCYXBMbn+EWne4UnuQfH OPuG2rn72nRwa+3g3NLOsYWtXfN27aFjEE3b8mgLXW2CwTYTArYao21T2A8YNlK0bdIWo3Gb No2srTFwV7AFtmfYVmNBvg95K7gzcX9KlfOAzHxBbkssYEqTtrDWOOQMolfiA2JdkquV6mTV iv43a2eDITrD+sPL8szWhoD9ADsE8jRv1655+/ZW8HnZ2ba0t2tlb9/awcHaUQpYdnCAlNYO 9rCqpR2EHXyy8PlatbeFglAcd1dbG9irjdi+atjaukHr1jzqt8Lgyw31wpqH2LcYbdo0hi3F LbJp2q5dM2gFmmMBn2kL6AB0w96hlYNja0enNs4d2rm42rl5OHp6OXv7dvTxc/H1d/MPdA8I hFc3/wBXPwxI5NHR29fZy9vJ3cvBzcPOxbWdc8e2Dk6t7Rxatrdr0c62uU375jbtmrE90wwW WMBRBBuLh7SdXSvcOY5tnJ1tOnSwdXGxd3d39PCECjt4+3T08XXxhdb9YNnZ08vB3d3O1bV9 x45tnZ1hH7bCHeigjNZSKHasIqAtw2fhaO1kHK2dHKwhnKEzTm07QH9YdOzQrmMHWGjr7AQF 2admBx8rjxb2ti3sbK1YwC5l0R52L4Yt7mRlYtP27SDEWvisYefb2bPNh5qd8RX2v4MjbAh0 Hj4a/K6xwKMCgx0eLJqxgwQ+U/nwqN+qVf2WLTFgoVUrPDysWzdqY90Yjmf43NvB527TrH07 6ImhV+1toRtNbdo1trFp1NamYZu2Da3bNBBh3bBNG4hGbTEatrFuYA2HHNYMTdRr2bJuixYQ sADBW2Qhjk9DiOMWOwkHJL6yaGQNBzYE/DWA49ymCfwlsYEtkgP/YjSBgG+BHDxnG5vG1rDV EG0atoawbtjKuoEycG/IIb4pGKw/sCC+F/wbAdWKv06iab7D5WhqAyH3SiOaQLSFsIENgWiE 31nTwN1rCNzh7Zu0s23a3q6prX0zFs0xHKxsHVrYOba0c2rp4NzasYO1ExzqLm2dXds4u8Cy tWOHVg5OLewcmkNBm/ZQLeyB+i2t67Zo9VXzlrWbt6jVzKpm0+Y1mzSvIaIZi+aYyKIWRDOr 2lLAsggpA0QNRYhSPE9ziBbQSm2rFrDAo2YzqxrNmldvivFlk2YiGkvB3lbHwAysQqykjlXL r1q0qtsSPhE4rtrwvQSHHz/26ltbY7S2rgeBy23qt2nTANbysG5bnwdseyvrehC4B1p/ZdWy TnOIFhDYSYyWvCHeFmSD/FAKamgIxw/7UBorohF8m/hXoDXkxKOlXstWEHUhWsAB3xKaMARL gbXsIIetYIc3bosq4BsEqyDgi1CvVWuo6quWWBw6hp8XRDPchxhNrWqwYG9b1GRra0NOaBc2 AbsBNeBuweZE8K5a14dVsI1SD6FytuEtodRXLVvXhXZbWUPA/mQLrSERVtVp0Qrqr9Ucgn2U PLA/2CvN4LtU7hKrB6NOi9a1W7SqZdWqZvOWNZq3qN7M6sumVl80aQ7xOURjfIVlSKwO0axF DQhsztC6oQMsRCLsJYgWLetIbfENwW3hC5DYolUdq1bQMawBqsUm2AEJzcFRxw48duzhXoXm YKu/agnF29RvDUeRTUNrmwbWNrAMKXVbWkNtWBXWw8qKoxcPYOkbAd8F7Bv7aNjuFZ8LHlf8 0II68egS0a5xW/Z9x78ktk3b2cE33crOoYU9fschWuE3Hb/sGOwtpjjAMkvBRBGtHDq0tHe2 snWCPxRN2zk0sbFrbGPbqE37hm3aNbCGwA2RgvdE7gC0Dn/nsfVm7eGvBwtbRwgrDCcMO2eI FhD2hrCCsINVTiIFO9yhtZOLtbNr2w7uNi6e7Vy82rt622mMlNQAAP/0SURBVLr52Lr7ytHe zcfGxbttR0/rDu6tnFxbOHRsbufUpL1DYxu7Rhi2jdrawiukNIN27Tu0dHRp7ezWpoOHjYtX O1dvKG7rJtXm5gP1Qys2HT3bOLu3dnSBDkA/oedN2/M9YNeknV3T9vZNbR2a2Tk2x052bOmE FULrbTp6Qp02UIOrTzuoyg365gvL0D1IhxZbO7m1dHCBCpu2d2zU1q6+dbuvWrapbdW6VnM8 kuFAxWO1ecua8DWBAwOOczje4Khr3QYCFuq0tIbE2i1a14KwwuMfAopD1LGyhqjdvDUE1Far WcuaTVvWaNqiRhOr6k3ENx3e8mOythX8jYLDG47nNvVata3fCg5IG1io27LtVy3b1sEuWddq 3rpm81Y1mrWs3rTFl02svoDvlFHw7xp80ZpC4Bfwy2b4XTMEfDGb4/fOKODbCt/KL6EUflWb fd4Iomm1hiwaQDT5TD9g7ecNm0L+LxrhH3z2NYFfE/hbAV8i/HbDt4l9Nw3fdPzJEN9QKAIF m37eECpp8jlU1aBxNRHsLdQsB2TDVkR82ahpdWyuGftKsl8o9pef/WXGv9jwxxb+TuIfZDbG aNoWhp0wtIYRr30L+JG1dWiJ4agIJylAcxyt4OCEowu+XPDHoWWbr+CThSMB/qTAZkIHoD9S DxWdYdvOesL/TrI/kvD3Af/wwq9YA/zFgT8F+Lsv/ejD19ChGRy9NrbYVmtsqy4cPLCv4NiA H27+O964Wc8Bg7bs2180gnnpSLNeevL8uRa27c4TBEEQBEEQBEEQxJsD7HT/8RNFXEpHjeXP idHw0nFzZnIv/YEgCIIgCIIgCIIg3hw1m3IvxWtlIXqMHnf/8eN//+hjhZfOhZglzZe2F+UI giAIgiAIgiAI4k0AXnqg/GQRl9IxeI9fTS9FNSUvJQiCIAiCIAiCIN44NZtZHThxsjt46eiS HmMhxt9//OTfP/7E1Etnk5cSBEEQBEEQBEEQb5yazVqAl4KUFoOUjpvQs2QCeOlf0EurMi+V pJS8lCAIgiAIgiAIgvg9qNWceakkpb3Gl95/8uQvn5h46bgKzuNdlVTFgPXw0z+cHm7N/mWr +MJromoiaZVIlZBaMbT7amB55I10+VUx3mXwHjb4dTetYlS7mFHJ9ow7/kqYVmKm2jfSIkEQ BEEQBEEQfyYKLx0PUtprwqt76e9tDubrMV37yu2+qQ4Dr1oVlFOYt/rdH8Cfu+tMKzFT7Rtp kSAIgiAIgiCIP5NazVvKXorzpcJL/w5eWtXUS63ISyvHq1aFU6OyikIlf6yW/sm7zrQSM9W+ kRYJgiAIgiAIgvgzqc28FO94hF46vuf4CfJ86Wt6qZyiWCWdJKtxHm7FaBmI4azb4erm4FWi 0k2pew4VM3S3wTgBSyUlSWmcSvdBIaZQn2FJuxeGLEZ5Kt0uR1EJx9CcYlM0EuWC6v5VDpPW jTZKVbG8ii2sEmuNyhMEQRAEQRAE8TYjvHQM3oy3J1NTvO+RqZeOZc8vNeulBpgxqIVBtYCL lTcHZROyk4glZiv6zVUOZQ0mTcECTxEoWhEbhVkNSa/YB9wiuRNSg3JtJo3KmeAtwNbJNVQe o27DW6kPuKP5Kr1EtiD351XAmk1Q188WpZbkVVIuQ38IgiAIgiAIgngHqMPP4x2NDy/lanr/ 8WOll86x2EuNTEApDGwBbUFBpb3FpAmVeJk0Z5rfUjRrkJbZVhjq1dgorVKvgNg65Uaq+mAA GpVyoaytMi1YWdTdxuYMnxaswzeaieoevmrz6tYRVbUGsEk5s6oUvDF0jiAIgiAIgiCItxvh pfj8UohxoKbopew5MW/6PF61yVQekyagQpWJqJszzW8pmjWoauN+hBujsVG6pSoJ2zwhmRyp No1G+b7gc4iwnLSKJ4i1lUXdbXVzsM50w0WiuiBmeYX/fzBqHZFS1I0y5MzKUhr5CIIgCIIg CIJ4a/lK9lJJTcFL//3jj03O430D15fCgnGmyqDZhNAPpkCmzb1aa5o1GNcGLbL3kG7UjLlS lYJ7naK8XJtpo6w/ijN4k5L4aa6vhlG3sTmhedgnvqiXqGoWe1XpbhhXokjBRtXrtFYZ+kMQ BEEQBEEQxDvAV1bCS7vzGD323iOFl47DmVKMN+GlXBgkKi0OKB4yokYpzeS+R4qVlWtI6iLW oei5vCy1aKjXeKOUpV6tDxJYs6EqVc2me1KZ2bhgZVFtAmJoTpGukSgVFJsNvMKWm7RubsPl Vbgg327q1fY3QRAEQRAEQRB/CkovLTLnpRVcX0oQfy6mNksQBEEQBEEQxLsB91IupRhGXjp2 DhgpTpaOnTPzxDldL+WTVErEijeHqFeBWPGmEbX/bvVbguiBGrHu90S0pEas+6MQrWohcmhD XkoQBEEQBEEQ7yomXjpO9tJP0Utnz2Ixc8ysGSfOnbWybSfKEcTbBXkpQRAEQRAEQbyr4P14 y08WjTTyUrwfL/fSmVxKR8+cDl7avD15KUEQBEEQBEEQBPEmqd28xYHyE91GjoEQXor34/2k ykefgpc+5UbKo/wseKmNKEcQBEEQBEEQBEEQb4Jazaz2Hz/RbfjobiNGo5qOHmvw0kfPnspS OnrGtPKz35CXEgRBEARBEARBEG+WWk2b7zte3nX4qK6gpiNHF40aI87jRS99+hR0dPTMafA6 avpU7qXnCYIgCIIgCIIgCOLNwb20y7CRXYaPVHjpx+Cl/0AvZVKKIXmp8FmCIAiCIAiCIAiC eBOw83jLu4KUDh9VNHJ099Fj7z96/Be87xG/vnTm9DGzWOD1pcZe+v3334slgiAIgiD+KF6+ fPmdPs+fP3/x4oXIShAEQRDvArXxfrwnuo8aizF6bI8x4+4/Vnjp2FkzeIzG+/F+Y2Vr8FKS UoIgCOIDpO3M/3vNEBW9HqCmz8xCakoQBEG8Q3zV0vrAyVPFY8f3GDuhx7gJPUtK7z9+8pdP /s6fE/N07GzmpbNnjJmFz4mh55cSBEEQHzgglg+//9crxxv00idmATUVWQmCIAjiraeedbtD p7/pOWEKRumUXhOn3n/y9C9//4d4fum4ubNEzJl18vy5FrbtRTnCAs6fPy+WCAVv4W6hT+qt hY6WP4YPYT+/wQrfEi8FHleEyEcQBEEQbz0N2jkcPnuhz7S5vafNYTH3wdNn//FpVfDSqo+/ e1YybzYPUFP0UjtbUU7BkYNHIMQbBZFRUZqRnJJy8eJFken3xKjdCkMUU3D48OHNW7aYjwsX LojcJugNg/bv3y+WdKgwg8ziJUtMY8OGDc+fPxc59DEqxUOs+z15J0bARsdGhSGKKTDKUGGI YoSaVztabt68KZZ+B97CA/j1eSe+la/Jq1U4ceIksaTg7fHSRxUh8hEEQRDEW09je5ej578d MOdriP4sHjx7/h9VP6/y8WfopePnz+EBanrywrkW9rpe+n//Z/xDazTsVoaFairnL504USRV Brl4uVnkbKKYAtDOZcuWX758+Tctjh47tnXbtosXL/3444+igBq9YRDonxmbhVWW+6Hsk0Zh Rk2V2Y4cOQIjeA4sK1eJ3Prcu3dv+YoVmhsCXm2mA+/ECLjCw0aJ5sHz+jUQQGWPllmzZsHO hMjJzd1n8f/vVIrf6QAOC4+AEG/+cN6Jb6US+JO1Zs2afhIjRo7cunWr+enBV9vGqOgYUzVV eik/3iyMN+6lDytC5CMIgiCIt56mzp7HLl4bsnDNIBYDF65+8N2L/6z2JXrpk++eTZg/l0fJ vDknL5xv6WAnyqkBKdXzUjHuloCRIk+3RE15Th6voKZyWfFeBzPZwEvBPLl/wuspLWAVBEia KKNAbxgE1gdGp1mEy54lWsjhDsnFklN+4gRP3LVrl8ikhq/lAQM7kfrDD7CsXCVSdZD7CWGk piClPF1PTS0ZHUJx8Ar5o4FlSBHrKgL2gHJbYBlSxDodTLukeTzooZn59WsggEq5BPyVgD2p DE01NcpTYYhiEqZd6lZUBNngVbx/JY6Xl5OXKjHTJVBQ+AVRfkY84A+FmZ+VV9tG8FJTNTXy 0gPlZy0JyGnqpXLnNUNk0udBRYh8BEEQBPHW08zF5/i3N4Z+vWEIi8Ffb3j4/OV/fl6De+l3 ExbMm7Bw3vgF80oWzD118YKel2qi97Mq/+JWqKZyzgpDFFBjfq2MmWzcS3mAYol5UjXcTjX/ n15vGMStyVTb4C0kcpUSSSbIuqUMsU5CNkPN84HlUuZD5NYCNlaWUh6ymspN84DN4elKNHeL /P8OUDkf5ZsGpJufD5F3oGko97bpbjHtEjQnlixAM7Nmovz/MkZrNTO/WfD/LMrLxRsGvIVE 8eZtxXKXkKUUFmA/c28BURGrFfBslocoJqF5tMg54RDVVCY5YC0vZYrSS/n0qWaIHG8US/bz mTNnyk+cgND8P7U3jl6XQErlPQmfNf+Cjxg5Uk7U+1kxv43cP82EUk2NvFReVsa6rbvhderM eX36DeTLck4jL2X/Z6sBrBKZ9IHPwjwiH0EQBEG89TR38Tt++eawpZuGSvHw+fd/lb20dOE8 VFMWzEvtRTkF5q8vFW8U8HQeZoZor4/cinivg5lsspeCeZqfNV22bPmiRYtFMQm9YRDIAB9L GQmSLHVmbIFnMAqjdHgrV8UKqeDp0IQeegWVGPknBKipaaLRBnI0dwvsf66mspTCQBPsAgZn 8CoPOs1PSclSumvXritXrsC2wCss80QuybyTPL+MaZegLb7AR4dGAf1RGjKkiCUFmonyWab9 +vUTSQzNzEpgLA5F4PvCJwCh9TXsJEZIgc3kecwgexrUw1P44F6u0Ax4lmS/frwg7wbAV0E3 +EdjukuV8CKmNcjFIYx2qYx5l1DC94PsJLBdvGb+VglPZyN/PLrgwMNJdS00azDtEj9o+cEJ W8F3tV7AWl7KlN/JOS2hwv38/Plz/j2C0Pxev3E0uwSfL9+NsLeNjnz4vPiez8nNfYVjychC TcO8lx4oP8vfnrxwHV637z82rnQKXwsBasqXeR4jLxVL+vC/jZrcrQiRjyAIgiDeepq7+B7/ 9sbwrzcMXbJhCAvw0v+sVl2eL50PUbpw/vgF89FLHXW9VO88XvFGAR/wmRk1cvhay0MUU2Bm lRIz2ZReCq9gnnfv3RPzpGpgleVeCsiyJM80wgJP0Tv/lsPzwICMw9+KdWr0VpkpwqkwA8fU Qo1Cb/CquVv4RyBLKXcYJZDCV0HNIkmNfAKz0XnFgLxvZXEVKyRMuwQN8QU4Vnm7RgGGyTMA 8FYsKdBM1MN8ZhiV8kYhoPMw5pZ3FITpvjICivCcMGqXtQ0WZH0y3SFKlHnkqmBZ/kTktXoo 8yhrkHWO94TLqhHmXQKAvSHvH+VpnHIif6tEmS6LsVwQkF1dmVOmwi69i1S4UfKXCGL5ihUi tTLAJ1WpGVfNLvGPFQ4Y2TzhE+SHFiB/WzW/FOa3kctnefkJozCVUsDUS4eMGD138fIbj77P zs2Dhakz54GaQjoYKWQwP18qlvSBPHpqeqciRD6CIAiCeOtp6ux5/OK1oQvXDFkAsXrw/NUP v3vxn5/h9aWfsfnSBRMWzi9dNB9emZc6iHJqzFxfKt5oYT6DcuRdYUBmUUyBvFa818FMtt/P S2FQxU+FhVd+tpX81ujkXiP4uFC8UbzlC3IoVxmhly5TYQYZM2pqZkZFc7fInwIEDDRFqhqu EJpnZgL87Gg9q5f/I4CHSJUw7RI0xBfkkS6MC2EZWuFvlRIlZ1Zimnjz5k1eFkJpQYBmDRyl GMNoG44cuQ8wOjc/2wmZoZ88M3xHjBqFt/K3DLLJA30jeAa+0+CVv+XL8InAxyGv1UOzBtgb 0H/+acrbyLKrMO8S0GejPxS8QllKlf99IMNX8WXefwjoA0/hnYHuwbIyp4z5Lr0yr3maLu+q 5SGKSVS4UfwbxL9lEFeuXBErLEOptTyOHNE4y0aJZpf4f2FAN8R7NhsPtYk30l8Jzb8h5reR +6d4o8BUSgEjL71w42GXomIIbqd8ma/l86j8FXLyRPNeCkcgHMCmv4Caanq7IkQ+giAIgnjr YffjvTxoztKBs5cOmPU1BN6P99NqVT5hXgo6OmER81J+Hq/WfKke/KdUvNHCfAZ5ZGlJaP5g y2vFex3MZPv9vBRQTuLxeTyQUtO5PiN4EXlBfmuK3iqjdP7WNGDkZ8mchqaampFSQHO3yJ8C hN4EoPk5dt603nDZaFgsUiVMuyS3IisTH/7yUS+EspNyZiWmibJPmqq1Zg0caJSXgg5AZ5Sq CYc9TxFZTZClC7qtmQ0S5S0y7RVHXgvtyhWKdcwK4K3pLlVipgauf/zLrtkBM18ipZRCDXB4 QA0g2/KfDs0/CwBfy5fhc4ReKfcP3yGQCMvKnDKmXeLdgFfx/pU4Xl4+fsKE1/FSOBgsxJKN MoL/x5n8PTJ/WocpkB9qgD908InLcivW6WDmDwVsgnjPPi/+ufO3UC1k4B+fEea3Uc9LTaUU MPLSkxeur9u6G165joKF8pN4+VqjVwg9L4WDkH+h9ML0kL5VESIfQRAEQbz1NGzncOTshf7T 5kL0mzoH4sHTZ3/5e1Xmpc+/K128EAPUdOH802bP4xVvFPDfUfGm8sB4Uf4xrjA0TcYoT4Uh iin4/bwUhncwUINu89EeBIzVIAWMzryayuM5GN4B8lu+IIcypxFG6bDMqzICRpDQN1gQ+XTQ 9FLzm2BmuMkjWefOJXw8DSHeq+FNa3ZYno6WQ6yQMO2S3IrcqDJgHKxsCFLEkgLTRFmiTCfx NGvgyN7IA/pjNHJVjtGNsCSPcgNFkhp5rTLEusp4qVHwVbIY633oel8iIykVqYr/z9KTUoBn EG8k4AOFOuGVr+UZNHNqHi1yTqiEz+npBazlpYzYsmULSCmoKX8rT5+aBs9ghFErFYYoJmHm jxVw5coV/sV5/vw5nzjly2K1ZUAl5SdOKP/oiRU6mPlDoTye+ZEAe5X/CkC1kOENeqkmRl4K ImoUoKlGKRCQ04yXwobI/2ujF6b/93G9IkQ+giAIgnjrqd+m/eEzZ/tOnN63dBp/ffDk6V8+ +Yfw0okopQu4l5q/79EbP48XBqk8gyWhOaI1ylNhiGIKfg8vhcEcnx01E2bmG3kGeUF+a4re KqN0vswT5YAU6Cd3TpZLG00p5WFGTc0MN+WAUaapYb7afCmM9oykFEKskzDtktyKrG0w0oWC ysdj8gyAnFmJUSJ0gxeEMLVEzRo4phZquZfCKtmRNP/vBhL5WsimVw/PAJoHGWTrE+sq46Wm NcBbPhCH0bbmVxjQPFq4isjVwlZAPXB4yJXDgsiqBc8j3jD4xwp1Kv8XANLlBSWmXeKd4c4A fZP3uWbAWl7KCPPaWSFGrVQYopiE5n6WMXq4MQ/z//1khPy3ArT29edLTQ9m/tHLC3+wl1oe ZryU9xwOD+i8jNJU4QCDo4tnlrlcESIfQRAEQbz11GvV5vCpM33GT+rNAhbuP37yl4//Ls2X opSyWLjg9MWLml4K/B7XlwLmh3dy6I3zjLJVGKKYAlMv3bBhI08xCsu9lI/P+PlsRl4Hgz/Q Km6tehdf8ZywAMUB+a0pequM0vWKc8ysNSOlPPSGreZHh2bgzqAUQiV8sAujXvG+Mph2ST4e wJ344QGVw1ulEfEMgHJZxihRaYAiSYFmDRwYm/KCPKA/pikiqxbge/LQ1mieVunYeloI8Dx8 8+GVv4Vl2CJ4yyuHLsGyXk80a1D+xxMOwBk8vxLNo0XuOQzlTT3QvJQCPBssQFloVP5AjUKZ U8krH8BvM+Y3SjZJZZjKoR737t3jReCPG7yV/2OOr9VDs0v8jwD/LwBT4E8iPxigwyJJgflt fGUv1Qx+5BglyqHppfBV0tulfJNNpRSAjTKPyEcQBEEQbz11W7Y+fOp0n5JSOZiXflLlk2ps vnTJwomLIVBN8TzeN/H8UoCvUoZYoQaGjEbZNENzOAsYZYNBsxFGGUQxBaZeaj5EMQnTMQEM LGA0BmOm5ww+2uP3qOSDNp7O5/dEGTWQzlfxhQqDl1JilM6XeaJRyGtNMZVSSDFN1FTTVxsq yV4H1YokNWbux1shpl2SjwfT44SHUi/hrVhSYJQoT8RpWpNmDRyjbwH0xzRFZNVB6dLywFfe n3rjXRmeje92eOVvYdn066n30SjXyjVo7lieX4nm0cIzy3vSjHtrwnPCgp6R8lDmVPI7jfVf c770NTGzUbJVyseJfCqv+SNHhv/d4yFLKYRYrYNml+STJky/R/JxDt9NzY5pVjhx4iRupMrQ vKZUiXkvPXnhOu8kf2aMaZh6KXTYjOeb+ZLCz4d5RD6CIAiCeOup26IVeGnf8aV9x0/sO2Fi vwkTHzx58pdPhJc+n7RkEQSezbuYz5dqeOkrXF/KVylDrFADAxejbJqhN74xyian8LWAvMoo XQYM58LFi6vXrFF66YYNG+/euyfHgQMHLfdSPsMJBgXL3OLk+T0YlMBbPk3Kz5qDzHyVEkiH gAWcLZXmS80EL6XEKAOEWKGF5loYIRmdGQvbwlcZqSlk4+lKXm1Yzy0IxmfivRZ8yGtmeKeH aZfk40FTn2DgC+NjngGAFLGkwChRLqssKKNZAwdEC7ZdBhzMNEVk1Qc+MhjHQ7dliYUFeAuJ euNdGcgJ8KMRXvlbWIZ2+bIMz2OKcq1cA7TLF5Tw/Eo0v0RGe5LvgQo3RIYXF2/MopnTtEtc h8wfnBVyvLwc4i300itXrsB3SnkmAk8BTE+b1wP+lPI/GlAKZIkXf272ClW9LsFByz8X2OFQ CT9y1qxZA8czT4dEkVWNXoVGalqhlAJmvHTd1t28Gzz4E2KMQnO+1BQzq2T45gP8h1gOkVrR f1oRBEEQxNtD3ZbWh0+d6Tthct/Syf0mTuk/aeqDJ0//4xPpPF4upewqU3bfI30vrdR5vPz3 kmfgy2KFGjmP+dArbpRNTuFrAXmVUboRIJxKL4UFGAHDK7+yFFbxdAhRQEJzSA0jMxjhwSgN FvjEKV8lT5PyMR8saI6zIR1CvJHslMNXiTcSIp8Cnk0ZmokQPJ0VMkZ5JyFZSjmymkIGzTv6 mhkBmwHcA+o07x6wDy18NKIRpl2SjwdL9Enz4DFzRJlSqcwfFJpHC58d5f87IFuK6QSaHjy/ 5SGKSWgeLXJOOGBkQdIMWMtLmaKcL+XLmsEzvFle7Vv5u2KmS/KHbhp6UgqYqVBWU0ukFNDz 0nGlU7Jz8w6wp8JAwAK8le/NK4eRl5oJkUmfwwr4BTUyPFHkIwiCIIi3nnqtbQ6fOTtg0owB k2cMmDJz4LRZD58++4+/f8qeX8q8dBKeyivO421hbyvKqeG/guKNhNHvq1HIGXjm3wO5Lb2G lGvNDGpvsBt1Llu2XPZS8B/Q0VfwUlk+eRh5IxipvIpfiGWKnEEvRD59uK/KmC9iZi1XUyMp 5UCinpQC78QIWPOA0UMz8+vXQACaR8vFixeN3M9yKQWUBS0JUUzCtEvK+dJX9tLfVTsr5J34 ViopLy9X3qQK9iocA+bPHTBfIRiphVIKaHopf37pjUffKxPhLSTKjzPlofTS12RfRYh8BEEQ BPHWU7+t3dGzFwZOnzdoxrzBMxcMnrXg4bPv/vPTz8BLq6KXLl7Iw7yXaiKPGDRDZPo9MWrR TFgyqJXlk5/WKyPPo5pe1qg5DAJbA23btWuXpraBKMIqyCDPoxoh+6deiHwWY1TcNEQ+LczM XppZ9U6MgI2OkApDFFNglKHCEMUINXpHCxhIpa4pfYO8hQfw6/NOfCtfkzdYod58qYXxBr10 BwN+NQ7uPyifxAvLkMJXiXwEQRAE8dbT0Nb52Plvh8xZOnTusqHzlg2bv/zRdy/+s+rnVT6u il46cRG/79HCicxLrewq4aXEezl+fX0+hBEw8aago+WP4UPYz2+wwrfHS7dIHDt67PjR4yCl J46f+PWXX58/f37s2DFIF/kIgiAI4q2nsYN7+aVrIxavxVhSNmLJukfPX/61WnXw0k+ffIfP LwUjZYHXl1rZkpcSBEEQHzRvj5euV7Bn955vTn0DUvrbb7/t3r2bJ4p8BEEQBPHW07SDz4nL t0Yt3zJq2WZ8XbH10Ysf/vp5zSofMS+dtGiBHOClzW3bi3IEQRAE8UECYvmaISp6PR48eLBa zfbt21++fAmv/O22bdtEVoIgCIJ462nm4n/yyu2xK3eM4bFqx2Pw0i9qVfnoU/TS0gXzJi6Y P3Hh/NIFOF9KXkoQBEEQbwOXLl1aZpaDBw+KrARBEATx1tPcxf/U1TvjVu4Yt3L7WAjupThf yr10oZBSEFTyUoIgCIL403nx4sWFCxe+/vrrRTosXbp03759kE0UIAiCIIi3nuYdfU9euTV2 xdaxy7aMXY6BXlqtBnjpP/D60oXzWNB8KUEQBEEQBEEQBPG70MzZ6+TlG2OXbBizZP3oJetG L1n/6PnL/6z6pfDSyYsWgJRiLJh3hnnpeYIgCIIgCIIgCIJ4czR1cD156erohatGzV85ct6K kfNXPvruxX/8oxp66dPn4KULpyxaOHkhxpmLF63MzpeOIixD7C+CIAiCIAiCIAjihx8at3c6 eeHy6Llfj5y9eMTsxcNnL3707Plf/l4Vry8FL526ZNHUxQshwE7PXKrYS6vMPElhPshLCYIg CIIgCIIglDRsa3vi/MURMxeMmDFv2LR5w6fPe/j0u3//+B/cS59P+3oxxhKMby5dbGH2+aXk pZYEeSlBEARBEARBEISS+q1tys+eHz59ztCps4ZOwXj49Nm/f/SJ8NLpS5dgfI1x9ttLLewq 8NK0fbcozAd5KUEQBEEQBEEQhJJ6La3BS4dNmzl08oyhUzDAS//tbx9X+bjqp8+eP5+1bOnM ZV+zWHru8rctK/LS/yMqgryUIAiCIAiCIAhCSd0Wrcu/OTd86sxhk6cPnTx92NSZD58+lbz0 xfPZK5ZhLF8Ggopeak9e+rqQlxIEQRAEQRAEQSj5yqpV+Vnw0hnDp8zA16kzHuF86UfCS+es WM69FOLc5cvkpa8PeSlBEARBEARBEISSr6xagpeOnDZrxNSZI6ZhgJf++0divvQFeCmLZXOW LzsPXkrn8f7f//3v//4vbOzTp08fPXr08OHD+/fv37t3786dO7dv37558+b169dv3LgBif/9 3/8tCqghLyUIgiAIgiAIglCC86Xnzo+cMZvFnFEz5zx6xr3000+/e/Fi3srlc1csgxBeWtFz YoR7vdfAlv7444//w/jXv/7122+//fOf//z1119//vnnn376CdZ+//334KW3bt0SBdSQlxIE QRAEQRAEQSip29L65PkLY2bP4zF2zvzHz777948/MXiprKbgpS1s24lyWnwgXvr06dP/j2HG S1++fHnhwgVRQA15KUEQBEEQBEEQhJK6rdqevHBp3LzF4+YtKpm/GOLxd8//8snfwUv/gV66 AqV0zvKlEOClVu3/AC+9lNdmziTNuca96/6muQrTR/HI2yvSXgn9phU8evTof//3f8FLp64+ PmDWnpc//My99LsXPwyes2fArF3cS8+fPy8KqCEvJQiCIAiCIAji7efu/aflZ24eOXHdTECG m7cfv1p+JfXatD916XLJouUli5bB6/jFyx8/f/GXv/9DeOn8VcuZmi7n5/FatbcR5bT4Pb30 6aTYUX8bsE7TG6/deiqWUFDXbRNvXgGLvPThw4fcS3tM2e7bdXG3iVtffP/T85c/di3dAm+z Rq3nXnr27FlRQA15KUEQBEEQBEEQbz/gkC9evHxRAS+PnbrxavmV1G/nePrytdJla0qXr52w HF+fvHj5l39UZefxvgQvXTl/5Qp+Ku+FK5eb/2leyqnQGyHDm/RS0Muhffta1a7dq6Dg2bNn PPH+/fvcS5+9/ClzxHquphCwkDF83Z0HT7iXnjlzhuc3gryUIAiCIAiCIIi3nyMnroMEVQhk e7X8ShrYu5y5enPSms2T1myZyF6fvPz+L1U/x/vxPn/5YuHq1QtXr1ywauWClStew0uZ7+09 6Cydantt/hx+2q3zfGmq85ZY6zz/4Ct7KVY74JJ4I3itpkFKY/7f//d8lSpd/p//Jycmhife u3ePe+n//M//PHn+A1dTLqX3Hj2D/cC99PTp0zy/EeSlBEEQBEEQBEG8/YBAPtHi9p27Yomh 9FKRxLh2/YZYUqPppQ2dvc/cuDtlw57JUjz5/se/fFa9yidVqz5/+XJx2drFa1cvXLt6weqV F69eeQ0vHfW32IPXYJFdCyqc0HDaLWbgl4Yyb6ysl7KzfKEJYykFXqvpJtWrf1ulyv9VqfJT lSp//bd/44l37tyRvfSHn37lM6UQXUu3PHv+PewH7qUnT57k+Y0gLyUIgiAIgiAI4u0HBPKh CRe/vTx/6VrxhqH0UpHEmLN41ZmzF8QbBdpe6hp49tbDKVuPyPH0h5//8nmtKp98VvX59y+/ Xr9uyfoysNNFa9dcvHa1+Sve90jpk1rLtw46c3U0SmTTmIpLRpVltdC4vvSVmpboHh/f5d/+ DaR07F/+EuPpyRNv377NvfSnX34rmrQNjDRzxHo+awpq+uTZC+6l5eXlPL8R5KUEQRAEQRAE Qbz9gEDeU3O0/BTY5swFK8R7htJLRRIDskHmvQeOivcS2l7qEXb2zpNpu05P3XVy6q5TEE9/ /OUvX9YBL/0MBGv5po1LN6xHO1239tK1a3+ol2pgZhXHNINWc8pls00/evQoIyLir//2bzFe XvLzSG/evMm9dNj8/VxKHz17+fDpi4zh6+Bt0cQt3EuPHz/O8xtBXkoQBEEQBEEQxNsPCORt BRu37eFSCiGSGEovFUkMnnPe12vWbNwOMiVSFfmVNPSOPnfv2fR95yGmstenP/76l+p1q3xS 7bMXP3y/YvOmZRs3LN2Iaope+orPL61IDnHhFc7jNXrL5kuFZCprlvNoLsOCJU0buH79OvfS AbP2ZI/e8Pi77/lzYu4//q7TuE05o8X9eI8ePSoKqCEvJQiCIAiCIAji7QcE8obEtWvXVq/f CpLJbVOkMpReKpIYPOeCZWuXrdl09eo1karIr6Shb9zZ+89nHPh2mhRPf/rnv1evX+Xv6KU/ rNy6ZcWWzcs3bwI1/fb67+el4uJPdv2n5n2PpCtIeajkU7nK9Izf12/aGPBSkFLgf/7nf/71 r3/99ttv3Et//vnnn376CfYDeOmLFy8OHz4sCqghLyUIgiAIgiAI4u0HBPKqmu27989mU6bi PUPppSKJAdkg8/otO69cuSKSGJpe2sA3/tyDFzMOXeEx/dAV9NIa6KXVwEtXb98Karp88+Zl mzZ+e+P6q3rpe8X9+/efPXsGUqrnpS9fvrxz5w7dj5cgCIIgCIIgiHcXEMhvTTh45PjsRavE G4bSS0USY+bCFbv3HxJvFGh7qV8CeOnMI9dmHr468/A1WHj282//XqMBeunLH35Ys2P7KlRT nDK9fPMGeSnw3//937du3bpw4cL58+fPnj175swZUNCTJ0+Wl5cfP3786NGjhw8fhhQwVVFA DXkpQRAEQRAEQRBvPyCQF7U4fuKkWGIovVQkMQ4fPS6W1Gh7qX/i+YcvZx+9zuIaBHjpX4SX /vjD2p07uJqu2rqZvPSNQF5KEARBEARBEMTbDwjkOQtQeqlIMouel1549HLe8Rtzj92YB3H8 xnfgpTUb4H2PXv7447rdO8t2bl+zY9vqbVuv3LppZdtelNOCvNQSyEsJgiAIgiAIgnj7OX76 BmjkGbNAhqMnb7xafiUN/RMuPnq5sPzGgvIb8Lqw/OZ3v/z2H9xLv+deumsHqun2rVdv3SIv fX3ISwmCIAiCIAiCePu5efvxsVN4+1wzAZJ59cbDV8uvpJFf/KXHLxefuMFjyYmbz4WXfoZe umH3rvVsyhTi2m3y0jcAeSlBEARBEARBEISSxn5x3z56ufTEja/Lbyw7ifHil9/+k3lpVfDS jXt3bdi9E2L9rh3X7txuYWfspT8qIC+1BNhLYn8RBEEQBEEQBEF8kAiflGjiE3P50YsVJ66t PHENXledvAZe+tca9at8UhW9dPPe3Zv27t64Z9fG3Ttv3Llj6qXHFJCXWgLsJbG/CIIgCIIg CIIgPkiET0o08Yq4+uj56vLLEGsgTlx++cs//1q9bpWPq376/U8/btm3Z/NeiN2b9uy+cfdO C5PzeFesWCF8iyAIgiDeF36uJPBreP78+e8VwFv6iSQIgiAITeAnUvikRBP34GsPn605dgGi DOL4xZc///OvX9ZGL/3hpx+37d+3dd/eLfv2gp3evHuXvJQgCIL4EBC6aTHkpQRBEARhORpe 6uJ77cGTssNnMI6cWX/0m5c///rXz2tyL/1p+4H9W5mabt6HXmp63yP60SUIgiDeP4RuWgx5 KUEQBEFYjoaXOrlfv/9o3cHydQfK4XX9wfLvf/rlr599Kbx0x8EDoKY4a7p/36174KXtRDkJ +tElCIIg3j+EbloMeSlBEARBWI6plza273D93oP1+49AbIA4cPT7n37+z6rV0Et//OmnnYcP 7Th0EO304IFb9+41b09eShAEQbz/CN20GPJSgiAIgrAcDS9t73Dj3oMN+w5BbNx/aNOBw+il n1YFL636488/7zl6ZNeRQ2CnOw8dvH3/PnkpQRAE8SEgdNNiyEsJgiAIwnJMvbSRje3Ne/c3 7T+4mcWWg+ClP/3nPz7F55eCl+49dhTUdPfRw2Cndx48IC8lCIIgPgSEbqp58eLF4sWLHz9+ LN4rIC8lCIIgCMvR8NK27W7du79l/8GtBw9hHDr8w08/Cy/96Zef9x8/vu/4MbDT3UeP3CUv JQiCID4MhG4q+PHHH2fPnt2zZ8/58+fDz59IlSAvJQiCIAjL0fJSm1v3H2w7eGj74cM7Dh+B gN9a7qWf/fTLLwdPnjhwonx/Odrp3YcP32cv3VW8IXDWD+LNG+TGt4H1fp+aCYIgiN8LoZsS z549W7p0KUjp8OHDly1bdvHiRdBUsY5BXkoQBEEQlqPlpe3uPHiw88jRXUeP7T52HAJ+aP/6 KZsv/fmXXw6fOnno5ImDJ8oPlB+/9+hhc4vvx/vDrMDyXfAvWhlbMMf94nob6imiuKICrMie WTfEmzfC63mpfn/ISwmCIN49hG5KlJWVyVK6d+/eEydO3Lx5U6xjkJcSBEEQhOVoeGk727sP H+0+Xr6n/MTeEyf3njj14y+//LXqZ8JLj5w+JanpifuPH1n+/FLwNMlLA7+1zB8rpZrvjpcS BEEQ7x5CNy2GvJQgCIIgLMfUSxvbOt59/GTfydP7Tp3Zf/qbA6fP/vTLr3/7rFqVT6pW/fnX X46dOX309Clupw8eP7bIS0HwlJOfLCxxNhO143Otu8pFJcJvf5gVqKwZQ5pfhVVQg5xBURub tBT5i++LRAQaldLlWU31HK+Rryq2jtdvvj9GKRKa/dHeXoIgCOKPR+imxZCXEgRBEITlmHpp UweX+0+fHfzmwsGzFw+dg7j006///Fu1L/H5pT//+uvxb84cO8Pj9MMnlnkpAorFtOrGrD1q DzSDppeqdFRhd5rzk8IDuUZi07ws1iNnxjySZ6KUynUa/JP7IUsElF6KUqqti5r94Rj1XL8/ 5raXIAiC+CMRumkx5KUEQRAEYTmmXtqso9eDZy8OX7hy5OLVo5euHbt07ed//vbRFzWqfPwp emn5N9+AmnI7ffjkicVeuquc6yjIoSx1FaHppXrzlrpeasgDfdB0YyndsMCwwEvNyGclvFS3 P+a2lyAIgvgjEbppMeSlBEEQBGE5pl5q5R748Pn3Ry/fOnYF4vbxK7d//u2/Pqpeu8pHn376 y6+/njx37gTG2RNnzz56+tSqfcVeCoYmnaEqh0VTpm/GS03nGI0FT6rWyA8r9lJ1uppKeKle f8xuL0EQBPFHInTTYshLCYIgCMJyTL20pXf445c/nrhx/+SNBxCnbj785bd/fVyjLnjpP7iX MjU9C8G81LL78UrTpJU6GfX38lK9+Ul1OpbV9E+1l+rJZyW8lOZLCYIg3nqEbloMeSlBEARB WI6Gl/rFPP7+55O3Hp269fjU7cenbz/+5b/++5Na9YWXnjp/7uT5c/z18dOnlj6/VHIqUDI9 WzOlUl6q0EgD2l6q9kloRcMzofJ6hqe5YB5eDzqkIR3r15n71ewPx6RX5vpDXkoQBPE2IHTT YshLCYIgCMJyTL20VUD84x9+OX3nKcSZu8++ufvsV/DS2g2Zl/7zn6cvnD994QK8nrpw/vGz Z5XwUmZiZmYRlaCbGU76le9FZN7TcK06v56XArvK5cqVlXDt5InK+uV0sFBYVhRhaiqqMrVo sUrRfzmzIh3Q7A95KUEQxNuC0E2LIS8lCIIgCMsx9dKWQUlPfvj1zN3vvrn3/CzE/ee//uu/ P6nTCO979Os//3n20qVvLl2EOHPxwpNnzyw9j5cgCIIg3mWEbloMeSlBEARBWI6WlyY//fHX s/dfnHuAcf7By1//9T+f1GksvPTct9+e/fYSj6fffdfC0vvxEgRBEMQ7jNBNiyEvJQiCIAjL MfXSFuil/+RGev4hhuSlVdFLz1+5jHH58rnL3z57/ryFHXkpQRAE8f4jdNNiyEsJgiAIwnJM vdQqKPnZT+ilFx6+vPDw+4sPv/8n99JPqlb952+/Xbx65QKPK5efvXje0t5WlJOgH12CIAji /UPopsWQlxIEQRCE5eh5KUgpGOnFR99feiR76WfopZeuXb3IAtT02YsXrRzISwmCIIj3H6Gb FkNeShAEQRCWY+qlzQOTZC8FKTV46d8/+wy89Nvr17+9fu0SxLWr36GX2olyEvSjSxAEQbx/ CN20GPJSgiAIgrAcPS+9+PDlpUcQ339r8NJqzEtvXIfgU6ZsvpS8lCAIgnj/EbppMeSlBEEQ BGE5pl5qFZAoeen38AqBXlq7EXrpL7/+evri+VMXzp08f+7EubOPnj0lLyUIgiA+BIRuWgx5 KUEQBEFYjpaXJjz8/pfyW09PQNzG+OW//vuT2g3RS598913pgnkT5s0pmTu7ZM4ssFPyUoIg COJDQOimxZCXEgRBEITlmHppC//YEzcfj9p8csyWU2O3nhq39fSTH375pFYD9NLbD+5n9uuT 1rtnaq8eKT26bz9woJWDvSgnQT+6BEEQxPuH0E2LIS8lCIIgCMvR8FLfyC1nrsVNXhc/dV3C 1PXJ0zfcevr9xzXrgZdWu33/fkqvXsk9eiZ2L44vKtqyf38rBwdRToJ+dAmCIIj3D6GbFkNe ShAEQRCWo+GlniGbTlyMGL0wcvSi6DGLYsYtufn4+cfV66CX3rr/ILlX36QefRKKe8V177nl wMFWjs6inAT96BIEQRDvH0I3LYa8lCAIgiAsx9RLrVz9Nh45EzpwctigyeGDp0QMmXrj4dOP vqhZ5ZNqn9+6/zCp96CEXgPjew6I69F/y4HDrZ1dRDkJ+tElCIIg3j+EbloMeSlBEARBWI6p lzZ39lh/4Hhgj+GBPUYE9RwR3Gvk9fuP/lbtyyqffP7lrQePEvoOh4jvMyyu9/Ath4637uAu yknQjy5BEATx/iF002LISwmCIAjCcky9tKlDx7K9h3wLekP4de7j17nvtXsP/lb18yqffFH9 1oPHCQNL4geWxA0YF9t/3JYjJ1u7+ohyEvSjSxAEQbx/CN20GPJSi7m7NqeKRM7auyL1z8PQ n7ehNwRBEB8Ipl7axNZpza59HtldPbO7eecUeecVXbtz76+fflblky9r3nz4NH7o1LghU2IH T4bYcvSMtbu/KCdBP7oEQRDE+4fQTYshL7WYt8tLlb0hMyUIgvjDMPXSxraOq3fuc8vs7JbV 2T2ri1d216uSl9a++ehZ3IiZELHDZ8YMnbHl+Dlrj0BRToJ+dAmCIIj3D6GbFvO7eanKm0rL ReorUV4qqvlz9euP91JzG6720tfcwwRBEISlaHmp8+pdB9yyiyDcc4o8coqYl1ar8kl19NL4 kXPiRsyOHT4LgnlpkCgnQV5KEARBvH8I3bQY8lKLebu8VNmfP3W3EARBfFiYemkTB9c1ew97 FPRzL+gLr56d+1+9++Cvn31R5e/CS2fHDZ8VN3xG7LDpW45/Y+0RIMpJkJcSBEEQ7x9CNy3m HfBSRU0flpe+LRtOEARBGDD10qYdvNceOOFZPMqrB4Z3z9FX7z/6a7Xq4KW1bj16Gj98WvzQ yXFDJsUOmrjl6Glrd19RToK8lCAIgnj/ELppMe+AlxpmDT8wL31bNpwgCIIwYOqlzdwCy46c 9RkwzXcght+g6dcePv3bF7Wq/P3LmrcePkkYPD5h0Lj4gWNi+43ccrjc2sVLlJMgLyUIgiDe P4RuWswf7aWKZJGosC9AabCqKoyQRc2QSSQpShnZnHF9FdiyqmOQV1lcUbMym6pB3RUy6k03 5KrkhgOam2LZ9ipyiQz6nwhBEARh6qXNvcLWlV/yG7E4cNTiwNFLAkYvufbo+UfVvwIvrXHr waPE/iMS+g6L6z04tufALQcOW3dwFeUkyEsJgiCI9w+hmxbzp3qpsZdx5MzGXqVES8+goJ5S 6VelaYzmWmYoSunqp+4KwEwD0OnKbrhySzmV2F5F1go/EYIgCMLUS618o9aduho4fjVEUOna 4NI115+8/KhmvSr/+OLLWw8eJvYeENejT2z3XjFFPTbvO9DayVmUkyAvJQiCIN4/hG5azJ/o pbpI6mQur7aeqbGkHsRYu7TlTIXC7irvpRV2ufIbrtqEym1vRbkRVfcJgiA+aDS81C923Zkb QZM2Bk/eGDJlU8jUzdeffv9xrQZV/vH5F7fu348v7hHXrSimS5fIwsJNe/a0crAX5STISwmC IIj3D6GbFvNne6lkPKp0lQaZm3YEzGgVb1WdQeqJdiqiXiO3qJZVRUcq66VGHTY0XV6q7Ebl NlxR8vW219CUKl2jfYIgiA8TDS/1j1t35mbAlC3B07ZChEzbev3pD9xLP7917158t66xnQsj O+WH5WZv3LWzpa2tKCfxTnjp/eJ6e2bdEG/02FW8IXDWD+LNO82NbwPrle8Sb956sLeV2fOV zf9H8aaOH+N63pf9QxDvGkI3LeZP9VKl7ejkr5yeAcqiiMondX3MULFuP1RrFB2ppJeq+qOx PQYqs+GGjlZ2e3XTzewJgiCIDxhTL23uH1d25qb/lC2B07YFTYfYDl76Ue2GwkvjuhRGdcoL z8kMyUjbsGN7i/Y2opyE3o/uD7MCmRoZO5Jeuha7yusZfBIKbqgX+G1FdqnJ2+al0J8N9RRR /BoSeWPWHqjBxGTelJdatOsYpjnxI6t407Q9Sr/dt9W7LDh+2DFs+Ny1N9AyL3339g9BvGsI 3bSYP9VLdbVJueLV9EzCzGrNVapEdXPKVYo1uv3TXFFBd5W80oabqV9nlW6JSnSVIAjiw8HU S5sxL/WZvBnU1H/atoBp266Bl+J8abVqN+/djS3sFJmfE5qVHpSWvG77NiubtqKchN6PLoyb Jf9UyaReugZgXIGBe8QIG/PD2/fDSzkW9aoiQHX2zNql3ploJn+8l5paqGVeqs0b2Tl/KBZ6 aYU7xLLj8N3bPwTxriF002Ledy81V1prnZnqlKsUVem2oLlCmajRXSXmug5o99RcIe11ultc wZ4lCIL4MDH10qZ+sWtO3/CauNFn8ibfKVv8pmy59vR7g5dGF/DJ0tSA1MR127c2t7EW5SQ0 fnRhYK2YFOKBY2i9dD3QS2d9W8yM68ascrV9wbhcqqT4vkjjknYDR//qyhWDeDabpJh3VdSj nGXi2XiI+k2lQqqWeyDO7rL8lsqzlloo27XELYWC8g0XaSJRrspYWaX65f0mKhFIXiTvRkOY dSrT/SP3ii/IFcpdNTShKGhIlENaq5lf6r/m/lduL0aFu1TruDJTv97xow32X2cfatbzFu4f gvhwELppMeSlHGmdmeqUqxRV6baguUKZqNFdJea6Dmj31Fwh7XW6W1zBniUIgvgwMfXSJr6x q09dd5+wwaN0g9fETV6TNl198v3fhJfevRuZnxOWlRacnuyfklC2bUuzthZ4KQLjXTb8xbNM Dd6on64F89IfdhUzpSn+9gYfXuMaGH/LA2gc0BuN4/lbbEIMwSUDZKNwxZAdy8pvDfNUmE3l TjzdZCILirNusGqltjC/ygp0kXplwPKyAnk3qvrG+yM5Bv53AN/VOtvF0g1Cot5M007qAgVZ 56FmXkQui21pfS4cza02065Jft39D5VIy6pt1wPKah1XltSvcXiYormlgPl6NEv9KfuHID4o hG5azPvupWZWa65SJaqbU65SrNHtn+aKCrqr5JU23Ez9Oqt0S1SiqwRBEB8Opl7a2Ddm1cnr LuPXuU5YDwGCil5as36Vv1f77MbdOxE5GSGZaYFpSb5JsWu3bm7WxkIv3VXOXYi7JU9D9NK1 EAP0XeWBxeXFsIBDZ4M+ySjG8TjmNlQLbYmxOBvE78LRuWq8bsiAyPXIsieQskl9hlbYCF7u j7pjFvgJx1QtsP+qpitA4RjKbTHaUYr+a26X2f6b8R9jRMEb3xaLs6+hLK9W73PhKLbCgJl2 TfLr9V+VrtmKOXTqUaSrN0S93zTBPmhMTlZQz1u6fwjifUfopsW8716qKq7foKFi3fx6HdHr n6oinfo1tseAXsUCnQ1X1W/B9urvwIr2LEEQxAeJqZc28o1ZcfKa07iyDiXrOkKMX3fl8cu/ opd+VvXGnds4WZqREpiWKLzUgvlSGDErB98sUIf00nWBATQbKEtDcMUwGhVLUY80jtcbW0tN q3TI2NPk8bqxGMjtgj9AfvAu2ZMr9jozaKqFQV0qlgRVu4ra1P2RtUd3u8z1X7OT2vCCsFeL d91nZ19DWV6teefRXGumXZP8uv2HSqScmKfiDdE+rnTq1zt+9NHeDxXV8xbtH4L4kBC6aTFv v5eqVpj6UYX2pF1ev1aV2Onk1/U6Kb9Rdv38iqahYZV+6neRoVqtWKtdTL8yvXr0VxAEQXzI mHppQ+alDmPLHMeVgZ06l0he+knVT8FLQzNTgtOTAlLj/Sz2UgSG2mzsazxE1kvXBAbQ6jyS 56jH0Ipxtl61YhAPOZVqqvYBLMvrMfIEw3QW81K80vUG8y6uqYDuuN88ZtSC11nBLsJ+KiRK z6Pk/utul7n+m+2kGl7/rmKsCs++NlwPbP7j1lxrpl2T/Lr9h0oMO8f8zkSwHq3jSqd+veNH H+39UFE9b83+IYgPC6GbFvP2e6l6jYRscBbYk2YFCoxKVZQdUQpkZfMbma+aCiu2YMMrt726 9eg3QBAE8QGj6aXLT16zG1tmz9W0pOyy7KXXb98KSU8KTEsISI3zTYou27q5uYVeKo19YYis Gj3rpWthOhyXxuIgVPI4G5flcbbmCB6QB/GYwaCmCg+BjhnqUfkJjt0N6YHlxewSRPCu4mLp VGTdcb95zKgFoLctBowaQr3R8Ezsv6hHb7sUebASQzqA3bBsc3gH9gRyxULple+fbH5bNNea adckv97+hz4oPbxC9I4rvfoV+1N1/Oiisx8qqOet2T8E8WEhdNNi3gEvNVonkLJYZk9aNXBU xiihbY6lpXKyupRm9py15YZGjVsxo6YVmalFG16J7dWtx2wDBEEQHyqmXtrAN2bZyWu2Y8u4 mjqVrBNe+vGn/wAvDUpLCEyND0iJ9QMv3bbZovvxAjD2ZSNjY/XSS9fCdDhuKMWH7xiB3+4y XKqqM+5XNYd5ZP3gGsZNwDBeB5iWyKtEIvM3MZRnGURbeuN+XVg9ilDUY0i0oBL1PpT1Rl2P aodob5dhP8DWwbKqaUVtWvtWgbHLad5rR4G6n8b1m7arlx/TNfc//6xN8uujfVzp1q9//Ghj 1B/Dx6ddz9u3fwjiQ0LopsW8E16KmJicyFMJe1JlBcznVjXIbc5QgXm7k2o2VGGSH9HbJDWv vuGWba9uPRU3QBAE8QFizkvHlTngfKl0Hi/z0pvBafGBqbEQAckx4KVWFnopQfzpoOzJc+MA arNBzwjaPwRhFqGbFvO7eSlBEARBvIfoe+lae/DSEnF9Kd6PV/LSuCAWoKbrtm9p0a6NKCdB P7rEWwpOfiq8y1jDPnho/xCEWYRuWgx5KUEQBEFYjr6XrrEft9axpKzD+DLhpZ+w83hDMhJY xAenx63fvqVle/JS4p1BfZ4qSZcxtH8IwgxCNy2GvJQgCIIgLMfUS6X7Hq2xH7vGqWRtxxLZ S6t+euP2rfCspPBsjLDMxA07t7a0tRHlJOhHlyAIgnj/ELppMeSlBEEQBGE5Ol561X7Maocx q53Gru5YslZ46d8/w+fEROWlsUiNyEnZuGt7K7t2opwE/egSBEEQ7x9CNy2GvJQgCIIgLMfU Sxv5xqw4cdVhzCoIpzGrOoxdLXlptao3796JLcyGiCnIiuqUuWn3ztb2tqKcBP3oEgRBEO8f QjcthryUIAiCICxHy0uj0UtHr3IcvdJp9MoOY1ZdefzibzXrVfnH59Vu3bub2K0goVtBfNdO sZ3zN+/dbe3oIMpJ0I8uQRAE8f4hdNNiyEsJgiAIwnJMvbSxb/TKE1ecRq2EcAYvHb1SeOmn X3x++/79lJ7FyT26JxV3jy8q2rJ/v7WzsygnQT+6BEEQxPuH0E2LIS8lCIIgCMsx9dImPtGr TlzpMGoFj46jVlx59OJvNepVqfrll7cfPMjoPzCt34CUvv0Te/XbcuCwdQdXUU6CfnQJgiCI 9w+hmxZDXkoQBEEQlmPqpU19olafuOwyajkP11HLhZd+Vr3GnYePcoaOzhw8Kn3QqOQBI7ce Pm7t6iXKSdCPLkEQBPH+IXTTYshLCYIgCMJyTL20uU/kmvLL7iOXsvga4sqj53+rUbdKtZq1 7z5+mj96as6oKVkjpqQOnbT16Glrd39RToJ+dAmCIIj3D6GbFkNeShAEQRCWY+qlVt7ha49f 8h6+yEvEwquPvvuo+ldVqtX66u6T7womLMwbvyB73PzU0fO2Hj9v7RksyknQjy5BEATx/iF0 02LISwmCIAjCcky9tIVXaNnxCz5D5/qygIWrD599VL1Olc9r17v39EXhlFV5k1Zml65ILVm2 9cS31t4RopwE/egSBEEQ7x9CNy2GvJQgCIIgLMfUS1t6Bq87ds5v8Ez/IRiwcO3h04+q165S rU6Du8++L5i+IWfq+szJ61JK1245ddXaN1qUk6AfXYIgCOL9Q+imxZCXEgRBEITlaHlp0Lqj Z/0HTQ8YPN0fYtB09NIv0Usb3n32Q96MLVnTNqdP2ZQ8acOW09et/WJEOQn60SUIgiDeP4Ru Wgx5KUEQBEFYjp6XgpQGDJ7BAr30Y/DSz+o0vPPsh6wZ29KnbUmdsjlx0kbw0jZ+saKcBP3o EgRBEO8fQjcthryUIAiCICxHw0u98DzegKGzAofODhg623/IrGsPn31cvU6VqrUb3n76A0rp 1M3JkzcmTMT50jY0X0oQBEF8AAjdtBjyUoIgCIKwHC0vDVt3/IL/8PkBLGDh2sPvPq7+FXhp g9tPv0+dsjFl8oakiesSStduPX2trR9dX0oQBEG8/wjdtBjyUoIgCIKwHFMvbeETsa78kv+o JQEs/Ecuufbo+Uc16nIvfZk6uSxl4prk0tVJE1ZuO3W5nV+kKCdBP7oEQRDE+4fQTYshLyUI giAIy9HwUt/IshOX/cYs92cBC9cevfioRr0qVWvVv/3kRfqklemly9MmLEub8PWOU5ds/cJF OQn60SUIgiDeP4RuWgx5KUEQBEFYjqmXWvlGlZ284jt2pd/YVTyuPX7xUc16VT6rVe/Ok+c5 E7/Ombgku3RR9oSFu05ddPAPE+Uk6EeXIAiCeP8Qumkx5KUEQRAEYTlaXhpddvKqLxrpar9x EGuuPX75cc36VarVqnv3yfPCSYsKJi4oKJ1fUDp37+nzzv4hopwE/egSBEEQ7x9CNy2GvJQg CIIgLEfLS6PKTlzxGbPKdwxT07GrhZd+Xuure0++K5o0r2jS3KKJs4tKZx04fa5jQLAoJ0E/ ugRBEMT7h9BNi3n/vPTu2pwqgtJykWYx5aWiaJWctXdFGsFR7NgPcufI22/hYVXZ/O8Qv/fX RLN+2v/EW4Oplzb3jlxbftln1HLfUcv9Rq+AuPb4xcc161X5olad+0+e9Zw0q8fEmT1Kp/co nXbw9FkX/yBRToK8lCAIgnj/ELppMb+XlyokRnPsWtH6V0dR8/vupa+1qSYYth3Q2HxFa2/p zlFsgWp/yOmqflfys1buHkv2dmXzv0tYsuuU33BTzO8Rrfpp/xNvDxpe6hW+9vhF72GLfIYt 8h2+2G8E3o/34xp1wUtr33/ytNeEqT3HT+lRMqlHycSDp864+gWIchLvvpdeLbGpUsWm5Kp4 +0cCTadvFsuvBnZepwozqzanw18Xi1o2UwlgeT3mqeR+wE4J/pzP7c8G9nvFG25RpjcI+1Te 1e8Rp7LHMx3/7zlCNy3mj/BSjcFrBatfh9eSNUsG3G8Pr7WpxijH8YDZz+xP2Dly6+ba1v74 FFum3E2GZIt2nnL/KAvodUwv//uA9n5WozhcNDC/R7Tqp/1PvD1oeKl78Noj57wHzPQZOMt3 4Cy/QbOvPXz2cfU6Vb6oWev+4yfFY8Z3Hz2uaNTYopFjDpSf6OjjK8pJvIEfXRxmKYdl0oBa MfyS4MMwHA7KAzKWS3r3KmNxVQV/FGJEuzk9fTO2/8rNm9lg86ssHE+b36GW16OHqKEy+wGL vAEXqCTmd4RlYM/lSl7nsLOoM2+ix5Xhnf4ecURt4p2E/o7Uzl8ZXqH/WOTdPP7fPYRuWswf 4qUmo1fza18PRd2VH45aMuB+e3itTTVCOYxnmOwARWt/ws6RWzfXtuYOUSRqJ1u4NXIB9b7W 7ZhO/vcBS74mqt1ugvl9olk/7X/irUHDS1381h485dVzvHevCT69Jvj2Lr12/8nHX9aq8nmN GncfPuo8dHjh4KEFg4Z0GjR479FjTp6eopyE9o9upUYxOCBTDrSMCxu/h/wIT1K9ecdGT9Bb 5DV6bLzrFGDlrz18NVP/G6RS++GP6ZIJb+DIMnPcVhKLOvMGevyOUKnjp9L8/gfcB3L8v4MI 3bSYP8ZLjcaMZle+LorKKz8g/WC9VNrwnLVrpV1gXKWitT9h58ifjNm2tT4/Qxqglfx6+86y jr1faO1mY17n4LSkfokPcf8TfzYaXurstWbfMc8uQ726Ynh3G3b13sOPP69R5bMvv7zz4EF2 335Zvftk9uqd0avXzkOH7F1dRTkJvR9dNtaybPxkPNIyHgIZv8chfUlJOku7WpJeshnf8/WV HD1hyxzjnhrWAJZsBttejsXZ+TyJotNiT8h1yTWptkvxhi3C9hvn51WZ7gp5s0z6qL3B6voN 9enUw/svr1S1L28UIq9hqSb7wRy8DfFGRtl9w1pIhRqN+wPtpJfwNGxZsYavlBD1KKsWqNpn 6y3oOO+N9nGr1S6g3X+WWVrmKzXrUSbLdQCK7VJtiFwtXyPXZKhFD0Pt6grV7Zqs1EJzP+jD shsfP7BgVFZaBd3Bf+VGpE2Tu6kqJ2eTMZ+fJX9wx//7jNBNi/mDvFQ1aDS3DjFerytIvKDR wFRzPKyqUlmfcgWUN7w17hRgGC0jql4pqlEUNKQqMhtqEYlyLqPNQVSNmKBoVZ1RsQIxXwsi NwpZlctK1K2pmtBrwMweAzS7r0gUe1JdiQGNT0irSqPiUrIhp1yPnGT0QfC3le2YaX5lolET iNZOVFRijFZ2CeNixnkr2w1VhVDG8NawacYoipjrKseC+hVZROLbu/+J9x0NL3V0XbPnkEde L898iN5enXpfvXv/o2pfVKn6xRe37t1P7t49qagosVu3xK5dt+3f375DB1FOwsyPLhvQvMJI y3h8Zvyej7Y24wAfh/ds3CXKG2e1COP2tVLMA/nl7Diws7QPynIIvAek4oaNUfVH8QYXAZ4L 3xga1toTbG/Bv6brsNMaGyzq52uU3dGpB6vRyK+uX7UxHEjSaN0I0RkVvJRqy5VvRBH+Vl7B egkl2b+QgivkiuR+4Fq5UvXWqGGN6KxTARkhm9Zxq9cuq9qk/4bOsPVySV5WWZHIriipfGOy SZDASvNmFYUVTZjBNKflZTmQX9l9o+7poyzH3hkVlPuBm2z6BdP/XgAa20DH/4eC0E2L+d29 NCdHLMjjOLEqp7RUNUZUrNJAOQo05CpdqyzA8yjqkAophp+Gtsy1Bigz6g+BDd0y5DDeUIZG opRkSJH3lQJ1P9RobKruVpmrx9B5zGXaQ45OxQLj+iveYxV2X1SpV5PmFhkyi9VSfcbHoWqT OYoNN39cWdQx0/yqxIo/a0UFWqg/HAn9Qsr8lemG+X4Y5VWgKKbdVQkL61dkE4lv4/4nPgw0 vNShw5pd+z2yu3pC5HT1yu169c69jz77vMo/Pv/85t27sYWdYwsKYwoKojsVbNm718bJSZST qOBHVxoDmUOMnpSohkDGQyLxHgb46ek4QDSMq15t9KQoL2A9qqDXulSiD9CO8ZYp2jX0S1kl pkpvML+hAuNcehugrEGAFZlmx4yGnMrqGab1qPpjyK+qXaN1TDNO0gXLq7tqnGJoWN2WlC79 K5VT55IxVIOo370Sogqt41aJoiXt/oslNo2tKq/uo/zOuB1pBaQb/8vzqQuoazWDcTs8xSjJ cixu17AFHOkdts6TFVus/IIZtWDIr0AzkWO6Cio0pBhqx2S5Ua0KIU2nDVOwvOleVqYYGla3 JaVL/0rl1LlkDNUg6ncfCkI3Leb391L5xFAxkBOjScUJo/Jw8G65pKqmKMaMOgNGkUOxlrWo eK8ad1Yw7Ky4PY6Uz7hZQDlulqsz9aEKOmJmAKzRpv5gvbRcsfFq5Hp4nwzVqpquqJ+V3WOa 3Vcmiozm9cMIQ3F1acPhxtMN+TSbViIqqmzHTPOrEzWpsDMGVJ+NxOt9g2QUdVeQVVGpEWYK Krtucf2KjCLxLdz/xAeClpc6r9211zOr0DO70Asip/DqnbsffVatyt+rVbtx505kfn5kXl4E RG7ept172jg6inISFfzo4pjHSDNN0B9XcTTes+xSuqL8K42ejNtn8I4jJqs0MORmVL4PDKxF UVTeGFgw9ELxRpWu3njlsjGa6+QtUFdoeGu6l0zqUWUxrFWXVFX6ClTcD0MO07yIlF9ai/8q uqpAUa3JxlYeqIJ1xrh9QKddRQ4VUIMqH8cot9xj467L+XiHrpaAJgtP5vnUFRkX10Wzt5jI MVmlgSE3w7J2jeGb9X+bS1Dd2ZK0BVi9fp2aG2pm601WqXaAYa16v0C6RbtCD3VtiHE/DDlM 8yJSfmkt/qvoqgJFtSYb+0EgdNNifncvhfGbNH5kIznZE2AIzZaUw0ZeTvneMPbUG1wqcyOK tdCg+p0C5aBWqkIrTZ0q1aGRZmhJFFXmMU001K/eHJPaFDmN0dg4k17wJPW2GyGXkYoYeq4s p2jNkFWZKLdY6T2maEeRqNxwQ3FlqgZGfZfegpVLFavSldWpNtCkncp2TDO/ugnT/SDnVKRJ +8aQZNhbGmC2ijpocTcUpQ2pWmmmqNtQoei/5fVrdk978xia+S3ecEVaJfc/8SGg7aW793nl dPbKLfTO7eyd1xm89GP00s8+Ay8Nz82VY9Pu3daV8VI2yLFgMGM8ejIeAmm8NxmYiYRXGj0Z t6+CbYTuWg7mMTT7Sn1gqEvK75T9Y90RmYz6rSxttEqFuXVspVSLKqNpKZMUZVnlWuOO6bdu CRV3xNCeaV5EWi+txX/lBLmnqm4bv3sloAp1Z6QE3Xa1+y9ngX+UnVLnNlRqXIvcAGufnZTK Ti5mbzGDuoCcvSL0esvAlfprOYYuIxa3awzbDnbFJlTI55V5Rer6jdHsvmYix2SVqnrFWuWG YLJehZZh2iPjFEN7pnkRab20Fv+VE+SeGu1/9bsPBaGbFvNHeKk8djQswvjPkMNoQIkohoUy 8mhQudJ0iKhYW1qqN2hVjn2VqzRGuYqcysZMkw0pLEH0Qz5dWZkovWUoOqzoik6zKpSbKuVR lNPasRpo9MloUzja/TS7I1RdN0nW6n7FrVSwUYbymFF6h8tyFdiY6o1A0bSq45zKdkwzv3Yl JntGldE0yaglTRQVyMgbZXE3FEnKRnU3WoFWBwSGnVuJ+rX7rN8VzfwWb7gi46vtf+K9RsNL nTqu3XPAq1ORNwufgqJrd+99XO1z9NLrKi/F+VLLvRTGMZYOwPTHVRyj96aDLUOGVxo9mVao xPxaBm6rlAWXX3EEp2wJl6U3hnRWuZyu3FhlfkDRI1g0pCNyMTZ0N0LZB2X96jcMk3r08hv3 36ieSqLsoQCT5EqxDdOWlUhdk9bKxbGolJ11VdFTVRsqcI1y3+th2hmpI7rtmhbhSAV523K3 FH1k1UhvFOl8jSHdJj1dTCnikiK/oVm5sYpQFzPG/FoGdk3KwjbAsnaNURRli8qvgpka5bXK 74Vq16kxya+qXvHGsOWQKHftVdHYj6pOYhumLSuRuiatlYtjUSk766qip6o2VPCNMm3mfUDo psX8IV4qv5NEEQd2OsM8xRjRCHk0qxgzaowQFWsVGGfUGc6aJus1ppEuF8YEab16uljOIm+M XguKVEVeNZp5FIkSqo4bo5FfgXaPlBWaJOvkM5tRs/vK0jqflwaGnFCpct/Lb6AGuRVlbXod 51S2Y5r5tStRpMo7wlCvKYa9pYV+Sbmcxd3Q2TrdjVagtVEmVKJ+7T7rd0Uzv8UbrqjXFPP7 n/gA0PBSZ7e1+w57dunj1aW3d9fePt36XLt3/+PPv5DmS/Nyw/l5vHl5m/bsaWPh9aXS0Mci jEdPxoWN3psOtgwZ+BhJpoI+YE0qRLXqdEs2xNAum5+xpIgJ+q3KayBRsTNUG2vUpLJDxn2R 1qmGoBKG7Kr9rHojMKrHTH4pJ5+8Mq6ncmj1RLUNig3WzcvySGvxX1HIUI3p54jZBOo6eaEK t8q0M1JHdNvV7r+yoNQtkUvuI6xWZlI0oEjkqbyoYtGoWVU9msitShj3hlFBJQxDN1/zeyRK smVpU9SbZYrUuDqPoUvGZY3yq6pXtyXlfC+Pf17m9TbqbUXopsX8/l7Kxn+KkR/AxnVGORjm BoOG0aD24FJC3ZQBdVaLB8R6jWmkG5Kgq6ImWCclKxZVVWm3oEjVHQbr5lGskNCrRCOrCkOX tPtpmqyTz2xGQ+90Sut8XhoYKjCcu8url9cY/q9AtVt0mhZUtmOa+bUrUaQq+mOoWY3eJ8nQ K8SQS1rcDZ2t091oBdobZUQl6tfus35XNPNbvOGAoWY1Zvc/8WFg6qXNXLzWHDjuUTzUs3io V4+hPj2HXrv/8OMvqgsv5UYKEZmXt9lyLyUqjzRcfJ9RDIHfH9iA/f0clxNvlvfy+H+PEbpp MX+QlyqHfmJgZ5xDnUcjTR4PKtIUg0sJZS2Azrm8ikGncpypMcqtMKdGx3LWlvNFVouUtVI6 pLXhxlScR9FLjV0FGO0tDeRy2v3U2BFauwYwSdbsfoWtaG+HArkG+V5HUhGpEq1bQQM6TQsq 2zHN/NqVKFJVn6NijwlUq01RVCTXr1W5xd0w+cw4lnwaehulohL1a/dZvyua+S3ecIaidwL9 LSE+KDS81D1g9eHT7v0mePSb4Nl/gs+ACdcePvm4ei3hpZF5uRARLDbt2V3p+x4RloJD1vdS bmDDpO3CqZX3aljOlJSklDDD+3z8v+8I3bSYP8pLFYM8MbYzzWEuBZDHhIpUxeBSQlmGrdbO rhxzSjUr0wxZK8qpGKsatlHYMF8nkg06pCii1z9Fqiq3Es08rDGjtwzNanRXG1ZInVLuWDnR kE1Rg1aiRpqyQpGkzKXcGzo7SRu5EulZIFIf5EqMHxrDMd+GzlrdQportHMrUg0dEluh0RN9 DBVJxRRVKyq3vBsVfZT63dPcKBMsr1+7z3rJOiu0c2t29VX2P/GhoOGlXqGrj19wHzrHY+gc r2FzfEfMvfbo2Sc1vpLmS3Oyw3OyeGzavcvawUGUkyAvfUO8v9OlQt4QGpQTHxx0/L+zCN20 mD/OS8VAT36rm0MPecioPbiU0BhkahYw35iyZkVxU9Q9MKpUrDSuQF1Ge3M0NsME0zxmuqpu VGDor3Ejpr0yUzeirN9sVkNGyz8CrbyW7BaGoR79NYjpJivRW6vXMc382pUoUuWNktN0N1ML 83vUtPIKu1Gpz0iFojYN5HIW16/d57ds/xMfCKZe2tw3es3JK55jV3iNW+FTssJ//MrrT158 UqseeGnVG7dvh2VlhGWmh7LYuGtna3s7UU6CvJQgCIJ4/xC6aTF/oJeyEaTWEFGdQ5cKRtUS WoNMZcWaiaaoa9bLajxoVTQOyHWoixt1WntzNDfDCJM8+o+v1NhRgKFfputNuqXeNiNMylu0 x7SqNJx4ra7TJK/2JiH6u9uoV+o9a7LFKnTX6nRMM792JYpUQ4/0diCie0SYLWUoVoluVFCl elcoUdSmgaKchfVr9xkwaYiv1syvXYki9XX3P/FhYOqlVgHxZWdu+k7a5Dd5U8CUzUFTt1x/ +v3f6zSs8knVT6/fvhWSnhqclhKEkbx+x/ZWdrainAR5KUEQBPH+IXTTYv5IL1Wjk0MxRuQr 5PFhBaNqCc1BpqpaZbpy9InJcj6NmtUjVe2xqU47qqJGJbU3R3sz1OjlMRpS65XXblhGUQtb LWdn9Rmv1cSCPabohMghp5jUq8prpl11PmWz6jVGFShWalRtbq1WxzTza1eiSNXvrBEaPRQo i7Fc8qcgV16pbiDKDxLXyVkt64YpRuUsqF+7zxyjtth6zfzalShS38D+Jz4ATL20ZVDSurN3 AmbsDpqxO3jm7tDZe248+/HvXzWq8smnn16/dSswJSkAIjnJPzlp3fbtLW3bi3IS5KUEQRDE +4fQTYv5vbyUIIjXwKwUISRGvyu0/wkzmHppq+CUDefuBc/aFzJ7f9icAxFzD9747qd/fNW4 yseffnrt1i3QUb8kDN+kpLLt21u0p/lSgiAI4v1H6KbFkJcSxFuHbEX6E5fGa4g3CO1/wiw6 Xno3eOa+kFn7w2YLL/277KW+SSk+LLyTUsu277Cy/SOvL8UbhrzTtzq16F5Gv9cNj9jtVt5I ze/GjVve3PZ+MBg+2D/ga6Z3nL+rN/yi4+39R+imxZCXEsRbR4WzdaRFvyu0/wmzmHppy4DE dWduB0zZGTh1V/D03aEz9lx/9uPf6zSu8tGnVa/euu2VkilF1todu6zsfofnxCi0R4IP93DF n+GlMFI2DDhfZ/j5p3op24w3sPveUDWVRG+v6O+td8MTfrdP+9X5g75mlf9E327ejeONeB2E bloMeSlBvIUor7g0gc4h/d2h/U+YwdRLm/vGrj153XvcBp/xm3wnbPafuOXakx8+qd2wykdV P7t6+45HWicWBR7phWt27Wvu0FGUk9D+0X2lsaZJoT/JS6FZhHdF9aayWLQbfrdxOVT8Bnbf n/Qh6O2V321v/UG8hf3/gz7h9/UTJd5fhG5aDHkpQbylaLgRGdEfCO1/QgdTL23iGbnq2GWX octdh61wH7HSY+Tqq49eflSzfpW/Vf38yu17LlnFLlk9XLN6uub0Xr37cDMnd1FOQu9HF0ab lbUikwEqHzDjK0NeqR5Iq4rJmZFXHGxDHTYlJems0qsl6SWb8b3UANsujqF6VuKqaUcVXeMr NetRJiv7L+rHJPWWSNXyNXJNhlr0UdZv2f4xbR7R6CcAqdAJeZ3oEHQwvYSnSb01dFWxHxTb awRbo5euWqXqKSbr7B/jylTlNFDlV3RUUafhrXa7xk0CilZN9wMvIDfAMlTUTVUjcmbt/sjw 1eINgO81t8scGv1nKNJVLWumQ1OwiA2qkhFDflVf5LyIomG99MrWo40ht3HWSvUHEw15oGeK Lr2RfhKvidBNiyEvJQiCIAjLMfXSRq4hyw+dt+89x7HvXKd+8zsMWHjl4Xd/q163yl8/+/Ly nQdOeYOc8wc75w/pUDBs1b7yph18RDkJMz+6bAylGlWZRz0wA8QgjA+/FIM43fGcesWrArVA hZtRTFFL2ThZ7oNcPQ4cle0C/C2+ESukrrH1io5hWWVFIruipPKNYgM5kMBK82YVhRVNaGJJ Hhleuxpe2NA1ozeiCH8rr8CtxZLsX0jBFXJFcndwrVypxkYL9NIBQ70C3h2RXbkW2xLLmKxX oYxJzRxVWUUeXNT7XDT7D3nkLKr9ILcgL5hDlUnxBhf1+gOYpJjUo85vCuTR7L9iP6u2XC8d 25J7quiFMr9yWa9veumVrcc8pqUq2R91smI/vNl+Eq+M0E2LIS8lCIIgCMsx9dIGzgFL951p 121S+6LJdt2nOvSYfvn+079+UafKf1ar8e3dR3adx9p1GWffpcS+24QVB840dgkU5SQq+NHF UZWlQynFwIyjN27THc/hitcfuIkKQUzT00FL9UaDRu0aum5YwZY2m3RKURKQ3xm3I62AdON/ eT51AXWtmmABrU0xh7oRxDjF0DCuMfRBSldsByunziWj7r/e1uilAyY9VScYSqrSTUppgHk0 M2nXqdcuYqb/AnUOrAuOQ809ZoTxlsgVmesPYFwOMOTRWFkBhrLqlipO5xsrr5FXqPMreoSL Wr3TSa90PeZRVCCoZH/UFRh694b7SbwyQjcthryUIAiCICzH1EvrO/ou3XuybcEYm8Kx7TuX 2HYd/+29J3/9vFaV//i81qV7T9t2n2rTfZpN8fR2PWYsO3SukVuoKCdRwY8uG0kpR1lmUA/H AL1xm146whtEXnn8BhWyslLFiuYMtTOkdtUdMgA1qPJxjHLL/VdviCIf79DVEtBk4ck8n7oi 4+LaYBmOVoc1MOotoNtPjbyIlF9ai/+KCnBRgaJava0xs5UmrasTFCVhUVqh6IxZDD1VNaHY NkMtuu0C2v031M5Q5WDrNMr8/+y9Z3xWxbr/nVfnf/Z226X3IggJgZAGgRTSIHQQFOkQwIZ0 6b0pKtgQqdIDSAktQCC0QIBQRJFuQbqC6N7nPP9zzud5XpznmllT15p13+sOCSTx+n5mk5lr rrbW3ea3U3RgTy3a8NUPoG9bGK/LHdqjxAqx5RV13ezmThzJCbInuakHGuwFyuMDEuJwDqAf WwLt/th4qD6RAsPkpmdQlyIIgiCIdwy6NCY1Y39++FuzIt6eHTX4vSZD5ly68es/ylUO+lv5 ahdu3W84dlmjcV81Grc8bPyKjLyLtZO7sDiOjw9deoSSJyq/+Dkwy203uwotXrCjGyTUA7mB 5JSllLp6QxLmAl/UFnVvmdSeRRSg9emPFNMfLqZL4qAHCHdPkFitmhv2rnz0afAl8H2+S74K g2xZ79/tanxcpaO6blAiYSpxNuwLklMNsbKCVenKtS5g6p/4S6PuYeUiDfvtUy+rJPLVD2CP o1hesKX7GiEJpJtLWenkZrfvCBwdGyChpljV/jB5DLh0a+GlHz2B7K6Q+0QKDJObnkFdiiAI giDecerS2jEpGftPRL01PfqtGU3enhnzzqzLN+7+o2yloL9VqH7h9oOQiasbTFwTOmlt6OSM Nccv10p5hcVx3D504WwV6LnJcRxzO7fR5NYGPZ4ZT3F6MEA78tCSI1BUlmVZNl7XGWLBA602 RZdkxRZWU2yh2K0daSc/ykkq0B8u5lpBLyuKeUMPdsfg59anS07eGN8V4SSUu5O52r9WQ8HN Djiq6wZ5f2Dm7NIr9iq0IXh8bCZTXQJ1t/Xvfh/kjurjhpabBLCFr34AfZtDk+nX5YbaG5mr ddmUmv3ZXTrRC7jhFqvaHyaPE9+egfVDrPI+FG6fSIFhctMzqEsRBEEQxDtOXfpis+T1B443 eXta07enNRs8vfk7My7fuPNk2YpB/16hxvnbD4KnrA+ZsiFk6oYGU79ec+JqzdRuLI5j/tCF gxU/Y3nHEaQfvdRt6xhHoH+vl9mlleBogJz2PLTlPPDJyjQFhf7eKE/mDLFwtsy8RKewrTop BRSjZbVClamtrJbHiKhK8ePMMV+buU9XX+rDd8lXFiTTaPeTonSr5XTaFYuFYpehyv2xB2j5 nejuWpMA3XV0aKxLUbIJJ+N9oEYtj99OlURKUbd+9OsCtOzO63LH2D8gKoBF1nW1642q6K0y H90okrvagYDyuKH7AwXuR+6o72PaBqGAfSIPC5ObnikKXXoaQRAEQYox7OOqQDh1aZ1myRsO HG/29pTmg6fGvjM1/p1pV5gurVjz/J0/gqdthBEyfVOD6ZvW5P/gVZcWS+ixznzsRf5CkOeB eqgnouohnhYkXWl8VpXW60IQrzC56Zmi0KUIgiAIUlpx6tK6zZI2HDjW/O3JsYOnxA+ekvDO FKZL/1ax5oU7f4RM3xwyY3ODGZtDZ24hurTlayyOUzI+dNl3GvCYjVg6VNGldpkaGA8XXXwp rdeFIN5hctMzqEsRBEEQxDsGXRqTtGF/XvO3Jsa+NTH+7UkJgydduXH7ybIVQJfWunDnzwYz toAibThzS6NZmWvzf6hVQnUpgiiw/5uCUUD5xZOUtv+zo7ReF4IECpObnkFdiiAIgiDecerS Ok1bbMg5GvP6uGZvjI99Y3zcmxOuXL/9ZBmuSxuBIp25JWzmlsazMjNO/lC7FepSBEEQpPTD 5KZnUJciCIIgiHecuvTFJgnr9uZGp49uMmBMzMAxzQaNvXz91j/KlA/6e8VaF+/82Xjm5vCZ myNmbomctWXdyR/qoC5FEARB/gIwuekZ1KUIgiAI4h2nLq0VFZ+RnRvRd2Rk31FR/d5tkj76 8i+3/vEC06V/RMzYFDljU9SMTdEzN2/I/6Eu6lIEQRDkLwCTm55BXYogCIIg3nHq0pqRcWv3 HA7rNaJx75HhfUZG9nv30i+3ngBd+kTFmqBLI6dtjJr2dfS0r5tO37gh/+pLLUvw3+NFEARB EI8wuekZ1KUIgiAI4h2TLo1fsye3Ya+RjXqPCuvzbnjf0VKXXgJdOmV91JT10ZPXNZ2yfsOJ Ky890v9ODPkLLCX5r6+U9P4fDvW/V+kL+nd2iuZPv/I/4RPQH/Epwn4eI1fn/m9QEB0R/1ua Lm1uBLuuiLnMYuF2vW7+COKEyU3PoC5FEARBEO8YdGl0izXZRxv1HQsjrN/Y8PTxF3+5/cQL Fej3S28/iJyUETlxbdSENU0mrt1w7PJLKa+wOE5hfeiaVExBdJ1XNfQoQF36mHWpRYAPQ+H0 U1jPw8LKQ3RaOpsL0hV5Zgk5Uurq/0ZYis4aepTQdTCsWGLRfbLSqRq08ihbUM6Qnw55idau IiZlYxZZ+pICFQ261HG9Aqc/gjhhctMzqEsRBEEQxDtOXVo7JiUj53j4oClkvD4l8o2pl67f eaJMxaAnKtQAXRo+YXXEuFURY1dGjVu1Ie/SS8ldWRzH/KEb+GnaFIG6tCRTbB6Jx/IwFNbV F1Yeg04DBRhBhpUd5CXMSSmqDMX9IrJT9XHKOeovexRLOmE5KUyXcoziEPoEIxSyeYoeIInz wURdihQFTG56BnUpgiAIgnjHqUvrxKatP3S6ydA5TYbMgX+bDp1z+cav/yhXOejvVJc2Hreq 8dgVjUcvDx+zYv3Ri3WTurA4jtuHLpynPf70JP3+lA6LswSF2NfO5zS/heJtw0t9JZFawJmf 9yN2/OoFb/17lB3mPtWL9tcnMdtC5dLQT6D+FKVN/5dGUlpojxQxB36fXf2tbbbgKH3KvULp RyYRKNlkXZGGBogVdSABvvMEipsunZvONGS6UIO6LrWWVndGTQiQ5E7tauXJkgrQiy6FcChh qVMViAULEagmtYm6FCkKmNz0DOpSBEEQBPGOU5fWS2y/8ei3cWPnx435HEb82M+v3Lr3ZPmq VJfe+j1s3MqwMSvCRi8Habru6IU6nnUpoJ+3/QDHcYcrO5lbR2Gy4IdimIvzMTnHK5GmPO7Y gjku+a1+lIVwMmP5cy+SyDnV5q6Y+yT5hVVZuPXp5u/Wj8Pf1LPbnCxEsE/UzBRiKPB9Jgu9 rjMDWNQ2/flb+b33QzBeveu9Ikmpu5hwPN9FP7jp0qtUN8IuFLE0oV2XKlKTyEIXacokK/0h W7bP88CWZfGvS0VpyMOFLoNmdv4ErwXqUqQoYHLTM6hLEQRBEMQ7Tl0aktp5y4kLKdO+Spn6 VfLUZSlTl1298/tTFavz75eOXxk2dkXYmOWNx6xYlxeYLiWQ07eXYzxxdJy/dQngdkLX7QGd 4z05Sydv/UhsEkYE6JE2LxPmUvZA4eXaJ9lgc9XHvR+548Vft+srH6ipKbrBfx5bAnuAI7+O I/9D90Mweek2PStZRaSn2zW1x2r+Meg0rv3SQY6mk4lfXUrg+tCWjeSHcCuDBc8DW1a4X12q NmlzBqANN6mJuhQpCpjc9AzqUgRBEATxjlOXNkx7Zdupy23mrGvzPowM+PeHuw+erlSD/X5p xMRVERNWhY9fGTl+5fq8i3WTA9Sl5Lht+lafA9P5210PWGkFSmQg53g9v4o5v3s/Zmz5eYAt OcF3Ipc+7Q0INx99wsLh4qsfpWdhc/PXyzrac8UWZzf4z+OnsCO/ZVLQ8z90PwSDl60oQXWh 247Mnu+iH8y6lFqESPOkSzmgG23f0rRblDygV8HuV5eyBii2XdI/1cO2R9ICdSlSFDC56RnU pQiCIAjiHacuDWv72o5vfuz0cWbHeTC2wPjx1z+fqVwr6ImKNS7dfhA9eU2TyaubTFrVdNKq r49frJfyqH+O16QHiF0665GBnOP1PBK3/G79uKH7y4BAeiS49GlLL9P66hNWZIt9sfDVj7UH GfUcJn+9rEvTBuzX4bN/E87CPtIBxCBTOvL7SeC/H4LJy1ekVQM89NIeq/nHhy4VgFojxW26 lC4NLTjsdrGn5LEy+9Gl1J99M9YaQuXSLdIb/W6tdoMoTp2JuhR5eJjc9AzqUgRBEATxjlOX hrfvmfXtta7zd3WZn9XlczJ++u2fz1apHfSPijUu33nQfNqa2KmrYcRPXb3pxMXg1ML/u0cW ulawcNMD6umd1lECTXlcIc6GJt3yu/XjhuZvT+os645Ln9q1kpxe+oQl0T9a6776oUUi5O9j Elz8lX6Ih9f/U0JvF/DZvwHN39mbI7/qQhvV8z90PwQS43Bz9saQG3YXYx4K7dyczoBTpzkt TK0pehIg3wU1CTwSrn+/1KgzWR6YgzT1rUv5zxUzaLjlr/4EL0TZ6gJOnYm6FHl4mNz0TFHo 0p8UmAlBEARBSgVOXRrRofeuc9dfW7ivGxl7u3259+d7/3q26otBT1asceXOg8Tpq5Omr0qa vjJl+srM/AsNUl9mcRzzh663s7sOOYEz2GHbXQ9YZ3JCxNws7Xt5pjy+ULyVls353fsxo+a2 NeNjy4y5T6VRxeq7T5rJ3rm/Vu0duvgLM+QP9P4ALA+xu/fvxKUZ1/y+Hl+NAvZjoWRza8my 02a0/OrSnAewrkEz+SBQXSq+aSkL6Hb/4lDVpZa29KlLnVrR+vlhsEOgeplOqeyMRV2KPDxM bnoGdSmCIAiCeMepSyM79t39/Y0eSw6K8fP9/3iuWp2gpypWv3rn95Yzlrea8VXa9K/azFi2 Lf98w9ROLI7zkB+6SLFHV2XFkeLf4ePHt04r6aAuRYoCJjc9g7oUQRAEQbxj0KWd+u75/mav ZYdh9F6W22tZ7rX7//l8tbpBT1es9sOd++2mL24/fVGHaQs7Tvtyx4nvwlLaszgO6tLSDdF8 nr49+BhBXeof1KUqqEsRLzC56RnUpQiCIAjiHbMuPX8L5Gjvr470oePa7//5fPW6Qc9UrPrj nXudpn7WecqnL0/5uMvkeVnHzoQnt2ZxHNSlpRX+86PFX/GhLvUP0Wm2n7/9z/8s2YNi/Xgw DIMutV0vxc0fQZwwuekZ1KUIgiAI4h2nLo0gP8dLdKklSqUufbZC5Z9u/9p10gddJ77/yoT3 Xp0wa1defkRiKovjoC5FkJLHf//3/w4YULIHXAKCFCVMbnoGdSmCIAiCeMdFl97suTS3N0jT ZUd6LzvCfo732QqVfr59p9v46d3GTe02bsprYyfvOpoX0SKJxXFQlyJIieTPP//37t2SOqB5 BClimNz0DOrSR8nlzcmfHPmNLRTc7CpefALgtyOfJBMKM+djg1zM5stsYcS/BwKUgGdF8Xwk H+Mz0FviEvDIliScujS8Q99d5250X3Ko19LD1mC69LnyFX6+dbvH2Ik9xkzoMWZcj9Fjdx85 EpmQwOI4qEsRBEGQ0geTm54pbrrUrr74Gr46YI5kSz9tUWd2VLMn1HCGFilwNjRWE3Yf/Rhj C94/iXxUp3u3yxY4L4NYAuiPHLp9e/v3eFgK/lgUFFlRv8MF74REFo9nBX0C2BDXWvg9Om8Z baBEPAM9JX6Mj6y+dN7pEolTlzbu0Dvr3I3XFh3osfhgTzrY3+N9vnz5a7du9RozttfoMb1G v9vr3VF7cnOjEuJZHAd1KYIgCFL6YHLTMyVFl3IMh7DLmz8BFCdq4F72BI8T6MV4NnSzq3jx CYBHeVts51Qnvh9BD/g/mvv3KMH4vcFeKVbPCorzcSuSR7JEPwOhV7838jE+srZl6cCpS8Pa 9d757fVXFuR0+zLntYX7YWi6tM+Y0X1Gj+r97sje747Izj0clRDH4jioSxEEQZDSB5ObnikV ujR582blaAbHNFhyL58HMpkN3BjOsyPxYhgOlqT8EeFhqCqKUOMRXkimEs5iIiqKJHTrMjfb q8Bk82X4R9vV0kBZWdBxQdIgClIjL0msypJZeEElxpladAVQCzGoEQBp3/0RdOY09ca3qDNP JYpr+dSMoihx5Q7qnKdWKhJkLo7sQVR18WI4NsltYDaZTOmG7lvJyRpmpHvLQLEuhtk1f0CU Ey0Up2eFGyRSd7AszssCiyypLmQt90rgU3KfgUKXul2pLMY2DNW1/OyKCuGRtS2tAD4xX46a k6CWKzY4dWmjtj13nL3WZX72K1/sfXUBjH0/3fvXs1VfZLq07+hRfd4d2WfU8N6jhmXnHoqK j2VxHNSlCIIgSOmDyU3PlBJdCudU7kZm5LjDvOwJNHg2JetvRzbr7oqBHLJsxWmoqMCLgVEU Fbmpp6Et4cwncg8slr8VK9xEQmnhmdVd1cYLM/T6Yk6uULWLhb4kbo6CdG66V0otR1YKOLg/ gsacht7ohlLV8mEL+1yWUq+JzcABYN60N8soXNUMAmIknvwrNQX0XCJ1re3LIJIUsWH50Q5k DPP+7bffZOcEkUX1J3M6o0Yln0hHUTKRXT4nvap2pZy6JG6OgnTu91nhiprHglZUqihNynxy oSRwPBwS8C/xz0BiEwXsVypza7FKdS2/bUnc1AtnZdQ6xEU2LNPYlyJczU/m3EdPxCsVN5y6 tGGbHtvPXuv02e6XP9/d5fM9XebvEbq03LVbN/taonTksN4jhu45jLoUQRAE+UvA5KZniqEu taOecbRTEcM6vbAzDOyDv+IFdi2BBvcjVd29JIZkrK6Fkk8YRYzRExB2PlH2OGosbNsSmnbB JlsVIQK5DTO1mtywtaEt1exaJYlWweQgAQfIbP3LerUVZ4hM5t60QrqLXIGTGipj+Axc6ffj qBP/qqfTc1twG8kvu3BHFuZABrUBPudetgC1M6NdTADuo+WwBQJyG2bqFcoNCFI3tKWaXask 0SqYHGzYygGaRVlo+bQyHuqAF6Sx/iVJIcJZmSAS27bZUtaVNoZckZaUUBnDZ+BagGcgSSuL 29CKmKvbUmpL6aXPFbQKqoO+FGldLkc1ay7FC6cuDW3dfeuZn9p9vLPDJ1kdP93V6bNdP/72 r2eqgC4tV+7azZu9Rw7vNWJYr+FDeg4fsufQwcg41KUIgiBI6YfJTc8UQ12qHXrsa8NRBVyI BXY2X6b/aF72BBpqNnB0qGAO2yPY9iGDYmHF1JqihNETEHbVwSrIW9NjYU9PaNpVW5AhErmv e5Il84W0apS2VIMMCRjmCk7AgWSGCqZHEHDkNPRGfh8QMLaoBti6IalZjNUGeJJ9SxeyBaBV 1BYM1cb6VesI2B7Bts+KwRfII+rznGyXI5dW2xxh1/yZD3xRcuiBBLmve5Il84W0tnJyqQYZ EjDMFVywlQM0i7LQ8unJWXEf5cCDpIF0JfgZCLA21fQWsqZrdVtKbakGGRIwXCsoS5HW7XLk lMzURMUJpy4NTnst8/SPaR9tbzNvB6hTGD/+9s9nqtRmurTn8GE9hw3pMeydHkMH7wZdGou6 FEEQBCn9MLnpmdKjS8kW/+E3xcueQMOZzWmBBCKDMxkvTmHbWg7hYPIEpLPmQJBO6pawCqNh V78M1YEhspCZuis3bLfCflXMS5uTXMpcVhDORsCBZoYSzkfQmNPQG90hzsyuTAE9nxIqUnIf 9RuVl4Uo0CtqC4bT5rSQ2jyhUpgDJlGfzWUCdQ6IJW1U5hF2Wyzx0RuyJSQwP2um7soN20Vp S+mlzUkuZS4rCGd3nPdQsygLLZ8puTOVBPzpFviU3GegwLApi7hWt0VpS6VHdU5yKXNZQTgD +lKk1fKrCzJnKO0UM5y6tF7LbptO/ZA8Z2vLD7e1+mh72twdP/z6z6cr1w56rly5n2/e6DFs aPehQ7oPfaf7ENSlCIIgyF8FJjc9U4p0qbKneNkTaHC/y5t5TmJxLQi5bMkUC3G0PGUItVn7 Rk9A9Mcm8MVtiyKSe9ylU+nAUfZJjMlX5LLQlmpNOVddlExkKhOpJRhgsvZlAjEz59Sa0Zbg o5TlhcicexBn1S6bgR3y52ksP1hs3iwfDK2itmBwW4GfS9RGfrGUeoCv/B1TAPZUd7nUN8RK NYu6ihGmapyFsq82r/qq1wBoS7WmnKsuSiYylYnUEiq2coBmURZkqqSWc+4sHAy1wGS5yYRi ptRQQlUroCzBR+mDFyJz7kGcVbtsBnYK/Az08cRTm9J21eq2lNpSCVfmqouSiUyVRPpSxGj5 lQW4K8HFFacurZv66tf5V+Nnb2nxfmbinK1JH2y7+uufTzFdeuNGd6FLh75DdCn+HC+CIAjy F4DJTc+UJl0q0Y85Kloy7nf5svyDus5DkcxA/u6uvRv5F3blDknLTPwvnhJP8hc5mVnmINnJ WrYsonkrckuZOyf6nExZFuVsK9Dvq3S2GZU4bamG2+YM9V7x9HRNXZQyAJjsDSrVTDl99EaL SS8WqX3rUdnQG6F27kbrihi1hL5gMFuBn0uAWl5rxVFRXbKcNJmwqw7KnEwtitezgs6VKgJb OUCz2Mtb0J/FtbKZHg7qpxcDk15FS23q39aYuiRzlp9Orciifgb6feIphYzVbSm1pRpumzNc X++2pUir5VcX3J0hahUrnLr0xZRX15+42nTGpmazNjefvSX2vczLd/98slIt9v3S7sOGEWlK fpR3yO5Dh1CXIgiCIH8FmNz0THHTpSULOJYpJ7liCpzzitfZDhoq/nettFPsnhWPEnwGFlts z0tdTxcfnLq0ZvIra49fCZ+2MWL6pqgZm6Nnbrl0988nuC692WPEcDKGD+s5fNiew4ej4vG/ X4ogCIKUfpjc9Azq0oeh2J7tLx/hfcE5r1hpZ/Idlr+uIHq8FN9nxaMEn4HFGV2IkseqWD5P nbq0etIrq49daTBlY8OpmxpN2xQ2ffPFO3/+vWIt9nePeo0a1WvUyF4jR8C/2bm50QkJLI6D uhRBEAQpfTC56RnUpQ9DcT3cX768WfyAHR7BEQt8ViAlAKJFBcX1/zxx6tJqSa+uPHa13uSN 9adsCoYxdfOFO3/+jejS8uWv3brVZ8wYMkaPhn+zjxyNbpHI4jioSxEEQZDSB5ObnkFdiiAI giDecerSqkmvrjh2tc6kjXUmb6oLY8qm87f//HeiSytUuHb7dr/xE/vCGDcBxt68vCZJSSyO g7oUQRAEKX0wuekZ1KUIgiAI4h2nLq2S9OryvKu1J24kYxKMTd/f/uP/VKgV9EKFir/cvtN/ 0tR+E6f2nTil74Qpe/OORyelsDgO6lIEQRCk9MHkpmdQlyIIgiCIdwy6NPGV5XlXao7fUHMC jK9hUF1aE3RppWu37/SbPLPvpBl9JpKRfSw/OimVxXFQlyIIgiClDyY3PYO6FEEQBEG849Sl lVt0/erI5RpjMqrDGJtRY+y67289+D/lawY9T3Tp3d6TZveaNKvnRDL25OVHJrVkcRzUpQiC IEjpg8lNz6AuRRAEQRDvGHRpfOevci9UH7miGhkrq49aee7m7/9WrkbQcxUq/Xz7bveJs1+D MYGMXXknI1CXIgiCIH8BmNz0DOpSBEEQBPGOU5dWiu2w7OC5qu8sqjpkMYxqQ5ecu3H/38pW C3q2fKWfbt3tOm5W1/FsZOWdDEddiiAIgvwFYHLTM6hLEQRBEMQ7Bl0a03ZZztkqr39Kxhuf VX3z83PX7/1bmapBz5Sr+OOtO53GzOg0dmZnGONm7szLb/xQuvTq3Iig9Cy2KDFkpQdFzL3K FgC5Ct3yaHhcdUsO9A5ZFO59unowImhqUMTBx3nvszYWfgOecp5PD1pQyM+6At3Ponv+F7v3 JftbjhFPTo+Q4vI+WZgwuekZ1KUIgiAI4h2nLq0Y3Wpp9qnKfd8no9+cKv0/OPfLr//2QuWg p8tV+OHm7XajprYfPa3DmOkdx87YkZcf5uXvHinygGMdT4rd+c8Tj/a85X7aLA3nvKIE7lyR Pruy0k1SqrDkop88v82NmFr4F/e4dCnFfD/dKZznv+n1VVjvS+QZKJI/TLvubwIKnpweIfZ+ zDeguHXtGyY3PYO6FEEQBEG8Y9ClEclLdx+v1H1Kpe5TK/WYWrnn9HPX7vzb8xWDnipb4Ycb t1uPmNR21OR2o6d2GDNtx9ETYYkB/D1exxGksM5/j5ZHe5IqWee2YsRjenI9Gl169WBEoVSx 8Vh16ePB9PoqpKcOpCFY2bVFoHh6Eyhu7xTe+ilZ729MbnoGdelD8NuRT5I3X2aLh8QtV2HW KMEUq9tQah+TorkwfAojpQ2nLq3QuMWSnUcqdhlLRtdxlV8df+7n2//2XAXQpeWv3rjVatj4 1iMmth01qd3oKduPHG+UGMB/v9RxBLHOf+Rf5ZuoDHBm+D+2WHlEhEse5ahJDolzrxoLG/0B xS4DRAbHMVbuWJB9SJE+17LzbmVlZ117CoBXca+rJdJuhAGSRiaAQBmgFVeLyPT+sjNc+nFe L6Xw6uoXx1Hzy12wQlax57GCDeuHUbWxUdYHyceMQtSR73lKHUgdSEu+81Cy0qdGzP2NLYhQ 3Dh37gLimX6efNcxSNmVdZXvr1qyVhRSe+DzqzShMY9yCczNGiw/Sas3zNMSZ94hDOUSAkQ+ ivZHWH18DQ+/iuZqwa8AdgrhfQkSRMydm079rs5Nn5tFn2Vs0/j8pxGG5yE487m1acyjmkUO QLsqOmXwtNaOyCSz+EDW1d2N/chulAbUFhnanWA2L/eHQs2eei84TG56ppTpUjgCf3KkoC/a gCnMA7dbrmJwqL+8OTn5Ed5Vhv5QBnYb9NhCpxg8JkWD6cIe/tH3e7sCKFGwR9Zv1KX8oy2y flc9iGXG7Utyzofu9r//+x+btC2ynHfpf9jm//5PbtbRFvn/ATN7idu3raWWnI0fc//JvFh+ msFCbQywp0UeCQZd2ihuyfbDFToOh1Gx04jKL48699PNf3u2fNCTZYgubTlkbBqRphNAmm4/ cqxRi2QWxwlUlwLWuYMs+AmEHG5McxcceZTzkAgleRQ7CbCWSoCbv9YDLLjdgiTQO1T8lezE Ssz0K9hknFtdwFFN4qxrD/aDnkCpZMhMIem5XZ274tKP2/UWSl2SxI4VQHZEN+qChVhLzStg FGknIaKOSzV1TqUplWdiwjHmsbALP9ClRJHSzCSJJf/IDnhaE4Dscj3JFKm1VErzolRtKiW0 nuX3S4mbaJLktOyOb6hCOG3DErGsllO+Bgp5oPRngtPiF3g6OR5s9nSQTxqeM6DnIYmE1FlE mBJZ6uH1zgpbS7JgG7xJuq8U1XrgTlqkupAODDDQaKusEqyUMKLWdZs7yxkzO7wAl/55o2yp eQF005GrcGFy0zOoSx8CvwfuAHDLVZg1ShT6QxnYbdBjC51S+5gUzYUVZtaCPbJ+oy7l/zgv S1eDWT/OU3SpkJq/XfpRkYVEdmpbICBBcAqHf/6uJIESRzfdpguA61IOSSV3BeCWf3uTIkQB 2Y+SH3mUOHVp+dDmi7cdLN92MIyK7d6p3GHouR9v/Nuz5UCXlrt6/VbKO2NaDh2bNpxI0225 eQ0TklgcJ1BdKg8qclt31L1M2DxMRx1AMetHGr/+uoPD3dGgZpALHsgtehcCP9Ukjrq+nE3o CZRgsmFLTdDTO8s78NRPEdQlON3sFpmW7MgKnrp2g0s7Ff3bm/qvhlI5l56uCDwLUx4LKTsZ XAdypafJRYkiF6WGJMj2aNEsmyi19y/y6Bci3cDO+6FtiIb1zh3yNVDMj7CX54aC6cHWE0uP AJ+HzB2EaXo6yFK3ACUr8ZAVbIWzHBen9yNW9jp8A+z2r5afHqBnNaF7yGiXfjh6GYahmt1P upAd6W0ILWqY3PSM0KXV282B8dh1KfnWiQU5yZITrUmc0HPmZVhJV0DGChOJYFgW9VsztuwU GaDXNZSznHk/xj4VZGJ1S7T8yebNaozRrrTBismkIlS/gWaLx0COvBwPycEg74S2CKSotLMd qwdhVrxlVmZ1xKpIb8ctFM5gMj7cAtrMEaODTOcMM1Q3WABjA8RT8SFXqTSsuto8ydLF00Lc MNuT0EKEw8TvbfH9MqHIFoTRawnTIyvTWRbio97cT44c8fV8YIDS25R/W36f8/btebCUklL9 FihZ8m9g/scm7XubFlJhqoGkxCVFRnrTpSTqNvtXwuWo3Y48Kgy6tEHM4sz95dPeKN/6jQpt 3qzc7m2iS58pS3Tples3kwePTqXStNWwcZmH8kLjElkcpxB0KTHb8H3+sB1klDq2VKrZcUIi GP3d01s4s4ELt5BN5s4Dub+yRaYKSn5HNYmjrsPgB91fryQ7Eh62JglurVm492NLVch1Kc7i 9lspPZy+BcagJ4l+s35yVQxF5kFx0IEOheaqS51yzocutZXmgdzTDhR1tGclUe6OaMDeiZCd IFDB/+rcjenpG8EB7FbCItelgHyyeHtATa8vPbHwkKkFPp+HEEiz8ARKWlsqnkYvLIEMmp+F zVv0KSYM4Wc1dHUuyGSmky0/PZE93AFxt0ED3Prh2PYtDNVc+zdneJQwuemZ4qVLxQGVTDeT 0yU9qbLXupzTw6gyFy5wKhVzkYOgHOOZj1KLo6ayn2/5QvVRUsCUW7U5w9gJTSvjvc1lZrLk K0hKnYhNePMbaLN4DJTwPU/J2d21UBaBFtUTUVf1vsm0Ig4CeDY9VkCT8IKXj1wmTwJDOHVj 8WotgeqgllWdwcysHFN1zV/M1fyKj3pVYHY6iKJy158nNar927umRp604LeFZ3W94d5KaPdA 9xFXxH2UsnqUASrw/mMTF4qX8n/Mva1+q1PTpaqkhK0WMxzi0HLQv5lpaUiZypMuBd1LM5Dv msof5QVI3awf52kZkEeHiy7NKddqEIwKaa9XavPGuR+uC116K+ntMcmDx6S8MzZ1yLjMg0dD YotAl5rOKj7R8+jHGJlIyepyvnHxd6bXu3Nmg1CJ2OIJub/IpKfUr15faTjq6nn8oycwVyI+ 3MlHL0bc+tHthV+Xol8cwW6RaZ2+BcakJ/XvN+pYEpEIQl0ouulSg91VlyoCVXEDfOhS4g+e asO6LiWxVh6bXpWXSXXpb3PTD17N2ggWS6YCj0KXctTnjy9Mzy09sfQI8HkI7noD3EDyy0RK VrcrYi7wRW1A95ZJ7VlEAVqf/kgx/eFiuiQOeoBwd8XFw60fjr0viiGXa//mDI8SJjc9I3Sp 9eH4mHUpOaraDpDydAkzvqccOfWF+wFU2aEBmx26gVZXbDLCrZxql3OYufRgwfNqWfV4o925 oZSBpGSLXIJe3GnxGCjhdb0kJyZpkYuAi+qJ9GvXFhIZocdyXMI4IshvLd0mVjBRqkI6Lc6Z CDxUi2xac1UWmodjRuBFZZAfT+lI0FcWwqZt+vSkyJXJlyAuRzhonsYweQsA8DBcO4tUX+Ba lAkhGokyBD2pq0opJi1skpJ40t8LldKRiEyw2L7LSmUn/xarF116W3wLlwtUAS3q0LHII8K3 Li2fNqhia0uXliG/Xwq6NPHtsYmDxyUNHpf8zvjNB/OCY4vi53jJNJDzh5ZHiVXTkLnI73K+ cfMn7mxKzT4vAwAnQ3ZipoHcX6R1q0tQattx1KUWY2kXZGEaaSykVlEb9YJLP76uV/AwdQlq PIOYRCmSky8MvgVFyjYFp+xkEAVoFQbxpmg2lzwOKUhx1aVqTjIXCf3oUstBSlNF35KGRR5N 95JrlPaI9I30V1vPp0dsTLd+rNfyf1S61M+uQHtOMPRQeKJwh4Ceh84GeCY1DZn7fR6KFoiD bFfpnabhC8Vu7Uh7RHo6/dVW+sPF7NultrKimDskp6FPt34YehmG1itDsyn9mzNwyKYjVSHD 5KZnhC4VPE5dSoAzJEGcI/nxVD2EakdWdeE8gLJ0BLlDjM6Dqi2YOFl53coZ7fDVmZpg70Qv J3O52fVyajoLvsU2lBy6JYBAC7Wuv+RkKTflgnlJ/BXVE+nXrt8INbes5kzoYnWG+6pF0W1k RQOVRBZanLO6zULCrQjXBngE2HikS1Ee5c9T70ErzBA2bdOnJ4WsrNR2X6URm4PmaQ+jaP26 XDvbUa5Lv0oDUpHm/8dvl35kc4+6lEG1qJCm4KMrSa5LlV9D9adLIYT/JSQylF3qrP5UMPJo cerSCqHNlmzdX771G+XTXi/f+vWK1vdLn+a6NGHwhBaDJya+A2PSpoPHgmMf9u8euZyH6CFD 4HoWsXB3to5HBPr7WX7PNy7+sgJYZJ96XYDntG9Ydh7Iq5OvLJNbXYKSjOV3rQuoe1oaI9Kb /v1R43W5NQModd0w92O+3sKsSyOcfrKwmt/sW0CI+mI/Nyu1n2IUdqrxNJ2mSVNDHrOedNWl LCcdEXPPs1/7BPzqUoBKU96P+HlgyKDpSSp3xRYzUo2q6G1eq7B0qf5kANhj5+P54wMlSskj nw7y9Q7oJXw+Z/QsBJnJ5fXuDLFQW7A6UDplaZT3JUAWUIyW1QpVprayWh43RGGKCDb3ozsD shig7GpNcJRm9EZt0Dz+O38omNz0jNClxeT3SznqoRROlZsvg0EeLV3Pr/oBVD2dKjt0esR5 VCXuykFYRriV0+w0wNangKS2d6KXk7nc7LZyPI0Ltt4AbilwoMSHRcsuFwEXtUVoDsoCvISb v2rE11nEGe5WS6DbxMpcleOsbrPIcPcGLB8wiUKuRWFDfzYaPcGo9KDVYgibtunTkyJXqp3U 412IhoSDlkFPx9AuwnhFALWrL3A3RwEXjaD3fpyXRcWeuy61y1SBqkXddalVhfycsG9dqjRA gISq6KWxrp0gRYxTl1ZsFLt0+8GK7QZXaPd2xbZvV5K/X1q2wpUbtxPemZIwZGqLIdNaDJ22 6dCJ4LgA/vulRYbP48qjh7Sjno/IGasYtYeUVEDjuf48MIIgRQ2Tm54pXrr08mZ+ECWHUu1Y CciTpev5FTzdN6wE3KpVsFBNMkBPpC40O+Dok6M6ysRqCTLnLm52WzmylLV++81KyR34ruGW eguUEAvZDTQ57Z2n0tP6L0qj+bblIFZyoZqV26bHCoi3dL982SXcpZZEzWOf269RonrS6pq/ 0j21uzQAK/LXiWQVLQmsZFHI6HzVODzVumSu1LIQ9bVGtAWD2LjRPndOTTdc3dYXHBIkjcTF cUU8TtnUo9RLZgjRyL6ZCbjoUpjr4lP+3SOy5eH7pQSya/vvu9h1qezEQvZD/ssxzJMYnX94 CSlynLq0cuOEZTtzq748okrn4ZU7DavSaZjQpRWv3LiTMGxmi+GzWgyfnTjivc25p4Lj01gc B3Up1aG2/5O/iP9vfARBEKSIYXLTM0KXWh+Oj1eXXr4s/8ipdiS1nyTdz69kQbC8SZwF+fOp YKPb3FlbMHi8Vs9RgS9ofiWD4cTLcHRCrbIa/VuzWg2nXWuDIv2SP9l8GXSi4wa63FL/gQqs rtfk4lLt3zwOqKh0pxlYD3KHL3zfWMeDId3BF1KYwl1rccCm/JlXbZcXBug16tirq/62G+XW AA2wXZZLUVLNg6e06U9ChqgvJgRtwaC2zYbbQi+brX3ecL8lLCuBXxhfA+SK6JJHyYUaRee2 +6KJRgtdl8qfp7X9BK+lMJ1bvnWpldOXLlXEJ4M4zLv0H/Cvqldpb1oh5BHg1KVVo5JW7M6r 2X18jW5jq786Bsa5n27R/35puUpXbt5tMfKDFqM+THz3o6TRczcfORPcog2L46AuBUhDEhSl CIIgJR4mNz0jdKngcX6/1A04zNoOksWTktIn8lfgUT8bieBzCkkEKX04dWmNmJar9uW/1H96 3b7T6vSZ8mKfKd9fu/1/nq8AurTylVu/Jo7+OGnMJ8ljP00Z99mWvLMhSe1YHOdx6FIEQRAE KVqY3PSM0KXF7PdLVUrKeRfP5Ujx4dE/G/H5j/xVcOrS2rFtMg6eafT2h6Fvzmnw+vshr793 4Ze7//5CpaAny1e5cuu3pPGfJ0/4InXigpaTvsw8di40uQOL46AuRRAEQUofTG56ppjrUnLU BYr9abek9In8FXhMz0bUpchfBacufSmh3Ybcs9EjPo0c9nHE0HnhQ+ZevPHr38tWDnqyQtWr t++lTPqy5eSFraYsaj118dYT3zdM7cTiOKhLEQRBkNIHk5ueEbrU+nAslt8vRRAEQZDiglOX 1k9sv+not3GjP2/+7qfNRn4SM/LjSzd/e6Jc5aCnqC4linTa4jbTl7SbsXR7/vlGLTuzOA7q UgRBEKT0weSmZ4QuFaAuRRAEQRA3nLo0JKndlqNnk8Z+2mL0x/HvzosfNe/yzV//Abr06QpV f7hzv820xe1mLOkwc2nH2ct2nDzfuFWJ1KXy7xIZ/lwS3SzCv1VU1PmdFLu/C/VXw9N/EtKT E6IDT23/N83389/76zHg1xFN7fY+EwCF9dTw2Y/hPuBT0gaTm54RurQY/34pgiAIghQXnLq0 QWKbzCNnUkZ/mDRqTuKI91uMeP/KzbtPlqsU9HTFaqBL289Y3HHmkk6zl7783lc7T10ITyvB 3y91OWYazmcFwP1IVzj53TDVdblQn5T0I2lh9A85ZJKHedg8NVMy73hhdV2gPOQB8vDE9v38 9/7AFuR1BBQwTKFwnxou/RjuQ8l8ShYhTG56pih0KYIgCIKUVpy6NLRFq8zck6kjZiYPm540 dFri0GlXbtx5smzFoGcqVvvxzv1OM5d0pqK065zlWacvhLd+mcVxSr4uLRwe15HOVLcgF1rS j6SF0D/cNoKVRVsEiqdmSuYdL6yuC5DHc0hhvdALmOfhyxfuU8N7PyXzKVmEMLnpGaFLrQ9H 1KUIgiAI4gODLk1IzTx8InXYlOR3Jia+PQHGleu3nixTnunSzrOIKO3y/oquH6zMOn0xvHUX Fsdx+9CFIw5HnImsA5LY8XQECiSPn/zO8xmxWDjPbUphNZGzH5lEwLO551eDxJ7VoGv/Ntzr WnnEvpYnoP5dcO0TNmBhLCzrau1oxdWyJn9zXS2FhUzkmt8A+EbMnZtO016dmz43S/2ZUed9 A2iE4XrBmc+tTWMe+6VxWH5i0jvmaa0d+33wg1JYCTDUdcuvujKU9mR6/aICzeOKlYwtCA6D 7f6IOnpDFs6Khvvjmsc3VhhbMGRlvbbZzi8EsBxEadXfcBFGnP3ILLrdva7x8fWFcjtFDasR seMpUaB1CxcmNz0jdKkAdSmCIAiCuOGiS4+nDp2UNHh84lvjWrw1luvSStV+vHu/8+zlnd9b 8fKcVS9/sHrn6UuNW3dlcRzjhy4cQMRhhBws2JFCO+tYhxQyc8dnHhZNFn7sDGIxVTTYlWIq 4GnqhwBLQwDFkV9rTVmQaUD3BzDVtfIo94HngXkB+nfgyM8j2Ya1VDZILV5YnRMX0ZCCi7+V nuW0xRr7d8tvBrwhRRYRpkSWUr1pRcNMpCH98ErEw+V66Yzu603KpexYiVQXjksCA422yirB SgkzpLCei+BS12d+R1MEkp77KPOA8/jAFk5wpAADdbHqMndnoDmVoR0/edxweBKDyK4s3Ozi yohNTUXW3npQcYty2t3qktvDl+rcDYgXLsqtpWnVhb88gdYtdJjc9IzQpfhzvAiCIAjiF4Mu bdEyMzc/dfjU5CGTEt+ZmDhYfL+0UvUf7/7ecfbKju+t6vD+6o5z1uw4fSkszZMu1YADhfEo Iu3ecMsjN9zsDLeTkNPuqTXdyUeIPb997dK/pyaMXt7y6HZv1SxsFyBDyYbMIux6biWaTLVb YeHmr9fVvfQVwyW/CywFCNP0dJCltnICpRLxkFXlBp1lOYrrPYqVvQ7fALv9q+WnB+hZjZhd 3Or6zG9KpdtkdKB5fEBS2f3BRk3KV6ucr7qAvk1wacZPHjfs+e1rnsjNzmbO5w+NsJk8YK/D cdpd6upX7pbODRmtR+pZTTxc3cKAyU3PoC5FEARBEO8YdGlS661HT7ca/X7qqFkpI2Ykj5h+ 9eadp8jvl1aq8ePdB+1mr247e3UbMtZsO3mpYStvupScIRQKeC7xlkcmcrMzbNsCh93N0dpR UNL7uBp7Ote+dEcv98fs5Z6nQP07sF2QDLVtMGxFCbKU3BSBrv56er1jt/4N+d2AFNSHp1LK 2VrilfSGJJBB87OweYuO7a0LP6uhq3NBJjOdbPnpiezhTlzadK3rK7+hGnG34b9P/11rGC8B coAt4PvjyGVMDvjJ44Y9nT2Q77vZ6Y5yGzWIk4WpYyP2fjhOu7muLCnwdyNsIcxdL+j3fvqo q215vhGBw+SmZ4QutT4cUZciCIIgiA+curRhSvutx79tPemztImftJrwcavx83649evT5SsT XfrD3Qdps1a3nLk6ZcYqGJn5Fxukevn9UnJqkEcOef4I8FziMY9cudkZDgPD6GhqTbfr/fu4 Gnt++1qE6hv+7w/B5OWWp4D9O9DzKyt9Q+AlNwnlsW7+evrA+lfzuwApdAduILEyuVLJ5Xq5 C3xRm9K9ZVJ7FlGA1qc/Ukx/uJguiYMeINxdkaU0XOv6ym+q5tZBoHl8YLwEyFGQ+2O/bnNy wE8eN+z57WueyM0uZvDFtSQJ1q/CFXsdjtPuUlc25g2SWAbIaL2g/6yB1i18mNz0jNClAtSl CIIgCOKGQZe27Lwt/3zbmUvbzlzSdsaSdjMW/3jn/jMVqwU9TXVp6szVSdNXJkxdnjBl+abj F4JTvPx3Ysi5hp8/yPwhziX+8yhObnaGXl7itBOLwdWtHwIJcbkcR37NlyQyXRfZcEmoYqrr lqeA/TvQ8qtJ9cIS1ccNNdbF3+26CH77d+tN4HTgFdR2yFwUcsspWiMOsi2lR5qGLxS7tSPt Eenp9Ff16A8Xs28H2sqKYu7QNpyN+qjrml+L4ZBYw30IOI8P9FwWYCvI/XGmIhbDBfjJ44Yj PzGIUHKvlD5NdlmKNiZcNBxVXHHzdNrd6pLevNWiqO5kzjPpBUUxdwKsW/gwuekZ1KUIgiAI 4h2DLk3rsu3UpfYfrG3/4doOH2Z0+ijjp18fPFu5BtGlV+8+AFEaP2V580nLmk9cuvHY+fpJ nVgcx/yhS08jFPr7SgU9l/jII5EZvdkBtuVmJ6h7sk1zPxZKhP/8MpGSnfhrLn7vD8Fc15wn sP7d0K9LcdYLqxhDdKNbM4DiL9Pb748S4j+/AT07QVZwuW/OEAu1NasJe0ewrfUvCyhGy2qF KlNbWS2PK6IyYK9gIa2+8yuZpJOa3mOfxjzu6MkslJuiTF3r6k0CSj51j7fplscNH/lpexZa ErNdLWUlpZn0/H6aAdz6ce3Tpa5YceR1uSAv6+He/wOtW9gwuekZ1KUIgiAI4h2nLg1N67rt 9JX28zZ2+HhTp0+3dPk886d7fz5XtRbVpXd+bzFteezkZTHjl8SMW/x13rl6SR1ZHOdxfOjq 5xuJmx0pXPA+I48BT0IGQQoPJjc9g7oUQRAEQbzj1KUN0rpuPX2l3ceb23+2tdP87V0X7Pz5 /j+fr/Yi06UJU7+KnQSidFHTsQu/Poq6FAHwPiOPBfJtOHziIY8MJjc9g7oUQRAEQbzj1KUh rbpmnr7Set7mtp9u7fjFjq4Ld/18/1/PVye6tDr5fumUpXETFzcbt7AZ6FLy/dIOLI6DuvSv B95n5DEBTz38ninyqGBy0zOoSxEEQRDEO05dGpzaZcupy60+2tj6k8x283e8/GUW16UVQZfe T5y8JGHiotjxC2PHLdyYd65+sfh+KYIgCIIULUxuegZ1KYIgCIJ4x6lL66d23nzyUsoH61vO 29zms22dyc/xMl1a7ert+0mTFreYuChh/KL48Ys2oS5FEARB/howuekZ1KUIgiAI4h2DLk3p tDn/Qsr7a1M/+rr1J1s6fbHtp/v/JLr0qQpElyZPXJQ4YVELOlCXIgiCIH8RmNz0DOpSBEEQ BPGOQZcmd9icfz7lvVWpH65r/fHGTvO3/HTvn89Xq23p0nvJExYlTSDSFAbqUgRBEOQvApOb nkFdiiAIgiDecerS4OT2m0+cS521vOWc1W3mruv02caf7v1JdWn5qldu3Usav5CORYnWz/Em Ft3fPSJ/Tcf2H4KgpsfzX64LhMf7d4AM9+0xIx+2AvZVoMe9+N2HoiXQ6y2U+wNJCuEWF+jx LSz83Yfi+5+jIZ0bb5jP++nveiWu+T3h/b7JdovrneYwuekZ1KUIgiAI4h2DLk1qt+XEuZYz l6a9v6LtR2s6f7rhZ6JLawU9SXVp4rgFSeO+TBpPxqaj39VPbM/iOEWqSy0e7rhUyJhOX4+3 Qdf79pgotP+YR4C3tXDuQ2GpkqJXN+brda9bSM+TQnt4A318Cwt/96HoH7mC4ueGuWx7f9wf 7gHxet8K7wkUCAV7VJnc9AzqUgRBEATxjlOXhiS1zTz+bdrMxW3e+6r9R6u6fJLx870/pC5N GjsfRvI48u/mo2frt2jL4jiP4EP34Y5LhYzpfFOsGnzcFN7NeCy3tbBUSWHlCZRHULewHpdi +rJ5XI+cf/zcsIe+nw+XwON9e0yPesEeVSY3PYO6FEEQBEG846ZLW89c2Pa9pR0/XNH1kzVc l5arcuXWb0mjP0ke/XHKmI9TRs/bnHsmOCGNxXEMH7pwBEifC6cPID0LFtqPa1lrijydkLOK 3SYJ5CQjM9nyQwdiz8MBxZBHNTGUnfQsc3p5vYoZXAPpx8ovMkl3kUG5VoaxLkF5ANQdV38z srK9ttUsW/jG9bosjJmU9uWey33wk9+GTCJQshnuDw0QK+pAAnzncWJ1yRYUSGWlhS2YiIR6 ZYoS6KOu0Z9XNt4fezKXBv0j75stBy/PFgy1rtgrQJ+aXUtkM3GUPrUK0u7tin1crwO367Ls 1ly92ZZdXIS9IT2MIFwdvcgdgG/6yu92H5Tr9XaLnF0S1H7kLlghpb0hKBnI54uamuGs7wKT m55BXYo8Yv7v//2/v//++z3k3r0HDx7813/9F7svCIKUEEy6tE3m8bNtZn7Z7v2lHT9a8QrT pTVBl1a+evPXlJEfpI6ckzrq/dSR7205nB8cl8riOGZdSj/66Vd2rrBOAjATRwKyq59jpJ+O m90BcRQp1QWZW73YNsy45gGgbUcwSy+uUXRLrtE0ZwGB9KPl193VihZudenCUMvV34zWgliw LjV8J2IRlpOWlEIsegKwCIPzUhz+Vn7m5MxmBNLqWQmu94ckFRevxRnzmHG4gsGqYF0A23WU MF6Rj7oOfys9c1d3lWt0VKV4vDoIFgVJTj3G2I9wURZkGlCfqo8T566SR7s21a75uACZ1TSy ITOkEcAKUS5Ab1D2o/k7G9LDJE67i6eWX/Vxuw9aC7JPMyy7hiwlQtUFC7GWYoNUJZH0K1jI hkiktiOT+u/ODJObnkFdijxK/ud//ufPP//87//+b5ggcB+su8HuDoIgJQGTLm2beeLbNrMW tp+ztNPcFa98ynXpU2UrXr1xJ3XY9JbDprYaNqXV0EmZB/NCmieyOI5Zl9IjAD8viAOFjuOk IM8XOm52O3Y/WUDvwN8RxT2PfcHQA6SH7qt4BdaPvSG7v71f97oulVz9zdgdAgyX2Fz9XpeO 42Ic/rrB5eJtmLx8XSBZRaSnO57h3qpRIAV1Vb6yAjS5yGJPKf0UfNR1+OsGGanZjVWI0a2M G47O7JntaxGgb3jok8y1VBr2OrbO5Eq3O8L8oEebsGUUAbpd5nHzZ7g16LQTi8HVra5eSHrp dns7Lpi7US0yEdmRObmdf+VxupegQN3ZYHLTM49Wl949MDs84zxbFBOKY0/FH3LXCLMP3GUW b9y/fx9FqQrcjQcPHrC7U0Ae11PYf93i8OIqpS/w4nxZpfSWKxh0aXLbzPzv2r63uMOHyzt/ vPrV+fz3S58qW+Hqjdut3hnXavCYtMGj094elbn/cEhMHIvjBKZLyVRBPylwfztudjv2o4eM 85rBwj0PYDrf6OmFBzHbYKGB9WN399kf4FrXpayrvwu+67sUMWFz9XddgK1VvU2Hv24wPXJO DF62ogTVhW47MnurZgG+0ObVuekAxEBCFuq4Ig3jro+6Dn/doETClG8QH0NCj5dHohX0EHs/ 9pxivyB9yspqCYq9rm0t8ssUAv0CnNhC/Lj7Kizt8nrd/Bm2bYHRTowWcsulrnQV0A1bXns7 Lji7cb8Opy+B+/Nd8pUlIFMFJa3H7mwwuemZotCl5zOoZNGw9EtxPK8oPZHGAxVaXoASStqi qvIoIddQoAfy3r17TJAhHLgn7O4QPD099GdUAV9WzkrEEkAm/3UL2FmhovQgr1i/gSUR9dZ6 es6o6JcfcLgTPaHam39K4mNh0KWp7beePNfuw686fryqy+cZr3254dr9P16oDrq0TLkfrt9M e2t42ptDW7/xTtrrb2fm7A9pGsPiOIHoUuUAobgJuL8dN7sdu58s4DWDhXse+4KhB0gPky8l sH5s7o5gh8GtLnE0bbj2acZeTw93dOOO7uoINBpkJUfXfhJ4u0qTl69IqwZ46KU9VrMAX/Jr faBJs9IhiC7phuOKNIy7Pup6vz8wlZga8N0Yh3jJZhyd2ZPY1yKg4H1asbYt33XJiuV3dOwH JRTwH+0sbK10u8yj2x0FbNsCNzuFbPJdt7ouV6K7k5Wf66U4u7FbXC+Ywff5rqgsJpqbhcs1 +IHJTc8UhS7lOE8ngZ1XHg2PoKeSePDyDZxkC3ZFXJeeXRW+6iydFQhf4dezZ8zIvs4WD4Xf TA95FQxdl3pCf0YV8Cl8PmM2oDyM1BCYoPDj/QheXH4x9qDfwJLIQ93aQr98PWFgvZXEx8Kp Sxu07LDt9HkiSuev67ZwY88lm6/9/ucL1WsHPV2m7A/Xr7d+/a3Wg95oPWhQ6wEDMvfuDYmO ZnGcQHQpbIhjBpnbTgrc346b3YF2LiEF+MJzBgvXPIC2x9DT88u3pg93RRaauzOnM5uvuqYN N38XSBq3+xPItQV6XaoLmdseCIe/boAI+wNngMQ43Jy9MeSG3cWYxwXwJT8KTMJBmMKMBzqu SMO466Ouw183yPsDM/eqFOnrC/WekLktxtiPcCEBbFHwPgFHFZ91aZuiCbLyX0GgutNE4mLM aI3Yg605cTHfB2dvjutiuNktlF3dEQr4uQ/E33jffGHoRsljZeILgy/AG+O7Ilxtkzak9KPV 0LBaN1wewOSmZx6HLqXflSGom2TLaaXQc8t5074MElbF2TrsGHwA0cPsjAzRJXFVpgoklZKZ WXgS9VTlKCcqAdSiVFG89ZOZpvvUhczGU6hJpE3iKOHoEAgorSOBowQBjPoDQSl6XVo4WpHy WHQpuZnWbTU9KARpZztWiDCr3vKh0XMQICADnv3K80x9MSihqkl9TGWrljNPJTrR8qkZRVHi yh3UOU+tVCTIXAoyrbJt7IFlFXsADzH0plUnVhKn7FJknJrKX88BRPmwq7Ha3IK1Kg3Mx3H5 PsMJYPR1RS4JhVnx999MycCpSxumddrxzcWu8zNeW7Sx57ItfVds/eX3f5apQXRpmR+u/9J2 0MA2A9PbDOjfOr1v5t7sBtFRLI4TiC7lZwBCxNws7ccVNdghwc3uA1nAfijxH6tizkNRulL6 lOn55VP0S+BOAfZjTmK3A25bSi11w3aHJP57c78/JJPHa3MrqtsBsRX480dm1R4XHyjZ3Fqy 7LQZLb+6NOcxo4RqWfQLEOjNAJqPs66bv55euT/2AHsPiqtv6NVQvDxegAxQKgTap27W82iI pGIHnLWL00Ps98GB+XrdcE8ud+jfx2V53Px1O2C8D4DRrl+szOrlPggzeGr+7uhFOPLGqUlc fakP3yVfWZCv+y96VW8dgQaZW2dy0zOPXpfy4weZ86OPOoeDiu18QqOUbb5/90AGPzpJq+bs y0ck0ed0qhSR7aiZiYOajbnA3FCOTGVH0l8rff7AeeFhi5ALpRSvREzcFRx5IwxnCVOHAadV +7N5anaxEIAGAzGnIZWd3GE2YmDKEDSiZXYPJ2hS8uyqGatWQRjkyKZRlq+aQUSDb/ZZUoMg a6rVeWK64PAEitEyaZ3IJRRfla3XMetSw4MiUe4/QG81c1YfDnVufhCJeJAelvbgeQzPZFpI FhYtSg/mwxb2udIMn8OUzcABYN60N8soXNUMAltaK5xGufRgTWVZgi2JmNNY4aevKH7vkppZ 4P/eSrNPO5vKOXXmDq6vdzpVutLC1VJ8TtOyheojcSZUr0vm8d9MycCpS8PadM769lL3hRt6 L9vSf+W2gau3X3/wz7I1QZe+8MKPv/zSbmD/dgP7tR3Qp01676179zSIjmRxnEL60EV8YD6e lXxK63WVcJRzPoWc29WHqbg8bP76LPbg879YQB4Gl8eByU3PPHpdKixyATPlYALHFB9RhqwE cbYxb1O4j2s+PlUd5FwLU89SLucqadYdTFXsaBFaIlspSKIYYF/L6KsEwBMHmlZGWrHKptww 13b/fikIN0Ukil02tfk7wy10MQhexI18AatNKBLAxPMwJz6nVhZBvGQkbIoFd1SNwpttsi9g pq6wtCtXsy51PigK8jYTtFstFx4eRLAwu+WsZRKIarZtttSa0V3kCpzUUBnDZ+BKv8VGnfhX PZ2emwImWZuH6X7KSk5lfWuh5pV7hoLuiDAtyl8Kc5Sy8mLnc93XgbwwOSPwMLCq4dJJy2ss Yk7oXEjcmikZOHVp47Yv7/7uUu8lX6cv3zJo9bY3126/YenSZ8q88OP1XzoM6td+UN/2A/u0 G9B72749oahLHwOl9fyK5/JiCdF3it6zyb/io/5891kCwOf/44Y8Ao7vnyowuemZYqFLyXlI w0cUXcljjBJqGZ1FHT76OUgJEFNpU6ppmdUcej5nSy4FbWEa2p7uyNLL1DqiQ4JLCSVIbAeS Vk1sK0EC5Z2zRQGuupTIORUpBK0d3dsRbmEzsyX7wmUgNUhYgCkj70n2YvPjCz2YrSAavlzP XjWDfCXfjyVZVFc2N+tSgv6gKOh3XbvVcsGiJbaHA/aJBQIyztN/7A+aksCqpm/TJfmNVEBY 3TrT7TQ1i7HaAE+yb337li0AraK2sFBatCD7bj0oU81F96c5LS9DQSdKC1YWfz1TfEfRlXc7 n9suhOOoZXN0CSdhVgWtB23BMSd0Lvw3UzJw6tKItp33fHex/+J1g5ZvfGvVlsFrMm88+LNc Da5LO73Rv9Mb/Tq+3hfG9pzshk09/BwvUsiU1vMrnsuLKey4zlDFHuwUI+3n3meJAJ//xR0m Nz1TXHSpr4OJnkcLE3Eiha2oyYfYTPmUKZkxhKeWWdTT56ZyurPMQ3xFPhtahB5uoSRx7EkM JYiJRziDvaVV920l5IZ2uwS+dKkq/xRA2a0CbadtOsIJjhTMi33h27AUbjKPKSONID8BrOxo fnyhB7MVjT6bvYr9j/WmurK5uy61MNxJ/fHRHOTCw4NIHSGC/wCtFiyiRSJbJ2RJd4gzsytT QM+nhIqU3If9PDEs6E8T65t0altYKHkkbj0oUy3OtTdDQR0SyfOIMH89e4hSVl7sfE4SS1+K sZYyI7iESyetB23BMSe0L0gBf82UDAy6tE3H7LMX+i9YNWjx2reWrR+8fMON3/8oW71m0LNl Xvjp+i8vvz2wy9sDuryd/vJb6TsP7Atr1oTFcVCXIgiCIKUPJjc9Uyx0KZ3Ko8ndu/ohheyq nmyuJpMHHtXq5mM7HmnJ6RSMMgdHywweomE5N5ejU5lPOJGJdD8vHACypQTLOXcXDoonMfu4 dbQEMYg17zDgtCSU76qeyjVrlSSKLtU1JLGo4o4jRZ666ww3yFIeK1PQfRkLM3/fL+URYlM2 QmbMTqa8tpyTlKuyYWopaytKrcPmZl1qeFAkLs8o20IPND2IlqMMETM1pXxUVSugLOUTQn0O kDn3IM6qXWkMZGhGBvvNUlhkZMiXn1ZRWzDUtLCyrtFXD9aUWGUqNYkaayuotw2o+3JTi7Kl ILhHcbPXOc8i5qqD++vdmnKzLZxfoHqxahZ9wXFJqC9Us2szJQODLm3Vfs/pc30+XpL+2bJB Xyx/48uV1+//XrZajaBny5b56cb1V4a88SqMoa/D2HVof0Sch/9ODIIgCIKUcJjc9Ezx0KUA WTHIjxUyK4U6wlnVQslIDjQWGQf4t1jsRU0+ajX5O21qrNINgYZpmSGI57LPGaZyjjzSnXyb yLJZiB36M5ZWovPnISczy1bUZu23DrCXcHZYgLSQRFyy6mkzymQcrkuZqiMImSZN/EdnVUFI F1z8GcJVwcdgJvYFQmRWCv1mKAsyhMsIFmM5iNKrzipBIqmtR7pPNplZrcPmRl3q8qBw+C13 PKNs9537AaYH0Z5YCXY+T+y5tSUtJL1YpPLiAuSG8jwBqJ270boiRi2hLyQyrbxGaTO/wIUD 70QGKL0p/gB10Tv3f5f0FAzXKMO7nJtdvVFqEZnb7fVOIBEEulbD+Yb7fdAWAteE2sJDMyUD py5tnNJmV/7Z7rM/6zVnfp8Pv+j30Ze//HrvhSrVgp4rW+bnmze6Dx/cfcTgHiMH9xw1eE/u waiEWBbHQV2KIAiClD6Y3PRMUerSwsJ8ECpCoKB6RILDVAk6MRVvhC4tZBQJWeLQdSny18Tt Xe6Rv/shHnDq0kZJaTvyTnee9GGXyR++MuXDbtM++vnOr89VrBz0XLmyoEt7jhra692hvUcP 7TNmaPbRQ9GJcSyOg7oUQRAEKX0wuekZ1KUGdCFK/j9+PBgWEvfv3//v//5vJsiQ//kfuBsP Hjxgdwf564K6tCTh1KWhLVptPXKyzehZbd6d2fbdGe1Gz/zx1p1nylckuvTazZu9Rw/vM2Z4 37HD+44bvjfvcJOkeBbHeRwfun+1vxeCfx/lMSP/vk4RPgy0SIn72z2PlUfyuPgjy9t/t7Mk E+Al+n6/KknPcyY3PYO61Ij8eTMAT4WFx3/913/9+eefKE0t4D7A3YB7wu4O8tcFdWlJwqlL QxJabcnNTxk+I3no1KQhU5KHTL564/ZTZSsEPV++3LVbN/uMGdFn7Ii+MMaN2Hs0t0liAovj FPWHrulI5PvcY6aknB4L63qRQsf4MBTe86pwzuuF1U9Jeb0Aj/nlUTzuVJF2EWBy3w9I4TzP Hw1MbnqmJOhSpFQBMuz333+/h9y79+DBAxSlCFLiMOjSFmmbc08mDpsZ/87UuLcnx7456fL1 2/8oU57p0t5jRvUeM9Ia2Udzo1ugLi1aCut6kULH+DAUt+dVYfVTUl4vwGN+eRSPO1WkXQSY vPS8XzG56RnUpQiCIAjiHacubZDUdsuR04kj348bOrP54Gkxb025dP32Ey+Q75eWv3brVq8x 7/YcPQpGj3dH7T6SG5ngUZeSo4lAOaOodj9HFy2FBYuwzj1iXzsywRGKo3jb8HBocubhdcWO p6Oaex62EIc+9z4tf7Gv1lWDZEqwgpMxwBWlUdW/kO6D2qfSqJpfT+NmN+Ljel3yGPuxrsua 00i9tL6tp7CQu8b8rkhvzdUqaLzPhvw++wngcSysPBbS3/X+2/KwhX7/taaUdgh6mLVWitmW LhT8ugD/6bUA1T3Quk6Itw2aycpi+VhARpFL1tXTm/pRA61qvluyKou+pLNsVW/MdhH2TQOq v3QHKxQzFC4oTG56BnUpgiAIgnjHqUsbpnTIPHY2Zey8hFEfxA57r9mQmZeu33miDNWlP9+6 1WPM2O6jx3R7d3S3UaN35R4JT2jB4jjGD11yMjAcLohZnBW0hTvqWYrDDh5WBbUWzEVZcsBS Ik15XHHJY9VVFoZr1PCRR4bqnZn6tOo6r5dMhbO6YAHWUvNyQWlOBULd+g/0Phh9SE5u9zJ3 w2rIeb1ueVz60c0QoN8SY5TDi+CS3w+OKGIw3mcf+d36Ee7kPigp3R7HQslDfAxz4iKSKws1 VOtA37Dj2HXkd4+1AB/hEuh1qX26oiRVCbSuDwxdOExgsDKRWqZrcelHZKKN+W/G6p85Ovv3 YvEJcRdXpi7IXNw5zauAMLnpGdSlCIIgCOIdpy4NS+u8Pf9c66kLUid8ljjm44R3P7p88+4/ ylYKeq58hZ9v3X5t7KRXx0zs+u6ELqMm7MzNC0tIYnEcV13qPGgQq2rkpx2fmJz0RG5pdLun YkZkpLe6bnjLY8rq4u9+P8mOzGJKqePfA9DTB3QfSIDWqoUeKbO62V1xuV7XPC796JUc12Vs xOFFcMnvB0d+13585Df2oyE9XPMDhZFHzyG8dHfFzbUfsqGFaNjzAW69ecEtVtqVzgB9ZcSD i5e6vjB4QRpqUr5aaXVfvZpE8aLTLPDzdiv99O8sSCzeUhPs8bIA2ZG1HIUDh8lNz6AuRRAE QRDvOHVpZNuuu85c7DxnRftZS1tPW9hy8oKrt397snyVoOcqVPr59t1Xxs/sMnZ659HTOr47 bXvuiYYJKSyO4/ahS48aFHGEsJ8TnOcTA6bDhR6oesiqFCUysEOKOY97XTcCzxPA9dpdpZse 4Bd3d7Kj4KF/N2QmEWlLTqCJ3Ozu6A1xfOYx9GNL47guYxW3qzfl94Mjv69+3PKb+5HeFObh K38h5LE5E+iGPbUI99WPTKZfL6CHWfBg2NNquSCzU1iISz+2evbLcWJq0CKguj4xeYEN0lyd mw7AHqSlLraiBB5q7ock0tZ+8NO/vs2Qlc13SsGeUOYzZn4YmNz0DOpSBEEQBPGOU5c26fha 9ndXe3y24dWPM7p8tLrj+yt+uHv/6YrVgp6tUPmn27++PPHDTuPndBj7frsx7209crJBQisW x/H3oUvPG+ZTg+ko5cDkpCeSHsQunfVIT8UYbnnc6rpRkDymrC7+utm9gF/0PiW63Vv//iCx PNgtMrCMgMv1esmj9uPnuoxV/NVQ8/vBkd9PPxR7fpMX8ZFG6eErf2HkMeUAdHfFzVc/HOKj RTvzUaxo2DJ1YIMkkG6yrks/ulkPNuLmEmBdn5i8wEZ+zRM0aVY6bNIlsxszuvXDp/DFHGjD T//6tg2y6b5LscfLAj4zFwQmNz2DuhRBEARBvOPUpc1f7rn//M8DlmzrtzCz94JNPT7f8PNv D56tXCPo2YpVfrz9W8dJn7ab8HGb8fPSxs7NPHI6OKE1i+P4/dBVzgpkKo4oHg85WgxDP37I YwlJye1krgaa8rjhlsetrhuu/cgNktJvn251NV+Sky/0AP/QLpwBbv279eMJNVgtoOJmd8Pt er3kMfdD74jtuoxViNHn5bv15sThqRtc7rMtytSPehvInDv4yl8oedQABS038XH6Exf7/bfQ ixGcFgItEiF/X9IHaptk7u+6aGprSt2NfaqQAEOLgdb1hdKTAGwR6en0FoAwhRl3UAsruPUj W6AX4rcbP/3r23Z871KIi0hJGuULD7GBweSmZ1CXIgiCIIh3nLo0rmvvQ5d+Gbxq95srdr2+ bAcI1Gv3/ny+as2gZypW/fH2vbaTv2g9cX6r8Z+ljvt085Fv6ie0YXEc04cuOR5ItEMJPe5Y +D3eMJRs7MyhHz/Uc49MT38fSivhzOOOOY97XTfc+pG90L9b6adPH3VlAbUZPcATSlVj+oe5 D2purU/7lkzqZjejN6RizOPej9xRHxfdH9BqKbt+85txy0/sspS8z77zO/sp2ONYKHn0VjUn jlpUurvff7fkgMwP0F3N4k6g1yUqg0W7XlfUXqV7oHV9oVTgwTS9tVCmBLUdxW7uR2vBipSZ DLj1rxcFmJNu93SxslHVXy9cCDC56RnUpQiCIAjiHacuTXilT+7l68PX7hu6JvudVXveXrHr +u//LFOtdtDTFar9cPteq0kLUid8kTzu88Qxn2468k09T7oUQRDk8VLoIgX5y8HkpmdQlz4E dw/MDs84zxZG/HuUYs5neLj2AtwhvyEPc9cDjTX6P0wDxY1HeS2l4r6RiyDMPnCXWVwpTc+T wgHuiIf79vhx06UjMvYNX7t32Jrsoat33/j9n2Wr1w56qkLVq7fvJY2bnzj2s4TRn8SP+vjr 3DMvxaWxOA5+6CIIUtwgqtTTd94QxBUmNz1T+nSp95MN6Cbb4ZFYAjgo+j9WloiD58OcBd1j PWZ1u0POB0fg96b6dfBBoLGqv+j5YRooJjyia4HsyqNcpLV8PKMKE1LG6zX4vd4AetbvpFcK FqUjm9SzFeyGQ44S8NJx6tL4rr0PX/pl+Jrs4av3DFu9e9iqXUyXPlm+ypVbv8W/+3HcyHmx Iz5qPvyDDYdO1Y0N9O8eIQiCPDr4T4Xi90qRh4XJTc/8tXXpbEDxpYYADsZQyo+3f49igPc7 5sQ1FjY8XXgB7pDfkALkFAQaa/R/mAaKG0V7LZBdef6UhvsGaszzq6kwr1e/k14pWJQbhZKt cFsqIpy6NPblngcvXBuyImvIip1DVuyAwXTpP8pVvnzz12bD5jQb+n7MkNkx78zccDC/TvNU FsdBXYogCIKUPpjc9EzR6FJ6tDgPhy4LcfRS7OzoARbLRzqR/5vdQh7ZnG7mEjKWm0zZGLCV kZEhz0AgS2GpVmCRpqIkjHiwLerMU4maWj41oyhKXLmDOueplYoEmUvBmdZQyC2VvD96cYfF YyyDBpDSHi4QvopMIg3f53MLmtMtRKDGArZwgdGuxNJ9eRUW9mpqLTE3J2ELYxpAbqoJA3j0 Tdt6BtIHvxT1XphLW3MxsSFj9LvHy6n5CQZ/eVdZXauW8ZGV4UqHxlqKnSCSWMnl3LatGnk+ o5vA6a+YtAgw+23JGCwc3DIwHHcSkOksC/FRL2z2gQOGKALx5Gt1zrtRmiEJmdnRA3dX/cWm BXFRsNoDo+JSPHHq0madeuw//9Oby7a9tXTrW0sz316aeeP+n2Wr1Qp6omzFSzfuNH17etO3 pjV5a2qTN6es33+sTkwSi+OgLkUQBEFKH0xueqbIdKk8AyknG81uLRUv/TBDphn8nOJw01Kp DsRDr2DLJqG5QIyK1NbhiecX7vIC1KJsSTekB/MRNfW5LCXSyHbBAWDetDfLaL5Mjlbi/IHz 1jHRUMg9lWyBYAu3UnuMlai3VQl0uUClCg8jc+nAguQFmkIEIpbNlVa0/G52GkuMvKzM53gW 2WvRuSkJNSoVuZnh9/mmhgt85wTUDCSvmlk25lKazlRPga2umKvlVNz8yUJxp+FKA2paJVw6 qMEczS4viNrFFZmzcU/T64jtcWy7shFYiDmHJle97S3Rub9HgWdQS0v0uqoP7LAizEcpq0dx pBVcfb8psaXloWcTdtWfzLkPuCt9sBmgLYonTl3atEO3nHM/DFy0adDCja8v2vjmoo3X7/9R tlrNoCfKVLh0/Xb06xPpmNDk9Qnrc/LqxCSyOA7qUgRBEKT0weSmZ4pOl8qThVw57Mophh1G yFlFsQJGNz2VugAH6e7MpmClYgmtKlpWgUhp22ZLraLuIlekEyVUxvAZuNJvFVEn/lVPp+em OE2uhVxTSRcANuRC9OEtVqJm4S5gC+AC+VTbt3ALESg2qKNui3bd7DxWGgDiLFc6an0xNyUB m5IDtpTyNkScmlxfWPjPqQWp/Wi9SZylDWWJl2qTuUzOgKu/OgW0cLmAmeIEIdTsUstm17LQ mTGbM5nRTQBr1aBchjIV6NnlylnVQuQQDpqnMUyrCx7G5mlkhnItpm4BbgZ/f69ZdalnE3bN Xy5Us91FzIspTl0a3f7Vvd9d6b9gQ/oX6wcsWDdowbrr9x6UqVoj6O8vlL/0y63I9DFRA8ZE DyRjfc6ROjEtWBwHdSmCIAhS+mBy0zOPSpdaxxXdDqcYHb7FNtgRx+xmP8iowfpJS8+mABsk CIIzztN/fDRo6p8uZ8+eTfaFVS8vA2xtkdQsxmoDPMm+9X1GtgC0itrCwpYWcC3kmkqLIP4a 1MtbrARctJTgzkxeL5BPDQXcQgSKzRZOro7uuNlprP0xJRAPwN6LVl/MTUlYAomWnqK4WHXU 5PrCwpSTuFmQHFoQuIv+1TngXtpQ1hRsuZicAVd/244WLhfEX4OaXWrZ7GSlX5Exm61DwFyU Y/Mnzmzfmcl/Sxylps1B87SHUbS6SiIL4U52lP5M3RLADiFQiOz6fM2qSz2bsGv+ykJOyUxG wkpJUyxx6tKodq9kf3u57/yMfvPX9p+/ZuD8NVyXPl/u4rWbkf1GRvYfFZU+KnrAqPX7cus0 TWBxHNOH7qP5LzTQv29SjP7kZjHqh//pl0L54y/F7T4jCII8Cpjc9Myj0qXy+CHtbmciBnc2 u2mp1IVLVr00xTp70S3+s2rSCzZFHpHSloQs6Q5xZnZlCuj5lFCRkvuwH3yFBf1pYn2TTm0L C1tawLWQayqlF9tC4C1WAi7SbPkHeIF8arscgluIQLHZwkW7bnYaS+eGwqZqqkXMTUlkCSPE k+8LV62cs7a/nIAWpLorc9+lDWVphGKTuUzOgKu/OgW0cLnQnTgutWx2ueIzYzZbh4C5KMfm rzib4vy1RCAZHTmEg5ZBT8fQ6pqaIFD7AWXTzdEq4eU1qy71bMKu+asLMmco+YhZXRZHTLq0 a/bZy30+X9P389X9P189YP7qX7guLXvx2o2IPsMi+w6P6j8iOn3E+n2H6zSNZ3Gc0qpL1f+U vDeKnX4L6GFwv17UpQiC/BVhctMzRadL+UnDPldOHGQpzzF375LZ+QzuIHZNbnoqdQFnI7lh yCYBT2tXhouZPaMVqloBZSlPZNLbmnMP4qzaZTOwQ/5AkuUHC/UH7bSK2oJBbMJ4/jxMiMVU yDUVcZJp1XBYBXK3FdiJ1gICAr5AMSUT4SEu0BQiUG1k7nY33OwsFsyW1dezyF6Lzk1JbLHs xnLUNLId1aovGD5zErQg2Yu9Lx+lTWW1ujLGxRlw86cLGaCFKws1HFaG56QCsauB6pxOXbOJ dI7XkXATqLv2K5JRDDW5fe6cKvmEVd3WFxznnXQ0z+OUTT1KAXy8vWbVpbMHutL8lQW4S28F N3sxwqlLo0GXfnup73ynLn2u7MWfb0T0HhLZZ2hUv2HR/Yev33u4TpM4Fsd5fLq0aAlclxY7 CkmXIgiC/BVhctMzRadLyUHGQp4xtAMKhVgYcAa6CyfCA9KiBzKomy2VY0EdD9x1ycYwHH+U ROSMZZEBSWzHRAt1SatKLxYpfjeLIjfkkZFA7dyN1hUxagl9IZGdkm9rEIuxkHsq7s6dZXhA d5tZKGC2lRYh3i5Qtdsu0C1E4ixhYbjtdruajzrMPnDA37OIW0WsIQktQOcW7MZK5EW6PN+0 hcRXTlsQlBBXapszTKWVC1SRdUUe1x4JRn9ppkYtXM8lw43PSQVq9/Pm48wGyNvgfB253Vu2 qVyRemM5bi1p99bnoyAmBG0h4O3w6nwNkObpkkfJhT1KoPnrzwGypdRXllo2Ydf81QV3Z7Ae wKpkL54YdGn7rnu/vdzvi7X95q/pP3/1gC+kLi1DdGmvdyL7DInqS6Tp+r2HAtGl9PtsBE3v gP5hKGZwhZU5wITw1HWXVVdUEGl82625VGYyucCfuguwH1cgAJxENjXAeN8AaXd0aZVnC3dk 8wIeJbfUPFAyfa61w69O9uTWJ4IgSMmCyU3PFKEuLe5HC6QoKQmHS6Q0UgzffPD90ATcFVUN c0FvMxdPnLq0SYdX9n13OX1BRvqCtelfrBm4YI2qS69H9Boc2fudKCpNiS6NjmVxHDddClha RlVHRLSY5izAUjJk4UnTqJkpVhoWq+yy9NZKSa8ngIaUsvrKE3o6wKprLGbGCmARZMFifdw3 kZLY9Y69VBT4uF57HlKJGOhXCJL7am/qHEEQpMTB5KZnUJciRUOJOF4ipY9i+OaD74cm9O8s k2/JknsE96oE3CqnLm3a8ZWcc5cHLFw34MuMAQvWDlyw1vH90t5DovoMJbo0G3Rp4D/HKxWP nBEULzKVO7qbO3a95FrX5ig23PwJXptQ8NyPKyRA+ogAPdJRhuHI7+ZoxEd39jzcldtF1976 RBAEKQkwuekZ1KVIUQEnTXwSII8a1KUlBvrjwRx6g+BOlYj/N8upS2M6vZrz/ZWBi9cPXLhu 4JcZg75cy/8e73NlL127Edl7KPn90r7DovoOX5d9+KF0KTHbYDKmYBLGEeVS1+6oNWTyJ+gr T3juxxVHBgqx2uCJbFt6fkM2zV/b89GdPQ935XbylRi05BZuKREEQYo7TG56pmh0KYIgCIKU Tgy6tHO3nPNXBi3ZMGjRukELQZdmMF36xPOgS29G9R0R1W9EVP+R0f1Hrt+bW6dJ4P+dGKl4 XLWPXfl4wxHlVle3y5WbP8G1V3c89+OKI4OFWyRxlxsOL5dsZnx0Z8/DXbldtOHhChEEQUoI TG56BnUpgiAIgnjHRZdefX3phkGL14MufV18v/SJF8pf+uVWk4Fjmgwc23QQjHEbco7WiUlk cZxAdCmZGpVSQApK4Ihyq6vZ1R7knLho394jhgBFlud+XHFkYLjcN/ul2PK7ZTPi43rtefiF cLsMdenTgnbovSEEQZDHCpObnkFdiiAIgiDeMejSl1/NOX/l9aXrX1+87nWiS9dQXVo96B9l Kly+frv525Obvz3FGl8fPP5S8xQWxwlIl1pbEu5kVz5+0JMALNatrrkoQe7Qvx+sCTMlyk9v en7ATz+u6AEqegnhY2k9QsTcLNG/Wz++UaKU/jUsO78Q3i35yq9MD9HqWr16agVBEOSxw+Sm Z1CXIgiCIIh3DLq08ys55y+/viRj0MK1g75c8/oXq6/f+71MlepBT5ardOXm3RYj3uPj/U2H T9WPT2NxnJLwocsFFIIgCIJ4g8lNz6AuRRAEQRDvGHRpp6455y4NWrh64IJVA+evGPT5il9+ o7r0qfJVrt7+reWET8kYT0Zm3tmQxLYsjoO6FEEQBCl9MLnpGdSlCIIgCOIdpy5t2uHlfd9d GDD/q/TPlqV/ujT9k6W//Hb/hcrVgp6uWO3HO/fbz1hMxnQytp/4vmFqRxbHQV2KIAiClD6Y 3PQM6lIEQRAE8Y5TlzZp23HvN+f6zlvUd+6XfT76su+HC679eu/5ylWDnq1c/adfH3T5cHWX D1aRMWdV1qmLjdO6sDgOfugiCIIgpQ8mNz2DuhRBEARBvOPUpVFp7fecOtvz/c96zP60x6xP YPx897fnKlUJeq5KzZ9/+6P7p193/3RD90829Phkw+5vrkS2fYXFcfBDF0EQBCl9MLnpGdSl CIIgCOIdpy6NSG2z68SZV6Z91HXKh12nfPDK5A9+uv3rsxUqBT1ftda1e3/2WbClL4wvYGze ++0PTdp3Y3Ec/NBFEARBSh9MbnrmEerSuwdmh2ecZ4tHyWMq7FbWYzsF79ocSayE2QfuMksJ puA357FSQtt+lOAtKhiP4r6VwMemqFp26tKw5LQdx053mvh+x/GzO46b1XHsrB9v3XmmfMWg F6rV+uX+nwMWbYUxcFEmjJxzP8R0QF2KIAiClH6Y3PRM6dKl5zNMuusxHafcyqp2c8OUgndt jCSVHtVNgAYKXf3qOQO7OUXRj0cepu2/JNot8vzA+XgdufIwz4qHiS0aHsVTq0hrFM0tLaqW nbq0UVLa9rxT7ce913bMrDbvzmgzatoPN+88Xa4C06WvL8l8YzGMLW8u3rL/3A/NUJciCIIg fwGY3PRM6dKlZh5TYbeyHtspeNfGSDi5P7KTNDRQ6LX0nIHdnKLoxyMP0/ZfEu0WFekD9zDJ i7SxAvEonlpFWqNobmlRtWzQpclttuedbjfu/TZjZqeNmtFqxLSrN24/VbZCUJlqta7f//PN xZveWrzp7cUb31789YFzV5p3wN8vRRAEQUo/TG56pqh0KTkPMPixwHZEkB76wX32gfNix+hO oTHkuyQWzFEtITZnZ2SohWUiJTtHqeLYdetNU3zKgjZzwOmvNinnLtcizCIcIFsOq9v1EmQA 25AG880nVmXJLLyEEuNMLS9Eb1rFcbGAsSWGIydxNt+cgPpxOFOTyzNQYIiCIrJrsQigbSWp cvlKM/ab4vA3dKWEq2YF2aHclImUAKPRQqniaEU4OwqJm2RbkFjLRYbwIFO3FiJKaUb3s8U6 kytdizBztoeJpUhvxSqNykMNpYx3yX45VjidkomSQdgVZCmxBSa3bkUpwxsLRaZjdQPLT7Dd UrLkLuqcJGZzWUPmMtfVIpQ781A4dWlYarsdx8+2nzS37fgPWo95r+XImVdv3HmS6tKa1+// 8fai9YMXrXuHjIyD5y41b49/jxdBEAQp/TC56Zmi0aV3D2SoByjrYKAcEeicHxGIB5+rZwe7 D4uFqSMfrydMNI/Y1OdKTmblGNsW0DzmhrhVW7j5EztPzeeKTb0WHkPmalolq3SQCeRcYmtM 7Uu1i4W+JG5qMzy9+Y4ptUwoCdSLNbUk0XPS3pR++FZA/RidaWbmrWYWGKO0CupCL+3etqdH REDt7OLunj9wnvyfCAW4FmLjWcwPhLNVYRSoVdjS7mwoBFsyRlkorjYnQxKB2CMTHkPmytQe qyWXZrrBnF2yPVSsOgdv6awY1TmfqgvibrsczQQakAWpc0bA3Sp5xVygORT8qejrUgFWAMx0 pmbgNve6dCZNhYJTl0akdcw6de7lmV90nPZpu4lz08bOuXoTdGnFoLLVaty49+CdhWuGLFoz dNGaIQtXH/zuYvP2L7M4DupSBEEQpPTB5KZnikaXqogjhjgiOA4JwkX1UReqWTtpyJMMhe9p afQ8SgQkkE52ZE8ct6Sap7Lw0YSw87mPa7EtYOa8BM3XtmLIxkgtZVtu2OK0pfTS5wpaBZMD B7Zt+8RibEmi27TejNerRpjy2RAuXjILRJRWQV3opV2Sg5NaRsa41PfTloh3KScgdZXuAHBS DLBPIoxGiZ7Y6OwsREzSoiy0bHYnexKBiNLC5cIUqyXXEDsu2R4mFmZKJHgTM3yRvmp2rY5m ttdXy7lVcyJSquF6vNKYvqIYTCr+8itolypW4Ep/wIC6869g1F3dk7FSYl1YOHVpdNsue765 0P3Dpa+8v6jzjPntJn189dbdJ8tZuvT+g2GLVltjKOpSBEEQ5C8Dk5ueKTpdCkcBjnZEYHvq MYG4WjvaiUVZyCmZyVhWhBu4m55fBis9WYhaAsVFbRFQ2gFkH1oxZeHmr9rVOatsDJcL4yVo LeiRHOmiO9OElrctTluqQYYEDHMFEyzIHEA27Regu7jcHApLTfDfj8PZV2aBI0qroC700i7J dSea3dpwqW/z55A4hrXt5VpYEMunpLAgEUajRE/s6qwXIkt5DcpCy6Y5EWxJBCLKxyXbYx3J uQfB2nHNVvBYxc+CmG3piI/wlhu6F0vELcZy8FXNK2HBBMvBvVslgeZkoTsIvOZXsGWCJbiA JzGezyD/soWW3UIkM9adPXs2MTgqPgxOXRrT4ZV9317u+9nqnvOWd5uzpPP0+T/c/vWpcpWC ylWrcfP+g5FLMuhYN3zJukPnLjfv0JXFcVCXIgiCIKUPJjc9UzS6lBwP+CFDnDeU0wjZV44J wkU/sagLMmc4zxfCkU/0/DKPLGSEhDnaFqjtuCZVFm7+ql33IQiLtiUXxksgjcs0zqSAjNOd lQ1bnLZUyypzkkuZywrC2Se8BEljbEmi27TelAVJ5Lkfo7NbZoExSqugLrQNt+QkpVJGxpjq AzZ/AjHxQiLe77UI+KYsrWA0SvTEXp01P2WhZXNJ5rwUYdG2nH6qTU8OK7EUO67ZCh6rRzJI AuGr+mjeplCRWCtHfTPOg81ZixbjZpHSvVslq60GQXegBJJfQbhaWD6WICUL+tupzMHmynCt S6dk11Gz4Dh1abOO3XLOXRmwYF2/z9f0nLei6+xFP97+7anylYPKV6956/c/xizfOHr5pneX bx61fPPh8z/EdsK/x4sgCIKUfpjc9EyR6FL13CFPC6qVzJUzhJirPuoCfByHivMZjmwiQs1J 5jxarQuru3xGUYurCRhkW81jyElL8TBf/rwMn/u6Fm5Vwh2X4Ha9ErCqjanOql2J05ZKuDJX XZRMZCoTqSUoLhfLfRz+FD2n1ptceOqHY3Z2ySxwj1KKyf710m7JlXAlqc1fgdhlF+fp95Xk 2vO1+HkgYGU9u4xGgS2xydl3Ie2Oadm0u2dIIhBRWrhcmGK15Gqchxv4ELFkKps33GGZQrMT s5zzzMJBqUABd/KLmSyPgurov1u1GdqBWoNAfGW+Aj8VLV/VCE7kDy1ZJlhkZMjPAJJAXpp1 D9WkxrpglDEPi1GX7j93ZdCX69O/WNfn09Xd5iz98c69p8tXCapQo/btB/8cv2bHuDU7x67J GrMmK/fitbiXe7I4DupSBEEQpPTB5KZnikSXWgcDC/IXadlxgBrF0YOcGCyU04J6uNAW0psC IefPy791y92UCBkgfz+JomSCQ49+TjG2zaHJ4XDEHERCJUz7FgWdHjD4K/eB5jwP5zmf12Jb 0BVDXIK02a6XATbbfbZwu/m2pRpumzPUO8bT0zV1UcqYLhYwtqSg5dR6Uxce+pGYnF0zC8wl hNX2bSqttI/k3E9rUnfRkF1AMXApwLX4fSCUF4jRaOFMbHc2F3K5Y9TMnXgm2HXp1kL0oDUj FuZYJTmsAruBDxMrggHTHbbiGaa7ZLwc7b4BZK1lEhTsSklyiFQqcGQ+SAbbgeUX8EK8abrm bjSnGiPbEvfQX10aYr4lAePUpTEdXsn57vKABZYuXdPtg6+ILq0AurTmi7f/+Nfkr3MmfZ0z ccP+8RsOHL18I6FrXxbHQV2KIAiClD6Y3PRMEenSQgZOFOp5Ag4ghXS8CAT1iIMEAtw5vHEI 8ih5PG+SfxWcujS6bZfss5f6frq272dre328+tU5y5gurVir7p0//3N65pGpW45O2XJ00ua8 vB9uJ3ZLZ3Ec1KUIgiBI6YPJTc+UDF2qn7HI/y/+GHQO6tICQR4tPCAjyKME36yKFqcuDU/r vOv0hdc+XNFj7kr49+XZ9Od4QZdWqv3S3X/+PzO358/Ylj9928mpW08e//Fu0msDWRwHdSmC IAhS+mBy0zMlQ5da6kbweA5ceNRDEKS4Q96nHtub5F8Fpy4NTemwPf9cp5lLXp69rPOspe2n L/rh9r2nyhNdWu/uP//vrB2nZ+44PX376WnbTh//8dfk7oNYHAd1KYIgCFL6YHLTMyVFlyII giBIccCpS4MT223J+7bV5AVtpi6E0WrSgqu3fnvS0qV3/vl/Z2w/PX3b6WlbT0/dSnXpa6hL EQRBkNIPk5ueQV2KIAiCIN5x6tK6CW02HjmbMPazpPHzk8fPTxz3+ZVbv/2jHPn90nq3//x/ Jm85OWlz/sRN+RM25eddvZv46gAWx8EPXQRBEKT0weSmZ1CXIgiCIIh3nLr0xbjW6w+fiRn1 cezoT+NGfxr77ieXb4IurRxUvuZLt/74z9Hr8kZlHB259uiItUcPX7od17U/i+Pghy6CIAhS +mBy0zOoSxEEQRDEO05dWis2LePQ6ajhc5uMmNd05MdNR8y7dPPXJ0CXlq1e58bv//H28gNv fnXgjWUHXl92IOf8jZhOfVgcBz90EQRBkNIHk5ueQV2KIAiCIN4x6NLmaRkHT0cM/TBq2EfR w+ZGD/vo0o1fnyhbOej5qi9eu/ev3gv29Pxid48vdnf/Yvfub69Ftu/F4jj4oYsgCIKUPpjc 9AzqUgRBEATxjkGXNmuVcfBU+DtzIod8EDnkQxhMlz5bpfaPv/2z07ztHedtbz93G4ztZ35s 1Lo7i+O4fehenRsRZBEx9yqzlQJK6WUhCIIgOkxuegZ1KYIgCIJ4x6RLW2YcOBn+9nsRg9+P GDwHxsUbd/9eplLQ05VrXb37Z+r7m5Pf35z03qbE2Zs2n7wa3LIbi+P40qXpWWzByEpX5BxV eHQltR5Fi9L2pLeemeW1fOUWmE35CaILvms3KGutawZPjSAIgpROmNz0DOpSBEEQBPGOQZfG pGbszw9/c1b4W7PD33oP/r14nerSJyvVvHz3j9iZXzebsSFm+oam09dvOHG5bkpXFscJQJeC iWDpOWWhuaqqkMwN8s9mFks6EQWc4tEoJiEoYm4W+Uf35K5karsOAHUpgiBI6YbJTc+gLkUQ BEEQ7xh0adOUtTknGg+aHv76zPA3ZjZ+Y+bF63f+XqZi0D8q1rx054+oaesip64Ln5IRPnlt xrFLtZO6sDhOgLp07tx0Kuiuzk0XatDmSuUlFX1mTQhIF/s0PSvLKgDYxaNJTLLa8EXfIqXB 4taBWyqnFUEQBCmJMLnpmaLRpXcPzA7POM8WRcyjrFUiwBuCIAhShBh0aXTS2r3HwtKnhA2c 2njgtLCB0y/+cufvL1QMeqJijYt3HjSesjZs8pqGk9aETly1Ju9CzRadWRwnUF0KUg/+IbKU /twtcbG7krWl74gsdBWG1K4KR5YHTJbFLh7ta0CUdu6RzPoP+CoYUtFcLu4IgiBICYPJTc88 Wl16PiM8fPaBu2xVOBSKDCv8xqAtU8KiuAM2XG+I3tIj6ARBEKQU4tSlNaIS12TnNew7sVG/ SY36T26YPuXCL3f+Brr07xVqXLz9oNGk1aBIG0xYGTJ+xeoj52skdGJxnAB0KRNzIEzT00GW Che7K1lLfcf0oV2eUqf0dDVSyUfD7eLRKSaVyuZNW1GB0xtBEAQpTTC56ZlHq0uLgkdZKwBc dOkjwKMuRRAEQQqCU5dWj0hYvedoSK9xDfpMCO07sUHfSReu3f7bCxUsXfp7w4krG4xfETJu efDYZatzv68R34HFcQLTpdTCRZ2iIzVXsnaoPgiyfTfSYZF5rJ/ltYtH+1ovbNslexS1M4Ej FYIgCFKqYHLTM0WpS8l35ChCJUnJJPZMEoq4WSg6iqqq83RHU1dutQCZh1t9J7Em3IEgsrnZ oa5MJBby6uzX57eQQHFgFUishfSWNmEUJTQcLQk3pRBAanFfxy2ycCZHEAT56+DUpdXCE1bu yq3ffUxwz7HBvcYH955AdOnzRJdWB10aOv6rBmOXhYxZEvzu4tW552rEtWdxnALoUgEz2FzJ 0iT6HHa7OFTy0Mz2fZO/jtimWyQXxKi9ceypEARBkNIFk5ueKTpdyvULmXOBw7UQ/0pNGar6 0f2JQFJjdaVkQe0utZQ80sEtCfVQHezZ1HS8fZjKdOpC25D4LSTQKuo+yuWImyd7EiXs6C0J N7UQyWLKY6yOIAjyV8SpS6uEx6/YlVu327svdR9Tr8fYer3Gn792+9+JLi1f/eKt+6FjljQY vSjk3YUhIxesPvxtzdh2LI7jXZc6LUzdaRtECJqUIPXStaBJZ/JImKen+9GltrUsQGYiE2lI CyPYUxFolMOKIAiClESY3PRM0elSoV2UBZ8S+aNIJBWpryhSS2k5FVxqwUypwLWU3yQu2WyB ciX7sy20DYnfQgJHRcPlqIiCpmQUvSXhpvmbL8F/dQRBkL8KJl2aALr0xW6j63QfU7fH2JcU XVqN6NJ3v2wwckHIiPkhwz9bc+hszdg2LI5TSLpUIl10u39xqBWwgrV9m79DW5IQsIBdV8YO gyEWoBUdVgRBEKQkwuSmZx6PLiWAuiEoeoeiiyfqZUVoORVcarH0Emr2m8Qlmy2QrKwutXbV he06OH4LCXSb+XJsO1ZBGUhmyo7eknDTCpkvwb06giDIXw2DLo1osWL30Rd7jKvTc1zdXhPq 9plIdCn5/dJyVS/cvBc6Yn6DYZ+FDP0kZMjHaw6eqRXbmsVxvOvS0oRJlyIIgiClByY3PfP4 dKmFw0IkkGKQ2sgZa+FSSxVYEr9JXLLZAuVKK6MuzPX9FxLoNnM6sAqz8DAlo+g5zJ2oPnKu RyIIgvyVcerSqtFJK7KP1ek7uW7fyS/1m1Kv/9Tz7O/xlqty4cZvoUM/aTBkXsjgj0IGf7jm 4OlazdNYHAd1KYIgCFL6YHLTM49Hl57P4LvEokse1QJ6SMy1nAqaXVnome/epTO/SXxlc5uz KqRZWZGsRCKJSKnkti0YNptSiKzo5agu8laZklH0loSb5g8+6iXwuam6UhJBEOSvg1OXVo9J XZWTH/z6rOA3ZoW8MTvkzdkXrt/9W5lKQX8vC7r019DBHzV4+4OQt95v8OZ7aw6crNWsFYvj +NKlFkLA/ed/luxBMFwWgiAIUvpgctMzj0WXnj9/ACYM4SchbhaK7NFyKrjVAmSe8NkZ50km v0ncstFpBlGeBDUFUWfMCE6KeIMIgq7cREolt23BcNp4RoBdjiwengG3lJWiRns6Ak9A/UR+ rZCiRbW5oTo16FeHIAhS+nHq0lpxrdcePtN4+LzwER9b4+LNX/9erjLo0spEl741BxRpyOuz Grw+c+3+/NrNUlkcx+uH7n//9/8OGFCyB1wCgiAI8teAyU3PFI0uLX1o4g1BEAT5y+LUpXWT 2m/I+675pIWxk2Esip248PLte/8oXzXo72UqX7h+t8Ebs0Nenxk8cHrIwGlrc07UjklhcZwA PnT//PN/794tqQOaRxAEQf4yMLnpGdSl3kBdiiAIghCcujS4ZectJy+0mrOy9QerYKTNWXX1 7u9PVaoOurQS0aWDZoYMnB6cPjUkfcrafcdrN01mcRz80EUQBEFKH0xuegZ1qTdQlyIIgiAE py5t1KbLjrOXu36+/tUFX3dbsPHVL77+6bc/nq1S09KldxoMnB6SPjW4/+SQfpPW7D1Wq0kS i+Pghy6CIAhS+mBy0zOoSxEEQRDEO05dGtGu655zV/ou2TRweeagFVsHLt/2y+//fKF6bdCl FS/8cqfBgKkh6ZOD+00M6TthTXZerehEFscxfegWi7/F6/Ync13/lO7D/o1d+ieRCuWvIck/ rqTme/j8AT8ushE9zM3+KCnSP4kMyR/XtRXFdXnKWaQ3tMjTFwUBv17cKA6vF6QAMLnpGdSl CIIgCOIdpy6N6tB13/dX3ly+eeiarSMydoxYl3Xzwb/K1XiR6dLQAVNC+k8K7jshuM+41dlH a0a3YHGcQHWp2/G0kI+tbi34aO1hO6CHz0K4BujDtfWH77AAB+MC3MuHx8+jUaS1rcfg4fIX 8NlUNNflqZkCduyNInu8CqtraJD2pzbqq+kC1C2ye4AUFUxuegZ1KYIgCIJ4x6lLo9t32X/u 8tDlX49eu2X8+u0Tvs66/ce/KtSqI3Tp5JB+E4P7jA/uPXb1niM1ohJYHKd46lLowJjNzU4o 0nO5d4rw9FrA1G5hRdipv0fD1+NYPCjYs6mIrstTM0X5/C+6x6uwuoY89LmsdurrCV6Aur7S IcUSJjc9g7oUQRAEQbxj0KVtO+//7uKwpWvHrtwwae3mqRu23/nzX5UsXXrxl9uh6ZNC+k2o 32dc/V5jQJdWj/SuS8m/FHZ+E2sJPwmypYCd3qw8cAK0sJ0DaZz5bOh2aDTYRXaCsqnY5VkS SoKLaFi4y0vQzp0++pcRFloNPQvgkp/Yjf0Asn9ptVIb3c3Xa2GFsYWCm92B5Wi8D4Y+RX8S exUIUpO45ocNWIiESoxaRGS3VdaqOvtkyA22Y8tCkJm0TcfN068LVulzLX9+dXJXKatlBw9R Q3grea1NYx7VrPbJ8hOT3jFPa+2ITDILR6nPUPOrBRQ3uTTn11JYKO0p18WtNEAUoA50S3EV UDerrqjjry7kcX+8ACsdWyAlASY3PYO6FEEQBEG849SlkWkd9n3z/TtfLH938aqJy9dNXbv5 7h//rFTrxaC/v1CB6tKJIf3G1+89tl6v0at251aPiGdxHDddSg9nfKGcxuC8ph3WOCa7I4/j mGfMZasocNrJ4VFYlA7AUzWrdtKQtSQLR0Nafsud+ai7Sl2ZxfLWcaTTDDzE0Y96XbZaMqm+ IRKr12vhrGvhZndg1fV9H7Q5AEu9C4mjrpWf2ciCR7INayk3VBd9ISBWWcO1T7JwBhOM/etZ 7dh3SXJioF8hmdyHmbEF4mG4XtEM3VdKkFg1EXNXItWFdGCAgUZbZZVgpQTgxUKRpdiC+ZCp W35HUwTwES7kGrWkdCEmDFgLuwglC8BaazvGuqQScaFfYdMWYc+AFH+Y3PQM6lIEQRAE8Y5T l4antss++d2gjxYO+WTJ6AUrJn617s6DPyvXqk106YVfbjfoPyG477h6vce+1HP0yt251Tzr UnkA009whvMcxWT3fxQ04Xb8c9oD7oykkD72AEcB3SDdNbs9ypFF4NwhFkM/emMyzJbA3j/D YXbryM3uQHeU+d36JLg0BzjL2iwylGzILNxuT2Aqpfm49unepHmLhNp6l9jbcvRLvhrKKZV0 D7lBZ1mO4nqPYmVvhG+A3f7V8tMD9KzOdAAx2W0UGatG+cpvr+ZE9yC5ItLT7XcSnGgF2JYb AdblJh5GSyk+ejqkBMDkpmdQlyIIgiCId5y6tGFSm6zj3/Sa/tnA2Z+/89HC0V+suP37g0o1 a3Fd2m98cB/QpWPq9nx3xa7cquFxLI5T7HSp9wI+0pMtBW73fbJ07OoGJT9M+Qbx0fpyr+Hc MfsSqw2rgs1dacgWojXkUsXd7kB3FGVtRQmysPpoaBg2bI1ID3OH9gwmL9Xm2qc5vYVb/zKZ LdIZwC28DPnKXGwt8UC3hiCT5mdh8xYN2DsRfrABX6/OTQfAAeyWn57IFm7PxiAxFlrD3Fvk JvjKb04vs1M0D7qnZ3BgVQuwLjfxMPJV9dHTISUAJjc9g7oUQRAEQbzj1KXBCWnbjpzuPO6j 1yZ81H/6JyBNb937vWL1mkyXhvQdX7/PuJd6janTYzTo0irhj+/7pd6OdQHkd6ZnHsoUUCJ9 t+DY1Q1KHphKbAndazh3XHzd7oHNXbgRu/F6Ldw6crM70B1lfrc+CW57JrueX1mZO7Rb/aZ0 64U4uV2Ar2sjkFi1C4M/N/FeRDm9rhLJPe0wF/iixNm8ZVJ7FlEAJuTXLUGTZqWDhS6Jgx4g 3Cn6ygmJVatZ/mBVogLNT/ylUfewcoFNLUqs1EevFGBdbuJh5Kvqo6dDSgBMbnoGdSmCIAiC eMepS1+KbbXp0MlWw99rP3L2q+M+GDDz0xu/3a9QrXrQ30CXXrsdbOnS3mPr9ByzYndulYf+ OV77YY1jsmt57EdJumsP0StLzHalJskusqml6Aav4pbewrGrG+R9gFkAWQTOHTdf9QIUNHfF R3Unc9tddaviYqcZtA3dEfZ5frWwDRKjt0Ewl9Ssak6XDrXcxN9fIbc+iZdxw1bDhFZBL8fg N4pvipRqO2QuChnTADwTdZBtiYQsDV8odmtH2smPwJIKIExhpvjLsqIYoO8YsbvQ4lDHZjLn Z+5ySSEtc396YcJB7qg+Midks+UOoK6ShIbZXfR0SAmAyU3PoC5FEARBEO84demLzVtuOJgf P3hG8tvT2g2f2X3ih9fv/lauSlWhSyfU6zv+pT7j6/Qet2LPkSoRgf93YvTznLXL0E5pTrti AexHOrqrHw31whI3u6wAedQ+Yc6gv5fH7S55RBaO0r90V/LbA9Schhpu+U2+DD2E+RiNFPP1 utV17Ydi5VJNepvqffbRkrrF7XoigWsSF39AXrDSjII90mcJjp5J2WH+ehLF217Ngt8ovku+ siDz4+WSR7/lVhP2jmBbe1zM94darVBlaiur5HHpR1SlKPkpdFeLcs1PUbIJJ9m+cn/UlgF1 CXM603MHWJc78DDyVRg0ZFKkWMPkpmdQlyIIgiCId5y6tFaz1HX7TzR5fWrzQZOT357a+d3Z 127/WrZyFapLf7kd3G9S/X4T6/Wb+FLfCSuy86pGJbI4TlF+6OrnQv/YT44cN/tjQpxXGdAe nlS94PY4Bvo88cAjfcoUs+dnoVGw6yqCRxNBCgSTm55BXYogCIIg3nHq0prNUtfmHA8fODmy /4TYQRPbDJ328627L1SszHRpSPqU4PQp9dOn1EufsnLvsWrRSSyOU5x0aQmB6FDlvG6XqUig FPrzhCREbfRYwFcDUnxgctMzqEsRBEEQxDtGXbom53ij9IlhfcdF9x+f/NbkH2/eeb58JdCl FS/8cqfBoOkwQl6fETJoxuqc/OpNU1kcB3VpAaC6R4DH8IekkJ4n6qOCovSRw28/3nqkuMDk pmdQlyIIgiCIdwy6tDnRpaHpExv0GRved2z8oAk/3Lj9bLmKQX8rU/HC9bsN35xNxlvvhb79 /poDp2o0a8XiOPihiyAIgpQ+mNz0DOpSBEEQBPGOU5fWorq0QfqE4N5jGvUeE5M+9ur1W8+U rRD09zKVLt64G/bOB2HvfNh4yEdhQ+euPXSmVmxrFsfBD10EQRCk9MHkpmdQlyIIgiCId5y6 tHZs6tr9xyxd2qDX6Ki+Y678cuupMuWD/l628sUbv0YM/zhixCeRIz+NHPXZutyzLya0Y3Ec /NBFEARBSh9MbnoGdSmCIAiCeMepS1+MTc3Yfyx0wHjQpSG93g3v8+7lazeffKFc0BPlqly6 da/JmAVNx37ZdNzCmHELNxw9VyexA4vj4IcugiAIUvpgctMzqEsRBEEQxDtOXVqH6tJGA8aH 9Bkd0mtUWK9Rl67d/Mfz5YL+UaHa5dv3Yycvi5u8LH7KV/FTl288fqFeSmcWxzF/6NK/YUL+ gIntb88WEp7+AxSl9b++UZoo4ucJgiBIgWFy0zOoSxEEQRDEO05dWjc2Zd3+Y2EDxjfoM7pB r1GNeo68+PPNJ54rF/RkxepX7jxImrUmedbalNkZKe9lbDl5ObhlVxbHCUSXagvqUkApUnJ0 Kf8jo5SHaecxXA3pXf3jqLwF7ZosrNbcH1+37qkT6lIEQYohTG56BnUpgiAIgnjHqUtfik1Z v/9Y+IBxoX3ebdBzZKOeIy7+fOPvz5UNeqpSzau//pH24cbWH21qM3czjK1nfght3Y3Fcdx1 KZUZYmIZCdZKWwSKJ5HmyalIUS/+YXkMV0PaN+lSjn3t4/F1617cocK8VQiCIIUAk5ueQV2K IAiCIN4x6NLmyev350Wkj23UZ1RozxENewxjuvTpKrV+/O3PDp9u6/jZ9k6f7+j0+c4dZ39u 1K4Hi+ME8KFLpMrcuelMh6TPzSJrLkVAuXCkFqIRV4lmoQhvReZYm8Y8qlnkAFh+YlJll0xr 7YhMMguFprLZzJAMegUKSaDEy6W5Lq2noyRVrpdb9Qapg9qFvu0Dqx22ACCTFmZfg7/b42t3 RRAEKe4wuekZ1KUIgiAI4h2DLm2WvD4nL6L/mEa9R4b2GB762tALP9/427Nlg56pWvune//s smB31y/3wHhlYXbWuV8ad+jF4jiB6tKrWUS4ENlC9aale2AmBBDRUVzDEA/AWpIF2+Ayh+4r 0onEqomYuxKpLhxiCQw02iqrBCsl2K4e6AbpRxeFFEc/zMNXXUezBPARLqSWlpQuxERCqzhz ObF14GjBvgZ/WJseX3P3CIIgxRgmNz2DuhRBEARBvOPUpXVjktbvOxre992GPUc06D4spNuQ Cz+BLi0T9Gy1F3+6/69ui/d1W5LzGhn7d31/I6JjHxbHCeBDl4kTEC7p6SBbHLqHoWgY4iH1 jNygsyyir7R4Xf2IlZu+snSU9tXy0wP0rAED4RamFvRavur670L3ILngPjtUaQCQFDa0ZPaW 2Nr0+PrvHkEQpHjB5KZnUJciCIIgiHecurRO08R1e4+E9R7VoMfw4G5D67/yzvmfrv/7M2WC nqtW5+f7/9Fj2YEeXx3sScahPedvRnbuy+I4gelSKlO4SFF0i00CcQ2jeGhABs3PwuYttJBd FAk/q6Grc0FGMR1l+emJ7OEFg7Ys8/CkoibBV11zFyRCQfOge4YYz+jtOFswrPltpXYl3tw9 giBI8YXJTc+gLkUQBEEQ7zh16YtNWmRkH2nYa1Rw9+H1ug19ierS/0N0afU6137/j17LD/de ASMXRvaFW1Gd+7E4TgF0qYAbiICRskXRMHZlxGEu8EWVO7q3TGrPIgrQ+vRHTukPn9IlcdAD hPtDIhsiWFnBpuT2VdfUhSkjW7BcYFMyBojejrMFw1qvJQ12VwRBkOIOk5ueQV2KIAiCIN5x 6tJa0S3WZB8J6TWqfo+RL702vM4rQ7//6QbRpc9Xr3vt9//suzK378ojfVeRkX3xVvTLBdel dpkj1Qp8FTtkLjSMM8RCyBziIBUPWbEFTcMXit3akXbyo66kAv3hU64R9bKiGEOv6RmtCYCu ob5yeb7q2sMJ5FK4P71g4SB3VB8Lz/3r7dgbcqzt7qqDPRRBEKS4w+SmZ1CXIgiCIIh3nLq0 ZnSL1dlHgnuPrtdrdN0eo+q8NoLo0mfLMl3ab9WR/quO9l9Nxt6Lt6Nf7s/iOIWhS+mMQX9v lGsYZ4iFKnOozOJe1oKmId/+lFpIFlCMltUKVaa2sloegNbQLC6IZizsIXRbuzoPdS2Ek7ws 5b6plwLYloH1r/Znb8i2trurDrQHiZfqCIIgjxUmNz2DuhRBEARBvOPUpTWILj1av++4en3H vdRnbN1eY77/+eb/ea5c0AvV6/7y4D/TVx8VY9/F2026FFyXIjpOHYcgCIIUF5jc9AzqUgRB EATxjlmX7s0L7j8hOH1S/fRJ9fpNOH/t1r8/X57p0gGrjw5Yw8a+S6hLCw2iSvHbhgiCIMUV Jjc9g7oUQRAEQbxj0qWJoEsbDJgUOmhq6OtTGwyacuGX2397oYLQpUcGrjlqjX2XbjXt8hB/ 9wih0J+jBfB7pQiCIMUXJjc9g7oUQRAEQbxj0qUt1uzLazRoctib0xq/NSPsrRkXr9/5e5mK VJf+/p8DV+cOXH1k0BpQp0dyLqIuRRAEQf4SMLnpGdSlCIIgCOIdpy6tGd1i7d688EGTI9+a Hjl4ZuQ7sy7duPtE2UqgS+uALh2w6vBAGKvJ2HfxZpOXH+K/X4ogCIIgJQQmNz2DuhRBEARB vOPUpbWiEjL2Ho0cNKnJ29OavjOz6RCiS//Bdel/DFh5cMCqgwPp2HfhRpOX+7A4Dn7oIgiC IKUPJjc9g7oUQRAEQbxj0KWR8ev2HokeNDHm7WnNh8xsPnT25Zt3/1GuUtDzVJemr9g/AMZK MvZduN6kc28Wx8EPXQRBEKT0weSmZ1CXIgiCIIh3nLq0dmTc+r1Hmg6a0PztKXFDZsQPm3Xl 5t0ny1UGXfriL7//q//yvel87D3/S3TnXiyOgx+6CIIgSOmDyU3PoC5FEARBEO84demLoEuz c5sNHBf39uSEIdNbDJtJdWmloOervXgNdOlXe6zRb9nu7PPXojv1YHEc/NBFEARBSh9MbnoG dSmCIAiCeMekS2M3ZOc2Hzg2/q1JLYZMTRw2A3TpU1SX1r52/5/9lmZZo+/Sndnf/xTdsTuL 4+CHLoIgCFL6YHLTM6hLEQRBEMQ7Bl0a0XxD9uHYAaMT3pqQ+M7kpKHTrt68I3Vp3yU7+i7Z DqPP4m3Z536M6vAai+Pghy6CIAhS+mBy0zOoSxEEQRDEOyZd2mzDnkPN00clvDEucfDEpCGT r94AXVoRdGmta/f/7Ltoa59FmTB6L9ySfe6HqA7dWBwHP3QRBEGQ0geTm55BXYogCIIg3nHq 0trhMet3H2zWb3j8oNGJb41LGjzx6o3bT5UFXVq11rV7f/ZZuLn3lzA29Vqwcc93V6Lav8ri OPihiyAIgpQ+mNz0DOpSBEEQBPGOU5fWahyzbteBmD5D4waOavHGGJCmV4gurQC6tOa1e3/0 XvA1jF5fbOj1xfo9316ObNeVxXHwQxdBEAQpfTC56RnUpQiCIAjiHYMuDWu6btf+pr3fiU0f nvD6uy3eGH3l+q0ny5RnuhTkaK/563rOz+j5+do9Zy9Ftu3C4jj4oYsgCIKUPpjc9AzqUgRB EATxjlOX1gxrkrFrf5Neg2P7D4sfNDLh9VFCl9a4du8ByNGen6/p8dnqHp+u3n32YmTbl1kc Bz90EQRBkNIHk5ueQV2KIAiCIN4x6dKmoEujew1u3n9Y3MARIE2vXL9JdOlzVWr8/NuDHp+t 6vEpjJXdP1mx+5sLEW06szgOfugiCIIgpQ8mNz2DuhRBEARBvGPQpY2pLu09uFn6sNiBI2IH jbz8y81/lCkHurT6z7/93v3TFd0/WU7Gx1/t/uZ8RJtOLI6DH7oIgiBI6YPJTc6WLVuGUYYP Hz5mzJhZs2adOnWK7VFQlyIIgiCIdwy6NDwmY/eBqD7vxAwY3nzQSBhEl77AdelrH3/12sfL yJi3dNeZ7yNad2RxHPzQRRAEQUofTG5y7t+/v3btWiFKjx07Bp+AbI+CuhRBEARBvGPQpREx GXsORPUd0nTA8GaDRsIQurTaz7/df+3jpaBIX5u3BAbqUgRBEOQvApObCn/88cf8+fNBlO7Y sQNkJ7NyUJciCIIgiHfcdGlkvyFNBgyPGTQiZuAITZd2m7ek27zFMF6bt3jXmXOoSxEEQZC/ Akxu6ty7d2/v3r0PHjxgawXUpQiCIAjiHaMuXbvnQETfd6LThzUdMBzGpV9uPkF0aeVqP/96 H+QoHYtgUF3agcVx8EMXQRAEKX0wuekZ1KUIgiAI4h2nLq0RHrN29/7wXm9H9h0S3X9ok/5D L/1y44kXygpdShSpNXaDLm2DuhRBEAQp/TC56RnUpQiCIAjiHacurd646ZpdOY26vxHe863I 3oOj+gy+dO3GE8+DLqU/x9v940XdP15sjd3fnItsgz/HiyAIgpR+mNz0DOpSBEEQBPGOU5dW C2uyeue+0K4DG736euPX3ojo/ualn68/8XwZpkt7fLK45ydLyPh06Z6z30e1xf9ODIIgCFL6 YXLTM6hLEQRBEMQ7Tl1atWH0yu1763fs36BzesOXB4R1HXjxp1+eeK5M0PNVql377X6vz5b2 /mxZ78+/6vP5V9nfXohu15nFcfBDF0EQBCl9MLnpGdSlCIIgCOIdpy6tEhq9Ylt23bZ967Xt G9yub2jHfhd/vPb3Z19gurTv/OX9vljRf8HK/l+u2vfdxSYdurA4Dn7oIgiCIKUPJjc9g7oU QRAEQbzj1KWVQ6OXZ2bXbtX7xZa96rbqGdy614Ufrv39meeDXqha/Zd7vw/4ctXAhWsGLV47 aPG6nO8vx3R6hcVx8EMXQRAEKX0wuekZ1KUIgiAI4h2DLm3Q5KvM7BopvWokda+V9FrdlNcu XP35b089B7q0xvX7D95csu6tZevf/urrwcs3HbzwQ+zLr7E4DmREEARBEARBEARBEO8wPcmp 1KDJsi3ZVZN6Vo1/rXr8q7UTXjl/5ae/PfVsUJlqNW/8/seQ5ZuGrtw8bFXm8NVbD1/6Kb5r DxZX8vn+++/ZrJQCF1jqr7EowJuGIAiCIAiCII+YSg2agi6t0qJn5bhuVZt3rRnXBXTpvz/5 TFDZ6jVv/v7niNVbR67ZNmrtjnczdh65/HNC154sruRT6uUHlaUosQIGbxqCIAiCIAiCPGIq hzJdWim2W5VmXWs0f/n7yz/++z+eCSpXo9bNB/8cvXbH6IydY2CsywJd2gJ1acmBylKUWAGD Nw1BEARBEARBHjGgS7/K3Fs1iXy/tErzrtVjuS4tX6P2rQf/HLN255i1O2CAQD1y6aeELvhz vCUGKktRYgUM3jQEQRAEQRAEecRUaRSzfOve6qm9qyZ2rxr/ao34rt9f+Unq0tGrt7+7atvI VVtHrsw8fOGHuM7dWFzJp9TLDypLUWIFDN40BEEQBEEQBHnEVAtrtmJ7Tq02/Wu07F09uUfN pG5Elz75bFC56rXI75cu3zLsq81Dlm56Z8nGg+euNOtg/+/EuLF4yZJOnV+GsW3bdmZS+PDD jzq/3AV280+eZCbPQKA1Br3++sxZszdt2vzrr79aWzCBJRhhS7hZW05KvfygshQlVsDgTUMQ BEEQBEGQR0yNiOarsvbX7TzoxQ4Darft92Jar/NXf/73p54NKlut5o37fwxevOGthevf+DJj 0Bdrc7691KStq8yzMe/jjy1dCuPo0aPMSlmyZKnblhdAaoKatcaqVavHjZ/Qs1fvXRSYDBs2 HIzCAXUpWyCewZuGIAiCIAiCII+YWtFxa/YcDOk+uH63t+p1fb1ep/TzP17796efCypTtcb1 ew8Gzl+T/tnqfp+s6vPxiuwzFyJbd2Zx/lB1KYwLFy5Y9s2bN6v2gulSNuNs2rTZ+tYoTJiJ 8zC6dGPvoN4b2ZyuwmZ9wxa2PW/oGfwD/hZ6Xc9JqCz1KLG+mRXGivH0gXb7+DDdJ/1GGT1c 8XzTEARBEARBEAQpHGrHJGTk5Ialj2jUb3jDPkNCe7x14afrf3v2haDnq1S/9tvvfeYt7/XR Vz0+XNZ9ztJdJ78Pb9mRxfnDpkt79uoNxtOnT6tGGIWiS3/99VdLl7K1wsPoUiJnhPikwk3I GlgFLtoCU3rCm1QmM9pB797ek1BZ6kFiWYmFyv5m1iwyD6xbzxR2Wn53dL6Z1TtM2GVJb8U9 3TQEQRAEQRAEQQqPOrGJ6w7mRQ0eF/X22Mg3R0cMHHHx2o2/P18m6LnK1X6+e/+19xa/OnvR KzMXdpnx5Y4T3zVKbs/i/CF06Wvde4A4hMnwESMHvf4GTF55tVu317pbu4WiS4Ei0aWK+oRp 71nwP0u9KRsBEJAkA2chFdXAAJJQWepXYhFhZ/rWb0DdeqeQ05rTbewdNmsW39EfRQ/FPdw0 BEEQBEEQBEEKkzoJKRtyjzd7dwoZIyfGDB136frNJ8qUC3q2YtWf7tzrMu2LzlPmd5r8eYeJ n23LOxvaoi2L84fQpVu2ZNq+d5qZuXXePGYp1rpU6hhrAiLIUnBiYsk6BjcRrdS7N/8eJHfQ lRI1WR5u0krko/5qcv/SikJlqQftLQup0EIbRfOsJFgZLIi4iYt17ALqxcp95qDfCT2bx7tE 76twI0AgTJUAUtayCB9feHhiIAiCIAiCIAhSmLyU1HLjsfyESTNbTJ6ZOHF6i7GTr9y8/WTZ 8kHPVKjy4+3fOoz/pP24j9uO+bj1u3Mzc08Hx6WxOH8ILbp9+w5Y9uufbi3fnzMHlpMmT7GW xVuXEilDlQz5BhxoHPGF6xtF6hAZZQkhYrRJIoDKLFs4BZbcW0GmozlEhNnbCJWlHnSpOR+t am2RqdoxINoge44EYle5CobY0ufyznITTP3fJWIF9cymVgALVAPovSfYrsKMlycGgiAIgiAI giAPyf/7//1/x8/+bM3rpbbalH8qZeb7LWe932rm7FZTp1+9ffup8hWCni5f+Yebv7YZ9WHa iA9bDf8gdeiczQdP1mvW0grzi9ClGzZsgOWVK1espbU7fsJEa1nMdSkTOUzqMBEnpRzRO1Lq cC9FEUlXgNupSpJmN6gbFVOzlCxKcn9QWepBl5rVmlpImcOUYVn0fmy7huSKv7hAC+Jo31VS G1GrW8XgX8sitpQmSHvGi9Xw9MRAEARBEARBEOThuPXrn1/vPmPNg1ulZZ463fqDD9p9+EGH Oe93mDXzxzt3nqkAurRspas37rZ8573UwbOT356V+MbMjTn5LzVJtcL8YtOlwOkzZ0CdWvMS o0upzNmo/mKpqhIVyQOA6qELXVwJ3aSJKBrq8ft3WhUtiW+oLPV7jfo1SNRCfC59xYXpF2vb NeQ2+gvsV0dcfN0l1d8qChYVyyIS8MZ84umJgSAIgiAIgiBI4RGa1nrb6dMd537w8rwPunz0 fpf3Zv50586zoEufKlPx6vU7yW9MTxo0LXHgtPj0qV9nH68Tlczi/OHUpYJLly4NGz7C2l2+ fMW9e/fYhjdAaq5atVqM/JMnLaMlQa3/qKkYD6tLmTISYsaSPULnkCVbSJWliiXpQBNpooiJ JNXdAIlT9v14q1BZ6uEaSY/ykqCg4+/x8rmwyaYUN8OurXnAltbHLsP3XSIpxF1XLkJJpWyQ dlQfM96eGAiCIAiCIAiCFATx47vqz/E2ap224/SprnPndJv7/msfznp19rSf7tx+tkL5oKde qHDll9uJ6ZNb9J+U0G9SbJ+JG/bk1YlItML84kOXWnYxcnNz2YY3LAmqjp69etsm6mBhDjzK D5u0sssfsm0hnIQiopAAa5v/3SNuYYl0d4504puyEsEQYofKUm8SS83NMqttiTn3I3+cyLKo bs5dQF6IddvY2lqodYlFyWaLU+toiBS2bSVAqWKV9Y3Xm4YgCIIgCIIgSOCIH99Vf463cVqr XadPvvbBrB4fzOzx3rTXpk/66fatZ8uXC3ry+QpXrt1u0Xd8Qp/x8b3Hx/Yat2H30ToRLaww v3z62WeW7Ny4aRMzcW7evNml6yvW7hdfLGBWz+SfPGlTnj6G9d1UI6VeflBZihIrYPCmIQiC IAiCIMgjJqJl6u784z1mTuk1Y3KPqRO6TRjz082bz5QtC7q0/JVrtxJ6j43vPTau15jYnmM2 7D5SJyKBxfnj/v37d+7chfHgwQNmUtiwYQOI0u7de9y7f5+ZCsrPP/9s/bwuDJjAkm3861+/ /vorm5ko9fKDylKUWAGDNw1BEARBEARBCh3nj++qP8cbmZK0+1hej0lje0wY/drYUV1HDPvx xo2ny5QRunQ0jPjeo+N6vfv17ty6EfFW2MPTpesrK1euYovHQamXH1SWosQKGLxpCIIgCIIg CFLoOH98V/053sjEhN1+wSZnAABWkElEQVRHDr82ali3EUNeGTK405tv/vDLL089/wLo0nJX rt1M6PMujHgYvUdt3JP7UmSh6dIzZ7755Zdf2OJxUOrlB5WlKLECBm8agiAIgiAIgjxiIuNj dx06+OrgN7u++XqngQPa9ut/9edrTz77HNel/UYl9LXGyI3ZufWiC02XPnZKvfygshQlVsDg TUMQBEEQBEGQwsLHj++qP8cbEdts1/6croPSO/fv275377TuPa/+9POTzzwb9OQL5a78cjOh /8iEftYYsWnv4fqoS0sOVJaixAoYvGkIgiAIgiAIUlj4+PFd9ed4I5o13ZWz9+V+vTv26tHm tddSu7565cef/qHo0hEw4sm/w0GXBjeJs8JKAaVeflBZihIrYPCmIQiCIAiCIMgjJiImOmtv dufePdq/1i3tla7Jnbtc+fHHfzz9DNOl8f2Hk9FvWEL/YZv2HQpuirq0xEBlKUqsgMGbhiAI giAIgiCPmIim0Tuzd3fs0a3NK11TO3dO7NDp8g8/PkF06fNlr1y7Ed9vqDUS+g1dtmXngOGj Q5rGNYghI7QZjHgymidYo0HzFiHNWwQ3I6O+MoKbt2gQl9QwIblxUmpESsvI1FbRrdKatG7d tHWbpuTf1jBvktYajFEt0yJSW4FPeErLxsktw5JS6YAJG42SWjZMahlKRqsGZKSFkNG6QXLr 0JQ2DVPbwmjUsh2MsFbtw9LaN07rEN66Y0QbGJ0i23aKats5uh0dZN4xqg2MDuqIhtG2I+w2 adupaTsyYtp1jmnfOYZMxOgY01aMDmS06dAURuv2TWCktYumI6pVu0g22kew0SGcj8atOoTB aNkhLLVDo9T2MBrCSJGjEQxiJw58dGwEo2XHhi07hqaS0SC1YwgfwXzQZScyWnYKbtk5uBUZ 9Vt1rkdH3Vad66R2rJ3SoVZS+xot2laLS6varGXlJimVohIrRiRUDIur2LB5hdBmFfmo1Ci2 Snh8tagWNZom1WqeWich7aWktsEtO4SkdQ5u3Tm4TZfgtl3rt+laL+1lyPxiaqfayR1qJbav mdC2RnzrGnFpteLSasen1YlPq5vQul6LNsGJbUOS2oUmtw9N6dAwtQNcCFwOHR1g0GtsH5ba rnFq2/CWbSNatYtKax/dmo0ouKVp7SJatm2ckgZPg9CElJD45JC45GAYsfBvSnB8akgCjJYN WrQKTaQjKa1hUlpoojXAQiYNEls3SGrTILltKNxeeAhadyIjrWNYGjwi7RqltmmQ2Kp+fErd Zom1myTUioqrHtG8alhMlUZNldGkKoywptXIgHl01YbRVUKjqjSAEVk5JKJSsBjhYlRWRpXg iCohEVUbRFQLjaweGlW9YVSNRtE1wqJrhjWp1RhG09rhMS9GxNSJbFYnqnnd6Nh6TePrxSTA 6ygkNik0Prlhi9RGiewV0Ti5FYwwGEmtGlkjOS0spXVYahsYjVu2DW/VNiINRrtIuIGtyYhu 0x5Gk7YdmrbrQJ7M7Ts269CJjs7WJAZG+05N2sELAV4U7SNbtwtv1aZxalqjZLiHqQ0S4LYn BjdPqNcMuop7qUksdFgnujkdMGEDjHWb0HlUsxcjY2pHxNQKh0uDa4yu3gguObJaKLkDVULI DakU3Lhi/bCK9cIqWKM+jMYV4V6FRFQJjazWMLoG3JPIZnWbxNVvlkDfTFIaJ7WMSE2LbNkG RhQdkS1bgyWc3IqWYYlwi+QgFrhRKWnhcsB9gxuY2rBFcoP4pODYxPpwRTEJLzWNg0HudjO4 24mhcUmNoFZiakRyq8iUtEioyEdECoxWUC48uSUbSamNE1Maxic2aJ4Q3DT2paiYF8Ob1GwY VTUEHvHGleUIh0efPPRwXY2sB71prfAY9qDTUTcy5iU66tHxUkSTOuHRdRpH1w6LqhUWVbNR VI2GUdXJc6ZpzfCYWhHNa0fF1mkSXxf6b5ZYLzapfmwSeV3ACyQhpQGMFimhMBJTGyalNrLe VOHak1s2hrdZMuDOsHmYNeiuHMyHj9RW4XCflREB79tw89loA88W8qzjT7yI1u356GAYaXTQ eSR5Q4Z35k7R9I26SfuXYUS3fzmq3cvw1h0Bo02nxvTVCq/c0JYdQlM7hKR2CE5uXz+pLby9 vATvM7Et68Sk1I5OqhWZUDM8rnpY86qhMVUaNKkUHF0xOKpi/cgK9SPK14+oABNYgjEkulJo kyoNY6o2iqnWuHmNiLhaUQl1mrSoG5NUr1ly/diU4LjUkLiWwXzUj2tZLzYVxkvNU+s2S6kT k1ynadKL0Ym1o1u8SEcdNhJehBEFI16MOtHx9Zq2CI5JbBCbHBqX0ighNSwRnjzWE4kM8rS0 nr3kaZkSmqA8M5vRAY9vDExa1G+eGBybFBKXFBKfBD6h8Ymh8S1C4xIaxMaHNI8Ljollo1lc cLP4kNgEeE6GJSaFJ6dEpKRGpqRGpaREp6REJieHt0hsFAef3XEhzeIaNI9vEJsQGtcCPqnh yRzVqnVM2/bN23eM7dAptlPnuM5d4l/uEgejc5dYOprT0azzyzBiOonROaajHE1hdIDRqWmH jk3bd2jSrkOTtu2j28JbUNuo1m0i01pHtEoLS4WPdXh+wrUk1o8l7yp1Y2LrNI2taw06r9Mk 9sUmsbWjm9eKal4zslmNiJjq4U35iKlmjcbk3bhaWDSM6mH07RTebeDtNKJprYiY2pExtSJj aoI/OMBLMpS881Qi7zmNKrzUEEZFMkIr1mtYJTisWkhY9dDwWo0iaodF1gmPeikyul5Uk+Do piFNYxrENAtt1rxh89hGsbFhcXFh8XGN4uIawoiNC42Ng5tfPyauHrRtvfVFN38xslntiGbQ ALzAazWOqdmYTojFes3GwWu2HjyaccmhLeCFCa+mtnBmiErrEN2anENgRMIBJo0eGFLbNUxp G5rUOiQxLbhFq3oJLV+Kb1k3LrVufGrdhFYvtWhdL6lN/ZR28IoIhY+zNp0bt+0cDi+Zdi9H wssHXkT0pRTdvjP826QDGU2t0bGLOmIM42UYTdmwHtDOTWDAZ4T1MdEOTk1wdoK220S2ag2H t0YtkkNjE+AZCO+B8MZVq1FkjQaNqweHwahWv1G1eo2q129UIzisVnBY7ZDGdULDX2oUUT88 KiQyOjS6aaOmMY2bN4+Ii41KiG+SmBCTkhjbMik+LTkhLaVF65TENqmJbVJawLJlUlxqYmxy i2aJCU0T4qNj46Kax0bExDZu2jwsulmj6GYNo2JCI2NCI2A0bQgjsmmjyKZhUU3Do2MimsZE xjSLgtGsWSQfEVC0eWx4bGzjuLjGCQmNExMbJyeHpaSEJqeEJKfWT0qt2yKldmxijSbxVSOa VQ5rWjE0qkJweLmXGpWrE1r2xdCytRuUqRVSplawNcrCqB1c7sUGsFu+bmiFeo3gA64SfBCE RsKBoXpYE3gqwmdi3ajm9ZvEwnE6rHl8eGxCRFw8jMj4+Kj4ODYS4qLh6hITopNaNElOapKa 3CQ1JTo1FUaUfaTA6zoqJTkqOSkyMTGyRYuI+ITwWMgc2yimeWiTZg2iYoIjY+pHNK0X3rRu eJM6jZvUho8e6CSsSY1GTavDaEj/bdS0RlhMzTDydH0xAk4gsfARXy8mHj7xG8AHYkISfGI2 SkyB96jGyWSEJaWEgSUhCd464D0kOKZ5vWi4riYvRkTXCo+q3jiyWiP4EIeP8rCK9RtVqEde axXqhlako3K9RlXrh1UPaVyzQXit0IjajaLqhJGPuTrhTaDDuhFN60bQD8GoZvWim9drAiO2 ftPY+jFwIiJdkddXVHN4ccH9rNowCk4LFes3rlC3UTl4OOBRqFm/TA0Y9cpUr/dC9ZfEKMMG sZMBDuZRn2Sgo2xN+oDWCi4Ho3YIjPIvwmhQAUadBhXrhFqjUp3QynVDq8B4qWG1eg2r12tU MzjsRXh6h0UER0Q1jG4S3qxZdEJcTFJCbGpSHDyHW6e2aNuyRbtWCTDatopv2yquTavYtNRm LVNiUpOikxIjEuIbNY8NaQJnAHi8omo1jKjeoHHV4LCqwY2rhcAIr9YgvHpoBJymyJmKDnhz qwaHK3K+YqN6aCScFmo2iq4VFl07HB6XpnUiY+pEN6sb3Rzepsg7FXmnhTciGPEvwadM8wR4 Hw6OTQiBBxQ+VhLgE6FFGIwWieGJiRFJSZHwBEtJjkxNjmqZEtUqlY20ljCi01o1bZPWvF3r uPZt4zu0jevQNrZDm+Yd2jTr0DqmfVqTdq2i27aMapMa3Sa1SevUJmkpTVolR6ckRiUlRCbE RcTCCzAmIqYpiNK3hw1Zs3FD21e7tuzcOal9x7i2HS7/8MMTTz3NdWnfIXS8k9BvyIgPPv9q y84tOYcy6di6/9C2/Ye3HTi89UCuNTLJOLJl/5HN+49sYiN3U04u/Jt58Oi2w3k7jhzLyju+ 63j+nvyT2SdP7T11Gkb2qVNknDy1J//U7vxTu07AOJl14uTO46dg7JDjNIztdGw7fmYrjBPf 0HF2a/7Zbfnfbj/53Y5T3+08fS4Lxplzu858v+ub73efPb/n7IVsGN9e2Avjuwv7rAHzs+f3 nv3eGtnfnLPGXhhnv9/HR459nMv5Ro59MM7A+G7vaTKyT3+bferbPafO7jlJxu6T37Jx6rvd p87tPk3GrtPfi5F1+vudp77fefLcDhj5ZGy3xgkY3+2wD2qnDtvyv99KRyYZ5+U4ycbWkxdg ZJ6i4/RFGFtOX9xEx9enL2w4eX5d/vdrj3+3Ou/sysOnVxzI/2rf8WV7ji7dlbtkx6HF2w4s zsxZstUa+5dtP7A86/DKPUdW5xxbezB/Xe7pr4+d3XTy3ObT5zedvrDpzMWN31z6+szF9acu ZEDOY+dWH/12de7ZVYfPrDp4atXBk2sOnsw4dGrd4VMbck9vPHJmc943mcfObj3+7bYT322j l2NdOB3fwdiZ/21W/lkYu+AenjoLt3Qv3N5vvtt75tvs07CEu/pNFjwT8vK35h7PPHxsy6Fj mw8d23Tw2CaYHD6+JffEltz8zCMwTm49enJr3qlteafg361HrXF6a97pzLwzmbSNbSfgOXNu BzwKZJzbefq7nae+3ZF/duux01uOntx4+MSGA3nrco5m7M1dvefQ6t0HV+86uIqMAzBWs7Ef xqqdOSt37Fuxfe+KbdnLt2Z/lbkHxrItu5dt2bVsMx2bsuxjM4xdX23Z9VXm7uWZu1ds3bNi a/bKbdkrt2ev2r531Y69q3fsW7MzZ01WTsau/ev2HFyffWjDvsMbc45sPpgHV73tyIntR/Ph Jshx9AQYt5KRv+1o/va8U9uPkdfLzhNnsvLP7Dr5DYzdp2Cc3UNvY/aZs3BL933zXc5ZGOf2 f0vHd3zy7bmcb8/tOwt3/tvsM99CyK6TkAcSntwOd/4I3Pm8zQfJq3tjzuGv9x3akA0dKmPv oQ0w9h3ekHOY/LvvEFjAvm7PgYzdB9bu2g/XtXrnPrjMlTv2rtievWLbnuVb4abRO6aOzN1f wZ2htwX8IRCSfL3v8KYDRzIP5W3LPQ4XvvPYyaxjp8TYmXdyB1w+3J8j5IZYY/sRuD/kLlFn OXay+3Z86+G8LYeOWlf0NbkiuNXwrgV3+ygpdPjYjiMnwDlLGbC0wmFrx5HjfBzbnpuXeRDe Aw9v2ntww579GVn7Vm/PXgmP8pZdbGTCII/4ym17VsF17di7ZsfetXB18FjTsW5Xzno6NpCx j4ysvet3Zq/bkZ2xfffa7bvXbNu9GmK37lm1jYZn5azddSAjG25y7oacIxsP5onXQiY8H47m b83L30YHPHbbj+XvOHaSjONs7NSG7S2XLHeeEON0Fox82zizS4yT9Jl2CsZZMk5/u/vMd7vP nNvzDYzv98Db7NnzdNA3ZPqeLAZ9c76477tLOedgXN7/PRkHzl+Bsf/8lZzvYVzed+5y9ncw Lu3+9tKusxezvrm448yF7acvbDt1PvPEuS3wvnT0m43wVnMgf/2+vIw9uWuyDq3ecWDF1pyv tmQv27Rn6abdMJZs3LV4064lMN8ML9LsZZl7l2+DFy+8hPevzjq4dvehjOzcDfuOfp2Tt/EA vLEc33LoxJbD+VsO5W8+dGLzwRObDp7YeOD41/uPbcjJg7F+79F12UcgBMrBWJfNx57D6yAV HTAhYw+8TA5v3Hdk84G8rYfgeXICnpNZead2HT+9+wQb9LPvVBY8LvAw5Z3YdvR4Zi59Zh4g n6HwnITxNR0b4bP14NHNh/K2HIY3BDK25h7dehheF/BRe3jL/kOb2Ti8+cDhLQdzYQuemTuP wufvsV1iHM3bkXt026Ej8MG95cDhzIO5mYeOQqrtR45DD3tOncn55tsD3507eO78oe8vHL5w MffCpcN0HKLj4IWLMA7AOE/G/vMXyPiejBwxzsE4T8f3+747t+9b+Hj9bu/Zb7O/IW9Be07D OxI8heCZBk9OeO86tiU3b/OhIxsP5H69/7AYG2DkHF6fc3jdvkMZew+tzT64Jvvg6t0HVu/e v4qPlbv2r8zKWblz3wryrpK9age8NOBNI3vNzr1rd+3L2JWTAS/G3fBK2bd6595V2+H9Ft54 4c1559KNO5Zu3G6NZRu3f7Vpx4rMnau37crYuXv9ruyv9+zdtDdnS87+zP0Hth48uO3Qoe2H D+/IhZErxvbc3G2HDm89CDeQ3PNNOYe+3ndww154JzxA3/Gg7n5oAF7ga3bCu/o++oLdv3Y3 vGYPrt8HFwgPZV5m7vFtefACPL0bPvjgIAHHiTNwIPk++8z3cGzIgrNN/tntx+GzCT68Tm85 cnJTbv7G3Pyv4UPq0In1h05sOJy/IffU10dOb8w7s/n42cz877af/n7HmfNZ35zfdfbC7rMX 9qivte/Y2HfOGhdh5HzvOvbBoJ57yTif/d357G+/J+PsORh7yPhuzzff7WEPKLwVnNqRB2+q R7ccOLRx7/4Nu/dl7NizZmvWqi07Vm3esXLT9hUbt6/cuH3Vpu2rN+1Ys3lHxpad67dmfb1j 16asPVt2Z2/N3rd9X87O/Qd2HTy4J/fQ3qO5OceOHDh+9OCJo4fyjx7Ozzucf/Tg8SMH8nL3 H8nNyT2899Ch7IMHd+8/uCvnwM59B3Zk79+evX/bnpytu3Myd8HYl5m1D/7dumvftl17t+/e t2PPvqzsnF17c3bvy9mdI8b+Xfv37zpwIOvAwaxDh7Jyc7OOHs06fmzH8ePbjh/fcuzEprwT G3KPZRw4snrvoRW79n+1fe/SzN1LNu1ctGH7wnVbF67LXJiR+eXaLV+u3WyNhTAytixal7lo /dbFG7aRZ9fmncvgzR8+0eBTfid534YnxobsA/BJAcfpHQcOZx08vOvQ4d2HDu85fIiPgzCy cw9lHzm8N+/IvmNH9x3P23vi2N4Tx7NPnLDGHjGOH88+fiz7eN6evLw9R4/uPpK763Bu1kHI fHB7zoGte/dnZuds2ZOzafe+jbv2fZ21Fz5W1u3cmwEvEPoZBB8lq7fD2AdnD3L82JGzdic5 fqzfcwA+3zfuOwRvQVsOHoH3h225x7YfhQ/fEzuPwUcqfA6egId7x1F4TzsK7yFb9h/cBA96 9r51u+GlB6/B3Su371qxNeurLTuWbYJX2bYlX29bsmHrkvWZS9dnLtuwdfnG7Ss2kSfG6sys tVt3ZWzbvW77nnU7YGTDp9566BM+AXfnfL0nZ2P2/o3kdh3YtO8gjK/hE5a+yuClvSYLjhNw +toDxyp4RS9ev21RRubCNZu/XL3py9Ubv1z19QKX8eVqa2w0DYilYw0ZC2HQh3VRBowtMBZn ZC5eR8YSPpbCgItav/UruK4NW1d8vQ2e5Gu37Fi/LWvTjt2Zu7N37Nu35+CBnKOHDh7PJU/m U8dyz5zI/SYfxuFv8g+dyT94Ov/AqeP784/lnMiDR3w3vNUcPLA1J2fTHni89mRs37Uqc+eK zTvY2LRj+eadK7bsXJGZtSITbjIZy8nYTQY5aZCxInP3yq27V23bA0cRctjIIu+H63bDaeoA HKjgHsIJjRzV9ueSAe+9B+EUAW9KR+CteAt8OsDHyuEj8AmyLRc+RI7sOHJ0J7w08vKyjuXt Op6368Sx3SeO786HcWJP/onsk/n7Tp/cf+bUwbOnrXHg7Kn9Z0/lfHNy35n87NMn9pw6vvvU 8T0nj2XDyD+WfSJvz7Ej9Ll6KOvggaz9OTv37d2RvQdE6bjp08h3Stt1iG3drmmrtpeu/vD3 J58OKlf+mffnftx/4nvxfQbH9Rkc33dwi37vJPd/J3XAkJYDh6QNGtr69aFt3hjW5s1hrd8c nvbmiLQ3R7Z8c2Tqm6OS3xiV9Ma7LV4flfD6yIRBI+MHjkh4fUTyW6NaDRndbvi4ju9O6DJu 8qsTp/WYOqPn9Fl8zO4xfXb36bO7TXvv1anvvTL1/a7T5nSd9kGX6R92mf7RyzPmvjxj3ssz P+4885NOMz/tOOuzDrPmd5j9RYf3FnR4/8sOcxZ2/GDRyx8t7jpv6asfL3vt06+6f/ZVz8+W 9/p8RZ/5K/t+sbLfglXpX64esJCMgQtXD1q4atCXqwYuWDHwi+UDPl+W/tnS9E+X9P9kSb9P Fvf7eBGM/mLMW5TOxsL0uQv7z/2y/0cwFvT7kIy+H8D4os+cL3q/P7/Xe/N7zv68x6zPX5v5 WbcZn70KY+bnr86c/+qsL16dvaDb+wtfm7O4+4dLu3+0jIy5ML567aOvXv1w2StzlnZ5f2nn 95Z0nr2k06zFHWcu7jhjUYfpC8mY9mWHqQs6TPmi/eQv2k+aD/+2m7Kg7dQv205b1Gb64tYz l7SetTRt9ldps5e3fm956/dXtHl/Rds5K9rNWQmj/QcwVrX7cFXbD1e3+Wh12kdrWs5dkzxv TeK8NfFzV8e8vzxy5pKwqV82GP/ZS8M/rP3mzGr9JlbuPrpil+EVOgwul/Z62ZYDyrUaWD5t YIW0QZXbv1njlWF1eo8OGTgpbMjMqNEfNpv8Wfx7i1t8+FX8R8tj566Mmbsq+sOV4bOWNZy6 KHj8gnrvfvbSiHl1h8yp89asl96cGfL2rLAhsyOHzY4Z+X7c6A+Txs1rNfHTNlPmt536RXu4 wBkL4Xo7zVjYacaXnWYs6Dzjiy4z53ed+dmrsz59bfanPed81ufDz/vP+yJ93hf9Pvq8zwef 9Z7zSfdZc7tOfr/D2BlpIyanDpmQ/M6ExMHjE/7/Rt26u47sTNTPZCbpboMYLTCzJItZOow6 zMzMzCRmtCVZMrs7DN1JZu6duTN/3PsJbtLpboMsMzVMkvl9gt+76xzZ7k5m5q71rLNKdapq V+39vu/ej+o4gSTBkyb6suTAGCU0QYtM0qNTzPgMMzGLMYcxz0gu0lNL9PQKI7vGGl/nTl3m z10RzgPbwrnLotkNwdRF9ugyIz1PiU0TQuND3lyfM9VlibWbIu3GcJsh1KYPtukCbTp/m9bX pvG2qt0tCmeT1H5WZD0tMJ/imU5wDMdYuiNMzWG6qpGqaCDL6onSOqKkjiA5hBcDsAF76klS +KqRojhCUx6lq48xNcdHtCdYupNs/Smu4TTfdFZgPieyNkvtrQpXp8bbawgMWiIEV4Lmz7Ci Y9z4OC82xouN8qNZbiTLCmUYgTTVl6L60vRgjhkZH4lPcZIzvPSsMDcvHluQji/KJhah95RT i6rpJc3Msm5uxTC/alxcMy1dtCxfsq6uW1c3MNYtK+vm5UvGxYu6+VXN3IpqelE+MSfJTQvS E9z46Eg4TfclyK4IwRYcNvsHDN5erbtH4+rRenp13l69r88Y6DeHBq3hYXsUGLJFB20R+LPf Euo1BbsN/i6dr0PjaVW5WuSOJqntnNhyRmA6yTMcZ+uOsbRvOM7WnuDoTnH1Z/iG80Jzq9TW qXJBE0OmIMEepbiTzECWFR5lA5ExTnSMExmDP0eCOYgNhv8t6LBglhPO8SLQXQUE0VFeJMcJ pUf8Sbo3TnFFiY4wlKwhk3/Q5B+2BPHWMNEeJbviNG9yJJCB07mRUQA2OKEcO5RlBTJMf5rh S9F9SYYXSAB0d5RsC+JN3iGts1dp65CYWvj6s2z1Kabq1AgGS32arT7L0Zzjapt4uma+vkVg uCAwtAqNbSJTu8jUITJ2iTFEhi6hvkuo6+Rr2rmqVraihSlrYkjPMWRn6LLTdPlppuocR9ck MF2Q2jtU7h59YMAawbuSJF+GEszRI2PM+AQrOclOTXFSU9z0FDczzcPgA1lg5g2CXJ7Zt4wC c0JgLF+H50XjC+I8E8BiHsnEUoHJJenksnR6VTazJp+7pJjfUC5eVq1c0axd0166gdXhDw2X PzJu/ci0/WPz9k/MV35qufoz69Wf2a793H7t547rv3Dd+IX75i89t37lvfVr3+1f+z/82P/R J4Dvw088tz923frYcfPX1uu/Ml/9peHKLzSXf6Zc/4l07UfC5Q+58zdYk9v07Do5vkwIzA45 x3qNiU5VsFXsPs+1nmIajpFVjQR5A15Wh5PWDksO4aT1REUjRXWEpj3G1J/kmM7wredFjgsy d4fK16MLDZiiw9YEwZEiuzM0X47mG6V6c2R3lujK4B0p+GrAHOszRODILk2wU+XvUHjb5Z4O hadT4e1SAp5OubtD5mqXOoBOubNL4epRuQd0PrwlTHUlWIEsPzIuSkxJMzOKsXnVxIJyYl45 MaecmJWPz0hyU6LMBD81yollmaEk1RsjOUN4WwBn8Q+ZfAMG36ARxSfBHiG5YhRvnOaLM/zx kWB8JBBj+iJ0d5Dq9FMcQIDiBII0d5jpi7KDCV40JYilhRiiWFoQTXGCCaYvRnVHKO4ouk4w xQxnuYlxydicenbFvLJh37ji2rrmvXrTf+PDwM2P/Bi+mx95b37oufGh+8Zt1/Xbzuu3nNdu Oa7dsgNXbwI24Apww7oNXLduXbNcvmre2DatXzZe3DSsretXLumWL2qXVlXzy/KZBckEBBuE KFStLD2cIgfiRG8U743iPJFhd2TIFRlwRvoc4R57uNsa6jAH2gy+CzpPi8bdpHadVznPKh1n 5PbTUsspkekkX3+KpzvD153j65r42hahrlVi7JCZu5TWTqW1TWZqEenP8TWn2coTDNlRiqiB wK/H8xoIvEYC7zCRd5wqOMeWtolUvQrdsM5EMtvoDhfb5+UHA4JwSBiNiOIxcSIGn8J4TBCL 8iIRTjA84gvS3X6y3UeweoZM7n69q1fr7NE4ulR2aLRDbmmXmlslpgsiI0JiaZXZWhUOqIF9 puCwI0bypRmRMW5qWjy2qJxZU8+vq+c3MDaVsxuSyTVBbpmdWmDE52jRaXJokhAYG/blBj3Z flemx5nqdqZ73Nle71hfYHIwMktILtJG11jTG7z5LeHiFenKVcXaNdWl6+pL1zWXrmvXr+nW r+s3rhs2bxiByzeNWzdN27dM27dNVwqY9zaMGIbtW7qtm9rLNzSb11XrV5WXrsjXtmQrm9Ll DekSsC5dXJctXpIvrMnnVxRzS7LJWUEaSnGC6g4SzK4BlblLpGllSZtognNk/hki9xSOfXKY fRrHPovjnMdzWoi8DpqwlyUZ4skJYhVFoWVoDGyjWWC1SVxOpc+jDfkMkYApGrDEgrZ40BYL msN+g9+r83jUTpfC5pSaHSKDXaCz87Q2jto6orQwFRa6zEyTmihiI0VkoIkNdLGeIdazpHqe wiBUG6Vak1xvVhjMCiOG2SK32mR2h9TplHi84lBQHI+JMil+LjuSyVJSOVwi1xdMtdvD57Xu E2JzI0tbR5XV4ASVfazyLnpZB620nVLaRiptzUMsayOWt5Mru2jVvYzaAVYdjttIEh6hSY+x lKe42nNCwwWJqUNh7dM4CAYXw+LhO/0St1/m9St8PpXfq/Z7MNxqv0sT8Ggjfn08ZEhFjZmE PpvS5TLaXFYzmtPkcupcTgVks+psRp1JqdNJdTKujEXl4ZDUHxB7vAKHm2N2jOhtdI2FojKT FEa8zDAkNQxI9H1ifbdI3ynUtwv0bXz9BZ6+BeAbWvjGFgHEqrldZu1WOvq0rkGDFy3jnWGa F0pNih3J8OI5QWpMmB4TpHKCRJYfz3AjUExCFLuXYLQPasw9Cn27RN0kUJzhSE8wREcp/AYC p26YdWiAWdvHqOmm1XbT6nvph/uZx4ZYJ3Gcs0ReE0VwgSZuZUjbRmTtbEUHR9nFU/cItb1i fb/MOKgwD6usOK0Nr3fgDc5hvXNQ7+zXObvV9jaZuUloOMXWHKPJGwmiQwOcyk56eSu5rIVY 2oQrOTdUfHZwjwGMweJz7zJUfP4NwyV5mgAcohlf2oIvayGUXyCUtxIr2kiVbeSqdnJVB6Ua Qa3upNZg1HbSgENdtIZu+uEextE+5slBVjOR20kTDLIlFLGCq9HKbGZDwGGPe13ZoHciFphL BRey/oWcd2HUvTDqnMs5pjP2iaR1NGZMhlQhr9jt4FjMVK1uSKrq5MrO04SnSPwTUKnwvKM4 7hEc7wiBf5QkOEoWHaWKj1AlEGOH6TLgCA2QA8doihMM5akR9Rm29hxX1yw0tkrM7XJYTTm6 ta4ePVQhX78lMGALDTjCg06ot9FhN9ReVIGhDpO8EbI3TPGEqd4Qwxce8YfZwQg3FOFFoADG RYmEOJWUplOybEaey6rGcrqJMeP0uHV20jY3aZmdMM+OGWdG9dM5zWRGOZ6U5eLSbEyWjckz GKmoNBoSBf0Cr4fncHDNZrZON6JU0iVSMl+IY3H7aaweMlNmdkzNzu17f9/3znU21jYc/vjf /s+wxgHgtE68zknUu5CaGt00k5uO7NTDsHrpVh9As/qp1gDFGiBZA0RrkGAJ4M1+nMk3ZPQO m7xEi59iD9CdoRFvhBuICSJJMdhpMitN5sBREekxSXpcnJ4QZSZF2WlxbhYW09hyZ0UytSqZ viiZuSSeXRfPbYrAH+a3RAtXRItXwUXFy9ckK9dlqzcUF2+qLt3SrN/Srt8GFzVsFnQUc1GE 9fJtxCZwy7J+w3zpumntGial22Ch+sXLusVN3cKmdn5DO7ehmVvXYM6JaedF9dRF1dSaanJN iaGYQBQsdGxVMrYqHl0V5VaEuRVBFlgV5taEoxdF4+viiQ3J1GXZzLa84KXXAeUi+pTNYV46 fRWkVDB5hQ9SmvdSzEjzOspOrrESqyPxFSaQXGOmLzGzG8zcZSZS06vMqetgpCxwURDR+dvc +du8+dv8hTwf8hY+5Cx+xF78aGTxI/rSj6hLPyIt/wjz0utd49ut2Y2m2Mpp78xxy2ijJl4n DdbyPTUsO0hpFUVfTTXU0Iy1DFM9x3ZU4j0NXmpJt3knuqPz/Vnw0i38wvWhhRv9Czd7F251 zt5om7jSnNk8G7t4OrR8yjd/yjV90jZ+2jba5BhrdY13eSf6AtPD4TlSbJGeXB5Jr7GzFzm5 dd7oBn9skz8Gn+v8sUuCsYvC8TXR+KpkYkU2uaycXlHPrurm1/Tza9rZFfX0smpyUTY6J0hO sEJZqidBdETBT3C26JAVtCc27Ejg3GmCN0cMjJFDE9ToFD0+y0jMMZKgowtMmNdTi4z0MiOz Qs+uMkcvsiYwL53dRl46ty2a24LQEs5s8CYvssdWmJlFWnKOFJ3GB8cHvbl+dxoEtdeR7LXH e2yxHkuk2xzuNoW6DIF2ra9V7W1WuM/LnGfF9tNC60m++TjXeJSlP8zQNFCV9WR5HUl2iCit JUiAQwTpIaKsjiSvpyjg20a6Gg47wtTB8cfYhuMc4wme+aTAclpkOyOxwzUvqDwdWn+3MTRg jRJcSVogw46O8cBLkVlluaE0OwBSBGYVA48iwCrHnaT4MvTgKNgpOzbJS04J0zPi7KwkNyvN zcpHZxVjc6rxOfXkvHZqQTe9qJ9dMs4tm+ZX3gB/GmaX4Sv15IJyfE4+OiPJTAlTE7w4SCBo XpLmiZGQxQXA4va81N2DpNTfZwz2m8OD1uiwIw6ORHCnCB4gjcfAuVJDzuSgI9Fvj/dCH5pC HfpAm8bXonI3yZ1nJbYzIgtwWgiYzwjMZ4Tms0LzOaG5SWS5ILW1y2GpB2s+76AxiLNGSM44 2CnVk6J50zQfgupNwR6yK0ECnAmyMw5QnHGQAbo7wXAnmB7ECCLOdMfprijVESHbw1Cy8ObA sNE3oPcCaOlvhibCEGAkV5zqSdJBQZHugpOnad4U7KGgf4tAQ3GiMwaQHFGSI0K0hXBgtlDr 1c5uha1dYrkgNJ7n6c9yded4sFbWn+frmwSIZgEYaYELsCbg61sxYH3Qxte18XRtXE0bR93K Vl4YUTQzYEKSnKWITpNFp8iik2TxcZLkBFWG1JSrbxaa22SOLo233xTCOeIkb5oayMJKlxWf YCfzUprX0ZkCezrKy87m4QM5YA4QAJBliHkhgP1zEFHw0sUCY4uidxCPL4knlqVT4KUX5XMg pVvq5avatRv69dvGyz8CEQULtV37hf3GL0EvQTLdtz/xfPgb30e/8f/ot4Ef/zb049+Ff/K7 yE9+F/3pP8aAnwH/BER/9k/hn/5j8Ce/C/z4d96Pfuu8/Ynt5sfma7/Sbf9CtfFT8FLB0m3O zLWRsU1aapUcmcd7J4dsmT59tEvhaxPZm8A5GdrjJPkRvKQRL2nAieuGxfU4SSNJfpSqOs7Q nmIbzvJgTWO7IHG2Kzzdan+fPjRkiuJtcaIjSXHDcGcBqidNdiWJ9gTOGh00hft0wW61r1Pp 6ZC722XONomjTWJvl9g7wEJljk6po0Niaxdb20SWdrGlU2rrVjh6Va5BvY9oDdM9SU4oJ4xP SFJTstyscnweskw1CXYKXjqjGJ+Wjk6KMmP8VI4TSzODCaonQrIH8BYfTKODBs+AzjWgcw8Z fThLgOgIkyGAPVG6LwZSirzUH2V4w3R3iAZ4wjRPhOaFb2EpmWSHU9xohhfLAnwMXjQL60tm KE0PIpiRHCs2xklOCrIzsslFzfyaaXXTtn7Fefma+8oN37XboKY+xG3vjdue68At97Vbrms3 ncDVmw7EDceVG/Z3sG0DyEutl69aNq+YN7ZMl5CaGtc2DKt5O11TL6woZhdlU/Pi8Rl+bpKT GmPGs7RomhJOk0IpQiCJ9yeGfYlBb3zAHe9zxrrtkU5LqN3kb9X7WrSe82rXWaXzjNx2Sgxl 03iCqzvJ0Zzmas5yNU1cTQtf2ybSd8hM3UpLl9LSLjNdEEP2ac9wVSdHYMUGkSBoIPIbSfwj ZP5RiuAkQ9zMV3TJtYMgpVY73eXmBPzCaFiSiElScWk6Kc2kJJmUOJ0UJhP8eJwbgW6HMQ2S HUhKh03uASSlDlgrd6tsSIYVlg65uV1qahPDQt+AkJhbZda3Xgqlw59hRMc56RnR+KJiZk01 f0k5e1ExvSafWhWPLfPS8yOxaWpwnOTLETwZmOMGncl+R6LPFu+xRrvM0BvRLmu82w6Cmunz juEi0+TUAnNsjTO9LpjbFC9tyVevqC5eVV+8qrl0VXvpqm79qn79mn7jmmET7PS68fINUFPj 1i3jNsYbHb1yS3/llm77lmb7puryDcXGNdn6VcnFbeHKZf7SBnf+Ind2DeDNrvFnVwWzq6LZ FcncsmxuSTI1x8+Os6JJmjdEtLoHtZYeibaNI22mC89TkJeeRF7KAk4Ns04Psc7hOBfIvA46 qKl4kCfDi1RkuZamNozozVyzVWizy1xOhcet8rjVXrfW69HCNuio3SmzOMRGu9Bg4+tsXI2V rbKyVBaQUobCDFJKBSmVGMkiA1mopwj1VJGOJtIxxDq2TM9XGMRqg1RrlOmMcr1JbjDJjWaZ xSqz2aUO8FKPOBgUxaPCTIqXzTBTGXIiMxzN9PgTrZbAWZXjmMDQwFQdIkmqh3gVPcyyTmoZ JqUlrcSSC4TSVkRZK3gpqbKLmvfS+j0vPT4CXqo5L9SDl3YqrP0aO9HgYlo9AqdP6vHLvX6l z6f2ezWBvJrueWnYp4sFDcmIIR3XpRPaTEqTSYOIqjIIJZBOK9MpVSqpSiaUiZgiGpGFglK/ X+T28h0ujsUxYrAxtBaq2kRWGglyA06mH5bqB6X6fokerK9HpOsS6joEunaBrk2gbxUY0H9L RaZ2qaVLYetROwb07mGzj2gPUt0Rhi/OCiW50TQ/kRUkc4JkVpDI8ONpzEvDVIeXYHLkvbRN rG7iyc+wJCfowqNkXgOeXTc4UtvPqOmhVXdRqjsph7qo9T20xl760X7GiaGR0zjOObBTsqCZ Kmyhi1uZ0jaWvIOr7OJrekW6folhQG4aUlpwGmSnw1r7kNY+oHP0qu0dckuLyHiWpzvJVB4h i+uHeNU9zIp2SnkrqawZX3J+qOTcYEnBSIH+vY09zgHvaComqOisgp0OlzbjypCa4kFNK1oJ la3EyjZSFQB2WoACYJpKqemgHOqk1iM7pR3rY5wdZrWRuL10AYEnGZErxUad1mU2hxz2hNeV C3qnYr7ZpHc25Z7LOOeyjtmMfSplG49bcxFjMqAOe6QeO99mYuh0eJmym4eS6DSJd4LAPYbj HBliNwLD3EY8r5HAbyQKGsmiRoq4gSpppEkbabLDNPlhuuIoQ3mcqT7B0p7i6M/wjOeF5maJ tVVub1c6OzXubr231xTotwb7beEBR3TQFRvyxIc9cZw3jvdheKMET4TgDhNdIbI7REEzS5Dh DTH9YVYwwglFC4IaT0iSSVkqpYTIzGV0o1n9WFY7mtbkUqpsUpGOy5JRcTwsjAYFkQBGUBgJ CsJBXsDP9XrZLveI1c4wmKgqDVkiJ/BFgyxeD43dQWRcwNF++vFvq2oP/f3+ou+19TUcLK+a X16dufLhkLqgpgSdk4TU1EUxuvJ2SjO7qWYPxewFyGYfCWLX7COY/XizD2f0Dhk8g3rXkN6F M7gJJg/J4qXa/AxnkOVBdsoPJfihJD+cFIRTgkhaEIXJcpSfGBekJoVZzEvRP+DXZLOXZHMb 8oXL8sUt+dIV+fJV+cp1OYjoGnBTefEWpqO3tRu39Zugox8iHd28bb6MsGwCt0BErRvATdBR y6UblovXzWtXTStXjMvb+qWtvIuChapnLqmmLyqmQDhX5eMrsrEV6eiyNLckyS6KgcyiKL0g RCwCgsySIL3ETy/xgNQSN7XESS2xk0us5DI7tcxJr3Kza7zcJZAu0cSmZHpLNntFPncVUGDA hnTminj6inByG4yUP7FVeFM6usnJbhSMFFw0usQIL9KC87TgAi2yRIuv0pKX6JkNxugWA7x0 +sbI7E2QUjBSEFHBIkK4+KFo8TZ8wjZv8SPu4kespY8YSx9Rlz4iLX2EW7jdP3Wta/Rya+ri +fDiKdfkMWO6QRE+JPTWchzVDHMlRV9J0lZRdDU0fS3dWM+2HpN4zmjCzdZ0u3eiJzo/AF46 A156bWjhev/CjZ6Fm52z11sntpszG2dja6dDS6d9c6dcU6dsY2esuSb7aKtrrMsz3uebHA7O kCJztMTiSGqFlV7lZC5ys5egizAu8nJr/NyqYHRFOLosGkWrXtnEkmJyCXRUPb2knFxUjM/L RmdF6SlOJEf3wRoxgrMEh0zBAWOwzxDsNYb7rbFBR3LYncX7xkihSUp0mg5SCjN0epGZXmJm lpnZFSYYaW4NpHRk7BJ7coM7jXkpemW6LZrfFgOYmvKnLnEn1lijK4z0IjUxS4pOEUIT+MAY zpcb9maG3ClYGQzY4/3WaK850m0MdxhCbbrgBY2/WeU7r/CclblOix3glsc4xiMjuka6pp6m qqMoD5HkCLICtuupqnqaupGhPczUHWHpj7KNx7imYzzLcYH1pMh+SuI8I3OdU3ia1L5WXaDT EOq1RIfscZInxQhmudExfmwMSWkwzfGDYsVozgjRGho2gSgiYSM64mR3iubLMIM5dniUFxsX JiZEiQlxElbDE9LUhDwzqchOKXPT6tEZzdiMdnxWNzGXB7YB9dgMfAuHwfGixJggNsoNZ9mw ePUlae4Y2REhWINIwAy+fp23B7wUvSz19RoCfaYw+DPcKigowZuBtRQpMEoOjlFC4wAZgxQa JwbG8L7skDs9AKpvjXWbwiCorUhQPS1Kd7PC1Sx3NskcTRJ7k9jWJLI2i6wtElur1A5q2ql0 9YCDGQJD5jA8LN4WJdhjBEccwNtjOFt02BoZtkTg2yETOEZoGCTWGMQjAgQMotGfh2Dw4fTe Yb1nSOcZ0Lr7Na5eNaJf6xnQ+8F+hy1huD4R/BZE1Jsie1Kg/UR3kuBK4LEX9eCBw44YejNs iwxbw0Pm4IDe1wvlXunolNvapdZWsblFaGoWmlpEsCY2t8KqFBCbWkXGC0LDBfBSvq6Fp2vm aps5mmY2oG5hq5tZqiam4jxDfp4mPUuVIB0lCk7g+cdwvKM4PnAEJzhKEJ2gYGrK0bUIzR0K JwzBkCUM90b2pemh3EhsnJ2Ehf4UL/2OlGZmee/ABbJzPIy8lxbUFDFfUFMMEWIhjzAHzAuy 30KYAztdkU5dlM9uqha3tavXDeu3zVs/tl79uf36L503f+3+8BNwS/+Pfxf4yT+FfvY/wj// n9Ff/M/4L/45+ct/Tv3qX4D0r/45swdsA8lfwgH/I/Kzfwr99B99P/qt6/Yn1hu/Nl79pWbz p/K1j4QLNznTVxijG9TkCik8h/dODNkzA8Zor8bfJXO2C8wtbN05uvIkSXqcIDqKFx3GCRuH hY148VGy7ARddXpEd45rbBZYWsX2dpmrS+np1foHDEGcOUKwxcjOOM2dZPog5lM0d4LsiBFt ERwUHIhztbtT7myHaMTks1VobsNoF5k7xJYOkbldaGoXGtsEBvjslFh6FPZ+tWvY4CPbI5BB vMioKDkpzUzLR2dV4KUTSEpVEzPK8WnF2KQ0Oy5KwzyY5USTTH+M6oLFPUymbphGB7SOPpW9 T20f1LmGjV68JUCyhyiuMN0bgSP31DRPnBlIMIOpkXCGFcmyYzlufIyXHOenJt7AS01ykxPs 5AQrgd6rc9LTvOysYGxeMrmkmF3VLq2b1rbASx2b11zbNzxXb3qv3fIUuOm+etOFuOG8Ai56 HbGNsL/lBsZ12xaAvNS6ecWysW1e3zJfugx2arq4CYCggp1ql5CdKmeXZNPzoolZ/ugUJzMx khpnJEapsRwpkiWGM/hgetifGvQm+1yxHkek04rU9ILO2wReqrCfllhPCo0neLrjLPVx9KsE 1VmW6jxb1cJVtwl1nRJDt8IMdMiMrRJDs1B3jqc+xVIcp0sPk4WgpkfIgqNU4XGa8DRL0ipS 9ar0eLOV6nSx/D5+JARGKs8mZdmULJeWjWYkuYwoneYnk9xYnBUG7YchCBCsXkxKnX0gpSp7 lxJJKZhwl8LSmfdSCSz09ZiXmlqllla5rQNKDVRsiCt/mh4dZ6enBWML0plV+eyadGpFPL4I KcZNTjPDYxRvGmePD1oiA+Zwnwn96qTHGOg2+Dv1/g6dD+g0BDuN4S5ztNeeHPKNkmDuyyyy x1f5M5fEC5uylS3lGqjptubitvbStu7SFd36Ff3GVcCwidnp5RuIrZuI7VuAfvuWNm+k2zcV l29IN66LLl3lr21zVi6zFtYZs2u0qWXqxBJtYok+scScWGJNLnGnlgQzi+LZRdEUFJPxkShM QGGiDUqrpVeq7eDKLjCETVT+GRLnJJ51YngEPOTEIPPEAPPU0Mg5PKcFqamge0Tcz5MNi1RE mZai0jM0RrbezDNZhRabyGIXW+1Sq10CGyYbpqNWrsbCUVvYmI4yFWaGHEGXm2gyTErFBpJI TxLqALJQSxFoaSLtiETHleuESr0E1FRjkGlBTY2gpjKzRbrnpaJgQBiLCtJJTiZNT6aJ0dRA KNnlibYYvWfk1qNcbT1NVksQVg2wK7rpZe1k7E0pSCm+pAVfegFR1oovbydWgn310msHRupx HAizozTJ8RHFaa66Sahrkxi7FZZBrZ1sdLFsHqHbL/MFFH6/KuDXBH0YXk3Qow54YEMb8eti IX0yokvFtKm4JpVQg4KCA6RSimQSkMNnIqFIxJGUxqLySFgaDEp8b72UZbQydBaaxkRRG0lK A0Ghx8v1OLl+WK4fkukGpLo+sa5HpO0Sajvg3kCbhXqYodql5k65FeK5T+scMnoIVj/FGaR7 IiP+GCeU4MVSgngajJQfT/FjKW44jt6XOnwEkxP9M0JuaBOpm7jyM0zxCargKJHbgF6WMmp7 6dXd1MoOcmU7qbqDXNtJruuiNHRTj/TSj/UzTg6CnbLPErjnSPwmCmanI7IOjiL/4rRPoh+Q GYeU5mGVZUhtHdQAtj61tUsOs6qxSaA/zVYfByXDCw71s6q66JXtZDDJUnBL8NJzA5ia9hef AS/9a94IasFR0Sl5O20agiuUNg+XNePKkZriKy6AmmJ2igQVOeq7gKZWt5NrOyh1nZTD3bRT A8xmPKuTzB0aEdJEUp5apbDo9R6LOeS0J32usZBnMuaaSjink/aZtG06bZtMWMei1lzYlPRr wm6Z1ya0m0YMOoJC2cuXtjCEZ0i8k8hL2YcHWQ3AELthmFOP49YTePVEQQNZ1EAVN0An0OWH GYojTOUxluY4R3eSZzwtsJwV285LHc1y1wWlu03j7dT5u43BXnOozxYZcMQGXfEhT3LYl8IB /hQ+kMbDpy+B88Rw7gjOFcY7QwRnkOgMkJwBKHp5QR3xhdmBCDcU5YdjwmhcHItL43FZIiFP wEZMEo2IImFBCPknx+tluV0jLteI2z3i8bA8HvhkutwMh4tuc1JNNpLGgJephvjSPpagi8Zp JTLPD1GTUwsz8wvvHyj6u4Ml36MPNbWda9hfVAxq+ut//d/GzDSoKR5TU6LeBXZKMrggo8hG NwmDCFGL8OIBkxdJqd4N0+eAxgEMah1DWidO5yQYXCSzl2r1MxxBpis04gqPuCOgqSxvjOVL sANpdgjm4zF+alqUm5dMLMumL8rn1hULm6qlLdXyFfXKNfXqdfXaDc3Fm5pL6NWobgOx94L0 NhipafOWeQMAC0U/1jVfum6+eA2J6GrBRQ1LW/qFy7o9F1VOXVRMrsnGV6VjKxKQouySMLMo SC/wk/O8xBwnPsuJzbCjM6zI9AgQhs8ZZmSWGZ3DmGcAsQU6YpEGRBfpsSVGYnkktcpKr3Gy SE2FE5clU1uymW3ZdJ4t6dSWeHIL9vPzP9lF70g3OdhrUnbqIiuxMhJdYoYX6ME5qm+G7Jki eafJgTlKeIkSX6WmLtGzm4zxK8zp66zZm5y5W7yF28hIlz4ULd0GKRUvok/h4m3+4ofcxQ/Z ix8xFj+kLn5IXPhwePZm38SVzsx6S2zlnH/2pG30qDZeL/HX8pw1I9ZqmqGSpKkkqqvImhqq rpZuaOBYjkvcZ7XhFmuq0zveG50bzK4QpjeJC1dwC1cHF671LVzvnrvWMbl1IbvelFg9F1k8 65896548Yx89Z8s2O3JtzlyXe7TPOz4cmCSGZ2jQXfHFERD41AqydwxOGrZB5pe5mUVeZoGX medn5oTZOXFuTjoKOjonyc6AkQqTE9zIKMOXIjui4GD9IAA6X7fW16XxdemCPaZovy056Mri fOPE0BQlNktPLYKOjmRXWLlV1ugae+wia+wSaxxYZ09scKcu82a2BNjveEXzV8QLVyQY4rkt 0WzBTjnjqyPZJXpqAeyUEp0ihSeIgVEQqmFPeqigprFeS6zbHOsyxTqM0TZDpFUXatEGm1S+ szL3KZH9ON9ylGM8zNI3MGAy09TR1PV0DWw3MnWNI4YjbONRjhnTUdsJoeOk2HlK6j4t955V +s5rAs26UKsh0mGO9ljj/fYEmB4ZU01edAz9DDWU4fiTLE+M4QiTwRKNPrCpPq130OAfNocI tuibhTUnmOGFsvxwVhDOCiNZUSQrjuYksVFZfFSWGJMnxxTJcWUKoUDbY/LEqDSeE0ezwnCG H0pzAym2LzniTTDccZozSraHCRZozj9k8A3ovH1aTw9omMbTg16WhvrNkUFbfNiZxLszRF/u 7c+qY9OM+AwiMctIztITM9ToFDk0QQiM4rzZQWeqzxbvNkfAwDv0wXatvw2EXOW5IHe1QBkV 25CXiq0XxLZWia1N5uhUuLrV3l6dH+x0wBgcMIUGTeFBcxg2+o0h9H8KfaBH5+/R+OCwbpWn R+nuUbh6FM4euaMXYe+VATagR2brllqBLoxOAPaA46ndfTrfgDEApocD73UliO4Uev3rTuHd KVyB5LA7OeRKDjnig7bogCXSb4KmfdAbnQpnu8zeJgWXtrZKLECb1Nous3bAelRubZda2iSm NlikgpfytE0czXmW6hxTeY6hOEuXn6XJz1ClpymSUyTxSaLwBF5wbJh3ZIh7eIDT2M9uQHDq +zkNg7wjeNFxsvQUXXmOrbsgMkOjfXo/aDnRmaBCqITRK1NOYoqbmualkZG+I6Vz3DdkEbzs PC83z0fM8bNzgu8yi8gU4KdnealZXnKGCyRmOBjcFKjsknhiTTazoVq8olu7adr8ke3qz503 fuW+/Ynvo9/mdTTy83+O/fJfEr/6X8mP/zX98b9lP/m30d/829ge47/517FP/nX0k/+V+/hf sh8jU01gXhr8ye+8H/3GfvPXxis/12z8RLZ6WzB3jTW+SUmtEiILOP/UkDPXb0n06kM9MOJy R5fY3MHXXQC9p8vO5K2eIDiGF7z1eYYKOq2Zb2oVWTuk9i6Fq1ftGdBBVAfx5jDJFqU6YxDw IxD5PvTzbIo9TLQEcAbvgAYCyd4BAyo0tQqMrXxDK08PtPH17YDA0CFAG9hLb227QN8lMfUp bYNaF97kozojrEBKEBsTp8E/wUvBRdGPF1TjM8qxKeXohDw7JknnhIkMrPnYoTjDE6bY/Xij a0jnGFDb+pSWHpm5V27pV9kGdU4cTLgWP9lR+KXuSCDOCiZYoSQrhH5ox4nlOIlxbmoS/VcC /VR7FvtVNnoBjrEgHEcIxhcB4cSSaHJZMr0im11VzF/ULK3rV0Adt60bV22b1xyXr4Oauq68 xbl9HXBsX3NsXbNvXS1wGYA/81wHkJRevgZYgc2rlg2kppb1rT0uI0e9uGFcWzdg7041iyvK +SXZ7KJ4al4wPssZnR7JTNKT45Q4uFaOEM4MB0BNE0hN7eEOc6BV721SOc/KbKdEphM8PUjp UbriGE1+ki4/w5CfY8qb2cpWvqZTpO+RmXrkpk6ZsU2ibxHpzgs0pzmKE0zpEaroMCalx2jC E3TRWba0Tazq0xgIFhvd7WYH/IJoWIq8NAVeKs2mpbmMOJMWJFPcWIIVjjECEYo7SLD73khp j7rwmjRPlwJW9qZ21C54KSSp/oLYeEGKXpm2q5w9Rt+gPYL3pSiRUWZyipubF00ti6eWQVB5 GcipCWYoS/YkcNZQn97brYai5+rWOLsAtbNT7ehUOTqU9g6Vo1Pt6tR6u3T+XnN4yJUiBsfo iVlWbok3uSqauyRb2lSubqnWttQXt7SXtnTA+jag38DsdBO4ptu8rrt8A7F1Q7t1U7N1U7V1 U7F1Q3b5hnjzOn/9Kmdtm7lymba4Tp5dI0wuD48uDGfncNk5QnaOlJujjs4xx+c5UwuCmQXB 1Cw7M8aIJik+mIbcyEtl2k6etJUpaKLyziIvHTk+xDw2yDg2wDjaTz8+wDg9PHKOgNS0jSbs Ykn6ePJBkQov1ZLkeqrKwNSYWDozW2fm6Cw8DI7GwlabWUrziMKM6aiJITPRMcBIaTIjVWqk SAxksR68lAheKtACZIGGKtQwxVq2VMeX60RKvVillyA1Ncj0JqnJIrXaJA6H2OMRBgP8aISb So6kUpR4EhdO9PnjHY5Qs851SmI6wlLVk8W1OF5V30h5J7WsjYjekSIpxZU0D5e24Eov4Mou 4MrbCJWd5OpeWu0As36YfZjIP0oVn2DKznBULQJth9QA6YzT2WlmF8fhFXsDikBQGQyqQwFt JA9oCeCDT200qI2HdcmINhnTJGPol7rIQhPyOBCXATEgJkdE5dGILBySBgJin0/k9oCXcq3I S5l6C11nommMFLWBrNKTAKWeqNQTFDqcXDck0w5ItH1ibbdY1yHStYnASw3tUmOn3NyttPZp 7EMGJ8Hsodh9dFdgxBtiB6K8cJwfSWDEeZE4JxRleoMUh5dgBi+19ijASzXgpafBSymCIwRO /dBIbR+9poda1UmpaCdVIKMjVrURq9uJtR2k+i5yI7JTGtjpicGRUzj2GQL3PFnQTEMvTtvZ oKaqHoEG/HlAZhiUmwYVpgGleUBlgW4EL22XGFtEhnNczSmm/Ci42TC3to9Z3UUD+wWZLAOx PJ9XU1DQvuIzf8V3HBUTVHQ8stPB0vOgpkNlSE2Hy1vATnEVyE6RoCJaAeK7VLWRqttIte3k hk7K8V7auUFmK57VS+MRuaIRmUysU6tsBp3Xaoq47Gm/YzRsH4/aJuK2qaR1KmkZj1tGI+Zs yJj0qcMu5KUOE8uoIypUfQLpBabwLDnvpRzkpQOs+kF2/RC7HtQUz6sn8BtIwgaKuJEuPQL9 wFId42igMJ4Wms9K7ecV7maV94LG36oLthvCnaZolyXWY4v3ORIDruSgJz3sy+ACWXwwRwgB o8TwKGzgAxmcLznsiQ+7osPO8LAjhLMH8DY/wR4gOQJkZ4DqCtI9IaYvzPJHkKAGIzxwVESE FwhxfEG21z/i9jIcbprNQTHbyCYrGT4tdorVAZAtDrLZTjLbCXrLsELXL1L2sMUddF4LiS0w OD/61W9m5hbe27f/7w6U/H1J5fd6zvefP37h6MmTB8urahsOTy0s3X30BLj36OlbHv9t7gKP AHT8nYcF7uZ5c5HHT+9/i2f3nwDP7z99vvPsxc7zlw9evNp9+Xr31ZcPX3318PVXj15//ejL PN8gvkI8/s/48uu3wIno9D3gauiaXz58idhFvN598frBG56/3nn+Ks/9Z3le3n+KuPeWV/ee vcvr73D/OfAlsPPiywfAy692/xaw/8GLr3a+xZc7cBbcA1wEmn4KvLz3BAM1Wrjs/Rdf3X/5 9c4r4JsHrxG7f4v8VzsY919/c+/1N3dffXPn5VdfPP/y82evP3v66o+PX3z68Pmnu0//sPPk DzuPf3//0e/vPQT+cO/RH+4jPn3w+I+7Tz979OyLJy/uPH159/mruy++vPfqq/uvv76HcRfj zquvvoDLvvjy8+evP3/26vOnwMvPn7yAs7ATsXPhQfL9iXr4v6DQ+Q/e8hLx7CUKjKcvIEju PX5259HTOw+ffvGGR8/uPH5+58mLfCv3YOzgUtCZLxGon4FX7/I14vXXu+/w8PU3D9Hnmz1f 7cKR2BV2XkDPwzVRMNwDnr64C209eQ7cQbwo8PjFF4+f5/n80bPPHz797OHTP+4++eMD4PGn O3tAryKeoK8Q6DCMZ9DV6MT8RfaujNp6+gIavQ898KzQGw9QbzzfQVnzDCUd6hBItKfQM3cf Pbv7GHZiCfXkOTrs6YsHBZ6jz2eI3b8NHFAAuz4ifx2soQJYgqO28gOBbcAQQLuoT+CG4W6h o1DuoBHHxvQFjAgCsiy/ke9SrD8hPNBjos6EcXz8DAb0i0doZD9/+OTz3e/yBYCNe+EGoOl3 eHNugTcnPnj8t3j0DoWd2PX3OhMeCkIOwIagwLN3gDtHN48FA0Qmuvl80+gi6FKFG85fE4Ht h1YKrX+28xBxH9j9I3Avz4M/3n3waYGdT+/s/OGvyH+LDoZzdx59DteE62P3fO/pcxQtz1+i WgpJ9CLPO4Xur3n5ZvvN8d/mnazEkhRS8h1QK69RRUUVGxXqx1/9+5Nv/vT0mz8/+/e/AM// 9B+IP//Hiz//f3le/gXx6tu8/Mt/vPwz4gXG8z/95dmf/vL03//85Js/P/76T4+++vfdL7+B 5N15+dW956/vPn1158lLFDMw6Pk+R739+IsHj7548PCLnYef39/9/P6Dz+4hUJcidlFXw1fo GDTW+cTJh3Q+vPOTEZY4eQpZBjMXzGJ3HqKxgyb2wgaBtfg3uLP7GJv40JVhdkN59/zl7otX D4GX7/DiJbD7Ar598QB4htrdS22YOh9Do3CpO7vogrCdn0zRLWEVAN0knAJ5jU6H2XNvAsXm 0DyFiQ94DaBZ9a959GUebOr86usnb/nmyddv+BrxrW//G+BS3+Gdb796nOdLxKMvvwSwO4Q7 h5h8tQO8eHn/+ct7wLMXd4GnWNXFEg3qw2e7jz+Dcrrz6I87Dz+9vwtAEkEqAZ/vPERhsNdp X6CBgzRBfPbg4R930JH54xE7u5/t7H6x+/DOo0f3Hj++/+TJztOnD549233+fPfFG6B7nwNY b8OAPrv3BFvzwFJnb7WDWvkOKNkL7WI8fpuqT57B48BzwQPuQIpBDqI0zCfXCwgYGF9UafMV A7saioTvgjWNEh/iASU+KrlYRqNxh5H9ElEY3K+Ar/9z0MrqIcYuxoOvvt758uv7X3517zXw 5d1XX959+frOi1d57mLce/HqPhqp1w9gyF7lxwvWcqhz7j5CQfvFg90vdh5gmbjzR+AucP9T 4A4C/vwMuIcO+OI+HLl758HDu7uPgHsPH91HPAZ2vk1+5/3d/4JH9/I8KHAf2H20s/voAfDw 0W6eR8Dj3cePd588QWCDjoYYePHi3vPnd589v/MUpmOYmmGyfvTpDiyQdv9w98Hv7+z8/ov7 //fzexh3v8Pvv7gH/OHO/T9A9Qag8uRjLB+QkMKPHt97/GTnydMHT5/uPnv28NmzR8//C54/ eoHx/PnDd0DB+Q7YzmdwNQRcFp4Frg+RDA09frzz6PH9tzx6A3QycBdAmYKAO8QoBFhh3f74 yf0nTwGohwDqJVgt7AHpgNXJvXRAYQ+FESotJNcDeHzoB9Qbd+5Dp+U7513+gPHpF29DAkUF 1O37EBUoJKCYQy7fQRUV3eddVFcR+TvEUgzNp1DYUVLfQzNjvkV0/c8BbFw+y3Pnv+TNYXu8 GdO35K/5n/DuE925/9nd+5/f3fni3s7dnQf3H+w+ePgQQu7hk8ePnj55/Pzp4xfPEC+fvwXb 8+j504fPYASfPHjyeOcxGqA7uw8/h/i5X5jICguD/AoB/syDFTQIUSiGf4TeAKBbYBEFaxIo mG8Wq9iCvMAzBFqGwWIsv8p9h3zVRYX36XMEWufAighS+y2Q6XkK0yUKBjRponjAQgKLChQ/ 9x6hsM8D2/eQDBbIFwpIfBjrfKEYn56prDn03oGi7x8o/X5J9ffLq7/3Xj91fye55kLHodPH G043HiivPFBelQdM9WDFO+zt/zZwfOX+sjwVBUrzG5UH8mDHvNnGLlsNFFXWFFXXFtccKqmt Lz1UX1rXUFbXWFbfWF5/uLzhDUcqvsthoPAtHImOR6Bz0RUayg41lBaoL62th4sjahDFiLo8 RUB1gYNVh/IcqARq98D+hJ2IugLVQH2eg3lq6osQDcW1DSXAocZSBHYDtQi0sxZ9+y3geLiZ aqCuqAo4dLASqEWfVXUH4ZawaxbVNhYdaiyuO1xcd6SkvkDpX5HfX4xRVHfkYN2RA4cO769t 3FfT8EF1/fuVh96rqP1hWfUPSyp/UFzxgyKg/B8OlgGwgSiu+GFJxXulVR+UV++rrN0Pz1tT d7C2vqiuoaiusageOHwQ40Bd44FDjftrG/bV1u+rqd9XXbev6hCishadiAHdBT1ZVA287eH/ hPxhh4oL1BZV5ak5WFlzoKJ6f3nV/rKqfWWV+9Bn1QfwCXdYUVNoBa4AfQideaixpO4tpXWH 31L/BtRRZUDDX5E/AJ0LwwejAz2P7g0LiXwk1OzHGv2bwP0A0HXvlwFV75dWvVda+V5JJfos RX+inYjq98ur4bAPyms+wE7ZV7HXaYUYy7f4tk9KELXFVTXFkCmV1UX5HCyDPoEOgXSrgv5B OZjPJiyh4Mi/SUmBaqD4Dfmz9shn5RsKCY6aQy3mG4VRQIMCQ1NRg3qmqhbdM/QVGgsE9F4e 6MkC+T3Yt+hI9KTv9GpFNRpTNLiVH5TmqfigBKPwJyIfAN8B4qEAhG5p5ftACVCBKAbKCxT9 FXtfQSv7SoF8Z1ajnqysgUFHQDTm47PmLdj9o6fGbh7iE9051i0YcJ/oVhFvewxdHx4H2oIW y94vKnuvqPS9g4gfHih5ww/2A8UF9hX/Q4EiAP7E9mNHwolFZejO4bLQBBp9dMP5gIFOLqkF 9oref0P+YAw4EXEIgIKMKKQkYi8r82DBiRqCog3lGivRjUerjhyvOnqiGjh2sgY4frL2+Cng 0IkCdd/lJHDoOKIWOHai5hicDhc5XnH4WHnjUchWqHtFtQ1QCSFBIFlQ7qCxLkTIvpJyjLJ9 xUDpB0VACfD+QcR7iNL3YWdxGfT83iijgc4Hdj7IUVpBIlTVlGAUV6E/sckOzVYwkUET+bFD wKVQW2Wo0TetFyiHg9HsVlFVuGB1bWntodLaOqBsD2zPodKaWqCkGo4ptIilNrSITZ2l+Ssj 8jMpNoGiKTh/5WI4EU5H82YdmuMO1aNZD2bAPA2N78ye/ykVjd+i8v+N75z1/8je6Y3vUpEH 3S3cfENpHVSMumKgNp9oKAEPVNUA+yuhRKD68H4ppHb5e8XlkAKQCFguIPZGOT8K5dBj+6AP MT4oLX+/BPIlf2TJG2APjNr+svKD5RVFFRVFlZXFVVUl1dXfobi6uggGqArKAur/AxWQcfko QuOyDzWEfb4BhRlqFEVLfiN/AJwFFTVfW7CSUlwLTwrrEMim/HwHxQcr7Ht3DsDtfQeIEATE AwQMhE1VfvlUV5JfPmGjn6c8T2Oew+9S9m1KGw+XYBQ3Hi5qOHywofFAfeOBuob9h+qxWb5u X80hYD/GgVpYGNQVwTDV5QcLKg88FKQMhCiELgxB6b7ifBoWvwccKPohsL8A/PnegWL4CjIU EhbSFo1CSdmB0nLgIFBWXlSgokDpf0s5gM4FSt5SVFJeXIooAcrKS/OUV5RWAJWllZUlMOJV aIiLa2qKamoOVheC7YMKmKxhBi//YVHpDw6W/OBA8T/shzp88O8/AA78NfAV8IP9RcAPDxT/ ECoPFmCoVmCDiMVYZXElNFdVVl1dXlNToPYdamA/9tXenrKaAqV5qqu/Rc0721VVCHgiABqq qECUI4q+RTkAPQwcwEClphBp+RU7hFYF3C2MJtwwSorKKpQXVd9NCthZBBlRmc8ILOb3sgwe H3oMuiLfaYgPvssPoLsw9qIC4gSFxNuowGrs/nw6F8DuEOXXXpZh8yk2mcK0CJMj1ujbFg/8 /ft59v93vDlyjzcj+13ePgIEw7t/omfZV/Te/qL3DxR9cLB4f1HJgeKSotLS4rKykoryssqK 8urK8poqGOKK2uqKQzUINMrViBqIChhBNHwwcDA6kEcQPFDWgMLTfQfoZ4z3oAegHwCYE6F6 wNoMVs6wPsGWZAdhxVVTDyt5tJj/FrBmfpf8zr0VGtRetMiBBR4Ape8dUDGs+Vtg8yZWJLFS gM1l+YjCgupdsHFEU+cHxfCAWKE4UPy9fQe/t7/470oqv19W/f2K2v8fyvS7QB22600AAAAA SUVORK5CYII= --------------070206090309060903070807-- From nobody Sat Oct 18 06:36:21 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B8E1A87C9 for ; Sat, 18 Oct 2014 06:36: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 fmni9ab-4rWZ for ; Sat, 18 Oct 2014 06:36:18 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC141A87C8 for ; Sat, 18 Oct 2014 06:36:18 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 65B67509B6; Sat, 18 Oct 2014 09:36:17 -0400 (EDT) Message-ID: <54426C86.2010400@seantek.com> Date: Sat, 18 Oct 2014 06:35:02 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/K2a6kDOp1g1X4l1DvYk8mc3jkc4 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Oct 2014 13:36:20 -0000 On 10/17/2014 9:28 PM, Murray S. Kucherawy wrote: > I'm also skeptical about what's at the end of Section 6.4, in terms of > insisting on prior authorization to make changes or updates to > existing names. BCP26 doesn't seem to preclude it, but is there > precedent for operating a registry this way? Honestly, not sure. I don't have a strong feeling on this point, so whichever way the WG wants to go on that is fine. Overall though we should anticipate that the syntax registrations will change over time if they are to have continuing value. The purpose was to avoid malicious bots spamming the registration webform. > > Finally, the syntax registry definition in the first document looks > sort of complex to me. I browsed a random selection of existing IANA > tables at http://www.iana.org/protocols just now and all of them are > pretty much in a simple row-column format. In contrast, the registry > being created for syntaxes here seems to be a lot more complex than > what one could create with a purely linear schema. I can't speak for > IANA but I have to wonder if they can or would handle a registry that > has a bunch of values, some of which themselves contain a bunch of > values. You might want to ping someone from IANA to ask about that. On this point, we should all step back and note that the purpose of a syntax registration is to be easier to register than an Internet media type. There is a registry of Internet media types--and each media type has a very detailed registration template that must be followed. Note that for Internet media types there are also a lot of optional fields, but RFC 6838 does not explicitly mark them as {optional}. Ditto for URNs and URIs. There are simple tables of identifiers, but the semantic meaning of the identifier is potentially very intricate. There is no difference here. Actually, a significant quantity of the IANA tables have three columns: identifier | prose-description-of-identified-thing | [references] The [references] are necessarily intricate--like RFCs. In draft-03, the Markdown Syntaxes Registry is supposed to be really easy to get things registered (First-Come, First-Served -- compare with the complexities of media type registration!), but the information requested is supposed to be in a sufficiently structured format to ensure GIGO--good in, good out (and garbage in, garbage out). If someone registers a poor or useless syntax identifier, it's their problem. We can make the registration template simpler, but then to ensure quality we probably need Expert Review, which encumbers the process. What ends up happening when the template is simpler is that the commentary/prose fields get stuffed with more semantic discussion, because the semantics weren't expressible in the formal template fields in the first place. Sean From nobody Sat Oct 18 08:02:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281A51A0055 for ; Sat, 18 Oct 2014 08:02:43 -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 nJc-QILI3NYZ for ; Sat, 18 Oct 2014 08:02:41 -0700 (PDT) Received: from cp.hebergementsolutions.com (cp.hebergementsolutions.com [184.170.132.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BB0B1A887A for ; Sat, 18 Oct 2014 08:02:40 -0700 (PDT) Received: from [96.127.249.215] (port=50474 helo=minimi.michelf.ca) by cp.hebergementsolutions.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1XfVXZ-0004pY-2z; Sat, 18 Oct 2014 11:03:33 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_759BB744-A9D2-4DA9-8BFD-8EEBD0D56FBC"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michel Fortin In-Reply-To: <54426B74.9090006@seantek.com> Date: Sat, 18 Oct 2014 11:02:03 -0400 Message-Id: References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <54426B74.9090006@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.1990.1) X-cPanel-MailScanner-Information: Please contact the ISP for more information X-cPanel-MailScanner-ID: 1XfVXZ-0004pY-2z X-cPanel-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-cPanel-MailScanner-SpamCheck: X-cPanel-MailScanner-From: michel.fortin@michelf.ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cp.hebergementsolutions.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - michelf.ca X-Get-Message-Sender-Via: cp.hebergementsolutions.com: authenticated_id: michel.fortin@michelf.ca Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Kd1YgLszuTz69Xba9wfEUvl8FT4 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Oct 2014 15:02:43 -0000 --Apple-Mail=_759BB744-A9D2-4DA9-8BFD-8EEBD0D56FBC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 18-oct.-2014 =C3=A0 9:30, Sean Leonard a = =C3=A9crit : > So maybe I should address the WG on this point: what is the feeling = about renaming "output-type" to "preview", with refers to the live = preview, or "right-hand side", of the Markdown editor? But even for live previews, the output type is a mere technical detail = of the processing required to produce the preview in the editor. It = doesn't really matter if one editor converts to HTML and then to a = screen representation and another editor converts to Latex and then to a = screen representation, as the same content is shown in the preview. --=20 Michel Fortin michel.fortin@michelf.ca https://michelf.ca --Apple-Mail=_759BB744-A9D2-4DA9-8BFD-8EEBD0D56FBC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMjTCCBjQw ggQcoAMCAQICAR8wDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAI6ByrMlixq5 piBb1m3JRDRfINXQII5OT8TWqeZz8zse9vt7fUZHaPVLFeWYlj8B9BA2uHhGfyZtPtyf0nYtnFPK g7xiSXX/apE16bFfYdtHka3qupMggZp1+OZmtAdRO/TRij5C2bV2o+kIf+53LfWav2tw6pICxfJO 9Hrjl7HbYo3+l3ul9YVB5SVKG8WLmMCkpm7ti1Z4LOYF0Y5AG3d8AqYS3/5aUWQN/ZQN4BMruXSJ GFYFYBDxu7jTBbBW9l2m4u/s80e+jkJ9P9XDXeOsclCsdAtY4F2C/kOH76j6fwiABKLx454BkTMt ukts/PLtzrIy37oV0UTiykmcFCXSmc1gQk+xz25vGs/D36Ve8L+2A+J7idUYP83A1wS4JLgb4Q7J Fzl/lqLO+IDM+AGH9cujofg7Pjl2HdyDq3FOn7eAz2ZPN+zGzes5/E8rK1QnTsk9tIsi7QRIPdAB TnhC8ImOaNjVkB9JGUJ2BAXwVLB5Dq9SEdnGiyWdS7a9fb+Tfy8D2wuOA9metV0hUlrPMHCmJtZR bFZAjOlQrKhMM5hE31Qal2HF6OkfVhtE0nvqgj6dLt3871yxSYh13c0OBF6kZPR9Sgij3GZhAwEN sESI065Wg0BRSoCtWB6RxATzwIyIGgD/Gm8uPp+cv9OtSrDRwNjGphN+MQ81oVh5MIIGUTCCBTmg AwIBAgIDCZgGMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTQwNDEwMDkzMjE4WhcNMTUwNDEyMDIxMjUzWjBnMRkwFwYDVQQNExBZbjhVdjUyNmNnNGJjcmlR MSEwHwYDVQQDDBhtaWNoZWwuZm9ydGluQG1pY2hlbGYuY2ExJzAlBgkqhkiG9w0BCQEWGG1pY2hl bC5mb3J0aW5AbWljaGVsZi5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM1xHBAc 28F84D5D/ITRvjBwB3dwI7osaLizqSCZhMRpXg4zWsxIoaDy6H9OTQdpaqY431ypMGiwd7vddirK pEn/DEVb0SItTb73touChfuVVE5LHYPKcL1CfRa0XJF4KhryeP/m9sPA4N4zLb7IR4HFioOkF/XL Hkh9bv12yXUK+6jWpSNaQNf/kUz2AlKUSSx4pW2kBH72EW4xreuRs30Qqft1rqwkL4LRhipd3GA9 0Pni7mOaNSKu3kGCHKz+/4+h4SUdNuD13nhZLwLFHyHhk4I+IpFyq5/vPFr/dFRg3rdpMxhgd+M/ H4rfaUm2Kb0ODq+7FXccjDSbhCFEc08CAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQD AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUu56gBRTHUtBmsqyG mqCVXtMAz9cwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYbWlj aGVsLmZvcnRpbkBtaWNoZWxmLmNhMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCC ASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRp b24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFy dHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29t L2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3Nw LnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2Fp YS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqG GGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAJjgunxV0rh494ufL ch4bvYfoewNrW9OIZjpyS3GTzjD+a8aUIctmXo5HilIew8NwaYzRRKhQ3V4uy3rPmpIGddZfXlxm jlejMlWCVcgBBuB2CziegUCWvJbpSjz4eM0dQX6nU0zAGV1iqWkdrIxMgkgeeGWZaWV+m2Qu/oWw 9EbgegPaz+cFJNbrZEjA06d9CKQJTn2MP7POPPSwDTlTHZ/b6/X1MckAfCeEm96CRCEEzBo06Yki UMJMOdqVggAyP7huNxo7TpnNfe7ylve4vsHBSxpW7NElcMaXIgFalFVmpxZICOvxcncajCmYOzJp cb+YJuJwkeYf5CMjGsBshzGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAwmYBjAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNDEwMTgxNTAyMDRaMCMGCSqGSIb3DQEJBDEWBBTieBLdvXXDnN9rSB3mcNuv2x7H cTCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwmYBjCB pwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCZgGMA0G CSqGSIb3DQEBAQUABIIBAHA1S0AjEB4/kUIRyrKzOt2+v9Kfx67V/gXMPcdHsEmeVhOyLMpqV40b /4TcSrsmK8ucZgMEx/n6UMp0ziasquTWsDLOui4zAjREi9tCkAXMuUf517ovoyvThTsw42Bj3QFx cCTb5xmmqAiSi+hRq3VfdSgw8+KTpCDNajgymjgh96nuNAttdasJWnpu3HJao3QzUPkAUP4uB7Il +XLAVaRxgG/qOWFMr6246Sl2o2r+jDQalhPIp7wGjTM5R5q/aBeo7rf2vh1TDh1d5quN2zGRvGKM PGeCkuneR38c1u8izF7HJVAIVBx33ZpnVg3G3xoRWhZiyh8coVWRxTU7TJYAAAAAAAA= --Apple-Mail=_759BB744-A9D2-4DA9-8BFD-8EEBD0D56FBC-- From nobody Sat Oct 18 10:10:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C3A1A8934 for ; Sat, 18 Oct 2014 10:10:07 -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 kd5k3lB-t0eD for ; Sat, 18 Oct 2014 10:10:04 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF4A71A8930 for ; Sat, 18 Oct 2014 10:10:03 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 6AFA6FA0088; Sat, 18 Oct 2014 17:10:01 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1413652200-4330-4329/12/12; Sat, 18 Oct 2014 17:10:00 +0000 From: Arnt Gulbrandsen To: Sean Leonard , IETF Apps Discuss , Michel Fortin Message-Id: <40081b86803172f9fe00ced45f3fa2dd78ddf4ed724a7ea3a744bb08880300d1.sha-256@android.antelope.email> References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <54426B74.9090006@seantek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Date: Sat, 18 Oct 2014 17:10:00 +0000 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3_6oxEBJW3H-IsO9Pbxk0jYgqfo Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Oct 2014 17:10:07 -0000 This and an earlier message today set me thinking. I am not sure the = result is significant to this document, but allow me to present it. Markdown is originally derived from conventional email formatting. And = it really does look like email - I have seen countless messages that may = be syntactically valid markdown source, and I expect so have everyone = else on this list. But those email messages don't have content-type text/markdown. They = have type text/plain, perhaps with format=3Dflowed. Markdown, as used in = email, is a flavour of text/plain, and is properly described as plain so = that renderers work in the traditional manner while a markdown-capable = receiver does the right thing. I don't know what happens of one sends a message marked text/markdown. = Perhaps most readers handle it as plain? I think this is a worthwhile = experiment. I will send something to this list when I am back at my desk. Arnt From nobody Sat Oct 18 13:03:59 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491161A0276 for ; Sat, 18 Oct 2014 13:03:58 -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 JNj-pfYac33O for ; Sat, 18 Oct 2014 13:03:56 -0700 (PDT) Received: from relay14.mail.ox.ac.uk (relay14.mail.ox.ac.uk [163.1.2.162]) by ietfa.amsl.com (Postfix) with ESMTP id B99691A0273 for ; Sat, 18 Oct 2014 13:03:56 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay14.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1XfaEE-0005fn-k0; Sat, 18 Oct 2014 21:03:54 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina-wl.atuin.ninebynine.org) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1XfaED-0003he-9F; Sat, 18 Oct 2014 21:03:54 +0100 Message-ID: <5442C7A8.1010901@ninebynine.org> Date: Sat, 18 Oct 2014 21:03:52 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sean Leonard , "Murray S. Kucherawy" References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <54426B74.9090006@seantek.com> In-Reply-To: <54426B74.9090006@seantek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0Um1XOVt38LToV1Qm5YhXok4qEo Cc: IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Oct 2014 20:03:58 -0000 On 18/10/2014 14:30, Sean Leonard wrote: > Splitting the document had two goals in mind: > 1) The text in the secondary document is not "as normative" as the first > document. In the first document, it says that the original [MDSYNTAX], > "Original", MUST be supported. The others do not have to be supported. > > 2) If we include seven additional registrations in the first document, it > becomes "too long". People thought the first document was getting too long. Speaking for myself, I think you misunderstand the concern. "Too long" is often a proxy for "too complicated" or "too detailed" (I'm not sure I used that term, but if I did, that's what I would have meant.) The critical thing is how much text a developer must read through to understand the basic concept. Too much background detail/justification and too much complexity in the specified mechanism (both things I've previously argued against in earlier drafts) fall into these categories. Having a list of registrations may technically increase the length of the document, but not in the important sense noted above, as they should be clearly distinct from the core mechanism description. So I think it's fine for the registrations to be in the primary document. (More generally, I think the the appswg should consider just the core document describing the content type, parameter registry and initial registrations. I think the other document could be submitted as an independent stream informational document (or even as an IESG non-WG submission?). I, for one, have little interest in reviewing this kind of additional content - but if you think it's useful to publish then I'm OK with that if it doesn't consume WG bandwidth.) #g -- From nobody Sat Oct 18 13:22:39 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6FB1A033B; Sat, 18 Oct 2014 13:22:37 -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 MRESOFdvBIWr; Sat, 18 Oct 2014 13:22:35 -0700 (PDT) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5A41A0278; Sat, 18 Oct 2014 13:22:35 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1XfaWH-0003n1-id; Sat, 18 Oct 2014 21:22:33 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina-wl.atuin.ninebynine.org) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1XfaWH-00044V-7m; Sat, 18 Oct 2014 21:22:33 +0100 Message-ID: <5442CC08.6080106@ninebynine.org> Date: Sat, 18 Oct 2014 21:22:32 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: internet-drafts@ietf.org, Sean Leonard References: <20141017233352.18234.3690.idtracker@ietfa.amsl.com> In-Reply-To: <20141017233352.18234.3690.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Qwd5_O578yxfV7SG7umuVcYAtRU Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-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: Sat, 18 Oct 2014 20:22:38 -0000 Sean, I just took a quick look at the new draft. I don't remember anything about fragment identifiers in the previous draft that I reviewed. I think what you have in the latest draft is seriously broken. E.g. "#o#page=6" is not a valid fragment identifier in a URI, per http://tools.ietf.org/html/rfc3986#section-3.5 (there's no such thing as a secondary fragment, and a fragment can't contain an unescaped '#') To my mind, this MUST be fixed. I'm not sure that the whole section about fragments makes sense, and would be inclined to just drop it. #g -- On 18/10/2014 00:33, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : The text/markdown Media Type > Author : Sean Leonard > Filename : draft-ietf-appsawg-text-markdown-03.txt > Pages : 22 > Date : 2014-10-17 > > Abstract: > This document registers the text/markdown media type for use with > Markdown, a family of plain text formatting syntaxes that optionally > can be converted to formal markup languages such as HTML. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-text-markdown-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/ > > _______________________________________________ > 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 From nobody Sat Oct 18 14:05:53 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA761A1A6E; Sat, 18 Oct 2014 14:05:51 -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 oOdIG4Ay7jDi; Sat, 18 Oct 2014 14:05:48 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51A01A1A6D; Sat, 18 Oct 2014 14:05:48 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7BA7B509B6; Sat, 18 Oct 2014 17:05:47 -0400 (EDT) Message-ID: <5442D5DF.3010107@seantek.com> Date: Sat, 18 Oct 2014 14:04:31 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: internet-drafts@ietf.org, apps-discuss@ietf.org References: <20141017233352.18234.3690.idtracker@ietfa.amsl.com> <5442CC08.6080106@ninebynine.org> In-Reply-To: <5442CC08.6080106@ninebynine.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/u9OoNarzcUT-jWI9yjKQ15MCAiM Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-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: Sat, 18 Oct 2014 21:05:51 -0000 On 10/18/2014 1:22 PM, Graham Klyne wrote: > Sean, > > I just took a quick look at the new draft. > > I don't remember anything about fragment identifiers in the previous=20 > draft that I reviewed. I think what you have in the latest draft is=20 > seriously broken. E.g. "#o#page=3D6" is not a valid fragment identifie= r=20 > in a URI, per http://tools.ietf.org/html/rfc3986#section-3.5 (there's=20 > no such thing as a secondary fragment, and a fragment can't contain an = > unescaped '#') > > To my mind, this MUST be fixed. I'm not sure that the whole section=20 > about fragments makes sense, and would be inclined to just drop it. Hmmm...just looked at it. You're right. I guess that in a URI there can=20 literally be only zero or one # character. At a minimum, the delimiter should not be "#". Let's go with ":", which=20 was my original idea (#t:line=3D10 using [RFC5147]). The broader question (which the section on fragment identifiers was=20 supposed to raise) is "what do fragment identifiers mean in the context=20 of Markdown content?" Because guess what...the media type registration=20 is where fragment identifiers get defined. Section 4.11 of [RFC6838]. At a minimum, we should not have less semantics than text/plain=20 [RFC5147]. Unless people think otherwise. (I would like to hear=20 arguments why Markdown content should not be addressable using=20 text/plain fragments.) Then the question is should we have more than text/plain fragments. To=20 [Michel Fortin's point][o]: some Markdown-derivative syntaxes have an=20 attribute specification {#o} that can be applied to header fields. This=20 is the case with PHP Markdown Extra, and with pandoc=20 (header_identifiers, which derives the rule from PHP Markdown Extra).=20 Pandoc also allows for attribute specifications to be attached to code=20 blocks (fenced_code_attributes extension). That is why in the pandoc=20 syntax registration, I added #id# for {#}.=20 (Note: now it should be #id:.) [o]:=20 http://mailarchive.ietf.org/arch/msg/apps-discuss/J4SkvytTQPqlBPzXej8Mn5r= v524 Adding more fragment identifiers makes the spec more complex. But is=20 this complex for the sake of complexity, or complex because we are=20 dealing with a complex technology? Nobody is forcing header {#o} down=20 anyone's throat. Most Markdown syntaxes (including [MDSYNTAX]) don't=20 have it. We could remove the prefix "id:" (and the prefix "t:") so that=20 the fragments are "simpler", but then there would be name clashes if you = say line=3D10 and somebody puts in {#line=3D10} in the Markdown. All of this goes to the broader point of whether and to what extent=20 "text/markdown" can be used for different implementations=20 (implementations of what??) to interoperate. We have a situation where=20 there are probably over 100 different "Markdown" syntaxes out there on=20 the market with some kind of traction in particular communities. Should they all be "text/markdown; charset=3Dfoo" and call it a day? Are = we satisfied that there will be 100 different syntaxes that have=20 disjoint (and occasionally conflicting) features with no way to=20 distinguish intelligently between them? Should there be 100 different, separate media type registrations? (This=20 may not be as bad as it sounds. But it means that, de-facto, the 100=20 different registrations will not have common points of interoperability=20 between each other.) Should we have a new "markdown" top level type, or a new=20 "text/markdown." facet prefix? Should we call this "text/editable; syntax=3DMarkdown"? What makes some text "text/editable" and other text (say, troff, html)=20 not "editable"? Should we say "text/plain; mdsyntax=3DGFM" for texts in Markdown Syntax? = What are the security implications of overloading text/plain with an=20 open-ended list of syntaxes that include URIs and executable code? Those are the myriad of different ways to do this. I am happy to defer=20 to WG consensus. But we have many different ways that this can be=20 skinned; what matters for standards activity is not that one way is=20 "best", but that everybody agrees to do it the same way. Until then,=20 everybody will be using "text/x-markdown" and nobody will know exactly=20 what that means. Respectfully submited, Sean From nobody Sat Oct 18 14:37:59 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07A71A1ADB for ; Sat, 18 Oct 2014 14:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ynAYrr5H0D8 for ; Sat, 18 Oct 2014 14:37:54 -0700 (PDT) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3698E1A1AD2 for ; Sat, 18 Oct 2014 14:37:54 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id m20so2133236qcx.33 for ; Sat, 18 Oct 2014 14:37:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=75OkhJttmMupwMv5yHZBmD8OCON2qQXUsRzCT0OwiFg=; b=b6vxjFozsGOa+jt25cYI/RXob9lGBdwcOZhty51exQyBLs932+ns//GYAbLGnS2eEB mGwLFFrQdKuzcyCbJMlsp2t2DLPMU8AjsDhMEZwnJGydn2WCSALHkBu0ovjU6SlgSb6P bblCcOQOi4npFq+Zi7gD6GWYyxWzkeBm64IaJYtEbPj+YAQ1Ihdj+gEoSwQz+dUgUahX TRSMj5dd8UMTgG+5IgU925Csb6Cwmcla1fO0iWsWwRuuWFjOt/xdckLvehb8FudXPTXL TOPTR2jAb0ueZhTx7zqeEwrUM63RRKuGT1f6t885dEHCKb4An/lZIFkzaHCZQJTKhm6z OrWw== X-Gm-Message-State: ALoCoQn4i2uwTGv1JzAtKJFAiMHD0zHKjLZQLHZVWFLaswDgUf3j4VpGeYl/mg3lXJV6pAf8SFe3 X-Received: by 10.140.84.106 with SMTP id k97mr22097680qgd.76.1413668273332; Sat, 18 Oct 2014 14:37:53 -0700 (PDT) Received: from Everready.local ([76.73.248.16]) by mx.google.com with ESMTPSA id e7sm4097418qaf.11.2014.10.18.14.37.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 18 Oct 2014 14:37:52 -0700 (PDT) Message-ID: <5442DDAE.7030506@fletcherpenney.net> Date: Sat, 18 Oct 2014 17:37:50 -0400 From: "Fletcher T. Penney" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sean Leonard , internet-drafts@ietf.org, apps-discuss@ietf.org References: <20141017233352.18234.3690.idtracker@ietfa.amsl.com> <5442CC08.6080106@ninebynine.org> <5442D5DF.3010107@seantek.com> In-Reply-To: <5442D5DF.3010107@seantek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JJDkn0RVs0GPjKY9X4aGdULAAP0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-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: Sat, 18 Oct 2014 21:37:56 -0000 On 10/18/14, 5:04 PM, Sean Leonard wrote: > Should they all be "text/markdown; charset=foo" and call it a day? Are > we satisfied that there will be 100 different syntaxes that have > disjoint (and occasionally conflicting) features with no way to > distinguish intelligently between them? Yes. Absolutely yes. > Should there be 100 different, separate media type registrations? (This > may not be as bad as it sounds. But it means that, de-facto, the 100 > different registrations will not have common points of interoperability > between each other.) Yes. Absolutely yes. If the content being used is not Markdown, then they should not use "text/markdown." > Should we have a new "markdown" top level type, or a new > "text/markdown." facet prefix? I am indifferent on this -- depends on what the prevailing "culture" is for media types. Out of my area of expertise. > Should we call this "text/editable; syntax=Markdown"? No. All text is editable. > What makes some text "text/editable" and other text (say, troff, html) > not "editable"? > > Should we say "text/plain; mdsyntax=GFM" for texts in Markdown Syntax? > What are the security implications of overloading text/plain with an > open-ended list of syntaxes that include URIs and executable code? I assume by "mdsyntax" you mean "markdownsyntax". To reiterate my earlier points -- this is like "kleenex". To be more accurate you *could* say "markupsyntax=markdown" or "markupsyntax=GFM", etc. I think "text/markdown" and "text/GFM" would be better, but there is certainly room to debate. > > Those are the myriad of different ways to do this. I am happy to defer > to WG consensus. But we have many different ways that this can be > skinned; what matters for standards activity is not that one way is > "best", but that everybody agrees to do it the same way. Until then, > everybody will be using "text/x-markdown" and nobody will know exactly > what that means. The problem is not really what "text/x-markdown" means. It's really clear. It means "Markdown." The problem is that people don't know what Markdown means. It is not "GFM" or "PHP MD Extra", etc. It's Markdown. I don't think a media type, no matter how elaborate or complicated, is going to solve that problem. F- -- Fletcher T. Penney fletcher@fletcherpenney.net From nobody Sat Oct 18 14:39:52 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211E91A1AF6 for ; Sat, 18 Oct 2014 14:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUE7GxrGrBZ0 for ; Sat, 18 Oct 2014 14:39:48 -0700 (PDT) Received: from cp.hebergementsolutions.com (cp.hebergementsolutions.com [184.170.132.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ED191A1ADB for ; Sat, 18 Oct 2014 14:39:48 -0700 (PDT) Received: from [96.127.249.215] (port=54118 helo=minimi.michelf.ca) by cp.hebergementsolutions.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1Xfbk5-00060e-W2; Sat, 18 Oct 2014 17:40:54 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_1D5FDBE2-E233-4D53-848C-C164453DBEE2"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michel Fortin In-Reply-To: <54425EFF.10501@fletcherpenney.net> Date: Sat, 18 Oct 2014 17:39:24 -0400 Message-Id: <2F19BAB0-F130-4E22-B649-A2D0371EB0D9@michelf.ca> References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <150B87D9-F747-4B89-87C0-F1F15A337476@michelf.ca> <54425EFF.10501@fletcherpenney.net> To: "Fletcher T. Penney" X-Mailer: Apple Mail (2.1990.1) X-cPanel-MailScanner-Information: Please contact the ISP for more information X-cPanel-MailScanner-ID: 1Xfbk5-00060e-W2 X-cPanel-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-cPanel-MailScanner-SpamCheck: X-cPanel-MailScanner-From: michel.fortin@michelf.ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cp.hebergementsolutions.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - michelf.ca X-Get-Message-Sender-Via: cp.hebergementsolutions.com: authenticated_id: michel.fortin@michelf.ca Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/jVUmkWVEF064upDMX9_k2ziDnxU Cc: IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Oct 2014 21:39:50 -0000 --Apple-Mail=_1D5FDBE2-E233-4D53-848C-C164453DBEE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 18-oct.-2014 =E0 8:37, Fletcher T. Penney = a =E9crit : > I understand that Gruber has, in his way, consented to the concept of = "text/markdown." Has he consented to the idea of using "text/markdown" = to refer to a bunch of things that are not Markdown? Based on past = history, I would bet not -- but you never know and clearly I cannot = speak for him. I would recommend asking him. I would not support the = idea of using "text/multimarkdown" to refer to things that are not = MultiMarkdown. I'd tend to define "text/markdown" as identifying documents using the = Markdown syntax and its compatible derivatives. "Compatible" in the = sense that they mostly follow the rules of the official syntax document = on daringfireball.net. Pragmatically, you can't define it that much differently from how people = have been using the .md and .markdown file extensions, because everyone = knows that those extensions are going to be mapped to "text/markdown" = eventually (it's just obvious) regardless of what the RFC says. I think = we should simply formalize the obvious. --=20 Michel Fortin michel.fortin@michelf.ca https://michelf.ca --Apple-Mail=_1D5FDBE2-E233-4D53-848C-C164453DBEE2 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMjTCCBjQw ggQcoAMCAQICAR8wDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAI6ByrMlixq5 piBb1m3JRDRfINXQII5OT8TWqeZz8zse9vt7fUZHaPVLFeWYlj8B9BA2uHhGfyZtPtyf0nYtnFPK g7xiSXX/apE16bFfYdtHka3qupMggZp1+OZmtAdRO/TRij5C2bV2o+kIf+53LfWav2tw6pICxfJO 9Hrjl7HbYo3+l3ul9YVB5SVKG8WLmMCkpm7ti1Z4LOYF0Y5AG3d8AqYS3/5aUWQN/ZQN4BMruXSJ GFYFYBDxu7jTBbBW9l2m4u/s80e+jkJ9P9XDXeOsclCsdAtY4F2C/kOH76j6fwiABKLx454BkTMt ukts/PLtzrIy37oV0UTiykmcFCXSmc1gQk+xz25vGs/D36Ve8L+2A+J7idUYP83A1wS4JLgb4Q7J Fzl/lqLO+IDM+AGH9cujofg7Pjl2HdyDq3FOn7eAz2ZPN+zGzes5/E8rK1QnTsk9tIsi7QRIPdAB TnhC8ImOaNjVkB9JGUJ2BAXwVLB5Dq9SEdnGiyWdS7a9fb+Tfy8D2wuOA9metV0hUlrPMHCmJtZR bFZAjOlQrKhMM5hE31Qal2HF6OkfVhtE0nvqgj6dLt3871yxSYh13c0OBF6kZPR9Sgij3GZhAwEN sESI065Wg0BRSoCtWB6RxATzwIyIGgD/Gm8uPp+cv9OtSrDRwNjGphN+MQ81oVh5MIIGUTCCBTmg AwIBAgIDCZgGMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTQwNDEwMDkzMjE4WhcNMTUwNDEyMDIxMjUzWjBnMRkwFwYDVQQNExBZbjhVdjUyNmNnNGJjcmlR MSEwHwYDVQQDDBhtaWNoZWwuZm9ydGluQG1pY2hlbGYuY2ExJzAlBgkqhkiG9w0BCQEWGG1pY2hl bC5mb3J0aW5AbWljaGVsZi5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM1xHBAc 28F84D5D/ITRvjBwB3dwI7osaLizqSCZhMRpXg4zWsxIoaDy6H9OTQdpaqY431ypMGiwd7vddirK pEn/DEVb0SItTb73touChfuVVE5LHYPKcL1CfRa0XJF4KhryeP/m9sPA4N4zLb7IR4HFioOkF/XL Hkh9bv12yXUK+6jWpSNaQNf/kUz2AlKUSSx4pW2kBH72EW4xreuRs30Qqft1rqwkL4LRhipd3GA9 0Pni7mOaNSKu3kGCHKz+/4+h4SUdNuD13nhZLwLFHyHhk4I+IpFyq5/vPFr/dFRg3rdpMxhgd+M/ H4rfaUm2Kb0ODq+7FXccjDSbhCFEc08CAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQD AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUu56gBRTHUtBmsqyG mqCVXtMAz9cwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYbWlj aGVsLmZvcnRpbkBtaWNoZWxmLmNhMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCC ASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRp b24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFy dHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29t L2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3Nw LnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2Fp YS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqG GGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAJjgunxV0rh494ufL ch4bvYfoewNrW9OIZjpyS3GTzjD+a8aUIctmXo5HilIew8NwaYzRRKhQ3V4uy3rPmpIGddZfXlxm jlejMlWCVcgBBuB2CziegUCWvJbpSjz4eM0dQX6nU0zAGV1iqWkdrIxMgkgeeGWZaWV+m2Qu/oWw 9EbgegPaz+cFJNbrZEjA06d9CKQJTn2MP7POPPSwDTlTHZ/b6/X1MckAfCeEm96CRCEEzBo06Yki UMJMOdqVggAyP7huNxo7TpnNfe7ylve4vsHBSxpW7NElcMaXIgFalFVmpxZICOvxcncajCmYOzJp cb+YJuJwkeYf5CMjGsBshzGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAwmYBjAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNDEwMTgyMTM5MjVaMCMGCSqGSIb3DQEJBDEWBBTgDkV89D1MsZWoLRGl8XYGY+8j azCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwmYBjCB pwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCZgGMA0G CSqGSIb3DQEBAQUABIIBAJL5HMFonCYBmofqReuc8izwCn6be7zms/yEpAiSIGVOvXVuitWDWice sdd21ukA+8PSOjSfPKpPa6lHWtXKvyrsJVqgo8naJhb2ogz5GZ3cFOfdjY+ACtlNL0ZQlED0vTAy csIVwtWqxyEZdfrNp/MEk1oYp3cxLMsMYOoh6stg46xh9R2ppuSjHRY1GXRR6J/fNqAyZUVg3cYb BCK0MNMpHn/+/iL3d9u/goFxwYdp7dJykylzUcE3Vy6LS0QoxcWEgsF1o64WROFOFIKlePlEEvS9 0XIeuLKOBFlfgg3sJ7At20FJql+hquEOxpG7Zwf90Tl5KMfC4hLNgkYzYssAAAAAAAA= --Apple-Mail=_1D5FDBE2-E233-4D53-848C-C164453DBEE2-- From nobody Sat Oct 18 14:59:03 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06021A1B17; Sat, 18 Oct 2014 14:59:00 -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 uxt-2zyKduzU; Sat, 18 Oct 2014 14:58:58 -0700 (PDT) Received: from cp.hebergementsolutions.com (cp.hebergementsolutions.com [184.170.132.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512281A000F; Sat, 18 Oct 2014 14:58:58 -0700 (PDT) Received: from [96.127.249.215] (port=54229 helo=minimi.michelf.ca) by cp.hebergementsolutions.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1Xfc2X-0002rQ-RV; Sat, 18 Oct 2014 17:59:58 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_0A33D01D-7989-40AB-A0F7-3D590AA98FFD"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michel Fortin In-Reply-To: <5442D5DF.3010107@seantek.com> Date: Sat, 18 Oct 2014 17:58:28 -0400 Message-Id: References: <20141017233352.18234.3690.idtracker@ietfa.amsl.com> <5442CC08.6080106@ninebynine.org> <5442D5DF.3010107@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.1990.1) X-cPanel-MailScanner-Information: Please contact the ISP for more information X-cPanel-MailScanner-ID: 1Xfc2X-0002rQ-RV X-cPanel-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-cPanel-MailScanner-SpamCheck: X-cPanel-MailScanner-From: michel.fortin@michelf.ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cp.hebergementsolutions.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - michelf.ca X-Get-Message-Sender-Via: cp.hebergementsolutions.com: authenticated_id: michel.fortin@michelf.ca Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JBBmR30mzlXSz9qBRdjGbCYMrIw Cc: internet-drafts@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-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: Sat, 18 Oct 2014 21:59:01 -0000 --Apple-Mail=_0A33D01D-7989-40AB-A0F7-3D590AA98FFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 18-oct.-2014 =C3=A0 17:04, Sean Leonard a = =C3=A9crit : > Should they all be "text/markdown; charset=3Dfoo" and call it a day? = Are we satisfied that there will be 100 different syntaxes that have = disjoint (and occasionally conflicting) features with no way to = distinguish intelligently between them? That's what people have been doing all this time. We'd be no worse than = before. I agree that it'd be nice to be able to distinguish between all variants = in an automated manner, but I don't think it's pragmatic. My opinion is = that what is possible is of limited utility and not very realistic due = of complex coordination and maintenance requirements combined with low = incentives. It's probably possible if you limit yourself to some = specific usage scenarios, but I don't really know. As a way to try to satisfy your requirement, I've proposed an open = scheme before. Just let people use whatever variant identifier(s) they = want in a mostly free-form parameter. Maybe an ad-hoc standard will = emerge from those who actually use that attribute for something, in = which case it'll be defined and evolved organically on those people's = time based on their actual requirements. For everyone else it'll just be = a fancy optional field to declare your love to a specific variant. Indeed, we could just do without any parameter (other than charset) and = call it a day. I'm okay with that too. It's clearly the least = controversial approach. --=20 Michel Fortin michel.fortin@michelf.ca https://michelf.ca --Apple-Mail=_0A33D01D-7989-40AB-A0F7-3D590AA98FFD Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMjTCCBjQw ggQcoAMCAQICAR8wDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAI6ByrMlixq5 piBb1m3JRDRfINXQII5OT8TWqeZz8zse9vt7fUZHaPVLFeWYlj8B9BA2uHhGfyZtPtyf0nYtnFPK g7xiSXX/apE16bFfYdtHka3qupMggZp1+OZmtAdRO/TRij5C2bV2o+kIf+53LfWav2tw6pICxfJO 9Hrjl7HbYo3+l3ul9YVB5SVKG8WLmMCkpm7ti1Z4LOYF0Y5AG3d8AqYS3/5aUWQN/ZQN4BMruXSJ GFYFYBDxu7jTBbBW9l2m4u/s80e+jkJ9P9XDXeOsclCsdAtY4F2C/kOH76j6fwiABKLx454BkTMt ukts/PLtzrIy37oV0UTiykmcFCXSmc1gQk+xz25vGs/D36Ve8L+2A+J7idUYP83A1wS4JLgb4Q7J Fzl/lqLO+IDM+AGH9cujofg7Pjl2HdyDq3FOn7eAz2ZPN+zGzes5/E8rK1QnTsk9tIsi7QRIPdAB TnhC8ImOaNjVkB9JGUJ2BAXwVLB5Dq9SEdnGiyWdS7a9fb+Tfy8D2wuOA9metV0hUlrPMHCmJtZR bFZAjOlQrKhMM5hE31Qal2HF6OkfVhtE0nvqgj6dLt3871yxSYh13c0OBF6kZPR9Sgij3GZhAwEN sESI065Wg0BRSoCtWB6RxATzwIyIGgD/Gm8uPp+cv9OtSrDRwNjGphN+MQ81oVh5MIIGUTCCBTmg AwIBAgIDCZgGMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTQwNDEwMDkzMjE4WhcNMTUwNDEyMDIxMjUzWjBnMRkwFwYDVQQNExBZbjhVdjUyNmNnNGJjcmlR MSEwHwYDVQQDDBhtaWNoZWwuZm9ydGluQG1pY2hlbGYuY2ExJzAlBgkqhkiG9w0BCQEWGG1pY2hl bC5mb3J0aW5AbWljaGVsZi5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM1xHBAc 28F84D5D/ITRvjBwB3dwI7osaLizqSCZhMRpXg4zWsxIoaDy6H9OTQdpaqY431ypMGiwd7vddirK pEn/DEVb0SItTb73touChfuVVE5LHYPKcL1CfRa0XJF4KhryeP/m9sPA4N4zLb7IR4HFioOkF/XL Hkh9bv12yXUK+6jWpSNaQNf/kUz2AlKUSSx4pW2kBH72EW4xreuRs30Qqft1rqwkL4LRhipd3GA9 0Pni7mOaNSKu3kGCHKz+/4+h4SUdNuD13nhZLwLFHyHhk4I+IpFyq5/vPFr/dFRg3rdpMxhgd+M/ H4rfaUm2Kb0ODq+7FXccjDSbhCFEc08CAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQD AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUu56gBRTHUtBmsqyG mqCVXtMAz9cwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYbWlj aGVsLmZvcnRpbkBtaWNoZWxmLmNhMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCC ASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRp b24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFy dHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29t L2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3Nw LnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2Fp YS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqG GGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAJjgunxV0rh494ufL ch4bvYfoewNrW9OIZjpyS3GTzjD+a8aUIctmXo5HilIew8NwaYzRRKhQ3V4uy3rPmpIGddZfXlxm jlejMlWCVcgBBuB2CziegUCWvJbpSjz4eM0dQX6nU0zAGV1iqWkdrIxMgkgeeGWZaWV+m2Qu/oWw 9EbgegPaz+cFJNbrZEjA06d9CKQJTn2MP7POPPSwDTlTHZ/b6/X1MckAfCeEm96CRCEEzBo06Yki UMJMOdqVggAyP7huNxo7TpnNfe7ylve4vsHBSxpW7NElcMaXIgFalFVmpxZICOvxcncajCmYOzJp cb+YJuJwkeYf5CMjGsBshzGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAwmYBjAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNDEwMTgyMTU4MjlaMCMGCSqGSIb3DQEJBDEWBBSmXw7UIaIdCv6Gx5/UxbmrHynS ATCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwmYBjCB pwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCZgGMA0G CSqGSIb3DQEBAQUABIIBALHte+8Zp1ahzDsfxZeIuiTcaG6oxhtv1KPWBBg07On3FNRc7j1xlKJu KqdscmMuH7LcQz0SL5PpxxqatOxZQN+MT3NHVOcWKjBE5On4EIEre/GrvJ/h1VUpXabX2de6LgxB cMpkRyPnyiJtfRj5UwhYV4BpkRTNlIPICTwniw7o9V0DI9qs4cCcgWLL4StQXLd8QBkH7MOLUiK7 hJ4Y3i1d3rpb+1Ji9fEAiP0PP97EPIyrVho+B/Rzy2w6dELiqV4POnSQAiQSJCiZtyPpLvcMYQWO /NbNLBVVSuj5s4VXf34NdCjhCQMPb/ejMZZ9J4nOBLtdvdIGtkDMRj/AODAAAAAAAAA= --Apple-Mail=_0A33D01D-7989-40AB-A0F7-3D590AA98FFD-- From nobody Sat Oct 18 17:50:17 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107821A0461 for ; Sat, 18 Oct 2014 17:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 O9c22Nlwlg4F for ; Sat, 18 Oct 2014 17:50:14 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id CABEA1A01E7 for ; Sat, 18 Oct 2014 17:50:14 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PDWGX4383K001QFD@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 18 Oct 2014 17:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1413679514; bh=WRXyoubA3UoKv57bdsbLQNYtJjcCnS8GIrw+fzejBvI=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=aDGwB55uhp/1g2tMxYo5wkgjivMbZ3VqGwNXRebZdGS1u838IYjBn7QPP8QzNgUon DLducntkwnVj9vafVAcO/q3TXT9GWawBvJ9VtNzo9JndV1IvCg0EKPcZJdBWSKnrkR xQz9oAa1xcdrblAFnOvbtMvhxxmzBR2kt79iA51E= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PDU0RJGGDS00005L@mauve.mrochek.com>; Sat, 18 Oct 2014 17:45:09 -0700 (PDT) Message-id: <01PDWGX2LM9K00005L@mauve.mrochek.com> Date: Sat, 18 Oct 2014 17:10:35 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 17 Oct 2014 20:46:59 -0400" <150B87D9-F747-4B89-87C0-F1F15A337476@michelf.ca> References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <150B87D9-F747-4B89-87C0-F1F15A337476@michelf.ca> To: Michel Fortin Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/sUGdGqMF2gvXobOFasW-AT_ctds Cc: IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 00:50:16 -0000 > Last draft, I wrote those two comments on the list: > > Hence, I think the requirement that parser implementers register anything > > is deeply flawed. I see no requirement that anything be registered. The syntax parameter where registered identifiers appear is optional. Additionally, I don't see a requirement that the identifier you put in there MUST be registered. > > If there is a registry to be maintained, it should be > > maintained by the subset of users who care about having a things registered in > > a central place, which for the most part does not include implementers of > > Markdown parsers. As opposed to using a neutral service that has been maintaining many comparable registries for decades? This makes no sense to me at all. > That comment still stands. Having a registry won't help you if no one bothers > registering anything. And I don't see why I'd bother. I'm sure it'll be the > same for other implementers (Fletcher seems to be of the same opinion already). > Who do you plan is going to maintain that registry exactly? It's an IANA registry so IANA maintains it. Along with hundreds of others, including the media types registry. You're worrying about issues that simply don't exist. Which doesn't mean the registry necessarily makes sense, but operational issues of this sort are not a factor. > > I'd question whether it is a good idea to say anything about the output. > > Has the desired output format anything to do with the type of the Markdown > > content? > I stHill think the "output type" shouldn't be part of the document type. It's > weird. I think there's a fairly close parallel to be found in application/octet-stream name parameter that was originally part of MIME. The name parameter was used to specify a filename to associate with the object in the event one was needed. But such a name isn't an attribute of the object itself, rather, it's part of the context surrounding a particular use of that object. As such, it was replaced by the filename parameter that's part of the content-disposition field. (Note that this made filename labels available to any type.) This seems to me to be very similar situation to output-type. The output-type isn't a property of the markdown object, it's a property of the message or whatever context that contains the object. And similarly, if there's a case for providing this information, it seems to me that it makes sense for it to be a content-disposition parameter. Ned From nobody Sat Oct 18 18:01:55 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86DB71A1B6A for ; Sat, 18 Oct 2014 18:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 7Nc02cKPRgiw for ; Sat, 18 Oct 2014 18:01:50 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id F0ED61A00E0 for ; Sat, 18 Oct 2014 18:01:49 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PDWHBHEH68001S19@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 18 Oct 2014 17:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1413680210; bh=7xSwDcMlMDCxRp3uCoY4SEzuI74g65PJghIsDK83VVs=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=q6VrbXJbtqY7kFcsbr75vCJwsu6VsvY4nxAsvFnzX6KQHSh3a+6UmoKOZBtKMwRbp vCUD++Lvf+mS37UaTvaxQ08mPfxaZHJJBZItLbLRWjvOr0FaUkw2EhBPmaSpbiZbdY dntRy6kd3qcWbHDTDDUxP/kSp7/DyK55fNjsA5O4= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PDU0RJGGDS00005L@mauve.mrochek.com>; Sat, 18 Oct 2014 17:56:45 -0700 (PDT) Message-id: <01PDWHBG1ZY200005L@mauve.mrochek.com> Date: Sat, 18 Oct 2014 17:47:35 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 17 Oct 2014 21:28:40 -0700" References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> To: "Murray S. Kucherawy" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Z4CaxYz7912CWZYHoo3gBzVRjKU Cc: IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 01:01:52 -0000 "Murray S. Kucherawy" wrote: > I remain skeptical about the "output-type" parameter. It seems to me the > consumer of the media type knows what output form it will need to produce; > this isn't context the generator can really impose. I guess that means I > either didn't understand or don't agree with your previous response on this > point. I understand that, for example, you don't envision email readers or > browsers as consumers of this media type, but what happens if such a thing > does land in one's inbox or on a web page? Should browsers and MUAs ignore > them, return errors, what? As I indicated in my previous message, I agree that output-type doesn't make sense as a content-type parameter. But that doesn't mean providing the information makes no sense. While it is true that the consumer has to have the final say, I can easily imagine scenarios where conversion to a particular type provides a better result, and it would be helpful to be able to provide that information. But the place for that is content-disposition, not content-type. Ned From nobody Sun Oct 19 09:06:16 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D201A1BB9 for ; Sun, 19 Oct 2014 09:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDJYR_q3u68j for ; Sun, 19 Oct 2014 09:06:11 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63DAC1A1BB5 for ; Sun, 19 Oct 2014 09:06:11 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DD014509B6; Sun, 19 Oct 2014 12:06:07 -0400 (EDT) Message-ID: <5443E124.8050903@seantek.com> Date: Sun, 19 Oct 2014 09:04:52 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org References: <46A1DF3F04371240B504290A071B4DB63E74D7B8@SZXEMA510-MBX.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63E74D7B8@SZXEMA510-MBX.china.huawei.com> Content-Type: multipart/alternative; boundary="------------000309090209090202060502" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/RkYtqEARwLiGINRpRV8B8MqvxzU Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Upload of CDDL draft v03: draft-greevenbosch-appsawg-cbor-cddl-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 16:06:15 -0000 This is a multi-part message in MIME format. --------------000309090209090202060502 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Bert and Christoph (et. al.), Nit: In the International map (Section 6.2, Pages 17-19), "CN" is incorrect. CN is the geographic code for China. zh is the language code (subtag) for Chinese. It is a macrolanguage tag. There are actually two different writings for Apple: =E8=8B=B9=E6=9E=9C =E8=98=8B=E6=9E=9C The former (which is the encoded item in Section 6.2) is simplified=20 Chinese, "zh-Hans". The latter is traditional Chinese, "zh-Hant". The Wikipedia article on Chinese Wikipedia=20 =20 illustrates some of the practical problems with unifying Chinese under=20 certain language tags. It probably was not your intent to wade into linguistic=20 techno-geo-political issues...perhaps for the draft, it would be best to = pick another language, like Korean. Cheers, Sean On 9/15/2014 11:26 PM, Bert Greevenbosch wrote: > > Hello all, > > We have updated the CBOR Data Description Language (CDDL) draft. It is = > available under the following link: > > https://datatracker.ietf.org/doc/draft-greevenbosch-appsawg-cbor-cddl > > The changes since v02 are as follows: > > =C2=B7Added information about characters used in names > > =C2=B7Added text about an overall data structure and the order of the=20 > definitions of the fields > > =C2=B7Added text about encoding of keys > > =C2=B7Added table with keywords > > =C2=B7Added strings and integer writing conventions > > =C2=B7Added an ABNF description of CDDL > > Christoph Vigano is now co-author. He made several=20 > changes/simplifications based on his implementation experience. > > We look forward to your questions and remarks! > > Best regards, > > Bert > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --------------000309090209090202060502 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Bert and Christoph (et. al.),

Nit:
In the International map (Section 6.2, Pages 17-19), "CN" is incorrect.

CN is the geographic code for China.

zh is the language code (subtag) for Chinese. It is a macrolanguage tag.

There are actually two different writings for Apple:
苹果
蘋果

The former (which is the encoded item in Section 6.2) is simplified Chinese, "zh-Hans". The latter is traditional Chinese, "zh-Hant".

The Wikipedia article on Chinese Wikipedia illustrates some of the practical problems with unifying Chinese under certain language tags.

It probably was not your intent to wade into linguistic techno-geo-political issues...perhaps for the draft, it would be best to pick another language, like Korean.

Cheers,

Sean

On 9/15/2014 11:26 PM, Bert Greevenbosch wrote:

Hello all,

 

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

 

https://datatracker.ietf.org/doc/draft-greevenbosch-appsawg-cbor-cddl

 

The changes since v02 are as follows:

 

·         Added information about characters used in names

·         Added text about an overall data structure and the order of the definitions of the fields

·         Added text about encoding of keys

·         Added table with keywords

·         Added strings and integer writing conventions

·         Added an ABNF description of CDDL

 

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

 

We look forward to your questions and remarks!

 

Best regards,

Bert

 



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

--------------000309090209090202060502-- From nobody Sun Oct 19 23:27:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BB81A1B5D for ; Fri, 17 Oct 2014 13:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMCSqJecRvIY for ; Fri, 17 Oct 2014 13:39:20 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (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 D86A51A1BFF for ; Fri, 17 Oct 2014 13:39:19 -0700 (PDT) Received: from [192.168.118.123] (p5086CE87.dip0.t-ipconnect.de [80.134.206.135]) by mrelayeu.kundenserver.de (node=mreue007) with ESMTP (Nemesis) id 0Mccy4-1XNYtC1HfM-00Hf9a; Fri, 17 Oct 2014 22:38:54 +0200 Content-Type: multipart/signed; boundary="Apple-Mail=_06733E65-BE60-4C8E-B4A6-08E5030E9432"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Libbrecht In-Reply-To: <17250A28-F165-4F31-B65F-9E78CC73D74E@seantek.com> Date: Fri, 17 Oct 2014 22:38:51 +0200 Message-Id: <2EEB08DD-9ADB-422F-8ABE-0AB2C152A547@hoplahup.net> References: <17250A28-F165-4F31-B65F-9E78CC73D74E@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.1510) X-Provags-ID: V02:K0:2UiDLTnld0dtw2Jf8cuwaUkSKUcSFKU90q/s7OHEHp8 RqbTDUDpQY5kzyOIOP975qA1l24zUt5VS6+4SAsyEvTFYCM5V5 4k4mwwo0cbtfizLt/W+HSII4nnUiISKis6BKQScSjDiy22uFjN JM9IWiZNOBgfmNN3+6aIO82Qvpx+O9EtHVgstCDYfRprjrrFvu yirbacRVTAf08tmIRIyqNHILukWWd/LlCzsRHqNlb5GotqvuDN ThtWwNLm29sPR06RIVySy1frugTUnqjcUIOejFLE/VLLG/SOjx fmEp4m46REcYOaRPIeDKZRQrBV7Xh9u1RFEVYqQfHCAk7agiKb g02//Z+4wBwm4P7soNwqiTAtpN8t63zUqe3LNNUjMfyU+itkM1 lfN0zi8R9QEng== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XrA0yTjmeNrMgfo-rtjnVW1kTI4 X-Mailman-Approved-At: Sun, 19 Oct 2014 23:26:57 -0700 Cc: media-types@iana.org, IETF Apps Discuss Subject: Re: [apps-discuss] [media-types] image/wmf and image/emf: New Version Notification for draft-seantek-image-wmf-emf-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 20:39:21 -0000 --Apple-Mail=_06733E65-BE60-4C8E-B4A6-08E5030E9432 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sean, I believe the etiquette of this lists asks you that you copy the content = of the media-type registration into here. I see in the links you provided that the wmf and emf registration = indicate an amount of question marks as Macintosh file types and Uniform = types=85 it seems unfinished or is that a question? (as of today, many agree that Macintosh file types are not useful = anymore, so that can probably be ignored, but not UTIs!) Also I see that you attempted to include Macintosh UTIs for all formats, = that is a good and desirable thing. Any reason you do not also mention (just besides that , I would say) the = Windows clipboard names for each of these formats? I am pretty sure = something can be found in some MicroSoft documentation about it. thanks paul On 17 oct. 2014, at 20:08, Sean Leonard wrote: > Colleagues: >=20 > An Internet-Draft to register image/wmf and image/emf has been posted. >=20 > Thanks to Alexey Melnikov and Dave Thaler, who provided advice on = these drafts prior to submission. >=20 > Feedback welcome. >=20 > Regards, >=20 > Sean >=20 > ******************* > A new version of I-D, draft-seantek-image-wmf-emf-00.txt > has been successfully submitted by Sean Leonard and posted to the > IETF repository. >=20 > Name: draft-seantek-image-wmf-emf > Revision: 00 > Title: The Windows Metafile and Enhanced Metafile Media = Types > Document date: 2014-10-17 > Group: Individual Submission > Pages: 8 > URL: = http://www.ietf.org/internet-drafts/draft-seantek-image-wmf-emf-00.txt > Status: = https://datatracker.ietf.org/doc/draft-seantek-image-wmf-emf/ > Htmlized: = http://tools.ietf.org/html/draft-seantek-image-wmf-emf-00 >=20 >=20 > Abstract: > This document registers the image/wmf and image/emf media types for > use with Windows Metafile and Enhanced Metafile formats. Originally > designed for Microsoft Windows 3.0, these image files are intended to > be portable between applications and devices, and may contain both > vector and raster graphics. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat_______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types --Apple-Mail=_06733E65-BE60-4C8E-B4A6-08E5030E9432 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMeDCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPDCCBSSg AwIBAgIDCDgBMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMxMTI1MDYxNzMzWhcNMTQxMTI2MTIwOTM4WjBZMRkwFwYDVQQNExBIMXZ3QWhnOEt5M1MycFB3 MRowGAYDVQQDDBFwYXVsQGhvcGxhaHVwLm5ldDEgMB4GCSqGSIb3DQEJARYRcGF1bEBob3BsYWh1 cC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC05AtxCGIaVT2rrWNnzQrgq0Mo MC19wHCyTPNbijOV9MYkU0GBs7zLUHqrTuzwaiJ8O5Z+f9NuBCgOInm8CDynoWTAyEVzGg/IZp4s CelD2I3EK1C0LLAziddkv0PtL2akuEO0qr1ROdvgfxu8jQvTt/AzMRI3X/iElvTyKVjtplWUdBpY yn9VO0nrU1QuRmheTUoK4FkjSJCdyIxgBjvoAl2RsfCcZ0Xe3Mf6d/IVAXGdotY77fTQCFBGBNQa wxUdaLwsGBfMLLM+5/soqTyc1s4Odb5k/7BCZR52MGM8u9ybQgrZFPzttJsSEjXLj4tCHdjReVC4 xdxgsr1fxd0FAgMBAAGjggLXMIIC0zAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAU BggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFKDfcmnF2BXH71XDROeCuaJPA13qMB8GA1Ud IwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMBwGA1UdEQQVMBOBEXBhdWxAaG9wbGFodXAubmV0 MIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1 ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRo ZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJw b3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1Ud HwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsG AQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xh c3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMv c3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wu Y29tLzANBgkqhkiG9w0BAQUFAAOCAQEAxuXe/1LjZYdRbmN57ycax9LQ9xvVa2udsOvhQSRl0EDK VObXHbv39X66gFiBFdeMi1P3eYVC5eDoU4tCc3LQD8tBkqC7q6VCjelnCbwU+dn4lmCjwRs2219i XTA4jrAIC1xjfVLgg+mVfEyV3rXSXqfHGICem+CgwVxAVCQeZemrPxrlbaKiTEKswPPbfq5oIYtt RvRAbfz3hVfHyC+UdkROvd8TXevhoawJa+EFUFeN6wSGFKJAlxx5Sv82oEJ8fLFvjZe+55bXrIHT k/WKHUK3AkJmX1T59KqJTgSIp7tA1cYR4UskWte5yIJwi4yhbqLmNS2xgYqYrL4FJHVmGjGCA28w ggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwg4ATAJBgUrDgMCGgUAoIIB rzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEwMTcyMDM4NTNa MCMGCSqGSIb3DQEJBDEWBBTBBeQ0sF+/dGOH2OdicrqAh9602DCBpQYJKwYBBAGCNxAEMYGXMIGU MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJl IERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQ cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwg4ATCBpwYLKoZIhvcNAQkQAgsxgZeggZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCDgBMA0GCSqGSIb3DQEBAQUABIIBABVwtIYA H8NcXMIWUI8GdpMJDGmXrXZyVMCqRKU8NzqNOMZL3FzZwl1VekBnVsY7W3/xq9XBrEqU8gZ1zkoH 5a+pwvWxyaKVleRa0DrQilxTFF6vhHE1bohqjjxwYOdl/7+lDL8vFspLwC8ahsgi6Dt0AW4fFLF8 tklpR6+BkQ9YHy3fzYQuNpBNvm7tGXtEP+Gj2hdMcCWIJoS/se+j8+kW4jxABZu6KkQ8mVukZ3Km GeuspYSu1rl21HI1MS5FapF8LjS0yYV14kXQZ9X8UoEuAGAvZMCFQna4Pe1xjSWp9rB2BrfUqusl 1MGOKiyOsjJZjH5MG7qnS8XoYjoFhSIAAAAAAAA= --Apple-Mail=_06733E65-BE60-4C8E-B4A6-08E5030E9432-- From nobody Sun Oct 19 23:33:33 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566431A6FAE for ; Sun, 19 Oct 2014 23:33: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 ImOgclrxtkKg for ; Sun, 19 Oct 2014 23:33:28 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F6111A1BE3 for ; Sun, 19 Oct 2014 23:33:28 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id q1so3257108lam.8 for ; Sun, 19 Oct 2014 23:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E5dCiDmUrsRuasYa6NwP9kJ9qoYfYziqrLxuwyicOdc=; b=qL3BMAAoc/UOJNE89fY9hRxfdK5TEf4Zt8k5enDCQDq5kSzYOyQoOl1etMIqYz4naB ejIvT2Hz4K0439gMLMmhWI4kvDIUKk0W+3XjirhqA6/0anwagTrAVs15RQyCg8bz9fCv AW63aNK5/BtUYQG0rl3qir3h5NuUY5AqBXfUsCK8dWN2tex6j/QIK/ypuo5yvnsdEQ9/ U0UkPEtEpxLex0NYEgjb/mT1G+Wq7tBUtKCFm46tObmB0KCuULj9k5keRoDHUbcYizjf XKn723kbyk1tvkKqX7c/P0m1dmlf++Pa6JKRtnA3AdBTQw4BuzvKs8Larr/5UcdafYgl zCLA== MIME-Version: 1.0 X-Received: by 10.112.147.225 with SMTP id tn1mr25220958lbb.37.1413786806912; Sun, 19 Oct 2014 23:33:26 -0700 (PDT) Received: by 10.25.211.11 with HTTP; Sun, 19 Oct 2014 23:33:26 -0700 (PDT) In-Reply-To: <2EEB08DD-9ADB-422F-8ABE-0AB2C152A547@hoplahup.net> References: <17250A28-F165-4F31-B65F-9E78CC73D74E@seantek.com> <2EEB08DD-9ADB-422F-8ABE-0AB2C152A547@hoplahup.net> Date: Sun, 19 Oct 2014 23:33:26 -0700 Message-ID: From: "Murray S. Kucherawy" To: Paul Libbrecht Content-Type: multipart/alternative; boundary=047d7b3a8cf46a0a750505d4e4b5 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/S_TUKjaGE7-7k_1dhKVeG5UPfH8 Cc: IETF Apps Discuss , "media-types@iana.org" Subject: Re: [apps-discuss] [media-types] image/wmf and image/emf: New Version Notification for draft-seantek-image-wmf-emf-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: Mon, 20 Oct 2014 06:33:30 -0000 --047d7b3a8cf46a0a750505d4e4b5 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 17, 2014 at 1:38 PM, Paul Libbrecht wrote: > > I believe the etiquette of this lists asks you that you copy the content > of the media-type registration into here. > > Is that really necessary given it's (presumably) in the referenced document? It's certainly true that media type registrations have been happening since long before I was on this list, but it seems an odd thing to me. -MSK --047d7b3a8cf46a0a750505d4e4b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 17, 2014 at 1:38 PM, Paul Libbrecht <paul@ho= plahup.net> wrote:

I believe the etiquette of this lists asks you that you copy the content of= the media-type registration into here.


Is that really necessary given it'= s (presumably) in the referenced document?

It's certa= inly true that media type registrations have been happening since long befo= re I was on this list, but it seems an odd thing to me.

-= MSK
--047d7b3a8cf46a0a750505d4e4b5-- From nobody Sun Oct 19 23:40:59 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CF11A1BEC for ; Sun, 19 Oct 2014 23:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JCHJQ-7JVSEK for ; Sun, 19 Oct 2014 23:40:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11DCC1A1BE1 for ; Sun, 19 Oct 2014 23:40:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKS47609; Mon, 20 Oct 2014 06:40:54 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 20 Oct 2014 07:40:54 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 20 Oct 2014 14:40:50 +0800 From: "Huangyihong (Rachel)" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] FW: New Version Notification for draft-huang-appsawg-aipi-ps-uc-00.txt Thread-Index: AQHP7DDJ+xvk3BVpVk+9YcwaYF1IEw== Date: Mon, 20 Oct 2014 06:40:49 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB862482AF@nkgeml501-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.144] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8L5bjOHybAVRdzW-8gB10wttoG8 Subject: [apps-discuss] FW: New Version Notification for draft-huang-appsawg-aipi-ps-uc-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: Mon, 20 Oct 2014 06:40:57 -0000 RGVhciBhbGwsDQoNCk15IGNvbGxlYWd1ZSBhbmQgSSBzdWJtaXR0ZWQgYSBkcmFmdCB0byBkaXNj dXNzIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBhbmQgdXNlIGNhc2VzIG9mIGFwcGxpY2F0aW9uLW9y aWVudGVkIGludGVyZmFjZSB3aGljaCBmYWNpbGl0YXRlcyB0aGUgdHJhbnNsYXRpb25zIGZyb20g dGhlIHJlYWwgYXBwbGljYXRpb24gcmVxdWlyZW1lbnRzIGludG8gbmV0d29yayBsZXZlbCByZXF1 aXJlbWVudHMuDQoNCllvdXIgZmVlZGJhY2tzIGFyZSBoaWdobHkgYXBwcmVjaWF0ZWQuIEFuZCB3 ZSBhbHNvIHdvdWxkIGxpa2UgdG8gcHJlc2VudCBpdCBpbiB0aGUgY29taW5nIElFVEYgbWVldGlu ZywgaWYgdGltZSBwZXJtaXRzLg0KDQpCUiwNClJhY2hlbA0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTQsIDIwMTQgMzoyOSBQ TQ0KVG86IFNvbmdoYWliaW47IEh1YW5neWlob25nIChSYWNoZWwpOyBTb25naGFpYmluOyBIdWFu Z3lpaG9uZyAoUmFjaGVsKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1odWFuZy1hcHBzYXdnLWFpcGktcHMtdWMtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWh1YW5nLWFwcHNhd2ctYWlwaS1wcy11Yy0wMC50eHQNCmhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUmFjaGVsIEh1YW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWh1YW5nLWFwcHNhd2ctYWlwaS1wcy11Yw0K UmV2aXNpb246CTAwDQpUaXRsZToJCVByb2JsZW0gU3RhdGVtZW50IGFuZCBVc2UgQ2FzZXMgZm9y IEFwcGxpY2F0aW9uIEludGVsbGlnZW50IFBvbGljeSBJbnRlcmZhY2UgKEFJUEkpDQpEb2N1bWVu dCBkYXRlOgkyMDE0LTEwLTEzDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6 CQk4DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtaHVhbmctYXBwc2F3Zy1haXBpLXBzLXVjLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1YW5nLWFwcHNhd2ctYWlwaS1w cy11Yy8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1o dWFuZy1hcHBzYXdnLWFpcGktcHMtdWMtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1l bnQgZGlzY3Vzc2VzIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBhbmQgdXNlIGNhc2VzIG9mIGFuDQog ICBpbnRlcmZhY2UgbmFtZWQgQXBwbGljYXRpb24gSW50ZWxsaWdlbnQgUG9saWN5IEludGVyZmFj ZSAoQUlQSSkgdGhhdA0KICAgdHJhbnNsYXRlcyB0aGUgcmVhbCBhcHBsaWNhdGlvbiByZXF1aXJl bWVudHMgKGUuZy4sIG5ldHdvcmsgc2hvdWxkDQogICBlbnN1cmUgaG93IG1hbnkgdXNlcnMgb2Yg dGhlIE9UVCBwcm92aWRlciB3YXRjaCBoaWdoIGRlZmluaXRpb24gdmlkZW8NCiAgIHNpbXVsdGFu ZW91c2x5LikgaW50byBuZXR3b3JrIGxldmVsIHJlcXVpcmVtZW50cywgZS5nLiwNCiAgIGNvbmZp Z3VyYXRpb25zIG9yIHNlcnZpY2UgZGVwbG95bWVudHMgcmVxdWlyZW1lbnRzIGFuZCBuZXR3b3Jr IFFvUw0KICAgcmVxdWlyZW1lbnRzLCBhcmUgdXNlZnVsIGFuZCBuZWNlc3NhcnkgZm9yIG1vZGVy biBuZXR3b3Jrcy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Sun Oct 19 23:41:32 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C3F1A6FC1 for ; Sun, 19 Oct 2014 23:41:31 -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 AjsC3hRnjCdS for ; Sun, 19 Oct 2014 23:41:29 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB2C1A6FC0 for ; Sun, 19 Oct 2014 23:41:28 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id l4so3280263lbv.24 for ; Sun, 19 Oct 2014 23:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a6aFZNbY0xhfrUOF53TFrX/EqFWCgmhR6v1LkoRNBVI=; b=bsPh/5UXsnvp3W15qzqZJdOjHcxDRIlFfpk1cOjzPD1ftLDx11c7ZAjzf9b/YrtSp8 dphL98sc/UNePCBzz0Q7ms/NWym6rq/04GPGSXK3ya1ShT4Xybu1jG+2NITxAa4wSAjb Rf5CuDpwZ31Nm1DsCrYIE4gwTYkfxs2DiqOUa5J2uv/3sjzn1OX5oAKMIoQofvC1sqsx PBcFAwj5Baq6tGbEjsHkvGJYNgomDmr46V0VVBYGQQov+d1sTRIfuFxdGNqq/RIyhqGP 5Q6kMpd3Mt8ksR+fqLtHtNTqz9l4Y9psioWKYSMYqZZlGV+usk1qREuyj3vQOSTQQf5O 1fAw== MIME-Version: 1.0 X-Received: by 10.112.137.202 with SMTP id qk10mr25215055lbb.0.1413787287263; Sun, 19 Oct 2014 23:41:27 -0700 (PDT) Received: by 10.25.211.11 with HTTP; Sun, 19 Oct 2014 23:41:27 -0700 (PDT) In-Reply-To: <01PDWHBG1ZY200005L@mauve.mrochek.com> References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <01PDWHBG1ZY200005L@mauve.mrochek.com> Date: Sun, 19 Oct 2014 23:41:27 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=089e01227eb20b9df50505d50146 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/AcB-mdytx0Sy4Wokus2GpBizYOk Cc: IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 06:41:31 -0000 --089e01227eb20b9df50505d50146 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 18, 2014 at 5:47 PM, Ned Freed wrote: > > As I indicated in my previous message, I agree that output-type doesn't > make > sense as a content-type parameter. > > But that doesn't mean providing the information makes no sense. While it is > true that the consumer has to have the final say, I can easily imagine > scenarios where conversion to a particular type provides a better result, > and it would be helpful to be able to provide that information. > > But the place for that is content-disposition, not content-type. > I think I'd be fine with meta-data like this being presented in a way that's clearly no more than a recommendation. As written, "output-type" in this draft sounds like something the consumer is basically required to do; it reads normatively in -03, though it doesn't use RFC2119 language. -MSK --089e01227eb20b9df50505d50146 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Oct 18, 2014 at 5:47 PM, Ned Freed <ned.freed= @mrochek.com> wrote:

As I indicated in my previous message, I agree that output-type does= n't make
sense as a content-type parameter.

But that doesn't mean providing the information makes no sense. While i= t is
true that the consumer has to have the final say, I can easily imagine
scenarios where conversion to a particular type provides a better result, and it would be helpful to be able to provide that information.

But the place for that is content-disposition, not content-type.

I think I= 9;d be fine with meta-data like this being presented in a way that's cl= early no more than a recommendation.=C2=A0 As written, "output-type&qu= ot; in this draft sounds like something the consumer is basically required = to do; it reads normatively in -03, though it doesn't use RFC2119 langu= age.

-MSK
--089e01227eb20b9df50505d50146-- From nobody Sun Oct 19 23:48:16 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E981A6FB3 for ; Sun, 19 Oct 2014 23:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txHmwLBM2_F9 for ; Sun, 19 Oct 2014 23:48:12 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8469E1A6FC2 for ; Sun, 19 Oct 2014 23:48:11 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id gq15so3293749lab.40 for ; Sun, 19 Oct 2014 23:48:09 -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=h7zowpPFzXe5GzbrO/429XYqiUZJrSfmHXtSLA2DNUE=; b=YzCVUG0l7hE+3ZPn5f00m7+xd7UKCpS5ooqQWY2BHWruYd7nRphHuHRpM4bPikDCRi XMoDp5kxbXw9piq3utnAlIuadAu5YihTKs7SI3YLWiPZDJZf7AEHDoukFfs96Q0z8AAQ OZ1gmS95wLsh57M9NO3HtYeT+M3LaPRS7ZaXqhT/k5lfMnQ/14PVsH9H/yZccj/79Paf 6kCDEYkCpPJoQo83wl1jOmUplw/hX5tqK8R0QierkCc5o7a/3DPTJsRAav9QAcZCP18k F5V/jybMT5rnsS59CSqTOCfnshDjqc54CMdH7Tc9neDKkXQMxrZsahm3U2DoYNwGEdwX aipw== MIME-Version: 1.0 X-Received: by 10.112.150.68 with SMTP id ug4mr6922278lbb.82.1413787689881; Sun, 19 Oct 2014 23:48:09 -0700 (PDT) Received: by 10.25.211.11 with HTTP; Sun, 19 Oct 2014 23:48:09 -0700 (PDT) In-Reply-To: <01PDWGX2LM9K00005L@mauve.mrochek.com> References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <150B87D9-F747-4B89-87C0-F1F15A337476@michelf.ca> <01PDWGX2LM9K00005L@mauve.mrochek.com> Date: Sun, 19 Oct 2014 23:48:09 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=047d7b342d480b17590505d519d3 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/sLn13GK90jn6K__9NsmHsWq14Mk Cc: IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 06:48:14 -0000 --047d7b342d480b17590505d519d3 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 18, 2014 at 5:10 PM, Ned Freed wrote: > > Last draft, I wrote those two comments on the list: > > > > Hence, I think the requirement that parser implementers register > anything > > > is deeply flawed. > > I see no requirement that anything be registered. The syntax parameter > where > registered identifiers appear is optional. Additionally, I don't see a > requirement that the identifier you put in there MUST be registered. > I think this might have been a reference to the "processor" argument, which was present in -02 but was removed in -03. Moot now. > That comment still stands. Having a registry won't help you if no one > bothers > > registering anything. And I don't see why I'd bother. I'm sure it'll be > the > > same for other implementers (Fletcher seems to be of the same opinion > already). > > Who do you plan is going to maintain that registry exactly? > > It's an IANA registry so IANA maintains it. Along with hundreds of others, > including the media types registry. > > You're worrying about issues that simply don't exist. Which doesn't mean > the > registry necessarily makes sense, but operational issues of this sort are > not a > factor. > I'm not so sure. The work we're doing on draft-ietf-appsawg-uri-scheme-reg was undertaken specifically because lots of people were inventing, and putting into use, but not registering with IANA, URI schemes. I think the concern is the same here: If it's a pain to register, or the benefit is virtually non-existent, people won't bother. To me, that either means the definition or purpose of the registry is broken, or the bar for registrations is too high. It's not a matter of the load on or capabilities of IANA; these are problems on our side of that fence. > > I'd question whether it is a good idea to say anything about the output. > > > Has the desired output format anything to do with the type of the > Markdown > > > content? > > > I stHill think the "output type" shouldn't be part of the document type. > It's > > weird. > > I think there's a fairly close parallel to be found in > application/octet-stream > name parameter that was originally part of MIME. > > The name parameter was used to specify a filename to associate with the > object > in the event one was needed. But such a name isn't an attribute of the > object > itself, rather, it's part of the context surrounding a particular use of > that > object. > > [...] > I commented on this in reply to Ned's other post. And I agree that re-using or extending Content-Disposition is a good thing for this work to consider. -MSK --047d7b342d480b17590505d519d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Oct 18, 2014 at 5:10 PM, Ned Freed <ned.freed= @mrochek.com> wrote:
> Last = draft, I wrote those two comments on the list:

> > Hence, I think the requirement that parser implementers register = anything
> > is deeply flawed.

I see no requirement that anything be registered. The syntax paramet= er where
registered identifiers appear is optional. Additionally, I don't see a<= br> requirement that the identifier you put in there MUST be registered.

I think this might have been a reference to t= he "processor" argument, which was present in -02 but was removed= in -03.=C2=A0 Moot now.

> That comment still stands. Having a registry won'= t help you if no one bothers
> registering anything. And I don't see why I'd bother. I'm = sure it'll be the
> same for other implementers (Fletcher seems to be of the same opinion = already).
> Who do you plan is going to maintain that registry exactly?

It's an IANA registry so IANA maintains it. Along with hundreds = of others,
including the media types registry.

You're worrying about issues that simply don't exist. Which doesn&#= 39;t mean the
registry necessarily makes sense, but operational issues of this sort are n= ot a
factor.

I'm not so sure.=C2=A0 The = work we're doing on draft-ietf-appsawg-uri-scheme-reg was undertaken sp= ecifically because lots of people were inventing, and putting into use, but= not registering with IANA, URI schemes.=C2=A0 I think the concern is the s= ame here: If it's a pain to register, or the benefit is virtually non-e= xistent, people won't bother.=C2=A0 To me, that either means the defini= tion or purpose of the registry is broken, or the bar for registrations is = too high.=C2=A0 It's not a matter of the load on or capabilities of IAN= A; these are problems on our side of that fence.

> > I'd question whether it is a good idea to sa= y anything about the output.
> > Has the desired output format anything to do with the type of the= Markdown
> > content?

> I stHill think the "output type" shouldn't be par= t of the document type. It's
> weird.

I think there's a fairly close parallel to be found in application/octe= t-stream
name parameter that was originally part of MIME.

The name parameter was used to specify a filename to associate with the obj= ect
in the event one was needed. But such a name isn't an attribute of the = object
itself, rather, it's part of the context surrounding a particular use o= f that
object.

[...]

I commented on thi= s in reply to Ned's other post.=C2=A0 And I agree that re-using or exte= nding Content-Disposition is a good thing for this work to consider.
-MSK
--047d7b342d480b17590505d519d3-- From nobody Mon Oct 20 00:15:44 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EA01A6FC8; Mon, 20 Oct 2014 00:15:42 -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 vZ6H3D1o1PEw; Mon, 20 Oct 2014 00:15:40 -0700 (PDT) Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA8A1A0163; Mon, 20 Oct 2014 00:15:40 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay15.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Xg7Bq-0008Va-og; Mon, 20 Oct 2014 08:15:38 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina-wl.atuin.ninebynine.org) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Xg7Bq-0000HD-7e; Mon, 20 Oct 2014 08:15:38 +0100 Message-ID: <5444B698.4030604@ninebynine.org> Date: Mon, 20 Oct 2014 08:15:36 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sean Leonard , internet-drafts@ietf.org, apps-discuss@ietf.org References: <20141017233352.18234.3690.idtracker@ietfa.amsl.com> <5442CC08.6080106@ninebynine.org> <5442D5DF.3010107@seantek.com> In-Reply-To: <5442D5DF.3010107@seantek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Zj0BEAqlQky91QG6MNHLnnf-CbE Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-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: Mon, 20 Oct 2014 07:15:42 -0000 TL;DR: drop the section about fragment identifiers; simply say fragment identifiers are the same as for text/plain (per RFC 5147). On 18/10/2014 22:04, Sean Leonard wrote: > The broader question (which the section on fragment identifiers was supposed to > raise) is "what do fragment identifiers mean in the context of Markdown > content?" Because guess what...the media type registration is where fragment > identifiers get defined. Section 4.11 of [RFC6838]. > > At a minimum, we should not have less semantics than text/plain [RFC5147]. > Unless people think otherwise. (I would like to hear arguments why Markdown > content should not be addressable using text/plain fragments.) Absent a clear use-case for fragments in markdown, I'd suggest simply deferring to text/plain fragments. The rationale for markdown is that it is usable as a simple text file ("A Markdown-formatted document should be publishable as-is, as plain text" and "Markdown is a writing format." [not a publishing format] - http://daringfireball.net/projects/markdown/syntax). Trying to layer more logic into the markdown *source* file, IMO, rather defeats the object. > Then the question is should we have more than text/plain fragments. To [Michel > Fortin's point][o]: some Markdown-derivative syntaxes have an attribute > specification {#o} that can be applied to header fields. This is the case with > PHP Markdown Extra, and with pandoc (header_identifiers, which derives the rule > from PHP Markdown Extra). Pandoc also allows for attribute specifications to be > attached to code blocks (fenced_code_attributes extension). But all this applies to the output generated for publication, not to the markdown source. Just as markdown constrains itself to "issues that can be conveyed in plain text", I think the same philosophy should apply to markdown fragment identifiers. None of this prevents the use of features you describe, with fragments applied correspondingly to the published output. That's not part of the source media type. > Adding more fragment identifiers makes the spec more complex. But is this > complex for the sake of complexity, or complex because we are dealing with a > complex technology? Nobody is forcing header {#o} down anyone's throat. Most > Markdown syntaxes (including [MDSYNTAX]) don't have it. All the more reason to not enshrine it in the fragment syntax. > All of this goes to the broader point of whether and to what extent > "text/markdown" can be used for different implementations (implementations of > what??) to interoperate. We have a situation where there are probably over 100 > different "Markdown" syntaxes out there on the market with some kind of traction > in particular communities. Quite: "implementations of what??" As we don't currently know, we shouldn't be trying to standardize. If clear use cases emerge in time, the community can come back and update the specification (or create a new one). That's way harder to do if the review has to read around poorly conceived features in the original specification. In this, I believe that less truly is more. (I note that RFC5147 fragment syntax is compatibly extensible as a base for more comprehensive specifications if such prove to be useful in the future. So there's no pressure to second-guess future requirements here.) #g From nobody Mon Oct 20 00:17:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004A91A1BF8 for ; Mon, 20 Oct 2014 00:17:39 -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 guYVChowIpbK for ; Mon, 20 Oct 2014 00:17:37 -0700 (PDT) Received: from relay14.mail.ox.ac.uk (relay14.mail.ox.ac.uk [163.1.2.162]) by ietfa.amsl.com (Postfix) with ESMTP id 9616E1A0163 for ; Mon, 20 Oct 2014 00:17:37 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay14.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Xg7Dh-0004bf-jr; Mon, 20 Oct 2014 08:17:33 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina-wl.atuin.ninebynine.org) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Xg7Dg-0000Jd-9J; Mon, 20 Oct 2014 08:17:33 +0100 Message-ID: <5444B70C.1050901@ninebynine.org> Date: Mon, 20 Oct 2014 08:17:32 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ned Freed , Michel Fortin References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <150B87D9-F747-4B89-87C0-F1F15A337476@michelf.ca> <01PDWGX2LM9K00005L@mauve.mrochek.com> In-Reply-To: <01PDWGX2LM9K00005L@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/N6XW_4NhTlhX7uiE0Y7H0TkYBpk Cc: IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 07:17:39 -0000 On 19/10/2014 01:10, Ned Freed wrote: > This seems to me to be very similar situation to output-type. The output-type > isn't a property of the markdown object, it's a property of the message or > whatever context that contains the object. +1 #g From nobody Mon Oct 20 00:25:36 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967031A6FC9 for ; Mon, 20 Oct 2014 00:25: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 LKxUTc2YCDqb for ; Mon, 20 Oct 2014 00:25:33 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BA011A1BF8 for ; Mon, 20 Oct 2014 00:25:33 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A4AC850A85; Mon, 20 Oct 2014 03:25:31 -0400 (EDT) Message-ID: <5444B89F.7030502@seantek.com> Date: Mon, 20 Oct 2014 00:24:15 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Paul Libbrecht References: <17250A28-F165-4F31-B65F-9E78CC73D74E@seantek.com> <2EEB08DD-9ADB-422F-8ABE-0AB2C152A547@hoplahup.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/cSPcfa8BPuwffk5dr0yag9a-ap0 Cc: "media-types@iana.org" , IETF Apps Discuss Subject: Re: [apps-discuss] [media-types] image/wmf and image/emf: New Version Notification for draft-seantek-image-wmf-emf-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: Mon, 20 Oct 2014 07:25:34 -0000 On 10/19/2014 11:33 PM, Murray S. Kucherawy wrote: > On Fri, Oct 17, 2014 at 1:38 PM, Paul Libbrecht > wrote: > > > I believe the etiquette of this lists asks you that you copy the > content of the media-type registration into here. > > > Is that really necessary given it's (presumably) in the referenced=20 > document? > > It's certainly true that media type registrations have been happening=20 > since long before I was on this list, but it seems an odd thing to me. I think the list militating the etiquette is media-types@iana.org, not=20 apps-discuss@ietf.org. I cross-posted. For these types of things, should we (shouldn't we) cross-post? If it is = proposed to go in the standards tree and is not obviously covered by=20 another IETF area or working group, and is not from another standards=20 organization, it would seem that the proposal should fall into APPSAWG. Just curious, Sean From nobody Mon Oct 20 02:28:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3796D1A701D for ; Mon, 20 Oct 2014 02:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 pDJtGTnZvZhO for ; Mon, 20 Oct 2014 02:28:51 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 384781A7013 for ; Mon, 20 Oct 2014 02:28:50 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 5737532E539; Mon, 20 Oct 2014 18:28:05 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 3231_22bc_ba161c37_5406_4978_a98a_3e7947b7f8c0; Mon, 20 Oct 2014 18:28:05 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 7E938BF53D; Mon, 20 Oct 2014 18:28:04 +0900 (JST) Message-ID: <5444D5A5.8030509@it.aoyama.ac.jp> Date: Mon, 20 Oct 2014 18:28:05 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Sean Leonard , "Murray S. Kucherawy" , Paul Libbrecht References: <17250A28-F165-4F31-B65F-9E78CC73D74E@seantek.com> <2EEB08DD-9ADB-422F-8ABE-0AB2C152A547@hoplahup.net> <5444B89F.7030502@seantek.com> In-Reply-To: <5444B89F.7030502@seantek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/B0FzGr2o__BDOS16YJ13UMDJjU8 Cc: "media-types@iana.org" , IETF Apps Discuss Subject: Re: [apps-discuss] [media-types] image/wmf and image/emf: New Version Notification for draft-seantek-image-wmf-emf-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: Mon, 20 Oct 2014 09:28:53 -0000 On 2014/10/20 16:24, Sean Leonard wrote: > On 10/19/2014 11:33 PM, Murray S. Kucherawy wrote: >> On Fri, Oct 17, 2014 at 1:38 PM, Paul Libbrecht > > wrote: >> >> >> I believe the etiquette of this lists asks you that you copy the >> content of the media-type registration into here. >> >> >> Is that really necessary given it's (presumably) in the referenced >> document? >> >> It's certainly true that media type registrations have been happening >> since long before I was on this list, but it seems an odd thing to me. > > I think the list militating the etiquette is media-types@iana.org, not > apps-discuss@ietf.org. I cross-posted. If you have a look through the archives of media-types@iana.org at http://www.ietf.org/mail-archive/web/media-types/, you'll find several mails from myself strongly recommending to send the actual registration template. The reason for this is that the chance of any comments on that list is *significantly* higher if people there can just have a look at the template and respond directly, compared to when they have to go and look up a template somewhere possibly deep in a draft. You can call this etiquette, or you can call it just advice on how to get comments on your media type. This is different from other lists that usually look at whole drafts, and where pasting in the whole draft into an email isn't recommended. Regards, Martin. > For these types of things, should we (shouldn't we) cross-post? If it is > proposed to go in the standards tree and is not obviously covered by > another IETF area or working group, and is not from another standards > organization, it would seem that the proposal should fall into APPSAWG. From nobody Mon Oct 20 11:35:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195771A6FCC for ; Mon, 20 Oct 2014 00:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNIUuf7FwXMs for ; Mon, 20 Oct 2014 00:05:47 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (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 8DF041A6FCE for ; Mon, 20 Oct 2014 00:05:47 -0700 (PDT) Received: from [192.168.118.126] (p5DDEDC0D.dip0.t-ipconnect.de [93.222.220.13]) by mrelayeu.kundenserver.de (node=mreue006) with ESMTP (Nemesis) id 0MSCWE-1Xa6lH3xAg-00TEPk; Mon, 20 Oct 2014 09:05:22 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_DC8E603A-8520-473C-9C68-D884AEDD0174" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Libbrecht In-Reply-To: Date: Mon, 20 Oct 2014 09:05:26 +0200 Message-Id: <62C2DEFF-933F-4BBE-B2E5-B929284DD753@hoplahup.net> References: <17250A28-F165-4F31-B65F-9E78CC73D74E@seantek.com> <2EEB08DD-9ADB-422F-8ABE-0AB2C152A547@hoplahup.net> To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1510) X-Provags-ID: V02:K0:9ak8GaMQu1VSHAm48+APikhjByLSK38F80+KIrRlt9R kXgI+oe5RXUsuUtbQisBl0Bt1YBixLvD9ZEJWLKtlgDwuiDPKH kKY5zwGqKBfc+WvJ8lDsSJjMbdZG0acAic7g6MWlyvWFvGEe8E eOWWct7++0BK97EEJsAg+jGRjtrIzavEVjaz/kxlzitQWSFk25 jt3pcCE7Y7rVTKQfdEatMRJoQXEgpqli1R7Q7H8X9u4JvyBa3J /25dzX+y3LX03PwJJFmBIMKPoV7/SW2kzPlnmffLCZxvLHx83Z JH6nj8MX7UlRf1EVYeFx20ZZuJVTj4jBG0033+byIV78pAnGOZ NkoZz3qntjCB7YhhcKdRDSABDVEwMipYenBqwuKq8zKdnw5bIT oiODs81+P3a4g== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-MA0srNYZTC4xyL-80xjb2T-WoE X-Mailman-Approved-At: Mon, 20 Oct 2014 11:35:23 -0700 Cc: "media-types@iana.org" , IETF Apps Discuss Subject: Re: [apps-discuss] [media-types] image/wmf and image/emf: New Version Notification for draft-seantek-image-wmf-emf-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: Mon, 20 Oct 2014 07:05:49 -0000 --Apple-Mail=_DC8E603A-8520-473C-9C68-D884AEDD0174 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > I believe the etiquette of this lists asks you that you copy the = content of the media-type registration into here. >=20 > Is that really necessary given it's (presumably) in the referenced = document? I can't find the description of that requirement in = https://tools.ietf.org/html/rfc6838#section-5.1 indeed. I've seen requests for that by others on the mailing-list though. > It's certainly true that media type registrations have been happening = since long before I was on this list, but it seems an odd thing to me. Personally, I think it makes a lot of sense to keep the core of the = registration inside a shared, communication anchored, collection of = exchanges such as as mailing-lists as opposed to the publisher-specific = specification space or the IETF. paul= --Apple-Mail=_DC8E603A-8520-473C-9C68-D884AEDD0174 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I believe the etiquette of this lists asks you that you copy the = content of the media-type registration into = here.

Is that really necessary given = it's (presumably) in the referenced = document?

I = can't find the description of that requirement in https://tools.iet= f.org/html/rfc6838#section-5.1 indeed.
I've seen requests = for that by others on the mailing-list though.

It's certainly true that media type = registrations have been happening since long before I was on this list, = but it seems an odd thing to = me.

Personally, I = think it makes a lot of sense to keep the core of the registration = inside a shared, communication anchored, collection of exchanges such as = as mailing-lists as opposed to the publisher-specific specification = space or the IETF.

paul
= --Apple-Mail=_DC8E603A-8520-473C-9C68-D884AEDD0174-- From nobody Mon Oct 20 11:45:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09E71A9004; Mon, 20 Oct 2014 11:45:28 -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 kTCOQBC5q1ad; Mon, 20 Oct 2014 11:45:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7861A903C; Mon, 20 Oct 2014 11:45:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141020184526.15367.46144.idtracker@ietfa.amsl.com> Date: Mon, 20 Oct 2014 11:45:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/gtQqJXPLaqOr54uCE6e_FG_ISMo Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-uri-scheme-reg-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 18:45:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Guidelines and Registration Procedures for URI Schemes Authors : Dave Thaler Tony Hansen Ted Hardie Larry Masinter Filename : draft-ietf-appsawg-uri-scheme-reg-04.txt Pages : 18 Date : 2014-10-20 Abstract: This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-uri-scheme-reg-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 20 13:47:23 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4EE1ACE6E for ; Mon, 20 Oct 2014 13:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 LwNIZOUC7sA1; Mon, 20 Oct 2014 13:47:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB281ACE75; Mon, 20 Oct 2014 13:47:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-authres-ptypes-registry@tools.ietf.org, scott@kitterman.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141020204717.7253.98483.idtracker@ietfa.amsl.com> Date: Mon, 20 Oct 2014 13:47:17 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Hhn_z5vwuIcyI_nBahg24xPJkC4 Subject: [apps-discuss] ID Tracker State Update Notice: 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, 20 Oct 2014 20:47:22 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-authres-ptypes-registry/ From nobody Mon Oct 20 17:44:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 489C91ACE0D for ; Mon, 20 Oct 2014 17:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 fr0ivlrQZ01F for ; Mon, 20 Oct 2014 17:44:16 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 24BE91A1A62 for ; Mon, 20 Oct 2014 17:44:16 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PDZ9ADE2KG0028Y6@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 20 Oct 2014 17:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1413851953; bh=pF8LzQf/Fk791KX5s1DmAl/mmACtLdVnow8Jx2ttBu8=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=awo1YoenrGdAXetst1MgMms0n5wYz603ZOyz4ubEHJu8VdFL8T8oG6p5LmZJPylFw iFPi8cYSqPFkukvXnfWGklF94HPrHs2wYJKD3349hpaNaGE8TX4uFotry/n1tyH2Tp SAQOAIp64G/FMJJ3THhP3SSnCB/pGdVloL4oQ0Ao= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PDZ9598U800028JO@mauve.mrochek.com>; Mon, 20 Oct 2014 17:39:09 -0700 (PDT) Message-id: <01PDZ9ABS0MI0028JO@mauve.mrochek.com> Date: Mon, 20 Oct 2014 17:35:35 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 20 Oct 2014 09:05:26 +0200" <62C2DEFF-933F-4BBE-B2E5-B929284DD753@hoplahup.net> References: <17250A28-F165-4F31-B65F-9E78CC73D74E@seantek.com> <2EEB08DD-9ADB-422F-8ABE-0AB2C152A547@hoplahup.net> <62C2DEFF-933F-4BBE-B2E5-B929284DD753@hoplahup.net> To: Paul Libbrecht Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ei1n8k9WXnc62XpTOHCnQ59bIAQ Cc: "media-types@iana.org" , IETF Apps Discuss Subject: Re: [apps-discuss] [media-types] image/wmf and image/emf: New Version Notification for draft-seantek-image-wmf-emf-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, 21 Oct 2014 00:44:17 -0000 > > > I believe the etiquette of this lists asks you that you copy the content of > > > the media-type registration into here. > > Is that really necessary given it's (presumably) in the referenced > > document? Etiquette != requirement. Nobody ever said it was required; but doing it may improve your chances of people taking the time to do a review. > I can't find the description of that requirement in > https://tools.ietf.org/html/rfc6838#section-5.1 indeed. > I've seen requests for that by others on the mailing-list though. Yep. So requirement or not, it's in your best interest to do it. > > It's certainly true that media type registrations have been happening since > > long before I was on this list, but it seems an odd thing to me. Why? > Personally, I think it makes a lot of sense to keep the core of the > registration inside a shared, communication anchored, collection of exchanges > such as as mailing-lists as opposed to the publisher-specific specification > space or the IETF. Exactly right. Ned From nobody Tue Oct 21 02:13:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4271A00B2 for ; Tue, 21 Oct 2014 02:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.512 X-Spam-Level: X-Spam-Status: No, score=-100.512 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 JffpzLhMwkMe for ; Tue, 21 Oct 2014 02:13:25 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id DC37E1A017D for ; Tue, 21 Oct 2014 02:13:24 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 67E4F182149; Tue, 21 Oct 2014 02:13:05 -0700 (PDT) To: andreas@sbin.se, nilsson@opera.com, barryleiba@computer.org, presnick@qti.qualcomm.com, superuser@gmail.com, alexey.melnikov@isode.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141021091305.67E4F182149@rfc-editor.org> Date: Tue, 21 Oct 2014 02:13:05 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mjhZxlfxnOtefqR5trYnmrj1AOY Cc: craig.taylor@bbc.co.uk, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Technical Errata Reported] RFC7239 (4137) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 09:13:27 -0000 The following errata report has been submitted for RFC7239, "Forwarded HTTP Extension". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7239&eid=4137 -------------------------------------- Type: Technical Reported by: Craig Taylor Section: Parameters Original Text ------------- Corrected Text -------------- Notes ----- Firstly let me apologise for not submitting anything above, but I don't want submit possible duplicate effort without testing the water. One of the issues that we have always had with Forwarded: is highlighted perfectly by Section 8.1, I essentially can't trust it. I am happy to honour (in principle) Forwarded: set by trusted third parties where: 1) I know that they have set it 2) I know that they have clean up anything they don't trust or can't verify. Without this, I could never honour Forwarded: for Internet third parties, something that has been requested by Opera, Google etc. in the past. Were signing/validation schemes considered? Scaling concerns aside, without such things this will likely be relegated to corporate LAN use for many CSPs. Regards, CraigT 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. -------------------------------------- RFC7239 (draft-ietf-appsawg-http-forwarded-10) -------------------------------------- Title : Forwarded HTTP Extension Publication Date : June 2014 Author(s) : A. Petersson, M. Nilsson Category : PROPOSED STANDARD Source : Applications Area Working Group Area : Applications Stream : IETF Verifying Party : IESG From nobody Tue Oct 21 05:35:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC64F1A1B59 for ; Tue, 21 Oct 2014 05:35:23 -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 hUPuGcz2hluL for ; Tue, 21 Oct 2014 05:35:22 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0E71A1B23 for ; Tue, 21 Oct 2014 05:35:20 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id gi9so925972lab.5 for ; Tue, 21 Oct 2014 05:35:17 -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=W/7G0sdWqEEISNQKpj1jHaO6r8UjhmlTCaVBibIF894=; b=QaQaFwZ3A5cSjhGE0GOqZUsVDOlAWDTNsw64qXlUCs/BX8W6PFENjKA2Y9swkU+BgD PZRtOTV3MR5lU7JVIXqVpctK+KvqLi/JpktDhAGm+rHM0X9syzhIr8a0zajFIn7RlFeq l7Ol4aWKBOx0kbg0bhG5ldht/LKdtukbDBc+NOUsJkJneEwcCWCjpkYl1SLrGhJrTfKb A9iZvvOgd+gOdzzChJxXpMPXGOA3s9INKOebRJXyOKYw8U3GxsF07rrc2D7coP6Sbz1k BEFRxXboVXcHGZD6rylFS33vbMi2isECFdMHLFrh9tDYMko37ciwTYWvGa75ixVAPAFD 7Hng== MIME-Version: 1.0 X-Received: by 10.112.132.104 with SMTP id ot8mr34269883lbb.3.1413894916996; Tue, 21 Oct 2014 05:35:16 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Tue, 21 Oct 2014 05:35:16 -0700 (PDT) In-Reply-To: <20141021091305.67E4F182149@rfc-editor.org> References: <20141021091305.67E4F182149@rfc-editor.org> Date: Tue, 21 Oct 2014 08:35:16 -0400 X-Google-Sender-Auth: 9v7DAINllj-6vf1LtWUCzqICbVQ Message-ID: From: Barry Leiba To: RFC Errata System Content-Type: multipart/alternative; boundary=047d7b3a7ffe4704450505ee1096 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/fvfx7_-VtMXyyjvoEHeIHZNqMa0 Cc: "apps-discuss@ietf.org" , "nilsson@opera.com" , "presnick@qti.qualcomm.com" , "craig.taylor@bbc.co.uk" Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7239 (4137) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 12:35:24 -0000 --047d7b3a7ffe4704450505ee1096 Content-Type: text/plain; charset=ISO-8859-1 Hi, Craig, and thanks for the questions/comments. It's too bad that there isn't a clear place for having these discussions that people who aren't already "in the know" can find. The right place to ask and discuss this is the apps-discuss mailing list, < apps-discuss@ietf.org>: https://www.ietf.org/mailman/listinfo/apps-discuss Craig, please take these questions there. RFC Editor, please remove this report from the errata system. Thanks, Barry On Tuesday, October 21, 2014, RFC Errata System wrote: > The following errata report has been submitted for RFC7239, > "Forwarded HTTP Extension". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7239&eid=4137 > > -------------------------------------- > Type: Technical > Reported by: Craig Taylor > > > Section: Parameters > > Original Text > ------------- > > > Corrected Text > -------------- > > > Notes > ----- > Firstly let me apologise for not submitting anything above, but I don't > want submit possible duplicate effort without testing the water. > > One of the issues that we have always had with Forwarded: is highlighted > perfectly by Section 8.1, I essentially can't trust it. I am happy to > honour (in principle) Forwarded: set by trusted third parties where: > > 1) I know that they have set it > 2) I know that they have clean up anything they don't trust or can't > verify. > > Without this, I could never honour Forwarded: for Internet third parties, > something that has been requested by Opera, Google etc. in the past. > > Were signing/validation schemes considered? > Scaling concerns aside, without such things this will likely be relegated > to corporate LAN use for many CSPs. > > Regards, > CraigT > > 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. > > -------------------------------------- > RFC7239 (draft-ietf-appsawg-http-forwarded-10) > -------------------------------------- > Title : Forwarded HTTP Extension > Publication Date : June 2014 > Author(s) : A. Petersson, M. Nilsson > Category : PROPOSED STANDARD > Source : Applications Area Working Group > Area : Applications > Stream : IETF > Verifying Party : IESG > > --047d7b3a7ffe4704450505ee1096 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Craig, and thanks for the questions/comments.=A0 It's too bad that = there isn't a clear place for having these discussions that people who = aren't already "in the know" can find.

The= right place to ask and discuss this is the apps-discuss mailing list, <= apps-discuss@ietf.org>:=A0<= a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss">https://www.i= etf.org/mailman/listinfo/apps-discuss

Craig, p= lease take these questions there.

RFC Editor, plea= se remove this report from the errata system.

Than= ks,
Barry

On Tuesday, October 21, 2014, RFC Errata System = <rfc-editor@rfc-editor.org<= /a>> wrote:
The following errata repor= t has been submitted for RFC7239,
"Forwarded HTTP Extension".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc= =3D7239&eid=3D4137

--------------------------------------
Type: Technical
Reported by: Craig Taylor <craig.taylor@bbc.co.uk<= /a>>

Section: Parameters

Original Text
-------------


Corrected Text
--------------


Notes
-----
Firstly let me apologise for not submitting anything above, but I don't= want submit possible duplicate effort without testing the water.

One of the issues that we have always had with Forwarded: is highlighted pe= rfectly by Section 8.1, I essentially can't trust it. I am happy to hon= our (in principle) Forwarded: set by trusted third parties where:

1) I know that they have set it
2) I know that they have clean up anything they don't trust or can'= t verify.

Without this, I could never honour Forwarded: for Internet third parties, s= omething that has been requested by Opera, Google etc. in the past.

Were signing/validation schemes considered?
Scaling concerns aside, without such things this will likely be relegated t= o corporate LAN use for many CSPs.

Regards,
CraigT

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
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.

--------------------------------------
RFC7239 (draft-ietf-appsawg-http-forwarded-10)
--------------------------------------
Title=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Forwarded HTTP Extension
Publication Date=A0 =A0 : June 2014
Author(s)=A0 =A0 =A0 =A0 =A0 =A0: A. Petersson, M. Nilsson
Category=A0 =A0 =A0 =A0 =A0 =A0 : PROPOSED STANDARD
Source=A0 =A0 =A0 =A0 =A0 =A0 =A0 : Applications Area Working Group
Area=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Applications
Stream=A0 =A0 =A0 =A0 =A0 =A0 =A0 : IETF
Verifying Party=A0 =A0 =A0: IESG

--047d7b3a7ffe4704450505ee1096-- From nobody Tue Oct 21 08:02:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133721A8720 for ; Tue, 21 Oct 2014 08:02:47 -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 7EpCF0KhJ3WI for ; Tue, 21 Oct 2014 08:02:46 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99BCD1A86FB for ; Tue, 21 Oct 2014 08:02:45 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id l4so1144537lbv.24 for ; Tue, 21 Oct 2014 08:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6YJTSh7DHzxc613vI5z1BqQMXBRoDSWIJX/Y379XBmg=; b=x1ZjyggBTkukBPhp4avRPsGIl6zr7lG6qfuuzHan8l4ezd1hfzj24lZoTtu21Owa0X pfrPxJYLPCQ5BrNVMEIa+aQiL/BJ8dP6RKbQf9AjXzks2FtRBIsP/g5cMoGyqGd3IqAR I2Ucf3GU1AwkMiyCTJ330Jwx+j+TXGutcUXIH9HtBt+1CR0kBUURjLr0WBIvpAnNWuoE 3ukFP/YLnxy2jUTq0VR/2vDXg9P0TYNIL9iS+0OqzNbxspL499tMZO8ToGPcCmVnMrE8 hJSX7ret5dyuB9F1BbRxCsuAkgG4rPeDLfvkH/po7+MHFppcDNtAyOJ/83EfmlGrgEed 9lUQ== MIME-Version: 1.0 X-Received: by 10.152.206.11 with SMTP id lk11mr36061183lac.42.1413903762534; Tue, 21 Oct 2014 08:02:42 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Tue, 21 Oct 2014 08:02:42 -0700 (PDT) In-Reply-To: References: <20141021091305.67E4F182149@rfc-editor.org> Date: Tue, 21 Oct 2014 11:02:42 -0400 X-Google-Sender-Auth: hAfvDgb_3elghEuGhD3Shb_URO0 Message-ID: From: Barry Leiba To: Craig Taylor Content-Type: multipart/alternative; boundary=001a11349392833ab10505f01ffd Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QUAZIXhVnxKQEFUfGzu_C2rhPcI Cc: "apps-discuss@ietf.org" , "presnick@qti.qualcomm.com" , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7239 (4137) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 15:02:47 -0000 --001a11349392833ab10505f01ffd Content-Type: text/plain; charset=ISO-8859-1 Oh, no apology necessary, and I look forward to the discussion on apps-discuss. Barry On Tuesday, October 21, 2014, Craig Taylor wrote: > My apologies. I'm slightly embarrassed I didn't think of that myself. > > Dear 'list', > > Please see my initial statement at the tail of the email... > Many thanks, > CraigT > > > >> Firstly let me apologise for not submitting anything above, but I don't >> want submit possible duplicate effort without testing the water. >> >> One of the issues that we have always had with Forwarded: is highlighted >> perfectly by Section 8.1, I essentially can't trust it. I am happy to >> honour (in principle) Forwarded: set by trusted third parties where: >> >> 1) I know that they have set it >> 2) I know that they have clean up anything they don't trust or can't >> verify. >> >> Without this, I could never honour Forwarded: for Internet third parties, >> something that has been requested by Opera, Google etc. in the past. >> >> Were signing/validation schemes considered? >> Scaling concerns aside, without such things this will likely be relegated >> to corporate LAN use for many CSPs. >> >> Regards, >> CraigT >> > > > --001a11349392833ab10505f01ffd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Oh, no apology necessary, and I look forward to the discussion on apps-disc= uss.

Barry

On Tuesday, October 21, 2014, Craig Ta= ylor <craig.taylor@bbc.co.uk> wrote:
My apologies.=A0I'm slightly embarrassed I didn't think of tha= t myself.

Dear 'list',

Please see my initial statement at the tail of the email...
Many thanks,
CraigT



Firstly let me apologise for not submitting anything above, but I don't= want submit possible duplicate effort without testing the water.

One of the issues that we have always had with Forwarded: is highlighted pe= rfectly by Section 8.1, I essentially can't trust it. I am happy to hon= our (in principle) Forwarded: set by trusted third parties where:

1) I know that they have set it
2) I know that they have clean up anything they don't trust or can'= t verify.

Without this, I could never honour Forwarded: for Internet third parties, s= omething that has been requested by Opera, Google etc. in the past.

Were signing/validation schemes considered?
Scaling concerns aside, without such things this will likely be relegated t= o corporate LAN use for many CSPs.

Regards,
CraigT


--001a11349392833ab10505f01ffd-- From nobody Tue Oct 21 08:13:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085D91A875D for ; Tue, 21 Oct 2014 08:13:40 -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_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 HHcAbFr9jBur for ; Tue, 21 Oct 2014 08:13:29 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA3AB1A8744 for ; Tue, 21 Oct 2014 08:11:43 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id em10so2117262wid.7 for ; Tue, 21 Oct 2014 08:11:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:subject:references:date:to :mime-version:content-transfer-encoding:from:organization:message-id :in-reply-to:user-agent; bh=DnVX7mT8DNdw2dJhYbicc5NEuQX24WfqUZ+I5/m3yEU=; b=MkL7Pylz+01DPAyDeaRWwFIkCsuei9rJmut1P9KiI3PcgWBIxUnGmj3UZwxKymaXXO dfoclrLp6AiNmSJhVp2ddFqW4ic43khBjITKng/XQGduCOrs0AlK4eiVCX8DK+KNNWU3 8uYIgvSEArH7Zk6aTKMtyTtW1QHAehu0BmGh5oHBfNqGvR7+hO8sDNNpXdc7ZDWHIiSv LVVQBcfVQeVa7QumjSurNPka7nCuMD0iqyntd7Q4+xQFEz2CAXLxtkWhCFVZLdz6EVOz PQXzFf4Ih7DQdGClyyuwoJBBRtD67AolJ3h6cO7i/BiEQ1LnwYWGbGBxYoHss9rwL/Oa 5hSA== X-Gm-Message-State: ALoCoQloX+j5fJMn2+JVNWnGmzd3fkcv3Kcu2zACC0aQt9rAjcgeR8J9uawml2/pmOFkLjtxJM3d X-Received: by 10.194.189.82 with SMTP id gg18mr14649195wjc.115.1413904298613; Tue, 21 Oct 2014 08:11:38 -0700 (PDT) Received: from riaa ([2a00:801:e0:30:a8c0:8876:4a72:498d]) by mx.google.com with ESMTPSA id ky3sm15662889wjb.39.2014.10.21.08.11.37 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 21 Oct 2014 08:11:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes References: <20141021091305.67E4F182149@rfc-editor.org> Date: Tue, 21 Oct 2014 17:11:35 +0200 To: craig.taylor@bbc.co.uk, apps-discuss@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Martin Nilsson" Organization: Opera Software Message-ID: In-Reply-To: <20141021091305.67E4F182149@rfc-editor.org> User-Agent: Opera Mail/12.16 (Linux) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/F-IbKn4yDxllcFyCIhifto04fao Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7239 (4137) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 15:13:40 -0000 On Tue, 21 Oct 2014 11:13:05 +0200, RFC Errata System wrote: > > One of the issues that we have always had with Forwarded: is highlighted > perfectly by Section 8.1, I essentially can't trust it. I am happy to > honour (in principle) Forwarded: set by trusted third parties where: > > 1) I know that they have set it > 2) I know that they have clean up anything they don't trust or can't > verify. > > Without this, I could never honour Forwarded: for Internet third > parties, something that has been requested by Opera, Google etc. in the > past. > > Were signing/validation schemes considered? > Scaling concerns aside, without such things this will likely be > relegated to corporate LAN use for many CSPs. We did see a lot of issues with XFF, since it was poorly defined and had a lot of edge cases that caused problems. As we published our first draft we got a lot of feedback from reverse proxy users, where we identified some more problem areas. We ended up with roughly this list of objectives - properly describe the existing behavior - extend syntax to support IPv6, ports and secret tokens - describe the security implications - address the synchronization issue of having multiple headers We did not set out to make something semantically different than the pre-existing headers. I imagine that you can create some sort of encrypted or signed extension on top of our specification. I don't know how it would look like though to be generic enough and at the same time compact. It's also a question of what security margin you think you need. /Martin Nilsson -- Using Opera's mail client: http://www.opera.com/mail/ From nobody Tue Oct 21 09:11:58 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043A51A88C6 for ; Tue, 21 Oct 2014 09:11:56 -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 hlPmaUETyedT for ; Tue, 21 Oct 2014 09:11:54 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 972241A876B for ; Tue, 21 Oct 2014 09:11:53 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id z11so1250938lbi.41 for ; Tue, 21 Oct 2014 09:11:51 -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=ZO/e/LX2TxKQaEyFRfs3yTsc0ZHhfwyF0mpHuI+yzO0=; b=yShWaSSU8I1sfDD8612ooxo/dZWaNswLXKqUdyaqqVsbqAfICfIDqMTv51fTCjjC0y BBt7/bbUYBK4LxolnZKPNvfjk6oCCHw7WcV0TqXcNsZ0hoAMcdXG+J6vNTDntVpOxlSs ISlkeZJti5DXUj79wjEUEf5s7HzkIQgObXhFZ83x491STxSROL0SVCdeHFSVA+l/teO+ XVd0zWCzpmbB0Rot5umQqEGDWtLBqc4JFLh0HVfrE+Y5PC7VSkhb6fQ79TtV8wsc2Iiq r3v4t1/a5BYrfPEXZgtyqlmXZyZOq4gY51qmjx3nTuwg4U0Doikq1fHEtJ/F2a0/muBk MraA== MIME-Version: 1.0 X-Received: by 10.112.198.226 with SMTP id jf2mr17570505lbc.84.1413907910935; Tue, 21 Oct 2014 09:11:50 -0700 (PDT) Received: by 10.112.1.234 with HTTP; Tue, 21 Oct 2014 09:11:50 -0700 (PDT) Date: Tue, 21 Oct 2014 18:11:50 +0200 Message-ID: From: Melvin Carvalho To: Apps Discuss Content-Type: multipart/alternative; boundary=001a11c341cac6c9a90505f11613 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Lz6QHHAD19BCM2Onhizu5HMFUx0 Subject: [apps-discuss] Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 16:11:56 -0000 --001a11c341cac6c9a90505f11613 Content-Type: text/plain; charset=UTF-8 Hi all, I have the need to turn a local username at a host into an HTTP URI. There are 3 cases: 1. User already has an HTTP URI ( e.g. https://graph.facebook.com/mark# ) -- easy, I just use that. 2. User has a profile document but no user URI ( e.g. https://twitter.com/mark ) -- I have settled on a soution here, by adding the #this keyword. 3. I know the local user name and host but do not know a profile URL. e.g. ( mark / example.org ). My proposal is to use the '.well-known' pattern here and use the URL http:/example.org/.well-known/user/mark as the profile document. I cant think of anything better right now, any suggestions, or feedback on (3) would we welcome! Is it worth trying to register this pattern with IANA, or should that follow implementations? Thanks in advance! --001a11c341cac6c9a90505f11613 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2. User has a profile document but no u= ser URI ( e.g. https://twitter.com/mar= k ) -- I have settled on a soution here, by adding the #this keyword.
3. I know the local user name and host but do not know a profil= e URL.=C2=A0 e.g. ( mark / example.org )= .=C2=A0 My proposal is to use the '.well-known' pattern here and us= e the URL http:/exampl= e.org/.well-known/user/mark as the profile document.

I can= t think of anything better right now, any suggestions, or feedback on (3) w= ould we welcome!

Is it worth trying to register this pattern w= ith IANA, or should that follow implementations?

Thanks in adv= ance!
--001a11c341cac6c9a90505f11613-- From nobody Tue Oct 21 09:15:57 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EF11A88FE for ; Tue, 21 Oct 2014 09:15:57 -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 7JibeY_O0gBz for ; Tue, 21 Oct 2014 09:15:56 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F0E1A88F7 for ; Tue, 21 Oct 2014 09:15:55 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id uz6so1300811obc.29 for ; Tue, 21 Oct 2014 09:15:55 -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=/b3N6m+QHDwqEd+F9x+wcwyJB11DZoCD8D8iHCW80JM=; b=ILk3m316jCWtMQt38tMH7H68WHhtlsyutMXsNeNww1044FNk/OkxuiimY8lbCy3+uk u6I2eZT0sZuhhyRnpTEOxPKUmAuGqEXjpZwQj9GgJmYHl7EOm6QVspjXdAGE5rxPE0S+ ndJrJAAIg7HTX7XDUgv+TjLxzKzpEmiPkiNlo= 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=/b3N6m+QHDwqEd+F9x+wcwyJB11DZoCD8D8iHCW80JM=; b=hwBD9YPQra3UoDtt+rx9yIfF0cdkcZKjVlOxgqu1hsMy+/4Rs1D9hFdeAl1fDdai5Q y/bMRFH3T0z2yUvw/Rk1SJ209nGgaKLWRjUF5n/1JRkiDjAjriEYJi3i5t7EGyXuOHi2 7Qf0yxuShg8droq3r7wEWlwk+mjRkCtvJMiY0FiKnLVt0DmdTzBQY6Q8GwvB2uvb6nv+ ywPbKwGs+JonJ/azsKIRo3Q5Ggjf9qWoe6gFX+bJ7rJNPHPzm9/TOC8OgRkBGTaI3Raj m6Nk3+qlXdsEEz/QEsVkK8LpWfZvLWgpyAt7v0bD6LCCNdkwiWAGyV7WGeZbadQnsip9 Sfsg== X-Gm-Message-State: ALoCoQlPJq5MsotKPOijFU3YxTm8CVemomAwqlP8WbSyW4kBWNjqadSP6Yy5wYZUhzkNj58/2eCI MIME-Version: 1.0 X-Received: by 10.182.149.162 with SMTP id ub2mr2489153obb.86.1413908155212; Tue, 21 Oct 2014 09:15:55 -0700 (PDT) Received: by 10.60.150.238 with HTTP; Tue, 21 Oct 2014 09:15:55 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Oct 2014 17:15:55 +0100 Message-ID: From: Dave Cridland To: Melvin Carvalho Content-Type: multipart/alternative; boundary=001a11348910563e580505f1257b Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/HnOUxIjpaALnpi2nqusojbJOESg Cc: Apps Discuss Subject: Re: [apps-discuss] Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 16:15:57 -0000 --001a11348910563e580505f1257b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Do neither of acct: or webfinger apply here?=E2=80=8B --001a11348910563e580505f1257b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Do neither of acct: or webfinger apply here?=E2=80=8B --001a11348910563e580505f1257b-- From nobody Tue Oct 21 09:28:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442801A88C4 for ; Tue, 21 Oct 2014 09:28:35 -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 jC4AUOk0vxak for ; Tue, 21 Oct 2014 09:28:33 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F37F1A8969 for ; Tue, 21 Oct 2014 09:28:32 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id mc6so1413764lab.30 for ; Tue, 21 Oct 2014 09:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6rwRSvBUCWNPwIZju4F0kM+iYMnqBglKxWRyyaPi1Jo=; b=xLiivgmXy3iiELwFJHnbCOukieJRHgOu0LyqaKG6lNjrbN1tgZ+fwaHO4ObxU2JI01 Un7xCvArrlY9RfUuTs2t0rLQcM1y2fFlc22DFUmhdkmVx3+fIH3/PA313+tzLnFr29EZ +MJA3I6AyfPvCR3Da2MiwB+I63kmBrs2EAH7whX+ZDVDL9EKZlGvBKXHS6JLlx1qYnKm 5BmW9CyMK7eKYd8ZgAp2udwgk7C/teZTfIhA1q97V2EjZNrsetcwarH/bJnrfPFTn+hX cLLH9RFB1yJLZUIIdD9El58f9yJ+wJGTpeXwYNT7qrumbtxjlHpDCNP+XevVJDRDCSQe wqbw== MIME-Version: 1.0 X-Received: by 10.152.7.175 with SMTP id k15mr35687420laa.58.1413908911162; Tue, 21 Oct 2014 09:28:31 -0700 (PDT) Received: by 10.112.1.234 with HTTP; Tue, 21 Oct 2014 09:28:31 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Oct 2014 18:28:31 +0200 Message-ID: From: Melvin Carvalho To: Dave Cridland Content-Type: multipart/alternative; boundary=001a11c353f6650c190505f15247 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/FVH6I8OaA4CUCtNvSwNM2adC-VM Cc: Apps Discuss Subject: Re: [apps-discuss] Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 16:28:35 -0000 --001a11c353f6650c190505f15247 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 21 October 2014 18:15, Dave Cridland wrote: > Do neither of acct: or webfinger apply here?=E2=80=8B > 1. acct: potentially applies here potentially, but I'm trying to model a user and not an account, and also I'd like to use an HTTP URL. So it's not an ideal fit, but I thought about it. 2. re: webfinger I would to return HTML, rather than XRD, if the URL is dereferenced, so again not an ideal fit. It also doesnt tell me what value I should put in as the subject to .well0known/webfinger?, which is the problem I'm trying to solve in the first place. --001a11c353f6650c190505f15247 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 21 October 2014 18:15, Dave Cridland <dave@cridland.net> wrote:
Do neither = of acct: or webfinger apply here?=E2=80=8B

1. acct: potentially applies here potentially, but I'm trying to = model a user and not an account, and also I'd like to use an HTTP URL.= =C2=A0 So it's not an ideal fit, but I thought about it.

<= div>2. re: webfinger I would to return HTML, rather than XRD, if the URL is= dereferenced, so again not an ideal fit.=C2=A0 It also doesnt tell me what= value I should put in as the subject to .well0known/webfinger?, which is t= he problem I'm trying to solve in the first place.

<= /div>
--001a11c353f6650c190505f15247-- From nobody Tue Oct 21 11:09:08 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF561A87B2 for ; Tue, 21 Oct 2014 11:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zh7n7d2cgxBW for ; Tue, 21 Oct 2014 11:09:03 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431FB1A8796 for ; Tue, 21 Oct 2014 11:05:52 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CD6E350A87; Tue, 21 Oct 2014 14:05:50 -0400 (EDT) Message-ID: <5446A034.5060908@seantek.com> Date: Tue, 21 Oct 2014 11:04:36 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John Levine , apps-discuss@ietf.org References: <20141017184541.1079.qmail@ary.lan> In-Reply-To: <20141017184541.1079.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_DnYC1eJzkdvQLkYV7ZiYdN0ZKU Subject: Re: [apps-discuss] image/bmp: New Version Notification for draft-seantek-image-bmp-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, 21 Oct 2014 18:09:05 -0000 On 10/17/2014 11:45 AM, John Levine wrote: > In article <469C8ADC-97AF-49FA-AEE0-15F59EC39A6F@seantek.com> you write= : >> -=3D-=3D-=3D-=3D-=3D- >> -=3D-=3D-=3D-=3D-=3D- >> >> Colleagues: >> >> An Internet-Draft to register image/bmp has been posted. >> >> Thanks to Alexey Melnikov and Dave Thaler, who provided advice on thes= e >> drafts prior to submission. >> >> Feedback welcome. > BMP files can in fact contain text, inside embedded JPEG and PNG. I > don't know as there's much to say about it, other than that image > manipulation software wil do what it does. Thank you. It is probably best just to remove that text...which I will do for draft-= 01. Sean From nobody Tue Oct 21 13:08:15 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7751A01F9 for ; Tue, 21 Oct 2014 13:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 kRSTB3zkpU5S for ; Tue, 21 Oct 2014 13:07:57 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0E87B1A6EEF for ; Tue, 21 Oct 2014 13:07:45 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 667CD564881 for ; Tue, 21 Oct 2014 15:07:45 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 5E00D60392 for ; Tue, 21 Oct 2014 15:07:45 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuJVjrd0IrUn for ; Tue, 21 Oct 2014 15:07:45 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 4C791605A7 for ; Tue, 21 Oct 2014 15:07:44 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 4C791605A7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1413922064; bh=Oo/GFCelP7VPxC4g4X3RfLgTIdTojmyHGrxBfAQy90c=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=ADzEoRpcOojFcNpSOxPRbCpq/RUosf7fZWVNaOz2TfsKzSq/ME5dnDTsembr+dZZZ fX99X/8B6Yh3+fn4MC6MikErniZrrGe7RQan4z2vCHdv1cvdJcu2MsUY6sAVyg8IP9 58RAQVmc3hWOV0rNdjU52CVqZkcON8GLopD9o6Fg= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 36BC160392 for ; Tue, 21 Oct 2014 15:07:44 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ConIpdfRir1P for ; Tue, 21 Oct 2014 15:07:44 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 14A166025C for ; Tue, 21 Oct 2014 15:07:44 -0500 (CDT) Date: Tue, 21 Oct 2014 15:07:43 -0500 (CDT) From: Franck Martin To: IETF Apps Discuss Message-ID: <44757941.49835.1413922063168.JavaMail.zimbra@peachymango.org> In-Reply-To: <2067875592.49433.1413921372906.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_49834_2041434580.1413922063168" X-Originating-IP: [108.174.0.144] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF33 (Mac)/8.0.5_GA_5839) Thread-Topic: WG adoption for draft-martin-authentication-results-tls ? Thread-Index: aVRron212oibSK6ub2EvoTMZRKffVg== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zhmD-61g9SVmMH9yo_mukGDykKk Subject: [apps-discuss] WG adoption for draft-martin-authentication-results-tls ? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 20:08:05 -0000 ------=_Part_49834_2041434580.1413922063168 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I incorporated the previous feedback I received on this list into http://datatracker.ietf.org/doc/draft-martin-authentication-results-tls/ I have not seen comments since. Several people were supportive of the work. I'd like to submit this document to become a WG document for eventual publication. If you have any comments on the current version, I'll update it as much as I can before the deadline for drafts submission 27 October. I have some code running, tho I need to do some fixes in the code (and it is not public yet), but it helped me to better understand what needs to be exposed on how to do it. ------=_Part_49834_2041434580.1413922063168 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I incorporated the previous feedback I received on this list into http://datatracker.ietf.org/doc/draft-martin-authentication-results-tls/

I have not seen comments since. Several people were supportive of the work.

I'd like to submit this document to become a WG document for eventual publication.

If you have any comments on the current version, I'll update it as much as I can before the deadline for drafts submission 27 October.

I have some code running, tho I need to do some fixes in the code (and it is not public yet), but it helped me to better understand what needs to be exposed on how to do it.


------=_Part_49834_2041434580.1413922063168-- From nobody Tue Oct 21 14:13:57 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78F01A00D7; Tue, 21 Oct 2014 01:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Dkmmr9DnUcxs; Tue, 21 Oct 2014 01:52:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24DF11A00FB; Tue, 21 Oct 2014 01:52:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNW43038; Tue, 21 Oct 2014 08:52:24 +0000 (GMT) Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 21 Oct 2014 09:52:23 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Tue, 21 Oct 2014 16:52:16 +0800 From: Bert Greevenbosch To: "'draft-ietf-weirds-bootstrap.all@tools.ietf.org'" <'draft-ietf-weirds-bootstrap.all@tools.ietf.org'>, "'apps-discuss@ietf.org'" <'apps-discuss@ietf.org'>, "'iesg@ietf.org'" <'iesg@ietf.org'> Thread-Topic: Applications Area Directorate Review of draft-ietf-weirds-bootstrap-09 Thread-Index: AQHP7QxQJs+8Z75SPkO+RCtr3FGFVQ== Date: Tue, 21 Oct 2014 08:52:15 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63E7789FF@SZXEMA510-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.174.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/PYBw7xnTEuex6y1rh8M046L97_M X-Mailman-Approved-At: Tue, 21 Oct 2014 14:13:51 -0700 Subject: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-bootstrap-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 08:52:32 -0000 Document: draft-ietf-weirds-bootstrap-09 Title: Finding the Authoritative Registration Data (RDAP) Service Reviewer: Bert Greevenbosch Review Date: 21 October 2014 IETF Last Call Date: 27 October 2014 IESG Telechat Date: 30 October 2014 Summary: Needs some edits. Major Issues: None Minor Issues: (m1) Section 5.2. The IPv6 address notation "2001:0200:1000::/28" is a bit = strange since 1000 is not part of the first 28 bits. Is this intentional? I= f not, I propose to replace it by "2001:0200::/28" or "2001:0200:100::/38".= This replacement would need to be done in the JSON code as well as in the = text. Nits: (n1) In section 1, second paragraph, replace "Autonomous numbers (AS)" by "= Autonomous Systems (AS) numbers". (n2) Section 8, first bullet: propose to remove "a" from "if it is a mistyp= ed information by the user." From nobody Tue Oct 21 14:13:59 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873491A6F0B for ; Tue, 21 Oct 2014 07:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 69ZnoZSV7o7o for ; Tue, 21 Oct 2014 07:05:51 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 487F21A6F02 for ; Tue, 21 Oct 2014 07:05:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id F3ED51E5A0C; Tue, 21 Oct 2014 07:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53bS8ZZ_ri5q; Tue, 21 Oct 2014 07:05:25 -0700 (PDT) Received: from [10.0.1.4] (pool-108-56-218-121.washdc.fios.verizon.net [108.56.218.121]) by c8a.amsl.com (Postfix) with ESMTPA id DAB8A1E5A0B; Tue, 21 Oct 2014 07:05:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Megan Ferguson In-Reply-To: Date: Tue, 21 Oct 2014 10:05:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141021091305.67E4F182149@rfc-editor.org> To: Barry Leiba X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/YVWY1WtxbJq0WSD-OR8CL724nRk X-Mailman-Approved-At: Tue, 21 Oct 2014 14:13:50 -0700 Cc: "apps-discuss@ietf.org" , "presnick@qti.qualcomm.com" , "craig.taylor@bbc.co.uk" , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7239 (4137) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 14:05:55 -0000 Barry, This record has been deleted as requested. Thank you. RFC Editor/mf On Oct 21, 2014, at 8:35 AM, Barry Leiba wrote: > Hi, Craig, and thanks for the questions/comments. It's too bad that = there isn't a clear place for having these discussions that people who = aren't already "in the know" can find. >=20 > The right place to ask and discuss this is the apps-discuss mailing = list, : = https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > Craig, please take these questions there. >=20 > RFC Editor, please remove this report from the errata system. >=20 > Thanks, > Barry >=20 > On Tuesday, October 21, 2014, RFC Errata System = wrote: > The following errata report has been submitted for RFC7239, > "Forwarded HTTP Extension". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D7239&eid=3D4137 >=20 > -------------------------------------- > Type: Technical > Reported by: Craig Taylor >=20 > Section: Parameters >=20 > Original Text > ------------- >=20 >=20 > Corrected Text > -------------- >=20 >=20 > Notes > ----- > Firstly let me apologise for not submitting anything above, but I = don't want submit possible duplicate effort without testing the water. >=20 > One of the issues that we have always had with Forwarded: is = highlighted perfectly by Section 8.1, I essentially can't trust it. I am = happy to honour (in principle) Forwarded: set by trusted third parties = where: >=20 > 1) I know that they have set it > 2) I know that they have clean up anything they don't trust or can't = verify. >=20 > Without this, I could never honour Forwarded: for Internet third = parties, something that has been requested by Opera, Google etc. in the = past. >=20 > Were signing/validation schemes considered? > Scaling concerns aside, without such things this will likely be = relegated to corporate LAN use for many CSPs. >=20 > Regards, > CraigT >=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 > -------------------------------------- > RFC7239 (draft-ietf-appsawg-http-forwarded-10) > -------------------------------------- > Title : Forwarded HTTP Extension > Publication Date : June 2014 > Author(s) : A. Petersson, M. Nilsson > Category : PROPOSED STANDARD > Source : Applications Area Working Group > Area : Applications > Stream : IETF > Verifying Party : IESG >=20 From nobody Tue Oct 21 14:29:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D433F1A873F for ; Tue, 21 Oct 2014 14:29:20 -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 q9-ievzRdpOy for ; Tue, 21 Oct 2014 14:29:18 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E90361A874D for ; Tue, 21 Oct 2014 14:29:10 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id l4so1797829lbv.10 for ; Tue, 21 Oct 2014 14:29:09 -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=bSVB1fz2Rr2cxyqYamEN2m7WYDCQuP0bJUxd6wDbJeE=; b=HV34bNXqEb9iVOa74EyTqaxVu2p9LMmX/1R6JTPiCkkU/gsvluhsaahx96XfGl5qLI +KwdUCoxR35xH/6sjSPstQq9SgWCS9tLe5KezgrEH5n6lvkNSMXLnAw0WlgOXbbPyEWA bHDd5Nhgi1t1OB/yaZC7uCYms2929AFPQ9vD1zk9X8KmiN2Liq/3gVnaL2GQlNs4chho 86t1j6w+q/8QdZ8F9D6LrJnH3i/rA8KHjp7ETbUp2wgpLM2SMuipDqZYJn/2uny6D46a joHBAozOYn4leWB0OygazgfzO9EQpE7ySHv9FBLLI/dcp83sqijJ7kTDdXDYuYhvNLuy A1yw== MIME-Version: 1.0 X-Received: by 10.112.150.136 with SMTP id ui8mr24986270lbb.60.1413926949105; Tue, 21 Oct 2014 14:29:09 -0700 (PDT) Received: by 10.25.211.11 with HTTP; Tue, 21 Oct 2014 14:29:08 -0700 (PDT) Date: Tue, 21 Oct 2014 14:29:08 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7b3a8c808a37630505f585e3 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0_xuNx98pkZ82QMKok2YYV3Ndlo Subject: [apps-discuss] draft-nottingham-safe-hint X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 21:29:21 -0000 --047d7b3a8c808a37630505f585e3 Content-Type: text/plain; charset=UTF-8 Colleagues, Some time ago we did a Call For Adoption of this document. In the datatracker, this bound the document to APPSAWG. In the end we decided not to adopt the document and instead Barry would sponsor it. At that time I marked it as a "Dead WG Document". We don't appear to have a mechanism by which the document can be decoupled from the working group, so you may see messages indicating it's being last called as a WG document. In fact, Barry is sponsoring it as an Independent Submission. Thus, any such comments you see in Last Call announcements were automatically generated, and not intentional. It will be a four-week Last Call as expected. No shenanigans. -MSK, APPSAWG co-chair --047d7b3a8c808a37630505f585e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

Some time ago= we did a Call For Adoption of this document.=C2=A0 In the datatracker, thi= s bound the document to APPSAWG.=C2=A0 In the end we decided not to adopt t= he document and instead Barry would sponsor it.=C2=A0 At that time I marked= it as a "Dead WG Document".

We don't appea= r to have a mechanism by which the document can be decoupled from the worki= ng group, so you may see messages indicating it's being last called as = a WG document.=C2=A0 In fact, Barry is sponsoring it as an Independent Subm= ission.=C2=A0 Thus, any such comments you see in Last Call announcements we= re automatically generated, and not intentional.=C2=A0 It will be a four-we= ek Last Call as expected.=C2=A0 No shenanigans.

-M= SK, APPSAWG co-chair
--047d7b3a8c808a37630505f585e3-- From nobody Tue Oct 21 14:30:16 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5977F1A870A for ; Tue, 21 Oct 2014 07:48:25 -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, HTML_MESSAGE=0.001, 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 FFVsGSs1J8cj for ; Tue, 21 Oct 2014 07:48:21 -0700 (PDT) Received: from mailout1.mh.bbc.co.uk (mailout1.mh.bbc.co.uk [132.185.144.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C681A6F6D for ; Tue, 21 Oct 2014 07:48:05 -0700 (PDT) Received: from BGB01XI1012.national.core.bbc.co.uk (bgb01xi1012.national.core.bbc.co.uk [10.161.14.16]) by mailout1.mh.bbc.co.uk (8.14.4/8.14.3) with ESMTP id s9LElx6J011940; Tue, 21 Oct 2014 15:48:00 +0100 (BST) Received: from BGB01XUD1003.national.core.bbc.co.uk ([169.254.4.153]) by BGB01XI1012.national.core.bbc.co.uk ([10.161.14.16]) with mapi id 14.02.0342.004; Tue, 21 Oct 2014 15:47:59 +0100 From: Craig Taylor To: Barry Leiba , RFC Errata System Thread-Topic: [Technical Errata Reported] RFC7239 (4137) Thread-Index: AQHP7Q9HdTSBnQaUB0mIbVWIHsZEgJw6bAwAgAA14QA= Date: Tue, 21 Oct 2014 14:48:05 +0000 Message-ID: References: <20141021091305.67E4F182149@rfc-editor.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [172.19.161.211] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 Content-Type: multipart/alternative; boundary="_000_D06C2FB243731craigtaylorbbccouk_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_eupnD6jrFMD0FB9WQDbLcLIZDU X-Mailman-Approved-At: Tue, 21 Oct 2014 14:30:13 -0700 Cc: "apps-discuss@ietf.org" , "presnick@qti.qualcomm.com" Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7239 (4137) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 14:48:25 -0000 --_000_D06C2FB243731craigtaylorbbccouk_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgYXBvbG9naWVzLiBJJ20gc2xpZ2h0bHkgZW1iYXJyYXNzZWQgSSBkaWRuJ3QgdGhpbmsgb2Yg dGhhdCBteXNlbGYuDQoNCkRlYXIgJ2xpc3QnLA0KDQpQbGVhc2Ugc2VlIG15IGluaXRpYWwgc3Rh dGVtZW50IGF0IHRoZSB0YWlsIG9mIHRoZSBlbWFpbC4uLg0KTWFueSB0aGFua3MsDQpDcmFpZ1QN Cg0KDQoNCkZpcnN0bHkgbGV0IG1lIGFwb2xvZ2lzZSBmb3Igbm90IHN1Ym1pdHRpbmcgYW55dGhp bmcgYWJvdmUsIGJ1dCBJIGRvbid0IHdhbnQgc3VibWl0IHBvc3NpYmxlIGR1cGxpY2F0ZSBlZmZv cnQgd2l0aG91dCB0ZXN0aW5nIHRoZSB3YXRlci4NCg0KT25lIG9mIHRoZSBpc3N1ZXMgdGhhdCB3 ZSBoYXZlIGFsd2F5cyBoYWQgd2l0aCBGb3J3YXJkZWQ6IGlzIGhpZ2hsaWdodGVkIHBlcmZlY3Rs eSBieSBTZWN0aW9uIDguMSwgSSBlc3NlbnRpYWxseSBjYW4ndCB0cnVzdCBpdC4gSSBhbSBoYXBw eSB0byBob25vdXIgKGluIHByaW5jaXBsZSkgRm9yd2FyZGVkOiBzZXQgYnkgdHJ1c3RlZCB0aGly ZCBwYXJ0aWVzIHdoZXJlOg0KDQoxKSBJIGtub3cgdGhhdCB0aGV5IGhhdmUgc2V0IGl0DQoyKSBJ IGtub3cgdGhhdCB0aGV5IGhhdmUgY2xlYW4gdXAgYW55dGhpbmcgdGhleSBkb24ndCB0cnVzdCBv ciBjYW4ndCB2ZXJpZnkuDQoNCldpdGhvdXQgdGhpcywgSSBjb3VsZCBuZXZlciBob25vdXIgRm9y d2FyZGVkOiBmb3IgSW50ZXJuZXQgdGhpcmQgcGFydGllcywgc29tZXRoaW5nIHRoYXQgaGFzIGJl ZW4gcmVxdWVzdGVkIGJ5IE9wZXJhLCBHb29nbGUgZXRjLiBpbiB0aGUgcGFzdC4NCg0KV2VyZSBz aWduaW5nL3ZhbGlkYXRpb24gc2NoZW1lcyBjb25zaWRlcmVkPw0KU2NhbGluZyBjb25jZXJucyBh c2lkZSwgd2l0aG91dCBzdWNoIHRoaW5ncyB0aGlzIHdpbGwgbGlrZWx5IGJlIHJlbGVnYXRlZCB0 byBjb3Jwb3JhdGUgTEFOIHVzZSBmb3IgbWFueSBDU1BzLg0KDQpSZWdhcmRzLA0KQ3JhaWdUDQoN Cg0K --_000_D06C2FB243731craigtaylorbbccouk_ Content-Type: text/html; charset="utf-8" Content-ID: <51793B4BEA119C48919FA8E72BE859B5@bbc.co.uk> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+TXkgYXBvbG9n aWVzLiZuYnNwO0knbSBzbGlnaHRseSBlbWJhcnJhc3NlZCBJIGRpZG4ndCB0aGluayBvZiB0aGF0 IG15c2VsZi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkRlYXIgJ2xpc3QnLDwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UGxlYXNlIHNlZSBteSBpbml0aWFsIHN0YXRlbWVu dCBhdCB0aGUgdGFpbCBvZiB0aGUgZW1haWwuLi48L2Rpdj4NCjxkaXY+TWFueSB0aGFua3MsPC9k aXY+DQo8ZGl2PkNyYWlnVDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8YnI+DQpG aXJzdGx5IGxldCBtZSBhcG9sb2dpc2UgZm9yIG5vdCBzdWJtaXR0aW5nIGFueXRoaW5nIGFib3Zl LCBidXQgSSBkb24ndCB3YW50IHN1Ym1pdCBwb3NzaWJsZSBkdXBsaWNhdGUgZWZmb3J0IHdpdGhv dXQgdGVzdGluZyB0aGUgd2F0ZXIuPGJyPg0KPGJyPg0KT25lIG9mIHRoZSBpc3N1ZXMgdGhhdCB3 ZSBoYXZlIGFsd2F5cyBoYWQgd2l0aCBGb3J3YXJkZWQ6IGlzIGhpZ2hsaWdodGVkIHBlcmZlY3Rs eSBieSBTZWN0aW9uIDguMSwgSSBlc3NlbnRpYWxseSBjYW4ndCB0cnVzdCBpdC4gSSBhbSBoYXBw eSB0byBob25vdXIgKGluIHByaW5jaXBsZSkgRm9yd2FyZGVkOiBzZXQgYnkgdHJ1c3RlZCB0aGly ZCBwYXJ0aWVzIHdoZXJlOjxicj4NCjxicj4NCjEpIEkga25vdyB0aGF0IHRoZXkgaGF2ZSBzZXQg aXQ8YnI+DQoyKSBJIGtub3cgdGhhdCB0aGV5IGhhdmUgY2xlYW4gdXAgYW55dGhpbmcgdGhleSBk b24ndCB0cnVzdCBvciBjYW4ndCB2ZXJpZnkuPGJyPg0KPGJyPg0KV2l0aG91dCB0aGlzLCBJIGNv dWxkIG5ldmVyIGhvbm91ciBGb3J3YXJkZWQ6IGZvciBJbnRlcm5ldCB0aGlyZCBwYXJ0aWVzLCBz b21ldGhpbmcgdGhhdCBoYXMgYmVlbiByZXF1ZXN0ZWQgYnkgT3BlcmEsIEdvb2dsZSBldGMuIGlu IHRoZSBwYXN0Ljxicj4NCjxicj4NCldlcmUgc2lnbmluZy92YWxpZGF0aW9uIHNjaGVtZXMgY29u c2lkZXJlZD88YnI+DQpTY2FsaW5nIGNvbmNlcm5zIGFzaWRlLCB3aXRob3V0IHN1Y2ggdGhpbmdz IHRoaXMgd2lsbCBsaWtlbHkgYmUgcmVsZWdhdGVkIHRvIGNvcnBvcmF0ZSBMQU4gdXNlIGZvciBt YW55IENTUHMuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpDcmFpZ1Q8YnI+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D06C2FB243731craigtaylorbbccouk_-- From nobody Tue Oct 21 17:57:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB8E1A88C6 for ; Tue, 21 Oct 2014 17:57:36 -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 KBAmYWyEmQRf for ; Tue, 21 Oct 2014 17:57:34 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 312B51A88C0 for ; Tue, 21 Oct 2014 17:57:34 -0700 (PDT) Received: from [192.168.1.83] (unknown [118.209.19.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id ADEA222E1F4; Tue, 21 Oct 2014 20:57:31 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Mark Nottingham In-Reply-To: Date: Wed, 22 Oct 2014 11:57:28 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <025AC618-F0AE-4717-ACBC-53E24C2C6645@mnot.net> References: <20141021091305.67E4F182149@rfc-editor.org> To: Martin Nilsson X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/qTRgzL7fYQlWRXPsOe0dbKmsoPU Cc: craig.taylor@bbc.co.uk, apps-discuss@ietf.org Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7239 (4137) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 00:57:36 -0000 On 22 Oct 2014, at 2:11 am, Martin Nilsson wrote: >=20 > On Tue, 21 Oct 2014 11:13:05 +0200, RFC Errata System = wrote: >=20 >>=20 >> One of the issues that we have always had with Forwarded: is = highlighted perfectly by Section 8.1, I essentially can't trust it. I am = happy to honour (in principle) Forwarded: set by trusted third parties = where: >>=20 >> 1) I know that they have set it >> 2) I know that they have clean up anything they don't trust or can't = verify. >>=20 >> Without this, I could never honour Forwarded: for Internet third = parties, something that has been requested by Opera, Google etc. in the = past. >>=20 >> Were signing/validation schemes considered? >> Scaling concerns aside, without such things this will likely be = relegated to corporate LAN use for many CSPs. >=20 > We did see a lot of issues with XFF, since it was poorly defined and = had a lot of edge cases that caused problems. As we published our first = draft we got a lot of feedback from reverse proxy users, where we = identified some more problem areas. We ended up with roughly this list = of objectives >=20 > - properly describe the existing behavior > - extend syntax to support IPv6, ports and secret tokens > - describe the security implications > - address the synchronization issue of having multiple headers >=20 > We did not set out to make something semantically different than the = pre-existing headers. I imagine that you can create some sort of = encrypted or signed extension on top of our specification. I don't know = how it would look like though to be generic enough and at the same time = compact. It's also a question of what security margin you think you = need. I always thought that a sig mechanism was necessary for Forwarded (a few = of my employers have done that as a one-off); however, we probably = weren't ready to do it back then. Anyone want to pick up the ball? :) -- Mark Nottingham https://www.mnot.net/ From nobody Tue Oct 21 18:54:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A231A899A for ; Tue, 21 Oct 2014 18:54:22 -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_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 tZUYNgP4Y5s5 for ; Tue, 21 Oct 2014 18:54:19 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6499A1A8993 for ; Tue, 21 Oct 2014 18:54:19 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id b13so2696126wgh.12 for ; Tue, 21 Oct 2014 18:54:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:to:cc:subject:references:date :mime-version:content-transfer-encoding:from:organization:message-id :in-reply-to:user-agent; bh=r22uGr+iPRnDrC4w9HFplz4pR2bd5c0ysV1I2QRkFmE=; b=kS1zSGeAFnaonVEgmIQusi/iImfvSS7r/SaEJJT3/yJr0bKw404eJMh4iOGB5Z8TwP kvprjD9nLp1KO81vETAhsEXtePEip1Gn1zMI/GVqx2EXHle2UYHvJgs8wRJS6xlqiV3W w9zfYHkO5tvpd7TEl5EVR4h3Mjv5Pl94Pe8CFeSa2CU0JDeUr55aua7AHbQXrGaSZZAM Wr2TQwFruxt5nwztHZOIi+vtsgYnqrG434QEUzoGuUrLTOXx0UihoLUYJP1zhsUHv0KY lSk4nYUuEKRefoVL12XWYiVRW1K6niv69YGQJhbBBHb9Co+LeUsjmMsE47dZXsKBNwIp KnIA== X-Gm-Message-State: ALoCoQnGCWLFAMKmhngVijumq2mDjRVUqE6Yw9KkxjT+vviaQupWcyj5LjYfEu2nG/QbhJrDZnNG X-Received: by 10.180.182.18 with SMTP id ea18mr1454097wic.32.1413942857858; Tue, 21 Oct 2014 18:54:17 -0700 (PDT) Received: from beryllium.oslo.osa (c-151ce353.03-25-6c6b7010.cust.bredbandsbolaget.se. [83.227.28.21]) by mx.google.com with ESMTPSA id u8sm17168104wjq.1.2014.10.21.18.54.16 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 21 Oct 2014 18:54:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Mark Nottingham" References: <20141021091305.67E4F182149@rfc-editor.org> <025AC618-F0AE-4717-ACBC-53E24C2C6645@mnot.net> Date: Wed, 22 Oct 2014 03:54:18 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Martin Nilsson" Organization: Opera Software ASA Message-ID: In-Reply-To: <025AC618-F0AE-4717-ACBC-53E24C2C6645@mnot.net> User-Agent: Opera Mail/12.17 (Win32) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/HV5S4gul28DPdyhBRyImDahb0PE Cc: craig.taylor@bbc.co.uk, apps-discuss@ietf.org Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7239 (4137) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 01:54:22 -0000 On Wed, 22 Oct 2014 02:57:28 +0200, Mark Nottingham wrote: > > I always thought that a sig mechanism was necessary for Forwarded (a few > of my employers have done that as a one-off); however, we probably > weren't ready to do it back then. > > Anyone want to pick up the ball? :) > What is the actual use case though? If you don't trust the IP number as an identifier of a third party, you should use TLS. I can see that you would want to substitute identification of third parties through IP with signatures as an abstraction for practical reasons. I assume that providing integrity isn't the point (again, if you think someone is tampering with the content without affecting the IP endpoints, you need TLS). There is also the case where headers are set by a trusted third party that then passes an untrusted (non-transparent) party, but I can't think of when that would that happen? /Martin Nilsson -- Using Opera's mail client: http://www.opera.com/mail/ From nobody Tue Oct 21 20:32:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0B41A8A75 for ; Tue, 21 Oct 2014 20:32:27 -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 EmwJ9KczeeIV for ; Tue, 21 Oct 2014 20:32:25 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 586401A8A70 for ; Tue, 21 Oct 2014 20:32:25 -0700 (PDT) Received: from [192.168.1.83] (unknown [118.209.19.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DDA4222E1F4; Tue, 21 Oct 2014 23:32:22 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Mark Nottingham In-Reply-To: Date: Wed, 22 Oct 2014 14:32:19 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <0659A04B-8ABA-4A02-BBFD-EB0ACF6A88F3@mnot.net> References: <20141021091305.67E4F182149@rfc-editor.org> <025AC618-F0AE-4717-ACBC-53E24C2C6645@mnot.net> To: Martin Nilsson X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/asziIkixTWqSzhtjayJLVR7ZBXk Cc: craig.taylor@bbc.co.uk, apps-discuss@ietf.org Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7239 (4137) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 03:32:28 -0000 > On 22 Oct 2014, at 12:54 pm, Martin Nilsson wrote: >=20 > On Wed, 22 Oct 2014 02:57:28 +0200, Mark Nottingham = wrote: >=20 >>=20 >> I always thought that a sig mechanism was necessary for Forwarded (a = few of my employers have done that as a one-off); however, we probably = weren't ready to do it back then. >>=20 >> Anyone want to pick up the ball? :) >>=20 >=20 > What is the actual use case though? >=20 > If you don't trust the IP number as an identifier of a third party, = you should use TLS. I can see that you would want to substitute = identification of third parties through IP with signatures as an = abstraction for practical reasons. >=20 > I assume that providing integrity isn't the point (again, if you think = someone is tampering with the content without affecting the IP = endpoints, you need TLS). There is also the case where headers are set = by a trusted third party that then passes an untrusted (non-transparent) = party, but I can't think of when that would that happen? It's useful to have integrity / authentication for this info within your = own infrastructure. True, you could do this with client certs on the TLS = hop, but lots of software doesn't support that (and AIUI won't easily; = think proxies, etc). It's also useful to have a spec so that middleware = authors have something to shoot for; think load balancers, CDNs, etc. = Persisting the information is also a good thing, but there's not yet any = stadard way to do that in a HTTP message for TLS certs. The other way you could go about this is having a generic mechanism for = signing headers full stop -- many have discussed that (and still are). = However, in this use case, you need to sign just one header value = (amongst potentially many) that represents a hop; most of the mechanisms = I've seen don't have that kind of granularity. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Oct 22 01:39:33 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B431A8AFA; Wed, 22 Oct 2014 01:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0AEOa-S1_ELo; Wed, 22 Oct 2014 01:39:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83E721A8BAF; Wed, 22 Oct 2014 01:39:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKU76820; Wed, 22 Oct 2014 08:39:24 +0000 (GMT) Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Oct 2014 09:39:23 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Wed, 22 Oct 2014 16:39:18 +0800 From: Bert Greevenbosch To: "draft-ietf-weirds-rdap-sec.all@tools.ietf.org" , "'iesg@ietf.org'" <'iesg@ietf.org'>, "apps-discuss@ietf.org" Thread-Topic: Applications Area Directorate Review of draft-ietf-weirds-rdap-sec-09 Thread-Index: AQHP7dOraLlEMb/T9k2LS8+NEgKgDw== Date: Wed, 22 Oct 2014 08:39:18 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63E779CE3@SZXEMA510-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.174.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/43K3yhPAizQ0xmUywTyt4j3Wboc Subject: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-rdap-sec-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 08:39:29 -0000 Document: draft-ietf-weirds-rdap-sec-09 Title: Finding the Authoritative Registration Data (RDAP) Service Reviewer: Bert Greevenbosch Review Date: 22 October 2014 IETF Last Call Date: 24 October 2014 IESG Telechat Date: 30 October 2014 Summary: May need an edit. Major Issues: None Minor Issues: None Nits: (n1) 3.3, it would be nice to replace "a 429 response code" by "a 429 (Too = many Requests) response code". REMARK:=20 The draft is mainly about re-using existing security technology, rather tha= n inventing something new for RDAP. The draft especially focuses on HTTP ov= er TLS and possible use of X.509 certificates or password+username for auth= entication, as well as more advanced systems for authorisation. In addition, the draft discusses various security choices that have to be m= ade, and issues that need to be considered. The draft is good reading. However, if one would like to build a secured RD= AP system, the draft can only serve as a guideline, as it leaves many choic= es open for the specific deployment. From nobody Wed Oct 22 03:14:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255C31A8FD3 for ; Wed, 22 Oct 2014 03:14:20 -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 TvtKZDHMZp9W for ; Wed, 22 Oct 2014 03:14:16 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DCEDA1A901E for ; Wed, 22 Oct 2014 03:14:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4F393BE32; Wed, 22 Oct 2014 11:14:15 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRFqIcYo62Pu; Wed, 22 Oct 2014 11:14:15 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 25509BE24; Wed, 22 Oct 2014 11:14:15 +0100 (IST) Message-ID: <54478377.6090304@cs.tcd.ie> Date: Wed, 22 Oct 2014 11:14:15 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Mark Nottingham , Martin Nilsson References: <20141021091305.67E4F182149@rfc-editor.org> <025AC618-F0AE-4717-ACBC-53E24C2C6645@mnot.net> <0659A04B-8ABA-4A02-BBFD-EB0ACF6A88F3@mnot.net> In-Reply-To: <0659A04B-8ABA-4A02-BBFD-EB0ACF6A88F3@mnot.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6e_AMYmv3DJ7OJtbR0Lw0hMVAlU Cc: craig.taylor@bbc.co.uk, apps-discuss@ietf.org Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7239 (4137) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 10:14:20 -0000 On 22/10/14 04:32, Mark Nottingham wrote: > >> On 22 Oct 2014, at 12:54 pm, Martin Nilsson >> wrote: >> >> On Wed, 22 Oct 2014 02:57:28 +0200, Mark Nottingham >> wrote: >> >>> >>> I always thought that a sig mechanism was necessary for Forwarded >>> (a few of my employers have done that as a one-off); however, we >>> probably weren't ready to do it back then. >>> >>> Anyone want to pick up the ball? :) >>> >> >> What is the actual use case though? >> >> If you don't trust the IP number as an identifier of a third party, >> you should use TLS. I can see that you would want to substitute >> identification of third parties through IP with signatures as an >> abstraction for practical reasons. >> >> I assume that providing integrity isn't the point (again, if you >> think someone is tampering with the content without affecting the >> IP endpoints, you need TLS). There is also the case where headers >> are set by a trusted third party that then passes an untrusted >> (non-transparent) party, but I can't think of when that would that >> happen? > > It's useful to have integrity / authentication for this info within > your own infrastructure. True, you could do this with client certs on > the TLS hop, but lots of software doesn't support that (and AIUI > won't easily; think proxies, etc). It's also useful to have a spec so > that middleware authors have something to shoot for; think load > balancers, CDNs, etc. Persisting the information is also a good > thing, but there's not yet any stadard way to do that in a HTTP > message for TLS certs. > > The other way you could go about this is having a generic mechanism > for signing headers full stop -- many have discussed that (and still > are). However, in this use case, you need to sign just one header > value (amongst potentially many) that represents a hop; most of the > mechanisms I've seen don't have that kind of granularity. If someone does do more work on this, please consider privacy this time around. There's no reason that this has to be done as badly as XFF. S. > > Cheers, > > -- Mark Nottingham https://www.mnot.net/ > > _______________________________________________ apps-discuss mailing > list apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Wed Oct 22 03:15:20 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874831A901C for ; Wed, 22 Oct 2014 03:15:17 -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 Fx825Z90LhQW for ; Wed, 22 Oct 2014 03:15:15 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB5E1A9009 for ; Wed, 22 Oct 2014 03:15:15 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xgswe-000FtY-Ha; Wed, 22 Oct 2014 06:15:08 -0400 Date: Wed, 22 Oct 2014 06:15:03 -0400 From: John C Klensin To: Martin Nilsson , Mark Nottingham , craig.taylor@bbc.co.uk Message-ID: In-Reply-To: References: <20141021091305.67E4F182149@rfc-editor.org> <025AC618-F0AE-4717-ACBC-53E24C2C6645@mnot.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: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/chNCg7ooojGH3G5xELdzuMd71AA Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7239 (4137) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 10:15:17 -0000 Could folks who want to discuss this topic further _please_ change the subject line so that those of us to try to prioritize RFC Errata reports won't be disrupted by a topic that is not one of those? thanks john From nobody Wed Oct 22 03:28:21 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E9B1A9030 for ; Wed, 22 Oct 2014 03:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okyTHh5ORCtz for ; Wed, 22 Oct 2014 03:28:09 -0700 (PDT) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB1F11A903D for ; Wed, 22 Oct 2014 03:28:08 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id y13so1227372pdi.20 for ; Wed, 22 Oct 2014 03:28:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AQ9l+5wwDF0iQlTekNEX0QP1sYZWZWylfYRSEc3ru7s=; b=jYhcfjIbJk3SEGdr80i5L7t10+IhViCptiPvYIE3M60R7P2hhCriZbNrQiwCK7Qb6J Zif4f/R4SYKI5vhTWv0834rpUi18vWEQK+8bex7/JWrKxzPnBb8EbLvWTfLoFzAs99KD m38UFIeWi/kz4h67YFJtQKondUz3SVFbXQUYmyq3SurSJDSMLsPnUteC3JVrpBuIOWmP msEqqm60PP9BlF1Sn1xyPS1RxqcSp9u52H59QIxT3FrDsSj6MAnJWh+9uh/M6S1vYbXH dcJ3+LB1Aw+HmQLuEA0xaqm/lZq+5/+JC3lCzilwCUTkSSSNxODkzHyTl3L30PVRZNXb hTLA== X-Gm-Message-State: ALoCoQmTrOjRSpH6AHwSKH0PIRHdVjA7brjZBwaTTdgREAL7LI6sxAFUwaOGT2SWV6+hbdRMwHQs MIME-Version: 1.0 X-Received: by 10.70.37.236 with SMTP id b12mr40520608pdk.75.1413973688185; Wed, 22 Oct 2014 03:28:08 -0700 (PDT) Received: by 10.66.97.36 with HTTP; Wed, 22 Oct 2014 03:28:08 -0700 (PDT) X-Originating-IP: [132.185.151.35] In-Reply-To: <0659A04B-8ABA-4A02-BBFD-EB0ACF6A88F3@mnot.net> References: <20141021091305.67E4F182149@rfc-editor.org> <025AC618-F0AE-4717-ACBC-53E24C2C6645@mnot.net> <0659A04B-8ABA-4A02-BBFD-EB0ACF6A88F3@mnot.net> Date: Wed, 22 Oct 2014 11:28:08 +0100 Message-ID: From: "c^" To: Mark Nottingham Content-Type: multipart/alternative; boundary=047d7bfea2c8683b410506006765 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/PTNx22RVmvCfzUaDWRRWhdJYBGg Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7239 (4137) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 10:28:19 -0000 --047d7bfea2c8683b410506006765 Content-Type: text/plain; charset=UTF-8 A few use cases: 1) CDNs, as Mark says. CDNs are typically used on a per hostname basis. Within one host we will distribute truly static assets (majority) and pass though assets that are dynamic (minority 1) or vary by other logic e.g. Geo Location (minority 2). This minority use cases do not preclude using CDNs, nor there benefits for Geographical reach on the global scale, but they do present a problem of no standardised way to return 'trusted' geo location data. Moving to SSL is orthogonal to this, as the termination point would either be the CDN (still no standard trusted method) or if changing the hostname to something locally terminated would lose the benefit of employing the CDN services for global optimisation. 2) Third party proxies In the first use case, we can expect the CSP to have a very close working relationship, customer/supplier. This makes something 'bespoke' a little easier. However in this relationship, third party organisations with no commercial relationship with the CSP, but a relationship with the client wish to broker this data on the clients behalf without diminishing the client experience. Examples of this are Googles Mobile Android proxy and Opera Mobile proxies. In this scenario, the CSP requires to protect the user experience and also any potential rights concerns using Geo data. The client and the third party proxy wish to, cache, transform, switch protocols etc etc. in a separate relationship for the benefit of the client. As it stands, SSL is typically used to bypass these, but it would be feasible that a non-commercial relationship could be brokered to protect the integrity of the client IP data where the risk was considered acceptable. 3) Multi-tiered distribution platforms Many commercial load balancers, random Apache modules, nginx etc. all mark up this data today. All default to XFF, custom headers or are configurable, none validate the headers added by default. A standard approach to this would just aid interoperability and stop everyone solving the same problems over and over. _sorry drowning in BAU at the moment_ CraigT On 22 October 2014 04:32, Mark Nottingham wrote: > > > On 22 Oct 2014, at 12:54 pm, Martin Nilsson wrote: > > > > On Wed, 22 Oct 2014 02:57:28 +0200, Mark Nottingham > wrote: > > > >> > >> I always thought that a sig mechanism was necessary for Forwarded (a > few of my employers have done that as a one-off); however, we probably > weren't ready to do it back then. > >> > >> Anyone want to pick up the ball? :) > >> > > > > What is the actual use case though? > > > > If you don't trust the IP number as an identifier of a third party, you > should use TLS. I can see that you would want to substitute identification > of third parties through IP with signatures as an abstraction for practical > reasons. > > > > I assume that providing integrity isn't the point (again, if you think > someone is tampering with the content without affecting the IP endpoints, > you need TLS). There is also the case where headers are set by a trusted > third party that then passes an untrusted (non-transparent) party, but I > can't think of when that would that happen? > > It's useful to have integrity / authentication for this info within your > own infrastructure. True, you could do this with client certs on the TLS > hop, but lots of software doesn't support that (and AIUI won't easily; > think proxies, etc). It's also useful to have a spec so that middleware > authors have something to shoot for; think load balancers, CDNs, etc. > Persisting the information is also a good thing, but there's not yet any > stadard way to do that in a HTTP message for TLS certs. > > The other way you could go about this is having a generic mechanism for > signing headers full stop -- many have discussed that (and still are). > However, in this use case, you need to sign just one header value (amongst > potentially many) that represents a hop; most of the mechanisms I've seen > don't have that kind of granularity. > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --047d7bfea2c8683b410506006765 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A few use cases:

1) CDNs, as Mark says.= CDNs are typically used on a per hostname basis. Within one host we will d= istribute truly static assets (majority) and pass though assets that are dy= namic (minority 1) or vary by other logic e.g. Geo Location (minority 2). T= his minority use cases do not preclude using CDNs, nor there benefits for G= eographical reach on the global scale, but they do present a problem of no = standardised way to return 'trusted' geo location data. Moving to S= SL is orthogonal to this, as the termination point would either be the CDN = (still no standard trusted method) or if changing the hostname to something= locally terminated would lose the benefit of employing the CDN services fo= r global optimisation.

2) Third party proxies
In the first use case, we can expect the CSP to have a very close wor= king relationship, customer/supplier. This makes something 'bespoke'= ; a little easier. However in this relationship, third party organisations = with no commercial relationship with the CSP, but a relationship with the c= lient wish to broker this data on the clients behalf without diminishing th= e client experience. Examples of this are Googles Mobile Android proxy and = Opera Mobile proxies. In this scenario, the CSP requires to protect the use= r experience and also any potential rights concerns using Geo data. The cli= ent and the third party proxy wish to, cache, transform, switch protocols e= tc etc. in a separate relationship for the benefit of the client. As it sta= nds, SSL is typically used to bypass these, but it would be feasible that a= non-commercial relationship could be brokered to protect the integrity of = the client IP data where the risk was considered acceptable.

=
3) Multi-tiered distribution platforms
Many commercial= load balancers, random Apache modules, nginx etc. all mark up this data to= day. All default to XFF, custom headers or are configurable, none validate = the headers added by default. A standard approach to this would just aid in= teroperability and stop everyone solving the same problems over and over.

_sorry drowning in BAU at the moment_
CraigT

On 22 October 2014 04:32, Mark Nottingham &l= t;mnot@mnot.net><= /span> wrote:

> On 22 Oct 2014, at 12:54 pm, Martin Nilsson <nilsson@opera.com> wrote:
>
> On Wed, 22 Oct 2014 02:57:28 +0200, Mark Nottingham <mnot@mnot.net> wrote:
>
>>
>> I always thought that a sig mechanism was necessary for Forwarded = (a few of my employers have done that as a one-off); however, we probably w= eren't ready to do it back then.
>>
>> Anyone want to pick up the ball? :)
>>
>
> What is the actual use case though?
>
> If you don't trust the IP number as an identifier of a third party= , you should use TLS. I can see that you would want to substitute identific= ation of third parties through IP with signatures as an abstraction for pra= ctical reasons.
>
> I assume that providing integrity isn't the point (again, if you t= hink someone is tampering with the content without affecting the IP endpoin= ts, you need TLS). There is also the case where headers are set by a truste= d third party that then passes an untrusted (non-transparent) party, but I = can't think of when that would that happen?

It's useful to have integrity / authentication for this info wit= hin your own infrastructure. True, you could do this with client certs on t= he TLS hop, but lots of software doesn't support that (and AIUI won'= ;t easily; think proxies, etc). It's also useful to have a spec so that= middleware authors have something to shoot for; think load balancers, CDNs= , etc. Persisting the information is also a good thing, but there's not= yet any stadard way to do that in a HTTP message for TLS certs.

The other way you could go about this is having a generic mechanism for sig= ning headers full stop -- many have discussed that (and still are). However= , in this use case, you need to sign just one header value (amongst potenti= ally many) that represents a hop; most of the mechanisms I've seen don&= #39;t have that kind of granularity.

Cheers,

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

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

--047d7bfea2c8683b410506006765-- From nobody Wed Oct 22 03:38:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E651A9030 for ; Wed, 22 Oct 2014 03:38:13 -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, HTML_MESSAGE=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 HkGDE7R2LdpH for ; Wed, 22 Oct 2014 03:38:10 -0700 (PDT) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF811A8AFB for ; Wed, 22 Oct 2014 03:38:10 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id lj1so3459765pab.10 for ; Wed, 22 Oct 2014 03:38:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=xeXym3D5mS6yY7DKbMMTVM5TsTk5RBFCBHa8+AGGRLs=; b=FITvUBsQ+5Y7uG2R/JiOTxmYgKiUW4T6V9y/M4F8rF4uyJF9Xl3jJ9/3svc95RvijP ZNBFhEa6pG35FwDBpmgnTZ5S7gq28bY/OHyRshbq6QS17rJAN2N3KFRZjCDqxe1gjfCL J6z6n0piSvp/c2yG8ssySxaIkfsh1+PvGJcRZ20IQgtcrKjbgyBTrqay5IlqnRKLoUHM 5gAB2aQVOPakDLZKbLuk7vWSj8WWUcC7o3ZiqWdGXH3lQSZa5YtinJHqgyOUQjvOIUVt mPmDrVnLUi020V+gK/z3eKQTfUcFd5KxxQaz77Gp7TOunipZWX6O1ykhHKSs0nz58kAv RvzA== X-Gm-Message-State: ALoCoQl4OaxEsVAw1+8i/CjHm11OMt8cF0sLjlNaGyznu+BIwU4MQr+8tKcHJOZcZcWcmYHCHDc6 MIME-Version: 1.0 X-Received: by 10.70.118.138 with SMTP id km10mr41496358pdb.65.1413974289841; Wed, 22 Oct 2014 03:38:09 -0700 (PDT) Received: by 10.66.97.36 with HTTP; Wed, 22 Oct 2014 03:38:09 -0700 (PDT) X-Originating-IP: [132.185.151.35] Date: Wed, 22 Oct 2014 11:38:09 +0100 Message-ID: From: "c^" To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=001a1132edb6449e2d0506008b9b Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/BMoVdAA95_kiTptFEuinNCUs74M Subject: [apps-discuss] XFF/Forward header signing X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 10:38:13 -0000 --001a1132edb6449e2d0506008b9b Content-Type: text/plain; charset=UTF-8 _subject move_ ---------- Forwarded message ---------- From: c^ Date: 22 October 2014 11:28 Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7239 (4137) To: Mark Nottingham Cc: Martin Nilsson , apps-discuss@ietf.org A few use cases: 1) CDNs, as Mark says. CDNs are typically used on a per hostname basis. Within one host we will distribute truly static assets (majority) and pass though assets that are dynamic (minority 1) or vary by other logic e.g. Geo Location (minority 2). This minority use cases do not preclude using CDNs, nor there benefits for Geographical reach on the global scale, but they do present a problem of no standardised way to return 'trusted' geo location data. Moving to SSL is orthogonal to this, as the termination point would either be the CDN (still no standard trusted method) or if changing the hostname to something locally terminated would lose the benefit of employing the CDN services for global optimisation. 2) Third party proxies In the first use case, we can expect the CSP to have a very close working relationship, customer/supplier. This makes something 'bespoke' a little easier. However in this relationship, third party organisations with no commercial relationship with the CSP, but a relationship with the client wish to broker this data on the clients behalf without diminishing the client experience. Examples of this are Googles Mobile Android proxy and Opera Mobile proxies. In this scenario, the CSP requires to protect the user experience and also any potential rights concerns using Geo data. The client and the third party proxy wish to, cache, transform, switch protocols etc etc. in a separate relationship for the benefit of the client. As it stands, SSL is typically used to bypass these, but it would be feasible that a non-commercial relationship could be brokered to protect the integrity of the client IP data where the risk was considered acceptable. 3) Multi-tiered distribution platforms Many commercial load balancers, random Apache modules, nginx etc. all mark up this data today. All default to XFF, custom headers or are configurable, none validate the headers added by default. A standard approach to this would just aid interoperability and stop everyone solving the same problems over and over. _sorry drowning in BAU at the moment_ CraigT On 22 October 2014 04:32, Mark Nottingham wrote: > > > On 22 Oct 2014, at 12:54 pm, Martin Nilsson wrote: > > > > On Wed, 22 Oct 2014 02:57:28 +0200, Mark Nottingham > wrote: > > > >> > >> I always thought that a sig mechanism was necessary for Forwarded (a > few of my employers have done that as a one-off); however, we probably > weren't ready to do it back then. > >> > >> Anyone want to pick up the ball? :) > >> > > > > What is the actual use case though? > > > > If you don't trust the IP number as an identifier of a third party, you > should use TLS. I can see that you would want to substitute identification > of third parties through IP with signatures as an abstraction for practical > reasons. > > > > I assume that providing integrity isn't the point (again, if you think > someone is tampering with the content without affecting the IP endpoints, > you need TLS). There is also the case where headers are set by a trusted > third party that then passes an untrusted (non-transparent) party, but I > can't think of when that would that happen? > > It's useful to have integrity / authentication for this info within your > own infrastructure. True, you could do this with client certs on the TLS > hop, but lots of software doesn't support that (and AIUI won't easily; > think proxies, etc). It's also useful to have a spec so that middleware > authors have something to shoot for; think load balancers, CDNs, etc. > Persisting the information is also a good thing, but there's not yet any > stadard way to do that in a HTTP message for TLS certs. > > The other way you could go about this is having a generic mechanism for > signing headers full stop -- many have discussed that (and still are). > However, in this use case, you need to sign just one header value (amongst > potentially many) that represents a hop; most of the mechanisms I've seen > don't have that kind of granularity. > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a1132edb6449e2d0506008b9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
_subject move_

--= -------- Forwarded message ----------
From: c^ <c@gryning.c= om>
Date: 22 October 2014 11:28
Subject: Re: [apps-disc= uss] [Technical Errata Reported] RFC7239 (4137)
To: Mark Nottingham <= mnot@mnot.net>
Cc: Martin Nilsso= n <nilsson@opera.com>, apps-discuss@ietf.org


A few use cases:

1) CDNs, as Mark says. C= DNs are typically used on a per hostname basis. Within one host we will dis= tribute truly static assets (majority) and pass though assets that are dyna= mic (minority 1) or vary by other logic e.g. Geo Location (minority 2). Thi= s minority use cases do not preclude using CDNs, nor there benefits for Geo= graphical reach on the global scale, but they do present a problem of no st= andardised way to return 'trusted' geo location data. Moving to SSL= is orthogonal to this, as the termination point would either be the CDN (s= till no standard trusted method) or if changing the hostname to something l= ocally terminated would lose the benefit of employing the CDN services for = global optimisation.

2) Third party proxies
<= div>In the first use case, we can expect the CSP to have a very close worki= ng relationship, customer/supplier. This makes something 'bespoke' = a little easier. However in this relationship, third party organisations wi= th no commercial relationship with the CSP, but a relationship with the cli= ent wish to broker this data on the clients behalf without diminishing the = client experience. Examples of this are Googles Mobile Android proxy and Op= era Mobile proxies. In this scenario, the CSP requires to protect the user = experience and also any potential rights concerns using Geo data. The clien= t and the third party proxy wish to, cache, transform, switch protocols etc= etc. in a separate relationship for the benefit of the client. As it stand= s, SSL is typically used to bypass these, but it would be feasible that a n= on-commercial relationship could be brokered to protect the integrity of th= e client IP data where the risk was considered acceptable.

3) Multi-tiered distribution platforms
Many commercial l= oad balancers, random Apache modules, nginx etc. all mark up this data toda= y. All default to XFF, custom headers or are configurable, none validate th= e headers added by default. A standard approach to this would just aid inte= roperability and stop everyone solving the same problems over and over.

_sorry drowning in BAU at the moment_

<= /div>
CraigT

On 22 October 2014 04:32= , Mark Nottingham <mnot@mnot.net> wrote:

> On 22 Oct 2014, at 12:54 pm, Martin Nilsson <nilsson@opera.com> wrote:
>
> On Wed, 22 Oct 2014 02:57:28 +0200, Mark Nottingham <mnot@mnot.net> wrote:
>
>>
>> I always thought that a sig mechanism was necessary for Forwarded = (a few of my employers have done that as a one-off); however, we probably w= eren't ready to do it back then.
>>
>> Anyone want to pick up the ball? :)
>>
>
> What is the actual use case though?
>
> If you don't trust the IP number as an identifier of a third party= , you should use TLS. I can see that you would want to substitute identific= ation of third parties through IP with signatures as an abstraction for pra= ctical reasons.
>
> I assume that providing integrity isn't the point (again, if you t= hink someone is tampering with the content without affecting the IP endpoin= ts, you need TLS). There is also the case where headers are set by a truste= d third party that then passes an untrusted (non-transparent) party, but I = can't think of when that would that happen?

It's useful to have integrity / authentication for this info wit= hin your own infrastructure. True, you could do this with client certs on t= he TLS hop, but lots of software doesn't support that (and AIUI won'= ;t easily; think proxies, etc). It's also useful to have a spec so that= middleware authors have something to shoot for; think load balancers, CDNs= , etc. Persisting the information is also a good thing, but there's not= yet any stadard way to do that in a HTTP message for TLS certs.

The other way you could go about this is having a generic mechanism for sig= ning headers full stop -- many have discussed that (and still are). However= , in this use case, you need to sign just one header value (amongst potenti= ally many) that represents a hop; most of the mechanisms I've seen don&= #39;t have that kind of granularity.

Cheers,

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

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


--001a1132edb6449e2d0506008b9b-- From nobody Wed Oct 22 05:51:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732021A90F4 for ; Wed, 22 Oct 2014 05:51:02 -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 VP6Iaa7uyvAK for ; Wed, 22 Oct 2014 05:51:00 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73CAB1A8AFE for ; Wed, 22 Oct 2014 05:51:00 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id hs14so2900217lab.3 for ; Wed, 22 Oct 2014 05:50:58 -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=DgV4ACkIwVRFmy5BpN91HxHMy3O8rABgEeE3DQUC3S0=; b=KcpqmaSkTwVgZf/FmCtWDpoeXZqYcW45OEdHsLfj8zT80p11i8fBiI3gCwZ3LIlqgt ZXpju3i9vrV8JxPnRiYN8TjBgSbB8DUxqFUZW2Czt2760GquDtLIGdw0g/in+JeSXh6y e9kPneuIst1+95xC5CZ+7pms207B4/QfDqTDFLjuMYN87u4H6VACxcyJnfKPsKrvJqlS 15pO8Ap/SrhFsr11p3JCifHd6JhIQlVUi71lB3RzsBT9Ecqi2uqqA8wzgzAE+QngmW3S xACHnmEMVyy6LLo/eYDQq6C6zU0Gn4yIbBPkfQ/0NtVEyJ7A+5Us0CuC34skbj0OIbIq /xNA== MIME-Version: 1.0 X-Received: by 10.152.87.98 with SMTP id w2mr40946676laz.27.1413982258590; Wed, 22 Oct 2014 05:50:58 -0700 (PDT) Received: by 10.112.166.7 with HTTP; Wed, 22 Oct 2014 05:50:58 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Oct 2014 07:50:58 -0500 Message-ID: From: Nat Sakimura To: Melvin Carvalho Content-Type: multipart/alternative; boundary=001a11c34bce3dfaa40506026608 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kiNcgkZHA-uot2EXgd5-Pempjj8 Cc: Apps Discuss Subject: Re: [apps-discuss] Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 12:51:02 -0000 --001a11c34bce3dfaa40506026608 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If it is OK, I would like to know more about your use case. Expressing a user as a HTTP URL was the first vision of OpenID, which proved to be a failure as users did not understand URL. I suppose your use case is not to have the user type it, but something else. Nat 2014-10-21 11:28 GMT-05:00 Melvin Carvalho : > > > On 21 October 2014 18:15, Dave Cridland wrote: > >> Do neither of acct: or webfinger apply here?=E2=80=8B >> > > 1. acct: potentially applies here potentially, but I'm trying to model a > user and not an account, and also I'd like to use an HTTP URL. So it's n= ot > an ideal fit, but I thought about it. > > 2. re: webfinger I would to return HTML, rather than XRD, if the URL is > dereferenced, so again not an ideal fit. It also doesnt tell me what val= ue > I should put in as the subject to .well0known/webfinger?, which is the > problem I'm trying to solve in the first place. > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c34bce3dfaa40506026608 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If it is OK, I would like to know more about your use case= .=C2=A0
Expressing a user as a HTTP URL was the first vision of OpenID,= which proved to be a failure as users did not understand URL.=C2=A0
<= div>I suppose your use case is not to have the user type it, but something = else.=C2=A0

Nat

2014-10-21 11:28 GMT-05:00 Melvin Carval= ho <melvincarvalho@gmail.com>:


On 21 October 2014 18:15, Dave Cridland = <dave@cridland.net> wrote:
Do neither of acct: or webfinger apply here?=E2=80=8B

1. acct: potentially applies here= potentially, but I'm trying to model a user and not an account, and al= so I'd like to use an HTTP URL.=C2=A0 So it's not an ideal fit, but= I thought about it.

2. re: webfinger I would to return H= TML, rather than XRD, if the URL is dereferenced, so again not an ideal fit= .=C2=A0 It also doesnt tell me what value I should put in as the subject to= .well0known/webfinger?, which is the problem I'm trying to solve in th= e first place.


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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a11c34bce3dfaa40506026608-- From nobody Wed Oct 22 06:30:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF921A9130 for ; Wed, 22 Oct 2014 06:30:05 -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 dMf9OfFqFqn2 for ; Wed, 22 Oct 2014 06:30:00 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9220D1A9143 for ; Wed, 22 Oct 2014 06:29:59 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id z12so2846506lbi.30 for ; Wed, 22 Oct 2014 06:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6g05571W+Sl0Asxmqmzxr7Uwx877OEu+OBNA67e+MIE=; b=MgUCDxbMsXnANK+mfzpME6wIYKwNI5uLdwklu6rDiRebG72qX9Z+nvRlT8vI/JQ6Qg bInF0sOzjTyAmWQvnuVs792mSiK9fsAwzXDxIwy7dv//4b6rdgAAFuCNqUDRi2dCiOMy 2BWM7qi7H1bufW4paBKfe1Hy2v2u/MJQxkbbGdgPlXDALsYz2QRJAWiEaW3DiHvEdr7M T6mi4P54vhf1JW5qUm+y3UYfeeWIAH3mGjVmRiQm/WhTjbxGyiSC2WMrH7VtyvvX2yTj pPuOhnHvj3ZDXTqdmQ1Ed3i+MVneOs/rCA4Qeeh9jZpcCvog4y/Q3slSDSYv8AHUlQds 7s/A== MIME-Version: 1.0 X-Received: by 10.112.198.226 with SMTP id jf2mr23482822lbc.84.1413984597416; Wed, 22 Oct 2014 06:29:57 -0700 (PDT) Received: by 10.112.1.234 with HTTP; Wed, 22 Oct 2014 06:29:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Oct 2014 15:29:57 +0200 Message-ID: From: Melvin Carvalho To: Nat Sakimura Content-Type: multipart/alternative; boundary=001a11c341caa5a336050602f1ee Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/aDpsrH5mgCmTZHIv-hJRcloTOuw Cc: Apps Discuss Subject: Re: [apps-discuss] Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 13:30:05 -0000 --001a11c341caa5a336050602f1ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 22 October 2014 14:50, Nat Sakimura wrote: > If it is OK, I would like to know more about your use case. > Sure! I'm working on a linked data system called 'marking'. It's similar to a facebook 'like', an upvote, a +1 etc. The only difference is that not only do you gain a reputation point ( a mark ) but you can pass it on to other people. Creating a potential virtuous circle. When I want to mark someone of facebook at web scale, I know the URL to send the mark to. But I other systems it's less clear. Recently an exchange has implemented marking in their chat box, and I have access to the data which I would like to make searchable as a reputation graph. However the only data I have is the user name and the host, from that I need to construct a sensible HTTP URI, that could later be dereferencable (I hope!). > Expressing a user as a HTTP URL was the first vision of OpenID, which > proved to be a failure as users did not understand URL. > The jury is out on that one. I think you are referring to memorable login identifiers which is not my use case. Looking at my screen right now, I see a URL in the address bar of my browser. That's more like my use case. > I suppose your use case is not to have the user type it, but something > else. > Yes, exactly. Although I would not call that a use case, more a user interaction. > > Nat > > 2014-10-21 11:28 GMT-05:00 Melvin Carvalho : > >> >> >> On 21 October 2014 18:15, Dave Cridland wrote: >> >>> Do neither of acct: or webfinger apply here?=E2=80=8B >>> >> >> 1. acct: potentially applies here potentially, but I'm trying to model a >> user and not an account, and also I'd like to use an HTTP URL. So it's = not >> an ideal fit, but I thought about it. >> >> 2. re: webfinger I would to return HTML, rather than XRD, if the URL is >> dereferenced, so again not an ideal fit. It also doesnt tell me what va= lue >> I should put in as the subject to .well0known/webfinger?, which is the >> problem I'm trying to solve in the first place. >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > --001a11c341caa5a336050602f1ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 22 October 2014 14:50, Nat Sakimura <sakimura@gmail.com> wrote:
If it is OK,= I would like to know more about your use case.=C2=A0

Sure!

I'm working on a linked data system calle= d 'marking'.=C2=A0 It's similar to a facebook 'like', a= n upvote, a +1 etc.=C2=A0 The only difference is that not only do you gain = a reputation point ( a mark ) but you can pass it on to other people.=C2=A0= Creating a potential virtuous circle.

When I want to mar= k someone of facebook at web scale, I know the URL to send the mark to.=C2= =A0 But I other systems it's less clear.=C2=A0

Recently an exch= ange has implemented marking in their chat box, and I have access to the da= ta which I would like to make searchable as a reputation graph.=C2=A0
<= br>
However the only data I have is the user name and the host, f= rom that I need to construct a sensible HTTP URI, that could later be deref= erencable (I hope!).=C2=A0
=C2=A0
Expressing a user as a HTTP URL was the fir= st vision of OpenID, which proved to be a failure as users did not understa= nd URL.=C2=A0

The jury is out o= n that one.=C2=A0 I think you are referring to memorable login identifiers = which is not my use case.=C2=A0 Looking at my screen right now, I see a URL= in the address bar of my browser.=C2=A0 That's more like my use case.<= br>
=C2=A0
<= div>I suppose your use case is not to have the user type it, but something = else.=C2=A0

Yes, exactly.=C2=A0= Although I would not call that a use case, more a user interaction.
=C2=A0
Nat

2014-10-21 11:28 GMT-05:00 Melvin Carvalho <= ;melvincarval= ho@gmail.com>:


On 21 October 2014 18:15, Dave Cridland <dave@cridl= and.net> wrote:
Do neither of acct: or webfinger apply here?=E2=80=8B

1. acct: potentially applies here potentially= , but I'm trying to model a user and not an account, and also I'd l= ike to use an HTTP URL.=C2=A0 So it's not an ideal fit, but I thought a= bout it.

2. re: webfinger I would to return HTML, rather = than XRD, if the URL is dereferenced, so again not an ideal fit.=C2=A0 It a= lso doesnt tell me what value I should put in as the subject to .well0known= /webfinger?, which is the problem I'm trying to solve in the first plac= e.


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


<= br clear=3D"all">

--
Nat Sakimura (=3Dnat)
Chairman, = OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--001a11c341caa5a336050602f1ee-- From nobody Wed Oct 22 11:15:20 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D0A1AC3A8; Wed, 22 Oct 2014 06:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 0fa_JKsXSjWe; Wed, 22 Oct 2014 06:55:43 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 3385D1AC3AE; Wed, 22 Oct 2014 06:55:42 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id E323F21378A; Wed, 22 Oct 2014 09:55:41 -0400 (EDT) Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 361B521378F; Wed, 22 Oct 2014 09:55:41 -0400 (EDT) Received: from CHACAS02.corp.arin.net (10.1.30.108) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 22 Oct 2014 09:57:34 -0400 Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS02.corp.arin.net ([fe80::54ae:f9de:2f8b:1072%12]) with mapi id 14.03.0181.006; Wed, 22 Oct 2014 09:55:40 -0400 From: Andy Newton To: Scott Hollenbeck Thread-Topic: [weirds] Applications Area Directorate Review of draft-ietf-weirds-rdap-sec-09 Thread-Index: AQHP7dOraLlEMb/T9k2LS8+NEgKgD5w8HmfwgABIuIA= Date: Wed, 22 Oct 2014 13:55:39 +0000 Message-ID: <2FC7374A-6DF3-49F8-9FDD-8E8ADDCAA15A@arin.net> References: <46A1DF3F04371240B504290A071B4DB63E779CE3@SZXEMA510-MBX.china.huawei.com> <831693C2CDA2E849A7D7A712B24E257F494F1417@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494F1417@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.87] Content-Type: multipart/alternative; boundary="_000_2FC7374A6DF349F89FDD8E8ADDCAA15Aarinnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/VR-roEumjX5m5s5S8ajOTBhQ_zY X-Mailman-Approved-At: Wed, 22 Oct 2014 11:15:10 -0700 Cc: "draft-ietf-weirds-rdap-sec.all@tools.ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" , "weirds@ietf.org" Subject: Re: [apps-discuss] [weirds] Applications Area Directorate Review of draft-ietf-weirds-rdap-sec-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 13:55:47 -0000 --_000_2FC7374A6DF349F89FDD8E8ADDCAA15Aarinnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 22, 2014, at 9:46 AM, Hollenbeck, Scott > wrote: n1) 3.3, it would be nice to replace "a 429 response code" by "a 429 (Too many Requests) response code". Thanks for the feedback, Bert. You're probably right, but since this is a n= it I'd prefer to leave the text as-is to maintain consistency with other RD= AP documents that describe HTTP response codes without using parenthetical = text to describe the meaning of the code. We have normative references in t= he appropriate places to do that. Scott, Bert has made the same comment on using-http, so the parentheticals will ap= pear in our other documents. I view it as a readability thing, not necessar= ily a normative reference issue. -andy --_000_2FC7374A6DF349F89FDD8E8ADDCAA15Aarinnet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Oct 22, 2014, at 9:46 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

n1) 3.3, it would be nice to replace "a 429 response code" by &qu= ot;a 429
(Too many Requests) response code".

Thanks for the feedback, Bert. You're probably right, but since this is a nit I'd= prefer to leave the text as-is to maintain consistency with other RDAP doc= uments that describe HTTP response codes without using parenthetical text t= o describe the meaning of the code. We have normative references in the appropriate places to do that.<= br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fo= nt-variant: normal; font-weight: normal; letter-spacing: normal; line-heigh= t: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfo= rm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tex= t-stroke-width: 0px;">

Scott,

Bert has made the same comment on using-http, so the parentheticals wi= ll appear in our other documents. I view it as a readability thing, not nec= essarily a normative reference issue.

-andy
--_000_2FC7374A6DF349F89FDD8E8ADDCAA15Aarinnet_-- From nobody Wed Oct 22 11:15:27 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DF51ABD35; Wed, 22 Oct 2014 06:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Da969gCBYMWU; Wed, 22 Oct 2014 06:47:11 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98AB11A9239; Wed, 22 Oct 2014 06:46:59 -0700 (PDT) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKVEe1UshHzT37Nzqqy4cmLAErYs8vX44D@postini.com; Wed, 22 Oct 2014 06:47:10 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id s9MDkvrU029266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 09:46:57 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 22 Oct 2014 09:46:57 -0400 From: "Hollenbeck, Scott" To: Bert Greevenbosch , "draft-ietf-weirds-rdap-sec.all@tools.ietf.org" , "'iesg@ietf.org'" <'iesg@ietf.org'>, "apps-discuss@ietf.org" Thread-Topic: Applications Area Directorate Review of draft-ietf-weirds-rdap-sec-09 Thread-Index: AQHP7dOraLlEMb/T9k2LS8+NEgKgD5w8Hmfw Date: Wed, 22 Oct 2014 13:46:56 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494F1417@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <46A1DF3F04371240B504290A071B4DB63E779CE3@SZXEMA510-MBX.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63E779CE3@SZXEMA510-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/u8oEfuFpXboot04zLKInPgxC3ZU X-Mailman-Approved-At: Wed, 22 Oct 2014 11:15:13 -0700 Cc: "weirds@ietf.org" Subject: Re: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-rdap-sec-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 13:47:12 -0000 > -----Original Message----- > From: Bert Greevenbosch [mailto:Bert.Greevenbosch@huawei.com] > Sent: Wednesday, October 22, 2014 4:39 AM > To: draft-ietf-weirds-rdap-sec.all@tools.ietf.org; 'iesg@ietf.org'; > apps-discuss@ietf.org > Subject: Applications Area Directorate Review of draft-ietf-weirds- > rdap-sec-09 >=20 > Document: draft-ietf-weirds-rdap-sec-09 > Title: Finding the Authoritative Registration Data (RDAP) Service > Reviewer: Bert Greevenbosch > Review Date: 22 October 2014 > IETF Last Call Date: 24 October 2014 > IESG Telechat Date: 30 October 2014 > Summary: May need an edit. >=20 > Major Issues: >=20 > None >=20 > Minor Issues: >=20 > None >=20 > Nits: >=20 > (n1) 3.3, it would be nice to replace "a 429 response code" by "a 429 > (Too many Requests) response code". Thanks for the feedback, Bert. You're probably right, but since this is a n= it I'd prefer to leave the text as-is to maintain consistency with other RD= AP documents that describe HTTP response codes without using parenthetical = text to describe the meaning of the code. We have normative references in t= he appropriate places to do that. Scott From nobody Wed Oct 22 11:15:28 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866381AC3B5; Wed, 22 Oct 2014 07:03:31 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 h66DrwAPHwrH; Wed, 22 Oct 2014 07:03:29 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70FF91AC3B0; Wed, 22 Oct 2014 07:03:23 -0700 (PDT) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKVEe5K1vcFP4MZkY0iekkMXbYos4mdqyD@postini.com; Wed, 22 Oct 2014 07:03:29 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id s9ME34Ja018825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 10:03:04 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 22 Oct 2014 10:03:04 -0400 From: "Hollenbeck, Scott" To: Andy Newton Thread-Topic: [weirds] Applications Area Directorate Review of draft-ietf-weirds-rdap-sec-09 Thread-Index: AQHP7dOraLlEMb/T9k2LS8+NEgKgD5w8HmfwgABIuID//76wkA== Date: Wed, 22 Oct 2014 14:03:03 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494F1506@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <46A1DF3F04371240B504290A071B4DB63E779CE3@SZXEMA510-MBX.china.huawei.com> <831693C2CDA2E849A7D7A712B24E257F494F1417@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <2FC7374A-6DF3-49F8-9FDD-8E8ADDCAA15A@arin.net> In-Reply-To: <2FC7374A-6DF3-49F8-9FDD-8E8ADDCAA15A@arin.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F494F1506BRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ywr43fbVhtK-0q5v0yjc6GqRjYY X-Mailman-Approved-At: Wed, 22 Oct 2014 11:15:14 -0700 Cc: "draft-ietf-weirds-rdap-sec.all@tools.ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" , "weirds@ietf.org" Subject: Re: [apps-discuss] [weirds] Applications Area Directorate Review of draft-ietf-weirds-rdap-sec-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 14:03:32 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F494F1506BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Andy Newton [mailto:andy@arin.net] Sent: Wednesday, October 22, 2014 9:56 AM To: Hollenbeck, Scott Cc: Bert Greevenbosch; draft-ietf-weirds-rdap-sec.all@tools.ietf.org; iesg@= ietf.org; apps-discuss@ietf.org; weirds@ietf.org Subject: Re: [weirds] Applications Area Directorate Review of draft-ietf-we= irds-rdap-sec-09 On Oct 22, 2014, at 9:46 AM, Hollenbeck, Scott > wrote: n1) 3.3, it would be nice to replace "a 429 response code" by "a 429 (Too many Requests) response code". Thanks for the feedback, Bert. You're probably right, but since this is a n= it I'd prefer to leave the text as-is to maintain consistency with other RD= AP documents that describe HTTP response codes without using parenthetical = text to describe the meaning of the code. We have normative references in t= he appropriate places to do that. Scott, Bert has made the same comment on using-http, so the parentheticals will ap= pear in our other documents. I view it as a readability thing, not necessar= ily a normative reference issue. [SAH] OK, well, if the other documents are going to change we should make t= he same change in rdap-sec. Scott --_000_831693C2CDA2E849A7D7A712B24E257F494F1506BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From: Andy New= ton [mailto:andy@arin.net]
Sent: Wednesday, October 22, 2014 9:56 AM
To: Hollenbeck, Scott
Cc: Bert Greevenbosch; draft-ietf-weirds-rdap-sec.all@tools.ietf.org= ; iesg@ietf.org; apps-discuss@ietf.org; weirds@ietf.org
Subject: Re: [weirds] Applications Area Directorate Review of draft-= ietf-weirds-rdap-sec-09

 

 

On Oct 22, 2014, at 9:46 AM, Hollenbeck, Scott <<= a href=3D"mailto:shollenbeck@verisign.com">shollenbeck@verisign.com>= wrote:



n1) 3.3, it would be nice to replace &= quot;a 429 response code" by "a 429
(Too many Requests) response code".


Thanks for the feedback, Bert. You're probably right, but since this is a n= it I'd prefer to leave the text as-is to maintain consistency with other RD= AP documents that describe HTTP response codes without using parenthetical = text to describe the meaning of the code. We have normative references in the appropriate places to do tha= t.

 

Scott,

 

Bert has made the same comment on using-http, so the= parentheticals will appear in our other documents. I view it as a readabil= ity thing, not necessarily a normative reference issue.

 

[SAH] OK, well, if the other documents are going to change we sh= ould make the same change in rdap-sec.

 

Scott

--_000_831693C2CDA2E849A7D7A712B24E257F494F1506BRN1WNEXMBX01vc_-- From nobody Wed Oct 22 11:50:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6057B1ACEF4 for ; Wed, 22 Oct 2014 11:50:03 -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 WoU-uuF1erdG for ; Wed, 22 Oct 2014 11:50:02 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4110E1A87BB for ; Wed, 22 Oct 2014 11:50:02 -0700 (PDT) Received: by mail-oi0-f53.google.com with SMTP id v63so3200639oia.40 for ; Wed, 22 Oct 2014 11:50:01 -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 :content-type; bh=Xe1/y8PG1E8KAbjMjIy5AVJQkyKw36whv3VpSQuOwvw=; b=iDQ8BjwAIkmBwt6ESNMU4BHsNYikFr0U3T3ZkZ/GY8TkHmfzrE6vixkith4cCAGzIq 50dQWt42AaAjDSUqPJFegMF1/mSF8dSURAooVlskgNKNR86+bgL69BelbaOYdsHzaFaq pCzJHXGuXuygEAOfYIVttikA7CchjSBFUKwj0= 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:content-type; bh=Xe1/y8PG1E8KAbjMjIy5AVJQkyKw36whv3VpSQuOwvw=; b=QL+sTTiWzu2lYS52bt+f3nBTbW9EE99iS2kP2NeG6hrMaX8Lhw2CxMTfZ0kdg9PTk0 +f6mlonuxOuL6oTOHej51rGBaLhzSITuKbp5ummEp6m2Z5WT4QB8DlRCr2SVeXGWFi6P Eq/4yFzIDP5PQP3JgQwHLE43KalS/L/CniPv9ImORSriDRShz0MGG3G8fOBd08AIU+XA svED+XZKN9MaDoJY8cys7xCe3Vje5PznULoafdUUMR/gIbg6v5rJVBSrojOujTjEd9FQ rpLLdoQTjcEdcT65gCxD0WQ+5ba8cKqwWhi7PTxlPpEQ6eDjbHacQPrJcpSfrnDx0+o0 0oAg== X-Gm-Message-State: ALoCoQkBRVSCdGy834vE8bgllot7HyRP3hR69AUvdoYdKxRa7kHSgjt9tG+HD6jRTv4jXM/mov9Q MIME-Version: 1.0 X-Received: by 10.182.149.162 with SMTP id ub2mr231689obb.86.1414003801645; Wed, 22 Oct 2014 11:50:01 -0700 (PDT) Received: by 10.60.150.238 with HTTP; Wed, 22 Oct 2014 11:50:01 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Oct 2014 19:50:01 +0100 Message-ID: From: Dave Cridland To: "apps-discuss@ietf.org" Content-Type: multipart/alternative; boundary=001a113489104efbe90506076ae7 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/uh9pmfHxPRlViAEo3UVX9eF3pVA Subject: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 18:50:03 -0000 --001a113489104efbe90506076ae7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hit the wrong reply - this should have gone to the list. On 21 October 2014 17:28, Melvin Carvalho wrote: > > > On 21 October 2014 18:15, Dave Cridland wrote: > >> Do neither of acct: or webfinger apply here?=E2=80=8B >> > > 1. acct: potentially applies here potentially, but I'm trying to model a > user and not an account, and also I'd like to use an HTTP URL. So it's n= ot > an ideal fit, but I thought about it. > > 2. re: webfinger I would to return HTML, rather than XRD, if the URL is > dereferenced, so again not an ideal fit. It also doesnt tell me what val= ue > I should put in as the subject to .well0known/webfinger?, which is the > problem I'm trying to solve in the first place. > > Well, surely you start with acct:, which has the easy-to-understand form of user@domain, and hand that to WebFinger to resolve to XRD, which in turn gives you (via a link type you define) the HTML you want. As for the HTML you want, you're not really describing that so I'm a bit stumped. --001a113489104efbe90506076ae7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hit the wrong reply - this should have = gone to the list.

On 21 October 2014 17:28, Melvin Carvalho <melvincarvalho@gma= il.com> wrote:


On= 21 October 2014 18:15, Dave Cridland <dave@cridland.net> wr= ote:
Do neither of acct:= or webfinger apply here?=E2=80=8B

=
1. acct: potentially applies here potentially, but I'm trying to m= odel a user and not an account, and also I'd like to use an HTTP URL.= =C2=A0 So it's not an ideal fit, but I thought about it.

<= div>2. re: webfinger I would to return HTML, rather than XRD, if the URL is= dereferenced, so again not an ideal fit.=C2=A0 It also doesnt tell me what= value I should put in as the subject to .well0known/webfinger?, which is t= he problem I'm trying to solve in the first place.

<= /div>

Well, s= urely you start with acct:, which has the easy-to-understand form of user@d= omain, and hand that to WebFinger to resolve to XRD, which in turn gives yo= u (via a link type you define) the HTML you want.

As for the HTML you want, you&#= 39;re not really describing that so I'm a bit stumped.

--001a113489104efbe90506076ae7-- From nobody Wed Oct 22 12:16:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097761AD289 for ; Wed, 22 Oct 2014 12:16: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 cxg7i7Mmmj1z for ; Wed, 22 Oct 2014 12:16:05 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6CD1AD061 for ; Wed, 22 Oct 2014 12:15:22 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id ge10so3538274lab.38 for ; Wed, 22 Oct 2014 12:15:15 -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=w5jHxSI8ItC5fNBvU4eYyY20TR7Hwgu0aBvPvxfFkkw=; b=SPlUYQgJN4y/L4eXa5fFt5EEXDN+QB1ZNGpJqFwJOrQMcFF2vWhiPvg9jnCc/8h1sj 0zSdnrFrDPXNJ4F4m430eBOQV6wAIwza6TDZg8WgfCHAkACq/ErrpkfqjuyQ1ovinHvo 1Jrw2nvg/1D6ObhaLYq03j93WnZ8bd/SRyjgmOVsqButmO4CUv3S2Ze//EN7VFcDOM/8 BiRjCzg/ZjmMjWEN+yAJp1TpGzPpZALVIJwI6cELVp2Yf7xiwDhg33uAJ4alRLx1ja1b AaMPkEmr1kTgmLzYp5/nCtvbDgj0BUHoEGazDJ8bi76pZlvYHAsh+jKuMSQiY2EdU0Y2 2G6A== MIME-Version: 1.0 X-Received: by 10.153.4.7 with SMTP id ca7mr46870lad.31.1414005315764; Wed, 22 Oct 2014 12:15:15 -0700 (PDT) Received: by 10.112.1.234 with HTTP; Wed, 22 Oct 2014 12:15:15 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Oct 2014 21:15:15 +0200 Message-ID: From: Melvin Carvalho To: Dave Cridland Content-Type: multipart/alternative; boundary=001a113447c88e85c4050607c48d Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XoEH_1CNiY4SWWTcv3Y9CXT8V2o Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 19:16:13 -0000 --001a113447c88e85c4050607c48d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 22 October 2014 20:50, Dave Cridland wrote: > Hit the wrong reply - this should have gone to the list. > > On 21 October 2014 17:28, Melvin Carvalho > wrote: > >> >> >> On 21 October 2014 18:15, Dave Cridland wrote: >> >>> Do neither of acct: or webfinger apply here?=E2=80=8B >>> >> >> 1. acct: potentially applies here potentially, but I'm trying to model a >> user and not an account, and also I'd like to use an HTTP URL. So it's = not >> an ideal fit, but I thought about it. >> >> 2. re: webfinger I would to return HTML, rather than XRD, if the URL is >> dereferenced, so again not an ideal fit. It also doesnt tell me what va= lue >> I should put in as the subject to .well0known/webfinger?, which is the >> problem I'm trying to solve in the first place. >> >> > Well, surely you start with acct:, which has the easy-to-understand form > of user@domain, and hand that to WebFinger to resolve to XRD, which in > turn gives you (via a link type you define) the HTML you want. > > As for the HTML you want, you're not really describing that so I'm a bit > stumped. > No, acct: wont work here. Let me explain: 1. I am modelling a user and NOT an account, so this would be a misuse of the term. For my use case there is a very important distinction here, just as a bank account is not the same as a bank user. 2. Even if acct: could be reused (it cant imho), I am looking for a well known HTTP URI that denotes a user. Why HTTP? Because that's the protocol of the web, and everything talks it. I've had the following suggestions: - http://user@host/ -- this passes the RFC and would be perfect, but guess what? Browsers fail on it. Snowball's chance in hell getting the WHATWG folks to fix it, imho. - http://host/@user -- seems OK, but can you get people to agree, I doubt i= t - http://host/@/user -- seems OK, but can you get people to agree, I doubt it - http://host/~user -- seems OK, but can you get people to agree, I doubt it All that remains is the /well-known/ pattern. It's already established that well-known is used when all else fails, and has sub directories. .well-known/user/mark Well what else could it mean? I think it's about as unambiguous as it gets, no room for collisions. It also gives me and other implementations a standard way to construct an identifer and introspect on one. If there's a better way I'd love to hear. Absent of that, my question is: should I draft a registration template or not? > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --001a113447c88e85c4050607c48d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 22 October 2014 20:50, Dave Cridland <dave@cridland.net> wrote:
Hit the wrong reply - this should have gone to the list.

On 21 October 2014 17:28, Melvin Carvalho <<= a href=3D"mailto:melvincarvalho@gmail.com" target=3D"_blank">melvincarvalho= @gmail.com> wrote:


On 21 October 2014 18:15, Dave Cridland <dave@cridl= and.net> wrote:
Do neither of acct: or webfinger apply here?=E2=80= =8B

1. acct: potentially appli= es here potentially, but I'm trying to model a user and not an account,= and also I'd like to use an HTTP URL.=C2=A0 So it's not an ideal f= it, but I thought about it.

2. re: webfinger I would to r= eturn HTML, rather than XRD, if the URL is dereferenced, so again not an id= eal fit.=C2=A0 It also doesnt tell me what value I should put in as the sub= ject to .well0known/webfinger?, which is the problem I'm trying to solv= e in the first place.


Well, surely you start with acct:, which has th= e easy-to-understand form of user@domain, and hand that to WebFinger to res= olve to XRD, which in turn gives you (via a link type you define) the HTML = you want.

As for the HTML you want, you're not really describing that so I= 9;m a bit stumped.

No, acct: wont work here.=C2=A0 Let me explain:

1. I=20 am modelling a user and NOT an account, so this would be a misuse of the term.=C2=A0 For my use case there is a very important distinction here, ju= st as a bank account is not the same as a bank user.

2.=20 Even if acct: could be reused (it cant imho), I am looking for a well=20 known HTTP URI that denotes a user.=C2=A0 Why HTTP?=C2=A0 Because that'= s the=20 protocol of the web, and everything talks it.=C2=A0

I= 9;ve had the following suggestions:

- http://user@host/ -- this passes the RFC and would be perfect, but=20 guess what?=C2=A0 Browsers fail on it.=C2=A0 Snowball's chance in hell = getting the WHATWG folks to fix it, imho.

- http://host/@user -- seems OK, but can you get = people to agree, I doubt it

- http://host/@/user -- seems OK, but can you get people = to agree, I doubt it

=C2=A0- http://host/~user -- seems OK, but can you = get people to agree, I doubt it

All that remains is the /= well-known/ pattern.

It's already established that we= ll-known is used when all else fails, and has sub directories.

.well-known/user/mark

Well what else could it mean?=C2=A0 I think it's about as unambiguous as it= gets, no room for collisions.=C2=A0 It also gives me and other implementations a= =20 standard way to construct an identifer and introspect on one.

=
If there's a better way I'd love to hear.

Absent = of that, my question is: should I draft a registration template or not?
= =C2=A0


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


--001a113447c88e85c4050607c48d-- From nobody Wed Oct 22 14:01:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0861A1B4B for ; Wed, 22 Oct 2014 14:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJ3Vz7h6LDxk for ; Wed, 22 Oct 2014 14:01:52 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4985B1A1B3B for ; Wed, 22 Oct 2014 14:01:52 -0700 (PDT) Received: by mail-oi0-f48.google.com with SMTP id g201so3413284oib.21 for ; Wed, 22 Oct 2014 14:01:51 -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=2QuJES/38UBqPmUsI+5uHa5g9kxhGlDSY3qtAyd4lYc=; b=CxvqNjWtIwtElJRQoisooFvKsUgRM6Vjvno55wOj4TH5ZT26C/jiSamdHt7MTiTwFj tVKhDzefirRJDVJCDAQddS/gxBmxbRZoi4ZJtToVrBsmKOTw5IE2SMk1CZt0gwjWPbtd H8AR/N9pOOEWwsvWY71ezU7xw4S/4/YUM24bE= 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=2QuJES/38UBqPmUsI+5uHa5g9kxhGlDSY3qtAyd4lYc=; b=OWqKVXg+nZ3deF6ngp7IFhsDEP7n8yGzo2L2utFOAQDcb0FC/w76jOg/2yRgaCbIT0 UFJVebei1gVZwopPDciXkpG2MoZltpclXodNFPCA6/NgWBb9tuuQUtjBvMGb7RsaQFAN Q3EKnv+z63r9rJYd9jnd8syrDoDtKtdZLuoJh9GcE7phuL2ZR5h9NIuNM8vHB3WP6Rb1 2Jne/1hV+jWfTCbKYFN5efUSsxh1P82e+fJwAW9A+0WpCyafMAMLeRXWh7mBYVe0aplL 8kLzDfIS+BLRBgHlNiWW7SUqFeAyHP9j8IOqRMwbe/qH1TDnlBPtggqfEeGNllouWnA2 CvFw== X-Gm-Message-State: ALoCoQncuW8I4sWhdQJuibusCnCCgBJI20N+tLX5IZVhlP87y0XTf8ZHd55e6gd9mUuzIM/StaSR MIME-Version: 1.0 X-Received: by 10.60.46.68 with SMTP id t4mr430876oem.33.1414011711568; Wed, 22 Oct 2014 14:01:51 -0700 (PDT) Received: by 10.60.150.238 with HTTP; Wed, 22 Oct 2014 14:01:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Oct 2014 22:01:51 +0100 Message-ID: From: Dave Cridland To: Melvin Carvalho Content-Type: multipart/alternative; boundary=089e0149c834c6d8da0506094129 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0WU1Cq9uxWbtsD0px5R9njtz7Gg Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 21:01:54 -0000 --089e0149c834c6d8da0506094129 Content-Type: text/plain; charset=UTF-8 On 22 October 2014 20:15, Melvin Carvalho wrote: > 1. I am modelling a user and NOT an account, so this would be a misuse of > the term. For my use case there is a very important distinction here, just > as a bank account is not the same as a bank user. > > I'm pretty sure this is either incorrect, or just a non-starter. Incorrect, because for nearly every purpose, an account is essentially a user. A non-starter, because if you're actually after a URI mechanism to identify natural persons, I suspect you're trying to do something badly wrong. > 2. Even if acct: could be reused (it cant imho), I am looking for a well > known HTTP URI that denotes a user. Why HTTP? Because that's the protocol > of the web, and everything talks it. > > OK. So "acct" is the wrong scheme because it's not an account you're trying to identify (though I suspect it is, really - it's your case (1) in your original mail), but "http" is OK, because although it's most certainly not a scheme for identifying natural persons, it's "the protocol of the web". > I've had the following suggestions: > > - http://user@host/ -- this passes the RFC and would be perfect, but > guess what? Browsers fail on it. Snowball's chance in hell getting the > WHATWG folks to fix it, imho. > > I don't think that form means what you seem to think it means. The userinfo portion of the authority relates to authorization identities. > - http://host/@user -- seems OK, but can you get people to agree, I doubt > it > > - http://host/@/user -- seems OK, but can you get people to agree, I > doubt it > > - http://host/~user -- seems OK, but can you get people to agree, I > doubt it > > No, you - more or less - cannot standardize paths of URIs. You want acct:user@host - and resolve it with WebFInger and a link type if you want something HTMLish. > All that remains is the /well-known/ pattern. > > It's already established that well-known is used when all else fails, and > has sub directories. > > .well-known/user/mark > > Well what else could it mean? I think it's about as unambiguous as it > gets, no room for collisions. It also gives me and other implementations a > standard way to construct an identifer and introspect on one. > > If there's a better way I'd love to hear. > > Yes, there is. You could use acct URIs to identify the user, and WebFinger top resolve them, which is specifically designed for this case. You seem to want an HTML resource - it's not clear why - so why not define a link type of whatever it is you want? Dave. --089e0149c834c6d8da0506094129 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 2= 2 October 2014 20:15, Melvin Carvalho <melvincarvalho@gmail.com= > wrote:
1. I=20 am modelling a user and NOT an account, so this would be a misuse of the term.=C2=A0 For my use case there is a very important distinction here, ju= st as a bank account is not the same as a bank user.


I'm pretty sure this is e= ither incorrect, or just a non-starter.

Incorrect,= because for nearly every purpose, an account is essentially a user.
<= div>
A non-starter, because if you're actually after a UR= I mechanism to identify natural persons, I suspect you're trying to do = something badly wrong.
=C2=A0
2.=20 Even if acct: could be reused (it cant imho), I am looking for a well=20 known HTTP URI that denotes a user.=C2=A0 Why HTTP?=C2=A0 Because that'= s the=20 protocol of the web, and everything talks it.=C2=A0


OK. So "acct" is = the wrong scheme because it's not an account you're trying to ident= ify (though I suspect it is, really - it's your case (1) in your origin= al mail), but "http" is OK, because although it's most certai= nly not a scheme for identifying natural persons, it's "the protoc= ol of the web".
=C2=A0
<= div dir=3D"ltr">
=
I've had the following suggestions:

- http://user@host/ -- this passes the RFC and would be perfect, but=20 guess what?=C2=A0 Browsers fail on it.=C2=A0 Snowball's chance in hell = getting the WHATWG folks to fix it, imho.


I don't think that form means what you seem t= o think it means. The userinfo portion of the authority relates to authoriz= ation identities.
=C2=A0
- http://host/= @user -- seems OK, but can you get people to agree, I doubt it

<= div>- http://host/@/user -- seems OK, but can you get people to agree, I doubt it

=C2=A0- http://h= ost/~user -- seems OK, but can you get people to agree, I doubt it
<= br>

No, you -= more or less - cannot standardize paths of URIs.

= You want acct:user@host - and resolve it with WebFInger and a link type if = you want something HTMLish.
=C2=A0
All that remains is the /well-known/ pattern.
It's already established that well-known is used when all e= lse fails, and has sub directories.

.well-known/user/mark=

Well what else could it mean?=C2=A0 I think it's about as unambiguous as it= gets, no room for collisions.=C2=A0 It also gives me and other implementations a= =20 standard way to construct an identifer and introspect on one.

=
If there's a better way I'd love to hear.

<= /div>

Yes, there is.
=
You could use acct URIs to identify the user, and WebFinger = top resolve them, which is specifically designed for this case. You seem to= want an HTML resource - it's not clear why - so why not define a link = type of whatever it is you want?

Dave.
=
--089e0149c834c6d8da0506094129-- From nobody Wed Oct 22 14:47:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8975F1A7007 for ; Wed, 22 Oct 2014 14:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLVTbIg6MfiO for ; Wed, 22 Oct 2014 14:47:30 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 643A91A6F21 for ; Wed, 22 Oct 2014 14:47:29 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id hz20so3778593lab.11 for ; Wed, 22 Oct 2014 14:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7dD3dXL2Kj/65w0RiunkP8Gk/AIGtHjehIMX0vu6F70=; b=C8YL2oMV7DOaNMfGJk1Hr1nfeRD8gRHj4Q4RrGBvaqrPzGZHI0MLEkncn+fQ1SQ5Nv ELKMY2g32jTzn5voPOgC3molrkITBuJe3Eyp90nQPjv0M/+MtYsTAVwNY7IpQpBro9fQ biuVpqwEgLgrFYSvltwm0PY9RTkhImCX1xKOXb+IEa/frZJ516vEamVfrILOKmmoVA3M V9ndND52UPv+2m7wiBDFWxW7O77cl6LARdSMpRQEGsUFC9HD266z7LyrZWK5+jbsCCN9 QJjvMggwgZQtKKd+aG+/ZVBu6Mmt5IuZ/CK6ycbdiJZ2L2Feb/Zm5g27GVxQCEKz8lAk DRsw== MIME-Version: 1.0 X-Received: by 10.153.4.7 with SMTP id ca7mr722841lad.31.1414014447565; Wed, 22 Oct 2014 14:47:27 -0700 (PDT) Received: by 10.112.1.234 with HTTP; Wed, 22 Oct 2014 14:47:27 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Oct 2014 23:47:27 +0200 Message-ID: From: Melvin Carvalho To: Dave Cridland Content-Type: multipart/alternative; boundary=001a113447c8dabff4050609e49b Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Cz0OJ16PEP8VYyK-8LpGHk2nkso Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 21:47:31 -0000 --001a113447c8dabff4050609e49b Content-Type: text/plain; charset=UTF-8 On 22 October 2014 23:01, Dave Cridland wrote: > On 22 October 2014 20:15, Melvin Carvalho > wrote: > >> 1. I am modelling a user and NOT an account, so this would be a misuse of >> the term. For my use case there is a very important distinction here, just >> as a bank account is not the same as a bank user. >> >> > I'm pretty sure this is either incorrect, or just a non-starter. > > Incorrect, because for nearly every purpose, an account is essentially a > user. > An account is not a user. > > A non-starter, because if you're actually after a URI mechanism to > identify natural persons, I suspect you're trying to do something badly > wrong. > Respectfully, I disagree. > > >> 2. Even if acct: could be reused (it cant imho), I am looking for a well >> known HTTP URI that denotes a user. Why HTTP? Because that's the protocol >> of the web, and everything talks it. >> >> > OK. So "acct" is the wrong scheme because it's not an account you're > trying to identify (though I suspect it is, really - it's your case (1) in > your original mail), but "http" is OK, because although it's most certainly > not a scheme for identifying natural persons, it's "the protocol of the > web". > An HTTP URI can quite easily denote, point to, name a user. > > >> I've had the following suggestions: >> >> - http://user@host/ -- this passes the RFC and would be perfect, but >> guess what? Browsers fail on it. Snowball's chance in hell getting the >> WHATWG folks to fix it, imho. >> >> > I don't think that form means what you seem to think it means. The > userinfo portion of the authority relates to authorization identities. > > >> - http://host/@user -- seems OK, but can you get people to agree, I >> doubt it >> >> - http://host/@/user -- seems OK, but can you get people to agree, I >> doubt it >> >> - http://host/~user -- seems OK, but can you get people to agree, I >> doubt it >> >> > No, you - more or less - cannot standardize paths of URIs. > You can, but it's an uphill battle, I think we are agreeing. > > You want acct:user@host - and resolve it with WebFInger and a link type > if you want something HTMLish. > Hopefully I've explained a couple of times why the former is not appropriate. Additionally the only mandated serialization of WebFinger is JRD, and that is impossible for me to work with, for example the predicates are non standard and I am unable to associate more than one literal with an object, it does not allow integers, let alone things like xsd:decimal which I need, the list goes on and on. It's a non starter, right now, maybe some webfinger 2.0 would work, but not today. Im unsure what you mean by using a link type and "HTMLish" -- is that a thing? > > >> All that remains is the /well-known/ pattern. >> >> It's already established that well-known is used when all else fails, and >> has sub directories. >> >> .well-known/user/mark >> >> Well what else could it mean? I think it's about as unambiguous as it >> gets, no room for collisions. It also gives me and other implementations a >> standard way to construct an identifer and introspect on one. >> >> If there's a better way I'd love to hear. >> >> > Yes, there is. > > You could use acct URIs to identify the user, and WebFinger top resolve > them, which is specifically designed for this case. You seem to want an > HTML resource - it's not clear why - so why not define a link type of > whatever it is you want? > Thank you for the feedback, but your proposal would be both logically and technically impossible for me to work with in its current form. I hope I've given some pointers as to why. > > Dave. > --001a113447c8dabff4050609e49b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 22 October 2014 23:01, Dave Cridland <dave@cridland.net> wrote:
On 22 October 2014 20:15, Melvi= n Carvalho <melvincarvalho@gmail.com> wrote:
1. I=20 am modelling a user and NOT an account, so this would be a misuse of the term.=C2=A0 For my use case there is a very important distinction here, ju= st as a bank account is not the same as a bank user.


I'm pretty sure this is e= ither incorrect, or just a non-starter.

Incorrect,= because for nearly every purpose, an account is essentially a user.
<= /div>

An account is not a user.=
=C2=A0
=

A= non-starter, because if you're actually after a URI mechanism to ident= ify natural persons, I suspect you're trying to do something badly wron= g.

Respectfully, I = disagree.
=C2=A0
=C2=A0<= /div>
2.=20 Even if acct: could be reused (it cant imho), I am looking for a well=20 known HTTP URI that denotes a user.=C2=A0 Why HTTP?=C2=A0 Because that'= s the=20 protocol of the web, and everything talks it.=C2=A0


OK. So "acct" is = the wrong scheme because it's not an account you're trying to ident= ify (though I suspect it is, really - it's your case (1) in your origin= al mail), but "http" is OK, because although it's most certai= nly not a scheme for identifying natural persons, it's "the protoc= ol of the web".

An HTTP URI can quite easily denote, point to, name a user.=C2=A0
=C2=A0
=C2=A0
I've had the following suggestion= s:

- http://user@host/ -- this passes the RFC and would be perfect, but=20 guess what?=C2=A0 Browsers fail on it.=C2=A0 Snowball's chance in hell = getting the WHATWG folks to fix it, imho.


I don't think that form means what you seem t= o think it means. The userinfo portion of the authority relates to authoriz= ation identities.
=C2=A0
- http://host/= @user -- seems OK, but can you get people to agree, I doubt it

<= div>- http://host/@/user -- seems OK, but can you get people to agree, I doubt it

=C2=A0- http://h= ost/~user -- seems OK, but can you get people to agree, I doubt it
<= br>

No, you -= more or less - cannot standardize paths of URIs.

You can, but it's an uphill battle, I th= ink we are agreeing.=C2=A0
=C2=A0

You want acct:user@host - and resolve it with Web= FInger and a link type if you want something HTMLish.

Hopefully I've explained a couple of= times why the former is not appropriate.=C2=A0 Additionally the only manda= ted serialization of WebFinger is JRD, and that is impossible for me to wor= k with, for example the predicates are non standard and I am unable to asso= ciate more than one literal with an object, it does not allow integers, let= alone things like xsd:decimal which I need, the list goes on and on.=C2=A0= It's a non starter, right now, maybe some webfinger 2.0 would work, bu= t not today.

Im unsure what you mean by using a link type= and "HTMLish" -- is that a thing?
=C2=A0
=C2=A0
All that remains is the /well-known/ pattern.

It's already established that well-known is used when all else fails,= and has sub directories.

.well-known/user/mark

Well what else could it mean?=C2=A0 I think it's about as unambiguous as it= gets, no room for collisions.=C2=A0 It also gives me and other implementations a= =20 standard way to construct an identifer and introspect on one.

=
If there's a better way I'd love to hear.

<= /div>

Yes, there is.
=
You could use acct URIs to identify the user, and WebFinger = top resolve them, which is specifically designed for this case. You seem to= want an HTML resource - it's not clear why - so why not define a link = type of whatever it is you want?
<= br>
Thank you for the feedback, but your proposal would be both l= ogically and technically impossible for me to work with in its current form= .=C2=A0 I hope I've given some pointers as to why.
=C2=A0=

Dave.

--001a113447c8dabff4050609e49b-- From nobody Thu Oct 23 01:10:43 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703F41A88F5 for ; Thu, 23 Oct 2014 01:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 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, J_CHICKENPOX_37=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiRw38AmqhIh for ; Thu, 23 Oct 2014 01:10:25 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E47801A8907 for ; Thu, 23 Oct 2014 01:10:24 -0700 (PDT) Received: by mail-oi0-f46.google.com with SMTP id h136so346158oig.33 for ; Thu, 23 Oct 2014 01:10:24 -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=R+Ppbs2tB+IXnPbJuu9/sjlkKm1EziYsJbKTsjj6seg=; b=Z0DDB7CyE1E8YkF/wMhYc7fhq5eUyFwCpEKiyBVifYwaRJrQRiTGZxUXbE7lJZCNJo iINQTO9uktTff4lU7tOR/sLw0azYBgm6psHL6/2ws36eKg7K92DzsHJXdlESUjiXdhBz EUkGOhsbzihfxcpBKeCaBqkSpFXjKsj7Ourqw= 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=R+Ppbs2tB+IXnPbJuu9/sjlkKm1EziYsJbKTsjj6seg=; b=l/9LbKt+YV8YsRN/K4b+qNbrDiNW9OTVRZjVSFWEuKWzn1SwJG8ULe9Inh7GOQ7gzW nVUjV/iRxLbocZ7B+dJEtZVVWklssr5DOxqa/mGogn6gBUr09HIEdLCAIkSHzQJCXJIs X/XfEV+EL65opt5tLx1ro3tNgcgE8RQ+kS4+iHYPnEr4IS0SJyR3umOnX1SHKS6m3jJ8 SbdEj3iE/DrvEMrcnqgWPBZd7jgve85LE79QigpP9HhCk5Y8TE6TH7Ue59Frf5O2w45A uw7/BSVGDH6GtJHQwQXJ6fVA/Rg4dmK/fR0bqyUuD9seuUR9PGeEic9aUEX/tIxy+OOw Yxyw== X-Gm-Message-State: ALoCoQnRogEnOUwVn9zpoaZCgzPHJXHyxD+yDI809BZPhwDcTwvti0Xg3EuMgz9Jm8ODgKggt0RY MIME-Version: 1.0 X-Received: by 10.202.81.68 with SMTP id f65mr140084oib.73.1414051824233; Thu, 23 Oct 2014 01:10:24 -0700 (PDT) Received: by 10.60.150.238 with HTTP; Thu, 23 Oct 2014 01:10:24 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Oct 2014 09:10:24 +0100 Message-ID: From: Dave Cridland To: Melvin Carvalho Content-Type: multipart/alternative; boundary=001a113d7818ad86e7050612985f Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/naGAtfKNMj-wSgZfdlwdvggslPs Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 08:10:27 -0000 --001a113d7818ad86e7050612985f Content-Type: text/plain; charset=UTF-8 On 22 October 2014 22:47, Melvin Carvalho wrote: > > > On 22 October 2014 23:01, Dave Cridland wrote: > >> On 22 October 2014 20:15, Melvin Carvalho >> wrote: >> >>> 1. I am modelling a user and NOT an account, so this would be a misuse >>> of the term. For my use case there is a very important distinction here, >>> just as a bank account is not the same as a bank user. >>> >>> >> I'm pretty sure this is either incorrect, or just a non-starter. >> >> Incorrect, because for nearly every purpose, an account is essentially a >> user. >> > > An account is not a user. > In a pure and semantic sense, this is true. However, a user can be described in only a very few mechanisms, none of which are universal. Firstly, you can identify a user by one or more accounts. Given the sole identifier on the internet is currently an account, this is by far the most practical mechanism. You're welcome to worry over canonicalizing to a single identifier; I suspect you'll find that most people will prefer multiple identities in that sense. For basic canonicalization, WebFinger is the thing to use. Secondly, you could use some kind of national identifier. However, these are neither universal (I live in the UK, for example, where we do not have any form of mandatory ID card) nor homogeneous (national id card numbers vary widely in form). > > >> >> A non-starter, because if you're actually after a URI mechanism to >> identify natural persons, I suspect you're trying to do something badly >> wrong. >> > > Respectfully, I disagree. > You're allowed to disagree with me there; that was my opinion. > > >> >> >>> 2. Even if acct: could be reused (it cant imho), I am looking for a well >>> known HTTP URI that denotes a user. Why HTTP? Because that's the protocol >>> of the web, and everything talks it. >>> >>> >> OK. So "acct" is the wrong scheme because it's not an account you're >> trying to identify (though I suspect it is, really - it's your case (1) in >> your original mail), but "http" is OK, because although it's most certainly >> not a scheme for identifying natural persons, it's "the protocol of the >> web". >> > > An HTTP URI can quite easily denote, point to, name a user. > This, however, is opinion. Any URI can be used as an identifier, however acct scheme URIs are the closest you'll get in semantic terms. You cannot resolve any URI to a person, after all. > > >> >> >>> I've had the following suggestions: >>> >>> - http://user@host/ -- this passes the RFC and would be perfect, but >>> guess what? Browsers fail on it. Snowball's chance in hell getting the >>> WHATWG folks to fix it, imho. >>> >>> >> I don't think that form means what you seem to think it means. The >> userinfo portion of the authority relates to authorization identities. >> >> >>> - http://host/@user -- seems OK, but can you get people to agree, I >>> doubt it >>> >>> - http://host/@/user -- seems OK, but can you get people to agree, I >>> doubt it >>> >>> - http://host/~user -- seems OK, but can you get people to agree, I >>> doubt it >>> >>> >> No, you - more or less - cannot standardize paths of URIs. >> > > You can, but it's an uphill battle, I think we are agreeing. > I think consensus is that imposing additional structure on the path is not a path the IETF wishes to pursue, so "uphill battle" is an understatement. > > >> >> You want acct:user@host - and resolve it with WebFInger and a link type >> if you want something HTMLish. >> > > Hopefully I've explained a couple of times why the former is not > appropriate. Additionally the only mandated serialization of WebFinger is > JRD, and that is impossible for me to work with, for example the predicates > are non standard and I am unable to associate more than one literal with an > object, it does not allow integers, let alone things like xsd:decimal which > I need, the list goes on and on. It's a non starter, right now, maybe some > webfinger 2.0 would work, but not today. > > Im unsure what you mean by using a link type and "HTMLish" -- is that a > thing? > Sorry, by "link type" I meant "relation type". By "HTMLish", I meant that you have previously made a requirement that the resource be resolvable to some HTML, though in the paragraph above it seems to imply you need something different. 1) Start with a URI. "acct" scheme URIs are good here. 2) Translate this to JRD via WebFinger. This gives you, amongst other things, a "subject" - canonical URI, some "properties" - key/value string pairs, and some "links", giving "rel" - the relation type - and an "href". 3) You register a relation type for your purposes, and then you have a mechanism for discovering a URI you can resolve to the object you need, in whatever format best suits your purpose. I'd welcome an explanation of why this won't work, given it's very close to what it was designed specifically for. Dave. --001a113d7818ad86e7050612985f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 2= 2 October 2014 22:47, Melvin Carvalho <melvincarvalho@gmail.com= > wrote:

<= div class=3D"gmail_extra">
O= n 22 October 2014 23:01, Dave Cridland <dave@cridland.net> w= rote:
On 22 October 2014 20:15, Melvin Carval= ho <melvincarvalho@gmail.com> wrote:
1. I=20 am modelling a user and NOT an account, so this would be a misuse of the term.=C2=A0 For my use case there is a very important distinction here, ju= st as a bank account is not the same as a bank user.


I'm pretty sure this is e= ither incorrect, or just a non-starter.

Incorrect,= because for nearly every purpose, an account is essentially a user.
<= /div>

An account is not = a user.

In a pure and semantic sense, this is true. How= ever, a user can be described in only a very few mechanisms, none of which = are universal.

Firstly, you can identify a user by= one or more accounts. Given the sole identifier on the internet is current= ly an account, this is by far the most practical mechanism. You're welc= ome to worry over canonicalizing to a single identifier; I suspect you'= ll find that most people will prefer multiple identities in that sense. For= basic canonicalization, WebFinger is the thing to use.

Secondly, you could use some kind of national identifier. However, th= ese are neither universal (I live in the UK, for example, where we do not h= ave any form of mandatory ID card) nor homogeneous (national id card number= s vary widely in form).
=C2=A0
=C2=A0

<= div>A non-starter, because if you're actually after a URI mechanism to = identify natural persons, I suspect you're trying to do something badly= wrong.

Resp= ectfully, I disagree.

You're allowed to disagree with me there; that was my opinion.
=C2=A0
=C2=A0
=C2=A0
2.=20 Even if acct: could be reused (it cant imho), I am looking for a well=20 known HTTP URI that denotes a user.=C2=A0 Why HTTP?=C2=A0 Because that'= s the=20 protocol of the web, and everything talks it.=C2=A0


OK. So "acct" is = the wrong scheme because it's not an account you're trying to ident= ify (though I suspect it is, really - it's your case (1) in your origin= al mail), but "http" is OK, because although it's most certai= nly not a scheme for identifying natural persons, it's "the protoc= ol of the web".

An HTTP URI can quite easily denote, point to, name a user.=C2=A0 =

This, however,= is opinion. Any URI can be used as an identifier, however acct scheme URIs= are the closest you'll get in semantic terms. You cannot resolve any U= RI to a person, after all.
=C2=A0
=C2=A0
=C2=A0
I've h= ad the following suggestions:

- http://user@host/ -- this passes the RFC and would be perfect, but=20 guess what?=C2=A0 Browsers fail on it.=C2=A0 Snowball's chance in hell = getting the WHATWG folks to fix it, imho.


I don't think that form means what you seem t= o think it means. The userinfo portion of the authority relates to authoriz= ation identities.
=C2=A0
- http://host/= @user -- seems OK, but can you get people to agree, I doubt it

<= div>- http://host/@/user -- seems OK, but can you get people to agree, I doubt it

=C2=A0- http://h= ost/~user -- seems OK, but can you get people to agree, I doubt it
<= br>

No, you -= more or less - cannot standardize paths of URIs.

You can, but it's an uphill battl= e, I think we are agreeing.=C2=A0
=

I think consensus is that imposing additional structure= on the path is not a path the IETF wishes to pursue, so "uphill battl= e" is an understatement.
=C2=A0
=C2=A0

You want acct:user@host - and resolve it with WebFInge= r and a link type if you want something HTMLish.

Hopefully I've explained a couple = of times why the former is not appropriate.=C2=A0 Additionally the only man= dated serialization of WebFinger is JRD, and that is impossible for me to w= ork with, for example the predicates are non standard and I am unable to as= sociate more than one literal with an object, it does not allow integers, l= et alone things like xsd:decimal which I need, the list goes on and on.=C2= =A0 It's a non starter, right now, maybe some webfinger 2.0 would work,= but not today.

Im unsure what you mean by using a link t= ype and "HTMLish" -- is that a thing?
=

Sorry, by "link type" I meant &q= uot;relation type". By "HTMLish", I meant that you have prev= iously made a requirement that the resource be resolvable to some HTML, tho= ugh in the paragraph above it seems to imply you need something different.<= /div>

1) Start with a URI. "acct" scheme URIs = are good here.

2) Translate this to JRD via WebFin= ger. This gives you, amongst other things, a "subject" - canonica= l URI, some "properties" - key/value string pairs, and some "= ;links", giving "rel" - the relation type - and an "hre= f".

3) You register a relation type for your = purposes, and then you have a mechanism for discovering a URI you can resol= ve to the object you need, in whatever format best suits your purpose.

I'd welcome an explanation of why this won't w= ork, given it's very close to what it was designed specifically for.

Dave.
--001a113d7818ad86e7050612985f-- From nobody Thu Oct 23 03:15:27 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E1E1A8A41 for ; Thu, 23 Oct 2014 03:15:25 -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 WBTYS0SfUaJ5 for ; Thu, 23 Oct 2014 03:15:23 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0BF1A8A14 for ; Thu, 23 Oct 2014 03:15:23 -0700 (PDT) Received: from [192.168.123.119] (unknown [23.240.242.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E367C50A73; Thu, 23 Oct 2014 06:15:21 -0400 (EDT) From: Sean Leonard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Oct 2014 03:15:18 -0700 References: <20141023100650.23822.44847.idtracker@ietfa.amsl.com> To: IETF Apps Discuss , media-types@iana.org Message-Id: <196FCA0A-94C7-4CCA-B97F-CE50852C87B2@seantek.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/yA9E82ROquYfda7ZQ5FUBiXOcy0 Subject: [apps-discuss] New Version Notification for draft-seantek-image-bmp-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 10:15:25 -0000 Colleagues: draft-seantek-image-bmp-01 has been posted. It removes the problematic = sentence about not containing text. Note that there are embedded questions in the introduction: shall the = .cur and .ani formats also be registered? And shall the .ico format be = re-registered? (.cur is almost identical to .ico; .ani, not so much.) Here is the registration template: ******* Windows Bitmap Media Type Registration Application Type name: image Subtype name: bmp Required parameters: None. Optional parameters: None. Encoding considerations: Binary. Security considerations: Bitmaps have a mostly unremarkable security history. Because BMP data can encapsulate JPEG or PNG data (BI_JPEG, BI_PNG values of the Compression enumeration in Section 2.1.1.7 of [MS- WMF]), the security considerations of JPEG and PNG processing may also apply to BMP. Interoperability considerations: Uncompressed Windows Bitmaps can be rather large. If there is a need to compress an image, modern applications SHOULD consider emitting JPEG or PNG data instead of embedding them in BMP payloads. Published specification: [MS-WMF] and [BMPSTOR]. Applications that use this media type: Office productivity applications; clip art applications; desktop publishing applications; Web browsers; graphics processing applications. Fragment identifier considerations: None. Additional information: Magic number(s): 42 4D ("BM"), meaning "bitmap". The next field (BITMAPFILEHEADER bfSize) is a little-endian DWORD indicating the size of the bitmap content in bytes. File extension(s): .bmp, .dib Macintosh file type code(s): "BMP ", "BMPf", or "BMPp". Apple has promulgated a uniform type identifier (UTI) of "com.microsoft.bmp". Person & email address to contact for further information: Sean Leonard Restrictions on usage: None. Author/Change controller: Sean Leonard Intended usage: COMMON Provisional registration? No ******* Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-seantek-image-bmp-01.txt > Date: October 23, 2014 at 3:06:50 AM PDT > To: Sean Leonard , "Sean Leonard" = >=20 >=20 > A new version of I-D, draft-seantek-image-bmp-01.txt > has been successfully submitted by Sean Leonard and posted to the > IETF repository. >=20 > Name: draft-seantek-image-bmp > Revision: 01 > Title: The Windows Bitmap Media Type > Document date: 2014-10-23 > Group: Individual Submission > Pages: 5 > URL: = http://www.ietf.org/internet-drafts/draft-seantek-image-bmp-01.txt > Status: = https://datatracker.ietf.org/doc/draft-seantek-image-bmp/ > Htmlized: http://tools.ietf.org/html/draft-seantek-image-bmp-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-seantek-image-bmp-01 >=20 > Abstract: > This document registers the image/bmp media type for use with the > Windows Bitmap format (BMP), also known as Device-Independent Bitmap > (DIB). Originally designed for Microsoft Windows 2.0 and OS/2, these > bitmaps contain a single raster graphic in a variety of compressed = or > uncompressed formats. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Thu Oct 23 03:57:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4AD1A8A93 for ; Thu, 23 Oct 2014 03:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, MARKETING_PARTNERS=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 doku2Xc7rBWn for ; Thu, 23 Oct 2014 03:57:49 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A40D1A8A74 for ; Thu, 23 Oct 2014 03:57:48 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gi9so605902lab.7 for ; Thu, 23 Oct 2014 03:57:46 -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=Hv3CI1FtgYRJ7rqhhU5irqLVibv6JHUA077GS4EcoNE=; b=vpKte160zwA9Nf5tO8oLgvK84jRJLb31w99vJNVHpmFV83vPMlwHCGbSbTZ7YldaiH AV4uDrpMiL+Mz9PfmWIWdAvZJkTIvdoPNPYQXdLk72YOZBn7HN7frQtH8nvefoxmLTr+ zTthT1djFE+UlxvV2bdRNU+2yR33+c9xFhwtrcoaljM8S8S586x0te7S4g1mXFZpksld boM40X1mIu9ozX17quJxREaoXPL89z4c0u0NtevUrWSPuO/FAX94ucP1/kg7JmPoPbbu ngWXPPbDICxawkddm07R9CYWuLIBhkIa0vPRw9qfDhbG1UmdQ6gSfBBe28jR8r+iSADj aMgA== MIME-Version: 1.0 X-Received: by 10.152.243.39 with SMTP id wv7mr4154043lac.48.1414061866511; Thu, 23 Oct 2014 03:57:46 -0700 (PDT) Received: by 10.112.1.234 with HTTP; Thu, 23 Oct 2014 03:57:46 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Oct 2014 12:57:46 +0200 Message-ID: From: Melvin Carvalho To: Dave Cridland Content-Type: multipart/alternative; boundary=001a113433c83e73cc050614ef6c Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_89AJ4TTxseamN862JiYFueIbJM Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 10:57:52 -0000 --001a113433c83e73cc050614ef6c Content-Type: text/plain; charset=UTF-8 On 23 October 2014 10:10, Dave Cridland wrote: > On 22 October 2014 22:47, Melvin Carvalho > wrote: > >> >> >> On 22 October 2014 23:01, Dave Cridland wrote: >> >>> On 22 October 2014 20:15, Melvin Carvalho >>> wrote: >>> >>>> 1. I am modelling a user and NOT an account, so this would be a misuse >>>> of the term. For my use case there is a very important distinction here, >>>> just as a bank account is not the same as a bank user. >>>> >>>> >>> I'm pretty sure this is either incorrect, or just a non-starter. >>> >>> Incorrect, because for nearly every purpose, an account is essentially a >>> user. >>> >> >> An account is not a user. >> > > In a pure and semantic sense, this is true. However, a user can be > described in only a very few mechanisms, none of which are universal. > > Firstly, you can identify a user by one or more accounts. Given the sole > identifier on the internet is currently an account, this is by far the most > practical mechanism. You're welcome to worry over canonicalizing to a > single identifier; I suspect you'll find that most people will prefer > multiple identities in that sense. For basic canonicalization, WebFinger is > the thing to use. > > Secondly, you could use some kind of national identifier. However, these > are neither universal (I live in the UK, for example, where we do not have > any form of mandatory ID card) nor homogeneous (national id card numbers > vary widely in form). > > >> >> >>> >>> A non-starter, because if you're actually after a URI mechanism to >>> identify natural persons, I suspect you're trying to do something badly >>> wrong. >>> >> >> Respectfully, I disagree. >> > > You're allowed to disagree with me there; that was my opinion. > Cool. Thanks for sharing, it has been noted. > > >> >> >>> >>> >>>> 2. Even if acct: could be reused (it cant imho), I am looking for a >>>> well known HTTP URI that denotes a user. Why HTTP? Because that's the >>>> protocol of the web, and everything talks it. >>>> >>>> >>> OK. So "acct" is the wrong scheme because it's not an account you're >>> trying to identify (though I suspect it is, really - it's your case (1) in >>> your original mail), but "http" is OK, because although it's most certainly >>> not a scheme for identifying natural persons, it's "the protocol of the >>> web". >>> >> >> An HTTP URI can quite easily denote, point to, name a user. >> > > This, however, is opinion. Any URI can be used as an identifier, however > acct scheme URIs are the closest you'll get in semantic terms. You cannot > resolve any URI to a person, after all. > I understand your world view but I think you've misunderstood how the web is supposed to work, or how it works. I'll invite you to review the original proposal form day 1 of the web. http://www.w3.org/History/1989/proposal.html You can see clearly that the design of the web was for HTTP URIs to denote people, and here is a living example: http://www.w3.org/People/Berners-Lee/card#i I think if you wish to continue to debate this point, we are going badly off topic, perhaps start another thread. > > >> >> >>> >>> >>>> I've had the following suggestions: >>>> >>>> - http://user@host/ -- this passes the RFC and would be perfect, but >>>> guess what? Browsers fail on it. Snowball's chance in hell getting the >>>> WHATWG folks to fix it, imho. >>>> >>>> >>> I don't think that form means what you seem to think it means. The >>> userinfo portion of the authority relates to authorization identities. >>> >>> >>>> - http://host/@user -- seems OK, but can you get people to agree, I >>>> doubt it >>>> >>>> - http://host/@/user -- seems OK, but can you get people to agree, I >>>> doubt it >>>> >>>> - http://host/~user -- seems OK, but can you get people to agree, I >>>> doubt it >>>> >>>> >>> No, you - more or less - cannot standardize paths of URIs. >>> >> >> You can, but it's an uphill battle, I think we are agreeing. >> > > I think consensus is that imposing additional structure on the path is not > a path the IETF wishes to pursue, so "uphill battle" is an understatement. > As said, I think we are agreeing. > > >> >> >>> >>> You want acct:user@host - and resolve it with WebFInger and a link type >>> if you want something HTMLish. >>> >> >> Hopefully I've explained a couple of times why the former is not >> appropriate. Additionally the only mandated serialization of WebFinger is >> JRD, and that is impossible for me to work with, for example the predicates >> are non standard and I am unable to associate more than one literal with an >> object, it does not allow integers, let alone things like xsd:decimal which >> I need, the list goes on and on. It's a non starter, right now, maybe some >> webfinger 2.0 would work, but not today. >> >> Im unsure what you mean by using a link type and "HTMLish" -- is that a >> thing? >> > > Sorry, by "link type" I meant "relation type". > Got it, but that doesnt help my use case. > By "HTMLish", I meant that you have previously made a requirement that the > resource be resolvable to some HTML, though in the paragraph above it seems > to imply you need something different. > Got it. Im not too set on a serialization, could be HTML or JSON LD or turtle or any other W3C REC, I dont mind. I think HTML is the lowest barrier to entry for our partner sites tho. JRD is a non starter. Which means WebFinger is a non starter. > > 1) Start with a URI. "acct" scheme URIs are good here. > No, it isnt. I am looking for an HTTP URI. Please read the original post or at least the title. May I request that you please stop repeating this suggestion. > > > 2) Translate this to JRD via WebFinger. This gives you, amongst other > things, a "subject" - canonical URI, some "properties" - key/value string > pairs, and some "links", giving "rel" - the relation type - and an "href". > Please read my previous response. This is an impossibility. On top of my other show stoppers, JRD requires a list of URIs to be ordered in terms of preference, there's absolutely no way I can reliably comply to this requirement. > > 3) You register a relation type for your purposes, and then you have a > mechanism for discovering a URI you can resolve to the object you need, in > whatever format best suits your purpose. > My purpose is to find an HTTP URI that denotes a user on our partner site, which can be constructed from user and host key pair, in the absence of a known profile page. I have no idea what this has to do with a link relation. I am looking for an identifier not a relation. > > I'd welcome an explanation of why this won't work, given it's very close > to what it was designed specifically for. > Please reread my previous responses. If you can come up with solutions I'd love to hear. If you are just going to repeat your webfinger / JRD recommendations, they have been noted. > > Dave. > --001a113433c83e73cc050614ef6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 23 October 2014 10:10, Dave Cridland <dave@cridland.net> wrote:
On 22 October 2014 22:47, Melvin Carvalho <melvincarvalho@gma= il.com> wrote:



Secondly, you could use some kind of national identifier. However, these = are neither universal (I live in the UK, for example, where we do not have = any form of mandatory ID card) nor homogeneous (national id card numbers va= ry widely in form).
=C2=A0
=C2=A0

A non-starter, because if you&#= 39;re actually after a URI mechanism to identify natural persons, I suspect= you're trying to do something badly wrong.

Respectfully, I disagree.

You're allowed to= disagree with me there; that was my opinion.

=
=C2=A0
=C2=A0
=C2=A0
=
2.=20 Even if acct: could be reused (it cant imho), I am looking for a well=20 known HTTP URI that denotes a user.=C2=A0 Why HTTP?=C2=A0 Because that'= s the=20 protocol of the web, and everything talks it.=C2=A0


OK. So "acct" is = the wrong scheme because it's not an account you're trying to ident= ify (though I suspect it is, really - it's your case (1) in your origin= al mail), but "http" is OK, because although it's most certai= nly not a scheme for identifying natural persons, it's "the protoc= ol of the web".

An HTTP URI can quite easily denote, point to, name a user.=C2=A0 =

This, h= owever, is opinion. Any URI can be used as an identifier, however acct sche= me URIs are the closest you'll get in semantic terms. You cannot resolv= e any URI to a person, after all.
You can see clearly that the des= ign of the web was for HTTP URIs to denote people, and here is a living exa= mple:

http:/= /www.w3.org/People/Berners-Lee/card#i

I think if you = wish to continue to debate this point, we are going badly off topic, perhap= s start another thread.=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
I've had the followin= g suggestions:

- http://user@host/ -- this passes the RFC and would be perfect, but=20 guess what?=C2=A0 Browsers fail on it.=C2=A0 Snowball's chance in hell = getting the WHATWG folks to fix it, imho.


I don't think that form means what you seem t= o think it means. The userinfo portion of the authority relates to authoriz= ation identities.
=C2=A0
- http://host/@user -- seems OK, but can you get people to agree, = I doubt it

- h= ttp://host/@/user -- seems OK, but can you get people to agree, I doubt= it

=C2=A0- http://host/~user -- seems OK, but can you get people to ag= ree, I doubt it


=
No, you - more or less - cannot standardize paths of URIs.
=

You can, but it&#= 39;s an uphill battle, I think we are agreeing.=C2=A0

I think consensus is that im= posing additional structure on the path is not a path the IETF wishes to pu= rsue, so "uphill battle" is an understatement.
<= /div>

As said, I think we are agreeing.
=
=C2=A0
=C2=A0
<= div>
=C2=A0

You want acct:user@host - and resolve it with WebFI= nger and a link type if you want something HTMLish.
=

Hopefully I've explained a coup= le of times why the former is not appropriate.=C2=A0 Additionally the only = mandated serialization of WebFinger is JRD, and that is impossible for me t= o work with, for example the predicates are non standard and I am unable to= associate more than one literal with an object, it does not allow integers= , let alone things like xsd:decimal which I need, the list goes on and on.= =C2=A0 It's a non starter, right now, maybe some webfinger 2.0 would wo= rk, but not today.

Im unsure what you mean by using a lin= k type and "HTMLish" -- is that a thing?

Sorry, by "link type" = I meant "relation type".

Got it, but that doesnt help my use case.
= =C2=A0
By "HTM= Lish", I meant that you have previously made a requirement that the re= source be resolvable to some HTML, though in the paragraph above it seems t= o imply you need something different.
<= div>
Got it.=C2=A0 Im not too set on a serialization, could b= e HTML or JSON LD or turtle or any other W3C REC, I dont mind.=C2=A0 I thin= k HTML is the lowest barrier to entry for our partner sites tho.=C2=A0 JRD = is a non starter.=C2=A0 Which means WebFinger is a non starter.
=C2=A0

1) Start with a URI. "acct" scheme URIs are good here.

No, it isnt.=C2=A0 I am lo= oking for an HTTP URI.=C2=A0 Please read the original post or at least the = title.=C2=A0 May I request that you please stop repeating this suggestion.<= br>
=C2=A0

2) Translate this to JRD via WebFinger. Th= is gives you, amongst other things, a "subject" - canonical URI, = some "properties" - key/value string pairs, and some "links&= quot;, giving "rel" - the relation type - and an "href"= .

Please read my pr= evious response.=C2=A0 This is an impossibility.=C2=A0 On top of my other s= how stoppers, JRD requires a list of URIs to be ordered in terms of prefere= nce, there's absolutely no way I can reliably comply to this requiremen= t.=C2=A0
=C2=A0

3) You register a relation type for your purpose= s, and then you have a mechanism for discovering a URI you can resolve to t= he object you need, in whatever format best suits your purpose.
=

=C2=A0My purpose is to find an= HTTP URI that denotes a user on our partner site, which can be constructed= from user and host key pair, in the absence of a known profile page.=C2=A0= I have no idea what this has to do with a link relation.=C2=A0 I am lookin= g for an identifier not a relation.
=C2=A0

I'd welcome an exp= lanation of why this won't work, given it's very close to what it w= as designed specifically for.

=
Please reread my previous responses.=C2=A0 If you can come up wi= th solutions I'd love to hear.=C2=A0 If you are just going to repeat yo= ur webfinger / JRD recommendations, they have been noted.
=C2= =A0

Dave.

--001a113433c83e73cc050614ef6c-- From nobody Thu Oct 23 04:24:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9511A8AD3 for ; Thu, 23 Oct 2014 04:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etR-voIaLXzW for ; Thu, 23 Oct 2014 04:24:53 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479A71A8ABF for ; Thu, 23 Oct 2014 04:24:53 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 16FC2FA000C; Thu, 23 Oct 2014 11:24:51 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1414063490-4330-4329/12/38; Thu, 23 Oct 2014 11:24:50 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Thu, 23 Oct 2014 13:24:50 +0200 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.6; X11; Linux; Ubuntu 14.04.1 LTS Mime-Version: 1.0 Message-Id: In-Reply-To: References: Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/LPX3QWeYIOKEGP1gZhxjzjIquy0 Subject: Re: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 11:24:55 -0000 On Thursday, October 23, 2014 12:57:46 PM CEST, Melvin Carvalho wrote: > Got it, but that doesnt help my use case. Is your use case a variant of "each user should have exactly one account on my service"? I suggest using Facebook Connect instead of a new URI feature, BTW. Facebook works hard on identifying people (too hard for my taste). If you want to do the same you might as well leverage their work. Arnt From nobody Thu Oct 23 04:33:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB35F1A8ADF for ; Thu, 23 Oct 2014 04:33:46 -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 0pK9YfknLEfb for ; Thu, 23 Oct 2014 04:33:45 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED8E31A8AC9 for ; Thu, 23 Oct 2014 04:33:43 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id q1so661588lam.32 for ; Thu, 23 Oct 2014 04:33:42 -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=6V2aa7SPdEvh6UVdzMbQflyFiYiO8t79JzB/HZGX6EQ=; b=CSoRcDWHKRR8vbHOw6lSDYyMrUvYCskfpZX824JymKYDRSQSBXkxrSa2Dx3ojUaKUF Fr8/KPp5ZR00BnhPSEr1fCLtd+5iOfczOyMev0We5lt67hahDT4K9e4/rLy7ZamTL3o8 zKozyNlPKzlK4Ye6MNdRrU2JFWUuNvzGYIddfG+57TGH/ZZyrLqrPeRmzPFudghAwgV0 faVjPpDhyb//Q2pAGLifzhEDZQJkv2ZpGAPIemCQwVz9TRACbgVxIheBb9FJzWcMM/bw QFzfPoITW2Yr0VYBe2xysSCEDwTKa44Fffr9d3Sm7CqIsmCBvoxjJHrUaGSBDt7WtCaf QeKA== MIME-Version: 1.0 X-Received: by 10.112.162.73 with SMTP id xy9mr2472388lbb.94.1414064022186; Thu, 23 Oct 2014 04:33:42 -0700 (PDT) Received: by 10.112.1.234 with HTTP; Thu, 23 Oct 2014 04:33:42 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Oct 2014 13:33:42 +0200 Message-ID: From: Melvin Carvalho To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=089e0117644fbb6ff60506156f66 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3NIxixoIFM1aXOZELQvKWCZ8ouk Cc: Apps Discuss Subject: Re: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 11:33:47 -0000 --089e0117644fbb6ff60506156f66 Content-Type: text/plain; charset=UTF-8 On 23 October 2014 13:24, Arnt Gulbrandsen wrote: > On Thursday, October 23, 2014 12:57:46 PM CEST, Melvin Carvalho wrote: > >> Got it, but that doesnt help my use case. >> > > Is your use case a variant of "each user should have exactly one account > on my service"? > My use case is that I have a global reputation database that covers many sites on the web. e.g. facebook, twitter, exchanges. In my database I need a column that has a super key to each user. Each key much be an HTTP URI, that as best as possible denotes that user, for facebook and twitter it's quite easy. But some of our smaller sites it's harder to construct such a URI, or find a reliable pattern to do so. My contention is that it's hard to imaging /.well-known/user/mark ever being used for anything other than a user profile page. So why dont I just do that. I've had feeback that it looks 'ugly' but I dont have a better choice at the moment. > > I suggest using Facebook Connect instead of a new URI feature, BTW. > Facebook works hard on identifying people (too hard for my taste). If you > want to do the same you might as well leverage their work. > I use facebook connect and facebook open graph already, works really well. > > Arnt > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e0117644fbb6ff60506156f66 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 23 October 2014 13:24, Arnt Gulbrandsen <arnt@gulbrandsen.pr= iv.no> wrote:
On Thursday, October 23, 2014 12:57:46 PM CEST, Melvin Carvalho wrote= :
Got it, but that doesnt help my use case.

 Is your use case a variant of "each user should have exactly one accou= nt on my service"?

My use case is = that I have a global reputation database that covers many sites on the web.= =C2=A0 e.g. facebook, twitter, exchanges.

In my database = I need a column that has a super key to each user.=C2=A0 Each key much be a= n HTTP URI, that as best as possible denotes that user, for facebook and tw= itter it's quite easy.=C2=A0 But some of our smaller sites it's har= der to construct such a URI, or find a reliable pattern to do so.

My contention is that it's hard to imaging /.well-known/user/m= ark ever being used for anything other than a user profile page.=C2=A0 So w= hy dont I just do that.=C2=A0 I've had feeback that it looks 'ugly&= #39; but I dont have a better choice at the moment.
=C2=A0

I suggest using Facebook Connect instead of a new URI feature, BTW. Faceboo= k works hard on identifying people (too hard for my taste). If you want to = do the same you might as well leverage their work.
I use facebook connect and facebook open graph already, works r= eally well.
=C2=A0

Arnt

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

--089e0117644fbb6ff60506156f66-- From nobody Thu Oct 23 04:51:08 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A5B1A8F3E for ; Thu, 23 Oct 2014 04:51:05 -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 4vUj0nyKMPNj for ; Thu, 23 Oct 2014 04:51:03 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CA051A8F3D for ; Thu, 23 Oct 2014 04:51:03 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 3E693FA000C; Thu, 23 Oct 2014 11:51:01 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1414065060-4330-4329/11/4; Thu, 23 Oct 2014 11:51:00 +0000 From: Arnt Gulbrandsen To: Apps Discuss Date: Thu, 23 Oct 2014 13:50:59 +0200 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.6; X11; Linux; Ubuntu 14.04.1 LTS Mime-Version: 1.0 Message-Id: <71f33d9b-f73b-4431-9232-8d8ea44d411b@gulbrandsen.priv.no> In-Reply-To: References: Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/WIjOBjCoYBbqTic5lrVnNILBJLk Subject: Re: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 11:51:05 -0000 On Thursday, October 23, 2014 1:33:42 PM CEST, Melvin Carvalho wrote: > My use case is that I have a global reputation database that > covers many sites on the web. e.g. facebook, twitter, > exchanges. Oh. You don't say. As it happens, I've had a job that I don't want to influence my private reputation. I wouldn't even want you to find out where that was. You can find the email address I used for that work if you google for the right search terms, but I don't want you to connect that with me. Arnt From nobody Thu Oct 23 04:54:22 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047DF1A8F3E for ; Thu, 23 Oct 2014 04:54:20 -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 PfPJ7MtiMr8S for ; Thu, 23 Oct 2014 04:54:18 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D56851A8AED for ; Thu, 23 Oct 2014 04:54:17 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id mc6so694030lab.30 for ; Thu, 23 Oct 2014 04:54:16 -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=L/mRtqP4GAxqNX/J1+tzy7qI511cjng+xnXZ2yGn3D4=; b=eLgpOtn1Xu+uKaYK4CDmMek1h5jt44VU11tyQzSX8XYQODIt3vZBBMn5IWIL+vFTOL G7DX4usMU/cw8VZ/842R3PJP7dFkALW/Sla39urgfqAEodRZ+NOUwKSD1FgrgxzJK2nG nMrpOsd2rqGTlp612liBI6FJVsOrLp15YIim6xNPodcR+v6FC1yuhZQeBeq2tPvl4lQj aBL33nPwXnm5JtQBLgnj1n6nOqIl7AgRcwZ/NftTq3PL+lSecaYM+kE7VSGGyDDuP8q/ yjN6awA/GX5iC6NMGoC52hHG6DGvSA1wTjsNZ7OpS/vGy1MKHMp3oSs2RfktIIg8hlMw qw8Q== MIME-Version: 1.0 X-Received: by 10.112.97.175 with SMTP id eb15mr4615302lbb.12.1414065256169; Thu, 23 Oct 2014 04:54:16 -0700 (PDT) Received: by 10.112.1.234 with HTTP; Thu, 23 Oct 2014 04:54:16 -0700 (PDT) In-Reply-To: <71f33d9b-f73b-4431-9232-8d8ea44d411b@gulbrandsen.priv.no> References: <71f33d9b-f73b-4431-9232-8d8ea44d411b@gulbrandsen.priv.no> Date: Thu, 23 Oct 2014 13:54:16 +0200 Message-ID: From: Melvin Carvalho To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=001a1133b634488722050615b97e Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/UAGkJJX7XgmQA31vKMsc7f_Pr64 Cc: Apps Discuss Subject: Re: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 11:54:20 -0000 --001a1133b634488722050615b97e Content-Type: text/plain; charset=UTF-8 On 23 October 2014 13:50, Arnt Gulbrandsen wrote: > On Thursday, October 23, 2014 1:33:42 PM CEST, Melvin Carvalho wrote: > >> My use case is that I have a global reputation database that covers many >> sites on the web. e.g. facebook, twitter, exchanges. >> > > Oh. You don't say. As it happens, I've had a job that I don't want to > influence my private reputation. I wouldn't even want you to find out where > that was. You can find the email address I used for that work if you google > for the right search terms, but I don't want you to connect that with me. Thanks that's a very good point. But dont worry, our system is opt-in, so we wont take your details, unless you choose so. But I think this is off topic regarding my original question. > > > Arnt > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a1133b634488722050615b97e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 23 October 2014 13:50, Arnt Gulbrandsen <arnt@gulbrandsen.pr= iv.no> wrote:
On Thursday, October 23, 2014 1:33:42 PM CEST, Melvin Carvalho wrote:=
My use case is that I have a global reputation database that covers many si= tes on the web.=C2=A0 e.g. facebook, twitter, exchanges.

 Oh. You don't say. As it happens, I've had a job that I don't w= ant to influence my private reputation. I wouldn't even want you to fin= d out where that was. You can find the email address I used for that work i= f you google for the right search terms, but I don't want you to connec= t that with me.

Thanks that's a very go= od point.=C2=A0 But dont worry, our system is opt-in, so we wont take your = details, unless you choose so.=C2=A0 But I think this is off topic regardin= g my original question.
=C2=A0


Arnt

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

--001a1133b634488722050615b97e-- From nobody Thu Oct 23 05:21:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9001AD34F for ; Thu, 23 Oct 2014 05:21:37 -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 FI3O_yAtyX7P for ; Thu, 23 Oct 2014 05:21:36 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 472F81ACF6B for ; Thu, 23 Oct 2014 05:21:36 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5E326FA000C; Thu, 23 Oct 2014 12:21:34 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1414066893-4330-4329/12/39; Thu, 23 Oct 2014 12:21:33 +0000 From: Arnt Gulbrandsen To: Apps Discuss Date: Thu, 23 Oct 2014 14:21:32 +0200 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.6; X11; Linux; Ubuntu 14.04.1 LTS Mime-Version: 1.0 Message-Id: In-Reply-To: References: <71f33d9b-f73b-4431-9232-8d8ea44d411b@gulbrandsen.priv.no> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Q4yjg7V2C2j7UENY92RKFQOAHSY Subject: Re: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 12:21:37 -0000 On Thursday, October 23, 2014 1:54:16 PM CEST, Melvin Carvalho wrote: > Thanks that's a very good point. But dont worry, our system is > opt-in, so we wont take your details, unless you choose so. But > I think this is off topic regarding my original question. Not really off-topic, no... Users who don't want their various personae to be unified are _the_ reason why "acct:" exists and "user:" does not, so if you want "user:" this is the central problem to solve. The syntax is doable in five minutes afterwards. Arnt From nobody Thu Oct 23 05:50:00 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086A01A906A for ; Thu, 23 Oct 2014 05:49:54 -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, HTML_MESSAGE=0.001, MARKETING_PARTNERS=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 QnLuP7GU0Olu for ; Thu, 23 Oct 2014 05:49:52 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F011A9049 for ; Thu, 23 Oct 2014 05:49:52 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id uy5so645454obc.8 for ; Thu, 23 Oct 2014 05:49:51 -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=sfMErOOaQ4BUj8KsupsZHrTvxGCJGFZhf0Icvmm1G7A=; b=V188F8cm/phRC2r0u5zYrxFc2D9RISF9WlqXAcNLskVhl788H432KJN/k0dGJQsPzl +P5NCA9Ds6eyij+QoTn5SfvgDqjc91EkW/qMSc/4pS0oyNOczVxmYz1Nzw+JwfezVUHN u5TnF8iXJs7YOCrQ/P1+jhcPcqHrvOSGMgmts= 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=sfMErOOaQ4BUj8KsupsZHrTvxGCJGFZhf0Icvmm1G7A=; b=bSTY9dH8/sKOAjaRNkeke8n8MU1LjOjKxBN/B4LVQRO8Meof3SQ8VSr8BUhr46iuDR 4RTJy19zuFwrpkf9tX03pSLwFuldu7CKUcCtyNK9YimdVM9SrWaa7PCPUk9LcWaiPmVk CE1UIXYC8UU/3kezNtu2CIz5+WGWZ63xgsrMfjZc2Sd3500CWjf8fX14sCzJ90PTkJqC r2we70OCbaQ2kAKQgkZ78Uo/hUAtQw4nxiEDsqyP+Y63BqVu8rliFqLxzdCqcShQw0SX e2w0BUI8W1LV1qnV53ZoJvVpz70VOXr36Mtf4CIdvFBOUtFJgYJZb/YfE6cg0KLf46Zd UDrA== X-Gm-Message-State: ALoCoQkKiCYtLr2SWXJAFPSNQWUH63CQD9DGyS+Qgo4hZYMg/hSz3U6FZZrH02tkkmnpjW+9nKk6 MIME-Version: 1.0 X-Received: by 10.202.71.74 with SMTP id u71mr2392734oia.54.1414068591678; Thu, 23 Oct 2014 05:49:51 -0700 (PDT) Received: by 10.60.80.231 with HTTP; Thu, 23 Oct 2014 05:49:51 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Oct 2014 13:49:51 +0100 Message-ID: From: Dave Cridland To: Melvin Carvalho Content-Type: multipart/alternative; boundary=001a113e559e186d250506168074 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZEzq8UdHDoqyDvva7m3qBPu19Mw Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 12:49:54 -0000 --001a113e559e186d250506168074 Content-Type: text/plain; charset=UTF-8 On 23 October 2014 11:57, Melvin Carvalho wrote: > 1) Start with a URI. "acct" scheme URIs are good here. >> > > No, it isnt. I am looking for an HTTP URI. Please read the original post > or at least the title. May I request that you please stop repeating this > suggestion. > > OK. So you start with a user and domain pair, arranged artfully into a string conformant to a URI syntax. > >> 2) Translate this to JRD via WebFinger. This gives you, amongst other >> things, a "subject" - canonical URI, some "properties" - key/value string >> pairs, and some "links", giving "rel" - the relation type - and an "href". >> > > Please read my previous response. This is an impossibility. On top of my > other show stoppers, JRD requires a list of URIs to be ordered in terms of > preference, there's absolutely no way I can reliably comply to this > requirement. > > Sure, but this is not the resource you're aiming for, this is a mechanism to discover that resource across any service. It's just an intermediary. > >> 3) You register a relation type for your purposes, and then you have a >> mechanism for discovering a URI you can resolve to the object you need, in >> whatever format best suits your purpose. >> > > My purpose is to find an HTTP URI that denotes a user on our partner > site, which can be constructed from user and host key pair, in the absence > of a known profile page. I have no idea what this has to do with a link > relation. I am looking for an identifier not a relation. > > Because you have a relation type defined as your user information page, and you can then find a URI with this relation via WebFinger. > >> I'd welcome an explanation of why this won't work, given it's very close >> to what it was designed specifically for. >> > > Please reread my previous responses. If you can come up with solutions > I'd love to hear. If you are just going to repeat your webfinger / JRD > recommendations, they have been noted. > I honestly think you're missing my point entirely. An example: Start with user "bob" at domain "example.com". Let's assume your link relation type is "http://webfinger.example/rel/profile-page". The steps are: 1) HTTP GET request to http://example.com/.well-known/webfinger? resource=acct%3Abob%40example.com& rel=http%3A%2F%2Fwebfinger.example%2Frel%2Fprofile-page 2) This gives back an intermediate JRD resource: { "subject" : "acct:bob@example.com", "aliases" : [ "https://www.example.com/~bob/" ], "properties" : { "http://example.com/ns/role" : "employee" }, "links" : [ { "rel" : "http://webfinger.example/rel/profile-page", "href" : "https://www.example.com/~bob/" }, ] } 3) Your profile page URI is https://www.example.com/~bob/ Why doesn't this give you what you need? --001a113e559e186d250506168074 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 2= 3 October 2014 11:57, Melvin Carvalho <melvincarvalho@gmail.com= > wrote:
1) St= art with a URI. "acct" scheme URIs are good here.

No, it isnt.=C2=A0 I am looking = for an HTTP URI.=C2=A0 Please read the original post or at least the title.= =C2=A0 May I request that you please stop repeating this suggestion.
=C2=A0

OK. So you start with a user and domain= pair, arranged artfully into a string conformant to a URI syntax.
=C2=A0
=

2) Translate this to JRD via WebFinger. This gives you, amongst other thi= ngs, a "subject" - canonical URI, some "properties" - k= ey/value string pairs, and some "links", giving "rel" -= the relation type - and an "href".

Please read my previous response.=C2=A0 T= his is an impossibility.=C2=A0 On top of my other show stoppers, JRD requir= es a list of URIs to be ordered in terms of preference, there's absolut= ely no way I can reliably comply to this requirement.=C2=A0
=C2=A0
Sure, but this is not the resource you're aiming for, this = is a mechanism to discover that resource across any service. It's just = an intermediary.
=C2=A0

3) You register a relation type for your purpose= s, and then you have a mechanism for discovering a URI you can resolve to t= he object you need, in whatever format best suits your purpose.
=

=C2=A0My purpose is to = find an HTTP URI that denotes a user on our partner site, which can be cons= tructed from user and host key pair, in the absence of a known profile page= .=C2=A0 I have no idea what this has to do with a link relation.=C2=A0 I am= looking for an identifier not a relation.
= =C2=A0

Becau= se you have a relation type defined as your user information page, and you = can then find a URI with this relation via WebFinger.
=C2=A0

I'd wel= come an explanation of why this won't work, given it's very close t= o what it was designed specifically for.

Please reread my previous responses.=C2=A0 If = you can come up with solutions I'd love to hear.=C2=A0 If you are just = going to repeat your webfinger / JRD recommendations, they have been noted.=

I honestly thi= nk you're missing my point entirely. An example:

Start with user "bob" at domain "example.com". Let's assume your link relation type is &= quot;http://webfinger.example/rel/profile-page".


1) HTTP GET request to http://example.= com/.well-known/webfinge= r?resource=3Dacct%3Ab= ob%40example.com&rel=3Dhttp%3A%2F%2Fwebfinger.example%2= Frel%2Fprofile-page

2) This gives back an intermediate JRD resource:

{
       "subject" : "acct:bob@example.com",
       "aliases" :
       [
         "https://www.exampl=
e.com/~bob/"
       ],
       "properties" :
       {
           "http://example.com/=
ns/role" : "employee"
       },
       "links" :
       [
         {
           "rel" : "http://webfinger.example/rel/profile-page",
           "href" : "https://www.example.com/~bob/"
         },
       ]
}

3) Your profile page URI is https://www.example.com/~bob/

<=
/font>
Why doesn't th=
is give you what you need?
--001a113e559e186d250506168074-- From nobody Thu Oct 23 06:02:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAAD1A907B for ; Thu, 23 Oct 2014 06:02:49 -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 hiOcVbLqabuT for ; Thu, 23 Oct 2014 06:02:47 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A06DE1A9046 for ; Thu, 23 Oct 2014 06:02:46 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id l4so773837lbv.38 for ; Thu, 23 Oct 2014 06:02:44 -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=ExqwRRvXA+L8jbfWiFIr7IKujhxO63yM7XLzNTQiJb0=; b=QLCLXiD88gHQ5MnDLhHra5yeCLPdv6/MeOdaSr58Sp6q4EWwmffKMMFitw7MlmivEo 5q8UzzmPabmgIxlYKgz6Uzg2qLSru0eTMwP7NNA+QDuwHSdIuHWo8PvJhi2UIaAgEEM4 8yS6D1ilgskh4WEBz+zV/hcR9T0e8g6AETo0qYTo9ghb9Gy1j0cz7FoXSPBj/ceLJelH e8M3Cg+5qQsUSj/orluwVRAzmq8yhphYydruC16mhGqgaVYojRimu2kWhelHbWal2OBP CBMe4Mj6lYGYqby6YVRbEEkzEIiS6RAk0Cr9OioQUzG8h43TrFVIvfkmUSSABrIHu5bR axRQ== MIME-Version: 1.0 X-Received: by 10.152.2.41 with SMTP id 9mr4796232lar.47.1414069364411; Thu, 23 Oct 2014 06:02:44 -0700 (PDT) Received: by 10.112.1.234 with HTTP; Thu, 23 Oct 2014 06:02:44 -0700 (PDT) In-Reply-To: References: <71f33d9b-f73b-4431-9232-8d8ea44d411b@gulbrandsen.priv.no> Date: Thu, 23 Oct 2014 15:02:44 +0200 Message-ID: From: Melvin Carvalho To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=089e013c625827525f050616ae38 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/spiQH5zlcZcBtjx84mISIZZsyqY Cc: Apps Discuss Subject: Re: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 13:02:49 -0000 --089e013c625827525f050616ae38 Content-Type: text/plain; charset=UTF-8 On 23 October 2014 14:21, Arnt Gulbrandsen wrote: > On Thursday, October 23, 2014 1:54:16 PM CEST, Melvin Carvalho wrote: > >> Thanks that's a very good point. But dont worry, our system is opt-in, >> so we wont take your details, unless you choose so. But I think this is >> off topic regarding my original question. >> > > Not really off-topic, no... Users who don't want their various personae to > be unified are _the_ reason why "acct:" exists and "user:" does not, so if > you want "user:" this is the central problem to solve. The syntax is doable > in five minutes afterwards. This is off topic, apart from being inaccurate. Please read the *title* of this post, if not the content. I am looking for an HTTP URI that denotes a user, that can be constructed in a systematic way This is not a post about privacy This is not a post about alternate URI schemes to HTTP This is not a post about how to denote users using URIs This is not a post about dereferencing This is not a post asking for help to solve my use case, I provided that for context, as requested, some casual observations are welcome All these topics are interesting, and comments are welcome in passing, but it's not related my question, but please try and stay on topic, even if you want to mention other items. As I need to implement now, it seems as good a choice as any. If there's some informed opinions on this please do let me know. As well-known was designed for introspection I think it's a safe bet to say that /user/ is unlikely to be ever used for anything other than denoting a user, therefore avoiding naming clashes and ensuring longevity If anyone can answer my question as to the pros and cons of raising the template with IANA now, or after implementation, I'd be grateful to hear. > > > > Arnt > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e013c625827525f050616ae38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 23 October 2014 14:21, Arnt Gulbrandsen <arnt@gulbrandsen.pr= iv.no> wrote:
On Thursday, October 23, 2014 1:54:16 PM CEST, Melvi= n Carvalho wrote:
Thanks that's a very good point.=C2=A0 But dont worry, our system is op= t-in, so we wont take your details, unless you choose so.=C2=A0 But I think= this is off topic regarding my original question.

 Not really off-topic, no... Users who don't want their various personae= to be unified are _the_ reason why "acct:" exists and "user= :" does not, so if you want "user:" this is the central prob= lem to solve. The syntax is doable in five minutes afterwards.
=

This is off topic, apart from being inaccurate.=C2=A0 <= br>
Please read the *title* of this post, if not the content.= =C2=A0

I am looking for an HTTP URI that denotes a user,= that can be constructed in a systematic way

This is not = a post about privacy
This is not a post about alternate URI s= chemes to HTTP
This is not a post about how to denote users using URIsThis is not a post about dereferencing
This is not a post a= sking for help to solve my use case, I provided that for context, as reques= ted, some casual observations are welcome

All these topic= s are interesting, and comments are welcome in passing, but it's not re= lated my question, but please try and stay on topic, even if you want to me= ntion other items.

As I need to implement now, it seems a= s good a choice as any.=C2=A0 If there's some informed opinions on this= please do let me know.

As well-known was designed for in= trospection I think it's a safe bet to say that /user/<username> = is unlikely to be ever used for anything other than denoting a user, theref= ore avoiding naming clashes and ensuring longevity

If an= yone can answer my question as to the pros and cons of raising the template= with IANA now, or after implementation, I'd be grateful to hear.

=C2=A0
=


Arnt

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

--089e013c625827525f050616ae38-- From nobody Thu Oct 23 06:07:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963B91A907D for ; Thu, 23 Oct 2014 06:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MARKETING_PARTNERS=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 Tz9zzt4Istcc for ; Thu, 23 Oct 2014 06:06:59 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2721A9085 for ; Thu, 23 Oct 2014 06:06:58 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id s18so800433lam.37 for ; Thu, 23 Oct 2014 06:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x80ERCH6Cc8Gh7RaIw3c2D9EQQIGj4zATbJ2yMz8bHY=; b=U+oojasI+qkb0qy6i8UD63M6lN0ei6XaKsNq82EtxjMnqNxoo6UZJmYityOv4xWwdU Ha/a2vy6cqNU40AVaZjzTJerzjaV+j51GOnL4goUdhLefTxcyMZVre+3St3JZEg1RlmR 1Yxnci0JWIYuhGpNFyspXtpgOlOCU8aRN5f31qfWTigHiY3Pc6JVgyadVGx71nQLP5W1 escPF7tRPNuFmJjO3hY3pKnfi6KZuawVptOFVnnaZSr1/ssjtRLM6fFsb0mdEAdEn0iZ ZFrM1L2n4lwNF5C4RjPPWDET5zdXBDsOK8Ap2cIraCFyn3XG3T5HogQrJyzmaI5KeZxp /yQg== MIME-Version: 1.0 X-Received: by 10.112.138.196 with SMTP id qs4mr3387898lbb.83.1414069617012; Thu, 23 Oct 2014 06:06:57 -0700 (PDT) Received: by 10.112.1.234 with HTTP; Thu, 23 Oct 2014 06:06:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Oct 2014 15:06:56 +0200 Message-ID: From: Melvin Carvalho To: Dave Cridland Content-Type: multipart/alternative; boundary=089e0117699135b71c050616bdb1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/sKDA-hVUFy2c7dFSuSqj2VL0gm4 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 13:07:01 -0000 --089e0117699135b71c050616bdb1 Content-Type: text/plain; charset=UTF-8 On 23 October 2014 14:49, Dave Cridland wrote: > On 23 October 2014 11:57, Melvin Carvalho > wrote: > >> 1) Start with a URI. "acct" scheme URIs are good here. >>> >> >> No, it isnt. I am looking for an HTTP URI. Please read the original >> post or at least the title. May I request that you please stop repeating >> this suggestion. >> >> > > OK. So you start with a user and domain pair, arranged artfully into a > string conformant to a URI syntax. > > >> >>> 2) Translate this to JRD via WebFinger. This gives you, amongst other >>> things, a "subject" - canonical URI, some "properties" - key/value string >>> pairs, and some "links", giving "rel" - the relation type - and an "href". >>> >> >> Please read my previous response. This is an impossibility. On top of >> my other show stoppers, JRD requires a list of URIs to be ordered in terms >> of preference, there's absolutely no way I can reliably comply to this >> requirement. >> >> > > Sure, but this is not the resource you're aiming for, this is a mechanism > to discover that resource across any service. It's just an intermediary. > > >> >>> 3) You register a relation type for your purposes, and then you have a >>> mechanism for discovering a URI you can resolve to the object you need, in >>> whatever format best suits your purpose. >>> >> >> My purpose is to find an HTTP URI that denotes a user on our partner >> site, which can be constructed from user and host key pair, in the absence >> of a known profile page. I have no idea what this has to do with a link >> relation. I am looking for an identifier not a relation. >> >> > > Because you have a relation type defined as your user information page, > and you can then find a URI with this relation via WebFinger. > > >> >>> I'd welcome an explanation of why this won't work, given it's very close >>> to what it was designed specifically for. >>> >> >> Please reread my previous responses. If you can come up with solutions >> I'd love to hear. If you are just going to repeat your webfinger / JRD >> recommendations, they have been noted. >> > > I honestly think you're missing my point entirely. An example: > > Start with user "bob" at domain "example.com". Let's assume your link > relation type is "http://webfinger.example/rel/profile-page". > > The steps are: > > 1) HTTP GET request to http://example.com/.well-known/webfinger? > resource=acct%3Abob%40example.com& > rel=http%3A%2F%2Fwebfinger.example%2Frel%2Fprofile-page > > 2) This gives back an intermediate JRD resource: > > { > "subject" : "acct:bob@example.com", > "aliases" : > [ > "https://www.example.com/~bob/" > ], > "properties" : > { > "http://example.com/ns/role" : "employee" > }, > "links" : > [ > { > "rel" : "http://webfinger.example/rel/profile-page", > "href" : "https://www.example.com/~bob/" > }, > ] > > } > > > 3) Your profile page URI is https://www.example.com/~bob/ > > > Why doesn't this give you what you need? > > WebFinger is a dereferencing system. I am not looking for a dereferencing system, I am looking for an identification system. I am looking for an HTTP identification system because dereferencing is built in. Only someone quite insane or quite brilliant would use webfiger to dereference an HTTP URI. Hope that explains. --089e0117699135b71c050616bdb1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 23 October 2014 14:49, Dave Cridland <dave@cridland.net> wrote:
On 23 October = 2014 11:57, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
1) Start with a URI. "= ;acct" scheme URIs are good here.
=

No, it isnt.=C2=A0 I am looking for an HTTP URI.=C2= =A0 Please read the original post or at least the title.=C2=A0 May I reques= t that you please stop repeating this suggestion.
=C2=A0

OK. So you start with a user and domain pair, arranged artfull= y into a string conformant to a URI syntax.
=C2= =A0

2) Translate t= his to JRD via WebFinger. This gives you, amongst other things, a "sub= ject" - canonical URI, some "properties" - key/value string = pairs, and some "links", giving "rel" - the relation ty= pe - and an "href".

=
Please read my previous response.=C2=A0 This is an imposs= ibility.=C2=A0 On top of my other show stoppers, JRD requires a list of URI= s to be ordered in terms of preference, there's absolutely no way I can= reliably comply to this requirement.=C2=A0
=C2=A0

Sure, bu= t this is not the resource you're aiming for, this is a mechanism to di= scover that resource across any service. It's just an intermediary.
=C2=A0
3) You register a relation type for your purposes, and then yo= u have a mechanism for discovering a URI you can resolve to the object you = need, in whatever format best suits your purpose.

=C2=A0My purpose is to find an HTTP U= RI that denotes a user on our partner site, which can be constructed from u= ser and host key pair, in the absence of a known profile page.=C2=A0 I have= no idea what this has to do with a link relation.=C2=A0 I am looking for a= n identifier not a relation.
=C2=A0
<= /div>

Because you have a relat= ion type defined as your user information page, and you can then find a URI= with this relation via WebFinger.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">

I'd welcome an expla= nation of why this won't work, given it's very close to what it was= designed specifically for.

Please reread my previous responses.=C2=A0 If you can come = up with solutions I'd love to hear.=C2=A0 If you are just going to repe= at your webfinger / JRD recommendations, they have been noted.

I honestly think you= 're missing my point entirely. An example:

Sta= rt with user "bob" at domain "example.com". Let's assume your link relati= on type is "http://webfing= er.example/rel/profile-page".

The = steps are:

1) HTTP GET request to http://example.com/.well-known/webfinger?resource=3Dacct%3Abob%40example.com&rel=3Dhttp%3A%2F%2Fwebfinger.example%2Frel%2Fpr= ofile-page

2)= This gives back an intermediate JRD resource:

{
       "subject" : "acct:bob@example.com",
       "aliases" :
       [
         "=
https://www.example.com/~bob/"
       ],
       "properties" :
       {
           "h=
ttp://example.com/ns/role" : "employee"
       },
       "links" :
       [
         {
           "rel" : "http://webfinger.example/rel/profile-page",
           "href" : "https://www.example.com/~bob/"
         },
       ]
}

3) Your profile page URI is https://www.example.com/~bob/
= 
Why doesn't this give you what you need?

WebFinger is a d= ereferencing system.=C2=A0 I am not looking for a dereferencing system, I a= m looking for an identification system.=C2=A0 I am looking for an HTTP iden= tification system because dereferencing is built in.=C2=A0 Only someone qui= te insane or quite brilliant would use webfiger to dereference an HTTP URI.= =C2=A0 Hope that explains.

--089e0117699135b71c050616bdb1-- From nobody Thu Oct 23 06:17:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341051A90A3 for ; Thu, 23 Oct 2014 06:17:22 -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 rmdKRYurwGPB for ; Thu, 23 Oct 2014 06:17:20 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E081A90A2 for ; Thu, 23 Oct 2014 06:17:20 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 504A1FA000C; Thu, 23 Oct 2014 13:17:18 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1414070237-4330-4329/12/40; Thu, 23 Oct 2014 13:17:17 +0000 From: Arnt Gulbrandsen To: Apps Discuss Date: Thu, 23 Oct 2014 15:17:17 +0200 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.6; X11; Linux; Ubuntu 14.04.1 LTS Mime-Version: 1.0 Message-Id: In-Reply-To: References: <71f33d9b-f73b-4431-9232-8d8ea44d411b@gulbrandsen.priv.no> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/G4v7matsqrQaWVk7rLyxOFwfzSE Subject: Re: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 13:17:22 -0000 What I'm trying to say is this: If a user isn't an account, then it needs to be something else, and that something else has to be defined. The IETF is a standards organzation, and standards organizations don't leave central terms undefined. So how do you define a user, if it's not an account? "A set of accounts that claim to be the same", "a connected set of accounts for which there exist third-party claims of pairwise identity, with the meaning of identity defined by the third-party claimant", or something else? Arnt From nobody Thu Oct 23 06:28:21 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309D11A1A72 for ; Thu, 23 Oct 2014 06:28: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 FlnWAe_Y3twQ for ; Thu, 23 Oct 2014 06:28:16 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8D5D1A90B6 for ; Thu, 23 Oct 2014 06:28:15 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gi9so832675lab.21 for ; Thu, 23 Oct 2014 06:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FlAO0kPVQxeFjLAXJu1GkWr781akq8vzYzCW2MhZA/Y=; b=dexY6Dpxvv+i1KQ/OPv/FRPReqvo/ETykjjNkKZE7Fzpv/SYwwaywsbw0twHdr7DJo 5t1QMVBPlS1r3jgIe/HfrCOIbBHMoNVWLt1+QF3CQZOvCy6wCWMTCdAbWqgm9pK5LiF9 45rHnDLf79DyrFOz3QgQOxR4UKzRlnqztwBtIiDdSiYEySuBqsTXmgWEpSNmGZC6XhFx +8apEcuydfUiexWaUWLgceCyJ+eJLFA4Qe1J92OEeD9Flmqs5wcEUIf/vCt2UtSQunpp B1FusZe7ESa1k8Usy11Gjt+4MzrXGHVo46lDj/pNdH1l4wOhw1AXznsr+Dnrn4DL2V5D SI1A== MIME-Version: 1.0 X-Received: by 10.152.8.136 with SMTP id r8mr3331712laa.91.1414070893882; Thu, 23 Oct 2014 06:28:13 -0700 (PDT) Received: by 10.112.1.234 with HTTP; Thu, 23 Oct 2014 06:28:13 -0700 (PDT) In-Reply-To: References: <71f33d9b-f73b-4431-9232-8d8ea44d411b@gulbrandsen.priv.no> Date: Thu, 23 Oct 2014 15:28:13 +0200 Message-ID: From: Melvin Carvalho To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=089e0158ae545133e005061709b5 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/gPepJl9WU9HClkh6zcOCAQMjP3E Cc: Apps Discuss Subject: Re: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 13:28:18 -0000 --089e0158ae545133e005061709b5 Content-Type: text/plain; charset=UTF-8 On 23 October 2014 15:17, Arnt Gulbrandsen wrote: > What I'm trying to say is this: If a user isn't an account, then it needs > to be something else, and that something else has to be defined. The IETF > is a standards organzation, and standards organizations don't leave central > terms undefined. > > So how do you define a user, if it's not an account? "A set of accounts > that claim to be the same", "a connected set of accounts for which there > exist third-party claims of pairwise identity, with the meaning of identity > defined by the third-party claimant", or something else? Good question. I would personally define a user the same way as facebook do ( via open graph which gives first name, last name etc.) or similar to schema.org Person or foaf person. Not everyone feels the same way on that definition, and the modelling can differ. The account / user delineation is a topic of discussion and in truth hard to define 100%. However, I do feel it would be incorrect to say user and account are the same thing always. In my case I am dealing with units of value so the difference to me can be critical, just as a bank account is not the person that owns the balance. > > > Arnt > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e0158ae545133e005061709b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 23 October 2014 15:17, Arnt Gulbrandsen <arnt@gulbrandsen.pr= iv.no> wrote:
What I'm = trying to say is this: If a user isn't an account, then it needs to be = something else, and that something else has to be defined. The IETF is a st= andards organzation, and standards organizations don't leave central te= rms undefined.

So how do you define a user, if it's not an account? "A set of acc= ounts that claim to be the same", "a connected set of accounts fo= r which there exist third-party claims of pairwise identity, with the meani= ng of identity defined by the third-party claimant", or something else= ?

Good question.=C2=A0 I would personally d= efine a user the same way as facebook do ( via open graph which gives first= name, last name etc.) or similar to schema.o= rg Person or foaf person.=C2=A0 Not everyone feels the same way on that= definition, and the modelling can differ.=C2=A0 The account / user delinea= tion is a topic of discussion and in truth hard to define 100%.=C2=A0 Howev= er, I do feel it would be incorrect to say user and account are the same th= ing always.=C2=A0 In my case I am dealing with units of value so the differ= ence to me can be critical, just as a bank account is not the person that o= wns the balance.
=C2=A0
<= div class=3D"HOEnZb">


Arnt

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

--089e0158ae545133e005061709b5-- From nobody Thu Oct 23 06:40:20 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF041A90D8 for ; Thu, 23 Oct 2014 06:40:19 -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 aUDZ2uRbHKcu for ; Thu, 23 Oct 2014 06:40:17 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6EF61A1A72 for ; Thu, 23 Oct 2014 06:40:16 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id gm9so842588lab.41 for ; Thu, 23 Oct 2014 06:40:12 -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=cGL9vJCrLfpfz2wIkeKOJ+6jwzJ7qtor0l/94TlIyFQ=; b=KuPZ+9In091aE6n8iANagh84FBZVNy7LLlfaZL7bQdwLlxa5kzeCRmM8mus5+UEPB+ W3ckEAFewT8xHx64b9QXUEMaun0EVuTueOGsWstazfm/77nehvZJxQjh6c4XCcE+AgBh Pd4HqXb6IWiRsy0xztLy4GCp2yCVEWUX4itJxU+A4iPgVw7kdkYwVMAcYGrpiXmfqn2X 1Htcoi8ei/r8510RShByPfjxTRHGBhVnyUUbYLCjhZDpSpmIbtWTL51IxfQS9B9LlUng wM3xfkb987NggsNHPl3svZE9bifHZEagjfQPuoBjfZ+kGXEbw2vwhvZGXVbeohZJDh9Z A6Kg== MIME-Version: 1.0 X-Received: by 10.112.138.196 with SMTP id qs4mr3601066lbb.83.1414071612883; Thu, 23 Oct 2014 06:40:12 -0700 (PDT) Received: by 10.112.1.234 with HTTP; Thu, 23 Oct 2014 06:40:12 -0700 (PDT) In-Reply-To: References: <71f33d9b-f73b-4431-9232-8d8ea44d411b@gulbrandsen.priv.no> Date: Thu, 23 Oct 2014 15:40:12 +0200 Message-ID: From: Melvin Carvalho To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=089e011769912c496705061734a5 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6wbv15_7_oUPeR-szbj0T5AcPD8 Cc: Apps Discuss Subject: Re: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 13:40:19 -0000 --089e011769912c496705061734a5 Content-Type: text/plain; charset=UTF-8 On 23 October 2014 15:17, Arnt Gulbrandsen wrote: > What I'm trying to say is this: If a user isn't an account, then it needs > to be something else, and that something else has to be defined. The IETF > is a standards organzation, and standards organizations don't leave central > terms undefined. > BTW I'd be fairly confident that if you were to ask anyone outside of the IETF (or maybe even inside) the term "user" would be much more common than "account" in reference to the entities we are discussing. Just my opinion. > > So how do you define a user, if it's not an account? "A set of accounts > that claim to be the same", "a connected set of accounts for which there > exist third-party claims of pairwise identity, with the meaning of identity > defined by the third-party claimant", or something else? > > > Arnt > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e011769912c496705061734a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 23 October 2014 15:17, Arnt Gulbrandsen <arnt@gulbrandsen.pr= iv.no> wrote:
What I'm = trying to say is this: If a user isn't an account, then it needs to be = something else, and that something else has to be defined. The IETF is a st= andards organzation, and standards organizations don't leave central te= rms undefined.

BTW I'd be fairly co= nfident that if you were to ask anyone outside of the IETF (or maybe even i= nside) the term "user" would be much more common than "accou= nt" in reference to the entities we are discussing.=C2=A0 Just my opin= ion.=C2=A0
=C2=A0

So how do you define a user, if it's not an account? "A set of acc= ounts that claim to be the same", "a connected set of accounts fo= r which there exist third-party claims of pairwise identity, with the meani= ng of identity defined by the third-party claimant", or something else= ?


Arnt

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

--089e011769912c496705061734a5-- From nobody Thu Oct 23 06:43:49 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635401A7001 for ; Thu, 23 Oct 2014 06:43:47 -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 9laAGYr1O9Jo for ; Thu, 23 Oct 2014 06:43:44 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7581A1A72 for ; Thu, 23 Oct 2014 06:43:43 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id n15so832228lbi.25 for ; Thu, 23 Oct 2014 06:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n+Ne/ukHWjXXM68fqKRkQvFcOLlhI3kdaA27jR6Yj50=; b=RfcJC/WzkZ0xm3GFJ6csZphLtXyj15zzOerTmQ9rf9LCSoG/2R7Ds8nOpf/D8y/ja5 MugcxukhII/FoG68tGDKoUWdx5BBokiV7z65A6cIOTbggRH6UhachebPwC0qCjry4XLb aH6IgYsm2YTntQaJ+LBnqxOQKA37V9KqAMsK7Es87jn/+Xnk7U3R0fQSmO6Cd+SDzYhH V1UPMrfTYpRzC0n0E04Kv2sL42/zCfCflzVUPEjaCSVYalE0XM2YFpmbDfLW+eR592D9 8SbZY1+7Q/0tvg3XTaBtoiK8ge3qM0HzHrWAP80vOdWwWeh6JiAM9KXUxsMnU6WbNiEp Fa0w== MIME-Version: 1.0 X-Received: by 10.112.45.228 with SMTP id q4mr5215827lbm.35.1414071821757; Thu, 23 Oct 2014 06:43:41 -0700 (PDT) Received: by 10.112.1.234 with HTTP; Thu, 23 Oct 2014 06:43:41 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Oct 2014 15:43:41 +0200 Message-ID: From: Melvin Carvalho To: Dave Cridland Content-Type: multipart/alternative; boundary=001a11345f6a9f72120506174074 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7jBpGFEWPsgz7omx2LGRduWKT50 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 13:43:47 -0000 --001a11345f6a9f72120506174074 Content-Type: text/plain; charset=UTF-8 On 22 October 2014 23:01, Dave Cridland wrote: > On 22 October 2014 20:15, Melvin Carvalho > wrote: > >> 1. I am modelling a user and NOT an account, so this would be a misuse of >> the term. For my use case there is a very important distinction here, just >> as a bank account is not the same as a bank user. >> >> > I'm pretty sure this is either incorrect, or just a non-starter. > > Incorrect, because for nearly every purpose, an account is essentially a > user. > > A non-starter, because if you're actually after a URI mechanism to > identify natural persons, I suspect you're trying to do something badly > wrong. > > >> 2. Even if acct: could be reused (it cant imho), I am looking for a well >> known HTTP URI that denotes a user. Why HTTP? Because that's the protocol >> of the web, and everything talks it. >> >> > OK. So "acct" is the wrong scheme because it's not an account you're > trying to identify (though I suspect it is, really - it's your case (1) in > your original mail), but "http" is OK, because although it's most certainly > not a scheme for identifying natural persons, it's "the protocol of the > web". > > >> I've had the following suggestions: >> >> - http://user@host/ -- this passes the RFC and would be perfect, but >> guess what? Browsers fail on it. Snowball's chance in hell getting the >> WHATWG folks to fix it, imho. >> >> > I don't think that form means what you seem to think it means. The > userinfo portion of the authority relates to authorization identities. > I'd like to clear up a common misconception here: The userinfo portion of a URI (per RFC3986 provides for such a format in HTTP URLs: The userinfo subcomponent may consist of a user name and, optionally, scheme-specific information about how to gain authorization to access the resource. There's more in that spec and in the more recent httpbis that runs away from the use of this userinfo URI component, but there is untapped value here. Additionally, the userinfo portion of the URL is mentioned in the WHATWG URL spec as follows: Userinfo must be a username, optionally followed by a ":" and a password. http://userinfo.me/ > > >> - http://host/@user -- seems OK, but can you get people to agree, I >> doubt it >> >> - http://host/@/user -- seems OK, but can you get people to agree, I >> doubt it >> >> - http://host/~user -- seems OK, but can you get people to agree, I >> doubt it >> >> > No, you - more or less - cannot standardize paths of URIs. > > You want acct:user@host - and resolve it with WebFInger and a link type > if you want something HTMLish. > > >> All that remains is the /well-known/ pattern. >> >> It's already established that well-known is used when all else fails, and >> has sub directories. >> >> .well-known/user/mark >> >> Well what else could it mean? I think it's about as unambiguous as it >> gets, no room for collisions. It also gives me and other implementations a >> standard way to construct an identifer and introspect on one. >> >> If there's a better way I'd love to hear. >> >> > Yes, there is. > > You could use acct URIs to identify the user, and WebFinger top resolve > them, which is specifically designed for this case. You seem to want an > HTML resource - it's not clear why - so why not define a link type of > whatever it is you want? > > Dave. > --001a11345f6a9f72120506174074 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 22 October 2014 23:01, Dave Cridland <dave@cridland.net> wrote:
On 22 Octobe= r 2014 20:15, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
1. I= =20 am modelling a user and NOT an account, so this would be a misuse of the term.=C2=A0 For my use case there is a very important distinction here, ju= st as a bank account is not the same as a bank user.


I'm pretty sure this is e= ither incorrect, or just a non-starter.

Incorrect,= because for nearly every purpose, an account is essentially a user.
<= div>
A non-starter, because if you're actually after a UR= I mechanism to identify natural persons, I suspect you're trying to do = something badly wrong.
=C2=A0
2.=20 Even if acct: could be reused (it cant imho), I am looking for a well=20 known HTTP URI that denotes a user.=C2=A0 Why HTTP?=C2=A0 Because that'= s the=20 protocol of the web, and everything talks it.=C2=A0


OK. So "acct" is = the wrong scheme because it's not an account you're trying to ident= ify (though I suspect it is, really - it's your case (1) in your origin= al mail), but "http" is OK, because although it's most certai= nly not a scheme for identifying natural persons, it's "the protoc= ol of the web".
=C2=A0
I've had the following suggestions:<= br>
- http://user@host/ -- this passes the RFC and would be perfect, but=20 guess what?=C2=A0 Browsers fail on it.=C2=A0 Snowball's chance in hell = getting the WHATWG folks to fix it, imho.


I don't think that form means what you seem t= o think it means. The userinfo portion of the authority relates to authoriz= ation identities.

I= 'd like to clear up a common misconception here:

The userinfo po= rtion of a URI (per RFC3986 provides for such a format in HTTP URLs:
The userinfo subcomponent may consist of a user name and, optionally, sche= me-specific information about how to gain authorization to access the resou= rce.

There's more in that spec and in the more recent httpbis th= at runs away from the use of this userinfo URI component, but there is unta= pped value here.

Additionally, the userinfo portion of the URL is me= ntioned in the WHATWG URL spec as follows:

Userinfo must be a userna= me, optionally followed by a ":" and a password.

http://userinfo.me/
=C2=A0
=C2=A0
- http://host/@user -- seems OK, but can you = get people to agree, I doubt it

- http://host/@/user -- seems OK, but can you get peo= ple to agree, I doubt it

=C2=A0- http://host/~user -- seems OK, but can = you get people to agree, I doubt it


No, you - more or less - cannot standardize = paths of URIs.

You want acct:user@host - and resol= ve it with WebFInger and a link type if you want something HTMLish.
=C2=A0
All that remains is the /well-known/ pattern.

It= 's already established that well-known is used when all else fails, and= has sub directories.

.well-known/user/mark

=
Well what else could it mean?=C2=A0 I think it's about as unambiguous as it= gets, no room for collisions.=C2=A0 It also gives me and other implementations a= =20 standard way to construct an identifer and introspect on one.

=
If there's a better way I'd love to hear.

<= /div>

Yes, there is.
=
You could use acct URIs to identify the user, and WebFinger = top resolve them, which is specifically designed for this case. You seem to= want an HTML resource - it's not clear why - so why not define a link = type of whatever it is you want?

Dave.

--001a11345f6a9f72120506174074-- From nobody Thu Oct 23 06:46:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADEC1A1A72 for ; Thu, 23 Oct 2014 06:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 TWVJ_Pw6Ln1N for ; Thu, 23 Oct 2014 06:46:05 -0700 (PDT) Received: from smtp.hethane.se (smtp.hethane.se [IPv6:2001:470:28:b88::]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CF8A1A90CD for ; Thu, 23 Oct 2014 06:46:05 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <71f33d9b-f73b-4431-9232-8d8ea44d411b@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Mikael Nordfeldth Date: Thu, 23 Oct 2014 15:46:01 +0200 To: Melvin Carvalho Message-ID: <233B7918-C453-46B6-937F-4824B70F4EE7@hethane.se> Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/lQk8hggwY5JcGdiGMPfjGdlO08Q Cc: Apps Discuss Subject: Re: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 13:46:07 -0000 I'll be brief and won't comment further within this thread. I think it's getting out of hand with repetitive arguments. Melvin Carvalho skrev: (23 oktober 2014 15:02:44 CEST) > >Please read the *title* of this post, if not the content. > >I am looking for an HTTP URI that denotes a user, that can be >constructed >in a systematic way I think it's pretty obvious by now that noone on this list has found/thought of/presented a standardised way of doing what you're asking about specifically. My suggestion for your system is to simply define something yourself, keep it flexible and hope it gets to good use. Apart from that, please note that not always is the best solution exactly what one was thought to be looking for. An acct URI may not be an http URI, but solves all problems this thread has been presented. Except being an HTTP URI (but acct can undoubtedly refer to http through for example webfinger lookup). Lastly: With specifically requiring an HTTP URI, you're ignoring a major part of the web moving to HTTPS, without a good negotiation procedure. -- Mikael Nordfeldth XMPP/mail: mmn@hethane.se From nobody Thu Oct 23 06:54:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAAB01A9169 for ; Thu, 23 Oct 2014 06:54:40 -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 0715LPCBENzP for ; Thu, 23 Oct 2014 06:54:39 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBAAC1A8BC2 for ; Thu, 23 Oct 2014 06:54:02 -0700 (PDT) Received: by mail-oi0-f43.google.com with SMTP id u20so743958oif.16 for ; Thu, 23 Oct 2014 06:54:02 -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=E9Rz3VGBUQUYX/rrCCbBagIE2riOl5kcDOBMSw5SO8Y=; b=cswqwoPO4FYAwTLdkijxsgTINiMtglvJ9ToHXqNGCkL0MzJiFL5AYlRaInUPAss10x 5ZCIInWykCvJLHRM4GqsPy5XmwUV4cEhariO3rovxkemCF7ZpDJS73rx2JRvjaWlIpxF wHUsBsp828+1rYBDZb776qCGOdAMVGFxdlxkc= 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=E9Rz3VGBUQUYX/rrCCbBagIE2riOl5kcDOBMSw5SO8Y=; b=H7gwsRjQSqCbr1dF7pp15cL1b88sXXJuvJvfCGf7R6SKXtQSsuBqlWx2a0ZbJ3DHQW 0XP0omV14kLcbEtqdMVthu3VK7BzEQVyvk66kkDa6WnIGBW0gWsfVSv6AwJUaZzFvNb+ xEJpJP+vFDNdwLzNMFHNR5U8xZgz1BRxdkIzFnsvs4VGEaiNkEE2F6voV21BpZhGuXZi RqL+qIkC0Gq6jCBoKTlQ0HBXm5uocF3WMryLJw01U+DBh+trs743UASm3RfFrF8tpXOM QvIdMUQGPBhIxOK1K/cc1J7YLB4VPeAqCxt0NnGHEJ7T1GVwtpeKJ39L6Kav5bD2weI6 k8OA== X-Gm-Message-State: ALoCoQkiM64DhwoEaUIbrMWmUIQTvpr7oF4pZfBqbP0rSloGtJZdtu+dvS17yjQyLAf5phb3b8Od MIME-Version: 1.0 X-Received: by 10.182.149.162 with SMTP id ub2mr458528obb.86.1414072442336; Thu, 23 Oct 2014 06:54:02 -0700 (PDT) Received: by 10.60.80.231 with HTTP; Thu, 23 Oct 2014 06:54:02 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Oct 2014 14:54:02 +0100 Message-ID: From: Dave Cridland To: Melvin Carvalho Content-Type: multipart/alternative; boundary=001a113489109ccc8c05061765ba Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zHRVL1CdQT3IkdhBOFvvX6JZlB4 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 13:54:40 -0000 --001a113489109ccc8c05061765ba Content-Type: text/plain; charset=UTF-8 On 23 October 2014 14:43, Melvin Carvalho wrote: > > > On 22 October 2014 23:01, Dave Cridland wrote: > >> I don't think that form means what you seem to think it means. The >> userinfo portion of the authority relates to authorization identities. >> > > I'd like to clear up a common misconception here: > > The userinfo portion of a URI (per RFC3986 provides for such a format in > HTTP URLs: > > The userinfo subcomponent may consist of a user name and, optionally, > scheme-specific information about how to gain authorization to access the > resource. > > There's more in that spec and in the more recent httpbis that runs away > from the use of this userinfo URI component, but there is untapped value > here. > > Additionally, the userinfo portion of the URL is mentioned in the WHATWG > URL spec as follows: > > Userinfo must be a username, optionally followed by a ":" and a password. > > http://userinfo.me/ > > You appreciate that the user here is being passed as the Authorization identifier in a Basic auth header field, thus confirming precisely what I said? (I love that the author of that page thinks that the colon shouldn't be included in the header field, which is clearly incorrect). I agree unreservedly that it's possible to misuse it in this way, however to claim that my understanding is a "common misconception" is unsupported by the specifications. Dave. --001a113489109ccc8c05061765ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 2= 3 October 2014 14:43, Melvin Carvalho <melvincarvalho@gmail.com= > wrote:

<= div class=3D"gmail_extra">
O= n 22 October 2014 23:01, Dave Cridland <dave@cridland.net> w= rote:
I don't think that form means what you seem to think it means.= The userinfo portion of the authority relates to authorization identities.=

I'd lik= e to clear up a common misconception here:

The userinfo portion of a= URI (per RFC3986 provides for such a format in HTTP URLs:

The useri= nfo subcomponent may consist of a user name and, optionally, scheme-specifi= c information about how to gain authorization to access the resource.
There's more in that spec and in the more recent httpbis that runs aw= ay from the use of this userinfo URI component, but there is untapped value= here.

Additionally, the userinfo portion of the URL is mentioned in= the WHATWG URL spec as follows:

Userinfo must be a username, option= ally followed by a ":" and a password.

http://userinfo.me/
=C2=A0

You appreciate that the user here is being passed as the Authorization id= entifier in a Basic auth header field, thus confirming precisely what I sai= d? (I love that the author of that page thinks that the colon shouldn't= be included in the header field, which is clearly incorrect).
I agree unreservedly that it's possible to misuse it in th= is way, however to claim that my understanding is a "common misconcept= ion" is unsupported by the specifications.

Da= ve.
--001a113489109ccc8c05061765ba-- From nobody Thu Oct 23 06:54:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AFE1A6FBF for ; Thu, 23 Oct 2014 06:54:46 -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 wqLC5Ne63T9f for ; Thu, 23 Oct 2014 06:54:42 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A70B21A9120 for ; Thu, 23 Oct 2014 06:54:28 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id mc6so1126183lab.2 for ; Thu, 23 Oct 2014 06:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Fvad9Xy7yo1tH6o7qBNb+5Hdgmvds3DSURChE4y+iyc=; b=N9RVX/D7E2zVDG1+0p7dQpuGfW/6ImjBwOrG4SX1WzKuvdZ+zTVpznSujEELJUD2Xw LT6dIkeQYzhnrsTeUGyw1xWGEh48LdXP1tj8+oszX8U5r27vSZKkBCgiWyFtc3U3W/C0 9x17VtpxpF6nOe0DHq/RvH40ZYrZucpRgd6l1G0Yspeuc2k9//N2aqOS/NXMC0Do3hUG /V5LmgVqVpQoa+t+sF4fgxEGtH0BaRdZzhCkYl8SWKJJYrwxdui7Roqw/iDqD4Of8zws X4ijOiuSTb58sA4zO8rJuLmgey2jKQITE1dM1IvYlfDDQ2qAWTdifROk0F8gQ/T17zLI sWYw== MIME-Version: 1.0 X-Received: by 10.112.45.228 with SMTP id q4mr5284095lbm.35.1414072466994; Thu, 23 Oct 2014 06:54:26 -0700 (PDT) Received: by 10.112.1.234 with HTTP; Thu, 23 Oct 2014 06:54:26 -0700 (PDT) In-Reply-To: <233B7918-C453-46B6-937F-4824B70F4EE7@hethane.se> References: <71f33d9b-f73b-4431-9232-8d8ea44d411b@gulbrandsen.priv.no> <233B7918-C453-46B6-937F-4824B70F4EE7@hethane.se> Date: Thu, 23 Oct 2014 15:54:26 +0200 Message-ID: From: Melvin Carvalho To: Mikael Nordfeldth Content-Type: multipart/alternative; boundary=001a11345f6a14fa700506176792 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-kU-YR_Ru7kd5VUPVyrf2kO3mVM Cc: Apps Discuss Subject: Re: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 13:54:46 -0000 --001a11345f6a14fa700506176792 Content-Type: text/plain; charset=UTF-8 On 23 October 2014 15:46, Mikael Nordfeldth wrote: > I'll be brief and won't comment further within this thread. I think it's > getting out of hand with repetitive arguments. > +1 thanks > > Melvin Carvalho skrev: (23 oktober 2014 > 15:02:44 CEST) > > > >Please read the *title* of this post, if not the content. > > > >I am looking for an HTTP URI that denotes a user, that can be > >constructed > >in a systematic way > > I think it's pretty obvious by now that noone on this list has > found/thought of/presented a standardised way of doing what you're asking > about specifically. > > My suggestion for your system is to simply define something yourself, keep > it flexible and hope it gets to good use. > Agreed. In that case although http://user@host is the correct thing to do and follows the RFC, the browsers (sadly) do not. So I'll go with /.well-known/user/ In IETF style I'll just ask if anyone could not live with that. > > Apart from that, please note that not always is the best solution exactly > what one was thought to be looking for. An acct URI may not be an http URI, > but solves all problems this thread has been presented. Except being an > HTTP URI (but acct can undoubtedly refer to http through for example > webfinger lookup). > Also agreed. I did consider it but our data is not translatable to JRD so would not be compatible with webfinger lookup, which would defeat the main benefit, unfortunately. Future versions of the spec may well work tho. > > Lastly: > With specifically requiring an HTTP URI, you're ignoring a major part of > the web moving to HTTPS, without a good negotiation procedure. > Yes a good point. Always comes up at some point. Thanks, I will consider. No one answered my question about raising an IANA template, tho. If there's any guidance there, it's welcome. > > -- > Mikael Nordfeldth > XMPP/mail: mmn@hethane.se > --001a11345f6a14fa700506176792 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 23 October 2014 15:46, Mikael Nordfeldth <mmn@hethane.se> wrote:
I'll be brief and won't = comment further within this thread. I think it's getting out of hand wi= th repetitive arguments.

+1 thanks
<= /div>
=C2=A0

Melvin Carvalho <melvincarva= lho@gmail.com> skrev: (23 oktober 2014 15:02:44 CEST)
>
>Please read the *title* of this post, if not the content.
>
>I am looking for an HTTP URI that denotes a user, that can be
>constructed
>in a systematic way

I think it's pretty obvious by now that noone on this list has f= ound/thought of/presented a standardised way of doing what you're askin= g about specifically.

My suggestion for your system is to simply define something yourself, keep = it flexible and hope it gets to good use.

Agreed.=C2=A0 In that case although http://user@host is the correct thin= g to do and follows the RFC, the browsers (sadly) do not.=C2=A0 So I'll= go with

/.well-known/user/<username>

=
In IETF style I'll just ask if anyone could not live with that.=C2= =A0
=C2=A0

Apart from that, please note that not always is the best solution exactly w= hat one was thought to be looking for. An acct URI may not be an http URI, = but solves all problems this thread has been presented. Except being an HTT= P URI (but acct can undoubtedly refer to http through for example webfinger= lookup).

Also agreed.=C2=A0 I did cons= ider it but our data is not translatable to JRD so would not be compatible = with webfinger lookup, which would defeat the main benefit, unfortunately.= =C2=A0 Future versions of the spec may well work tho.
=C2=A0<= /div>

Lastly:
With specifically requiring an HTTP URI, you're ignoring a major part o= f the web moving to HTTPS, without a good negotiation procedure.

Yes a good point.=C2=A0 Always comes up at some p= oint.=C2=A0 Thanks, I will consider.

No one answered my q= uestion about raising an IANA template, tho.=C2=A0 If there's any guida= nce there, it's welcome.
=C2=A0

--
Mikael Nordfeldth
XMPP/mail: mmn@hethane.se

--001a11345f6a14fa700506176792-- From nobody Thu Oct 23 06:57:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30B31A90DF for ; Thu, 23 Oct 2014 06:57:07 -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 DKa-oGvnUaBT for ; Thu, 23 Oct 2014 06:57:05 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F177E1A6FBF for ; Thu, 23 Oct 2014 06:57:04 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id q1so897539lam.36 for ; Thu, 23 Oct 2014 06:57:03 -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=7IXAEQQdZ1YlaNZ4fNf7eexmBAgE9fNhvxcgFfNpH90=; b=KaOPChTOaB9oDOlArK4vtktIP1Qq4BuRih6Ko8ucvkoDhelYQcFUA7Vfm/NsZe8PRP kXj+gc98aFg82gmFRD6N7V4ZAFi6NXfwWzSrjPIgvSDCtoFixvuULhaseapIx6yypUXM SxYVLL9Ms9DzSlVt0xwGCQHn2UwMBjpb78b0jQYIBZ0lnbv9kG0yoZEM3+H1hZ5BSLoG piVrKvunnm4UWf6m1UZXJzv/mMezHOoH1j20W3TLILoMMcUy5PdMDiO/xWQslvFVGSNK QXeRXTodgemilPj45a17y20T2cistb+eHAV+XJ4ZUa5Oo1ASDvblwigdGxgex0ICk0UV nTnw== MIME-Version: 1.0 X-Received: by 10.112.169.6 with SMTP id aa6mr5330157lbc.29.1414072622561; Thu, 23 Oct 2014 06:57:02 -0700 (PDT) Received: by 10.112.1.234 with HTTP; Thu, 23 Oct 2014 06:57:02 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Oct 2014 15:57:02 +0200 Message-ID: From: Melvin Carvalho To: Dave Cridland Content-Type: multipart/alternative; boundary=001a11c38e965ac0d0050617705f Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Ah09DAc2UXmP4-W3w_IkB_mnvzE Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Fwd: Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 13:57:07 -0000 --001a11c38e965ac0d0050617705f Content-Type: text/plain; charset=UTF-8 On 23 October 2014 15:54, Dave Cridland wrote: > On 23 October 2014 14:43, Melvin Carvalho > wrote: > >> >> >> On 22 October 2014 23:01, Dave Cridland wrote: >> >>> I don't think that form means what you seem to think it means. The >>> userinfo portion of the authority relates to authorization identities. >>> >> >> I'd like to clear up a common misconception here: >> >> The userinfo portion of a URI (per RFC3986 provides for such a format in >> HTTP URLs: >> >> The userinfo subcomponent may consist of a user name and, optionally, >> scheme-specific information about how to gain authorization to access the >> resource. >> >> There's more in that spec and in the more recent httpbis that runs away >> from the use of this userinfo URI component, but there is untapped value >> here. >> >> Additionally, the userinfo portion of the URL is mentioned in the WHATWG >> URL spec as follows: >> >> Userinfo must be a username, optionally followed by a ":" and a password. >> >> http://userinfo.me/ >> >> > > You appreciate that the user here is being passed as the Authorization > identifier in a Basic auth header field, thus confirming precisely what I > said? (I love that the author of that page thinks that the colon shouldn't > be included in the header field, which is clearly incorrect). > > I agree unreservedly that it's possible to misuse it in this way, however > to claim that my understanding is a "common misconception" is unsupported > by the specifications. > I didnt. I will look that up, thank you. If correct, perhaps a discussion for another thread. In any case, I cant use this pattern. > > Dave. > --001a11c38e965ac0d0050617705f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 23 October 2014 15:54, Dave Cridland <dave@cridland.net> wrote:
On 23 October = 2014 14:43, Melvin Carvalho <melvincarvalho@gmail.com> wrote:


On 22 October 2014 23:01, Dave Cridland <dave@cridland.net> wrote:
I don't think that form means what you seem to= think it means. The userinfo portion of the authority relates to authoriza= tion identities.

=
I'd like to clear up a common misconception here:

The useri= nfo portion of a URI (per RFC3986 provides for such a format in HTTP URLs:<= br>
The userinfo subcomponent may consist of a user name and, optionally= , scheme-specific information about how to gain authorization to access the= resource.

There's more in that spec and in the more recent http= bis that runs away from the use of this userinfo URI component, but there i= s untapped value here.

Additionally, the userinfo portion of the URL= is mentioned in the WHATWG URL spec as follows:

Userinfo must be a = username, optionally followed by a ":" and a password.

http://userinfo.me/
=C2=A0
<= br>
You appreciate that the user here is being passed as the Auth= orization identifier in a Basic auth header field, thus confirming precisel= y what I said? (I love that the author of that page thinks that the colon s= houldn't be included in the header field, which is clearly incorrect).<= /div>

I agree unreservedly that it's possible to mis= use it in this way, however to claim that my understanding is a "commo= n misconception" is unsupported by the specifications.

I didnt.=C2=A0 I will look that up= , thank you.=C2=A0 If correct, perhaps a discussion for another thread.=C2= =A0 In any case, I cant use this pattern.
=C2=A0
Dave.

--001a11c38e965ac0d0050617705f-- From nobody Thu Oct 23 15:16:13 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54F71A8A4E for ; Thu, 23 Oct 2014 03:24: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, 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 RbYpdvu1pT1m for ; Thu, 23 Oct 2014 03:24:12 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id AE8961A8A47 for ; Thu, 23 Oct 2014 03:24:11 -0700 (PDT) Received: from [192.168.1.64] (78.72.130.23) by smtp-out12.han.skanova.net (8.5.142.07) (authenticated as u57601879) id 5435BD330034806D; Thu, 23 Oct 2014 12:23:48 +0200 Message-ID: <5448D72F.9050006@henke37.cjb.net> Date: Thu, 23 Oct 2014 12:23:43 +0200 From: Henrik Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 To: Sean Leonard , IETF Apps Discuss , media-types@iana.org References: <20141023100650.23822.44847.idtracker@ietfa.amsl.com> <196FCA0A-94C7-4CCA-B97F-CE50852C87B2@seantek.com> In-Reply-To: <196FCA0A-94C7-4CCA-B97F-CE50852C87B2@seantek.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/OYjCpzZWeK3Nhkxa6JxDZKvlr2o X-Mailman-Approved-At: Thu, 23 Oct 2014 15:16:11 -0700 Subject: Re: [apps-discuss] [media-types] New Version Notification for draft-seantek-image-bmp-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 10:24:14 -0000 Sean Leonard skrev: > Colleagues: > > draft-seantek-image-bmp-01 has been posted. It removes the problematic sentence about not containing text. > > Note that there are embedded questions in the introduction: shall the .cur and .ani formats also be registered? And shall the .ico format be re-registered? (.cur is almost identical to .ico; .ani, not so much.) > > Here is the registration template: > ******* > Windows Bitmap Media Type Registration Application > > Type name: image > > Subtype name: bmp > > Required parameters: None. > > Optional parameters: None. > > Encoding considerations: Binary. > > Security considerations: > > Bitmaps have a mostly unremarkable security history. > > Because BMP data can encapsulate JPEG or PNG data (BI_JPEG, BI_PNG > values of the Compression enumeration in Section 2.1.1.7 of [MS- > WMF]), the security considerations of JPEG and PNG processing may > also apply to BMP. > > Interoperability considerations: > > Uncompressed Windows Bitmaps can be rather large. If there is a > need to compress an image, modern applications SHOULD consider > emitting JPEG or PNG data instead of embedding them in BMP > payloads. > > Published specification: [MS-WMF] and [BMPSTOR]. > > Applications that use this media type: > > Office productivity applications; clip art applications; desktop > publishing applications; Web browsers; graphics processing > applications. > > Fragment identifier considerations: None. > > Additional information: > > Magic number(s): 42 4D ("BM"), meaning "bitmap". The next > field (BITMAPFILEHEADER bfSize) is a > little-endian DWORD indicating the size > of the bitmap content in bytes. > File extension(s): .bmp, .dib > Macintosh file type code(s): > "BMP ", "BMPf", or "BMPp". Apple has promulgated a > uniform type identifier (UTI) of "com.microsoft.bmp". > > Person & email address to contact for further information: > > Sean Leonard > > Restrictions on usage: None. > > Author/Change controller: Sean Leonard > > Intended usage: COMMON > > Provisional registration? No > Perhaps you want to note the problem of upside down images? Bitmaps and icons have the pesky habit of commonly, but not always, being stored bottom up. From nobody Thu Oct 23 23:28:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2FE1A8840 for ; Thu, 23 Oct 2014 23:28: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, 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 EqHFSPjXaZRq for ; Thu, 23 Oct 2014 23:28:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 DA3AC1A1B74 for ; Thu, 23 Oct 2014 23:28:01 -0700 (PDT) Received: from [192.168.2.160] ([84.187.32.111]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lm34j-1YGL0G0I9B-00ZhLk; Fri, 24 Oct 2014 08:27:49 +0200 Message-ID: <5449F158.4010907@gmx.de> Date: Fri, 24 Oct 2014 08:27:36 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Carsten Bormann , "Manger, James" References: <20141015183752.37123181C73@rfc-editor.org> <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com> <306B15D1-D5F5-46B8-8473-599B3B4667EE@tzi.org> In-Reply-To: <306B15D1-D5F5-46B8-8473-599B3B4667EE@tzi.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:7MCovNYG4Et0y5hGJqfyRAP70kIkacEQ4B0XarIt1hYNMYhlXIy m1iPiqYMMnj49u7IN3evhD+5JSAzlYNhe/Bw81yMDGyAaO4fLWgxseVGEykDyekaYFZ2J6y safOFeQLHQmPBf++s47Aj96lOjIwAqP9gd6IxfarLajUlmRzyE31N4yjOej66Of7u+C38NC f/8xbJRsx+8tP1nPjmfww== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-LdUvgzgu90OiIeJx5I3Jdh0MPU Cc: "apps-discuss@ietf.org" , "presnick@qti.qualcomm.com" , RSE , Paul Hoffman , "barryleiba@computer.org" , RFC Errata System Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 06:28:04 -0000 On 2014-10-16 01:16, Carsten Bormann wrote: > On 16 Oct 2014, at 01:06, Manger, James wrote: > >> P.S. Curiously, the "Diff2" format on tools.ietf.org [https://tools.ietf.org/rfcdiff?url2=rfc7386] shows the indentation as being correct in rfc7386.txt and draft-ietf-appsawg-json-merge-patch-07. Probably a tools glitch. > > This looks like the canonical tab-width confusion. > The correct text had a tab-width of 8, but the RFC text was converted to spaces applying a tab-width of 4. > > Yep, the copy of rfc7386.xml I have has been tabified, while draft-ietf-appsawg-json-merge-patch-07.xml is clean. > > NEVER, EVER, tabify documents. > THROW OUT ALL TOOLS THAT DO THIS. > (Sorry for shouting, but this TAB nonsense has cost too much time in my life already.) > ... For the record, I see at least two RFCs in AUTH48 with HTAB characters: RFC 7390 and 7391 (reminder: there's an Atom feed with validation results: ). Best regards, Julian From nobody Fri Oct 24 05:28:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2B91A8AF2 for ; Fri, 24 Oct 2014 05:28:36 -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 yUSJVBYPa9r7 for ; Fri, 24 Oct 2014 05:28:31 -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 127281A8AE1 for ; Fri, 24 Oct 2014 05:28:31 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XhdyW-000MRu-S5; Fri, 24 Oct 2014 08:28:12 -0400 Date: Fri, 24 Oct 2014 08:28:07 -0400 From: John C Klensin To: Julian Reschke , Carsten Bormann , "Manger, James" Message-ID: <9130A2D5849F369BBC0E38AA@JcK-HP8200.jck.com> In-Reply-To: <5449F158.4010907@gmx.de> References: <20141015183752.37123181C73@rfc-editor.org> <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com> <306B15D1-D5F5-46B8-8473-599B3B4667EE@tzi.org> <5449F158.4010907@gmx.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zW3ECbqfCuICI7GSUT-ZqoB3Jig Cc: presnick@qti.qualcomm.com, RSE , Paul Hoffman , apps-discuss@ietf.org, barryleiba@computer.org Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 12:28:36 -0000 (RFC Errata system address removed -- this is not an errata issue) --On Friday, October 24, 2014 08:27 +0200 Julian Reschke wrote: > On 2014-10-16 01:16, Carsten Bormann wrote: >> On 16 Oct 2014, at 01:06, Manger, James >> wrote: >... >> Yep, the copy of rfc7386.xml I have has been tabified, while >> draft-ietf-appsawg-json-merge-patch-07.xml is clean. >> >> NEVER, EVER, tabify documents. >> THROW OUT ALL TOOLS THAT DO THIS. >> (Sorry for shouting, but this TAB nonsense has cost too much >> time in my life already.) ... > > For the record, I see at least two RFCs in AUTH48 with HTAB > characters: RFC 7390 and 7391 (reminder: there's an Atom feed > with validation results: > ). Folks, regardless of what the IESG and posting tools choose to allow in I-Ds, it would be extremely simple to direct the RFC Production Center to remove all tabs from documents as part of their processing and then verify that the results look reasonable before documents are handed back to authors, etc., at AUTH48. It would also be easy for them to add a note about checking formatting on the possibly de-tabbed documents to their AUTH48 instructions to authors and, with only a tad more work, to include that instruction only if there were tabs in the I-D that came to them for processing. While it would impose more burden on authors, it would be easier yet (and at least equally effective) for the RFC Editor Function to require that documents not contain tabs when they were submitted for publication, to perform a very simple check, and to bounce the documents back to the submitting Stream if one or more tabs were present. If you believe any of those things are important, take it up with the RSE (copied on at least the last few of these notes) and/or on the rfc-interest list. If you don't get the results you like, take it up with the IAB. It would only affect some I-Ds, but a suggestion that XML2RFC might generate warnings if tabs appeared, either at all or in artwork or equivalent might help too. Or one could suggest that the posting tools at least warn if tabs are present in their initial nits check. For those suggestions, talk with the tools team and/or the IESG. But, at least IMO, continuing to kick this particular horse, of already dubious viability, on the apps-discuss list is a waste of time and distracts from topics that are actually in the Apps Area critical path. john From nobody Fri Oct 24 07:45:19 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5161A033B for ; Fri, 24 Oct 2014 07:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzPifRinBbUY for ; Fri, 24 Oct 2014 07:45:17 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879251A0121 for ; Fri, 24 Oct 2014 07:45:17 -0700 (PDT) Received: from [10.20.30.90] (50-1-50-141.dsl.dynamic.fusionbroadband.com [50.1.50.141]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s9OEixnH074807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2014 07:45:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-50-141.dsl.dynamic.fusionbroadband.com [50.1.50.141] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Paul Hoffman In-Reply-To: <9130A2D5849F369BBC0E38AA@JcK-HP8200.jck.com> Date: Fri, 24 Oct 2014 07:44:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2797CA13-DB40-46BF-B527-80772BCDB86D@vpnc.org> References: <20141015183752.37123181C73@rfc-editor.org> <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com> <306B15D1-D5F5-46B8-8473-599B3B4667EE@tzi.org> <5449F158.4010907@gmx.de> <9130A2D5849F369BBC0E38AA@JcK-HP8200.jck.com> To: John C Klensin X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/SmX-ykMnQI2KmwYs3jnYKK7Ij7E Cc: apps-discuss@ietf.org, Julian Reschke , Pete Resnick , Heather Flanagan , Barry Leiba Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 14:45:19 -0000 On Oct 24, 2014, at 5:28 AM, John C Klensin wrote: > Folks, regardless of what the IESG and posting tools choose to > allow in I-Ds, it would be extremely simple to direct the RFC > Production Center to remove all tabs from documents as part of > their processing and then verify that the results look > reasonable before documents are handed back to authors, etc., at > AUTH48. =20 Note that, for the RFC in question, the tabs were inserted by the RFC = Production Center. Thus, "directing" them to do something will require = more care all around. --Paul Hoffman= From nobody Fri Oct 24 10:08:00 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD0A1A886F for ; Fri, 24 Oct 2014 10:07:54 -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 7xFuxOqptFsY for ; Fri, 24 Oct 2014 10:07:49 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0741.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::741]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879921A6FFB for ; Fri, 24 Oct 2014 10:03:00 -0700 (PDT) Received: from pc6 (86.184.62.161) by AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) with Microsoft SMTP Server (TLS) id 15.1.6.9; Fri, 24 Oct 2014 17:00:55 +0000 Message-ID: <030b01cfefab$bfcf1760$4001a8c0@gateway.2wire.net> From: t.petch To: Julian Reschke References: <20141015183752.37123181C73@rfc-editor.org> <255B9BB34FB7D647A506DC292726F6E127CF275517@WSMSG3153V.srv.dir.telstra.com> <306B15D1-D5F5-46B8-8473-599B3B4667EE@tzi.org> <5449F158.4010907@gmx.de> Date: Fri, 24 Oct 2014 17:58:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.184.62.161] X-ClientProxiedBy: AM3PR03CA050.eurprd03.prod.outlook.com (10.141.191.178) To AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) X-MS-Exchange-Transport-FromEntityHeader: Hosted X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB050; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 0374433C81 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(13464003)(24454002)(51704005)(377454003)(377424004)(84392001)(97736003)(15975445006)(122386002)(19580405001)(110136001)(19580395003)(105586002)(15202345003)(102836001)(50466002)(31966008)(76482002)(99396003)(33646002)(23756003)(15395725005)(14496001)(107046002)(40100003)(104166001)(120916001)(80022003)(46102003)(19300405004)(44736004)(101416001)(21056001)(87286001)(88136002)(87976001)(81816999)(76176999)(4396001)(81686999)(50226001)(50986999)(106356001)(61296003)(62236002)(89996001)(92566001)(77156001)(44716002)(92726001)(116806002)(42186005)(66066001)(62966002)(86362001)(47776003)(85852003)(93886004)(20776003)(64706001)(85306004)(93916002)(95666004)(77096002)(74416001)(7726001)(562404015); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB050; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/V2Ffa01cvBzK7-t3oCT5jlWbkMs Cc: RSE , apps-discuss Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC7386 (4132) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 17:07:55 -0000 ----- Original Message ----- From: "Julian Reschke" To: "Carsten Bormann" ; "Manger, James" Cc: ; "RSE" Sent: Friday, October 24, 2014 7:27 AM > On 2014-10-16 01:16, Carsten Bormann wrote: > > On 16 Oct 2014, at 01:06, Manger, James wrote: > > > >> P.S. Curiously, the "Diff2" format on tools.ietf.org [https://tools.ietf.org/rfcdiff?url2=rfc7386] shows the indentation as being correct in rfc7386.txt and draft-ietf-appsawg-json-merge-patch-07. Probably a tools glitch. > > > > This looks like the canonical tab-width confusion. > > The correct text had a tab-width of 8, but the RFC text was converted to spaces applying a tab-width of 4. > > > > Yep, the copy of rfc7386.xml I have has been tabified, while draft-ietf-appsawg-json-merge-patch-07.xml is clean. > > > > NEVER, EVER, tabify documents. > > THROW OUT ALL TOOLS THAT DO THIS. > > (Sorry for shouting, but this TAB nonsense has cost too much time in my life already.) > > ... > > For the record, I see at least two RFCs in AUTH48 with HTAB characters: > RFC 7390 and 7391 (reminder: there's an Atom feed with validation > results: ). This scratches my itch. A long time ago, I downloaded RFC2328 (OSPF v2) but found that any utility I used to view it produced a mess, hard to use in any way. I eventually looked at the binary and found that it was riddled with tab characters. I downloaded it several times from different sites, using FTP, with the same result. I tried all the combinations I could think of for tab settings to no avail. (Interestingly, using IE now to access the web site gives a reasonable display). I eventually gave up (on OSPF that is:-) I notice that the last modified date for this RFC is 1998 on the web site so things would appear not to have changed. Well, RFCs are never changed no matter what:-( Tom Petch > Best regards, Julian > From nobody Sat Oct 25 14:08:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34421A0A6A for ; Sat, 25 Oct 2014 14:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Se8PrpWkRSd for ; Sat, 25 Oct 2014 14:08:29 -0700 (PDT) Received: from samu.mail.cebe.net (samu.mail.cebe.net [IPv6:2001:41d0:2:daa:dead:beef:0:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B68141A1A17 for ; Sat, 25 Oct 2014 14:08:28 -0700 (PDT) Received: from [192.168.178.50] (port-92-206-105-252.dynamic.qsc.de [92.206.105.252]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by samu.mail.cebe.net (Postfix) with ESMTPSA id A646E29749 for ; Sat, 25 Oct 2014 21:08:21 +0000 (UTC) Message-ID: <544C1145.6030302@cebe.cc> Date: Sat, 25 Oct 2014 23:08:21 +0200 From: Carsten Brandt User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <150B87D9-F747-4B89-87C0-F1F15A337476@michelf.ca> <54425EFF.10501@fletcherpenney.net> <2F19BAB0-F130-4E22-B649-A2D0371EB0D9@michelf.ca> In-Reply-To: <2F19BAB0-F130-4E22-B649-A2D0371EB0D9@michelf.ca> OpenPGP: id=2E494B35; url=http://cebe.cc/cebe_pub.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x80m1DGTh9CwIeRGb5vOaej0BeW9hvvSd" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/qqVxXHJ2mztOY9SYpi17DxnUm0A Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mail@cebe.cc List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 21:08:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --x80m1DGTh9CwIeRGb5vOaej0BeW9hvvSd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 18.10.2014 23:39, schrieb Michel Fortin: > Le 18-oct.-2014 =E0 8:37, Fletcher T. Penney a =E9crit : >=20 >> I understand that Gruber has, in his way, consented to the concept of = "text/markdown." Has he consented to the idea of using "text/markdown" t= o refer to a bunch of things that are not Markdown? Based on past histor= y, I would bet not -- but you never know and clearly I cannot speak for h= im. I would recommend asking him. I would not support the idea of using "= text/multimarkdown" to refer to things that are not MultiMarkdown. >=20 > I'd tend to define "text/markdown" as identifying documents using the M= arkdown syntax and its compatible derivatives. "Compatible" in the sense = that they mostly follow the rules of the official syntax document on dari= ngfireball.net. I think an important part of this document has to be a definition of what it understands as Markdown. Imo Markdown is a set of languages that share the Gruber Markdown syntax as a common subset. There is no such thing as a standard or specification because markdown is just plaintext with some additional rules. Parsing Markdown is, when it comes to edge cases more like natural language processing than following a spec (I have written a markdown parser myself [1]). A good parsing result is in these cases the one that most people would interpret from the written plain text. A result from this is that every markdown parser will interpret a given document in a slightly different way when the document is complex enough. See babelmark example [2]. So the important part of the media type is to describe the content of a file as "text/markdown" letting the consumer application know that it can be presented by parsing it at least for the syntax described by Gruber. As markdown is designed to look in text already similar to the rendering result it should be generally fine to interpret markdown as plain text and present it that way. If there is a known flavor attached as an optional attribute the presenting application may choose to render additional syntax elements according to the flavor. A library may therefor support mulitple flavors to render markdown files as for example my parser does [1]. Different flavors may be registered if they are common but it should be allowed to use application or library specific flavors to indicate usage of a customized flavor which is common to the nature of markdown. Output format is nothing that describes the content of the markdown file or significatnly influences the way the document is presented so it should not be part of the media type. best regards, Carsten [1] https://github.com/cebe/markdown#readme [2] http://johnmacfarlane.net/babelmark2/?normalize=3D1&text=3D1.+a%0A-+x%0A-= +y%0A%0A2.+b%0A-+x%0A-+y%0A --=20 mail: mail@cebe.cc phone: +49 176 / 96 52 999 7 www: http://cebe.cc/ pgp: http://cebe.cc/cebe_pub.asc skype: skype://cebe08 irc: cebe @ irc.freenode.net --x80m1DGTh9CwIeRGb5vOaej0BeW9hvvSd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJUTBFFAAoJEDNFvywuSUs1vI0H+QHJr6laBF2BEygaIvYjhVNs AjV26ks8BuNZOCJk7Sq4LV1AuudyCmzh6/U8VcF5NRnGAkrfom0btjNMpG+Swfeo 0JCCUuNP/EX3wPG+y8MjuBXUJ/dWlo+Qzv5hdZKbj/rhh9tRJXnxyI1rBhDJuGx/ kedlqUpwIFaMuN10KsD6F0rzcQTobpbyG0eBcRqhSwcp1TX4WLt1KUAmyrKyUU6B B+gwBi60UNhJNTUOERl2Bk4wnq8wOsGiiBQr2tkOPzS70YCGyNs14JKQwom6TkPh +3iHnVeJs1RMxzmGBhu/xd3avYT63Uhk8foNLDI9weouqukrhdg+Qszkuta2WIQ= =er1M -----END PGP SIGNATURE----- --x80m1DGTh9CwIeRGb5vOaej0BeW9hvvSd-- From nobody Sat Oct 25 22:09:27 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDC91A6F28 for ; Sat, 25 Oct 2014 22:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCLo0sewlD0t for ; Sat, 25 Oct 2014 22:09:18 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D401A1B21 for ; Sat, 25 Oct 2014 22:09:17 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E6FA2509B5 for ; Sun, 26 Oct 2014 01:09:15 -0400 (EDT) Message-ID: <544C81B2.6090409@seantek.com> Date: Sat, 25 Oct 2014 22:08:02 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: IETF Apps Discuss References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <01PDWHBG1ZY200005L@mauve.mrochek.com> In-Reply-To: <01PDWHBG1ZY200005L@mauve.mrochek.com> Content-Type: multipart/alternative; boundary="------------000308050605060804020908" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/q86Et6L14vJQPsRTDQCkGE6Wb1s Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Oct 2014 05:09:23 -0000 This is a multi-part message in MIME format. --------------000308050605060804020908 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 10/18/2014 5:47 PM, Ned Freed wrote: > "Murray S. Kucherawy" wrote: > >> I remain skeptical about the "output-type" parameter. It seems to me = the >> consumer of the media type knows what output form it will need to prod= uce; >> this isn't context the generator can really impose. I guess that mean= s I >> either didn't understand or don't agree with your previous response on= this >> point. I understand that, for example, you don't envision email reade= rs or >> browsers as consumers of this media type, but what happens if such a t= hing >> does land in one's inbox or on a web page? Should browsers and MUAs i= gnore >> them, return errors, what? > As I indicated in my previous message, I agree that output-type doesn't= make > sense as a content-type parameter. > > But that doesn't mean providing the information makes no sense. While i= t is > true that the consumer has to have the final say, I can easily imagine > scenarios where conversion to a particular type provides a better resul= t, > and it would be helpful to be able to provide that information. > > But the place for that is content-disposition, not content-type. In order to keep this draft moving, I'd like to focus on specific=20 technical issues. Based on feedback thus far it seems that there is some support for=20 conveying an output media type, but it should not be part of the=20 text/markdown media type's parameters. Proposal: Content-Disposition: ... preview-type parameter. The preview-type indicates the media type (and optional parameters) that a receiving application may present to a user as a "preview" of the content. The preview-type parameter is advisory and does not dictate or constrain the semantics of the content in any way, but rather provides a useful way to duplicate the sender's intent with regard to how the content should look when processed. The syntax of the preview-type parameter is the same as the field value of the RFC 2045 Content-Type header, i.e., a media type and optional parameters, delimited by semicolons. The purpose of this parameter is for Markdown content. Obviously, it=20 could be used for other formats, but I am not concerned with those at=20 this time. (The choice of "preview-type" for a parameter name is meant to=20 distinguish this from other kinds of previews, such as "preview-image",=20 "preview-thumbnail", "preview-soundbite", etc.) 1) Can we get agreement on this preview-type parameter? 2a) Shall this preview-type parameter be registered in the text/markdown = RFC? Or: 2b) Shall this preview-type parameter be registered in a new, SHORT,=20 informational RFC? (RFC 2183 does not require this; the standard appears = to be First-Come, First-Served with a simple e-mail to IANA.) 3) How shall the text/markdown registration discuss the applicability of = the preview-type parameter for Markdown editors (or other Markdown=20 applications)? Regards, Sean --------------000308050605060804020908 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 10/18/2014 5:47 PM, Ned Freed wrote:
"Murray S. Kucherawy" <superuser@gmail.com> wrote:


I remain skeptical about the "output-type" parameter.  It seems to me the
consumer of the media type knows what output form it will need to produce;
this isn't context the generator can really impose.  I guess that means I
either didn't understand or don't agree with your previous response on this
point.  I understand that, for example, you don't envision email readers or
browsers as consumers of this media type, but what happens if such a thing
does land in one's inbox or on a web page?  Should browsers and MUAs ignore
them, return errors, what?

As I indicated in my previous message, I agree that output-type doesn't make
sense as a content-type parameter.

But that doesn't mean providing the information makes no sense. While it is
true that the consumer has to have the final say, I can easily imagine
scenarios where conversion to a particular type provides a better result,
and it would be helpful to be able to provide that information.

But the place for that is content-disposition, not content-type.

In order to keep this draft moving, I'd like to focus on specific technical issues.

Based on feedback thus far it seems that there is some support for conveying an output media type, but it should not be part of the text/markdown media type's parameters.

Proposal:
Content-Disposition: ... preview-type parameter. The preview-type indicates the media type (and optional parameters) that a receiving application may present to a user as a "preview" of the content. The preview-type parameter is advisory and does not dictate or constrain the semantics of the content in any way, but rather provides a useful way to duplicate the sender's intent with regard to how the content should look when processed. The syntax of the preview-type parameter is the same as the field value of the RFC 2045 Content-Type header, i.e., a media type and optional parameters, delimited by semicolons.

The purpose of this parameter is for Markdown content. Obviously, it could be used for other formats, but I am not concerned with those at this time.

(The choice of "preview-type" for a parameter name is meant to distinguish this from other kinds of previews, such as "preview-image", "preview-thumbnail", "preview-soundbite", etc.)

1) Can we get agreement on this preview-type parameter?

2a) Shall this preview-type parameter be registered in the text/markdown RFC? Or:

2b) Shall this preview-type parameter be registered in a new, SHORT, informational RFC? (RFC 2183 does not require this; the standard appears to be First-Come, First-Served with a simple e-mail to IANA.)

3) How shall the text/markdown registration discuss the applicability of the preview-type parameter for Markdown editors (or other Markdown applications)?

Regards,

Sean
--------------000308050605060804020908-- From nobody Sun Oct 26 04:54:36 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6382D1A8032 for ; Sun, 26 Oct 2014 04:54:34 -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 XaL1B6ypcYiQ for ; Sun, 26 Oct 2014 04:54:32 -0700 (PDT) Received: from cp.hebergementsolutions.com (cp.hebergementsolutions.com [184.170.132.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0511A8030 for ; Sun, 26 Oct 2014 04:54:32 -0700 (PDT) Received: from [173.246.4.57] (port=54510 helo=minimi.michelf.ca) by cp.hebergementsolutions.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1XiMPm-0004MB-B6; Sun, 26 Oct 2014 07:55:18 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_16F016C2-A262-4EAB-A9EE-716E6B474347"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michel Fortin In-Reply-To: <544C81B2.6090409@seantek.com> Date: Sun, 26 Oct 2014 07:54:27 -0400 Message-Id: <8D95B7DB-9BAC-455D-BAD2-DB2B97B104B4@michelf.ca> References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <01PDWHBG1ZY200005L@mauve.mrochek.com> <544C81B2.6090409@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.1990.1) X-cPanel-MailScanner-Information: Please contact the ISP for more information X-cPanel-MailScanner-ID: 1XiMPm-0004MB-B6 X-cPanel-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-cPanel-MailScanner-SpamCheck: X-cPanel-MailScanner-From: michel.fortin@michelf.ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cp.hebergementsolutions.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - michelf.ca X-Get-Message-Sender-Via: cp.hebergementsolutions.com: authenticated_id: michel.fortin@michelf.ca Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-qg8h4RiadSsxYBemayesZVCbTU Cc: IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Oct 2014 11:54:34 -0000 --Apple-Mail=_16F016C2-A262-4EAB-A9EE-716E6B474347 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Le 26-oct.-2014 =E0 1:08, Sean Leonard a =E9crit = : > "The preview-type parameter is advisory and does not dictate or = constrain the semantics of the content in any way, but rather provides a = useful way to duplicate the sender's intent with regard to how the = content should look when processed." An output type is a very poor way to define "how the content should = look". What does it mean that the content should look like HTML? or look = like Latex? or look like PDF? I see no justification for any presentational attribute. The media type = is there to tell you what that content is. How it is presented or = processed is up to the user of that document. --=20 Michel Fortin michel.fortin@michelf.ca https://michelf.ca --Apple-Mail=_16F016C2-A262-4EAB-A9EE-716E6B474347 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMjTCCBjQw ggQcoAMCAQICAR8wDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAI6ByrMlixq5 piBb1m3JRDRfINXQII5OT8TWqeZz8zse9vt7fUZHaPVLFeWYlj8B9BA2uHhGfyZtPtyf0nYtnFPK g7xiSXX/apE16bFfYdtHka3qupMggZp1+OZmtAdRO/TRij5C2bV2o+kIf+53LfWav2tw6pICxfJO 9Hrjl7HbYo3+l3ul9YVB5SVKG8WLmMCkpm7ti1Z4LOYF0Y5AG3d8AqYS3/5aUWQN/ZQN4BMruXSJ GFYFYBDxu7jTBbBW9l2m4u/s80e+jkJ9P9XDXeOsclCsdAtY4F2C/kOH76j6fwiABKLx454BkTMt ukts/PLtzrIy37oV0UTiykmcFCXSmc1gQk+xz25vGs/D36Ve8L+2A+J7idUYP83A1wS4JLgb4Q7J Fzl/lqLO+IDM+AGH9cujofg7Pjl2HdyDq3FOn7eAz2ZPN+zGzes5/E8rK1QnTsk9tIsi7QRIPdAB TnhC8ImOaNjVkB9JGUJ2BAXwVLB5Dq9SEdnGiyWdS7a9fb+Tfy8D2wuOA9metV0hUlrPMHCmJtZR bFZAjOlQrKhMM5hE31Qal2HF6OkfVhtE0nvqgj6dLt3871yxSYh13c0OBF6kZPR9Sgij3GZhAwEN sESI065Wg0BRSoCtWB6RxATzwIyIGgD/Gm8uPp+cv9OtSrDRwNjGphN+MQ81oVh5MIIGUTCCBTmg AwIBAgIDCZgGMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTQwNDEwMDkzMjE4WhcNMTUwNDEyMDIxMjUzWjBnMRkwFwYDVQQNExBZbjhVdjUyNmNnNGJjcmlR MSEwHwYDVQQDDBhtaWNoZWwuZm9ydGluQG1pY2hlbGYuY2ExJzAlBgkqhkiG9w0BCQEWGG1pY2hl bC5mb3J0aW5AbWljaGVsZi5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM1xHBAc 28F84D5D/ITRvjBwB3dwI7osaLizqSCZhMRpXg4zWsxIoaDy6H9OTQdpaqY431ypMGiwd7vddirK pEn/DEVb0SItTb73touChfuVVE5LHYPKcL1CfRa0XJF4KhryeP/m9sPA4N4zLb7IR4HFioOkF/XL Hkh9bv12yXUK+6jWpSNaQNf/kUz2AlKUSSx4pW2kBH72EW4xreuRs30Qqft1rqwkL4LRhipd3GA9 0Pni7mOaNSKu3kGCHKz+/4+h4SUdNuD13nhZLwLFHyHhk4I+IpFyq5/vPFr/dFRg3rdpMxhgd+M/ H4rfaUm2Kb0ODq+7FXccjDSbhCFEc08CAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQD AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUu56gBRTHUtBmsqyG mqCVXtMAz9cwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYbWlj aGVsLmZvcnRpbkBtaWNoZWxmLmNhMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCC ASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRp b24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFy dHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29t L2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3Nw LnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2Fp YS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqG GGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAJjgunxV0rh494ufL ch4bvYfoewNrW9OIZjpyS3GTzjD+a8aUIctmXo5HilIew8NwaYzRRKhQ3V4uy3rPmpIGddZfXlxm jlejMlWCVcgBBuB2CziegUCWvJbpSjz4eM0dQX6nU0zAGV1iqWkdrIxMgkgeeGWZaWV+m2Qu/oWw 9EbgegPaz+cFJNbrZEjA06d9CKQJTn2MP7POPPSwDTlTHZ/b6/X1MckAfCeEm96CRCEEzBo06Yki UMJMOdqVggAyP7huNxo7TpnNfe7ylve4vsHBSxpW7NElcMaXIgFalFVmpxZICOvxcncajCmYOzJp cb+YJuJwkeYf5CMjGsBshzGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAwmYBjAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNDEwMjYxMTU0MjhaMCMGCSqGSIb3DQEJBDEWBBSxh1EcGYM7ODP+b6FM9+fIKxiG NTCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwmYBjCB pwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCZgGMA0G CSqGSIb3DQEBAQUABIIBAC1hdSyjnYUnX1jabOMVhGQgbF9rDnh8goQWVvRM19klUiTm2qx1oiwe zGKqpEMCJ4ZptOQBXKPkSgXchQtpwFKvAbm15nhitpVv1Xr8NQQFs6mrClelSN8yR6fKriz2qJQn 0O1xMpIpFEYne7Yi5OqZ9GydC8wv94cfYvIGxEIhnbz6n5ztf3RYs5D28NURRZWQtFzYBZEbSA5e THVgh2zoUHtnpGDFJmN9GzgS9EuGvPh0Heb0R7dS0eUCH/FKgIrBLOZr6TNXZIJguVS44YS7clzR Xv7+/TStFETeikO8bhyqwx3RrnoH301Pp5qg8UkKIHkRSh1WHEY5tybf/vcAAAAAAAA= --Apple-Mail=_16F016C2-A262-4EAB-A9EE-716E6B474347-- From nobody Sun Oct 26 11:42:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC1E1A0384 for ; Sun, 26 Oct 2014 11:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNMtZ7L56DMO for ; Sun, 26 Oct 2014 11:42:22 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF6241A0019 for ; Sun, 26 Oct 2014 11:42:21 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id w8so2976563qac.3 for ; Sun, 26 Oct 2014 11:42:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oFMCu2j0VbJDlTy/M6JwV1J+wCeUHZF/MLsaJGPdKYE=; b=Uu1hep3kxp88L+1m/cPq2Xs7g1Gt5G8KPHgJ7uS6JkRHjx3TrC1r8QLYynIvi07EPN vL/20xPw/dI1bWEeHefQhbAUZ9DD49dQkuB0J2n/YIfN5jo1Ag4CMJtjMcL+P/Yozre3 a5xJYOAeLUMcM+adalN+A1Y9JUUucsLZkvd/2xgElaCKXcRNg1+yg/26OaRPvKkRcu+f 8B10oKAMpKgF3eFQ4EuaxRHE/ujyfLnBoONYEKQQ615Ww3ueoao36kvf+Jps4dvYtM5c VbX/lmIcQVXMV0NsCclUKtsJbbfUBLuV6Mv9/lxvl2grDfO5YC8/Fts1Pp4MDBR5jh7n C73g== X-Gm-Message-State: ALoCoQlG9snQ5vOBDGMvjxDq4pLferLmRjVuhJV0rYrp3ZoXLxNUbzM/W2Z6MAOWiSTdR8qdNZuQ X-Received: by 10.140.109.244 with SMTP id l107mr3418448qgf.80.1414348941015; Sun, 26 Oct 2014 11:42:21 -0700 (PDT) Received: from Everready.local ([76.73.248.16]) by mx.google.com with ESMTPSA id v4sm9373290qag.23.2014.10.26.11.42.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Oct 2014 11:42:20 -0700 (PDT) Message-ID: <544D408B.3090404@fletcherpenney.net> Date: Sun, 26 Oct 2014 14:42:19 -0400 From: "Fletcher T. Penney" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: IETF Apps Discuss References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <01PDWHBG1ZY200005L@mauve.mrochek.com> <544C81B2.6090409@seantek.com> In-Reply-To: <544C81B2.6090409@seantek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Vqw4IRLtydFIbvkN8BYMfXuOrZw Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Oct 2014 18:42:25 -0000 On 10/26/14, 1:08 AM, Sean Leonard wrote: > In order to keep this draft moving, I'd like to focus on specific > technical issues. > > Based on feedback thus far it seems that there is some support for > conveying an output media type, but it should not be part of the > text/markdown media type's parameters. It may be true that there is support for it, but there is also opposition to an output media type, regardless of what you call it. Perhaps I am just dumb. It seems to me that the purpose of a media type is to say, "What I am about to send/attach/etc. is digital content that represents a picture/sound/movie/file/etc." I did not understand that a media type should then say, "Now that you have the file, here's what you have to do with it." In this case, the content is plain text. The plain text happens to follow a set of rules/guidelines/whatever that allow some programs to do something with that text (e.g. convert to HTML). *Whether* that happens is up to the user receiving the file, not the person sending it. > Proposal: > > Content-Disposition: ... preview-type parameter. The preview-type > indicates the media type (and optional parameters) that a receiving > application may present to a user as a "preview" of the content. The > preview-type parameter is advisory and does not dictate or constrain > the semantics of the content in any way, but rather provides a > useful way to duplicate the sender's intent with regard to how the > content should look when processed. The syntax of the preview-type > parameter is the same as the field value of the RFC 2045 > Content-Type header, i.e., a media type and optional parameters, > delimited by semicolons. > > > The purpose of this parameter is for Markdown content. Obviously, it > could be used for other formats, but I am not concerned with those at > this time. > > (The choice of "preview-type" for a parameter name is meant to > distinguish this from other kinds of previews, such as "preview-image", > "preview-thumbnail", "preview-soundbite", etc.) > > 1) Can we get agreement on this preview-type parameter? Unanimous agreement? NO. As I (and others) have said, it just doesn't make sense and isn't necessary. That doesn't seem to be persuading you from moving forward with the mission of creating a needlessly complicated media type however. It feels as though my difficulty understanding this proposal is that there is a "hidden" agenda that I am unaware of. It's like being asked to pack a suitcase without knowing the destination. Please explain to those of us who clearly don't understand the need for all of this what we are missing. In aggregate there have been 100's of person-hours spent on discussing this. To my knowledge, there is not a single instance of something like this "in the wild" that needs standardization. We're creating a solution where no problem exists. If "text/x-markdown" were being used all over the place, in countless incompatible and creative ways, then it would make sense to agonize over the best way to standardize. But we're trying to standardize something where there's not even a working prototype, much less competing versions that are creating confusion and incompatibility. > 2a) Shall this preview-type parameter be registered in the text/markdown > RFC? Or: My vote? NO. > 2b) Shall this preview-type parameter be registered in a new, SHORT, > informational RFC? (RFC 2183 does not require this; the standard appears > to be First-Come, First-Served with a simple e-mail to IANA.) My vote? NO. > 3) How shall the text/markdown registration discuss the applicability of > the preview-type parameter for Markdown editors (or other Markdown > applications)? My vote? It doesn't. The programmers of Markdown editors can do whatever they like with it, including the most likely thing should this come to exist (IMO)... they ignore it. I've been working with Markdown for a long time. I released one of the early Markdown derivatives (second after PHP Markdown Extra??). I released one of the first dedicated Markdown/MultiMarkdown text editors. And not once have I ever needed something like this, nor do I foresee any need to support it in the future. Identifying content as "text/markdown" is a nice convenience, but hardly necessary ("text/x-markdown" works just fine). Anything more complicated than that is really unnecessary in my view. If I'm editing a text document, and want to preview it as HTML, I'm going to be pretty upset if the app says, "Sorry -- the author wants this previewed as a PDF, so I can't make this HTML as you requested." It just doesn't make sense. I understand that one can envision all sorts of hypothetical cases where a complex media type would be useful. But those things don't exist, and IMO the logic for that behavior belongs in the application, not in a complicated media type definition. Fletcher -- Fletcher T. Penney fletcher@fletcherpenney.net From nobody Sun Oct 26 11:42:57 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784661A0365 for ; Sun, 26 Oct 2014 11:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_oVEgqiE3KH for ; Sun, 26 Oct 2014 11:42:54 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40A911A0019 for ; Sun, 26 Oct 2014 11:42:54 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id z60so3017351qgd.5 for ; Sun, 26 Oct 2014 11:42:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Nztc9cKgOugTp+NaVPDMgsUqSCuAn0zXQH3sM/EUOpY=; b=k6eJ7FO/LUo23m7P21XWV7cg2Tgo/C1PDF7KhfJhODH6Bk+eLQcLWDIu3oYYHwlB9r pk+aUT0T245T+ydnpS3DyUVcZLNOMLBAAVqwfiAyCAOV9oh/FtMMyAhM+8QhkYGSdh4D VhnorXcTA2BxxfoIEE79vydTarE4LU71GFSEoICstke+dbH8BMtGonnyr3hWeMu/KDS0 5v/Gylp5lmT059spz4VcYzG9hDS72lxMGL8yVvilewGwbxP8g12MrtFesjYFKl0jMjJx vMyb+6iVgWE3Xo9pwjPneYItt2T/oac+bWFwTNd5Q54OSS6QHQMt9tvFwVQEYF9w/GnL tFLQ== X-Gm-Message-State: ALoCoQkgNj1et2jBd6e3Cug2q0CM7uTw9UdFuJhioRJGmbUg4ctrSo8y+gadIqW8rmv8WaXGlKsc X-Received: by 10.224.34.73 with SMTP id k9mr26791635qad.23.1414348973438; Sun, 26 Oct 2014 11:42:53 -0700 (PDT) Received: from Everready.local ([76.73.248.16]) by mx.google.com with ESMTPSA id 94sm9285908qgg.33.2014.10.26.11.42.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Oct 2014 11:42:53 -0700 (PDT) Message-ID: <544D40AC.3000701@fletcherpenney.net> Date: Sun, 26 Oct 2014 14:42:52 -0400 From: "Fletcher T. Penney" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: IETF Apps Discuss References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <01PDWHBG1ZY200005L@mauve.mrochek.com> <544C81B2.6090409@seantek.com> <8D95B7DB-9BAC-455D-BAD2-DB2B97B104B4@michelf.ca> In-Reply-To: <8D95B7DB-9BAC-455D-BAD2-DB2B97B104B4@michelf.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/sk4Etyp-8j3irQlXcgaCx36kvGU Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Oct 2014 18:42:55 -0000 Agreed. On 10/26/14, 7:54 AM, Michel Fortin wrote: > Le 26-oct.-2014 à 1:08, Sean Leonard a écrit : > >> "The preview-type parameter is advisory and does not dictate or constrain the semantics of the content in any way, but rather provides a useful way to duplicate the sender's intent with regard to how the content should look when processed." > > An output type is a very poor way to define "how the content should look". What does it mean that the content should look like HTML? or look like Latex? or look like PDF? > > I see no justification for any presentational attribute. The media type is there to tell you what that content is. How it is presented or processed is up to the user of that document. > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Fletcher T. Penney fletcher@fletcherpenney.net From nobody Sun Oct 26 13:58:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFAD41A1A0A for ; Sun, 26 Oct 2014 13:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 ELyPz-d0QYYh for ; Sun, 26 Oct 2014 13:57:58 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 368601A0372 for ; Sun, 26 Oct 2014 13:57:58 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PE7F4W048W002RNM@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 26 Oct 2014 13:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1414356775; bh=UO6Aa5KfDGZTP4tK0tAub0WMyi6x6cfx+HRv+UTw5LY=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=FOpy5gr2KpgNYcnfaExkK1CH+jDl2t6T9+1jLSyYwczAl9701FJtk+2Zm+QhXHe9h TvOx3xxf9Vk74E71fxHp6dbQTT9L7bK/3eoBANHIjxwdrQLzHDnBq6gR4zVW6EWa5r VR7QHTVQmY/iyKk7WaThe3iFdT6DK8aff8pqoi80= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PE3G6YIHXS0028JO@mauve.mrochek.com>; Sun, 26 Oct 2014 13:52:53 -0700 (PDT) Message-id: <01PE7F4UX0780028JO@mauve.mrochek.com> Date: Sun, 26 Oct 2014 13:34:56 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 26 Oct 2014 14:42:19 -0400" <544D408B.3090404@fletcherpenney.net> References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <01PDWHBG1ZY200005L@mauve.mrochek.com> <544C81B2.6090409@seantek.com> <544D408B.3090404@fletcherpenney.net> To: "Fletcher T. Penney" X-Comment: Internal;probe=process-dkim-sign Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/I-6P8w5r6JT_Xi44QXnMavd0HgQ Cc: IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Oct 2014 20:57:59 -0000 > On 10/26/14, 1:08 AM, Sean Leonard wrote: > > In order to keep this draft moving, I'd like to focus on specific > > technical issues. > > > > Based on feedback thus far it seems that there is some support for > > conveying an output media type, but it should not be part of the > > text/markdown media type's parameters. > It may be true that there is support for it, but there is also > opposition to an output media type, regardless of what you call it. > Perhaps I am just dumb. It seems to me that the purpose of a media type > is to say, "What I am about to send/attach/etc. is digital content that > represents a picture/sound/movie/file/etc." I did not understand that a > media type should then say, "Now that you have the file, here's what you > have to do with it." Indeed. The name parameter was removed from application/octet-stream and moved to content-disposition because it didn't fit this model. But this is argument against preview-type as a media type parameter. It says nothing about it being defined as a content-disposition parameter, which is what's being proposed here. > In this case, the content is plain text. The plain text happens to > follow a set of rules/guidelines/whatever that allow some programs to do > something with that text (e.g. convert to HTML). *Whether* that happens > is up to the user receiving the file, not the person sending it. Here we disagree. The content is *not* plain text. It's text containing a type of markup intended to be interpreted in a particular way. The fact that the markup is defined in a fairly loose way doesn't make it unformatted a la text/plain. There's also lots of running code here. For example, comma separated values have their own media type, but are also a subset of plain text. > > Proposal: > > > > Content-Disposition: ... preview-type parameter. The preview-type > > indicates the media type (and optional parameters) that a receiving > > application may present to a user as a "preview" of the content. The > > preview-type parameter is advisory and does not dictate or constrain > > the semantics of the content in any way, but rather provides a > > useful way to duplicate the sender's intent with regard to how the > > content should look when processed. The syntax of the preview-type > > parameter is the same as the field value of the RFC 2045 > > Content-Type header, i.e., a media type and optional parameters, > > delimited by semicolons. > > > > > > The purpose of this parameter is for Markdown content. Obviously, it > > could be used for other formats, but I am not concerned with those at > > this time. > > > > (The choice of "preview-type" for a parameter name is meant to > > distinguish this from other kinds of previews, such as "preview-image", > > "preview-thumbnail", "preview-soundbite", etc.) > > > > 1) Can we get agreement on this preview-type parameter? > Unanimous agreement? NO. As I (and others) have said, it just doesn't > make sense and isn't necessary. That doesn't seem to be persuading you > from moving forward with the mission of creating a needlessly > complicated media type however. > It feels as though my difficulty understanding this proposal is that > there is a "hidden" agenda that I am unaware of. It's like being asked > to pack a suitcase without knowing the destination. The only agenda I see here is a desire to provide a label for something that is different from any existing media type along with a parameter completely separate from the media type that can be used by content creator to suggest handling to someone processing the content. > Please explain to those of us who clearly don't understand the need for > all of this what we are missing. In aggregate there have been 100's of > person-hours spent on discussing this. To my knowledge, there is not a > single instance of something like this "in the wild" that needs > standardization. We're creating a solution where no problem exists. > If "text/x-markdown" were being used all over the place, in countless > incompatible and creative ways, then it would make sense to agonize over > the best way to standardize. But we're trying to standardize something > where there's not even a working prototype, much less competing versions > that are creating confusion and incompatibility. You're conflating the issues with the parameter with issues with the type itself, and also seem to be missing the fact that this isn't a proposal to have preview-type as a content-disposition parameter. > > 2a) Shall this preview-type parameter be registered in the text/markdown > > RFC? Or: > My vote? NO. (We don't vote.) > > 2b) Shall this preview-type parameter be registered in a new, SHORT, > > informational RFC? (RFC 2183 does not require this; the standard appears > > to be First-Come, First-Served with a simple e-mail to IANA.) > My vote? NO. Have you read RFC 2183 to see whether or not this fits as a content-disposition parameter? And if you have, why doesn't it fit? Personally, I have no problem with the parameter although the word "preview" doesn't seem to fit very well, and my preference is to keep the parameter in this RFC. Ned From nobody Sun Oct 26 19:27:00 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3435F1A6F02 for ; Sun, 26 Oct 2014 19:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOmdK9wRTzBO for ; Sun, 26 Oct 2014 19:26:54 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8092D1A6F01 for ; Sun, 26 Oct 2014 19:26:54 -0700 (PDT) Received: from [192.168.123.151] (unknown [23.240.242.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 40D5A509B8; Sun, 26 Oct 2014 22:26:51 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_E92F88B3-8EDA-46EA-A95C-C056219C8745"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <01PE7F4UX0780028JO@mauve.mrochek.com> Date: Sun, 26 Oct 2014 19:26:08 -0700 Message-Id: <94B993C2-29D2-4AE6-9B7B-32417F7E1B9D@seantek.com> References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <01PDWHBG1ZY200005L@mauve.mrochek.com> <544C81B2.6090409@seantek.com> <544D408B.3090404@fletcherpenney.net> <01PE7F4UX0780028JO@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Yi-06xu5s0OCiuuQ-6vUjCmMRnY Cc: IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 02:26:58 -0000 --Apple-Mail=_E92F88B3-8EDA-46EA-A95C-C056219C8745 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 26, 2014, at 1:34 PM, Ned Freed wrote: >=20 >=20 >> On 10/26/14, 1:08 AM, Sean Leonard wrote: >=20 >> > In order to keep this draft moving, I'd like to focus on specific >> > technical issues. >> > >> > Based on feedback thus far it seems that there is some support for >> > conveying an output media type, but it should not be part of the >> > text/markdown media type's parameters. >=20 >> It may be true that there is support for it, but there is also >> opposition to an output media type, regardless of what you call it. >=20 >> Perhaps I am just dumb. It seems to me that the purpose of a media = type >> is to say, "What I am about to send/attach/etc. is digital content = that >> represents a picture/sound/movie/file/etc." I did not understand = that a >> media type should then say, "Now that you have the file, here's what = you >> have to do with it." >=20 > Indeed. The name parameter was removed from application/octet-stream = and moved > to content-disposition because it didn't fit this model. >=20 > But this is argument against preview-type as a media type parameter. = It says nothing about it being defined as a content-disposition = parameter, which > is what's being proposed here. That is correct, and that is what I am proposing. This is not a media = type parameter; it=92s a Content-Disposition parameter. RFC 2183 says: MIME specifies a standard format for encapsulating multiple pieces of data into a single Internet message. That document does not address the issue of presentation styles; it provides a framework for the interchange of message content, but leaves presentation issues solely in the hands of mail user agent (MUA) implementors. Two common ways of presenting multipart electronic messages are as a main document with a list of separate attachments, and as a single document with the various parts expanded (displayed) inline. The display of an attachment is generally construed to require positive action on the part of the recipient, while inline message components are displayed automatically when the message is viewed. A mechanism is needed to allow the sender to transmit this sort of presentational information to the recipient; the Content-Disposition header provides this mechanism, allowing each component of a message to be tagged with an indication of its desired presentation semantics. >=20 >> In this case, the content is plain text. The plain text happens to >> follow a set of rules/guidelines/whatever that allow some programs to = do >> something with that text (e.g. convert to HTML). *Whether* that = happens >> is up to the user receiving the file, not the person sending it. >=20 > Here we disagree. The content is *not* plain text. It's text = containing a type > of markup intended to be interpreted in a particular way. The fact = that the > markup is defined in a fairly loose way doesn't make it unformatted a = la > text/plain. Right. Note that any textual data can be relabeled as text/plain; this changes = the textual data=92s semantics. If you serve text/html as text/plain, it = will show the source as plain text. There is differential handling = involved. >=20 > There's also lots of running code here. For example, comma separated = values > have their own media type, but are also a subset of plain text. >=20 >> > Proposal: >> > >> > Content-Disposition: ... preview-type parameter. The = preview-type >> > indicates the media type (and optional parameters) that a = receiving >> > application may present to a user as a "preview" of the = content. The >> > preview-type parameter is advisory and does not dictate or = constrain >> > the semantics of the content in any way, but rather provides a >> > useful way to duplicate the sender's intent with regard to how = the >> > content should look when processed. The syntax of the = preview-type >> > parameter is the same as the field value of the RFC 2045 >> > Content-Type header, i.e., a media type and optional = parameters, >> > delimited by semicolons. >> > >> > >> > The purpose of this parameter is for Markdown content. Obviously, = it >> > could be used for other formats, but I am not concerned with those = at >> > this time. >> > >> > (The choice of "preview-type" for a parameter name is meant to >> > distinguish this from other kinds of previews, such as = "preview-image", >> > "preview-thumbnail", "preview-soundbite", etc.) >> > >> > 1) Can we get agreement on this preview-type parameter? >=20 >> Unanimous agreement? NO. As I (and others) have said, it just = doesn't >> make sense and isn't necessary. That doesn't seem to be persuading = you >> from moving forward with the mission of creating a needlessly >> complicated media type however. >=20 >> It feels as though my difficulty understanding this proposal is that >> there is a "hidden" agenda that I am unaware of. It's like being = asked >> to pack a suitcase without knowing the destination. >=20 > The only agenda I see here is a desire to provide a label for = something > that is different from any existing media type along with a parameter > completely separate from the media type that can be used by content > creator to suggest handling to someone processing the content. That is correct. Let me give two concrete examples: Example #1: The Markdown Editor. That=92s the example given in draft-03 = (Section 1.3), and one that we are probably all familiar with. On the = left-hand side, you see syntax highlighting on plain text. On the = right-hand side, you see a preview of the processed content. It is useful to use Markdown-like syntaxes for things other than = text/html. For example, if you write a scholarly article with it, you = might want application/pdf output (which looks sort of TeX-like). Or if = you are writing an RFC, you might want text/plain output (in RFC style). Assuming that your Markdown editor is modular, it=92s quite easy to = treat the right-hand side as a generic Web Browser object thing, and = feed the web browser object some kind of labeled content = (data:application/pdf,=85=85). Then the component will magically present = the right stuff. This leads me directly to Example #2: = https://github.com/cabo/kramdown-rfc2629/blob/master/examples/stupid-s.mkd= In this case, GitHub recognizes that the thing is some kind of Markdown, = so it shows a preview of it=85a really poor one at that. Firstly, it=92s = not identified as kramdown, so GitHub runs its GitHub Flavored Markdown = processor on it. Sure, you kind of get the gist, but the YAML is all = screwed up and the {: =85 } attributes are showing. Ideally, if this were tagged as =93preview this as an RFC=94, we could = get something slightly more RFC-like. Note that the option to get the = raw view is always there, and guess what, it=92s the same content but = it=92s relabeled as text/plain (but obviously this is source code view, = not text/plain-as-RFC-view). Anyway one upside of putting this in the Content-Disposition header is = that the media type registration template itself is one parameter = shorter, and I take it that is a goal. > Personally, I have no problem with the parameter although the word = "preview" > doesn't seem to fit very well, and my preference is to keep the = parameter in > this RFC. Definitely open to suggestions on parameter names (to keep score: = currently the ones on the table are =93preview-type=94 and = =93output-type=94). -Sean --Apple-Mail=_E92F88B3-8EDA-46EA-A95C-C056219C8745 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO7TCCBJ0w ggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsG AQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlfsXzw PlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1ctxE +2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj2iC0 o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRowggQCoAMCAQICEG0Z 6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAw NTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdC lOD5J3EHxcZppLkyxPFAGpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh3 37EXrMLaggLW1DJq1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJA AVtIaN3FSrTg7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJy ZCaRTqWSD//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOC AUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEE aDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF0q0bc24+6SZ85kyY wTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6L566k3nK/uKRHlZ0sviN 0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6 PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrR eTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqT PDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0EwHhcNMTMxMTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J 9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2g uKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G 53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia33JN+ oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5j b20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50 ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMf WE2/5myX518DB+kTa5iQDbKYRuJp3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmI H4kfI4LWrY8XrPhlX3JmHjD6hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3 jx9VF/gA3vqYpL+jNumInz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d 9ljRDEiAts5OopkeeFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYID rjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggHZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MTAyNzAyMjY1MFowIwYJKoZIhvcNAQkEMRYEFFutDsv3tA5Zoo23NRmgOoVf y6HLMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQDKkzwxu6lupsyQvhKSvQd8MIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEBBQAE ggEAzW4tvKMh/fY/FvJvds2WWiuhLxv52Sm2lzSsRHQfEDNgOXIIvZxXCkUbCEU2tpaytJaXyWnl 9TLlOF07A5GIePxE6Iv4VXdnwrfrUr6/gWva3z+yX6BabDg6+hJNDSugTjiGFTB4+39LOHqBZR/N J8oBw4u8y6I4t/ih0D7lmLRllcCVEMXpw3fo44fDAMdoT3WNy0RVLgt8rXuhuo7KZyysLnIL8NT3 7LmYcNNRUl4VVOL9O1DR6MnRnlKt/pe5FKPge60JjJRDhxDJmSTcwi1l4tobvsHsjoAl2CbKKySl VxTc2yOqqrUHIQiaKtnmcm5bq4QO2lZnrvrqLLErhAAAAAAAAA== --Apple-Mail=_E92F88B3-8EDA-46EA-A95C-C056219C8745-- From nobody Sun Oct 26 20:22:58 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5843C1A6FA7 for ; Sun, 26 Oct 2014 20:22:54 -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 WtxgUjpKEjRO for ; Sun, 26 Oct 2014 20:22:51 -0700 (PDT) Received: from cp.hebergementsolutions.com (cp.hebergementsolutions.com [184.170.132.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CAD01A6FA3 for ; Sun, 26 Oct 2014 20:22:51 -0700 (PDT) Received: from [173.246.4.57] (port=61124 helo=minimi.michelf.ca) by cp.hebergementsolutions.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1Xiau6-0004pD-Uy; Sun, 26 Oct 2014 23:23:35 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_6FFFCBD6-BAD3-4FBD-A790-F6A501A7C373"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michel Fortin In-Reply-To: <94B993C2-29D2-4AE6-9B7B-32417F7E1B9D@seantek.com> Date: Sun, 26 Oct 2014 23:22:44 -0400 Message-Id: References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <01PDWHBG1ZY200005L@mauve.mrochek.com> <544C81B2.6090409@seantek.com> <544D408B.3090404@fletcherpenney.net> <01PE7F4UX0780028JO@mauve.mrochek.com> <94B993C2-29D2-4AE6-9B7B-32417F7E1B9D@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.1990.1) X-cPanel-MailScanner-Information: Please contact the ISP for more information X-cPanel-MailScanner-ID: 1Xiau6-0004pD-Uy X-cPanel-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-cPanel-MailScanner-SpamCheck: X-cPanel-MailScanner-From: michel.fortin@michelf.ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cp.hebergementsolutions.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - michelf.ca X-Get-Message-Sender-Via: cp.hebergementsolutions.com: authenticated_id: michel.fortin@michelf.ca Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6uShflYF7zhplsm9J5rvZl6Oc7M Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 03:22:54 -0000 --Apple-Mail=_6FFFCBD6-BAD3-4FBD-A790-F6A501A7C373 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Le 26-oct.-2014 =E0 22:26, Sean Leonard a =E9crit = : > Let me give two concrete examples: :-) I think examples are a good way to validate if this is useful. Let's = see... > Example #1: The Markdown Editor. That=92s the example given in = draft-03 (Section 1.3), and one that we are probably all familiar with. = On the left-hand side, you see syntax highlighting on plain text. On the = right-hand side, you see a preview of the processed content. >=20 > It is useful to use Markdown-like syntaxes for things other than = text/html. For example, if you write a scholarly article with it, you = might want application/pdf output (which looks sort of TeX-like). Or if = you are writing an RFC, you might want text/plain output (in RFC style). Note that someone might also want more than one output to publish the = thing in various formats. Also, why a "text/plain" output would be in = RFC style? Personally I'd expect to see the raw markdown content in = text/plain. > Assuming that your Markdown editor is modular, it=92s quite easy to = treat the right-hand side as a generic Web Browser object thing, and = feed the web browser object some kind of labeled content = (data:application/pdf,=85=85). Then the component will magically present = the right stuff. But how does the editor app get the preview-type in the first place? The = only way that could potentially work is if the editor edits the file = directly via HTTP (with a special WebDAV server maybe?), otherwise there = is no Content-Disposition for local files. It is also unlikely that an editor app will support more than one = preview type (is there an app that does this currently?). Generally in = Markdown editor apps the side view is there to validate that what you = write is properly interpreted by the parser (it also makes the document = easier to read should you want to review your prose). That said, if = someone wants to preview the result within a particular presentation, = he'll probably need much more than an "output type" to achieve that = presentation. He'll want style sheets, fonts, etc., much more than a = Markdown document in short. I think storing the output type is either = too much information (not needed to validate the syntax and reread what = you wrote) or not not even close to be enough (not enough to do a = preview of the final result). So I don't see it as very useful in this = scenario. > This leads me directly to Example #2: > = https://github.com/cabo/kramdown-rfc2629/blob/master/examples/stupid-s.mkd= >=20 > In this case, GitHub recognizes that the thing is some kind of = Markdown, so it shows a preview of it=85a really poor one at that. = Firstly, it=92s not identified as kramdown, so GitHub runs its GitHub = Flavored Markdown processor on it. Sure, you kind of get the gist, but = the YAML is all screwed up and the {: =85 } attributes are showing. Again, same fundamental problem as above with the file system: Git = doesn't convey media types attributes, nor Content-Disposition. So = there's no way Github could know how to parse this file better (other = than having a kramdown-specific file extensions). Beside that, would = Github be willing to run kramdown and potentially many other third-party = Markdown parsers on their server and keep them up to date? This might = require a security- and performance-focused review I suppose. I suspect = they'd rather integrate the missing features in Github Flavored Markdown = instead, as there is much less to worry about this way. > Ideally, if this were tagged as =93preview this as an RFC=94, we could = get something slightly more RFC-like. Note that the option to get the = raw view is always there, and guess what, it=92s the same content but = it=92s relabeled as text/plain (but obviously this is source code view, = not text/plain-as-RFC-view). If Github wanted to support various presentational themes for viewing = Markdown files (such as RFC-like), they could already do it in a = proprietary way (go to a file, choose a theme, done). So far they = haven't, and I don't expect that's something they want to do. > Anyway one upside of putting this in the Content-Disposition header is = that the media type registration template itself is one parameter = shorter, and I take it that is a goal. Getting it out of the media type is a good thing. But I'm not convinced = it should be part of Content-Disposition either. I don't see anything in = those examples convincing me that preview-type would actually be useful = to add this attribute to Content-Disposition. --=20 Michel Fortin michel.fortin@michelf.ca https://michelf.ca --Apple-Mail=_6FFFCBD6-BAD3-4FBD-A790-F6A501A7C373 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMjTCCBjQw ggQcoAMCAQICAR8wDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAI6ByrMlixq5 piBb1m3JRDRfINXQII5OT8TWqeZz8zse9vt7fUZHaPVLFeWYlj8B9BA2uHhGfyZtPtyf0nYtnFPK g7xiSXX/apE16bFfYdtHka3qupMggZp1+OZmtAdRO/TRij5C2bV2o+kIf+53LfWav2tw6pICxfJO 9Hrjl7HbYo3+l3ul9YVB5SVKG8WLmMCkpm7ti1Z4LOYF0Y5AG3d8AqYS3/5aUWQN/ZQN4BMruXSJ GFYFYBDxu7jTBbBW9l2m4u/s80e+jkJ9P9XDXeOsclCsdAtY4F2C/kOH76j6fwiABKLx454BkTMt ukts/PLtzrIy37oV0UTiykmcFCXSmc1gQk+xz25vGs/D36Ve8L+2A+J7idUYP83A1wS4JLgb4Q7J Fzl/lqLO+IDM+AGH9cujofg7Pjl2HdyDq3FOn7eAz2ZPN+zGzes5/E8rK1QnTsk9tIsi7QRIPdAB TnhC8ImOaNjVkB9JGUJ2BAXwVLB5Dq9SEdnGiyWdS7a9fb+Tfy8D2wuOA9metV0hUlrPMHCmJtZR bFZAjOlQrKhMM5hE31Qal2HF6OkfVhtE0nvqgj6dLt3871yxSYh13c0OBF6kZPR9Sgij3GZhAwEN sESI065Wg0BRSoCtWB6RxATzwIyIGgD/Gm8uPp+cv9OtSrDRwNjGphN+MQ81oVh5MIIGUTCCBTmg AwIBAgIDCZgGMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTQwNDEwMDkzMjE4WhcNMTUwNDEyMDIxMjUzWjBnMRkwFwYDVQQNExBZbjhVdjUyNmNnNGJjcmlR MSEwHwYDVQQDDBhtaWNoZWwuZm9ydGluQG1pY2hlbGYuY2ExJzAlBgkqhkiG9w0BCQEWGG1pY2hl bC5mb3J0aW5AbWljaGVsZi5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM1xHBAc 28F84D5D/ITRvjBwB3dwI7osaLizqSCZhMRpXg4zWsxIoaDy6H9OTQdpaqY431ypMGiwd7vddirK pEn/DEVb0SItTb73touChfuVVE5LHYPKcL1CfRa0XJF4KhryeP/m9sPA4N4zLb7IR4HFioOkF/XL Hkh9bv12yXUK+6jWpSNaQNf/kUz2AlKUSSx4pW2kBH72EW4xreuRs30Qqft1rqwkL4LRhipd3GA9 0Pni7mOaNSKu3kGCHKz+/4+h4SUdNuD13nhZLwLFHyHhk4I+IpFyq5/vPFr/dFRg3rdpMxhgd+M/ H4rfaUm2Kb0ODq+7FXccjDSbhCFEc08CAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQD AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUu56gBRTHUtBmsqyG mqCVXtMAz9cwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYbWlj aGVsLmZvcnRpbkBtaWNoZWxmLmNhMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCC ASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRp b24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFy dHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29t L2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3Nw LnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2Fp YS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqG GGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAJjgunxV0rh494ufL ch4bvYfoewNrW9OIZjpyS3GTzjD+a8aUIctmXo5HilIew8NwaYzRRKhQ3V4uy3rPmpIGddZfXlxm jlejMlWCVcgBBuB2CziegUCWvJbpSjz4eM0dQX6nU0zAGV1iqWkdrIxMgkgeeGWZaWV+m2Qu/oWw 9EbgegPaz+cFJNbrZEjA06d9CKQJTn2MP7POPPSwDTlTHZ/b6/X1MckAfCeEm96CRCEEzBo06Yki UMJMOdqVggAyP7huNxo7TpnNfe7ylve4vsHBSxpW7NElcMaXIgFalFVmpxZICOvxcncajCmYOzJp cb+YJuJwkeYf5CMjGsBshzGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAwmYBjAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNDEwMjcwMzIyNDZaMCMGCSqGSIb3DQEJBDEWBBRDcZWaIrGg70sUgipwms+LvC60 dzCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwmYBjCB pwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCZgGMA0G CSqGSIb3DQEBAQUABIIBAESO5eF62svMRpnufIzeklm54jhh+EbQdlOb2vQqURuqQpV/5iH8P4n/ r+ETEOO4GSGh0uTWAYuIQnmpvUe+tWGeTFk40sSudbfdX4NyoSdJJ5xBXafBxHDpEaq/LQ+f5shd wNTPKRI70WJAw7J6yK5yf/edcZ8/+GMRFZqaxmZrlhc1SsGzo/1xFBs1TcUA9PCC84wwgHTpMqme amFGUAp/OPI6Tgg/m2hF1yREuGyNgeOYjnI0/HcdEGZyW4QXty+PyhtBEuI0nSUwjddDTj3NX/N5 i9A22CjHeV+UoYNHLw/e3sJo0nlOhButrM/OFj8kQMaqj7nTgUWX0IioCGYAAAAAAAA= --Apple-Mail=_6FFFCBD6-BAD3-4FBD-A790-F6A501A7C373-- From nobody Mon Oct 27 02:06:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A420A1A8A4C for ; Mon, 27 Oct 2014 02:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAt86Nn2BSts for ; Mon, 27 Oct 2014 02:05:58 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 068DD1A8A1A for ; Mon, 27 Oct 2014 02:05:57 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id q5so5734133wiv.17 for ; Mon, 27 Oct 2014 02:05:56 -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=I5JCNgLnQv0V0rtDWPmC7nOtZX8gKAeGzE0Iv3tisoU=; b=J2dl3Y4yK+GCSwEGFPNntZRbVuzgYchhG47U5xb1l0QjB85LOC0dcPmWqmaZxa10yC RqA7++PQHhvl9uFqh0H9DpRmXcwkHhPVyrsNZ+pEAxXXDZylkV+JIB3z3ZkiI+bk0na4 r5U8c5c2VNBM78WP1bw7NxJMjrdy6y5VX2WtpFRTrjB4lZRrqHsdrrNtcj+VwrNYyDo7 EazCye6nmD8SK5RU8PWZ6JtiSZzXAzoq9B/COp3cBXKlQjph4G/lHaVCqnI8iVumYq5E AC+e3OQ4aCWb95oig53eYuXHegw6ZVyItxbICP2W71c/AtnrAPXmUeTS2VsD+IuchJFs X7/Q== MIME-Version: 1.0 X-Received: by 10.194.143.7 with SMTP id sa7mr1136458wjb.110.1414400756664; Mon, 27 Oct 2014 02:05:56 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Mon, 27 Oct 2014 02:05:56 -0700 (PDT) Date: Mon, 27 Oct 2014 02:05:56 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e0115e732abd078050663d64c Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/GKs6Atd4bHIUPrMQQMrWEWRSoUI Subject: [apps-discuss] Preliminary IETF 91 APPSAWG/APPAREA agenda X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 09:05:59 -0000 --089e0115e732abd078050663d64c Content-Type: text/plain; charset=UTF-8 Colleagues, We have uploaded the preliminary agenda for our meeting: http://www.ietf.org/proceedings/91/agenda/agenda-91-appsawg As usual we have the 2.5hr 9:30am Monday slot. If you have requested time to present and you do not appear on the agenda, then we did not receive your request. You should re-send it to appsawg-chairs@tools.ietf.org. If you requested time and didn't get enough or got too much, please let us know so that we can adjust accordingly. If you would like to see something relevant to APPSAWG or the APP area covered, please let us know. -MSK, APPSAWG co-chair --089e0115e732abd078050663d64c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

We have uploaded th= e preliminary agenda for our meeting:

http://www.ietf.org/proceedings/9= 1/agenda/agenda-91-appsawg

As usual we have the 2.5hr 9:30= am Monday slot.

If you have requested time to present and you = do not appear on the agenda, then we did not receive your request.=C2=A0 Yo= u should re-send it to app= sawg-chairs@tools.ietf.org.

If you requested time and didn't= get enough or got too much, please let us know so that we can adjust accor= dingly.

If you would like to see something relevant to APPSAWG= or the APP area covered, please let us know.

-MSK, APPSAWG co= -chair

--089e0115e732abd078050663d64c-- From nobody Mon Oct 27 02:14:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E20F1A8A63 for ; Mon, 27 Oct 2014 02:14:47 -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 LjxE0EKuNQ1I for ; Mon, 27 Oct 2014 02:14:46 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6D81A701C for ; Mon, 27 Oct 2014 02:14:45 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id q5so5688943wiv.13 for ; Mon, 27 Oct 2014 02:14:44 -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=IW8NbcCYuKmTrL4d+GWHOnrj9XM+BfcFAC7RniPKCpI=; b=LvqR4ZqNt4j8YLt2VAMa1tXBgxvjjw4elb5KSJ5KI0pmL8O8hIGerHdFjUTkBfBnQh gwP66xrn+0gLJJWje5laYCnAO/9bCAG4rGAAE90ZCCqNIIAMBJnpLfBn/0pSU0gaMooq u5SzKkA0q1jHAXmnzFHG5RPZoXRlfNtSe0fK3lgoEBy4GLCn3cEWh7T67p0V0fFkyVXu UuOyk0XzQ4hIk8jvYZzsh3YHQDXNeLk11k6kKlyokeDpDJ8/FoNjDDrDOo6sg+HMmDqp 2SCLrjZ9egnqL+xslGO3cxAl6mOvCWQHxk7i6UQsr78SpoFXNn58MPsw0P2G2v8fCms+ FRug== MIME-Version: 1.0 X-Received: by 10.180.73.40 with SMTP id i8mr19293526wiv.30.1414401284517; Mon, 27 Oct 2014 02:14:44 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Mon, 27 Oct 2014 02:14:44 -0700 (PDT) In-Reply-To: References: Date: Mon, 27 Oct 2014 02:14:44 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d0438907d223583050663f6dd Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/AQPsJekM7HQLsCDI3ST68ccDOw4 Subject: Re: [apps-discuss] Preliminary IETF 91 APPSAWG/APPAREA agenda X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 09:14:47 -0000 --f46d0438907d223583050663f6dd Content-Type: text/plain; charset=UTF-8 On Mon, Oct 27, 2014 at 2:05 AM, Murray S. Kucherawy wrote: > > As usual we have the 2.5hr 9:30am Monday slot. > > Correction: 9:00am. -MSK --f46d0438907d223583050663f6dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 27, 2014 at 2:05 AM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:

As usual we have the 2.5hr 9:30am Monday slot.

Correction: 9= :00am.

-MSK
--f46d0438907d223583050663f6dd-- From nobody Mon Oct 27 03:24:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E526B1A8F3C; Mon, 27 Oct 2014 03:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.768 X-Spam-Level: * X-Spam-Status: No, score=1.768 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 ZawGP1af8QWy; Mon, 27 Oct 2014 03:24:02 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 449BE1A8ADA; Mon, 27 Oct 2014 03:24:02 -0700 (PDT) Received: internal info suppressed Date: Mon, 27 Oct 2014 11:23:58 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: draft-ietf-weirds-object-inventory.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Message-ID: User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1414405439; bh=M4kPST3mNAqUCKvQirSX8U610Cf6SzsPT+1igVB+0js=; h=Date:From:To:Subject; b=G1WpLMDpCEFrQR4ZSl8Mx3/y6G/4n8RR26EW17GyPi5L/sHrN57Q/bOrn0BmMfO21 1Z1/mibrHat4LYxP0nvnYQov5t+qCFvlv0LDu9aC8zT3/V2gdTP5Q2Lwy7gvji/ild AId4u9hRTAlIfB8Ud0/8Cq8NU/avozLUWiP27ugM= Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hmkZ0r2WFfyCDAI3r0T0gNbt-h8 Subject: [apps-discuss] Applications Area Directorate Review for draft-ietf-weirds-object-inventory-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 10:24:05 -0000 Document: draft-ietf-weirds-object-inventory Title: Registration Data Access Protocol Object Inventory Analysis Reviewer: Claudio Allocchio Review Date: 27 October 2014 IETF Last Call Date: 24 October 2014 IESG Telechat Date: 30 October 2014 Summary: this document attempta a usefule surver of what existing WHOIS servers can disclose "in public" for their registries contents. However there is a strong differenc in the accuracy of the selected statistical sample between RIRs and DNRs, thus before publishing this Informational document, I suggest making this fact more clear and evident. There may be data elements which ARE very useful for RDAP which just do not show up at all, but may be accessible after authentication. Major Issues: 3 Methodology The method used to collect data from existing whois servers, specifically for DNR objects, does not mention at all that many ccTLDs whois servers are "protected" against autmated queries, or just "closed" because of security and/or privacy reasons (avoid mass queries to find out available domains etc...). Of course this has an inflence on the data you collect, thus at least there should be a note mentioning this. Also, not all ccTLDs have a "nic.xx" existing domain, as this is not conpulsory. Last but not the least, many ccTLDs registries just "block" or do not support anymore whois queries again for privacy/security reasons and completely rely on authehticated web services. This makes the whole query method much less reliable than the RIR one (it did on 64% of the existinf DNR in all). This is somehow mentioned in 5.5 Limitations (nic.ccTLD choice) but again no mention o the above "security / privacy" related issues. This is not enough IMHO. Minor Issues: none. Nits: none. ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Mon Oct 27 03:31:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40211A8AEB for ; Mon, 27 Oct 2014 03:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qvrbUaqlboR for ; Mon, 27 Oct 2014 03:31:27 -0700 (PDT) Received: from relay14.mail.ox.ac.uk (relay14.mail.ox.ac.uk [163.1.2.162]) by ietfa.amsl.com (Postfix) with ESMTP id B6DEC1A8F4D for ; Mon, 27 Oct 2014 03:31:27 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay14.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1XihaA-0008GR-jy; Mon, 27 Oct 2014 10:31:26 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Xiha9-0007wj-8x; Mon, 27 Oct 2014 10:31:25 +0000 Message-ID: <544E1EFC.5050200@ninebynine.org> Date: Mon, 27 Oct 2014 10:31:24 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Melvin Carvalho References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-1eCiuewG-OF66P2ETVGVrIw4Uw Cc: Apps Discuss Subject: Re: [apps-discuss] Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 10:31:30 -0000 Hi, re: https://mailarchive.ietf.org/arch/msg/apps-discuss/Lz6QHHAD19BCM2Onhizu5HMFUx0 https://mailarchive.ietf.org/arch/msg/apps-discuss/aDpsrH5mgCmTZHIv-hJRcloTOuw On 21/10/2014 17:11, Melvin Carvalho wrote: > Hi all, I have the need to turn a local username at a host into an HTTP URI. I'm not sure this is the best venue for this discussion. Scanning ahead to some of the responses tends to reinforce this view. It seems to me that many of the linked data ideas that you refer or allude to are not entirely common currency in the IETF community. What you describe seems to me more like a *web* application, and as such I'd expect the relevant expertise to be more concentrated in W3C mailing lists (e.g. see below). But you're active in W3C community, so I guess you already know of such forums. FWIW, I have doubts that you'll find a single solution that will work at web scale, and would personally look to use a combination of available URIs, including acct:. You mentioned in another message that you need a master http: URI in your database for each user. I think for a system such as you describe to work at web scale, you'll need to deal at some level with aliasing of multiple URIs for a given user, which implies some kind of mapping between URIs (cf. http://sameas.org). In some circumstances, you may need to mint your own (such as when all you have for a user is an acct: URI). I can imagine a reasonable part of such a solution would be a .well-known registration along the lines you suggest, but that wouldn't be suitable for all host environments (e.g. those where applications don't completely control allocations in their domain URI space). Just my 2c. re: https://mailarchive.ietf.org/arch/msg/apps-discuss/gPepJl9WU9HClkh6zcOCAQMjP3E There are other communities who have addressed aspects of this problem; i.e. how to identify people separately from their current memberships or affiliations. One that comes to mind is ORCID, providing identifiers for academic researchers (http://orcid.org). But this depends on an additional registration step with (yet) another registry, so as such is maybe just an example of XKCD on standards (http://xkcd.com/927/). #g (also: http://orcid.org/0000-0002-0323-0093 :) -- http://lists.w3.org - look for lists that mention "linked data" or "semantic web"; e.g. http://lists.w3.org/Archives/Public/semantic-web/ (this is where such http://lists.w3.org/Archives/Public/public-lod/2014Oct/ http://www.w3.org/standards/semanticweb/data http://www.w3.org/wiki/LinkedData http://www.w3.org/TR/2012/WD-vocab-people-20120405/ On 21/10/2014 17:11, Melvin Carvalho wrote: > Hi all, I have the need to turn a local username at a host into an HTTP URI. > > There are 3 cases: > > 1. User already has an HTTP URI ( e.g. https://graph.facebook.com/mark# ) > -- easy, I just use that. > > 2. User has a profile document but no user URI ( e.g. > https://twitter.com/mark ) -- I have settled on a soution here, by adding > the #this keyword. > > 3. I know the local user name and host but do not know a profile URL. e.g. > ( mark / example.org ). My proposal is to use the '.well-known' pattern > here and use the URL http:/example.org/.well-known/user/mark as the profile > document. > > I cant think of anything better right now, any suggestions, or feedback on > (3) would we welcome! > > Is it worth trying to register this pattern with IANA, or should that > follow implementations? > > Thanks in advance! > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Mon Oct 27 03:44:53 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2261A908F; Mon, 27 Oct 2014 03:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.037 X-Spam-Level: *** X-Spam-Status: No, score=3.037 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_35=0.6, MIME_CHARSET_FARAWAY=2.45, SPF_HELO_PASS=-0.001, 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 0iy2YpEk0iNc; Mon, 27 Oct 2014 03:44:39 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 01E411A9078; Mon, 27 Oct 2014 03:44:24 -0700 (PDT) Received: from [192.168.100.173] (unknown [218.241.119.125]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0B5gbnrIU5UobfGAA--.10059S2; Mon, 27 Oct 2014 18:44:04 +0800 (CST) Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Content-Type: text/plain; charset=gb2312 From: Ning Kong In-Reply-To: Date: Mon, 27 Oct 2014 18:43:55 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0114E1A0-9B1E-4E56-A816-1DB70EAA202B@cnnic.cn> References: To: Claudio Allocchio X-Mailer: Apple Mail (2.1990.1) X-CM-TRANSID: AQAAf0B5gbnrIU5UobfGAA--.10059S2 X-Coremail-Antispam: 1UD129KBjvJXoW7WrWrAw48GF15CF4kZw4xWFg_yoW8tFWrpa nakw4xKan5tF1UArykA3W8WF1Yvw4DC3y5Jan5X347Aa98Cr1YkF4fKws09a9xJFyxAF4q q3sxt3s8Gw4vk3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvG14x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26r4j6ryUM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j 6F4UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII jxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVW8JVWxJwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IYc2Ij64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7MxkF7I0Ew4C26cxK6c8I j28IcwCY02Avz4vE14v_Gw1l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr 1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE 14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7 IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY 6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa 73UjIFyTuYvjTRiwIhDUUUU X-CM-SenderInfo: xqnr0ww6fq0xffof0/ Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/20UO30AXBjhKHS_TQeKFM26XgbQ Cc: draft-ietf-weirds-object-inventory.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Applications Area Directorate Review for draft-ietf-weirds-object-inventory-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 10:44:40 -0000 Hi Claudio, Thanks for your comments. Because we only queried each WHOIS server once, so the query rate = limitation was not a problem for us. But you=A1=AFre right that we could only get the public data from WHOIS = servers having nic.ccTLD, so our data was not very common.=20 We=A1=AFll add more explanation to clarify the issue you mentioned on = the limitation section in the next version. Cheers, Ning > =D4=DA 2014=C4=EA10=D4=C227=C8=D5=A3=AC=CF=C2=CE=E76:23=A3=ACClaudio = Allocchio =D0=B4=B5=C0=A3=BA >=20 >=20 > Document: draft-ietf-weirds-object-inventory > Title: Registration Data Access Protocol Object Inventory Analysis > Reviewer: Claudio Allocchio > Review Date: 27 October 2014 > IETF Last Call Date: 24 October 2014 > IESG Telechat Date: 30 October 2014 >=20 > Summary: >=20 > this document attempta a usefule surver of what existing WHOIS servers = can disclose "in public" for their registries contents. However there is = a strong differenc in the accuracy of the selected statistical sample = between RIRs and DNRs, thus before publishing this Informational = document, I suggest making this fact more clear and evident. There may = be data elements which ARE very useful for RDAP which just do not show = up at all, but may be accessible after authentication. >=20 > Major Issues: >=20 > 3 Methodology > The method used to collect data from existing whois servers, = specifically for DNR objects, does not mention at all that many ccTLDs = whois servers are "protected" against autmated queries, or just "closed" = because of security and/or privacy reasons (avoid mass queries to find = out available domains etc...). Of course this has an inflence on the = data you collect, thus at least there should be a note mentioning this. = Also, not all ccTLDs have a "nic.xx" existing domain, as this is not = conpulsory. Last but not the least, many ccTLDs registries just "block" = or do not support anymore whois queries again for privacy/security = reasons and completely rely on authehticated web services. This makes = the whole query method much less reliable than the RIR one (it did on = 64% of the existinf DNR in all). >=20 > This is somehow mentioned in 5.5 Limitations (nic.ccTLD choice) but = again no mention o the above "security / privacy" related issues. This = is not enough IMHO. From nobody Mon Oct 27 04:18:23 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A6F1A8F49 for ; Mon, 27 Oct 2014 04:18:20 -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 uJKbA8OEgyXm for ; Mon, 27 Oct 2014 04:18:17 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A67841A6F34 for ; Mon, 27 Oct 2014 04:18:16 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id f15so1844899lbj.9 for ; Mon, 27 Oct 2014 04:18:15 -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=FLpb2johR4tN77YdEMlHoixLc0JjO/6yg/kdqBA6vEQ=; b=cO7Nxa49e3m0qXKjaNImjJ/h0h7DGOFxQAosbwryJDsJd2yraBLmW7Je9jDkpfCu0I 1gMFPv7t24ASRmCXXHcgbX3mD0SVXZtgbIFdleecJq03u2FnZCHpf96n769ZXYcbIj84 EweCNqpdgjd4K4K5FL8hQJSotarXsZa6dEHtB+Hyg8QWz7kowLJxS1aA/cxpadxkrRdp JK8zlRVmRfjbvL/T9tlkWNREt6kOYs/xTZ1wZIhm2F/qvbr98nOsxogHsgrS/KGOjvBq qgR0xpKQeNrbziMe9KPbANUBgx3biLtlAJJPZdppiJ9UOUY+FWbPCVxIONkGA75xeGy8 qtDA== MIME-Version: 1.0 X-Received: by 10.112.169.6 with SMTP id aa6mr23160901lbc.29.1414408694870; Mon, 27 Oct 2014 04:18:14 -0700 (PDT) Received: by 10.112.1.234 with HTTP; Mon, 27 Oct 2014 04:18:14 -0700 (PDT) In-Reply-To: <544E1EFC.5050200@ninebynine.org> References: <544E1EFC.5050200@ninebynine.org> Date: Mon, 27 Oct 2014 12:18:14 +0100 Message-ID: From: Melvin Carvalho To: Graham Klyne Content-Type: multipart/alternative; boundary=001a11c38e96d33a99050665af9e Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/X5UYdVcEPvwt68Ucwmu9OWs7rm4 Cc: Apps Discuss Subject: Re: [apps-discuss] Giving a user an HTTP URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 11:18:20 -0000 --001a11c38e96d33a99050665af9e Content-Type: text/plain; charset=UTF-8 On 27 October 2014 11:31, Graham Klyne wrote: > Hi, > > re: > https://mailarchive.ietf.org/arch/msg/apps-discuss/ > Lz6QHHAD19BCM2Onhizu5HMFUx0 > https://mailarchive.ietf.org/arch/msg/apps-discuss/ > aDpsrH5mgCmTZHIv-hJRcloTOuw > > On 21/10/2014 17:11, Melvin Carvalho wrote: > > Hi all, I have the need to turn a local username at a host into an HTTP > URI. > > I'm not sure this is the best venue for this discussion. Scanning ahead > to some of the responses tends to reinforce this view. It seems to me that > many of the linked data ideas that you refer or allude to are not entirely > common currency in the IETF community. What you describe seems to me more > like a *web* application, and as such I'd expect the relevant expertise to > be more concentrated in W3C mailing lists (e.g. see below). But you're > active in W3C community, so I guess you already know of such forums. > +1 I am familiar with the W3C work, however, and have discuses similar topics at length. However, I felt discussion of the using the .well-known pattern, and IANA registry, may belong on the IETF list. I hope this was not a bad assumption. Guidance very welcome, as ever. > > FWIW, I have doubts that you'll find a single solution that will work at > web scale, and would personally look to use a combination of available > URIs, including acct:. You mentioned in another message that you need a > master http: URI in your database for each user. I think for a system such > as you describe to work at web scale, you'll need to deal at some level > with aliasing of multiple URIs for a given user, which implies some kind of > mapping between URIs (cf. http://sameas.org). In some circumstances, you > may need to mint your own (such as when all you have for a user is an acct: > URI). > +1 sameAs will likely come into play after the initial implementation, I was more looking for a logical starting point. > > I can imagine a reasonable part of such a solution would be a .well-known > registration along the lines you suggest, but that wouldn't be suitable for > all host environments (e.g. those where applications don't completely > control allocations in their domain URI space). > > Just my 2c. > +1 totally agree, I think the resolution is to create an implementation, and if it goes somewhere think about registration. > > > re: > https://mailarchive.ietf.org/arch/msg/apps-discuss/ > gPepJl9WU9HClkh6zcOCAQMjP3E > > There are other communities who have addressed aspects of this problem; > i.e. how to identify people separately from their current memberships or > affiliations. One that comes to mind is ORCID, providing identifiers for > academic researchers (http://orcid.org). But this depends on an > additional registration step with (yet) another registry, so as such is > maybe just an example of XKCD on standards (http://xkcd.com/927/). > Thanks, I will check! > > #g (also: http://orcid.org/0000-0002-0323-0093 :) > -- > > > http://lists.w3.org - look for lists that mention "linked data" or > "semantic web"; e.g. > > http://lists.w3.org/Archives/Public/semantic-web/ (this is where such > http://lists.w3.org/Archives/Public/public-lod/2014Oct/ > > http://www.w3.org/standards/semanticweb/data > http://www.w3.org/wiki/LinkedData > http://www.w3.org/TR/2012/WD-vocab-people-20120405/ > > > > > On 21/10/2014 17:11, Melvin Carvalho wrote: > >> Hi all, I have the need to turn a local username at a host into an HTTP >> URI. >> >> There are 3 cases: >> >> 1. User already has an HTTP URI ( e.g. https://graph.facebook.com/mark# ) >> -- easy, I just use that. >> >> 2. User has a profile document but no user URI ( e.g. >> https://twitter.com/mark ) -- I have settled on a soution here, by adding >> the #this keyword. >> >> 3. I know the local user name and host but do not know a profile URL. >> e.g. >> ( mark / example.org ). My proposal is to use the '.well-known' pattern >> here and use the URL http:/example.org/.well-known/user/mark as the >> profile >> document. >> >> I cant think of anything better right now, any suggestions, or feedback on >> (3) would we welcome! >> >> Is it worth trying to register this pattern with IANA, or should that >> follow implementations? >> >> Thanks in advance! >> >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> --001a11c38e96d33a99050665af9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 27 October 2014 11:31, Graham Klyne <gk@ninebynine.org> wrote:
Hi,

re:
=C2=A0 https://mailarchive.ietf.org/arch/msg/apps-discuss/Lz6QHHAD19BCM2Onhizu5HMFUx0
=C2=A0 https://mailarchive.ietf.org/arch/msg/apps-discuss/aDpsrH5mgCmTZHIv-hJRcloTOuw

On 21/10/2014 17:11, Melvin Carvalho wrote:
> Hi all, I have the need to turn a local username at a host into an HTT= P URI.

 I'm not sure this is the best venue for this discussion.=C2=A0 Scanning= ahead to some of the responses tends to reinforce this view.=C2=A0 It seem= s to me that many of the linked data ideas that you refer or allude to are = not entirely common currency in the IETF community.=C2=A0 What you describe= seems to me more like a *web* application, and as such I'd expect the = relevant expertise to be more concentrated in W3C mailing lists (e.g. see b= elow).=C2=A0 But you're active in W3C community, so I guess you already= know of such forums.

+1

I am fa= miliar with the W3C work, however, and have discuses similar topics at leng= th.=C2=A0

However, I felt discussion of the using the .well-known p= attern, and IANA registry, may belong on the IETF list.=C2=A0 I hope this w= as not a bad assumption.=C2=A0 Guidance very welcome, as ever.
=C2=A0

FWIW, I have doubts that you'll find a single solution that will work a= t web scale, and would personally look to use a combination of available UR= Is, including acct:.=C2=A0 You mentioned in another message that you need a= master http: URI in your database for each user.=C2=A0 I think for a syste= m such as you describe to work at web scale, you'll need to deal at som= e level with aliasing of multiple URIs for a given user, which implies some= kind of mapping between URIs (cf. http://sameas.org).=C2=A0 In some circumstances, you may need t= o mint your own (such as when all you have for a user is an acct: URI).
=

+1

sameAs will likely come into pl= ay after the initial implementation, I was more looking for a logical start= ing point.=C2=A0
=C2=A0

I can imagine a reasonable part of such a solution would be a .well-known r= egistration along the lines you suggest, but that wouldn't be suitable = for all host environments (e.g. those where applications don't complete= ly control allocations in their domain URI space).

Just my 2c.

+1 totally agree, I think t= he resolution is to create an implementation, and if it goes somewhere thin= k about registration.=C2=A0

=C2=A0

re:
=C2=A0 https://mailarchive.ietf.org/arch/msg/apps-discuss/gPepJl9WU9HClkh6zcOCAQMjP3E

There are other communities who have addressed aspects of this problem; i.e= . how to identify people separately from their current memberships or affil= iations. One that comes to mind is ORCID, providing identifiers for academi= c researchers (http://orcid.= org).=C2=A0 But this depends on an additional registration step with (y= et) another registry, so as such is maybe just an example of XKCD on standa= rds (http://xkcd.com/927= /).

Thanks, I will check!
=
=C2=A0

#g=C2=A0 (also: http://orcid.org/0000-0002-0323-0093 :)
--


http://lists.w3.org -= look for lists that mention "linked data" or "semantic web&= quot;; e.g.

http://lists.w3.org/Archives/Public/semantic-web/ (this is = where such
http://lists.w3.org/Archives/Public/public-lod/2014Oct/<= /a>

= http://www.w3.org/standards/semanticweb/data
http://www.= w3.org/wiki/LinkedData
http://www.w3.org/TR/2012/WD-vocab-people-20120405/
<= div class=3D"h5">



On 21/10/2014 17:11, Melvin Carvalho wrote:
Hi all, I have the need to turn a local username at a host into an HTTP URI= .

There are 3 cases:

1. User already has an HTTP URI ( e.g. https://graph.facebook.com/mark# ) -- easy, I just use that.

2. User has a profile document but no user URI ( e.g.
https://twitter.com/= mark ) -- I have settled on a soution here, by adding
the #this keyword.

3. I know the local user name and host but do not know a profile URL.=C2=A0= e.g.
( mark / example.org )= .=C2=A0 My proposal is to use the '.well-known' pattern
here and use the URL http:/example.org/.well-known/user/mark as the = profile
document.

I cant think of anything better right now, any suggestions, or feedback on<= br> (3) would we welcome!

Is it worth trying to register this pattern with IANA, or should that
follow implementations?

Thanks in advance!



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


--001a11c38e96d33a99050665af9e-- From nobody Mon Oct 27 05:05:20 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1925F1A9148 for ; Mon, 27 Oct 2014 05:05:19 -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 f9frFXOHRvck for ; Mon, 27 Oct 2014 05:05:16 -0700 (PDT) Received: from relay14.mail.ox.ac.uk (relay14.mail.ox.ac.uk [163.1.2.162]) by ietfa.amsl.com (Postfix) with ESMTP id 64BAF1A9144 for ; Mon, 27 Oct 2014 05:05:03 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay14.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Xij2i-0000mr-ji; Mon, 27 Oct 2014 12:05:00 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Xij2h-0002X5-8Z; Mon, 27 Oct 2014 12:05:00 +0000 Message-ID: <544E34EA.3090406@ninebynine.org> Date: Mon, 27 Oct 2014 12:04:58 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sean Leonard References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <01PDWHBG1ZY200005L@mauve.mrochek.com> <544C81B2.6090409@seantek.com> <544D408B.3090404@fletcherpenney.net> <01PE7F4UX0780028JO@mauve.mrochek.com> <94B993C2-29D2-4AE6-9B7B-32417F7E1B9D@seantek.com> In-Reply-To: <94B993C2-29D2-4AE6-9B7B-32417F7E1B9D@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ynVCXDuq9QbdcG68EntypRTzI6I Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown draft-03 guide (and use-cases-00 guide) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 12:05:19 -0000 Sean, I'm agnostic about whether or not it's useful to define a content-disposition parameter. I don't see a particular use for it, but I don't see a problem or have any deep objection. But it seems to me that the examples you give are not really about content disposition or output format, but refer to how the author intends the Markdown text to be interpreted (i.e. what variation(s) of Markdown is being assumed by the author). As such, these examples are of things which I would expect to be communicated by a (simple!) "flavors" (or whatever it's called) parameter on the content type. #g -- On 27/10/2014 02:26, Sean Leonard wrote: > > On Oct 26, 2014, at 1:34 PM, Ned Freed wrote: > >> >> >>> On 10/26/14, 1:08 AM, Sean Leonard wrote: >> >>>> In order to keep this draft moving, I'd like to focus on specific >>>> technical issues. >>>> >>>> Based on feedback thus far it seems that there is some support for >>>> conveying an output media type, but it should not be part of the >>>> text/markdown media type's parameters. >> >>> It may be true that there is support for it, but there is also >>> opposition to an output media type, regardless of what you call it. >> >>> Perhaps I am just dumb. It seems to me that the purpose of a media type >>> is to say, "What I am about to send/attach/etc. is digital content that >>> represents a picture/sound/movie/file/etc." I did not understand that a >>> media type should then say, "Now that you have the file, here's what you >>> have to do with it." >> >> Indeed. The name parameter was removed from application/octet-stream and moved >> to content-disposition because it didn't fit this model. >> >> But this is argument against preview-type as a media type parameter. It says nothing about it being defined as a content-disposition parameter, which >> is what's being proposed here. > > That is correct, and that is what I am proposing. This is not a media type parameter; it’s a Content-Disposition parameter. > > RFC 2183 says: > MIME specifies a standard format for encapsulating multiple pieces of > data into a single Internet message. That document does not address > the issue of presentation styles; it provides a framework for the > interchange of message content, but leaves presentation issues solely > in the hands of mail user agent (MUA) implementors. > > Two common ways of presenting multipart electronic messages are as a > main document with a list of separate attachments, and as a single > document with the various parts expanded (displayed) inline. The > display of an attachment is generally construed to require positive > action on the part of the recipient, while inline message components > are displayed automatically when the message is viewed. A mechanism > is needed to allow the sender to transmit this sort of presentational > information to the recipient; the Content-Disposition header provides > this mechanism, allowing each component of a message to be tagged > with an indication of its desired presentation semantics. > > >> >>> In this case, the content is plain text. The plain text happens to >>> follow a set of rules/guidelines/whatever that allow some programs to do >>> something with that text (e.g. convert to HTML). *Whether* that happens >>> is up to the user receiving the file, not the person sending it. >> >> Here we disagree. The content is *not* plain text. It's text containing a type >> of markup intended to be interpreted in a particular way. The fact that the >> markup is defined in a fairly loose way doesn't make it unformatted a la >> text/plain. > > Right. > > Note that any textual data can be relabeled as text/plain; this changes the textual data’s semantics. If you serve text/html as text/plain, it will show the source as plain text. There is differential handling involved. > >> >> There's also lots of running code here. For example, comma separated values >> have their own media type, but are also a subset of plain text. >> >>>> Proposal: >>>> >>>> Content-Disposition: ... preview-type parameter. The preview-type >>>> indicates the media type (and optional parameters) that a receiving >>>> application may present to a user as a "preview" of the content. The >>>> preview-type parameter is advisory and does not dictate or constrain >>>> the semantics of the content in any way, but rather provides a >>>> useful way to duplicate the sender's intent with regard to how the >>>> content should look when processed. The syntax of the preview-type >>>> parameter is the same as the field value of the RFC 2045 >>>> Content-Type header, i.e., a media type and optional parameters, >>>> delimited by semicolons. >>>> >>>> >>>> The purpose of this parameter is for Markdown content. Obviously, it >>>> could be used for other formats, but I am not concerned with those at >>>> this time. >>>> >>>> (The choice of "preview-type" for a parameter name is meant to >>>> distinguish this from other kinds of previews, such as "preview-image", >>>> "preview-thumbnail", "preview-soundbite", etc.) >>>> >>>> 1) Can we get agreement on this preview-type parameter? >> >>> Unanimous agreement? NO. As I (and others) have said, it just doesn't >>> make sense and isn't necessary. That doesn't seem to be persuading you >>> from moving forward with the mission of creating a needlessly >>> complicated media type however. >> >>> It feels as though my difficulty understanding this proposal is that >>> there is a "hidden" agenda that I am unaware of. It's like being asked >>> to pack a suitcase without knowing the destination. >> >> The only agenda I see here is a desire to provide a label for something >> that is different from any existing media type along with a parameter >> completely separate from the media type that can be used by content >> creator to suggest handling to someone processing the content. > > That is correct. > > Let me give two concrete examples: > Example #1: The Markdown Editor. That’s the example given in draft-03 (Section 1.3), and one that we are probably all familiar with. On the left-hand side, you see syntax highlighting on plain text. On the right-hand side, you see a preview of the processed content. > > It is useful to use Markdown-like syntaxes for things other than text/html. For example, if you write a scholarly article with it, you might want application/pdf output (which looks sort of TeX-like). Or if you are writing an RFC, you might want text/plain output (in RFC style). > > Assuming that your Markdown editor is modular, it’s quite easy to treat the right-hand side as a generic Web Browser object thing, and feed the web browser object some kind of labeled content (data:application/pdf,……). Then the component will magically present the right stuff. > > This leads me directly to Example #2: > https://github.com/cabo/kramdown-rfc2629/blob/master/examples/stupid-s.mkd > > In this case, GitHub recognizes that the thing is some kind of Markdown, so it shows a preview of it…a really poor one at that. Firstly, it’s not identified as kramdown, so GitHub runs its GitHub Flavored Markdown processor on it. Sure, you kind of get the gist, but the YAML is all screwed up and the {: … } attributes are showing. > > Ideally, if this were tagged as “preview this as an RFC”, we could get something slightly more RFC-like. Note that the option to get the raw view is always there, and guess what, it’s the same content but it’s relabeled as text/plain (but obviously this is source code view, not text/plain-as-RFC-view). > > > Anyway one upside of putting this in the Content-Disposition header is that the media type registration template itself is one parameter shorter, and I take it that is a goal. > >> Personally, I have no problem with the parameter although the word "preview" >> doesn't seem to fit very well, and my preference is to keep the parameter in >> this RFC. > > Definitely open to suggestions on parameter names (to keep score: currently the ones on the table are “preview-type” and “output-type”). > > > -Sean > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Mon Oct 27 05:19:41 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1FF1AC3B8 for ; Mon, 27 Oct 2014 05:19:38 -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 PnlbyseaKoWh for ; Mon, 27 Oct 2014 05:19:34 -0700 (PDT) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8681AC3AB for ; Mon, 27 Oct 2014 05:19:26 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1XijGe-0004Xe-hQ; Mon, 27 Oct 2014 12:19:24 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1XijGd-0002uG-9d; Mon, 27 Oct 2014 12:19:24 +0000 Message-ID: <544E384A.5030709@ninebynine.org> Date: Mon, 27 Oct 2014 12:19:22 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: IETF Apps Discuss References: <3F8A6179-ECE5-40B5-ACCD-413502675077@seantek.com> <9AD273B04D7CB4B07CE8D1C5@JcK-HP8200.jck.com> <543CDE33.4030402@ninebynine.org> <01PDQCNHFSIM00005K@mauve.mrochek.com> <543EA941.6030704@ninebynine.org> <54418809.6040404@ninebynine.org> In-Reply-To: <54418809.6040404@ninebynine.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Gv2x-axBrUh3WLKLQdXFAaKsi6c Cc: Ned Freed Subject: Re: [apps-discuss] Fragement identifiers for archives X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 12:19:38 -0000 Contrary to what I claimed in my previous email, I see the issue of packaged content *is* still live in the W3C TAG. This call for consensus to publish a TAG first public working draft which, if agreed, "the group sends a signal to the community to begin reviewing the document": http://lists.w3.org/Archives/Public/www-tag/2014Oct/0109.html I also note that this appears to a joint action between the W3C TAG and Web Applications working group. #g -- On 17/10/2014 22:20, Graham Klyne wrote: > Henry, > > While we agree that any move in this direction should take account of W3C > interests, I'm uncertain that the TAG is the best group to engage: > > - They are an *architecture* group, and it seems to me this is a design detail > not architecture. Jeni's draft (http://w3ctag.github.io/packaging-on-the-web/), > which I cited previously, addresses a specific issue (delivery of composite web > content), and provides a fairly comprehensive specification for fragment > identifiers. But I'd be concerned that this structure is very biased to the > particular requirements of packaged web pages, and might be over-complex or > difficult to apply to other archive formats. Maybe a subset of that proposal > could be used? > > - I've not been aware of any further TAG discussion since the publication of > http://w3ctag.github.io/packaging-on-the-web/ in April. > > - My sense is that the TAG are currently heavily concerned with > browser-as-platform issues, and aren't giving much attention to other topics. > > > The possible web communities of interest that I'm aware of that might have a > stake in any archive type and/or fragment proposal are: > > - W3C TAG, subject to reservations noted above > > - web applications: http://www.w3.org/2012/sysapps/ (with what appears to be a > focus on applications that run in a web browser). This group produced the app: > URI scheme proposal, which appears to be a way to define a URI that accesses > components of an archive in much the same way file: URIs access files in a file > system. > > - a research objects community group, who are interested in composite objects on > the web as a way of bundling information about research results. My take is > that the technical substrate to support this work would be quite similar to that > which would support the TAG's composite web page objects work. > > - parts of the library community who have been working on resource packaging and > synchronization, notably http://www.openarchives.org. ORE is specification to > describe composite archive content, and ResourceSync describes a form of > packaging for bulk synchronization of web resources. > > > As far as I can tell, introduction of a top-level archive type would complement, > not compromise, the work of most of these groups (but the TAG draft currently > proposes an application/package type). It would probably need to coexist with > e.g. application/zip for the foreseeable future, but I don't think that's been a > problem for (say) XML applications being application/... or text/... > > A common default fragment identifier syntax is less obviously independent - as > noted, there's a proposal for this in the TAG web packaging note. The app: > scheme addresses access to archive contents from a different start point and in > a different way, with which I think any common fragment syntax should aim to > provide a route to interoperability. I don't see any conflict with the Research > Objects work. There would be some overlap (but not conflict that I can see) > with aspects of the ResourceSync specification, > > #g > -- > > > On 16/10/2014 10:20, Henry S. Thompson wrote: >> Graham Klyne writes: >> >>> On 14/10/2014 16:37, Ned Freed wrote: >>>> Very good point. Do you think it would make sense to define a generic >>>> syntax (which of course could be overridden in specific cases)? >>> >>> I think it _could_ be useful and sensible - I've been involved in >>> design discussions where URI mechanisms to delve inside a composite >>> package have been raised, and it's been tricky to figure out what >>> would also play well in a wider web landscape. >> >> There has been, and I believe continues to be, _extensive_ discussion >> of this topic in the W3C TAG. A quick search suggests the most recent >> discussion was at the F2F in January 2014 [1], which resulted in a >> writeup from Jeni Tennison which in turn provoked various >> comments [2] [3]. >> >> Please review this record and then coordinate any further substantive >> work in this area directly with the TAG (of which I am no longer a >> member). >> >> ht >> >> [1] http://www.w3.org/2001/tag/2014/01/08-minutes.html#item07 >> [2] http://lists.w3.org/Archives/Public/www-tag/2014Jan/0133.html >> [3] http://lists.w3.org/Archives/Public/www-tag/2014Feb/0030.html >> > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Mon Oct 27 11:30:53 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28531ACEC0 for ; Mon, 27 Oct 2014 11:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.023 X-Spam-Level: X-Spam-Status: No, score=0.023 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 OMJjXGXSsa2L for ; Mon, 27 Oct 2014 11:30:23 -0700 (PDT) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1041A9098 for ; Mon, 27 Oct 2014 11:27:59 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hq11so2670972vcb.22 for ; Mon, 27 Oct 2014 11:27:58 -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:from:date:message-id:subject:to:cc :content-type; bh=Ot88E7FWC/bBmaOtFDKy2tdznx4gK0lTAxioMLpV0bI=; b=bfSEZ3lpIWjMKszfwm7Izt5SFrfDNLXiXshflqiJ65+3fhbmYnSUFc2VCX/GSfRI3d 1v2KJGXFDOyo4oK8w3V7rm8RncPfKLpY2lDYo2VPkuNuM1AE24LGIb8A5mWKZRvy+p3a PLF9+YYKXFaUO475ZByAWJvP+e+SBgqa9p50JamQ0WFCBpWzpz133py81+RfM3hXyNHk zLQLpQJHYhqXA9IvkouVjOGFJIvwomTeP/etlYbbct7ngBc+0TzNOqO5Rt/U/DeTxUb4 AZ1bEG2RMXTNrMCjjHSNQh6XQexsknvgPsJqM9TVhBa3RxIyD88KgcOIfPu8U4g2mv3U anRQ== X-Gm-Message-State: ALoCoQkdR5GOkvmHq3T9xuWI1Ynec9NzyFiRrV8omTeCnTxLgOAzCnGVougK2WKw3ScQhK7bPkdQ X-Received: by 10.53.13.229 with SMTP id fb5mr39129vdd.82.1414434478554; Mon, 27 Oct 2014 11:27:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.187.3 with HTTP; Mon, 27 Oct 2014 11:27:38 -0700 (PDT) X-Originating-IP: [24.84.235.32] From: Tim Bray Date: Mon, 27 Oct 2014 11:27:38 -0700 Message-ID: To: "apps-discuss@ietf.org" , draft-ietf-weirds-json-response.all@tools.ietf.org, andy@arin.net, Hollenbeck Scott Content-Type: multipart/alternative; boundary=001a1134dcfca711a805066bb0e4 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/J1n9fMaIf779Ko-Xgw3JTyy_PLg Cc: The IESG Subject: [apps-discuss] Apps Area review of draft-ietf-weirds-json-response-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 18:30:27 -0000 --001a1134dcfca711a805066bb0e4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/are= a /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-weirds-json-response-10 Title: JSON Responses for the Registration Data Access Protocol (RDAP) Reviewer:Tim Bray Review Date: October 27, 2014 Summary: this is pretty clean, and generously equipped with examples, which is a good thing. I think the specification of extensibility is unacceptably messy but could be cleaned up easily. However, I think the fact that there are no Security Considerations is very troubling. Major issues: 10.1 The only security consideration in a protocol definition is the basic JSON stuff? Really? DNS vulnerabilities can be horribly damaging to the Internet; it=E2=80=99s hard to believe you can just skip over security considerations. If I were on the IESG I=E2=80=99d be having heartburn. Minor issues: Construction of new values with underscores. A few things: 1. Why not give these things a name such a =E2=80=9Cforeign members=E2=80= =9D or =E2=80=9Cforeign objects=E2=80=9D, short for =E2=80=9CJSON markup that is not specified in t= his document=E2=80=9D. Might make them easier to talk about. 2. You should also explicitly say that =E2=80=9Cthis document and its succe= ssors will never define an member name containing an underscore=E2=80=9D 3. Why don=E2=80=99t you restrict extensibility to members of objects with = names not defined in this spec? Practically speaking, that=E2=80=99s the only pla= ce they=E2=80=99re apt to turn up. Being specific would make the whole thing c= risper. In section 2.1, 2nd-last para =E2=80=9CClients processing JSON responses ne= ed to be prepared for values specified in this document to be absent from a response=E2=80=9D. Uh, do you man that ALL values specified in this documen= t are optional, none are compulsory? This is super-important and should be called out in its own section. Reading through the text, there seem to be several instances of some members being optional, others non-optional. So I=E2=80=99m actually not sure what this language is trying to say. 4.2 =E2=80=9CAll other JSON values are OPTIONAL=E2=80=9D. I don=E2=80=99t = understand a value being optional? Does it mean the value can be an empty string? Does it mean that the name/value member can be omitted? If true, doesn=E2=80=99t that imply t= hat some are mandatory, and conflict with the 2.1 statement that everything is optional? In general, there are a lot of different structures defined here, if some are required, others not, a shorthand way of flagging them one way or the other might be super-helpful to implementers 10.1 This is a really substantial and complicated registry. I=E2=80=99d li= ke to see some remarks about why a registry is called for in this case. Sorry if it was there and I missed it. Speaking as a person who=E2=80=99s been skeptical of JSON schema efforts, i= t pains me to say this, but the information about large-scale message structure is scattered through this document in a diffuse way and it=E2=80=99d make me n= ervous as an implementer whether or not I was getting it right. I think it might be helpful to have a =E2=80=9Clarge-scale message structure=E2=80=9D sectio= n that quickly runs through the allowable top-level shapes of messages, and exactly what can be nested inside what. Nits 1.1 Section numbers might be nice on the 7159 references, e.g. for Object 1.2 first para: =E2=80=9C=E2=80=A6 is conveyed in four sections=E2=80=9D. F= ollowed by a 5-member list 1.2 =E2=80=9CThe following object classes are served by=E2=80=A6=E2=80=9D = What does it mean for an =E2=80=9Cobject class=E2=80=9D to be =E2=80=9Cserved=E2=80=9D. Do you mean = =E2=80=9Creturned in response to a request? 2.1 =E2=80=9C=E2=80=A6SHOULD ignore unrecognized JSON attributes in respons= es=E2=80=9D What=E2=80=99s a JSON attribute? Do you mean unknown members in objects? 2.1 =E2=80=9CThis allowance does not apply to jCard=E2=80=9D. The word =E2= =80=9Callowance=E2=80=9D puzzles me. Do you mean the rule about the underscores? 2.1 =E2=80=9Cthese limitations have been given to aid some client programmi= ng models=E2=80=9D uh, =E2=80=9Cgiven to aid=E2=80=9D. Do you mean =E2=80=9Cob= served to aid=E2=80=9D or =E2=80=9Cshown to aid=E2=80=9D or some such? 3. =E2=80=9Cused in this document derived from the JSON character string=E2= =80=9D. What does =E2=80=9Cderived from=E2=80=9D mean? Do you mean to say that all the = data types in this section are encoded as JSON strings? 4.1 =E2=80=9CThe first data structure=E2=80=A6=E2=80=9D First in what sens= e? Is it extra important? Must appear first in the JSON instance? (I assume not, that=E2= =80=99s a very bad practice). 4.9 Object Class Name is actually (as with a few other things here) a name/value member of an object (if I=E2=80=99m reading correctly); why not = say so? 5.1 the example.vcard there=E2=80=99s an array containing ["", "", "", ... = which looked kind of weird to me. I=E2=80=99m assuming this will make perfect se= nse to someone who knows vcards? --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a1134dcfca711a805066bb0e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I ha= ve been selected as the Applications=C2=A0Area=C2=A0Directorate=C2=A0reviewer=C2=A0for=C2=A0this draft (for backgrou= nd on appsdir, please=C2=A0see http://tr= ac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirector= ate
).

Please resolve these comments along with any other Last Call comments<= /span>
you may receive. Please wait for direction from your document shepherd
= or AD before posting a new version of the draft.

Document:draft-ietf-we= irds-json-response-10
Title:=C2=A0JSON Responses for the Registration Data Access Protocol (RDAP)
Reviewer:Tim Bray
Review=C2= =A0Date: October 27, 2014

Summary: this is pretty clean, and generously equipped wi= th examples, which is a good thing.=C2=A0 I think the specification of exte= nsibility is unacceptably messy but could be cleaned up easily. =C2=A0

However, I think the fact tha= t there are no Security Considerations is very troubling.

Major issues:

10.1 The only security= consideration in a protocol definition is the basic JSON stuff?=C2=A0 Real= ly?=C2=A0 DNS vulnerabilities can be horribly damaging to the Internet; it= =E2=80=99s hard to believe you can just skip over security considerations.= =C2=A0 If I were on the IESG I=E2=80=99d be having heartburn.
Minor i= ssues:

Construction of ne= w values with underscores.=C2=A0 A few things:

1. Why not give these things a name such a =E2=80=9Cf= oreign members=E2=80=9D or =E2=80=9Cforeign objects=E2=80=9D, short for =E2= =80=9CJSON markup that is not specified in this document=E2=80=9D. Might ma= ke them easier to talk about.
2. You should also explicitly say that =E2=80=9Cthis documen= t and its successors will never define an member name containing an undersc= ore=E2=80=9D
3.= Why don=E2=80=99t you restrict extensibility to members of objects with na= mes not defined in this spec? Practically speaking, that=E2=80=99s the only= place they=E2=80=99re apt to turn up. Being specific would make the whole = thing crisper.
=
In section= 2.1, 2nd-last para =E2=80=9CClients processing JSON responses need to be p= repared for values specified in this document to be absent from a response= =E2=80=9D. Uh, do you man that ALL values specified in this document are op= tional, none are compulsory?=C2=A0 This is super-important and should be ca= lled out in its own section.=C2=A0 Reading through the text, there seem to = be several instances of some members being optional, others non-optional.= =C2=A0 So I=E2=80=99m actually not sure what this language is trying to say= .

=
4.2 =E2=80=9CAll other JSON values are OPTIONA= L=E2=80=9D.=C2=A0 I don=E2=80=99t understand a value being optional? Does i= t mean the value can be an empty string?=C2=A0 Does it mean that the name/v= alue member can be omitted? If true, doesn=E2=80=99t that imply that some a= re mandatory, and conflict with the 2.1 statement that everything is option= al?=C2=A0 In general, there are a lot of different structures defined here,= if some are required, others not, a shorthand way of flagging them one way= or the other might be super-helpful to implementers

10.1 This is a really su= bstantial and complicated registry.=C2=A0 I=E2=80=99d like to see some rema= rks about why a registry is called for in this case.=C2=A0 Sorry if it was = there and I missed it.

Speaking as a person who=E2=80=99s been skeptical of J= SON schema efforts, it pains me to say this, but the information about larg= e-scale message structure is scattered through this document in a diffuse w= ay and it=E2=80=99d make me nervous as an implementer whether or not I was = getting it right.=C2=A0 I think it might be helpful to have a =E2=80=9Clarg= e-scale message structure=E2=80=9D section that quickly runs through the al= lowable top-level shapes of messages, and exactly what can be nested inside= what.
Nits

1.1 Section numbers might be n= ice on the 7159 references, e.g. for Object

1.2 first para: =E2=80=9C=E2=80=A6 is conveyed in four= sections=E2=80=9D. Followed by a 5-member list

1.2 =E2=80=9CThe following object classes are served= by=E2=80=A6=E2=80=9D =C2=A0What does it mean for an =E2=80=9Cobject class= =E2=80=9D to be =E2=80=9Cserved=E2=80=9D. Do you mean =E2=80=9Creturned in = response to a request?

2.= 1 =E2=80=9C=E2=80=A6SHOULD ignore unrecognized JSON attributes in responses= =E2=80=9D =C2=A0What=E2=80=99s a JSON attribute?=C2=A0 Do you mean unknown = members in objects?

2.1 = =E2=80=9CThis allowance does not apply to jCard=E2=80=9D.=C2=A0 The word = =E2=80=9Callowance=E2=80=9D puzzles me.=C2=A0 Do you mean the rule about th= e underscores?
=
2.1 =E2=80= =9Cthese limitations have been given to aid some client programming models= =E2=80=9D uh, =E2=80=9Cgiven to aid=E2=80=9D. Do you mean =E2=80=9Cobserved= to aid=E2=80=9D or =E2=80=9Cshown to aid=E2=80=9D or some such?

3. =E2=80=9Cused in this document d= erived from the JSON character string=E2=80=9D.=C2=A0 What does =E2=80=9Cde= rived from=E2=80=9D mean?=C2=A0 Do you mean to say that all the data types = in this section are encoded as JSON strings?

4.1 =E2=80=9CThe first data structure=E2=80=A6=E2=80= =9D =C2=A0First in what sense?=C2=A0 Is it extra important? Must appear fir= st in the JSON instance? (I assume not, that=E2=80=99s a very bad practice)= .

4.9 Object Class Name i= s actually (as with a few other things here) a name/value member of an obje= ct (if I=E2=80=99m reading correctly); why not say so?

5.1 the example.vcard there=E2=80=99s an arra= y containing ["", "", "", ... which looked ki= nd of weird to me.=C2=A0 I=E2=80=99m assuming this will make perfect sense = to someone who knows vcards?







--
- Tim B= ray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray)<= /div>
--001a1134dcfca711a805066bb0e4-- From nobody Mon Oct 27 11:41:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D591A8BC2; Mon, 27 Oct 2014 11:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 drM1qmijrJ2J; Mon, 27 Oct 2014 11:40:35 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 816341A8F33; Mon, 27 Oct 2014 11:37:44 -0700 (PDT) Received: from h118.viagenie.ca (h118.viagenie.ca [206.123.31.118]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9FE9B403C8; Mon, 27 Oct 2014 14:37:43 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Marc Blanchet In-Reply-To: <46A1DF3F04371240B504290A071B4DB63E7789FF@SZXEMA510-MBX.china.huawei.com> Date: Mon, 27 Oct 2014 14:37:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <46A1DF3F04371240B504290A071B4DB63E7789FF@SZXEMA510-MBX.china.huawei.com> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hzxBF9y6IydIH3t7liPM-iBqb7o Cc: draft-ietf-weirds-bootstrap.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-bootstrap-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 18:40:37 -0000 Le 2014-10-21 =C3=A0 04:52, Bert Greevenbosch = a =C3=A9crit : >=20 > Document: draft-ietf-weirds-bootstrap-09 > Title: Finding the Authoritative Registration Data (RDAP) Service > Reviewer: Bert Greevenbosch > Review Date: 21 October 2014 > IETF Last Call Date: 27 October 2014 > IESG Telechat Date: 30 October 2014 > Summary: Needs some edits. >=20 > Major Issues: >=20 > None >=20 > Minor Issues: >=20 > (m1) Section 5.2. The IPv6 address notation "2001:0200:1000::/28" is a = bit strange since 1000 is not part of the first 28 bits. Is this = intentional? If not, I propose to replace it by "2001:0200::/28" or = "2001:0200:100::/38". This replacement would need to be done in the JSON = code as well as in the text. done in -10. using 2001:0200:1000::/36 > Nits: >=20 > (n1) In section 1, second paragraph, replace "Autonomous numbers (AS)" = by "Autonomous Systems (AS) numbers". >=20 > (n2) Section 8, first bullet: propose to remove "a" from "if it is a = mistyped information by the user." done in -10. thanks for the review,=20 Regards, Marc. From nobody Mon Oct 27 15:55:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5670C1A1BA2; Mon, 27 Oct 2014 15:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Gw3FT6p5E2i; Mon, 27 Oct 2014 15:55:07 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF29D1A07BE; Mon, 27 Oct 2014 15:54:50 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id q5so7854110wiv.17 for ; Mon, 27 Oct 2014 15:54:49 -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=XM+mhG+xTKtW+INqmnofNrXYebnJvp6G0RWEfBmjrQU=; b=g53ZfAHlA3niinR4aREVczKsfsenW7ZihIt+tKBa2nENG3/K5LlyxjVQuVJQhTAW4Z y5/2YNXAJ3dTxjQ/+b05ZaDZKzBr4noHZAKsPVJkYhx0H+2kgXgAlpJAuLNXtzv0Qa/B lxO1yf8zGNd00KHbtwvGxxGk69J5yzFGp4+mubm1VsNJr+raZbdzI0znn8EQmmOhNKbB 5BonfTYFQ6hUnigsFie5YC0waOAM88e//klYILdbQo7frdBvMu8o4+63Aki3XxeohMKU 4Ja19XseGBMKZOAnwjoQkzr9eKtjnIuEx1sJWi9RSVnA56uMHBI5PnNlOzH0Sn3onixE nyyg== MIME-Version: 1.0 X-Received: by 10.180.73.40 with SMTP id i8mr23388492wiv.30.1414450489640; Mon, 27 Oct 2014 15:54:49 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Mon, 27 Oct 2014 15:54:49 -0700 (PDT) In-Reply-To: References: Date: Mon, 27 Oct 2014 15:54:49 -0700 Message-ID: From: "Murray S. Kucherawy" To: Tim Bray Content-Type: multipart/alternative; boundary=f46d0438907dfccb8205066f6adb Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-ly0N7veGW5HUuxq9os7ViCMPPE Cc: Hollenbeck Scott , Andy Newton , draft-ietf-weirds-json-response.all@tools.ietf.org, "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Apps Area review of draft-ietf-weirds-json-response-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 22:55:12 -0000 --f46d0438907dfccb8205066f6adb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tim, On Mon, Oct 27, 2014 at 11:27 AM, Tim Bray wrote: > Major issues: > > 10.1 The only security consideration in a protocol definition is the basi= c > JSON stuff? Really? DNS vulnerabilities can be horribly damaging to the > Internet; it=E2=80=99s hard to believe you can just skip over security > considerations. If I were on the IESG I=E2=80=99d be having heartburn. > Are the things you have in mind here specific to RDAP, or are they general DNS considerations applicable to most application layer things? I don't know that we need to call out general vulnerabilities unless we're particularly sensitive to them, but new concerns definitely need to be called out. -MSK --f46d0438907dfccb8205066f6adb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tim,

On Mon, Oct 27, 2014 at 11:27 AM, Tim Bray = <tbray@textuality.com> wrote:
Major issues:<= div dir=3D"ltr">

10.1 The only security consideration in a protocol defini= tion is the basic JSON stuff?=C2=A0 Really?=C2=A0 DNS vulnerabilities can b= e horribly damaging to the Internet; it=E2=80=99s hard to believe you can j= ust skip over security considerations.=C2=A0 If I were on the IESG I=E2=80= =99d be having heartburn.

Are the things you = have in mind here specific to RDAP, or are they general DNS considerations = applicable to most application layer things?=C2=A0 I don't know that we= need to call out general vulnerabilities unless we're particularly sen= sitive to them, but new concerns definitely need to be called out.

-= MSK
--f46d0438907dfccb8205066f6adb-- From nobody Mon Oct 27 16:05:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84291A1B8D for ; Mon, 27 Oct 2014 16:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFh_GwZxnuH9 for ; Mon, 27 Oct 2014 16:05:37 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37581A6EF9 for ; Mon, 27 Oct 2014 16:04:00 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id la4so3073847vcb.27 for ; Mon, 27 Oct 2014 16:03:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=b6Pte/P1rvQpupPBAscutyIhKwTrqH2hLCtkuG9c9Fk=; b=i93Q/wnE4Os085bAnhldTg4SgSjV73iigBYE09pQF5eWIOrx5e/ZqV04VAkAPsFLPN DRUzS3KnQ3flrDX1nVpE59fVfYkYQx6fcKIi0SRW/HpB8N6v5QBsfKYfUh+lPMaOOnO3 tCBk6me8FfuTNJDK8L4hpPWhEj0xfLMVjZvymUhmjgNT/ZwvKTMeeiXD4lGKdKKywgEf 5RijRe3CxToyg/1LotbC9rv5PM+7iyKBFa7bAuIG9wIKAVL+sBbZ0s/af5EjkGm2m6Gh U/ElIwgCjYrQLELZkeys1pvbb4uFgwDsy9vkvKQJl2I0ikkyEb5PspoZ4cArAyOxDuYx mhvQ== X-Gm-Message-State: ALoCoQmkORDhtB4687Gu/BpXs6znuTMbJt6M6LI12EH8f8/iR29BYugUmLrP8jOPmIM7nIfrW0tZ X-Received: by 10.221.46.4 with SMTP id um4mr18568362vcb.23.1414451039857; Mon, 27 Oct 2014 16:03:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.187.3 with HTTP; Mon, 27 Oct 2014 16:03:39 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: From: Tim Bray Date: Mon, 27 Oct 2014 16:03:39 -0700 Message-ID: To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a11337e0ec8849405066f8bc6 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XnMq51uJaA4dfdR60rfL5Acp0bY Cc: Hollenbeck Scott , Andy Newton , draft-ietf-weirds-json-response.all@tools.ietf.org, "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Apps Area review of draft-ietf-weirds-json-response-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 23:05:43 -0000 --001a11337e0ec8849405066f8bc6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I suffer from a lack of expertise in the subject domain, but this payload is going to be used to guide people to what they think are the domains they are looking for. If I were a bad guy I=E2=80=99d think carefully about how= I might mis-use this payload for my own gain. RFC7159 calls out interop pain points in JSON, could any of those serve as attack vectors? Or maybe a callout to the Security Considerations in the appropriate DNS specs might do the job? Also it=E2=80=99s possible that, even in these troubled times, my reflexive= =E2=80=9CWTF DNS with no security considerations?!?!?!=E2=80=9D is overdone. On Mon, Oct 27, 2014 at 3:54 PM, Murray S. Kucherawy wrote: > Hi Tim, > > On Mon, Oct 27, 2014 at 11:27 AM, Tim Bray wrote: > >> Major issues: >> >> 10.1 The only security consideration in a protocol definition is the >> basic JSON stuff? Really? DNS vulnerabilities can be horribly damaging= to >> the Internet; it=E2=80=99s hard to believe you can just skip over securi= ty >> considerations. If I were on the IESG I=E2=80=99d be having heartburn. >> > > Are the things you have in mind here specific to RDAP, or are they genera= l > DNS considerations applicable to most application layer things? I don't > know that we need to call out general vulnerabilities unless we're > particularly sensitive to them, but new concerns definitely need to be > called out. > > -MSK > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11337e0ec8849405066f8bc6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I s= uffer from a lack of expertise in the subject domain, but this payload is g= oing to be used to guide people to what they think are the domains they are= looking for.=C2=A0 If I were a bad guy I=E2=80=99d think carefully about h= ow I might mis-use this payload for my own gain.=C2=A0 RFC7159 calls out in= terop pain points in JSON, could any of those serve as attack vectors? Or m= aybe a callout to the Security Considerations in the appropriate DNS specs = might do the job? =C2=A0

= Also it=E2=80=99s possible that, even in these troubled times, my reflexive= =E2=80=9CWTF DNS with no security considerations?!?!?!=E2=80=9D is overdon= e.

On = Mon, Oct 27, 2014 at 3:54 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
Hi = Tim,

On Mon, Oct 27, 2014 at 11:27 AM, Tim Bray <tbray@textuality.com> wrote:
=
Major issues:

10.1 The only security consideration in a protocol definitio= n is the basic JSON stuff?=C2=A0 Really?=C2=A0 DNS vulnerabilities can be h= orribly damaging to the Internet; it=E2=80=99s hard to believe you can just= skip over security considerations.=C2=A0 If I were on the IESG I=E2=80=99d= be having heartburn.

Are the thin= gs you have in mind here specific to RDAP, or are they general DNS consider= ations applicable to most application layer things?=C2=A0 I don't know = that we need to call out general vulnerabilities unless we're particula= rly sensitive to them, but new concerns definitely need to be called out.

-MSK
=



--
- Tim Bray (If you=E2=80=99d like to send me a private message, s= ee https://keybase= .io/timbray)
--001a11337e0ec8849405066f8bc6-- From nobody Mon Oct 27 17:54:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C711A6EE7 for ; Mon, 27 Oct 2014 17:54:16 -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 E1qfrh4pCdja for ; Mon, 27 Oct 2014 17:54:14 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B2221A1B3F for ; Mon, 27 Oct 2014 17:54:14 -0700 (PDT) Received: from [127.0.0.1] (unknown [69.163.240.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1FA28509B5; Mon, 27 Oct 2014 20:54:12 -0400 (EDT) From: Sean Leonard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Oct 2014 17:54:13 -0700 References: <20141027144500.20867.37118.idtracker@ietfa.amsl.com> To: media-types@iana.org, IETF Apps Discuss Message-Id: <21F21E2A-E192-4F23-8531-8C9BC06B6469@seantek.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6jUTEKKUYSDOSpufhbjhJxa42OY Subject: [apps-discuss] New Version Notification for draft-seantek-text-nfo-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, 28 Oct 2014 00:54:16 -0000 media-types and apps-discuss Colleagues: An Internet-Draft to register text/nfo has been posted. text/x-nfo is = currently in use. NFO refers to Relase iNFOrmation.=20 Feedback welcome. Regards, Sean Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-seantek-text-nfo-00.txt > Date: October 27, 2014 at 7:45:00 AM PDT A new version of I-D, draft-seantek-text-nfo-00.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-seantek-text-nfo Revision: 00 Title: The text/nfo Media Type Document date: 2014-10-24 Group: Individual Submission Pages: 11 URL: = http://www.ietf.org/internet-drafts/draft-seantek-text-nfo-00.txt Status: https://datatracker.ietf.org/doc/draft-seantek-text-nfo/ Htmlized: http://tools.ietf.org/html/draft-seantek-text-nfo-00 Abstract: This document registers the text/nfo media type for use with release iNFOrmation. While mostly compatible with text/plain, ".NFO" files and content have unique encoding and rendering characteristics that make them distinguishable from typical plain text. The IETF Secretariat ************ 2. Release iNFOrmation Media Type Registration Application Type name: text Subtype name: nfo Required parameters: charset: Per Section 4.2.1 of [RFC6838], charset is REQUIRED. Unlike most other text types, the default value is the character set of the original IBM PC and MS-DOS, called OEM Code Page 437. For purposes of this Internet-Draft, the parameter value is "~oem437". [[TODO: figure this out.]] Implementations MUST support OEM Code Page 437. Unfortunately, the simple application of the IANA registered character set "IBM437" (aka "cp437") [RFC1345] will miss some important characters, so conformant implementations MUST support OEM Code Page 437 as specified in Section 3. NFOs authored for more modern computing environments are known to use ISO-8859-1, ISO-8859-15 (including support for the Euro sign), or UTF-8; however, for maximum interoperability, these or any other character sets MUST be declared by the sender. When absent, a receiver MAY guess, but SHOULD heavily bias the outcome towards OEM Code Page 437 unless UTF-8 encoding is patently obvious. A RECOMMENDED detection algorithm is provided in Appendix A. Optional parameters: baud: A natural number (integer greater than 0) indicating the gross bit rate at which the NFO is supposed to be rendered to screen. This optional parameter provides a nostalgic effect from the days of modems and fixed-speed serial lines. It also controls the animation rate, to the extent that the NFO employs optional escape sequences. Encoding considerations: Text with 8-bit code points; all 8-bit combinations (including perhaps NUL) are possible. Accordingly, text SHOULD be quoted- printable or base64 encoded when transmitted over a channel that is not 8-bit clean. Security considerations: None; it's just text. The ANSI escape sequence "CSI 5 m" could, however, blink you to death. Interoperability considerations: NFOs are plain text but look best when read in a terminal view or with a dedicated NFO viewer that can emulate terminal features. As a result, they SHOULD be treated differently than text/plain files. The reference implementation that all NFO viewers SHOULD target is an IBM PC-compatible machine running MS-DOS 6.22 with the ANSI.SYS MS-DOS device driver loaded, where the NFO is displayed as if it were output to the terminal using the "TYPE" command. Published specification: This specification. Applications that use this media type: NFO viewers; text editors; terminals. Fragment identifier considerations: Same as text/plain [RFC5147]. Note that escape sequences do not contribute to the character count [[NB: do they?]], and line breaks are treated as one character, regardless of whether CRLF or some other code(s) are used. Additional information: Deprecated alias names for this type: text/x-nfo File extension(s): .nfo Macintosh file type code(s): TEXT. A uniform type identifier (UTI) of "????", which conforms to "public.plain-text", is RECOMMENDED. Person & email address to contact for further information: Sean Leonard Restrictions on usage: None. Author/Change controller: Sean Leonard Intended usage: COMMON Provisional registration? No From nobody Tue Oct 28 02:12:12 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA84B1A1ABA for ; Tue, 28 Oct 2014 02:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hv0YiArhchhJ for ; Tue, 28 Oct 2014 02:11:30 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 269C31A1ABB for ; Tue, 28 Oct 2014 02:11:27 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5EFCBFA007D; Tue, 28 Oct 2014 09:11:25 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1414487484-4330-4329/12/56; Tue, 28 Oct 2014 09:11:24 +0000 From: Arnt Gulbrandsen To: media-types@iana.org, IETF Apps Discuss , Sean Leonard Message-Id: <914810f6405179cc42066aaec240bc9bcee5b37ebc1cb173be7d84f27b999e0f.sha-256@android.antelope.email> References: <20141027144500.20867.37118.idtracker@ietfa.amsl.com> <21F21E2A-E192-4F23-8531-8C9BC06B6469@seantek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Date: Tue, 28 Oct 2014 09:11:24 +0000 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/IUMsU7OUMytJgWkXuWbYWO7b3yo Subject: [apps-discuss] New Version Notification for draft-seantek-text-nfo-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, 28 Oct 2014 09:11:32 -0000 Surely this should be called text/dos-ascii-art, and could you please = finish the markdown debacle before starting a new draft? Arnt From nobody Tue Oct 28 10:08:36 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A132D1A7022; Mon, 27 Oct 2014 10:27:44 -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 dXMUQ73dThU9; Mon, 27 Oct 2014 10:27:39 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A923C1A0187; Mon, 27 Oct 2014 10:27:39 -0700 (PDT) Received: by mail-oi0-f45.google.com with SMTP id i138so3718161oig.18 for ; Mon, 27 Oct 2014 10:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :cc:to; bh=RReos6z0I8xPLx1dmdXMk0RX83UWBkENC+21PrRsdcg=; b=LHbf2jih8UqIUiwlgrLIbnAUil8EPUs5qPK86XBYMUEPrvWey2w30GqNYJ/SYOWG1P 13NEYuflUdqCi7w4BBIEyjPKexYYWQUMjIUAHwQwiK9cH1byZJsIqp1DHFBGAboJ9cyE OAHECbOkwqlook8dVs+HgQ7YjgccKiBIqmnRi3DFEXtoE6lWY8Wv3M0tH1FRSl6b+Hx5 0sGI/7DtijdA19drwUwmhx3EFqKWABrsGbB9oQnwrwxwgGJQhEnXLEO7HTbago0M2Djt 9y1hjEu7D+/LxspMKm8uN2WtF8hKlzDKS3mLjvVLaD+3djRqJE215AQVXuJx1RwXJBOt OtxA== X-Received: by 10.60.57.41 with SMTP id f9mr21390758oeq.17.1414430859054; Mon, 27 Oct 2014 10:27:39 -0700 (PDT) Received: from [10.0.0.6] (99-64-100-240.lightspeed.austtx.sbcglobal.net. [99.64.100.240]) by mx.google.com with ESMTPSA id n2sm5160219oel.17.2014.10.27.10.27.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 10:27:35 -0700 (PDT) From: "Adam W. Montville" Content-Type: multipart/alternative; boundary="Apple-Mail=_0EF69CDE-AA60-4B7B-A821-CFFE915379ED" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Date: Mon, 27 Oct 2014 12:27:34 -0500 References: <20141027172040.22908.7076.idtracker@ietfa.amsl.com> To: MILE IETF X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/r8DirCMV4eCHB12GTRvZbrDhgi0 X-Mailman-Approved-At: Tue, 28 Oct 2014 10:08:34 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Fwd: New Version Notification for draft-ietf-mile-enum-reference-format-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: Mon, 27 Oct 2014 17:27:44 -0000 --Apple-Mail=_0EF69CDE-AA60-4B7B-A821-CFFE915379ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All: I=E2=80=99ve made two minor updates to the enumeration reference draft = (link in the forwarded message below). Both changes are found in the = IANA Considerations section. The first change makes it explicit that = all fields are mandatory, including abbreviation. The second change = further clarifies that the =E2=80=9Cversion=E2=80=9D field is the = version of the referenced specification. There was a third issue raised by an early appsdir review. The appsdir = review included: =E2=80=9Cthe lack of any specified mapping from the (to = my mind) unnecessary level of indirection from integers via registry = entries to URIs which would actually give _access_ to such entries is = irritating at least. Can=E2=80=99t we at least _ask_ that IANA provide = such a mapping along the lines of = http://www.iana.org/assignments/enumeration-reference-type/abbrev_version = ?=E2=80=9D An example was provided in response, and we heard no further reply. = David and I believe that the URI described above would look something = like this for version 2.5 of the =E2=80=9CCXI=E2=80=9D specification: = http://www.iana.org/assignments/enumeration-reference-type/CXI_2.5 = . Regards, Adam > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > To: "David L. Black" , "Adam W. Montville" = , Adam W. Montville = , David Black > Subject: New Version Notification for = draft-ietf-mile-enum-reference-format-09.txt > Date: October 27, 2014 at 12:20:40 PM CDT >=20 >=20 > A new version of I-D, draft-ietf-mile-enum-reference-format-09.txt > has been successfully submitted by Adam W. Montville and posted to the > IETF repository. >=20 > Name: draft-ietf-mile-enum-reference-format > Revision: 09 > Title: IODEF Enumeration Reference Format > Document date: 2014-10-27 > Group: mile > Pages: 10 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-mile-enum-reference-format-= 09.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-mile-enum-reference-format/ > Htmlized: = http://tools.ietf.org/html/draft-ietf-mile-enum-reference-format-09 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-enum-reference-format-0= 9 >=20 > Abstract: > The Incident Object Description Exchange Format (IODEF) is an XML > data representation framework for sharing information about computer > security incidents. In IODEF, the Reference class provides > references to externally specified information such as a > vulnerability, IDS alert, malware sample, advisory, or attack > technique. In practice, these references are based on external > enumeration specifications that define both the enumeration format > and the specific enumeration values, but the IODEF Reference class > (as specified in RFC 5070) does not indicate how to include both of > these important pieces of information. >=20 > This memo provides an extension to RFC 5070 to include both the > external specification and specific enumeration value in the IODEF > Reference class. This memo also establishes an IANA registry to > manage external enumeration specifications for use by IODEF. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_0EF69CDE-AA60-4B7B-A821-CFFE915379ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 All:

I=E2=80= =99ve made two minor updates to the enumeration reference draft (link in = the forwarded message below).  Both changes are found in the IANA = Considerations section.  The first change makes it explicit that = all fields are mandatory, including abbreviation.  The second = change further clarifies that the =E2=80=9Cversion=E2=80=9D field is the = version of the referenced specification.

There was a third issue raised by an = early appsdir review.  The appsdir review included: =E2=80=9Cthe = lack of any specified mapping from the (to my mind) unnecessary level of = indirection from integers via registry entries to URIs which would = actually give _access_ to such entries is irritating at least. =  Can=E2=80=99t we at least _ask_ that IANA provide such a mapping = along the lines of http://www.iana.org/assignments/enumeration-reference-type/abbr= ev_version ?=E2=80=9D

An example was provided in response, = and we heard no further reply.  David and I believe that the URI = described above would look something like this for version 2.5 of the = =E2=80=9CCXI=E2=80=9D specification: http://www.iana.org/assignments/enumeration-reference-type/CXI_= 2.5.

Regards,

Adam

Begin forwarded = message:

From: = internet-drafts@ietf.org
To: "David L. Black" <david.black@emc.com>, "Adam W. Montville" <adam.w.montville@gmail.com>, Adam W. Montville <adam.w.montville@gmail.com>, David Black <david.black@emc.com>
Subject: = New Version = Notification for draft-ietf-mile-enum-reference-format-09.txt
Date: = October 27, 2014 at 12:20:40 PM = CDT


A new version of I-D, = draft-ietf-mile-enum-reference-format-09.txt
has been = successfully submitted by Adam W. Montville and posted to the
IETF repository.

Name: = draft-ietf-mile-enum-reference-format
Revision: 09
Title:= = IODEF Enumeration Reference Format
Document = date: = 2014-10-27
Group: mile
Pages: 10
URL: =            http://www.ietf.org/internet-drafts/draft-ietf-mile-enum-refere= nce-format-09.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-mile-enum-reference= -format/
Htmlized: =       http://tools.ietf.org/html/draft-ietf-mile-enum-reference-forma= t-09
Diff: =           http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-enum-referen= ce-format-09

Abstract:
=   The Incident Object Description Exchange Format (IODEF) is = an XML
  data representation framework for = sharing information about computer
  security = incidents.  In IODEF, the Reference class provides
=   references to externally specified information such as a
  vulnerability, IDS alert, malware sample, = advisory, or attack
  technique.  In = practice, these references are based on external
=   enumeration specifications that define both the enumeration = format
  and the specific enumeration values, = but the IODEF Reference class
  (as specified = in RFC 5070) does not indicate how to include both of
=   these important pieces of information.

  This memo provides an extension to RFC 5070 to = include both the
  external specification and = specific enumeration value in the IODEF
=   Reference class.  This memo also establishes an IANA = registry to
  manage external enumeration = specifications for use by IODEF.





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

The IETF Secretariat


= --Apple-Mail=_0EF69CDE-AA60-4B7B-A821-CFFE915379ED-- From nobody Wed Oct 29 18:14:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831C71ACE86 for ; Wed, 29 Oct 2014 18:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llQdYLiMJC_d for ; Wed, 29 Oct 2014 18:14:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C18C1ACE7E for ; Wed, 29 Oct 2014 18:14:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOE87061; Thu, 30 Oct 2014 01:14:10 +0000 (GMT) Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 30 Oct 2014 01:14:09 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Thu, 30 Oct 2014 09:14:03 +0800 From: Bert Greevenbosch To: Sean Leonard , "draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org" Thread-Topic: [apps-discuss] Upload of CDDL draft v03: draft-greevenbosch-appsawg-cbor-cddl-03 Thread-Index: AQHP67aicSvUh3UZA0mhG+1qfTeG5pxH3sbw Date: Thu, 30 Oct 2014 01:14:03 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63E7A86E8@SZXEMA510-MBX.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB63E74D7B8@SZXEMA510-MBX.china.huawei.com> <5443E124.8050903@seantek.com> In-Reply-To: <5443E124.8050903@seantek.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.174.121] Content-Type: multipart/alternative; boundary="_000_46A1DF3F04371240B504290A071B4DB63E7A86E8SZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/oFmIMVub2lOixhdJ8pBAAnsfnbo Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Upload of CDDL draft v03: draft-greevenbosch-appsawg-cbor-cddl-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 01:14:15 -0000 --_000_46A1DF3F04371240B504290A071B4DB63E7A86E8SZXEMA510MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2VhbiwNCg0KVGhhbmtzIGZvciByZXZpZXdpbmcgdGhlIGRyYWZ0IGFuZCBzZW5kaW5nIHlv dXIgZmVlZGJhY2suDQoNCkluZGVlZCB0aGVyZSBpcyBhIGRpZmZlcmVuY2UgYmV0d2VlbiB1c2Fn ZSBvZiB0cmFkaXRpb25hbCBvciBzaW1wbGlmaWVkIGNoYXJhY3RlcnMgYmV0d2VlbiBkaWZmZXJl bnQgcmVnaW9ucy4gSSBwZXJzb25hbGx5IHVzZSB0aGUgc2ltcGxpZmllZCBmb3JtLCBzbyB0aGF0 J3Mgd2h5IEkgY2hvc2UgdGhhdCByZXByZXNlbnRhdGlvbi4NCg0KSSBkb24ndCBrbm93IGlmIGl0 IGlzIGEgYmlnIGlzc3VlIGZvciB0aGUgZHJhZnQgLSBpdCBpcyBqdXN0IGFuIGV4YW1wbGUgZW5j b2RpbmcgYW5kIHRoZSBleGFtcGxlIGZvcm1hdCBkb2Vzbid0IGNsYWltIGNvbXBsaWFuY2UgdG8g YW55IHN0YW5kYXJkcyBleGNlcHQgZm9yIENCT1IgLSBidXQgb2YgY291cnNlIHdlIGNhbiBjaGFu Z2UgdGhlIGxhbmd1YWdlIGNvZGUgdG8gIlpILUhBTlMiLCBpbiBhY2NvcmRhbmNlIHdpdGggUkZD IDU2NDYuDQoNCkJlc3QgcmVnYXJkcywNCkJlcnQNCg0KRnJvbTogU2VhbiBMZW9uYXJkIFttYWls dG86ZGV2K2lldGZAc2VhbnRlay5jb21dDQpTZW50OiAyMCBPY3RvYmVyIDIwMTQgMDA6MDUNClRv OiBkcmFmdC1ncmVldmVuYm9zY2gtYXBwc2F3Zy1jYm9yLWNkZGxAdG9vbHMuaWV0Zi5vcmcNCkNj OiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBVcGxv YWQgb2YgQ0RETCBkcmFmdCB2MDM6IGRyYWZ0LWdyZWV2ZW5ib3NjaC1hcHBzYXdnLWNib3ItY2Rk bC0wMw0KDQpIaSBCZXJ0IGFuZCBDaHJpc3RvcGggKGV0LiBhbC4pLA0KDQpOaXQ6DQpJbiB0aGUg SW50ZXJuYXRpb25hbCBtYXAgKFNlY3Rpb24gNi4yLCBQYWdlcyAxNy0xOSksICJDTiIgaXMgaW5j b3JyZWN0Lg0KDQpDTiBpcyB0aGUgZ2VvZ3JhcGhpYyBjb2RlIGZvciBDaGluYS4NCg0KemggaXMg dGhlIGxhbmd1YWdlIGNvZGUgKHN1YnRhZykgZm9yIENoaW5lc2UuIEl0IGlzIGEgbWFjcm9sYW5n dWFnZSB0YWcuDQoNClRoZXJlIGFyZSBhY3R1YWxseSB0d28gZGlmZmVyZW50IHdyaXRpbmdzIGZv ciBBcHBsZToNCuiLueaenA0K6JiL5p6cDQoNClRoZSBmb3JtZXIgKHdoaWNoIGlzIHRoZSBlbmNv ZGVkIGl0ZW0gaW4gU2VjdGlvbiA2LjIpIGlzIHNpbXBsaWZpZWQgQ2hpbmVzZSwgInpoLUhhbnMi LiBUaGUgbGF0dGVyIGlzIHRyYWRpdGlvbmFsIENoaW5lc2UsICJ6aC1IYW50Ii4NCg0KVGhlIFdp a2lwZWRpYSBhcnRpY2xlIG9uIENoaW5lc2UgV2lraXBlZGlhPGh0dHA6Ly9lbi53aWtpcGVkaWEu b3JnL3dpa2kvQ2hpbmVzZV9XaWtpcGVkaWEjQXV0b21hdGljX2NvbnZlcnNpb25fYmV0d2Vlbl90 cmFkaXRpb25hbF9hbmRfc2ltcGxpZmllZF9DaGluZXNlX2NoYXJhY3RlcnM+IGlsbHVzdHJhdGVz IHNvbWUgb2YgdGhlIHByYWN0aWNhbCBwcm9ibGVtcyB3aXRoIHVuaWZ5aW5nIENoaW5lc2UgdW5k ZXIgY2VydGFpbiBsYW5ndWFnZSB0YWdzLg0KDQpJdCBwcm9iYWJseSB3YXMgbm90IHlvdXIgaW50 ZW50IHRvIHdhZGUgaW50byBsaW5ndWlzdGljIHRlY2huby1nZW8tcG9saXRpY2FsIGlzc3Vlcy4u LnBlcmhhcHMgZm9yIHRoZSBkcmFmdCwgaXQgd291bGQgYmUgYmVzdCB0byBwaWNrIGFub3RoZXIg bGFuZ3VhZ2UsIGxpa2UgS29yZWFuLg0KDQpDaGVlcnMsDQoNClNlYW4NCg0KT24gOS8xNS8yMDE0 IDExOjI2IFBNLCBCZXJ0IEdyZWV2ZW5ib3NjaCB3cm90ZToNCkhlbGxvIGFsbCwNCg0KV2UgaGF2 ZSB1cGRhdGVkIHRoZSBDQk9SIERhdGEgRGVzY3JpcHRpb24gIExhbmd1YWdlIChDRERMKSBkcmFm dC4gSXQgaXMgYXZhaWxhYmxlIHVuZGVyIHRoZSBmb2xsb3dpbmcgbGluazoNCg0KaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ3JlZXZlbmJvc2NoLWFwcHNhd2ctY2Jvci1j ZGRsDQoNClRoZSBjaGFuZ2VzIHNpbmNlIHYwMiBhcmUgYXMgZm9sbG93czoNCg0KDQrCtyAgICAg ICAgIEFkZGVkIGluZm9ybWF0aW9uIGFib3V0IGNoYXJhY3RlcnMgdXNlZCBpbiBuYW1lcw0KDQrC tyAgICAgICAgIEFkZGVkIHRleHQgYWJvdXQgYW4gb3ZlcmFsbCBkYXRhIHN0cnVjdHVyZSBhbmQg dGhlIG9yZGVyIG9mIHRoZSBkZWZpbml0aW9ucyBvZiB0aGUgZmllbGRzDQoNCsK3ICAgICAgICAg QWRkZWQgdGV4dCBhYm91dCBlbmNvZGluZyBvZiBrZXlzDQoNCsK3ICAgICAgICAgQWRkZWQgdGFi bGUgd2l0aCBrZXl3b3Jkcw0KDQrCtyAgICAgICAgIEFkZGVkIHN0cmluZ3MgYW5kIGludGVnZXIg d3JpdGluZyBjb252ZW50aW9ucw0KDQrCtyAgICAgICAgIEFkZGVkIGFuIEFCTkYgZGVzY3JpcHRp b24gb2YgQ0RETA0KDQpDaHJpc3RvcGggVmlnYW5vIGlzIG5vdyBjby1hdXRob3IuIEhlIG1hZGUg c2V2ZXJhbCBjaGFuZ2VzL3NpbXBsaWZpY2F0aW9ucyBiYXNlZCBvbiBoaXMgaW1wbGVtZW50YXRp b24gZXhwZXJpZW5jZS4NCg0KV2UgbG9vayBmb3J3YXJkIHRvIHlvdXIgcXVlc3Rpb25zIGFuZCBy ZW1hcmtzIQ0KDQpCZXN0IHJlZ2FyZHMsDQpCZXJ0DQoNCg0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KYXBwcy1kaXNjdXNzIG1haWxpbmcg bGlzdA0KDQphcHBzLWRpc2N1c3NAaWV0Zi5vcmc8bWFpbHRvOmFwcHMtZGlzY3Vzc0BpZXRmLm9y Zz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MN Cg0K --_000_46A1DF3F04371240B504290A071B4DB63E7A86E8SZXEMA510MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 QmF0YW5nOw0KCXBhbm9zZS0xOjIgMyA2IDAgMCAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMg NSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9z ZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFo b21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAx IDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBCYXRhbmciOw0KCXBhbm9z ZS0xOjIgMyA2IDAgMCAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29Q bGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFp biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0K cHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJs YWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xp c3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0K CW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYu MHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1M UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5Q bGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1m YW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93 dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6MTE1OTM1MDg3MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTcwNTY3MzQwMiA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC10YWItc3RvcDo3Mi4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1z dG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDozMjQu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNt O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkhpIFNlYW4sPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5UaGFua3MgZm9yIHJldmll d2luZyB0aGUgZHJhZnQgYW5kIHNlbmRpbmcgeW91ciBmZWVkYmFjay48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkluZGVlZCB0aGVyZSBpcyBhIGRpZmZlcmVuY2Ug YmV0d2VlbiB1c2FnZSBvZiB0cmFkaXRpb25hbCBvciBzaW1wbGlmaWVkIGNoYXJhY3RlcnMgYmV0 d2VlbiBkaWZmZXJlbnQgcmVnaW9ucy4gSSBwZXJzb25hbGx5IHVzZSB0aGUgc2ltcGxpZmllZCBm b3JtLCBzbyB0aGF0J3Mgd2h5IEkgY2hvc2UgdGhhdCByZXByZXNlbnRhdGlvbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkkgZG9uJ3Qga25vdyBpZiBpdCBpcyBh IGJpZyBpc3N1ZSBmb3IgdGhlIGRyYWZ0IC0gaXQgaXMganVzdCBhbiBleGFtcGxlIGVuY29kaW5n IGFuZCB0aGUgZXhhbXBsZSBmb3JtYXQgZG9lc24ndCBjbGFpbSBjb21wbGlhbmNlIHRvIGFueSBz dGFuZGFyZHMgZXhjZXB0IGZvciBDQk9SIC0gYnV0IG9mIGNvdXJzZSB3ZSBjYW4gY2hhbmdlIHRo ZSBsYW5ndWFnZQ0KIGNvZGUgdG8gJnF1b3Q7WkgtSEFOUyZxdW90OywgaW4gYWNjb3JkYW5jZSB3 aXRoIFJGQyA1NjQ2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtCYXRhbmcmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkJlc3QgcmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dCI+QmVydDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2lu ZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OndpbmRvd3RleHQiPiBTZWFuIExlb25hcmQgW21haWx0bzpkZXYmIzQzO2lldGZAc2VhbnRlay5j b21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjAgT2N0b2JlciAyMDE0IDAwOjA1PGJyPg0KPGI+VG86 PC9iPiBkcmFmdC1ncmVldmVuYm9zY2gtYXBwc2F3Zy1jYm9yLWNkZGxAdG9vbHMuaWV0Zi5vcmc8 YnI+DQo8Yj5DYzo8L2I+IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW2FwcHMtZGlzY3Vzc10gVXBsb2FkIG9mIENEREwgZHJhZnQgdjAzOiBkcmFmdC1ncmVl dmVuYm9zY2gtYXBwc2F3Zy1jYm9yLWNkZGwtMDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQmVydCBhbmQgQ2hyaXN0b3BoIChldC4gYWwu KSw8YnI+DQo8YnI+DQpOaXQ6PGJyPg0KSW4gdGhlIEludGVybmF0aW9uYWwgbWFwIChTZWN0aW9u IDYuMiwgUGFnZXMgMTctMTkpLCAmcXVvdDtDTiZxdW90OyBpcyBpbmNvcnJlY3QuPGJyPg0KPGJy Pg0KQ04gaXMgdGhlIGdlb2dyYXBoaWMgY29kZSBmb3IgQ2hpbmEuPGJyPg0KPGJyPg0KemggaXMg dGhlIGxhbmd1YWdlIGNvZGUgKHN1YnRhZykgZm9yIENoaW5lc2UuIEl0IGlzIGEgbWFjcm9sYW5n dWFnZSB0YWcuPGJyPg0KPGJyPg0KVGhlcmUgYXJlIGFjdHVhbGx5IHR3byBkaWZmZXJlbnQgd3Jp dGluZ3MgZm9yIEFwcGxlOjxicj4NCjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1p bHk65a6L5L2TIj7oi7nmnpw8L3NwYW4+PGJyPg0KPHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJm b250LWZhbWlseTrlrovkvZMiPuiYi+aenDwvc3Bhbj48YnI+DQo8YnI+DQpUaGUgZm9ybWVyICh3 aGljaCBpcyB0aGUgZW5jb2RlZCBpdGVtIGluIFNlY3Rpb24gNi4yKSBpcyBzaW1wbGlmaWVkIENo aW5lc2UsICZxdW90O3poLUhhbnMmcXVvdDsuIFRoZSBsYXR0ZXIgaXMgdHJhZGl0aW9uYWwgQ2hp bmVzZSwgJnF1b3Q7emgtSGFudCZxdW90Oy48YnI+DQo8YnI+DQpUaGUgV2lraXBlZGlhIGFydGlj bGUgb24gPGEgaHJlZj0iaHR0cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9DaGluZXNlX1dpa2lw ZWRpYSNBdXRvbWF0aWNfY29udmVyc2lvbl9iZXR3ZWVuX3RyYWRpdGlvbmFsX2FuZF9zaW1wbGlm aWVkX0NoaW5lc2VfY2hhcmFjdGVycyI+DQpDaGluZXNlIFdpa2lwZWRpYTwvYT4gaWxsdXN0cmF0 ZXMgc29tZSBvZiB0aGUgcHJhY3RpY2FsIHByb2JsZW1zIHdpdGggdW5pZnlpbmcgQ2hpbmVzZSB1 bmRlciBjZXJ0YWluIGxhbmd1YWdlIHRhZ3MuPGJyPg0KPGJyPg0KSXQgcHJvYmFibHkgd2FzIG5v dCB5b3VyIGludGVudCB0byB3YWRlIGludG8gbGluZ3Vpc3RpYyB0ZWNobm8tZ2VvLXBvbGl0aWNh bCBpc3N1ZXMuLi5wZXJoYXBzIGZvciB0aGUgZHJhZnQsIGl0IHdvdWxkIGJlIGJlc3QgdG8gcGlj ayBhbm90aGVyIGxhbmd1YWdlLCBsaWtlIEtvcmVhbi48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0K PGJyPg0KU2Vhbjxicj4NCjxicj4NCk9uIDkvMTUvMjAxNCAxMToyNiBQTSwgQmVydCBHcmVldmVu Ym9zY2ggd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGVsbG8gYWxsLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBoYXZlIHVwZGF0ZWQgdGhl IENCT1IgRGF0YSBEZXNjcmlwdGlvbiZuYnNwOyBMYW5ndWFnZSAoQ0RETCkgZHJhZnQuIEl0IGlz IGF2YWlsYWJsZSB1bmRlciB0aGUgZm9sbG93aW5nIGxpbms6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWdyZWV2 ZW5ib3NjaC1hcHBzYXdnLWNib3ItY2RkbCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtZ3JlZXZlbmJvc2NoLWFwcHNhd2ctY2Jvci1jZGRsPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgY2hhbmdlcyBzaW5jZSB2MDIgYXJlIGFzIGZvbGxvd3M6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlz dDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPkFkZGVkIGluZm9ybWF0aW9uIGFib3V0IGNoYXJhY3RlcnMgdXNlZCBpbiBuYW1l czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QWRkZWQgdGV4dCBhYm91dCBhbiBvdmVy YWxsIGRhdGEgc3RydWN0dXJlIGFuZCB0aGUgb3JkZXIgb2YgdGhlIGRlZmluaXRpb25zIG9mIHRo ZSBmaWVsZHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkFkZGVkIHRleHQgYWJvdXQg ZW5jb2Rpbmcgb2Yga2V5czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QWRkZWQgdGFi bGUgd2l0aCBrZXl3b3JkczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QWRkZWQgc3Ry aW5ncyBhbmQgaW50ZWdlciB3cml0aW5nIGNvbnZlbnRpb25zPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT5BZGRlZCBhbiBBQk5GIGRlc2NyaXB0aW9uIG9mIENEREw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Q2hyaXN0b3BoIFZpZ2FubyBpcyBub3cgY28tYXV0aG9yLiBIZSBtYWRlIHNl dmVyYWwgY2hhbmdlcy9zaW1wbGlmaWNhdGlvbnMgYmFzZWQgb24gaGlzIGltcGxlbWVudGF0aW9u IGV4cGVyaWVuY2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGxvb2sgZm9yd2FyZCB0byB5 b3VyIHF1ZXN0aW9ucyBhbmQgcmVtYXJrcyE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCBy ZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVydDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hcHBz LWRpc2N1c3MgbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFp bHRvOmFwcHMtZGlzY3Vzc0BpZXRmLm9yZyI+YXBwcy1kaXNjdXNzQGlldGYub3JnPC9hPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYXBwcy1kaXNjdXNzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2FwcHMtZGlzY3VzczwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_46A1DF3F04371240B504290A071B4DB63E7A86E8SZXEMA510MBXchi_-- From nobody Wed Oct 29 18:32:41 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606761ACF14 for ; Wed, 29 Oct 2014 18:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fG53FT3Q85bt for ; Wed, 29 Oct 2014 18:32:37 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C921ACF1A for ; Wed, 29 Oct 2014 18:32:30 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id x12so2971572qac.7 for ; Wed, 29 Oct 2014 18:32:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=azqVZfiOO5LeUzTLqo7r00vP4AD30yEXWQNFbiGBP1Y=; b=NAEeAlKY3+wQyd4xLcu27/0JzFt+F3SNZ33Dekn1ZzkNbzQhC0MyhQP4l1x+HF7Nec bYKM9+/JnB8sDJ0Fp7LStMnNobgZ4PJcG6m4iwJEJqM3kuM6quibqp50cw352ABJwptW oyV6CvIMx/Kil2dE0W1EnMgOsSzse2OWHudhzMRXHZnIgHpaGpK/ux0wVA5iRa2f+9in kxo+qPTMyZHdUT9mdc9uDjvof32FaNIksJmKP0ynu+ncc++ki1W1tz6Vst3aUbjvBnbn QUfMsZyggypcQlk6ys3hNFREEgrDHaNn0qvKUzDoLpLVKHrZylOBCFdmmaxoO/v4rjOz 5z6A== X-Gm-Message-State: ALoCoQlvvV587CxItfZzrBPYL4MBnO1PNbc9bOPYs8z8R9X1gEq8xcpXbDC2ErHhZaYY2MYJ+Qrr X-Received: by 10.140.102.169 with SMTP id w38mr20367327qge.95.1414632749955; Wed, 29 Oct 2014 18:32:29 -0700 (PDT) Received: from minime.private ([76.73.248.16]) by mx.google.com with ESMTPSA id w8sm5651720qag.2.2014.10.29.18.32.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 18:32:29 -0700 (PDT) From: "Fletcher T. Penney" Content-Type: multipart/signed; boundary="Apple-Mail=_18AAB516-94A9-460B-BBCB-602D92C16F2C"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <18726A9B-D2C4-47E7-A564-5D15E3631F32@fletcherpenney.net> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Wed, 29 Oct 2014 21:32:27 -0400 References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <01PDWHBG1ZY200005L@mauve.mrochek.com> <544C81B2.6090409@seantek.com> <544D408B.3090404@fletcherpenney.net> <01PE7F4UX0780028JO@mauve.mrochek.com> <94B993C2-29D2-4AE6-9B7B-32417F7E1B9D@seantek.com> <544E34EA.3090406@ninebynine.org> To: IETF Apps Discuss In-Reply-To: <544E34EA.3090406@ninebynine.org> X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3JCeKlEhNNuSlzuRI2FNH87ajaQ Subject: [apps-discuss] text/markdown discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 01:32:39 -0000 --Apple-Mail=_18AAB516-94A9-460B-BBCB-602D92C16F2C Content-Type: multipart/alternative; boundary="Apple-Mail=_6E8D3BCA-1711-4B4F-A5BF-156A70215542" --Apple-Mail=_6E8D3BCA-1711-4B4F-A5BF-156A70215542 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 FYI, This project has grown to consume more of my time and energy than I = have to spare. I am increasingly convinced that the end result is = unlikely to be substantively different than the initial proposal. I've = explained my concerns about how I fear that certain aspects of this = proposal could potentially harm the Markdown community by increasing = confusion amongst users about what is or is not Markdown. Hopefully = that will not come to pass. I will unsubscribe from the email lists. I have emailed Sean Leonard to explain this as well, and to ask him to = remove me as a reviewer of this project. Thank you, Fletcher Penney --=20 Fletcher T. Penney fletcher@fletcherpenney.net=20 --Apple-Mail=_6E8D3BCA-1711-4B4F-A5BF-156A70215542 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

-- 


= --Apple-Mail=_6E8D3BCA-1711-4B4F-A5BF-156A70215542-- --Apple-Mail=_18AAB516-94A9-460B-BBCB-602D92C16F2C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPOzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTgwggQgoAMC AQICEQDAX9LMQixpGwQOeQtHJ7TlMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTEwNDAwMDAwMFoXDTE0MTEwNDIzNTk1OVowLDEqMCgGCSqG SIb3DQEJARYbZmxldGNoZXJAZmxldGNoZXJwZW5uZXkubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAph1i3pN+Zt7You7JODIYgGIv82YJVkSxBp0i9zpw+IIADYI0grIW2G3lg/E9 i9MBwetn++K37I7Kt7SnYZcdrkZUBCwS3bDOobGlLXFTtcXJQI+GB1zPP1vM8kFilI3aZYdbCzgt cxW0WWwWxJ075nBvvHyBkLP2PWdzxSArKCpz5v79rDqdk0pTjuASGb2/VrSZ61BNxusaanmryDph Vcnnnkf+l9diwAW3NbC/99ApJTgqtrqnRs4Nene1w/+GXyeM72AmQPJT+coCyCC/0ss1Vu3j0BbC XaqsfTcVAuXOjbY6SM0aVwIbQ+g00v42zzj0GfaGLVg2OjlIpaww9QIDAQABo4IB6zCCAecwHwYD VR0jBBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFAyy5amhFrElryQn4HQCVgoU ozhZMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsr BgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEw KzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBM oEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25h bmRTZWN1cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8v Y3J0LmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWls Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEb ZmxldGNoZXJAZmxldGNoZXJwZW5uZXkubmV0MA0GCSqGSIb3DQEBBQUAA4IBAQAec1OL/CaNPcde mvbBBSRWg04qFvV/F4PNUNJgpKPu2z23U8FZJAn1RhCGb6dWYquCIDCCtyz5yP1Xdcv57dd9d/xR YJIPYK+iSSgB8xyVnraH5GfryRHx/5aIqIVSjZrrAhQAZ4Q8a16HuAkjYwmdKESn55eiYFUHioht 00xh4o6q0hPP24KfKPZLLN7jAeuqISR5bgrvsJGAjp4N9N0MbInDsZ5SEySKEB6RK3c9xd9f1bYV Xu+jhqV0GzIEbOWHiWGFvbQSqgK+6Az2eW0nSRZBanCEcb4NMhCF0kK7czCUo+YgNOQilx57gMwr OHtpBDRdKeXh2R4guFijK6e3MYIDrjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQI ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0ECEQDAX9LMQixpGwQOeQtHJ7TlMAkGBSsOAwIaBQCgggHZMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MTAzMDAxMzIyN1owIwYJKoZIhvcNAQkE MRYEFOqLV7srFsFhOZPupFYDTh9XJM8RMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDAX9LMQixpGwQOeQtHJ7TlMIG8BgsqhkiG9w0BCRAC CzGBrKCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9E TyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMBf0sxCLGkbBA55 C0cntOUwDQYJKoZIhvcNAQEBBQAEggEAmh4Kbfd7AZ8MWQ9MRjmPWlK3RFdGI63KqYiNehtRP4la T3MLwbuDSbYU5Z/DC68K0iqvqPv3A/WwDsYY+r0W1pI8ZoscoRH683CuaI4Jtny8IQvTjQX8aOGp JSstoJakI6eo2lZ8tvzm5y4WnG5DuipSFVIbHsv3obO0YjePE3e22oX0oIS29dxpfNxxz1HiAGN/ WupJuDzVVlukn2KPnwjQLiiWiqFl7kEuIrWbd71ffmhFg6zzTWEkS4RfDRoPhGfTnAF9lwcC9XcQ KOmbouuPzOh3R3VMmz0f1VBQw/gpx2pYaGcq2ph/OLTl63YOjNtQlvF04ymrCR81NNBkzwAAAAAA AA== --Apple-Mail=_18AAB516-94A9-460B-BBCB-602D92C16F2C-- From nobody Thu Oct 30 00:37:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034421AD03B for ; Thu, 30 Oct 2014 00:37:00 -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 BJ23bMhswSXX for ; Thu, 30 Oct 2014 00:36:58 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A150D1AD038 for ; Thu, 30 Oct 2014 00:36:44 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 3A1DCFA0136; Thu, 30 Oct 2014 07:36:42 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1414654601-4330-4329/12/63; Thu, 30 Oct 2014 07:36:41 +0000 From: Arnt Gulbrandsen To: IETF Apps Discuss , "Fletcher T. Penney" Message-Id: References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <01PDWHBG1ZY200005L@mauve.mrochek.com> <544C81B2.6090409@seantek.com> <544D408B.3090404@fletcherpenney.net> <01PE7F4UX0780028JO@mauve.mrochek.com> <94B993C2-29D2-4AE6-9B7B-32417F7E1B9D@seantek.com> <544E34EA.3090406@ninebynine.org> <18726A9B-D2C4-47E7-A564-5D15E3631F32@fletcherpenney.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Date: Thu, 30 Oct 2014 07:36:41 +0000 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/dVGxPwZcAcudoE0ZDneiQLPqNM8 Subject: [apps-discuss] text/markdown discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 07:37:00 -0000 I reiterate my earlier proposal for an RFC consisting of four sentences = plus IANA and IETF boilerplate. Arnt From nobody Thu Oct 30 13:33:08 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEF61A6FA3 for ; Thu, 30 Oct 2014 13:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJ4WCwWwNxvO for ; Thu, 30 Oct 2014 13:33:04 -0700 (PDT) Received: from cp.hebergementsolutions.com (cp.hebergementsolutions.com [184.170.132.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1751A6F3D for ; Thu, 30 Oct 2014 13:33:04 -0700 (PDT) Received: from [173.246.9.72] (port=51507 helo=minimi.michelf.ca) by cp.hebergementsolutions.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1XjwPd-0002jl-EM; Thu, 30 Oct 2014 16:33:41 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_B0F86D7D-7615-4739-AC77-F9D52BB6D448"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michel Fortin In-Reply-To: Date: Thu, 30 Oct 2014 16:32:59 -0400 Message-Id: References: <706B0BF7-734E-4459-92FC-EA9EEEDE8610@seantek.com> <01PDWHBG1ZY200005L@mauve.mrochek.com> <544C81B2.6090409@seantek.com> <544D408B.3090404@fletcherpenney.net> <01PE7F4UX0780028JO@mauve.mrochek.com> <94B993C2-29D2-4AE6-9B7B-32417F7E1B9D@seantek.com> <544E34EA.3090406@ninebynine.org> <18726A9B-D2C4-47E7-A564-5D15E3631F32@fletcherpenney.net> To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.1990.1) X-cPanel-MailScanner-Information: Please contact the ISP for more information X-cPanel-MailScanner-ID: 1XjwPd-0002jl-EM X-cPanel-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-cPanel-MailScanner-SpamCheck: X-cPanel-MailScanner-From: michel.fortin@michelf.ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cp.hebergementsolutions.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - michelf.ca X-Get-Message-Sender-Via: cp.hebergementsolutions.com: authenticated_id: michel.fortin@michelf.ca Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QFORez0mkiVBDHsHg1OzC3YX4Uo Cc: "Fletcher T. Penney" , IETF Apps Discuss Subject: Re: [apps-discuss] text/markdown discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 20:33:07 -0000 --Apple-Mail=_B0F86D7D-7615-4739-AC77-F9D52BB6D448 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 30-oct.-2014 =C3=A0 3:36, Arnt Gulbrandsen = a =C3=A9crit : > I reiterate my earlier proposal for an RFC consisting of four = sentences plus IANA and IETF boilerplate. I think I'd like that too. --=20 Michel Fortin michel.fortin@michelf.ca https://michelf.ca --Apple-Mail=_B0F86D7D-7615-4739-AC77-F9D52BB6D448 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMjTCCBjQw ggQcoAMCAQICAR8wDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAI6ByrMlixq5 piBb1m3JRDRfINXQII5OT8TWqeZz8zse9vt7fUZHaPVLFeWYlj8B9BA2uHhGfyZtPtyf0nYtnFPK g7xiSXX/apE16bFfYdtHka3qupMggZp1+OZmtAdRO/TRij5C2bV2o+kIf+53LfWav2tw6pICxfJO 9Hrjl7HbYo3+l3ul9YVB5SVKG8WLmMCkpm7ti1Z4LOYF0Y5AG3d8AqYS3/5aUWQN/ZQN4BMruXSJ GFYFYBDxu7jTBbBW9l2m4u/s80e+jkJ9P9XDXeOsclCsdAtY4F2C/kOH76j6fwiABKLx454BkTMt ukts/PLtzrIy37oV0UTiykmcFCXSmc1gQk+xz25vGs/D36Ve8L+2A+J7idUYP83A1wS4JLgb4Q7J Fzl/lqLO+IDM+AGH9cujofg7Pjl2HdyDq3FOn7eAz2ZPN+zGzes5/E8rK1QnTsk9tIsi7QRIPdAB TnhC8ImOaNjVkB9JGUJ2BAXwVLB5Dq9SEdnGiyWdS7a9fb+Tfy8D2wuOA9metV0hUlrPMHCmJtZR bFZAjOlQrKhMM5hE31Qal2HF6OkfVhtE0nvqgj6dLt3871yxSYh13c0OBF6kZPR9Sgij3GZhAwEN sESI065Wg0BRSoCtWB6RxATzwIyIGgD/Gm8uPp+cv9OtSrDRwNjGphN+MQ81oVh5MIIGUTCCBTmg AwIBAgIDCZgGMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTQwNDEwMDkzMjE4WhcNMTUwNDEyMDIxMjUzWjBnMRkwFwYDVQQNExBZbjhVdjUyNmNnNGJjcmlR MSEwHwYDVQQDDBhtaWNoZWwuZm9ydGluQG1pY2hlbGYuY2ExJzAlBgkqhkiG9w0BCQEWGG1pY2hl bC5mb3J0aW5AbWljaGVsZi5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM1xHBAc 28F84D5D/ITRvjBwB3dwI7osaLizqSCZhMRpXg4zWsxIoaDy6H9OTQdpaqY431ypMGiwd7vddirK pEn/DEVb0SItTb73touChfuVVE5LHYPKcL1CfRa0XJF4KhryeP/m9sPA4N4zLb7IR4HFioOkF/XL Hkh9bv12yXUK+6jWpSNaQNf/kUz2AlKUSSx4pW2kBH72EW4xreuRs30Qqft1rqwkL4LRhipd3GA9 0Pni7mOaNSKu3kGCHKz+/4+h4SUdNuD13nhZLwLFHyHhk4I+IpFyq5/vPFr/dFRg3rdpMxhgd+M/ H4rfaUm2Kb0ODq+7FXccjDSbhCFEc08CAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQD AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUu56gBRTHUtBmsqyG mqCVXtMAz9cwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYbWlj aGVsLmZvcnRpbkBtaWNoZWxmLmNhMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCC ASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRp b24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFy dHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29t L2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3Nw LnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2Fp YS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqG GGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAJjgunxV0rh494ufL ch4bvYfoewNrW9OIZjpyS3GTzjD+a8aUIctmXo5HilIew8NwaYzRRKhQ3V4uy3rPmpIGddZfXlxm jlejMlWCVcgBBuB2CziegUCWvJbpSjz4eM0dQX6nU0zAGV1iqWkdrIxMgkgeeGWZaWV+m2Qu/oWw 9EbgegPaz+cFJNbrZEjA06d9CKQJTn2MP7POPPSwDTlTHZ/b6/X1MckAfCeEm96CRCEEzBo06Yki UMJMOdqVggAyP7huNxo7TpnNfe7ylve4vsHBSxpW7NElcMaXIgFalFVmpxZICOvxcncajCmYOzJp cb+YJuJwkeYf5CMjGsBshzGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAwmYBjAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNDEwMzAyMDMyNjBaMCMGCSqGSIb3DQEJBDEWBBQWWGD/Me+o1paZsrKn2pNXPrbs aDCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwmYBjCB pwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCZgGMA0G CSqGSIb3DQEBAQUABIIBAGhbSKINySIsOif6QtV+KbSoi+dCBAnXGn/ca1AsymdVw8XGwt6VfdE/ nlA5foDHPyijb577M1FfwBdXJkKD/FhHJJTQmGqzcznD+OIw7+l0XwQ7/iErNfk7tsXkio5Cqi7K 3f52BqotqPpWJ+2QOVVNkvh9Y8aIIniKKaeZE1ikCoIhTYdfxj6Z/CgNsRkzJYayosep6qectEou 2yx/Wx1P7ShbzYTPCpfE5GsrFQGVwwEdN3SbhA117hQaubaTVP7X1nPftjYccpoJndndXRnbZjne p49Ca7bSb6EpdhicA0mlHd5Ww39cMzWlolAqF0nnb8za0IEUWH5HMxS5fDQAAAAAAAA= --Apple-Mail=_B0F86D7D-7615-4739-AC77-F9D52BB6D448-- From nobody Fri Oct 31 16:31:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE3F1A873C; Fri, 31 Oct 2014 16:31:43 -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 s7HrxxwIODfJ; Fri, 31 Oct 2014 16:31:42 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5FD1A870D; Fri, 31 Oct 2014 16:31:42 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C8558181C73; Fri, 31 Oct 2014 16:30:49 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20141031233049.C8558181C73@rfc-editor.org> Date: Fri, 31 Oct 2014 16:30:49 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/bsa35INKNPxYekoro3Vq3fc87Lc Cc: drafts-update-ref@iana.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] RFC 7396 on JSON Merge Patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 23:31:44 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7396 Title: JSON Merge Patch Author: P. Hoffman, J. Snell Status: Standards Track Stream: IETF Date: October 2014 Mailbox: paul.hoffman@vpnc.org, jasnell@gmail.com Pages: 9 Characters: 12791 Obsoletes: RFC 7386 URL: https://www.rfc-editor.org/rfc/rfc7396.txt This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target resource's content. 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