From stpeter@stpeter.im Wed Aug 1 10:59:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7614911E83B6 for ; Wed, 1 Aug 2012 10:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.201 X-Spam-Level: X-Spam-Status: No, score=-102.201 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZnOFXBCEnOF for ; Wed, 1 Aug 2012 10:59:15 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D272E11E8335 for ; Wed, 1 Aug 2012 10:59:15 -0700 (PDT) Received: from [192.168.0.4] (unknown [67.177.192.224]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2808C40075; Wed, 1 Aug 2012 12:19:00 -0600 (MDT) Message-ID: <50196E71.4080306@stpeter.im> Date: Wed, 01 Aug 2012 11:59:13 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , "public-iri@w3.org" , uri@w3.org References: <1343842421.2556.229.camel@chacal> In-Reply-To: <1343842421.2556.229.camel@chacal> X-Enigmail-Version: 1.4.3 X-Forwarded-Message-Id: <1343842421.2556.229.camel@chacal> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Fwd: web+: enabling websites to expose services with custom URI schemes to registerProtocolHandler. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2012 17:59:16 -0000 FYI, Philippe Le Hagaret has initiated discussion about the proposed web+ URI scheme prefix on the public-ietf-w3c list. I think that is the right place to discuss the topic, so if you have feedback then please subscribe to that list and post there. http://lists.w3.org/Archives/Public/public-ietf-w3c/ mailto:public-ietf-w3c-request@w3.org?subject=subscribe Peter -------- Original Message -------- Subject: web+: enabling websites to expose services with custom URI schemes to registerProtocolHandler. Resent-Date: Wed, 01 Aug 2012 17:33:59 +0000 Resent-From: public-ietf-w3c@w3.org Date: Wed, 01 Aug 2012 10:33:41 -0700 From: Philippe Le Hegaret Organization: World Wide Web Consortium To: Barry Leiba , Mark Nottingham CC: public-ietf-w3c@w3.org Following the morning discussion, here are the links to the web+ definition: http://www.w3.org/TR/html5/system-state-and-capabilities.html#custom-handlers look for the item on scheme (registerProtocolHandler() only) http://www.w3.org/TR/html5/iana.html#web-scheme-prefix Note that the Working Group is about to decide that this section needs rewrite because it must not look like an IANA registration. I also suggest to look at the rational section of a change proposal related to this: http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-189#Rationale Philippe From Michael.Jones@microsoft.com Fri Aug 3 10:04:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FCC21F8E23 for ; Fri, 3 Aug 2012 10:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.794 X-Spam-Level: X-Spam-Status: No, score=-3.794 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaOptfT9QPiU for ; Fri, 3 Aug 2012 10:04:22 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id C2AC221F8E19 for ; Fri, 3 Aug 2012 10:04:22 -0700 (PDT) Received: from mail49-co1-R.bigfish.com (10.243.78.225) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.23; Fri, 3 Aug 2012 17:04:21 +0000 Received: from mail49-co1 (localhost [127.0.0.1]) by mail49-co1-R.bigfish.com (Postfix) with ESMTP id 82D414A03C5; Fri, 3 Aug 2012 17:04:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VS0(zzc85fhzz1202hzz8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail49-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail49-co1 (localhost.localdomain [127.0.0.1]) by mail49-co1 (MessageSwitch) id 1344013459838891_13303; Fri, 3 Aug 2012 17:04:19 +0000 (UTC) Received: from CO1EHSMHS022.bigfish.com (unknown [10.243.78.243]) by mail49-co1.bigfish.com (Postfix) with ESMTP id C17A0480044; Fri, 3 Aug 2012 17:04:19 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS022.bigfish.com (10.243.66.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 3 Aug 2012 17:04:18 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0309.003; Fri, 3 Aug 2012 17:04:18 +0000 From: Mike Jones To: "appsawg-chairs@tools.ietf.org" Thread-Topic: draft-saintandre-acct-uri to working group document? Thread-Index: Ac1xmgJoVAvN6lBvTgy4wckLNeiPGA== Date: Fri, 3 Aug 2012 17:04:18 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366751E1D@TK5EX14MBXC285.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: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366751E1DTK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] draft-saintandre-acct-uri to working group document? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2012 17:04:23 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366751E1DTK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is it time for Peter to submit draft-saintandre-acct-uri as a working group= document? -- Mike --_000_4E1F6AAD24975D4BA5B168042967394366751E1DTK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is it time for Peter to submit draft-saintandre-acct= -uri as a working group document?

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

--_000_4E1F6AAD24975D4BA5B168042967394366751E1DTK5EX14MBXC285r_-- From superuser@gmail.com Fri Aug 3 10:50:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6024821F8DE0 for ; Fri, 3 Aug 2012 10:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.658 X-Spam-Level: X-Spam-Status: No, score=-3.658 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhTX0b4GeAxk for ; Fri, 3 Aug 2012 10:50:32 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CFCCE21F8D68 for ; Fri, 3 Aug 2012 10:50:31 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1878593lbb.31 for ; Fri, 03 Aug 2012 10:50:22 -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=MGy6IMX3qzyvYT+qMc2+NqeTYuZrzV8EojCATuQkHjA=; b=PV4p1AZQPG+vQgxkCZ6P714MUfn2NIQjNx3DK0gVljvo9N+jGKgIIHtAbD6IMdBGG2 4Er6sWZ8t3JSQc0UtdZMS/Aou4ukDOd+BXE0pCLS8RSrBezYA6qUKBGi/puX6Ln3moZk nM8zImVGYraLmvxc63oE9VPGgAPZ1Jvc+JZGYjXrvaEaJx+LGRmCHyBLKAJDhHk/PFhM zoXfaMa959XnMR5vH7TIDwdyiyaW/dLy6OMKX9N9F13D78NCHtqU8lc8IFl/5Wal0y28 3WiepsEBtUvHezYRlXmNFMRpes5vd9AJJeSqLPI/VrFuc73Aovf3WwTAclfHfNSgZMGE MZNA== MIME-Version: 1.0 Received: by 10.112.39.135 with SMTP id p7mr956734lbk.78.1344016222214; Fri, 03 Aug 2012 10:50:22 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Fri, 3 Aug 2012 10:50:22 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366751E1D@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366751E1D@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Fri, 3 Aug 2012 10:50:22 -0700 Message-ID: From: "Murray S. Kucherawy" To: Mike Jones Content-Type: multipart/alternative; boundary=485b390f7a767f58ee04c660297f Cc: "appsawg-chairs@tools.ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-saintandre-acct-uri to working group document? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2012 17:50:33 -0000 --485b390f7a767f58ee04c660297f Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 3, 2012 at 10:04 AM, Mike Jones wrote: > Is it time for Peter to submit draft-saintandre-acct-uri as a working > group document?**** > > > > Salvatore is the document shepherd for this one. He'll reach out to Peter when he's ready to move ahead with it. -MSK --485b390f7a767f58ee04c660297f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Aug 3, 2012 at 10:04 AM, Mike Jones <Michael.Jones@mic= rosoft.com> wrote:

Is it time for Peter to submit draft-saintandre-acct= -uri as a working group document?




Salvatore is the document shepherd for t= his one.=A0 He'll reach out to Peter when he's ready to move ahead = with it.

-MSK

--485b390f7a767f58ee04c660297f-- From superuser@gmail.com Fri Aug 3 13:19:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901CA21E8042 for ; Fri, 3 Aug 2012 13:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.658 X-Spam-Level: X-Spam-Status: No, score=-3.658 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6adZOLGZKi3 for ; Fri, 3 Aug 2012 13:19:09 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C60E421E8040 for ; Fri, 3 Aug 2012 13:19:08 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1948219lbb.31 for ; Fri, 03 Aug 2012 13:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yMNNU4+uK2UYuWcoWZds4V81mahigYpv/i6/YPtgbAU=; b=moGF7NiyoPwd+zaO0RyNw5YK60fAA2HrvJhBxTGUs/vi9oFFaDCOjip/v7ZrWuzUi4 e8lhtovdpzdjFT5xeOm2tzWdqL7GsVfyT0b6fw7VXyHUOeix2EKVkWewdfwTqSkkfTBM 6x7/th+jX2bIiXZ08OPk2TnXJ0DmRsr23WVOKSBRQKxbfhTdqYrdesw+iSU3VwunmN5/ hJdR4FcvjXewT6SQviuks29/Oy+GPoZDbX8fyeeM9kqs5KLSsf/kJiheV/d0DNOcfdtK 7lpRP6FGk1frz+fw/iq29NAYexbUyMbYJjxfPWnQ5oCjns6kixsJuzvLPfZmxZ23cTQS x+hg== MIME-Version: 1.0 Received: by 10.152.131.68 with SMTP id ok4mr2626363lab.47.1344025147742; Fri, 03 Aug 2012 13:19:07 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Fri, 3 Aug 2012 13:19:07 -0700 (PDT) In-Reply-To: <9B30F7F1-A25D-4B18-8DD5-DD4FF7A84709@isode.com> References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> <9B30F7F1-A25D-4B18-8DD5-DD4FF7A84709@isode.com> Date: Fri, 3 Aug 2012 13:19:07 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alexey Melnikov Content-Type: multipart/alternative; boundary=f46d0435c1d28017ff04c6623d8e Cc: Barry Leiba , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2012 20:19:09 -0000 --f46d0435c1d28017ff04c6623d8e Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 29, 2012 at 7:33 AM, Alexey Melnikov wrote: > > I think Specification Required would be better here, so I support this > change. > > > +1. Are there other opinions on this point? I'd rather send this to the IESG with more than just myself and Alexey weighing in. -MSK, multi-hatted --f46d0435c1d28017ff04c6623d8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Jul 29, 2012 at 7:33 AM, Alexey Melnikov <alexey.melnikov@= isode.com> wrote:

I think Specification Required would be better here, so I suppo= rt this change.



<participant>
+1.
</pa= rticipant>

<co-chair>
Are there other opinions on this p= oint?=A0 I'd rather send this to the IESG with more than just myself an= d Alexey weighing in.
</co-chair>

-MSK, multi-hatted

--f46d0435c1d28017ff04c6623d8e-- From mnot@mnot.net Fri Aug 3 13:42:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5C921F8E27 for ; Fri, 3 Aug 2012 13:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.216 X-Spam-Level: X-Spam-Status: No, score=-105.216 tagged_above=-999 required=5 tests=[AWL=-2.617, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1udHuuFHVb8 for ; Fri, 3 Aug 2012 13:42:25 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id B357C21F8E24 for ; Fri, 3 Aug 2012 13:42:25 -0700 (PDT) Received: from [10.6.130.84] (unknown [50.56.228.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 18CFD22E259; Fri, 3 Aug 2012 16:42:19 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Mark Nottingham In-Reply-To: Date: Fri, 3 Aug 2012 15:42:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> <9B30F7F1-A25D-4B18-8DD5-DD4FF7A84709@isode.com> To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1485) Cc: Barry Leiba , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2012 20:42:26 -0000 If you do that, you'll need to specify an expert policy. May I humbly suggest = . Cheers, On 03/08/2012, at 3:19 PM, Murray S. Kucherawy = wrote: > On Sun, Jul 29, 2012 at 7:33 AM, Alexey Melnikov = wrote: >=20 > I think Specification Required would be better here, so I support this = change. >=20 >=20 >=20 > > +1. > >=20 > > Are there other opinions on this point? I'd rather send this to the = IESG with more than just myself and Alexey weighing in. > >=20 > -MSK, multi-hatted >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From barryleiba@gmail.com Fri Aug 3 13:49:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366F221E808A for ; Fri, 3 Aug 2012 13:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaMVYZngBggA for ; Fri, 3 Aug 2012 13:49:52 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0A28221E8089 for ; Fri, 3 Aug 2012 13:49:48 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so100842pbb.31 for ; Fri, 03 Aug 2012 13:49:47 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=plVt70nTAEg3aFJTJvhFsBLOJwNRpBA2rcdsZhTLH3o=; b=SmldPf4+l7481LI+3TNrmRQ6EXBa+mV7wcQPdJ5AlSyvRApzOEKHsB3GKsSFf3CvQx oB420BBbUxzo9mao4w6pcjaoUiizOZj3yN2Z7T95g/V5bDO4KomNhxOPWrChtAdlrhQV c7awGXDzz8kTVhFxqYC40R63ldY9CQITaUxmvMH5ADLc8Npd+121fwCp1luuKkvm2kUw srP7gYeN9ZrkhZa7TaM1jARnkAQwJhPzp6XiAarQKDIb6l1kKMG+DcimQ02k3/O2wroA BBwZdAUviSJo9uCOTqWHVe/GTEE6/2/wO32khwv8+JYUtwB7QFJgPhaJmQC6pqaFuxL/ 18kw== MIME-Version: 1.0 Received: by 10.68.221.74 with SMTP id qc10mr340342pbc.31.1344026987869; Fri, 03 Aug 2012 13:49:47 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.68.64.103 with HTTP; Fri, 3 Aug 2012 13:49:47 -0700 (PDT) In-Reply-To: References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> <9B30F7F1-A25D-4B18-8DD5-DD4FF7A84709@isode.com> Date: Fri, 3 Aug 2012 16:49:47 -0400 X-Google-Sender-Auth: sS3Un9whrvq1JNjNsHMgitMbiKo Message-ID: From: Barry Leiba To: Mark Nottingham Content-Type: multipart/alternative; boundary=e89a8ff2432b2e36f204c662ab9a Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2012 20:49:53 -0000 --e89a8ff2432b2e36f204c662ab9a Content-Type: text/plain; charset=ISO-8859-1 > > If you do that, you'll need to specify an expert policy. > There is one, in Andreas's message to this list. Does that sound OK to you? b --e89a8ff2432b2e36f204c662ab9a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If you do that, you'll need to specify a= n expert policy.

There is one, in Andreas's message to = this list. =A0Does that sound OK to you?

b=A0
--e89a8ff2432b2e36f204c662ab9a-- From mnot@mnot.net Fri Aug 3 13:51:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A058621E808F for ; Fri, 3 Aug 2012 13:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.842 X-Spam-Level: X-Spam-Status: No, score=-104.842 tagged_above=-999 required=5 tests=[AWL=-2.243, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUUeOYaTyNpv for ; Fri, 3 Aug 2012 13:51:33 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id F1BBC21E808E for ; Fri, 3 Aug 2012 13:51:32 -0700 (PDT) Received: from [10.6.130.84] (unknown [50.56.228.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4FADD22E25D; Fri, 3 Aug 2012 16:51:32 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Mark Nottingham In-Reply-To: Date: Fri, 3 Aug 2012 15:51:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <02DEB8B5-0A02-46CB-93D3-32D5EC838771@mnot.net> References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> <9B30F7F1-A25D-4B18-8DD5-DD4FF7A84709@isode.com> To: Barry Leiba X-Mailer: Apple Mail (2.1485) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2012 20:51:33 -0000 Ah, missed that, sorry. +1, assuming you're referring to this: """ "To keep the registration process uncomplicated and to encourage parameters that are in use to be registered, the designated expert should set a low bar for new registrations, confirming mostly that the specification is reasonably stable, readily available, and sufficient to create interoperable implementations. The parameter name ought to make sense for the requested usage, being short but sufficiently specific. The specification needs to comply with this document and the general HTTP specifications, and should address security and privacy implications of the requested parameter." """ On 03/08/2012, at 3:49 PM, Barry Leiba wrote: > If you do that, you'll need to specify an expert policy. >=20 > There is one, in Andreas's message to this list. Does that sound OK = to you? >=20 > b=20 -- Mark Nottingham http://www.mnot.net/ From pmhsfelix@gmail.com Fri Aug 3 16:07:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D04811E809C for ; Fri, 3 Aug 2012 16:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qScEjaCs9PTM for ; Fri, 3 Aug 2012 16:07:28 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7540121F8DBA for ; Fri, 3 Aug 2012 16:07:28 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1942110obb.31 for ; Fri, 03 Aug 2012 16:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/ce+eltRYtQN0TtFge7sHgHfNPdDf19Pwn3Z3RySJQ0=; b=XOZ1z2wYJ5Tm4BsJ2AFncDzOlwYjA5h7GOW+BWQe2B/RiHcEPvKtLzv2GZf/tSnt76 zJQ+D6TySzA7ozJHqp5UT6m8MTVe28xYp+tKp6PuKDnZjLKYns/34dRieMT44YElzXxE rqbRhLUiSENNzbaYnlEtMlmpaUkR2AlqPUNQKuUUZtO2ErHSZYG9r898JxRAVBTvdIpq Q3eZCL3KYx9l50XihjqtxNMpBcMY+KyZSm7/8q/q5Bgj3Affk9v2rDI0zFxEIlMmksp6 XYRgPh1tHKorX3DVc+VmlGEnB30gUFTdCPYX+2u7nzy5jyxzXQzInE1fyfPU4mJKOwjm Prmg== MIME-Version: 1.0 Received: by 10.182.117.71 with SMTP id kc7mr7944121obb.62.1344035248067; Fri, 03 Aug 2012 16:07:28 -0700 (PDT) Received: by 10.182.13.194 with HTTP; Fri, 3 Aug 2012 16:07:28 -0700 (PDT) Date: Sat, 4 Aug 2012 00:07:28 +0100 Message-ID: From: Pedro Felix To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=f46d04446a4d86d28304c66497c5 Subject: [apps-discuss] Fwd: New Version Notification for draft-nottingham-http-problem-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2012 23:09:11 -0000 --f46d04446a4d86d28304c66497c5 Content-Type: text/plain; charset=ISO-8859-1 I also like Erik's idea: 1) Mandatory "error type" (described by) as a error code URI. If dereferenced could return a generic representation of the error type. For standard-like apis, this URI could be resolved by the standards site. 2) Optional "error instance" URI. When dereferenced always return a representation of the error instance. This could be simply generated by a template that receives the JSON properties (no state required on the server) Example: { "describedby": "http://example.com/probs/out-of-credit", "title": "You do not have enough credits.", "detail": "Your current balance is 30, but that costs 50.", "balance": 30, "required": 50 "account": "http://api.example.com/account/12345" "error_instance": "http://example.com/probs/out-of-credit/instace?* balance=30*&*account=12345&required=50*" (opaque URI for the client; needs a better name) } When dereferecing http://example.com/probs/out-of-credit/instace?*balance=30 *&*account=12345**&required=50*, the server would return a representation (e.g. text/html) of the error instance (e.g.

Unfortunately, your current balance of 30 credits on account 12345 is insufficient. At least 50 are required.

). Notice that the representation associated to "error_instance" contains the exact same information present in the original JSON response, so no sensitive information is disclosed. Is just presents it in a nice formatted way. Pedro hello all. thanks, mark, for the initiative! On 2012-07-04 07:54 , mike amundsen wrote: So the content at the other end of URI "z" will always be the same content, no matter the app using this URI, or the specifics that _caused_ the "problem", right? FWIW, in my current usage, the href points to a record that is specific to the immediate problem. This means it is possible that the server will create and collect error logging information at these URIs. I assume that possibility is not accounted for in your baseline design. it seems to me there's value in having the ability to express both concepts: an "error type" that indicates the type of problem encountered (and i think mark's idea of using a URI for this is better than using a non-URI identifier), as well as an "error instance" that indicates specific information about the occurrence of the error in that particular case. both could probably be optional, and for the type link i'd suggest to treat this as an identifier only (clients should not dereference the URI, the only meaningful operation would be to compare it to known error identifiers), whereas the error instance would be expected to return a representation of the specific error instance. cheers, dret. --f46d04446a4d86d28304c66497c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I also like Erik's idea:

1) Mandatory "erro= r type" (described by) as a error code URI. If dereferenced could retu= rn a generic representation of the error type. For standard-like apis, this= URI could be resolved by the standards site.

2) Optional "error instance" URI. When derefe= renced always return a representation of the error instance. This could be = simply generated by a template that receives the JSON properties (no state = required on the server)
Example:

{
=A0 =A0 "descr= ibedby": "http= ://example.com/probs/out-of-credit",
=A0 =A0 "title= ": "You do not have enough credits.",
=A0 =A0 "detail": "Your current balance is 30, but that= costs 50.",
=A0 =A0 "balance": 30,
=A0 = =A0 "required": 50
=A0 =A0 "account": "<= a href=3D"http://api.example.com/account/12345">http://api.example.com/acco= unt/12345"
=A0 =A0 "error_instance": "http://example.com/probs/out-of-credit/insta= ce?balance=3D30&account=3D12345&required=3D50&quo= t; (opaque URI for the client; needs a better name)
}

When dereferecing=A0http://example.com/probs/out-of-c= redit/instace?balance=3D30&account=3D12345&req= uired=3D50, the server would return a representation (e.g. text/html) o= f the error instance=A0
(e.g. <p>Unfortunately, your current balance of 30 credits on &l= t;a href=3D"...">account 12345</a> is insufficient. At l= east 50 are required.</p>).=A0
Notice that the representati= on associated to "error_instance" contains the exact same informa= tion present in the original JSON response, so no sensitive information is = disclosed. Is just presents it in a nice formatted way.

Pedro


hello all=
.

thanks, mark, for the initiative!

On 2012-07-04 07:54 , mike amundsen wrote:

So the content at the other end of URI "z" will always be the sam=
e
content, no matter the app using this URI, or the specifics that
_caused_ the "problem", right?
FWIW, in my current usage, the href points to a record that is specific
to the immediate problem. This means it is possible that the server will
create and collect error logging information at these URIs.
I assume that possibility is not accounted for in your baseline design.

it seems to me there's value in havi=
ng the ability to express both=A0concepts: an "error type&quo=
t; that indicates the type of problem encountered=A0(and i think m=
ark's idea of using a URI for this is better than using a=A0no=
n-URI identifier), as well as an "error instance" that indicates=
=A0specific information about the occurrence of the error in that=
=A0particular case. both could probably be optional, and for the t=
ype link=A0i'd suggest to treat this as an identifier only (cl=
ients should not=A0dereference the URI, the only meaningful operat=
ion would be to compare=A0it to known error identifiers), whereas =
the error instance would be=A0expected to return a representation =
of the specific error instance.
cheers,

dret.




--f46d04446a4d86d28304c66497c5--

From randy@qualcomm.com  Fri Aug  3 16:38:59 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5428321E8053 for ; Fri,  3 Aug 2012 16:38:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8ZdcmPiLEZe for ; Fri,  3 Aug 2012 16:38:59 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 4F05F21E8048 for ; Fri,  3 Aug 2012 16:38:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1344037139; x=1375573139; h=message-id:x-mailer:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-originating-ip; bh=5wcHwUSUcwkGcI3y/dySaA2Yf1L+vUBbT/mi8gCJ6mQ=; b=Mwg9vDiCmx03DyZicvBrDdUZa9C3io2OvJATTK26GKQP3OGR05bh2b6e 3WKlUuLZyaWNNUTqHZC7PlAHDHQlxrgOMSe+RAmDpKivaSw7zoNI5hMAZ YsQMR1Y4jUIYnpYlllmC6ctAGAYqeAMGNSe1nZlH5Uw6EAg76dQUOkqtz E=;
X-IronPort-AV: E=McAfee;i="5400,1158,6792"; a="216742410"
Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 03 Aug 2012 16:38:58 -0700
X-IronPort-AV: E=Sophos;i="4.77,709,1336374000";  d="pdf'?scan'208";a="160305626"
Received: from nasanexhc12.na.qualcomm.com ([172.30.39.187]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Aug 2012 16:38:58 -0700
Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc12.na.qualcomm.com (172.30.39.187) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 3 Aug 2012 16:38:57 -0700
Received: from [208.181.206.130] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 3 Aug 2012 16:38:54 -0700
Message-ID: 
X-Mailer: Eudora for Mac OS X
Date: Fri, 3 Aug 2012 16:38:46 -0700
To: 
From: Randall Gellens 
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="============_-868085363==_============"
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [172.30.48.1]
Subject: [apps-discuss] 2006 proposal to add spam score and spam notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 23:38:59 -0000

--============_-868085363==_============
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi all,

During the apparea/appwg discussion of 
draft-ordogh-spam-reporting-using-imap, I was asked to send 
information regarding a proposal I'd made a number of years back to 
do this.

Attached are slides outlining the proposal from July 27, 2006 (so 
pretty much exactly six years ago).  Page 20, for example, shows spam 
score being included in the message notification to the client, and 
the client sending an indication if a message is or is not spam back 
to the server.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I think we'd get fewer weird bug reports if we stopped selling our
software off planet.
--============_-868085363==_============
Content-ID: 
Content-Type: application/octet-stream; name="mobile-email-spam-slides.pdf"
Content-Disposition: attachment; filename="mobile-email-spam-slides.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjMKJcTl8uXrp/Og0MTGCjIgMCBvYmoKPDwgL0xlbmd0aCA0IDAgUiAvRmls
dGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNqNk09v4jAQxe/+FHOkB4YZe8YTX/tP
2tuijbRnxILUqpQS2v38azsQ2NBWOJFsRz+/eX52djCHHYSYX6Tc1MA8gQpBt4Lf8Aqz
uz3Dcg9cn/2ywGo9HSs87Wm3vlqLgJDVJ2Fu8jD6UCahqO/y3IdUm6NKHqdFmnrlBMsN
3LaglSgdKwt4ZWg3MHtkzF+gXcOEb6B9hofWzb9wFxIWcRk8/lx1y9Xb+8fiBbqnvERj
QMoWmlpqKkjWu5MGjetSaRSbhkiKrdmPDcP9FubXR+sO0Yqh+lxQUKoaodRaKjDtxw2J
leVfZ+0usy4RU21+HDF8G7HLEfMh49LH5IGDah+yH0L+9bbYzB67xccfuNu+vnfbl0Pq
QwjumjtxvU/3yVXozyd37PNVYtI4tvm3ujoHTVGEkzvSEz9GAlk+2tAMghO6QIQw+Lyz
grjPEfNo0eJJJY4RIUVPSc8LuRESDGO55wNiFyqWY0nhtP9hR+6IKHnU/MN9o6JBMJnx
CcEzxFVEGfm/XPjszP8BQgfrTQplbmRzdHJlYW0KZW5kb2JqCjQgMCBvYmoKNDAwCmVu
ZG9iagoxIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTAgMCBSIC9SZXNvdXJj
ZXMgMyAwIFIgL0NvbnRlbnRzIDIgMCBSIC9NZWRpYUJveApbMCAwIDc5MiA2MTJdID4+
CmVuZG9iagozIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VCIC9J
bWFnZUMgL0ltYWdlSSBdIC9Db2xvclNwYWNlIDw8IC9DczEKNSAwIFIgPj4gL0ZvbnQg
PDwgL0YxLjAgNiAwIFIgL0YyLjAgOSAwIFIgPj4gL1hPYmplY3QgPDwgL0ltMSA3IDAg
Ugo+PiA+PgplbmRvYmoKNyAwIG9iago8PCAvTGVuZ3RoIDggMCBSIC9UeXBlIC9YT2Jq
ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjU2IC9IZWlnaHQKMSAvQ29sb3JTcGFj
ZSA1IDAgUiAvU01hc2sgMTEgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAv
RmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnjabcJ7MNMBAADg/uuuu67rurq6urrqyps88wh5
JHmEIhyicCRROJIkiqIokkj89n7YxryGYZ7zGPOe2WZjbPPaZjaPeZR+uCvd9d13QAU4
qAIcUgUOqwFH1ICj6sAxDeC4JnBCC3JSC3JKG3JaB3LmCuSsLuScHuS8HvSCPvSiAfSS
IfSyEVTlKlTVGKZuAtMwhWmawbTN4DrX4FfM4boWcH1LuMF1hKEVwsgaYWyDMLFFmt5A
mtkhze1RFrdQlg4oK0eUtRPaxhltextt54K56Yqxd8M43ME6umOdPLDO90pcPEtcvXBu
3ri7Pjh3X7yHH97zPsHLn+AdQPB5WOobWOoXVOYfXBYQQnwQSgx8RAwKKw8OLw95UhEa
UREWWfn4WWV4VFVEdFVkTPXT2OqoOFL0c1JMfE1sQk3cy9r4xLoXSXUJr8mJyeRXKfVJ
b+uTUxtS0hrevG9MTaekZVDefWhKz2zKyGr++KklM7slK6f185fW7Ny2nLz23G/tX/Op
eQXU/MKOgh+d34s6C4u7iiBdxdBuAEaDwmkwZA8c1YtA96IwdHQJHYPrw+L7cYR+fOkA
gThYWj5IrBgqrxyqqBqurB6pIo2Qahk1daO15NG6eia5gVnfONZAYVGaWE3N7OYWdksb
p7Wd00Ydb+/gUju5HV28zm5eF22iu2eC1jvZQ+f39vHpfVN9/VP9A9MDg9ODQ4KhYcHw
iHCEIWSMihhM0Shzhjk2M8aaZbFn2Zw5Dnh8fpw7z+Ut8CZ2TkyKJ/liPl/Cn5JMTUun
BVIBWLgoFC6KRDLRjGwGPLs0O7c0B56Xz4MX5AsLCrFYIZYoJJJliXRZCl5cWdwtk62C
l5Z2y9fkYMWaYqdSsaxcBq8oV1bWd66ur+5d21jbq9xQ7twEr6//vbEB3tq7ubn/z62t
f+7z68//2t7e/g0SGRtxCmVuZHN0cmVhbQplbmRvYmoKOCAwIG9iago3MDcKZW5kb2Jq
CjExIDAgb2JqCjw8IC9MZW5ndGggMTIgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl
IC9JbWFnZSAvV2lkdGggMjU2IC9IZWlnaHQKMSAvQ29sb3JTcGFjZSAvRGV2aWNlR3Jh
eSAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVh
bQp42vv/f2QDAAgA/wEKZW5kc3RyZWFtCmVuZG9iagoxMiAwIG9iagoxMgplbmRvYmoK
MTMgMCBvYmoKPDwgL0xlbmd0aCAxNCAwIFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VS
R0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjafZJPSBRRHMe/syVCrAVl
JlLwTrYHVwbtYB2M3fVvyrasa6YIss6+2R2dnZ3ezG4lHkKILkHWMbpY0Uk6hgcPHQIP
EYJiXSLoKBkEgpeQ7Tczu+6I2oM37zO//7/fe0BdKG2aeoABecMWyf4ouzs+weo3UIcG
BEErrVhmJJEYdplscWTtfYXknJvh4/X/XQ2CEgISVYDGrMfXHJ72eMDh+7ZpE086rOTS
GWKTuE2kkjHiV8Rnsz6e9nGGWwrxMvFNxRQUJ5AiHigpWSfmDrFsZDSD5JeJuzKWkicm
38BTZxZemfYQ0H0FOPW5JpuwgOV3wKXWmizUDFwcA1Y6a7LdpDsfqWndUjs7XJEUjAJ1
P8rl3Vag/gWw/7xc/vu6XN5/Qzm+Ax91pShKlRlJ0hfA68Ndjf3c4EJTmHNfCVFQNZ37
Rnq82uvXi0f1Jat0EnszcVcXsET3MHYGGHoMvPwJXH0PXPgAJBqA1HUEHqG6bf7AzRMr
mA+Fls3ZrEOWO1jYOTpZhF4IZ7FC3izaXLBBQ2lvY2ldZ66pxQS3uCjxTDvyerHa7zna
QW6MjtBJ8wqo3OqtsDSTSffQ3aCdeCPDe3qdd0G8qGp9g86F0P6kir5Rj6Xzmj2Y8jjQ
bejx4QrDKMRvezGxY9rRZDW+VRrprcpn0rcSdLaQ/MZsYcixaSLf0FwuNeaxlJrLxeIV
XsU4dHBoMOhrgCGJfkQRhgmBAlTSaGShkZS7NoLYwuyxljoSPmak3yafbdfnHork7Xjd
QTSOhbaDCEz+Jv+Wt+Ql+a38a7GlGKppFsSUpqw/+0NxnczVuBVtpSYvvkJ5I6TVkSVp
/qAny1eprzrVWGypRXJy8CfxPV+X3JcpjGk30qybqeTqLPpGfNlOmh7Zrs2vNtdybZ1e
mdwMrs0fmlXhSFf8oKvD/zU7vz//B82wAWgKZW5kc3RyZWFtCmVuZG9iagoxNCAwIG9i
ago3MDYKZW5kb2JqCjUgMCBvYmoKWyAvSUNDQmFzZWQgMTMgMCBSIF0KZW5kb2JqCjE2
IDAgb2JqCjw8IC9MZW5ndGggMTggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0
cmVhbQp42s1aXXNbtxF9v78Cj/JMDWPxjdc27kxm2k481Uxf8kLRlMOEEmWSStt/34NL
8WIJXFzbTcaOkoks52ix2M+zC34U78RHYTz+lQpfLoiglXBWicNG/Es8ijd/OZJYHwWN
/xzXGezCGe1H8Oszerj/bFlKKElOJ0sU8UevTf7BZOkf8bM2afwa1Ii8/JhFq7PkJNYP
4s+3wo2I/I0cWaEdidsH8eavJPE34vZe3OhX4vZn8fZ2eNfRziSZhdtJxx82h/Xm6fS8
2onDFr/ivJEKKsTxqNdWqnDWzkYZaPxVG52MUSmb1Xrz/YMW3+3Fu8837fBiWhuk0zjQ
SjtKU9KOZzkrXp//HJUN+df7th5aW2cTq/FL1yYWiyYeYGIyZgTl76TwH03Gnq2sJyv/
c7TyFZQ0yWSyU8744eapBWllpAl+knmzmsGEbJWYCujh1VCDTIIdonYFJFpJ1hhJ2jPQ
D60kp3EtF9hxh1aSC0Ym64oxbvatJO+cNDExSXetpAAHRmOZTrtWUsBxMURbQJtWUkQ8
Kmbwi53e3n5BKJ7zaSZIhsU8jGc9YjaNgyrw1hghZoqQH7V1n0rFL1CHV4kldXAqU6cO
2IIzSkkXNbnhgn4JVwZxhLS0OH+CrGpICnBmvk+GDGcfXENsQFogBqlIETUkOdSYiIIz
QbajJwvEUcT9iV3u5lhJyVXEhaBMe9BwgcQgAwovu9GHSoo3UXqjjS6QA4MMGYIbKa8V
u9G+khJyLfAwXoH8u4ZEL0OEjQd26WtIVCjVxqVQpDzWEK/ggBipOKC+USKSwZK3fQck
Y2VEc+LnXNs/oeCH5GPs3xm10kufuLanyv6kcqV3aiEWSMFHXmk3f1C2PxF85JSzfbOg
zSZpUR8LZFdDNGnpvArF/v9tIC7KBFcvqKtjrp6RJUDtaBQnVLwQrOg6mkxAQmueaafK
AZRTLUQe3T/VUiwKoo+G+glAORsRdL71UZGSEiqDSwsOcA7NOfJgaKS4kBM2Ub92kNdI
2GiZAxofeRCEYMKSAzxMh//pigO+byAJHMbqhXAJ1qK92bhg/xA0otsxKZtaSqSEc1Rs
S8dk/5hralB+QZekNCiCMfMHjfZPIxOLacH+CYzV4uILlkMrARMlZv9ailY6QBfdKYZn
iEsyKorF/rWjNdJeIvJYSt83EDCVmELikKGCeJLXJXXbSImoY4o7YF05QKOJQBfPdPlT
LUU7K3Xi0S0qB+hM0awjZpe7WorRURpeo54bREhSOx8X7G9VQKMPpu9FbU0eLVJYsL9F
LFzXy7p36kwCo1NXd67s72wmL8bWGf05dGv4En4jPsFvBsJcUPObmrxocApk0pi5aT5f
jdVSI6BoEthEtwlW+pC76wWxrrkLOr3SxscRMsydYz2SyIMDFSl10o/0BiZLBVIXoNH8
WlsmpXa0S6gcHhNTgXyo4t9bg4NU7lc9s3i0To/Kyw6q4z+gdQbgdIE0DAhDJIhSTvoL
pE76kFALNZJ2mD1opDeUOZ11sa9uZkAJZCwUB7yuIRF9MeRomqTULDX5fCPvLLdu1QEU
6Fie8gpk21IghNSV6XYNBcKQZCmI7p0JVBjEJDkeC1eQgXJFNZSYWQ4NAwJJCpZLWbUk
Cbw7ORb/93MkKVq34EVCkZIuOZYAjVk0giFYnovrT5eO4f8YjTqlYyiTmg9Lk9pXr2ST
Op8xqU3K9ye1SeDSpHaBLExqgAyfmNQuUrZzpew8qV0gx7qUlUntAqkPYpNafaOplJm8
mXIq9KV4FyR6dc7quUuPpQx8AOMeP+i5mdSQ1AhhXSC7ZlJz4Ekx6OKAupfHcReTuBub
ec95qSNldn5xQFvKbN55cAfcz817URvHTVdNc5hrSIfEHLBuqpDCqBa4lE1bykC9KZHo
XprVslpKmeYwBlyZ5X1Tp4LDOSH1HU2wiEyIqKGbIzgGRDWwKx/mZjkDylvM38y4Bl4E
5fVFyl0DgYswxVoeLVUnybROe5XmrXKGOPRP5ZvI/RrbJDTtjME3nSdoUNSmZBqt+iVz
+A3qzCxkizrGGaZOKZl/2+9/EauTOD7fvX467O92m4ejWD2+F8f97vm03T8exf3+IDar
9U/fakNonfojbQgndYoR/9H0HScJ0xS61Av6JR1+u/WGL2iT47JiRl3xDUxncg2a0eXY
DAUOLVslU0xX1/q8q8GQbyd5zUyQ9zDeeD0WAzW72st7GGeSKhZqOlNe3HuUV1Mgm6oc
eY0Lm0BUIE0jxdhAcSR5F8ixbscYGxyICNOlmQnAFK3JFHBW3eFlbHBJsRBt2nGeCWwy
mklpeu042Rnv+vaPHh07+TzC99RN5PMeILnigMdmbEAhx+yh+6ZLSeU9ADF1f7xpRguQ
JlLWt+YV1ep0Rt+pHxPhTtzTYm4ocIrVo5oEDiPj94pYYK5m16I2FMSHpgdiVDrz0Z79
x06qlGb3Wbdb0SSNDbHYv7mQVRoX4la5m+ukVhniEVWZ34HrmHE+7KUROZ03PtG2kKGU
eYXBWUWeabWU5GVy3s6H7nDZigbl44IX81Y0usQc/abdipJURH5YkJLAU7xldnlq16Kg
+96n4oDGjcGD7lNiN/pPuxYF3feWWbd+3aFoQPcp2AXTjczXzwT3UBanSEbebFsmORJf
ima+uoyrvTzlK82L4bFdeSLPvA/9AqRVRMGkPA9MSf/qqzXPir8Zq3r8bfh9mNDn0smx
OE3qlP759+fdafu024iH7Wn7YZUZmzieDqvT5sN2c/xWlE1r+iNRtkmdYre3/UfdF3Qz
HY5raaPzO0YX4saPFuTnBUDmV5oou1bH3AMuUtZzBAcdv2jerDTHvbS2uQRdINs5EhTG
d8cL5Nf6UbcsRi+QTX8xeoHUK02P3umQ2UyXOu+9Jxn9OLZdIHXFnBajxQF19wwubxGZ
Q5s9TN4UaFIvkNm+lzcFoIZJ96Uko3LDip4bt14DgBvS+TMnk4sqKZFwEPnUumjgmwJH
lunS8IFp6dmxSt5oEiynfV8VIg2GSTr1owUECOTFO1vM30zw+RM4GCGZnx9bfpNXHyr1
7T9+RgfUnFmu2SYYQj47Qzws6zfd7MbEXfSxJTgB1IRY5D43b7poalpx+zd2sdmNzod5
dc9vumRkiN72swiTt5JkdD9DyCsPywVWf1raofNY016nAGIeavSU8UN7TND+/PGgvq75
E0QoCtWFB04oMN96Z4Lo64oiKOP4/t9WuZedcgyYkh0P7SbiErRVjtenxzr682ttcsH2
o1/nLAsqxH7EIbID/MOtv295ScxP1Mz+u+YRlUhC54Xoz5+3AjHnPaR984UXfeK1sv5I
yfgUCxbLbvS+eYqN6DPJ+9ZH04NuXlN4G1O/n+k8apj8scXZcBkub7HB2tSPKG2zG8dZ
u6tubmgpGVZ+7tqHVnD35JdMhzjA9PoSUsNcb9V5ZHeRx8svX+1BJdO5obBLfH3ZdvB3
flC5YpdDUYcttjab92L7eNoc9k+bw+oOPHP7ALb5sHk8rc7bwe2jWO+2+Pllbbg5/Lo5
cOL5P4VWLfkKZW5kc3RyZWFtCmVuZG9iagoxOCAwIG9iagoyNjU1CmVuZG9iagoxNSAw
IG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDEwIDAgUiAvUmVzb3VyY2VzIDE3IDAg
UiAvQ29udGVudHMgMTYgMCBSIC9NZWRpYUJveApbMCAwIDc5MiA2MTJdID4+CmVuZG9i
agoxNyAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VD
IC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxCjUgMCBSID4+IC9Gb250IDw8IC9G
My4wIDIxIDAgUiAvRjEuMCA2IDAgUiAvRjIuMCA5IDAgUiA+PiAvWE9iamVjdAo8PCAv
SW0yIDE5IDAgUiA+PiA+PgplbmRvYmoKMTkgMCBvYmoKPDwgL0xlbmd0aCAyMCAwIFIg
L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNTYgL0hlaWdodAox
IC9Db2xvclNwYWNlIDUgMCBSIC9TTWFzayAyMiAwIFIgL0JpdHNQZXJDb21wb25lbnQg
OCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNptwnsw0wEAAOD+6667ruu6
urq6uurKmzzzCHkkeYQiHKJwJFE4kiSKoiiSSPz2ftjGvIZhnvMY857ZZmNs89pmNo95
lH64K9313XdABTioAhxSBQ6rAUfUgKPqwDEN4LgmcEILclILckobcloHcuYK5Kwu5Jwe
5Lwe9II+9KIB9JIh9LIRVOUqVNUYpm4C0zCFaZrBtM3gOtfgV8zhuhZwfUu4wXWEoRXC
yBphbIMwsUWa3kCa2SHN7VEWt1CWDigrR5S1E9rGGW17G23ngrnpirF3wzjcwTq6Y508
sM73Slw8S1y9cG7euLs+OHdfvIcf3vM+wcuf4B1A8HlY6htY6hdU5h9cFhBCfBBKDHxE
DAorDw4vD3lSERpRERZZ+fhZZXhUVUR0VWRM9dPY6qg4UvRzUkx8TWxCTdzL2vjEuhdJ
dQmvyYnJ5Fcp9Ulv65NTG1LSGt68b0xNp6RlUN59aErPbMrIav74qSUzuyUrp/Xzl9bs
3LacvPbcb+1f86l5BdT8wo6CH53fizoLi7uKIF3F0G4ARoPCaTBkDxzVi0D3ojB0dAkd
g+vD4vtxhH586QCBOFhaPkisGCqvHKqoGq6sHqkijZBqGTV1o7Xk0bp6JrmBWd841kBh
UZpYTc3s5hZ2SxuntZ3TRh1v7+BSO7kdXbzObl4XbaK7Z4LWO9lD5/f28el9U339U/0D
0wOD04NDgqFhwfCIcIQhZIyKGEzRKHOGOTYzxpplsWfZnDkOeHx+nDvP5S3wJnZOTIon
+WI+X8KfkkxNS6cFUgFYuCgULopEMtGMbAY8uzQ7tzQHnpfPgxfkCwsKsVghligkkmWJ
dFkKXlxZ3C2TrYKXlnbL1+RgxZpip1KxrFwGryhXVtZ3rq6v7l3bWNur3FDu3ASvr/+9
sQHe2ru5uf/Pra1/7vPrz//a3t7+DRIZG3EKZW5kc3RyZWFtCmVuZG9iagoyMCAwIG9i
ago3MDcKZW5kb2JqCjIyIDAgb2JqCjw8IC9MZW5ndGggMjMgMCBSIC9UeXBlIC9YT2Jq
ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjU2IC9IZWlnaHQKMSAvQ29sb3JTcGFj
ZSAvRGV2aWNlR3JheSAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVj
b2RlCj4+CnN0cmVhbQp42vv/f2QDAAgA/wEKZW5kc3RyZWFtCmVuZG9iagoyMyAwIG9i
agoxMgplbmRvYmoKMjUgMCBvYmoKPDwgL0xlbmd0aCAyNyAwIFIgL0ZpbHRlciAvRmxh
dGVEZWNvZGUgPj4Kc3RyZWFtCnjajZTLbtswEEX3/IpZuguPZ8gZPrZ9orsaFdB1INho
irqJ7RT9/Q4pxxIiOQglgKJweHl1xeERtnCEEO1GsqYJkidQITjt4Af8gc2HM0N/Bm7X
ua+wpoGODV4PtNu/WYuAkNUXYc72GH2og1DVjzb2obTmqJHPwypNg3KB/gDvO9BG1I6V
BbwydAfYfGa0N9DtYRXeQfcLPnVue8NdKFjF5erx2+7U7x6f/t79htO9TdEYkMxCbkut
BSkN7iRj4jZVsmLORFJtbb4eAnx8gO3bo3WXaCWheltQUJoaobS1VGA9PGeSVKffztrN
s64RU2v+ZcTwasTOIuYQGlT7LJYxBxlC9teQv7eQp2QJHkvgK+5WjzOGiQVDspWeNVd3
C1DOFkrOo9JhDnlKSNmHUQkWIBFkH/2o1M2h4BU1UR6VTgtQSiiaJ1+3YFyUMTJPPO0X
oGL/j/2UcS8Z+6koZnyE7udC2ixFHaF+rhSrJSryakzRAo8aJr6/zJVS8RjiFFqIybYL
eqU0Qg9zpWKBx6ITpX8zJU++oNAUepop2R4ImGslXKGfl+K/1KLtpba3GYp9otj5lVs5
BqvkVlzu5hkgw0FzJRe1huKXVvxu+x/1eR8eCmVuZHN0cmVhbQplbmRvYmoKMjcgMCBv
YmoKNDY3CmVuZG9iagoyNCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDEwIDAg
UiAvUmVzb3VyY2VzIDI2IDAgUiAvQ29udGVudHMgMjUgMCBSIC9NZWRpYUJveApbMCAw
IDc5MiA2MTJdID4+CmVuZG9iagoyNiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1Rl
eHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxCjUg
MCBSID4+IC9Gb250IDw8IC9GMS4wIDYgMCBSIC9GMi4wIDkgMCBSID4+IC9YT2JqZWN0
IDw8IC9JbTMgMjggMCBSCi9JbTQgMzAgMCBSID4+ID4+CmVuZG9iagoyOCAwIG9iago8
PCAvTGVuZ3RoIDI5IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp
ZHRoIDI1NiAvSGVpZ2h0CjEgL0NvbG9yU3BhY2UgNSAwIFIgL1NNYXNrIDMyIDAgUiAv
Qml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4
2m3CezDTAQAA4P7rrruu67q6urq66sqbPPMIeSR5hCIconAkUTiSJIqiKJJI/PZ+2Ma8
hmGe8xjzntlmY2zz2mY2j3mUfrgr3fXdd0AFOKgCHFIFDqsBR9SAo+rAMQ3guCZwQgty
UgtyShtyWgdy5grkrC7knB7kvB70gj70ogH0kiH0shFU5SpU1RimbgLTMIVpmsG0zeA6
1+BXzOG6FnB9S7jBdYShFcLIGmFsgzCxRZreQJrZIc3tURa3UJYOKCtHlLUT2sYZbXsb
beeCuemKsXfDONzBOrpjnTywzvdKXDxLXL1wbt64uz44d1+8hx/e8z7By5/gHUDweVjq
G1jqF1TmH1wWEEJ8EEoMfEQMCisPDi8PeVIRGlERFln5+FlleFRVRHRVZEz109jqqDhS
9HNSTHxNbEJN3Mva+MS6F0l1Ca/JicnkVyn1SW/rk1MbUtIa3rxvTE2npGVQ3n1oSs9s
yshq/vipJTO7JSun9fOX1uzctpy89txv7V/zqXkF1PzCjoIfnd+LOguLu4ogXcXQbgBG
g8JpMGQPHNWLQPeiMHR0CR2D68Pi+3GEfnzpAIE4WFo+SKwYKq8cqqgarqweqSKNkGoZ
NXWjteTRunomuYFZ3zjWQGFRmlhNzezmFnZLG6e1ndNGHW/v4FI7uR1dvM5uXhdtortn
gtY72UPn9/bx6X1Tff1T/QPTA4PTg0OCoWHB8IhwhCFkjIoYTNEoc4Y5NjPGmmWxZ9mc
OQ54fH6cO8/lLfAmdk5Miif5Yj5fwp+STE1LpwVSAVi4KBQuikQy0YxsBjy7NDu3NAee
l8+DF+QLCwqxWCGWKCSSZYl0WQpeXFncLZOtgpeWdsvX5GDFmmKnUrGsXAavKFdW1neu
rq/uXdtY26vcUO7cBK+v/72xAd7au7m5/8+trX/u8+vP/9re3v4NEhkbcQplbmRzdHJl
YW0KZW5kb2JqCjI5IDAgb2JqCjcwNwplbmRvYmoKMzAgMCBvYmoKPDwgL0xlbmd0aCAz
MSAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNzAgL0hl
aWdodAoyNjIgL0NvbG9yU3BhY2UgMzQgMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRz
UGVyQ29tcG9uZW50IDggL0ZpbHRlcgovRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnja7V0J
d6sqEHa5VzxaDz5aQ5Lrwf//Lx8zoIKAS7PZVNuUmgCR8WOYhRmFOA7j+E8df7vj6AZq
/HfQwqDGgY0DGwc2Dmwc2DiwcWDjwMaBjQMbBzb2h42U82xDLxXv/6tJuvEKyirSl1Lv
FBsclFuyupNMCEk7DqMiYgMVa57Cd/H+O/eJDSYE66JsGzYyHI3YQg2sHItYnZGdYiPr
cRF1EWfwRowTJ0qZBADj6rJrOQoOrzoryy6NBJEFEaVqAkccs66ElhnXZx2LZLsYTnld
ElFnQA2ok2alBEpd62+sOYvSnfANAeDAQh4l3HYhJGXwlAh9/4noUomHDN9Rk6vSTZAc
KTaOgLJEpOqsw/YwnTLBVdVYfQmcdaVqrqeq2AnfqOWlyPsHI4lhNBFj6lpZgQPnaqLL
oQqJiUx+0KWyTcnkuKN+tghFLRiUKuBMtshk1Vj2G8nzKMMvkD0yJJsiWCa/LY03MK4H
rymsAnLIK8aRSKiX8toy/dIzvRYRl1gnarRdiVcvh6E5qRxRJO87zJ1a1EyQGM6wyxTf
ZlgZ34EeS002nGzyy8tXUuOvu06oYaubKnBOiK7o34a2nMSEE6IGobgoUEJhI9Ool0Dg
gvVnqi0BaugFKEKgxIpZKYqU6vyFM+U/5nwyUAPxa2JDSQhy/ssbCGKCogbRy4TCRn9v
JSrkf/2ZokYsMphtw5oyjF5jI94VNgQvYdpGOFtIB2wRR2RjQ84TFgHicRDwSWpgA+dB
lsHoFMHwLMK2TBFRVmbYW2RjA/hGyV+KDVM81AtDrEuOK4HEvMJGLy/ViisqHAGf0DDS
Elik14Uaq+gz3VYtGLByZPAOvAxsZFvFvztS42/897/473kiJYJwIAGr5Q2eZSXwUnyl
mZYEpODBUBDJkG3yOJWfSRFDC2AsVpIJCqn6TLdlhKivqRnLUvUuvmTTUnbRpWn5EmzI
Swt9OIiJdz4YS6VoMivcpjhNX0GN4MEfdEGDgBYkF06rdF/UqAv2GGygkD5bQ03VXVHj
F9o3Dhoc1Dio8QJq1Om295XhUf7Wu6UGqB9rWDrKXpEt04NYRUb76vBBOXcVccf5bqmx
FjCiBg3GbSlGsvb/kTkLoaT8jqmBhu+04lJjKAmIYLwWdazgwoX8lBHUY6XOkkXRYBIB
FQWETKlikC4lhEnpmsSqB1Eo1UabCfsOZSvSVVLQ2jE1lFQM6qiUogHkJO7ARoGGDzkk
sOimWEPqaXpKyRENQEElDn5T+E/1gPqMJF/Vzw3VIfYtNZgdUwNEYxyTHEPK5R8wcMBY
kFSVHBNhim+wlDAkHROong3UiAAPqonqAbDBeRZLXTirO1LoT1lMpA6b7ZoaUm/CkYks
EwVgBGBSCMUna1TT9QQhjLCqBLcSzv2BGjA6khVoBoIeEBsV4VJr5VBPd8hEVP0EasSI
DZgABMeib3RJNGsUGkTyH1TcoXY5UgOoo5qoHlAHi7nBVPFTjqvJvqkhOAdgkKqSTLMC
M/iADTkvJIskFVHzv5IzvhJa4SXDmiKby1cNtXmEPVQIJtG36zvMZE8EyFkLvltslCXe
YfibMiUegR0G0ZANFZCn6rflB6k+t96u+39S5WTRleWZ6jBN9WdtuuOZskHq+B2SeXxQ
49DajuOgxkGNgxoHNQ5qHNQ4qHFQ46DGQY3HHwwMKYxHBzWAGKKGnX01qQ5qdMqmHfOA
ucJLjbrO6vHlPbLx7/Bn+rr5MHu+wy+Ol4sYbbTeHeBeasRRDL/65fuJ3b+6wXy7bT9O
z5t/L1d56B6AVZTK1lsGvF1vPlMSSYyLcY5W6wKxUf4+auQTajDERrSJb7wvNmCPK0fu
EXUHNiTnQNN9zX6VvJFfLpfEg43fKYvCYpL4sPFrqZEf2DiwcWAjyD6TPEkPbOgDRPHz
gQ2DGl8HNgxqfBjYoAc2DmwEsPHLqHEm16sRAUd+NzbOgIYDG/r4cqmBKyxV2KC/Hhu/
WN7wUKPo+Qb7tTPlIo+PKTZ+HRf90NTQgoZBjeSXclEyLCaMjFzUh40KUhyMyWd+AzaK
MDZwuAxyArw/NZb5htoSH2/xIMQ7P/JGF3kTxbFyp02KEwgaeQxEOelWGEYoIMJqm68t
qzP4fdZr8rv4ghGfVHHN6giLLIMiqnVRnIAo9T+sWshW8IOCO+sE2+aH3bt5S8E/V1Pk
05gpn0PR6ynUXVNECZnFCPvp1IgtJ0miyKClr34xWZZFMdyI/XwuarPGfKQG3GhNBmLJ
Gy4XxcQxGLf5DtRwsFEYM+X8K/QUOTaSz2DjOioopg7L3lMy16AYsEFdvtENfIMSWTRv
bBfVoPBiozAk82W+8Y7YGPgGMWcKgkKCYdRT2LvyDS826IRvnN9bh9VGiyA2fHzjSt7V
vmF4R0xsUIdvsJFv0CtyUVxTgGLNW1EjjA1q8w17hX0jbJgmnK/5NeUX8I3SNlps4huU
zNi+fiQ1JkNclDccPaV5J2x82SJVQBalPnnjDfnGxNg5K28Q6uUbb7SmfH2XbzDye7EB
DONsyxu6aOgb8Y2z5SRZhQ2DGsWPx4a+bs0+v+bXFC2L0gk1yJm9ibyhr1sLGh/2DV+P
Dck3frS88XmWx3DdZ69Ba5ZvkB5G1OQbQDjmwwYkl6p2axc9jXf6MkyRry3YoKZocl2w
9kQEI5j2ajO/jHf6MkyRD4NvfASxMeUb13IoDCuxJW8gFSAadj01qiccvLpW1ysUcFTV
SRVVsGhUcZJVqaTDihYnVVD9jZiUidRpjH629Z7H9CkHglkVDWvBgfinTdFzmPZFi17F
tFVVVdG2iA3W4kzBFlQWWPWrVAVUpVAVJ1XbtrKrtO1gqwIknUPPY7GvmWLAf+QbBhed
6Cm5CX/aKMmcLPjapnyDEHgCAzz3ajeeR9jg+WWxxktoTSE+Lpo7K6ypw9IFHVZig8Hz
G/bCRd0bPmJD+wMKd03Jp5vHHWuP1mHpvF00jiGl4wv39rCv8/kLdDFV2FvBg9gwZorW
OoZNoKMHgQV0WENP2ZsO++VuRvpY5hvGDbew0TtJFDaYzTd+gA7r2Zq1lW/QifTV2Hxj
Dhu7ocY5T/J/oyWLjFuzPmb5BuvF7euyJdDRYXerp9gCpoMN2jODy6CYnr0LRWNgg1me
Rzalhrum7IZv2MqHuW1vNd+YYiMJYAMZhuFPodcfgg1XiLD5BhlY46RqYykfPd8gPr5x
oiEd9uXYmFiy5uSNRY3ewoaSRalX3qAk2Sc2zDvtbPedYINQH9+gQ9V8wRJInJ1OP4Bv
jGx/o7yRLK0pdLe7WcJrisk3hjWlGUAxETD18tM42Oht5swnb+xmFxwIGskiNhb5BiOL
a0ovmmiDKNvjTifDPHWxLVnFAt/w6ymjvJH7ZNEBRmzCd/eBjcS54cQ0a3uxAYTr7/QN
fMPySu8MG9aa4jXkeuQN5pO+kikz8Mui1x2uKYmjfPgdx0trCtkmi5r+lB+BjcLaqKbX
lMbhG8Ryri7JG+6asjO+Qd0bPjFBNNM1hTYGNqhHT2lm1pTJ/o1mv2tK6PZRvyzqMgMX
G816vjHJ95WOf/fFN/QNp+Oa4uMbxZY1ZUneEBwfk/XcXHBBvuG60WfkDeaB0Rq+Ucyu
KWJjnsBb/UYfvVdHFeU/5Sv6hPv2L01hhv8rwVdEc+UyuqQpXreu2hdQVbbAqtfc9i6l
WIxVVeel2WKoqo5WDS4T8ECgDTkkb/crgv/rOhSDO9A+k6cnfFP7EWnYjyjraD/iWLVZ
8jwavQ6eR/X89CfnF7X5RigQD00QFwXmaKgKRovSbgF1Io+PHqrORvn5VljRPTvmMfcJ
mBPTpbZyNnTZ89jQoao/rs21i4YtgaSM4+fmF018AmbndZUOGr0tb5iK6WRN0aKJsydw
6mvzYaPKIiG7rQl/3Zoy5w6bSOZa3rBb2PLGdG9PqHMPNlgEUeNd+tx85olPiND3zXPD
9diaBZt548QgLMkbyd70lCbkDjMU0yUPwhQbdJVGnw8Wtd3ZN6RGMeEbjaXDLvANavMN
1/PIpjEIe8QGDfMNW4dNHD3F8rWZ9g13L3FQ7M93avu6Lti+8llfG7XXFOrlGx676D7i
YY2p7bVvKFWCTvhGY9k3/DskXXnDv6bsEhvUGCILyBuz2DCXn2ZIW6Xljfl9X3tcUy7a
kuW6PCwf/TzfsO0bhIZzLMzLG/vgG9S7Ffy6Yk0J20VD+8wNMyNLfprNvLHXlID0RV2b
OfCmyZqCTImavjayAy7KRruoccM7fd++zTd82GDjrnuX1GyvfEOPbVZPCfphNYs5TbAx
xNGTH7OmXMIhJBMd1jChhvcSJ4O8b8QgXNkP4xtBm3mz0rvk2EVDsijt9/bsyQ+rRIJN
8sZKHTYPxTySFfEpu1pTDJv5orwxLhReX5sRn6LM63R3fth/eZKfzTXF9aeE7RvTmcK6
ZXljsrW05xv78LW5qsTlW/YN796eDXxjH35Y16zddPNK9wLfcPWUcU2h/twsc3yDcS7Z
efskS6AfG/pOk/V20YntK4SNYL6vwL4vJrIY0uJlz7EST83adOpP8dk36Lhj4XP9/g29
ppTBjUMebDAGvoNvPNnwW78ZhN79qes/mPSy5qpQSS+HbJc69yWkAM1VC1knH6pSnSaT
jC0oUENV5f/qeOz8OrRQVYfEmnZVfDqididVpCPlFs9jhNlJv/UXrqKJIznD6SmOgfud
4tzMhJpDQa88wqoX2YJi1QbzovZVYaQUWlBsgblT477FZez8anf+R7UYO8dsq/2TERUx
hPKzPcXX5gbwqoWC9mAuB+eg5huOLEpV0lBqBLn2VaknOnhS1e7ckTcqjAyBCNDyJVy0
cbhAyC5KmxUxCLm7z9wSdMmKvMRR9STPo2vkd7W2KzXXFFfemMiitnndjRwnM5HjzlMv
BedqN0v9khXWK2/4ddhVftgQNtwYBC82iqwAOjz6yYaQw+4zxDeUEOH3w06wQWjY12Yz
g2TF7tlXyaJXX475fGr7mro8tumws3Ftu4p5tAMZvXyDrfHRj0k1iNcPmzh7icM5nZ6o
w5r2SCfI1b+mBPjGEBXv2y86ZTG5s190qhLSV+SQNK+i9GFjwjc6b+jZAt8gjpnMjnkM
842Hx7W15/NZMkoIAD876VOC2LiEpzbdzDfMYLXct/wYnT84rg1ViSHW9zwX5DrnlfbH
Lnn4xlw87Jq9xI/FRm5FIp3nglxDfIOu9qfQW2OlH803EitK7SscyMima4rL9gtDT6Fu
VU8EaGIl/7vY8bBsBhvNs7Dhe6bNdCt4MAZhhbzByBo9hb5E3vBjww1kzL2RXGzdnkCv
nmLAaK0s+vAcC3byuvAzbZKN8oZn40sxk38jyDeem1/UxkZow44PGwbfKBZ8bXN6il8W
DRjk6aOw8XH++GLT2/cVjNhO1sobG/Zv0BA2tD+FmZ0/NoekfcPPbrq28zLf8KmZNCxv
TONhZ9aUcOePWVPsG154n8bgjScL7Z5dt5eYbeQbT5I3vNjwBTIyT+hZ2A9Lt/ra3DXF
lkWfk1/UxoZ/U8Ec3yjmTJd2BGjxXfsG8ypBz8GGox+wRXmjs0Ld7YQrK+WNYLZV34bD
ADZScLLVtzzZcAPfcNOnNAtplwx5w7umLPCNafqnBb4RwYBbcsuTDRf5hjevp39NMVwe
inCnebsondrM3ZxO1NO5XdWgBrgOIEaFrKaG8RDBJo8HH9dJPybQfZTgn6Gwq6oi54Gq
FOtQXRXP/oCT0Wmh/XFu51S2WHEdyhc4eFS2+dqGZwji8wGHQjlXM/0oQe1cLUznqqqa
15l+oqB2g0bUePjgUGBVVciqnBqda+eqr2r8T7lssXM6XIev86GqerBhNlCDZN+KebR9
45HpRmefBi//HH2E5lZwpvd9fbqex9IUMPsotQY97lYgIx16NfdvQK8scZ9saM9Y/woL
1KhVsuZvUCOZWVOMIRqBjGFLIPWka9PyBjBcNxfcyj2BWNXpPB9484QaBelS0t2Ijdnt
vldfXMjKvT3u9sGzgQ0ndimfiWtbkr5SAeHBFRFpdydseNVMbxxq7vW1EZ8fNp+NefTl
ZvHHpyzHw26XvoZ1ni5hYzaezMm/4XGV4m6MabjCJMh1RQwCC8TD3mPXvZsCNPdtBSfd
fDxZ7ttZ7ddTPDkWmGv7Mq8jX5Hv6z7YmMvdeJ7Le9FY+7sTn+0rlNNpdv/GWr7xkHjY
6wwvPy89C8ue2kux0ie6OjfLiS7sCXxQDMIcNooV8evGls6LGbLqSSt9sbYPbotPmdu/
cWdsfPn28DYTeYOtwoaxNevsS0Tt8g29CgXljSb0TK4p/7pHrLSbHjYJm7VdvmHevjV8
IyxvrI5r8zhr7hafQkJrSlDe2M43TnPyhn9vz6p95ibfuE9c2wpsLO3v7kNWZ+JTTPtG
snJP4LIsSu8eu3Sdma+WvMGm+7sDfGNm39d1Xt5Q1taZfeaj3DOxi95/TaFb5I3Cd/su
3lD3wl1TPEwpHA878Twyv332jtgobpQ3mgW+4eaeXYpBcPWUaVXmx+gO5A0njn7Wn5Ks
3BO4TYe9m9Y2K4sG/Z/u7QtmMVrUU7rOY173yqKkm8kF90I9xRUJVuSe3S6LOjkWWEdW
5Qm8jW/4ZFEtbwSZgcs35nRYfw5JO9oppKfQaygl411zVm/ABpnxw2ohojCdgx77xnfl
jYVn6yQP0NqSeV8b8z7d2i9vaLuUN+ZxjX3jErRvBGXRe/joZ/NeeBmdPx9wKI7eyzfu
Iosu8Y2I+DOLLmGDzMmiS3aFDfaN2ZzVZCbX/cQuSlblnhWBOJ01M0Wn5LKZgd5MYzxt
0h+/3qyVNwY95eR0fl1tF/XqKQ42CqKea7iBGinvs3Se1BMFoSDDWUXxDIrrWKgqsg7p
c3/CowjlSTN+KP8aKUBlHXIair7q2CvxVe2vg8A1Eno1O5+0GKpWVdsPjXP12kKNqjUS
yZZtiZlb4b22bKMYzj/hA53StVR/WnhT1ZUFtML/S+xg/FDXgE/KoZC9MvWRqoydf6qu
8L2+aqtq6RpwPfCjvge+Q3+oWrA8auGJhqxKb6KGwU8dH23cPeDY2CtbVy3uQ2AHbNRE
+R238I165hvqh1DjMb3GeiB1O443Zdu56N3u4kt7jV0/PAs8Nfi71IgeQo2H9BplGxvs
9AnsLzoOahzU2EwNRuCBASX+rQjmZ/A+fDjYMREMmt+VIViXs/IqcImtb6RGVXRVhtuC
yojDnsJCVBuoQYouimHjHbnrvcOO49W9QuUYtrDcYabIvuS31hFplarDs03XrdSju85E
oiWTkmy6CsFup0ZFuloKsRkX6jq6TdjQL3FPQUJdDlx0u+Uqap7Gt1IDkpioryfdt7Eh
ePcAashZu+UqBMv4jdTI4INWgHgLM4VspAY8Kbvq+F25hr6c/qavu4qyKiQrJfFt1ODq
W1NJW0kYyGayiRpVDGxnLaJX0ziFLmsky9qrgIsubsVGJWAXYYqLWYSAX01hzXUibHJX
LprizsZKVO2Wq5DUuJlvHNLXQY2DBgc1Dmoc1DiocVDjoMazqJEuSHuRIMrnUkWjsjh1
c0hpXrwFNUSXpnOteAFaCOh2xagsgnXIPIr6vqael1EDR9GClhaBrynKIqVNAyBapb9V
hXy74m3HqjaS6lTVtoTEbcHbKAZcpFDpPbBRQ7QoqSuIpZVkkKPMeB1npBAdQd2egPVD
vi01RJFVckpEUtElUVGITNRgf0sx++97YEOqzEWBKUkJmFf0pgdSRXp4PCoJ3nmeyY9V
DQJwyYACcsakVd/wLdaUkoNNgIB1g/fGXjFE2MpJIIkFeyGygusaAt5FCvCsFUPDn08N
VmVqCkg+WBJcGmI1U2I1Uyo5MQrERt2JUmhsxDxCCvBMIgeNqpt8DrvFRlaVCgHyP1YD
K1WWeDkXShhgweWqghw2lcxWDlv+G8MEamtZyjdrnrK07hh/j5my/ijwMc2HLKp5iHgb
YhyS+UGNgxoHNQ5q3EiN4zCO/wFGUT1BCmVuZHN0cmVhbQplbmRvYmoKMzEgMCBvYmoK
NTk5NgplbmRvYmoKMzIgMCBvYmoKPDwgL0xlbmd0aCAzMyAwIFIgL1R5cGUgL1hPYmpl
Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNTYgL0hlaWdodAoxIC9Db2xvclNwYWNl
IC9EZXZpY2VHcmF5IC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNv
ZGUKPj4Kc3RyZWFtCnja+/9/ZAMACAD/AQplbmRzdHJlYW0KZW5kb2JqCjMzIDAgb2Jq
CjEyCmVuZG9iagozNCAwIG9iagpbIC9JbmRleGVkIDUgMCBSIDI1NSA8OGI4YjhjNzM3
MzczODBhZGI5ZTJlMWUxMzY3ZDkxZjc5OTljYjdiOGI5MmEyYTJhNjc4NzkxMDA1MzZk
YzVjNGM0ZDNkMmQyYzlkY2UxNDg0ODQ4MDA1NzcwMDA0ZTY4OWVhMWEyZWUzMjM3ZjRm
NGY0Y2ZlMmU3YjFjNWNhMmY1YzZhMTQ1ODZkNjE2MjYzYzRkOWRmMjI2OTdkMDA0NDYx
OWFiZWM5ZThlOGU4MDA1YTczMDAwMDAwZmZmZmZmMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwPgpd
CmVuZG9iagozNiAwIG9iago8PCAvTGVuZ3RoIDM4IDAgUiAvRmlsdGVyIC9GbGF0ZURl
Y29kZSA+PgpzdHJlYW0KeNrNXEtzHLcRvuNXzC3yQWM03sgxr6pUkoqdqCoXXZbLpbQx
yZV3SamUX59uzM4AiwYmosyItlyWZLWARj+/bjTm5+HH4edBO/x3lPiP9YNXcrBGDsfd
8K/hfvj+9ycYtqcB0o/Tloitn6hdIn49UYubL15LDnIEq6IBCPhLpzT9RtPqP+PvlY7p
HyET5fxbWlpOK8dhezf87s1gEwX9BBbMoCwMb+6G7/8EI/6f4c3N8Mp8N7z59/DHN+LH
Dnc6jrS4WXj8YXfc7j48PG5uh+Me/4p1epTIQkhbvTaj9BN3Jowe0l81wY4hSGmIre//
fGeHPxyGH79ctOIsWuNHq3BDM5q0mhxN2sua4fX06yCNp7/el7X4OlkPfVmLSdZwFjb9
HI0aFKgwSVst0v7nh83d8PePu+PH/e7TWfINQYi+XeCPL+cMxS2QM28TDf6krB3A+zNf
euHrrTK2z86K6J7KznBmRyR2tCnZqcT09tXj/elwu9/uH3bXw9Xj7U/D7m6zv3373bA/
DZv7YYdyfP3uePi0v383fDgerm53d9+J/3WIL5ap+J+HKGTqfFyRqXgGdkq/X2MnyXRh
J8v0b5vPw/5+e/t4vRs2w81x83j9eLu7fxi2h7sPh3v81TeTnfPp7+FPOij0lyiZ7LSS
30x2mR1jdcFOlt0PiZeCLvrROPTTmfjVsaKwSo9GUhhYSHY1icOQFZALohBE8VBTBDW6
4NTKIg7i6J3ymeI+qbGgSNuYGDPJdbWIlzAq6TFcLSTDmUTMJLSPispmkppbb2CMKtqC
l0NBIoiEDmQhOL7RvEpAXsDrkBXx6qomwY1CdNKJrliCD2P0qlAn34h0GA1mxEX+NxVJ
xEO7aAobZXrGBUang7XloS8VEIMbtZPBZJK7ahWQaRnv+goAiVkP/7TYaFOvAqRH3Reu
ACA1Wl/Ywi1bRIdR+dJcdozE21FjFs7yf1eTKEBn9aWi94xEm9ERRuraPyjrRkz0cW0V
4kWpWAr3Uv6gcSMbo1uRnPYwulL8D7X4ddRjQE9bEYvRcoxWdeQvEomJCFOMa7vItEpE
PBJd6NscQjk3gpF2Rf6WJOdKj2ZntniiiMfK8r+vSRypyIFdkb+zeoSgC5L/1PLHEDYi
y2uW6zFc2qhX5O/RQ3zUeoUVjx6iEcr14w8EaRGreluGy+HJWU98Feyps55UyIDoZL2v
SMLia9mZsl5iZ8p6YmLnDct6GnOASgY+UfO0RxETM04+H1OTxfgCYQow51W2NQn6tHLG
+EzyU53VQI2aEmwmqQO8Q3dEF4gqk9RWRcYrnVb5/K/e16vQoTG+F6vs6qw2bdTnxKPX
Y0aLxXlONQn6iHGYBsRC8lgnLOVRcMoXR2aZ0fkxSiun84jWRlGaMQYgkNgTP6KWEe2t
FNyxzmkuoDVNPn0mqfVMaQ9RUCmXK5bT8EiIkkNbtkvaw/iu2zaXnFpixFQYpvoKwMyI
tWgI0GcXMJNg9JCQFcDCIdCpL6yFZSwgXrTyWQEHnvcoTZiwwq5KacIVJB/roKpIvFar
lRNpCna+tNwTy2qoakona6sgfnReu/ahkwIwnmFu1HFlFYPQREdbkDDpGuIFDTwrgGU1
QxsZqVdEZ2kjpwoP4IkPI5DRYU0BlD4RYRYO+4llNTSpANav2K7DnBWiWvMAyo0Oj77C
i0c1ohZMO3iIKTmqUYFaU4BHNXpdhlRmu4TOo7aFB+y+Phs9sVFVJUcDplcSiuepUJ9U
Ei7s5JLwT73kKGZqZngWHd/H4GFZkKFvS5lCSfJ8JGkGcEvlRPTks/MqrCik4hNdNnOO
VlXlTyrWonUFL3UycWgOHqhWqPe5KAqj0b5/IKzkMKomIDqT7Ov0SVAVtb5yIE9QFfBI
maSu1QJhYgTPURRnrkgIzWoXXZuXREJo1gaCFbP8H1hpScVPqoS7G1GtEEDpcqMqgSJ+
wUCWTZ0n6pQDogt8H8Gz8EzCso2kzKd0ocUPLH/STsapvvwxfVIyL1XEihKgEzmn+/ZP
6hmtUYW58PyJhZg3OoufsaJS3I3Fma9b6dMa8H3zB0Wic6XlXvH0SZjBFpL7zNOnJeSn
+6ZAgRuxn9HtM5/TJwo3mOJE71niI3AiS1vg1WfaSOu+/af0ifBQ9901pU/cDFYUQOkT
IWYhOl59+jheWEtt/lh+edRzGVyYKVBrK5oA3Ftz9qRM7mVBwjorLm3kio02LHtiXAhK
mxVevPWjVOWZmVgwEI7obbAifwwJo1MKVtyVApA2pog/zNECCTeUcmHyjwrzGfp1eehK
AZFOFEqLYoAsouiCjCsKUBh8Rq2hIPlPtYqi6OIw3fQVoCi6eCNtXwGKAHw0MvZDtyIA
j1GsSAAHRuKo9rRQH7oLKcTzXMIgpBAVwtHoHv2m9zrCEc9wCZPFnxDOwk5GOP+ogQd1
Zo0hqzpTs1RelP8zCYMvlnSNETqT/FSTUPqEEL1YSFhtn8v/maRWdlHbI0mzv+tSn0FT
87a7US7/86EvXckTL9IXi7D+OrGioi/OzKAUdf2kK7a5Z+hFYpQKpeAqLxEh7ZNCQ0tD
E3oBLBulD91VEnrxFiBL/3MNTRIr3oa+3Ai9aBPP3DaBVCRWTCwWYWlPomiVV1DKTdSd
c9qIGs0zyQ1bJW0U2JG/7d1S8npKIU/y+me+Ca7qmoWd7PV/6Xv9mZrdMFm6j0Hklxdk
zkg3WTakJtlM8qnuxWEWNob6DHkf7q4IdkPMJPUFB7mrCz74TLJhFQlWYc7o4kCsGec8
tRmoFXG50bethNP1SUNFaDHqBSrhgOu22PnAmpAIIREOQZbee9aEVHSBAYUOWPsQIYxz
iqAFkrRbmQhhsL60hT2wjWKgtmrhehyKEoaJgSrUnuGBpJ2khUzy7gUiCMgYegaha/sU
z8JPY8ylGnxANT59mOQZYVU1+LCwUww+HK72t7sXmG6xZHYNhp4YS8Qv42USjqOmKfIi
Kl4muRR0hi7INNVLZ85f0czNsL3d7+4fTgXn4hvNs6DzmaeK8f82PwUJ5zWYeV/JEUAB
XXP5LMfNx93w8P64w/9+/rA7DYebYbPdHh5RrL99qdEbOQ8E/jpGbxZ2smD/2B29OROz
aF1cMM4kD43RGx2ChkTSbHPYtI8hoDyvcmy1WWWwPpN8YMM3ZqRGkltZBZG/9OkSbCap
y2yPxa+NzharMMhCAyRexYKXXWP4xtPESyZpDd8oDyZbBmuoBBQdgmlwWQEHlt1pFVlu
dMXKA2o/KxeyAhgAoI3AuGKVW1ZBRAxWzqny0I3sDnDWdLstI1Nf2PIz53vK1H+GwqJ4
b5Nu9ULQXItLnym1P0Hq/oHmG0a1wi2kiz+jsvzfvmr1SL0tFXDfv2KcFcAvKtMkyoob
oVix9I1Rl+yy4RuUi4KCZMtbpB6NofS0Ta0Ak64yS7s88ukbGGW6rmiRTNM36VYPfFtH
0ypYY5igXduNztM3WMs4WSjg+ALFAVgdmwET47d9gXQCtohgJT85Uom59YtlnFy1cQdY
xikDXaMRWAdiGZemx3phCFykXraKK17gNRUidOXZtU7vqJcNaxYRpBtVLFyJ92xxH2VK
y7vnbV2FxmkyxdvvXggVRKd+RaBg4eYLxnHPtDyZ0wSgURDm1fjg0nkY150pBG9c4iYW
jdIsa7COI01OBpNyVzHjIMoOBiYs6ZZdGt0JmpsMutjllk0b0dikReeYKYZGuxEUmvZC
8eeagsYdTVRxkdg/e9epyxo/tIAAWn5cJMbQBJ4WHd3l096xRmIYtY86XspUXKZ4yuFZ
c1e8SRjp+iavwRKvpG2MjU2Zngt8Gpf0mYLfgBIEMEaLntSXC9DuaefLTbVIbNO53HTN
s0wUdBNowF2eRVxkdrqURDzT5VSlq0KbKQoEIYrxIoK2F6Z8kbXTlWToegOmdcIyMkuM
w4c0LCVdn1OTgIzKXrnlU0N4WhW7DjVfetpL1xcXd54odPSGbnAAih9opn0Ls3Rth+7S
tx+LZ9URTLXJt236YmJ1rYCaMMO3apAUVlZYaRsyzGxTbtRNkxZFrkdYvFDwPK6wiNIQ
+wabMj0h667NBxnH6N3KLsH4UVqVgyIHCwFLQlUYE7O2CFQR6m4WgUjYJ+bcSFDhW7WU
LqFC8EZ87S0mtyXxC7ghqIDc1DPMv+9eZ5yJG1NamMUV6nChqIdf6f0hOKw3CooaK9Bt
XpALS6ykp+lBl/+YTXDRtLt0JnS3cJTCrVRezBSvG1eXwZKsZooDuwpBWIR+MR9EsF6+
pxvSaKHLKI00aA+2YlSU95Y0AWYLaW1aE1URfF6jHpGhtzo2qkJrO4Yk6KUCgq+F4po1
C2gX6e0iMHZnmap85bPm+Tud9Noh2kVghyZOwEy/rHHFOwXUbjCXplG6N6QhtHyS2xaO
cIW4dnVxdK7/8x5DC0YoimTdo84DxqKnNkQAVKVFx4x8YOPFs7huu9PFXU41IcBYiGMC
K0+7/IJffPdiJFzEl3O0u25PMfsoepYKJh3IZOe/ac4wR+MXse15DwITEbgsFJaqqKDB
giT2zYyGtMDJ2PS684gzzVKDahqaWAaw6N1a11Yd9VxsYSSfeZluqIvXdUugAQtbRBie
2mnEiK5/Znnx90U0YQTFWY/N2SxrfDeOAQUyG4PpmzviZUztnSg1vT+iITGa6bzk42m2
/EufH9F42Cyqp6PAnmuJr2dHx1bqZigQkdfoMy03lBhpngcKQxHVLJrGbKW96WZEhbgL
8VvkjrWMvGH8Hn0oAvyWTZkhPAs2qG58VhA84tkiWdXmqBTQc8PC2O5foFxQdMPbCHpf
Ajef/TaVePHef92XC86iEc/AzXLZLBZusmT+sP+4O552w+nhuHnYvdvvTsP9bne9ux5u
Dkdk4vpxSx8rKD9ssLm//v5wfIHvFlDA9NLWRyi+DHC3O50275DhF2pEUrX662lELtxk
Wf21+wjkTMxfP9JEG2KEeTU+/Li8AJkoeAWZH4DMa9RJ19EbPywjF56npCtazz9mCjb4
mK7faMZvpqhB+fI+ZCZg5QXdjyJuUt1N0icDnIJFXFfsWSR9AcHofBJegNAHECQGqVle
W/amg96XoFq6jKbywtLN6ExxV7ch0xoOQpePc/HgXPOwYp5mNBT1Z4ot/wwA3RBmpRz5
KKMdjTWha19T/eFdW23nPqUbwXtYBLZvVigxQp/R1Mn0Nh9lw7qQ1FSzCrpGOnUyF701
5JUamdH1T5IecUSnu4pNbzgChOyPQ7ONaWTe5dR6wUFXN7O4HnmTkh7oxWxfV80mJb2j
v9hE1F1KXTgTE7lNM/3GNI1jakLiLtGGLHJeNkxfToI+pw7PoqQyomfn4OitoQ+hb6RY
h48YBO0isVPrSaMqDew3vFsHVDn6S+sQF1d3kSrHTPHIQT+1XNuandA4+NF4ZbpOjYje
TKPDXfsJBBi9zB554O08Tc3jfFhW70WNikM8uAiMI1viAxV86W+X2BewOikCVN01nMAv
mMzHdRP80kvTnksqSbuUJnbirzCosWVCl1OFJSHmDVCi59cTPIYiwbG3HpggMZRq1zUx
pYxGiXVljjmauJBcogvQ1xLzW3B9l1QaTTC4IjnVA/n0/J0eIdj+SXSga7RCs6wkMegK
Wvocw+4ZBe1CF9A9K1WGdrGQQcWnmsJqepDofJ9Ta2mSI/jL05YWZj1dPBaB8P0LtKUJ
qlmr6kHHuxYQ8xhAiLg9s24VfflOKjFTXDUeqmCgQteeKfaNdypoiSqeKXgHzKVxdLri
mtdgveA0jQ6YKWeKOha69IUh7aG7xgzF4kJx15oOA4dGNFNsWkgrVa29055bvUYvErtt
Y7HqKPx1rQ6LwNjUd0JR9A2j3mFjQlH0zm6mOLJbZYJRNuY1PraenqBP2OZhz7fKMEpq
ss4UHM7RczMt+5wCpHTrs8BO/M0sWhCKrCsxjJNyDORRs8T4IJfEqK2yZm84FCNDDvqS
or5URufvWynGfUweNLtyIfSLd67pDd+KNNC2MI7ZLFHWXdXppaD3oisNAmPKxSyvJhjD
bJld8jO/MqanY6FvpalDa6PUl7oX1StZ55zvuhPQV27SNEBXYNR/dcE3CSakheAVA4jv
eiSiNUdft8wC43gOD6tUrPU2Be3/AqKCrkkKZW5kc3RyZWFtCmVuZG9iagozOCAwIG9i
ago0NjAxCmVuZG9iagozNSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDEwIDAg
UiAvUmVzb3VyY2VzIDM3IDAgUiAvQ29udGVudHMgMzYgMCBSIC9NZWRpYUJveApbMCAw
IDc5MiA2MTJdID4+CmVuZG9iagozNyAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1Rl
eHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxCjUg
MCBSID4+IC9Gb250IDw8IC9GMy4wIDIxIDAgUiAvRjEuMCA2IDAgUiAvRjIuMCA5IDAg
UiA+PiAvWE9iamVjdAo8PCAvSW01IDM5IDAgUiA+PiA+PgplbmRvYmoKMzkgMCBvYmoK
PDwgL0xlbmd0aCA0MCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X
aWR0aCAyNTYgL0hlaWdodAoxIC9Db2xvclNwYWNlIDUgMCBSIC9TTWFzayA0MSAwIFIg
L0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0K
eNptwnsw0wEAAOD+6667ruu6urq6uurKmzzzCHkkeYQiHKJwJFE4kiSKoiiSSPz2ftjG
vIZhnvMY857ZZmNs89pmNo95lH64K9313XdABTioAhxSBQ6rAUfUgKPqwDEN4LgmcEIL
clILckobcloHcuYK5Kwu5Jwe5Lwe9II+9KIB9JIh9LIRVOUqVNUYpm4C0zCFaZrBtM3g
OtfgV8zhuhZwfUu4wXWEoRXCyBphbIMwsUWa3kCa2SHN7VEWt1CWDigrR5S1E9rGGW17
G23ngrnpirF3wzjcwTq6Y508sM73Slw8S1y9cG7euLs+OHdfvIcf3vM+wcuf4B1A8HlY
6htY6hdU5h9cFhBCfBBKDHxEDAorDw4vD3lSERpRERZZ+fhZZXhUVUR0VWRM9dPY6qg4
UvRzUkx8TWxCTdzL2vjEuhdJdQmvyYnJ5Fcp9Ulv65NTG1LSGt68b0xNp6RlUN59aErP
bMrIav74qSUzuyUrp/Xzl9bs3LacvPbcb+1f86l5BdT8wo6CH53fizoLi7uKIF3F0G4A
RoPCaTBkDxzVi0D3ojB0dAkdg+vD4vtxhH586QCBOFhaPkisGCqvHKqoGq6sHqkijZBq
GTV1o7Xk0bp6JrmBWd841kBhUZpYTc3s5hZ2SxuntZ3TRh1v7+BSO7kdXbzObl4XbaK7
Z4LWO9lD5/f28el9U339U/0D0wOD04NDgqFhwfCIcIQhZIyKGEzRKHOGOTYzxpplsWfZ
nDkOeHx+nDvP5S3wJnZOTIon+WI+X8KfkkxNS6cFUgFYuCgULopEMtGMbAY8uzQ7tzQH
npfPgxfkCwsKsVghligkkmWJdFkKXlxZ3C2TrYKXlnbL1+RgxZpip1KxrFwGryhXVtZ3
rq6v7l3bWNur3FDu3ASvr/+9sQHe2ru5uf/Pra1/7vPrz//a3t7+DRIZG3EKZW5kc3Ry
ZWFtCmVuZG9iago0MCAwIG9iago3MDcKZW5kb2JqCjQxIDAgb2JqCjw8IC9MZW5ndGgg
NDIgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjU2IC9I
ZWlnaHQKMSAvQ29sb3JTcGFjZSAvRGV2aWNlR3JheSAvQml0c1BlckNvbXBvbmVudCA4
IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42vv/f2QDAAgA/wEKZW5kc3Ry
ZWFtCmVuZG9iago0MiAwIG9iagoxMgplbmRvYmoKNDQgMCBvYmoKPDwgL0xlbmd0aCA0
NiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjazVdNb+M2EL3zV8wx
OYThx/Dr2G63wB4KJFgDveTiepWFCttKJKdA++s71BcZyk68i25SO4Ds+Gn4+GaG8/QI
t/AI2tIfF/QyDpwSYFBAW8HvsIfrD52ETQeyf3ebCDZuQNsefDWg2f3ZsQQILo0KKKWn
j1bp+EXH6I/0XenQv5jokdPXGFoMkQNsdvDzCkyPiBdpJIIyElY7uP5VcvoPrO7hwlzC
6k/4uGK3J9jpwGNwnDneVO2mejg8rbfQ1nSLsZoLouD7pa6QCzewQ8+d7G9Fb7j3QmCk
df1pZ+GXBm7Pl5aN0qLjRtGCyLGPJjj2axmEq+GzF+ji7ae1Zt+nNZzWmg1ay1HseA0u
gJLKD2qrWe0P60P1tWnrf9aHutmP0h9Rgp0uDHqfT430ZkTN6x5DF2UMSGdxIKZnYncK
zWk6L2j3rXRgpMN6OhpzOkmnn3ouiTYKwyWlPKEvNjNkCIVGUnFQMR6DjFGC495JpRKk
eQ5hJhatw3yhpyKKCYFbZ71PkH0BsUZw44Kjwp0ghxLiPNdaiCwKFBAnJNW5ouKOEBYh
qxJiFNfe6CzK3yUk0I60CDZBHi7ZM4hH2pHWVLMzpCqi+GA4FbV2CdK9dnJ8X/myZb04
02Pooj3lzppl+Wol3qybEh00OqOTt3nb1lULzUPVUsd3sFvXW+iq9q96U72XbIZ67X8k
20xnKduXhiTbN4dJv+fysddOqbP5shdPKev6++iCgeYP0mA5Ld+Pz2aiY6zK6CT5PvZc
Es4Ky9FSHifweE5lCBqo0tPYnOON51QGsYFOGK8HBVg6GxLE9eug8ylKW0K04ig8iTJD
hkMogzjNpRbevhCFTl7h0GQL1SOEjRAvySIEa7IoXRHFG6TzW4WMS74jFiFBcochDqcJ
AkWUIClbTmJKxcWuhJB0NE+kTQlYFxBJHpEsB9rljhJE0exDa1MCtq9P6rOK7nX/WPSA
nvzjsgfYf9OS39QDM53UAzcne2AEL6rXoqYsKTJ/M6Q90gNkYeMIJQg7VlSxB4gTYorS
lBBqNuUxpnSC7Mse8J42bMeFjlYM+QEuvM4X2pY9QDuywmBK2KJ6vVVcKurKBPlU9oAn
M4xBhQT5XBZ4rEyJIYPcHOsBT1tiJ7kE2jQVuc02vVv0AGlH/gRTApad5OmpwJgsjYtO
olXIxDifS/dW06Sw4Eq/ZMF//DRJdHoLPtNJnfR5YcHJ03olDZvQdIQXEBMNa18PE2R9
zILruJ8IYSnZmb92kgdlKUNzFFhYcGoC5+mRc4ZsCk9rkbiQojZBmtKCBzLP1AQZ3cnI
s8k8UyspLeITQ1qo8NeeKtwZn9HNzTOL5lmTeVYyX6gt/bWlxwEjhVtymSBBBq7ocVym
BHRvNggKLykVvusgKLzkTCeV72/NH/W2gnUHXfPUbipo7qF7WO/g7mLX/3RFj+Ff6z3Z
yy93l292DBQ6Cmnf1VQWOs50junYVpv6oa72h6WUh6rdHZHyX1I3IiwKZW5kc3RyZWFt
CmVuZG9iago0NiAwIG9iagoxMTI2CmVuZG9iago0MyAwIG9iago8PCAvVHlwZSAvUGFn
ZSAvUGFyZW50IDEwIDAgUiAvUmVzb3VyY2VzIDQ1IDAgUiAvQ29udGVudHMgNDQgMCBS
IC9NZWRpYUJveApbMCAwIDc5MiA2MTJdID4+CmVuZG9iago0NSAwIG9iago8PCAvUHJv
Y1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JT
cGFjZSA8PCAvQ3MxCjUgMCBSID4+IC9Gb250IDw8IC9GMy4wIDIxIDAgUiAvRjEuMCA2
IDAgUiAvRjIuMCA5IDAgUiA+PiAvWE9iamVjdAo8PCAvSW02IDQ3IDAgUiA+PiA+Pgpl
bmRvYmoKNDcgMCBvYmoKPDwgL0xlbmd0aCA0OCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1
YnR5cGUgL0ltYWdlIC9XaWR0aCAyNTYgL0hlaWdodAoxIC9Db2xvclNwYWNlIDUgMCBS
IC9TTWFzayA0OSAwIFIgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURl
Y29kZQo+PgpzdHJlYW0KeNptwnsw0wEAAOD+6667ruu6urq6uurKmzzzCHkkeYQiHKJw
JFE4kiSKoiiSSPz2ftjGvIZhnvMY857ZZmNs89pmNo95lH64K9313XdABTioAhxSBQ6r
AUfUgKPqwDEN4LgmcEILclILckobcloHcuYK5Kwu5Jwe5Lwe9II+9KIB9JIh9LIRVOUq
VNUYpm4C0zCFaZrBtM3gOtfgV8zhuhZwfUu4wXWEoRXCyBphbIMwsUWa3kCa2SHN7VEW
t1CWDigrR5S1E9rGGW17G23ngrnpirF3wzjcwTq6Y508sM73Slw8S1y9cG7euLs+OHdf
vIcf3vM+wcuf4B1A8HlY6htY6hdU5h9cFhBCfBBKDHxEDAorDw4vD3lSERpRERZZ+fhZ
ZXhUVUR0VWRM9dPY6qg4UvRzUkx8TWxCTdzL2vjEuhdJdQmvyYnJ5Fcp9Ulv65NTG1LS
Gt68b0xNp6RlUN59aErPbMrIav74qSUzuyUrp/Xzl9bs3LacvPbcb+1f86l5BdT8wo6C
H53fizoLi7uKIF3F0G4ARoPCaTBkDxzVi0D3ojB0dAkdg+vD4vtxhH586QCBOFhaPkis
GCqvHKqoGq6sHqkijZBqGTV1o7Xk0bp6JrmBWd841kBhUZpYTc3s5hZ2SxuntZ3TRh1v
7+BSO7kdXbzObl4XbaK7Z4LWO9lD5/f28el9U339U/0D0wOD04NDgqFhwfCIcIQhZIyK
GEzRKHOGOTYzxpplsWfZnDkOeHx+nDvP5S3wJnZOTIon+WI+X8KfkkxNS6cFUgFYuCgU
LopEMtGMbAY8uzQ7tzQHnpfPgxfkCwsKsVghligkkmWJdFkKXlxZ3C2TrYKXlnbL1+Rg
xZpip1KxrFwGryhXVtZ3rq6v7l3bWNur3FDu3ASvr/+9sQHe2ru5uf/Pra1/7vPrz//a
3t7+DRIZG3EKZW5kc3RyZWFtCmVuZG9iago0OCAwIG9iago3MDcKZW5kb2JqCjQ5IDAg
b2JqCjw8IC9MZW5ndGggNTAgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn
ZSAvV2lkdGggMjU2IC9IZWlnaHQKMSAvQ29sb3JTcGFjZSAvRGV2aWNlR3JheSAvQml0
c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42vv/
f2QDAAgA/wEKZW5kc3RyZWFtCmVuZG9iago1MCAwIG9iagoxMgplbmRvYmoKNTIgMCBv
YmoKPDwgL0xlbmd0aCA1NCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFt
CnjazVvPc1u5Db7zr+AxewhNEvx57W47k8N2vU2mvfQi288bdWRLK8np7H9fgNJ7pMjH
t3Hisetk4jiGQRD4AH4Amd/5r/x3Dg5/C4kf1nOvJbdG8v3A/8Uf+dWPB8VvD1ylX4db
Erb+JO2S8PuTNLv/al2SS6GsjkapgH91GugLIO2/49caYvpgMkmOX5JqedIc+e0D/8sn
bpMEfVJWGa6t4p8e+NXflMB/4Z/u+Tv3A//0H/7XT+zXjnUQBSk3k43Xw/522B2fVhu+
X+OPWAdCogkhLfXeCOlP1pkgvEo/aoIVIUhpyKyrDw+e/7Tlv369a9nZtcYLq3FBI0zS
JoVJa1nD35/+HqTx9ON9X7Nv8zXv+5qdfK3OzqbP1mmulQ4nb+vJ23/fPr7/cbXfr4f9
+192w351HO74z6v15s+iMIsR/LVsJWsRESDJ4CdtLVfe65ONMNn4b23s2ZyZGLHvMKcC
KLswB0xpTnbZP5ItWc5IKxRGP0u/G35glyJWIU4Ql1lkU2vxRjgfVJZYnSXYWcJqTBIN
LmSRY6XEEsK9KU1ZFyKMRLwSUTtbLLSttDitRdARCi2PtYgH4UGrwCaRQyWCYcHE895l
LZ9rES8FJgj6nkRYbW4SiUYoAFlo2fWxsJBSz8XCCE2WzAgdLPA/t6XEJfs+W04uCWcE
sMqWm8p1UUUhoypdN9QizgoDzlnWhVSMgOj2ssDLfysRJW0QactTGOuFlJJGgFXQt0Vh
mRIuulii7jKNlJaYRzH6LMJrLVob4a3WWeShyiOlYxDBhIUMUGAiaikkKucyZSRaayHM
Z1pSYjSIIJ3uJ70yxolog2N9txgMAEijF/ZslRPGusL/t42Iw5yWeskWi2ciHlyu3FHl
fyejUNKrhSg6i5Cy2rW1Y/K/lw6xUBT7BnTKA6Y9wmp+0yyJWC+0DdAWzElLkCAcMoF+
HVPBGmGl8zkAd7VIxPpuZLQLAYg6CHsONCsxNx1tUmqES+gbqyVCTkowffdr6TUyg1LL
ptESLaKlxDav3K+RVgjjZLFQXbq1QkJzidyhcr9GNWiLKny7r7VoA8IGVTjuSyMSkMxp
dFoXUBqwoqKErxfqFl32MmQAiy7zNsngJwjoDOdVw01Ay686A9gLnEcnc8gqY6EwJ58B
P6/+4DcDHx6Pw363Xx8Gvt1zpHWH7SOy4w8fry9sZS9F61ALW6Z1lB3/R7RuMie77peG
1kUR8OSDSfrdU03rnBRe47ezSF3JTMBkw6ZDZ5GbmtdhQwPe+EJLfR7ZiJvznohStuUy
IZ1RxEJNsVBD2iLuNoDO+2+KnTcaGZmTyOtGkbrYeeeQkYUiqE21C4ZicfYzm6t2ITgs
DVKGrKQ+PiP6HykmdlKTyKbyfwQ81IIlbtKzNloEFHq3WOhQn0dUmyGAmnfumeGA0KH0
/019HhHDUSH4vluU8gG1GN/fdGI4BjzrAgoJTiRCZvmCCG46go/Z/80xDZI2BKYPBQWW
NuSgdG7FB8B7AVDu+cscCXLBQLtnVpKgkPqaUWQ1R4JU0DAfaDaSIIDSucMcCXJICvop
opyiMwvUQgAo0wDALizkgsdmLqocgH3DcLA9UjIUm941ItiqSaWKurCvA0AMxxgFC4gK
GlMtwlICBOQVESIs7IiaCYRukQBXdQAi1g6EbgGpD40W7DdsiIUtHxsCg12uIkIwSlw3
Et4hNy8LHW9ZENIK6Xz2f0PIFPbbmPi+DzqtMUSQ+oTsXDZDcVLrn2tUrQXrpbM6tOay
kgVhG6zbEF2wIGyQ3HyIEiNDiiJMLPO1YWRGGWr+++mqjVN40ijLulDQViK4MUT1Oq9B
yCpWgY3G81jFCxOy7P102k3mZFZRpwCWORruUZk6S1/UIFJlqG+3RPBGibqzNy5S16gK
kYYxIHbxHI/YWY4i9aFGkyDv0jExZ8o4CXL4cVqIzR0TNAmyLlLbOGrhDe9wRJOIA40i
D1Ui0SQo4PFYuKWhDMoL5Uo/NycJ8Q5QtlyoTkc8z7D5CVQO58xlZ27itAzFQvu50YqV
xE1GkbnRCkSndA5A05RjcRfeKN/XchqtJBI6BqAp8NjtEUYLLc0hrLTHultCqp5QIjcB
PANkAYa7udFKAPCt6/JoxXjij3rBFh0NHp8qtGGcThLAUJvEGXpgUIBxDDo2YSyynr1U
a1PP1UszCsSWad9OcQB3rf2UJaylHnQnoUEWsDu2gx6i5zIsxNFa7Ca0M33wYoIg7KxT
WWRXx9GZNK6IC1qct4jM4Bbi6CLyXaOKhQ4NxzEGkemWUsBj84NMH3IiXTUcB881Gcqi
2lCPAB6963VOpI+NCPZHQcUCdtcNgTHYzkllS9hVAYhYVm1ZGdpZkLHCmRhbeLNMYJSI
0Xacex7jWKFMWb03NSNAeAqQEvqlWSPhPY/reiFCFuSFj6Hwf0MJNLUKZgFzSHGQhfpz
7WCz1AOwm8PCulBTMX7IQtPdRV6IPWcAv5j17CsH8Il6gFmiHq95bZaOxMmcXIP+2Qw0
JKaaJm53lm7KahpHa+9hUjhzT4WGBKmTxOyBRL2axhLks5K75p6KbnUKN6IlrJl4IPWm
UjeK1NXQKawuoIrdN4QgtWoBqBEbRbYzQxEEJ7Uto0hNyLyh5jPawpa5oQh+T5r+QsRf
tDHBZ/ffN3MTQ1mvTX+hQPzReK+y/w8NOTHYB4COWctTj5xkkZu6jknsp3UslDTjDIkx
gmhi3/9KUTttSuc2Z5rCGOno/bzIabSCfFemRmwUaQ4JhDXaAguYU9SI6egK+LeXR9iI
GbO0Z+IddhRh87MKGhxGOQPLgg1g1TAXWVZ531js9+gZQd9YrP2IOR/aME/ut4A1JHWN
o8iuvfWhOT50Fjod43R3l25pu0F0WLtlut/uwV85bE8jUo/a/d9fu9kzLk/p8mm2WiZE
sVLQYjtt/XxZmIYvYOOsX9jIOtC7SuoF5AaPZNeWxWVf3zXSKDSEslzu2smKFD4E6GpB
EarLdGPfg6WmlAdfIrchA9Jp4ZUryk9zSGNdENKpQstVI4JwwT8Kz32oJytIZAU4V3iu
GRXhSgIJWSFy/WrHb3UzhCz3eTdDL3y9kc1JN0OTORnf50c+fH3gj9sjv1vvh9vj5g++
fvyy3XwZUrVkL8OjnuU5NcOj3tBzqq0M15vV8X67f7i63ayHxyM/fN4+be744Wm32+6P
b4A4ZTG8c5byN/BaGgLOGfNzMqYQdGl8ELKT3w2Hw+q3gX98unlYHw7r7eOrkfkKhHQW
90H4mrFNIJzMyd78afiyvh34br89Yt6iq/j2nt/uhztE5Hq1ObyB52iOMGtrhiF7vZxw
at5xnxsY2kiPZZCHnKXfDZvd/dPm28kI+9aXXNRIRqReGXrsWSPsl6VG1EdO1tR5nEkl
3SEYRTPhs3DbAIKnkbCMk0TFF5mh/kPR0LirY7o3HyV+q3vI8dqcjRI1E6cHTegs/G7H
Dk63fdjQ+rMAa8xwQLNgUH5S0fSPgZ4A543Ur5084EZ0CNldbe+oRBrmd5ZgQWkahxYS
998ID/Y9zw5RZwkP9k0vIF8EqSGDr0Rqfa95fkFgwuS3XdMHS+HAguIdDGGRkI5GrhnL
D3Pzd+ld7AY4PQ3QOhrWQ3sa0ENQoYFR+3ZghCrvPB3Ie2k6AI1tZ3Aur9I0PTpgCJA+
ThLNnQXQdbKtVFwM7+kyWUI/tZH3O2oWJ4H2zQDdJGMzwuYWOc/Kg8Dcz9Wh6fapPDhb
xITNPoi0/bhS7ocYTIONPCUPQCOd/k7TS8dYmLGp4eV1FNYsYIfaUC9VXuRp/pUjdmM9
lJ8fORbI4HNNKB6MdkLXsfMKMnYLoaKnNoBAvlyFXYzG8eh1VvNeXDUGRKSp31wesOn2
XxXwOrb9Jx5QDmJ/FXppHOhutJcp2CbTDDNCt3JoTS9UjVaTx/ZzF//WFzm9nnv96KlX
GyUOlcfStb90MfT3km79VSYSzbsMTf8/wTqf/fGhufTXgQ7KHJem1cbjR4DUGWPXr1b2
L6l6gC5Tf+XulZj6ZE2vz34DJhy1nLPrLXrDaPScKXcVJY/E9SyCcBR+1wwn3qYv9Bfc
/K3bQt8yns5o4mbgt6vd6mYzUJe4W+2P69v1bnVcP/6GLuX3681x2OMXhVv/B4H+z0AK
ZW5kc3RyZWFtCmVuZG9iago1NCAwIG9iagozMTA5CmVuZG9iago1MSAwIG9iago8PCAv
VHlwZSAvUGFnZSAvUGFyZW50IDEwIDAgUiAvUmVzb3VyY2VzIDUzIDAgUiAvQ29udGVu
dHMgNTIgMCBSIC9NZWRpYUJveApbMCAwIDc5MiA2MTJdID4+CmVuZG9iago1MyAwIG9i
ago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkg
XSAvQ29sb3JTcGFjZSA8PCAvQ3MxCjUgMCBSID4+IC9Gb250IDw8IC9GMy4wIDIxIDAg
UiAvRjEuMCA2IDAgUiAvRjIuMCA5IDAgUiA+PiAvWE9iamVjdAo8PCAvSW03IDU1IDAg
UiA+PiA+PgplbmRvYmoKNTUgMCBvYmoKPDwgL0xlbmd0aCA1NiAwIFIgL1R5cGUgL1hP
YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNTYgL0hlaWdodAoxIC9Db2xvclNw
YWNlIDUgMCBSIC9TTWFzayA1NyAwIFIgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVy
IC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNptwnsw0wEAAOD+6667ruu6urq6uurKmzzz
CHkkeYQiHKJwJFE4kiSKoiiSSPz2ftjGvIZhnvMY857ZZmNs89pmNo95lH64K9313XdA
BTioAhxSBQ6rAUfUgKPqwDEN4LgmcEILclILckobcloHcuYK5Kwu5Jwe5Lwe9II+9KIB
9JIh9LIRVOUqVNUYpm4C0zCFaZrBtM3gOtfgV8zhuhZwfUu4wXWEoRXCyBphbIMwsUWa
3kCa2SHN7VEWt1CWDigrR5S1E9rGGW17G23ngrnpirF3wzjcwTq6Y508sM73Slw8S1y9
cG7euLs+OHdfvIcf3vM+wcuf4B1A8HlY6htY6hdU5h9cFhBCfBBKDHxEDAorDw4vD3lS
ERpRERZZ+fhZZXhUVUR0VWRM9dPY6qg4UvRzUkx8TWxCTdzL2vjEuhdJdQmvyYnJ5Fcp
9Ulv65NTG1LSGt68b0xNp6RlUN59aErPbMrIav74qSUzuyUrp/Xzl9bs3LacvPbcb+1f
86l5BdT8wo6CH53fizoLi7uKIF3F0G4ARoPCaTBkDxzVi0D3ojB0dAkdg+vD4vtxhH58
6QCBOFhaPkisGCqvHKqoGq6sHqkijZBqGTV1o7Xk0bp6JrmBWd841kBhUZpYTc3s5hZ2
SxuntZ3TRh1v7+BSO7kdXbzObl4XbaK7Z4LWO9lD5/f28el9U339U/0D0wOD04NDgqFh
wfCIcIQhZIyKGEzRKHOGOTYzxpplsWfZnDkOeHx+nDvP5S3wJnZOTIon+WI+X8KfkkxN
S6cFUgFYuCgULopEMtGMbAY8uzQ7tzQHnpfPgxfkCwsKsVghligkkmWJdFkKXlxZ3C2T
rYKXlnbL1+RgxZpip1KxrFwGryhXVtZ3rq6v7l3bWNur3FDu3ASvr/+9sQHe2ru5uf/P
ra1/7vPrz//a3t7+DRIZG3EKZW5kc3RyZWFtCmVuZG9iago1NiAwIG9iago3MDcKZW5k
b2JqCjU3IDAgb2JqCjw8IC9MZW5ndGggNTggMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0
eXBlIC9JbWFnZSAvV2lkdGggMjU2IC9IZWlnaHQKMSAvQ29sb3JTcGFjZSAvRGV2aWNl
R3JheSAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0
cmVhbQp42vv/f2QDAAgA/wEKZW5kc3RyZWFtCmVuZG9iago1OCAwIG9iagoxMgplbmRv
YmoKNjAgMCBvYmoKPDwgL0xlbmd0aCA2MiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg
Pj4Kc3RyZWFtCnjazVtNkxy3kb3jV9SROqgEJBJfx115HeGDw5JN2xddhjM9VDuGM8Pu
Hm/sv9+X6K4qFFBokSJjaMqO0diPiUR+vgRQH4efh4+D9fjPqPHHhSGQHhzr4bAb/jk8
Dj/8eDTD7XEw+Z/jrYBdOKN9Bn9/Rqv7T5alBz0aR4mNifhXT1Z+sSL9I34nm/IfpTNy
+lVE67PkNNx+GP777eAyQn4YZ3ggZ4a3H4Yf/mhG/C/D2/vhTfhuePuv4X/eqp872tk0
inCedfxpd7jdPZ9ebh6Gwx5/xXk7aqgQ81Lf86jDWTuOYzD5r3J0Y4xas6j1w58+xOEP
T8PPn25adTEth9ERFuSRszQ9cl7L8fD9+d+j5iB/vW9r9ftsPfRtrc62Nhdjy89g7UCG
4tnaNFv7x5vDYb87fP+X593h5rS7G/58s3+4eEAMoj45PvDPdQ1VGw3RZgx+kHODCZ7P
+tlZv1+IXaFOZUL1BepUwalW6lgu1VnM9desy4Jj7UYDzy/oN7vv1BriDGIEMblAHmop
gUcfolkQNxeEuiAcIUHI+rhATpUQJ9EduFRlX0CUQIIZE3lXLPRUSfFEY6RkCymPNSTY
MVgyUc2QYwWBW5B0IfhFyq81JOgRyQHbC0TV6mZI4tFYqwspz/1YuJJOnxsLU2iqrEbs
xMLw27qUcam+TJezSeIlAlSly7vKdMmkUSdTmm5XQ7wb2XrvVDekUrKI7qCLePnfCmK0
i2Pe8uzGeiFjNI/WGdvXxaBEjT75VEbdOo0MaeRRSmGBDLUUIh6DI1ogH6o8MpTiGDle
yQBjOUFKgaiMqwxraOts3M60LITJjlF76ie9YfZjctGrvlkYDrCa6cqenfEjO1/Y/7aB
eOS0pmu6OPRDNC1f7qiyv9dpNDqYK170DiHlyLe1Y7Z/0B6xUBT7JuhMsEh7hNX2plWG
uDCSi7YtmLOUqO3owQL6dcxEx6PTPiwOuKshCfWddXJXHJAoju7i6G37J5T3pMtiWGtL
GvWdnC1cdKjsT9phQyjNJaSWEv1oDG10gMn+ZODFdQeovUgGXvRGx3qhVyYEJsbNsvuL
pYYRqK+izwaFKvQhYzb1qXsfEYITxWEOTtXEDFGUcqdDW6hmiEVwhuhXQVNFBKMiGku2
X4aIUREpcmhTf44IBodle6WsEqNVuwjW3Ov3iqQKgTRcCyth5dh3vBK/LjkQdM1LQv67
hniG5V1ZV5uFfIzIWVMQi8PndepuvKjP6NSZ0HruElr15ep8TjplQjurs0TvXxpCm8aI
no8ud0G/eakhXo8BVcLPApsazuICjFqUIWqjieYxzgYOhZS6E7uEzYUgFHHRZZ0Dno3w
b6YF0tDVhN1GS8v+5zI/5UBAUKXoJTYnSJ0EwaO02lg4dZWyKvNE8UVh56bMR9Rnh2mh
WKfO2AT7g1w7XuxfN+tk0c6jE1bW0zY5BBSsGxf7HxvipmlElTJD19FGWg7F0v7valYg
3A6VOmyb5QwJ8VKD6k2rktvlGtQLKFC7JFTUdSEKfU9qUCi0bQiK1bIhy20oLBAnG/JF
/Dcd34YwWlvu+d9b9M9Htov991v0L+aJrhcumf6ZSLZ0tGrpn7WlcTfpnwcdahdSJbfT
VDr60HA7ZBo7F7YhmZXJYIjA5H50G5+CBGa44qPAVuKySIBvUb5NKCpTQz/UV9EnG+5T
9UHZ2NRnyWt1AaKfW3OlOMhEN7K3rpuzyiQGNXaJrwRnQnVO2vWdjaRm9Org+qWMEAsj
XdGVNJqN9UsKqJZvYcodQ1lTNxgt+q+zdeyqFdsE0V9VhoZ6kDVyNGK2FlIXCEqdmcru
74xd9cWHBJl6OLLqs87Sroau+gJ1ckuEOnPkqrM6f6oMjFoo555Syy7oppezHGs4ZyeE
amgF+yRDtbGLkIZWkB7R7JNfIDWtkIOy4HMv6akiB2Uef4qFaloh9dD5xMVCQ0NOvHAp
IUoTpKYVclAW0UMLszS8woTR+NLOTTIKObHGJVIzpE5GND2UhSjHGj11hcB4jJlLfDWN
Ip88OS1dYJKydfJkkzfFpm/rvqYNPMAm9KWcT57AVNtNz31NRyMxWkhpOrUhTGvR2e2F
1JnAWBALnVpPr06eorWhbzqDwBaSWTig0YUSo5mb2HejsXA1Z2IxOaApzBZ+RJ1q3Pi6
p6bGFhFbNqyGn7DFrin4Nr5nP7LMy8EWAXNoz8HAlTSlbUj2o2OHwZz8FfM61CAfZY7t
hp03DhRGe1Ut9Mr8xPO2eb8VP/HBbOrT8JOACEaF5iupEmSqyydQW0UxE5QIL4AcxH5R
BIk34DDEV9wdI4M6cOwXRZN0GKMrq0x7AghioPUl4baHrSQjg+tVmcsRoIUuehXAzRGg
DKHa98sZyBBh8vYbAbwcAXJEfSirzOEb3GRkksL6P4qkQJ2apPyjOR+RszAwyhndBF4+
16cgIXOGqI0LPygSNS1C6tCU0Y9Qq8ICuas4q2O5HnNXNJEDFI45kSbIqUpHbzCcW1Ps
vlFFJj8MZEJ8J0hFqZScsVD0gRdIzZdkrDMxuUKXrTMWyyTnf52FMtMh5liY5b5hOjym
lPP+El4tjRGmySEUOzo2NIZH+ED6yQSpSWJBYybIu4ajYDynVAhpLqQ0fGQTp779jUFr
c1wa99RQFPiIUgjbkLMUMGOdb74mSNPaENbQxQa1jrkVxMuGvOt70VBMI182pDZPhISh
OC733B59yDlkHi8Xs6iaN6BqsF0Q7Q2b1Et5i9EouzCLkBBzIZZurjmBRQ1xUnUnyHPD
LMAzgeMrVvFyCZqvu7se8jafbdt++BsfCc2zTMXf4Hbq67yOQLFUZYMurHGV2wWHduRC
5eiVKLmQ1VRYt6F20QqLJ7sFmQ49EFHeX6mnRkaXuKpzu+bQAwFlGkVeow8FlzH4YSPJ
HGDnawM10zr9ajRzUYedLdRZHP3n3fF48343/O3l3Yf98bh/ehx+efNqtHPRD/WINhU8
P9QRoDoDLSpxMGbZzps//ohWrdMv332yXdUXTkeF3p6S2tJ7+F1OVl+ojDzHOyujSmX2
sxEnYADTlaF8suFxQCDsHk/7m4fh3c1x97B/3P3W+72vdrsFciQY/GCpiCa1l21Xs+Yr
vx5b1Mn3k7M6dVAuOG80eAhrntGX12MFhEF4QPwXgW8+1lIiBiom8c8EeblA1AUSCGMt
vFwstK+kBCx0eeszQQ4FRAkkWBk/wkrdtRSQTYxlgQopQw2BLoGSQfxPkOcaAqrCznCx
6acKksR0wYbzQqpWN0OsvIYIwhAmKaca4uJoTShNN1QOSEGuaVIodHGVFLA8Oybji03H
ygFGOw1WKm1ugoRGSoyj9qljOnGAkaNudP8CclNLAS2Cq8sdPTYQTL02prg44K6GEDl5
SXLFjYZkIcuL/RtV5JWDXOe3cTlDLMnFH4XSRaqC5HVsocqvjRTZUJ6u67ic7c95IXkU
0DULewKJY7MdLtn+nBfiK2lkHAbwGIoCcCFFJUReMDvyqu9FF8KoKZl+6BqXEipDKhzQ
6OIxLYX88K6XRij9clNvV+FSOcBjIZMHt24syJkO/ltAwAaE6JUY2bWJxZbeN2LkmI+3
A0adIRi95T4oXMmAKFuyqVPIJCjyuQ+YVqFvkwFJMkC7QsqxgUjARONU3zBJUkCX5q3V
JS22CyktfnzfQLAjlx/w9aUkN7oQfRmZaz8SSgN2pH0/BTD/8RiptMuxSiQyyWAwS9yP
TCK590vJ9wsZgc6Pnozv+kieUcm7Osf94EX0IwWQbKobUmRZX87mejWIrPhoKg1qq6sR
w0dRR9tPAVRDuYjXtsz7ygHIs5G1L2L3oZGS5IV2DG2BmR3g0PnY6dBvwuTyZwnBbns6
O8Ch2WA1d8WNPi/Uj3/yeRnPi/k/g0t/vRklj0xonj3y9yovraqRaVZnIX//uDnsn16O
w8txd//y8GokeVEsBb2p2PBqDLnQJdGmLv9VTxyaMbZlxnNBv/n7T8Npd/vr4/7jy+74
aiPnetZISV8ZNV5z8pFRY9ZmsePbekYAKwmEgqku4IZEedAsZkabnxB1RfZg5TbKi7Ez
QjUFOQgpl48OJhF1TQko+9boxYJnREETgrzJBvO0M6KukTKFaGvnba9oTx5Tktz7OLPs
pO5zEWpQwMQzI+q+EQPJR2ZoLROiGWNkFQKrmWW8a+YPrAIi4md71V07iUVJzjAnGQ3H
0PJeXj6MmBC7mldpcVwAEZ8Qd+1gwULglt1uzBUk/G1BPG2NFdhL6to0TxXGE3UtZkjL
QzRenP+hQXi0P6/TbLFdg0DLl5eNfYvZPPbZuEaUFrMyxya9RFBDIVnGWO/9ZnycJwGZ
52Ks/LKSkcc5d8W3Tigmm9i3mMvDXLGXxi8uM9klxA7tDKARY2nb+WcEBvLoTFgnvloN
CYwi7Fx/s15YYTCLOW5rg8kRRML8tJm2Z/YvD9FBlmfEczsfRDiOlqRsZER5C4ZJrq9p
hElDWmpYE8cyG2Bmst0ihtCRRazvR1jKi/RNLpODNdTbqSKtpcgVhaHheJpzrQ3dck3a
o/tgWO2GF0lhcPKOvrfV89u64JeE3DcIBDEhE7pJTSavUpSfuoShL5nRu6LmN5qS7Dbw
dmycJwqw+CgXU12LydOZFKzpW0yOGpIJ3fAiTJ5SBbvpCDXlCsEs4XX3jT49kHdR/zlf
HszaFDcIzdM+Htmg2KkLuL0St0Ge06E7TIjmswO5kTXy4O6MUK2M+cOEScb77ncJE6K+
spJv5WAsdNyeHt5IS9Zh2NqKSPJW3tEhIGdE8x1uzLPV/P831+kWGyGwsdlc7W06CIo8
hOwtEQ3JU7IZoS5X6a8brBEyN8JjeDUuvXoAuaXKcfsTDY6z6Z+bB4569Nah1KxiaP31
hZfPn9Ns++aSXN4uaim9PQfnby/yCeAqzFT1uNFGMOFeGC0fZ2ytoopvM5a9NPezZO0Y
vV9WaR8WoDijU/Bsseai2JIHab8iwgoj17af2gY0Wa7PZxHtRxlM8mGYXy9S2kvKA3J/
qQ537WOAhFbV84mavrVdEB/aW36PRhW5Hxs+Wnnk0i2E549oU6FG8/IhUBodL9E1bF3M
B20WLV62P6DlxRbPtbXO388WkbHxpUGAtZLbrJSq+MA2dauUkW+ZwJVCf5UU0ojST93o
wuDhxvwOqmdzubMaxXmzxQ7tyzqWh8KpmweEGB21KSJw33xlgMJgriQKkVzwQE61yGt8
ers+UAveftPL1PV52qxNwR9eHk7754fdcHx6eDntnx6Pw+NudzecnoZ3u+Fu9/zw9H/4
9eY03O3v73eH3eNpeH7aP56O3+CZgljUg5V9yzOjtUVnbRaL/vRwc7p/Onz44fZhL9Y6
/vr08nAn1ry9eb55B1M/3Q/PN4fT/nb/fHPaP74f9o/D/f7htDvgl8Ks/w9GhR86CmVu
ZHN0cmVhbQplbmRvYmoKNjIgMCBvYmoKNDA2NwplbmRvYmoKNTkgMCBvYmoKPDwgL1R5
cGUgL1BhZ2UgL1BhcmVudCA2NSAwIFIgL1Jlc291cmNlcyA2MSAwIFIgL0NvbnRlbnRz
IDYwIDAgUiAvTWVkaWFCb3gKWzAgMCA3OTIgNjEyXSA+PgplbmRvYmoKNjEgMCBvYmoK
PDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0g
L0NvbG9yU3BhY2UgPDwgL0NzMQo1IDAgUiA+PiAvRm9udCA8PCAvRjMuMCAyMSAwIFIg
L0YxLjAgNiAwIFIgL0YyLjAgOSAwIFIgPj4gL1hPYmplY3QKPDwgL0ltOCA2MyAwIFIg
Pj4gPj4KZW5kb2JqCjYzIDAgb2JqCjw8IC9MZW5ndGggNjQgMCBSIC9UeXBlIC9YT2Jq
ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjU2IC9IZWlnaHQKMSAvQ29sb3JTcGFj
ZSA1IDAgUiAvU01hc2sgNjYgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAv
RmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnjabcJ7MNMBAADg/uuuu67rurq6urrqyps88wh5
JHmEIhyicCRROJIkiqIokkj89n7YxryGYZ7zGPOe2WZjbPPaZjaPeZR+uCvd9d13QAU4
qAIcUgUOqwFH1ICj6sAxDeC4JnBCC3JSC3JKG3JaB3LmCuSsLuScHuS8HvSCPvSiAfSS
IfSyEVTlKlTVGKZuAtMwhWmawbTN4DrX4FfM4boWcH1LuMF1hKEVwsgaYWyDMLFFmt5A
mtkhze1RFrdQlg4oK0eUtRPaxhltextt54K56Yqxd8M43ME6umOdPLDO90pcPEtcvXBu
3ri7Pjh3X7yHH97zPsHLn+AdQPB5WOobWOoXVOYfXBYQQnwQSgx8RAwKKw8OLw95UhEa
UREWWfn4WWV4VFVEdFVkTPXT2OqoOFL0c1JMfE1sQk3cy9r4xLoXSXUJr8mJyeRXKfVJ
b+uTUxtS0hrevG9MTaekZVDefWhKz2zKyGr++KklM7slK6f185fW7Ny2nLz23G/tX/Op
eQXU/MKOgh+d34s6C4u7iiBdxdBuAEaDwmkwZA8c1YtA96IwdHQJHYPrw+L7cYR+fOkA
gThYWj5IrBgqrxyqqBqurB6pIo2Qahk1daO15NG6eia5gVnfONZAYVGaWE3N7OYWdksb
p7Wd00Ydb+/gUju5HV28zm5eF22iu2eC1jvZQ+f39vHpfVN9/VP9A9MDg9ODQ4KhYcHw
iHCEIWSMihhM0Shzhjk2M8aaZbFn2Zw5Dnh8fpw7z+Ut8CZ2TkyKJ/liPl/Cn5JMTUun
BVIBWLgoFC6KRDLRjGwGPLs0O7c0B56Xz4MX5AsLCrFYIZYoJJJliXRZCl5cWdwtk62C
l5Z2y9fkYMWaYqdSsaxcBq8oV1bWd66ur+5d21jbq9xQ7twEr6//vbEB3tq7ubn/z62t
f+7z68//2t7e/g0SGRtxCmVuZHN0cmVhbQplbmRvYmoKNjQgMCBvYmoKNzA3CmVuZG9i
ago2NiAwIG9iago8PCAvTGVuZ3RoIDY3IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlw
ZSAvSW1hZ2UgL1dpZHRoIDI1NiAvSGVpZ2h0CjEgL0NvbG9yU3BhY2UgL0RldmljZUdy
YXkgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJl
YW0KeNr7/39kAwAIAP8BCmVuZHN0cmVhbQplbmRvYmoKNjcgMCBvYmoKMTIKZW5kb2Jq
CjY5IDAgb2JqCjw8IC9MZW5ndGggNzEgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+
CnN0cmVhbQp42sVYTW8jNwy961fo6D1EISVSH9fd7gI9FG1QA7304nWcwkW+nRTovy81
45mRJc8gu0FbJ4Dt5FkiHx+fKD/pK/2knZdfA/LgoIMFzQT6ead/0/f68tMB9fagsfs5
bDOYQ4/2HfiiR6ubN68FGgyyTYQY5aW3Lr9xefUneW9d6h4KOuTwNi8N/cpJb+/0x7Xm
DpGfkJG0ZdTrO335BY38Ra9v9Cp+0Os/9ee1upqJziWTF6cxxl92z9vd48vr5lY/7+Uj
7J0BCSF2W12QgdBHR9EE7D5KkU2MAJTDuvzxLukfHvTV26lVR2opGLayIRnqVgND3V5M
+qJ/HYFC/vg81+r7uNbzXKueazySnZ8ZrbZoY8+2Hdn+af+y/2Pzsn+41w83Eud2t/9r
d60Pj5u7XAf1ef0NtPTbLcepWk1E12HkyTJrDJ76KN0Y5e+W+CiLM+God4RTSVSdhOOo
DGci7eculglHkEzEGNyIXj1+UKcQDyZYZD9BdtUqDMGAD9IVI+T5CFEDRLRPycdio029
SlY2WcIJ8lJAlDx5dIaTDWGCPFSr+KzoxB7bWEZI8iZZkaYaIRcVJFgyPrAvkv5UQyKZ
yBz6jdS5WKJjEyStgpf7GhK98ZJWLJM+LUBCyQgx0HxGibxQh+RaXoYCpBRMILJFRrfV
KggWTEw+nIeoDkJiSpTsvBgQEhiXqMjouoYgobEp+KkAuoHkOk4iXn2pASJJI/4ybqNW
+wbiomFgu5Cy9Wg8l4Kq6RfrEelCXErZdYUui1jrH52PBkUQE+Qw7wvnbEp9ny+csSlP
nVzfblOLrqneEU5nUxLOaFOqD+fXxqbAcJSKj+jVaw1hlJOMZMMjRK2+NjZljYshV3JY
5VBD8kHrHE2IbXeYFIjEcipHOaJHSOMvVs5WiLmPBsgkTdVDGHLbo5sgdbQB0Mg8kPwE
qXSnghziCRLzfCwhSjO6ZIuNaq+LEA1I26vTnEsESy86xiLn2uoSSDe6CDjKq7E6MWVj
pZEKcl9qSHQyIUlrlwlV7QjoDZWIh8aAfDDOuoL+27obs0dR8LaFTAYkZ423MZynvzND
ZBnoAhWrXLcuJZYaikV0a1LiqDImqVlRigNJEQPP84ZOaoiWaWJ/00ByEQOkpVWiNdaW
otzX7FOuc3BRz4oFcyfKsEptziP9FOTsDLjQQ5hnCgdzHd/RzxyNBXILReSIckj4ONtD
8g/p1gC24f/986P6VmNmadMZY/6Px9nOmMdwpvlx1pjVgF4y5gGyYMwCUcvGPCxS664w
5gFSe0dhzAOknhkKY66jVa0xD5BaVIUxT7Gcqrcw5gEyZ8zz0UYncxRZCBP97YBpDRIV
7N801i13gMTWT+zXfZScKJJCKIJ9PWfdMmydsFJbtxP5pTyaz0WLIA2LpVa2tXdgLiLR
AvsyKzvJCIp9rmvvsDLgh1Tk0/pyriFxobiPM65biH/GdbEI5e/GL6WHIh5Fqc4mRBKL
GJWdVmnOCEpyNRL9l2Kp6GfMdw0okm7C7b6AyIZQVWjhS41/wX3QI521H/0/XKXRu3g2
mIY8LzdCAu9L8qoSBLkoOEi0UIIQ842kcI5meIkgpycEXtBUFNNFdnheMF0HRLkQUooL
XohJ7oOesVmlL8A/ne4dyQplbmRzdHJlYW0KZW5kb2JqCjcxIDAgb2JqCjEyMzIKZW5k
b2JqCjY4IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNjUgMCBSIC9SZXNvdXJj
ZXMgNzAgMCBSIC9Db250ZW50cyA2OSAwIFIgL01lZGlhQm94ClswIDAgNzkyIDYxMl0g
Pj4KZW5kb2JqCjcwIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VC
IC9JbWFnZUMgL0ltYWdlSSBdIC9Db2xvclNwYWNlIDw8IC9DczEKNSAwIFIgPj4gL0Zv
bnQgPDwgL0YzLjAgMjEgMCBSIC9GMS4wIDYgMCBSIC9GMi4wIDkgMCBSID4+IC9YT2Jq
ZWN0Cjw8IC9JbTkgNzIgMCBSID4+ID4+CmVuZG9iago3MiAwIG9iago8PCAvTGVuZ3Ro
IDczIDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI1NiAv
SGVpZ2h0CjEgL0NvbG9yU3BhY2UgNSAwIFIgL1NNYXNrIDc0IDAgUiAvQml0c1BlckNv
bXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42m3CezDTAQAA
4P7rrruu67q6urq66sqbPPMIeSR5hCIconAkUTiSJIqiKJJI/PZ+2Ma8hmGe8xjzntlm
Y2zz2mY2j3mUfrgr3fXdd0AFOKgCHFIFDqsBR9SAo+rAMQ3guCZwQgtyUgtyShtyWgdy
5grkrC7knB7kvB70gj70ogH0kiH0shFU5SpU1RimbgLTMIVpmsG0zeA61+BXzOG6FnB9
S7jBdYShFcLIGmFsgzCxRZreQJrZIc3tURa3UJYOKCtHlLUT2sYZbXsbbeeCuemKsXfD
ONzBOrpjnTywzvdKXDxLXL1wbt64uz44d1+8hx/e8z7By5/gHUDweVjqG1jqF1TmH1wW
EEJ8EEoMfEQMCisPDi8PeVIRGlERFln5+FlleFRVRHRVZEz109jqqDhS9HNSTHxNbEJN
3Mva+MS6F0l1Ca/JicnkVyn1SW/rk1MbUtIa3rxvTE2npGVQ3n1oSs9syshq/vipJTO7
JSun9fOX1uzctpy89txv7V/zqXkF1PzCjoIfnd+LOguLu4ogXcXQbgBGg8JpMGQPHNWL
QPeiMHR0CR2D68Pi+3GEfnzpAIE4WFo+SKwYKq8cqqgarqweqSKNkGoZNXWjteTRunom
uYFZ3zjWQGFRmlhNzezmFnZLG6e1ndNGHW/v4FI7uR1dvM5uXhdtortngtY72UPn9/bx
6X1Tff1T/QPTA4PTg0OCoWHB8IhwhCFkjIoYTNEoc4Y5NjPGmmWxZ9mcOQ54fH6cO8/l
LfAmdk5Miif5Yj5fwp+STE1LpwVSAVi4KBQuikQy0YxsBjy7NDu3NAeel8+DF+QLCwqx
WCGWKCSSZYl0WQpeXFncLZOtgpeWdsvX5GDFmmKnUrGsXAavKFdW1neurq/uXdtY26vc
UO7cBK+v/72xAd7au7m5/8+trX/u8+vP/9re3v4NEhkbcQplbmRzdHJlYW0KZW5kb2Jq
CjczIDAgb2JqCjcwNwplbmRvYmoKNzQgMCBvYmoKPDwgL0xlbmd0aCA3NSAwIFIgL1R5
cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNTYgL0hlaWdodAoxIC9D
b2xvclNwYWNlIC9EZXZpY2VHcmF5IC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAv
RmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnja+/9/ZAMACAD/AQplbmRzdHJlYW0KZW5kb2Jq
Cjc1IDAgb2JqCjEyCmVuZG9iago3NyAwIG9iago8PCAvTGVuZ3RoIDc5IDAgUiAvRmls
dGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNrNWs9vFM0Rvc9f0ZdIcKDpqv6dWz4C
Ug5RwoejXLjY6wE2rNdmdx3Ef5/Xs57p3u6ZxZ9iAQbJGD9X11RVv3pV4y/irfgitMNf
qfBhvfCshDVK7Hrxb7EVL1/tSaz2goY/+1UCW39EuwH84ojuPjzalhJKkuVoiAL+6Vin
L3Sy/gVfs47DR6cG5PhlMq2OlqNY3YjfLoQdEOkTWTKCLYmLG/HyDUn8j7j4IJ7F5+Li
P+L1Rfd2wTsdZTJuJh//2e9W/d3h/nIjdmv8iHVaKrgQhqNeGKn80TsTpKfhR02wMgSl
THLr5d9uSIm/3oq3j41HN8XWeGkZJxppBnNKmuEwa8SL47+DMj79+Hywu/lgpxir4YPr
GIvlGHfHGJPWAyh99s4LJm2OUeYpyq+HKJfIYK2MOuUE8A7wZx8aTFRKas1KTzbnQMZI
r/nh4MFS34BIUUAGrMuWVjOgmDIZXLZ0aEGkvTQ6cra0ngH5lCHN2dJ/WxCjQJx2lC3N
OK6ZpQ+RsiUxA7JRBl2E6V2LMakcnTEjqHt214KsRqpVzIYuW4xTRsLrkEE3z7sa5OF2
hLkMmnHbw+1oy1C+ai0haZKNLyzdtpYikuJi6dO2scSKoiTtTAa16WWF22y1L5Kyay0R
WWnYuHM+MUUng4uFpc1g6fXF42/+8fbN3cnuLO+ROv5g+kzWIorh4U7q6U6+Z2OT193T
OFTy8nmHcG7hUCaJv99vDuu7TS/2d5c3YnW7PexuN+LQrz5t11/u+724hC/bvr/ur39Y
IMMxofjEgVGx3jVhBEF9r4c8WRizO9rqwp0cxO3gS8YZpWVUHHQ3oh9qtYBYI4Oyzk0G
Hy5rAfEeNzXQ8cyBhvYVxDJoQaWbM1lZ1xC0L2MTdUyQ4zUtIDFIsJkqrHysrDgTJcOI
yZDNA6QbIZ6lIaMLK31lxaMhgH9CnH/oLkEMgcOgPTLkUFtxUTrHnpcPCpRqoYz/qkY4
xjPrUITlUwWJpCVb9xDc7hi5CgJRQDZauxz/GLzUxGVwv1TxJ/Q/yWQKX+4rK6QCeBTf
bp95jD+aJAjSab1cUaBQdD+yft7dboAEQssKhbt10RFzgC/6TOkSRB/qxVFOwF0N0Yol
ubIW+gaC9gkJaXMCdg0kKAk1UtTChxpiFB46GlceVCXAQBgpowordb2QVSR1KEN3+GEM
1HQWByJa6CwlQ3dP4tCc/Kw7y+RQJsV3tzd92UhWl1tx1Yvd/Vb028N612++ifUWveXw
9Xb3+Wc1Fwvvf6HmMrlTdOi6LXDiWedAbg/oB8FYQFySncw0GWyYy1IiUYtxJkGGu/Wt
hjg8MymXo9Tcc5tYyWmI1wlyW90tZ/DELgnOCVLfUOe8BGNzaA+amkvENXfB2ww5zDUX
Qu/IkE91c0mdAxqxsNJ2DoxIzhe5aPhvaB2kibpFKzFRjoUQXQ4d5jA8NFGO/9caAS3r
OBZV2qgIUmk41ewzZNc0Fw/B79hkyOemLbCDjDgTfiL0f+NUYeSqofw0OA7tZy4qQ2+B
epdehbicROI0xJ1Uy2GucWBecsvhPzYOa7kMy1zjCCbm+Iu2caC7a19Y+dpAcNPQ/mNZ
c1X8000LNoTlmqN001gZ3V7XKQGOvEQqz9xFSjeNbXQZ8q86AR45whxdlMtfaiveKUiE
GM4c5IOWHsNmt3hFKGCmhVw599DBuyRXCgJqIBFUF0pyac6JuNHDdwtvq/jHiOuq/HIp
sOK0zXC+dbabIJ6kCnyGFTCfQmizL6zcV+FnyB2ptSoytGmsRJIm8JkrAlqHFtfadIsZ
Yjb8IFZGyPtnDcarNJlzjn/zSBoy2gQqnLlrIOBuHUyR6MsqAWygo71WRene1FYMRHLg
uU4zZcAS7qsvr1HjrrXwhU1hZVVnwGEycy7GZUplh8nM+rIZNQWDRoQuzmaZgdhrLbXx
xUHvn9fy7JFrwj8gz46iomv0IjTDY/Riq3K6J3EoOdKd6MXJoaxzfuv3h1IvpqWD2N9f
7Ve79VW/G3cTLz/g/68uV59/3l4HNPpr7XUmh3I0L6ZA/nnKcvfDtOwgrZWjM9J6Jkzd
Ew0pcKdrpfXkTg7SP2rdTEmIBp/RILyuldaMjp0hfSOtMUw6TyZDdhWbDUsZ6NnioFrD
26hlMCDPDDlUbAYpKyGVUssZITWbDUuZaB21vky6GSonsuXYTZAXNUSzhCZ2xUO/qiHo
sgEEfDyom/MlGPQBG2wRl3oqCdGAnqHNyoc+TUAcxh/yZvmJYtqtpVVUG5dJT6FOpDcl
ZNNoaw4yROfnIYOeUhbFZCIvFwOptFyLpnii60Z+p+Va9C4noF3cpDzabOPd3E5GaZ7y
3LUbjCSttT9XLaTZSg7KlrGt5JRGk/Wkikdez0lrDEm2zfMUfqPTlqkshY+NtA4oOlcQ
SbMrJIskBlbFE/0+J61BCgWkWa05qJyodBH+zZy0VufuPJQdpJIil8t///3u+iii+/4L
11PexW1fot0f0p1OaXfyplgMNdtyDGsBnNo9gJsUYSCEDjU4fURcNZyL4TP46fG7dlVu
MXtCNU8m6vuRpKHyAZPPiBh4pSsQ2kqrAhhhRNSl79J+1RHpWUeHFYSK0jqNKW1ENEvy
9JJWpZ3yiR8lIqQxIrKeAvZibv8dikNquk7DF7vo7BSvmgvQVyRYx+SYN8tvD8rxlvMp
hypgA8sGtn7xUY6rb2tzWm4bjk07JpsLu72dRGkho+wZxHE13i3FfNh6B6R2MtGQNKMH
elD1FLCZnTce1ulcP2/azQVq0Dl3Wj/dCQFHGTEDLj8KLhWiTvY06GXABvrFkLhYYVDf
yC0a+nJa0o2z0fMUsZ/FZsHSL8RmkzePYbMH8Bk2GxHLbHZEnGGz0cQym42IZTYbEcts
NufoKZuNiGU2O/Fjls1GhGjYjCBiKTv6rtnIYh73OtgpXocZYRk4TZ2jjVpvR0O4E0W8
ajKLadXHipbjlTZNyrPTs1npRrozlOu6ZRHIB2m9yqf83m5roZ2s8osFNqhFZ3XOSkuI
0abXz3EKWMMRaYVEGGUmG49jgO4JtgXFvgaR8sb9sTFyjgG6/9ebkQHgTVcvLpopUksK
sDC63r6fSezKuDjdiGjevaTG6aHqJxvNlInRIy0UHwAzFIHBwzrWYTLR3O9USNDZ5tTR
kiNQ88opk93Yzrx1iU5DBIyI9o0+ComszzbeNLMjUkuYHhc9TXqG0tQxBayu6KCj1Kwh
V0bEYZEkxoj1My/8DaXfeRxtNJOlQVpMesd04ukJS0SUD9m4GDFKvxIVlclR/1jUcvdD
XySjPH6p98iTP0V/Tb+XtF/d4sD3z/4kNuvP/Wb96fb2Whxu0/vk9HtL75+L6/7Q727W
2/5aXH37KavB5L9lX/t/udmIm3716XK73t/sC8/+B+wHMYMKZW5kc3RyZWFtCmVuZG9i
ago3OSAwIG9iagoyNTU4CmVuZG9iago3NiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFy
ZW50IDY1IDAgUiAvUmVzb3VyY2VzIDc4IDAgUiAvQ29udGVudHMgNzcgMCBSIC9NZWRp
YUJveApbMCAwIDc5MiA2MTJdID4+CmVuZG9iago3OCAwIG9iago8PCAvUHJvY1NldCBb
IC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8
PCAvQ3MxCjUgMCBSID4+IC9Gb250IDw8IC9GMy4wIDIxIDAgUiAvRjEuMCA2IDAgUiAv
RjIuMCA5IDAgUiA+PiAvWE9iamVjdAo8PCAvSW0xMCA4MCAwIFIgPj4gPj4KZW5kb2Jq
CjgwIDAgb2JqCjw8IC9MZW5ndGggODEgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl
IC9JbWFnZSAvV2lkdGggMjU2IC9IZWlnaHQKMSAvQ29sb3JTcGFjZSA1IDAgUiAvU01h
c2sgODIgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUK
Pj4Kc3RyZWFtCnjabcJ7MNMBAADg/uuuu67rurq6urrqyps88wh5JHmEIhyicCRROJIk
iqIokkj89n7YxryGYZ7zGPOe2WZjbPPaZjaPeZR+uCvd9d13QAU4qAIcUgUOqwFH1ICj
6sAxDeC4JnBCC3JSC3JKG3JaB3LmCuSsLuScHuS8HvSCPvSiAfSSIfSyEVTlKlTVGKZu
AtMwhWmawbTN4DrX4FfM4boWcH1LuMF1hKEVwsgaYWyDMLFFmt5Amtkhze1RFrdQlg4o
K0eUtRPaxhltextt54K56Yqxd8M43ME6umOdPLDO90pcPEtcvXBu3ri7Pjh3X7yHH97z
PsHLn+AdQPB5WOobWOoXVOYfXBYQQnwQSgx8RAwKKw8OLw95UhEaUREWWfn4WWV4VFVE
dFVkTPXT2OqoOFL0c1JMfE1sQk3cy9r4xLoXSXUJr8mJyeRXKfVJb+uTUxtS0hrevG9M
TaekZVDefWhKz2zKyGr++KklM7slK6f185fW7Ny2nLz23G/tX/OpeQXU/MKOgh+d34s6
C4u7iiBdxdBuAEaDwmkwZA8c1YtA96IwdHQJHYPrw+L7cYR+fOkAgThYWj5IrBgqrxyq
qBqurB6pIo2Qahk1daO15NG6eia5gVnfONZAYVGaWE3N7OYWdksbp7Wd00Ydb+/gUju5
HV28zm5eF22iu2eC1jvZQ+f39vHpfVN9/VP9A9MDg9ODQ4KhYcHwiHCEIWSMihhM0Shz
hjk2M8aaZbFn2Zw5Dnh8fpw7z+Ut8CZ2TkyKJ/liPl/Cn5JMTUunBVIBWLgoFC6KRDLR
jGwGPLs0O7c0B56Xz4MX5AsLCrFYIZYoJJJliXRZCl5cWdwtk62Cl5Z2y9fkYMWaYqdS
saxcBq8oV1bWd66ur+5d21jbq9xQ7twEr6//vbEB3tq7ubn/z62tf+7z68//2t7e/g0S
GRtxCmVuZHN0cmVhbQplbmRvYmoKODEgMCBvYmoKNzA3CmVuZG9iago4MiAwIG9iago8
PCAvTGVuZ3RoIDgzIDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp
ZHRoIDI1NiAvSGVpZ2h0CjEgL0NvbG9yU3BhY2UgL0RldmljZUdyYXkgL0JpdHNQZXJD
b21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNr7/39kAwAI
AP8BCmVuZHN0cmVhbQplbmRvYmoKODMgMCBvYmoKMTIKZW5kb2JqCjg1IDAgb2JqCjw8
IC9MZW5ndGggODcgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42s1c
W5MdtRF+16+Y4slUYaFu3fMWIFRRqSSkylW85GXxHtuL9+Y9ayj/+3w958xIRxodwDYG
IFkMn6VWX79uaXgz/Xd6M9mAv7TBHz5Okc3knZkedtMP0+305dd7mp7vJ5r/3D8XsI8H
dJjBTw9o9eI3r2Umo8lzdkQJfxvYyi+srP4Gv2ab5z+UmZHLL2Vpc1g5T89vpq+eTX5G
yA/yxkzsaXp2M335LWn8k+nZi+kJmc+nZz+pfzyDcNvi2axldbcK+f3u4fnu/vHtxfX0
cIXf4oPVBjIk2Us9ddrEgzwu6Ujzb3XJ65SMcSLXl9/dEE3f3A13PCpEbSjXRe0ZOzrt
5uWMdvNm3k1PD3+fjIvy23ttqw/T9nSqbdVrm47qlp/exomJ00HfvOr7P/e7h4vHu4en
X9/dPj7cXV/vLqdvr64fdw/7z9Wzn6YzhtiUHH9uyKnOekWy8+/DD/Z+ohjcQUq7Svk/
dl78AuKojyDOebUVcayrxSlK+9csS8E5gv0pBKsW9JOLFhKMjoGZ1gWf3DYQT6RD8PAi
gSiBvGshPmlDJnBZZWohiTQFa3KB3M2WLJBgcZTgc7XKfbNKSKxzSLGc/8nuCFFHSOSs
LTlrC+ShWSUG0tE5U21U60XhRzI4UcqhIB6bRZJFrMJasT5QA0kB+3BSQ0kyZU2RXaWV
fQsJXntKJhb1t7rNKekQjbfT0M5kIK6hUNn5ulE/GViRQvJjxZHJRvucaKx+Ivg/0kI8
IwslqznlStzLRv3E1mnKtVu2PoekAVlsjGOfI2usDtmw2tzoAPEOJ7L9gVaEM0Zne1SL
2vJKcp50cmRr5baQ6FAfbBq7P3IrPCqHcObMPrJmxxtxturfZ69tdmfckoILmnMdRPet
/kOOmo05p5forPbO5zPuEqPX2CeM8w8lZm1RAcaBRskjE0aqDNCdKIuNENJnZMnWamdc
5VFPWwNk5AXy9SrPm1WgElTWLdWq479HDCGxpHE6ZQSRtlIeRidWTDZq4+t0+tCtEjJq
u09jMzOz0TalqIZeyTzbkKYziBAQQrZK/q0jsKWZ2NA0jDK24D4gDrn2W9VAEs6cXXXm
F+0qUs+Sq137qvF+nCcizOKZSGQnVnZ5oH81Q5BQ4VI09n72yKeo/uGMiXyISMu+qr77
I1n4UO7y64y24S7BDbmL+jhU6ndxl1Wcwl3+3RIT4zWqnvFqQXc2kKyLnBnsNIYgjaVI
kjABUVu+6YV+R2xXVum4SySdOaArWCEXLXehpBk6y+NVgiPtDi6zQH5u3BfMBrIYcvVG
DXeRwih1oEAeGveNCFkkZleJe9WukjKiOqY0Vl0SX3DWhWKAjgIhqiNqWiXLu47goGlA
OSr678gL8jJnSrEsctfxGyEDLlRqedGRF7DU7GoTTZsUCFWiQG468oLcTHO2G6kFugcf
s6ky9POOvBjQgVQ5+pNXHXnxrGOKZwxNnCGL5Vz0f9uTF8SZ9WlsaFQSizhKVQDsO2oC
EuqtTb1eCiSDSEGgAtl37EUa4OjtGQNIB0wcq40ee/ZiELC1R22wF7D3NDY09IW+F25V
6f/HjpmQsPc6dXSMLVoUgZSSGosiYZQyhW1fOJAXhBHbWOn/dQdBU+MTpzOay8iGEf32
Gf1neJRB21Ig9z15QfcEgXqnW+uncSAnnGnsC+BqIFI8TpegL+CXPsYwDTMHgz1in9qK
Xflkg+7Jx0r/Fx3Ew6FMbeiOM0iXkHyVfzqERasXTB2tVx3EwuV8SLWd/6QphGf7V5pC
rOKUSv71uJIf0U/edpUc0iIC8rpg5w5CyTzSZpwhagviwXdBIDmUVdrsLZSMkV9cgdxu
VHLEW4gF8thVci9s1lSrtG1YAD032Uo9Gq6SA9isTXFb3LmSO0neuVJ0l2AkBYGLGlsg
bbFJzmjwYmkEyqEbSCZtnalEueoKudOoAhSK/t9sTCpsrrT/tqvAJI2nsI5y4raOB9YI
suo4Xb0iI4k557H2CXUTHJ/t+DxzHefs0rSplGMdD3CFeEb7cx33zlZm7uoIowkOWZrg
oV4sBxmrVP7UzykiGk8jffKi/n5QgcScXKhO9Ldf7zfUe6SFjSwFJUkLjB8zHZRZSJul
LJvf3P6ojyDONIvjpP9axSlZ6qvru+evr25fTm/38v+Pr3bTd99PF5eXD7v9frp7Mf+T
/e72Uv7t/t3+cXfzybol5B7B4IeTSmzJ/z5lqg8Qp1GmOhFnHkms4hRlHjJxhUMfIzNA
u6KPgV4ggUHG2ZT1jtW9QiATmBzEnxfI9RGiFgiKO/J18AXytFklgvMk5NBYII8VRAlE
RKHMuUCu2lUOcxIpLQvkpoGkeaMIg1ZnbiBW6KJzxabHzFVBZH5EwR4OrQp3rSBzX5BC
7PWyQDJFHYKRhqlo91T/2TswykiVAZ63q6AoJLLVmV83+ifDSac81j4Z9Ogmm8oRXp1C
FFou2aZW7V27iqRzb10enxjpnGRkdkb7BKINxVk71v6c8YP3tmh/30HgCtFSnMYbzZzT
pMrMD432yc7klirf/rldxWIjcCLXe+WqfosQOdT+kQ3Re2ew9TqIdo37k0PiwCKVJ3SH
dugifczhjOpcRslFgS8GaB0XLSJChG0cxzxaxHycvA0NAL9GoxnCGQOAQGjjK7VctvoP
Ce4f/TlfiEYGE5F7v1z1H2UfdF4FctutIhu52l2mVv9JNgq1WjpfEApn3blsSQkEQS77
VOV0DQRxqG0wbpzn5MpFox+tAqALxiwMzbhK/28biFwcoLsLufYo1UCElJpzwTjP0jPX
NnrRGICN3CrOfdFIL0wymTOUt2NEzRChgjHZ7RJxWEW0G5MfJynmeSMTxwZghr+Qc76N
tCGpUB+nioNUKJ8ObxzSFAzqNqPcvS9DUx+BMB7EEamCdOerOIVU/HOWpRIb/RLKhCno
Y7SVpeLcp6cCuGvWiOj/LAqoL5BfGghKkY4B+VltbjNDXEKj4yUcF8jUQoJDkFA8bFQl
sgqSowxYQ3We+waSkTBDlInxgjiU8QqBnouQh3KB3DSLzF0XmovYQ9QKCajjczlaILt2
FSyDdGirVR4a7ZNMhvLcrS6Q97nwUB/gT6t7k5P4Uu/dgHTurd5bHHHvgzgH91bHFy6d
e2cNxky0ojt3iDLANl7a9OP5OjOJgzsXpFIvq3Tei+RsYpJnFgtkarwqUdacfCiSnxj7
EAMEpwpi7AWya7wqRQfqkWy1ynUXAyDwtjrRksCLV2UWcUOuIO/aMPHzE4n6RJ3jqY/S
rNWWVpuOZwL9/rz6x6R5cbxVnJJXvxnn1SP6QAuqpdAmaGtZJroL5KJ1PCeEyoUKUoyt
jr5p4DJkU4E8bVdJwgqCtJkL5O0pRCVkM2OTDAIXSBsnyGTLe5gF0udnuRiMjCzfi3uE
gLkZtGyp0UvteAa2yCbSDFFb0ZYRs5k5VOK2MZuRfFEG6kN/ukduZVIig5uM9cfe+8dP
l0/mNkWa6onbxdXtI/4nU5njsGa3n97ud5fT3e31u+nF3cO0v7+4gTzy+PLq7vaTafJ0
aiNPM/5MTZ4ObVZpiiY/a2c2csVnYszqCG479SlYhyxgTFqW6zgwuAr6LunwDgjV9UNy
73ZIE8sabfMWPQsVIbci5nSvKkRCj4hktCq5GzsIhyOO2a6I+4bzp3kXwzw8S8rS8jLq
yYJ47KYschaOcdVY26vKnVxCY1zO8tknKwSn7hjhBH8m3S+aF3dcpSnu+PfWleThgHOo
SkfwcSReBkfBG51CsHaEQGUj7VMqG3YdWaSovWXr1YLo3VGIfEpll9bIEbuE5BeA6gCJ
EzoKimkabZKC3EYnDqebVDbMcnVLTrY7Itp2WTp3dBPBr4hXjc9L404+5aLStv3PMk9N
pvhLp1Iyso2xrMYI2UZ68tFpyYDqzi35orHbfuAnIe54eFoiGZS6yrRXjcbQFQV5K7wC
uk1YpqQym9zaZJ7MsFzey+uhBfFLP+pL2oRI48NaRocGw6wK68ZiVqwf/Ni0oEzIvKAr
q8Luu+mb7FKk6KZDTowCur4iXrazLC8eZlIcn2R+4YHUPIoERT6ipQ1UTP9Ft0YGVU/W
j88ayGkyfhyRFEDvKK3u0ydmCtFCX6vdVD8WjUgvzqcScLpDsNwymnAqae1gUb6yMG3Q
tsM/H4ugd93oD2azhuxYHWmeAlseb5Jk2pxzXBV2vzXUC1wprHOPjGgKcgG5KOymG8Yh
WDJq87pGj4DxuQLsGn0xarq8+XDDbMzkjLyi2z6sWuZw1qUwVBiOiWiKld1edVM4mXdn
TmqkDmb4Twj5jKTyOCuQLUm/HdmyxS5B7p1GfszyNCuGQMOkzw5emuStzcjT2VkrQ6Rh
CuP5kWRw+cwSsxhVWHcK83L3n6IdhiSyvexiY+Mdn57nBDDLvw7PWaVpv9GpeY4wELmV
OoJb5YLnCANBG7oA9hs0J4DljBFxZiCgzGpBtC4fZwaSuYjxsrvfRNQgty+nUj2LQaqS
m8uRFJKoIjhdQUxNEZKrTUQnOPdojQzDWVTdOFRXnnO/vOFcEF3hN1JiiMKK6AqImbeh
rFpJq4tNB4XZfGYNKYbWFX3115qwfZT3y8Nd5GOa+WbixG6nLAfH9a7o47KnOW4eoG0i
DjRH7oJzXv21vzmSG83oOI+0LhcaUaMmWzWy3PylTcp+7B8gfYQaw0Vj/SWjlO3saBr5
MdwL8STp/8T6tcbkJRnnKlo6jXnO2pCnTbvMGvOyi41n5PAo/SgQxZOv+3tMqwHwaoyQ
uu2jH/tHQMEk6XMXjV31ZAmhLwxjeNow3xDbcGrbE6IjBXMcTlEKP1ep47HlhXHegssW
nZhJ6AX4/IroGFvy8mCEhhlM5r/yvPuMxuUxeqDsxv6VYXk4WckdNx0iyQONxENtsQGn
g4+GoZ+zdEi+cp6O5UiDFFx1lP5WEyaJXKWfl5s3li6UgNz1F5Zgp+A6Y0FZynpey2qv
MPxuOCCY3brGjx3LmTlMVd+uW4VZ+WIz+KLSu54poczKa/kt7zjQHBM11cXndUdznNMs
V+hDfbhESPpScU9C5dN/ruNd/gt9rbNKU0jMD+3jXEbl95bVEds9QZWvH71HxltW695j
ypc60aRlO9W9o5TXvQk8KKxLbD7uNXLtsSAOLVuFyAbFMhuaRoLKxwUc0HVt7qKO3+gE
g2K4IlpJpbeMPqe8Iu43PkAO4GNFYS82nvU6ks+lF8TbjVe9luRr6ZHG5PMcFxKCYlnj
i40PlAMXrfcayybrGK0tp73pPs5BgxoyF7vcte9owYJkUFq03n9XPJuO0tC24EryAi86
dSLpCUIaLvnPK4xcjKAtneRt7KKx7mnx8cVvnoa7sCQrXznybaOxmSuxrzS2Gzz3TUMf
IxtZymHZ5XL7sW88s4uT1Jw5qtM1Dgnk/3CcA78KZW5kc3RyZWFtCmVuZG9iago4NyAw
IG9iago0MDYyCmVuZG9iago4NCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDY1
IDAgUiAvUmVzb3VyY2VzIDg2IDAgUiAvQ29udGVudHMgODUgMCBSIC9NZWRpYUJveApb
MCAwIDc5MiA2MTJdID4+CmVuZG9iago4NiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYg
L1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAvQ3Mx
CjUgMCBSID4+IC9Gb250IDw8IC9GMy4wIDIxIDAgUiAvRjEuMCA2IDAgUiAvRjIuMCA5
IDAgUiA+PiAvWE9iamVjdAo8PCAvSW0xMSA4OCAwIFIgPj4gPj4KZW5kb2JqCjg4IDAg
b2JqCjw8IC9MZW5ndGggODkgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn
ZSAvV2lkdGggMjU2IC9IZWlnaHQKMSAvQ29sb3JTcGFjZSA1IDAgUiAvU01hc2sgOTAg
MCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3Ry
ZWFtCnjabcJ7MNMBAADg/uuuu67rurq6urrqyps88wh5JHmEIhyicCRROJIkiqIokkj8
9n7YxryGYZ7zGPOe2WZjbPPaZjaPeZR+uCvd9d13QAU4qAIcUgUOqwFH1ICj6sAxDeC4
JnBCC3JSC3JKG3JaB3LmCuSsLuScHuS8HvSCPvSiAfSSIfSyEVTlKlTVGKZuAtMwhWma
wbTN4DrX4FfM4boWcH1LuMF1hKEVwsgaYWyDMLFFmt5Amtkhze1RFrdQlg4oK0eUtRPa
xhltextt54K56Yqxd8M43ME6umOdPLDO90pcPEtcvXBu3ri7Pjh3X7yHH97zPsHLn+Ad
QPB5WOobWOoXVOYfXBYQQnwQSgx8RAwKKw8OLw95UhEaUREWWfn4WWV4VFVEdFVkTPXT
2OqoOFL0c1JMfE1sQk3cy9r4xLoXSXUJr8mJyeRXKfVJb+uTUxtS0hrevG9MTaekZVDe
fWhKz2zKyGr++KklM7slK6f185fW7Ny2nLz23G/tX/OpeQXU/MKOgh+d34s6C4u7iiBd
xdBuAEaDwmkwZA8c1YtA96IwdHQJHYPrw+L7cYR+fOkAgThYWj5IrBgqrxyqqBqurB6p
Io2Qahk1daO15NG6eia5gVnfONZAYVGaWE3N7OYWdksbp7Wd00Ydb+/gUju5HV28zm5e
F22iu2eC1jvZQ+f39vHpfVN9/VP9A9MDg9ODQ4KhYcHwiHCEIWSMihhM0Shzhjk2M8aa
ZbFn2Zw5Dnh8fpw7z+Ut8CZ2TkyKJ/liPl/Cn5JMTUunBVIBWLgoFC6KRDLRjGwGPLs0
O7c0B56Xz4MX5AsLCrFYIZYoJJJliXRZCl5cWdwtk62Cl5Z2y9fkYMWaYqdSsaxcBq8o
V1bWd66ur+5d21jbq9xQ7twEr6//vbEB3tq7ubn/z62tf+7z68//2t7e/g0SGRtxCmVu
ZHN0cmVhbQplbmRvYmoKODkgMCBvYmoKNzA3CmVuZG9iago5MCAwIG9iago8PCAvTGVu
Z3RoIDkxIDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI1
NiAvSGVpZ2h0CjEgL0NvbG9yU3BhY2UgL0RldmljZUdyYXkgL0JpdHNQZXJDb21wb25l
bnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNr7/39kAwAIAP8BCmVu
ZHN0cmVhbQplbmRvYmoKOTEgMCBvYmoKMTIKZW5kb2JqCjkzIDAgb2JqCjw8IC9MZW5n
dGggOTUgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42s1bTXMctxG9
41fMka6yIDS+kVvi2FWuSiqOxKpcfKGoJUV7yaV3l7H17/N6ljPAAoOVGNGSaJdXMh8b
jUZ/vG6Avw3/Hn4bjMe/UuHLhSFoNTirhu1q+M9wN7z8bkfD5W6g8Z/dJYNdOKD9CH5x
QIurj5alBiXJ6WSJIv7oteG/GJb+G/6uTRq/hBqR019ZtDpITsPl7fC388GNCP4gp9Sg
HQ3nt8PLH0ji/wznV8MZ0TfD+S/i+3Mot6yeSZKl21nJn1bby9X9/uFiPWxv8CPOG6mg
Q+S1xAsrVTjoY6MMNP6ojU7GqJRlvV7+eEt6+Pumu+KjQcSCcW2QTmNFK+0oTkk7Lubs
8OLw56hs4B9vrS361mYjq/FL10Ye+kYWByOTMSOIP03ygyZjD2bWs5n/xVY+QtqUZFAp
mREvgD+7b0AuEhzBWj0LPVs1IO+cNCqYkCVtG1BQQVKyMWVJFy0IyxkbQsyS9g0oaieD
jZaypE0DSuNyutxdq1NySSqcl82SXjQgUsrgsImypO8WQGxNn/QpnRBMJPF9nyXdtSDt
tfQuFpJaExDMLZWL8dTuyLgok/XmpE7WKmmSSlnSegEUgrTGxixpAeQIQRFisbvVAihG
6Q1lJz1724J8gIcHr7OkoQWNDlVY6fUCJCH0HLkJJM4uW1DEYlrZ01ZKjqQvnFcs2Fuz
ozjjC2+6WQDB3i4qkyW1PqBJI3K1LWLlugVp9svC5cSClbTm5cgUdnrVggxSVFRU6PTQ
gixFqa3zp3wA33dSx5yDxIIPaNQSiZRSSNqNoBM1wCqxlDSfkCsfCxKieaxa+IQzOhx/
fMyVZs6VP2MbH1aIK+rzKDSWLf7EuoVCOXm/elivdsPl5m6/3azXq7fD6m5/s12t3w9v
3g+b+9X2Yr/ZzhqLJ1T5D2osWo3j4SjxoZGlKATfGNBo1Teg+AR1KgOKI3WMM4U6de3L
OEtBRsR9RqPyiWOIB3XQBG+fIatKCvKKVD6QzZDtI0RMELAFm3wsFrqopSQjo0VwZci+
gAh8eE3SJR1ChmwqKT5oLOQ8tbpMkKCsTBx6YobsagiSnA4qFgu9rCEBOR754rDpMTX/
WEMSKFIAcchSXleQ6AxYBbJzhvxUHUBSOACrqJBSq5uQa1R0PmXIUB1ACshZJlKx0G0l
hZTTEhui5TMSIyShaGFfGfK+lkIWyujCAWddMgQ+he+G/gGQRgl12hRS3jUQ7yTnztn+
tUeRIZIhlHveNhBrUfNK111V9idwAulsadzaF8iSkZ4JZBMjYoZ4RKu1hZQ/ailOeSYg
LkMua/s7HFEwpXc3ZvEoht7E1I808haNRLQu2/+uhgSl0CaUieG6gSBIQlI6H8CqgcBd
QL7CCV+IiGkdi/TZHkD0ATsyMUOuGikJxBvZo4XMB5A0Qs1Y189jlHziZob6BwBXQfuk
yx3tKynMoBD2hdPdNAjvkVNjYf//1hCCR6lgdV9b5GRoi6Yu239oIFFDFW36AaA1J29V
rPNQmV9znCVlC/OvGyER7YML1Pd/hDKiVelYZ7EPMYu5MIpPZhYT1RFo6MP/TXXKSi2e
QaGR6kAhUdXqf652u4vr1bDbbx8u9w9Y+O3qanW5/3wMkQ9YZHoDX3savamMJp5BnZne
iKxONtk/anqDVIgEdcjQaTEWreb2sZB39muNCGgulEKHOUNaAoSW13rrR4hYChFntYwp
pkKVunI6BJG21lGGDFUsekKFRpYK/Q15xJmzCZ38DLmrYtFHL63TOpQL1RwpSa9sKKTs
qlQYQDqSUyZ7xuPUpGA3KGhgOGg7Z8jFEgFKKDT5AGpeAsInNbr34gC+bQiQQh81MtDp
AOodJRyjS8kX1n1oCJAG6cB/StNVtUgFTmOuOMZ1IwVFz7mwcEZzLQK9kYFUYbpflzgS
HLPjdWLiSFaRPaGLNqCgzoS+1xHCA56ZigNoavRhxkKx73XoZsfZgc4H0FAKwxM0Fajv
dWRBzbVLrtxRdQAcsJZ0PxiJAzaMBXiCXNf2dzhoD6J0YkPcsUQqY2TfkDH4gvOGTklJ
PHh1hS4N6+aOJeK4RTdGKCC/kCstt28g1iPVhSIDLZAxA+OW8dqSMfLs3b60bkPGwEAd
0YkdJR6i2KDbqM9kLHLY6xN5TCtmw0fZcF2UGvGnNvYVYUCQJP8xhEE8i0JLg+2aMMwK
5er317vN7cX6ZrUbbu6G/bvVcL/d7DeXm/Ww2Q5Xm+3txX48zKcQnL6+4imMC+ksqJ4B
xfMo9PEnOhpwVqhgXBf7y3cw39XNH6u3zLtu7q5HY/K8aXW3ZzvONr26Wa3f7r6cQXlW
/1UZdFYoG/T7Py5u79er3V8+W+AeT+SScV/RQG7W5mMI6yP4MN8SBcJZGZGh/Yyo66xT
TgYV3Qy4ruqWc156Gm99HhF1HXCBr3BMSDOibhuZiCLP2ygmRE2mPF9FJq6OPUUDWlzY
jSZNRTuG8wolAPW8q2lAHbEJ9bFrsGiYJHGHOyHq4QFXNAKRTYursKgY+VpPx2z03xcI
KPgY6NqEaOYyShHfZNjZYjdL9JOCzzL27YSOJKqmni22WiKfAMSuxUbuaXX2x4PVxRH1
DDKgA5gR9+10jseAoJUTohkU8tBAwUNmxOXScM54m1dp9mJcYJacLdYS06gkji/v9maJ
USqadytaWsoRlcB8+hazAVQ8KH98LuJocsdTocJizelz0AVt4uJuxTS3Uz71fZ289lLD
9DPidmlqZygE0bUp80SEZnX6NU1Eu5u6UUnRJGmcdYunf0BEzkGKjnOQqDiiV/rE6aeo
ZbJFHhuaWRwYIhWL7BoK6TTaQp9FPDQDMhjdoFueDfamnbJxS5Kzxy8NgG+E+da0F5Na
a25IupGARhx1I7lQxf335+JPr+LH9TIa9RXVy1mbXC9fN/USrXbEGU3gwwkf1Use6Vos
NyHeNMMbxEwMeftHRzwWTGOkG2eXE2K1UDDh8ygQE6I+5DF2DZKNmBB1cvcO5TByIpoQ
Q3O3FXiCPeshmtsvJH6pTKAsY7tQUq338XgRcVxRPVqzvJUf6npp+GqGs93SImO99GhG
HYW8Sq1o4otHpJB8cM3UJxGPl5wXPXMQz+IRwLOIJg0pj1LHKWSy19umGPJAzVGW0SI8
d81WH2/2qFwmJ300fe8gbfkRQ7IzYteUyxilCW4R8DhfsagfynedY6yWPEebAL83ZUxr
6VHpZhHvliYnLlk/26stpwllzAbq+jnSJfM+dPZHqxwVy8S8z9n+Vjy8g6vuokUPxdIz
7zNZRnuBRZZHpbp/sgEURcPNRNfokfitiw19TTkWQprtsWCxiGNJMFtfU77gjU7bbkii
WMJ/lE19T+frXYNoWdT0sVgSzzZTV49DtVQuHufSplqqmEPytlMMXTfbohhGfiJnZ4u1
5TJY6V2Rbbef7QlKYS/Ug6DdJ114fOq11XE5hDbio8vho+rNEc7lUEyIfjmcEDXjyeXw
gBAnyuEko1sOZ0TNqXM5nBD9cjghfq+vKCzXEDN//6YphlxAnA3HWhw94dCITRfNbK86
aUbL5C760NVzrIaoNGa2V1ProKdCh5F3Ugd4igHxrX226LpOEgoHhwyQ7dVckiuD3tC5
bPNN87wj8qA5Zottl7pHfm05AZoW5FANLc0G61XDbLAmM2tYHTnPzgYbnnwzuxxz4gkx
R/w2c04BukwB+rNN2Y7qe1xS51X7FiXCeLX9P7PtuOlatp35ErZzKiyp05RzZ4g7sRzt
P5+1jTyqtXXZe1ftAxxklVSEu2wbedRAa3IUXbeXQnwXXIT7t3W4B8VXwambdQjfkM4V
teCujvYQ+B7YmsV88Pg4h9NO0P1VouOsk7zoZXqKiS+Bne6vkmyQ4zO5yWDrlt4opFDl
ujK0Ql6K/Ij2aLeiRAQtA9h8dy/oaJyMPoZuftTwa35Q5rr5EQQo8XuyvsXQOHHLYdxs
sWZsoW3k12RZxn2DSHw9r7PF6nqhjXWgnSF2KzACR4P+GnfsyKXF4KHSm0KPn7/5AtyH
mZjXSnwyE5tTifhEJgZt5kwiPsTEHsF9JjYj3lRXrZmJTYg+E5sQ9bOrzMQmRJ+JTYiK
A4nMxCZEn4lNiGaSrw3/ShBah84qhye3Rum824vuc9oDQjTRh4YB5+Zs6u1l4G4suNIe
9fQ7KctDRWu7ux3foziTsj1q3onYlUg3cMMJcbM0u9C6a3S+TgMHCihFE6K9UOAH06V7
fIAliecZ1CEejqYfFI4ComJJn7ltI3JpSZ1X7Q0GAiOEKnAmZcVz0RJ+E9CnJcznl21n
vsDMldDaL6nTTpp4HGHJdDMXmXF2b6mb/cgafu3v20gtHkzzY/9gunFISJ8y2JSzTtWM
iEzW6vzYkrVe5iKPxOSMT6KPQGKKUdtu5qLAr8zn9CgW3lKDesD+qa8oWipkUF+lJXH0
MsdKMMssY91eyyD7RVpWVBwmTch+OnSrBaXIv9tZJK5fWybm+XdKqGsvMDEjQcT8F01c
YHv+K0pcGjGzpM6PDcHk22r+BcTJeDWt15qfjpuQzfuiJZgKflAU9FcNOVQg3D7m6rNq
CSZag8KV7lt+GSW0zU7fvBq3mm+Aizr6vkHwTTQVm33RcFQEDprNHL/ntQwHzm58USY3
X+I1CjLZR6T6/wFavw01CmVuZHN0cmVhbQplbmRvYmoKOTUgMCBvYmoKMzQ5MwplbmRv
YmoKOTIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA2NSAwIFIgL1Jlc291cmNl
cyA5NCAwIFIgL0NvbnRlbnRzIDkzIDAgUiAvTWVkaWFCb3gKWzAgMCA3OTIgNjEyXSA+
PgplbmRvYmoKOTQgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUIg
L0ltYWdlQyAvSW1hZ2VJIF0gL0NvbG9yU3BhY2UgPDwgL0NzMQo1IDAgUiA+PiAvRm9u
dCA8PCAvRjMuMCAyMSAwIFIgL0YxLjAgNiAwIFIgL0YyLjAgOSAwIFIgPj4gL1hPYmpl
Y3QKPDwgL0ltMTIgOTYgMCBSID4+ID4+CmVuZG9iago5NiAwIG9iago8PCAvTGVuZ3Ro
IDk3IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI1NiAv
SGVpZ2h0CjEgL0NvbG9yU3BhY2UgNSAwIFIgL1NNYXNrIDk4IDAgUiAvQml0c1BlckNv
bXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42m3CezDTAQAA
4P7rrruu67q6urq66sqbPPMIeSR5hCIconAkUTiSJIqiKJJI/PZ+2Ma8hmGe8xjzntlm
Y2zz2mY2j3mUfrgr3fXdd0AFOKgCHFIFDqsBR9SAo+rAMQ3guCZwQgtyUgtyShtyWgdy
5grkrC7knB7kvB70gj70ogH0kiH0shFU5SpU1RimbgLTMIVpmsG0zeA61+BXzOG6FnB9
S7jBdYShFcLIGmFsgzCxRZreQJrZIc3tURa3UJYOKCtHlLUT2sYZbXsbbeeCuemKsXfD
ONzBOrpjnTywzvdKXDxLXL1wbt64uz44d1+8hx/e8z7By5/gHUDweVjqG1jqF1TmH1wW
EEJ8EEoMfEQMCisPDi8PeVIRGlERFln5+FlleFRVRHRVZEz109jqqDhS9HNSTHxNbEJN
3Mva+MS6F0l1Ca/JicnkVyn1SW/rk1MbUtIa3rxvTE2npGVQ3n1oSs9syshq/vipJTO7
JSun9fOX1uzctpy89txv7V/zqXkF1PzCjoIfnd+LOguLu4ogXcXQbgBGg8JpMGQPHNWL
QPeiMHR0CR2D68Pi+3GEfnzpAIE4WFo+SKwYKq8cqqgarqweqSKNkGoZNXWjteTRunom
uYFZ3zjWQGFRmlhNzezmFnZLG6e1ndNGHW/v4FI7uR1dvM5uXhdtortngtY72UPn9/bx
6X1Tff1T/QPTA4PTg0OCoWHB8IhwhCFkjIoYTNEoc4Y5NjPGmmWxZ9mcOQ54fH6cO8/l
LfAmdk5Miif5Yj5fwp+STE1LpwVSAVi4KBQuikQy0YxsBjy7NDu3NAeel8+DF+QLCwqx
WCGWKCSSZYl0WQpeXFncLZOtgpeWdsvX5GDFmmKnUrGsXAavKFdW1neurq/uXdtY26vc
UO7cBK+v/72xAd7au7m5/8+trX/u8+vP/9re3v4NEhkbcQplbmRzdHJlYW0KZW5kb2Jq
Cjk3IDAgb2JqCjcwNwplbmRvYmoKOTggMCBvYmoKPDwgL0xlbmd0aCA5OSAwIFIgL1R5
cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNTYgL0hlaWdodAoxIC9D
b2xvclNwYWNlIC9EZXZpY2VHcmF5IC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAv
RmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnja+/9/ZAMACAD/AQplbmRzdHJlYW0KZW5kb2Jq
Cjk5IDAgb2JqCjEyCmVuZG9iagoxMDEgMCBvYmoKPDwgL0xlbmd0aCAxMDMgMCBSIC9G
aWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42s1bTW8juRG981f0JcAusNNLFr+K
OeYLyCFAgkyQy140sjxWYku7lgxn/n1eUepuihS1mcxgvTOLtT14IouvilWvqts/DX8b
fhpswH+jxh8fh0h68E4Pz5vhn8Nu+P73BzOsD4PJfw9rAft4QocMfndCq/v/eS096NF4
Ss4YxreBrPxgZfWf8DPZlP8onZHTj7K0Pq2chvXT8Lv3g88I+WK81gN5M7x/Gr7/kxnx
L8P7++EbQ98O7/+l/vgexl03z6ZRVnezkX/dPK83Px5fVo/D8xYf8cGOGjaw7KXeuVHH
kz2Ox2jyRx37kVlrJ3Z9/+cnY4c/7Ls7nglRV8h1cfSEHd3o8nJ6dHkz74Z3p+9Zuygf
b9lWX8b2cMm2atk2Z7rlq9EhDmSIT4TTTPjff1w9DX9f7583QvwgxKvPiAv8/Wy72GYM
vpD3g4mRTkbZ2agfyPnZnM8h7mfNqYJSXZhjXWlOwVG2ZcE5rUfPZBb0Nz9+qy4h3iAk
HDacIat6lRRHtkLvDHk6Q9QZ4qMZEwVckxkyVKv45BHgjGifIYcCovAlONgCRsMCWVer
BI5jjNq4BbKvINHyGCKlqGbIcw2BuUZTKDbaVBA2cXSO6bSRunYidgh6rWNx6G0NwRWP
3ppYHvrSAcnAzYmj71OXrB2RgohaXiYHpJhGnwL3vYjz+jE5Kph7vIQoo12CLS72+Tca
bnRO2wXyUkOMC6N11qjeRoCENLpUOroxF1E7sjO08H9sIM7i0OaGF5FHkIVt6aK7in9j
4UZ2ffaNhRNTKon7TcW+cYg5zTdXccGM5DRfp19lCLvRwtn9eEKGRCJ3vljl3w3E25GT
carPCqIWiSakoe8hZPPRcirCv7ElwM/elbH90ECS3CIXytta0R9R7ayLNy60QXVC/Gsq
nXhKuupvwy9WAwxLebqSdYc3qACGo71qzFNNHq7z6HRZAuoMBKmBLOXKS/KxWoW0c2O4
qBLDG7iAdJHhylNvG3sTCpJ3rK4WmwwxuLNWl5lsaCC4s85TWC5BswrhQsbEtqywNcRD
z2lDZbK79AChuo7alRfyqR9UFb3qC4KqUTnKhGA+T+V0vK2+2JyscmCOqpz9h0bl+NFA
1Z7QVzOeqBxPENzz+ZpqAg08Ugz9NfB5aFwjufcEUY2u8PC0RqGOyyr1fQyWRuOi1PIJ
sq2iIXg/UsrFfILsagGjw0ha2pLG3KkmRU/Izlwg7mpxoi2iWye7QKoboJgCJI61aYF8
qFeJqEga5WKBfKr1C2oJe8NG9TYaJEuhLymZqxWBZCnrEi9B0VYtbVCSdGlLC0FfFkBM
eegqH+I0I+to+140EAVj0pb6/KMpgmpzXGzUiCkiUW3OLZCHWhMQoz1Lkfq8GAsnsaMb
4WIsnBQhrFURdLU+gSaAOi/i5dBA4CRorrg4oOHFkxkRLuHGKj7EMbCnGw7wCbbY8jL+
8E0jLQyjt+EbDgjodqGmilXGZhEW3RaKQ3+sHSDtRGJON1aJQe60Kdz4XQNhudOW+zcA
GYyhlcKtqGOWO33OHepqMCTikTkWvPyngUTYYq274YCUUBvZF4fet4oA+ZK5YPe+cgBK
Y5QBh+nmF1RYRJ1JJXWrygEk7YTPYrV3p0naicDJ34IkknbihgNIOo6U3I0bQARPI7x5
cUB9p1HKWcLb36DO+iShWxz6uREEMFcbNv1yRNJzoDXh1tzZAdJQRF3y8sO3n1fI1VfS
FdKWnAv5F+qK08bqS3WFn0Z64FmdzPlHX1ec0U1AzLpigqhWesj0JObmfVqlLsReBn7R
lRvVN7IYsEyQbX/AMkF2VUAEhwjnHFbLRpU+wVVCS0zFKvvqRsIvuNbRmHajZcCikXpl
gjlDrg1YCPeEVNcWGbCg3EjXcc2WDIHORwPPNAfYnIaWAYsMNYxJ/UMnR1LYQuGAYz2m
CTLOdbpw40M7YZESGlJ7aLVICymh5Pq2GI3iZ5MrVrmvaxK0BQqOt31e8oRFu9LT7RAG
OYa0DqoPkZRob+5DAUrU+7Tw/9qID2sQmDIE6IWusd6NRPEiolStT3AbqYyFj40+8cgd
VjRkTe4yqIHKN1l8TJDGXI9WF21hsVFdkrI+gRQtwuVToyyQx0Iq7+uhFR9Iha7k/7f/
Zzb8/Acc0efP4YuVu4M2oGn6LOmfe8Tx1Vr8xZwc1bM5xWj75cNh/bz9sHkenlafhvV+
d7/9+ILdV7th9XLcP62O2/W7u83j5rjd74bjw/Pm8LB/PE37vs4R1Ocwar3pMfqLDE0q
Rm1R7soHKgd5oDJsd+vHl7vNHb4ZdpvXd0+r7eOw2x+399v1Svg8vBWN5OnXRONszrXA
PFSRmVlcP243u+Nw3A/73eOn4X5zXD8MT5vDYfVx8xas5mNA1dTHeH3YHzZTOByGD5vH
/euwGu4+7VZP2/Ub3KcQ8+fwxUkHgQr+poGwmOMDFebUk9cFF9AKUwxRnqukspAUEM9S
Xmk537mQFBB53kJZVABSPIdaINHYEZVGnmb1NorQqZpY+qwJ8pg9WUAgGLzXprDlWK8C
sRW9dnaBbM4QdYawtJ90trZ49rYswij1kIehWKQ6kOJo0SxT6FvCwkoCZoE8VJCESIB8
MV51TUnSt/v8kKM+zwyRRw9wkV/oP1QQo7GTlWfgXVvMqRN2Bbf7in5oughyS1oe61Vk
6ESRC8hdRT8WkTma9l1yRfZ59CxUQO4LiBIIiS1EXJpbrSJDbee86TvakDzOYmbVt8Vq
GpPR3HcA1COEN0daHLBqIHLoIHOpaZV1DXHGQTFrU/qocoBDYHIgd4M6F+WhWBn/h9oB
3qBnCTreOJGXlzHyM8l6ldkBHtQFY/11SF5F0kvgVNy0bQNB/0Twt+q7MbA0aq64R7vb
GlR9nadZSKmqzvDa3sjwtwuO+nJzCvpPGX4yZ8nwd3VuRvTimlCa0RfOlqUCojcifOMC
+bFeBS7wZK6vccrviJcUXVQzZNfkdxQSk4pd7prcLf2gSSdb1bV4kY4cCUiGt719GPsQ
LolfIB+re8SykWYZsE+Q+h4l2chqV2y0r+5Rko38qZB0bJEZJVhJnY3yPdLyFkcqV3lq
U3NAPbKxteUiNWMVdQMh5pqcmTv84xrCXHR7C/9NepG06y7IvZp2zQW5z3Uek7SL/8U+
/zntBq8L/td1HpO0G3NHPkGa9GLl0C6VplzWcWPFlESx3WdJqaKSQiqYe2kgwYwp5ULe
c6LPq5T8N/lSns1Z5+LC/7GByE10Bf1NpQnwUMjvUy1RWdGfNZ2zfOPMJ02nqb3yM/3R
koRcwdx39SpZ0xkON8I/a7o8V+zSwjqg0pR+bvhn1CuEg1P9EzEc7fKj0QnSSKBEfkRA
mBvxn5xFWKZ0wwEJLop5ULec6NIBJHeeTZmU640oKzZb3qJt5QDSogZ8mTnum1VEdviS
utoBJG9L+VhUtyboKOu+WF6AhwaCkIIyLy7ApoHkjdjcODSJBNK6cMChgSCkEDS+Hwwo
dkYeExa8fKgdYBG7uCSmH3Xy7tEYUvT9BERIlZKX++lFnoCg/prI13NUdoAM6FHzY2lu
vYq8KhJM6hdgFCLUNJvfkOvZ4hEviYluOMBDPaJ7on4FJi+PfSg01N3UP+qryLFshpo7
3ATmK/lTn9lzREWz0U7gi3KV1Q+6wRAgk2ZE0wEHP0YnVWRC1Lk9Im9oZI+kJkTNWpTX
AJ1BvzghGnmE9ETBen9GqPPsuFAtJO6D7J7XqPMtyy5artiEyA4uVCx0EZyX4nKWRmFJ
gfG4YVctlaVSHhpIyr7Y5aKvFUV5i9MERYOGyTnVXQPZAgndLWd5uNbUGnPaLzP2ck04
sV0O2/R/RuQxU7xEqBKB+IjyGu6E+NSsgfhgba96JZc4I00m9ekyqLMjy6tVE6Lpx0g6
TGStma5GGMhjX8CWkzQFkGROIMl1omt8o1E+O/MrmuTP1ixZ5C+rT8PqMU8X1+vN4SCj
0WkeOrw+bNcPw+sGtuz2x+Fu/7p73K/uNndvNCmFgKrtfzlsdx+HFYz8MHx43r8eNs/f
DZvjenyjyWhg/SsajIZ2snxsyoaTq2JJncFN8gmSjEnK4ITYNGVDWoKk+YxQzb0/d9Xo
caY1Dtfbam9nxEuVn85dNc/HasTDqasWrXNtF1mKcx7lYpc6d8i0E/JNL2s0I9Mkz+Q5
ppmx7ZWOGnU2xq6l0lBDwcx8qCujTnQlXt7+79mBhG5GJ2+9TYi6BOa365I8JZkQbb+d
MyXk1oRYNSl9GnNOiLYqyBzOF5ZeGXJCpkbIyQnR5nQjv3AVFjse2l7bodIm6jJmshiO
frFj104vSYIs9RmzorllLjMhmsmBlV0cXb0M6tRD85gQYzOimRzLm3vOade9UPl3D7wJ
3CfMiyA3sb+Eh0JCI+NnvpqW1cvrU8D1/SYtONvoLmOw5CuIGWz6ucEEJ6+bRt+PsPPU
0/Q5jzJd9WGxo22/nUavxEsWG9oGXd771ovjmmmOpA8no/iJsebGMdSvDYH6jIkuZS5y
1LpmTFRnCsVtabtqwzIcNJeZsGRM0kcM1nWzqZH0wfJqXM8v6Lpl2B9slzE03cgvtjjL
se257RiQCmfG9m0/DUEYNHcZIwM7QBhf5kpVImQX7ftHQWEZgzxOu7ZJbjzl1V6c2HVD
DPUtp0rfDQ+ysosr0v5r20eTvO+cugkIbbQdpa+fCXtsEAj1/NsfXTscdoGCpssAUhc9
tAyafD+JIZdqmdCZbhZDexxlQOf7a8grvzqEftoneevGM4duFiMZz0VO9Wl/2ecdWSmZ
8D8rpQk81yjVKqUz4oZSOiPqp62FUjojmhY8t5xRCswZsW8abFlDG6cmxIemwZZff5Me
akI0zbHsgtztzog2VM9PHwo+NoXz/gvMdwcRCmVuZHN0cmVhbQplbmRvYmoKMTAzIDAg
b2JqCjM2NzAKZW5kb2JqCjEwMCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDY1
IDAgUiAvUmVzb3VyY2VzIDEwMiAwIFIgL0NvbnRlbnRzIDEwMSAwIFIKL01lZGlhQm94
IFswIDAgNzkyIDYxMl0gPj4KZW5kb2JqCjEwMiAwIG9iago8PCAvUHJvY1NldCBbIC9Q
REYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAv
Q3MxCjUgMCBSID4+IC9Gb250IDw8IC9GMy4wIDIxIDAgUiAvRjEuMCA2IDAgUiAvRjIu
MCA5IDAgUiA+PiAvWE9iamVjdAo8PCAvSW0xMyAxMDQgMCBSID4+ID4+CmVuZG9iagox
MDQgMCBvYmoKPDwgL0xlbmd0aCAxMDUgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl
IC9JbWFnZSAvV2lkdGggMjU2IC9IZWlnaHQKMSAvQ29sb3JTcGFjZSA1IDAgUiAvU01h
c2sgMTA2IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl
Cj4+CnN0cmVhbQp42m3CezDTAQAA4P7rrruu67q6urq66sqbPPMIeSR5hCIconAkUTiS
JIqiKJJI/PZ+2Ma8hmGe8xjzntlmY2zz2mY2j3mUfrgr3fXdd0AFOKgCHFIFDqsBR9SA
o+rAMQ3guCZwQgtyUgtyShtyWgdy5grkrC7knB7kvB70gj70ogH0kiH0shFU5SpU1Rim
bgLTMIVpmsG0zeA61+BXzOG6FnB9S7jBdYShFcLIGmFsgzCxRZreQJrZIc3tURa3UJYO
KCtHlLUT2sYZbXsbbeeCuemKsXfDONzBOrpjnTywzvdKXDxLXL1wbt64uz44d1+8hx/e
8z7By5/gHUDweVjqG1jqF1TmH1wWEEJ8EEoMfEQMCisPDi8PeVIRGlERFln5+FlleFRV
RHRVZEz109jqqDhS9HNSTHxNbEJN3Mva+MS6F0l1Ca/JicnkVyn1SW/rk1MbUtIa3rxv
TE2npGVQ3n1oSs9syshq/vipJTO7JSun9fOX1uzctpy89txv7V/zqXkF1PzCjoIfnd+L
OguLu4ogXcXQbgBGg8JpMGQPHNWLQPeiMHR0CR2D68Pi+3GEfnzpAIE4WFo+SKwYKq8c
qqgarqweqSKNkGoZNXWjteTRunomuYFZ3zjWQGFRmlhNzezmFnZLG6e1ndNGHW/v4FI7
uR1dvM5uXhdtortngtY72UPn9/bx6X1Tff1T/QPTA4PTg0OCoWHB8IhwhCFkjIoYTNEo
c4Y5NjPGmmWxZ9mcOQ54fH6cO8/lLfAmdk5Miif5Yj5fwp+STE1LpwVSAVi4KBQuikQy
0YxsBjy7NDu3NAeel8+DF+QLCwqxWCGWKCSSZYl0WQpeXFncLZOtgpeWdsvX5GDFmmKn
UrGsXAavKFdW1neurq/uXdtY26vcUO7cBK+v/72xAd7au7m5/8+trX/u8+vP/9re3v4N
EhkbcQplbmRzdHJlYW0KZW5kb2JqCjEwNSAwIG9iago3MDcKZW5kb2JqCjEwNiAwIG9i
ago8PCAvTGVuZ3RoIDEwNyAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl
IC9XaWR0aCAyNTYgL0hlaWdodAoxIC9Db2xvclNwYWNlIC9EZXZpY2VHcmF5IC9CaXRz
UGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnja+/9/
ZAMACAD/AQplbmRzdHJlYW0KZW5kb2JqCjEwNyAwIG9iagoxMgplbmRvYmoKMTA5IDAg
b2JqCjw8IC9MZW5ndGggMTExIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJl
YW0KeNrNW0tzHDcOvvNX9NGustsE+L5uNqnKYWsfUdVefNFjbCmRLGc0Ssr76/cDZ7qb
IpudrK2y13ZZfkAkCHwAPoCcX4d/Dr8OxuPXqPHDhSGwHpzVw343/Hv4MLz57oGGy4eB
8s+HSxF24Sjts/Dro7R696fX0oMeyXGyRBF/9GzkL0ZW/xV/Z5PyD6Wz5PRXWVofV07D
5d3wl7PBZQn5Qk7rgR0NZ3fDmx9oxL8MZ++GF2ReDmc/q+/PoNy6eiaNsrqdlfzHbn+5
+3h4PL8d9jf4FufNqKFDlL3UazvqcNTHxjFQ/lYb3Rij1lb0evPjHdnhr/fdHU8GUSvG
tWF0jB3taPNyerR5M2eH18c/R22DfHtrbfVl1h6eWlu11qaTueWrd3Fg4ni0N8/2/unx
4uFyf3Ox2w8/Hc4PN5fDvx5vdw8v1dnPw4YTVrXGzxUd1SYiosnfhy/s3EDB26OGZtbw
LVsnmIA66hnU2TbZoo6xpTqLwf6edVnkrE5jpBiMmqRfHGoRA5T4pNO84IvrWiRGoIUS
ZxElIrtKxBmLjcKi1Yt9LeHDyLLKIvJ7duQi4g1O4t1pnyxyU63inRuZoomLyMNJRJ1E
giYcyCS/iNTaBkQGTlz49MVQiCgRCQh7z5oWkV+qVXDe0ergihN9qEV8HA1py4v97yuR
RAknMuxLu1QiEWnCPLF/vRFpOCAZG9dPdBRxcdTAwiJyXjmAoOpoDafWuouI02MI0dYb
fd0AIAq2iIAlRde2Iyw3Bpuc6sKbOCGROTZ92JEhMyJZxsUDh0bEAnfOcQ27zUSlPsMw
nUSlTmrEuJoa3vyxMqWX1Jcpc7KJpQWzpZcuauNZzyPisQDebSMS/Ug6WlXAtxJxSCDW
FdC8bCQCymw65Qa1RPWXVxP1v9jF83r+zqGkSkHQAk6hSA5vX9Rn8kKgyshfUswJE4E9
rKtjPzsjdafRRO26+QNmjzw6U0TJx3qRaAzSh4tD30UxIBwjFV5sMkyCtsRhIwelAD+H
kw2zF980IsmNpZUbyLG2HvQoxBJyqhLxafRR89DN3mAtenTRtJBTs4SH8TmGfiFh5P+R
gy2A+/ZlVY+YkV4029RP8MxgehQC94OIoceI/O5VN9Ux6hX4Im3UAHA+P0YOvp8N2aBm
IdioXuXrZsNM27zdom1/HPfqGdSZaZta1FnC/qyyngF4k+ZjAlgHngV6Ea7ezws2eLBA
b3KRilXqIHBAb/Ra8iFE1pmd8DawMjt0N3Konwa/0SKya6idH4O2kuAnkXc1tZM+xdmT
Lk9EpljyiaELsny5UUXtTEQV1sU+VQ1Q4C5jTF4S5iRyaJgdj976uICnCZNonBQSw4v9
f6tFkC/J2tRXFmlhtEmfVMnmf1WLOIIqaLH65k/BQhVnC/N/qImdZqTDFDcMRxpJVVsT
WxE1ky4CnY2lLlcNPQToODGvq6uyCLxoLRrPrv2JgUvC0fv4R4FAPkwh9fEPXmdHdtr2
8Q/S5kaaALWKfzKJ4KQY+w4AzbEgkMQl6FRNcPQI3lGs8thwEyIAMxWgq1sbcqDwSF28
YToXkTuS8+umyw6QYIypzC53DR0gUdfafgBQQMeBYxUO+E8jEhy6QkMbqIuMIHGxSEBX
LWVA4va0EQGEeJYmKpWerhyQ0PMBnQXqPrWcAfTFs2k3mou5Jj9CldD6qCANoLK+RN1j
XctJuglvNhIzWAOC2nva2AjLjBKSqpfqIOLQorpQQGrfMoI0xhiKCFhhBHlm5TfUNd6M
ybLtVwDwF1TJGKnW5euWYDACRdLrfQkjmAiKeg5GMIg6qp58NYMcoZlMR+n1QQ6KiTHs
eD5f42xJQsEDOMsqN82sB45EWIdZrWbWsMx6pkXe1xLIQbCYsYvIQ3/WM4kM/VlPfeaZ
EESJtVjqct8QAsRaIBfXN8qzHkQJqLUuVqkBHnUAifexWKVOZdGh2gS2XnVPFAPCkW0M
yyp3K/UerCwW9q97qJQCsgf4SR8Lx3pPvlC3qUgaBTR5LnzUDEZQh7GT4/bQ6km9J11s
dLVazMm4vgOILRogXxyo6RslTXns1gcdajliBIRL9VcxEZXP99FPkqQ08ayraidtuZKD
M5TYrmsw0MJeSOjiIFWPKhw2og3452KPWh1aB83Wxx6IIu/6qCSJIktlyJ/X1peJKWIg
bPgwODDiXNS6G4ENI8t56qcfxDKd5gPdQ0sUuVwlJvi/a0QQ9MZsujFpHDpRqW1NBxBn
0fjizLftlMGOKabWKgsbQJTFRLEPBRZWzSaYPvhZo9sDq/b9HMYAnbDqws9NHSeZbDFz
P/sgDnHmYDfSHAgDjyGc1FWruhhtTkORHlrYZCcWZ/70ra5srDb/T1c2szpLpf++V+nV
JN3WaDYj2LfnecGWDADeNlqoKCJqLbs7jTCKIRarNL2/XEoaKeOTxL6KIxdJcpROi0hT
xrUdDZLZcvwZdqqt9JNIHY0e8DZBx2KVuq8JjFIUjC9WqQmxNCReBoyLSHOrw1IWrcyZ
eyeK0jSi/6FllWYqC0aNShNOyqi1YEviRhmK9E+drMwOORU71Xc20rSAmNjUPzWBvI+5
gaoPPRcSLV2jS4VdXjdkAF1AoK6uCv8vxZWLbW7a6YCU11LXpnaifxqN1wX82+mAdJ6Z
c8zmf9nIeOQ6T7yYvx0PRCnBUl/XEHXkC6jSibzrBwAODWA+icWhM0EoNvpY299aHq0m
149FklvYYEsP7OtC7oBdCmUANI29Q7EBSw0bTvIUwVKlj+h6AOQTG5Uh3RzagxgaLuC/
cnEBIqvzVeK0SnN7F8SNaTm0akmqDOvkWcPGiWRYl1yJzIaPoR0fg+a44YAk3NBmV1Qx
MrsxmQBdSk+3rELooyNeVze7Ue57EbO+HyXorfRobdqoACzXvYReQfWjhI9hrzfAC26f
RmknFkc2O+XAd4VdrhuJCLvk673FutV4IAe1Jr+hikwz2JnUwntmZAYM09iU+m4EGQuj
T6W6DzUjQ48GT9OG/W3QKJ5lYqh7DXbkUTy5CKP3jYiHKqYJ+i5PUp9JTFqepCqeJHcN
nzsRUc90ZXM0fuZJszp/aiJykm7mbAUJmkTq0millzZynlnkukOC1CzR3H+gk44xDzEn
kRowklPZ0Olsq2HkwSpSJGl9plX2KyTIUnnkmyqMiscvk0jdwEorZ70UiUnifRVFEQzf
+ORN/zywKsiA40LZuq+ZGFAhcrdGb7yR4jmJtMMO6KITL9b/tMpunI1D10EkM9moAy3W
v+jRm2mN3Sp3cUWwYJv6+UwEF9OxDzcClxudM4V77usawhGp3Xnb9yDlLOdS4Z93dQ3B
fyOdljho37Sgj2ZfurAZqVhjQO9tUqsxdqIlyJU++D5qSTIhAs0u1m+M68RBtjjQVctK
4B/r4ob5T/caPPS19ShEUVMLbFVda2wZTuaFnBKteyibP2rEu6a0YduYPWTDBmxl0oGi
V4D/vH0sEUefeUt3FRl1hPwwaTL/7w0PgIdcsH30H281KBUi9Q3L8VaD2fRVyUwBQFgx
bvFcQh9ff/TQn+89NKfiyFUqVVACORtpbONAwv6JN2CLdB3kQVdQq1F2FEHONnorf7GQ
f+9OSFCrtzTyBDOlMoS+xcsxttGuVt63huhPXo2oZyIC2YmSagm2/eKbGvVMbzeyOurz
rVN7S32BOlZCfrYO1FFHdf62QnCCTbTYskmKQnAEofOCqoGoS1YQKrfK0yrXa/RFa2Hn
k0idoKUl1I5jsUrzfIMQUOh/7CJyXr/vRUsYrJWmZRJp2ImWl66p2KfK4Uom0aD5OvRV
kcsaF4MvLLdv3u7KOAPkUBVnrkRyBV1s2yaR3BCyZjPDq51DaHkacJJYr7HaylsHDn3r
gwTJe2XXN9uRAzntW6wU9z3y1MEU/mmYFDg58qY36xupaTqTcnmcRBqmZKSC2mA3ziwX
Pj4EUj03y3RGalKJhIu1xxvo0+xi/nb0AnV1iBuqWNBUp0Moz9zc+CTpks3QxQrlD4fk
ZmQSOTQvQJKGi4RUTyL37XBGKk5M6xsdX4B4ucIlO/QtJ0wJ3LxY5UP7AiTKRWRQfUSF
KJPdErmHtflN8uw37C9UCXjgNik8ufEBLgsfXbVXPl5w6TcckOR1qk7UD4A8efFUQnfl
zkee2wa3nluOL0BY2hrDfV3ynY91ZcpdvfNB41mkn5bmsJPGsx9oLA+pXPChb//MhBLz
BlxYXr/rYAvo/lbzQxPl9rvM27uWCSEBeZdKL36jqxoduCZCdftqCfUsOflswUm6OZH1
brQ23xZPIjVc5NlXiIEoi6hVERnlGfZpWeV85ZbFhigFYBJ5X5dfJ/eMp33Wq69cBHOe
DdTaztUXZAH/V+4zNJcsqK1I3cWZD/VVTYroA1yhyv3KgAEVOJn+PvldmNF2sf7jyg0L
CjAVyn5ceTwZpR8/Cqi28ZRL3pA/VdGz/fHpZCYty4Hr4ptwHmND3/gkAU+5aalP/OS1
hclT9Ulk396fkLzxWRDcjMWI82V+icnb9nWlvNwLfkNdIy/3vDyAfYqVr/FRCuRWkcEX
g6qQVpoEw/qPPqv5bJlj0cY6s2hTzC53t7vLw3D/YTe8fXG/H+7u97u3L7H75e7mt93V
cLd7eDh//xU/2PjUftHZnv2+SuZ9ar9Zm8V+P364urk8P+yGw/X5YTi/vZ0tNvx+fXN5
PdydH/D74Xo3nN2/Gn7Y39+9Gr67fPUN7CknCG3p+Onx4mdA4NUA71/cX30aHq7vH2+v
hovdsLuB3vjX2/vLX4AFCJxfykeGd1djof9/AR4DsWUKZW5kc3RyZWFtCmVuZG9iagox
MTEgMCBvYmoKMzU5OQplbmRvYmoKMTA4IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJl
bnQgMTE0IDAgUiAvUmVzb3VyY2VzIDExMCAwIFIgL0NvbnRlbnRzIDEwOSAwIFIKL01l
ZGlhQm94IFswIDAgNzkyIDYxMl0gPj4KZW5kb2JqCjExMCAwIG9iago8PCAvUHJvY1Nl
dCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFj
ZSA8PCAvQ3MxCjUgMCBSID4+IC9Gb250IDw8IC9GMy4wIDIxIDAgUiAvRjEuMCA2IDAg
UiAvRjIuMCA5IDAgUiA+PiAvWE9iamVjdAo8PCAvSW0xNCAxMTIgMCBSID4+ID4+CmVu
ZG9iagoxMTIgMCBvYmoKPDwgL0xlbmd0aCAxMTMgMCBSIC9UeXBlIC9YT2JqZWN0IC9T
dWJ0eXBlIC9JbWFnZSAvV2lkdGggMjU2IC9IZWlnaHQKMSAvQ29sb3JTcGFjZSA1IDAg
UiAvU01hc2sgMTE1IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRl
RGVjb2RlCj4+CnN0cmVhbQp42m3CezDTAQAA4P7rrruu67q6urq66sqbPPMIeSR5hCIc
onAkUTiSJIqiKJJI/PZ+2Ma8hmGe8xjzntlmY2zz2mY2j3mUfrgr3fXdd0AFOKgCHFIF
DqsBR9SAo+rAMQ3guCZwQgtyUgtyShtyWgdy5grkrC7knB7kvB70gj70ogH0kiH0shFU
5SpU1RimbgLTMIVpmsG0zeA61+BXzOG6FnB9S7jBdYShFcLIGmFsgzCxRZreQJrZIc3t
URa3UJYOKCtHlLUT2sYZbXsbbeeCuemKsXfDONzBOrpjnTywzvdKXDxLXL1wbt64uz44
d1+8hx/e8z7By5/gHUDweVjqG1jqF1TmH1wWEEJ8EEoMfEQMCisPDi8PeVIRGlERFln5
+FlleFRVRHRVZEz109jqqDhS9HNSTHxNbEJN3Mva+MS6F0l1Ca/JicnkVyn1SW/rk1Mb
UtIa3rxvTE2npGVQ3n1oSs9syshq/vipJTO7JSun9fOX1uzctpy89txv7V/zqXkF1PzC
joIfnd+LOguLu4ogXcXQbgBGg8JpMGQPHNWLQPeiMHR0CR2D68Pi+3GEfnzpAIE4WFo+
SKwYKq8cqqgarqweqSKNkGoZNXWjteTRunomuYFZ3zjWQGFRmlhNzezmFnZLG6e1ndNG
HW/v4FI7uR1dvM5uXhdtortngtY72UPn9/bx6X1Tff1T/QPTA4PTg0OCoWHB8IhwhCFk
jIoYTNEoc4Y5NjPGmmWxZ9mcOQ54fH6cO8/lLfAmdk5Miif5Yj5fwp+STE1LpwVSAVi4
KBQuikQy0YxsBjy7NDu3NAeel8+DF+QLCwqxWCGWKCSSZYl0WQpeXFncLZOtgpeWdsvX
5GDFmmKnUrGsXAavKFdW1neurq/uXdtY26vcUO7cBK+v/72xAd7au7m5/8+trX/u8+vP
/9re3v4NEhkbcQplbmRzdHJlYW0KZW5kb2JqCjExMyAwIG9iago3MDcKZW5kb2JqCjEx
NSAwIG9iago8PCAvTGVuZ3RoIDExNiAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg
L0ltYWdlIC9XaWR0aCAyNTYgL0hlaWdodAoxIC9Db2xvclNwYWNlIC9EZXZpY2VHcmF5
IC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFt
Cnja+/9/ZAMACAD/AQplbmRzdHJlYW0KZW5kb2JqCjExNiAwIG9iagoxMgplbmRvYmoK
MTE4IDAgb2JqCjw8IC9MZW5ndGggMTIwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+
PgpzdHJlYW0KeNqlUstOwzAQvPsr5kgl6u76ETtXoJW4gRSJC5dSUihqSJukgs/HdgIS
fQkJO9La0ezsaDxb3GMLnYVPUljWwSmCNYSmxAPeMbluGYsWnHa7iGDrenSWwOMeLZZ/
5iKQZKtyw+zDMVM6XnRk34a70nlaghLy+xqpqWfOsahwVcAmRCxsiaAso6gwmbEMf1As
ccFmhOJNTIsg7rg8ncvIbn5E3pXNotx0u/kazSq02ExLChp8nCXGRpLr9RgvHadW4630
nshEXZPbii1u6pMTB0PEEXONk1aFiUaaREfSpGHWYNyfPRkX2w/dFv9zG7/dFodu82B3
rE47KPaq91v9+D1brbuywc1qvq5fMP2cV5t1ORLFG848wVHNYR9RKM7mgWlQGGrmQiAo
0/sKHy+WTV1hunuum/klnnYd2tf6o0X3WmJTr967x9FvwYqsVGBFQ+i1Z2nzGAitTscm
orKA5xTjiNznGbKSDVn5AvDKzHIKZW5kc3RyZWFtCmVuZG9iagoxMjAgMCBvYmoKMzY4
CmVuZG9iagoxMTcgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAxMTQgMCBSIC9S
ZXNvdXJjZXMgMTE5IDAgUiAvQ29udGVudHMgMTE4IDAgUgovTWVkaWFCb3ggWzAgMCA3
OTIgNjEyXSA+PgplbmRvYmoKMTE5IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4
dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9Db2xvclNwYWNlIDw8IC9DczEKNSAw
IFIgPj4gL0ZvbnQgPDwgL0YxLjAgNiAwIFIgL0YyLjAgOSAwIFIgPj4gL1hPYmplY3Qg
PDwgL0ltMTYgMTIzIDAgUgovSW0xNSAxMjEgMCBSID4+ID4+CmVuZG9iagoxMjMgMCBv
YmoKPDwgL0xlbmd0aCAxMjQgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn
ZSAvV2lkdGggMzUxIC9IZWlnaHQKMjk4IC9Db2xvclNwYWNlIDUgMCBSIC9JbnRlcnBv
bGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlcgovRmxhdGVEZWNvZGUg
Pj4Kc3RyZWFtCnja7H0JnB1Ftf5NMtkBWUQfIgKCKDsoKE/x6ROfCigqvicIAiLgwhNZ
DQSyT/aQkAUIkA2yTzLZSCBk32afJDOZmawzmf1u3X27737vrP3/ur/MoZnJ5BH+2bn1
61/futVV1dVVdU6dc+rUOS6Xq0uXLmlpaS6Xi3eXneJKhZMaOARdu3blXxkaeSoZ2j06
bD1SVbdu3f7PV3fv3r1dWUbkjR2rkjgiR25PKpyyQUZWRlBmF8eXcZmTqXDSx0vwgBPe
nYOF0KtXr/+zHicIH3l8+ZSvdkK9EykJDsHfHj16INKzZ892yCQVTrvFCKF3794cXKQI
rkCEEwCjLNMgFU5WwFgICHNcnOOFFI6mgOQRquKAEpY/zeC2QwKChZwLiiAQ5wQDlhBk
khrB0ytwhrRbdGTa+Hy+cDhcX1/v9/sDgYAnFU5qcLvdGBFEMCKKotTU1GBc3Haorq42
DIMpzIDEzuqpra31er3IUFlZiQpVVcXfurq6zvKjThRBBmTmG1E/4rquV1VVaZpWZwek
sFo2Fe1hTpRNjd3pGDg3EMFkA4ogNUj8D7oUiciAIcbQY4jdqXBSA4ZAYB9giNFhBImE
TeQBfgC0Mltn9eApsvnswNqAWwTPHDYQHeEtnC2CBFCQk4RvRwuJN/hIsApWFuKrVDiN
AnE+h74j6chpgPmA+YbplMKlJzcIHsB4EbFPmzZt1KhR5eXlBEYs5YhMnz59woQJRxiv
0aNHf+UrX8GYoh4iE+KZzvKTdESYOnXqGDuMs8OaNWtQcO7cuStXrkQ2NOwHP/jBCy+8
wKowbTivEDly/alwylIOGHRigHZCqt69e+MRKE9kO3jwIJF/KpzEQLRA+gER4ITvfe97
YAaBCriOY7BA55999tlE7J3VM2zYsOuvvx5oAaUw7hhckoWd5WflyIbXXXfddQ8++OAD
Dzzwhz/8Yfbs2ZgVd911V3p6OmH/lltuee6550jGrFq1qrS0lFiLsyg1gqdXqLUDRhMT
oOMWFflT8owY37pUONmBjAPFBUDpN998c58+fbBe4xHScZ8yZUrfvn0xfEQmhw0gNi69
9FKMKYoAclEPQfgI76WY4qabbnrsscfIkrAZvAMjETkAezzzzDOIlJWVgS1dsmQJERo5
jtTwnXaTjcOH8XVKlRnhhKlpC7WpcFIDgRErOAcFowMC4JFHHsFIFRUVIQWD+OMf/xgp
GEoO2fDhw7Gaf/GLX7z99ttXrFjBgQZbcfnllyOOqp566ql7772XTMGiRYtQ4Re+8IUf
/vCHO3bs4NxAfrwIBAbQ0Y033vjEE09wTeF8QIY777xz5MiRJA/wlqeffhrxb3/722gD
3gL+BX9RZOHChddeey0wxh133LFz505Ujld8/etfX7Bgwa233vqTn/yE1aJJpGlR6mT1
c80pFk5iPzByWOSAROmr6lQ42aHSDgQcrN0Ymu985zvjx4+/+OKLX3rppYqKipKSEhAS
7777bvfu3QFlyDZx4sSNGzcWFxcDA9x9993cnhgwYACgEsVHjBhx2WWXoRTGd9u2bSj7
+uuvA8/8/Oc/R4XITFnl/v37yXoAOdxzzz2gB5YtW7Z69WpkQOKPfvSjJ598EsCOPLfd
dts//vEPxPPy8jB/Zs6cicrRsPz8fOCcadOmoXLkf/755/FGxJHnW9/6FrIhP7EBmnfg
wAG+7vM2vp0hh5PeHgx0RzUYJCJPlR0qU+FkBxIMAFUAzu7du/fu3QvkAPD/5z//iRUf
AAV+//7771+8eDHGjrwAAJMEwMCBA6+44gqMIwqCnABIggE599xzs7Oz9+3bh1Hu37//
JZdcsmrVqqysrH79+mHpx4tQnIJN3MvLy5GIPFjowT785je/4RQCZfK///u/ZC7w6IUX
XkBBxNGG5cuXk/gENrjooos++OADvO5f//oXcAhqKygoSEtLmz17NrABKBOkHLQDvhTv
RamT1c9Vp1g4if1A8MegdEQOGCPk4ZAhfjAVTmoAFJMewFhQVvDNb35z8uTJ69atw2B9
9NFH1113Hdb0OXPmgPYDrCHPm2++efXVVyP9qquu+upXvwqwBdC9/PLLQBQXXnjho48+
CqgHksH9gQceAK4Atrn55ptR5Ac/+AHIBjxCfrwUtSEOygE8C3AO/mJioBTgGpAO2EcE
lX/3u98FFYFHaCqaBBoDbQA6evjhhy+44ILvf//7V1555W12QFmQE2jnmjVr8Ipdu3aR
5UElXKpS8+3UCRiLjgqu5XbAuMs9FU5iwBgRKom0wSxgKR83bhz+AvzB71966aUA4Xnz
5vXs2RMRUP5A+FiaAc7p6elg/zHQGMehQ4defvnl8+fPxxCPHDmSsPzMM88AOZSVlQkL
g0TUvGfPHkA3IBcpN9100xNPPIFKAMKoB48QBxr561//yrUGcbAVKAVgB5cKGgZl8XYw
KX379kWcFAir3bp1K/KAVuHs4nchA6tNzbdTJ2AsOiKH/XbAJJF7KpzEANgByJeWlgJ4
MWSANSCHsWPHIhGMAKAP5D1A7N1338XYASQzMzMBfWvXrgWncO+9955zzjmAO1QyYMCA
b3zjG4hPnTq1R48e77zzDkoBVFEDGJOioiKgiG3btqFavJTTA6OP/GBG/va3vyFCGgZz
BnlABoBT2LlzJ9oDduOpp55CIuIgVAYNGsQ8GzZsOPvss1EWSAMp+Is3gnJAO0E5sFV4
RHSEsgfskBrxUyd0PHOBwcLIcjLsTYWTHShnAFgBEjEiiFx77bWgHJBeWFg4fPhwIAFk
yMjIwNgBwIFG7rzzzu7du5933nmjRo0CYfCLX/wCGUaMGHHRRRcB5LFMA1Eg89y5c5F/
+vTpgGhQHRdffDH4DkwJJJJIQARge8MNN9x3332EX1ROBHXLLbeAciAmAeMADMClpH//
/n369EELCfszZsz42te+xsovueQS5CdyWLlyJZEeiqBCZEZx+dhUOIlBoJ5MYjvkQMzA
YdqTCqdAKCkpAajKiHAhJihxKBEhIHNMAcI5OTmIIOf27dtBFSADK0FxMCbIJjWwTpAQ
BQUFJBVwL7MD8vBdXOKlCB4RnDlP8JfvJRmAvxs3bkQRYDMhIdAMfgICPwqNZIrzRamx
PunBiSg6HubFLOIMxCwqTYVUSIXPUwDg4w4kD/B3nsok5YCFBvgBGYjnd6VCKnyOQ/Fx
Dqfa9wLwAf7gWEEhOA3+MFJkBzQb99zc3OJUSIXPQSg6SeEU7If8/HygCHCFpBZ4ahtx
4AcgBOANtrwwFVIhFT5PgYC/Y8cOIAen9R7egRzwNCcnJysrC2RGqrtSIRU+PwGAj3tB
QcG2bducll5IRbz66qsjR46cMmXKpEmThg8fPi4VUuFzHMYe53Cqfe/kyZNHjx49YcKE
iRMnOskGmhbUNC0ejwcCAUSi0WgoFVLhcxyCxzmcat+rKAqgHg0D+Ds1JIkidF0Ph8NA
DsiJSDAVUiEVPjcBIE8MYBhGOyPGCJodVFUl8dBZoCkw1INKFDvgL+Jerxd3WplDhKbG
8JR1slq0gcZI+QqfzyfvQgY8RREtFVIhFU5SIDx2tFcfsAOhm/fDBsIvTZ4iHolEAONE
CMAYTCSk45Gko2agBfwFaiKuQE6iLHkjsh3hvamQCqlw/AKhkpGOLi3IB8n9CORHPB4H
4APqwaQA6hFhOtACysZiMfx1kh/EIYlEgvhHGC7SIaRkEFK8TCqkwkkPWKM72nMAeBIt
AEiPjB9IPAAJALSTyaQgByRK/YwAISAbMANSInYAXgJuYX4KQCjiIMuDDKnRSYVUOPFB
JJMic3A6LRKRgtAYhw1c60EAiC1rcg1kE+gNh1iCYgc6MkAeRIANWDndH+BO6QSRCfgO
chmpkAqpcIIDhYdOtkLcq316gSQlA8QhXO4J5rhTIElCgm4X8BTEA6AeaIFtYHG+YurU
qZs3bxZBh8gzUyEVUuHEyxxEIOk0Ss/A5Zu8/xHYirS0tFtvvZWcAsLu3bupQEXRAVAE
WQO8orGxkfJJsg8kEhCnvAL3X/7yl2+88QYLolXgUIQxSYVUSIWTzlYIlmAGSh64+neC
HHqcffYXSkpKKEXs16/fl7/85ZdffpnySUA38QYlEm+++da99/53MBi2EU84Go2jehAO
4XAUKXfffTeIB6AsCi6oYpEaplQ4wRK4tisVPiGQdHrE+3Rshd49rfdvf/M/Q4YMA3Qj
8/XXX//b3/564MBXUOuQIYNuueWWK6+88vHH/4Kne/bs+8pFXzvv/C9f9c3r8vJ31ruV
Pz36F/y9+pobBgwcqqnBu+76Jeq5447/uvDCC0eOHJki7VLhhAdFC/gOXYgfumxA0PTD
Xik9h855f/3ss86bM3vBVVd9y+9Xly9ffs899zzwwP0jRqR7ve7Cwny6Tfy3f/tKcXEJ
Mo8dM+FX99wbjTWoWnDylKnfuvr6XSV7tEDIr+gej+/uu391ySWX5ubm5+Xl9enTB2/3
er2p+ZoKJxo/fBItcJ5/3pDDMdFz6No1LRKJnX/+FwsKtj/88MPLli177LHHBg8ebNMj
Wk5ODjiF3r17r127FszCpEmTfnvvr1TNEwxp//Gj74O0iMfBfIRV1RI+/OIXv5g8eTI1
H9CGAwcOUDqRCqlw4nhtIywXON9DlxF1XkZQrvDnh634DHoOvXr1QZaHH/7TX//6929+
85tY6x999NH09HTUefvtlsXR1atXX3XVVevXr1cUZdLk8b/7719GYkow5L/9h7dOeG1M
vbsqFA6ELbGE9otf/Gz69OncvgQ+cbvdojaZCqlwQgJwQlSuj5HDJy/DcaX0HI6wH9q3
b1/c16xZgyJABaj2wQcfGjp0aHFxca9evYArKioqLrzwglWr3vd46ufMnXXLLdfpuido
KK+OG3nrLTdqqqeuvkpRPbqh/OqeO19/HZSDtTEK5LBz5060LbXjnAonMAQ0xWi7EFc1
a7ffb12a9+OLKYeulJ5DpwEYwO/3+3y+0aNHZ2dnA8888sijQ4YMw6M777zzsssu++53
v/vrX//q1u/erAV8e/eVfufbN9x04/X79u6urjp4x09+3Ktn9+uvv/aZZ/6pKL6f/vQn
kydPBEJCJXTWiUiKB06FEyqCU4P2pQdULWAjiDYRpbftOoy4MqXncNiAhT6RsDSi7QPg
8VAowgulwZfU19fbe5rhffvLGhpj4GDQ87VVHkOLRENJUG6eei8GQtcMiheoOI2qUCEo
GmCMFKWbCidW5kCeAvxFMBTU7UsLBVVewZBmXZ+Djc5joucAwPf7vYBlW3kpRAUGRAIB
Ix5PUrkanRkKB8A4oKZgIBrSG+wrEVBC4WAM6CIajqEgUArPfcdiMZ7WTJ2tSIWTiRwO
4Qet7RL9B4eU8kyXSR5WzwGwSc0lHpdA4OEImm4gV2KJEQ+z9YNEHcgBd2pG+XwecGq6
Bfc+YAOfW/d7jEgwofh1KkGJJjZfgQ5HcY/HZ9efCu3V1NvtNAn559xx5k40LWxw+KRI
KhyhP31e/AmqikHqV04B2LNUR7qmhgJa2O8D6xHXAzHtNN/N5HLshGueowRJALKfKsrO
fYpudmDXcelHnt27d2/atGnBggUzZsyYbod33nnn7bffxq/jYpiJa9q0GW+++RYyIP/c
uXOROm0aMk+fOhUps96bNXvWrPemTJmCxBkzps2cOZ0RBLv+ma+//ubs2XPxb3oq2GEG
e8fun5noL0ci49M+Gd58800MEHIiD0cKdxm7VJAec/YnI7NmzXrrrXemTp36Fn7sPsRM
RnT6tHdnvzf/nbdn4Zo5Y84br0+f+iZn+2kc3rEDuwJfmpGRATAvKysj3uCBSlIOdG3D
ODEJLbQUFBQsX7585cqVa9as2bJlS15e3vbt2wsLC/Pz8ws6CbR+v337zq1bs3DPzy8s
KNi+Y8eOvLwc/MvLz9pelLerbAfuW7dtKNyeU7g9dwfS8XT7dmQuLdmbl7s9N8cqVXAs
Qn4n4WTVc7T1y1toE1j+oku322GHHSSOzqcZYabv3LkT99zc3NO9H45t/exPzmT7b15+
YU5RCXotDxcmasH2/B07CtGlJSUlmPbZ2dns5NLSUpRFr57u/SA9gK/bunXr2rVrAebL
li1DOhl84AeiBRAMTj2HaDQKFIFptmTJks2bN+/atau2thaYBIyGx+PB3dd5qK6uRh5Q
bV6PClLN41btS/H6fTWeao+vzuuvL6/cW++tDkY0t6fa56+vqi4Hb4JSdXXummo3SDgU
9PkU37EI3k7CyarnaOt3vgJxt9vNIUCk3g5MYeAA1aEf7YBRQ4Yzox+Obf0Sb+s3d527
GnOy1l2JKepTvLX1NQh4hA60zZ35amurPd7ayqr9Pn8d5i2KnNb9gICv4+ShRQWAOYAd
+KGoqIgix3YCSfwlSwJuAtQCMldUVGCOST0OZi1gXwwf7/8Gg7qdRw+H4j6v4fOEFF9E
UaJ+LeILhOo8qj8Q1MMRr6r5NBRAVr8ROnTcG+weCvq9iqYEjuG+7WHDyarnM9dPDlES
RbDQTvLgFNc4pQ1nTD8cwxexP/k3GDb8uuJR/B4FU1RX9JBfMRTV8Cu6z6+Go5F6T40R
VCIxxacc1PQ6RfWc1v3AWYEekGUFYF5eXg4q4qOPPgJ/gXc59ymIHDjxcnJy1q9fX1VV
BbBlCk21kB+xZRe6QybziXMrRA6aaqEFI9BoBJo87kRNXVLTTa/S4vY16EHT44sqgbjH
r3/9im/itePGjWdFFpb2+S0tlFRwCBglThkjVc1FHYUIgTOHIiYWYTpSjqyy8jnvT0up
JmC4fYZXiRihFr+arPfE1ECzHjAVf0MkbHo8wXq38q2rrwWAjBo9LBpXff6a013VgbNC
LLvyOBWAvbKyct26dWCjkN6OpyBbEY/H6e6KmEGsvbEnQW/YW41hx26OfmgjOKSGwnhj
AFkUv9GQMH2eqOprigTNYNCsrTMVzfRrViQYNqtr4v1fGduly9m33HI7yAy7cgyW1tgQ
CxpqanPNue9MzRNxFkCpMic5t5sZJznBw/IYOJrI0GxHJKmebBec/amqkXDEdHtM3TAD
AbO+1vR7TdVv+n3AD0AO5oCXJ7pcX/j2t283glFQEZp+2s9PW6EoROTAKcSlBKtzcXHx
tm3bksmkU/2JWAKlMJc2bdoEMsPeXgxyX1L0H+wQOnQOxZq2zh1hzSLPVKWhoUHXk3v2
Ru761T969Lq0e++ruvW8pVvvf+/S5ztd+9zYo8+N3dKuOOu8K12uc12ui96dvSYUTqBu
YONEIubxuS3t9VRoQw7OIeAJFLB4zz///NNPP/3Pf/7zueeee+GFF3B/9tlnkdivXz8k
/vnPfx4+fPiOHTuoMUJK43OswxCUE1XWyQhLccFawuypG/OrFln7wx8/2vusW11p16ad
9Z203jf37POdHr2/3aPXDT16X9Oz77dcrosxUecv3KSoLUYwFoqEzwDcKEDt/IvFBYC/
YcOGRCJBmYP4wuOR7VgsBrqCPEVn28VAtn4t5A9oasBnqL6g6guDSVO1etAaoZBf9dR5
Yo/+9b3BY/M27zDKaptLqs3CKjO3rmGHr2Vvlbm7PHb7z+90dTvr+u/940f/1b/eEw7o
lvcKnz/gC4QUIwxKj5QPtSC4AnIrlqyNUNTi5ILMFLdaeGacH0tT+Zptzo6WLbnCcquX
XjMoTjkF1bZ5gJ1jxx5AZN68eWD6otGoaZpNTU0tLS24M97Y2IgI0D6YxylTprQppVjO
QTCsQkyiTvYh+RRxO8JeIjNO8kN6WyJkfoNtdj6DtplQZJZ20mYg0p08KSPMeQL8krQd
rLYUoYOKHkZz/JaCtF8P1SheLaTqhl9RPW63oQXNhx6fPHz06tzSlh11Zl6tWVDVuqu2
tbi6saQmXlod/O5//s7V9dKbbrnvx//1tC9gelCPoVATQHQnRKUEPSOcC5dj6gtx7GQq
kpgny49x5COpxNljrAogjM48Afo/aEl1dTXAH8jB1SGgMaAccnJyampqRPzYCXKICHII
K76IT8Mo6JFEtd8XjhoVNdFzv/bEsKmeRVuUxVv2L9lcs3KHPiuv8t2c8sx1BwYMn+bq
2cv1patGT6856+KHq9wRYKxoOKKpQWAGV5e0gG1Dhp3DQxxam5cc9r+osjixBDPU19fj
E5CCFZbuM6gLyhkrs1q+TpBn5997MpV2RGjAO75u/PjxZWVltOkNWEYEEwyfjA9hBOml
paWvvfYavYSwB7AiiPyZei9ObEl5BSJ1dXXdu3cnDqFMm5aERbEKcbopIR5ABnYv7sTJ
RBFEIORJReuGGFjA6ngih6CFHLDUaFi29EgbctBC0fqA4te9iloXjugBo3nHbvOLlz3w
6sziBRt9GTmeBVm1S/O98zZWLN52MHNL2Qujxrt6nNPjizdMnJl91ld/XVxhetUEegWv
QN/yLBJRKzuEOsbEk8SNEiEqFrSJvsIw8YyhIHBbLB9iP2O8evXqxfWL9ZyA+YkX4b0A
f6wvHe05oA1gCgoKCuiUqrMjriCuArjAXoS0iKHFA3o8EIzoYdUIG7GYonl3VxhX/CB9
yHvht9d63123b86He95YVjxpU93UbZ5py/LOufgGV6+v3PfijBGZiUv+Y2hFXSwGysHn
DgWUSNRI69FNjnjQeR+aykUKAXFMYzrOkKVKWB5kQJ9TB5t58Ij5aQiXM1McAjo5dJGu
nGpshbQNfysrK8EyAHVTF0U+QYpwzQIOefXVV5FNChInYHB5wA09gzmMvuLONRkQ3JGC
pyQzYnbgXGVvcxoTG7NVTMcEBt0ilKqIPkiN2Pr2h2x0OJ0XHE+62dJwxuQEqxvVw3EM
eMBSkAblgPkZT0ZUzRPQ/YFQS0mVefn3nxuxpHLM8r1z15fNWbXz3dU1czYGZm/0vJ6Z
d/ZXr3B17/1Q/0ljF5d942evbK831aCZiCU5u+hEkn5b0A+yvOIR/S/QUCoxAOUbnKVR
OxAYURCIIm4HYlFxB8NhostappwAdgONyc/PBwna7tQV8R7SgRy4InSGHNpkDpYoMmLo
Ud3CDEhXjaAeDumGsq8u8fWfjus/P/Grlxa7vvTvXS+4cfSM9ZPWe8Z+WP6zPz7r6nbh
2dfcNf5DZcAH5pd/Pmbn/kBLLJIED6j54hENDcKag8b06dOHyJlLFaUiZKLRUWghHfmx
6zAhhRbC2oeZz4WSvU1xCr8RpcTDDrmqtLQ0pODDT025mQAawsGDBydNmlReXs61XtYU
RuS0O3D7xIkTkVmgmPvUlpEde1bTJDiF0sTA6BZ0GrqOU4LGPJHByXIiGzIDIpCIt6AG
rph4irK9e/dmTpnG4qOZDAtbglInDDlY81MPAz9wfgZCuICggkYQ0Br0BVsKK82rfzns
hYzy349d4Trv6m7nXTtoysbXMytmfFDz0wdfcfW44KKbf/jah3uHrai64p4R68tNT8AM
qDqoXHwvpw3nGOch56eQZ/hSioWRk9OMsxQ9iQwcWUSQwiPSyCCsMWtjv5F3OwGyIyIH
gD9QvfOwtpzKRFNzc3NBXh7RpINN2GuWboOuqLq99+7TAqqhqwFFVXzbitzX3jfzz9P1
wavDadfe6+p60VU3//yNlXtffGuN64LLXGkXPv/6puEfJO6foV764DuF5VF3VU1DJKZ6
PYloIC0NzbBM2FEUgAmGGciBQON79uxJAhXpZOLYh1zUOChIxHdx0UQ2/MXMRyX8QPwF
CLAgiUD8BTQJ+XeqBVFjQA/s2bNn2rRpQA7CVTFd3JKSsdq/f/9bb721b98+OYWBbySz
z85kL1ERjn7HSDAQXZBOI4LFnRNVspGWxuShmj2KoHJObzaYY4cMaAleAfKYOIRc9pFN
hRybHlPANwUwP+0pqtJKgxUJWgJzzE9LFhGKVGuNa0ubv3HP8D+/V/bssn1n33iXq9vF
37j19zOXFg9//QNXjytd3S/rP339kPfdj729+9J7hmfVmB69CWW97kPMFE8T43spN3Ae
bSbWJV9M5IkIipDhYoRFmE72jcU5Uoyj2eg00nUnYKYB8A/LVnREDp0Kynjm3d7tNVQg
BZBouk/XfAELXYRDRt4+42v/89bdk2t/O7nkt8OWuHpe5upywe2//ceFN/4M2PiGX/35
8fFb7h1X8p8TKi95eOaWPSE9EPF7AqpfM3Q/VioAOnECVy6uTZictBPFycmlkPOWjBuR
ABlqnhPhuKDPBbHLICIz4IJ0OFHKKSiQlEMxXDUQLykpmT17Nu4HDhwAiti7dy8ioBBw
B97AvaqqqqKiori4+L333kMKIZEIgbDMyYye5GSTOSxQz/WLtIrMVZmo7E9EkA2TlrIy
jg6GTM7scP6T5COuIIsEOvkECCRpnEG1xAtK2wk/a7r6VQtHRYxgwK94Vb1SbdpwwPzu
E9N+9+aO30zO+v3wha5eV7rSvvrjXz9+0bd+6Or2tW/8/KlHJmy9/419975WcsNDb6wo
ivjDTXoADNehrsMHUqCNjgX4szN5kpFiLg4i+op8hKxHyEABDh6xfeLsnlMUdYISY7+R
lqiurj5hMgewn04lKH4OWi4yh855cNm+BAt3iKEA9aNEgnpQDRpqNBjK3W/c9FTmXdN9
jy01/jK77PsPDXR1/4qrz7+5ul/guvjGJyatenZe5RPztHvnhL/5v5lbyuOq0WjorQE1
iT5M6w5g9wuPjAgpYfQk/orbCw4Evog9TxaP5K5Q0eQEmRkFwaeQdmKdyEzJG+e2iDVO
qf1oslEkQdHUsrKyzMxMgH9lZSVmC+9YoIHMMaxADkgBrgDNMH/+fGSmVJCSBGIG9BU6
h5wynmLRF6jnVgVJMjKVJCfYRRQdMJvQEuKuXVY9omJaC6H8h8siRRyYV/Sjelz3LiO6
df7aCAUDYd2WjAWphwOsFgbFEABXAXiL10XM1ftbv/3EOw/NKr//3QP/u+jgDX9Kd/W8
0NX7XFfaOa6vfvcvbxc/8E7t4wsbHnin/nt/mbm1xtQSLT5/nd/vJVdOMkCkBPjkvn37
Uu5KEpeUFSkHTmORV5DPYg9jLaPuCkW78gh1iiOYE2DKgGJ8kTk42QqnQPKIMgcLOUQM
S9qAIcBAgMVTIhZyAJcXjRhAy9l7A7f1X/ngssSTHyVfWK0NWXHgvFt/7epxrqvn+fcO
njl0je/55f5nPkg+kBH9wcC1mw/EFK3B0Mxk1ARJYsscLL85FHyRGBAsTQyGKYfWsrs4
J4VNk8mMFEz1s88+m/OWEgYK24U3ZJ14BdNPQZmDU5AFiAO8r1q1CngA2IBK+DxhQZqK
bAVPDSxYsAD0gww6u5FCRZJV0nvC/MqcJMgzTkUsRpBIZMJOIyXMbHjEVxCBEB3RAoAo
17GTj7fglwsWkYMWDlLOYIRVIAdb9BCKaaEIJm8kXhNqXVth/vSlhX9b5HlufdMzH4Wf
W77//O/93NXXnqj933xldeSZ1eaTK8wn5gV+8eKSDRVNNWoUZAO7lJ8pG17CVsjixQiJ
KApwyB0jBVQBEQtXKM5Adp10ESkxVs5+PgFTzimQbGeaHq0Cu5GXl4e517kdAPAUXgOX
qhmKZeUJvJzH0D2YvAErHaTc1jLfXaPXPb3ZfGFz49C81iHbEv2W73Gde+mXfnjP+G3G
yKyWgRvjg7LMflvMX6SvW1/sD2qNUbVZrwsl9Ega5lJAJ5WLniSVS0qMU5SYmbIC4XNJ
FCEzaTl+i0RQFl8txTkiACg5kaodyRT/yVRz5bIu5+6Bt9euXUtqk7OFa5PIxskaoODK
lSuLioqkuEhoye3KFvBh0wW1ikCST0kki8BN1CHYsWQfSMsJ+8bizs24482+BQ5NS7AV
Glhdv7Utoak62Ag3oqpfiShG0B9UVOOgnlxRFrx3xPv9VhtD88yBWc0js0NDl+W7vnDl
hT+6f/wWz7BtTUh/aYP5yrrk70evWb4z7A+aYE0sCNA06RNuQZL5clpCYDppJ0q00DNk
08RIIxdBimgocpf53LH+4z3f8CIAfm5uLin2dgJJOqQjcjhCHUACwA9BxRoFTQ36AxZy
8OmKX6k1NDeQxtrCg79/be3QAvP1veb4XeakcnPS3oY/vvHugOUbZx0wp5SYb+43J+8x
R+w0/zwtb3OJx1uvBryAW0vD0lAVxXdIY4Rbw5TDk7rm+ij6IZzhvFOjiXQF5a4EefQq
8bZo/nB5xZfizmFiqVNQz4EiRE4YREpKStasWcNNRtBCWI4BxVhxuCmJr2hqasLIIvGj
jz7atWsXXRjje5GZJ/vYh5y0naVzBZGNdWEZEK+pqeFyyQGS/REWpyieCg/E4VwNGec2
yvHerxfk4LeQA+5BVZCDoajWYSoNyEFVjCottvZA6I+vLh+dF39ttzmhxJxx0JxapPz3
2NlD15S9szc+sbRlfJk5eb85qaT5jxNWrtoTrlGaNNUyCCNHWkj5owO5vhOEuR1GvRFx
MM2OouKTnI5hZpblhCe2P2z9J2DKgRAF+FMg6Tx4RbZCtjKPIHOwjlEEVXsH0zLjb1Nu
oOL0SFRLJAyfx1u43/Poayve3NW0UjFX6Oa8kPle0MwIhj9MNGV4mzO8ZmbAnO1pestt
/mrc7PWl+8OJiBpU9JgeiId8IS1g6FwTebqcfSUpJIO5Bomzb+pCiFFKbj1T7YGaJ5yo
4uQXT4kWgB65m38q2+wS3aE9e/bMmjULjcf3mp0HdNHChQuRWYQV7AGSrKRRpSs6psux
Dq7+3Okg00HVEWkYlUykNnQ1JRLCoZChY+Xc3z8B7g5DNkN8aFoGbatuIdUI+4EcLBGB
FkkEE5FQ1GNEN5fr96VPn1menO0zMzRzUaBlecxcGGhZrLUuMcxlYXOO2rggaE7Z4//j
xJkbq5WKQDScaAyGInLUiMiT0E2vjuL4leIFchZil5XzVvRz5LwMRTHEuuz5jvWfgMkG
LATwd1IOXdoC9RwKCwuPjBxsDk6zt4+j6H8tTGP+oDDrQmEF3P++Wu0PL73+6uq9+REz
J2ZuazU3NjVnm61bk8msSENRs5mXbM5ubO2/euvvRkzY43EDq+ghjx9XVPNHg0YkLMBO
REoUQXkpJY2UhNPDJuUM7FLBJFQFx4fgi6jVg1kqyiTsfKTIVvLxFpR9NrRAKBOFqPLy
8nHjxmVnZ1NTGu0nNmCEetR4hAzjx4/fv38/uktUQxGomUBiA13XWTreS4klX016gOro
pNlEKMFAgQ8HhU8FNKitShUL0Tc7gcgBkylG5BC0zmH7o/FYFPNFj+GBFooWVmp/Tn9z
wrqdOY1mbmPLlkTD1lZzS4uZ12JmxRq3xpIFprku3pz+0frHRo7eXlvtjYQUzP9QkOIU
quRRtQxxwjI1cyTOr25paSE5IUpTnK7Eq6iBJDHnM8mMjvWfABkXkUNHgSTZCswEkTkc
/rC55vcFvJYpBoudM7wB8BjWVjK4imDQpxte0OwHarxzP8j95RP9L7ntji/ddPP5111x
8U3f/MoN133xyisvv/aar1937UXXXHnFv3/3zr88uXDD1vq6mrC3LuitDqpuC8MENFHF
J3eGbiQ1S71NEtj8HDnqDnKI4nQ+El6b/UyjFk4TguR8qelKJdVTUM9BtKbFegMavGjR
oscee+ymm2667LLLrrvuum9961vf+MY3rr766q9//evXXHMN4rfddtvjjz+emZlJzXN2
ILefUJyaeEhHSmfp6DQqn/OgiuzXk4kgByH6wBwsinoo7ua2HVLYAKGHGTke9hk6BGtL
XdFURTU0f9hySKF6Vc3j1xVr08KvB8Bk+MH7+A8q4WlL1vz2kX9ceevtX7rx2nOuu/Lc
G6/5t2/f/KUrv3HptddefP31X7z6mitu//F9T/5z7vx5GmaprZJtMS32XOLHsmcwRQHp
VFmnMUbhuZzK52Qf2D/U/WBZ4YiFWe5Y/wnwW0GZg5Ot6Aw5HH4z1OodRQ0oYNxApoGt
8+kWlxf2Y9DrwNlFYmFFD+2p8G3KLfkga8uc5fPnL521dPmcVcuXLV+U+X5m5qKMeUuX
L169Yc22HTv3llfqbk8yoIY89S2RsLemLmSExSIByTPitNraWu6Ss4cxaUXtnCSrONkU
/ECRAseCyFmAjp1PAkP4jlPTECi/URT4Kyoqtm7dumXLlhUrVoB3WGYHYAzcFy9evHz5
8rVr127atKm6ulrWetkul0rIJnSWTvEXepumhtkzzCZHxSnV4dRlKRE+cLuE9IPzlAEZ
8OPfz5aBEUsZL2CZjTX8EUMJ2a4ovH5D9SBNsXQno1jgvLX+UHR/ta8gt3j92g2Zq5dl
rMmcvXTu/IVz1q9ctXTuvMUZi97/cPWq9RuzsvO9BysjPk9Exdz3auqhgzyUGHBxAeAI
YmSHcF5xclJ1ATlxF2Ev1z5ORRSXY0Tsro71nxSBZEeZwxH0HOwdImv7OBqwVNaViLVh
FA+EEwHQoho4Oz860AipPiMeTQSCbq9e6cPdVxfx6aH6ADB5nU/zWjKLkBYIxWON4bDF
FWK8DJ8RDoJBDpFlwDSj7Iu6DZQSkCoj1UoelrvJhHRSdM6TFMyGv/hqynZEdiEng8gA
nsqna8nyEFvK8QTONMIvaSo5xUk5A0FVNtTaPIOECJ6ydd4xnQXJoFG8wznPqc4M5CbI
lLEDyVMwRTgR2VJhS47g7+AYcmMAfuuy9PxjUa0hGohFDCvRHw54g0YYky4Ubo5oIaU2
YIA3TkQ0wL2/Uq2t1Ov8hlv3u7WD9c1aXPMG/Ioe0IOhYCxsJH1eQ7OslYRFuiVqJFz0
Oet4RAUTWJRJKLxFOlk2cgrEsbINioHjXOXAHbb+E8DGUn2abEVHYy9oNmUOnY0jkIMS
sUQ9ESNoKZtZMp8wkUNId+tBdzQeCeohsHWgJTStOhz3GlGLTGoKxqO+cCzSqoQaLK+6
Vk8GI6EoyAw9HDMsxRVAcdR2hHFIVkMSC00SHsHpzZOLPuahGEUhAhGY4h6HiBcozGQi
O1zYeZn8pxpmEFEhTzlxywbT34IA42NrMMzM79Itga6lohYOAWY1y3uQwxEJiV7q83eW
zpWOQ0BsQEkCR0QYauk9YglOY+dRI4mwHhG1nSDkELIOWUS1hCCHQMTAQha2FPV9iaCS
DIEKtdBgUNGbGho9YDhiaiisNIT0qFdv0OJRIwZaCf2MaamqsVC0JRRvBDMdiUW5ssvJ
SsKyCBKJVynjkhNnciielAORswjW5AyFoIiO9R9bmYwtJww7dJYs0Pb6lIKC7Q0NTe12
K5zq06DhO9tyUjXdr0c9FrB6ggGP5RRIiRoeNejzBJTygFphW3gIgZYDr6cEPGrIax28
sBWtufWpakH0cJteq5y+1zUt5bHiU23VhVRD9+EeMAK2BQDD6kCfX7Vch6BzQUopGAJL
5ySgeT/px+3zdmni5A5/bV5DadP/t6QHzKb6wXypXs2nBhWfvz4Ksgt96fMHVFG9ti0V
aLZALKCd1n1ieQYFZxXQfWpYUQ2QT1GlJuzzhJCiBarqvTm525OJZnAVXbp1PWqZgxb0
KhF/IKgFa/1qpeLVDS1hOQwKgvj0BQP1QcvMg+5za7oR0SNGtbeaI5IKxwo5YBQjiqH7
A2DhvKru0UNuPeYx4m4t6lPBZ4VVxVLy8WmGO2DU6wYy+AKpq9PLqwX1SEINRsHwIoI7
4oicAd/V8cKsAEWvqME6Na4ayWjAnVBqgp56cFA+Xa/0+HLzdiQTLUAOQA/t2ArZyjzC
ke1EtAm0oarXGQlFT4IeS9QZBlAPKg/oth88i9e3lFhBxenRsBEKpsIxpAljRigWjBp6
xJrSSbMm3FwdMWsTZk3EumrtC5HKqFkeNytiZk3UrIukrk6vmpBZZZgHAy3+BtMTt+LV
QbNSbz0jP9YdNrW46Y2Y1Ybpi5ogJKJqfVQFEwX0GKnxq/kFRY0NrbZA0tWlg0DyyMjB
YsG0oGX2MeTxBd2eUMQfb9Yam3xgVCMN4IyBGaIRy6qDX/WphrXXbJzpvgVPcIgGQ5a9
gmiyUo1sLq15e1X2hEWbR8/fPHZh1tgF2a8uyB67IHfMwtyRGfnpiwpHZOSPmZ81bv62
1NXZ9dqi3ImL815ftn34rPVj521F/NUFWbhO9+/iV7S7xi/YPGn+uvc+LFxd5K/QzUii
MRGxDqWB+AdyqPOpBfk7mxtbgBG6dnN1ORxbUVtb2+nmu+oPed0J3R8y6sIRNRCMuf1h
yzOFLxgJJ/31iu5TQprf564OBbR4pBncjKoYaiocu2BtT/g1d7hxU0n1Wx/kpi/YNCoz
N31R/vDF24cv2jkyo2hkxq7hGaVDF5cOWbwb17DMsuGLU1en18C5O0Yu2TNgzvbRy/al
Lyrl3zHL95/u34Vv6XgNX1Q0OiNvwpKCNz7at7LIW+Wzd5YVI2hEvZpR5Xbn5uY3JJIW
cuji6tZBICnIoTNjDhHVF1LqPXUVlnxDbXDXJVW/qXpbPbUNirdZ8SZ1LRENNao+w19n
xIwmy3xfKhy7EAyH/KHoQT057cPc4fM3jVxWmL5056CMwvSMHSNwLdxpX8XpGbh2Dlu0
c1hG8ZBFqavTa/jSshHLdqcvKR20cCfjr8wrRPyM/FhMhqEZ2wfOy8MHTv1ob6UWC4TC
WL4VvyWQrK535+XkN7Uhhy5tBqg/tfp00N68iqkBLRptVbzmR+9XvvjsrFtvfvz88+76
6iX/c+OtT/zlqakfrq1SFDMSbAqqRihlbP6YBi1gKJHkwaD52tJtoBmGLdnx3LR1Y5bs
GD5/66h5W8bO2TJ27iZc4+ZsGDdnHa7Rc9ePTF2dXyPmrBsy88PR8zcigguRsQs3D5+9
9nT/rlHzNnS8hs/fMmzRjoGLdg1avHvC8tL6qBmMJvRA2LKQY+hur2dHfkFrshE0Q9on
2QqROfAUWGcCSVULBSONoZhZXds0fOhHN17zjwd/P3FJpicn1/xoQ8v8lcqjz8674XvP
DB76vt9jhvQG26ZfKhyzENCDRtKsjJhjF24dvrhg8KLtY5furDVN1TR10wyZZtg0o6YZ
M82EfcffoJ2euh/5bth39KEr7dwz9RsV0xy8MG/Q0j2Dlx4YkVFYE2r1Yz7pkVgkbhgB
MKw78yzkYIsiLalkRzNxR2ArrM10LeRT4h7FfOnlJRee98TIYXuXLfVmZUfWbQyty46v
3xmdvbp++KS9//a1v/V/aYW7xgwHW+rq6qgJQ6cJVOyhqhLe5dQTdnorE6cVcsqAiiKM
OI3Mi2FkZqOJOaruUL/X6SdOjhCyAU6daqd5cNGEd9rDlxfJ6+Rd1FASLe7j6c/C8Orx
yiCQQ5YlclxcNGZxrmoPPbBBg2k2mWazabZaR7JaWpobEY+brUgMNzU2tB7KwHustUXi
kWbr4FbCjuPe+Mk8ybaURjvOUvGmVuZh/c6a292TLZ/IjzrZErmzzmRbirNOvrddy/Et
jZ98C9vf0KGGRFucbWiXHm1plnR5lyutZ7Lzbzmt71gpRi8pGLhk9+DMPcMX5NYGm8AC
WKaxbG0Qd33t9py8lkSDhRwsPYe0o9JzsLRBFMPnb5m1YN+Xr3j68hsnDpukzfkwOOv9
A7M/qJrxQfnk5WUz1qtvZDbe8btFF1/5/LwF1W5Po9ODJ43x8o3i0YOK0HLwhOniyYU6
5+KPhkeQqKra0fGoeJCkrSQq5okjGzHpQPskxFF8r5zDEu+BNDzFo6xUgeMZLrH2KWiK
NiKoEHjcz1yoml+LHTTMMfOzRmTsGLW4aPziXKx30dZDaKGxGROhxWxtNBsigInGhlhr
a3MyGUdiU1MD4i0WuLfwwt/m5kakM45H6BY+isejkk0ulpUaUC2KI5JIxJyJqAqRhoZE
Y2PSmZ+vQ6RXrx5sEq52eWxHPQ1sLRORgRWiCFJYA/M4szGDvIgRtMH5lPFQyOj4XawW
F3rA2UVn0gVKcuyS/CFLygZn7h6+ILsuaKkfW7ZZ/H5V8dTXVRVmZzfH7YNXQA5d0pxb
mZ/ChmQ4FknuLU/e/VCG69JhP3yy6I+Tfc8sqH52/s7n52b/a07uv+bsHrDQ//QbvkeG
lve4bOBvH8/YUxGlCjR1/sm/JJNJnvTnAR85YCWWBMShIaE7FovRFg0f8S99OUkeDDBV
1nkgCC8lohD7D1T9pTor2kOLfyQDxHeDHGfgsXE5m0zjEqyKLaeBCLEVRuXhE2AGLWbt
MidrI+arGbkjM4qAHF5bmBOylwYbHlpbAS8tnOeNLQ0AFouKwJVsaMG9ueXQ36ZmU/42
Nh1K5NXQ2Cp5kIFP5e7q0r1rt55YViR/Itnc+sm3SP1SIV+EZ3wpi0tjpHLkZB4p0rF5
Uo/zvUxhQcZj8UbnU2cGeRdTItEkG8xs+MB2rztjLgs5ZOYNydw1JLN0VEa2L9wUNAKY
UXGLWVV93rod+XktDbaZuC7dXK7uYs/BqedwhEmuG6GSg00X3jTqa3etvvxPm/77be/9
b5f+oN9M13fudt34qx8/NfexyfsenlR9y982XvrrFZf9dOLumiZS+GLTmGAlx3i7d+9O
I4RijZBGSqmfT8NuPAki9uJ4OELqIXITk54oReJEzliJ3wraNHOa80Ienq1gA8j+iOEv
cYdBK/c8fMQUIhlk41l7nr873rYoQ0Hd8vERjNvIIX9kxq5Ri4pfy8gK26Q7pnaL2QxI
cqV1d3XtZq2trWZjY3P3tN5du/QAPFo5mi3A7Na1J+KtLdaMQdwmINOYwgjjfOScXs6n
FoC3HKqENeBqaf44Gx7hvU2NVgraIA1w1oOnPbr3wV9mQ+sR7+LqjrJIQWa2HHe2vF0l
uHr26JuINzEb0+ViI9O69WI7+ZfNlqesHH/xUlbe7pPPpAvM1KuLc4cu3jV0cemYhRZy
wIyKB60VJxTUfP76nQX5rY1NghyOyp6DL+Cv0d0rttd89SdTr/zDlv8cVnbfWweenVPp
+uZvXL2/aBnv/drd/WdX/+GNsv9I33nFPwsv+OXbH+TX8kAoF1YnVPIwmrg+IanPQ74A
ZGE6xG9Cz549hSMgqY+cAFvyGjQOyfxB2+8Ynbsxzpqd1uwZYcNoso8GUeU0E9AFzeCT
wODfPn360LQX30L8hsbQ1Q7P4R5HIw+q31A8impU6OboBTnpC0uAHCYuyo7aZANXSFeX
rmS9Xfac79YlzVqhW1ox2BaQdulqwUVjE/9ad3uN79uzV3OygSlWpLklzdWFM8rKY6+7
zIwaLGm2/bRntzSpGRFWfqisvfDz0Vm9ejfE4vIX9Vs5m1vQDCtiN6BPj57JaAz3j1/6
yQjexRby1YgfamFzCxrPBkhTnW+XyCf+2tmc7cSKyW7p0bXbx3TGmXWBf5uwJH/okpKh
mXtGzD/EVoBR1RXLPmNtbXVBTm5Too2tcMgcnAZmO7V6qivVgfqlefuv+s30X6ZXP75A
f2qp7/nZB1xfv8t11kWuHhf0vOref80u//uC2gfm+X421Xf5n+Zkbt4nJrBoGJYSPOHx
STAAsvBegD/ZCtIJJOyJuCQn7Z9ziXc6nqDAEDwR3V6ISXbKH3r37k0NIjq9InIgQ0HR
BIkNuhKg+RfE6+vr6WWA2ECaIR4f6DmRxqYozzy+0kjLdonXHwgeCJojFuYNWVQyYnHJ
pIxtMRsakomIaS+qrrReri49e/U6NxFt6mJBhLVq2qBh3y3ioqVnt67Iy8RkNNKtLVva
J/M3JeL82xCL9u3Zo6UhyQwojniPrl0kJ6rlo8Z4rFdaN76Fj5ATKchsY57Eobfb1bIG
ZGhtbJD8iLOdiKS1NVha2L2LIwWf63h0qPGgORyfICk2cgOrlezWlo0RNMn51R+XOuMu
IIdxtsxhyJK9hwSS9sndgKormlpbX+NADtZuxVGaiQv6VWVrUe1dTy54aFLFUyv059cE
0jcEfvT0VNe517i+fMv3Hp00bkPypVWRp1aE/zi7+qcvLVhbWC7WX2lakPQ/kQBtkOLe
0NBAnEDJPyK0rUcynpIEGvYXOGUlJPjlHLEYWictwaP09HQjFteF0RCDfsQ24lxALLeT
rSBlAsTV1NREs5/0U8DjzGKdlfKH430kORzS1EisPG6OyNwxZPHuEYuLJy7cbBuMw+hb
uwpocLKhFex0d1dv06Kcu8YScawbXdO64e7q4uIywoj85dOGpkamoK60Ht2ZIncpYkur
XN26pzUCfk2ze88eiYZkU0szKmm2OP5PvAVVIT3Z2IDMyMnakBJPJpiBlVurfWsLaj70
rq5dnO2UhkkKXtezdy9+GjLLe22pi+nMmbR2aUw2j5+GdPzlVzOCFKmBH36myhzGZFq7
FYOW7B+RUVgXMbVgJByKh2zvt16/b2f+DpBPtvrTx1uZn/JsBeBb10J5O2oe7DdnzGp1
yCZ1eH54cmnDiCzvi0u3PzMve0pBZNy26MR8c9TmRL/MA7/p//aWogPBNg+2hHrS7WJv
k8bhCWWk6plNXkmXVXxKhEBXKcKJBNvcxYrTTEmRs/bCLwgyEW5FEIU4bmBj2Cd8FwkY
IhnxDSdOup2OUI83cgiGNH8kdiBmDl+8fUhm6fBMsBUW5WCBRLOFHCxSwSYguoF3tpCD
y9rNbGyw5j+hAJlawX24cO/SPQ2PkNK1R3dGnBmabW5FIk02WCGSbG6SOyvBI2dOC+Rb
mm0apptVqlvXw9aJPCiLdOtR1y4xrOk9e0hVTdaeYyvSo8kEW4gMn3gLcIJdCetH+1Gc
L2LbkOFQxPHtEknYCIcRVC6P0CSk8O8ZdoH9HLNkx6Ale0E5jMzIB3JQg1F6F6USVEFe
YVMDHem6jtaeg6YGsXIW7fH9c9i0Qe9teGeHb8bB+NSqxHSf+XZ90yyvOau25d2DjTNL
IzMKtf7vbvrfEdMLy8rFnp64VCMokUOnpyoqMJBOoGyBKgRC/0uEBL/Tj6T4zyVzQcCX
FZ/sBt7CCvmlNIFIvMRAtgKwL/ZVmFPcR5LTYeUUmZ4c83G65g4Ey6Nm+sLsQYt2DczY
OeX9oqCtJGAvmc1NjUk0FZ9jk8fWlpx9vs7lXHmxQHOF5TLa1daHk79cxJttWAZ8YcVH
OhdWFpeqmIgMzkoOlaUCruOlrE1qZgOwrIMCkYW7Y/1c5bnuk6hA41kJIkKHMA+r5VcI
JSCfZrXTbhWLO4kQJ80jbz/zLiCHEYuLQDakL9r16oKsqkCjLxCy1YN8AMG6uprc/Lxk
Q9Mh4vAo7TnYJlniNe7Q/FVb/tgvPaO4ark7kqk2rjHN95vMlU3mmiZzldaSeUBZWFj5
yMvj31u5pd4foBcJbi6IbpLoHtBYGQ3gOA08ivIDi5Oecdp+FCh2aiXRqwt5FqfSAh07
iqkiyhlYlniJbaC5WraBtZFEQaJYVWWdJws5qApaENqvm6MX5YxeuWf4spKxmXkBS7eH
MknzYx2AVur1tAAAkdqjV89k0trTAHNkQUezRU6DVrTVpSzWoKXFgg7c7S1EGzabmwFQ
5iGVKpNlGbcYCot3MfkUhQCkQNqS4izlzHloa/WTKU2WpORI9Zs2opB3dZYiZSVFvoV3
1M93sQ1SA9vAPgFt6fzqM+kO5DB6eZmtHrlj3LyNNXqrYtjeHxSvqniAHHLycmOgHLq0
N/by6diKYEAN1tf5d1fUjnlr1sP9hywvKbetzZs7TLPINAsT5s6oOT9r56P90wdPmrar
HLghSBAWXx5Ot2hin1+sFJKtIMyKI0IaPxd76cQzmOpEEWKGi5oMIgGgjhNlDnT+TpUq
FKS7CtqcpOhDPll8xNBaOD3giIk5qk+cLFP21pF5PRCNNVaHzNHzNw9fWDB0Xv6oeVt0
W+XPBmfZ0W+2yIbmBkRc9qJtGbT/5HTBt9g7d9ZTy7J9q4UN+LS1uQUdLilWWRvaWpqa
WZbpgC9Le6itVFdXF8unRttT1m+BuF22MdnAGoh++EbWcGin5XD1H6rHUYO9ZdtiqUE4
vgI55SlrYzrjaD+oZak/EYu3oUDrSy2E0fZezJOe3XuYZyRqaLVkDiOXlgzIPJCesXPc
/C21EdMfTBq2vThrK9PnyS8soHiHxl6O1p5DIhKOhYI+xb99V9nQ1yb+6fkXnxo5ds6m
bYU+Lc/tn7th6ytTpv7uL0+OenPazv0HQQDH4knafybxIBYLubiLqT1MBoItFQ/oyIkC
QwoNxFynuFMRpxX0sUvbnnwXaRK+jhoIpDpEq4HiApIKRltgq8QHGeM0TSnOZcSX3MlC
DkFNDYUTdVETZOGoxUWjl5ZOWVXqpf58s4UiEjYVgXuw8dDxCkkJNVmKlO0yyBVuPvQI
2ZhiNHwiQ8x+ihpwxdtq5hVpOfSU8YR56EXtLhZ0vjrc/H/UzwxIYbUxs32T+Ea+Dplj
jvYf9jPlo5At3qGqhCWpOIdlz7wLFOawzLJXMveOWFw8fnE2kIM32ADkEAkDQRh+nwfg
T+TQ5ZO26T+lPQfD8hfo1QPgC3zlByvmLJj/ytCh9z3y6M9+89s7fnXPf//x4X6Dhry3
KONAdXWV263ogdr6Olry51pMil1MKDvNFBAGxY0dgJHuFcTOPEGSpn0RQZ2sQVxWUUeC
G5qkMSg84QkLgjZrI+vBt4gxW26wiqF77nJSK5svpTsG0i0nK6AP6tVYVcgcm5E3dOGu
gQtLX5pdMH7lvvFLd735Qdmk5UVjFhWOXVo8Zlnp5I8qRi8teXV5ydglO8ZmFo1bunPi
+7tfe79k3JLi8cuLR2VsRxzpiOP+6rKiCctLJ6zY9erSXUgfs3jnxJWlb609OGpRAfKz
FFImrdyD/OOXlUxaVYbaUCfSUQpxpL+2ogw58ZTvwh014ylqRhtYA+pnfsTRhrfXVyBl
ZEZ+Z/W/va5yxMI8xNFC1I96WAPqRArqxxuRgrIjFhSgNtQz5cM9yImnUz7YhxoQx1fg
jjje+Na6ctQ2JnM786AGxPG9qBPvRRylGGdLzqT72OW7hy4/MHBR2bCF2ycvyasItNQH
4pbVR6yHfm9dbXVOTg79VliHtY/SnoNto9IHzKCpXr+vXvXW++rryoqLcnOy1q9dl5OV
nbV1W2lpKcCwqqbSssapWzrPhC86SiC/wDuPLTCRC3pdXR2dJhA8aVWe67hgBraDUCyH
I5CO+oUfoa+l6upq8hSkPUQX4tCerN0M8XZBHMLDU6Q36ImAeYhJxCUBkdhJ8qEZrPeF
Kg1zxke7QTakL9k7AsO9oGhYRsnwxSVAFKNWHRy6vKJ/Znm/Rfv/lbFv8PLyIcv2D1qy
f/DSfUgfsHj3SwtKB2buGbLMSh++suqlBbvwdNCSvS9n7H5lUdnAzH3DVpQj5wtzdvRf
CP50H9JxR/rLGaUo1X9hCdJRFumoB+moAflZA3Ly6YDFeyXOUmB18XbWg/zPzMofsar6
xfnF/ebtGvNRbWf1vzCnCKWQjlmNFMTT36/EG/EV6e/jc/ayNr4RbcZb0BLckedfc4tR
Cl+HUkhBTtxRP+pE+rAVB1E/UtjCfvOKEEc63o787JMz7G6pN6w4MGh+wYj52TNW7zyg
NPhCSS1g7xcoPiAHp9+Kz2DPAfSHZcwhbnH0ZIHJaIDcte+BWMSi1UORcEAPxhJxIgGw
dUK6kzsA/GLpJ/tA7EG73IQ7usAj0hDnreJ/TU48UUGaeah1wCIkGPAKyhzkNJYYBpfT
HIzTtyZr5qkKUfkWN+jimI8blyeLrYiH0bUJT7B50y731PeLRi7Iw9o3fOH2MUt2pS8o
HLdy74CFRQMySkE6vpRZPnhVNeB9yJI9gxbvHrp07yuA0Mzdw1eU447lY+CiUmsRWbZv
cOYe3PEUM2coIHp+EVJGrqxAyoj3yzGjBmSUoAbk6T+/GCkj3q9AnmHAOYvLRq48+PKC
YuRHnemArPlFuCMd9aB+Pn15wS7UhnehDbyjzvTl+9ESPOW9s/rxFK1CDYgPsfbg9uCO
OPIzzq9jPcjJ70INaPPoD6oQR1m8C32CnEh/ZSEacxCtxbvYJ0hHWX6jvIXxM+w+eHHJ
yMziMYvyp39YtKHEXas3GtFGy5Cj5eVPJ1sBUO3oDu/T2HNAPSBCwolGRQ+FIzELhehG
PBwBZojiIe7hiOoHtMZjsYQWsBQzCWIERhIABDdKFJ32/Ik0uFiLnxTmpNBAuH7CMsUC
9BZE1OH0BSPEhtPbhagiMC4CDVIX3EYhCuKxL6pIEWVR+CAOfE8OckB3qz50smLEPOHW
9UXVM1fvmJyZPW7+FlwTMrLGLNgyNiM7fe62V5cXD8nIH7wwb3Tm9uELskGZj1qUN3px
Yfr8LMRHWoe28kcvzh++IBdPh83LHrukEOkjFuaArh4yZwvocORHnsGzN1vUuB1HKebh
nSkoOyazgKWQE+l4C+rk0453lEV+xIfN28a3oCxa1Vn96fNz2CrcUT9K4Y3jlm53xlkn
7qgHdeK7hs7Nwp1tQwrqsfijpdsHz97KON47ZM42tgR3xpGOlo+xe6yz9p/W91EZ2Zgk
0z8oxMypMZoD0WYjnNAtxz160Aj4vO7C/E840j0qew6WFnYgjJnpViy/5pZzq4AGBsPy
ntAmqbNZfm/QiAa0EJ6kHFIc861May9VC2IUvKHGai253xv1xkyMda2RrNcTbj2BO+I1
RiMvLBC1enPqflrf3SGzJtCAOEbcFzXLvZGaQJM71FKtNWKZqDNakMcTNqvUBOJ1RhPu
yI88SJeU2mDLwUBjVSDpCze7tbBmKTkYms8bCii64q2vq8nPzbORQ9cuXdOcxl4+pZ6D
z295xNAA+6Go3/KFoSp6QDFUvMTtrVc0mmLQVb9me14KpZDDMUYOlo8WFSybV9VqPP5Q
stUTiNUpYV/A9idiGXzw4Wpz2nLIbVDqOt0vn19V1ADuwVCk3u3FBGhobHZ7fCDmcUcG
JoJcRx5E7NNUAedleaQKBLGsB2MNNW6fx+sPB0OKxx3R1XBACfg9ntqavBw60j2EHI7S
nkMwEooHdcuppe37xx+JBaMNEcv1tuEPRw381QK+ZDQCSh1URVjTUzYkj6WPvGBYC0UD
sYQeBirQVHBywYg/FNVjTVooBnQNdBw11KjhxxWxHJJplsZ1KpwB5gFt7RrqCFH2JUaK
AM7gecmPixJRqC04rL+G6L7QnkmBBEoEDaCFqKEFwauiQq8HbIXtK7OrdfLKNvby6e05
2PvsWJ8C8XAElVt6/qpH1S2HmMmmqNtXoxv+ZCIc1lU8MRPJsKalkMOxRQ7+UESNxIyQ
HgnrzU0JVfWHYnEFgxyOB0OxcMgAeo4FFVzRYCAcClg+RlLX6X8lEjFF8YXDwBKqdf7O
ErDpQAlAGJgDeGQYAVwh20cqnuJurws6Etu8ploZMCU0nxtzIxEJB/w+3MN6wNKsCxpA
DjsLeLbCRg6dm4k7vJ4DqBO/D/UYYH29dagvEsW7/UARXl+dbii4a6pX9dbrfg/Qke7z
aUrK18QxC4rlkBAsnBIOeHV3RaBuf9Lw+bxua1gClh9S0I6WM0SbsyAPkrrOjKu2vi4S
i1oOUQMaD0lhMvgUP+5Isdx/B7BSK8iAONMRt4SBdPGpB6zLYkm90YgRCQframpjkajl
SxRzJqArPr+7pjY/O6shGW+z59D1qOw5WFt4BjCP1+/zIOJx161aueLFF/91333/c8st
3/7Zz356zz2/HDN6ZE72NsxYMMd6QE1JCY6twMGr4q6ElPqYWtNieMK+qif/8sQrLw/u
P2AorgEDBg18ZcDgV14eOODlVwYMsq6BA3AhpO6n9T09Pf1fL/Z7+eWXEe/fv//fnvy7
pbejWUp9uHfv3t3VxdW7d2/rFJvL1atP77S0tO49e/Ts2TOtR/ceCL164ta1q+v8888t
KSm29IvCUb+ig9r0+iz8oiga0EVBTnZzMtGlbbfiaO05GCHLxD3QSE1NzTvvvPP888+/
996cujp3c3NrMtlYXl4+d/685154fsasmZjJKUeZx5jxDEXdeiyUbLX0XVV3XHUndW3a
2++0tFmXbTuA13ZwoO0oVuo63a/mpoaPbeo2Jt96681kImYxCza/0LtXj6KiHXt2lxYX
7zxYcWD37tLSkuKyspKy0l1ABbgjXrKrqLAwv+/ZZ331ssvD8QbNiHrUUCCcDEaSeige
NKJ+rwK2gpZ2bIsdrqO052AhB5A31TV1M2e9h3Vq48bNpn3eB/Oxpc0iaEnp7iHDR8ya
Mxs4KYUfji1y0GLNdVpEN0KJSDCi+qKGlp9b0NRsNrVaV2tLmzXVFvvQ0qGzS82p67S/
2lAE49lZW0GZW/LnSAj3L15wXuXBchDzWDVwD1qyBYMnJkKWgSArDjLe7Xaf/8ULXF26
ggm1EEKswauFI/EmJRDWjYjX67cEkg0JQQ5HZ8/BViTGK9atWzdq1KglS5Zgxpo858tD
cq2tsVisubk5Kyd73PhXs3NzpCoeggA9Q2Msh7Sx245sUxUKeEn4ayogUY+a9uSZU7CZ
2G1j5QhihV7s27NOMdUix7TFTL2k82y4nPXmsQsx/kb7cmKmnmrbVMDm63gG3KmPLSrW
TGQ7GacVC0ZQG/g4fiw1RcUkJvuER8jZQsVyMxBRDVuFO6CCucN969ath05Y20OAQeSJ
Retgoz00HBe5O9MZYQoCesOZh6FdinVC0z773C4DI5LNOm55uFc43+Is2y7Osi1tE8tZ
GxsgEfnrDM7vldqs05dtEaajVRLv+PZTKji/CPctW7bQdADn3rnnnltVVUXjA05HMJgn
choaU2j//v3I6erahdujii2/4C4nasI8zMuz9By6dFCC+nR6DpZdBTAUs2bNyszMzMnJ
ocUDnqNEcRp8AzSBAgHqmDNnjrPNVFEGNwT0wvbTqIuAIdUUkUKgRiJ1p5mZ2tFixYXW
WgiDNFdLBEIMQ9sLYgWCx7h4pIKnqMRVjZiDoPo0IZRdKq5qaCRKDl+IDUw2mzaomSJW
takSRixBrChHPlkbv4htZk7iN9aJPGgwW04EQl1Tvk4OiyFl/fr1AizoLueMQqsEKi1j
Ba2tGCOZ/AQNmW8oDgQoZZGT2VhE4JqYmcURBHidwOUMAuaWHQm7MWB+BSqdSIN/0Yx2
sMkXtQNb5+usc+JtbbBOajvag7/OF0lj+IjF0WnMLE87+5ZTB0VgReCCQpXds88+u7Ky
UpAANXgxfySF06+6uvqcc84R60lyrIDLJeYYaAM5ePUZ7DkgHDx4cPLkyZs2bSouLgbs
y4Ir6zUSS0pKgGemT58OTMIWYo7RCrS9keridi0SaR6KluEJVmw8sok5JiozEzkAt3D3
liZkxaI1PkocT7A2ZOMJShqEpNI4ZiZLEdZ69epFuoIv5UkNsYlNC3VsIQMPcIm+NyJo
D01bc4uZi77kZBvkvWKdkp0vqt2sXFxssAhN3rE2fB0/nwV5oIzdnpWV1W4K2Y5pTPaq
E6gZj8fj+Gqaz5JllH9tfy4tklOqcsYJO8gsa66r7YQOYVAIA+ZHCoejY52sB2WFtECc
rSKcihIOH7FmIjR2OxtMdwbtKArpAYF0fiObjf7s06ePdIu08LB0yKmJHOT8IO7nn38+
AF/crPAUIQ8BUSmCJ5gAuV/4whe4pIq1RjFHgDlcUEA9h48tORyVzAFh+/btGRkZuINK
qbYDV206mQI2KLdDUVHR+++/j9ehCJ3X4E4SBXcevCIg0JwsZjvGDpkxdWnrCS2nVwt8
Gj3IIIXm2kjbIycNuxGcediKr0BOWpNjTpqJoylpZGa1RCyYJGJdlpZeiF6IjsS3BaBb
TEMIbkGFPE/as2dP0kVOG5WSU2zT8cNpLBfptEfBVzAbNVXQbGSgGVvawWAN7Cj5S5wJ
JNzSFrggEnA6AjUxM1MAjAAQwh0zoCABkzDItR7N4GwUhIMPRDZmJr4lBkBOwh3e7nwv
2iz4hxHWKc1AkGagScjDv8SN/ChGEJyVE1KQmXnQMCdFIT0gLZe/pBk6IjHLktUn+ZFT
HDkQNDANLrjgAqzIIBUeeuih+++//09/+tOjjz765z//+ZFHHrnvvvtwf/DBBzGpamtr
wVaIoWY5rcxFCgAC8Hcih6Oy50BGYPPmzatXr967dy8QEdrDs8ykYUg/19sBGZANX0HT
asIRkGsgnUDSGoMiTiWcHihYxGmQgTIHTn7MOryFOJ+ByzeFA2gPGQcu6Hw1ugX1APvR
MDUycEGXOonl6NFGbE6S4GeDSdWTC5AKyYmQSWGDxYA2Gw/UIXYpiQbZ4ZQnkHLgh7Bm
gj+bQZJP+oTtlPNlyLxu3bp285kEA5djAS6uvAIXAinIQGCXdKIIJwQBYAmVTkDjI2dV
5AgI8u2gj5ONSzaqarSDEDZsKt8rrWqHWJyQjkSiAhIq/HxW60SJTpaK7+LMd75FPkFI
plMTM7TDWgAr4QswPUAPYI3GhHnuuedIATJ0tQMizz77LJ6SchCWlhNV2FsAvtOeg+uo
7TlYnD4Yk0WLFiEbiATy41xGxZIb4QuP5s+fv23bNjHg0I6REamjiBEIEcJZcN2kRQhU
Sw6FVqbFGDX/CrMPwBfr9+LFkviHslDiCgI1MpDARnFmY3uYgXwZTdfSGDUhnYNC4acY
upd+ZgrYN7xRJJZEO2IiWzz1cGTxCtqoJCpAbfhSJDJFOoSyWX6sCEAQx5ARCkQeKBQC
E/GNhHRZGZ3wy6WcbLtQ+EznCu6ENc4WcLhCBgiZcdZZZxFsCeNoAN7rBOd2AI7ZIiRE
O2JAoLUdjYGnhHGB6HbYSVAB7kDIxEUkOZw4hAIWZGDLQTqiJ9tJSk8L5CATEvTAvn37
MPlBSDz99NNcaywjw/aK88ILL3DmEDmIeWQnisBTQLTTnoPr6O05YIoWFxfPmDEDVTk5
F4qbKEbgq4HKpk6digq5xjmJYbEbL/5lSEWQraAwgXeCLSl8pJBroElJEQXgjfg0jDXx
Q9++fUkmkYYXH50EcCIQfLUw+/R3I05wKI1EBkp1iE+Ev+C3iPl6zDShcEjkoxmon+0U
rhBgIpXQtZb41mEiZbl03UtLd2IJnyY0+S1sA3GX+OvJysoiOMhdKAfK5WQhRiknTpDF
WqBVQI9YgkiGSMBJYMi78BQ9IDSGs3KBNafcg9AqMIiyxEVkSQi2bBUjToJf6AQKXZ0C
jXYkQTsM2ZGtaEeEsBOctMcpvluBgDVXBJKYWueff35FRYVYP3vqqaeIxtGxTzzxBG2r
Ao6wZpGtYEEyFwLsZCs+sz0H2l0EvzBlyhRuVWBiIIUN5iRB5eSDgIUmT5584MABsZfC
1ZDmESjro0yPkEgQ4CosKzUNthDYBWwp9ic4E+cI1JDeJkXEF7EHKDFgToAqYVAEFCLA
FC+94iMDmcmt8EUcC2IhRijmkq7mZwpmEK8ZRDVoBr+OxIzYy3UKPAUpoSW0209XHdJF
9J1BjgmfsGHDBidQOFdAEdoL88UMJAkw3FyaGRGJn3P5brchiIL4BJIZDBhuUl94JDsC
rIprt4hDUdDJI3C2MKegMvnLZhDwBUuIvKKd2FMiwkOxYUD7QuG0exf7RPI70cgpiBk6
7vYCOchBKsAFkAP4aFm5cH/ggQcwD3HnrKb+c0eBJDMTagD4BQWf3Z4DiROQBMuXL09P
T0dtTi6Po8D2o5IRI0YgG9pMnl22+GW7v7P6hQcRC5Cfwc2cuNkSc3B0fHkGKFHTeyA3
PfEXWNqpdfD/GUQZoDNthM72K0U+cMpS5qd1EIEzqS/AKRdxAjWQA1hRTnVRmHnooYfI
etAKIh6BunDKHLgXT6ICKaLn4Pqseg6U/5eUlLz66qsjR47Mz8/njBKCE2HHjh2vvfba
2LFjQWOgYe30f46MHMhcELmRv6aJyKOFIH4yjcKRzidFcbpjBukTcfOxZcsWWWr//4PI
DzuuWZ0FTFqsEdRe+DT5U+GzjYtTpS07O1vgBZQnQB4gSQVF0tiUkGON5vYWxeYg4885
5xwQVJSrkyhFHlpW7KjncNT2HNp280tLS8eMGfPcc8+9/vrr1NdCDevXrx89evSzzz47
YcKEoqIiivRJvYjzOFLanfp7swMJJGpBIJFu7o/Oopr9CraWRDgRxRmgRE1SUNyPovOP
4WLNqpyaSE12OFq6NxWObXAOAZAwBt1pOBHwTlOoVHmiQxawpdws4BY8cgIPkHJgIncQ
aGixMz2HT2/PgS0hp4NIeXn5okWLXnzxxQcffPDnP//5HXfcAUpm6NChy5Yt27NnD9UD
KKYT5OCE3MMGqhpSAwotoROKI4tBOkMywoJR2YD9c7oHMeUh6i6rV68uLi6uOEYBPCPQ
flVVVWVlJe6YTkgEydpZfmTDHTkx4mBpWXDfvn0VqXBMA/sWELfHDuvWraPYDaDN3Yqt
W7eCjAetvrMtAJZ37dqFCAZ0+/btoOfBgQI59OzZU8RxJEEJp59Gz+EI9hxELZn62yiC
zGg5SmVlZW3cuLHEDphL9GLP3Tehfw4Zhfjk33aBDSZPLT7piBKP0r+DLmbwxS/nGRCI
H8gxUZ9Tdj2OSaBMgxVicOvr62myu7P8VH4TP4ZO52WpcMyD7C9QpCYCPSAHsHXdunUD
4FPLFHfuOJNBQAqF0vzLIRNRHnUPOuo5HK09BwIvmyqzgscZMGMRoWxfPER8BkEip5ns
GLLmz2L9wGbH6ImG2OwMkEZSCElaiHHRoj9WMg0iZDG7zXMrR2gPlV3FwSgiR55CqfAZ
AgeFsgJAGdd6cdAAWqJPnz4C0WlpaUQFIAAY6du3L5XMSRJwsLiGcqwPq+dwtPYcKDeQ
fTSel+T2n1MNQM4fHS3ZTLUEchNoCXf6jqzO3Rn7g+YRU/H0FnWVzwzOQnhJfBH1sY9V
5dTHoIRK0PsR6kd+dDJoTvE+QG43db7+GFsItKcuTziKmXfubotPFuGdxS0Ly/KQBUsx
D09bcH0hdBxBz+HTn60gEiA1S4EYt/tlUnGnXnZRO4oXRJDS2cznfBPnEZ/NMaWgFJIx
PH5yBiAHzg2nDw7yGsYxChw+omjRcDtCfk4zzjFZNUhhpsIxDAQE8gKU+BEPiI9Xcn/i
FZrpVKQh7Iu9WfG6wrHjkB1Wz+Fo7TmQpmU7ZXEhNuCZaBEdgLbkX04VObjNT5CD58Ke
kIMgKUKuyqnkyeIUm3AXTxxcCqtLlkTqPzaW2extDpLufK9oa/NdPFIhJheOu6U4u29l
L5jbMeIklH5CibqdnJoIAdq5FCRRKudWnP0pAiL2P5lc6qGJDslnY/eIUjhMIhRKMQ4n
eCucg0g0QvmVU8/BeWSJAslPI3PgPJHDC1ST5pwUYCe8kN+nuRIudlKcBSnLIjnEowds
pEAZZ5FgG05U6i04Z7J4wZbT68dQvMDdGZ4LI4qgg13iKDknRVj7DMpan4H3FBM0HFDx
7CmH2qgizj4h9hZcIeYjuKDgWyivYAbxSiyohmQJuV1QpzyrIuZEuIQdVSC3KF5HmSiR
VDhW4cjwS1KBPAKlkXgEOBU9h3a7FZ+SrSB9LlvtiHDbUcQFJH254BJqgIsoEiSmojUY
pCfsQGEmc/LENCckFzUu0HzKNQ6V4I0ChuJek8hK3OcdQ16PlYtVCtHBYLqgxM/G/nwG
/Q1+O9/Y0tJCpkk6mUiDVKhQaKLgwTHit2AacKwpPhImkfiQuFf0tEVKTLZXKIrPoKRB
7CT8KSJofEqqcMxlFJ2xJ0QI6HnGge0pI0IkPz+flMNns+cguhOcMCtXrhwyZMi99957
2223ff/737/vvvvGjBmTlZVFMQhnF2cyoIkgRsKG1Kn4peWdT0lLcCaLq00UoTkXFqTE
jK8gshLrKxQyHEPpH9dfnl7hF/FDBMWJ4ZoT42CX3L24JP7rX//63HPP9bfDoEGDXnrp
JYwIIoMHD0Z84MCBQ4cOfeWVVwbYARH8ReKwYcNQKj09HZmRiLIvvPACc7Lsy3ZABH+Z
yFIvvvgiqkVBpg88ytCvXz+8BdWiLF6NqhBB4sBUOKZhQCfh73//O2ZpU1MT6UnMZAKR
yByo59CZ+vSR7TkgUEUTEPr6668//fTTc+bMQREexqmoqJg7dy6m2RtvvEGmhouXsLoE
atK0PAJJQCNGEs+5YhpOrOExD/kFWcVI20s2sScpoo9jQp5RIid7fGJHToQbJLalzcc1
EKOyY6kN8u6778qpK6eerdPqo9OyAY/DOI09yiktakW2s4bkPKgoJuOoQskiRxU61uk8
O5AKxyp0poY9bdo0sUBIYlsYeafMwUk5fHp7DqwZ03LSpElYO2ijTE7cMLJr166xY8fO
mDGDqlBc5mhGFQXFfh1S0DDuV1LCRkpYDKpwP5fsvGzISkSsaxLnkMsWqcWxPeUk0jOx
uYf3cldFhGmf7YDYZ2gPPpAoghKPDRs2OM/zikHFduYZO2pBOw0qtgPVjibXnGZaj9XZ
LrFg6TyYkwrHNWzZsoVSdIEg0XPoePCqHVvxf56tIEcAnADMsGbNGtTJ2ShLEgd906ZN
EydOzMnJEU0kcuuiqUXymEehyWjItkuPHj3IGpP/JX9BgwbcMvt/7L0HnF5Vtf6fewEp
guWqF64Vr14r/L2i+PNaroqAClhQvFTpAkpVKQpEWioJqaQnhBCSQBoJaTOpk55JJoX0
Pr2+Zd4p6cD8n5kvedy8U0iGSJhw9uf9vJ/znvecffbeZ6+111p7rWfZRQp1GDnBtxAW
faRkeMKo1TVUezgtMBFwA2LccPlohQ7eCl0SBQdlSj1dtWpV2oocRluHUcxhVLIp1DBr
RmVsPKM4b6QmIOZaHV3l1hLe5ZUlKkewNCdRLF26FNOZzXo2T2kRtFqRtltxqHkrGlbS
oUOHTpw4USwCs5JIA4MAJiY9VMLDyy+/LIkXIRzCRz7BMmCwFyAUjFyhf43KbvubWQfX
2HqJRcUbuBALDl1HqhDlTUuwtPBQO3qp4wapaCFm5AgmVIUNgn6jM3Pnzg3FAAO6mgZh
/swNw7U5ADMNCyXtOA1hyRArjYGjD734RsPIRAv6O1YWLFhgOGh8F72PEPo5tBxb0YJk
u3nz5v79+0s+0Zq1c+dOzNpI3XAGcQ/9JdYhHrJ+/XrvS0L1Ni8gkxMjBjA1QrtFGvXC
Ir1B4RBydLv+AjHSCE4hkHWaSzaoLCAxWq/hSse2S2TCxdT+pR4c+42zvHrH37hw9iVz
xAGymbcUj+BWJg3GBKGDhQsXGmzHwkCI5mRUSR+EKNPgNjhGO80aAFyt/6LmkL1wIyct
loAEC8RTGuIcsE6wBTXGjAKEnJAdhQGevp01MYr9fDvMIQ0/4Y00rAdDtpt0goI5vKUT
lCgoJydn7NixYiP5+fnE7kHCIoGdDUVntm7dumbNmsmTJ+tiez6INRlxCOEcyEd0B5DT
gHlhJxSqNwgtRIokb5A31WkAOngL1EqgOhq6vk8++WRULfMNniu+cdJJJ8F/rCPAsoxM
C1MFwhq/gtA7ndaeeOKJDBr1GwMWKKcjGPtg5mYfMJLaWG03WiMALGmwTqa7NPQ2AyUZ
zM3mR58BjtLyA2wEmaRJEDZoP4Rp4tjwU7QBnCuepdfE5EwTMwBrepfjxrch5uAETI62
w89BRP12/BxU7eLFi6dNm7a5oahCB2nqRh60fft2EeaWLVsyMzMBmAVrBTUZwwJYi6DE
0zZEBcwLBpBnzx3qM0MDcx7gehJDqH7HoThcXbMRnx+I3Y7lzm1hTHvbPTT5jf3uhBfe
EcagQRsI3AA+3TxERW1j9DyquBAcWbNDqL8gOUBEWBLSUjDU5zA6uPLqADaCbAAWtA6M
9deCWkHNoRHDJG/EYx2ov5ZewuU+vAWmYWBbXexYoRDpDlTJMPcESWoiyaHVRfK8ceHS
JlILMHEwBy30LYMniOjEXiZMmCDO4EhhCMq6DBudO3bsQMCwbwMKO6o6REcuBmv3xmBE
wYfioH0DRRJzES7rmFtRDaBrdg2M9AIrMEwKhkSDTPKXxgQ0aSNDOgGN/kI3AU6Wk+xs
6hpxLZiPkWDhV5hNuOXIxnSkvVMntXGypxCkPUSYt0bASSNOewMizZ6J8GC42sY4jWni
h273vokx7UNkyyaNGxZFwn0Qqz/hLe5gRONHnDk06efQOLYCMLrm9tlVgxjIoEGDdMBu
KS5zenF6y+gmBO2Kmvr167dkyRIdEPlFZhmDq+MI7YUeiiMrJaoECWIIA2dVMvi8Id/h
SLQfswOQsLhkg1xtJQK5wvDX+HXzF74KPJr0EEhERphH3OIRiAfGjnbSHOfrATo+lECO
lJ+DI1CsZYAEpRE2hli4C+AVPw2J2iQGczAQKyjTJLwwOC2LtRUW4z/rpYcw0XVvTliT
5kcRKjW4XoivhqzG0oXGDZRat9xVNU6WF5W3Y3OwTpEGE9eCn0MLNgddtnHjxp49eyJj
iMAbb1Xr5Wr+iEf16dMHAYNgBNsAMdyB2+Z8duwyONGM8/JgBCDDps0jBhVxCgx2ZHSl
2g9pc9K4KIAk41bBGRKieXAgaoQENQbnCifbBRfCSXDY+oEtwHwwj+jRGmR3CkUsDIM6
gjYHfmJzCO3/ahL0mwZWH9oAnR3Si754AuK9E27CH6Bi1Do/yDj2fi5rjYk3FFG8k6JH
hPvdTrITAlemSRoacF9jF6yIP/zzmEMLasVbQtOjm4wfP/7JJ5+EoBAd/b5QOfWgbt26
vfTSS3g9pUVwO6AJHYRYb5Z4/AfUEkjAYU1AteOo7AhWBHs2bbGI8hQHkhPZgXLhABDE
G3YfqBDjg7cV2NwRCzULQlNwsBLKFC7fPC4MYaZJCAxOn3cEdQrrSvzE5mAPtDRjfugA
GR6kZd8O3R1De4Udq6BQv+hQtEjLdm33vNCiGDpQNd5uCB20wiy3mCbS3D4jj6kjqFaE
tsTGfg6tyJWpsmXLlt69e7dv316Cgd8dBm0drFmzpmPHjv3799+0aZOrgqaI93F6LMgw
DbQBjmGFCGMXJgunFSYEAy8p+AAqvymU7rO1ynm7IjhEyzda/wpjKKiEf+EJTksKl+Ok
WZxH2/RrYQYz7BHkDzSA8RFzSEsSHcIUN1bS05K5N/ZYaPJkeKZxqmv+SktXHaa3CNd6
Lubf0M07zaszbKE5UkTdR4Q52NQQTiQAZtP8HOAS+DouXrxY0ruDFBy2EIInsIsnNiLl
4o477pCEAPq0rlyyZEnXrl3vvPPOHj164IsVRdAfcZg4mJjHNlQrohKVxkJjyHvnzZvH
qmfsFIOWSCrQQiMRzu6RZhE4+4m6cVoIN0DTkE+ca2bDhg3SLx566KGrrrrqZz/72UUX
XXTFFVfop05u3LgRe35EzkcczwGOzQvSQWZm5urVq3dEJSpB2blzp76BreZ427ZtEvi1
jhPAaL0eZRnLv8gfycF5eDlgxzA7OxuPnRA9wCknkO0R4L2QqQGSIuY3FIklasY7iW/w
XiuhysMOLNpNNDJRaQ7SwaouTow4BfGXITvAC8rJyTH6tPPwOjvtqlWr8vLyQnTKxn4O
6Lzo0QYfcz4FNHRORpP2n/HGceUK422dnjgqUQlLmOLEaZ7wynM0ExE6IlgR/iuvvBIy
B9scsOFLHdi0aVNoakgDN3CqAkP/OfATpcOuyDhkRoBdR7YwvIaOJ+ijhTwgUYlKmlkg
DdbAIABbt24V+eP0a2uDwxZ0Pj8/f/369foOjZBhjku8DmA1Tsln6MgwZ41jiqNyBAsW
ZqmHhHtYf4wSvkSlhURFoZ8S30ZLxvNQJL958+adO3eGOd9tloSW9U04lcGiQ4NDCANo
d2U2+9iUdNiymVKkCBzZgh0JNAwHs7eMHh+V92BpDkzSHjL26kctlU4ByhPOw0gOTpIF
veNQVFhYKBYB9GuTqQpsELPm4lxdYduid3TEi/mA0Wbw5YhGJirNsQhnr2YTPI1FSPcX
sYvkiRHA6zh0ggoBELhLnEGchBBscZXChlIQlahEpS0X+AC0nNtQdFBcXBzqII23Mu3j
ZPAWeyPji1gdlahEpY2XkJbDkMzQaJnmAWVotTAJGtkQ9u/fr++9DWVfVKISlbZcIOc9
e/aYnIFb9NanpII0pJcQd5ErDfYYRg24kqhEJSpt1/khDFF0AlwbJaxNhGqFtyxDGcOZ
Ghq7PUQlKlE5NvwfwtSoFhhCDMnQ5uDt0TDftz0fohKVqLTREpKzCTyM3Gns5xDaHJAu
KCH2e7Q3FJWoHDP+DyZwb3Q2aXOQcuG/Ql+mNL+FdyAvQ1SiEpWjWELmkObnECJHRSUq
UXmvAQKEfg6NbQ6NzZJRiUpUju3S2CCZZnOwh0MkXEUlKu9ZtSINXRaQxjQY2KhEJSrv
kWIvCPGBxn4ORqiOnBmiEpX3WgkdmaxNpDGHyCAZlai8N20ONkimZbQhS0sqgD2PBK2o
ROU9rlaYS6QOIkA61jsqUYnKe9YgGbpPH4paAYBkqiHpFcnmAKMrKyvj29CyoNXBavhX
53WQOogvZ6wqQBGNlRoaPRzuYffOqEQlKkfdz6FxdAbF2abIFAlepfHSIfyioiJdYHg6
YIvEGQDB5gw5p4qLi1MNmezAMuJxsAJ4QlpqyKhEJSpH3c8hzRPbhSX+1FNP/dOf/kSO
yD179lg22LdvH+GfXFxbWyu2cOGFFw4cOJAMtoDVQ/I62L9/v2rzeUeShi7caRnnoxKV
qLw7/RxE78OGDfvkJz/5wQ9+kAT3JKzkdpZ7Xfbxj398zZo1oFKTJWfv3r1OYosEop/6
Sz/Jha0aQNR3jLnNINEri0pU3j1+DqGwkVa+9a1vPfvss6effrq+0R0kFdx4443//u//
ftZZZz300EMPPPCAKjzzzDPvvPNOPfe6664bPny4riksLLz88ss//elPf/azn33sscfQ
RK6++urevXv/4Ac/0PW6F8uD7RKOE492oqMSlXe5n0N2draoWPQrteJHP/oR9sYBAwb8
53/+55YtW8rLy4uKirT0i/zJrqt/f/aznw0ePFgHTz/99EUXXbRz585169aJRWRlZUkO
+elPf/qpT31q4cKFqvmUU05BzMBEaViJyPUiKlF59/s5iCfcdttt27dvX758ue5atWqV
tAOt+x07dsSMsGvXLj3oQx/6kC6gqp/85CeDBg1SzRdffHG/fv3QLG666aZHH31U1//4
xz/u37+/rhRjed/73ldQUED+Pj8xUiuiEpV3s5+DwSLOOOOMb37zm+ecc87Xv/71j370
o3/72990vZhD165dyXEjJiN2IRUjJyeHzcpLLrlEooUq0Y2jR4/GnnDzzTffe++9OoZj
gGd73HHH5eXlxRsywxp9IhXFgkUlKkfJz4FipwIneQcoprS0VAu9lnUdPPfcc9///veN
JjdkyJBPfOITOnjqqae+8Y1vSF9QDexcfO5zn5s4cSLM4YILLhg4cKDOd+nS5dprr9WB
VI8vfvGL8+bNU7U///nPxTqQbSQ5bN68WRcYK7tJZMuoRCUqb8eToUmDg7X40NrQpM2B
u0pKSrSgFxcXizNIKjjvvPOGDx9OklwIVuqDhIH8/HxpBzo+66yz7r77bpF2t27dPvWp
T/39738Xpf/0pz+V4qCTubm555577le+8hXJFZIcVKcq17/iLdgu1Awy8aUl4oyYQ1Si
cgT5AzZ/G/TIpRtvBkNSxeoD8jyOB2xTkkOTOnGPRH0QFXMg0UI3iq7FRnSvHkSyV9E7
ZgfdKz4ggUG3b9u2DedJnBnYHtWBLtDj1EKShoceF3acaIUO1RiX+6jU09brj8bh2BiH
EGY2zG5pJMnQ5pCGIWnvAogUssWYQK4cHe/fvz/ekDWPxJqoALogNFns3r0bjiTeQrJd
MQpdv2/fPrybsCqQhtt3iauYM5g5kOG31UCazRlP3uF62nr90TgcG+MgwnTOa/sUpWHG
kigzTa0QbZJcm2NVIn0B5+fCwkKyvesveztLEiA4Ai2DpPCphhTbOmZHEs9nAih0oFtw
lBKv4BFcjzyTOpieG1WCDU20jFbITm+ZjvydrKet1x+Nw7ExDsjzps20miG3xmoFhA97
0e1btmyZNWvWxIkTBw8e3L9//1GjRg1rKPo5dOjQESNGDBgwQAeDBg165plndDB8+PCB
DUUXDBky5Nlnn9V5/tVdOtBJ3aWDkSNH6jJdr/N9+/bVsb6fe+453agzuky1DW4o+snx
0KhEJSpHogxvKCbksWPHZmVlvfLKKyJ5i/pp+5gEXuHSLN6yZs2aCRMmTJo0ad68eUuW
LFm6dGl2dnZOTo6Oly1btmrVKh2vXr1aBzqjg+UNZe3atfrWg3T9ggULdKCLFy5cuGLF
ipUrV+pblegC3cv1+sk169ev17fq0Y0674tzGorOrDj8sryZcrTqaev1R+NwbIyDSUzf
ItKZM2dOmTJFlC6SLy4uxjgQ+k6zlYl/goQHEen48eNF9aLc3NxctioKCgokWui4rKFI
y9C32IjUBLwiixuKrtQxf1FUoXQTsSN962dpQ9GVvpFbfJf+YttUZ7jedx1WKWmmHK16
2nr90TgcG+MgKoP6qFMELrawaNEiCQOidwx9afHaxx13HDr+unXrMjIyFi9evGPHDpGz
bvd+YrilqJoxCGBF1AHOCapcfINAS7XBIRLhpiQ2CgNBUBs12+JxWDqaGon2hNGjZRhM
3DCwkGBr9dNbCGVtIc/g2y9MCbWE6DOPs5qnMQyhLeja4RaPM3Fw+KIcru+9N5d5ubYp
/bN9/mkqoXmG+2CIotKKYlgG5jYRT9u2bZMwMGPGDMnwuiBNp9A3M0fCxvz58zdt2oSQ
YAuJKRGzIQfQsrgQWwzYOiSZMOGxLsJAeK3saeJlzRRVkbjCq9e/mDoPNxkoG6Mmdsi/
OUpR8/Ly8jDS0ke2Sg+XCRzBZKbIchpG+KRxLegLsatYdFtHFCBpMOBg9bQCH4MXSiMJ
vyXg7p+9KU9TNYE1GvoOeV1U3k6B3llSVTZs2JCVlSVdHskBnULfVitEIwsXLpSYAUWn
ggx6/gln8MG+ffsgeRW2SPBbcIAGnhJqCbuZnGcDYm9DYYLBUnbt2nW4+7Y8EQInQEN1
smnSZCF4XE2itTrWo8GaOCqF7R6Nj0Zy9+7d7A3hK4Lvh/qi87AvNbUVj7CzimpTVUDx
tKISXpmONVz6uWfPnlbU0+r3q5aDFuINuKi0okBldiHQsb4JkBThz5s3T69YbOH4448P
c21rQmrwJTZs3769cc5NMwdoClbAs+AqQD9B+5YWYCCa0vv378cPipUaJsCKj0eEZpqF
isMqQECoQh6H2aSF6+2UxVaO2vAOzPAWCm9H33ADnEZgC/A6dZCB0hi22q/G70IHesus
/odVeL+8cbUEdcwuc/+8QpuZzJKgNBpVUXkbRcSI6iomACHbJWnHjh1z5849cOBAiOTg
3QqYQ35+vnXSJgUSDAsseZMnT27fvv1ll1127rnn/uhHP7r00ks7dOgg/YX5jJpQfrDY
I8uSBvzE4nQr9nMlEalmNmIwm9i5ogWNgAvYoCHG/GhJd2q/xwE/E/xRrebDLhACWyFO
cxcdVJ1//OMf77vvvoceeujhwyz333//448/rnftn0888cTf//73h//JRU959NFHH3jg
AT1aDdBz+flwVFpVbrvtNkRQKE7zCmRXTTwR/oIFC5AczBZwiNLk0fItusaMmeaSEWrZ
aAEFBQUDBw688847x40bJ54jhlNXV6eDUaNG3XPPPU8//bQNDijRxpJFiladmC4R6U3a
hzv5EQYc6xGa71pgDqjeGGTQeo6i6mezKt2B18FLPfiMWyuYmG5khKlzxIgRr732mt7U
64dZuIV7X331VX1rKdHB6//konml6VrXUJhjlNej0qoyZMgQliQDQUOe7A8uW7ZMTMBs
QQcwB12p88uXL8cg0Fjpo6AmSMAbOnSoFo6ZM2fqTWnOaJ5otvD6NmzY0L17d3Ci7DNJ
PWgl6IwEU6g21sfWKZKY8hCNMLXZ5bvJgqcoqj0ydsuO64fr5toKtQixAXsCDQvrR/FB
WWvdI1Sz7tVoq5LZs2dLKahrVYE5wBlgF+9A8YN80Or2R0VFigM6ONMYLcN7WCJ/sWIY
Qgj2oltgDhi302BmQywI1ZyVlSXOMGXKFN0l+oIpsayocp1cuHBhjx49xIg8zzX/03wy
dRnrIyYIR38cLnMQ7VAhAjnfLejO4EWo7yIZetQCX3oHAmFoFd2nL3wTWe9hJ8CkFYZE
5AcsipIMvfS3gkj51otmFVAj34H5rKdY2kljFFE53LJo0SIDOkEIoncsOSJGTQ+Rc5ix
wkhQYg5Lly6VvtDyFp4uGDRo0NixY3UxMd3IACqadaj869evnzBhwvDhw/Py8sLsFWqA
+BJKhPf0Ea0xqodwVVxvr05ImD21cN/WgSFwv7S91/AYEQUB3uBXNAxLCHXyUI7hq06u
gXwS6gKYDeGi1pjoF832FiTWAyrnGv7SeUli1r+IbMUKpLFyy7EHcg1P4YBh9M4UjbFH
hzvCIMyfPz8U0fk2r+AgPBmyESjUxUI+pJpWCd/2ogmX+1A7aE5OCKvSROV29IuwST72
2pRWf1oj0YaaO6Pa0vp4iGJSG2JWWrWdhCIEjNW31Hyt5hqN0CDpvBViDvpX17TAHFTh
1q1bBw4cOGfOHHGA7du32yvb+Sby8/PXrl27YMGCZ555RiqGY7fxgsCnAhgZHbz//e+P
H8yjoZ/6933vex/7m3QhRLkkXOv4448/4YQTMKTY1VM1q0L9pdsx3GFSgBfBCSFP/Tzx
xBO5kWgy1wM1sW8YP5jEh20d1cNWC/xNJ/HN0O36F69O9gV0o/7FqAJ/1kkPuCUopAVa
grRDm0877TQpSrpYxzRb19AS+707Wk2X2UrJSzQjorMhv9Uj9FLSCIcKIQRNcq8aOqP5
cOqpp+pYtMn8d7wevEI/zTToXUhTJ510kmlT78v8gfHU9dSp41AO0b38a8LkPLf7KVC0
RkatNUUbFjXsl/+iUKEu00GaBOVb1B7Vr96pKp6rR3gxDa98raG0IclBE8B4DsxM+9dp
umq5xyBp32m+NZc0IFIrtHKxpDa3T7pq1aoXX3wxJydn586dOFJCs3hZ61scY/PmzevW
rXvppZdeeeUVhAoHb0KkuCXogHFG49a0wcVFL92Ic9COClh2XKPaxFWAi4HQ4AwSkNR+
TUU9SK+Vx7FRa7QKuIGmri5G53IDdKXTeOkAmV//EpyuVvliuBZig6rSkLI/yNDRJF0G
29R5eBScAb+vELpTDSY3EGyEf3W7vtVIcTB1TW0w7AYHWCq4HhmDoYa5palpjIAWjnCd
NflwAKFBCPrWQ1ms1UFfw3nfZQkB3sI1HJgM+Vd9hL1A1350WBvkH/50VaF+wTVUxQU6
D2eDll25zqgL+ktd0ADyOCwn5gPucgvNoCquDwetzSk4UivCAO3QiwmbgwYwZAsUdtJX
rFiBa3QLEHPEa0g2EGfAyxFxOvTcFscQf5g1a5YuxjqqyvV2dJkmCS5PWBG10NsEp39h
1yoQC4QAo4AKWC6xGGDNY8WES6iofq+tnER6xw6DMyc0BRNAjoIbQGL4HuAoxZW2Bqja
U045xeIKuhhtMBvhG14BCcOjdAxb1nm1nMssF8EAaTC9VqfUF7qmyzSwah66lc7zTkP+
aVdPGzFsHvGBmYPlYUQ1Vmp9h0wjjXXwIjgICTykFwsSqtPcBrJS5Qy1xQPkAQsJuiwU
ZkTFpnTqFHOGBZkj0RELIWENepbuSnscnCSNgYR9pGbfqEroSMgJ9RRLWYxDC4rSu9Pm
0BidFcVf5B8yh+bUihbcfaVQjB8/XkICYLBMUUwc9kMWhxF/eOGFF6TkokTjecu0t9bA
T3gLZIh0DQXpMtZQ/Qs1WaPnPIYIJHxVpUmCEzViErRvc4rjFByXilOWiojOF9srALUF
YBxEdC7jud4jRkiDgehb3US2wfmZStQXTWyMAHRfNWjWoSvpJFoSvuh4qyJpWFPgobqM
3qlJ3l/muZxHWbOVxqqlNYtQrdA0gABN3XyLsai1Ifnop6iAk7oeGQDBuznmAEV7o9x0
5CsbL83c4hWcC1y5xRLrAk0yh7TKNch6y2ZWvgampLvYkA0ZHV3Q9W4wlZ988sni7fqr
ccvbkPzAYh0CxqKTigZF0UuWLAnVitAgqfMwh5adBLKzs/v06WNrhohaN7KPKRJGAsev
qW/fvrrYljRmKbRjMx3TXuSjWU38F0TBbBfJICSAMInJgogkvT6oCYrmLgsbsCyd1+OI
AGVPUJfh/csCDYFrKGgzN5ImmAbrYv2rGkyqtAchBzLUNTYhotEQcKoxoX66iTak9rAv
iYSDMcGiDvVY+eIuBgHmCZlzo1UY81iLEzw0DAPhOGQOpkRkfpaMNMkhpOi0NVevWyPQ
nFqB2B/q9WgoUgb1CE0S6yw2V4YMSl3Q+4VUTae6EvKk2U2qFWypQ78WAMx5LEKEkkBj
ZSEkfOkjukwcBpbov+CNyCdtSK2Q6Ghrnt17WIDEHJYuXRoaJK1WpBoyVx6KWiFton//
/ppmCK5Yq2zo1liJRegvyQyDBw+WckFtLKZMfrQDtuCtPrOvZwcM++ueeuqpeHtCLzZR
4rOtZ2GNRDGB0WnuQYBUCMadakCusPEBboPIHQJp2lOCY/RWSBI/ZxrpvQz0I7QM6jR0
HuxI35rhWB1FFLgz8Tisc/oXDol8AlQXzAEegowE06C/9EK3e0MWCQemgRQXapdcD3Pw
+0qzszHzJSEg6qvYvgcJ6CcNZvPaVogmDZLUZlUFgoJyqcTLLkIUlg1doC5LdwuNAJpX
lg30LxygSYNkC2JJyBMs/6QZQpFwzEZsLA21GzWeAXSD25zNwYtI6K6AWpHmPm2DpJlD
y1h2og6pFV27dtXiCM+3Ex38gfS4nTt31mWI94RiYZETfaGMoBeja5tXYJTD1YqwI44R
NjznMQuwvcgeKHv6hqjlLg6wMTqmyXbC0BvE7gTwMa40G6ESTCVmRLapmpdSOYZBO4wZ
A5MDusk11ODRMK6vQ8nsZEKvDdRpdzKGwo4QvgxOG6YnpjuaG01uR1qcbqwmsL6HknMo
gTe3lRlufYb7mFwcKguNtyBDb6vGG5fhSt14K5NKvL0Sttwcxq3yvE0bh7Rmh4NDhZwx
W2hDwoMkh3DJcIAkAvPy5cvTJIfGfg4tuBNDhqtXr+7Zs6fIf9WqVX5HdnN95ZVXOnXq
pAs2bNgQxcYe3cK2BcpU6OfQgscR2wdMePs7WXJgQQ+Xg9b5U4ViRtuSzNtECf3ew5Oo
FewReMFFwX/7fg6qDRgZcYBevXrddttt3bt3X7x4Mcufbu/QocPtt9+uv3TcCvCWqPyT
IvcRNjQ3pAS1MKm0XIpUvfKGrolsBYaCROuIOvJ/Piq8Aj6v1cF77hjBbL1v7Ofgcohq
BSI0Av+6desmTZr02GOPXXbZZZdccsl555136aWX6uf06dO3bNmCxSAqR7egBCE8aCbM
mTNn7dq1O5svubm5Yv5bt27Ny8vTT02GTZs27dixY/v27fn5+Tsaiq7hSgmZOw+/UAmP
2Lhxo87oeGdUjmhhkP1Tr0+DvHnzZumVhkVywA7abpN+Dodlc0BPRxqB86gNUi4WLFig
VQnYSc0ZbG6tAyeJypEFS7FtREt/Y+eoxrEkvDsOsBfxrrmLdcFx8YfbHoNUwLLUJOwk
0Zs64u+9MSoL2iVGKi8cdoM5FD8HYitadnVg78P7ZewkgmZmFDLiQCPUvqNeeCOsFywW
jkBpsoBADjcIw0CAuOSNY6T1BYde4Da0Acg+TRugfqJyZEta/juv6QZnM5025+eQZpA0
c2gBPIQtQoM+sRHg8A3ApXE8bgU+Q1SObHEsmLk67KI5ToJtCiGTN0uECFOLV68DnQRS
8nA5ldgOgIHs9sJkWlFPVN4SSBZ6TEs1y2vF7ceuDjj8NPZzMIbkofs5IKO62jC4my05
QrCN4RCVo1ic8xQVD9+MFkLUw+SJeFZIBXB8qzOlGiOiFTYQMp0xVy3fRm/qyJY09NdQ
rUPfZ+sc2Y8rm/NzCA2SuCK3bJA0kIIRCXAbsLRp3JLoNb0bMEVTQeJRXC9awJfAESX0
BAu9OOwWghN7q9Vh77DjqRK9pn+S2SGNUcAN/Jd9aZr0czhcPIdWwLipQhCNJJMYGMq5
v5FzUg2YxvTCsPbAzhAlavB54O8MEGEcA0Qp35sGdMAmrMOZCUDgDAAIyDncji2FNdSJ
QdGXMaqEG7uANIqgQK5AbKbN0CAZRXlciL8HRoQxKzhvxEiKkb0tKzr3aAiL5zwg1i7d
O+p3lgGehYLAUIeu7C37SxCubvy60Pk2bLk9K0CoQ/e07EHoCsNo8E+rn06EwcQII9Dp
C2/H/jbUb9yMSIt8O/4wb9/PoRUYhl5rmIdwA/4lAxdQD8x5Q5RAHVArREdqDPBg1Uhi
mZ0FA1ozerO+uR4SINYDV0lTnJGNbWqzQZUJr+ahjjme2goapGq6cPxIKsjmQ4VYgaBK
uB8XQ2hU6LYZRoZFnNAtA+fyM2SAugugGBsEuMaYnPBGm6GgL3gjAXGm01SL+SysVtBZ
swg6600QI/caOJenY6NASNCxXzGv3u8C4GI4A8NCzQwjfUdcARWHd8cIRAT+Np1h3j6e
w+EWvVajRDIBAF13QDFvGaAquyiz6ab2sAHnzS+21dB5gbfiEQSAG1DaYgChT2jcPo/7
tMHTaCEkT2YEPVpDxL98m2PAIqA1nsVchRexLDqtOco+Exiy4kWocqJF7O1sl3KiuR2a
wcXg2BBLokKn7NQNxbGAMoZI7PYJp7+QmMHBnI2dYdEgI6e1oJuQ84JXYEcaBtZiAy1k
ywOveAbNMSyIi/ZO9xYbvBFIMXgaATKeDL4LNmtzh/5V5Y6qi7SJVpe3j+fQCoMYHrl6
BKhHjn/0lDNGgXfH1ACInTXCaz3rqZNloLqCwM8M1KTSUwjfJpzKsczWc6Emo7YeOHCA
CUwzIFh23FIH06mwUELFxFMTFeVvCJA4slDFo1qTjGYyoVt4C9BmIKR4kA25NINHY/qz
XAQjMpESB+r8FDw99J+Hw6hh+gZoIkSZsH2yZeIyBAehYbAFxpDoNgzaiCXemnzf+97H
W7CIYsBPwuv8aF0AvSNOaMJY2iQOlzYYApQxt+oahqVEpXUGzLeP53C4BWnQMcXW5UW8
FshDZZYYcLDmePsOSLTqnTqYaA8lWoKHMSSRKABqAxIKZqKJh67E+g5ZIdmqv9YC2H8X
CQBhxz4g09Xo8QaZDJmD00zAjnDw0HQtKCiwjozneRhKT/1WydEIWENDYZ7WOg0ZmJPW
6wmBpzZ0KOcW5AKPP1A8oV2CxhgzE27Z3NaYNzcRO51m1IB7tpaYqzuUnleDnkhgPvKe
Me7IPwJP4xZeK7yF2pxhhNniDVmWDOuGUWlFOSJ4Dq2wObAQs9wwzyEiuJOlbqaQQ6fD
1JCAORC87PBqJjbo+sDEYQFzParEmIeQDBNb19se+P73v9+T30uwUVnELcMUvY6P9iOY
xk7OS9y0UR/x8yEeGVGEWc066I7oKZr2IYIN57lAD4Xi8E0yAhVVWfyzsfG4huKfiBZG
rXTeYUiM9+5lomV/Cd4UiBx0nLemdhJF7mbD53WgmoGmwd4FV6e17IYY/RJRwaYYOJ4b
ZuHK0wP4oHDETjrpJNt7o9IKm8Pbx3NoRUEqRoaE4YeYikwVvXfmMHIjc0z/On2krsf4
AGACs8LiBzciW+pKYzWY6UHImnKIJTTGBGJAeKQaZinoTLQNfYQ64VQ8CB6SOpj1j5Yg
ZliuYPkDn1Z/wXAs0nOl0/mZiiEiOKTYC8KV5r//QsZmHOgLEHPIA9TpkQS8zo4ocGzG
h7sMcNHCFqfNIzA03UIzRJIGAjWqHm5OwGwyu1BJuJ25x2IBMqd1QAP30RiuZ0hVD0qo
ma35P5wToKGotNrm8DbxHFqx2cpsNHaiUVvRu3mzIC1zHkUV1mGfT6YckwHVGMnWy6JR
GqAp8QHWLIQKuIEr4aGpIO2FVXXn/QTmRderPSY3GAWzndrApLUREn5lEBsYL6iYkACE
A0aNdX/jW6rZHje6xuR3/JRTEXnrgUYarff4hmJjAisyvAh+6w1uc7aQDFuIiaCDZkHw
Up6ivsB/vNDwcm2c8fVIMt5h56XwunUxiiRchX5xbFZmWQITDf1CCGECRDTeajp9+3gO
rRBX0MEhMYRn0N3RqQ30qmURHZZp4P19Kx0suMw91lPfaxjnEOvV0I5I40wz5G0WfRdn
voC9oA4jaVhDQZBAK+e5fDN1JTNjaeQn0oXqMay0d1UQ7N1C2oO8zRJs92YtqaE/hlUz
2m8XWcbKyHWG78OeY5hK7rXpxh2hhlBdakGtYIg08ugmIVAnvM7vwvqCz9iwg5oAB0YK
olreke05DJ1vd2uRSZqbV1hFuB4Z2BvTUXnLrUz7OVgftwr/z7A52DkHmrWgzoRkvTCO
IpQl7qSJ4UQ2LDfcbjBGWy0gilNOOQX7IXMJ1mGd2jIA0w8YZ2wCOjYUfOpgthoIGaRK
5Bl9YwPEoOc5b2sbtziHBczEzQbokvoxjeoaWmj2iGIihkD8GowCed6IkSHerOmIWwzM
a6heJ8fxX6G3lZqUOojsTfILM8kmixO1Gy3TThRqqhi7hkgvjrGyGUfvRdOJ0c7Pz0cn
4uXi7WDap1N2xrB4EObjCDFCm5tXsFb1zkm+gEGOylsWDZr9HNJ2K/5JakUqSK/ArjR7
FkjjoYRvERcjYejnb3pk7vHSNeVCk6NR14zlGKq3zFVEX5v3Uw0Ald4CsO4PU4Jbmg+g
d7D5zknbHHg0IjcivRc7nUc7sKnBe7K2MGBXwVRrDQLbCK3Vlbh8WK3wQ6EIKyMYNwzL
aWs/reJFILqzdQjHcMcZ0uYMR7oSpd5mH2+AMj7IcvBh2w9pki7W7GIXkuY5BodOqYW2
l6Ya8P9JRKLXJ86DLdc2z1dffbW5eRWi9COzoQxGisNbFg14dnY2kkPr8BxasX8KjTBX
4efMCggKcsNgZTpFOIQYITq8kkIfSGBsud4+CeGjAbRH29Xtoc9S6iAGIwIzlgc7ah44
cMAxI3YwQDZAtDYOf+ogcCUbl3bx9d49ahGVqGaNvL2qcAZAoUC8wfhg5yV0aggTfcTP
wriHrTX0SKda9cLxVjSSyBecLWm8cWid2MJ3NVnsnsR2sBNkeFT9ljHaULPuMtwu344C
s18THAPhgQfZyco+53g9UbPNUE3OK/vA2E7S6gTE702bA34OzblPvyWew2GVEA8ZewI+
0rgZQ3QSOHmnTpGjOY8MjKzurW0cJhFu2Zq0CwEyLeTplDSOrUBQZ+22Lx9qKc/iESI6
p6uAR+HgjdRtnmPHBnt9exLavxrjAPMfJSX0Etd5Enk46zecx04R7PKDzgEnhGk7B7rh
EUw7GBNosD20Q28TlnvvRuGzbc8NbCbNvUfeC0RtEGC7Ott3ggFXzfadsDGHJmFacey2
E8Hbg5Tu+AXZTYWkiqFvTJPzyv4bGHaw/TpkIyotlNDmEEoOh47ncLiF/TtSUjo/Jm8c
IjLCoTenmPAhITuowTFETHgug6xwsoW0wQcI2YsXEZYb/HmoGaJz0JAOUIft82z1VgdE
UdEGBNc0kxccw04+DteCTh0A4hwTDrF3f4244oAOWITNGuw6OWCBgqWI66FfeK9jKADn
cciSE/i6a3Ykay62wu8F8vcwssTDfu3Rau4RkjMvEVaGS5j1LHtMmZV5TETdWj7MiGhA
c/OKgVXN8HnDF0QmhcMySDaOrZBEccRjK5Bm9Y1WiMJLCAMzxPoCLz1M32aF0esvqwD6
iGpQPfa3ZzlmlzzVkHgulDQMbm8wfHsisc5aUUUTwYvAuj+hDYi1DqYI4fIMj4/Eghhv
//CwZsYEEkBmUFNDbHnH17vBTrupA4bRjtlhAEsYl43egahAB42cQDsdzeHRhqibe48a
VSrE8uDXGkZ5c42O7ehl51LsCY5T0xxDC6DX8AQcwq2jORCMEXCyePre3LxizMNsgGim
keLQcmGVtFqRtltxiDaHqsr6j/S5Sn2qUg0fjXzy4Pl/PI2PVWxmEfRll1en3g4TLhjD
lilt65b1aBZfk7+nvdVP6IWYC8dPmQqcZIfHGbvA+qwb7JBSqrJXv92iHDTkCAWWUYjF
btv2wbAiDNuh8QQNcZmRP90Ah01hgoDbhJgtOsZug7Lj6FcUDdrg0DAbNJw4wzzKNp/m
DJI2gdqoQmshfKP90ELqdF9I/cNdXMBboGth4JjvoncMYAhgQhuam1d+v66wZaYXldAg
aT+HlmMrmpYtY/FURbwqVplM1MSSNaWpypLKivJkaTxRmqwor4zFk/F6YoklKmJxnSyr
TEpMrYhktqMrLiKco+lbJY/KsV1Q8Qw+b6WV5SzEDIR5Eg7vrUz7RobMoWUnKDGH3WLS
5cmK0mRxWaIoERdzKEsWVcSKa5LVqVhVRb3VqhTOEJeGXVYSkefRLchmCCqo6p4nUTm2
37ttv4iUtjiFwEGOsmEd8VZmWjkUtaKqsrqmvGpXrKa2cpd02WR1VbJG6kXDZlZ8b3V8
dyopPUOMqLy6KrErVbu7ao9uiQS2o1i8h4gegVoUDct7wYYA+dtEgxrrXXjrX7a/6dsh
200yh5ycnBYxJKW17q6pAoGhnuvok6qMVaeqahL7apP7a6trqmuSqaoGY12iWtqHbone
1NEtBw4csDuBd4WqonJMF5vuOUBssF+QTd8218ArYA7WJhrHVuTn53t/PH2zO54orqwq
SqaKEmXlSQmrov9YKlYcLy2sLEslSmsqyhIVscqKRG1Z5a7SquqSqkRFPNpAPspJK/A6
MNYBU6U8Ksd08Uv3PjILBPvR3p03Bin6BbsVzTEH/ByaszmUJ+L1JF+dLK8qqUgU1fOQ
8ngyEauqrK0o3R8vq4vH9sVie0rLdxfFaopTFWW1FeXJyCB5lAvmKbH9IUOGPProo3fe
eedVV111XVSO6XJDQ7ntttsefPDBwYMHL1y4kPwjbNzg5GPUFGPMvqXNoUW1IplIlSdT
xVXVRdXVZdXVtanUq+XxA4XldSUVdcWldaUVdYlkXXVVXU31nkSquDyRKxUjEuyPYtF6
sXjx4l69ej3yyCNDhw7V0kDw196oHNNFNI4teu3atc8991z79u379u27ZMkSUEDt/Y7B
waEE3soMJYdDjK2oSiVrUrGqZHFNqnRXbXVZ8f7p0zbc8afe3/ruDR8+/Wcf+8TPv/HN
6+++u1/mtK0VJa/t3l0rFSRiDke3TJ48uXv37qNHj2ZW2CFkV1SO6YK/HL4ieuO5ubkT
Jkzo0KHDrFmzcLB3UIw9XkT1Iv/GzOEQ8RwSsXiyPJEoS1andpUW7Xvi4ZfP/uKtN17X
f9TotYuXlc5fVPjypNy7/zDmm1998PGHZxeX7C+Nl8UScUSREPTP0Q1Wf5x+wiED6Mj+
13v09qZ2UAB7c/bETlO30/IaWOm2zzBtM7RjCJZuFOswjjvcMo4fTJCBL5Ovb5zWQRfA
ddH3Yb+4H3hHyWEXrdtqDB2wefqUKVM6duyYlZWFDImrEhOjrRvcDKCNf7VdInGVxBDH
sBumxkDEdq9K83nDdocPmxGA+TdE+W4TBXsjuxI4wmnizZ0798knn5w4cSJO/qHNAQqy
+3RaOTQnqGSqPFUd319Q8Pqf7x11+hm3PfLE1mfHxOZl75+1NH/2soK5i3aPf2l3zx6x
f/vILfe3H1cUe72yeh+hAU7PanwAlCBMJfxF6ITzuUDF9I7Nesyt3q51+h4oQhNDddod
t7m8BjBJk6QDuLzha2QAbDswMQdN8FwwZIjtMjgqPqh22yMIgnvZcbZ7oeMamLeEhDjq
oXVJSRykQBekTQwaNGj69Onbtm2z62YY7dimC/EpRiXl7dN3xtBDYeRwppAjWDm2P7mx
djkThtka+zr0aX+Xl9TB1IeG3tWZnTt3jh8/fvDgwZobRnN1LAA2h9AJ6jD9HMQZRMOv
jZ9c/pHP/Okz5w58ZMirAzPqBmQkBk3fOWja9mdmJJ7LfLXv6F2X3jj13z/3p2dfzCss
2QdPduQg3Jgpyvm8vDzxJecy8MYKhOxYbN6vvWGdVMKJfR184dCGVKO8BnYJS8uhwO4e
8ozjO+AzOOdTJyZfmoQQgpTucA+j3yO3sAbxFC4jnMrx4HSKPWjeVOpggstWRN16ldSj
hw0bJuawadMmDNcwXnjUMWBlXbBgwZAhQxxWw5uFFnjXOtYq+aUvfQk+4JSyHmcogiiP
eEMCI+cBYTwRv0MfobYVwOUESWFo87p164Y2FNzhDDDYglpx6HgOyUQsv/j1C/9vxAn/
2eV7t6658snyu4YV/vX5DQ8/v+yBYQseenb9A8O239Fny+8eX3fSFzpdfMP4wvI66FrT
Uk856aST/GgQ4DGOmeJYpmEgzmziUAtozSEPpkpAGuE/9s9vMq8BUU5GVbVlhimkEYBs
LR449qEyKE4cY14B5AhQKs5HCSgi+lSqAezR6SSIEiKjloOPnNWiFbEAYZ4gVSj18Kmn
npoxY4aUTXiCF9NQi2m75bHHHjvjjDOYKvDhMH4W1bh79+5nnnkmqpwh/pCdEPacUMDM
GUnSkaT+SQQoGnpbKU6ijWKuySa5WiOTkZHRo0cPcVcC4uwoFTpBgQV6WHgOZfFYUTKx
eEv1R77V5cM/mvDVW1b9ulfpbUM3n//n/sd/5fsfPPeiH/xxwG2DN904JO+rv59x+i+m
nPGjvtmbqp3vwBBtKNoOwjXsIYKxgdQchGvBW22zxUC8BUS1ENwM+H1COFNN5TWAHrkL
sgrhCPSv4yWdTo64TichZcydgwM9wsCGTtkJxrWXIUut8CLnibNRgsR2pBMNLSeHXrxe
6CnDhw/v06fPkiVLtmzZAhKCsRFCe0jbLe3bt//85z/vkG33jpEnyEsM5JxzznFsvicb
3N6WHy7w9HNGTmf3S8tr31b2r9HTGRCsWxouzQctHAMGDJByYbODZ47Iv8nYikPBcyhP
JAsrK6euKv3383t//voFP+hU8H+DSm8fvrndf17Q7qSPtTvp9OPOuuKWwRsv67fpR103
fOWe1Z/4xbDZK0tD05xx4cyTjcNmSEYjBBpcHSxixG/yJhgS1r3gPZ7YUIqKiprLa8Aq
A/4Yfxmc+bTTTmNK2OzJIk798CiwH7HwgDBpVFvwXalTk9NjayAFg1W6j0Y240bnyWqF
5O+IdT1LHezQocPo0aO1Oqxfv17rhTpuYw4GnLZucxDhf+pTnyJg5IYbbujYseMDDzzw
8Y9//Dvf+c706dN5d506dfrc5z43cuRIKRcf/vCHb7nlFltddPsXvvCFk08++etf/7rk
K8LMr7/++t/85jeYlKWe6y+NHjgz6L+2Hr/7i7VvJ2VGgFy1atXChQvHjRv3xBNPaAIz
4b1HkObnAN0dYt6KylR1ebxqRnb+Z3/R9cIOq68ZVfHHiZUPjMo/5cu/bfe+09ud8LHj
/uvXD44rvmNC6eUjCi7suf3L1w2ftnQHYCzO+2aAZcMkgkUfP5juRLwLKGMsiiAWcmPa
T/AcQIPnL/CFADRuMq8BAc7xhpRYXGMIRDJkOQTY6SecXsHGQ6NSI8Q6cw1mCrgcLSQO
moWMjoMVbxx458tw8gijnLXC4IBOIa547733zpkzZ1FDWb169Zo1a6Rsbmoo27Zt27p1
65Y2Xv785z//x3/8h/qi46985Ss6vu666zIzM3/84x9ffPHFGzZs0Hkxh1NOOeUXv/jF
xIkTxS3f//73P/vssxoHnRev6N+//8qVK1WPrhEX3bx5s6hGDEc8RJxBXOLKK6/USY2V
nvLKK69o0dTPtjI+Gzdu1Dfjo+O1a9eKLYi6c3JyNCXmzp2rjiMnM2eY9nafTlMrDsUJ
qh7DoXLP5KwNv7r3+ZuHrP/j+JL2c3d3nlnz/Zt6tTv9rHYf+cJ3bu7RKTP5wNSKe16O
3/R80Q/vGZGxbLMjO5ynwNAHzoHiaH2jTDhChIwPAJPiB86ijLnAKKbqmq4kHSe3NJnX
gLUmzFVhPHkEKlMoF+svNylEYzCPChNh0DADvJDpCTHJKWNI5aDzYkTOHIHZxAgnrbBG
OuMDm9q33nqrhMBVDUXkoLmtGbJ9+3bNFs383LZf7rvvvjPPPFM90vEPf/jDn/zkJ/RL
hP+JT3xCx/n5+RIPdCzBST915f/+7/9ec801ooizzz77V7/6VV5ens5rWCQx/u1vf9Nl
O3bsGDVqlHiIRAhxCbECVSiewLdq0DVtZXxosF63OqVv9UUMU9NgZUORZqE+ohEfKT+H
WDxVFt81Lyf3dw8M7Txh+5NzU0/Mr+67ru7xJbG7X865aXRW95U1PVbu675k9xMZFR2n
lv363sGzl603aCQKDlkP7LcAbnmIrN5kHgpOIg/TGCdKgB65HdHaambjvAbwEySHUKdo
Ll+G08dYM0UJ1e1OzugMF/GDmTg4pmGGjLPkgMFB7deBs93BSWwWaJ31ieZpVtx5551Z
WVliC+sPFhEC64imhAinqI0XkfMnP/lJ9UXT9dvf/vZf/vIXrG19+/b9yEc+ovPqb+fO
naVQ6GL1V//efPPN0hTEHHTBI488Iuagv/TznHPOufbaazW1REe67IILLtCcHDp0aEFD
0ajCanSsatvK+KhfarCazXvXlJAIpPkgziAxcvHixbfffrvOh3u+aTaHNIPkW+atiMWT
BaWxNVtLHujy3N+HzBm5ctfzW+r6b94/rLxucFn9Z8DOVwdtPjBy0+vDs6vuGzj3rk7P
rd9RwoILnir5ZVjowxQn0EULeSgsAzi7AUqETYumL71lMYQW8hrgeEBmB6wKLefLwDzl
rHNOuiGNFSO5s17iXAG96y+JMXAzp7Q2lD1ML3Uw1yR3YQ2wkflwDVB2D2NhnTVrFsxB
DEEzhJS+6jsmiJI2Xv7+97+LOeBkIuYgIVkTTB2UsiBpgckjDvDlL3+Z+azLvvWtb/3y
l7/UgdQQrZv482jkNdlUm27XX2PGjDn99NPPP//8733ve6Idsvdi0tG/Om4r46Pe0SPe
uDihZoX4g7iEpIgpU6Y88MADHhkW2bfp51C/Bb+rOq+4bMTEuTf+teeY7OKMoroZybrM
vXUz9tXN2FM3/9W6mYm6abl7Ry8rvPZvT4+YsnRH0Rs4zBJX0CNQuhGAEcVBHUf9aS4P
BRkroBrSIRmuHNnA2ZmhzebyGtAGp3hgZwR6bzJfBnoQRkgs3lgSGEz6ojmp9tAXUsoa
KY49YuqhI3oorhQ2TaC5kKyKLtPCVoTw48uhN9inTx/p11oKkS21gvBtF822vlshwpfk
j5ODCFmCBJN8wIABH/zgB3WsMezSpcuHPvSh2bNn6+ecOXP0fl944QWRzKOPPvqZz3xG
66DOa6BOOukkqeF6mxK8xXDGjx8v8vn4xz+utZVVCRHR3gJtZbeCTQpQkdGhEB01DQYN
GvT000+T2MhKveZPTk5O46jMQ/ZzEHWUJiorNu0s6tJ/5C3te45ZtmXN3rqcA3U5r9Wt
rKvL3v1qTvVrz81b+fuHu/+t+5B1eeUViWpjD7IvaacLewzSF7xbm8tDYa8h+zz4PLuN
QEHCdsAwbDKvgbmQFY3wuY3zZQDeCIHDE+BUdr7VX6+99hpOmBSeqxpoJH3xHpl9IN1I
GyTt1ms3y8PiDB4QdSozM7N9+/ZSqFGZjXJvP4e2HjOitf7MM8/kLXz3u9/VT0C2Bw4c
+PnPfx5bUI8ePSQ5XHjhhZ/97GfFe++44w5MwRqHa665RgLDGWeccdppp40cOZKp+IMf
/ODee+9l+ZB+LYYvYuHt4F/XhrAoobgQ/xzJR9KChEmxR80Q8oLZzzzEc2iFn0M8VpqI
5e6qLq+Ix+YvW/VYjwHX/+XBPzze6YUli1Yly1cny0dmzf1Lt6du+MsD7Z/slbNha1F5
ojJVbd9gFncKlMhLhMRw1GkhDwW3GJ0eSExAiXFm8+QHQL7JvAbw0tCDmt2Z5vJlgPpO
Dfbltr8Z+4PQMnYJvr3QEFJBS3CkYXGHX9Fl3gJ6H+46yDOHWxx+q0evXbv2scceGz16
tH1FjNBr9602XfA3o1MwbYmmOmPoWqaWZpEGE5HJKc7BQtG70ErKHqUoQpdx7PHxzjLP
anODFiI+UZgGmhWPP/64VE50Ckc2YXMgK1wr/BwS8bKaypKivE1VqXhJafnWHQUjx056
sFOni678v/+56Lz/99Mf/vqGa/7U/qHnxo3dkptbWFoWT1Q6HAnqg9bQ4tlJ1ItzRBX+
Wk3modC7k5DM9AYonsvYHjUUnrGOm8trwA4pj4Ol2J+2yXwZsDJdpovhObQQsQ2Mfftr
OXUL0pc9wGkPHBLrB3zAt8BDHCmAB8jhRl1RFQ2TDPnyyy+LPyxcuFAjCf6/Wisq0LEG
c18bL+qF+iKZ7cCBAzpWH/VzT0PhL86//vrrmjPEL+9vKHV1dfrr1YbCGVUCxL2Yg07q
gvAR+qlKqFk3tq1RYkw0eznWQVZWlmbFSy+9pBmCLc55ZJpzgjrEvBVVqWRtVXx3VaI2
VVVTVVteliwuiW3dtiNnzeoFSxcuX529NGfZth1bS8pK9czKRD3mJNI+Wj/CA2ng4NLe
07e421weCvWCXHJ2dnUMETuSul7vDrJFI2gyr4H9k3kuwoC9mhvny4BawxgKBzaisFC5
umPgnRAR3ZkxjdmObRbPB2PF48jqTFut8HNwZjpnANm6deuwYcO6d+++cuVKjUxdQ3mt
odS1/SKCfe1gCc/om596141vEe0zFHq/nIT8XfSvJszrDYXhgr74F9bRJko4FBTNkC1b
tvTs2VOzQiITi5GDGQ/Rz+EtDJJV1cmKmKi+MlFdDyaZ2lXPASpiqcpERXlxZbIiEa/Y
VVNbVakra1PJKkckOZ6I+W9wS4cSk/axuTwUCBUY+mxCQUN3bZC589c0mddAFepBsAUC
Meyr0Fy+jDCRBJvCzpsAF7IN09kzcaGEccEBaIwTzTg806YVtjDMlFqHJYvtBVaDdikd
XDLklClTVGfabGnrxfM//DZFm9jNGcIb/W94novhAFxjbtCY1bStoimRkZEhmaFfv36b
N2/W3PDE9rJog2STaoW3Mpt3300mktVSF+JiD8maZLwqVp6sh3dIVFXG4ql4TJ+KkuLq
VFW8nklU1p+It/kYnzYHCoc6gylGr3vUqFGPPvqoWMSYMWOkaWpKaKq/3kypi8qxUtB5
tUC88MILTzzxRIcOHYYOHbp27drc3FxHnIUYcS3jORyKn0NFot6DujyRKq+Qbp5Ixivr
mUBpLF5WLomiNlVZUV4aq2hIoZjalUxUR8zhHeMJvGIf404vZWfjxo2zZs0aMWLEk08+
ef/99996663XX3/9DVE5Jsr1zZQbb7wRDEm98U6dOoktzJs3b8eOHUTpOjLXoEZN+jk0
tjm0HFtRWbsntWtvfWqKRDyZwrRbIw1i7+498Vi51IqqaukbyURlRaq6qiKWiIDa3pli
03roi+6dTTF86ZuSIubPnz+roUxrpkyNyjFR9CqnT5+emZmpN75y5Uq9fTw80WdDfdnh
PE26Tx9W4FVZvLKisrq8MlZZmxSfSKbwVVDNDZAIqVhVdTxVE5dkUVmVrK6ticj2HdvX
tmEEQ4eLHdfFJaRo5OXlaQXJi8oxUZqLrdBf4gZaFIA1cHCTzVz22LF57VDwHLA5NFMS
lanaZHVNWaI0XlmiT2lFYSxRr25Iy0hV1VTES0vKC2LJ4srqWFn9xmBplDninSnWHNMC
LgxpEsZrtA4vIiptqHg5MAIYTgXhVLES2txW5mFhSEo1KS5qeES8JJkqLo/liTlU1VSX
lSdKSysrYpViCPHKskSyJJ4orSgvramqjqwBR8X44LdvgAjiKeAVzISoHAOlOeaAxclx
BMZZ9UqRtlg0iedweH4OldWv7X29KlYZLyt+/UBtRUVBRubUzp26/fIX//ftb5//ne+c
d/nlV/bq1WPunMyK8uI9NbXJ8kRVlJjxaOdMtHaJE6CBmqNyDJTqZgqRAna8cerMNCNV
aKdq2c9BTOMtE+mmYlU1iao9Namy4ryBA/rccfsfRj3/4vZtha++Wrd79+s7d+Y9//zz
f/7T3S88P7KssHR31a6IObzzJc0mad8tGEU4JRqXaPTa3LtusuD5H1qi0gzXZiyeJG8T
z6Fer4hXlpeWJeIVPXt0f/TRv2dlZTV4jNTVvf4PV5P169d3fKLDc8+OKC4sQlzBZm5J
Bm9qg4RzjCO0w5bxeXZiCIcPGA0S0chwcDogHMNpLAjHUG14Je3cuZNADOIsnMDC8VZO
T29U/8YB0QRNePeHW4xazwFPcWoMgqqMQumUpoj39NpIDkaicM0hpKSxLOwM7zBtKqTj
9jA3KFyYDQTzlGuwR6W9r62VGEDM7uj2M/fQhcYNI+zhOKrFSyoqUgqgQzw9dIjlLR8D
gLdtvRBk5IxXodhwyDaHN0h7+vTpTz755JQpU/Rm9+7diy8ZbmkEwixYsKBnz55LlizR
ZMCBGZEGVDqQGfLy8mBZDrEkdh78FiiaOc9U17/HH3+84xoIs8LRMT8/34jBDut2tgso
9wMf+ABTlCD3EHdaFZIQCgMO8xkWZPxecwDnoTBVwnCMkevIU0PQ4Nt83HHHeQBRCZHl
iJeEsgySbMgLuAfXQIC0HPoiwh2cW0Cu4CrwTOsURsygGQ5Mw1PULYF4WUp4TcB1+hHG
xXWKDYbL+X3CSFvw9Bh/xpmLNQfgV4ynGWZUji5UtWaFZAMMkmnM4RDdp1kF+vfvP2bM
GF3Mmd0NBZB59J1169aNGzdu5MiRqo3pzZQGLhKQBGLHHG1E9KiuAV8xBHIkaBrABJgG
ooJ9p9GmneGIK0844QR8m41bSwyO0YlxZvZUd1SFwaiJ3oXe8bUmB0cYPQESpmPAaQM/
CR4XgeBrzSAby8Jx4sRcQLnOuwHJ6DJYKzEpRMrwODBs9RSxZSfscPZDqgrx6mk28DJ4
qkPdvDunxMLJ3OIWbBzf77BtmgMkFGAoiIhhiKgN9ig+AKt0hKDh8liMGAcc2qNydNUT
0SlZtoElaUXeCr1iaQ3Dhg2TVJCdnS1ZPYR/Z43Izc2VBLJmzZrBgwdv3LiR6CdjwEIp
XtyZ5EAwmerFQ2ARTE7jtTY+A+k5qNNQ/MayVrXAxoK1YjRIh0gAtOLwTC5QS0BpMKAl
8189ta3GsWP+SRY2ZCHzQAiK0VZrTUqEaeteMm6oy4gWBtvkFiNfAVyjy5AQvKab88Ar
6Bf1g5ADjIwBc0I8TI+qI9GIXoEPEL1rdH3ArNRCjeeJJ56on6QLYV65v8b/RJ86+eST
jdKDgZSHHjhwwKjyfkRUji5zsJ+D596h4zmgWq5cufKFF14Qk9m8efOOHTt0PVuowFIB
O7NlyxYxhwkTJuhiQw9BR7YD4HnF9NYFEC/pG2ib8Z+RgQF+hBVI99EUJSgbNEj7DyMb
o5gwP9FzTUpQGQrISSedBE4LIyA6gkAAulTNJjSWbG7keoKwAIylnUjvFuypgZxK7gjx
3XAhEQ6Kj441jAa1I4MGqHfASYGGh0kB8EyNgB4NI+IvlVNOOYXOmstZqefR9N2pBnkd
KiD/29bBjhXtQeSj1+qOofwYAfgbGhmPU9Fl7hfKCICZRsLhpdA2+F7kmXB0i96OZqBW
fNSKUHI4RDwHQCB1zeTJk9euXVvcUMQNUDb1FyyC3DoSMDIzM+fMmWNTlWYC6z7oCjoW
bzmhoZC7AcpiAoebKXbqYJFFzOYvFlA91BktbXNwpgYUdpbdUPwgXydmEGfC5V8wH+AG
jBXLHKShv9RmHeTn59NINR7kOu8ag1qm81SrxrDaOgEWBEIQqM7rX0iPQdazYFBGqFYN
htmH0yK0UxV/sUYbctN0DQ+BL6lavWJqMBYuE8DZkdBHNKpG+nWWEIRD0z6FPiLAkLQI
xYqWW0p029QGcosgYDBzovJuszkcVt4KXvTixYsnTpyoCYZ9z3HWjv3U3ADvd/z48VQI
XgpUb5lT1GQ0eCMYWFpg6fdereEWVbmEXq+A2A3Y1fW+DNNevI4QbJAcQp5AtiwdqwEE
SltbQeNAWqYSA0pDsKgSZM2gGRo3MMr8dGwRWOTCDBpkzWDQxA0QongQeVWQQ2gkJ1Ub
ahHU59R7sEdEAkkgHkBup0feCjd6HhIaneIa1nqeRfAdoj6DyVuwIRRJw4qMVQnsIQ45
Vy+sTBnbE1UFcU718F5gua3DzIzKkS2aiqH7dJMGyRbyVlCys7OHDRsG2C8KPjg8Ihay
PTIbpVwMGDBAFTrDneaJ5jn7C57YJKtijnnLVSd1JRsTkvy5gLWSCckyat0c070zWuok
VOkMFF7UDBbNgzigGSDMm+7416YSmzLcWsyP3GhmZdbnCY+0E2bKMNI+FzAacDnEJDqr
jiOEcCX8yo0BnN+qPX+5gwg5HNgK4bGlwfAipwsxJA5GWjfeuYZRK7y3DqOgzfBVlDL+
8vACr+GXC3MzBAfPOgYwLY8BZzkt4vaQtORgm4POSyrIzc21majJ1L3bt2/v2bOn6kF6
NCAGB6+//joTXtpHnz59Nm7cGCLFOZeuMQ8tnXo7jJwO6LDQeNgANsK83kGttuHbC0KX
YVm1AwPmAnfW+NI+Q2n8U3MerR+LpQV4d8G5bOw7wXkGELrjGBqB6dmWYksCr8M51+AY
uhijCpmIvdbrKaT6sl4gUQRH+vB2DE3ef/RQNNdfVDbGnFaF/YKT82+oVjBhkBlgZcb0
5hVwgFaF3ZVee7giwf4oKhSIsjt37pRaISaQJjZArVr9cYJq2VlCF4wbN+7xxx9HXNdd
IXgOGFwizI4dO44dO1byAyuXgRNJcuftPyaGfRVgYpAMZjfHnhsCzoYsR5s61bIfhJlL
4g1UaUZkMFtcGuAk1I9GDCO1vwTokfZ2YI1zHhzv6RtlhR5x0nwAmqKp4IHTGFw1GAfU
MRX2Lu2qZHcjY+LBKMzcbOx1ksHQBOTIGlBwvdfZXH9xoEIkCHttdwW7e9E2diox7+C0
Zi8pRCDSKPDGkWfMgvy6j4HEvsdASI5ozVuZaWYHNu/0Lw4qzaFw89IlPPTr1++xxx57
5ZVXQugt0LS2bdvWqVOn3r1779ixw/ubaf6cBsW1+wSbgJAYyw02B34inbKliG4r7dhr
NKZ4pF9zDJRZdA03npbwLHYeoWIeYQh9kkfY3GH8YYNF6+l2dYC5QWhwQrw1oFbXyZVO
SwE3hoKMO2fnB8Po0VmPlboMQiy7lu6m8SoZB7pjeEz2Ty38eEgb9xd254SztMRIehhM
qN+bnswufBXsv0F7gILHEOHcIkYNZYiMnxmVowgGgsi9YsWKAwcO2AjPN3oxzAGDpF1W
QpQAoztqgq1evbpHjx533XVX586d582bxyo2f/78vn373nbbbfpr5cqVvHc8kZiKmtt4
4zhChGP790IIXOzH2XfIxj2bInUsuYV9WCCpdeBAEh940fRPQ7/yTafCETOSLdQKZbGs
A3VLA7id+d84DS5kiL2OYj4AlxNNwcE0MlhQbZjVX8g/cACPDGTrNtvMAgcLUSghatoM
oLeeruFqob9k8VAHAeoPWRyagrtMDWy48GZ5KAzQDbbAyU/eTmhkcCrVqLwzfCCNoqEL
vVNJyKHkYGdmw8TpX6keLWsoCL26ftOmTcDTXXHFFRdeeOH5559/5ZVXtm/ffvTo0aoE
YRIBHgWTJRjh0/ovf3kVtjgdBg6gGsBJkEjRCOzVbOdhKsSzAoOhRWXL0qxWFstpgEHd
7fDjhH12V8bLmoTd3EvlbOA6OMIuYXYUtEc61GqtgTeC87B4Jo1k48Oe2E7UJbUL+mJI
GQTYQlqAAzVwpQNVoH213EEfTfZXT6Fm9CnHs3Al7aGbFoqsJaH6od+FocFhhAjQpkhE
3OtAmKi8Y7gfTRbRbE5OTojnYIMkvJ3UijagpUEEYIbymiutQfNHLCI7OzsrK2vhwoWL
Fy/WT5KJkAveKxTGB1AFPP1sM3SwuQ40fxBfERWIg7D7PSQT6jgIpbrLHgXEdzBFUe1x
zIYuHPRkU5vz7DiayT9plboJ1r1V+DAYCqKG7zlSADolwAEJxyzL4U5wPK50oIHz4DgB
n8HtNapeZMNANmqGvVCnRgOWi0xCe8gYgr9lc/3VyGNAYDBpm52gWHQYc71QxCRiZGB3
Rju3PcTpVBh51EOCO/y+HIcSlXce98PLiggff2YLDNYskBg1u7Zu3YoLEC86VC48dZ1P
B7XXC4eXJ6cl0jRA4HdYaJj0gduZbBbyJfcyZwjTYN7iq2ytnGMWUCid4A6qYqH0BhwE
4uSbaLtMWm5xBIezVRJ0QJN8GVYCn4T0rCKhAuAuwtOR3BjV0KRgjxFqCCMUbLigzQQs
pGXH8FjRNUdkYPqAKtEvnAeQLmMf8LZOk/1FQqAe2on7oj2v/BZCawP2B4MGOH1GGBds
S7K3SumvhiuS9o9KOL9tSkiwYg4QXZqfAzYHiF3MQWsBvCXMEGFNlqlo+1KoTTMhoUom
sOOAbCeHUXjbPaQRUxnKKfIqU5EpnXpz2hfTJpSIyYJrWASRMaA12mDyDJUv561wzgsO
UgfzZdimZwMa/MTXh2NOH20SIc7LeTfC7Dn0C4uEoypCMyD1sMtsXw6zWT8UvmRrhsV1
20xCeyn3NtdfcwP4EpID9fjF+XYPIP1ybAtcqzHIABKdd1VsnTjiOShBEXlvYIlUH9Yn
nDamFMT1bdu2ETpnmeG4447jIEQX1HIPBinolAYW4zgqUXn36tSxcn2SFbF4RYzvhhQq
b/q86fpG/7atT6yi8rA+omBvHKOzS1cVpYs5GMMkDenFu/YwFjEBEvLm5+cDZos7NEET
UYnKu7YUFebrU1Jw8LugMPgU83nT9QVt+yOirP8UlDb7HX4K3wiGgiGomK7RbREI02Di
8NKx5mtRPMxoHJWovOtLde2ulD67ag9+68w/Pi67g88bt7TtD71o8vvNn10HCxvoaciT
KMXhJiaQAvYetPGQXW9SEpNfmBiKqETl3V32NvNxebX+s+/1hoO9+w/sPsY/wSCoiJBN
1KJoW87tKpzmPo1TKztWjf2u0zIjHJP7vNF+9zExDomKWKqiorr+o4P6T2VF/cmGTzz2
xsdnYolYPNnkJ7zm3ft5o0flb/7EWvj4FaeB24epTBrHVtiHxy5toYOQHYeiDeKovJtx
UmOxmlhsV8OnJhavisVT9cSeiB/8QFUHf77BClJt9hN2La1TTX8ceZRG14YiIewxLW+F
3Yrs2+8tD+sjUYnKu7vUpKp2HfzUpKqrUtWVqepEqiZeVR1+EvWfqsqGT00b/1Q2+rRU
vI3u8AQTu0uTzMH3phrlvHjLfAdtpRwu/v+xWo7VcUim+CQaPrFkVUVlKvzE6j+ViYYP
49CcP0BVW/hUHuxLotFIVAXflc1RcZrPD99pzMF+DgZjtIoBY3FIb1p+vfeax2mY6R7U
NQOzt+y43gLOvzNaOsqg8dgeim98G0IPaNwRNFb8xvG1dmTN4RSNXnk8UVYRK0kky8UN
YvGSWEVJvedD4g2fh2S8KlFRFSurjJdXpxK7E7FUIpZsy5/4wc+bzlcmqtXZirJEZSKl
IUmJS5aVVyaSh+JT3TipjeMFDNPqkH+7SjoOArqwQ/4xMGlbmMxhGIKBa1zSwhMOt34I
wV6srvO9w3498ewg6nw6rZpXFQ2p3kUupWILFeWl1VWVNVXV9TyjnmpS8fJUMlZdldxT
Gd9VUZpqcCWKHRMfe0ZV6lvcQP3VQU1VLdyjtKSonpW0yLQ5SLNGNlYr7NXMzqaZgHEG
fJ6fx6xz6pu7yU+niPJ5Iyq0IoTWDthGxz3i7sRtBanMAa2UVuA87KrZXVZSnoxX1lbv
2rdnf8MamtInVakXpMlcq9clOcVZRfTYVFW87X6qUvok6z+VqYMfscOU5ITqVFV1w49E
vKy6KlFTndhVW1nf37d6C2m49KB4Od4hzYIBCeAYb+qwoxSc5FidsXTNPTVv3LVrF2fS
IllaEQhDDYRKGa/mvcYZQvgOQ/S0AudBFCFCgS3UaxDxqtrqPZXJmmSiOpGsTkoHr2ow
VdZqusdjibJ6c2Vb/rzZCGkrZRUuYRqCBvUqVl2TqKqWylrYHHMIQ7HMHHwQ2hnCcGnn
T/R+qOVAGyKO4S3OEFEtrfs2v3igLAwflr8BygjZ7mAX78H0cA7uBoMCqezwcR7KRQsl
pQV6Pw1oIanKVK3YQixeFU9UV9bsFoUUl5cVlhdXVFXEqitKEsVlifKyeKztft7s+VDp
T2lZHEeI+g2cmmRZrChZVZaqERWXN5e3Ik2twDeySYOkaSG0KhjuL9wttXXumCxp3fTg
hBhHoeWhdQZJOLDRXXzgYpeVtj6ezXWEKWQoTmOEHq7BIVlZHk+U6oWUVZRXxFKx5J6C
oqryilfLyl/LL9pTULy3NF5XXllXGNtbULGrtHJ/cexA/afitTb5XfFaafgpf92fotL9
sWRdSfneorLasvieorKqRPVescJYPNmczcHT2zuYIYBw6mAiNsMgGN4QbUKvb/78+aNH
j37iiSf++Mc/3nDDDddff/3vfve7q6666rpjtKhr6qC6qc6qy+q4uq9BMBQShkRD3h2u
GIy8QZT08uXLhw0b1r59+3vuuadxS65vKG19PJvrxd133/3www+PGDEiOzvbWurhp8lL
VsRLa3ZJ2a5NVu2tqa1LVNaNHZvTsfPEG2/q++ML/nrW2Td95eybz/7abV/+6s1f+uqN
Z//3rTpz1v93Q1v9Pvums8PPWb+v/7zx84Zvfeu2H/zwnquu7tq5y9SJk7bkF9alquoq
K/cdulqR5udgPIHQFgdWwOLFiwcNGqQ3qAmsN0j6iT179uCqve8YLQ4qAQmKnB0aBA2F
BsSQDsZYaIWurbvEFnr16qVqhw8fvnLlyqKior0Hy75jurib0qpWrFih7v/1r399+umn
NSCtM7xo8iYrq5LxfbF4XUbmpnv/OuyHP77r1tuH9H56xYSX44tX1C3KqVuUXbdsZV32
qrqFy+p0Jvws4bO8/nhhw0H9p+HksuVvnPdl/zheXn/xQn4uf+Obaxau+MdfvnhJUNXi
Nz/lTY1Z3sTFLXz+cb1am1O3YFHd5Cnx/oPW3HrbM//7g/se+Ouk6TOKE0nxhz1VlbVY
L+sJvKr+A2sNDZJhYGZjPwfgGZGZX3rppa5du44ZMwbAc4yTGNAI26w5/AIEig8cKYYZ
GXhnckADPMIZMmWDzuSwMhqjf0FqoirDugKCBLAtaKjUrNudFry5RrprVAIojQZBQ6EB
0bCgeTkWvgXbhTHkQzB2nZw+fXqnTp1UIfiNYZChmqcnEh3jYDrSD9FsULb8LmitKgEb
lp5SCcix3IKJdU9D8QAyXO6prqESG6L9gsQw/RTbD/Wt9+Ls5z5PVfSF+nko/zofmfG9
NQgaCg2IhoURsx7nDAWNbVw24JSWllcl91Xk1z0/bOnlV3W+6fZBw19YN3txcvay1Jyc
msyV1TNWpGZmp2Zn75q9fF/Gkl2zV9RmrqiZsax27uoD05YmZmUn5y+v0sWzVu2bml2r
yxboggXlc5fF52cns7KrM5bsWbS2bs7y+Ozs8syVqYycqoWrd2UsrpyWfWBa9qtzVuyd
u2LPzOzaWcuqs5Yn5qxITs3ePWNl3fSc12fmvJq5rEr1Z63ck7G4aubSqqzVe2dkV87I
rpq/au/c5dVzllbMzo5lLE3NXLFb9agSXTlvRU3m4sTcFWrtnozsXTNz9mcs3zt9ac2c
VfunLqmdtWrv9NWJqStjU5dXZuialXt1+4wliXkr1XLdWLl41Z45i5Jz5ifHvLj1lluf
vfTXTw4Zvrisoi5eUpssrqhNppLxRLHUr8pUvX0iUZZMxBLxinbt/rXh8xZ+Dii/kyZN
6t69+6xZs9LgoeyH2YoCEBAzh2e5TlJyg2MGQBnaDVhnQEUZ4J0pbTxnkJNTB5PLm2TY
FIAVOAzN0G1v2Yu0vRv4gAZEw6LBMZxjy34ObATDJYCAk4Qwc+bMDh06TJ06FeZmwEmj
uKc9GhIzehL0DkAc5n3Q5FDYIUnsnKBYOyeda4CQDSjNX1xJvywRiSPZDQNewbjBdQ1G
55xZhumDXfBGnCHdYPi8bp5Oq3SxBkTDosEhpSYgmYxeY+eHwCOi3pOhonT/qOErf31p
tz/8edywsTszl1S/mJE7aUHJxMXFE5aVjMzaOW1l5YtZBS8vib28pPylRYUTFxdNXFw6
aVnF2IX5k5YVTV1cOGVp2ZjF5S9mV07OrhyfVfjy0pLMnIrJC/JeXlwyaWlq1JzCcfPy
Xl5eMnZxwej5OycvK528rGLC8trn5yfGZJXrlgm6Nytv1uqKsfO2T1qeeH5++ZgFiXEL
Yi9nl704d9ukRcVTl8XGLyweu7Bg3KKCCUuKdKwKp2UXTFqyc8KS4qk5qbHzC8fOzZ26
tHRCVt7kRUVTl5ZNWlo+cUnFuMUV45fE9D06q3jSsuSLiwrGLN0+blXBuOWlz83Lf3Fh
0eTl5XrK2Pl5ExaVzFhZ/eKcvAnzCsfPKhiXUTxmUuz2e1+6+Lednnshp7xo757E7nhJ
hZiDOENxrD56KxYvTcTL4rFymMO/NO/nwHaz3kVOTs7AgQPHjx9P5mXbJ9MwnFtRDEcZ
4sWRSNcvHShFz2ejRzKdMOUxqXw9qwy4iNRDvhj9VVhYSJYue3OFuTibKyFOtY20wERr
WDQ4GiIueEvsPjQ1QztKeH7qqaemTZtmeGonqGJAwpwRzpRNZxkEo8wBMgnct4NoICUa
pmHEymfEWuphZMzxGBNnuTWsPQjeRvsMM2TZRYFmgywHuwAo2+Ys7/4YYxwxD7kLeF46
pQHRsGhwNES8euc98WCm7QWjpVUmd8+dt+26Pzx/0dXPdhm8eehLpcNeyn1+RsGIjIJR
c0uenVv0TFbJkNnlLyyuGj0zd+ycHS9m5Y6cvW3U7O2j5+Y9Ozfv+QVFQ6dve25e6YC5
pcOX7+o1reD5JTXDs8p119DZhcPnFY9aWvHM/NIRC2tGzK8emVUhHjJiYUn/mTsHzcp/
cfmu4fMrn1tU/dzC+MhFpcNmbh+9sHhkVsGY+SUvzCsbM694zIK8cUuKRswpGD6n8Nks
VVI2enHR2OwyVTt8XoluGTpnp74HZ2wft7hkTFbuGNo2J3dEZv33CwuKh2TuGL2obISq
WhxT5c/Pz38ma/vQOdtHLiwfmVU2bmlSlT+XVTA8K/+ZuUWDZxcMU2fnFg2dWzRkZlmP
8QVdR24/78qe19zef978rdXJV5N6UYlkqnZXZU21VLEGr4n6qf4v/3p8yBwa+zkYTlkq
9tChQzds2AB8XLinGfKKw+UM2KuXLl36+OOPX3311ffdd9+AAQOWLFnCog/uIjOcVE0q
BQUFTCp2+oxLr8nDZAakGtRZXU+qXE/4NWvWnHzyydLoSQpvMGq8l5trZ8gNwh1Mcmlp
WDQ4GiJwU1vYlzdHstOIuvPcc88NGjRo69atak+YnMubQfTUFn7dKGFbt8BFraEAlQ+y
93HHHYeyA+WyG6Ibf/7zn//ud79jBff+rP4dOXJkr169Onfu3L9//8zMzPXr1xsrWwUo
fo6dvYJ3x6vn24nAIGH9K9VgxowZ5EfT0jNv3jyLnV4FWB3sJGkOT952DYt6qiFSDXYp
eSNs4M1+OP/A5EzVFpVUd+r90td/3v3aR5d1HlXYb1Jp/wm5z2aUPDOn/KmJW0Ysig+a
WzZwbmX/jJKBk9d0HDzt4ls6fPu39/3oir9ec/+AR0YsGTqvuP+UbSPmV/TLqngys7j/
gppeM+O9Z5b0nVk4eH786VlF3aZv6TO3uEdmvMe0+IAZJU9P3dEnI3fYopi+B8wp6ptR
1Gtafs/p+QNmlwycVTh4Zt6AaVuGz94pYWPw1C19p27oP3N7/4ydz8wvf3pWyaB5RQ/0
e+k3d3W99O6+v/zTgN88MOR3T4zpm5n30DOLrnig//DZW/tPWfexb/z2Rzd2FE8YNnPr
oOkbh2cV9puxfcDMgoGz8gfN2KLPgMzcgbOKB2SWD8qs6DMlr9/03AGZOwfNyRdzG7gg
3md2SbcZO3vNzOs1o6DT+B0dxuTe0GHuuZc+8USP8YXFtXt3vVpTVR1PVFYk7S/RkAX1
X98Hc2jOz4GfCxcufPLJJyXjkYeCJGtAl3txD6PCDyPwPpF46KGHTjjhhCuvvFLC+YMP
Pvi9733v9ttvZzVxojrgcHmiEyXYf5tmwB/wE7DXsTgDazR6q2bOpk2b1E31CLKCakJK
bG7/1/uYjA9pMhgKDYsGR0OkalvGQ/Bep/1GRC9du3YVPYoKcJMgHR6EadR6ExQY+1/8
4hfVCzFV691OTMm9xx9//KhRo8iTC6cFW/jyyy+/9tprQadneEkwcfbZZ5911lnXXXfd
RRdd9F//9V96I5LnGW34mCUZuqwzy5Yte+WVV7z0qzZylIA2xkN/85vf6LXq37Vr16rB
GG95a0gg5l3uMs/yUGhYNDgaIjOWtAFMS/VYbwsqT2bMX3PpbV0+c0nnG/ttenBMXtfJ
BX2m5nebuLnbtNzumQWilC5TdvSeWdZz6s4Lf/9gu5M/9dVf3HXxnX1+ct1jp3/912f/
5q89p20ds7Cs94S1/WfnPzWzsOu0kp6z4r0z8ru9vKVfVuzJ6YXdMvL7LYh1n1Xac2bp
gNnl/acX959W2HPyzr5zirvP2NJp1PyHhs56el6885SifhkFfadtGzq3sNu4V4Zm7BiS
mfv03KKu07b3mV3U5eXtT2UU952x7Ve//2u70z75/y659ayf/P7sS/7w/Rse07+/evDZ
j3/3mmfmbO2Xsfn9X/vNN696ZODcggEZW/4+bHbHMcvVsA4TN/ebXTx0Xu7T0zb3nlHS
7eXyvjN39ZqafDqjovf0gkHzSvpk5nWbvLPL5NxemcX1DZu6+alpW/TXI2O2/b7Puq/+
ptelN3efMWddeWl1Ml55cJ6X1Yel1EenJNr9S73kcHwj5hAaJPWChgwZIu6dnZ29efNm
UjSGvkBeRluhWUycOFEP1frCS7ergB1oPfPhDG+8/YY8FxA7K2CYhxGVwYTM8mQpZdu2
bVpVRcXmCczVNOeuxjpFmgMYHIMZrmHR4GiINFDkjGghgsAhA3Rk+PDh/fr1U3u2b99O
hgt6ZxmbvtNanq5Bk/DziU984qabboJmdZeT3HHNSSedNG7cOCfNAXxeF19yySXiACgg
Tj+hG88999y77rrLyUR69Oih99K3b1/dKE6C2gVLdEpiVXXLLbeEQSXIdcj8sGWapwrV
OzVpwYIFxuXmxTlXCDzH1m8dk9VCN2pwNEQaKAQMD2AIPuANeh3kl6U6D3rpG7996EvX
DLx64La/TY4/ODGvy9TCzlPyOmaWdV+Q6jq7vMOU3P6zE7d1m9LupE9f33VYj1kF3aYX
9p++Q1pD79klos3e41YNm7bp6Yyt3abt6DM30Xd2hdbi/hnbtAp3zyh+anaZJIquMwt7
zCoSuT09JXfQtKIBGcXdpuf1nr3zU//zi2//3109ZhV3ml76dGbxgIz8HpM3SbDvN2WL
1vSn5pZ3nRPvklHSY26y65zKpzIKfn3rg+/76GeHT109cNqmPtM3956d23l6nphY3+kb
e09aPWDWjg+ce83//L77UzN29Jqy7nPn3/SVX9zTY9r2p+fHOr8sCWTbkNm5fTPLJMP0
mZ7qm1HZ4+WCvhkF4gydJ2/pNbOi98xk55eLO07O6zKtniV2nLj9gdE7L++99cvXPnfO
pY90GzQlNz/REInWoMM2cAZJEeWJVLt/keRw/AmBWtHYz0Gj3aVLl7Fjx+rNSvUrbigh
Qb0dD8kLLrjg29/+NgnanOoFiXHy5MkXX3zxJz/5yS9/+cuPPPII65fWEa1rmi3nnXfe
hz/8YckbmjzoPhkZGd/4xjc+8pGPfOhDH7rnnnsAVH/44Yf/vaH85S9/QbnYuHGjuila
Rkf2/LQZ/FA8JC1UMxoaFg2OhkgDxdRtOYbC+SA02zt16iRiX7RokcQAct94ITYncRYh
zJjq9Y033nj33XerXyy1GkBRpTr70Y9+VOMjYUx9VLUwTI2kBIPTTjvtsssu02jffPPN
zrPj0Ln//u///sMf/uCsxDq48MILdRKryJQpU/QWTj311J/85CfihDqjR5x44on/9m//
9tnPfnb06NH5+fniOV/4whf+4z/+44orrtixYwe8SE3t1q2bhig3NxfJgQF87LHHvvrV
r6pJv/zlL+HnqAxpwZhqpIZFg6O+aKCQWDyAtnPaIEPj88tr7+j04jlX9/76bS/+8NGl
Nz9f9LdpNZ1m1j4+PfX3mbsfzKh5eGqiz/w9fSaX/tvXrj79h9d2nb3t8ZmxTnN2dZte
3j2jvPOsWJep+dc9MOgL373qqvbD2n3mgp/f//xTk7be1WXkB770o3Ynf+1jP7z94Rc2
PDmzrGNG6Xl/Gnba1y5r99H/+cjXLr/rqcw+s8r/57oO7U79z3Yf+q92n7/4tx2n9JlR
1GnM2o//8NZ2p3+/3acuuKHTy53mVj08q+rRWTWPz9v7xMK6RzNiF9zU/l/POHvAjB29
Z5d3zCzvOCf51MLqi/426vT/uWbI7G29Z2w/4etXnHV15z5zSs+/pWu7U7/a7gPntPv8
Jf/XcbL4w00dXzjh8z9u96Fvffib1z41cVuPl7ZK4zj70j9976YOX7/6sW/c0LfrjOou
mbVdZ+3uOrf63hd3dMyoundi8vwuW/7r5snnXN7t/q5jKpL7q1M1lZpciVh1gw92qmpX
vLK23b+eWJ/fvnk/B33n5eXdf//9UnJFUKtXr16xYsX6hiIq0zzZ+vbKxz72sXvvvVcy
55YtW/QgnVm3bp2kdNU8adIkLRZr1qzp06fPKaecIglWi77IUO0Ux9CU05z/4Ac/qH91
cVZWlhYmrWXScFetWqWfap4EY03d2bNni2+IY0jyV/1qv8QkjnWNniv2sq2h6PgQm60n
6l7GQRVqWDQ4GiINlHrRwta8c/egL2i2i2tJbBa70yCokpycHCk+qlxP0YFapW8da0w2
bNigA/VOI6DBUaekO2iJp9niS+IM0s1Xrlwp7Ux/PfPMMzovytLIiFtqJEeOHPnpT3/6
V7/6laoV/dJrdV+Xfe1rX7vhhht4HOdViZQLdVB8T+Pfq1cvdfPHP/7xHXfcoe6rMd/9
7nd/+9vfMh/UeNH7sobygQ98QBKULlDN3/zmN3W9Gi+2oGFXm3VSb0c1z5kzRzdKWVBt
vHH1ms5yoKHQgKhmDY6GSAOFfIgZlr0qJxMxQ65P6Fa6+4r7hp91Rb9v/WnaBV1W/6zH
ut/033p571duHLr9yqF5Vz9TcNOz+XcO23Z/3xXtPnb+5y79y++HL7rh2Y23Pl/4+yGb
bn1m0y0jt/9x+Cvfv/qxdid99f3nXn1Zx0k39My6vdfMdu8/87JbHry33/RTzr3uS5c/
cdvgFfeM2vLNm5++ocPY+/tO+/R3f3fGd66/Z/Dyu/st+NjXLvr8D676ff95Nw/O/sv/
396Vh0V1ZPuLgDpZx0zeJCYxmWyjMRnNM0aS0Wwmk2TMYiYaNEpcoiAiCm6ARhQFAUF2
GhpZRDQgUSESml0UcWVzARdW2bvpvdnXvu93+5hKB5Us7y+Z1Fff/e6tW3Vu1alTp865
dU5VVMF9k78c97atQ1D6u4s9uXGzrGNKl+2vtd5fuyim6suYBtv9lRaW67mHX/rCJe5T
16P/csuwiry0PPrypEW7uaffdwrPcI4+ZT7Favw8L4fIcw5BaQ9PmfvkTJsVQZm24nOL
fNK5+1/+xM7bMSjlLxZfTpjl4BZ31ikyg3thJjd22t8ttywPK1wRXbk8smaB6NqSmErE
//gX/3t36XSv6gmrsy2+Dp/v4F9Zh4lH297aJnAGg5GDRtuuULdxpn8iyeFOdg5g4GD7
VlZWoEkMTFACOp3GMjoRHV39Y0D/3vjtAeIxiBCCK+5BkJgHiUtgJgJwpAMyqB0Vk0gk
+ASqAaUAAjzSUeTNN9/EHIpJc+PGjaA9UCDyUHFAw9yEWQzsAuRtYWGBiRWvaHCB2GoM
gT6NwG7uFJCZNZYGFKpK44KYA4gZsyc+PfTejEynwBVgIZmfOXMGEFAcoIgzoPLEKunc
MdwjBRVAS52dnSdNmoR7zKozZsyAJIBpFzXBLA/BgOqJQYQ2xsbGoqyLiwuQTD2F65w5
cxYsWABohFsARCIgTJw40dbWFpWnrsQNuA2AICcgPPLIIxjFwCRGKHgCfQVS35IlS1Ac
NcEVoAATNXnjjTdWrFhBJ56QtgJoaB2goSMAEAwE9AZGSiREEACTmkyUcNUQMCOgIJCD
nrW2tsZHGepIvDHWJkgEwvVarWaWdfDLVpGzdha+71M6J7JhQWzz0ugGmzjZsgTt0m/V
jsmdG+Nb3GIquD9Nn/K196qEopUHa9YkqW2+lX0dL12epFmZ2GyxNIh75F/LY8tWHW5c
E1/30jwP0/95cbNPhP2uxMlfunMvzHdOanSIv2G/96rrwSvuCYUzl27lHv3nugNXNn9X
+fhUq/Hv2a9LrFtzqHGRXyY36sXP14et9Dy4xiORM5+0Iuri6kPNqw822h+U2h1SrUuo
nv6FI/fQhNETZnMTv+KmrLQMKXBMqLZYEc6Ne3d73Gm3hIsm/1jwd0svl4Qr2/adHTd9
8XMfrP7m2wsuB8tfnOfJPTp9pfe3Nn6HJ36x0fzlz7cknN+wL3e0xZxHP7Kz31/geLDO
PlG+MlG7PEG1+IB0cbxs4b7mT8Lr3whoetfn+v8uDvlw8daqemGrB+EvQ4tMo5AL/twq
XYtSx5kIkoPpne0cENB3q1evzs3NBd2CetFfYPJEQuhNIombm/8bDrn4TWHcuHEgJIAC
GYNEif5xjytICJLthAkT3n77bVQsOzsbNIbpD/cgVFJtkAHjEXBApc888wwSMS5QN6oM
pAXI2NOmTQMQXDGsAAGUBvaCyYvO48CVmoD8dKjH7c9BMGoa7fZPvAI4AX8ATJJeIJnj
1S/6VrATbAEBRTC5o10QmTCyaOokYYaOGqGBgys4J4CDM0B6h2oAjo1GgSViYkWrIYNt
3bqVqof8kBYOHz4MOMiJ4QxcIR0QoKlB1CfewpoMPEyZMmXZsmX0x4OWJ9atW/fUU08B
FPJDJgEXgtaGwY5rvSF8+OGH6DvCIQLUHEh0yAZOgo9iNkdZsC/AATSQDWgsKyuLTukF
40LXQweMioqiutFcgCYzYQaoAFZBckAOUAREAV3GCpexLwBjDnh7vVb1ma3/v9bEf+5X
+mlIzfxYmVWcdM0R7arvVKuSO1ceaXdMbndKVGzbX8c9Y/nUf5y2pFWuT5E5fK9dm9q9
+oduO0m341HFO6siub996iRRrExqcUpRP/fZdu6hF8Y8a2E24WPu5UXcKyu2SJTrE2pn
70jnJs7nnv/I9NkZ3NNvbjhcvfG7mrFTF0/9j6tzknpdimbuziTu3hdHTvx01PhPHpj4
+b0vf/WJ5zH7JPnaI8oNR1vXJLdtTKz/eIUHN2bizvgLbodqvkmRrz3c6HSk6TVbsfmE
zzzii7Yllt4/w+75eT6uh6p2J1/785R5k+dudU8q35HS8Ni/nbkxFvdPms29NNv01QWm
U602fXfZXXKdm2o5/iv3zZK6jUdVDklt9oZWWx9WI359UG0Zq5gVqXrH89K7DrGWa3yu
VbcIW/LKWsAZ1PIWYaccpVam0HIm5sQc7mTngGkO9OPu7p6SkoJRgI4j0qUDboiWpD8G
WkP/TQGE9/jjj2NQsJOgabkBj5gKMfBpaKBuqADSMZtgaINTEW3PnDnTzs4OBTHwkQcU
SKo0yAw0g9lw3rx59HOAfnDRHIecGMjGFaalhyHqadw0AkUH/ZDADzKGQAXFfNu2bfj0
EEuZtM7C1AoAgfIOMYaE6nJDQCIdd0uB0ILvIh3jHRK+n58fFHAoTT4+Phi2kNtRJQxD
TP30G4S28Tly5AgeIQCASaKSdEQRNC/IWrRmSis4KIuvgM9QcTzSQScY6ZiskRP6wr33
3ouByf63oCZoyzvvvAMGRaux4EsPPfQQSU3vvfceqgQIqDlqhZkFlQd+iMPTL0d8HfWE
0AiSAw4JvbgSc0M1AIqwgYJADlAERCGRqRXGxxoaH+GK9BsNyrXbImY7Rn7uXzxvr3TZ
EbXNYRnGqVOqzjG1zSWnb3N6p1tGh292z5h31nFjX/sm5dLmTDXS16b1rEvrcslq35Eh
fWfxznsmfLwjvcE1W735aMs06xDuvheCUy+6pzdvy2nbmtm25QfF2n0XuHumzPVK2Z1R
bbl2N/fYNK+8ti2p0rGvWr3x5XYwh42Stg3xhdw94xd6J3unNvhnyLenyJ2zu53yeOcc
ITrl8K4Zrf9c5Gby5IwASb3HDy1u2W1bMrVu6aq3HWO5sTNDMmv9Mhq4SVYvLQn0TGv2
lVQ/8sbyF+a4uidXeWcppiwN4B56zTepzCO1fmeWekeaZnuqyiNDzk1dPnFJwNZ0pWtm
t0tqr5Ok30nSu/6HtrVHNQ6HNdbfqubtVXzqXzLbaZ+9m7iiTkH7yLVqdW0atcGaWnBs
F/45mJgNbeeAXoMYv2fPHpAHOotkbJrRyLjl9y1iUsB0ibnvgw8+AEzQBggGAuTevXtB
AJgKMdaQJzg4GHkOHTpE6wIknZJZHSQHSK0oiPnl/vvvB6sBQNQKugMAhoSEjBo1Cuo5
DWoQIaqNJtCCO1scYcf8MUl16AVN4l10YBCpPySxi8VizIP0j/1OzIEseYi2ycooPDwc
uMXgRcVI5qHZnLlkEnMgg0Po+FAKyJ6BugZD78knnwTeXF1dMZyhyKOZCxcuBAsljEHf
GTlyJFAKmIGBgcCSpaUlO/CaFlxQMcgDEAPwLbQIXQDEjh07lqQ4CPZjxowh7Q+PYGJU
NzATaBbIAyBQjl5//XVULC0tDfUBV6E1I/CcTZs2AT4xB2imaDIkAcBE3aBPmZubo6eM
nTQBnCGBSA7IAYqAKJRl3JUdGGq8CwRRbH2TPDgi8WMbry8Dihfvl684oliX3up4tGVL
Vpvr8b6tuX1uOd1u2V3ux/qhGnAPvzr6zQWbUm54n+7zyOu12V/xqU+OzzEZFAFu3Nt+
J5VuuSrPY22bv6vg/jL1n8vct0ka3HJa1ybW75DIvw7OQvEN8ee3Hir621sLub9Oc8+Q
+xzXvfy585hX5nsf73I/0el/oukeC8vRry1yPljqlS5zTZW7HOt2yO5yOc475+qdsvu9
TvW9tSqQe3SGf47KLV3jkd/jmtvudaLjrfVx3N8/C85p3JVR/6cZKydbh/rkqnZnN42f
63r/DNvAE+rtkibXI5Xcw9OnLfH2zpB5ZGq2JCm8s7o8M1vNX3OYvHyP9/Fu92MDbtm8
2zFE/TeZnc6S1vVJrfYH1V/F1C4JvzBrlb+HKKFBqsVsRgtSrTpNu1bgEmADnOlIzmTE
EPs50HSDOREKO6n5RDDMyMF4x9rft78HSHHy5Mn4NKTlxx57DHIphhh6WSQSYZaEvoyZ
7t13333uuedAVDTvgwPQBATJFiRKYxxjAWSJgfDggw8uWrSI6MTNzQ1AMGqQCPkW5IRW
AAIUAfa7m27Y4ba/uOcqW7mg+Y5wApkKUxuGBgbXEKySLc7SeAf9p6amArcYccAqqVc0
sdLfNvZdmtMx5HNycuggbDp5HMISmpOYmIhBBJkf9xj+CQkJYIDgijRwMFQ54b+z2dKl
S+fPnw/kkMcE/QAhRFlYWFAeoAsKGrBK0he5YEBiAW7vu+++p59+evz48WSnnZeXB60N
oguaUFhYiFf4NJgMcA5QGMsADpUQzIEURtAYuAEqn5SU9MADD0BiRI8jM6Hd+Gxu0qFo
jYPYEVCEr1CV2C8dY2tVYyZf3yA9lJxhabdzodcpmzi5baLCObNzU1a7a2635xneNbvb
9yzvfrzP6ywPbuBwoMhkymfcPRO5x2ZwT70/4hWrmVsO+J3VzNq0n5vwhdvJdo+CAfAN
/5O6FSFp3NNvcX9+hXtmFjfBUnSuIzBP/uDbS7m//IN74tW5rhHcX1+HnB96qn0zpIXn
3+eenGkVmhlwQuaVWvnn6QuhXHDPf8w98cG8sJOeBT3ehTyi1zne63TnDEcR9+yH/me6
Ai/wHud51/wuz1Mdr6/by700N+ysxj9POXKG7aQVobtOaoLP6tbsL+aenc098eFiUb5/
vmqRfyo3/iPuoencuI+4J+aITvaJT+tHW6yeahPpl9fre5L3zOM9TvE7TvFbcntdsro2
pvatS2q3i6te4PnD7JU74lNywUsFilWqZfIWhVwGzQL6hbCfg4mZwBxG3NHOAf2LHsFQ
2rlzZ1xcHJnpstU6Mke81TvpNwXyJMLnoDvTsjgz7CcDhr6+PlAU2AJzqqI/1ahJf38/
c54ir3/Mm4BArgdswyvIFVRPsuZlDh3Mvo68LcgRYGjHK3LxYHIsxizqA0o+cOCAl5cX
JkQ0YYglUWYyQcSMguB4wG18fDw6iFkM0hdpXYM8Edjx5bTsS5MmMANo5NRAzaEjkukt
eVqR2wWZItNsS95nBJw8UKgt7J48qsiHgnBOn0AXkCbC/LxoMYuIAYlAPmUm63eS7sjb
C6VwpUVnSqHMlIKv4HO0BsF8rwgVQAt4HVAENkhCFFGmsd2asRWrYPnWLCu5fGWDe9hs
x/2rompcUludM9vczwzsON2//WR/QDEfdJHfXcj7FvH+xfzuM+rQ8y0BOeVuiaejzzRG
FShFF9r9izqCCnv8Cvs9S3jvi5StPfS8Lvy83FtSJj7dHHJaLipoDS/pEhfpfLOuh+XX
igtUu09Iw85qdx+T7bnU7XtG5pZ5LaxEE1rYHnJWE1MoE5+64ZVeGVrYGnKp26ug3ae4
17ugN+gS73O+PahQi7jrbOfOc/34nG8pH3yZDyrpBY8KKe4IOK8TXezefVYXerlv9/mO
oAvdoZcGvsms9z2DUrrQAq24WLM97ar/SWlsKR9+vj/wZIe4SL87r02ElhbxfoX8riLe
/fzAttM9W/P7txzjXVLbHOOu/Ht10DoPcVFpdUOjTKVRy5QqpVqlVIAzyLRK4ZgfboQp
+IKxAfUgOwdGVxKJBHrluXPnqO9ACd23hN/hq0uESu54II8+QwAojHqk00FdSCfzfjzy
PE9kiRuiw17D4V54ixQ86vV6onPc0JlnAwMD9C2kIA9ahxsk4hV5mlMp8sj+NW7FLNAY
wQ2EH8yAEBswUozF3V+zOxxwC8Fsx44dAEJYJfQSWsj1kh1eRs1HbZGCKzlO4hXQRVVC
HhporF14xFvCD1rNsE2oxg3yMFTThwgCK0hoRHFyiaX8BJ9AUd3Y55CTuAr1I16hp/CK
oOGGMgvH0fX3E9qRSNyDHhEILG4gbAA5QBEQxXReY5NpNk8x1zkQebNStj8lc4lzhLVv
1jcSqWt+p3cJv+sCH3yV9y0eCLg8EH6dDy3tF18diKriQ8u6IisGwkp0sZfbRAXKyHJ9
QGlvaBkvruD9yviwSj74Ih9Txftd4kPK9NFXesUl2pgKvehKD8ZpRJk+4kJf7FVedFkf
cY0PudAGUMFX+PAqAb6obCDksj78Sn9osWJfRVfo5Z6gMn1oOe97pV9Uwwdc5QMu9u6p
4EVXugEtspIXlfNeJb1IBwTRVX3YFX34tQHRlT7xdX1oWW/olYGwct7vct+uku491Xyk
ULGOvbheUEfVdgVcUQeVdgZe6N1Tzgdf6heX88gffE34iv9VvW9pz65LPbsu9m8/1eeU
3LzMP2Px5vCDafl1jS1KlUbbqlO3tmna2g1qhapDK2y4yZmaGZjDHe0c2D7A4PPQWz08
PDDT8UZBbxT43xtABrcm0lgwBgtaAnkbpwy6RwbjssjMUgbdUx4qTpl/MdyppZAWvL29
Y2Jirl+//osbHjIthrlD0s+Q6OhoX1/f8+fPM+CsVqzaxO7YK4Y0ag4VZM1kbTROpOKD
UDeo+ZST3hpjzLjsrZgxzmwMkBWkvjP+BPsQ67hB3YHHgoICoAXIIdtytq8O07mYJxrd
EHPAPNjY0lRaVRcQ84OVU7hDdF5gkS7oUofoan/YtYHoGozBflFFz57KnoiKbvGNgZCq
/tBqfXjVwN6qvrgbwitxHS+u5oPK+T21fEh5X2QVL67k/cv5sBt8dDW/p7w7vLxHfIOP
qOajhEcerCaihg+r4iNr+kQVXaI6PgjMAcVrBDjiKn5fvT6kTAtooTV8IBhRPR9YxQdV
UgZ9yPWuPXV88PV+MCJ8WiSA0oejoOEGGUQVfYCPlBDUpJ4X1/KB5f2h5b37m/jgsvao
+v7ASnVEc29gRVdUEx9wXah/aPUAYkiVcA2rFmoVXtElvtbrdVK94duSLzYE+cUeLats
amhsFsRIlRKcAZqFTqtu0yjbNGqNWik4XglqhYnxUiYzXaYfRGS+S8oFFElPT8+UlBT0
AqPJQZ0+vIPxmAIdYkYDQoAW8ExaWWAuY0P8czBegCPlGjJzREQEeW2DyAmZ/x9+ezci
lgIxbSABkhi0CbFYXFJSQr9ibovA26JZ2iSXSnWnCyu9w79bvi10nThZlF8ZX9Uei1jb
s69RH9vMxzTro6T6SKk+SsbvadZHNumjmwYQI5sHDI9I5JH4Y+T3GFKiDdmQh6VHNyIb
Rb2QLhSnsj+l34TcpDe80huiEfxmBvDmW6Pv/iwalf2pICDHSHsR0ZwowJT+FFHbmLo+
NDm+tju+ojU0v9oxKnPepuCgfd+fKS5tar5p/y/Y5SpvolQ47kIpKL+G9UshjjAEMzMz
WjUjf0PmCEOJuEc3QX6ACA0yhiZYWlpKMjyjZP3wDeCBtB8UmlxWVnbw4EGQLlABmQFo
Ya7QzGFqiONCjI8Eoh+bZCYUFxfn6uq6ffv2I0eOQA5BnoE7hOGHWwokoyYnJwOxLi4u
kBnoNw7zrBmEwNsjWaHWKnSKZlVjg6LwckX4gSM2m3cu3eazKfqQKK8kpqQqsUp1tLnz
e1nP4aZOxCPNXUmyTsRk6V15Rfxe1vW9rCO5pStJiD2H5ULETYqy9/ANbXxZo/j4RWdx
wqLN3g6eYaJvU/LPFdXX1zNvHeabTNb7NOrBG0xNTUlswA34A3CLkU6/idi+Z/RfizBf
WVl54sQJjAgfH58NGzbY2dnZ2Nh8bQjLli37epiGpUuXonXWhrBy5UonJyeIu5GRkceP
HwdC2CYMbGOTIXwrjG0emAML+VCTJdX+/fshjaxfv97e3n644nMQqSz7MaxatWrt2rWY
eg4cOHDmzJnq6mrmkcq24rktMn+GZK26p13XrlGoWpqbmhrKq6tOnCuISji0xTfQdpPb
0g3ffGm/fq6N41zr1V/YrJlnLURLa/u51vZ369XGbo6N3ecr7D6ztZu90m62rf0nK+0/
thOuHy23nb18hdUax7Vbtnrs9o+K3XfixEnCKvuvTouY9JebfgiTi9PIkSNJm8CNmeBj
wRF5k3BGP5aJRbNDRmh5vaamBlpGXl4eeS5AGIauIZFIUodpoKZB0EVjs7Oz0XBIC2TE
yKYzQhGtAgxxNuWg44mJntlBeM3NzQBbXFyMT+BDqf8dQWIIQG9ubm5+fj45mECaIhnM
+DDHQQi8PZJB6fKGNq0UxA45Tq5obmiqL7t+7VxRce7J/LSs7O+PSpKTj6amSDLS0rPS
0jNSJWl3eQQOf5CkIB6VpH6flpqUfjOmZGRkHss5djwn70TOhaKzjdXXVI03WupqNGol
2+SNnUFDYgC55XZ1dYEbjB49mv1wMDc3J/qkZUEiV7ZmxDY3gwKIjiOrY7ICIvclMioe
loHM/kGxaCa1nczAyIqbeXeyHcyGdlQfdAYcpVC/APmAT86ewxifFG51zAGSyXSTDGVp
VcJ4E55bUXfbvXl0whGRjTJFo1wpVWnkMlVLg6yxrqmxtr6uvrHBYL9We6OmoqryKmJN
tWB+VlV94y6NghtL1c1YU3UDsVpIFF5VVApXg5cD2l0nbahVtzR36NQqpdx4XLMdwEi5
IFGNrWCSTkF2DuyfJOl6VJCd3UAzI9vmy3gfEtpbaVgG5tpMShk7T4FMJoxtLEkM+JXH
yBq7DpFhNnFj6ibaN2MYh0FnWBACiTPQXl7Gm3jcirQhQrOsSaVRanTCfzaZvEWJcaAR
7qUAKW+RoQNbmqUtjS3KJqVGptYJ1j9ShbIFrOQuvArWiLIWlbRFeDZEuUwhMESZSq1q
xRVtpvNXFYoWqbQJkW1kanxaCjN9pERzQyCFAje4kiZCzvhkRcO2YaF9w4x3l2UyHhPz
hv1ZmcZ2koz30raotB3Kb7JzMD6akGyBSDcxNgn+LwmEVTJvow2EjY8l/a3d1dHWrVXo
NHJtu6azQ9ulVbSq5DqdukOn7VRr2hQaLRRsbWe7qlMnbVU2KKXqVuF4PJ3hXKi77iqc
/qnVGUVDohaN7dCokadDo21vUanlao26vVXXJewVqdb+TMllfx5ojFNfMMmB+AOJEIxR
sF2pmVyBR3plfOAFe0Vlh2swuV0gXDErkV+JgVvhGOOT/SIe3mEQGgcdy4gblk73t2L+
zmGEGWduypmbcSPNuVEjuVFmwj0Id9QIbqQJN1LwNxRW8AULHw49Zj6CG3b4NhFMG0cY
kGd202IB0dREaO+Pu0obE9sgbA866+qP8EcYdgNEiBgNZgK7+CmaCvHm2+HTzh/bw1rN
oolxzpuHUfwR/gj/3XyBhGFDHHlLNDPEn7iEyd0cacgb7inBzCj+jBP+dp74f0Y5easK
ZW5kc3RyZWFtCmVuZG9iagoxMjQgMCBvYmoKNTg5OTYKZW5kb2JqCjEyMSAwIG9iago8
PCAvTGVuZ3RoIDEyMiAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X
aWR0aCAyNTYgL0hlaWdodAoxIC9Db2xvclNwYWNlIDUgMCBSIC9TTWFzayAxMjUgMCBS
IC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFt
CnjabcJ7MNMBAADg/uuuu67rurq6urrqyps88wh5JHmEIhyicCRROJIkiqIokkj89n7Y
xryGYZ7zGPOe2WZjbPPaZjaPeZR+uCvd9d13QAU4qAIcUgUOqwFH1ICj6sAxDeC4JnBC
C3JSC3JKG3JaB3LmCuSsLuScHuS8HvSCPvSiAfSSIfSyEVTlKlTVGKZuAtMwhWmawbTN
4DrX4FfM4boWcH1LuMF1hKEVwsgaYWyDMLFFmt5Amtkhze1RFrdQlg4oK0eUtRPaxhlt
extt54K56Yqxd8M43ME6umOdPLDO90pcPEtcvXBu3ri7Pjh3X7yHH97zPsHLn+AdQPB5
WOobWOoXVOYfXBYQQnwQSgx8RAwKKw8OLw95UhEaUREWWfn4WWV4VFVEdFVkTPXT2Oqo
OFL0c1JMfE1sQk3cy9r4xLoXSXUJr8mJyeRXKfVJb+uTUxtS0hrevG9MTaekZVDefWhK
z2zKyGr++KklM7slK6f185fW7Ny2nLz23G/tX/OpeQXU/MKOgh+d34s6C4u7iiBdxdBu
AEaDwmkwZA8c1YtA96IwdHQJHYPrw+L7cYR+fOkAgThYWj5IrBgqrxyqqBqurB6pIo2Q
ahk1daO15NG6eia5gVnfONZAYVGaWE3N7OYWdksbp7Wd00Ydb+/gUju5HV28zm5eF22i
u2eC1jvZQ+f39vHpfVN9/VP9A9MDg9ODQ4KhYcHwiHCEIWSMihhM0Shzhjk2M8aaZbFn
2Zw5Dnh8fpw7z+Ut8CZ2TkyKJ/liPl/Cn5JMTUunBVIBWLgoFC6KRDLRjGwGPLs0O7c0
B56Xz4MX5AsLCrFYIZYoJJJliXRZCl5cWdwtk62Cl5Z2y9fkYMWaYqdSsaxcBq8oV1bW
d66ur+5d21jbq9xQ7twEr6//vbEB3tq7ubn/z62tf+7z68//2t7e/g0SGRtxCmVuZHN0
cmVhbQplbmRvYmoKMTIyIDAgb2JqCjcwNwplbmRvYmoKMTI1IDAgb2JqCjw8IC9MZW5n
dGggMTI2IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI1
NiAvSGVpZ2h0CjEgL0NvbG9yU3BhY2UgL0RldmljZUdyYXkgL0JpdHNQZXJDb21wb25l
bnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNr7/39kAwAIAP8BCmVu
ZHN0cmVhbQplbmRvYmoKMTI2IDAgb2JqCjEyCmVuZG9iagoxMjggMCBvYmoKPDwgL0xl
bmd0aCAxMzAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42s1cy24c
Nxbd8ytqE8AGogov31xOMhNgFkEyGA9m401bKtmd0SvdbSf++zm3uqvIJosFx1Yk+wFJ
9hF5eXif5KV+6/7V/dZphz+9xC/rO69kZ43sdkP33+6u++6HPXWX+47G3/tLBlt/RLsR
fHFEi+tPHkt2sieroiEK+NQpzV9oHv03fK10HH8JOSKnL3loeRw5dpe33fevOjsi+ANZ
KTtlqXt12333I/X4l+7VdfeC7Mvu1a/iH68g3LJ4OvY8upmF/GXYXQ4Ph/ebm263xbdY
p3sJGQLPJS5ML/1RHhN6T+O3mmD7EKQ0LNd3/7wl3/39vjnjiRCxQK7xvVWY0fRmHE72
ZpzMmu7i+HmQxvO312yLL2O7O2db1GzTiW7+GCCRIhWOfKuZ7+83H4f9dnPX/bi9OQy7
7d3bl+LVr90K/4sC4/eCeGJVGbwdvw8fyOJv8Cdl0LNwr5UZ1QHiiEcQZ52tJA5mzcRJ
XP202d4d8HffHX6/7642h82bzX7YPxlhzo/fhw8qqI68VxVhWsknIyyJo63OxEmE/TzK
knBGmh6KGIOY0C/uSoixvcV/mnnAF0MJCap3Vrs4QgRDugJiJfXkrXNplN9LiGUvIV02
0XbcyQziqbdWOUqQQzlK1L2Heab1v3h3gogTxGk4B2DSjlXiOqvg0+CbEmSfQQRDItj3
Gp/NkPfFKF7L3kebDfKmRPCCKFBM/F+UEF4QBUvLovCHMM5jokr8l7SEcUE238VdCfGh
jzpK3eY/RN8bJ2M2SqkuUYeeglbZKG8L/iNPJLGP7RWRJNvHkPPfFfyTxDZahJUEua5G
sa730mQT3VcQXpJyVjR3kYiXZEJoL5oIS4J/orQBVyVEUeyhnKatdKR4IrIrBkAKK3La
qxVZFFakbbT1RNMGkCaOtqRXNkCzwlifLfqh3AANzXQIqAmyKUcxrJnWZbLcVhC2I62V
aPNiZYDZ5/pSjWKd74OmzAOVToocfF2Uwaws2hmC1pkzqy82AAvupcupqxbtyfWkc+pK
C2BP2AfX9qjEVh91Ttz+FEaOUU08VhjBKGI9qjnvVqLaQpAVXyZOHtVEHdVmcT4hqs1o
WIloRbUJshLVJkhpSFlUmyArUW2CbAtDyqLaBFmJahPkXRmypqgmKnEXotoEKU0gi2qA
iPWoNg3SjGoJclHwn0W1lihZVCtpEXVUmyArUa3FfxbVkro0o9oEeVtCpqgmmivKolpr
i7KoNvG/EtWmUZpRLUHel44sRbXWorOoNkGuSkeWolpzRSmqtTYgi2pNWVJUa040RTXR
HkXzRFK7Feo0T6RstgF3dVQLvTSZb6ySNoI+9coEk6u3KAPfOFFCPFRBbZwnp2VT8m+9
7cGwT5AqNI6OgUvhReZG/kfHoHIzuq2DmupRqlPbX5I3sVfwhisG4IPDLqoVq6egNFQ3
2MR/FWADyLXStm2RIhyzUjlzQ0k/m7SWOXP7dkgrIqz4gpBWRVhBNsg/F2EbAV98sThj
hIU4ooiw/y4I1qPLtL6bZK+ihBk9po9uXl4VJgx7TJJch02Qi6WyEQ4vSVUpjD1OJCmN
UkVP6IsOXusE2ZWVJSumJlaqCbItQ+OYVWiZjXJXVpZjVoFQniClajpMBF9ms4nKytLD
ArQ3MuOl9HUeiWqIri2sx5INskgvKmHnyMjcYpZslMsqBIdekXM+0X9TFZYIRjo421aF
U3zlUDNBrgr6T/GVMoUaqvhqe7hlTqRKVubCkpOKgFqgPQriq8QuZqJ8OEcIkiglENHW
BoGe9JIoV6eqZpQon0xG/8cK4uDdNa3sMsHTITPUKtF/qOIiaiNvtV2RVkErQ6a1f1RF
JTLdKPMtrKbRWDGYCfUup6KSp1ExY6Vy3HqcKNf9mzIUGWilUd6usGKQcyAvXFuysb6H
ZovFeY4IqBP2J64MYhHynDImsV+Xnch045kmLJSd8HI+X9BdVVMicDo+Hm/z78aJcidX
FfWcuhulMkiV23jNJm8yE7ou+Ycu9doYv8I/p/dhcgrLGx140UaTaI8S1BhCMnErdgPU
H54upA2o2I3wlYGCWvamRwhcYYgm5JAyF4CHQl2k2itSUlvOxRY8u5ghUClfebCnCOA2
HG9xAgIzcWZpxGPkE8eJxReIY5waxZkrdnEU54dRloSziK2kHCepJ/RJeTOIjnB0IQGO
ZpQBQL8Okf3CBDmUY0SEcNh1TJDhBBEniINaKuvl2UTnozinUGfEXNh8IsEQODqNOkEn
SFeOEkOPTFi69pI9MncUARIp4gS5LiEwV+sROdsTeQfigpV6VozT2UGCBHh3AweywMsM
0Z7jZsggm2IDkIQho5Y+o+6qGAXOH7FVedPegDEv98Zl1O3KURz1MDaTjbIvNoBTAUt+
bQNIShCjTL6gEmFQ9DgnmqpA0vvex5UVE1IBuOUTtWJREBS3KH+PNaHJUuUc4pD9uOBz
ZTlnH5mA5BDhVmRRsHikE9koH5/scqr0USSf9VSx9FGTOKnm+aXyUcwvB/IT+FREZAgE
I4R7FRKk8mIWNTKSbp0gh8IAYM69c9bq9iiODBcRfFA9QS5LD2Q4L4cxrYzCTsoTH95M
kJslJ+WDZBMguexeIIsPYyY1QUrf4Q18qnLuKItYmsg7WInW2q6MEpFf+vGwb4Lclh4I
E3mjjG6PEoJEpXH0zCTPjHr2QHyORC7fxjKQRGQDypBNmlN7IJQRLmjjE+TbcpSA5AXp
Y7aiBScFxY0uiuaKUNIoWHXIxO1rR4YqwXBhNG3A2woSDLTBu5VRIExvg1H5ikTp7aB2
mX0vODs9HkJntGwK/kdnZ3TMILUnkxwCqAERk7Pz41lfstdyFFijkca01QWuGckuopFY
3OgRohWsMQTdrUDGKlmqxH/Fi/aKb3wyMyqjNGojWKPLN3oo+TcGvCAq1ewmiIepjWcU
JXXzBlhERuiDX+HFYiIM0mB33ABuwlHHWN/iBfU8fF3UbRshhyos+BUHBEtladfMFRUW
mJMnHyUWdYErLBTTa8xBm3pnpcu9bsG/53gV1RpzHnW/1cbWNjLzD3/KhY9a0YWgkGx5
rZYnGvnn2xHOdldWFAIfqqwZWsQ8yPpW3E/kilHLuGJnkdvdNGXup9QEJC+hh2a6tiYo
CTtzQeqcOFFADEvr27yhSEMKRLGOihP5ivik2xK11VbBzPjWo6lwQkHjYIdBtx2hQpEM
88i3p8wuUcwjEtnc+W8qCDRbxdwn3JYQ5OScxSbyhwoBn+xkHsI/4SxcfHkiNnV5idR0
pqVbaTr764/mz5rORBIn5YU/3N8+bHbDvtvc3HT7928u9gfu0tt399fdBlJcDtsPw1V3
O+z3m7dDd7jv3twf3j1Dd1rRzgcr/Jra+WZxErN/2++3b+/23f5hc4vx7zHv6xfyG6YQ
qcc3r18+F3USZe9XRN0sTt4J+bF7M3SlmYjH6hGZJRKlRBbjLkl0dIkZzlhkbJJPKo5o
8WK3OcBQPvNY6s/3OidZxsppQebNSWYx4SJnU5YT9BP6xUk7t9cnBR3+uByGKzgDqOr7
/bC7uBqut3fD1euX3eEdvMS7+5urZ1LbGL6m/t1ZmoVW5+up1bl72N1/GO66zeXle9YO
5hn/9DDsbj52z0FjQFBckPy1VuoZeKSIimdBnNLWKBqU9jKSOIFhaqyUX2Jq4jOjKLlS
ZHFiUD+Z5Z93tIXQbNMWj6Nef6ZNe5Ymbed/qn628dpGGnECV5ccfNuulLTz4upuNr4+
Rcid/r+6AOeOCcPHWxOiauGm2Hun0hDpzlnMN/EKtXJClFfOlpsnpYtuRpRtso4nUVFZ
Uc8y9blhFksqLbW8tXZ8EaC8MyeEqG5zuJkFdCLHn8Y4VE1uqDWkMfqcUHHe5IZqJKYx
qga28WqWa7QlSsfOM75s8FF3rcUGvlOVlJFedoMFvkVGjNKitW98i2aVts1diSyFwd7M
fJUXh3yWFbFY1RyDuH5z3GY3IS4Kvo4371G6Jl/Hm/dMfaqOY+JJQsZXdfFIIMw7G2fE
bX1hzhd5yjX5gmrp3jrjVsYIqKwN6aaCkeY7avK5vZUI3lpHaZb/lYSNt+U6NE2aDGpz
iRUvWpOY2tDGbs7mYg1MUtng25Ra4tYYS03nQ9zjCmNy7VnGe3Kt3UxY3XrNR060uPXz
HbnnBsxSznT/DT0PMltJ3cNm4NFRT8+Ib8veDzgNLoRNeyU+6J5UTIj7pQa2YMmL5tYH
Xgu/SGvOwlatyZs2X3yTpqOObcYiVotNoXPGcgXj82eKqq3oii/AjIum6cGUhIbFSKqp
P0pGeCjusWvpjyJtOb41LVLBvfXOuab3UVhsr8Mc22sPBpu23Elm2mMoz20yyjY9mFK8
Ep0542olmmfJY0LpwpQeZyHb5ssQN8n4Uo+f4lLsvH7w/jOPYh79ZIjrB1/3/f90vz90
w/X1cHnYfhi639+hcngGrqIPS9JlNcKTnqJJOOIFcaoaQfJjF/ipCTzWCPzc9Kny4EwW
ZHwNCvVzKL/WckmcrqQQUZEPX/VM4XbfXd3fQRW3h3coYscn0KeDwOc69+Nr16/nFGCW
Jjv1u9o8HPZ8yLe9u9p+2F4xafv3b/aXu+2bYfcsvBkZlkSFPj4HcfyMbkmcSh8N9BFZ
YxAn8IuH3XA97Ia7y2H/LRi+GXab4+fD4bL/pPJbPIJzysJf4Lf58cu73cVjNN9z+c23
K5/luB+pVy6TJrjETWqV+7nRWB8ncP1i+9RXb2dE+fjBju+QnEtjVMX++AwpjM3z8Sw3
FPmTNP4hBhNgUxXqkgucEApBn+J4Oj8MUGes1pbc2GPxOJEF0oj8eR0tSVPmkV7xHivr
qv0R8wOA8Q3YUYEXc1EuVHxANjAjigpBBDU+NdPNHcTu9dZzr0apBOnogLvpHWJxS5FQ
ovT6TE/KM45oPfet2UnQutiJyO6j5zaB1ixYJkrQGOL5Ws6OH6zktxmmaTact/MRWVrt
fXX+oLFnsz7VXdpkueNBJjnfVQheCp8+JNOsnsthDkoLqapHxXxxd9JEV32A4V1vuH2j
tW3EdYp3ZNt0cTtK0D62jfcJHDQZMg0PbZ/BQ48NvQsuel8fqvAPjAmmra8m8EmWTIjq
faZV3JukfNPAyTrHP9CGulKX0pGI1PxwPm1z9ZbUKSiCtTGTozgSceMsIc1SPaVwwTJj
1F4tN85YpUi0fAB5BTqNobZ1eqegss7Man9dH83Atpxbtt/T0Yzl88Nz28q1PiCBclqt
WA4CK7xVXA574njuAvvkJ0ZNNxFZPYJTTZdIEerhZUiEVecZktVDS/Op9vmXhDMlvWxE
17xu+z/Fd8SSCmVuZHN0cmVhbQplbmRvYmoKMTMwIDAgb2JqCjM5OTQKZW5kb2JqCjEy
NyAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDExNCAwIFIgL1Jlc291cmNlcyAx
MjkgMCBSIC9Db250ZW50cyAxMjggMCBSCi9NZWRpYUJveCBbMCAwIDc5MiA2MTJdID4+
CmVuZG9iagoxMjkgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUIg
L0ltYWdlQyAvSW1hZ2VJIF0gL0NvbG9yU3BhY2UgPDwgL0NzMQo1IDAgUiA+PiAvRm9u
dCA8PCAvRjMuMCAyMSAwIFIgL0YxLjAgNiAwIFIgL0YyLjAgOSAwIFIgPj4gL1hPYmpl
Y3QKPDwgL0ltMTcgMTMxIDAgUiA+PiA+PgplbmRvYmoKMTMxIDAgb2JqCjw8IC9MZW5n
dGggMTMyIDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI1
NiAvSGVpZ2h0CjEgL0NvbG9yU3BhY2UgNSAwIFIgL1NNYXNrIDEzMyAwIFIgL0JpdHNQ
ZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNptwnsw
0wEAAOD+6667ruu6urq6uurKmzzzCHkkeYQiHKJwJFE4kiSKoiiSSPz2ftjGvIZhnvMY
857ZZmNs89pmNo95lH64K9313XdABTioAhxSBQ6rAUfUgKPqwDEN4LgmcEILclILckob
cloHcuYK5Kwu5Jwe5Lwe9II+9KIB9JIh9LIRVOUqVNUYpm4C0zCFaZrBtM3gOtfgV8zh
uhZwfUu4wXWEoRXCyBphbIMwsUWa3kCa2SHN7VEWt1CWDigrR5S1E9rGGW17G23ngrnp
irF3wzjcwTq6Y508sM73Slw8S1y9cG7euLs+OHdfvIcf3vM+wcuf4B1A8HlY6htY6hdU
5h9cFhBCfBBKDHxEDAorDw4vD3lSERpRERZZ+fhZZXhUVUR0VWRM9dPY6qg4UvRzUkx8
TWxCTdzL2vjEuhdJdQmvyYnJ5Fcp9Ulv65NTG1LSGt68b0xNp6RlUN59aErPbMrIav74
qSUzuyUrp/Xzl9bs3LacvPbcb+1f86l5BdT8wo6CH53fizoLi7uKIF3F0G4ARoPCaTBk
DxzVi0D3ojB0dAkdg+vD4vtxhH586QCBOFhaPkisGCqvHKqoGq6sHqkijZBqGTV1o7Xk
0bp6JrmBWd841kBhUZpYTc3s5hZ2SxuntZ3TRh1v7+BSO7kdXbzObl4XbaK7Z4LWO9lD
5/f28el9U339U/0D0wOD04NDgqFhwfCIcIQhZIyKGEzRKHOGOTYzxpplsWfZnDkOeHx+
nDvP5S3wJnZOTIon+WI+X8KfkkxNS6cFUgFYuCgULopEMtGMbAY8uzQ7tzQHnpfPgxfk
CwsKsVghligkkmWJdFkKXlxZ3C2TrYKXlnbL1+RgxZpip1KxrFwGryhXVtZ3rq6v7l3b
WNur3FDu3ASvr/+9sQHe2ru5uf/Pra1/7vPrz//a3t7+DRIZG3EKZW5kc3RyZWFtCmVu
ZG9iagoxMzIgMCBvYmoKNzA3CmVuZG9iagoxMzMgMCBvYmoKPDwgL0xlbmd0aCAxMzQg
MCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjU2IC9IZWln
aHQKMSAvQ29sb3JTcGFjZSAvRGV2aWNlR3JheSAvQml0c1BlckNvbXBvbmVudCA4IC9G
aWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42vv/f2QDAAgA/wEKZW5kc3RyZWFt
CmVuZG9iagoxMzQgMCBvYmoKMTIKZW5kb2JqCjEzNiAwIG9iago8PCAvTGVuZ3RoIDEz
OCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjaxVzLkly3kd3jK+6S
ihCv8Ei8tvbMRMzG4ZlhhDfeNJvVYttsNtVVTYX+fk6i+l6gkECZlBi05AiKdBJIHOTj
ZCJv/7L8z/LL4gL+t2r84+MSrV486eXpsPxt+bj89OejWW6Piyn/Hm9Z2MezdCjCr8/S
6u6L19KLXo23mYxJ+M9gHf/G8eq/4PfW5fKP0kVy+y0vrc8r5+X2YfnTm8UXCf7FeK0X
683y5mH56b/Mij9Z3twtr0z4YXnzD/Wfb6DcWD2XV16ddiX/eni6PXw6Pd98WJ7u8Vd8
cKuGDon3Uq9p1fGsD6U1mvJXKfk1Ja2J9frpvx9wrP94nO74AogagEtx9RY70kplOb1S
2czT8vr830lT5L8u0VZ/DO3lEm0l0TYvcPOvHhpZY9MZb7vj/X+fbh6Wvzye7u/ub29O
948fl9evlz8/Hd7dn35Qb/6xXLmIoeb4d6CnumoVyZW/h1+s94uJgc5aul3Lv1vybBdQ
R30Dda7DVtVx1KrTgFZ0qXKk9eqTNV5t0q+eexFvYCKE/XeRt52I13Z1KSZbRBSLHHsR
NmHnqC5y20tkD3tPMP5d5KlcZBUJFkarU4hV5L5bJXjYXTDGSW3Vi0jUZoWn5VBFDt0q
Ed6RdW7uFLpUEcUiSa/OZdtstHSrJO1WyqbR9qGXiDhQiqGB/7ETyTZhEU0NLKdexIfV
kk5U4e9hyTGvLjtn6iqfOxGjrccVpeaebzr8jY4wpdTYltDF6JzX5Fp1Dx3+xlBYDaJL
FXnXr2JyxEZuAi7jb6xlX/Dxii6WrzGF5tCPQiQnxNOU1fQWjbM4NLUWdStEQoIDhFQv
QGxEJq825Ti2qLMIPA1hnuYOYOCIq6E8t1zjHaJ3piC13fHnpJpI2yvIBU2rz7pZ5UOP
PztjpAaV38QiERkspTD3EBNwzxbpQk0d2iBEsumGK9YSo1ltDo39C1iSiWug5sgfhQTu
0NOln3XopwxHy97Ow4/JuGai2Gh718OfYZWmDXMCuJwdVHFz4JTVJqyhDWE33SJWM5kg
4+dHtgiTayZyagqtNSAIiaKd36E1KTKv8RV9sZF1CfG0jZWPQiQhbmhv5/Bbhzv03l+J
/taRXqNOc/Qtuyr55Ofwwx5xZk12HnwsOZzZh2aVo1gFruq0bVb51It451erfWP94hZ9
QrLy2vc5ZMpu1O+kE5LdqOiLDH5xnNqDl+zGWX1dnRd2o/64OstZHdaKvGvUqezm+Lic
3t+clrv7D6fD03G5AQ6fnh4/HZ4+/Lacnm7uPx7eLafH5f4Bf/r5sDwfD0/fjStWNOEO
Y/0B5/cji60+UGWIZ1GmFUQARMwmtUm/WgDh5/vbwxdZwVBt9XusYDdKDzKyGaX6SqP8
1yiqr1CnGOWuTgXx56fDDayxGNtyRKVyvLu55Xrl32B5BTLErit+/D0Nr0C2q1Mh+9/D
u+fbw8KOe3N6fPo3aGY0k6yBao2L7henvok+7cUpqU80Q316FzWc072hTVi9Wm4fj6fj
d3OIriR2Js9KYvVtbP+rSuJdnYrg3/p617o1eGfVJvzqfS8BXut90G5fT/BND9KawdFM
ERmSIg/SCpZBVFdZRElMzDKyqSJ9SRbIMMtga52tErjH44nJ4iZy7Etio6GL9o0ufRsg
BhQn2sGodpG3HStKxq5BByv32etdDx7oTUxVpK+lsgYnyhFetYv0hVIG+Yo2mgYWUe8G
HCgWqr7h/1ZUqgYnSvbKLRoNfY2NDbiiItNZwxhimONfXBIID9StJTHsPwVbLVTWJ0yz
Y2iv6J0oiUGzQ0h2jouxuMZkdZhfgHEahw7BqMboehEPDzCmsQVRQSLVrDbY5gIEumSh
rm6N4ShEInuAu/CRviRGBc8XdUUXb/2afGuY70c1cfR5mZ85IC4gLYTpPkyKYHVN1BvU
u1wS69ic51HWuziy0U7NTSFGnMdcM9xk7Wp8ChV9oUoiv7rWh4Qmpdw17pr1c3cqlEp1
euTMXY02+Dz0JRk3nlK2c02s5tvJdKFJVxDDEVdr2+s5iELV+9XHNmzLWjYmhBYb58HH
omrmJvcV9MGn40o5VfBvRZ2qHcpql64s4mBMuALfOnNfEEe3OjLNKp9lLZvXkKKXG+3w
U0Duda6PK1+TndXvLOm67Iz6QnXZue+Y8nl09vksPUSOgl+JjIcHbSKiG11Cf8kgUxEO
/c6GvKslQgI3yQgZJNZVfhbtaDhZavc5dJfI3ehoA/cOZ6pESqtmq6wiS5/AuQNmKboq
0mvLHTC2/kaXvqed+HlrBitHA9yST1KLPety8ysn7SvyIjETOILXvtGiD2+l+wUCliry
i8zdCAhsj/sqd0KEmPYE0yIyyN0JS1URkQwNuIYp/a9N5CRyN7fIcoxzXJC7cYN+esOA
y9HqQPWqyCeRuRMTo+TnN2ycM4jGVNF/EPkU7Iqzzybw4ygnIxbvuyh5GPLcD6ckIWnS
dka89o01vu+x5z51yGlub0jJEfu4MLd6EzRiZG4kHkYJ12Y7BU2V/nJwsVlEtqAJBC5X
gQ9CACEUlt3YvUAtwtZ0ntsA0i2iLJEO1exPskdNOK9uVHmUDWiPfVxqvbxP2uXt19EV
7NkHU8hz6K1GONHW+Dn2VmdkStOa203fR2X3omCbjX6T7WWoolOYu5cFn13B+LOa+jFS
MlKlDmEc/F460Pz+FVzFX+Zkx+9fc2vilJxWsm0wEG1sXPFqYruK2IddDDd0DX8CBwwx
iID/xWlb/f5ObJe2QRH7tN0XW4ht/ABwjqhjLyuZ3XPW3iR6NyPkDlBBdtWpCHK/C+Wl
4UUruQ9isTecTLdFRGXukMZAFhtlf+4u0cObHXtsFRFlN6o+iro9cv8SF3wGj0cJX0V6
qwwZZ6bALr+JHPqXaFR9PpvQnKh/xomJEzN5M4e/FO8Ucqz49+EnEb/ERQ4cs0OnwC9X
HNY3+J8EjYAlnLn86EAbR3DW69gid4l/xiWGqIOvIiISalyjj85LcNXFe7Z2do6cgXut
5SF0cmRVnrN1eVHaRG7kc7ZdSbf3LKI/1+6RclBTbEvtDidqVvlVvlWDF1nd4C9COxcN
CIQ0dyL8ORd+KbciSj5nu2jc3BQMuyuCWJK4qPqcnTjN0BVcyhuZ8VfwZ6buQmwWeZbP
2SgOS+W3iQh6FQKoRHRGzU0B9QJ4uM9XLjpy5bepO87hEWkGS+W5KxqkOzgAuTZE9U/R
nsvdaNoQJZgATmRzltDVp2jnVpusm/ui4cmRUFpgI3VLEtfaoprSzQWcBBUA2wPja2zh
vRBJZiXnGgeQBTyPHMTs5uHS4qqRI3LFfxnxCRdayxVPt8ioqC5iex41qPB9vOLz5xL/
IracxFu048ddF+emYLnThjhnZBKpb9GoIFFQpbkrWrJgwZquAYdSCTSY1NSJOCDjDkOe
Bw5bSH1p5czCjy2s3rXh/wveJtQ3edAuaqjKW3ioqn/eedUTF2SI6DXf0Yv4HnS3a+RZ
AB8KK99E3g84B8HnbRXpvYhbEgE+36xyGvASF8twySYi3h2Yw8LbcI+byE+ia4GYG7m6
3iTeiqYFzD/6UIropEY3HRKyok2mLtLbf7Qccl1o9umTOLcxA0BpzvPPni1YpLxAPNq2
ifRBjPuYhiN3FfkgWElaLaiNmcOfUKuQtaZR9zh6dgixhV9M4oF+whONU9NVyrMDaFJj
UH//YURdgiFTL0B2QAIMM4QwvwHDLVHmL1VEpBEOl9pUX5BJzyKL5PJi0xuUqtSFJ5W1
qyJyzC4RWF97R33vyfB0D+nWLuUkHvFbi282+pNscGgUcb6x/xvJS3i2sHVXMYBFKH/J
Bl/xH8zZsZNYM7cX7r+zZcbW6tSQmFzxI8MtxGB8bG+xuwAkCDa7cAU6dsfQOsA70QdJ
mulyvKJKArvMJru5A4CX0BpCTlfwz5yvTHuLb0dvBtmkxv7lKpl9ulVXpHHuAAJg14ZL
1bcoYN2ehNd/SRWtvkE22l/KVd4m3Iez41/zUK6+QU1/1ka1qfGvs9HxF2HJKcDmcNEG
wRsSw6lYAhfLqJ/ivsZnkfOgNQr6ukvvQ4gHqNZttLvEu0Gf3qFMqGscRCG+TY1vEkdR
hyNoaPagTaKvQ7iPaFCHp13ig+jjO35xC1WPHg/UxSh2CDa/SfwqXtAzP9bUw77uBRB0
YuK56Jc7lC/suBbUBWauRka01o5nVC/gUBcZSoOLIBduEqfp2/km8WMf8ZnxW64bJpBy
BiPUBDZPITVcEoD0ODU7i+EnPfCvitivcky89AbzjthrIRGZYseq6XtZeDNR0XWXmx6x
MiPO79QzEzM8dxp4dmckURAjpOucwxU8XgbESZh6PyCe1RR19qjAb0mbhOyqn2e/aUfs
MJn9zpd49HPdWKJa0MceMX7Uci7OnfI81Z0a+xBfCXDPCt5Q17gbzn0nH6fecJ7pTmmP
0XJy/yVf2bkl58hft+jqlTJbwYLIhKrps3wFt4gfuYagtx1iKJBRz1uTp4ihPs4oVhpL
FuUkIjrO4sw0rFtLsGSyqQnJvQRujgCKutD0oq61lnuJeWqnZVA78hDbhpgsWUEkQPzn
9mGZ6oEYpct7aRGjqJkX0TSOWZ4vIeA2tI+CmKfM7Ro/vX0UvRb1X5M8+maN5ekSF3P1
SoEHWBVKu8aST99tEPySGyQnyuZb0e43L2/FL8Ki9cpTdqj/bNwlxDN+5PaVTvuGgrJ6
eIxmO9kl7sVXZ4iGEex5lzgNpvBQgcJUN4ll+l3aJtGHkABbRhBy2y5KhJAQcVrH1WWP
Rx0D4Mlqkyoevakyg3cGnGqXEHMCXE/7jACxSXzqq1wQeI/gTbuEmBKI3O5OzS4PojvP
TIhsnCKW+eZKkNkkRFslZ/7ALpodsdvR871t7UMEXR4KQvCnSwtSF+QABNSmmQExNwD/
5LbkyIDUxYdoMwNCfU3IMHCaGRz7Z2hqZupgY2CoKID3NX6Rpa+HhxLtgD2PmvbGgQbP
rrY05Imz5SbxoQeMn88CZ8vpWbiTFVOMQzwKYt7AxlyqRijyKUyDH7rzfBd+XvPZ0Y6Y
MI+AWJddXUIQspDimmj3ODUgIA7BITVW+jR61g8m1qP83ANWhmpQi06jmOEXsYQafnjY
M0WBptrEPI0vSPm0xpDcHFJuPCGNVRN7GtXLRjemvowICPKL2xETCVczMUzOTE9rsQN7
XN3lVlAUCtzE9FfWyJZ7mHbqlIWiIFBVlxNjb8in/ILlppmhvPY7RN0dsY/ysT9wB5Mu
b/9CAjdn+A1+Q0w23g3KJJvyXA8ukikZe+lQFxQl4F7a4PDSL/y+L/08zR9NUt+mR1Gu
8g/2KKDNzkNePv35i+hReP7SWO/CsgPhA0904IY2iX7AmGeZLGJiXeN++vn7JtF36Lii
spmfqzcJ+fV7RuQFC9wlOr9QARkgJ26K9bvUHkVYU6JAu8RJNOWJ47s2anYW/vId8Z3S
vsbnQY/COMc/ksOMiz+uuSimRo/RmEDg4eNN4K4zem7HI4dQnF4cDwnYRBWvvqGcUYFG
ZMU81YJJSAqBwi5xHLIQY3e4nuXn7vz60OgpepllPABRYofrOJoOcMHZqXGchwN0ipeH
VV2HwrhEUyMtHMPyK9VIU7VxDJNdnJkgcwyD3J7HoL/MD4JRhaxmmJfuu+Gu4cxGy8x/
4v93A+xxNM8fYwO6JBAoUTM/j28SgupwSaZ5Ln0KGBN/1KlmCMf5E3gCHDHWNX6UUwUw
QjfXs7AUcFg1tUBmKUhWczV55MClPcSpwZftOsFVnJvbV+nat0FQUOmMxJ5jjbqDDgdi
C49VjRRV29ihRfSY33xpkticrmzCLCZZt+P16/Czd22mceP80bt21byeh9+886zghfGI
T959hetdn7PZYcH45ycpDEXDXYaXos4DBGl1volfN+PhAF8VfZYtEvBCneb2ZfmHTmT4
9NTpSwPE5t3pByyHC3Gsk6eZqTRAoG0XzlXXALG+8SWxBrcU+QdT7BKvG+KhvuNXhEH+
MKLjrAGiXoTFwFEZZiRUKNty4nrLoGLmBBZeOmB9KY5Snsct4FJh0nnieYBEttmlp5c8
pugzT6yGSf+zfD+YeZI+TLqsHMUCJV3X6LNgmVH0Ou8C4ifuJB6ixyJqdhSOYpr4g5jZ
JvXrwg0wMQiQLH/DZfL0sPw4onVE9RHsuIIpP0rHo/jYBP45+kE6ISc7PKza5w75859w
8WR1NuX/B+1p6cIKZW5kc3RyZWFtCmVuZG9iagoxMzggMCBvYmoKNDY2NgplbmRvYmoK
MTM1IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTE0IDAgUiAvUmVzb3VyY2Vz
IDEzNyAwIFIgL0NvbnRlbnRzIDEzNiAwIFIKL01lZGlhQm94IFswIDAgNzkyIDYxMl0g
Pj4KZW5kb2JqCjEzNyAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdl
QiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxCjUgMCBSID4+IC9G
b250IDw8IC9GMy4wIDIxIDAgUiAvRjEuMCA2IDAgUiAvRjIuMCA5IDAgUiA+PiAvWE9i
amVjdAo8PCAvSW0xOCAxMzkgMCBSID4+ID4+CmVuZG9iagoxMzkgMCBvYmoKPDwgL0xl
bmd0aCAxNDAgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg
MjU2IC9IZWlnaHQKMSAvQ29sb3JTcGFjZSA1IDAgUiAvU01hc2sgMTQxIDAgUiAvQml0
c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42m3C
ezDTAQAA4P7rrruu67q6urq66sqbPPMIeSR5hCIconAkUTiSJIqiKJJI/PZ+2Ma8hmGe
8xjzntlmY2zz2mY2j3mUfrgr3fXdd0AFOKgCHFIFDqsBR9SAo+rAMQ3guCZwQgtyUgty
ShtyWgdy5grkrC7knB7kvB70gj70ogH0kiH0shFU5SpU1RimbgLTMIVpmsG0zeA61+BX
zOG6FnB9S7jBdYShFcLIGmFsgzCxRZreQJrZIc3tURa3UJYOKCtHlLUT2sYZbXsbbeeC
uemKsXfDONzBOrpjnTywzvdKXDxLXL1wbt64uz44d1+8hx/e8z7By5/gHUDweVjqG1jq
F1TmH1wWEEJ8EEoMfEQMCisPDi8PeVIRGlERFln5+FlleFRVRHRVZEz109jqqDhS9HNS
THxNbEJN3Mva+MS6F0l1Ca/JicnkVyn1SW/rk1MbUtIa3rxvTE2npGVQ3n1oSs9syshq
/vipJTO7JSun9fOX1uzctpy89txv7V/zqXkF1PzCjoIfnd+LOguLu4ogXcXQbgBGg8Jp
MGQPHNWLQPeiMHR0CR2D68Pi+3GEfnzpAIE4WFo+SKwYKq8cqqgarqweqSKNkGoZNXWj
teTRunomuYFZ3zjWQGFRmlhNzezmFnZLG6e1ndNGHW/v4FI7uR1dvM5uXhdtortngtY7
2UPn9/bx6X1Tff1T/QPTA4PTg0OCoWHB8IhwhCFkjIoYTNEoc4Y5NjPGmmWxZ9mcOQ54
fH6cO8/lLfAmdk5Miif5Yj5fwp+STE1LpwVSAVi4KBQuikQy0YxsBjy7NDu3NAeel8+D
F+QLCwqxWCGWKCSSZYl0WQpeXFncLZOtgpeWdsvX5GDFmmKnUrGsXAavKFdW1neurq/u
XdtY26vcUO7cBK+v/72xAd7au7m5/8+trX/u8+vP/9re3v4NEhkbcQplbmRzdHJlYW0K
ZW5kb2JqCjE0MCAwIG9iago3MDcKZW5kb2JqCjE0MSAwIG9iago8PCAvTGVuZ3RoIDE0
MiAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNTYgL0hl
aWdodAoxIC9Db2xvclNwYWNlIC9EZXZpY2VHcmF5IC9CaXRzUGVyQ29tcG9uZW50IDgg
L0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnja+/9/ZAMACAD/AQplbmRzdHJl
YW0KZW5kb2JqCjE0MiAwIG9iagoxMgplbmRvYmoKMTQ0IDAgb2JqCjw8IC9MZW5ndGgg
MTQ2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNrNXE2THLeRvdev
wJGKIItA4vu467VjFbEb4Y1lhC+6tIdNTps906PuHtLcX7+Z6K4CClnZIiWZFOUwRTEJ
JB4SLx8SWfxZ/Y/6WdmA/xs1/vBRRdDKO62OW/U39ahe/+lk1N1JmfLP6Y6MfbxYh2L8
6mI9vPvisbTSo/GQnTEJ/zWApV9YGv1n/DXYXH4MulhOv6Sh9WXkrO4e1L+/Ub5Y0E/G
a63AG/XmQb3+ixnxv6g379QLE39Qb/4x/PkNOrfuns0jje5mJ/+6Pd5tn87Pm7067vCP
+GBHjT4kmmt45UYdL/64NEZT/qhLfkxJa0d+vf7xwWT1Hwdxxisgwwq4Lo4ecEY3ujKc
Hl2ZzDv16vLvSbtIf5yjPfw2tNUS7YGjba5w08/GgFFgIF0Ahxnwf3s871795bh5fkvA
KwJ++Iq4wH++2q/oiw3+BN4rE+PVKTs79RM4P7vzNcD9ojtdUA4Ld6xr3akY/e/2+HF7
PKnN49vXh6O62++2j2f65Wb/+f+26mF7Om3eb0/qHf7m0+GMv7nb7PeffxikFXw1oMPN
Y9WvAA96t4K3m8f32+Ph+fRSPexO++3m7e7x/UuF/h7O99vjp91pq07Pp6fd3Q6N1H73
+OGkfnrxHVYAFolhbQk/WYBrTAy/gz9fHKLWplV/noozrWGyY9bRD5P1i/vd6R5xliP5
l7wevjySO68DUuvC62FG0f56f76S7lt/Ul7f1R9+ie//VbQTdPwj0c7sTsXmP7f7J/V0
REK5O6vn0/ao3h0PD/h/SNbq0+58f3g+q7/vD3cfMMjUfvt+d949bM5bdXd4JBL6HqeX
kPX6FqF/y8NbkJ3daZMeMvdpd1J3m0f1aXN8LPAio5/P24enM8F5PiCd7/eHT8iLd/cX
RvxmgIZY/hz+ZBMo41Cf9IBa0N8M0OqO87ZxpwL638WXaoeYj97ij2GyfrHpTZwfg0aV
Nlsce4toRu8tukEmA5l86EwCzhMwY8Q6iupNIJKcQnE2m1xORmPi8ogiCxc+m9z3o2TE
JDrfuLu9mgxXk1gmMjrIvkRac4TcuLtvTAYyQS1pssu+muz6URKgkA25RsaLx84kgR2d
zcZX/HvoUtCjNz40o5x6k4zyNqNwnPHvF5RNGI1x2sjeZutwi3zOrbdL/HP0iH+CJCOX
syXFbppRNh3+Rls9Zh+iDIvRGFIhZnGewWjcaNA6ywsyBoMuAuQb8xiMKOc8VPjfMhOc
yIR4Y58NUHSnaygU/O+YCUZUDH4FlmqC4ZIcWDn+jdV+1A7CDV9QN4x4z2lMPvb4W4yo
gLcWfkTqKBhR0bSLVl38428E4qLG5FM/igtp1Nn5G4v2uCLUG7luwGdm4mAEF60cdHg6
NKKbbd2AQ28StBkdHoMbwRBoIlx6O1G3AYEmsr4JXRYvkSZq+WfX44+X27Hl0xMbwsdR
+9Dg9tSHf6QNikkgqDJKwg1aUi5DP3k72hhNj/63EJ1d7rTWSLnzm6jOLnfO7tTc+WOH
nqO0BybjblytWUh5Q6FbDuxk8tSbeBhzCKTH0KTE7nNvgpwaUkqujnLu056hQkkJ78mk
j92A/I6H3tgbo/gwBuREX00OXfAGjDuUC9G1E3Vpj3zxKAqqyalPnrRoC60vPS6RFu0R
u2rSh2+ydBiJOyaLB5YYaZdjaOZ5xTIjbpGOucG/P4+Y5UdIC1d6fs8Jz1qgbFSB66hD
o+zQyTaoHFnWw+OoITSjMO6gxOhdSkqMOdxiXFE0zUTve+42hD8mfHkTjaGJkHtl+Eva
89mkij/jICCtZWxa9+ViEuKYbDAVf8bdlibyyd6AzmJ0ew2mha5PngXdG4fIWNQ3gOe1
mtz3+DsM7uxCc0IeWNYro7TgnhpSHb7l3Rms/SPdnWd3Kqn+7X77qE6lbqfeHrbXYh1e
+V6q3ePd/vntFl05Pe/P5SI9lfC+143Z4K7+gW7MszsVzz//c/PwtN+eFls8/F4u4SjD
7TSu0S/5Cvyvj7gujc/uVIT+q0/jmGjwlkA5+mrNqGNK49XicT2LuzrlfI8b5iyuSbtn
U01Oa1dgk4kuJ5Nedge6mTpjG28/sStwRKUbiIAmk/6WHG1CpZs83aPmNXcmqAWi074Z
5W4lRSfUuxdchrWJEtGyzeDXV1RMiJYDZopqsu3wpzSO5ByrxcNKinbGtfg/dfjnMgje
6qsJS1eaLnI+NRMd+tSpqQaRKNNPJuzColEMOB+tvGa8mroxxwwV/w2/mmLMeh/loDOG
CgwxVfgVT9FmBDop8yA/MhO8jSQMhmry1z5zQnAogGK4saByedW5MWHXfksTpcaCXZ3K
xVQnK5oMVMJA/ambUZgUcHiKIDrXxhO7mLrRep0G8SjixRSvcdBGCzfBU+S1vYW/p5sc
+KTEc2Y8ygXv4mKf+1snXbVDu4vMl0A3OVxWNTn3+IcyUUg3cIlIdAEsqNWwLPEfMf7R
lVvbGPGkOTD5RrgkPGjZ2WYDmOhLNFEIDV2+YyaoUVMI/sYGEHXYcnUSD1rGeEHkFqTb
bUBG1kWJn2RGNXQDiC0t9DcnoAuAs8bKuwg6kIqNie/ihD/oMk+SsQW8RoxgZdoAQ6vB
m6tMPkgHpJVTkhkXdTKMVl/5aVgLJxT/xJVgbjgLmKyydqbdnyX4QNI+J+3lIw9EHBla
9t9+p6J7TqxucGKCg0rUGHDD1Zhf+OlimzG6p+HYGJ4uTdEja18sBnZ/DuVyFl0dYyeq
jcmiJPihsSg1bo+cLY5RStwxzQtnCTNShdtRT4u02lJJp+4JcbWJsphNMc6IMRGBuSUG
Hd08xt9XyuguWW1nxLZrVXRP5coFHrxE3uCx6RDLyEhIotaJqzUaOdYhVa+udpYY3tSN
264JDFQpdZIVfeFHo7ObAWN3XYO7bylhTxaM0QxVbzFpi4ChuqBZUvXjMy97w4hMnpae
DgttgbGuQ1pCuhiDSp0Jk9JkcewBo5p3pLqJiBgRRNJNiCl+90euAl8RO3BdQQI+VsRY
PnKXSnVF7LwmPJxLIHtKusPjILPFY4/YpR7erFYoh6e8GoRDUw0H8ciZQOImNKtlnpKe
CK4CxnUAFaBDsLKjEQ9USqmeyR0vhSN9GG2XcCzVBtKHhSCHWCJV45tz/bAmJDKl5rUg
LIBlnamSWLdlvyYjPD0ZSlyJKgJTkDdhkPgFRYQdUUrLnA0aNy74hm27ZKkpKyPnivyD
AsLSo0xkWz8LFTzXo4kNAXGJgcERELDZoruDDkCvZt41K2ESg0qDAZpd+cws8LBEpMtB
ClKwiEaMTZC+ZBa4FsgzzQ18LRbXghrFi5kDiBq8s3GJaRNhQNQApFUluqXqAYpM4SwU
YedIw6Qmk/bnCYgaImYHJVEUEDU4C1nMk0DUkH1DyD3tA1FDmAN94BtHzIDHsrrxkVkg
MyTIackd3+EZJxvWrLMXX3GuxozoSo9EThSpV4v3rEWCckdJYsWC81jRaw5CHePMHnku
5aE4W+x6NUZ+BJfdbNHzWCizmFDH6HksUt0BCVH2o3RHYMo2SsLj2vmQ8oyYWm98IJ10
tXha73vA+9KE2DPTa6QK6elgGuO48riDOscsJ2nFGMroBNHm2aI/MLm8puQAswUXY1QS
giDDQVcOpCkIq2Nc9RrVabIRAUO9ZlCN1Ul+esH1msWrobEzYCeu15ByY6yrfV6rBs2H
Ys4+c4EAJTbmjiZGmSSkC51GklLCQoYi1gLosBqB80tNaML8xJUYkbp1MlqWej+od3uy
+LSmxFBKOfFAGqLbEMGJB8E4KmnhcVjCsVBitCfZL09s37pAOnq2eOzDy9MkNhslLpb4
2AZjZESJkDE9BRkwetjNraf7NTGH6boCdlhTc6BtZPGz0GqQNCw9HbrKkPUNP+3XCkOJ
+hrW1lIQS1RGQcZfxfQyBl5cDECSj2ymi0vOdhA3n9QcZhkvh1jGswB+zgocMTxtecwx
yAwGRB0ZmrV86JUFUUfOsWGGH76uQ2P4dW8p/GkHE/rwVS87NzP78Bu8ocyO3vQt0/LD
ztWYZ+XpXWcy6Cuv9VlnsvggpG0zW6i+Y+KStpE0Jwv2YEOlCSogSo5iQFC51KTqB0vb
yBJ4Q8XEPlmwNx9HxVKqufae1sROtdJgvTwLRqNPoSTwvF5EMVS1tZjYpzH+yd57wog5
2YflLE3QJ1qtzQ1iaqVU4wLSyWxx19FELg9PVHucLHju96jZtW82n1VqqOoLcZDgwHsp
Mg31dEwWG97IiLMQ806AsRyhKUyTueGHKb0NNi3Do+VVU1obfLoxBs3iqgFrCQFqD4ra
ipgbKE0jAPJigQ4Dyj4xwi6dHFkHMUpxrailUWjMgB3Wsr9ugvS09gBkMO2KAYbygCYx
coChPKCuFBtXEb1k7tKUEmQ0SuO0RYUxWTzw1I5qHPd/xovXWPDQ5uSrG6+ZBak+KkxM
eK2kdhRtdLGQaNCEUvlsAGM1p/JgHJsQ/MCSf+kNFuLn8nJEz8WxiZ+PLHFTY7BL1dPt
WmrHQDczYkf+4GORslNlBlaTzNYgZXs3I6Z4oSZT7cvJIUavPcSl4pEETRIjNEfyYe2x
B5OPW92XYU7+wVWLPX/rMSjbghWjsJRqfGhIjIkQUx6dQhAPw/QaFGbEWHmDKsEADWMf
+HMRPToZWM4ydOUeFxsy5bMQ6tHaVfYYLuUekm3eixEEtsxisrxaWySXzYOIaakEt1x5
xyw8UpCLMmCOys0uVjhYnc7TJCF3BNMC5sskQY4OeloOQWS5ARMTXrJTzvIQwdBVvoFr
x8tB9DjTwPXIy0GG+v1NRx6iaBx+n3YgFI3DUsLSa9ivlbDDb/emCVSSsLM3X9KbdDVm
ynCWsJOB3Jk0WYgSdpgs1NpbYpGwk0Uf8LUt6WLB03YoHbI2eNHTWBpkMSRniz5vx9KI
G6COsWEClWaBi9xdJdWk6cmBOiUkP1L54Im+Jpgs2HskMkRAdeBFxDK9WGpvYbmW1oIq
YNrPfnDEMlXAIDZ+PPF+JVyM13UW9vahgTr8oVrwnie6F+QmgrasBEZ6nL4JnSw+8pbj
QE9jZnWMWaGixqyI7dcajjGMvJIwrV/iTIixFyegil/KNU4PvIKFs9A39pPFQ4+YLWOg
gJBijJrI8EjVE8xiDHNuwLQcrRhjlyYlen6VYqw8FWKwy6fyUqDSyYgxVr6u0fRAOyF2
vyZSo232lsvYMks04qlEGUuzRCfvXKBCGTSRzN7XQmn98nXnmLAjAqFarRxj1GqAZ18G
LFI5jt5nxW2JpeY3H6iV20cqNb+Ggs68cQkhzZDkQ0m1bYvbJ4NO/GHpfXZtlsuDZPHD
BBn0XIqP9oanufhh04zYPX9uxK21MublvdEYqGdScZmLO2ub/HPmL5JUA3V+eWpbpVOK
3z4EkQmLiIWY0iocw0XEUhzrJDIhlPI4NBvHG5qoQo534EFiQgCqo0Z/AzG83OJaoIbY
/jt9ckUM9sf54mr25gvU0HA1lgt6k4Gshi4Ww42C3jSGrIYmC9Y3NauhyUJWQ2ueDgs1
NFmwYtyshiYLUQ2JgFU1JCFW1dCEmKiGRMSqGpostuypLuFaTBLdoGo7qh2dl6AvZAqJ
EOoTlEA3KLeQAiDOFm95MY6aOFweFo72xbhA73DiGIYqITBv/rAmZOyYSOqsrWUWMpla
aCcL9vZUhEwb6pu1Wlukp7jJgvdN0VrqYVgbg97inI6yp44ebFC7DVKYGkf1FvqWWMT0
+p3wDBhv6cZ7qraxhsdKL7ahD9zrUl7ytqmMeShAF6Xf9iHF+FAWMXRU94krJhyDvu9Z
BMDap8ji2S6FP/Axigwyf6s8Ac8lFVWPrHMy8FT3C0bXrXni7VeBPhk1cpTRJyB4tL18
tumt36EY7mLo69LU8Fs3j0TdFap2815y5UXc7WRCROVVWNVNsbDyeKgRNUhx9fReLCx9
5wntLH0zmKc+4mb3+CyZvvIMgYVIbQYztvRyiIEIeLKol0M63tQLdv2UVFwKmIhxmEEE
DJUXvcUYmKP9mSsvaoy3ciZD5YWzwEy7vOcEJ0l0QYhiuNNfeECfiNZA5L1gtnwhKpMq
/V0Go4YmDe2/2fehS83lE/sLYrZis/rVmMnm2h41WWzX/gYZVCvThANvXKKHkBKH0hj0
dzNooAaFyaJ/oyit6J4aFCYL/kZKs1Cb1mTRfib5/034Bm8KZW5kc3RyZWFtCmVuZG9i
agoxNDYgMCBvYmoKNDYzNwplbmRvYmoKMTQzIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9Q
YXJlbnQgMTE0IDAgUiAvUmVzb3VyY2VzIDE0NSAwIFIgL0NvbnRlbnRzIDE0NCAwIFIK
L01lZGlhQm94IFswIDAgNzkyIDYxMl0gPj4KZW5kb2JqCjE0NSAwIG9iago8PCAvUHJv
Y1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JT
cGFjZSA8PCAvQ3MxCjUgMCBSID4+IC9Gb250IDw8IC9GMy4wIDIxIDAgUiAvRjEuMCA2
IDAgUiAvRjIuMCA5IDAgUiA+PiAvWE9iamVjdAo8PCAvSW0xOSAxNDcgMCBSID4+ID4+
CmVuZG9iagoxNDcgMCBvYmoKPDwgL0xlbmd0aCAxNDggMCBSIC9UeXBlIC9YT2JqZWN0
IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjU2IC9IZWlnaHQKMSAvQ29sb3JTcGFjZSA1
IDAgUiAvU01hc2sgMTQ5IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0Zs
YXRlRGVjb2RlCj4+CnN0cmVhbQp42m3CezDTAQAA4P7rrruu67q6urq66sqbPPMIeSR5
hCIconAkUTiSJIqiKJJI/PZ+2Ma8hmGe8xjzntlmY2zz2mY2j3mUfrgr3fXdd0AFOKgC
HFIFDqsBR9SAo+rAMQ3guCZwQgtyUgtyShtyWgdy5grkrC7knB7kvB70gj70ogH0kiH0
shFU5SpU1RimbgLTMIVpmsG0zeA61+BXzOG6FnB9S7jBdYShFcLIGmFsgzCxRZreQJrZ
Ic3tURa3UJYOKCtHlLUT2sYZbXsbbeeCuemKsXfDONzBOrpjnTywzvdKXDxLXL1wbt64
uz44d1+8hx/e8z7By5/gHUDweVjqG1jqF1TmH1wWEEJ8EEoMfEQMCisPDi8PeVIRGlER
Fln5+FlleFRVRHRVZEz109jqqDhS9HNSTHxNbEJN3Mva+MS6F0l1Ca/JicnkVyn1SW/r
k1MbUtIa3rxvTE2npGVQ3n1oSs9syshq/vipJTO7JSun9fOX1uzctpy89txv7V/zqXkF
1PzCjoIfnd+LOguLu4ogXcXQbgBGg8JpMGQPHNWLQPeiMHR0CR2D68Pi+3GEfnzpAIE4
WFo+SKwYKq8cqqgarqweqSKNkGoZNXWjteTRunomuYFZ3zjWQGFRmlhNzezmFnZLG6e1
ndNGHW/v4FI7uR1dvM5uXhdtortngtY72UPn9/bx6X1Tff1T/QPTA4PTg0OCoWHB8Ihw
hCFkjIoYTNEoc4Y5NjPGmmWxZ9mcOQ54fH6cO8/lLfAmdk5Miif5Yj5fwp+STE1LpwVS
AVi4KBQuikQy0YxsBjy7NDu3NAeel8+DF+QLCwqxWCGWKCSSZYl0WQpeXFncLZOtgpeW
dsvX5GDFmmKnUrGsXAavKFdW1neurq/uXdtY26vcUO7cBK+v/72xAd7au7m5/8+trX/u
8+vP/9re3v4NEhkbcQplbmRzdHJlYW0KZW5kb2JqCjE0OCAwIG9iago3MDcKZW5kb2Jq
CjE0OSAwIG9iago8PCAvTGVuZ3RoIDE1MCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5
cGUgL0ltYWdlIC9XaWR0aCAyNTYgL0hlaWdodAoxIC9Db2xvclNwYWNlIC9EZXZpY2VH
cmF5IC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3Ry
ZWFtCnja+/9/ZAMACAD/AQplbmRzdHJlYW0KZW5kb2JqCjE1MCAwIG9iagoxMgplbmRv
YmoKMTUyIDAgb2JqCjw8IC9MZW5ndGggMTU0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k
ZSA+PgpzdHJlYW0KeNrNW9tyHLcRfcdXzKNcZY9wadzylshOlaucKieWKy9+WS9H4drk
Lr27sqy/z+mZnRkQGIxIkZYsuUyJagKN07fTDexvzb+b3xrj8F8r8cv6xmvZWJLNsWv+
2+ybl69OqtmeGtX/Pm1Z2PpB2vXCXw3S4s2D15KNbJXVkZQK+KPThv9iePXf8HdtYv9L
yF5y/CsvLYeVY7O9bf7xurG9BH9RVspGW9W8vm1e/lO1+E7z+k3zQoUvmte/iG9eQ7ll
9UxseXWalPy+O267u/PbzU1z3OFHrDOthA6B9xJfUSv9oA+F1qv+RynYNgQpifV6+e0t
1v36UN3xAohYAJd8azV2pJb65WRL/WaWmq+GPwdJnn+8RFs8De3mPtqiRFtd4Oav1qtG
Kx0GvPWE978O2P3r7rzZ3Zyaw7755o/N7d1Nd/pCvP6lWbHCotr4vaCkWHWJYPqfwxdt
baO814OKZlLxJ02WnQLqiGdQZx2zWR1DqTozYn/vdZnlSNpWwfhWjNIv9rmIhbZBhzgt
+GKbiVipW9IBvsIigkWucxFrWmOUmRc5ZBJOEs5GqcixN2QiAuCcM0HPIk2+io1tUA6+
MomcLyJiFAnwe+fcjNCLLlvFG9NGpXWiyx+JiGCRAFNYH1S50bhKkAH2CSrU1Q1GtcpJ
RzP+u1zEUgvgVLLRKROJEpFmg4sz/vlGURvgki6yySU8R65z97S9j3+MMKKMimaRH7NV
lIShKcQEuf9k+EMLAzPGZJXv8lUUkpL1Kf5Nhj/yi2+9vvjcIv5KK4s0ZpNDXxcizrXG
+yiquAB6jY2MXdnIEOdLs4K/MkjsTrvkRLtCJLjW+xBSQ983gCI4ptJEdY9SHK/auyRc
r3IDWOlb5aNf0cUaiXjVSaS9yQ1gbeDEYJdFhlW4VBkd65GmnNHQJSQJ6FiIwBmcTKO+
WMUr2UZrkgS0L0ScagP8e8WMPkRslEKXR4AK7Aw29d3i0AHOYGUMTXGiyQDB6zaaaOvZ
UPUBS2kE3OYGiNFjlbVsqKUGO4lyJUi0BLMIKNeiGiRaxth6Mitm1Iq4SlxwSSLg6VX4
w8QsVSMxXlr3+iOJRFBrZDtKqmThdlpbjRxEi24nLiIxoE7EWPcGbTRqlpdFxI7AiOfi
A1hF1IExTFsXgMnzt4YnYBHtRZG/ZxGPohXSqP5u3dbi44+U2Vp428vgS+/4zquCcRkt
H+R64unqNIM6rBVZk6gzA3y+7ppz98e5uT6f7/728uW7d+/aunriaQ6Qqicm9fiLUuzr
C/rd9cqkglG1ZJi0XKRfbN7fbW4+GadOVDFhGdN20lkMggTuKG2q8/Zw29zs9r92V835
8BHuAA4ztC49xIH7GQ/G+HALiPw0vYNYCOWpackvqHk36PLqh0QXcU+XH149xlmx/aWN
hhL9PyhxC3Lp8+82N81188Nj7FzR7yODib9ALbGE1Slz1oD861ElaUL2xbnb3Lw/vD3u
9m8Oc+O1jGfzkXiybZeQu4XL6jD8+WF4ilU8H+N7Yj2SuCFaALTNo99Q3z/ZCX6OpA/5
5SqOH6jfS4jdMkWlAkfxSL/8uCY6qzA86nlUhfnTUviQQEZ1Zhu+OtzevT13x1Pzv27f
HTc3N++bn7szvtNszs35enfC/zb75vrt7Wb/2WYjJv6lZiOTOjOO32Y8x7jAoyxCKrpI
F+wOFL6NUvfNW1ym4KQiSpMdJMQSAydQ5yD7zmRcJGfgBKbvZZj1BhW935hY4gpIMtQ1
sc63WjpLs0g+GkFjgzbKRZVulA1YSLVGaoqzSD4a4QGLo8BdR77RNGBBZ25iIKqr601o
LfqoGf28M0fmR9bBTvMid8V8xbY+RqNn+AsR7rrRJ9n6mSO6bkneJ2be5KMRH3EgYxLk
ij5WglojYyYip7wxlOipFfCrw6JkgAG0qmIrlJJwOZ8eqOgukVXb6NfgVyrwqMGFGf9t
MTzRsSWvaWUjHWRrvE3wLxpzgNbqfpBW8xZloC7CzNXxVzzJND5RpRhpEAqN1S6BZZ/D
T7Ai6bgSzopnnbaf6S255TAYQUcdtV8D13rNk/1klR+XBiMaRXjG/z+FSNSg6jEJxWKQ
hra9NaTDjH9TDkZcS/FiouURGE89wr3kUkymAkykgls7dAi6NSbE0l0mA3CkoQX19YhW
yBqXzn1JRPTzCkQ94lXX/VIjmSLTSV3G4jxLYANEmxignHr4gEynEr+8KqYIiBEkZ6ob
oB80uOhCPQA0hxFRmoAOmQE0hxG6fFU3AMgatTgz1ROQJgkmhzCox5EG3ebSmhggn0yh
OoDTxdQZcjPqPkhiGmo3hQiCRFnlcgN82pnSQBdU0YR2GXQGfTNkbZik7xXGvowbFMao
en+5iOS+SwFJKg4xfRHJcbEoI54cJatsitsWxl9LEpPIvrhuYfypLzWVVZxFSkVrPZx/
kbs4FAkZ+9nsuMph6S4lGjejWNzr9BkIDkyzyPu8SvPc1YWYbNRkBuBaHxG1CXTFjQwP
4b3qa81FpMsMEBU8QXmqWxEEqTVOx1Dfp89RKGwJ/mUdl6BjLnWXn14UMpzIlFOzAYpp
s3QMTIpuWeyH+xZTN4Dqx7ep05V0wEWUI2VL5ER63WKjryMHOqHaSLruucALfqlD6lC3
5T0J6kggvRxF0z2JDl5Ug6i/JqF+BL/kCVOp9yHx/i8LCQ2XM97muK1mKPEsk9BkDA3C
ERdTFBpV/cCMKZ5Fn4sNbVSL+mxLjgO6K1USA7vcHxxcBsXC1IMNfBnsUKb5cFfeD3Ep
8Wp2iJ9LGoRUZtMYKGkQiDV4ZuIRBZkNDnxXhkTdXz+HR/RXPgsWaAs2ZVDvpUv03Rac
zHsuw7GeYbTkGY4lnwftcGrxiRp7raSuxYHJrSCe69Iln/jeuxSjRX0KYqbQmkc3FzdR
si4eyyPDJk6+L0giYQud7FmwdPDIgC5Jqno0oT912Ei6eqLXqH4tudRpNgVJRBpHzZ4l
MmIsNKFh8IpCveZoQqIPzq+QC22R6H2S5998LobIfX0l/YrnGbc9eL7FnG5BnW3BRsHj
0eaDpFykiypJFqHviEcWo0jumMQNPvx32FMsPg/iK1DXv6AYV/k1F/F8O+GZo4wi+dW7
jY6fytAscV2MpnyLVKaTRXLXBQtCBg8hOVA+pvGa3ywEmy/yaS9s+Wa14lPmk82eU/pN
y+p8kTNs5CAHSyYAf5kZMjjbemuUT22dz+TQnEjrEmPno8qINOWsk6ruDxFZFZ1QoGXv
7dl+lEhCKvGYU8nB4VWW3xXUtAUHB4wyJoG0K6d2Bk0DM53qRkojIUpPcyCVJNwiIfYc
JXfwWSSCp0tL6UYZ2UfqBS4JcAV91og1sibWA0kZGNrzc9RJZFvy9NiqJDeW5I4Uj1h8
IrIpeTqPWNIMVFL5gIY42pU81l8nxX6sMYq8L0QsiGa8JClRmdpRS6hb8yoFi3Sae2ae
VM4nyuBHA9q6SHN8X2rjQ6qEeC6SzpcyAi6nVi5lHl60xJPV6Wso1BEfeJ8yPVhtRuWL
sSghvxgkBjWdrxiLWiQP7fjmchIpbksMuD46KzWpVb5pjVz6gk5WKUYo84vVUSQPx36E
ItdU8ZIrn+KyPorssnD0yB2Gu95ZZF/clsAUaITcLHLOsmGQTEO9TVbp6q9RR5Hj0oUK
6eBEVZfIgzB04KaOXAw8NuJ/nfC/WRqh4NC+Dh2yN04dnUoPLfIXq2heyCUeVU5QeFhG
MVH3rnjUyg+PrU42+qq8UcGppU42usmvDtDCoDZyO18zgNLMye4FwO9F4pVgOZTg35UP
VlFrYuoLBbiG3yhS6v/FgXhYjEyWqHJVpm/FMyGTgisWblT6q/5R5LZMvA6rpFbc5Pg7
zeqqhRiZE28/5CK1HCNiuFFx8DoX03BdvlGxK053uVERdYcKyrcm+lCPIvByOJT2c1pc
uFBhEyVrvCu7ew8zh8TM1zn6EVQLDSHVcdP9vWXPBvLEMXWE0vDLWdJ1vx1uXChWglUM
/TsIg0xjqLyUsZYvQkIZiXOPi3RprEzcf1O5cUm8cluIgEeNBxKLB0LJatFrrWQfzU8I
LNV9X/PrACIdcz/4tFwAJxFKUvWKoymvOC7S5adFQAvRt5OaFiz7zvmKYxQ5LBXf6Prs
TAP8V0vFF6Hq5lW6heLryXJ9HkWuiuI7PVUYRYrqq3hC1jPq/ERT9eWUTI7HHaPI9dJn
QSjwvHkUye+N+9Ia+1c+o8hSaQXf0Hp5lfGtAtJYqOPPTxWssiax4rlyOeFn/LulD3q4
vnWqaYuqCdflfDtKnD7DK1ImX5HWHnGJj3nruPo2TzzirSMbfNJv8VnoqTv+vtt27Qze
058ziurz0GjU5U+3yEom/UbtJaN4GlqPesnYa1TCVT5j5ksiqcVF9vKI+c98yHgfK37Z
iF5+ETzxmVxt0KgEb3wFKiY5fgemp7jhN6Bt+oz6AeiJxz1PzsC6Zbamhnef03fFo18m
P8fLxWDUX+jhYihncNUWWVyE6x3yuNxKgzxIiJX+eFzjbbU9DunISyx1x6Eyzpqa47Aw
NRNj44uGKUwSRf3mj/FIP2NXviOMgfmtNBNg+2KqiXYJvMdVd+mpuAzGTIDlz0kDWgvp
pI/TGt8XDwsUyIgO2VlEWrqJJ12mfhamz+Aict7lKu9xJL894655SeIyieReys27HMtB
JL+2c1rUDKfQNbReq7BoucsYEpTI+dnFTp/s7uY+O/Cmyg4eeXWzkrLFx30SgtnBpN8Y
82JkBzwyRlNrZWtfvrvenLvfu+OfmaVnluB1kqpJmuEDJfN3nyVVP9aQzqhnMuRTPzrA
ZnNlqu5Od91217/Q371p+KNhm6urY3c6Nae7zbZrdqdmfzg328P+fDzc3HRXzc/ve7HD
XXfcnA/HhD//H14kAZIKZW5kc3RyZWFtCmVuZG9iagoxNTQgMCBvYmoKMzY3NAplbmRv
YmoKMTUxIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTE0IDAgUiAvUmVzb3Vy
Y2VzIDE1MyAwIFIgL0NvbnRlbnRzIDE1MiAwIFIKL01lZGlhQm94IFswIDAgNzkyIDYx
Ml0gPj4KZW5kb2JqCjE1MyAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgL0lt
YWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxCjUgMCBSID4+
IC9Gb250IDw8IC9GMy4wIDIxIDAgUiAvRjEuMCA2IDAgUiAvRjIuMCA5IDAgUiA+PiAv
WE9iamVjdAo8PCAvSW0yMCAxNTUgMCBSID4+ID4+CmVuZG9iagoxNTUgMCBvYmoKPDwg
L0xlbmd0aCAxNTYgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk
dGggMjU2IC9IZWlnaHQKMSAvQ29sb3JTcGFjZSA1IDAgUiAvU01hc2sgMTU3IDAgUiAv
Qml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4
2m3CezDTAQAA4P7rrruu67q6urq66sqbPPMIeSR5hCIconAkUTiSJIqiKJJI/PZ+2Ma8
hmGe8xjzntlmY2zz2mY2j3mUfrgr3fXdd0AFOKgCHFIFDqsBR9SAo+rAMQ3guCZwQgty
UgtyShtyWgdy5grkrC7knB7kvB70gj70ogH0kiH0shFU5SpU1RimbgLTMIVpmsG0zeA6
1+BXzOG6FnB9S7jBdYShFcLIGmFsgzCxRZreQJrZIc3tURa3UJYOKCtHlLUT2sYZbXsb
beeCuemKsXfDONzBOrpjnTywzvdKXDxLXL1wbt64uz44d1+8hx/e8z7By5/gHUDweVjq
G1jqF1TmH1wWEEJ8EEoMfEQMCisPDi8PeVIRGlERFln5+FlleFRVRHRVZEz109jqqDhS
9HNSTHxNbEJN3Mva+MS6F0l1Ca/JicnkVyn1SW/rk1MbUtIa3rxvTE2npGVQ3n1oSs9s
yshq/vipJTO7JSun9fOX1uzctpy89txv7V/zqXkF1PzCjoIfnd+LOguLu4ogXcXQbgBG
g8JpMGQPHNWLQPeiMHR0CR2D68Pi+3GEfnzpAIE4WFo+SKwYKq8cqqgarqweqSKNkGoZ
NXWjteTRunomuYFZ3zjWQGFRmlhNzezmFnZLG6e1ndNGHW/v4FI7uR1dvM5uXhdtortn
gtY72UPn9/bx6X1Tff1T/QPTA4PTg0OCoWHB8IhwhCFkjIoYTNEoc4Y5NjPGmmWxZ9mc
OQ54fH6cO8/lLfAmdk5Miif5Yj5fwp+STE1LpwVSAVi4KBQuikQy0YxsBjy7NDu3NAee
l8+DF+QLCwqxWCGWKCSSZYl0WQpeXFncLZOtgpeWdsvX5GDFmmKnUrGsXAavKFdW1neu
rq/uXdtY26vcUO7cBK+v/72xAd7au7m5/8+trX/u8+vP/9re3v4NEhkbcQplbmRzdHJl
YW0KZW5kb2JqCjE1NiAwIG9iago3MDcKZW5kb2JqCjE1NyAwIG9iago8PCAvTGVuZ3Ro
IDE1OCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNTYg
L0hlaWdodAoxIC9Db2xvclNwYWNlIC9EZXZpY2VHcmF5IC9CaXRzUGVyQ29tcG9uZW50
IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnja+/9/ZAMACAD/AQplbmRz
dHJlYW0KZW5kb2JqCjE1OCAwIG9iagoxMgplbmRvYmoKMTYwIDAgb2JqCjw8IC9MZW5n
dGggMTYyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNqNlE9vGjEQ
xe/+FHMkB8zMePxnjm3aSr21KlLPESJqqpAESL5/x17CbuIlqkHaNfr5+fE8nj38hD2E
ZF+PNmKGzAhREA5b+A0PsLo+EmyOQO1z3FQ45oFODV4OtLv9by0E9BRZhajYa+JQJ6Gq
723OQdtw2MjXaZXGQVlhs4PPa4iNqA+KiMCRYL2D1Tfy9gusb2FBegXrv+7r2szN2wvq
q7qcTf7YHjbbp+eXm3s43NmSmIJH81DqXm4pHvPgR4rP1JZKib4URKm+Vt93TPDl8eKO
p0DcTLiSfWTbUbw0OfTSNosCy+G9oOS6vE/bXU67hoxt8PuQ4XLIbgiZQmhQfSZzxxRk
iJnPMf+qKb8hs6DXQNJwZ/jiqWMKsw856qi5uOkhTZZJKTQq7TqIkKLHwmFUghkosidO
PCpd9xDZsQrJROmxh5jVl1h0VHrooUDkA4Y4Kj3PQDH6jDL5d4ceErS6UEofepKiVqdp
onTfQ5GtXArShznViieWV8YtPvVMimox8URoxne2BFg1jUqbGcguj0SexPSnh0pKvmge
mbsr955RDF4F9cO81Y43yDTKbafEaIUpKjJCvW9GK8wk+c3xdkok1oukTGJ66ZW4bcd5
mmWnxFl8sNs/NV6Vzq2NNLdOViBln6x9JLvN2Q7AukZ2QW05o538pT7X2NbkoMFUpWZE
3anH8anH/QNuwE5fCmVuZHN0cmVhbQplbmRvYmoKMTYyIDAgb2JqCjUzMQplbmRvYmoK
MTU5IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTY3IDAgUiAvUmVzb3VyY2Vz
IDE2MSAwIFIgL0NvbnRlbnRzIDE2MCAwIFIKL01lZGlhQm94IFswIDAgNzkyIDYxMl0g
Pj4KZW5kb2JqCjE2MSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdl
QiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxCjUgMCBSID4+IC9G
b250IDw8IC9GMS4wIDYgMCBSIC9GMi4wIDkgMCBSID4+IC9YT2JqZWN0IDw8IC9JbTIx
IDE2MyAwIFIKL0ltMjIgMTY1IDAgUiA+PiA+PgplbmRvYmoKMTYzIDAgb2JqCjw8IC9M
ZW5ndGggMTY0IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo
IDI1NiAvSGVpZ2h0CjEgL0NvbG9yU3BhY2UgNSAwIFIgL1NNYXNrIDE2OCAwIFIgL0Jp
dHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNpt
wnsw0wEAAOD+6667ruu6urq6uurKmzzzCHkkeYQiHKJwJFE4kiSKoiiSSPz2ftjGvIZh
nvMY857ZZmNs89pmNo95lH64K9313XdABTioAhxSBQ6rAUfUgKPqwDEN4LgmcEILclIL
ckobcloHcuYK5Kwu5Jwe5Lwe9II+9KIB9JIh9LIRVOUqVNUYpm4C0zCFaZrBtM3gOtfg
V8zhuhZwfUu4wXWEoRXCyBphbIMwsUWa3kCa2SHN7VEWt1CWDigrR5S1E9rGGW17G23n
grnpirF3wzjcwTq6Y508sM73Slw8S1y9cG7euLs+OHdfvIcf3vM+wcuf4B1A8HlY6htY
6hdU5h9cFhBCfBBKDHxEDAorDw4vD3lSERpRERZZ+fhZZXhUVUR0VWRM9dPY6qg4UvRz
Ukx8TWxCTdzL2vjEuhdJdQmvyYnJ5Fcp9Ulv65NTG1LSGt68b0xNp6RlUN59aErPbMrI
av74qSUzuyUrp/Xzl9bs3LacvPbcb+1f86l5BdT8wo6CH53fizoLi7uKIF3F0G4ARoPC
aTBkDxzVi0D3ojB0dAkdg+vD4vtxhH586QCBOFhaPkisGCqvHKqoGq6sHqkijZBqGTV1
o7Xk0bp6JrmBWd841kBhUZpYTc3s5hZ2SxuntZ3TRh1v7+BSO7kdXbzObl4XbaK7Z4LW
O9lD5/f28el9U339U/0D0wOD04NDgqFhwfCIcIQhZIyKGEzRKHOGOTYzxpplsWfZnDkO
eHx+nDvP5S3wJnZOTIon+WI+X8KfkkxNS6cFUgFYuCgULopEMtGMbAY8uzQ7tzQHnpfP
gxfkCwsKsVghligkkmWJdFkKXlxZ3C2TrYKXlnbL1+RgxZpip1KxrFwGryhXVtZ3rq6v
7l3bWNur3FDu3ASvr/+9sQHe2ru5uf/Pra1/7vPrz//a3t7+DRIZG3EKZW5kc3RyZWFt
CmVuZG9iagoxNjQgMCBvYmoKNzA3CmVuZG9iagoxNjUgMCBvYmoKPDwgL0xlbmd0aCAx
NjYgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDM3IC9I
ZWlnaHQKNDY0IC9Db2xvclNwYWNlIDUgMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRz
UGVyQ29tcG9uZW50IDggL0ZpbHRlcgovRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnja7J0J
XBNH/8bt9f5be9nbHm8P3x7WVqi3VavFttZaW3raaqltbYtaL7xLlaJ4FdRqPFFURERF
RMULkUMF1CAGNSgBBAlCOAJGCEfAEOb/7E6yLCEgKgKBeT6pDXtlZnbnu89vZ3aGECYm
JiYmJiYmJiYmJiYmphauylpkqIdq7sXKk4mJyVqIZwa0CpH0vK7XqfJaVNv2epHor9TB
VXammJiYGoGEYvqZQa/MJJ1JpSaVlJQU11CRSdpaVFRd4n1LTMLBddWFBIjRKlDUDJvs
nDIxMd0OD8UwFGweBSDlnsArCrTCwsICkzQiXb16Nd+kPF5qkXLrFN0mr7qumkSPf40X
frTQJIGolKICPCk5awKTnXEmJqZ6UlHgITWEAgkFBlIuUeJRguXwyuKlUqkSE7JiTmSH
HczdtzN352b1ljV565fmL3fL9/hLM9fp2qwxBX/+Vjj9l8KpI7WTf9BO/L5o3LdFY78u
Hm1fPPbL4jFfFeNPLMQqbDD950JsPGt0AXZ0d9ZI5l1dtyQfB9y5OW//TnX4IXXMiRzF
xazMTFU2LyQDXKUgRfJAUcpPpJyaUsF2UqsppiW7BpiYmOqgIrWINCIGTygMKQaBHcrA
RIXq2JFsf2+1ZF7+nAnXJnxXNPKjUvtu5Xb/03d73PDaXZW2DxsGvGT4olvFsL4VPw+q
GPtlxZQfKlxGGxZMNixzqVzvQTYsIZuWkS0rydY1ZMd6snMjCdxM9m4lQX5ktw/3JxZi
FTbwXs5t7LWYYMeFUww4yNQfDTjgLx9XfNevwr5bxYCXDbaPGF6/u7LbY4b3O+g/71r+
44e68cOKXMcXgKU7NuUdO5KbpODISbGJvCBHyBelJUUl5aTwGJNdFUxMTJSNAhjBChAD
Rgt2CxgBT0CVc7IsOMBFMzRjvyoCfADAzg9WftSxYtQnFbN+N0hcK4Gy8P1EdoKkKEi+
mlRUNEFG8KNX80hqIok7SSIOEH8vsnJu5SxHw2+fVgzuVGHzkKFrO8PQd8rHfFm8cPo1
f+/8s2c4k0lRSeNx5B33BQGS7NpgYmJsBBAARjgoIAKeCtEouHE+LnuNe/7vnxW/+2xF
9ycMPw6sgPGDwTsTzVHIGnXtKkfOPVvIommVIz+q6PWMofczFb9+WrrW/Zo8jrOUyDsM
MyCJ0qCEZI04TEyMjQilwUb4KIARzurbvmWwiBO/MwAmypQWWwJXLpN928jkEQbw/6te
5Ts2crcGRNzURjIPycTUmvEIAtCAGkwAGRBHL5517b3/Gg76k/LyVlQUej05soe82obM
/LUE5YBYG2Vy/fp1lA8zkExMrdY6IqYW2JiWlgZEZGW00jIp0HCEPBubg9KAl0bJgJDM
QDIxtVrrWFxcfO3aNbBRqVRevHgRfLDrwDVtNEnzSlMJCIw8zLERnwvxSpSGRqNBydAQ
mxlIJqbWhkdqHRFIqtXqK1euKBSKM2fOgA/7t5Ove5He7Ynzr+RwIMnNarGFkJdDQveS
2aNJ3+fJF925nkVvtzWciU1MT09HmaBkUD4oJYZHJqbWhkdEjiUlJbCOWVlZKSkp586d
i4qKAh6prlwmPiuI42ek2+Ok/0tktD35dzY5FEAuniWlJVaZZV0pSTjHAV/iSsZ+SQb+
j3R9jPw6hGz8l1xOMm4DPJ6IPo/SQJnAQKJ8YLAZHpmYWpUMBgPwWFRUlJ+fn5GRkZCQ
EBMTExoaKuBRLGUKB8blf5Px35AhnUnnB0mvZ8hXPcmEYWTBZLLeg+zxJaciOHKq0klJ
cZNlCtzOusIlA4kJ8uN6ki+YQiZ9T77pTd59Fugjn7xN/viKLJ1FDvpzSKyJPeDxaEQs
SgN2Oi8vD/G1tePR7OVQ8TghTE0u8UlhHcmaVZUpKyvTarWIItPS0uRyeXR09P79+y3i
saYQccedIod2cu+zLJxKJo8gP35AhtqSfv/lKNTxPg5Hg98iI94nvwwm474mU38kLmM4
WC1zIZ7/EN9VxHc12b6O+G/gQlrQdd827miwdoh28QUBPhZiFTbAZlvXcLtgRyAaP4dD
TRvJHXbUJ9xPAHp9niNv/oe89QDp9wKXDIeBHBXxcyDkgR1cf/XszHrlC3gMPXIKpYEy
yc3NRfnQx49WegcURg4RXpYXDxXC1BwkvNwqjKDCepQ1OR5xCnBSCgsLs7OzEUuePXv2
2LFjgYGB9cRj3SovJzkqkhRPYo6TY4c457nbh0McWLpiLnGfQeZOIH+PJX/9Tv4cxYFu
yg8czWBNEfPigy8Tv+MWYhU2wGbgIXbBjpI5HPFwKJAThz16kPuJRDlHv7KyBkg58Hjo
YGRcXBzKBCVTUFCAq9fq8IjKJVCR8pCOjERfhqKiQ4UwNZWEoVSE0QDoKwmolZST7OXW
psUjKg6qv0qlSk5Ojo2NDQsL8/f3bxA8Wq/eeqBiX1DEmTNnkpKSsrKycOlaHR4FNqKi
ocZRJKI+5uXl5eTkgPkqXhlMTS16IuggKjg7Zi+30m63jJBNiEdUHG50ncTEmJiYkJCQ
bdu2NSAes6RklYREK6sv1ZP9nmR7ZPPF457doSgNlElmZibKB9eqFeFReH0eJxdsxO0P
9W7fvn1ubm5z5sxxdXV1cXGZPXv2LKbmIRdeOC84OzhHFy9exI0MZ62kpEQgJONVU+ER
NyzcxRQKhVQqDQ4O9vX1bUA8xkn4noR2RC1eqiVD2pA+7s0Xj4G7Qk6dOoUyAR5xrVoX
HmmLGx1wCWxXq9UIDdq0afMHU7PXa6+91qtXL8QsuKPBRlJCsm63TY7HhIQEAOHgwYNb
tmxpQDzGexo7Wo/3Ey3VkWFtyBBJ88XjroDDKA2UCUrGuvAodPVHzYIDARuRhXPnzrVt
25Zd881f+/fvt7OzS01NFROSGcgWj0d8ItS14lGvIXFSEh1J4quPfaHTkiwV96VIya2N
kRK1rjHwGLAz+OTJkwhzrly5QvGo1+ut67SiZuXn58P9Xrp0CXHBAw88wK55q8DjgAED
Lly4QAmJa4+9t9VU9QhVHvcmnAJAACgAEIDHzZs3NzgevSgkHYjOEh5jvKsQyn3sSaK2
Wmy+1LPaBhGqxsYjSslaXpxBIql1pG+JXr58GXUtPDyc4dFa8NivX7/YWK7brVKpzM3N
RQhAgxeGx5aKx3gd8bHnviwIN8djerARetsjSZaSrHI0ErKouvkc5U7iZGSpA/e9jxvD
Y60yGAz0JXqEZggKEhMTz5w5c+jQIYZHa8Fjnz59IiMjz507J35vC/E1w2NLxWMcXKPS
CDqgUozHVXbcwkBRTE2X+Ciqdh8i8FDDtem8aof/MzxaFu3LqtVqYTzS0tJgHZGR3bt3
MzxaCx579+4dGhp6+vRphULRYt7bYnisC498sBwjqfJ+RjxquS/AXZFol/QgbrNVsqrd
9wvRtI6Mot6SfhHF40UMjyY80r6siKxTU1NhQo4fP759+3aGR2vBY8+ePQ8cOIDLD7c2
xNdqtRo3O+CR9X5s2XgkejKdp5lPJBlP8WiinNgN6hTmeIzTWsCjlzNZ4Gb6SEgDtthY
Ox5LS0vpGCNJSUmIrMPDw7ds2cLwaC147NGjx549e3BTw60NN7icnByGx1aBRwTH0irL
N8zThLvqvSITveuBRxZc3wiPKpUKeESMduTIkU2bNjE8Wgseu3XrFhAQEBERQV9rBR4L
CwvLysoYHls8HqFARxMe+WeP2/nWlqXhVQCkDnO/kuHx1vGo0WgyMzMTEhJoV38vL6/7
77+fXfPWgkd/f/+wsDA4/+TkZPpaK8NjK8EjAulhIjzSUBofF28Sg6Dbhn8+6VzL7qZn
laxppm48Is3ivqzr1q1jeLQWPHbt2nX79u3w/LGxscJb/wyPrQWPhKQEmIJryku5EZhC
H56i2nbXcQ8tmXtkeGzZeNy2bZuAR5VKRQdFYXhseXisv9Qqkq4kam3Tl0xNPOZklYQG
VfwzvfLrXtxM2dZ1Tg8cOMDwaF149PPzCwkJOX36tBiP7L3C1ozH5iOKx/17zqxbmjHt
J+3gTvrObSsd7Awr5lQ28zkca8Ojp6cnwyPDIxPDY0PhEYXwfoeyRdOvRR4pKCzkguuy
ssqO9xGdzsrOKcMjwyMTw2PD4vFouHTKyHzbRwxzJ5ZmZ3J4vJxUadeBm9/B9mFu7obf
h5I540nyBeNeZbpmek4ZHhkemRgeGxaP9Nmj7LRq2khd18cqV8ypOHao0mEgt0HhNW66
w9C9xHs5OX/auNfWNdwMO4M7cfMeuv5B0pKNyxtzVjKGR4ZHJobHRsMjbZpJjC+d9L0B
xQK7WIeKtNyUN2H7uNlvk+KNC9e5k073k0EdufnIXMZw0zgKGzM8MjE8MjxaOx5pxx7F
+cpbm90bBhIxeMQBbqZFpWnwjX9nc/Mqfvg6+XkQmeVI8nKMy2FNb7kDUZmuskDD8Mjw
yMTw2Nh4bPB+j7pScimBm8YRgXmOadgNt4kcNge+SkZ+SJx/42hJpcm/MTY3LOHa1lfP
L89SMTwyPDIxPFoxHms3gSQ1kUQeJts8SYHpBaGZv3BThw/8Hzd/95+jOLRS5ecSob/w
qMGV+7ZVjLHX93rGsHL+1fPnGB4ZHpkYHmt3aDpys7MgNNu3ZsrKyOUkEnWE7FhfhccJ
33LYfP8VMuJ90uXRyotx3DmNDi/4vn9pn+fLF/+dvH8/wyPDI1Nj4VFHAt3JEBvTO4DO
JF7dNFngZon1JD7e3McLX/xIjKIaDIvkVYP/tAA81qbycqK8RE6EgZOV10zPHi8lZ2xY
fqX7k+U9nipheGR4ZGoMPNK3nvGxIeOdyDATJFOaYqIq4yyxZh8bEqFsXXg0Rtlq8uZ/
Ko/srZjndP2L7vpO/2cY+k7JJIfMBc5nGB6rpAdpmm/PfoZHq8ZjPD8YYx+nqkEhfBwt
DDrROKIDViwIxyXPBdFZCtNUNW1Ior7V4TFHxWX2x4GGf2eXHwkqTElunKYZnTzY08HO
pg0vO3unAKmyabCnknpKPL3F8vT0DpDp6Sp3SaSSo6JMYodkSrXN9CQyPFo1HuN4IrkE
W16rVhnHlEiXW5iVleOVikSHk5BgEiMXjbqj52Zr5f7UkngpN1trlqk9wngcZV14NKMf
HU9ylHcVHr3k3E/Ey7hDpahbLB4JN1xPI/d71Ac7G8Ho4OjkaG9Hv3srmoA+WpmkjQW5
a7hV7vjmJuWuKrmnfZs29jJjAnWqlBSlWsfwyNQgeEzxM87tklKzBmj5ebIciYt9Vag7
xK0Kg4HO5oFwHI/BIhn3fbqk2rBmgQoS6FT153jv+uLROIAkPyYkxeN0dz5hpo9LQIvF
Y2N3C1cF83B0lJluZ3I/J/ztHJTSBHiUe3L21S1Yo9WoTdJoefTp1CkKhVqrN8ejTgag
27jLGB6ZGgSPRF2FmumeJL3aJDGm6bFsSLSSaJRkAc/J8TyOjNMo2HHtODotiZBUjYhL
IUbXhkiJl4iKq4JIhLfxmJr64VE8orhw5D5OnG9MlxkJTKdBZHi8bSJ58w7N2eLoxDqN
WsXHEhqlQhoZKZXVuKPq1LLI8ODg4PBImUorPLzWc/tp8KdOKZdhP7nSeHitUhHJ/Z2i
qx2P9p4yi88buQmt+F8Q8KjXadUpwXY8UdX4SVU1E6lRyrk0S8UJw3WLzbjEaFXIkVSh
0jI8MjzWeMhDptuIRq91M80UozPCJ1qoLXTeVZ5UOiXx8eSwKbaaZniM1xljbYpZL6lx
Wy9+atcY7c3gkd/eeGQ7kiWkSFp9ZliGx9uROpx3j/YB8prPLLSefKht72BXFenaOAk+
MyVYYlM9DHYLThEcHaDlaF+1ytFbpgh3r/rb3lNVGx4lstribvfqwbXMvUYcLqWJU/s5
2VVLmMkM888t27hJnE0rpAyPDI8WBSe21LGqsTjFNHv1qw7VJg30sRdxj0dffCRZ5UaG
2Zm7RzrtdVWQLpoxIcLNcutPXXjkp/eiRxaGJRev1TA8NoA03iaI2Tm6R1Z7sKsVVnmG
KzQaVbDEgZKNO416Ob/Szk+q1Om0KZGeHCptJBoejw4mmEqCIsP9nKug6BYgjQxwqOXx
pjG4do/U0cZpXVULNV0lkVXDo0YhDfJzx+/aOErgYIMCgnl3qw924tPi5ClXKuXBlPE2
4WrqPI1Jc3D3Cw8OCJCqrAWPZWVluCqqykqrxXVSc4OaA5JjIVbVPGAJL4bHG1QPhXF2
mAWRRjxWY5EJj9T4RXiKpil0MMfj9KDqeLSvfUqFuvGoqaJrrXisczoGhsebImSQm8jn
2TlHqnRiPDoHCwGDzo+nSwBupXp1sLenCC86zkra8eTUyejhJFIKWx0llJ2bcbY2TaS7
wLqaeKwuYwu1RTzyN2u5AwdseVVkpAyqYrjo59wi1QIe7SXSO3cGGxaPtra2SHD//v1p
ceBPgFEoHX9/fy7Lej3djGr16tV038zMTGHh0KFD8a+HhwdXCHK5uIixGcOjoCI1yaoe
SGUFmbyfJfKssjN2s0kPMvpMn3DCPVhSkz7V8eglr5VgN4VH2rbex63qyMMk4lpknMyL
4bEhH0Kq5AGSKpvnJ9eY8Ggv7kIj93YwI5tKIfWTuDk62HOOzYRHB94FCleZ1J1rPwlW
k5pW0AIe7Zwknp4SXu4SP74vT+145FFsJ4rHtTLKWBtnN2debtQv2rlLTfvaBKv01oVH
CjFHR0f6ferUqfizHS9s4+rqioWAHlwi3aaSF904LS1No9G8/PLLAjkFzGI5jgByMjxW
4Y73inGi+DnG3dSRxvTscb/QK5tvkqbhNu3CvcrEwJgaTTNVlLtJPFZxFYf1M7rTCHW1
p5qJpgTTfptmFpfhsYEomeJNn9o5BuiMeKzWw1AhwqNa5udgevhoY29f5dkoHkX+rXpX
nBvgUWwFzVbVB4+6lACKQwcHB3teDg6Atz19/GiWEmvBI42OcWFQJ0lXeXtzzWqIpqkz
VKurmR5qHcFMo6nm94V7xPbUTJrF5i0SjyhwFDvuAuJZ7bZs2VIHHkP4ZuU+9iQwnCQq
uLcLKX9C1KKWayArmEQHcP6Qm8Oaj0Xo7IR9HEi0vGqvIe6W8Fhjtta68ci9v+NIpjsa
f47ruhNUnc/80fZHkv2SavCsA4+7Ag6jNFAmFI+lpaVW8WC8sfGo05g1+BpDYztPjeAe
RRjj8YKoGSuNEbSzZ1AKdwA9F3fbNQQeLTbN1IlHcWM3bcRxC7d8fVgjHmH8hGsDWQsN
DaV/wgpSPIqDaBhL+kQRm1EbKRxKCK7xL90YRwZjGR7NGj68HM27L3pFGldxzx7dyXZR
/8YFoieKC+yqlgNWo3hjKXS/8RK5x/GmVfXCo+gz3pnEifqQ04h+VXC1nw6U36BkxHhE
yTA81iZjS25kFal0Cr6rj53EhMc2jt6m4tYrnPh14Wo9pZCNc7hpLz+6l7qR8Ugpbe9d
RXhjW7yTQif4yWAnB6cgviWoBeBReFQo4JGu2rdvnxCJY2FsbKyw1gyPtGWH7i62oy0b
jwqFQiqVBgcH+/r63rBppkjNvYQSh4+cFOmrsAY8DvE0bpCuJJoaHdS412pUpEneUkD0
wL2bU4+YAHgM3BUCPKJMcDkxPNZapJHuxidzfsFyXD9BtBWljYOfgnv2aGqBdpIESaVB
xs4yTsF6vsGD9vrxDpdJg4QePvyDyir/eefxSFTutF+7JCg8yNsvkmsqinSnjdUOfuGo
D8bmd095C8FjWlqaGR7FrdiUivhRxNpiq0kdJsUjcCEcnwbmLRuPBQUFOAWJiYkxMTE4
Kdu2bbvFAc2oe5RYfclwDjMgDBcnygQXBi5OhsdapJeJOt6YOr0E0+ZiGlxLPN2qGpKd
/ExRqy5c4lDVsTAgiP+L4lHONQ84eIvcI9Y5iPDIGVRPC3jkljtYfvZYtQt/NBFsFQFC
H0cbd9okrQ2XOIpz5Own01elpKXhsV27dvTZI7hHDSSNr2lzDFxlVFSU0KhNH0I6Ojpi
G8pS7NIa8JicnHzmzJmwsDB/f3/wwcHOUF5+s0/muad/fdytuExwAc53qkD2cd9EaeDi
zMrKsqJOuU3TNKPTpMhlkFQmV1YFDEY8yvX0EaWKvkFTfT81Fmu0Tf2QX69RKfn0iRKi
516QUWF5I6euwfEo4Ks2PGKJ+F4AGAq7Dx8+XFgIWlL3KITVENDaUns/UjyWlZUVFhZm
Z2enpKScPXv22LFjgYGBnp4bP7ZJ6/pYueu469KjpL6nRc8NKBGvtL6iMBhIbBRZMEXf
48nyT97J2rJ5/9GjR1EaKBOUDG4fDI83LyMeZVrC1IB4xJ/FxQ0/+SXtFi60xeAqgjkU
byB+9ojNausu3pLwiHsH8qjVamGtcRORy+XR0dGoTb6+vhLJyhmT13w5IKzvSzlvPXD9
q14li50rDgVwg/w3++4t9ZLyEjkcSP6dbfimT4nNQ9f7vpj37cBo1798N2/2xSWKckBp
oExyc3NRPiglhsebxSP/SNFGyvDYEHjEPXrbtm19+/ZFmU6aNOlOJ4M+bJw6dWoZL/qM
UfzUsTUIeLx+/XpRUVF+fj5tncEZQVwZEBCwcePG5cuXz58//6+//ho39q9hQ1d91G3f
gNcTuj1Z2PE/+v6vlPw8uMRtkt5nBTdv6QUZyc0iNV5Iag644GYAvBBHjh7kZgmcP1k/
akiJ3f9KOv2fvuvj2gGvJw7uETzcfv3kSW7I6bJly5Br5P3IkSMxMTEoDRAGJYObdXl5
eaU13BWa1USuKgXC7RQdQ97t4RGnb8SIEQ888MDDDz9MQ9offvihEVJC+/YIQkpa27lA
bQIeUZtwe8rKykpNTT1//nxUVNTBgwd37Njh5eUlkUgWLlzo6ur6559/TpkyBbetcePG
Of4+ccQ3bvYfrvmox86BnY8PeF3R67lc20dKX7vL0PVxHcj5WdfinwaVOI3QLZisX7uI
+HuRvVvJkT0kMoSciSYXz3ITpmRncnPwFWlJaQk3hUod1gyrysu5zbAxdsGOacncQWQn
uFlXcNggP+K/gXj+QxZOrZj8g+7nj0s+71b8foeS7k+WvXa3ofNDpb2eU/d/LWlg56iP
euz64qN1I76ZP2b0lIkTJyJHM2fO/PvvvxctWoR7AfK7fft25B0lcO7cORpZ445pLX3C
CZvnugXh0d/f/48//mjfvn3btm3vvvtuMakaB49ClN2yg+gb1ib6+DEvLw8VCvcImUx2
7NgxUAInaPPmzWvWrPn3338BEDc3NxcXl1mzZgEp06dPh/GePHkygDlhwoTx48fjVI4e
/ccvI2eM+GbOt58ttv9w9ZD3Nn/YfedA2+CBb594/804OM9+HVL6vJjR+zl1t6eu2T5a
3PnBsjf/7/ob9+nfuKfi1TYGrlPiXZVv3GvoeJ++0/16fAFv+Z6KhtfvMWAzbIxdsGO3
J6/hIH1ezHyvQyoO+/6bZwe+ffKDd0I+7B7w6Xs+4Pa3ny0Z8c3cX0bOHDNmAniOFCKd
SC3SjJQj/bDEyMvcuXORL+QOefT29kZ+QRLk/cyZM4mJiSgNtVqNkqGPfRgemRoTj8Dg
fffdZ2mAX65B5GlLeqoWPVmLnqhFj9eix2pRu1r0aC16pBY9zCs8PLz51CZUfESOiB9h
IHNzc5VKZUJCAvgQGRl5+PDhPXv2wFABHevWrVu1ahXCz8WLF7u7uy9YsGDevHlz5syB
9Zo9ezZo4+zsDIc5Y8aMabym8HLiNZEXpSgFqVhjRQJgHR0n/P7bRHzwZfToceK1wi7j
eOFQE3hN4jWZ11ReYCBSAgwiVeA5Uoh0IrUgPMzwP//8s2TJEuRl5cqVyBduAdu2bUNO
g4ODkevY2FiUQFpaWk5ODrWOKB+GR6ZGxuP8+fP79esHQsI9muHx66+/zrGk3FqkrkV5
tSi/Fl2tRZpadK0WFdSiQl7N5yE/ffecGsiioiLkCOEkyADvdPbs2VOnTh09ejQkJGTf
vn27du0CQ3x9fYFKBKGgyurVq4EXRN9wX6CNh4cHsAkzBv7gzAKeYBHlJwSrBkaBVH/x
+tOSZtYis83oSAGzTHLhhfAfvwU3OI8X6I2UAIOAOdKGFCJ2XrFiBdIMUCD9mzZt2rJl
C8gfEBCA3OFGgJwiv8i1QqFACWRlZaE0UCawjtevXzc0w+eqDI+t4NkjjAqu5DfeeAOn
TzCTI0aMYAXVyAaytLSUjsKB21B6evqlS5cuXLgQFxcnlUqjoqIiIiKOHDmCiBswgdEC
VRCKAphbt24FZ2DAAJwNGzasX78eNXHt2rUIV+E2QSTwE2j6l9cSXh4iufP6p065i0T3
WsxrKa9lvPArYDV+EQDEr4PeSAnFINKGFCKdSO2OHTvA+d27dyMXyAuuQOQLuUMekVPk
Nzk5GXlHCQAvKA2UCdhoLdaR4bHl4VFouZbL5QjHaBfuYcOGsYJqZANJCUk9JIw31yVW
qUxJSUGkiVMDeuBkwV8BJsePH4fXCgsLAzARkIIzqIBBQUF79+4FecAfCk+wCETCiaYI
9fHx2cwL/nMTr40bN26otzaahB3pNHQ+vHBkeFr8Cn4LbhC/i18PDAxESoBxYBDXG1II
f4jUIs3gIdIfHR0NbiBHyBdyB8eI2wFMI3KNYARXI2UjDautxToyPLZgPNIH4LgUsRx/
soJqfELCKeEsoHIVFhaifgEUiLUzMjLADdADZwqojI+PP3/+PIJQmUyG0xcTEwNmog4C
OJGRkSDPsWPHgCCAKDQ0FEQCl4DQQ7wO8MIFsI9XEK+99VCQSPtNwqHAPRwWxw/hhV8M
Dw/Hr4Pex3khVSdOnEAKkc7Y2FiEKkg50g+jiLwkJiaC/8gdSIJoGjcF5LqgoKC4uBjl
YHVstBY8qqQBEk/P6hOuegbJ1bdzTPFUrS0YjwxWTUhIlD+1kTgXQAQcFM6LwEmcJqAS
sefly5dTU1MBTISi8F3gzAVesGHneMGSAZ5g0WleUl4neZ3gFW0SvGhkPRRlEsWdoFO8
YnjF8sLv4tcpA5EewBwJAyWQTlxpSDNSDh7CGCMvyBHyBSrm5+eDisgvcg3TWFZWhnKw
OjZaCx5lEvuarbGm951vUeKpWhkeme4QIQVIwkmCEmAFiIGIG/SgqARJwJOcnByABY4r
MzPzCi8lL0rOFF6AJ05uIq8Eky6YFC+SvE7FW9JFXjigglcSL/wiAIifpgyE0nmBhEgn
hSFtyMvLy0NekCP4ZFARPKFUxK0BeTeYZI0nsfnjkU5J4Bys0IpmXL3dV5tFU7UyPDLd
aU4CDgInAQ2KStQ7SksghbbF0xZ82u5Pr3Ohm0EWL5zcTF5XRAKylDWUVovE26SbRI+T
wUtlUjYvoYcD7aUg9D2gMISQfuQCeaGzNSF3yKNVU9Ea8ehp8WVsvRbnkYOcTiXj4gZp
isosXtamyKT8bK5cMK7lpnzlNxBN1Vo13apSzh1CKlebx9zaFG6a1lrnhGV4ZKq/n6So
hK6bRN/ExCkr5VVskpYXpZCYn1TUfFLl3YbEXbDEPawKRSriRTEokJDCUOChGImVLeJN
cmvCo1xnKUbmhsl19vYTDyjmbJpHVa+KFC+3sacDM3LzG4qnauUH6bVxFw2k1qaNfbhp
ghidMrzaaGVtHCNVeoZHpgY0llSUmdRhCqJWk8KTiiJUcJ41pa1TFncpMQlH1lVXuUk0
PXqTDNXVUk+QteDRQRIsk9HH0nBxxikLq2YbtHMOl8mCjOMuOio4gKnp0LV2Tt4KlUoW
LBHmvNaaD3grTLcaIJNFuvNT2ti48SPa6+QOxiEcI5VKRZA7nVvWW8vwyHSHgSnQUgAm
xRSlZalJJZZUXIssbmyGRPor+hpqSbaw5eGxutw1YjzaOKcYDZ2WH3+cGyZXNE2DUapg
3h/aWcajHeUhMY1Mzu+o4G2po1+KkJhgZxuz6RQZHpluJ9AWSCgOt8W+0QyGAuvEXrGw
uup+z4jKzE+K4SkGpkX3SJuhW1gobdV4dAqQq9XcMLRKpVIYKZdSTjx1oFRinL+ArnLw
VohCcam9ZffITbcaJITMoslrjI3m9k7GaVqdnXlryfDI1DAPHoVmGuGRo0A8MdZwQi0+
dczLyxMaK2kDSk6dMnt1tObjR7O3O8VQNYvEzRpizMJthsdGf/ZoAUmUcs7BStHGRjzq
Uvz4ab/UYjza1YpH0TC8VXjU8jMlcvPGGmdp5eZpxVdnuY7hkekmgmWBh/QpIjWB1PVZ
bLOmNKO9fVJTsuNOZx8NyQ3aod6yNm/90nzJvKvuzpq5Ttf+Gl04daR23LfFv39W8ssn
pT8NKnX4QDfifd1375V926fs615lX3Qv/7InPtyfWIhV2GDkR6XYGLtgxyk/anEQN6cC
HFDidnX90qu+a/ODduRFHM6NO52TmpJD26+FxmtKUQGeAjYpMIXAXLCXDI+Ng8eac2kJ
eBQ3aguso40v1WbaUgXZWA6ua8MjdY92zXmEXobH5k9FahFRywQeUgdIMQgAXkrOOnYk
Z/tG9XK3/NljCsd8Vfxdv7JBHa/3eqai432Vbz9Q2ec5wydvVwzvXzHu64opDgaX0YaF
UwzLXCrXuZMtK0nAJnJoJwnexY3WGL6fHDvEjdx4MpxIj3EDQspOkJjj3J9YiFXYIHQv
tzF2wY6+qwgOsvzvykVTK13GGKb+aBj/TcXwARVDOlf0fd7QuW3lG/dW9nyqAokZ1rds
zJclYKnETbN9Qx5wfSmZYzjtBy509RGj0to5afUt1zVmIaxinUZKJ4Y1cU8b4GjT5ubc
I1EGOfGPJcOFtmpFkMTRUaJg7pGpTjYKYETlov3AqTmEB7ucqjq0OxcO0OmHoq96lQE+
nR+s/PjNil8GV/w91rB2EQnczKEsKZ4bq7bJx84sL+eGLk++QKJDyZ4t3DC5ruMMvw6p
+OStCtuHK3s8afiqZ/mkEcXL52oO7c5TpuVQVNK3Zqz6lRnrwiNCXCdHQQ4OzgHauvGI
78apYe3dvT2dhTdvbohHrWhmWH0KnVjRzlHCTSHr6USbuBkemepgo/AuIcBI347JysoJ
2ZfrOqHgsy7lb91f+UX3CudfDTB+MHjZmVacX5AzNor4riazHMHJijf/r3Ko7XXX8doj
+zQwlYAkSkA8GIV1NeJYbcu1ECObT9JqNneqIsjdOO+qjVOknO8GyXOvjqlajTPDCr13
NHLa1cfUe9IhSNGMgm2Gx+bJRvGAZpK51wa8rP/wdcPiPytPR5KyljtfCKxm3Eny76zK
IZ0NfV+o8F1bALAg4qYTsbEhKZqR9BqFTKbUcGGxcdp6dTAwZ3dLL2tzU8jys8g2t7cQ
GR6bVW0SD/aIMDM7O3vGKC1YcS6m1ZXGhTjyzqOV3/Ypp4S0usEeWzYe9XzLdRs7iXFU
Hp1SwptQt3BVS7oIGR6bm3VEyYONfECdlZaW9mobokxppWWSrybI/hmpcThc6xoqvIW7
R6ILdjM9cLQxRsf27uEtLLJheGxu1rG4uFiYRgEVCnzo8xzXQFzQmma1LdKS7esIP/MX
kZ9PQ2mAMCgZGmJbi4Hcvq7Sd1XFHt+yw3sKIw5nHw9POnZUumtncIsZDledIg3w9pRI
3N0lnuG3N0QkwyPTDZ0Gil2YplChUMTGxoIPcSfJxO/IO4+QHz8gG5ZwPW2uX2+BJaDX
k7NS4r2c/Pwxwmryx1dEepR0ftAQezoxPT3d6qYpjD9DbB6s/Ot3w5gv9N/1uz6oY3nP
p69T4LPRwhkemW4Wj+JJri9dunTu3LmoqCjUJqqSYhK2j8ydQOy7ARpkqC2Z6kDWe3Cd
FZMvEl2pleW3rIykKLgulBuXkuk/kc+7cJn67B3y91gSsptzj1TAY3TUeZQGyoQaSBhs
K5mmkPR6ujIt2Rhcp6dfcZ2Y2/Wxcs8VkQyPDI9MNyWDwQA8FhUVwTpmZGQkJCRIpVKc
FAGP1diiI/JYrlf2omnE8TMyuBPpdD/p+TT5qicZ+yVx/YOsmsetBTljjnN9DnOzuEbh
xhT8rTqb4/bpSI6BSMyaBWTOeM4TfvMu6d2evPkfMqgj+X0oWTCF+HuRczGWCQ88RoTH
Xrx4EXYaJYPyaf54LC3hOs+7jCGd21bOGWcAHlOSNMP66T7vWnwwKJbNNcPwyHSz1hF4
LCsr02q1iCLT0tLkcnl0dDTOjkU8WvQqwNH509z7LFtWkiV/EedfyWh78v17HDyBo473
cfZswMsclOA/sfyXwRyspv7IVeSFU8k/08liZ/LvbCKZw9F17ULOmsLaIdrFl7WLuIVY
hQ2wmfsMjszYcdpIMu5r7lDD+3OH/fhN7idsHiJv3Et6PcP9+V0/4vg5+XMUWfwn2Swh
hwJI3CmSoyL1JBzweCTkFEoDZZKbm4vyoY8fm+2pRO5sHyY/2HGPQbyXV/48yBAZouv1
jMF1QqFczqbiYnhkuhU8orRR8QsLC7Ozs1NSUs6ePXvs2LHAwMB64rE+Ki4iqnRyKYFz
nnCVxw5xLN3tQ7auIRv/5d4NhMFb6UaW/02WzuJoBgAumMx98MVjJrcQq7ABNvP8hyMn
dgzczBEPh5Ie4w4Lu4ifKGq4jr3A48EDkXFxcSgTlExBQUGzujL1ei7juLMsczEuAfm1
hcbv2sJKnL7uT1Qe2lXIZipkeGS6HTyizFH9Uf44C7GxsWFhYf7+/g2IR2vU220r9u4J
R2k0wytz0vekSzvyRXcicSUZaZZPa/j+isuXStlErgyPTLePR5Q8yj8xMTEmJubw4cM4
LwyPgbuOoDRQJpmZmRqNprS0tEmuzMpKckHGPWcQBOecl3OD08rmuWZ4ZGooPKL6Z2Rk
KBSKU6dOHTp0yNfXl+EReERpJCQkoGTAmcbH47kY7kFu7/bkoze4Jww3dVoZHhkemRoW
j0ABgHDw4MEtW7YwPAbsPEzxCMI0Gh7TkklWhvH76vlco1J66q2cVoZHhkcmhsc7ikdQ
hfbtAWdAG+MYCA0tg4EbdW2+E/ngNe5NpdTEBjitDI8Mj0x3oh4Bj5s3b2Z4BB5PnDhh
hscG7PooNDQfDuT6ZMIrXjx7B08rwyPDIxPDY3PGI4ziWSnXG+fzrly3HKoG7znP8Mjw
yMTwaF14xHXd40nyydtcZ87TkeTOvYLD8MjwyMTw2MzxmHyR65Az9ssq65h1pclOK8Mj
wyMTw2NzwOM2T+4lx/4vce+hnwhrFqeV4ZHhkYnh8c7hUZOvjzluGY+whX5rubGAqA4H
ciNyNKvTyvBodXjctm2bgMesrCyGR4bHOyGdjtxsj5yaeIyN1vV7gXuXWTzCT34u95L4
kM7cQ8WpPxJNfnPJMipRaSn3UqG4t/+6desYHq0Lj0eOHDlz5oyAx7KyMmufhL1V4FFH
At3JEBvjwNqjnEl8E43ZnCUlqzyJjzf38cIXPxKjqAbDIjmXwlWy28Lj2kXF3R6vPLiz
wsGuct+2qj45Yfu4oYTiTpHmds2a4VEqlQKPXl5eDI9WhMft27dTPCYnJwOPBQUFDI9W
gEcdGc9T8VUbMt6JDDNBMqUp5nuLkxh/vdrHhkQoGwaPp6WKnz8u+dRGn3SxFGW1YUnl
O49WvdjSbEXxqNFoMjMz6av0CNM2bdrE8GgteOzWrdvOnTvDw8NlMhkdlpnh0SrwGO/N
AaePEykyLfFx5JbENcVEwfGe3E8vCCd6HRdEZynIKkcjJBP1t4vHoMAzfZ4rn/6zNifb
2DSToqjs+7wVnFlhICZUK3gPOJDQ0NAtW7Y88MAD7LK3Cjx279599+7dR48ePXfuXGpq
ak5OTmFhIcNj88djHE8kl2DLa9UqouY5mS4n0ZEkvsZ0h0UqEh1OQoJJjLwKsIiHs1T8
n1oSLyUxUpJlmgLMeBxlXXg0o18gT8hR3lV49JJzPxEv4w6VUo/nABSP2LHT/YZP3i4f
8f718d/oXcYY/p1d2flBkii3GjxmZ2ejctFhPH19fdu0abOJqdlr8eLFHTt2PHDgQHR0
dHx8vDAms7XM6NGa8Zjix9sze5JS0y5qyRCsciQu9lWh7hC3KgwGOpsHwnE8Botk3Pfp
EjJMtCpQQQKdqv4c711fPOoU/C52RGPC43R3PmGmj0tAvfC4f09sxJHksAPZBwMKd3mX
bZZUrJhTueQvbtoCq8Aj/Aaq1eXLl1HFoqKiBg4c2J9Xnz59evXqBX/SpUuXd955x8bK
1fett6w6/ba2tjgLXbt2xRnBeenbty/OkYeHR0hIiFQqpYOi5OXlWdGER6362aO6CjXT
PUm6ptpjyVGmp3/RSqJRkgU8J8fzONJIjdSKVxOdlkTwjw2HSao8Hl0bIiVeIiquCiIR
3sZjauqHR2My7DksC0fu48T5xnSZkcA+ino9e7xz71zfUSEEQ1WiUwgh/RcuXBg0aBAq
4N69e/38/NatWyfhpkF1d3Nzc3FxmTVrlrPVymXatLOdOjlbs1D+rq6u8+bNAxJXrFix
cePGHTt2wDrC8MP2JycnZ2Zm0vngrl+/zvDY3PGIOFVFpttUEWyUG1GbuEThEy2ATMOz
lCeVTkl8PDlsiq2mGR7jdcZYm2LWS2rc1suO+zNGezN45Lc3HtmOZAkpkho9bQvGozAB
pUajSU9PHzJkCBxjREREaGhoUFDQtm3bEMF5enqiMi5btmwxLw/r1L4RIwx33bVm1iwr
TT8tfJyFlStXrl+/3sfHx9/ff//+/UePHo2JicF9TalU5uTkFBQUlJaWWtEV2JrxaHwq
KCNLHasai1N0Jjw6EJ1oMx97Efd49MVHklVuZJiduXscIqkepNtV2cUIN8utP3Xh0Y6D
Nj3yME8LazUtGo9ILSpUfn7+p59+amdnh/gaVuTUqVPh4eGHDh3avXs3LIqvry/Otbe3
t/U+pku3tSVt2si+/NJ6s4Dyx4mAq9+5cyduXocPHz5+/Pjp06flcnlKSopKpcJJ1Gq1
VjTZOsOjII2CjOed5IJIIx6rsciER2r8IjyrPOcwB3M8Tg+qjkf7qoeWFIP1xaOmiq61
4lF08BaJR1Ql1Cn4xk8++SQjIwMeMikpCZCMjY2Njo6GOYGTDA4O3s8ryDp1aOtWwz33
VLZpU/LUU0F79lhpLugpwLkICwsDGFEH4+Li4BsvXbqEa0+tVsM64vJDOMCarZs/HovU
JKt6429WkMn7WSLPKjtjN5v0IKPP9AknGj33DLNPdTx6yWsl2E3hkbat93GrOvIwSbX2
o2E8PFswHiFYR4Dxiy++0PBCgIaMpKamKhQK2BJUQPgTmEmc8Wir1aVp02Adr4wciX8v
LF1qpbnAZYazgHOBOxcFI25kly9fzszMBBuvXbtWXFxcVlbG8GgVeFzFe8U4Ufwc427q
SGN69rhf6JXNN0nTcJt24V5lYmBMjaaZKsrdJB69RD1tYvyM7jRCXe2pZqIpwbTfppnF
bWF4RCA2aNCgb775ppQXbCRqGepaVlYWbCSqHpxJYmIiUBlvzSru2lX3v//Fx8XpH3us
4IMPrDcjQCLOBc4IzktaWhrcPm5neXl5lI04g5SNLLJu/ngM4ZuV+9iTwHCSqODeLqT8
CVGLWq6BrGASHcD5Q3xfyrewpATwOzqQaHnVXkPcLeHRZPA09cMj9/6OI5nuaPw5rutO
UHU+80fbH0n2S6rBs0XiEUn94IMPhg8fjjqFNONf1C/UMsRosJGodNnZ2eAkzMkVXgCm
0gqVceIEwmrNtGn4XuDoWHnvvVdiY822ydq3r/D338Uf7fDhyrS0ZpURlD89ETgjODW5
ubn5+fkAI25qOGu40+EMVlRUMOtoHc8edcTL0bz7oldkVcv1MHeyXdS/cYHoieICu6rl
gNUo3lgK3W+8RO5xvGlVvfAo+ox3JnGiPuQ0ol8VXO2nA2/Ur9t68YgKZWdnN3LkSINJ
lJCoZRSSqHSFhYWofUAl8pVntSp2cQEer8pk+H711CnE11gi3kA9fToW1vzk5eY2w+zQ
ZyA4Lzg7FIw4X+Xl5XpezDpaV9NMkZp7CSUOHzkp0ldhDXgc4mncIF1JNDrzHbnXalRE
1xT5Vav5d3Pq8W64leKxqKjovffeGzVqlJBOM0iiuul4oeqVmFRsnTK89VZF797AfbFG
U5ybW9Gzp6FDh+KiImGDyy++WNG3L0xz88+LcC5wXnB26JNGAYzMN1pvy7WZsRxm1g5i
nbJGPMJ19OnTxxFhZo1ECpCs4KWvruvWKJnMojPUh4QIm6S99JLht9+sIjdmZ4SG0lTM
NLYcPGq5p3993BkeG1sFBQW9evX6448/6nPSBRmsV0ePVs6cWTl7tuH330FFw6hRhqVL
DStWGE6eFDYp++efykcfNZSXW0uexKeG0akF4lHPDShR2/ARDI93SBqNplu3bpMmTWqN
F3F8POcbQ0IsXIyrVxtd5dChZOpU48fRkTD4MDUJHluKrAiP+fn5Xbp0mTZtWus9W8HB
5Pr1mouVL79sMQAn7FEeE8NjK8CjWq3u3Lnzn3/+yS5mJiaGR4ZHQTk5OZ06dfr777/Z
lXwDlZRwH2YamRgeWwces7OzO3bsOG/ePHYZEzc3olJZXrVvn14cVg8fzh48MjE8tmw8
ZmZmvvrqq4sWLWLXMMnK4rjn5WXh8g4N5Va1awdIkqgojo348+WXWZkx3SweMzIyEhIS
Tp06BTz6+PgwPDZbPCI9HTp0WLJkCbuAOWk05K67yMaNNddwTTNDh1ZbJJdzhMzMZMXG
VB880lH3NRqNGI9btmxheAQeURp0KHvgkQ5G2uQJUyqVr7zyikQiYVdvlcLDSXFxzcUJ
8I2xsWYXPIfHtDRWZky3gEc6ITLDo4BHhUIh4BFl1bSpSk1NffHFF1etWsUu3fqIwyMC
arEARuYemW4Jj3S++ODg4K1btzI8Bu46gtJAmaBkmgMeL1269N///nfdunXsuq2nyry9
ORj278/F1ACjh4fxUSQT083g8dq1ayqVKikpic4Xv23bNuCxNTfxIfsB/hEojcTERJQM
yqdp8YhT8/zzz2+09ISNiSxbRhS1zKxGkSh8bG1JM3hCwmRdeCwoKAAE6HzxYWFh/v7+
vZ8rGPCyIT+31ZXJtatkntP1zg9eDw0NRWmAS1lZWcAjnemjaYLEhIRnn33Wx8eHXbGW
dffdxNW11rXgIaJpfLRaVlRMN4vHsrKywsLC7OzslJQUOl98YGDg+vUbvuh3DpT4+WPd
Lm/S4jmpySd7fMlo+7LOD+q/HZC0fdueo0ePxsXFoUxQMrh9NBUe4+Pj27dv7+fnxy7X
WvXQQ2Tu3Ko/EVNTWq5ezb1hLbxtzd65ZrpJPHIDm5SVFRUVqdXqtLQ0VMYTJ04cOHBg
69atq1evnvP30uFDd37w1oW3Hyzr/azuj69KvRaTyMMkN8vq856XQ6JDycalZOJ3ur4v
6N5uWz6oc/LILw8s8fDy9fVFCURHR6M0UCYoGa1Wi1JqfDyeO3fumWeegZln12pdOnGC
5OcLf2UgguY7N7J3rpluU8Dj9evXgcf8/PyMjIzExMTTp08jrgwICNi0adPy5csXLFjw
119/TZ485acRbp+9723XObxfhzTbR0re/I/+wzeKf/mkxG2ifstKcjiQxJ0kmUqLYwM0
mRBXqdLJWSkJ2U18V5P5TvpfPy0Z9GZxp/v1nR8u7fdK+ge2xz+38/1tpLuz81/z589H
fjdu3Lhz584jR47ExMTQdhmUTHFxcXl5eSN3eoR3ffrpp+HkxQtBaXbR3qYnYGXAVH8D
SeeLv3btWlZWVmpq6vnz52EgDx06tGPHjg0bNkgkkn/++cfV1dXZ2XnKlCmTJk2aMGHC
2LFjfx01afhX8z8fuPajHv4DOx8d8PrFd/+reuexojfurXjz//Q9ntJ98HrJV72KgaMZ
P5ctcTasnk82LSPb15G9W8mRPSQyhJyJJhfPkkQ5Sb5IUhOJMoVkpJGsK5w1RSx/NY/7
kpXBIRerLidxm2Fj7CI7QaKOcAcJ8iM71nOHXbOALP3L8Oeost+Glnzdu/jDN0p6Pq0D
A9+4p+KddkXv/jd7wOsJA22Of9QjwP6D9d9/ufD3X6eMHz8eeZk6deqff/75999/L1q0
CDlFfrdv3468wzrCudHIWqPR0Gk0GxOPsbGxTz31VFCQMBEFgYNtwyuNddur57Xt4cG9
LFPdDOhZxx6mm8GjXq+HJ0Hty8vLg1lKSkqSyWTHjx8/ePAgPOTmzZvXrl27bNkyQHLe
vHkgyaxZs4CU6dOnT5s2bfLkyU5OThMnTgRtxo0b98cff4wZM+a3XyeNHPHn91/N++qT
JZ8P9BzcZ8sHXQMG2h4Y2Dl84Nsn338zDrDq1yGlz4sZvZ/P6dE+r+czV7s/fa3rEwVd
H9d2aVcEa9r5oVKbh0vx5Z12xV0e03Z7srDbU9ewWc/2edilz4uZ73VIxUHef/Os3Vsn
ucPaHvywW+DH7/p+PnDd10P+BbdHjnD+7VcnpAepQtqAdMAQqQUPZ8yYgfTDEoP5yBHy
9e+//yKPyCl8I8Jq5P3MmTMw0leuXEGZFBYWNvIM7KdOnXryySeREnG9BhhxalrdBarV
cj1z6g6QN20iUmnNXbl+jyBk9auddQtnuik8ouIjcqQz2eXm5qanpyOoBB+ioqJCQkL2
7t0LQ+Xj47N+/fpVq1bBYi1dutTd3R12C2xxc3MDZFxcXGbPng3gADszZ84Ef6bxmsLL
iddEk8bzGsfrD5PGijSG19gaoqwTNIEXDjiJ12ReU3nhp0FvpMSZF3iOFM6ZM2fu3LmI
oBcuXOjh4YFcIJRevXo18gUwIo979uxBfiMjI+HcEhISlEplTk4OTDWsI8qn0fAI6w7f
ePjwYfFCf39/5It+h5t1dHQcOnRoawi0uQeJdDxbV9eqD4pCfC5efJGMGlVtN7UavlEt
dHqMjeU+cJI4DnOPTDeDRzpPE22gofPFgwzwTmfPnpVKpbBSgAacTGBgIMJtX19foBJB
6Lp169asWQNgrlixApwBbRYvXgxswoyBP/N5ufGaw0ugKAUpRNn1p0gzaxFd6yzSLF44
FI4JQ0vRB83jtWDBAqQBAEd6kCqYQ6QQYEdqkWZPT8+NGzcCicgLqIh87d+//8iRI8eO
HUN+EVPj7oASoGE1yoTOpNk40yGhtOEbQ0NDzZYD47a2tmq1GlSEjRw+fDj+fLkVjK7A
Na8AcXXrzTfJb7+JF+QBoRYbZfCp7ieZmOppIOl88WACPCTiykuXLl28eDEuLu706dPR
0dGgB6ptcHAwYAJLCarA0gAvfn5+4MyWLVu8vb2BHS8vL/gxIAggQqWm/KQIhRCkA6RL
liwBtTxMolCtQ+4mYePFJuE4y3hJeOEnVq5ciV9cywv0RkooBsFzJG/r1q1ILcJnpBzp
Ry4OHTqEHB09ehQ+OSYmBreDCxcupKSkwD/jHoFyQGnQGdgbxzpGRESAjfhXHFOjVAnX
xqRv164dwAjfSE0jluDPFj8pCeceb4jHuDiSkWF2TaOAUugIZrivocToh7VZM908HukT
SEpI+CVElDAqKpUKoAAu4CTlcjnogagT/grRHyJQUCU8PBx4gbcEZ2AvAZygoCCQZ/fu
3bt27QKIwE8Yzm3btgGhoNMWXoDVZl6bqgso28DLS6SNJgmbefPyMcmXF46PXwH98IsB
AQH4daQBKUF69u3bd/DgQaQQ4SpSizSD80g/gI+8IEfgf3x8PBwjcgrTiFwj73QSdjrR
cOPMwI60gY1ImHhhUlISGOhhyfAA6a3BPRobUwBJxMi0dzc+9Xx4iIAaUTYTUwMRks4X
X1JSUlhYCPuUl5eHGDMjIwPcSE1NRW0FRmApz58/jyAUYDlz5gy8JThz8uRJYBPMQQUH
fwBPuKCwsDDUesSth3kd4nXApH28gm5S+006yCuYVwgvSj8Iv44oFSkBQ5CkU6dOIYVI
J4UhOI/0wygiL8nJyZSKcMvIKcCIXCPvxcXFKIdGYyOyADaiAIUltJ0aoXT//v3xBa5Y
OFPIFO4CWIiktvgrs4K+N33LfRdhIwXriE9JCWuXYbplQtJJkKmNBCJQSQsKCq5evQpO
It6EswIqYSnBk8uXLwMswAuYmcALwIENO2cSQCSTycBPQAloQvQKRoFUJ02KNinqZnTC
JBwBR4sxCb+C38IvnuWFBICBML1IFXgOEsIDX7p0CWlGytPS0pAL5CUrKwv5olRETpFf
5Bp5RwArTDd8p0sed4qnnnpKWr3tVdyBB18EQiKpiLKHDx+ubx3vDnPPHtu146wj7gWw
gsJHrN27udm4aoqO7ljzw167ZrptSMJJghKUk4i4C3gBI/n5+aAl6inAArxkZmZe4aU0
CfyB1UzhlcwrkRcYJYBUEIgqN+l8LaJrsaWw10VeCpOSeF3ilcqLMhCJSecFEiKdFIa5
ublIP5iPvCCIhlcEFWGYKRVxa0DehamH73SB7927F2yMrT4sIeVh9YouxxL6HLJVicOj
2aBkNdW3Lxk0yPK+iMpjY7kmbEdH4u+vp23ZTEy3DUnAQeAkoEFRCYxQWlJjKTCTYhNS
8wKCcniBSPCcmbyuiEQt6C0o3SR6nAxeKl74LQTIuSbl8brK6xovJLWQF9KPXCAvOl7I
HfLYmFSk2rVr19NPPw2bbbYcBQgYmvXbsbW1bYWE1E6dyrlHBMV16KOPyODBNa9hrakP
Tx7YiA8h12FBmXtkujOohK6bVMYLbCnlVWyS1iRQqEAk0AkIpbCi/pNKbUmUb+pahL0o
igUHaEY/gYECBgUSUhgKPBQjsZFbgf39/Z955hl4Y/FCAYmIoB35Gi1o6NChuMXUxGbL
VokwItnQoVyfHDrEhNmwEklJxFKHec408ssro6K4I/C7aE0LmZjuEC0pMAVmUocpJicF
EXWbUJFJYs8pYFMsAaFUGpPE29AdBQzSB4ZUNEamv45k0PToTTKI1LRdYrZu3dq+ffsL
Fy5U2aTq7wwi8bRphj5jXL16tSs/Cs3w4cM9WlPPvdsZViKLdgJPSjI2fyOsBlpZt3Cm
pnhcSTkpDsbF9hLgqukqzcB4Q1l0ibShWaBiTYvYfKhItXnz5ueeey4hIUFYYvGdQaSc
BtSUkzTltKcou+rqIxQgZyD520q5v7+Rq+zZI1Mjhtti9wgiCaZRHGubPaUUx9dCKF0f
CfG1EFnXZCa1qSUm0dYW2uBCRdujG/MZo1gbN2584YUXzEhYxzuDZulsbcE1veBu0Dnn
6FGybduNj0P3ZWK6YzG1gEQhjhZgKDhDIUYWHiRmZ2dn8aJdg4QGmpSUlNOnT0dFRUVE
RBw+fHj//v27d++mry5u2rSJvveHP7EQq7ABNouOjsYuycnJ9AiZmZm0XSabF+2lQx9O
UnJSbNIA3Kx5WozKxnGVnp6eYOOlS5fMlt/wnUE4xtDQUKySy+Wt68qrT+ec774jnTpZ
3h1xtPhu0tpKj6kRY2cxEmn7NchDYSj4QDEDAbHw8HAfH5/58+ePHTsWtf6TTz7p06dP
p06dnn322QceeODee+9t3749iNGhQ4eOHTva2Nh0794dG7z//vuDBg36+OOP8QV/YiFW
YQNsho2x73333Yfd8eXNN9989913cdjvv/8ePzFv3jxAFRQFgmiLNmUmEkYNZ209eYQY
/M5xctWqVS+99NLly5cthoF1vDOI71ju6uraCgd7rFfnnF9+IW+/XStaTUisegLJxNSg
ETR9m4a+ckiRSM0h7bpD+4rDBHp5eU2bNu3LL78E0MA9QAxAGDBgwM8//wxCrlmzBlFk
WFhYXFwctsehbieF4DMIfPbsWRB4586dMGYLFy785Zdf7Ozs4LsA3meeeaZbt2729vZT
pkxZv349kketJtJM7SVFJXWVtB3nzvXtWb58+SuvvKJUKsVI7N+/P1yi1tIcKK3kncEb
XoT16pyTkUHOnrWM1qFDLQCzFbxtxNQ4dpE+ThSoCLBQi0jnxYZVGzduHKo5zA+83Ecf
fTR16lTYxWPHjgEFTTi1H/gGeEZGRiI8nzFjBozo888//8gjj/Tr1++PP/5A5K5QKCgq
aRgutO+YmckGSczixYvhe5Ee8UKYQ5QVbKH4BZnW9s7gDXU7nXMutWtn1kjNxntkahA2
0lcLKRjpe4WgIh2kIiQkBH4M/hDh7XvvvffXX3/t27dPbQ3v/iMXBw8edHFxgcNE4rt2
7erk5HT48GGBk8gp8itAskEIuWjRotdeew0/YVbO/U1RHn2oSAnZ2t4ZvKFup3MONxyu
qcHLWOzYi+GR6VbZSE2j2DECGkAHwtKYmJiZM2e++uqrcIkwYAhpgRHrzSyi6aNHj06a
NOnFF19EGDt9+vTTp08LkKROUgi3b/mBpJub2xtvvJGdnS3+XVdXV29vb1fR3KOUkJms
P14N1atzTlwcMQ3ZIZaxSzkAC6sJJAo9zNl0M0w3z0b6pFEY1owO/Ig6ixD1+++/h6v5
6aefTp061fLyfubMmd9+++2xxx4bNmwYMotcw2cKgz3eMiGxV6dOnXA0cWUHBkFj2ptR
vDEcOCNk3aDk2qB1Ogudc2ARH37Y4k4Vjo7V2rvhJ9kjC6ZbjamFQXHBh6ysrMuXLyP8
fPzxx//8889r16617ELAHQGO7oknnkA4jFgYNhLmWRgO92ajbGdnZ+AuLy9PvNDDw4MO
vENfijF7bRAekk1EaEG0tVr40BFuxfr7b/Loo3VxlY4SaakJjImpnmE1OEDZCDKAD2Dj
559/3r9///T09NZTFAiEYfneffddGDkxIW/KQCJUf+edd/JFky9jd5hG+t60sKQmIZnM
pMPdBEh8+WXi7Q2HzbGRmkCxUM4nT1b9iS3pgwvsS9/RFn/M3tdmYqqHdUTcR583wjeC
jampqXPmzOnQoUMTtj43lQAuwG3ChAkoB5TGzU43A7/dtWvXmu3OU6dONRtyh8bajJB1
iGt9Fj2k5ZSUVHfzCjf/At8n6nbe12ZiEvCIii/Mdp2Tk5OWlnbhwoW2bdsmtdaxTbKy
shBlJyYmCpMV1gePKMlx48b17NmzoKDA4gaUkOIIGt9tbW0rmZ+pA4/VScidhdrxyJXk
0KFGfwi3yV6TYbptPIqnur5y5QqdyLU1d71DQI3snzx5Mj09vZ5TXWPVmDFjEJVj4zqO
TDs6lrCXf+una7DWFrt2i09EaipZtEiAJ/egkn/MWHOe61aroKCgTZs24RZ/OwfJzMz0
8PCo+Upsa8AjgADPk52djbD6/PnzUVFRqMXjx49vnZfTsGHDkP3o6OiUlBSUCUoGQEMp
1YZH1Mpff/21b9++9XkViBGy/iqjc81Q0OF7//7GANnfn/uT9udZvpxbwt+VjC/aDB+O
yqykX9Tqqjm86j+NV4ur47g+33vvveLi4ls7glQqffLJJ4MtTlrRoiVE1vn5+RkZGbCO
p0+fPnLkCKrw008/7e7u3toKZO7cubTjzdGjR1EasNMoGVxXKCWLeEQB/vTTTwMGDKg/
8YYPH96fvfxbz+C6thmrhQeJ69eTu+4SGqZrnb2rpT97XLZsWUxMzJ0gZN1sRNQpkUhO
ilvHWhYey8vLYXvUarVSqbxw4cKJEycOHDgAPmRlZfXs2RMVXyaTtYbKKJfLP/744y5d
uiCgbtu2Le4R8fHxKBP8iWugrKysJh4Rcf/www8ffPCBVXeSb85X5w0+hHv9nhvTTCy9
nmg0KtonHPcsjabap4UqPT395ZdfXrFiRcMSsm42IuLu0KHD0qVLW6rrRgVHxS8sLMzJ
yUFkffbs2WPHju3evZv2WwY516xZ8/zzz3/++edgpqEl3nlRCCEhId9880379u1xC9bp
dFgIPB48ePDcuXMoExpf08eP1Wuh/rvvvhs0aBDdhelOnBqu5ZrelRBQw0za2ta3ByPi
6Fb2BKPBCdma2SjgEbUb1R9eMTk5GUYxLCyMjoogbAZIenl59e7d+4UXXpg0aRKizpbR
2BoVFTV16tRXXnmlW7duuAuIKffAAw8EBQWdOXMGZYKSqYlHsBFEHTJkCOvLfed0lXZ0
rKzkxjVinXMal5CtnI1meFSpVElJSadPn4aV2rZtm9lbb1QJCQnz5s0DTB5//HF7e3uc
BbhNKxo/Ae73/Pnza9eu/eqrr5544glbW1tXV1eLY8wCj7DQKI3ExESUzLVr18R4xP0C
2f/ss8/whVXJOyeu9RmmkRAt7R/O968gZiP2qNXExYUId65W3y28PoQcNWpU//796yAk
Y6MYj6j+yLJCoUCxoEx8fX0t4lFQbm7u9u3bHR0dO3Xq9OCDD6KoJ06cCIeJ3W+5dexO
qKSkBIjbtGnT5MmT33//fSS1Y8eOuHtu3boVnrCOHYHHXbt2ITsoE5TM1atXS0tLKR5h
F4cOHfrll1/eZk8JphuKa5rhb16XaFhtcVCyXbu4JRcv0r9Yt/DbJyRjoxkeNRoNHcIR
JXPo0KEtW7bUjUexcEOPiIhAcf38888wlkAQjBm+IPacNm3a6tWrDx48CA+mVqvv0Ds4
OCwODuuLE4oYecaMGd9++22PHj1wipGYLl26/Pjjjx4eHmFhYbV12K4Nj6dOnQIeZ8+e
/d///pemH2X1ySef4PhszLFGUBpYBzBS6xgayi2i/R7FY3ccOsQtUSjqecWzKLtuQjI2
1oFHAAE0uyk8WvSWMTExO3bs+Oeff0aPHv3xxx/Ds6HM77777kcfffSVV17p3r37oEGD
hg8fPmHCBPi6mTNnuri4IGx3d3dftmwZiAojunHjRrAOf2IhVmEDbIaNscuIESMGDx4M
AOJMtWvX7p577sHB33jjjY8++giGduHChXC2yEhOTs4tZwF4DAgIwEEuXrzYvn17/AQI
iWsDP/H999+3wnctm0YajV4YbEd4ZcZsHHV4+CNHLFzbHh4kKsrs0Yq+NU3kekNC8k8m
1GbtrWlpabV1w2hVbLxzeKxDiOJTU1MR8B4+fNjPz2/VqlUo7UWLFs2dO3fWrFnTp0+f
NGnS2LFjEf/+9ttvY8aMwZ9YiFXYAJthY+yC0BgWFwROSUlByu9EOxHwuHPnzpMnT65c
uRIWFKVx7733vvDCC8OGDTOwdoHGFEpb3Bun3u8J1nxrphWOFl4fQtZTrY2NxPTKTElJ
ydWrV69cuQKnBCAAjz4+PncIj9YiAY+vvvpqG5PgIfEnm+aguUuthm9U04FzgdPYWO4D
J0nHHm9lg2qigjfIoFs4SP2fTbVsPG7evJnhEXhEmI8vbUS67777/ve//7X40S+tSYgE
Z80iolfd81xda31lhr2FzcTw2EB4fOedd9pUF6Ule2O6GUkq5bh3+LD4soZnShHGzi0r
M37YU5FalJWVFRQUxMqB4bH+eFyyZMl//vMfAYwPPvjgY4895u7ufptT0DI1sOLjq9q1
xUJATWeIw70MH8bG2rVmzZpHHnmElQPDY/3x2LNnz7vuuos6xtdff33Lli0WX7tmanod
OUIs9kHdt898IgZ2+hgeGR5vW//3f/9HW6v79eu3Z88elE/dY5oxNbtrG36S9gjat49r
l6HvJ5p1CmJieGR4vHndf//9gwcPDgwMRJmgZBgerU7cWzMWh9Jl00FawuPDtcz2yPDI
8GgxuKYdexgem/9FzL1kXQN6XL/H2Fizq7219Xusj3Btd+vWbeTIkawoGB4ZHluaVCoO
ehs2WMAjAmqxAEbmHmsINX3GjBnswmZ4ZHhsgdJouNHCN20yW2yciIH2DAcYPTwsTALL
RMjbb7/9wgsvbNiwgb0qy/DI8NgCdfQosThOFEWi8LG1JWwgEUuKiYmxs7N7/fXXWe9H
hkeGx1Yk8JBOwlXPMcZbKwf8/f2feOKJ7777jpUGwyPDY6tQbGwrHA735q330a5du3bv
3j0sLIyVBsMjw2NL05IlJCHBbFlxbW9es9dnqgs1fe3atawcGB4ZHlum7rrLOIGCSFy/
x/792cPGGyoiIqJLly49evQIDw83v8UUF7fCua1vH48qaYBE4ilV1bz2NMHeEk8/qbVP
3cfwaE166CHi5mYBjwilmerHgR07djzxxBPD+a5QuM6PHz/+3Xff0QFYjh07xvB4U3iU
SeyxgY1bpNlyrdyTG77BRmLtQyIyPFqTTp0iV6+aLbvu4cF142HusR46ffr0wIEDX3vt
tT179uBPiUSCSnz33Xfj34cffji05nAfDI914lHu6cAPY2Mvq9YeqA9ysuEW23laezNh
C8ZjZevQ9VWr6MPGyk8/rZwyxfj5/fdKg8Hi9q2WjW+++ebzzz/v5eUl9HvUarXe3t5d
u3ZFLXjooYcYHm8Vj20c/URTIGmk9nSpfTU8apRyaWSkVCpTaavfyvVahQxrsEqh0ddj
OdHjSOHBwcHhkQqluT9Vc78ilcn5XXQalUqtr08aWgEekWaDSXpe11uB0l56yWLTzPWy
spob602ipdSqaIn6+uGHH8pkspqrLl++vGLFilY769zt47GNjbPStFDh59jGHI9qPyc7
8XCybkEpdIUuJci+2kCzdkEpujqW61WR1JkKsnEKsPwrNo7OXOrspNobpKHF45FWdrgC
ikQdL2SkyCQtr0IrV+mKFcVhYTe7F807LYfi4mJaOAIqadG1Bgjg8li7du2zzz47bNiw
5ORk9qihIfAIhtk7O3Ekc4/kBx0lKjf84eDm5iAE1/pgnmg2Tp5ypVIe7MlDyiac21zt
zq9xD4hUqpRSP2f+D2nty/VBPHodPMPVWlhDmZt9FQDl3pTVjkHcz4SbKOrAB/51pKGF
41GwixSMlIrXeGk0mjxeubm5OdaviueeKx0x4mb3Qt7VajUKIT8/HwWCYikoKEARlZaW
lpWVodzAjdYz7VpCQkKPHj169+7NqNhAeHSUKoI52th7g0NaGdco4x4u5ywkj0e9Msgs
0NZEunPmDTjVyXnaOclN63S4kev0tS4nRBkZ4OkXLhwqhUeiJ7edihI1SGhG19IYn3su
WlcaGhqPq1evxpE9PDwonfv374+F/v7++P7yyy8nJSWZlbzF01HH08JbCKiRYNR01HfU
emShU6dOL7zwwvMtTpfuvde3bdvbPAhKBmcqNDQUxhLnuoyPwVsDIbOysn799dcnn3wS
l25tU7gyPN6Ce5TrdQE8zoJU2nDO6Dko9Fo/eyMeKTC58NvNmZcbNXl2nBvUBZkCcQcn
94BwqcrIr9qWm2ipTgkP8HZ2dLDjLaJEpsHP2Js3Bmm97Y14rDMNDYxHb29vmnJ8cXR0
FGL5qVOn0i+0ogn8hEBUum9mZma7du3oQmwAnO7btw/LUUmBWWH7tHoPxkVjauyOZOMO
A3eEn8ARlC1RqkOHMmJibv84Li4uEyZMgJmEk6ThNiVky34Uiati8uTJrW0WwkbAo0wH
p8b1AbCx43DF9/PReZvwqEsJoChycHCw5+Xg4Ihvpkd/2nBvZ/HTRM9IVV3LNXJ3R9Mj
RBvjF4pHnnjuGkt4vFEaGt49xprGGKQp1PKv+sI64jt2x1oKQIR1FKH4guV0Y6yFexEg
iR2HDh2K71FRUQAj5Wc9TysqNao2zAC8ENiIWPLSJZise9k1X4cWLFgwduxY3EcQcQMX
ICTuLy0ej66urk888cTo0aNhI9k10JB45Kq+0tnEMT+FDmjyrHKPHDndbvCYT6dKkUr4
Z5ht7MS9Jc2WU+K1sXOURCo4Wiq4n+HxqJPz7TDuop9Ru9sJ7rE+aWhIPArmDd9dTa9y
UOeGf6l1zDQNOUgnr6G2U1hIWUrxCBsp2E66ff3xiI1pTJ2bmwtrFB8fz/B4Qzz+9ttv
qampKpUKHpJr9CktxV2mxcfXuIHOmDHjoYcemj17NrsMGhSPREFbRmwooLSCeyTqcN4E
OilMr9DoUoKdHJyCFNwzwQCJu5/RLnLHcKAYrG05pW4bO5nx+aLSzc7kHk2tNu7hxr2U
wW5VfTLrSEND4xEwfNk0lQk2M4ud8ScW4iD0VoItQUVa78RcFdBK8YgQm24PGxlbfezr
G55WVG1YILAxIyMDyI2JiWF4vCEef/rpJ5xxEDI7OxuEhPlvDQYSOnfu3FNPPTV37lx2
GTQUHo09Z/Q6RIgaY3/CKvcIRbrThmIHv3CpNJgaQL49RSejK9z9gqWRQc72lGHB+tqW
m9yjk2eQXBbsbAqyPWnjNG1/adPG0c1T4mbqcWSid61paGg8vsxLjEcP06TzFI8UhtQu
Ck8acUwzPFKEYhvhzi48yRxqNnlK7ae1vLwcsSEqOH4alR3WMTIykuHxhngcMWLEmTNn
EhMTcdJxZ4GB1Ol0LR6Pp0+fxtV15MgRQ9OpGfbPvz08OsgtvFmt9XMQN5RowyWO4j6H
zn5GA6iSeos7I9o5eir1dS1Xy7xtqno8eocHcBbRLdjoGHXKcCc743pJsNSP68xjonft
aWhYPNra2prhkTaviPEIKyJEarRRG76OBtdC51v6fJLG2vhR4fjDhw8XB9p1CNUZeITz
ycvLS09PR2VHlT98+DDD4w3xOGzYsBMnTuBugntKVlYW7k0t8mVS8ZsCuFpWrlzZtm1b
oZN8eePKrH9+Ba/m0D+/cUbs0WvVKkhZ84UVHVaouf+09Vqu06iUyhob61UKuTyFf2xp
RIxWwhHWUUzv2tNgWf/5z3/g2dzd3bdv3y6VSnNycurjHtuZxuqnAbLQ0CyXyynZ6LNE
HArfaYs2KiCYScNtfKdspPvSgyAZ+ALW0X3rk3hcXfA8NLK+fPnyhQsXkAWw+p577mEM
rBuPX3/9dUREBO4mly5dysjIQL2ACUe1rbue4h5nLa+WCD2+KI5oZ/jly5c//PDDTfWa
QG398yktmxCSLWJAM4077yiDKCGJXubtxEfaAbdzvQKPAwcO7Nu371tvvfXMM88ALI8/
/ninTp0++OADBweH6dOnL1261M/PD1UpISHh2rVrQnmKY2ThT5x9EJJwk0GliX2so2lI
GWovqVxdXQW0insBiZvF64lH+B9U8/Pnz0dFRe3atYvh8YZ4/OKLL0JDQxFswnLDeMN+
o87C4dRRQ2nHA9q1FREBPdHNHIy4PGhvWFwkuHqXLFny0EMPIbNqtVr8pkD2nVHN/vmQ
xf75wntMTQLJljHeoyrSUwi7jQG2nZvi9gbFMAuuceKUSmVcXBxCVB8fn3/++cfJyen7
778fMGDAG2+88cgjjwCnqCC9e/dG/Ro7duzcuXPXr18PwwagwYSYWQtchOChEDiDhLgq
BPOLteKGbCzM5HXDsJq+DUfxiEsLlxn8Murs2bNnjx49ChvM8HhDPH7++efBwcGnTp3C
ecd5wbm4IR4Fwy+oXfOb8It2ZsDlgbxQMOLywFWNzC5atKhbt2733nvv1yJ91Vj6urq+
/fZb1J2AgADa+5RCEmmmQXcjE7LFDIer1yrDA7wlEgnCYb9g2e2PF3Szzx5xm0tNTT1x
4kRgYOCqVatmz57966+/fvrpp127dn3uuedw7T355JNvv/32Rx999OOPP86YMePff/8F
r0AthULx888/CzxEoF3//o1m8vTkbhPr1q2j3oB2BYe5RagIR7Rt2zaGxxvicejQofv3
78d5vHDhAk4oXA2cf914pM+EbW1tsSVuYfiCP2Ej6XLcNOvf5eDOibKRviYAb4brGZHF
mDFjXnrppV9++QUVx83NbXMzkLe39+jRo1977bXu3bvj6kU6kVr6EhMlJMNjc1DDvnON
WoOKhiAX5hNli/v1pEmThg0b1r9//9dffx1xzV133SW2H3/99ZeXlxfqKciGi6SeV8Xg
wYOxL4722GOPIfaHdYRxBR5pb/OtW7cyPN4Qj0OGDAkKCoqKiqKtMwj96sYjbYMTN5kJ
L08BjEKXA22TTgRGqzlygWsYlowGL4h0+vTpA3vWDE8Ekor7FFKIqofUIs1IOfWQjWkg
GR4bB483FMwe6iN4uGHDhpUrVwKPo0aNQlXt0qXLs88+C6w99dRTNjY2gwYNGjly5MyZ
M5ctW7Zjx45jx44hdi4sLKQHsbGpetnowQcfRMgPEyuTySget2zZwvBYHzzu3bsXeJTL
5fXBI32YPHXqVGEJRaLQ5ZX2XKVPklHTqbdEgODq6to4vc1pWE1jajgxpAHXM0IMRDTi
fhHN8GkA6I1SooREymmU3ZghNsNjM8HjDc0n6unZs2eDg4NhThYuXDhx4sRvv/32vffe
e/XVV2EXkdoOHTrgi9lDMCwHJ8eOHXvgwAGGx3ricc+ePZGRkbD6/9/emcA5VZ39n1oX
FEHgba0LWqqvdakOtnaxVmmn9a1WqGO1tS86/duFjrsO4jYoIqMvOiDiYNEoQlQYtiCQ
AQkKEQxbAMMSlrAEJ+CEgYABAhggMPn/7n1uzpzc7MPMkOX5fSzNZLn3nHPP+Z7nOec5
52zZsgXFjt5HDsfSicIPxEBxOLKYVPwp45E+gtNNkEwzTOvEKw+51eD8nj174FMgX3fd
dZcAeNZq9uzZv/zlL5FaWsREIfo0TcN4ZDymr4MHD6IWnX766e3iqX379viX8ZgOHn/w
gx+8+uqr6eNRB0MyJmXy0Kp5XIFm3ESsAmFTt49TK5mOtPre7/fv2LEDJjEM48svv/yL
L77I8seBRocen8x4ikGlNZ5tZkAyHvMDj2E1jgj0E0jE644dO5522mnXXXfdE088AWeK
8ZgOHn/4wx9269bt3HPPve++++BlJ8cjEY+OryJRUBbFIYQj4a+wFWWWivVQYCO5t7g+
rNDu3buDpfDrW8OzpjUCqMkul2v58uUXXHDBl19+mf1PBMWF1CLNSDnSTwMdjEfGY6Zy
u914ZJ06dQISr7jiiieffBIONZoA0o8K9sknnzAe03euUf/79u178cUXA1koSYfDEReP
qA/gobzLnM6YpOUAkydPpj+BTTFrI8b9xH5NcuArENoihqW8+r6hoQGVZPXq1Z9//vn5
55+fK3hEf4E0I+VIP41AtlkzbHU8Bj2mKrHar6i0wuD0hRiPrSFYIM8///y0adP27t2r
e6aMx0zxKJxrlNtjjz0Ge/LKK68cPHhwcmQR/cqk02NpmoYWSVHNwQtyt8UyUvqOmNwR
m5BQ8OQJzubQ6nuqDF6vd+PGjTRPl0N4RGqRZqQc6admmDzOKmfwqG39DS6WlJWXl2iQ
LHdrgAx63W6PL8h4bO1nynhsNh6Fc71o0aLHH38cVLn22mtfeeWVRGwRkfnhSMwPUY5W
P4mv0YQOLUXUGZzhyC525IOf4GwOviw2J9m2bRsqw9KlS2fPnn3eeeflCh5FlD6tzkBe
kKM2m/RvPTzSETBF5eZIyJffWFYUOQImTJv2FFU5GI+Mx+zHI7VH/LtgwYIHH3zwu9/9
7s9//vPhw4d/9dVXSS4Iy5CmaWj7EfxJ/KSI8TpVuqmcsLq3CYVKnvhsDi0vPXDgwK5d
u3AvOPvwVWfMmJFDeBRhqGIRE3KUB3h0qFs0Vli8cTrZYMDnVs6pKa60+PzK3hOyERny
exx25dhVp9sb9bbP61NOaQ15nA6b3eGN/CbTQ1oZj6zm4VHGzqeffvqvf/2ra9euN954
45tvvolvJr+4fL4GDT+GpX2S5ccnL0tMNJuTER6RBSSPBh7nz59vMplyCI/Tpk1Dl0TD
j2KLuTzAo5vOdS2pcsesGHBU6YNPquzahhJ22lBCqKTKJVmbyvGIZZqXXqn8pDmHtDIe
WSeIR6GjR4/OmjXrb3/72znnnPPb3/723XffhQOYZHASZuSgQYPETndkPc6dO1d8h+xM
sc983NmcZuCR5mUcDofVakXF/t73vpcreERqkeaVK1ci/fQ48gOPYZ9VkKvcYPb4m0w7
v8turlEOGCwqq7ZYLGaThRDqsdDJDCU1NpfX46gmEqonIQKPkY1ui6trzCZjjd0bbN4h
rYzH+Ar5LEaDwUgy4JXZ2mSik4Jee1VkFLmouKTa5Ahm8nNd3VAORFN+VW2osQeVnens
hurqGpsn9useW011tdERM6/nwo+rDVZdB5xRSk4Mj0L4Duycu+++u1OnTrfeeitakFjN
lJIAwoAUu1vQDiSJZnMywiOdNwQ8Ijs0LzNp0qQcwiP6i3nz5gHsNHlNJ1zkAx7VCl8u
napVWmlqQldIOSOmxCDv/uRX92ksMrlFHfCp77QzupQNxtWNvotqInvxNPuQVsZjfAXs
xXGCypsK3GurFlNtFeURI77E4E3v57Ks6mFrJndQ+1WRcswQHQwkTd41OSLlUS6GgDVV
CfzCHMokI62BRyGUPPhzxx13nH322bfffvuECRMOHjyYzIhQBxh1CieezWkeHnfs2LF5
82bC48SJE3MIjyhMpJl24MwzPFIl9jis0iGDle5gU90urpamZuIcyRr2mCsiR245SqOP
62r2Ia2MxwQPSithb1A5Xdzvc9VU0vln6hPxWoiHVdbI8EXARSf+FFfbU/9cFl2KmEa/
Uvu4gFPbmK7SGjVeTb1e5GghuW6IcRixM3w4s5S0Ah6bqnMggDLHBTt27PiXv/xl6tSp
8ArlL8AmpBFIXBzmItBHcZI0F5NoNofxmF94FA61hQwOzbqLxaPmPlfKbSDoMkbhUbIV
m31IK+MxGR6lEoaFX6L2aHB3bSoKS6od8cZP1GiEpD+PYzrSIRnx8Ig/5TMrayKjKtF4
pPMoi+nI83KzJ82MtBke5SHH0aNH33zzzfC777333tra2iNHjgj7UDYIyYkWDIw7m9Ns
POJGuYtHpFzGY9vsbNaqeFSOL/BFdfde1RTUkKjiscQg4zH2SFbtGMS4eGz2Ia2Mx3Tx
SO8UVXnDfnVgt8iiL+wQDf/GfUDSzxOYjonwqAynBKO+H4NH6jdRl/z0q2KJqGmmpK3w
KPvRo0aN6tmzZ5cuXf7xj39YLJZzzjmHwhpBAGKjWIGYaDYn05pAS2byA4/IBS2cyX08
+quL1KNXJX/CXqX04aVGV5MrXWIMxtgJ4khWALOcDkqApRFb55t7SCvjMSkem56IW+3O
lHe0Ub6KWOvLqfVfgWQ/l3Gqmo5mTyicAI+Vhqoi7XhKRY5qpRc1mauj8ahdx+RpGpk0
6a+ZPCUnAY9NXYTXO2LEiOuvv/473/nOjTfe2KFDB+J///79W7CCyXgUS2Y+/fTTCRMm
5BAeAXPC4+bNmwUe2+Zkn9bEo2ZXFJWUm6wOl8thqiJPQVggXrUZtCurNlvNRjrbOuiq
0Q4TNFrsNhM540UV1qZxeNlIaO4hrYzHZHgsKjeDDlazGC6uQfcT2zcJPFaXaE53kp9L
/kORbiYlBo9Gp1t9kMU2fwR9ZWafWjGa8Biwl0jpcYg0pMxIduCxafjU46mqqvrJT34C
Xj366KOLFi1iPBYGHpU5GUOZbgqx2GBr8m8CLpP4uCgyn+J3mkqkH5RWWQIRS7JMNT2j
W2hzDmllPCbDozzXW1Khxcxos2bV/lg8Gkq1yZQkP4/qMYuaTMd4eDS4gn5rJXkZfnX8
pMoeCIkhaLIG1ZBaGm8MKV4D9aoV7pQZyTI8CuFeL7300tVXX92tWzfYkC1y/gLjMavx
qI1AepwOVU53nEUtIb/X41VObI36KOjzol/1+NJbBZPpIa2Mx2R4LK5y+wN+n8/vl20t
T2VRzASxZLk1Odfxf64+JgrEqrCEEgx4Eh6rleEYVxlFVqq2plvpGw0SHr2VRXE3tox8
IVVKshCPQnheAwcOvOyyyy655JKKigokg/GYx3jMUfHUjO4zU1m7eDGlHhr3q3EHk/5c
oaOZTEdvKJwCjwri7NWaD1GiRg3JH9HropLyqqpKTVVVFeSnxAQLZaRswKPQypUrn3nm
me9///tXXHHFoEGDXC4X45HxyHjMSjyG/XY6TrxCHsBzGsv0y5oS/JxMx6IKS5KbygwM
e82ER/LEpY9CFO1o1k1Cq6sMNPs2L/AoZLfb+/Xrd8EFFxQVFQ0ZMmTr1q2MR8Yj47Ht
8ViSjCoBkzbKq0yEOZ12LdZaGUsMpvo5Ma3I4g0luWkUHvEnHGOfthK16SOKtCwxxt6F
5rLLTe5UGckxPIrHilQ99NBD55577k9/+tPXXnst+WZBjEfGI+OxRfGoTn4lo0rAEj0R
1q6ozOoJpvx5iKZOKAIh8U0DTmOiwIPIpHbAbVI4WxVv3Sj9XJm8S52R3MOj0LFjx+bN
m9e3b98uXbrccMMNI0eObGhoiP0aKsB//dd/wfJkPDIeGY8tgMf0FPR7nA6nE/9zedOs
oyG/B+3UE8j2h54TeGwq1VBo9uzZ/+///b/OnTsXFxcbDAZ5s6Dhw4e3b98e1XjcuHGM
R8Yj47Ft8JjHyi08CiF5SPP//u//durU6ZZbbhk7duzevXuvvPJKcU7l448/Xl9fz3hk
PDIeGY+FhkfZoZ48efKdd9559tlny6f6nnXWWT179nQ4HIxHxiPjkfFYmHgUGjRokO7Q
8zPOOKNbt25ms5nxyHhkPDIeCxmPl156aWzM/CmnnAIz8j//+Q/jkfHIeGQ8FiYe6cRz
WI/t27fv0KEDHO2OEeEdfMR4ZDwyHhmPBWs9jhs3bsSIEW+99dZ7772HtjxOFV7gzyFD
hjAem9eUNmzYsHTpUsYj45HxmNN4lGsCxz2eSAHSfsJ+v/+rr74SePzggw8Yj4xHxiPj
kfEYDAZ1eERTYjyaTCaUBsoEJQPUtNkexYxHxiPjkfHIeGQ8Mh4Zj7mCR5fLBSDMnj2b
8Sjjsb6+nvHIeGQ8FjIeqQDtdvucOXPGjx9/yimnFHJL6dSp09SpU1EaKBPgce/evYxH
xiPjsTDxSAVIZ5mhKVEBonoUZjNBo8Bz+fjjj1EaKBOUDOOR8ch4LEw84unTUY+oDw6H
Y968eVOmTLnjjjt+/OMf52KtOPEy+dnPfvb73/8e5SAOHwce0YkwHvMej3+9+eaZ48fb
Pv+c8ch4hPDc8fQDgcCuXbu2bt26evXqBQsWoAMdM2bMVVdddckll8C1LJwG4vP5nnzy
yWuvvfajjz76/PPPURooE7QRlA9KifGY93j8d8+ewS5dGr/97VCXLkcuueTIT3969NZb
j/3tb439+uHjsMEQnjOH8VhQeDxy5MiBAwd27969bdu2devW0cKZ8ePHjxw5sri4uFOn
TgMHDgQf8rtpoMxfeumlzp0733zzzR988MGsWbNQDigNj8eDkkH5oJRywoRgPJ6gcz33
zTePdO2Klhm8+urDN954rKio8aKLGjt0wDvKf88+21INL9zKMbSMxxYpw6NHjx48eNDv
94tN4eBXTp06FQbk66+//thjj8HL7tix4z/+8Y+VK1fmX6NYu3bt/ffff8455/zkJz95
+umn33vvPZPJhCcCqmzatImmrVE+KKXsjwlnPJ44HuE6rfjww1DXrqHvfW/30qVNzvUD
D4TPOCMcb2vuTLW/Rw8Ntr17h1utz21pPIaCwWCobZ9INuAR90LG9+7dCy+yrq7O6XQu
XrwYBiQS9u677w4fPnzw4MEPPvjgr371q+985zsXXHABgGmz2WBN5W5DAOuQxyeeeOLi
iy/u2rXrTTfdVF5e/tprr73zzjuoPMj7okWL1qxZ43a7Gxoa8ERyZckMiVZCAY8UrIWq
hQrGeEwTjzNmzFi4cOGmadOOde167PzzD6xejareWFcXPvXU8B/+0AJ1b+5cBYxOZ7iu
zocXnTtnFR7dtpqyEu2g3KLiMqNVOzxcPgnIazdVVZs8oYLAo/Cv9+zZgwYFk8nhcCxY
sKC2thYlCUKOGDHi5Zdffv7555988sk+ffr8/Oc/B1XOOOOMG2+88cUXX5wzZw7SnP2V
PxAIoJzhQf/mN79p3779RRdd9Itf/KK0tBT5QruAnYycIr8zZ86cP3/+F198geqE0kCZ
wHSkgcccxSPygoyPHz+e8ZgSj7169TKbzcAjfIrts2cf79r1+IUXHtm4sbF///C3vqVg
7ZVXTvTpbNqk4TEc/gbUxetQSLFOy8pa1t3OHI8Bc0Wxdn5uWXl5WSm9Lqtx6fDoUE+t
tJ3geFvQ53Z7kh9Cnj14pGLctWvXtm3byOQAJWbNmjV58mSj0fif//wHxhXYMnDgwGee
eQZ2FxxS1CU4pJdccsmZZ555/vnn33zzzRUVFcjOkiVLkJGTW9VhCS9duhSJB/1uvfXW
Cy+8EIlEUq+77jok+6GHHkIukBdgf9iwYW+++ebYsWMnTZqEHgG5Rt43bNjg8XhQGmQ6
wtrMiXkZGY80WkJ4tFqtaBSMx5R47N27N/pHeBbr1q3bunXrns8+a+zaVRl77No1XFIS
NpnCgBvpm2/Chw8370ZfkXO9YoXyx6FD+Oew0ai8A0LihbhF2+LRXaOes1ZUbvdFmOVX
j8QtqvZH4zHo87hcnuAJmiuOauVUNUcgm/EoihGEpBFIuJMoOvABzQrdKIzDadOmwfZ4
7733Ro0aBUvy1VdfBSdfeOGFAQMGPP3000Al3G2YYbfccsvPfvazq666CrZlx44dTz31
VLzo2bPnP//5TyBozJgxFFGGiodbnKBvjgQDgEgkUghvCHADvfv27fvrX/+6e/fup512
2tlnn427IzFIEvD4t7/9rV+/fkgt0oyUI/3IBSxG5Gj06NHI3UcffWSxWJA85Hr9+vUo
ATwLlEbOmY4Cj3v37kUW4AusXr0azJ86YcK32rVzshILdeP2229HNUDHijpQB+fX5/tm
6dLGLl0Udi1ZElXKd94ZxvtDhmRUaxX6qdrXs6dyTZWEqFp+MRQJQhIn2xqPngrVVoz2
mUMuq9lkcQaj8RhSDtn1y9/ze5x2m81ud3gDTW8HAz6vV/l+wOO0KZ86BXcDfr/bqtig
FWaX3+/z+gLZjEcYkDCQgsEgPFA4ZcAX6gYMj1WrVsEUROOaPXs24Iakvv/++3BCYUy+
8cYbgN4rr7xSWVk5aNCg5557DqYj+NO/f3+AqLy8/IEHHrjnnntuu+02+OAwMq+55prL
L78c7DrvvPM6deoESwYeLh4T7Lof/OAHP/zhD3/0ox/9+Mc/hsMLooJyPVVdf/31+O3V
V1+NL+Br+DJ+DjvwW9/6Fi6Cn+OCuCwujq/hRrjdvffe++CDDyINSAnSg1TBgAQSkc4h
Q4YMHToUhAcV33nnHeQFOQL8kbvPPvsMjQL5Ra6RdzwIlMOBAwdQJrllOhIeKdR/59at
9e+/v7OsbN+113r+539QwugyLrroom7dul2g6nxV5xWkKO8oBFQqFAhKBm+ieqAx0tAK
3Kjdu3crs3LLljX+8Y/6Ul6/PnzXXeErrkjfIw6RKx0JAtnVuXO4e3e8OECm48KF9P5x
+N3S19oGj0GXegxu4tNvo5zravjgRXbtq76a8mJ5W/JKszZcSV+rMlRKH5ZYlfMt/VX6
vcyr/NmKx3AkPhwWHZoVmACrCbbZ9u3bt2zZAmPP4XAAHYDkJ598AtcDhhb80A8//BAG
ISAD1FRXVw8fPryqqgq0hIcyePBgABOuKzETbuxTTz315JNPglflET3++OPg53333Qez
s0+fPn/961///Oc/33nnnSUlJXBwUFGLiorgBePPP/3pT/gIX8DXYAT+/e9/xw/xc1wE
DITtiivj+rgL7oU74r4EQzjOSA8qPNKGFBISkWakHOlHLuBKI0fIF7oA5BE5RX6Ra+Qd
JYBywIMgNuaQ6Rj2+49Nnx4qLw9dd10jvGnVLDl8/vnzpk1DrlECNNeGskLpPfroow89
9NADhSd0oA8//DBqEWoOKgzqyciRI9FdwgZAfUAv6Xa7aSsSLWghZf+4c2f4iSfCy5Yl
/1Y9eEgDj05nQLUSNdMRdqPUGAMRw7LN8BhwGFQ6OsNp4NFpKMF3Vbc4ZCkvUj1yg9Pj
cVoMKiiLrOo55E6DNnpZWmVyOGxVpeo3K234ldNmqVHPTC+tqrFYzGarM5TdeCRCkg2J
KoFk7NmzB6Xq8XiQMPgaqDPLly9ftGgR6g8K+eOPPzabzYRKOKcffPAB0fLtt9+GbQkc
wXUlZsKNhdkGbFaqevHFFwFPEAzV8vmIgLUBkmAfPvLII+JPfEpfG6gKv8UVcB00c7jJ
hEEiIVxsGIe4O9Lw1ltvwdBFqlDtkUJCItKMlBMVkZdly5YhX8gdwEhGIwwGuKXkUxMb
c2PFxDffhB99NFxURDMIjaeffuyGGw7163fk8ssbTzll43vvwTyeMWPGuHHjDAYDHg2e
CNn86FaeLjwh188++yzqEiokqg3YiHoyZcqUOXPmwBJYu3atGF1JN2hh48awGi0ZHjcu
hR1C7jPNWYdCRyZPDkfDUDMyfQpivunTR/synHF1lLK1rEe3ScFjtSMjPIY8Zp3N6bcp
hmGlzSfwWKzwUPtMgWdxtV/z2xV71eAMZvnYo86GJEKiVuzfvx/VA7hAquBooD9FCaPm
rFy5EqlFLbLZbGh0KHCLxTJr1iyi5eTJk5GjmpoaGGngEmrd6NGjCZuw30Ctkargm49Q
RRR9TdUwVTAyu3btOkwSPsJ3RkgCAN9UhWviyrg+7jJ27FjcEfcFDJEG1HakB0xA2uA+
I51ILdIMWxGcBxWRF7jSW7duRe5Qf3w+H/KLXOceG0n336+0o7/+tfHzz48EAshF4P33
8Y7/4YeRU7vdjhJAgcjDyDQ8UpgitwJVEf0Fqg3qLfrNBQsWwLNGS4TpiPqAyqAsJm1o
aBw7NnX5HzigDC1u2xYhTjCcwOZUYBtp4D6iH5Ao7FCauKFxErB00CB4BIdhXuJNv7+1
rEcnWY+Z4ZFsTpiEFZUVqirJXiyuske+VmT2RlAWVCd6IiyVL5gTeBTjkDpIwpoCJBsa
GlBnQBLwZNOmTRs2bHA6nYAMUg4bbPHixZ9//jlql9VqxSNAL4zKRsyEw4JWaTKZUANh
wk1QhUYKS+ZDVe9HZFQFd/umm24ySsJHH6jCl/GrGlW4CIoO18SVcX3cBfeC7w8S4u5I
w7x582AigodIG+CAdALsSDNSjqJGLmAY19fXI1/IHcAYUJFCYAxRrEVuCc3zBz/Af40H
Dijtwu1u7NLl6LXXflVXh/yuXr0a5YCaVltbixJD6aE80aGgW3m3IEVuBaoTqhAqD+oM
ai8qCU3MoVbQ4DPqw46bblLQVFur/Jf+kOAvfxnu1i08ZkySrxwk0xEmIpxu1UBtHDpU
HoeU5cL7QGVrOtdFldaM8Eg2J3CINluiqrS0DK9o+FHywfMEj7IZiTQISKKegJOoMMRJ
lPb27dvhjQIySDZssHXr1sFEQRuk08YBTBAJ7RF0ImzCcgOvkFOCJwzO2apmSZqp6oYb
bujXr9/MaOHTj1VZVBEAcTVcE1cGBnGXhQsXwl+GWUswREpAb/AQFV4gEWlGykHFnTt3
krmIAkfukEc0hCNHjhAYc2mwUQg8/9//VTzr3/8eD+/4b3/beNZZ+7/4AtlElpF9FAXM
ZjwRdGEoQJQqUAnrenpBSnSm5FbAp0DvKQctoMIrg8+7dmnuLQ0bJmBXHC1ZEv7tb8PX
X5/kK17ymsNhDxxturiYtgaH8REsScATWN60KYSPgFPF4vSJGfAWm7kO2EvUYUK9sxtZ
K5PAelSCcyppqDFG6eDR4AzkHB5jLUkdJ2FP7tmzB6gEZJBmsiphjIE/8MFhW+JZgEjE
zDVr1gCbqHtfqFquivi5VNUSVWAp4AbEderUadq0aQtVLY5oqaRlqlaoAgNxZWAQd8G9
iITANQpzy5YtqAPgIdIGHiKdhERAniq/joo5DEbSmjXhU04JX3MNatVxlZNHRo2CSYzM
EiFRICgclBWeAnVeKGHqvwpNyLXoTIVbgUpLbETdRvWgurGrVy8FWZGNWb4Gr5q3zmXr
1nBFhTJEqTMdxZYvTqeCQZ+viZz4b9SocP/+TWRWK2cDBQXh5/gvsTWbYWCPNslSUm2X
5/mqipTJZ3+iqRmfVV1gU+4KijFMS3lpudkVSI1H1V4tN3tyFI86Y1JwEnUGKSRUovUh
wWiARMtdu3bBtkQugCO0R2ImHgRhE0IeN0YEiKG1rle1LiJ06xdddNG6aK2XhF/RzwFh
YiAuS2YhkRCsxt1RH5ASpEfwEOlEnUeCkXKgnqgo/OgcpmKUDRBQ5mguv1yxIe+4g54U
HhO6M5QDigWPg/ovFCN6EzCBOq8CFPWnqIGoSzQxh5oj7EZi4yHVdGz8z39EAW8HmpqH
R9icZ56pTJxZrU3WPngY3w84HiR3XpUyPUSoVCMThDUbohcJ5rgzXjXjJwOyXXG5weH2
eFwOIw0llptDCWeuw7YqmqwurbHa7RYjXYFsQj0eAw7l02KDNjVD0zrtSowWq8lgsHmD
OYrHWE6S3y1QCR08eFDQkoAJKBEz0TCBKbIzIa+qelXbYzR48OC7777bo2qbKvnTr1R5
JYGBuPIuVbjX16pwdwBhvyoyEWORSNMuOU/FtWvDt90WXrAg6s2lSxu7dTvu8yGbyDIF
a9FDwbNAicmdV12hiuoYVSpUJNQiCloQPgXqiZdMx0gl0TA1dCj9oXjBQCWA6XSm9bB2
7w6/9ZawD5VFN4mrn+Zu48orVmhB4+pguI/maNSpHNReLwUFgZnAb/TETXPWXPudFH4j
VFRmcAfJF1YnmjU8lkrcC1jVEB2hihpHKByO+RqsR2eZikPxhsNY3hT4aPfnOh7jut4y
LQEfAUxipjJ/qopgRfBEJfSr+lrSHlW9evV6++2390Tr62gR/SAyCAUGBQlxawFDHQ/z
x1BUmpBH2UPme98Lr1ql/8jno8yKAWQyI2lgBBKdV4FLVCcagkZ1RVnRYMvRhoawsNkI
bxSTQ50OIWvQIG2di/S1dPWDH4SvvDKJAalcHL48TWSrTD5KpmPkXqjJPjFiGTMu2uwd
e/wwHCG7w+VJd6I8pCyQ8Xo98qKZtBRUTnHx6tbg5AEe40ZOCmAKT1zGJomaqqxDEaF+
dunSBZ7OwYjwGkU0c+ZM+gJKEqSlXwVVCQYSBomEMgzzecPzYFCxRvbsSTxXc5yeCEFS
FD5Kkqx9FspB9Ke0QkqMQh/fujUYsdlUW+9wKDJ3vIdG/yKBiFrsohSXuKt796gZHDTn
2KjFWbPC110nB4THJ08o5I+E9Owg0zHSvx8BWiUfXLmp5Pjzfo85hE2ZnEJUFQVF0WVd
eumlMlfJ8KbdaIUd7na7xRWOS8qNEkGrob0Imlug4SlTwl5v8x6BrsBZcbvUuP6FbDqG
JChRCQcjY4CHQE76phTKqP02uduyZk34pZfCiTfnPw6vPNpMFRPfJGVJTvTqG8ZjPmnk
yJF9+/YVf6JbR/kcUrvdPn364LXRaOzevXvnVtsir7XlFfEbqWyG+Prmm/BvfqP8PI24
juS0ZOmUeiQDxd6/f1isapG269HApZLtOMxLesR4RuKyaM4pw4GmTlW2lDzjjPC6dfG/
UFcnW7PavpGR8UYtDXiT8Zin+tOf/lRTUyNVhzqUD54yvRiqDr84nU68zkWX+QCaD5kQ
tOMfjfBnJDSBX/7yRNjIOnFpIJKc5b2Sz3uEnnKfPiGx1S1cb3lyGV8AZmEExtZhjyc8
YkRTrM7Ro8m62mjTUYv2OcGpGcZjFrvhXbp0kTeKRCGgfGAukk9Nb8KAzC3rUSE5mgP5
XJHOXRs1kvyvZEraTFhtLxehSV7nQgHbIFxkAFB57oGAFqITcRaORsJytJgckDCR4YqH
3qmTElW+aFGcxnLoUCCyLruJ2NEGKuMxn7RmzZrLLrtM9yZKBkUEHpKLPXnyZPw5qhmz
hCe3KZEhEe0Ua919Srdu3Djlt2++yVDKIvn9QXm+OLI9o+Z3S2PL+wme6r4WIGoIj1J0
7j6fMufSo0fCu7z/fhgt4h//SJmcPTGmI+Mxz/TGG2+URe8CWltbK5+QiMeN4uopORTZ
LvTmNKepSt5qICw2QU3SOqBdu5RA4ptuSjYX4/N9QxZLmtF3rJYSYBgdbfhV9JoamI4B
WlKt+kIBsfhFeA144fOle7slSxTXO96uFJ7oUUfGY/7pjjvuwIOTGr1PTFX36dMHRQRU
5lbIohbZq47nU2PR7eyntI7Ipwm1ZUuSw+wUo1q9ZiOxt4X24Wc1bxQlEI2pINwcaWNb
JaIbVYL2KIOFOWhQOKNmPnKk5obs3JnmaBXjMT+ERwkPukE6JdPv9xMbxdijQOWhDDe+
O1nSgofVHaGbeBivo4/S11+HH3kkxXdIcNVpwyvZw8rjOM/s97mlTXW0XW3JdNQND/r9
R/Ai2g1PS3AQXnutadI86bNmPOaNVq1adfnll+tKRva1adRRaFPWmkloBTAII7PSjaj/
0WPmh2gwKtFOAgcPhi+8MHz66eHp05Pf5xiuQJ6aGJ8n6zS5t85qTWnBNmq8zf7oB62b
WXbr+s1mCDbkmWeGb71VOdaB8ZjXGjFixP333y/7KSiZw9EnwY0aNapM3Xy+Z8+e3U+w
arWOjlDMG3lPESd6L4UEyxZvEsvw2DHF/FizJq3b0fR3ZM60yTrlyJ+TKLRc1SY8CjxG
6oAuKFHrNKmL9/vDRE70axmNHjc2Kr3weeeFn32W8ZjfKikpQTno8FgbvRwVRUThPTAd
KR4yu/IgRQsfpsjGSPo9KU97dzjC0sBCYufNr7AXrSkCQG2DAqm2HIpMlTKoskc609Eb
mb9uWrtNG5fpOrtMNW9eePRoZe0A4zGPBBh27tx5Z/SAM96hUPBDhw4pk7zqUGR/dSKD
8JhtuVCcqYhjqx3TKXwrinZLsPlA+LHHlE9feCGFsUCOG/BI5ijal7rcwxfrpqU/Gcpq
fTXS9FnEdNQOIlQNRe3A60hfpvnmot/P1AB46inl5xddpCzGZzzmi1auXHnFFVfEMlM3
KUOLZVAyeL9/ygnfNpdykrs6xriPXGxxLJ0w/OIKNfnSSxXLIRi1351iBEoGp7bOVzhf
FHen+m6NtEwjp2JBC07SHIo74kpo2JQ6TWW3K3x0/HijGMPMdPrGZgsPH063Yzzmh15/
/fUHHngg7kc+nw+FM2rUqIULF9LjJk7qhiVPjny+o+j9wUAJTdook2o0Biiuo3lrfEBC
aQhRizeWzAnNCFGpqwWQZEOZsFJ6GagzKvFi1243CXjE1/Bw6QhsqSYoh2Knt2C/cd26
xvbtQ3/5y/716xmPuas//vGPk6UhF5p86RFxVGm7SM2mOnTIaDRmReGQvwwbj9AUcW/3
S1bf17SrVezKwWXLwtdeG3755dR3wc/VjQ60lbxSU9LiRsTFebAx15QMj7pBG9UHUdyT
Pn2CUiStepVQokffeOTI8aeeauzY8ZshQxiPOet2HO/UqZNPGi6DrYhiWag6qmVl2kbE
gzI5o611h5JgwqFzRxUV4TpkMap9+kGaTR406BDwHreXx5Pt0CF88cWxTpNyZdFNqNOa
bnKviMfS4rU4eGTlmrRxY7WSKAu0I7FqyuGtqDw9eyqdb339fvJQwsrcpDaP06ePQGKS
rdI05/rQIeFcb3799TXPPTdx/HjGY67I4XBceeWV8judO3c2qt4Ebc7Tp0+f/v3744U/
k0N+W0/HaFY6er5Yi/JVLYHjgwaFolGm19Kl4f3747xP5sSoUfsjyw+1mU01tFgbj0I3
QW2BrNa82fm8MFVXF5LXbh86dJAGrlF5wEYxwRcZc/ZS/A+NaRMhE2+VFjv2uOf3v8cP
4dQwHnNFw4cPf/DBB3V4dKr1Qd6oJytCwZEA1dXVgmekKLUUttyxY8qKsE8+SXmH7SIE
LsI9LUZOnfc8Tqap+C/9M5dZ2Q1JpS6pfWvUdB79GRmr0U42pIdOu+bqtkpLhccVy5ev
HDx4xX33MR5zRb17954yZYr8To8ePcRawnrCkbovbuAk0kDu5dVHo62nluRPtOQZoKNz
5F99NcU4gzrbEooJ1IkKLIcXhjLh0J081QExF7Np0zEKao0MwviiF+zrtkpLC4+6sccF
C5Q90x56KLx3L+MxCxU78EgwpKBHGn6sq6vrrOokJjIQsxRFO7QOHCNqkaub6Kk99piy
F3Q6Une+0g+/pxNYzsobwUeggWvpoWsrpKTxpf2p4v9T43H//nDfvsr+5JMmMR6zUF98
8cVVV12V0rxEKflOnr2kzTBqNqJfISFqZijUSOONYjtH3dDozp3K5hLpKHqZdpNDLeZu
YDYnDyxn5aOUTcgjtULb7UfXZUf2u1DqJO2lJp3gkG7cYxZvtlzgeBw2bNjDDz8svyOm
qsUmZic9kVrcdc+eUTugqnX1a1peHduDjxmjTE///e8pLx53mXaTQw1vnWaCgMfsmJli
nRRpM9SR8HJ5qzRtxSIqz6hRIcng5LDwXFevXr1MJpP4s76+nja8pYO3hE7+GpnJk6n6
EaM0e1Ktq964bu9FF4X/8IewdDBEfCVepq0MQ5F7xUYjS41hCERO+JK3StPWIUZqiDbm
o/6pHE85cOA3gQDjMRd17NixTp067d69W7xDEY/iTzxrlExvVdlVV2n8nNwcCnrUAfzY
sXSuk2yZdqRV8P6NrCY5nWgV8lZpytE20VvYbcE7qkt+2GZTZvr+8peDM2bstNkYj7ml
5cuXX3311fI7tO9E9m4Jjp4aZiS5w1JUz3G8OWNG+O67U24rQZlUotrwn8+XYpk2ixVP
Yqs07TyO6OX2nsghmPXnnEMdbqP6Yn+vXozHHNLQoUMfeeQR+R06QKF79+6BrIzo044w
hpkXOwx4+eXK3qSpZgC1wMX+/ZWzD8QWLi21TJtVeHJHnwisLU9wOml279grr9DYY8Pr
r+PP1R9/zHjMFd12221TpXAX+XAZUllZGYrlcE7stGCxhN1u3Xu6XXe0HVpiQsfTWqbN
YsWTNkdD/fWmTaHIdvHezp1hNIqpmfrZs/E1x4IFjMec0LFjxzp27Lhnzx7ZmKSVg1Bt
bS3F85AxmaV5mDNH2YA0+UiRFC2pBQLFKPUybRYrsb6mJajSsgVaX9C4Zo3A41dXXYV3
2LnOFS1btuyaa66R3xk1alTsIa0+VdmYgUcfVapivNCd48eP75dBF9l1J+4OLd+o2wuk
XqbNYiURrEfJ6aAtJUVgz/41a1DxttXUMB5zRVVVVY+CMJIGDRqE0qjLFb/y/vvDlZVx
l8nsBPHUTU2b6qpqNGoD6dG77oR41x1WS4u2lBR4/PLii1EDeeY6h3TrrbdOmzZN6v38
cpSj0+nMxhI4ejSdbRW30OKFsBqWEwrJu+5oI+eRzdmORrbyY7FaXITHoMuFOrZ74kTG
Y64IuTv77LPlDcrwKDdt2jR06FDdAQpz0znuuW0EsnXvrgR7p5IWpbNiRSgSDxm16w7t
uyL+47UwrNbE494BA1DNvF4v2hcggwaVW3icNGkS0vzFF18UDh7tdntRUVGiT48fPw4X
m2ZqJp/IwW0tq2uvDV92WaKDP+RJ6mOBgLa9j5T4qF138C9gm7VHdbPyCI/K1MzevQAL
8EJ4hD2Wi3jcsmULcrF//37k6Fh6yy5yVK+++upjjz2WY4neuzd85EjCT6VJas16xH/R
+5TyrjusNhYwokzN7N+fH3hsaGgoBDzecsst06dPz/ZUAoYDB6a1EEZ2wGmfUrFlrhzf
zrvusBiPLYHH4/m70jZ24DFL9cc/KjQDIRM7L0mOhgnHXSHII42sk4dHQAaoAXAYj1mr
pUuX9oheRJ+lmjo1RdR30qNhmv7MviO5WYWGR4AFeAFk5s2bN3ny5AsuuGBT1g99o/mc
dtppU6ZMsVqtDofD7Xbv3Lkz7/E4ZMiQ8vLyLE0c6szixel/PfnRME1/JjgsicVqbTwG
g0EgZdeuXcDLypUrx48f/+9//7t79+4ffPBBlif+888//+EPf2gymT777LNVq1Yh/cgF
8oIc5TEef//738+YMSMbUzZ6tLKx/I03pvn1tI6GoT95vJF18vC4bdu2MWPG9OnTB0Zj
165df/Ob3/z2t7+95ZZbsjzx995778033zx9+vQFCxasXr36yy+/BB4DgUC+4rFfv34v
vfRS+/bt5T0es0h9+4bvuSecUdr4aBhWVuro0aOwvgYMGPDTn/60Q4cO4OHzzz8P1Cxc
uLC2tha0vOyyy55++umsTf/IkSPbtWv37rvvzpw5E2leu3atx+Px+XwHDhyA052XeDzr
rLNOO+00PKxvf/vbxuiTrU6mMtleUpmOoQOIwcOIfZhbR8M0suIpP5qYy+Wqrq7u1atX
x44dAcZnn332008/9fv9X3/99fbt2zds2GC32+fMmTNx4sTXX38d/Ln++uvfe+89wGdj
1ujDDz+EodutW7chQ4YgnUjtsmXLkHKkH7k4dOjQkSNH8hKPl19+Oa2FOeOMMz7++OOT
nyCPJ/y734V/8Yt0v08b2sOVHjRIO3cmEsaTzUfDKJvqRxRSdZQVrVBEVEq5RUvYVBMm
TPj73/9+4YUXXnzxxX379p0yZcrX6jFwyAhg8s033+zdu9fr9dLszGefffbRRx/BgBwx
YsQf/vCHH//4x+edd973vve9c0+2KA09evT43e9+N2zYMKQQ6URqadoa6UcukBfkqJUe
ED39Y5JCbaibb74ZbDzzzDMfeeSRNrjdsWhR3qOK47bblHN+J05Ms/SUberF2XDh8E6a
sI5cMwuPhhGPm5AYVIX+90BEAVX7C1KUdyqHgwcPUuEIVMapLdkkOJhz58596qmnrr32
2k6dOpWUlIwaNWrz5s2xPaO2aY86O/Pll1/CUFy8ePHs2bMnTZoE13X48OH/93//B78b
jvbjjz/+2GOPoW0+3LbCHXFf3B1pQEpgNCJVSBtSiHQitUhzXV0dzcvQisIWxCP5DsJs
AHuVgBNV37St7r//fuDx+9//PvUCbSPKKbKMjFPlBy604oXtt2tX+qgJRu+uo+3AI48S
ZNPRMMJcJDASFfeqgre1WxWq3M5CFfIOuwuFsGfPHhQIimXfvn0oItQZ1BaqJ1lFSNS3
1atXDx069H/+53/OOuusG2644cUXXwQ9kiwhwU/wKWo+OgLYk1999RVFP86fP3/mzJmw
OeFZv/nmmzDVAElcbeDAgc8999wAVRWtL7oRkIj74u5IA1KC9MBuhFs9a9YspJNWW9fX
1yP9eDrIS1P7bYk2QmDEZUUbIYNBtBQammgDoRCAR5vN1gb3ogpPIlOBav6R998PDRok
LISMCtMbvYxa86mzMoaTHOqQul8Qco28o0yuuuqqbt26XciKJ5QMbYGC2oJmgnJDt5IN
hIRTaTQa77nnnu9+97uXXXYZzK0ZM2akf9oIsoCMkH+NHsHj8WzYsGHFihVwWj/++GOT
yTRu3DhA8u23337jjTfgbsNyG9a2wh1xX9wdaUBKkB6kCmlDCpFOpBZpRsrJpqKH0rJs
JDDiuS9ZsgT2Km6NvsNsNs9QNb2tNHr0aIPB0Ga3o9zV1tYis8iyxWLZ869/KaE4f/hD
uubB5MlBCmtU97DdSadRSz2X8o7kbmePyKdGNvHc0ZTQWdAhuR5WYqH7fvTRR2FMoiWS
u02Nse2HInF32E7wN9Gjde3a9e6770bb2bZt24nUBHSRqAY7duzYunXr+vXrYZUtXLjw
008/ReuYNm0arLWampoPP/zwA1Xvt5Xodrgv7g5vGilBetBJIW0OhwPpRGqRZqSc5qxb
qsOiYiHHCqUNxwFmGxrIL1T9vMCELKOm9WnX7uDQobCbAY2UlV87Fat/f20WBt/Dryhi
h+as4ZvTdEz2mY7CZkCfiKoFX3LLli2nnnoqR7wkEZy7Bx98EP0IPG60F7Qaao9tg0c0
2GXLlr388su//vWvO3ToUFxcPGTIEJhPJ0gDuTJQRwnafPnllxs3boSrvnz5crjn8GHn
zZsH+wG20yxVM9tKdDvcF3dHGpASmHBIFdKGFCKdxEakXJiOLfI4RJngKeP6Pp9v6tSp
v/rVrwq28sMq6Ny5M0oblZ/GeMmGjFP9/H7YjcqpWOo5DoeIinQ4AiqYvFtjtobuCIMB
PjW5VGvXrmU8psRj3759Ya7An0VtoUqCRtSq/nVdXd0777zz5z//uUuXLldffXW/fv3A
ikNp7LqcaX2gKWxBSNiibrcbrqvT6Vy1ahWMSbvdvnTp0iWqFreV6Ha4L+6ONCAlSA9S
haeAFMpsbMFRR9FAyKcGG9Enjh8/nvGI/giVH4REmVMMVWyZa6e/SbtJ0AKZJhiCn3V1
4Wyd2Wza6G/fPrDxq6++2rRpEywTxmNKPN53333k0DU0NKDCoJK0hgGJ5wIvEpbqf//3
f5977rmlpaVwMIGCTK+DCoymnc7esDTORhMQNEOHH+KO27dvB5+R382bN7tUrVe1rq1E
t6NbIw1ICdKDGou0IYVIJ1KLNCPlzZgsSNJA0Ouh9PAggAKwET3F2LFjb7jhhkLG4znn
nCOPZtACpbiVXwvakTrxQP/++g3KslUU7QavAVnGo0d+YTrabDbGY0o83nPPPbBh4NaB
G2KFb4vgEa174cKFL7zwwi9/+cuzzz77lltuee2119asWdO8q6G/kzfVX5jGon6ZkKgb
qPyAD2oIKIS+ADYDoLRd1ba2Fd0UFRVpQEqQHhr+RQrFCHALspE8a2og8K127twJkwlY
eOutt/BoChyPK1asQD8l5sLIgIyt/HgcAeFQR+SJWV6dnRKxHOgZUf3Q2NHk58yZw3hM
ice7776bAu1EH3pIXTfabDyCY2+++ebtt9/eqVOnn/zkJ88888y8efPSP7od96X4TDqM
iTbPp1k2qLa2FvUZPtHQoUPTHN6kIFhdHAuMKBHHImI/9rS+YuNMkBIRZCKMxhaPHyDP
mhoIHTPhcDjeeOONAscjqij6Wdr9g8aX0IMkWqN0jNa/yJE8MCZz4ZAL2oiAPGv0jHBh
7HY7mtK3v/1tZmByPN51111imQasKbRc1BBYLxnhEfVq0qRJ//rXvy666KJu3br985//
nDhxYjP2GQD62kWrt9pfixPhm+dZyAGxxEkRBQ1gHjwZwn1FiDKZi8JibI1FTLTPGxoI
jFXYD9RAUKrXX399geNx7ty5y5cvh0GFyk8jkDT8GPcnB+lYhFzbw1bgEfYPmjk8OHQK
U6dOZTymxOMdd9whaggaDmoIhSKjGK+99lq0qUS/xXesVuuzzz4LE7Fjx45//OMfR44c
iYtkZCXKxBMmIiAJfxNgpD/xzVGjRuFFjx49jEbjQlXNOAteXmqqW0B3slZ0yqvbWm9p
J83LUCAohTmtXr3aZrMNGTKE8Th79uwlS5agv4B/vXPnTjH8mOhXbop7zDU8imW2cBxg
Lc+fPx8GDOMxJR7hBVsslqVLl65fv76uro62iBk9evSZZ555yimnvPPOO7qfOJ3O4cOH
33LLLR06dEDjGjhwIGCV6Tl6ZA0K0c+JgSuko9/oEE8kCegAG3WGZZl0fvqJAySPNwMR
E5dwDWhSBp41GsjgwYN/kf72C/mIR3TrM2bMQE+B/gKVH6Y1GJIcj0pAeK5t50J4pFDw
DRs20Bb6EyZMyAyPIZ/FWF1ttMaaziGv3VBVbbJ78w+PMNJmzpy5ePFidKCwK9B2brvt
trPOOosQRHskotp8+OGHpaWl55577qWXXvrAAw9MmzYNtnrzbjpo0CAyBUFacLJz585k
Q5K5KNMD4JXP7jx8+DBFpNTW1uJX+CiPN4ltcTzSvMz27dvF+bYvvPAC4xE+JnoKMfxI
K5Xy7OAzwiOtsaUVZHj648ePzwyPAXuxygSDUz9Zb6tUPimusucfHgFDs9lMGwyaTKau
XbueccYZwkLD6x/96Edg0V133QVLsk5agJ+mgD6YeT179hSUw2U7x9salKxHeRLn0KFD
eAe/jf1ynz59GI+Z4hFAoInL5cuXf/LJJ88//zzjccqUKWAFHV2Bnrdw8AiDJzM8Bh2l
mttmivIVg056v6TakZd4hH+xYMGCf//73zIYSTAjjUZjRhRCS6Typ6lS+Wpz1RM3yPAD
M2EEAsv4MiERf+J9eVtU8XM0cPoUBieYSfZnZ95+ubl4tNvtFotlwIABP//5zwscj3Tw
GSrhli1b8hKP9PTRash3WL9+PXWOzcdjuyKLtwmQXksFvVtikPEYcDvtNpvN7nQHdZfx
exx25SOHyxtK430QxeO0W1FfrTaXR+fZB9wOu3oTZSYi4PP6/MF00pARHidMmHDxxRe3
b9++XYxOP/30wYMHp2klgnUwL3VX6N69O+hK73dXg8R0EYwkvImv0WtBYyCU3kG91V0Z
lwrlQkxFljSQo0ePCjy6XK6lS5fOnj27oqKC8Thx4kTCo9glqcV3kMs7PMp+tL+6WHtT
WI9Bj7UsepbAFgGes6Yi6pOSam/S90NeW3lR1CdF5aZA5CP5LkUlajqKqv2p0pApHl96
6aVTTjkFZXXqqad26NChU6dOZ599NsBI173qqqvSuZSYOoFRB5QJsglnGT6ymIUhy9Dn
84GKYihS+NfQ0KFDaSiyf//+ZDTS2COqMX4SyIWlClmIx927d9P+RYxHgUfYBoRH1CsK
bGM8JsJjSbt2pdU1lfi/dqVO1SALuWvwR7nBiNZeTHiM+NoVNTaPx2WuUv8qMaLFBtUv
A3Bmh9vrcRrKFPBVOwKJ3sflzSpFSg1WXyDo9zrUWxfbldbvq1KxWVxudHm9Dkt1hKuG
QNI0NAOPU6ZMgQm6Zs2alStX0s6x48ePf/3115988sk777wzzfNZyPmFBLuEXyx/IfY0
VXxB4FG+Dn2Z/Os0g8BZjEfGY6viscTodJvLFSSaPHjPWglIlTq8DoFHV41CtLIat/id
pQLfKQHTgk6jArRKS0gaPQuGEr4PeWwmQ41VYM1tLKW5oaDLqMKx2t/k41eq7yh4TJKG
ZuBx+vTphMctW7bQwcrNOPuJFrnI57nT7IkwF+kLsBXD6iQ1vGMyIMnsTHQSE/nUsCqZ
coxHxuPJx6PBGQ4pL+DG+oIuhVbl1nDIVRLBo6O6RDXVyisjW0CXKmaeiqaA+kOVYhXV
RpsjMiSY6H1xZ5/bajJWlJUWqxZjtcMfcBoUq9LokgYa7SUR6zFZGk4SHslc7C4tQUWt
E36x7gvkMgsRM8V4I4BJlZNmrnXT2az8xqOyV2+I8ZileCQGqsZYu+KSItWWC4ZDzshH
AUMJjQSWlJZoKi3FywrNGfc5q8tKpBHDCooSSvR+2O+sKosMbhZpL4BH8scrbT4Zj8Ua
HlOk4WThkUYLBcrIL+4vHfhLXyB7EnYjTeXo0CcGLWUXmxFXKHhU2yC5SIzHrMWj5tsq
DKr0RH+kWm7Fye20UNDvtNWUq7ZgqdGZ+P2AUQVdcVm1zaXM1bhU8CnWo6NaH0rkNRdF
ak46aWh7PE6ePFm37EUXfkPjivWRwy4TCQYnvGm42wzGAsRjqRhgZzxmKx6VCesimu5w
6j7yqCOTxZVW4QG4zNVlZdWuYNhrN1VXGeyRGeSgirjiKnui9yO2aLFD+8Sjhp8reAz7
VVe6XZlDqygBU1mRmJpJkoaTiEcaXZTX+pG5yMHbjMdM8ehnPGY1HhVLDw6gNgwifxRy
U4wOTD6rw242lKt/lSp4pAjJ4gqTzW6tqSJXudruS/S+sB7LDWanw1IRcbINKhOdRi0a
vcpoqBB+OXWsidNwEvEYjsxWy8D059r2JozHExg29Hu93oDos0MB/OlvGkkM4WM5cNfv
UcJ27XZH0280PBrxJa9LCfmNCRJmPJ4sPCrRMtGx3wk+8jurSqVoxaJSs4uMvIC1Omro
rKLGkfT9sM9hLGqKeDRaTcr0dKXFG7EJNZbiM5tTDYMsjnSsCdNwMvE4dOjQ2qw8boPx
2AZ4dNcobKuI1F4HRQxX2iKtxqbU1worVfya8mK5RVSa3U14bFdcKn9YZvQyHk86HjP1
JX3oC5XuUde7hQJ+r3IMoNcfTOv9cFB53+uLhlvI73I4POq1tdgYn6UoZt13ojScLDyy
Ctq5VofHiyos2vCUhrgKDwHRqnT9VcpsY8iiroUoKjc4PR6nxUALHqw+eWlGqcXp9Xud
1aoN0BrbHTAec3dDMwpHhz/vIZYGPdVqvam0tmRHynhkPLborbyVRREe+qzCAKxRA9lE
aG7IY24XPf/it1VpcRo0c92uyOSOdPghJ62ccAZbuFgYj7m832PQUhkZcCzSnOiSKmvL
1hHGI+OxZe9lV0eDLL6w31qBimu01BQrIHSBnBWRhV0Bh0ELbtPCditLxUpesh6l1RBo
CKay5sT0Mh7zGo+qP+K2m4yG6uqqqmqD1elr8eszHhmPLXsvCkirtLrU5WYVXooAKTZ6
VYuxtEZZ5hB0mwiHarAuRe2W4ZUy/Kg511XyfJ46R1niYDwyHttWjEfGY0s7PQrfikrV
JRDqICTF6JaXK2+YVC87glBfop/DjpSXQ6jRHWw9Mh4Zj6wcx2M4WBOJ0VBnYbQNB8iZ
9mhOkVUdLSoXcWhBt6W8tFwJvdDGHtsZ7Jr9GPKoqyHaVbhbOr6H8ch4ZDyy2jgs3G2i
KNwSjXAhV5lGR6v4jo0C1opKa6x2u8VYInbpl/ZcrTJZbdqkdrsyk7vF08l4ZDwyHllt
vWrGaymK2l4vRAsequyyNx0nEjgUca6LK2vM1aVNYY8Ge2tEhjMeGY+MR1bWLioMBZSY
Xa9HWmgje+lKUK/HF2it7XsYjy2JR2WjpWCeNRzGI+OxYIuF8Rgfj0GPqYp2zVGHPyoM
Tl/qHkpdIdUCm+R47aaqapMn1Na/ZTwyHhmPjMcUeAw6yyJnt5SVl5dokCxPOS/mVPbW
aYHgK4eyPqCdLdDWv217POIieChNg02BgO7wLPpC7I3wZtz9bw+pYtwxHhmPrYRH2gan
qNwcYYzfWKYel5CKOS2Fx6DP43J5gm3+2zbDIx2OQAdv0fEK8nGudNo1npc4uks+K6G+
vl68SZuh0SkzTqdTHsZPuWMki/HIeGwGHh2GEnlTET1+vF5fQMJPMCA2aCI8OoPhoNft
sENOaRuIkF85YjWk+O1Oh3KwauQ81oDHpTtoNRTw+3xNP83o1Ffdb8PKsho6ydXh8UnJ
DkWSHfQiNfjY7Q22MR4JYmLr7/79++PPzqrwHTqdENDDjeg7jaroy3V1dX6/v3v37oKc
ArN4H1cAORl6jEfGY4vj0U1BqyVV7lg7UD2toEjaG4TC+6vU+C2nQVkNUF5eKp/GaiFT
Lugops0XS+RNmBwua5X0XQMRWR3DLKIxzExPfZV/Gw66q0ujjoAtM9iCUrIrjDVy5ESF
2d2WeCTvGM+FLEn6yGg00u64ZBn6fFHrJsh0FGfT0G9hPdL51/gJH2zNeGQ8tu7Yo7SR
SLnB7JFtMTqKSzq/gM7DUvbu1vCo7pljcvj9Ppu2A20FHbUgYlmrzTarBLeSSpPdZqJP
jep+jMJJz/zUV9nBD9bQRUur8C233URgLlejZynZtAGv1eEwawFmZa5QG+FRHMhFBiGq
H/1Jx1jjyrITDcOSRhTp6C65WgrnGv/Sl3HlRGcashiPjMcTxSPMEq+9XDK7SitNPgmP
xUnxWCptlkt71lGof0nTBuDKhSjWv7hSWyZA+zVFrhPBY+anvurRWlzVNEZAJ9EUKe9o
eCwS67ACanrirFptGzyKoUKBR/qotrZWeOJ4E1VUd/KCfMI1CoF+LpujLMYj47Fl8UgE
8zis0hGBlcrgYAo8lmg7dja53gZtYWnMOnp1W6ciiy/RdVQLMPNTX8Vv4xzzKq3cp0/l
jNir488rtQ0e6+rqdHiUZ7GJiqic8LVlU5MsTMKjfCIDOeYMvfzDYygYbMvxE8ZjyrBw
v8tCJ1yJrTjlwxRoEE/CWlTcY4RC9tjj1XTT3PHxmPmpr5L1aNIf8xrBo4BnhcUTTpCe
k47Hzp0709gjuEcGJPnXNB0Dq3LhwoViUpsGIcvKyvAdYil+wtBrXTyGfBZDtcHsaCNa
hbw15VqFl7t1xmMb41FZxuSLOhzKa67QHgpZj1U28ZG6F1MEa2pEkFmKyfaRy2z3NxuP
kU4zzVNfJesx9phXbe/6JuvRIN2jjfEo8JUIj3hHnlQCDMXP+/TpI94ELcl6FG41nQzL
0Y+tjseAvShm38VEjpjX7Y4KnMhc1NDaFZdVVVXV2LyMx5OERzqetdghPUx7VYnmqGpe
bWTbJb+dZj9UrNGWxU3DiaAjHaVR4wo2D4+Zn/oqXVabYBLHvCKx1e3EbszS7doej+mL
wsJFPcRDlM/I1o094muJwsVTClWikBcBNcu5DnndLrc3HTo61HiPEzH56DjjMmfbBiYw
HmPwGDkDqKTcZHW4XA5TlbbZkjpO6KnQ1hlW1tRUC+dW5Qw9QZVAFUa73VJZqp067Q9r
g5ZNZwimiceMT32NuqxdS6CyJZS1plJKas7gUScabOzfv/9hVTTGeOLnwDY0NOA6Xbp0
eeqpp5BBxmOaY48Bv89PMcCJw2hDwYDPbSlWZxJ96rFwshEZ55xWJZQYX1Nrqddlt9ld
Xn/A51JqeXGV269cQhxUhy/YrBaLxWp3xkThBX1Oh50iinUfIbFqwHBT7DHjMZNFhR5D
WdQJkgrXIvZ8wGUqkaINbVaDNjcdDqhBhKU1JkPTpHdptTZrQgsVS42S9Vgqr8QJqJPR
hqYZcCJVxqe+Sr9V7mo3lkfnwhN7u3g/zFI8hiOxPUKosSd+TQChQ4cOuNrpp5/evn37
a665ZvTo0cgj4zEZHimUt0g58yVJGK2jqp1OVdomjwnOaY2c7lpZHQl+e36M7gqVyhX8
poqS6LfLRHX22gxR8b7tSi0RRrrMlVENu7zGz3jMfGom4PM4HarQ+4Rieib1XNWElj6d
u+ptmdPtMz71NfbnXiU5zdv2KTu3pMDTbJ4TnRyPQvjzjDPOuOOOO9Aujh07xniMi0cx
XpQkjNbvsptrqpTDW8uqYeeZTQSqxOe0SvHDpVU1VovJtNhpM9eo06NlNcoVzE5f0G+v
org1py8Aa9Oq7v2ojbRrO43DZrB5fV6Hmb5pDEbmAnBhs8PtcdmIr0n20WU88n6PaeKx
qKjoTFVnnXVWh4jOTkMdM1SnDHVOhuocI9wUMGwXo29961uoHr169WI8poXHRGG0Iafi
mRikKcUk57RG8FhSLZ9bHVSCLlTERTw8u9FgtIndBdTlbIRHlzpDWtYU0hZygrFWZ0iL
3CgW0XThkDbkFWA8Mh5PDI+oIWgyq1evdrvd9fX1aEf79u0LpKH9GWpfhtqbofwxQqZ0
1iNqBd7p1q3bK6+8smPHDsZjOnhMGEYbGy2c5JzWSPywJWqDAZVssRwL+WFZVleWl6jB
G4RHNaI43r6CkZVrJeUVEanuvTQjwHhkPOaBc92yqqurE3hEc4B5/M9//hM1hMceM8Jj
wjDaGDwmO6c1/ixhLB6DVkPTuHpJaUkEjzRDmhSPkZsqty0tKa0wsfXIeGQ8JtK2bdvQ
auBf9+zZc8qUKS04qllQeEwYRptgMUX8c1rTw6PHXE4RJEarui+WTzm8hqxHNUKyaT2a
lGCnmmBj+vGXjEfGI+MRslgsDQ0NBfuUWwSPCePEKFpY5lKSc1rTw6O2HMMZlHx5DY90
DGKReoI2XdtSXV5eZQlGNmmRAjY81eVlFQZbiPHIeGQ8sloUjyKUN1UYrbdKpWFZtdlq
NtKal4TntKaHR7e6BqOotMrmdJiqtJlubTkbWYnKLLrR5rDX0LhmSU0wEs+mxiBZHHZr
FUUmV1gKHI/QsWPHkClkDRl0uVzILLLMeEwTjzNmzFi4cKHT6dy6dSvwGAgEjhw5kk/V
g/GYOR6bQnlThtEGXCYR4xjZLjXBOa3xQ3BVPEoz3bhiZVPUZKnZZlZ3y6rRvHmPTd5x
CxR1RX7ptdfI4ZLFZYYke+sXLB6/+OILZHn8+PGMx5R47NWrl9lsBh7Xrl3LeGQ8NlMh
v9fjVfbal2y15Oe0pryiz+vzeROt5Q75KCzYF2eSxqt+5POnGIYsNDz6/f76+nrCo9Vq
RcYZjynx2Lt375kzZy5evHjdunXA465duxiPjMdCUKHhce/evTt27EA2V69ePX/+/ClT
ptDm/KxEGjBgwO23326xWNBe1q9fX1dX5/P50I4Yj4xHxmM+4TEYDO7bt6+hoWHLli1r
1qyBtwif8Uc/+tHFF1980UUXdevW7QJV56s6ryBFeUchXHjhhSgQlAzeHDp0KKoH7O2N
Gzdu27YNLYjxyHhkPOYfHvfv3w/f8Msvv4QhZLfbP/nkk0mTJr3zzjvDhw8fPHgwKkO/
fv0effTRhx566IHC04MPPvjwww8//vjjTz311MCBA1955ZWRI0e+//7706dPh6W9atUq
t9tN1QPtCK2J8ch4ZDzmDR5h8Bw4cAAVACbQ5s2bYQ599tlnM2bMGDdunMFgeP3114cM
GTJo0KDnnnvumWeeebrwhFw/++yzAGNlZSUsRrBxzJgxU6ZMmTNnDhrL2rVr0a3s2LHD
7/cfOnQoz6oH45HxWMh4RF6AR1QA5M7r9W7duhXtHQbkp59++tFHH40fP/69994bNWrU
iBEjhg0b9kqhClSEIQ0wor+A3Th58uSPP/54wYIF6ErQoaBu+Hw+WOCww9HdMB4Zj4zH
vKkAyBHyRf41son2vnr16sWLFyPvtbW1JpMJ5fDBBx+MHTt29OjR7xakYC6CijCnAUb4
1LAbwUZUjPXr18N0bGhoQN2ABX748GHGI+OR8ZhPFQAtGu0arXvv3r2wgrZv3w5COp3O
5cuX22w2q9UKGsycOROohMc9vSBlNptRAmgXMKo/++yzJUuWrFy5kthIbjU6F9QNNCVe
MsN4ZDzmU2aBR9QBZC0QCKClEyG3bNmCyrBq1Sr4j/C1YUwuXLgQtPy88IRcI++LFi1C
00BlABjRd2zcuJHYiKoCNtJhLmw6Mh4Zj3nWBGDwkAGJ3Akbsr6+HvXB7XYj7y6Xa+3a
tWDCmjVrVhekkHGUAFoHqIiOo66uDvVB2I3ERrQjxiPjkfGYZ00A2QEhaR/+YDAIQu7b
t4/MyIaGBnASxuS2bdtQPeoKVR5VKAdUA6/Xu3PnTrQX9CMoK5mN7FkzHhmP+WchHFeF
rKEygJBkRsIuon2kkXEUyO6CF8oBvQYKBN0HygetBmV15MgRlBuzkfHIeMxXPApCopkT
JMmSRH5hHaF6HGCpPERpoEyCqlBKIVVUdAyTvMQjnq/Ao8vlstvtFouF8Qg8Tpw4kfBI
sW35jUdRH8jXJmOSUMmSRcVC5iLEg42FgEcAYdu2bRs3biQ8DhgwgPE4adIkWlS7ZcuW
+vp6eFXAYyGcX6mjJUsn5kah4ZH2ixZ4fO65537xi18UOB4nT55c4HhksRiPMh5pv+iB
AwcyHk0m0/z58x0Oh9vt3rFjB/BIq8a42rBYBYhHsSPBiy++eN1113kLVR6P5/TTT58+
ffrnn3++evXqrVu3Ao/79u1jPLJYhYZH2hAVWICZBBqACWPHjj3ttNO6du3aRVVnVefk
tSiPXSK6+uqrZ82atWjRonXr1oGWDQ0NjEcWq9DwKG+ICg6ABosXL549e/aECRMMBsNr
r71GO/498cQTjz322MOqHsojUY6Qtf79+z/33HMvv/zyiBEjRo8ePXny5E8++WTZsmUu
l2vbtm20VT7jkcUqKIkNUXfv3i3OY7JarXAtP/zww7fffnv48OFDhgwBJEGPClXP5pGQ
nQEDBjz//POVlZWvvvpqdXX1O++8U1NTM3PmzAULFqxcuXLz5s2wq/fs2XPgwIEjR45w
hBuLVVB4pA1bQADa8c/pdC5duhS200cffQRQjBkz5q233nrjjTdgSQ4bNmzo0KGv5pGQ
HWQKFuPIkSPRF4wdOxZms9lsnjt3rt1uX79+PSxqmI602SnvBc1iFZRgDqHVo+3DvyYD
ctOmTatWrYKLPW/ePBhRgOTEiRPHjRv3/vvvgx5j8k7IFO3mN2nSpGnTps2ePRvGMzoI
dBNut7u+vp52ZYGNzXtBs1iFNvyIVk97EezduxeW0rZt2+jQOtrx77PPPvv0008tFgtt
+mfOOyFTyBoyCItx/vz56BdWrFixdu1aOkMEXQbvWMViFSwedTv+7dy5c/v27YDDhg0b
YEGtXLkSnIQ1tWTJkkV5KmRN3s3P5XJt3bqVNsmn/Qd4s1MWq2D9axiQR44cETYksOD1
emFGghKbN28GLoDKtXkt5JF28/vyyy/RO+zYsQN2I7GR9h/gXVlYrMI0IOX9rGjHP9rD
qqGhAaCAHbVdFe37l2dCpih39fX1yKzYzQ8+NW1aJTZmYc+axSpMA1Js0kI7WYEM8LVp
xz943F9//XV+7+bnV0VURMYJjDIb2XRksQqckAKS5GtDhyQdzFOJDNJufrT/swxGZiOL
xRLb/R1TFYpRvu7gJ0vs5scONYvFSkJL3tCPxWKxWCwWi8VisVgsFovFYrFYLBaLxWKx
WCwWi8VisVgsFovFYrFYLBaLxWKxWCwWi8VisVgsFovFYrFYLBaLxWKxWCwWi8VisVgs
FovFYrFYLBaLxWKxWCwWi8VisVgsFovFYrFYLBaLxWKxWCwWi8VisVgsFovFYrFYLBaL
xWKxWCwWi8VisVgsFovFYrFYLBaLxWKxWCwWi8VisVgsFovFYrGEnE5nWVlZ/4jwetCg
QXPnzj106BAXTmursbGxvr5+8uTJKPk+qlD+Q4cOXbhwYSAQyOhSeGq9e/fGzw8fPswF
y2KduNA22yVWjx49AE8upVZSbW1tu1QyGo3Hjx9PeSk8KfGTnj17ctmyWG3TQiFYJj6f
j4urZdW9e/d26Sl5J6Xr43DZ5PcFb2GdwkHYtGkTPwUWK5HQTNqlLbh+eZNx0B7MObnM
l02+5IL3nSTxuj4Ol01+X93FQ6FQoZU8i5WmDh8+jNYX61bHbad54LiBBnKOevfufeIX
pBewsTurKisra4b1OGrUKNh1MOp07+OC4hZxE6/D49ChQzMaTqmrq8uekm92YbJYbePo
Ub1FRTUajbGEbGNjo8UFCulylM7gXlwBLIJsslWW0r0l9e/fX06G7OoGAgFAD5eFeZ8y
8bo3k+MRlpvuCo2NjdlQ8idYmCxW2zh6MGASWRon4l+jGTYbRK3aSJt9KZSGfBHRxZB7
CxAlN8x0KdGRMP3EZ2Q96q4ARGdJyZ9IYaJeHVKV6303K/vxSN13rJmRvN0lFyxSukis
r4RaTWEt+LcN+KkbSTgRPohMkQ3Ws2dPeg1ewfwTs1pppiSd4o2beF0vlvw6MoVaxLP2
+Xy4SDomaPKSb0ZhkoMDB1xXUVGB28wkZhUaHmnMR1flhEkZq8OHD6MOo93hIuj08S9e
y7YQGqx8KTTnWJdKxLGcSC7QKOCizlWVJG5QpCeuMZwyOzLYRcpBCdxUGD+ypbRixYp0
hgHT7H1iEy/okc51dKPKJ9gfCYhBugJHrvE08a98iyQln2lhxh350XXxLFaLSK7nsZKB
JgstQu70Y0Wx5aKq69qvbqw+NoIFUJKbM+6VKBYFYIRpETvBlAhNJ5IdWUgPfeT3+ymn
FJUtW0qJmqoOaylnnJN0CunjMf07pix8nVOPLlW4urruNc1I9TQLE9dPGRPFeGS16rhQ
Il9YtrJSRqRQk9FZj6L96lgk2hc1+USz53hfZ/MkD25Ps7Gknx0iQL0q+mGsiyrKM/nE
a0tNEslllQSPuH46IE2z8GODZml4Odb1SO4UZFSYur6Aop5gbabsyFisFjE/dM0BjYh6
8+TGTyKhEcXFI66p+6ZsnMQ2sUT1PyUbYzFFpjJuIfMh/ezIRq8YDUMLxS3gMxKKUaR4
J6XVpCuZdEYC4ya+ZfGYZuHDMo+N+4r7fUHU2MRnWpi6sVNRwnIYAE92s1pQsaSKG/Go
G1yKhSq+g64cPpFsFqIh6GZ5qGmg/idy9GLjMOMqOdgTDRHo2pcwbNLPjgxkaom60YN0
5qDjsj2llZso8WniUXivSW6XfuHLo4XpdGRxE59RYerwLpuIsXOLLFZrW49JDLywGrtL
xgDalC6mQuaebv6FJhZ1V5YN1FjXGJ/CVtGNOKF96fACjtGUJYwKnWFGiY+9r9yU0syO
DBD8Gdu5pD+KqEtP8h8mSbwMB90SG3nuQ2cWojzRc6EYR6lC9mNHGJIUfsoha3m+JlHi
MypM3eNOVDKJhspZrOZJZ8slcZRi/TXhJaFuwwnCv7o6r2t0AJdu2lH2fHUWApxZ+Xay
IYfGrht00nlVAIL8ffwZO0jVjOzI47Tw6eIO06U/iqj7oU8VqAUjCnmH7SRAnSTxSaxH
/AqlnXzKSeimm25Kv/BjLb0kQ8SJEp9RYcp4lEeqdV1hNoTXsvJJunEkclvQKcdO2eia
DL4ZO2WsQ1ZK61Qeo9NZCLqqrnPQdu7cGUt1XcwbjfbTLXQXjw1KTCc7okySjNGlGU8Y
C424ohwlSXxcPOqM9nR07733pl/4+DTRgG3sgsFEic+oMHW2Zdz+lPHIanHp6rlMGN0E
pdwqk8eeya01SSSGztrRtSM5JbGzMGgIuqV5IqwuroeVfKwvzewkmuXPdK48zVE+4S0m
SXzckbd2mcvtdmdU+HE7vrhDBIkSn1Fh6m5HPXWsYcx4ZLXq8KNuQxW5Zxe7UiS3snT0
S7I7TfIoHTF4FTtPKtyrRBcHk3UZ0Zkfso2XfnbizpWjkcp0Tbl3Rzoo1tEmSeLlEhCr
UVLOtQEvNPeEsqWCyrTw4+Ix7oqVRInPtDDj9oaJwsNYrJaSbODpPGgZj4S7RBtF4ptx
l60lgk9sWGDcGeSULnnsREzcW+j8TTHTlFF2dPO/giTyRVLGliRJMG4KZIEbuKY8Q5Qo
8To8ilvLTEMh6KZm4tq3zSh8Xd+UaBFlosQ3ozBTdihsPbJaXImG93UVmCp23PlNYTbI
l6K6Gmt+JJpkjB1KimtQxW4+gLuDKomGsMgQ0rlyIjIko+zErkYnAy82RiW5uQ7LDTeK
5WSiaMlEiQ8nXQsj23Ip43+aUfg6PCYKK0qU+GYUJspH95RxcfkdxiOrxSVPXouhdd26
P6qoOkuAmjPMDFRR8uxEkxEVO1G7i5uSJKP0+Chl2AaSF3eiNnamKa5hkzI7sf4gLV1M
PqmURLrUponHRExLQmb5ConMvEwLX4fHRE8nUeKbXZjo78jATtQjs1gtKLkCUxOLDUKj
Tl+ebyU3XLYwZWNGdmxjB+ETLbhL5IlntGFF3H1fdWkgyyrT7CTaMrHZeNTZ54nWicdN
fKxHnCYeE30t08LX4THRlmKJEt9ShSknm/HIalU8UnRx3G5dxxPayUdENuJXMlRlVys2
5DiRIxYbkYI2mGQHHlw57qe6EcVYPFI7yjQ7iabydVE66TdSHd8STevETXzsfZPgUT47
I1EIeqaFn+aulYkS3+zCxKNBbxV3A5822/+cVTiK7ccTVXtdC4IHelgVzX7KDUG3A4/O
cUtyFJTu7rrt1IAsOKTkxwmzQTedFOu0oo3HXeOcaXZ0ho0YRtNRLiMbRjcDEvcolkQL
tNM/ikv+ZpIVOukXflynIO7MdZqJT7Mw5fEEmmOSr8NHjLFa23pMbhLEHZii87KTREfr
oh+TjCLGshoXpxVw4iJ4oQvXFBcE3HQzzhTvoZshEsnLKDuyYSPHP+tadEabxiRZRiSU
KPE6Oz/J6TlpTh6lWfiJqk1c4y1R4ptXmDIeaetIuY87kX2bWay4/l2iMfm4tT3NfXLk
32a6uiF2nWNsWGNsMuLu5SsMP90uCgKnmWaH2IsEyFnQZTAjFy92+UysDZYo8TojOckI
bfoDeukUfiI8xjXeEiW+2YUpQE1rzOWhG8Yjq2UVd1UL3kyyJVc6a9bkgXpd20wnfDf5
SuGU63Hithcke7IqXSvONDtxJZM50xGwdHql2MTHRiomOSM1I/c/ncIPxwvgTFRnEpV8
8woTd4FTE3fLiyQHWLBYmSpu1E06u3KhTuJraCCJgodlE0jnP6a561TswaaEVrE2JOU2
tol2sDnB7MQV7kWHLyQ5eyLNwY0ksyHJu7bkGczoFikLPxxzVHoLoimjwpSzxvs9slpW
ZCrQgFuzR7aBWZguotPXzcDqmJPR0BzNTUN4EcsovBnrDCIZAM6JHF2XPDut9xQyQnpY
nSsR0TXJg0J1eEzTvk1e+GF19pnGNNrGbAOQKW4/UdaafSwFi9XaEsNow4YNE7PJupH5
1kANGgiaDFox/m3BAz1FdvIgXKR5eMwqyTa2bP2y9cjKIW/9+9//vujKY+cdkoyPZWd2
8uYAZTmKOxe3jdWNiMaNjWc8srKcJ0kGA+Men8pqezxm5MJniXRBR/DoqeeS3ZM2GAZh
sU5ESZbu5o0llouSR4BzNAAmdrZIN/LMgT2sLJcuKptXNGSJ5LG7HMVIylgF7n9ZWa64
2+ynf4Qfq5Ukh1flrpXV2NgYd8NM+CxxDx1msbKQkD169KCQj969e3O9zQbJq1cy2gEp
OyEJZ4RCzWtra3Nrvo/FYmWhnE5nnz59Bg0alDLKncVisVgsFovFYhWs/j9Kj3N/CmVu
ZHN0cmVhbQplbmRvYmoKMTY2IDAgb2JqCjQ4MTQ2CmVuZG9iagoxNjggMCBvYmoKPDwg
L0xlbmd0aCAxNjkgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk
dGggMjU2IC9IZWlnaHQKMSAvQ29sb3JTcGFjZSAvRGV2aWNlR3JheSAvQml0c1BlckNv
bXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42vv/f2QDAAgA
/wEKZW5kc3RyZWFtCmVuZG9iagoxNjkgMCBvYmoKMTIKZW5kb2JqCjE3MSAwIG9iago8
PCAvTGVuZ3RoIDE3MyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnja
jZRNb9swDIbv/hU8Zoco/NLXtd0K7DBgwwLsXATpsKJpm6TD/v4ouY28yQkqB7AVPHpJ
vya5h2+wBwn2c2jLR4iM4BXhsIUf8Air6yPB5ghUr+OmwD6OdKjwcqSHu3drIaAjz1mJ
kj0GlrKRor63PUuua8BKvm2LNI7KGTY7uFqDr0S5kUcE9gTrHaxuyNk/sL6DBeMHWN8P
n9aW3Hx6kl1R11OSX7eHzfb55fftAxx+2REfxKHlkEqsYakO45iPJhepHtXkXUqIWvJa
fd6xwMensxFfDRlmzNXoPFtEdVrl0GkN5hWW43NCjeV47/Zw3u1iMtbF/5sM500eRpNJ
pELl7rMAk+hoM59s/l5c/ocMiVwW0ooPhi+eOyaasxJ95pPm4raDkhRPUqKmtOug7M2F
xKJNCXooiyMOzE3puoMIU3ZK2t5z8dRDFNEln3JTeuwh9uwExTellxkoBxdRJ2936CGx
UvOZwsWcVOzDSZgoPcxAIZpRSJd8sl5SM+rk5bD40jOBvKOMsQltZyDzUlRCUzr2UKkC
zWFi0wxUqiBonuTUVwplIpeQJ0XwcwayKmANuSn1iTOaTaUjLtnEZDapSmpKNzNQHQ1p
klP/VdiWNQtTU+q/L4uFkxgmjv+p0Gm2cckngXLt38iglK11rOkH5XB2vlWK3kZBITuh
16mmNtUGi/UXU+FK4wplbmRzdHJlYW0KZW5kb2JqCjE3MyAwIG9iago1MjUKZW5kb2Jq
CjE3MCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDE2NyAwIFIgL1Jlc291cmNl
cyAxNzIgMCBSIC9Db250ZW50cyAxNzEgMCBSCi9NZWRpYUJveCBbMCAwIDc5MiA2MTJd
ID4+CmVuZG9iagoxNzIgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFn
ZUIgL0ltYWdlQyAvSW1hZ2VJIF0gL0NvbG9yU3BhY2UgPDwgL0NzMQo1IDAgUiA+PiAv
Rm9udCA8PCAvRjEuMCA2IDAgUiAvRjIuMCA5IDAgUiA+PiAvWE9iamVjdCA8PCAvSW0y
MyAxNzQgMCBSCi9JbTI0IDE3NiAwIFIgPj4gPj4KZW5kb2JqCjE3NCAwIG9iago8PCAv
TGVuZ3RoIDE3NSAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0
aCAyNTYgL0hlaWdodAoxIC9Db2xvclNwYWNlIDUgMCBSIC9TTWFzayAxNzggMCBSIC9C
aXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnja
bcJ7MNMBAADg/uuuu67rurq6urrqyps88wh5JHmEIhyicCRROJIkiqIokkj89n7YxryG
YZ7zGPOe2WZjbPPaZjaPeZR+uCvd9d13QAU4qAIcUgUOqwFH1ICj6sAxDeC4JnBCC3JS
C3JKG3JaB3LmCuSsLuScHuS8HvSCPvSiAfSSIfSyEVTlKlTVGKZuAtMwhWmawbTN4DrX
4FfM4boWcH1LuMF1hKEVwsgaYWyDMLFFmt5Amtkhze1RFrdQlg4oK0eUtRPaxhltextt
54K56Yqxd8M43ME6umOdPLDO90pcPEtcvXBu3ri7Pjh3X7yHH97zPsHLn+AdQPB5WOob
WOoXVOYfXBYQQnwQSgx8RAwKKw8OLw95UhEaUREWWfn4WWV4VFVEdFVkTPXT2OqoOFL0
c1JMfE1sQk3cy9r4xLoXSXUJr8mJyeRXKfVJb+uTUxtS0hrevG9MTaekZVDefWhKz2zK
yGr++KklM7slK6f185fW7Ny2nLz23G/tX/OpeQXU/MKOgh+d34s6C4u7iiBdxdBuAEaD
wmkwZA8c1YtA96IwdHQJHYPrw+L7cYR+fOkAgThYWj5IrBgqrxyqqBqurB6pIo2Qahk1
daO15NG6eia5gVnfONZAYVGaWE3N7OYWdksbp7Wd00Ydb+/gUju5HV28zm5eF22iu2eC
1jvZQ+f39vHpfVN9/VP9A9MDg9ODQ4KhYcHwiHCEIWSMihhM0Shzhjk2M8aaZbFn2Zw5
Dnh8fpw7z+Ut8CZ2TkyKJ/liPl/Cn5JMTUunBVIBWLgoFC6KRDLRjGwGPLs0O7c0B56X
z4MX5AsLCrFYIZYoJJJliXRZCl5cWdwtk62Cl5Z2y9fkYMWaYqdSsaxcBq8oV1bWd66u
r+5d21jbq9xQ7twEr6//vbEB3tq7ubn/z62tf+7z68//2t7e/g0SGRtxCmVuZHN0cmVh
bQplbmRvYmoKMTc1IDAgb2JqCjcwNwplbmRvYmoKMTc2IDAgb2JqCjw8IC9MZW5ndGgg
MTc3IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUyNSAv
SGVpZ2h0CjUzMyAvQ29sb3JTcGFjZSA1IDAgUiAvSW50ZXJwb2xhdGUgdHJ1ZSAvQml0
c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42uy9
B1gVV/e+HQQUQUEUBBsoQbGgIioGK0XAgr0HUNHE/oqCDQsvggVECSKggoLYMErsJcYS
e4lJFHsiGLGCqIAE6fh/PvYv8533HDCIHZ/74uKavWdmz95r1qxnr5lzzrx8SQghhBBC
CCGEEEJIueXixYtLly7Ff5qC0A8J/ZB+qGgTFRWVL774Av9pGUI/JPRD+qEcixYt+uIf
sEyDEPohoR/SD2X573//K5kFyzQIoR8S+iH9kGYh9ENC6Ic0C6EfEkI/pFkI/ZAQ+iHN
QuiHhNAPaRZCP6QfEvohzUII/ZDQD2kWQuiHhH5IsxBCPyT0Q5qFEPohoR/SLDQLoR8S
Qj+kWQj9kBD6Ic1C6IeE0A9pFkI/JIR+SLMQ+iEh9EOahRD6IaEflo0vl39de+kAmoXw
8iSEfkiZIIR+SOiHlAlC3tAPCwoKaCjyGcbDwsJCygQhr/BDXCMnT578+uuvzc3NaSjy
GcbDx48fUyYIKdYPb9265enpqaurW6VKlQoVKqioqNBQhNkEZYLw8pw5c2ZISEjTpk3V
1NQqVqwo1VetWvVzMEVeXl5GRsZrzSrLTGpqqmwxJSUlPz9fbpvMzEx0iTLxEUKZIJ+t
TAB1dfUvFIBk1KpVq06dOvXq1atfv76RkZGxsXGjRo2aNGnSrFmz5s2bm5mZmZubt2nT
pl27dpaWlh06dOjcubOVlZWNjY2dnZ2Dg0P37t179uzZu3fvvn379u/ff9CgQUOGDBk2
bJizs/Pw4cNHjhw5evTob7/9duzYsRMmTJg0adLkyZOnTJni4eExffp0iNfs2bPnzp3r
5eU1f/58X1/fhQsX+vn5LVmyZOnSpd99993y5ctXrFgRGhq6atWq8PDwNWvWREVFRUdH
b9iwYfPmzVu2bNm6desPP/ywY8eOXbt27d+/X84CGBT6iWNh7MibHB0dEZ8l4cBBtbS0
YIRq1aotW7YM08uDBw9iMxxRaqFVq1bt27eXiosWLcIGZ86ckTtQcHAw6tExGA0NGhoa
YpsLFy5Al0X76J7Y8tmzZzAXxBoCjf5cu3ZN1MfGxo4YMUJfX1/lH548eUKZoEwQ8t78
cNq0aYjDNWvWrFKlipKSklSvqan54MGDe/fuJSYm3r59Oz4+/s8//7x58ybC15UrV+Li
4n7//fdff/31l19+OXv27OnTp0+ePHns2LGjR48ePnwYQfXAgQP79u3bs2fPzp07t2/f
jlj3/fffx8TEbNq0af369evWrYuMjIyIiFi9evXKlSuRziCcBgUFBQYGBgQE+Pv7L168
eMGCBT4+Pt7e3vPmzZszZ46np+eMGTPQW3d3dzc3t//85z8TJ04cP378mDFjvvnmm1Gj
RiGWuri4ODk5DR06dPDgwQMHDuzXr1+fPn169eoFqZKzABQQY4ROocOQJCxDocQqHAtF
iBe6jWaxDOmBUkAfIZTiyf7x48eFlRDwUczNza1duzYUU9HUGBQ2MzExgR0gFpAnCBDa
gQXWrl0LFa5evbpIZzBS2B+St23bNnQe26MSRewOkcUpw8Y4BA6tmG6gAxgLTDFu3Dho
LowDE02dOhU6CKPNmjULmgszohGcaxgWogbNhakhgtBcGB+nICwsDJqLk4KOQXNxmjZu
3AjNxYlDl6C56NLu3bv37t2Lk4tTfOjQoSNHjuCknzhx4tSpU3CD8+fPwyBwjEuXLl2+
fBmucuPGjT/++APOAxe6c+fO3bt34VSPHj1KTk6G2KFvlAnKBPmEZnG43hGOKlWqpKGh
gXptbe1ybAHIBDIg2SJSISy8ePECaRTyIGmVqakpEgcsQNFgFjH5RxiHqmLmj7QIRWgf
ViGoliQTCJuiCI1DEWFWFKGDKJ47d046KYjPYpW4Q96jRw90QNQgP8IGCL+KR8nPz0d4
R5BHqEfAR6qF4A8JgBBADiAKkAYIBA4BsYBkQDgQoiEikBIIClI5iAskBkIDuXF1dYXm
Iun7+uuvoblIAwcMGADNhdoizUGXkCoiYbS1tbW2tobdOnbsiMQKSWXbtm1bt26NNLNF
ixboNoQV+tiwYUOkokhIDQwM6tatC1Pr6enp6upCH+FslAnKBPnkkv309HRM7zE3NjQ0
LN8y0bVrV6mIuIcIhoWLFy/CJpi3t/yHGjVqqKurCwXR0dFBYMSUWFlZGXEV4RSB7vHj
xwiPsBim9CXJxPXr10URKoAiJuGiiJk5iiJxSEpKQmhFESKFybbYADkOIurz58+xjDiP
tZiZfw5+SJmgTJCP//JMS0v7fGSiV69eqMFCQkICbAIJuP2/iM0wFcdabCwiv9AUUVy4
cGGxB5KTiZiYGFmZQFqB4o4dO0QxKysLh1BVVYVO3bp1CzUQBUzIkd/hP7YcOXLk5+aH
lAnGK8LL86OSCbFKX18/JydHWov0QSw8evRIfBjM1tZW1HTq1AnFypUrl/RYufQykZKS
IirPnz8vPSspLCycPXs2MjsPD4+DBw+Ws+880g9pFkI//BRlIiIiAmZBcdq0aQEBAYMG
Dapfv760JebzsvP/bdu2oThmzJiSDlR6mbCyskLjsbGxXl5eqAwNDUXltWvXsIwUA4kG
/ZCXJyH0w49BJkBISIiZmZlSEY0bN163bp20Ki4uDnN76fsOWDAwMJBU4E1kAlsii0FR
S0vL2dlZ6MLTp0/RE1RqaGjY2dl99913smkO/ZCXJyH0ww9IWlpasXN46e5QscU3JDk5
WXoUfv/+/apVq7Zs2XLRokXe3t7dunUTH+KlH/LyJIR+SEBoaChOkPQ9OwClQFpRbp5Q
0A9pFkI/JG/C6dOnlZSUBg4cuHfv3l9++SUiIgLJhYWFBf2Qlych9EMi2L59+4ABA3R0
dKAXzZs3nzx58v379+mHvDwJoR8SWQoLC9PT0+mHvDwJoR8S+iGhWQj9kBD6Ic1C6IeE
0A9pFkI/JIR+SLMQ+iEh9EOahdAPCaEf0iyE0A8J/ZBmIYR+SOiHNAshb8jPP//s/Q9Y
pkEI4yHNQgghjIc0CyGEMB7SLIQQwnhIsxBCCOPhx0N2Xs7dtOTCwkKahbwJzZo169Ch
w4fanRDKxLsgMS1pwPdeqj62X3hbafs5rrqwi2YhlAlCKBMSzj8sUJ5v03HtJJt1U5W8
rSAWmy8fplnIxywTt27doqkJZeK9Mf2nlb89/EMsH7n9G2SiRdgomoXIkZOTk5SUJPcC
4mfPnsnVFBvnHz9+nJGRUQaZyMvLk3sTTWFh4cSJE728vBT3/buIfz1EZmYmmi3lqBU7
IGeTFy9eyBZhkLIdvVjzlgYMWW6vUtqBUCZKT35BvmyxYbCT+gIHmoVIXLt2rXPnzioq
KjhfNWrU2LRpEyp37NhhYGCAGn19/XHjxj1//lwxzufn5y9evFhHR0ec6/bt26MG9fXq
1evbt6/Ufs+ePRs0aCC3O+LtkCFDKlWqpKys3KVLl507d4qg7eTkhKYqVKigUkRqairq
4+LiLCwsKhTRqVOnhISEYgeCNnEsNTW1qlWrOjo6Ylyo1NDQEE3VqVPHxsZm165d0saK
HRBgRAMGDHB3d69cuXLFihVdXV2zs7Pd3NzU1dXRN7RcbJQu9uglmRdAgObOnQuDoIem
pqa4UnAUsero0aPYfsuWLfPnz0cfdHV1Dxw4UHo7EMrEv5KSkvKKtXoB/ZqEDKdMEEFy
crK2traqqurQoUODgoKsra3nzZuHeiMjI4TKlStXirjt6empKBNz5szBKmNjY39//0mT
JkFQcnNzUV+rVq1evXpJh+jWrRuEQ2739evX161bF1lDYGAg1iK6pqWlXblyxdfXF206
ODgEFYHIiVSlWrVqJiYm6ExYWNiXX36J5WJn7N7e3kpKSuHh4du2bRs4cKCI/BACBGEf
H5+xY8diAY3jECV1QLSDw6Gd6dOnI1xDI4RWYmHfvn0uLi4oLlq0qJRHL8m8SC5at26N
piwtLSEWomOwjNDZI0eOoGhvbw/lnT17NsTlwoULpbcDoUy8Ccf+uviFt9WcI2toFiJA
MMRp2rx58/+ffhZFqoMHD4oiIr+WlpaUHUhxHvN8zLQbN24sfXxOujdSGpm4ePEi4p6o
XLJkCfpw6dIlLCclJWFZ9qYT4ipqzp8/L4oIwihKSYGi40VFRUn3r4RMDB48WLrzY2tr
i4n6w4cPS+qAkAlpvOnp6Qj+7dq1E0XIFqb3GFEpj16SeZGFoT40NFSqx5BRs2LFCkkm
pIOi269lB0KZKDN5BfmmoSM1FnZLyUyjWYjAzs5OU1NT9g68LIhXmIQj0nbv3l0uzp8+
fRrnd+HChYp7lUYmpFwmODjYzMxMCoCKMtGnTx9lZeWW/4AWsAHyF8XjYl8xLUdv0bKo
lJUJsGnTJmyAvKCkDgiZkN3F0NCwU6dOUrFNmzbYvpRHL8m8SJeqVKki+0AHmgXZRQYn
yURAQIDsLqW3A6FMlJnFJzchlVhxfjvNQiQwu9bQ0FB8AH3jxo2OHTt27twZaUWDBg0U
ZeLkyZMlnd/atWsjDP6rTCDEQVDmz58vJvMlyYSLiwtCfVxc3G0ZSnqUnJWVhVm3qqpq
nTp1xMel5GQiLCwM7e/evbukDijKhImJiaxMYJKPKF3Ko5dkXisrK21tbVn5QHaGPEXY
WchETEyM7C6vZQdCmSgDJ+7Eqcy36Rsz5z18w44y8Qkxbdo0nKbVq1crxjEglo2NjRVl
AmFNRUXFwMBA8fZ4kyZNoBRSEXKjKBPHjh3DcfEfyxs3bpSidHp6OpYnT54s7Y6+oQZz
fqkmNzf30aNHimORnsqhKewyZcoURZmwtLSsUKHCvXv3SupAmWWi2KOXZF5PT0/UR0ZG
SjVBQUGo8fHxKUkmSm8HQpkoA0kZT2st7W8aOjIj5wXNQuRulVSvXh2R09raGpFq/Pjx
Ir4hgzA1NUUU2r59u5aWFqLrhQsXXhb3CFtPT8/NzQ0zc0jJ1atXUT969GjUz5o169Ch
Q6NGjcKyokxER0ejftWqVYmJiUOHDsXyli1b4uPjsQrTbKhMeHg4eoJAmpaWhr3QQzs7
O/RwxowZRkZGa9euVRwLdG3kyJGxsbHiPr+48w+ZgMwhiYiKirKwsED91KlTX92BsslE
sUcvybwYlKGhIert7e2XLVuGtUpKSg0bNhSfoSpWJkpvB0KZeF3yC/Kt1035wtuq9eox
vTZ7ir9RO/0/c7MQievXr9vY2KiqquJ86ejoILyjcsOGDVjW19dHWENgFx8Efanwgdil
S5fq6upiLTILyIq40/L8+XMHBwcENHV1dQ8PD1tbW0WZyMzMRGxUVlbGoefOnYuNNTU1
ER6xaufOnebm5mizfv36iLqoweS/X79+kA9Uok0XF5e7d+8qDgTBEx3GNtA1Z2fnrKws
IRNoWUNDA/VowdfXV6Q/r+hA2WSi2KOXZF7w8OHDQYMGqampoR7dGz58uPREo1iZKL0d
CGXidZn6Y8gXRV++lv2rFziIMkFkyc3NlcKUICcnR3wsp7CwUPpQULGkpKRIUVEiPT1d
fD72FSBWS1NluRbENyZkKSgoePWHvQUYhexxxU0n7IuJ/Wt1oGzIHf0V5pWkFinba90K
LqUdCGWCZiGkNMg9myCE8ZBmIYQyQRgPaRZCKBOE8ZBmIeTNSUxM5J18wnhIsxCiSEBA
QK1/kPtGMyGMhzQLIfRDQj+kWQihHxL6Ic1CCP2Q0A9pFkLoh4R+SLMQQj8k9ENCsxD6
ISH0Q5qF0A8JoR/SLIR+SAj9kGYh9ENC6Ic0C6Ef0iCEfkizEEI/JPRDmoUQ+iGhH9Is
hNAPCf2QZiGEfkjohzQLzULoh4R+SD+kWQj9kBD6Ic1C6IeE0A9pFkI/JIR+SLMQ+iEh
9EOahdAP6YeEfkizkFfz6NGj3Nxc+iH9kNAPaRaSnp7+999/S8UTJ07Ur18fp6BatWrD
hw/PzMx8Wwd68OAB/ZAQ+iHN8snRtGnTdu3aieXU1FRtbe2GDRuuWbNm/vz5OBErV658
K0fZunUrWtu/fz/9kBD6Ic3ykRMfHy9bjIyMjImJkZZh/B07dojitm3bDh48WOYD3bp1
S1q+f//+zJkzHz9+TD8khH748ZsFc+Zi6/8u4t0dKCUlJT8/X26bzMzMvLy8Mh8C+2Zk
ZJR++7i4OH19/cLCwmLXzpkzB8ZPTk5+RQsI9XJHRB/S09Nla9D+xIkTvby83tGZ4uVJ
GA9plrduloiICBUVleXLlzdr1gztI1T+8MMPssHTwsKiQhGdOnVKSEjALBrbr1ixQtqm
VatW7du3l4qLFi3CBmfOnJE7UHBwMOqjo6PFgQwNDbHNhQsXmjZtKm7479q1S2z57Nmz
nj17qqmpVa1a1dHR8dq1a6I+NjZ2xIgR6KHKPzx58kTuKPXq1bOxsfHw8FBXV8cG2F32
IcLZs2ft7e11dXVr1qzZrVs3HF3Unz59Gh1AN0Sz7u7uqGzRokXnzp2x0LFjR8n+jRs3
Rg32bdOmjdgXArd48WIdHR2xAUyBGgxhyJAhlSpVUlZW7tKly86dO4VqODk5YRsYUxwI
0R6DwsLhw4dFay9evJg7dy5MpKGhYWpqitOdnZ1dmjPFy5MwHtIs78gsq1evRrO1a9fe
tGkTQhZCU8WKFcU9EPxH8DQxMVm5cmVYWNiXX36J5dzc3CZNmhgbGxcUFGCb48ePi46J
kIu1aEoKobIEBQVhM7SAmAmxQDzX0tJCO+vWrVu7dm2dOnWqV68uZuPe3t5KSkrh4eHb
tm0bOHCgiLEoYvf+/fvDAtgYh8ChFdONWrVqYbPRo0cfPXp05syZWJ4yZYpYtXXrVsRn
jAjzeWdnZ+gIYviePXtEBEZ4x8ZBRaBlVCIad+jQAQuI4d27d8dadHXfvn1yMiESDQzE
399/0qRJiN4wwvr16+vWrYusITAwECOF5KWlpV25csXX1xcbOzg4iANBAjBG1Bw6dAhN
5eTktG7dGkVLS0uIBc4FltEHkWq94kzx8iSMhzTLu5YJ6U67KCLGYnnevHlYPn/+vFgl
Ahrm/GIbMflHGK9SpQrC4PDhw1FEBMOqjRs3liQTly5dEkXM2FE8cOCAKPr4+KB47tw5
abxRUVHSjRr879GjBwKjFPCxweXLlxWPAplAjJUtiowAOYW2traBgQGm61LOAsnQ09MT
WjNu3Di0KXvTSZIJMHXqVKyVEhNJJpAOIFYjxZB2FOp58eJFKYAvWbJEGnhSUhKWZW86
ycoEshIsh4aGSmuxJWpE7vaKM8XLkzAe0izvWiZOnTol3ZZBcc2aNVju06cP5tst/0Hc
68CcGZFWR0fH2tr67t272GDChAmurq6VKlVCYGzbti2mu8V+s0DIxPXr10URKoDikSNH
RHHv3r0oisQBsVRMpDGHlx4HICnQ1dV9/vw5lsVnjeSeOEu60LVrV6mIeTtm9dK45KyH
NlGJSX6ZZeL06dOoX7hwYbG2ReeDg4PNzMwktX21TKC30FzZBxwwKWRowIABrz5TvDwJ
4yHN8t5k4rfffkMRlVh2cXFB8I+Li7stAybhUqLRq1cvEfkxeZaKJcVMOZmIiYmRlQmk
FbIfJcrKysIhVFVV69SpIz4XBFEwMTHR0NDAf2w5cuTIYo8iJxPoEmqwcOzYMezl5+cn
u7Gnp6cUwMsmEydPnizppEBPcWgomsgmSiMTVlZWSHmkfEdkK5UrV4ZcvvpM8fIkjIc0
yweRCbEK82FpY6QJjx49eln0ZWTMcrHW1tZWrOrUqROKiGmKj5VfVyZSUlJEJUKr9HAB
AXz27NmGhoYeHh4HDx4U93ZKLxNpaWlqampGRkbS44zs7Gx9fX11dXVIkiQEQgRf66aT
ioqKgYGB3FMSoUr4j+WNGzdKMpGeno7lyZMnFysTQrYiIyPljObj40OZIOST88PsvJz4
p/dz8nM/dbO8IvggtCJUVqhQwc7ODvFqxowZCLNr164VW2I+L/dVAhTHjBlT0oFKLxOY
VKPx2NhYcWde3Ku/du0alpFiiKheEiXJhNQBFDEQd3d3XV1dFMPDw2XXjhgxIiwszNHR
sZQy8fKfR9h6enpubm7IIDDzv3r1anR0NCpXrVqVmJg4dOhQLG/ZskXcJUO+ULt2bRwX
8gdFkJUJGBw6CIPb29svW7bM2tpaSUmpYcOG4tPIlAlCPhU/hDR0WDupkq/dF95Wqj62
bgdW5ObnfVizIIzcuHHjrcsEuHfvXr9+/RDZUImJt4uLy927d8WquLg4xDTp+w5YwKRa
UoE3kQlsiXk+ilpaWs7OzkIXnj59Km7ya2hoQLa+++67nJyc15IJMbEXP7iB8NuoUSMo
kbQqIyPD1dVVU1OzUqVKaL/0MoGBL126VIgOMgtTU9Nbt25hSwR5ZWVlGxubuXPnIvKj
ZTHYnTt3mpubY2P0BB2QlQnw8OHDQYMGIfERIx0+fLj0dIYyQcin4oeZuVn1Agd9s2vJ
xH1B+gH9IBZzjqz5IGYpKCg4ePAgwriqqipWvbsO4EDSjSBZ5CqL3abMIDxKj8Lv379f
tWrVli1bLlq0yNvbG1FafOq1bC2npqaW9M27rCLK1iyGL7evJCtIE+RWvfr7cZCeR48e
lfRdP16ehDLxCflhwrMHyvNtGgU7v2ezXL58efLkyZigInhiYixmnuXYMUJDQzFG6Xt2
Yj6PIZf0hILw8iT0w/fJKyZ1WXk51f16NQkZ/t7M0qVLFwMDA/EV4y9kQMzcvXv3vn37
Dhw4gBTj0KFDR48ePXbs2IkTJ06fPn327Nnz58//+uuvv//++6VLl65cuYKQe+PGjT//
/DM+Pv727dt37ty5d+/egwcPMIl9/PjxkydPnj17lp6ejlk3psTZ2dmY2Cv+nsZ7A0OA
Gg4cOHDv3r2//PJLREQE9NHCwoKXDC9PQj/8GCj2i655BfmnEi+P3rXkC2+rBcfXvzez
iJv24t61LKhxdHTs3r27g4ODnZ2dra2tlZVV586dO3bsaGlp2a5du7Zt25qbm5uZmbVo
0aJZs2ZNmjQxMTExNjY2MjKqX78+pKdOnTq1atXS09PT0dGpXr16tWrVEIqhPpUrV65Y
sSJUqUKFCuKuvrKysqqqKo4ItapSpYqWlpa2tnaNGjVq1qyJ7tWuXbtevXqGhoYNGjRA
+40aNWrcuHHTpk2bN2/esmXLVq1atWnTBhH+q6++6tChQ6dOnSB8NjY2Xbt2tbe3R/97
9uzZq1evPn369O/fH7owePDgYcOGOTk5YTO0WalSJfQB3UNrI0aMQEo1ZcoUd3f3adOm
zZw509PTc86cOV5eXt7e3j4+PgsXLly8eLG/v//SpUsDAwODgoJWrFiBxGTlypWrV69e
s2ZNZGTkunXrNmzYsGnTppiYmK1bt8bGxm7fvn3Xrl179uyB5v74448//fTT4cOHobnH
jx8/efIkBOvcuXOQKmjuxYsX4+LioLnXr1+/efMmNDchIeGvv/5KTEyE5j58+DApKQnO
8/Tp09TUVPGz5C9evIDm5uXlfYp5EGWC0A9fK5s4evt3CAT+em32fM9mwYR/0aJFiMYI
0eKOk/hNpPdjDcQ3RLmcnBxEPMS958+fIwYiEqakpCAqIjbev38fcRLREjETkRPxE1H0
6tWriKiIq7/99htiLCLtmTNnEHURe3/++WfEYURjxGREZsRnROkdO3YgYiNub9myBTEc
kTw6OhpRHXnE8uXLEecR7RHzEfkR/6ECS5YsgSJAF3x9faERUIq5c+dCNaAd06dPh45A
TaApEydOHD9+/NixY7/99ttRo0aNHDly+PDh0CAo0ZAhQ6BK0Ka+fftCp6BW0CwoF/QL
KgbNhaJB16C50DgoHTQXqge1guZCB6GG0EQoI7QMKgnNhWJCN6G50FAoKTQXqgptheZC
Z8WJEz/uhBrUQ5GxDbaECGIv7AvVRjtoDToONUf7UHboO46I40Lx0Qf0BHMA9Ap9w6wA
/URvMU/AbAH9x8yhd+/eGBHGNWjQIIwRI3V2dsaoMfbRo0fDDrDGhAkTJk2aBPtMnTrV
w8MDFoPdZs+eDRvCkvPnz4dVYVvMPSgThDJReuKf3h+09b86/r2hFF5HIz+IWU6dOiV+
Xw7xR1NTk/7zyZGfn5+bm4v8ApqbkZGBjAOa++TJE+Qg0NwHDx4gK4Hm3r59Oz4+Hpp7
48aNa9euIX+B5v7+++/IaKC5Z8+eRY4DzT127BiyHmjuwYMHDxw4AM3dvXv3zp07kR9B
c7///ntkTNDc9evXI4cSmousCpobEhISHBwMzV22bFlAQADyL2juggULkJFBc+fNm4cc
DZorfvaKMkEoE6/Fg+cpFX26qi9wKCgs+FBmQXgJCwsr6bvPhPCmE6Efflgs10xAQvH4
71SahfDyJIR+CP5KfSSJArIJVR9bbT/H8mGW69ev8yOmnyJ37tx5u++NokwQysSbsPny
YfUFDg4bpg/83ktjYTekEktOxZQDs6xZs0b8xJz4TE6Z25H98nLpEb+hXeyPvpJ/JSIi
wsHB4V1LPGWCUCZKyeWkhP5b5omH18gjlp7e8k4fTLwfs1y7dk1LS+vmzZtYbtq0abt2
7SgTnxAQCHNzc19fX16ehDLx8VBYWJj897NyYxZLS8uJEyeK5cjIyJiYsudHlIkPwo8/
/qisrPyK39SiTBDKBM1SZsSvz0m/KVcseXl5Jf0O0uPHj2VXva5MJCcnZ2dnFysTxX6x
MTMzU/HdpmXYRpZnz56VdMdGfENEtij7Y+MlkZ6eXhpblR65Bv8uQrYmPz9fR0dn4MCB
vDwJ4yHN8tbb79OnT40aNaTf4mjRooV4MSioV6+ejY2Nh4eH+HkQR0dH6efssD1iO0KT
6Fj79u1FC7Iygd379u0rHahnz54NGjSQ0rGwsLCaNWuKH1YVP0IrZAIR3svLS0tLS3xt
cNmyZeIbjojPaEFNTa1q1aroiexPPMkGfMVt/P39VYqoUqVK8+bNJ0+eLAnQjh07DAwM
xNfbx40bJ96OBzCuAQMGuLu7iy+hu7q6Qsvc3NxgB2yMlkt6fINczNjYGNs0bdp0wYIF
r7bVy6KX0Nnb2+vq6sIU3bp1E68UF1hZWaGR27dvm5qaKikp9e/fHyIVFxdnYWFRoYhO
nTolJCRI248aNUpVVbXYH87l5UkYD2mWNwHB3MHBodh0oFatWuK3WI8ePTpz5kzpJUEv
/3nPAkIigvCkSZMQZsUPusrt3qtXL6llhEEcSywvX74cuyNoh4SExMbGWltbSzIhWh47
duz27dsR+rC8YcMG1Ht7eyNahoeHI/3BtFm8EVWOYrcRqQrUwdPTE8EWIoLeCqUwMjKC
HKxcudLJyQnbYAPRDuQJ7UyfPh0Dh0YIHcHCvn37XFxcUFy0aFGxc36oG8L7gQMH/Pz8
evTo8Wpbbd26FdEex5o4caKzszM0SFlZec+ePWIvqEDdunUhCrA8xLp3797oMzY2MTFB
hyGyX375JZalvAmWxFF+++03Xp6E8ZBmeYukpKSgWYS+kmTC0tJSWoWiSDRSU1Mxx27c
uLH0SybSTZvSyAQ21tTUxOxaCnHSTacXL16gZfGZKwHm0q1atZLsEBUVJeUjJdlKbhvR
uHTf/vDhwyhOmDABywcPHhSViNuI8FLug2gsLSP4QzKkx/pIK5BiYCyKR8/IyNDQ0EBg
T0pKko5ekq2QlyGHQi4j3dRCKoTj6unpCbOIFwLu379fut8l3i0rXoQn3S3ctWuXKEJt
UYyIiODlSRgPaZa3yKFDh9DstGnTSpIJ2bf8IOnA/PZl0U+2lvTa69LIxK1bt0S+IK2S
ZEK8VrtOnTot/6FGjRqYZr8sepE0JANrISLSy3rkKHYbOZkADRs2bNu2rVQ8cuQIOlOp
UiVJnhCuBw8eLG1gaGiIoC0V27RpY2ZmVmwHVqxYgQQB8T86OlrUlGSrs2fPKp5QJGuo
vHLlipAJdEN66Ya4PYh0Q7IMTI2NkaGItadOnUJR+igCL0/CeEizvBVEbBk/fnxpZEJ6
GdzJkydL6ozs7rVr15a9nSXJxP3797H71KlTFWUiISFBTPVv/y9is6ysLMyoVVVVoSPQ
mmJHpLiNnEzk5+djFObm5li+ceNGx44dkSIhrWjQoEFJMmFiYiIrE8gsEKVLMilm+0h/
cMQZM2a8wlbifdl+fn6yleJ12CJfwBFxXNm1SPqgZXFxcbKWkR6p//zzz3KKz8uTMB7S
LG9ORkYGZr+yWlAamUhNTVVRUTEwMFD8QJHs7k2aNIFSSKsQkKVnE2gHU3TpPozsJ52w
Sl9fX/ZRrHizqvR2PERR2ackcvfQFLeRkwkogvTabqsiRL2xsfEbykRaWpqY/MMsvXv3
hlQ9fvy4JFthYzU1NSMjI6k+OzsbA0fqJF51pygT4j2nwcHBUg0O9+jRI7G8ZcsW6TkO
L0/CeEizvEUQixDEXksmXv7zWFZPT8/Nzc3f3x8B9urVq3K7jx49GtvMmjXr0KFD4mG0
JBMbN25EEY0vW7YsKipq0KBBkkxERERgGQfCxDggIACr6tevL0L6yJEjY2Njvby8sEFo
aKjiWIrdRsiEeCY+adKkqkXcu3cPq5BBmJqaItJilZaWlqWlpfisUdlk4siRI9CawMBA
tIZm69atK8SuJFuJ94NjpMg73N3dxQu1w8PDRWuKMgFlgXkh63Z2dtgXe0Fl1q5dK9bC
ktj98uXLvDwJ4yHN8nYZNmwYIo/0suZSykR+fv7SpUtFZMNsGVFR3OGR3f358+cODg5o
HDNkDw8PW1tbSSbA7t27EW81NDSk0UnfmwgJCTEzM1MqonHjxuvWrRNBVbyVCfHc2dm5
2JdWF7uNkAnxqS1lZeX27duLm/8Ac28dHR3sgrwD3RYfdi2zTNy5c8fe3l68v8nc3Fz6
LFZJthJyCREU73tq1KgRBE5qTVEmANStX79+4vPDsKqLi4tItV4WPblAjeyzDF6ehPGQ
Znkr/PTTT2j5+PHjZds9JSWl2IgtkZ6eXrbYhcmzYsvJycn/2prcNtJNp9TUVNnvygkw
4RffYigsLCz2C32vC/os3fsqpa3Qsdf62l1BQYHcIfLy8jQ1NSdPnszLkzAe0izv4hAW
FhY2Njbl1YCKn3QqfyANQV4m7qTx8iSMhzTLW+fq1avq6upHjx6lTHyKIHUyNjYOCQnh
5UkYD2mWd2eWyMhI2W/SUSY+IYKCggYMGMDLkzAe0izv2ix3794tl68lSk9Pv3Pnzrt7
tvvBSUpKys7O5uVJGA9pFpqF0A8J/ZB+SLMQ+iEh9EOahdAPCaEf0iyEfkgI/ZBmIfRD
QuiHNAsh9ENCP6RZCKEfEvohzUII/ZDQD2kWQuiHhH5IsxBCPyT0Q0KzEPohIfRDmoXQ
DwmhH9IshH5ICP2QZiH0Q0LohzQLoR/SIIR+SLMQQj8k9EOahRD6IaEfvlOy83IePE+h
WQgvT0Loh4oUFhYO2vrf0buW0CxvnczMzLt378LCvC54eRLy6fqh19HIL7ytKBNvncWL
F6uoqGC8sbGxb9jU6tWr0c5vv/3G64t+SOiH75ktV45AIygTb50zZ85gpCYmJl5eXleu
XKFMvGdSU1Pph4Qy8eb8cv+Gmq/dsFgfysRbZ/r06RjpzZs3/3XL+Ph4ysRbp0GDBrVq
1Vq5cmV6ejplglAmSkNKivwT6nvpj2st7d9944y7acnvWSaUlJQqVqyopqamrq5epUoV
LS0tbW3tGjVq1KxZU19fv3bt2vXq1TM0NMSVbmxs3KhRo8aNGzdr1qx58+YtW7Zs1apV
mzZtLCwsvvrqqw4dOnTq1KlLly42NjZdu3a1t7fv3r17z549e/Xq1bdv3/79+w8cOHDw
4MHDhg1zcnJycXEZOXLkqFGjvvnmm7Fjx44fP37ixImTJ0+eMmWKu7s7ovrMmTM9PT3n
zJmD+b+3t7ePj8/ChQsXL17s7++/dOnSwMDAoKCgFStWhIaGIviEh4evWbMmMjJy3bp1
GzZsOHnypNx4cVwMTe6pxOPHj+U2i4uLw5CLfXiBjTMyMhRlAvPkUj7s+PvvvwsKCuRq
wOdwGcKdYDGcArgZPOHYsWOUCUKZeC0yc7PMV33bJGR4evbfD56nvGeZmDdvXnZ29osX
LxCynj9/jrj39OlTCFlSUtLDhw/v37+fmJj4119/JSQk/Pnnn5iQX79+/cqVK4ioFy9e
RKj85Zdfzp07d+bMGQTn48eP//zzz4cPH/7pp59+/PHHffv27dmzZ9euXdu3b4+Njd26
deuWLVs2bdqESB4dHY2ojtiOCI84j2iPmI/Ij/gPFYAWQBGgC76+vtAIKMXcuXOhGtAO
KAh0BGoCTYGyQF+gMtAaKA50Z/jw4dAgtCM7WFNTU0ghRqqiooKj5+XloUGoIWqqVau2
bNkyEedPnz6NotgM4CiozM/PR090dHSErdq3b48aIROrVq2CYmJBT08P4yrWzkePHkVT
WDt//vzKlSvr6uoeOHBA6BG0tUIR0FbYVtpl9+7dkFpotOiGhoaGYrNnz54dNGjQkCFD
oLnOzs4YNcY+evTob7/9FtaYMGHCpEmTYJ+pU6d6eHjAYrNmzZo9ezZsiIGjJ7AqbOvn
57dkyRJY+7vvvlu+fDnsHxYWhkHhjKxduzYqKgrnCGdq8+bN6D/O3Q8//LBjxw6czb17
9+7fvx/n99ChQ0eOHMEZP3HixKlTp+AD8IQLFy7AK+Ably9fvnr1Krzljz/+EIYVYMhV
q1aF0SD906ZNo0wQysS/ghg14HsvSMOIHYt9j6+f/tNKLLdePWbhiQ286fRWWL9+fYsW
LRBvIR+QOWQoGDXCKcQL4oJlBENsFhERARVAMagISB4qxcZIo6BciL3INXJzc4VM1KlT
B5ETmojGK1WqBFVVPDSiKLZEYoWWEagxqUYURWKCsGliYgJ9RGT+8ssvsQzxwvYBAQHY
vm3btojtiKJmZmZoWbFZaPf3338fExMD1cPokENBc9F/dAxthoSEBAcHYwhQQDSIni9a
tGjBggVoEJqLWQEGBc2dMWMGojTU0M3N7T//+Q80d9y4cWPGjIHmurq6jhgxAhkfNHfo
0KHIxZAJ9uvXr0+fPsgNe/To0a1bNwzK1tbW2toaotaxY0cMEBkltK9169bIMZFpQp2b
Nm0KJW3YsCGSiC8UwBmRLVImCGWiJA4l/Koy30b2DzKh5G1VeYE9ZeJtgRCHmTwWkDRV
rFixe/fusrkGwppYRpyEQaSbSEissDECnVQj7hoJmcAUWlRi1o0iFKEkmWjXrp0o5uTk
4D8CNSrPnz8vKrdt24YiZunI4CAKCLBIWMQqxOpiZeKTQ1NTU/I3jAiJVbNmzZBCIj2k
TBDKxOvy/m86fVYycfHiRZEItPwHzPDV1dWLlYnTp0+juHDhQrnW5B5hYwHFNWvWlCQT
mNLLVmJOrqysLHUAARPbYM5/6NAhLAQGBkpblhuZgNpiyFWrVq1Zsyayqlu3bn2efkgo
E5SJj18mEhISMOQJEybc/l+KlYmTJ08Wa59iZQKVJclETEyMbKWLiwuCf1xcnGwHnj17
tm/fPmy8YsWK8icTrVu3dnJyQv4l97ifMkEoE5SJj00mQK1atfT19cX9H8Hdu3fFwtSp
U2EQRGzpppOKioqBgYF4cPC2ZELsHhwcLNXk5uY+evTowYMHmHK3adOm/MmE3Ee8KBOE
MkGZ+JhlIiIiAqOGWEybNi0gIGDQoEH169cXq4KCgrAKwTksLMzR0fHlP4+w9fT03Nzc
/P39u3fvfvXq1TeUibS0tGbNmlWoUMHOzg5HnDFjhpGR0dq1a7HK3d0d23fs2HHjxo0/
/vijubl5+ZAJ+iGhH9Isn5BMgJCQEDMzM6UiGjduvG7dOlGfkZHh6uqqqamJ4IwY/rLo
A7FLly7FvuKDsqamprdu3XpDmQD37t1Dl7S1tbFWXV3dxcVFZDQ4nK+vr/j4qKqqKlZR
JgihH9IsHwrM6rOyshTrs4qQq0xJSSl24ze8FaP4RUvBo0eP8vLyys1NJ/ohoR/SLORd
QJkghH5IsxDKBP2Q0A9pFkKZoB8S+iHNQt46T548SUxMpB8SQj+kWQj9kH5I6Ic0CyH0
Q0I/pFkIoR8S+iHNQgj9kNAPaRZC6IeEfkiz0CyEfkjoh/RDmoXQDwmhH9IshH5ICP2Q
ZiH0Q0LohzQLoR8SQj+kWd4zmZmZd+/elXvJJqEfEkI/pFnA4sWLVVRUMNjY2Ng3b61W
rVq9evWiF9EPCf3wfdJvy9wvvK2kvw5rJ31ws5T0/uJPjjNnzmCYJiYmXl5eV65coUzw
8iTkE5WJygvs3Q6sEH9BZ7d9KLMUFhaePHnSycmpdevW5cMHpk+fjmHevHnzX7eMj4+n
TPDyJPTDj1YmdPx7f1iz3Lp1a/bs2TVr1qxataqysrKqqmr58IHBgwdXqVJF7qnE30XI
1sTFxenr6xf78OLx48cZGRmKMpGXl/f8+fNSdiM9PV2xWcXNMjMz0SwvT0Lohx+PTMyc
OTM0NLRZs2aVK1euVKmSVK+pqVkOHMDU1FRJSQnDUVFR2bRpk5ADCwuLCkV06tQpISEB
ladPn65WrZrYDLi7u6MyPz9/8eLFOjo6wiDt27dHjZCJbt26TZ48GRaDnjo4OMgpjoSV
lVXTpk1v374tutG/f/+cnByogJeXl5aWFtrEQZctWya06dmzZz179lRTU4NMOzo6Xrt2
jZcnIZ+tH6akpCjKhPoCB59j0Vuv/pyZm/U+zQI0NDS+UACSgXhYp06devXq1a9f38jI
yNjYuFGjRk2aNIGmNG/e3MzMzNzcvE2bNu3atbO0tOzQoUPnzp0RGG1sbOzs7BA8u3fv
jrjXu3fvvn37IkIOGjRoyJAhw4YNc3Z2Hj58+MiRI0ePHv3tt9+OHTt2woQJkyZNQuCd
MmWKh4fH9OnTIV5IbebOnYuIOn/+fF9f34ULF/r5+S1ZsmTp0qXffffd8uXLV6xYAYFb
tWpVeHj4mjVroqKioqOjN2zYIDvS9evXt2jRAgMMCgq6efMmJvCIzCYmJitXrgwLC/vy
yy+xjLgdEREBFcCog4o4fvw49p0zZw5qMGp/f390D7lGbm6ukAnUjxkz5tdff/X29say
m5tbsXaGDNWtWxeqhOHALDCF1CxGvX379lGjRmFZ9BlNQUowlm3btg0cOHDnzp28PAmh
H8rKhPT8uv53Q359cPO9mWXatGk+Pj56enqYxGKCLdUjnD548ODevXuJiYmYD8fHx//5
55+ItJjlXrlyBXPy33//HXHyl19+OXv2LGbjJ0+ePHbs2NGjRw8fPnzw4MEDBw7s27dv
z549CHeIh7Gxsd9//31MTAym9Ajd69ati4yMRHBevXo1InZISEhwcDDic2BgYEBAAMIy
pvELFixAxxA8582bh9Dq6ek5Y8YM9BZTfYTl//znPxMnThw/fjzC9TfffIN4O2LECBcX
FycnJ3nb9uunq6srltEUhnb+/HlRREBGcdeuXVgeN24clqWbTqmpqRUrVmzcuLFUIz3T
h0wg5kvtN2jQAHJQkkygzf3794siUokXL16gWQiobL7TqlUr6aRA7ER9sbe/IDQYzoAB
A6C5Q4cO/frrr6G5GLirqys0F6bAKKC5MA5MNHXqVGgujDZr1ixoLsaOQ0BzYdhFixZB
c2Fq5DLQXBgfpwC6Cc3FSVm7di26gdO0cePGzZs348TBUD/88ANO5e7du/fu3YuTi1N8
6NChI0eO4KSfOHHi1KlTcAMY9sKFC3CMS5cuXb58Ga5y48aNP/74A84DF7pz587du3fh
VI8ePUpOTn7y5An6RpkglIlSkpTxNCPnxfE7lybuC1LytjIKGvYiN/s9mwXXO+KPmppa
lSpVUF+9evXy4QOyMtGnTx9lZeWW/4C0CCOFKinKBIQPRaQwig3KPcLGMhKukmQCaity
EMHFixfRLHI0qQ81atRQV1f//3wgKQmSgbUQEUTRYhtEoEa4RtBG6EYARxhHMEdIR2BH
eEeQR6hHwEeqheAPCYAQQA4gCpAGCATONcQCkgHhQIiGiEBKICjIlSAusACEBnID0YH0
QIAgQxAjSBIcA2aESDk6Ovbo0QOpIhJGW1tba2trpJAdO3ZELoaksm3btq1bt0aaiQwO
Y0HiiWStYcOGSEWRkBoYGCC3gvUwJ8EZgYPJ3uSkTBDKROkZtdMfOcWJO3EfxCzp6emI
NohjuK7Ln0wg3UBoQip0W4Znz54pygSSo5J8RlEmUFOSTCBOytYkJCSgWcTk2/+LWJuV
lYUwrqqqCvvfunWLlych9MNimXYwDDIRe+3YhzVLWlpa+ZOJ1atXY8jBwcHSWkz1Hz16
hAXMq7FKSIa46aSiooIJsOLnjt5EJsTu+vr6OTk5Us3du3dfyjyxOn/+PHoyZcoUXp6E
0A8FN1MS8wvyxfKD5ymai3pAJv58co+X51uXCWhfs2bNKlSoYGdnFxQUNGPGDCMjo7Vr
12IVirDGiBEjwsLCHB0dX/7zrFlPT8/Nzc3f37979+5Xr159c5mIiIhAs9hl2rRpAQEB
gwYNEomblZXVyJEjY2Njvby8sEFoaCgvT0Loh4JvdwcYBQ0bsWOx/fppyvNtoBGjdvrT
LO9CJsC9e/dQo62tjbGrq6u7uLiIyXxGRoarq6umpmalSpUgIi+LPhC7dOlS7Cs+KGtq
aipuBL2hTICQkBAzMzOlIho3brxu3TqhU8gycCwtLS1nZ+esrCxenoTQDwX7/zzXf8s8
Hf/eEIga/r3/+3NUdl4OzfJOKSgoUPxY8suipwOK8RlbvougjdRGsdnk5GTZR968PAmh
H0oUFhY+fZFOsxBenoTQD2kWQuiHhH5IsxBCPyT0Q5qFEPohoR/SLITQDwn9kGYhhH5I
6Ic0CM1C6IeE0A9pFkI/JIR+SLMQ+iEh9EOahdAPCaEf0iyEfkg/JPRDmoUQ+iGhH9Is
hNAPCf2QZiFlIDs7OykpiXagHxL6Ic1CwIMHD6TlrKysMWPGqKiowNpt2rTZvn372zpK
enr633//TT8khH5Is3xabN26FYbdv3+/KM6fP19JSembb76JjY01MzOrU6eO4otTy0bT
pk3btWtHPySEfkizfPyIF9sJ7t+/P3PmzMePH4uigYFBy5YtxXJCQsKaNWukVa9LfHy8
bDEyMjImJoZ+SAj98LMyS3r6a7ybCdPyV2yfmpoqW0xJScnPzy9Ns3I7vprCwsKJEyd6
eXkVuzYnJwepxPjx41/RArZJSkoqKCiQrXz27JlcTVxcnL6+Pg73JuaFxTIyMuiHhNAP
P0WzYG5sbGyMLjVt2nTBggWiUkNDQ6WIOnXq2NjY7Nq1S4qiQ4YMqVSpkrKycpcuXXbu
3Cnqg4ODsXF0dHSzZs3QlKGh4ZkzZy5cuIA2UaxWrZrUghwRERHYcfny5WJHBOQffvhB
WvvixYu5c+diFfpjamoKo2VnZ4uo6+TkhO0rVKgg+gmJiY2NxcLhIr6QYcuWLefOncPC
3r17RbPXrl3r3LmzeGxRo0aNTZs2oXLHjh1IQEQfxo0b9/z5c1SePn0anRdv5Qbu7u6o
bNGiBXaXOnn27Fl7e3tdXd2aNWt269YNo5ZW1atXD9bz8PBQV1fH7o6OjpmZmfRDQuiH
n5BZkBRoaWlZWVkdOHDAz8+vR48eoh5CgLDs4+MzduxYLKDDvr6+qF+/fn3dunUxhw8M
DEQMVFNTS0tLQ31QUBC2MTExgXBALLAKzUJ91q1bt3btWmhN9erVi51Or169GjvWrl0b
sRpxHseqWLGiuDuE2X7r1q2x1tLSEmIhutGhQwfkJleuXEF/UHRwcAgqAvKxbds21Bw6
dAg5Ag6KZYTlmJiYxMREWZlITk7W1tZWVVUdOnQodrS2tp43bx7qjYyMBgwYsHLlSiFA
np6eQsXat2+PojjK8ePHUQnZQjdE/7du3QqpgpQgtXF2doYcQED37Nkj1taqVQv7jh49
+ujRozNnzsTylClT6IeE0A8/IbMgdGOibmFhIT41Kt1agUwMHjxYujlja2uLyfDDhw8v
Xrwo3eFfsmQJBnLp0iVJJsQywKwbRUiPKEJuUESsLkkmDh48KFtEUMXy4sWLsRwaGipt
DHlCzYoVK7CMDmNZ9qaTJBNC/rA8ffp0sUpWJlCJ5c2bN0s7intiUh9yc3OhcX379hVF
ZBbYXvamkyQTSA2gOMhBkPVI2RYkQ09PTzwuh0xA46QdUZRNQ+iHhPGQfvhJmAVRF/Nh
hDtkAVKlrEwATPXR53379okiJuTBwcFmZmaoPH/+vCQT169fFxtERUWheOTIEVFEfEZR
ukOlKBOnTp2SbuCguGbNGiwjU6hSpYpsDgKFQq6BOf+byISdnZ2mpqYU2OVAn5FAYfjd
u3f/V5kQvZU7lcgXUIl8R+hC165dpVUYEXIx+iEh9MNPziwI9a1atUKvZsyYUaxMhIWF
Ye3u3bux7O/vj+g3f/58kU0UKxMxMTGyMoG0AsUdO3b8q0z89ttvKKISy1ZWVhAv2Xie
mppauXJlEcDLLBPIjJBAKd4Bu3HjRseOHTHbR1rRoEGD0sjEsWPHsMrPz0+2HU9PT8ks
cjLRq1cv1NAPCaEffkJmSUtLy83NfVn0ULh3796qqqrinpKcTFhaWiLjuHfvngiM+I/K
jRs3vlOZEPE2MjJS2lgcxcfHRxKCyZMnv65MTJs2TTqELFZFiGVjY2NJJqZOnYrtnz17
pigTsJ6ampqRkZH0jYzs7Gx9fX11dfWsrCzKBCH0w3JgFkRyhMTAwMDt27ebmprWrVs3
JydHyATqkURERUVZWFigw4iWqI+OjsbyqlWrEhMThw4dKj5HFB8f/y5kAkHY0NAQ8mRv
b79s2TJra2slJaWGDRtK34BGrlG7du3w8PApU6ZATUopE0hDqlevjmbRILo9fvx48VgZ
GQQs8OjRI5hCS0sLyig+sySGNmLECFjD0dHx5f8+whZrEfyRiLm7u+vq6qKILom1lAlC
ypMfZuflfIZmuXPnDoIwYia6ZG5uLj0+gExoampqaGigHtHY19dXTJgzMzMRXZWVlW1s
bObOnYsdsRnk4F3IBHj48OGgQYMwY0clOjN8+PDk5GRpX/QWfcaq+vXrx8bGllImAPqJ
/iN1QqWOjs6sWbNQuWHDBiwjF4BqQAXEB6VeFj3ld3V1xTBhEzs7OzmZEFkVOoDtoWKN
GjVCT6RVlAlCyocfFhYWTv0xxGHD9ILCgs/TLFlZWSkpKbI14qZTQUFBsb+bJ334HxN+
cXflnZKfn49JfklfcHutL+XJkpubKys6L4s+0yU+9YRjyX1lO6uIV7SGbnw8X6CjTBD6
4VskNz/P6YcFX3hbfRUxPjUrg2aRlQl6Mi9PQuiHw2J9oBGjdvp/njedKBPlmJLyLMoE
oUyUnn1/noVG9Nsyl2ahTJQ/GjRoUKtWrZUrV8r9ABdlglAmSkLu9ntWXk6DoKGVF9j/
lfro/ZtFSUmpYsWKampq6urqVapU0dLS0tbWrlGjRs2aNfX19WvXrl2vXj1DQ0Nc6cbG
xo0aNWrcuHGzZs2aN2/esmXLVq1atWnTxsLC4quvvurQoUOnTp26dOliY2PTtWtXe3v7
7t279+zZs1evXn379u3fv//AgQMR8IcNG+bk5OTi4jJy5MhRo0Z98803Y8eOHT9+/MSJ
EydPnjxlyhR3d/fp06fPnDnT09Nzzpw5qJkxY4aPj8/ChQsXL17s7++/dOnSwMDAoKCg
FStWhIaGIviEh4evWbMmMjJy3bp1GzZs2LRpU0xMzNatW2NjY7dv375r1649e/bs27fv
xx9//Omnnw4fPvzzzz8fP3785MmTp0+fPnfu3C+//PLrr79evHgxLi7uypUr169fv3nz
5p9//pmQkPDXX38lJibev3//4cOHSUlJjx8/fvr0KebG4kUPL168yM7OzsvLk/uNPiIH
3AmeBu+Cm8ETxMeYKROEMlF6jtz+DanEl8u/7rB2UpWF3dqsHnMo4df3ZpZ58+Yh1iHi
Ie49f/4cMRCREEKGqIjYiAiJOIloiZiJyIn4iSiKWIqIirj622+/IcYi0p45cwZRF7EX
ERhxGNEYMRmRGfEZURqxGhEbcXvLli2I4Yjk0dHRiOqI7YjwiPOI9oj5iPyI/1ABaAEU
Abrg6+vr7e3t5eU1d+5cqAa0AwoCHYF2QFOgLNAXqAy0BooD3Rk+fDg0CEo0ZMgQqBIi
EhQKOgW1gmZBuaBfUDFoGRQNumZpaQmNg9KZm5tD9aB9UEDoINQQmghlhD5CJaGVUEzo
po6ODjQUSlq1alWoKoIeFFZZWRlSK/36H2oqV66soaGBbbBl9erVsRf2xXS6Tp06aK1+
/fpGRkZo38TEpEmTJjhiixYtzMzM0Af0pF27dugV+ta5c2crKyv01s7OzsHBAf13dHTs
3bs3RjRgwIBBgwZhjBips7MzRo2xjx49+ttvv4U1JkyYMGnSJNhn6tSpHh4esNisWbNm
z54NG8KS8+fPh1VhWz8/vyVLlsDa33333fLly2H/sLCwVatW4YysXbs2KioK5whnavPm
zThrOHc//PDDjh07cDb37t27f/9+nN9Dhw4dOXIEZ/zEiROnTp2CD8ATLly4AK+Ab1y+
fPnq1avwlj/++EP8aKEAVoJl9PT0IP3imyOUCUKZ+FeWnt4CmUA2MfB7ry5RbkreVhW8
rU/fvcKbTp8W+fn5ubm50NzMzMyMjAxkHNDcJ0+eIAeB5j548ODevXvQ3Nu3b8fHx0Nz
b9y4ce3aNWjupUuXfv/9d2Q00NyzZ88ix4HmYsp99OhRaO7BgwcPHDgAzd29e/fOnTuh
udu2bfv++++RMUFz169fjxwKmhsREbF69WpobkhISHBwMDR32bJlAQEB0NxFixYtWLAA
YRmai1kBcjRoLnI0RGlorpub23/+8x9o7rhx48aMGQPNdXV1HTFiBDI+aO7QoUORA0Jz
+/Xr16dPH2hujx49unXrBs21tbW1traG5nbs2LF9+/bIKKG5rVu3Ro4JzTU1NW3atCk0
t2HDhuKDxHKIDznTDwllojQM374IMnE5KUEUd988jaLjplmUCVI+0NTUlPytUqVKyLaQ
QyGFFL9VSz8klIl/ZeK+IFmZKCgsqLqoe5OQ4eXbLNevX+ct/Y+HFy9eIM15R42LW3NV
q1atWbPm7NmzpTf9cbpCKBOlJPL3/ZAJ9x//73eqTyVeRrFvzJxybJY1a9ZIP1VEPgay
s7NNTEzEayzeOq1bt3Zycjpx4oTcNxMpE4QyUUpy8/NMVriIL9aN2umvsbCbynybX+7f
KK9muXbtmpaW1s2bN+mfHxU7d+6sXbu23PfB3wolpY2UCUKZKD0Pnz/pvnGGqo8txKJh
sNPB+F/KsVksLS0nTpxI5wTx8fEfVX+++uqrr7/+mpcnoUx8vIl/Xs6TzLTybRbxs3jS
L+wJMjMzpV/ALg3Pnj0raYKak5Mj+2IIFGV/eftNkPtqmCIYwmv9mFJcXJy+vn5JvxBV
+uPK9eEV28t9GzolJUX8cpREUFBQhQoVLl++zMuTUCZolg9llj59+tSoUUOKTojhPXv2
VFNTq1q1qqOj47Vr114WvW9IpYgqVao0b9588uTJ0s/f7dixw8DAAN1GgB03btzz589F
vY6OzoABA9zd3StXrlyxYkVXV9fs7Gw3Nzd1dXXxC6vSj34rcvbsWXt7e11d3Zo1a3br
1k38arfAysqqadOmt2/fNjU1VVJS6t+/v/h5c1nq1atnY2Pj4eGBY6HPOJb0g4SvaPz0
6dPi2wRipOi5YsciIyONjY2xDfqwYMECUamhoSF2qVOnDo67a9cuyZJDhgypVKmSsrJy
ly5dpJ/YDQ4OxsbR0dHNmjVDU4aGhmfOnEE30CaK6IPUArh7967cK5Z4eRLGQ5rlPZsF
QdXBwUEqent7I/yGh4cjyxg4cKAIbuLd01AHT09PRGaICERBKIWRkRHkYOXKlU5OTtgG
G4h2EO7QzvTp048ePQqNEDqChX379rm4uKC4aNGiYvuzdetWzJ+x+8SJE52dnRHqEWb3
7Nkj1nbq1Klu3boWFhYzZ85ETO7du7diC7Vq1UL7o0ePxqHFJzzFayNe3XhERET79u2x
cVARis+OkRRoaWlBpw4cOODn59ejRw9RDyGAZvn4+IwdOxYLaMHX1xf169evR1cR4QMD
A2FkGC0tLe3lP++hMDExgW0hFliFZqE+69atW7t2LbSmevXqskkQBLdXr168PAnjIc3y
QcySkpKCIyJuy/UkKipKFMUdGCET0jsjDh8+jOKECROwfPDgQVGZm5uLcNe3b19JJqRl
BFhIRrt27f7vVl52NlIMzOQV+4Npv7a2NtIT6T4V5uRoSk9PT9wEg0zg0Pv375duYRUr
E5aWlrLFzp07l6ZxxZeWyoLQjcQBCiV+QV3aTPZHrtAfW1tbJAsPHz68ePGilHOJt75e
unRJkgmxDJC2oAjpEUXIDYrnzp2TjgvpgXbw8iSMhzTLBzHLoUOHcMRp06ZJNYiBYkrc
vXt36TM2cjIBGjZs2LZtW6l45MgRzKURMKVP1SL8yv5CoKGhISK8VGzTpo2ZmVmxt5sU
LYBcAJVXrlwRMoGWxdtXS0LujT/IlTCrL03jr5YJsGLFCiQj0BpkAVKl3G8hbtq0CY0g
aRJF2DA4OBiDLemtr1Bk2fc07d27F0XpDhXAWFAj95ILXp6E8ZBmeT+cOnUKRxw/frxs
ZVZW1rx581RVVTGJFV+8kpOJ/Px8hGJzc3Ms37hxo2PHjpiuI61o0KBBSTJhYmIiKxPI
LFq2bKnYH/FCbT8/P9lK8eZrEWPRCJp69aBKejHcvzb+rzIBsGWrVq2w2YwZM4qVibCw
MKzdvXv3y6JnOjj0/PnzRTZRtpeDd+nSBbnY+3mxES9PQpmgWRRvpGB6LBtUpR/LRUyT
7urLyQQUAcUxY8a8LHqmDES9sbHxG8pEWlqampqakZGR9Dmr7OxsfX19dXV18Ya4N5GJ
f2186tSpGFdJH8TC7iKLwe69e/eGjIoZvpxMWFpawqT37t0TqiR+fHXjxo1llonGjRt/
+eWXvDwJ4yHN8qHMgqhrYGAgFRHzR44cGRsb6+Xlhc6EhoZKMjF27Njt27dPmjSpahGI
hC+L3lxgamr66NEjrNLS0kKQFJ8dKptMSFEUgR3TdXd3d11dXRTDw8PF2jeRiX9tXKwd
MWIEMgLxtmtZEMmhg4GBgRgphly3bl3xZAQygXrsEhUVZWFhgRYgN6iPjo7G8qpVqxIT
E4cOHYrlLVu2xMfHv5ZMILWBVfv378/LkzAe0iwfyizDhg3D7Fd6mzOCGCbY6Aaik7Oz
s6gXMiE+QaSsrNy+fXtxMx9s2LBBR0cHuyDv6NChg/iw65vIhJh7169fX7x6o1GjRtAs
adUbysSrG0du5erqqqmpichvZ2cn1+ydO3fs7e1hK+xrbm4uPT7AxthF/Lyqtra2r6+v
yFYyMzOtra1hLhsbm7lz52JHbAY5eC2ZuHjxIooLFy7k5UkYD2mWD2WWn376CQeV+/xn
cnKy7GNi6aZTamqq7HflBJhUi69dYOr7Fp+04ljv7ob8KxrPKqKkHbFK7iVW4qZTQUGB
+ASUHNJXNtLS0l7RbEn4+/uj/YcPH/LyJIyHNMsHNIuFhQVmvK/YQPGTTkROJt5Fy5Ce
Fi1auLm58fIkjIfkw5rl6tWr6urqR48epUx8VDIRFRXVoEGD9/MZJ16ehPGQZnk1kZGR
sl9Jo0x8cJnIzMw0MjKS/aESXp6E8ZBm+bBmuXv3bkk/35eenn7nzp1Xf6ntsyUxMVHu
acVbITs7u9iHHbw8CeMhzUKzEPohoR/SD2kWQj8khH5IsxD6ISH0Q5qF0A8JoR/SLIR+
SAj9kGYh9EP6IaEf0iyE0A8J/ZBmIYR+SOiHNAsh9ENCP6RZCKEfEvohoVkI/ZAQ+iHN
QuiHhNAPaRZCPySEfkizEPohIfRDmoXQDwmhH9IshNAPCf2QZiGEfkjohzQLIfRDQj+k
WQihHxL6Ic1CgxD6IaEf0g9pFkI/JIR+SLMQ+iEh9EOahZQPfv75Z+9/wDINQhgPaRZC
CGE8pFkIIYTxkGYhhBDGQ5qFkHdNSkrKn3/+STsQxkOahbw5ixcvxvmKj48vT4NydXUd
NmzYZ3tOK1Wq5OzsjIWgoCCc3OvXr9PPGQ+Lv1J2+n3hbSX3p+pjezctmTJByrdM1KpV
a8OGDZQJygRl4tWEnN/ef8s86a/16jGQCZftC5lNkDLIxCekIxcvXlRSUnr8+DFlgjJB
mXgt+m2ZC5mIS4qnWYggOTk5OztbTiby8vLS09PltoyLi9PX1y8sLFRspDTRODMzE82W
vmPPnj0rKCgodlVOTs6LFy9ki9hYbptFixa1bdtWrhIdyMjIKIOVSr+jot3KNkaQmpoq
W0xJScnPz//XNmENnNOSZOJz1k3KRGn448ndCt7WDhum0yzliXr16vXt21cq9uzZs0GD
BmJZQ0NDpYg6derY2Njs2rVL2gzRPiwsrGbNmjhN2EBbW1vIBALXkCFDEGGUlZW7dOmy
c+dOsf3p06erVasmNgbu7u4ieHp5eWlpaaEea5ctW1asiKBN9EpNTa1q1aqOjo7Xrl1D
pb+/v2iqSpUqzZs3nzx5shTBduzYYWBggDahSuPGjXv+/Lmo19HRGTBgAA5duXLlihUr
urq6QuDc3NzU1dWxMVr++++/pYN27NgRfZNMhOF7eHhgSxwRW0KzpC3Pnj1rb2+vq6sL
a3Tr1u3ChQuytn3FjnJERkYaGxujJ02bNl2wYEHZxhgcHIzto6OjmzVrhrWGhoZnzpxB
l9CmMLLsSZTjr7/+Qv+xO7bEcJBMycrEyJEjGzZsKI6Io/PC+ZxlAlOOklaN2b0UqcTh
hF8pE+WJWrVq9erVSyoiUCC4SbcdTE1NfXx8xo4diwWcEV9fX7Fq+fLlKCJ2hYSExMbG
WltbC5lYv3593bp1EWADAwPRDmJ7Wloato+IiGjfvj22CSri+PHjqJwzZw5q0Pj27dtH
jRqF5WKfBXh7eyNkhYeHb9u2beDAgUJ6RP6CyOnp6dm/f38cCOFLRFEjIyPIwcqVK52c
nLANNhDtIEiinenTpx89ehQaISIeFvbt2+fi4oIiMghpHg6ZQ/yXTIS1o0ePxo4zZ87E
8pQpU8SqrVu3VqhQAS1PnDgRQRVygB337NnzrzsqJhGQSysrqwMHDvj5+fXo0aNsYxQh
3cTEBFaCWOAUoFmoz7p169auXQu5r169erF5DSqhOxBQYZClS5diILIyAeHA+YLkaWpq
YsgXL17ktcNsQo6kjKdqvnbmq76lWT4rmRg8eLB0L8LW1hZTzYcPHxYUFCBWYHIu3QWS
bjohekgz3iVLlqDy0qVLoohJL4pSvvDixQtM6bt37y4dGkrUqlWrklwiKipKSmSkI0o3
zA8fPozihAkTsHzw4EFRmZubiyAp5UoI5tIywjIko127dqKItAIREmOXgn+NGjWk+zkw
kaWlpazFOnfuLO6DIY1CdJVuYSHxwVH09PSEZUrasdgojdzNwsIiKSnpTcYoQrpkc6RO
KEJ6RBGKj+K5c+cUOxAQECBEXKqRu+l05coVUX/y5EkUxSrCeCjLnCNrkErEXDlCs3ye
MgE2bdqEk4Kp5q1bt0QWIK2SezaRnJwcHBxsZmaGyvPnzxcrExAUFDG/bfkPiMyYjRcz
RUlKErkMNEXcNlcMoaBhw4ayTxOOHDmCHmIIkhIhgMsOx9DQsFOnTlKxTZs26LBYHjly
pOxHYWGirl27SkUHBwdkTOJ2k6KXIl+Qguordmwjw5MnT1C5YsUKzNKhO8gCyjxGucfN
0FYUsZko7t27F0XpTqAsyEpw9AcPHpQkE1KbOIMYl7m5Oa8dyoQsf+e80PZzrP/dkPyC
fJqlnFG7dm2Er9LIRFhYGE7K7t2779+/j4WpU6cWKxP+/v4II/PnzxfZREkykZCQIObG
t/+XYjuZlZU1b948VVVVyApESjGE5ufnS7Hrxo0bHTt2xLwdU+4GDRqUJBMmJiayMoHM
AlIlwqC+vv769etLkgmoKmqwcOzYMfTBz89Ptquenp7SqF+xY10ZJO3DXsinsPuMGTPK
Nka5kB4TEyMrE0grUCz2ycI333yDVPHp06f/KhNIlHR1dTt06MBrhzIhS9DZbUglgs/9
QLOUP5o0aQKlkIoIPiXJhKWlJSac9+7dEwEQs3Ep5ksyISIn/qNy48aNsjIBWUFR9jNF
aAQBOScnR6q5e/euYg+l52VoSrq9LxdCES1RHDNmDJatihD1xsbGrysTv//+u9xHYUuK
9mlpaWpqakZGRtLNt+zsbIwIORF07RU7KoKmcnNzRRDu3bs3BBEdKMMYyywTq1atwqrI
yMh/lQmRkkyePJnXDuOhRF5BvuF3Q6r79UJOQbOUP0aPHg1Tz5o169ChQ+I5sqxMIAQh
iYiKirKwsJDNIIQEIAYuW7YMawcNGiRkIjo6GguIOYmJiUOHDsXyli1bRJYhos2IESPQ
oKOj48ui59qoQeScNm1aQEAAGqlfv75iDxEPR44cGRsb6+Xlhe1DQ0MlmRCPvydNmlS1
CCFhmF2bmpo+evQIq7S0tKBu4tNHpZSJBQsWyH0U9hXRXgwKRcz/3d3dMc1GMTw8/F93
lAORHKYODAxEn9F5pBhQzzKMscwyAZFq2rQp2p89e/bq1avXrVuH5EJWJuAbOHGogYRV
r15dPEMhjIf/d0f68iGkEnOPrKFZyiXPnz93cHBAmoA5sIeHh62traxMaGpqamho4Fxo
a2v7+vrKfnNh9+7dCK1irQBykJmZaW1traysbGNjM3fuXDSLFkSYysjIcHV1RRHN2tnZ
iUZCQkLMzMyUimjcuDGiUzHJbFAQpuhoH/EQYUpM1EUIFR8lwuHat28vPWPdsGGDjo4O
dkHe0aFDB/Fh19LLBHaRPgpbmmgPxYS64SgYQqNGjSBnpdxRljt37tjb28NcaMfc3Fz2
01yvNcYyy8TLoufv3377LcaCgYgTKmTip59+QsopaipWrIh+8qeuKBNyLD65CalE8t/P
aJZyTHp6urjpIYu46VRQUPC6U0fp2wFpaWkiqktkFaF4y0WxUo7k5GTZHko3ZFJTU2W/
KyfAVFx8laywsPB1vxGGGCh9DaH0oBtl++adnHFkP5H+7sZYtr7dv3//tb7hSD6reJid
l0OzfIbIPZv4uGYvCp8CKn98DmMkjIc0C2WCIZRjJIyHNAtlgiGUYySMhzTLZ0hiYuIr
frzlw5Kenn7nzh3F5ynlic9hjITxkGYhnygBAQG1/gHLNAhhPKRZCKEfEvohzUII/ZDQ
D2kWQuiHhH5IsxBCPyT0Q5qFZiH0Q0I/pB/SLIR+SAj9kGYh9ENC6Ic0C6EfEkI/pFkI
/ZAQ+iHNQuiH9ENCP6RZCKEfEvohzUII/ZDQD2kWQuiHhH5IsxBCPyT0Q0KzEPohIfRD
moXQDwmhH9IshH5ICP2QZiH0Q0LohzQLoR8SQj+kWQihHxL6Ic1CCP2Q0A9pFkLoh4R+
SLMQQj8k9EOahQYh9ENCP6Qf0iyEfkgI/ZBmIfRDQuiHNAuhHxJCP6RZCP2QEPohzULo
h/RDQj+kWQihHxL6Ic1CCP2Q0A9pFkLoh4R+SLMQQj8k9EOahWYh9ENC6Ic0C6EfEkI/
pFkI/ZAQ+iHNQuiHhNAPaRZCPySEfkizEEI/JPRDmoUQ+iGhH9IshNAPCf2QZiGEfkjo
hzQLIfRDQj+kH9IshH5ICP2QZiH0Q0LohzQLoR8SQj+kWQj9kBD6Ic1C6If0Q0I/pFkI
oR8S+iHNQgj9kNAPaRZC6IeEfkizEEI/JPRDmoVmIfRDQuiHNAuhHxJCP6RZCP2QEPoh
zULoh4TQD2kWQj8khH5IsxBCPyT0Q5qFEPohoR/SLITQDwn9kGYhhH5I6Ic0CyH0Q0I/
pEFoFkI/JIR+SLMQ+iEh9EOahdAPCaEf0iyEfkgI/ZBmIfRD+iGhH9IshNAPCf2QZiGE
fkjohzQLIfRDQj+kWQihHxL6Ic1CsxD6IaEf0g9pFkI/JIR+SLMQ+iEh9EOahdAPCaEf
0iyEfkgI/ZBmIYR+SOiHNAsh9ENCP6RZCKEfEvohzUII/ZDQD2kWQuiHhH5IaBZCPySE
fkizEPohIfRDmoXQDwmhH9IshH5ICP2QZiH0QxqE0A9pFkLoh4R+SLMQQj8k9EOahRD6
IaEf0iyE0A8J/ZBmoVkI/ZDQD+mHNAuhHxJCP6RZCP2QEPohzULoh4TQD2kWQj8khH5I
s/y/9u48Nqq6C+P42xekCAURLVIM0UqpWkCREqqCCGIUrFVBUIiIoKCENIobgikGSRWt
0bC4xKAiNoqJxIobKC6URQ0CGgVBKGWtC1oqSoVS7bxPeuIvN9N2Zuwd+rad7+cPMr33
ztCceeae+c1yCnJIDkEOKQtADkEOKQtADkEOKQtADkEOKQtADkEOQVlADgFySFlADgFy
SFlADgFySFlADgFySFlADgFySFkAcghySFkAcghySFkAcghySFkAcghySFkoCMghyCE5
pCwghwA5pCwghwA5pCwghwA5pCwghwA5pCwgh+QQ5JCyAOQQ5JCyAOQQ5JCyAOQQ5JCy
AOQQ5JCyUBaQQ4AcUhaQQ4AcUhaQQ4AcUhaQQ4AcUhaQQ4AcUhaAHIIcUhaAHIIcUhaA
HIIcUhaAHIIcUhaAHIIckkPKAnIIkEPKAnIIkEPKAnIIkEPKAnIIkEPKAnJIDkEOKQtA
DkEOKQtADkEOKQtADkEOKQtADkEOKQtlATkEyCFlATkEyCFlATkEyCFlATkEyCFlATkE
yCFlAcghyCFlAcghyCFlAcghyCFlAcghyCFlAcghyCEFoSwghwA5pCwghwA5pCwghwA5
pCwghwA5pCwgh+QQ5JCyAOQQ5JCyAOQQ5JCyAOQQ5JCyAOQQ5JCyUBaQQ5BDckhZQA4B
ckhZQA4BckhZQA4BckhZQA4BckhZAHIIckhZAHIIckhZAHIIckhZAHIIckhZAHIIcgjK
AnIIkEPKAnIIkEPKAnIIkEPKAnIIkEPKAnJIQUAOKQtADkEOKQtADkEOKQtADkEOKQtA
DkEOKQtlATkEOSSHlAXkECCHlAXkECCHlAXkECCHlAXkECCHlAXkkByCHFIWgByCHFIW
gByCHFIWgByCHFIWgByCHIKygBwC5JCygBwC5JCygBwCfqxduzbvH7pMQXh4ghwC4OEJ
cgiAhyfIIQAeniCHAHh4ghySQ8SI11577eWXXy4tLeXhCZBDoKaTTjpJgf/qq694eALk
EKBNAOQQoE0A5BBN0cyZM//++2/aBA9P0CaAmmbMmKFc0SZ4eII2gebn8OHD9957b58+
fdq3b5+enp6Tk3Ps2DHb9eCDD2ZkZFxxxRW//vqr9yrvvfdeRrUVK1box/vuu89ylfGP
pUuXuoNXrlyZmZnZpVpWVtb69eu9N3XDDTfo+LVr15aWlk6ZMuW00067/PLLv/nmG+16
+umntUtZLSoqGjVqVFJSUq9evfQruV9Pfvrpp1tvvbVHjx4JCQlpaWmPPPLIkSNHaBMA
OUS07Nmzp3v37paKdu3aubO9nWzLysrOOeccbRkwYMDRo0ftKlu2bFFD0cbbbrtNP06d
OvU/NegMbwfrvB0XF6ctrarZhddff939AmeffbY2FhQUXHbZZe7qvXv31q4HHnhAl889
99wOHTq0bdtWHcT2jh49uqqqynpEp06dgv7rkSNHNsU2kZub2+YfukwyQQ7RSAwfPlxn
0UsvvXTdunU6965Zs6Zv377a8vjjj9sBO3fuTExM1JYxY8boAC0rzjrrLLuKPavXU/1V
q1bZKXr79u1F1X777Tft2rRp03+rLViwQIsFXTcvL0+H6dz++++/e9tEz549x40bpyvq
11CT+uijj1ybEMW1oqKisrJS/aVFixbasnr1ah2wbds23fj06dP1H5WUlGgdZMcXFxc3
uTYBAI3Qt99+q1Oonu1rgeA2Llu2TBuTkpLcFp264+PjtVHn7UGDBulCt27dvC9D7d69
287P9iTfuf7667Xxxhtv9G684IILtPH555/3tonTTz/dXde9wWFt4tprr/Ve3X6Bp556
Spf37t27fPlyt0utROsO7bUuQ5sAAJ9effVVO0XnesyaNUtP0bX90KFD7sglS5bYa0ei
E+93333nvZ262oS9nKVlgvf2Bw8erI333HOPt01kZ2fX/PWsTdx0003ejbo1bdTCIehg
/deFhYVdunTRXm/voE0AQL099thjOoV27NgxvTZFRUXeg0eMGGG94Iknngi6nbraROvW
re0FpZo3Pm3aNG+bePPNNyNsE3fccYeta9wWtbPp06er2XXq1MneNHn//fdpEwDg3zvv
vKNTaP/+/cMeqefn9qaAnHzyyVu3bo2kTagdaOPKlStD3LK1iXfffbd+beLtt99OSkpS
j1i8ePGxY8d69+7NagIAoqW0tDQuLq5Vq1be9yZMZWWlu6ymYCdbnaIHDBigC8nJyT//
/LM7YP/+/dYm3BvT5s4776x5ng+6fT9tQn1BK4j4+PgDBw7Y3kbYJprK7EEAqNWQIUN0
Fk1NTV23bp1t0al+yZIl3bt3/+uvv6yVpKSk6BgdqXO7frQTe79+/crLy+0qhw8ftjZh
n3Q9dOjQG2+8oQurVq2ytzmmTZumYwLVb09v27Zt4sSJDz/8sP828cknn9h7K+5d7549
eza2NhH0C/zyyy9BazEAaOQLCvtmhL2apFOu+wKCzr3qC/Z1BnWNgwcP2lWKi4vt2wrX
XXedOz/bYVqbnH/++Vqe6Bm+bX/22Wft1lq0aHHmmWeeeOKJ9uPMmTP9t4k///zTPto0
duzYxYsXu3dPRo0aNWHChEbYJioqKuzbH19++SXZA9BU7NmzJzs7Oy0tzc6xCQkJI0eO
3LRpk3ZNmTLFPtoU9AR4/fr1bdq00a677rrLtpSUlAwbNsxuQe1g0qRJ7uBFixZlZmba
d/e0uNDaZN68eTrD+28Tkp+fb5+nUo/Lzc2dPHmyLp9wwgnugEbVJrRA08KtdevWLCgA
NEUHDhwIGsrxb5WVle3du7fWXTpD7t69W0+no/5rV1VVqUm5H/fv3+/9KO//XVCfUgXc
uiy6tMp78cUXiTEANC0Ns5zZsWNH165d3Ut5AIBG5fPPPx8xYkS3bt3atm2bmpp69913
79u3r9Y2MWTIkIyMjO+//9579RDTEY8ePWrTFLVMmzt3br9+/U455ZThw4evWbPGHaNb
szeV9K8dPHToUO6UZk/3e05OTo8ePRSJ/v37P/fcc+5TJYGQIz3lww8/VE7Gjx+vywUF
BcpVcnLy7NmzKysrJ0+erF1PPvmk9//SCl3/hbbby9EBHyM9gRiUl5fnvlTivPLKK7W2
iZqLi9DTEY8cOWI3eNFFF9n7PvbhsYSEBHtgbt26tXPnzkH/+6mnnsr90rz98MMP6g66
r1u2bGkf5JCPP/7Y9oYe6RmonqugLX379lW/8Kb3rbfeys/P1wXduHsDUebNm2cfZbHv
RvkZ6QnEmg0bNth5e8yYMVu2bPnjjz909p40aZJ7yIRuE2GnI7o2kZKSYmuQ4uJiLRa0
RQ9A/Xjw4MGioiL7lFd2draNXty1axd3TfOm5yG6xxMTE+2trs2bN48bN66wsND2hh3p
aW1Cy0/latmyZWor2qUn/IHqryPZ4tQNXtMtaI2sLfPnzw/4HukJxJqrrrpKD4err766
rgNCt4mw0xFdm/AuQGwkb/v27d2W8ePHa8tDDz3EPRI7z0/sQ33uG09OJCM9rU14e0HA
M3Vzzpw52pWWlmZrhw8++MDyZl3A50hPINbocaeHw6efflq/NhF2OqJrEzt27HC3qQWF
bbSvQNImYtOFF15o30hSVLSMddsjGelpbUJbvOMUHK1Q7BPv9nfHsrKydHnq1KkRhjYQ
cqQnEFPKy8vtdO3esP63bSLsdMRa28SPP/5oG91LzbSJGKQTvr24ZM/83eciIhnpaW3i
vPPOq+vG7TtTQ4cO1XMSe4lp586dEYY2EHKkJxBrbCbtZ599Vr82EXY6Im0CoRUUFNj8
fEXLQhLJSE/3FnZdB2zfvj2u2jXXXKMj9a/b5XOkJxCbC//bb7+9fm0i7HTECNvExIkT
vUt+NHveacxlZWX2DrUNH4hkpGfYNiHWIII+QxXwPdITiDX2cNOjMicnxz5AWFFRsXr1
avehjtBtIux0xAjbxP3332+vIdj33L/++uuNGzdy7zRjjz76qBaP7i0JnbQVgMzMTPsx
7EjPSNqE++PFvXr1CtruZ6QnEINGjx5tj6aWLVumpKTYeEO3vgj7vYnQ0xEjbBOFhYW2
JTExMTk5WRfmzJnDXdOM2V9+j4+PHzhwoJ4e2L3/0ksv2d7QIz0jbBPSp08fHbZw4cKg
7X5GegKxadGiRWoQ9hRLj9z09HQ3XilsmwiEnI4YYZuQF154oWPHjvYLDB482PsqAZqf
zZs333zzze783KFDh6DvTYcY6Rl5m8jPzw/6nl0koaVNAHXRY0Qnc+9fdPpX/E9H1C0U
Fxd7eweaN93jage7du0K8a0EPyM9FWYl6riGFgAAAAAAAEAMCj2LOFDfccEbNmzQ9osv
vjjoT/DMnTtX23Wk/VjvWcfccQDQAELPIg74GBdcVVVlg1/cRMqA5y9B5+fnB/zNOua+
A4AGEHoWsc9xwc8884x2de3a1T35t4lknTt3ts9F+Jl1DABoACFmEQd8jwsuLy+3j/G7
1Yf9YR37nqb/WccAgAZQ1yziQDTGBc+YMUN79V/o8saNG+2bXza42P+sYwBAA6hrFnEg
GuOCS0pKtFTRAV988cWECRN04ZZbbrFdUZl1DABoGDVnEQeiNC547NixOuDKK6+0puNm
BURl1jEA4LgKMYs4EKVxwfZak7nkkkvc9mjNOgYAHD+hZxFHa1zwoEGDrE0sXbrUuz0q
s44BAMdP6FnEgSiNC7bPL51xxhnuDze7BUVUZh0DAI6TsLOIA9EYF6xzvhYIeXl5NXdF
ZdYxAOC4imQWsc9xwfv27at1ZL3jZ9YxAAAAAAAAAAAAAAAAADR7/wOiOV+7CmVuZHN0
cmVhbQplbmRvYmoKMTc3IDAgb2JqCjI2MzE0CmVuZG9iagoxNzggMCBvYmoKPDwgL0xl
bmd0aCAxNzkgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg
MjU2IC9IZWlnaHQKMSAvQ29sb3JTcGFjZSAvRGV2aWNlR3JheSAvQml0c1BlckNvbXBv
bmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42vv/f2QDAAgA/wEK
ZW5kc3RyZWFtCmVuZG9iagoxNzkgMCBvYmoKMTIKZW5kb2JqCjE4MSAwIG9iago8PCAv
TGVuZ3RoIDE4MyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjazVpN
bxy5Eb3zV/CoBWKaLLL4cY13A/jgwMEKyCUXWZ5xZiNp7Bl5gc2vz2PPdDeHbLY3tiDb
XuxY9hNZfKx69UF9kv+Qn6T1+E9p/OIgA2nJTsvDRv5TPsiXr45G3h6lGX4fbzOYwwnt
B/CLE1ps//RaWmplmJIzJuKPnmz+wubVP+Frsmn4JfSAHL/MS+vTykne3su/XkseEPnD
sNaS2Mjre/nyb0bhb+T1Vl6R+Ule/yZ+uYZxy+bZpPLqbjLy7eZwu/n4+PnmTh52+Bb2
VmnYEPNe4oVTOpzscVEFM3yri6xi1Nplu16+vieWP++7O54JEQvkuqCYsKNTblhOKzds
xk6+OP05ahfyt7dsi29jW16yLVq2zZnu/BlxRDIUT3zTxPfPu+12c9g8PMq3h/3j/nZ/
d/xJXP8mVy5g0WL8XrBPrHpDtMP34YOYpQnenayzk3X/IsfZH2COeAJz1umazbGuNGcm
69fBlhnntFYcybAY0VcfawgbuIbD/hPkpoakoKLN58kQkSH3FYSDUYk8wmVaRdaQxHD0
CK+fILfDTc4Q72ALGPUzZF+t4hMpS8EW5j6cIeIMCc6CRU00Qx6rVULQCo7PxSqHAiLw
EbVVzmiKfVsiO2WNNcWh72pICMp55ii6vCTckTeIwnmVmt0UHITBnu9ILN0RLIVGcSqo
+6OBeBijmco7EhUkwWGgxn1nMAbunbSl9tBignh4Lp/9ZYAc61VIe9hiaJldMUA4KKvd
iktBLqBh7OdguHpXQ6w1ynJy8wVsGgguKWhe2SfHUeTgZv4fGgjiKHhtZX8fl6IymmMJ
qfhnB6FmU/jC+3qVHEeWS1o2Nf85jnwqI61ZJceR19Q59MB/MKxCoXtX23qRHGms2fVD
xISEA+lIYjHQBkgkD3kJaYV/6BNyqi74f91AglXGleH6poYkR3Du5Fb8P3mc2ZgVMSQ4
LZw7cF+A4Nukktcrt0gIIxW9tfWhT2lNPFMeIfj+YiJ529gLf+EUguheNdHgDWUcvSqO
tJAaxVceqc3UosrU3q1l6vXCQXy7OUUUDZl6Mmcm+O9NpmaFJKBn9IXniXOmZkLxOEPq
vIZ6TlFW7xHwuU7CFqVbiPDVCVLHI/usDDGniRFSKxn+WaVBgoAQSxHrLUHqfE4B4yJN
Jo+4HJ2jcURsq2gMRkOA4HQzpN4nWKuSISo4OdblAHIEUkk0M6SugSJyBHKWd33ycyJn
xHWxUZOlcT+QVLNi7pDI2UHDuldotKYsqvMi/24QjNIEpdRMf6OpOvcPNnD/DiFAuCKc
vDxzpYbwFHhcDH2HG/I4hWTaM0/ZiCgpZ01hy12zCuPMsaB/d4kQhgKE2fpikf80aZwQ
XnHFbVG5RNSXwYu+JTYhyKIuztOUUc4G1Lpn1xbL9YI3udY1K8S5GFWkyGWA1MUAOslg
DfX9yeRgRTQXN/SuKQaQaUL0a67gUa+BPrO80VAM5GilWIjZ1e9Nqsc9e1tS12wUcIsp
oLPsqg80MOYi1a1cQK67A6+oj8nRihq1WKQpgBKBf12K6a4pBhDQiUv3byqgBMENunT/
bVMMaFTdKNr6tFAO6KhLxa27EdIRcWZdWlklBzRct1D/hwaCW3TRNvLz7c30l0crEKOM
wYfNQcqofeoUbUl/abjyZEXQbI5jW5gzp+jXb+TNw/uaH/EkBpX8iNogn/SiQfLLdyWe
pJwabBGDLSF3twu2nArE2eYAxbPO+/lmr/av5O9H+R0uNEW/aPObymajHTQgEfLBaPOb
X/Ody1/ub3Z3XxUZ4ivZLiLDoSsbI0NcRsYzB+oQGZM5SzO5jzeHx6Pcb+XH83Du2WZz
FWkWZVdHTp5lNleRNpmzRNr95ni8+bCR2/3h/gb0ZY+73T884t+O34s/JJgfib/JnCX+
du/x/912tzl8N7pQpf9IdE3mLNH1eNh9+JC5ei4lvmzGE/j6v3px8UR5FdaIZmo+WfMn
huYj+NQviqWZ+YjYdEfmI+K2qujypM8ga8677JpGPChL0ZsJse2N1EVvDW8iuDHzwS/s
GBDeKQ5B2zNCtL18DAq1vZtPe2y68PyGxXo+7b5iLESHwj/3iSOimZSj7jdW23mNz3UL
zklpa2kC1D1VRI0coi1I3zWz9qSS9dqJC0NLBFqhaGOc12gmvdoYFZwJE2HHtkGP6ESD
ndaQbX9uss9Wu4i6PXfkuy42dOfoImkRcZqgk8NhCkqbLujcVvu+pZRQI8UkeqTDTo+2
LznZo3SYr7Mj6nrYMF/3yc2Gvlsar3MKfHlYcTFdR8/nrOkfhfMTSWLfjUmTQ845Q4s+
eO6mI+pc1w0Fk+PJx+T7hOXRu7OFeOyX5uo2z7JHwu6bBtfAUBv7nm6ig4ql4ij/rQmD
6+TBmOt7WO6RvbaL7iPG9pez1PY4pzzN8hxtV8NIW51fCEI3JCkHizWFUh6WpulhvrfW
wyi/WkWE/qWmX/bGkLnk3eUu5WSZCImGCj1uR+DBKEMxLUrU0McP4RRWoiU3+VAxoq5i
Qzc8dgkrjDkXIJWaK7V9/kl8zl4/ziB+smZO/q+6c/gzuCZXOPZ5zIhLHhF1hmDtVYoc
aELUV8iMALfGihGwaTJ7Uj74GKclan/1jPgOKZgzQjRC45EfrNV6XqPJ28gPPjDkf0T8
pc7bcCSc1cxHkd2n9BHxoc7bkN0YoWeyd9roUaVQn9BkEmoDSFqXr/xu50Io9qg1IuX0
oAu62hd0VGTEFKYl7roP6BdkiKX38xHRqL/JCQSKtkiGOL2e41bYhq73GDI6/4iRnRDN
EwFUCqclI3qUgk5SUbuZ9F37cs4q5fwwMvapQaDgil7PfHxempUHb6vTXqRtVIYoh3zX
SU1+s3Lsll3wlLYRTh6X07+5/ANmgVcOmwMuIcdMhDXPC975nC5N14vHN/UwEdaYcX5S
n9doZtvB54czHfouFiLDDjvT0dRKEWqKUmYxFAa+crwxBKqncUjsiDjUlrMKNtGSIw5B
PXvY+/ah3OfaMnVvBak/5dpy9rA/2tR/Hnv35AehkBQKIbq0tExDcA/YUchLk/rzI5a3
BR8fm7TNKGFt4aXNWfKPonj0F10XIzQ3Kjo7i36b2KHppkgsN0uZn62bPezdUuZ3+eGv
a6gLub1NsQrJUzb+H3vpt58KZW5kc3RyZWFtCmVuZG9iagoxODMgMCBvYmoKMjM2OApl
bmRvYmoKMTgwIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTY3IDAgUiAvUmVz
b3VyY2VzIDE4MiAwIFIgL0NvbnRlbnRzIDE4MSAwIFIKL01lZGlhQm94IFswIDAgNzky
IDYxMl0gPj4KZW5kb2JqCjE4MiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQg
L0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxCjUgMCBS
ID4+IC9Gb250IDw8IC9GMy4wIDIxIDAgUiAvRjEuMCA2IDAgUiAvRjIuMCA5IDAgUiA+
PiAvWE9iamVjdAo8PCAvSW0yNSAxODQgMCBSID4+ID4+CmVuZG9iagoxODQgMCBvYmoK
PDwgL0xlbmd0aCAxODUgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv
V2lkdGggMjU2IC9IZWlnaHQKMSAvQ29sb3JTcGFjZSA1IDAgUiAvU01hc2sgMTg2IDAg
UiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVh
bQp42m3CezDTAQAA4P7rrruu67q6urq66sqbPPMIeSR5hCIconAkUTiSJIqiKJJI/PZ+
2Ma8hmGe8xjzntlmY2zz2mY2j3mUfrgr3fXdd0AFOKgCHFIFDqsBR9SAo+rAMQ3guCZw
QgtyUgtyShtyWgdy5grkrC7knB7kvB70gj70ogH0kiH0shFU5SpU1RimbgLTMIVpmsG0
zeA61+BXzOG6FnB9S7jBdYShFcLIGmFsgzCxRZreQJrZIc3tURa3UJYOKCtHlLUT2sYZ
bXsbbeeCuemKsXfDONzBOrpjnTywzvdKXDxLXL1wbt64uz44d1+8hx/e8z7By5/gHUDw
eVjqG1jqF1TmH1wWEEJ8EEoMfEQMCisPDi8PeVIRGlERFln5+FlleFRVRHRVZEz109jq
qDhS9HNSTHxNbEJN3Mva+MS6F0l1Ca/JicnkVyn1SW/rk1MbUtIa3rxvTE2npGVQ3n1o
Ss9syshq/vipJTO7JSun9fOX1uzctpy89txv7V/zqXkF1PzCjoIfnd+LOguLu4ogXcXQ
bgBGg8JpMGQPHNWLQPeiMHR0CR2D68Pi+3GEfnzpAIE4WFo+SKwYKq8cqqgarqweqSKN
kGoZNXWjteTRunomuYFZ3zjWQGFRmlhNzezmFnZLG6e1ndNGHW/v4FI7uR1dvM5uXhdt
ortngtY72UPn9/bx6X1Tff1T/QPTA4PTg0OCoWHB8IhwhCFkjIoYTNEoc4Y5NjPGmmWx
Z9mcOQ54fH6cO8/lLfAmdk5Miif5Yj5fwp+STE1LpwVSAVi4KBQuikQy0YxsBjy7NDu3
NAeel8+DF+QLCwqxWCGWKCSSZYl0WQpeXFncLZOtgpeWdsvX5GDFmmKnUrGsXAavKFdW
1neurq/uXdtY26vcUO7cBK+v/72xAd7au7m5/8+trX/u8+vP/9re3v4NEhkbcQplbmRz
dHJlYW0KZW5kb2JqCjE4NSAwIG9iago3MDcKZW5kb2JqCjE4NiAwIG9iago8PCAvTGVu
Z3RoIDE4NyAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAy
NTYgL0hlaWdodAoxIC9Db2xvclNwYWNlIC9EZXZpY2VHcmF5IC9CaXRzUGVyQ29tcG9u
ZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnja+/9/ZAMACAD/AQpl
bmRzdHJlYW0KZW5kb2JqCjE4NyAwIG9iagoxMgplbmRvYmoKMTAgMCBvYmoKPDwgL1R5
cGUgL1BhZ2VzIC9QYXJlbnQgMTg4IDAgUiAvQ291bnQgNiAvS2lkcyBbIDEgMCBSIDE1
IDAgUiAyNCAwIFIKMzUgMCBSIDQzIDAgUiA1MSAwIFIgXSA+PgplbmRvYmoKNjUgMCBv
YmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJlbnQgMTg4IDAgUiAvQ291bnQgNiAvS2lkcyBb
IDU5IDAgUiA2OCAwIFIgNzYgMCBSCjg0IDAgUiA5MiAwIFIgMTAwIDAgUiBdID4+CmVu
ZG9iagoxMTQgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJlbnQgMTg4IDAgUiAvQ291
bnQgNiAvS2lkcyBbIDEwOCAwIFIgMTE3IDAgUiAxMjcgMCBSCjEzNSAwIFIgMTQzIDAg
UiAxNTEgMCBSIF0gPj4KZW5kb2JqCjE2NyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL1Bh
cmVudCAxODggMCBSIC9Db3VudCAzIC9LaWRzIFsgMTU5IDAgUiAxNzAgMCBSIDE4MCAw
IFIKXSA+PgplbmRvYmoKMTg4IDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvTWVkaWFCb3gg
WzAgMCA3OTIgNjEyXSAvQ291bnQgMjEgL0tpZHMgWyAxMCAwIFIgNjUgMCBSCjExNCAw
IFIgMTY3IDAgUiBdID4+CmVuZG9iagoxODkgMCBvYmoKPDwgL1R5cGUgL0NhdGFsb2cg
L1BhZ2VzIDE4OCAwIFIgL1ZlcnNpb24gLzEuNCA+PgplbmRvYmoKMTkwIDAgb2JqCjw8
IC9MZW5ndGggMTkxIDAgUiAvTGVuZ3RoMSA2NjY0IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl
ID4+CnN0cmVhbQp42q1XeXxTVb7/nXNvlm40LdA1NDekjdK0FApYKLVN2qbgVPaCCRZJ
aSstglTL6iAEFdGwKQ8YQUdcRkV96u0ikwI+qqijyDbq4LgBIjPifAZBP08dFXrf99yE
Smd87zN/vJx8z2892+/87r3nECOieAqSRO76BXUtNIoNhOYQcGv9kkXKtpZ3lxCxEiLj
sJtb5i7wPfm1h8g0n8jwx7nzl9+8fPHVKUQJbvhfaGqsa/gqxnmJqN8wyNc0QZG8IH4N
5CbI2U0LFi1L8LBmyOvFqPMX1tdRLb0I+SHI5gV1y1rk1fFbIT8GWbm1bkHjkcz6aZC7
hdyysHWR1sHGQz4F+eqW2xtbpva8/iVRopkoVoOOkViPWJGR5oA+RXlRzf/3jyMCeygd
yDA8Q+myk9KItC+As4L2NGtnhV1Q/jf4h6Mg2kUvIAYv0H56jV1Aq5eoizrpLUqlSnqE
VtAWWovZz4TmfpqKYoB+C0vXOqmAHsc+PU6H4XsDraQ9lMLStC9pFa2R3kOrNZRAg8lD
k2khbWDXa4sR3ZPy3VRE19Ot1MKCmk/bqG3Wfoe4dElvaZcojjKoHuWw9pXhz9onlI8W
W2k7nWSbY14mN0YJwvO3dDvtkGbJTJur/YgZ2Gkp5iDTBDrMurkLvTfSFyyNrZAq0MuT
mqq9Di8rzaIm2kF72Cg2jtsNtdoE7TClYIxl6HU7tdNulDC9Qh+xeMMF7XfaBUrHfl2H
9XTSEdYt9Vxa3VOGiBkQpSE0BpaF9F/0BzrGHOxVvtAQbyg0uA13aO/TABpO0zHbZ9Dy
r+x7vhJllfSmXKWVUz/E5UERbXqDPmMZrIBNYjP4EL6QPyrdTmaMOBylgZoR74fQ+wnm
Yrt5PD8qPSk/L/9kHNRzSuuHHXHSw/RbepUlYKUKa2V3sePsc17BZ/OH+Wlpi/ys/K6p
Dqu+iRbQBnqevmfJbDSbwm5kTWwFW8seZNvZYXaMneUeXsNv4eelJuk26RW5HGWa3Crf
bbjXsM54tsfX83rPH3u+1wq1e2kK8mE1Zr+VHsXKuugofYhykk4zA4tj/VAUZmfT2a9R
VrIN7Am2iz3LOjHKMXaafcm+Yd+ynziSlRt5JrfzwSgOfjtfyrfwR/hRlGP87/wHKVUa
LLmkUVKJ5JcWYlZrpQdQXpY+kzPko7KGOBcathl2GnYZnje8ZrhgjDfdZSbzoYtPXsq9
dKKHeu7r2dbT3tOpfUYDsYcZiIKNSjD7OpR52O9tyLiX6D0Wj9hlsFxWyq5HZGazeew2
tgyRvIftYE/pc3+R7UOUPmDnMecEbtXnPJSP4uV8EspNvJHfxh/gm3knP85/lExSnJQo
DZRypXHSLKlRWiQtl7ZJqnRI+lQ6LX0nXUTR5FjZJg+WnbJLHifPlhfLj8pfyF8Yag3v
GP5ijDUuMN5rDBu/Nl1jKjVNNk0xzTJtMu02vW8OIDsP0Mv0+ysfe3ZKWi15pZdpIx8h
p/Mj/AjyeTY1SBM4MpXvYvfxO1knzzYsM47lY9lEuiA7Ees3+U7+HR8rTWDVbBrN48Mj
vRkHyM+BlMgH6Jy8D2s7gp6XGePZSn7eGE/tjPgYjPmGNEx2Se/QR9JJZpIfp4/lWJbK
zvFnpMnIglfkUoOP7NIj9KJ0G7uTXuZevA1/Mq9HHk9kz+G9UMMK2T8kjSQ+EVlUJH1O
d9Mt/M90Ds/xffQb1iDPpY00gq2gL+hpPBVDDLcac40D2du8WQ7x/qyTuPwsVjeGZTPJ
MIDuYbOkHcbz/ENaTEflWDoh/Sdmf5S/KE2QLximsiY8AXfSvXSbtpqWG3zyu2wuSWwG
5cin8HZbIRXKdtBVeKvU4p22G0/3HrwHPNIEaNKQOdcjL6bjDbED5SG8J2RkUDOe8Rvw
FjtCncYaHqa5hn4Mbx0i+Z2eqTRTe5q2a3PpVm0z5eN9sFZbgR530V9oE+1ia3p+TS2U
hSfnBLveUMWPGqq0fB7iH/JpfFvf/UW0c1ga/Q3lRaqiUsNeCskf0DQq09Zrf0J2X403
7HZ8W35FZ7DKrzDCeKmbRvRM5G1aldSC9Z6kKdozmo3FUpM2nybRPnrKZKA6k8tdMb3G
4y4rvbZkbPGY0UWjRo4oHD6sYGh+nit3yNVXOXOyHYPtii1rkDUzIz0tNWXggP7JSZbE
fgnxcbExZpPRIEucUZ7XURVQVGdAlZ2O8ePzheyog6LuCkVAVaCq6uujKgHdTenr6Ybn
zf/k6Y54uns9mUUpoZL8PMXrUNTDlQ4lzGZO8YHfUOnwK+o5nZ+g8w/ofAJ4ux0NFG9a
U6WisoDiVauWNIW8gUp01xYXW+GoaIzNz6O22DiwceDUVEdLG0stZTrDU73FbZzMCZiU
muGo9KrpjkoxA1XK8dY1qJOn+LyVmXa7Pz9PZRX1jjkqOcrVRJfuQhX6MKqxQjXpwyjN
YjW0TmnL6w6tD1toTsAV3+BoqKv1qVKdX4yR5MK4lWrqHWfSfhbReXKFb+2V1kwp5E1r
VoQYCq1V1Mem+K602kXt96MPtOU5VYFQFYZejyBWT1MwGl/j96lsDYZUxErEqiLra3R4
hSYwT1FjHOWOptC8ALYmI6TS1OX29owMd5d2ijK8SqjG57CrZZkOf12ltW0AhaYu70h3
K+l9Lfl5bZakSGDb+iVGmfiEK5nGXpvO6e6Cq57aG1kmZuS4DgmhKvUKZuJzYE2jRdU4
mkL1o+GGn5+hldqAHWlWYyoCIUux0Iv2qiHH4lBC3xIywHHu7301dVGNMcfyLQlW5Elv
qsF+mVddLjU3V6SIqQJ7ijmW6vKo/LwlYe5wtFgUEISPJiO2df7iAoTfbhcbvC7spjkQ
1OAUX0RWaE5mO7kLXH6VB4Sl+7Jl4HRhCV629DYPOJDJnfpBcqBqdvb+Ey0p/b1NxSpL
+T/MjRF79TRH9ZSZPsUbCkRjW13TR4rYR/faopzav8InZfIoxzMl3YqkrO11FoIvXpVz
8DfqSd0QNpmRlbqGKVWqJTA+Uvtj7fZ/s1FYuyBa6eTnZtFpqsWuvvLYPnKf6cWHJEwY
n8HqmpmhUGwfG1ItMuB1UYKMpxqfXalQaTqezBz8w1r3aAF/pupGyCqEA/IvooqKfRwz
o7wfP5Gd+XlVeNGFQlUOpSoUCNWFteAch2JxhLr4a/y1UIs3cDlxwtqedZlq1Xo/YtXE
ivFQcCoXj3FFje/KDdKz3p+v3wOYfkA1EE68Jirv5OyM0RTm2939ySCfkSjWJJ9hlG42
Gs5waR8+/DE4Bg6lNJflu5JLJRMt/10y4VIJlYG3XEQ1fJg9yZ6Ug4rhs3dRkbovug30
Eylyt7jdLGDHeBNOAnFk68IndZq7X4zxkELDcMJbHH/DM6LXWeeo4NzwYf1HXjOiEN8Q
o2Owc8HWpuatW5ubtvIjzVu2NINHX9pFdlBeyG/EvLPciWwU8QyDgiHS5Y470lwTLWdm
Wf5KBRPQlTTKPlCWW9nBBx8kPcul+MN3TfLmzU4s+dacada/mt1fnU2/TLWL0YgQxfTe
vkBNpT0TqcJCP77UM8JS/C/3MskIFT9MC+RW0QNdg9PBssh4TNy36tElJwtODDPw1U/A
fU8StzB4JEf7MuKsTz6vZ3q1x+W5vblu/oQa3QM/7SqcQX/pJwFrqb2tJtEzWEql84AG
SGRDXQBMAmYDm4CdgJESo5qFwCpgP3BBt7il1PbNI9xhkHU66Zg3v1AX6yJi7Sxd7LjB
H6ETpkRo5XURt+KI2/CREfXQ8gi9Ki9Ck3MKg4LGJhR2e1KkFDoGcGpBzfjrlMgYTk+P
SQNJBTgCGtG4peSObGfhzv2STEziCGcD2bRuibUnJBV6YrnGzyOGNv4VPxex8HMd/ZIK
d3p+xU/TS8B+QOKnUT7jn9EqfgoBt6AuA3YC+4GjwHnAyE+hnEQ5wU9QIv+UCoAyYDaw
E9gPnAdM/FPUFv6J2D69FnwZwPknqC38YyzrY9SJ/CNwH/GPMLX32ovGFHbpjKsgythy
okxqZpRJTikM83fbfxhiC/PPOxSX7THPMP4+qQAyArUFUIDJQABoAYzgjoM7TkHgAeAx
QAWMaHMcbY6jzUHgEHCchgFuYDJg5sfaMUyYH213lts8Kbga/AHXdBs/zN/S6SH+pk7f
4W/o9G3QLNCD/M32LBt54mAntLGAWkALYDfwVzuyk22aJ4nvR3hsqAuAMmASMBvYBBj5
fj64vcGWjE720kE8kTbeTl/q9Gl6wkzueTa3swI5pojKWXwtOFQ7lZ1O7nZu2w5RVM6N
m8GJynnPenCict6xGpyonPOXgBOVs2EeOFE5Z84GJyrnpBpwqML80d9nX2UrmnQLUzyJ
fCmitBRRWoooLSUZN08U+kEWc3u4PTcXEdvhdg3JtQX3sOA+FpzKgk+wYCMLrmTB1SxY
woI3saCLBa0smMWCbhbcy0YjFEHm7uwjjnGnseBBFnyBBVtZ0MmCOSyYzYIKK3KHub39
uhE68eqkwyOeK9BrSwsTMUc7ImpHWtvx2O9HfRTQdMkNJ2VwxDk9S9DBHbllEXloceFC
z3h+AA0PYBsO0ElAxgYdQBodQCcH0EEi6jJgNtANnAc0wAjvwZj4Jr1ORF0AlAGzgVXA
ecCoT+c8wGlhdIov6RMriE56kpD4ARRxtbdzu3uQxWpxWcZLm6wsMYtNytKyeBGlpOA1
l5xkTgqzhN3fJ/zj+wSK8cTwjXwTDcJGPBClm9p/GGQLs4fanXttnoHsN5QlI+vYGHKy
HNDR1KrLo8hqFnQkWfnzoIXt1hloltjuzLPtYf1Eq922H6xnbF9awxzsWete2wdKWGbt
tj9B8/xu2/vW+21vF4TN0OxzhhnIHkV37bKOtr1wUHddDcOOdttKQXbb7rSOs91i1Q2N
EcNNrZDcibapzpm28eiv0jrH5m5Fn7ttZdabbCURr1GizW7bMEzBFWFzMdkhVn1QR5be
4fSiMGty55m2mXymSaZrTIWmPJPdZDMNMmWaBpiTzRZzP3O8OdZsNhvNspmbyTwgrJ1y
u8S3Z4DRIohRFrWs8xYu6sinCecDM8dlUe0vVfPqaeWsWu2up+o5ivrdNEeYxeKsZHCU
MzW5mqprytXRruqwSZuqFrmqVdPkG31tjG30Q6vy+8IMB50w04RqTaa4lXQRY0lrNmQK
evWaDX4/paUsKUsrSy5NGlNV+QtVIFq7fv6l9eEHqduqp/nU5wb51ULBaIP81ep/iGtL
F/uGXfBWdrGvBfH7uqRS9o13qtBLpZV+f3WYzdD9SGFfww8Z87XuZ84iRfiRYs6K+O2I
+OWgPfyyBYFfTAzl6H45MTG6n8yEX1trtreyLTtb90lVqFX3aU1VrvQ5mAOfnBzdJyVI
B3WfgylB4aOW6i5WK1yyrLoLyyCr7mJlGbrLjJ9dCqIu9/e63K+PJLGffawRn4RTl30S
TsHH9e/+GstdLtYx1l9fK658AYe3EQio65Y0panBOYrSVu+P3gWdgTn1TYLWNap+R2Ol
Wu+oVNrG1v6CuVaYxzoq26jWW+Nrq3U3VraPdY/1Ouoq/R3jJo8s6jPW/b1jjZz8C51N
Fp2NFGONK/oFc5EwjxNjFYmxisRY49zj9LFIz/HJvjYzlftxw9BpB4+LRb4GMu3+8hRL
S6mevGPtaSsz9+BAsovicOGKx+U9ARCmfE++R5jwTAlTP3Gvj5rSVo61Z+5hu6ImC9RJ
jnJyLVrcupjSvM2VkX8rflAtWiwCHqldrf/bDzYvruiVrYuIqtXcadVqGQ76bSYTtAGx
JLX4si4uzoubRUQ5FMpioZSkXkehKxG6mJio47/u/+IorRBPQZDv7WDuLLaIWv2SmlVd
w/EqqIleoPbguCQ+D61+LLCVuVjr5T70aVOEJ7Hey1i0OMpF47AoSiOt0KT1cjh6fyJK
9D8NsOStCmVuZHN0cmVhbQplbmRvYmoKMTkxIDAgb2JqCjQ0MzIKZW5kb2JqCjE5MiAw
IG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCA5MDUgL0NhcEhlaWdo
dCA3MjMgL0Rlc2NlbnQgLTIxMiAvRmxhZ3MKMzIgL0ZvbnRCQm94IFsgLTY2NSAtMzI1
IDIwMjkgMTAwNiBdIC9Gb250TmFtZSAvWEVBVUtBK0FyaWFsTVQgL0l0YWxpY0FuZ2xl
CjAgL1N0ZW1WIDAgL0xlYWRpbmcgMzMgL01heFdpZHRoIDIwMDAgL1hIZWlnaHQgNTI1
IC9Gb250RmlsZTIgMTkwIDAgUgo+PgplbmRvYmoKMTkzIDAgb2JqClsgMzUwIDc1MCA3
NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAg
NzUwIDc1MAo3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUw
IDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwCjc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1
MCA3NTAgNzUwIDU1NiBdCmVuZG9iagoyMSAwIG9iago8PCAvVHlwZSAvRm9udCAvU3Vi
dHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9YRUFVS0ErQXJpYWxNVCAvRm9udERlc2Ny
aXB0b3IKMTkyIDAgUiAvV2lkdGhzIDE5MyAwIFIgL0ZpcnN0Q2hhciAxNjUgL0xhc3RD
aGFyIDIwOCAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcKPj4KZW5kb2JqCjE5NCAw
IG9iago8PCAvTGVuZ3RoIDE5NSAwIFIgL0xlbmd0aDEgMTQ2MDggL0ZpbHRlciAvRmxh
dGVEZWNvZGUgPj4Kc3RyZWFtCnjarXt7fBNV9vg9984rk9ckadOkD5I0bVMaoNDSlmKl
Q18CpRQKQovUFgWkKo8CoqgriAhSH9TV9YG6sCqIsLuEVjBUV1BRUXFlVUTUlbqComuF
VUBFmvzOzLSI38/+fn/8Pt8kZ859nHvn3vO+0ykBQoiFrCCMqFfPm7mQ7Ieh2HIAYfPV
S5f4a87PeoAQWEKI8PichdfMu6ronu2ESAoh/KJrrl8257J5fkqIdRUhad1zZ8+cdYqE
NhMSnoXjC+dig6WOT8D641jPmDtvyU1XzJafxPperE+5fsHVM6vaaxYSMghpyKB5M29a
yM+yYt8gFev++TPnzfbnXZmK9WashxcuWLwEfPQfWL8H6+MXLpq9sOGJf57H+ke4iUJs
A6LtR9uRQNYjHkrGYAvF3XGExzaRSMREZPK/+zHj/ayIbXrNTpA7xEGc/4PKpV9xp3wX
SdFhM0nhskgKIfHj/RC7Ln5c64tdHz9Ov8INpRrQ97mZfAgh8JAz4CTbIY28RZ4jH0EO
uZW8A7OImySR8zSD+EHbq4dMIVvJWyCSBtIZ/5psIdPItxyQ+0k3DCJTyQGwIV8uJ0+Q
CZAY30b+DTTejTOMJBNJOyTwS/mPYCXhgdE747nEiiPvwNWPIo+T9+FW0874IVJE/saN
j/+HPAIemoO7X0i+JKdwfYPpCNoYn0dmkuXkZRBYOf9AfBCZT86z1fGncCUimYz3bSK3
kYfxrqNgL93OzyKppBSlNY40knlkM/kLncOf0mWXRa7Htb9BTsBf4BN2gv3MSdyV3D18
ZqwU75lO8skI3FkTuYosJveQR8hLqAQ+qINH+bze25EnfpxhGNKsICvJWtKJvTZwQCJM
hSfobfRd+h33LP9R/F2kGk6W4pruIC+T18i/yfcgwBAYCithN/yDAl1GzzF/nMRfJNnk
MlJHZpAbye2knTxKOsiLyM2XaQ0rZzeyCPdv7pfYPtSJ6bimW0gneZMcQrk5IZVm0W9Z
gN3JnmIH2BnciYu7A2m7cRdDcY3j8TsZ978Y5byG3Ef+RLaRXaQL13OQ/IN8Qo7jqkfA
dXAr/BFegLNwjgZoOi2hC+gfaIR20X8xN5vEprBW9hBbz15n73MOroyr5p7gdnEfC4OF
E+LM2KbYF/EJ8fr47fHfx1+IvxJ/P/4dWoQVVxAkg0gL8roV97UcOflX8hJ+95PD5Aj5
mHxKjqPWEbBAChTAOJgMl8P1sAjug3XwIDwCr8HfqUwdNJHW0on0Grqa7qfvsmJ2CYty
2VweV8lN567jlnCr+Tz81vD38Fv4rfw2/hR/XnAKWyUiHejN6f0sNje2NPbPuBy3xQfE
h8Zb4mfQbgeg9GaSa5AnjyFPnkbt+DPZS/ahl/oH+QBX9yn5J/mMHMUV/kDOQwK4wYPf
FBiEujUBroWb4HaU4iPwGDwFuyAKL8Kr8A4chH/Ae/ARfA7/gm/gOzhFGfVSHw3SMG2i
c+ly/K6mD9BH6Xr6FurJu/Qg/ZCeoD1MYeksl43AbwkbzcpYG9vGDnKJXBJyu5a7gbsZ
Ob6Z28u9zP2D+4InvMK7+Ax+EF/N383v5d/Q92wTPEKWMF+4Q1glbBKiIie6xUJxpbhW
fEz8k/iBlCAFpY3SC7iLbPBC8sWOBOrhdbKdjYcGWANTwApt0EASaJj8iWul47jH6Tqa
Q7dplEIxF9Ewe5bcx4DauXZ2PzxIdgKQS8gqGEVuhN+jpF+Hhahdg8h6tofFaBWgW4Cn
YQQ5y95Fn3QIuTUchsFlZBzdz/2df2PGGppBr4Qj3JWCiXudPEBf4Jq5Ag6Qt8vQ/d7F
7iWF5Du2mB1Dq5jHtaNF3gocuZReQk4j/hB1SIFMOoSUwljmhYlsDiTjPrWxh9BLtNAd
tJTsgwfpdSwbboE8cobESCf/KnmUr+MOxSdwO+N+bLlZZ8ZWnAf3CPewZm5gfFrsR1jD
PPRllkUvhe+5mbQl9leoheH0OBsGi+kS+AU6IRs16C1aQ0dDMn0adf8M+RZ16Dz5D+ng
HmD3xj9j22KT6Iskg59B3kOPJpBJtAt+IO+jP30JtUJCn/sXrpDsZPPJKdZMo7QXfqQ/
kj+Sv6IX3k5D8AlVSY/QxHXD8QU2GMDmoE+jZBN65avYd2R0/HPigyXxd+N7IAXtpQv9
0n/4V+kC8nv0Fy+hR7kN/dhM1ObriQWWoQXY8NuJuv89+ockFA+PPnQ+2ul69Jdd6C8O
odc4gf2fkrNou4+STyiQicLjuPJT5BXc3zmQyG6ShzHDhrZ0LH6Wew959xxZy4C8KrqE
Udxq8jd+jzhKLZuilo66tOSSkcUjigoLhufnDRuaO2TwoHDOwOxQVmZGMD3g9w1IS01J
9nqS3IkJLqdDsdusFrNskkSB5xjeeFBlsKrZH8lqjnBZwTFjBmv14ExsmHlRQ3PEj01V
v6WJ+Jt1Mv9vKVWknPM/KFWDUr1ACYq/hJQMHuSvDPoj71QE/VGYPqkey/dWBBv8kR69
XKOXuSy9YsVKIIAj/JWeuRX+CDT7KyNVS+e2VTZX4Hw7zHJ5sHy2PHgQ2SGbsWjGUiQp
uHAHJI0CvUCTKkfuoESy4qoiycGKyog3WKEtIcIyK2fOikycVF9ZkRIINAweFIHyq4NX
RUiwLGIP6ySkXL9NRCiPiPpt/C3adsjd/h2D9rbdE1XIVc1hy6zgrJkz6iNsZoN2D0cY
71sRSbr5mOfXKk7uLK9fc3FvCmur9LT4tWpb2xp/ZO+k+ot7A9q1oQHnwLE0s6q5rQpv
fY/GRU8uLkRbvrYVY1Ozg5VaS/O1/ogpWBac23ZtMwokuS1C6pYFOpKT1d2YNyRX+tum
1AcDkdKUYMPMitQdCaStblmnV/V7f9szeNAOxWFwc4fN3lewWC8uzL7Qp5d0cq1UXXeB
naCtKDgW1SDiv9qPK6kP4kZGaJfZI0jb1SOQDD8NgKMis1AMLRFTeXObMlJr18ZH+Ewl
6G87Q1DswZ5vf9sys69FyFTOEK2oKccFBcP+/nIkHI7k5Gh6IZajIHGNo/R6weBBS6N0
anCh4keE7CMT63FYw8hc5HkgoEn17qhKrsJKZMWkeqPuJ1eldBA1N9wQoc1az97+nsTL
tZ4V/T0XhjcHUX2f03PexIiUdeFnV9yuyrkjI+D+f3TPNvqrJwerJ02v91e2NffxtnrK
b2pG/4gLfX0lMDqQ4REuEzk1NogaVze9XmvAH59ZFaxsaR6DFoZrjLjK61kKbTBKNIXp
U6Hazrgws1apt2hzcZmCrvazIgzVVm8Af1VEaR5jXBvkQOD/OiYqShcNisZPaaN09Ouw
vi1FRoZ/W7/kN/XfrM7SxnC9XBatnjK9rU3+TV8V+qi2tqqgv6qtuW1mNL7iqqBfCbbt
xmywvG1hZXO/9KPxrrtTIlX3NOAm5sJI1GxKygajcKgmIcwTMFCjXy95jsLzghilZ1QP
4bnnGZFF7nkgXkngn6csYtrzmSesnC3pLZmgnC6p6S0hpVhWzuNl2NCAI+DIxAvggee8
n+09r/LkF+LntAMXRqBV8a+43/N7MZr4yTjVIXOSwJkF6wn3T25hIIWUKKR28LwTkZpg
sXpa8KQnUSk53d5CvIEXH/aE8ZY1PROUs401PaS0p7Rn2FDSCI2u4UVOkp/nTEygJJhO
MxPc+XlFhS6MH1nBdFFgwqrqGWixHcefiR3r6PgKkseXTBw1Wc2vKRl/ybTSQvjnP7/A
1NYWi539PGaOnQHatbR53NUQ/GrN/Jljr42d0Q5CGA0J58YswET+oKZUkxpTE2mCJhM/
CLPMQr5QmMp+Ngkcz0ehCdmXIAiiSLrofAIsSTUzhj2CRRQUNtoMTxIO5hCR3ovHmwgR
6A0EaKvqUDRTKSW1pBm555WFpChL2PGDJ6zturG15tjZntO9PWFFY3hpiXK6t3gNPyT8
O2XfsKHQSBpdroyifAi4BOGHQlj89vbY27Gjh6b/m40D8uThc5eyn0Y26yfUW3Ef96MM
fDBOnaGfRo3zo0tYlgDrXeDMtecqg5NGJtXaa5XahNrEWvc014Oup1ydri7PTt9eea95
r+t91xFPt+u4+3jSadcZ95mkZLvD7rS77AncUJtq22s7aONsUbhWdTjwlGjX2iJ6K4+t
V+5SHJYmXEkXXUTSUOIcr3TRVmKn61Rrcss6MS5SIioiRR3M2RUgLX4AiNIFnYoDHF0w
gfiRLQ9rOth4urFHOdPY2nP6GCntPdaIithY4nAWg9LTuEOg5VPqd1o4RwJnI9iIvwbk
VGsj2uxuYo13dziLndH4Tx2OYlM0vheRbCCzgSwGshrIZiAXDthhKSZhCPd9GlABWxsh
s7AwPw8TEkEUOEEMsMAoWlRYVGiooEDTYl+l//zCO9+MqbskdnpaNpwvPH+n7eoHX3sw
VDV8WnnFHPafnANHPts2bXtzxc9X5MfOXf/qlhfuC09YNGTcjGuQU3PRbm5BmQ0i36s5
fk+FcHXKqnQu1/OLRP3S1OSW1KXh9ZS3yFa7N9GDyhXMclpFi12zo1RFBjlXrpW75VMy
J3sIYChZCCvgFHDQxQYidapqz7HaPbDAs9yzzhP3cB6tPRElk8ajDNY+PzSrNotm3e7E
smohfsVP/clDVAtYovCwam/3bPRQtFVvuzfiZd4o/Ek1t6PIsGXw6R/6bBZF1dv4ZaNh
uig2XV6t+sVR3Jjb2gOGiPok5ch35Btqjdad6UZ77jPmogtFQcxEBvcx3Y1XUQimZ80F
l6Nh3FW3z613e/LstsU3TSobdVVa7Fxew5rX3npv9Q2N9Yuf+KnrP7A8cMP0VddMb+FO
0htmXVZ3xfzhT05b+fkTi6LhYY9f/uRdXYd0fzUCbeUWvgttxAqL1N/JFq+FitTEJJ4J
TJTMkoVaPczDu4Uk0WNxWm3OEjqeNuDpbSt9gQrZbDKbTRewZustbC17jG2mm6VnLVH2
PLePvsk+Zoe5w5LTxJssY/mx5jEWnlIrmFGKgsSZQOQ5k1UgFhlEPBkCi8I01WSxJlgs
Vs5kQi+jWmRLgixbmCyaBBplHtUlqNaDVmp9X/Qh/4GZZAuK6NqdHOMsiulv6GtkFLcP
k/qtqjtXLpU3yGy5vEc+KaOTb5LXyUyO0ndUXECynaCaUDS7NTsnWiM4Z5TO67DJSVF4
VHdJ6JF6UJpf1qBAG1t7e5SesOaXjpeWOItzGzU7/FKXaPEa3UWtGeIJS4jt+NFEDMW6
KZILxqjKSjFTHMUUQbOtBl32gSLIZ/likAVcLqDLevfkMe9PL3fkd5TGvl/UFPsdhE+x
Dednn44doj54M1ak+beVaCsb+M0kAFQtd6nm4gQEzaeV2C9Rauw1ypX26coC2zHpbOJZ
t8UPfi5byU7w+y9VSh2lCQ8rjzjWJ5xwfOE8nnwm0Z6QmBiF7apbcSQoCh41Ei0eMlE3
oG7NfOCvRIDUnT7rAjvYo3RdZ7duFNNVxePyJ5Qm1CbsSXg34WiCkIBur9Pp4ExoQh0p
u9CSWncSl+KirtEWeJgE8fx8hCTSDGKHrcSBgUGhR1QztKAYiDe9L/K1ouUc6+k9hiw/
drqH6N4ut7cR/V7v2cZig9u2IWH+QkgIh12ZQmLCRSYTcqFrEvt8FeXQYFZCElwxds4z
V04Y0TLs26P088KYtzxnysAtHz0cO/3AC/+Bp70J8pw5r/55ztzhBU7aEzv3L5frXy89
Ejvyx+91G9kc/5J7DH1TMskmPepcyc+HaIFUECqTykJzpLmhpdJq6SHpMfdm6ax0Lvnn
oE2QQBDlpAQxQcrxFvmrxHr3HKnFeS1SrpL+IG2SPgx9IZxwfxlyobJK6SkTMyFztoIe
jMqo1k2wAY4CQ97/SXNdHR5+gObm7A5rruZzlpN1pBvzGGSw6kpvsVuBWBXrQusK60lr
3CpYozBeVXJSWtTEFYmUJCqJ7Yks8UX6DhkIG+lBokeV1h79omm4lmSgj1qUi2Xoc086
b9HltwKfpecXYh87Nf+TVaCQQJ4bjBTE4LrAPRb7QSovHls8aVjj3K2frv9yxS2vXQcz
IO3pV3oLZlRMKZk0fXTRwlJuinta1cjJuy89sX9D7PjKW759HdbSjOfOP7Vk/oSWHYvm
Td6p6fcH6JPeQ/22k+fUKjvqNkH4iQOTPYlTiQqXiVWWKtt0vl6YZp/DzRGX8susy2zL
7Hfyd9vW2h/lHrU/a99v3W8/LB62JJtRb03oWp5UFWr368nHHvIuOUoEogVqChz6EIbM
7KTJDtOLmgfBSK1lKxaNtols1FIVpQs2w2NEV9LGGtRNdPM1x/Q0BVVU6QVHv7mjRroC
okApci2A7ttZ9EEReyM847O/lUxOiJ10lted/Sv3BJgOjIsdjt2/6diC+Xu/hejbWma6
BvVsLeqZl2SSYeQ1tXSktcQ21fmM5cMwH7b6nX7XpXy+s9A1xnm5rcG51LbadlfGI9Ij
lt0ZJ9J/SndYCVhJWq5V9pNk1p0LuZqZykPTIC0teHIgDMTqzgRrdxCCWscAkR/UskAB
5XZ/C5EVmfowiibnJ7f42VBGWRddQLIwGJpJkpJEk7x5L/7Qt3lNa3D3rf1RrgeNs9FR
3K8/fSrUzw5AfRle+NsgFkjX2lwXWS27qAzRmprrD9+179Nbb53ecO362JlXvn363JTy
mhumlte2rpg+ZsGyxjHT72ah/DsnXfnKwgOPz3+qsOiJ2Zvv2nd8xwMnIKvy8hsmXFa/
pFeou3Lf4nFNm9F+NX95I/LVQ7LI39XGkdLIzFrpOmmZdJf0qPRgwvf0Z+m050zAYhJZ
YqqYKmWLWUnFA6YktEjXOG6W1krrpWelI+KRxCOZX7Kvxa+lLz1fZ7pvE2+WqGa+fm8T
snT2QhnsyMEoS9w5EdoxsPSbr9uaqpnvQIX3thgOMTnb36JaJ1qbre1Wznq7X88kiIIr
9YZ+ZXOjwee+c0Dv6UbNYi82UY29RuaAeZhmmQXDtSMCJtnIYDAOBoZrLFwJVs06R9QN
bbxm66eQ/PXfP449Ffvimf300K/GCXXuqVXFk3eXfLW/G2bEPoiT2A29n+1hdUvm6cY5
ZSeucAbysoIrRX8+DJ5R592UvTp5ZcqdqW3ZvJNjgp/kM7OzKrkiZWzoruS1od3JbyZ/
kvxJ6GyW2e2F3PwP2YncE0O788+Hz+SeGSpleEc6G5wtzrneW7y7yfPJH9NDng+9J5K/
Cf0721bvhWEZqWyATXQACcQzICMKbjU5dShmfAtTD6Z2p/KpAZtdZoNdg+mpwTAY89fO
PG+pjrMTDBx06lhNHWAvHRxKMBPiI9SOlzBa9gJykJzC82CUZagDAyqODag4MKDiqICK
I+wBiAcgkMOJYoVvACgD/APogCitVJMtdY58ggR0oX2vnRK7Yvfbh9rjdh5jZKkq5/vR
jWXY9ay+UvXkVCSppQVNSTA0SU16N+loEocGVfaWIenWMBoSSlYrLjrdc751kZY6YjN+
tASyRysgLtGyyJ5WLbVAcCYVaydDTB7JolZoxSRDVUCV0VXKxaCaECP0Z+8Xpe6JCUmB
rJBgqEuhlsD3WR32XVCXIvgqdmLoydfe2efIz/HEvnZwpU9PXvXnv/3wTqVz3NiaBoDk
8EdluWMuGb242E1/9ty3cdONQ6//8qXxFZNHjqqq/stdj+xyOTwlGUNGlcZeFIXkvIxL
8ypLr25B/RmH+nMQ800HyuCw2jpWgSySYU63BJSAM4AZRUbSaOc0toWcAMvBAFRwj0qU
aWmJgyqJNpYqMIU6nQ5K/UASALSDfWqOICaGbGYHkYEo3gyTmjN0+HbTuya63YSn13Wm
uIkRk2Lym06ZMDuB6uf8KFMapf4Ox40on4efr0Vh3ecnmPnt3lGjZX6YfWAO0ooG17oo
3H8exbN4aUnfeRQ8xbmO4v5Ufo2W99n26Sd1NMpWPKOy/gRE43RINHxd/2l9HOSB/5ra
tZO2vNW0YXvzsesyb1tWN+aOaTdMvn7CdXxXzF2S//nh+2Mnt03evx12XLd67rElrbfP
WqufbW9B/q1C+0shu9QRKSmQY2mgDew6eh27hd7CbuYXpt2Vsp08S7eyPyc/m9IBO+nz
jkiaKyyPoGMoAy+xOe2YOqSrZm+IM/vssEfP69LVUmfILJIMKIUFQO3gAxoHyMVqLazD
hGQPCGCvIDbF5rcxW3KaO0M7wPrFUyInHk8dOFVPK/r8VTEq8qJc4wC0CC8Gl7SkohEW
AS9wuvI5M5BDSXqCIfQpHkuHpMrY9x1vf9cO6X95sdsWOyk3jJncXjOjsnIFtA/ueuX7
D/4Cw3fs25jWMOXWH6+/cs4sLT+7EXmyEHmSRPzwkXr/Xc42H03ygfNu013WVbYeE+eS
FJNbZqlSsuwzexzeRJfP6W+QpDZlje9vpl22A6ZPTF9IolmUnRgQqcIUThmg+Cp8lX55
qnWO9WbxJudNvrXiH/xPmTZZXxT3SO9KR6SD8sfmr8WT0jnxZ+n7hF9ST/vcYcddTjrN
d43vSZn5Jc8eP6zD9DtKT6pJBBSYCHQigObvBWdayCWaDkiak8rMHq5hNdE7YPhECWol
0J4K+aWD0imJl6L0MjXfKYQsZulW04E0z70emuYBTwVxK26/m7lXpPsz7sApMwwvdMrO
2Y8H+gWiJ3o9i1q1ZLpXP4kIhpcUtBsPTjIwOj2hz1tquANdn3Hy11wSeqHSHs2/eNM0
F5mm4qg0zU+maX4yTb1A7NDknov50KIS6BN3YyuaxCL0UPqtlfhPHbLxKEIulgyk10xG
zWTUbHpth83wX7+elAwlKeI1kyIFw4sKA5qFZfYn/tyM3qGwbNo65HD1L49/GDu9bBPk
vfpl7Bxc29Bwrxe6HKZrVz4YfuwxsB/9eOuX/zkyd4ZLXrp09R26XU3FnLML/VIyDFTf
9KeCl4ftpq3OT02HLYeVjxzfOsUEjPVUcngsHjum65ZMe0ZyIYyghVKhpdBemFwlVVmm
cdMs05KXWW623yk/A1tMz1iesT/reNb5TPJOeZdll/0N8gbsp2+a3rC+6XjTeZh8ZDls
/UT52PGJ8xvlG0cul4xZoGK32Rxmi1X24InVavXbHAnYwAjqNkWPhwdlkpAjilabDYjs
sFFQrHXtNvDb3rWdtDG7LddWaovbOL/tdzZqi9I81ULqalE97kuxJYHu4jDu6D4O0zf0
b5p70x0cXi/ycNpx1qZ5Os2/2fbtW2NT9u0TbUpJiX44WIRibQ0EfnV0Ih5g+/0bfuGG
2OeQD775M7c03/5Q6srY53cmlhWPKZs62DuQ7+o9O778wZvU1b0P0GXXpBWoeWXNBfuM
56d1eHkK5cCICKLa5jeNYe2mjaaD6LwFN3gYtVM7oxIn8R7Ow28Rt5v2c28Ib4iHhR7a
w05w1iAX5HNNhUKhOJWfJqwwPSQ8JG4SNoknmBXFh5GARWiE7aV72UF6kJ2kJ5lEUaWA
YZAnlAeBcXhrQfCLJEFraWcbWYQxptlHknc4i7JM1cYBqguOEmX0gloM6RDq0Ks+rNpF
DPTtItTi6u+TxKQo3b3jHSOktIYxqPQ/2ywtUc6GWy+EEy1h1kBE/oo6j41nbhhMkM+g
nWgRYBX4CmOfDwDfZ7HPMU6cb//lY013a3Ax3yDPzHBWfVniecHDMQuzy6kmn8w5x8BY
NoYbK83j7uXWmMXL2GWm2cKN7AH2B2Eze469xg6xj00fy1+wr0znTOdkRWAmk0kuZ4vY
SvaJ6RNZSmSPm2gmCQlBMSjlWguFYeIwqUooF0dL09hUeQ4/R7hWnCutFlZYH2KPio9K
z5AtsEV4Rn6eRcU32H5xv3SYfAwf0SPsCHeYPyRgLi19aD5oPQFfseOCllH/yP8o/Cyd
Nf0oD+eidKnaoPHWJJskmZdlnjGOmmUTSoaTqNmMuVUCbptxjHJFvJzA80hokiW/KKDE
BO3ppMksSpKZyDwnUO2NJUWq84mwAYUSpWNUp4+HdXycp9qLA9v5PTzHY5q2q9Z61Eqt
VBOjbK7TkwILSeqC3VBBDBFiUtCoZ2mYif8qSTQcPP45MBvQH1dryQBiz68FxJgpJBWL
UolUskZS9kmYQCg9fc9vTX5zANUq3t0hB4ajy2swDEw7futek8W7VacFVUMp5hAkxY7Y
rj9CChM9vWvUEg4IgCvARFajmd1GWIoWePkXsc9//0o52hsP18Ru650B//5z7GX9BQcy
Ee3sT7qd3aK6CO/n2/mN/EG+mz/FixEeeC0eXVpekMtPYyuQR2+Q/fAG+wgOsxPwIzNT
xvqkQLV3GSRQWF2EdKO1ENAZxxnZVL/qLzKenV3wLtoWIbxIy5QwKObDgNjf+a5zVThy
ffwr5ucfIl44oP5Qy9axowx/kMTB76UHzZ9w7BbuTm6VdKeXA7CLhRyzsj+y/ex17gg7
xgnZbDlrYwwP3xyvv40mmASPm7p5h+BABrodJ6Ru5RvvKcFxNKUbjnGfC9xRVMajjiNe
bp+wT3kfPuS456U9jn3wBsc9LW0ybfY87Y3AC6KwwrEi5QHuIekh00ZOqPfcZFrmWSGs
EFcoQrq3krvMVM/qTQ2JQrqUZfIrGY7BiVkeIZNmMj/n5wNCAFdiNnMet5t5mZuIEmcm
Is+ZQaDMDdjH2WSbQ3ExTT8HcpyZY2YM7glIL9oJxJEzIczRiQKnMEMJucyOAxEsaLmB
VTggoseJixBB/X6BzsDcUMJTh8kMBzbguHyvdgZJNGe0uyPuvW5m5A173afdvLuLjseI
l6jJSX8gdOz0omPKsZuVn1BkntzTp1uPaef7Vu0hBzorm6HcxJOrpXTFYe2iPe5cowUK
LUAYMb//o51OWltb9fjvKsovytSfc/ZFcdE4gRS51g+6Jwhja7YPijR6c4pc4wePm/BI
W2YDm3Ro6+ux9kOx8mWOQKZ4yH7D3GE7YJuuuw8QIuzmsogFDql7bChsKmN4lnntgXUi
80qck1guufCrEOFT4VPpU9MxmXtLe7tGeFN+3fIp/ZQXnzVvtEVIJzwvviDvNotrudXi
4+Rx/nHhUfMWQbxWbJGXc5j7Scttq5hYbb5CnCRNNE2Rr6MtTCwghdwwvlgeYS61VRIx
m+Ryg4TBYo6UYfHbxCxSSMpIpVAhjjOrtrXmOyzvy3g8YWDmzQKR3eA1i5TnRFnzdkl4
kCGMQy8mCWaLReAFycRESl6gIdythf60a4UZus1gxjOLmiSTugWwF7qBwYGjMsiPNZkW
mKjpJTqGaM8jnsIDLU+fVOUmYYGwXDiJ7jBKZ6ipRFwhUr84VFTFhagv3RikDxPqp6WY
UUTpz53WSZoSaH/DaNX+5oRfzB61kubslB79LxZGlqB9jUKv9qcow43tJnK8u9OUNFxE
T/Y8YurHi5bB6X+Sar2gFK2649I9m6w9FE8qljxO9G7OXx+KBzRvxvJdEMAftyX2/fDY
i7Gzd8bHQTXwGTAW/PTp3hlcVu8Iul8Dov8BnlneuWdN+pome8kZySvpry7t/e6E9wIe
Ef9S2M2/iu7K1PcOqz5OHBWbQMpN4V9W9842jSYBZN/Fn0QBibjFZBXCDwi3IsxFGIGw
EmEzwgcIa/rqM7gvyDjEtyDciOWptJjUYbkG8US6lawXijX9JcPJ78lZOEjvYXO4AdyH
fB0fE54W90mzpO9kRf7APN9yl+UD65e2U8bLBZqCkGmERxErJJdcjhH/M0shtlF9F86+
HQkE91s1ZfykyRPDoxe1zLx+cNmC62eNXTLz+para6Zo+RWJn0YIkcP/9T3bRP0t2gTE
2puuHpwtGb1JKqkglaSKjCHVZDyZQGpxJdN3TFGjrKYzNz9Pwx2j8vVq5VijOlGvdkw3
0Oz8FVpnSore2elMMLDZmmcfnchqyHKEkwiMlOK1FmEdQhyBI/a+fsrGd0K6r/lvrBrr
1bgVlY3tLC/PW76HjSUbEI4iML11qL6osZ0FBQbOHWbgUMjA6Zl4YwuSlyIsR3i3bziv
Dze58nJHB9g47BqH91mH1z0I7yIcRTiJwOO6xpFchFqEZoQNF1qP6qNUNq5z4EjtfuP6
Njyu06zkTRytsDE48RgcMAaXq10Bh4zBacfow8Z0mpQ85+74Xvpphzo6zygUl+iFzzpL
Rud9MNpLP8NBQ+mnREWYiNCMcBChG+EUAioxXtsRNiJEcAauqH10On0bx7WjxQCOfFu/
7tdnelu/amW/Xvb30WzCCL+JLMUxT+NMTxNKn1Yzm7qFbpHuEfaIdLuwXaQbhA0irRVq
RWoX7H1t9tGNrAwZVIYMKsNdlumiLEOOl5EmhO0IexHiCALJpYVkOQIldrz6ELSWUoRa
hHUIGxD2IEhkO15Bp+unaeobHUfAEEkLsFagz1WANAXImALktNYGem8pQq3Wxsbht4yV
0SL8FuK3gBYglw90BIbr7H67v/BWf+HN/sJ+raCdCeYll+j46+QCrQOu6MCC1nBrH17a
h5v78BADd+QMz9dRvoHyDDTMQEMNlGugHAMNNFC2gQIGSjKQ20CJBkowkMtATgNZDWQx
kFlDnTl9iwkZiwkZiwkZiwkZiwkZiwkZiwkZiwkZiwkZiwkZiwkZiwkZiwkZiwkZiwkZ
iwkZiwkZiwkZiwkZiwn1cSigYZRCRoEvijLQ0VsGetNA+1Uz4nkZJb6vtTpcofoQ34qw
FKEZYQhCDkIIIaDRsNKO+wYiGtXpD/qaRpvYpWQBwnKEdQgcK+70B3w+9EcjUG1HoKKO
QNUdgWq7Aa/bEfYgsAt9lBXswnnXlZbg/b27cCk/6kvp1FcI2ww01UCXGyhFnYD4HMI3
CO8h3IgwH2EawniEcoRLEQoQitCvd8MpoE7tZYZ2jPdATEDRBJKS0E87HZL6AnVjyUTX
drS4cP6dHdnX4A7gOZKNJ1QfdEKTjiOkRcfbSAgyEW9FPBXxkx05f8RhG1D7ED2BGoZo
dkd2GqJZHdl+RFd3ZA9FNLMje7TG547QH32jTTCNhCRtwqkkB9YjvrwjZy12TzHQ5I6c
ckQ+Y4YBHdkP+EabIY200G1Im0JCOvaSHLqtw3cuFOWgw/dzKEq37fL9mFPr+yYnKsEu
39c5y3yHsqMUVLvvgyHv+N4LvON7NTvX90oLUqpm396Wd3wvIfmODH2C9TnIbWx+NGeE
7/4cVIYh2Iz1G3Ho0pxtvoU4Fd5ugU+nnh+IwnrsnRd6wDc753Zfcwjru3xNOTm+aUOi
kNnhq8PbIOF4rE3d5avGm4/tu/FlOWFfBd68XFtnh290tj6jijOAmuK7NHDMdwmuoWjI
C76CnEt8w4Yc8wVzKn3pLTjR877LrSarqag9CkG1UGz/p9i+SGy/XGwfLrbniu1hsT1L
bM8U2weI7WliguSUFMkmWSRZwsxQwsOvRKQEzK/UQVrQTxAUDQmcduX0skKJ/h8demZD
QaJkHHFGXKyaVk8ui4wIV0fFeF2kKFwdkSZeUb8D4L4GrTWy92pSfZU/cnZyMArypOkR
PlgGEWc1qZ5S5onQu6JAptSjlmsD7kzR3oXdTQC8d96b0ocbGsrru9BHuwksbiDupaWe
UucoR3FVxX+5NPddw79+PBeVw9UTl+1G9djSKfoKRaxOxmq7Vm3Xqp60yEPVk+sjW9Ma
InlaIZ7WUB1ZO9mPCSX1UHdlxW6apKGG+t1cJ/VU1mntXGdFQ0M1ilinw+jmQTqSoSGk
s0nEr9ERv03S6eg2g85HkzS6bA0hnWcT8el0Ps8mnY4DjW5Hi7+yYoffr9MECWnRaVqC
5CKa3dBEMpAqI8Og2ghNGhU0BTdqVJGwPlEohCRDQjoJpJKQPlEIUnWSgl9JAn0kTRdI
mnSSe34lyTFI2NZ+ErYVScL/C5/ZZZUtk8ugemL9DomUNWAmr2O3snCUrhlW76hNKV3k
PfZvYg43RORgWcQcxMBfiseLEsjV3ofpWA7Q2KCXTmolwRIRkExE0Ga4JOC5LaWLI7BF
n8GCzda+rsGjB4/WulDntS6b9rJ3X5fntksCKV2wpa9LwWYH3ve/bWHx4iXhxRc3kP9/
dhBPZUuF8fP0AU5/gw5LFi/RPosrK/C3hFRHciZXR0ZMml6/QxQrI2pzRQO2DelvY0xv
22EyIZ5Z0bC47xNecsMS48ikDlMxa1AxZVAxX1AxWVAxU1AxTVAxgKsYvVUM3SrGbRWD
tooRe+NoWc/nNur53Aa9vAHDZz6omFWomFKoGNBVjOYqpgkqRmcV8wsVw7qKCYaak4YZ
dEi/BPLJb1m4+DccbCBh3LHWsQSR0XVDGBb3N/dzi/wfU34J9wplbmRzdHJlYW0KZW5k
b2JqCjE5NSAwIG9iagoxMDY3NwplbmRvYmoKMTk2IDAgb2JqCjw8IC9UeXBlIC9Gb250
RGVzY3JpcHRvciAvQXNjZW50IDkwNSAvQ2FwSGVpZ2h0IDcyMiAvRGVzY2VudCAtMjEy
IC9GbGFncwo5NiAvRm9udEJCb3ggWyAtNTYwIC0zNzcgMTE1NyAxMDAxIF0gL0ZvbnRO
YW1lIC9GVExRU1ArQXJpYWwtQm9sZEl0YWxpY01UCi9JdGFsaWNBbmdsZSAtMTIgL1N0
ZW1WIDAgL0xlYWRpbmcgMzMgL01heFdpZHRoIDExNDYgL1hIZWlnaHQgNTI1IC9Gb250
RmlsZTIKMTk0IDAgUiA+PgplbmRvYmoKMTk3IDAgb2JqClsgNTU2IDU1NiA1NTYgNTU2
IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1
MAo3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3
NTAgNzUwIDc1MCA3NTAgNzUwCjc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAg
NzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDU1NiA2MTEKNTU2IDc1MCA1NTYgNzUw
IDc1MCA2MTEgMjc4IDc1MCA1NTYgMjc4IDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1
MAozMzMgNzUwIDc1MCA3NzggXQplbmRvYmoKNiAwIG9iago8PCAvVHlwZSAvRm9udCAv
U3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9GVExRU1ArQXJpYWwtQm9sZEl0YWxp
Y01UCi9Gb250RGVzY3JpcHRvciAxOTYgMCBSIC9XaWR0aHMgMTk3IDAgUiAvRmlyc3RD
aGFyIDQ4IC9MYXN0Q2hhciAxMTkKL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nID4+
CmVuZG9iagoxOTggMCBvYmoKPDwgL0xlbmd0aCAxOTkgMCBSIC9MZW5ndGgxIDI4OTM2
IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42qy8CXxURbo3XFVnX7r79L6l
k+500lk6kJB0SALBHCCEJbLJGrQlILsLhJFFHSEqso/gqICKAzoKigthDygaHXfHK46K
qOPIzOCgjhm5DiIKOf0+dbrDMvfOvd/3/t50Ti1nrXrq2f711DkII4RU1IoYpF9345R5
j94Q+Rr2/B4h7Lhu4c3h756+n5aPIyT0mTFv5o2RO/zrEZKyEOJGzLzhlhl/eKeoBiHr
DQiNDM+aPmXaqT6xCELJtXCP3rNgh+N36ldQfxXqebNuvHnxoFXBSVCHfTh8w9zrpmzc
u+x7hCaLcPzXN05ZPE+Q7D9CfTPUwzdNuXH6vXe1PQ31F6CeP2/uL24WnhQ/gvoJqO+e
N3/6vP6RaQxCzZsQ0ubCPoxof2iPEObR//qHEUHQc5aDcwVRkhXVgqw2ze5wutInuD1e
nz8QzAqh7JxwJDeK8vJjBYVFF25QHC/p0bO0rFd5RaKyd1V1TZ++tf2uqNP7DxiI/p/+
1XcXBjWgwf9/LuQOoSxz246y2BiCcUud6N6M2akT9BjNyTdAjVB6y/ztRs+gj3EhDqM9
+GfkRWexH/dCQxGLfgSa7URd6AHkQmPRBuxAeciDxqGhmIVz4mgtfji1MPU16od+jR5L
HcB3pnbA8XXodXQWWvAnFqMqNALOH4emo6+ZL1FT6iEkohVIQX3RVdiDpqCj8PsB2nAf
uh+9iH+ZOgtPdaE74X61qD/qn3o5dR4Vo7Xseu6YtA/di57HfOq61GyUjXLRahJPHU19
gWKoCf0WPQNtiuMOdgiKoOvR3WgT9jOvQ+kB9DgysEqSzEDuJXjSUDQe3YQWodVoB3ob
O/Ao7hh3KnVb6iTikRMVQptmo69xJR5OnmDV1BWpT9HV6CB6E/pLfx3s1ex27mqjLvVI
6hXkRgewjF/AL3Pl3D1dd6QeTT0HHBlDvYAiI+A5U9Fd6GX0FvpP9D1ZmlqKhqAx8OTX
cAiHcQwofpT4yRKyhPkA9YTeJqG1C9AW1AYjcgg9jw4DbT5Dx9GX2IWDeBieiu/F3xOV
TCPvMQ8ze5kPWcw+BfSOonyg0c3oCbQf5Pld9B7m4P5leBSeg+fijfgRfJy0kW/Jj6zI
3sWeY7u4mHHcOJcakfoB+VAAXYluRUuBtr9Fe9Be9B/oI/Q9+ic6gzVcjWfhR3EbPo6/
JRLJJSPJPLKBPEGeZUYw9zIvs5XsAPZ69l32U245t0aYIhjntxn3Gc8a76cOpN4H3rHC
/WOoASh6B3DFE+gl9AHc/RP0OfoL5R+4f188CV8LT/kFXonvx8/i1/D7+BvoJTJ/uaQv
qYenziXzgU53kvvI/fD09+B3hHxKPid/Jz8wHJPL9GZamEeZNqadOcL8jdXYGNuT7cWO
ZCexKRiZcm4wN4Z7knuae4U7xdfy0/h5/FfCncIy8fddxV1/MpAxy2gz9gDvisBJtwIl
foMeA77fC2PwNlD0P6DFx9FpGIUAjuACaHcNbsCNeDiegK/B0/GdeAX+Nd6EH8aP4eeg
B9AHIkDb46Q/GUOmkOlkGVlBfkX2wu8QeYscJcdIJ7Tcy0SZONOLGcpMYq5mboI+3Mws
YZYBZe9ldjDvMR8wJ5mvmE4YNS+bzS5gb2UfZLeze9n3uSu5G+H3GPcS18G9z53nzvOE
D/BZfCk/h3+S/4vAC72FUcIq4UPhn+I8nIWLoeXhS7UF8YMMZpMdxMUuxZ2wI4RZZIOe
x2EcxoBU/BPVMQaMi5Ueh7a5iZ910it5nW2D62/Gz6NK/BpayhMGNDF7HO3GfyTH2d+R
fugj3Iz97HbmJu5tEkFPgzZaT14gz+MBaC+pJePJZgbhL/GT6Evg98Xofnw9/gV6Gnfi
Pvh2XIWXog+JhxmDl6Ha1GOExRIeik8haAG6g52Grv1f9HwN+iP62vgNa2F/CfqpHW2A
EX0GfYGfQj9jLvUtaDcGtNEU0DJrgd/vRlTrJUHOloI8+kGD3MC/h/ZSiyJU8Vewt6JT
6Cf0NXcIOGoAaNKTxmz2N+xfU1WpHiBhIGXoSZC7WaCpv4fefAIS+6RZuwYkXQZdUg5S
PQpNQtPQ7aD17k21pTan7krdkpqL3oFrf8Yl+Ge8FSSiHa6oRW/Cbx36BK8BORz8f2c+
jGmoA32DfTgfl4M8dHILufXcDm4v9yL3Lt8LqL0MPQwc/RfgZhl6cB16H32DfsQijI0f
laAEtLca2j4R3UCamMNoIA6geSCzhaDHB2R68gu4y51Avc0gz4dBNk6BnrgGvYiOYYK9
0KPr4Pki3KcR6DwZzt4GI3gX3gN7poHWLkZ/h35bcTW5GZ6nw502gNbqgDb9Ef0NqJ0y
21UCeqEej4d7/YgmoGnwhN5oFN6FGlL7QVONQPXM74HeeVhDA3AufhyuawYJtaIQquH+
igkqMUakqsls5jDYmBTs3wrWK4j64RZohQ360YXceCSqNK6CNnyAkN5/rF53Rb/avn1q
qqsqExXlvcpKe/YoiRcXFRbE8vOiuZFwTnYoKxjw+7wet8vpsGs2q0VVZEkUeI5lCEYl
g6INzeG2WHMbG4sOGdKD1qNTYMeUS3Y0t4VhV8Pl57SFm83TwpefqcOZM/7lTD19pn7h
TKyFa1Ftj5LwoGi47d36aLgdTxo9Ecq/qo82hds6zfJws7zeLFugHInABeFBvln14Tbc
HB7U1rBw1upBzfVwu12KPDA6cLrcowTtkhUoKlBq80bn7cLeK7BZIN5BfXYRJFqgUW2B
aP2gNn+0nragjckfNGVa26jREwfVByORph4lbXjgddGpbSg6oM0WN09BA83HtPED2wTz
MeHZtDdoTXhXScfqte0amtocV6dFp025ZmIbM6WJPsMeh+fWt3lvPeG7WIWbOwZOXHHp
0SCzepBvdphWV69eEW7rGD3x0qMRmjY1wT3gWpLf0Ly6AR69FojYOCYMTyN3N01sw3fD
I8O0J7RX6f5Njw6ie5rnhNuk6IDorNVzmmFoAqvb0FW3RHYHAvrB1HEUGBRePXZiNNJW
F4w2TanP2uVCq6+6ZY9fD/svP9KjZJdmTxN2l9WWKaiWSwvTLxwzS+bptNR41QXKYtqi
6FBgiLbwdWFoycQo9KmaJtOr0errquE0+GvCcFXbNBiR2W3SwObVWh+6n17fxuVr0fDq
HxBwQLTz28v3TMns4fO1HxAtUj65wGpwvLvcFo+3FRdTFhEGwphCG68w65U9Sha2k97R
eVoYMiAfGgW0ndLUpxTIH4nQAV7TrqOpUGlrHT0xXQ+jqcHdSC+NN7WRZnqko/uIexw9
0tp95MLlzVHg5L0mEHC3ibEL/zbN4xw0q08b9vwPh6enjzeOiTaOnjQxPGh1c4a2jWMv
q6WPV184lim1OQdOZIIkUyJBxjwKTHnNhZNpZaLaxubDP28y9bQ2BpjS3IHDDW1a85B0
2iRHIv/2mnZBvOSi9tQpepWZXbws08q2PvHL630vq1/WOnU1A+1lY6Rx7KTVq+XLjjWA
Alq9uiEabljdvHpKe6p1ajSsRVcfJNvJ9tXzBjV3D2h76tCaYFvD2iboxCzcB5iVoAE9
qHtBic7BD6ytgAbsJdjghXZSpzsRxxoMkgXWwMgv8pxBmBdwDEngZPqQL66dqe2qHaGd
rh3eVYvqoKydh6RXWcQesedDgsFwnw8zHed1Dp1DYbYDnoXmMbuY6YBvOPBprtcTK7gV
yhnujMLyHK9M56YrC7mFCo84BvOKLAoc3INRTosig8SwJpfKdTIjt+PbdJkJ55h+M4Pb
yYY96hMDaXuSnV3JLmiK1mn31mC7o6aGbr3K8PwWJ1MZcTMVZvpEJS7veZomzC5sP3vW
+C6dUjI0pV7jD3MfQOuCKAfFAfvs1kfkZM3NwlkfhbJdoVB2SM3iXdnhnERJVlkoeqL6
h7IToXiRdEL7wXciJxscrH5aP9LP6w2gGD4Vw7FrEjtRCT5VgkuusYVzwgT0vqSHEI9P
8Zi/xrUTqfiUitVrRoIFJshfOxy6AlRNDu9KtpyhWzJTGDFoev3fktC92uGdpztLT0AC
3aPddNSYyYqe8eTt2qu9ypyJ3hXlYPz4aG6syuX1VJRX9a5MFMSiuQKPo7gC/w/Hm569
/8Fn6fZZxF/Swx8O+3uU+CO49ghjedt46dkNGy8e9EXgIKTsqNdePPw6bG+u65WX12vd
urL8vF4/n+SVcwtfe/HF115/8cU3zF3rzMNpiH8NkP4ekw+u0D3LuR85wnMzwANi6Nhj
7jRBTDsWdYWOMcF/5i9SBdUN70wP7iUDe++lo0nvf70xmsyCcdRQg24ttG1niChhJGnI
IR7GuUhCGFJE7tdl6Z/qw2G2jCUs5ST7E9dnOOl0p9aJ6uq0Wg14GidxNEYqNWfvqgpC
3C6H10Omv/zg1uvGL+tYNbNfZdQYfRJ//zVADnL8sPG+MeEfjxtPPjwj3deB0BbdbMtQ
3VdACuSZZKa8EQT0SasgiRqCf4dGW4VAtsxW7RX/yT2s0vY45pic3dl14vLmOK9gKhOE
qfA43C6BMIPG1PfJmrHqpY3bBzQ+Y4ze/eLZLxb8Az+FSz82ss++/51x2jiXbssC4yB+
AlNEUbdPEhVeFtpxth7kN+NqRZbn45iQZwPGD6MykF6/OnNhhuwnujop4U93YXsNslPa
OyPAQLxQ0Lt3VXQt9hcvmFQ1bghZif1v3fqreeGbs6aOo8/rj1eQ2WQr6JZyPVKGdRjM
KtA0GhNmyhiWqec081kM8rNP3ECfdSI5XAMuL+1MwiNAk/QnhQDZ/MbJdPvvg+QZaD+D
8nQ3qUYyiV3SXvZCe0026VVWAXe4j04GZK5PdaVOkr4wFgyqBiHEeChhXIRQrxA0Hf47
CXDM3+E+95ltOT28c4R2Zjj0vLaudgXXM25KlwACxODrPzDu9XPf/mzOSRE0PnWStXId
4L+G0X1642J5pbwd7xB2SNutB6Q3JXG8vcnTFBifM9M+yzMrMDNHrCE1fG+pt2UoGcoP
khos26V3yFv8q9Krlk/IZ/yH0ocWu+YL+4ivPdWh5zs8Cd820ZJjK7URmw412zbEhY6N
ZDEbyHUdU/yRD1652OIW2uTOeAvdKLOgZBKXez12TQCJR3atqrc3lxd4u+YB0e9d1duu
xWKk/KPF69Yv+uio8TOkFaM8ocTIinTGdWzaa0w2mvdvAHi3Df9m/4av+4+90YC/l8Eb
vwGGlLzcH8bmMRjYGNBAQuN16XpyG1kDhGXbcdGeyRzm2sm1B0QJNLoqoefxRKAZJknd
wiE2hw2zbSzL+uVDeDtgrPQQ1g6n9sUk/elkJzAcSkYidl6o7J1XVcHEjJMPvX8TJmUn
2Oj6Qam8t5an+aMC8K0KbQjhOn3yPt/+wMHg2+wbviO+I/4jAXFgcGDWwNB4/8PsA74d
7LYskQ+EUSFfFRjCDvQN9A8MiHm+PH9egPHE2PHsSt/m4OaszaEdWTtCogOFtFA41Cu0
MLQstD50NCSG6Mh4XO5EiGiqLUQZmVA+1IGV4NAeGCXUTh7dQ7Bqa8fj9WiOWqoSlY6e
us3JScc8HgA2GAVybMe0RcSf3T2Ep80xBDVPJb4r3nICjGs82VJravuKeBLcjoMolOrY
ba+hbdhtMzPdqtWwolbDiXbI7TVx869pF08Gjp2oK1LQHyRBJ6YzA3bTYCSbKG80jp54
GAXBLc6CLZQ6Xl1d3YRbksAx9khvR1VvahnAMPBCfu+8tNEQeJYXWPV8gbb12xfjfaY3
TZwlGl/5sfj6J2cHD68wzgz2YM44dz+WPttVN2HctdPn3Jb11dvfPHfdnqn9T4+KpeUF
MrYexklGFvSFXqOGLTWS6lfj6hj1evUvKt9pwTzrYfPZQssQy9WW7ZYDltctEiYiUnmL
wMmKRUCqarG04+f0AMO6GFAmRGUtjIWwMhJ0S4flCFSex4VIBBdn737EsnABascT93Lr
ZAxeBNEdmrBFeElghICtjiwlhPith/CVeIjJgSdawAwMBz6kTFgHbk5XsjZtbGtQ2tyC
QmBBI9hstm4i91D7qcPVd9XPVQ6lyQuyFwdfqBJX2CvcUTu2Y7Kk60nyy2/37zdOGTtx
wRnmt+ev/dH4hGTjHwzF5OGrQZdUctuAhzW9SLSG1SrHIMdQ/4OW31g3Oj61Sg670xGx
Rx13O0B4sEUGOjjs9nayVfdYLS6r1eKQXdRu6pgZhdeDeAL37dNAyEAYUx0HgP/YbUEL
mJdJuiUHnCoiU56Ut7koFykuTyLsKnPpLsbVjp/WXXZ7jlaqkVKtThupMRo9VaPPctps
VtamHReOHfFi3Yu9gRxrO47oDssi/MIRhHW0Be2kij37g4N4cEaoQTOdPgHcbRaocGsm
Z8OOuMnoNEm22NPEtQJxTXNjsitQsyXpzDdVlsmSQoETKCuAK4PABoJmy7sa+9SFwyfe
esuUW5pPrCcnu/5Rcu3U5zE7e53xTgrhW0KT565bv2LF9RFyzvjpp1Lj1Cf77nnlU5Mf
JwDNi4EfvSiKDut95ygLxBXiRv92brv4lHWH86B1v/2ws8P+ntPi5nrb67VbPfvIH7Qj
LuF59B5czmLB59CCYRAxSsRsIFJwm82SEymNkAglWWRbnYR16YiUkhipHY/csxNjTMmV
m8OWwsDo5qi4OXwMLco+NhIcwkC+75jDn/cvev10WiWcTgIJMxqeMiWlUTKt6jEXM+UV
6AK+ATIVPgLJxa4LlONZm3FKHjuw6TZt9ua2c8bZ9/5k/AUX/2P7Z12PLhk9Yta8saPn
sWOyx47a2vVL4/SHfzZO4Sa8Ct+Hpz1//utVD9y6Zt3dS4FPJ4AM+4BPFbT8IGJTx/Ve
NntCVgJKH7ZaHsKNV3YoLyrvKp8ockTBCiOgHKVUIaVKnTJSYRTaY+UQdQ3wMwcIwawg
qiKI555SAQP+aNatZCSDmYAFwIeaoUIt1Ysgk12mWdA6TebB3X2Pg7/g5gnxRhyOqgnM
y4vO3IGN/xQ6X2cfxdzvFxjDDOcruIws/gm4ckzqb6wXxtuH8lAZtuwrE0M5iVh76qx+
AxTesL/h/Jj7WGAXaAtdyzQmhorV3qiv2oCuVG9irxPBirsXFawo2GjZ5Hvc8pTvqcC2
7O0F20qeKjsYOJDtXeRc7lzuWlHAboRx3AiUyuq5CUpxiZbzmZ6063U9R/YkPQ+Re0Dx
duiax5eYl9WaRbYC0MjiHYWUiyQ4raxQLySF7eQe3eKw1OWOzCW59OpcuifAcznHpEXx
YyNt2BYo9x9jFuUf8/h7XWCZ05cwTWc8WdeVjGv2mtJkS7wzGTfJRjeTd0wKtiRRSzIe
x7FYZTdCEDyQstHcArrLeQkLMZeU8ZAbr/vyg/dPzmm+danR9fGbdz+y8ODkkaOaJ48Y
3RxY1DRh/s1NM6cz3p6PNj9+9OjjM7YU93rhtneM2b88tugNPHrstZPHjpzc3NXv5jtv
Xzjz9nvS9qE/jI8rI49H9Il97Y326cqt4irxKe4pcZt1m3MfOsjss7bb9zpfQ2/bO5z2
hHO80mSZbL/K2ezk/dwiz4Pez7UvXNwsJ06LZ06wFMRTT4smp0XCIJqUzJopnmUSHil9
IZ3KiOfWtHheVJt6MC2hFt+xkQ7sCOSnJVW9REJPX/C9/o2EdpM4o8WqQGeRygQIJxVR
wGLYpKbbpGwSa/LYQRNutc/Z8uw5LL37Bc42jn73zIfk2tuvGjETJHQuHpM9ZtTW87dh
5egX2G5sNxYYNxmbDzBZKzfctvaeu1tNOr4FBuUvbMzE9j31IFONeb6alaWdDCF8DIe5
Mo5wO8V3nzZRDwXxtWeAWeo60943OAH2t6j3jP2Mhebn/9ntSxMzkvkSYDgBPOf+B5GQ
OqZLVTUJvhASwWTgwsoEr0MCtWP6qEgBHIOkCBWDri2US9VqVMXVqXPQHDKdmcHNEmfK
XzG2YTymYI2RJYkVJIzDSAAnW+Allg1zvIvjeFHWA6ErZNNcBUIJOZ8wDM/CuL2gW3mB
cCyLkahSCN5OpuhKDjanClrNyYI8XcqRcJnUKhHpEMlDLJwhhcE/9SvXXtcNHvwwdmCs
fF0m5qaQWwN9M5zi7VLwxeImGFhx+6srevpoJmi1tStefTXtBeyVEpIlgeLU/De2KWMa
27JHTwKHjUkZu0VWPpQygFLnd/FsdXXG10p7apEIAz8ccTIM95LxYmvX/luM10lfXFP8
9ut4uLGHO3R+NQl3HadkZ9AGoP1UoL0TvM4SdEyvW1SMZ1kXF/+NPcOyUsQt8YUlkXyP
I8c90k3K3DvdxO12RXPzHU4x7MrHiAQL5vGtPOEbCwt2gm6iDqukJMApWAs4rafec1TP
5p7zerb2XN9za08x3LMMlJUrN4zCzjIncbaTNXt69BrT7ah3gauabDkTp6om2WnOBdHN
VDWms+pOte4O1bipsxqgWesuJ/VPm+CkS2QjTS0bUGuXHAbKgDFzRsqzSbcaArTJcxFw
gcurelPNUxCLMvZIphKLbiDDnnt6xaS5k5evTz66cJjxpWHBha88W3zlhMZhJe/vwI6t
8QFj9Fve5g6Frnlw8sxn4gUvLJ12uMUiEvZ141lOmjC4fpzEdR00FktqcsSAa4qpLzYl
dZK7FvBiAB3VRyyXVrlWebagTfwb0ofMh8oPjJQvFaqFliJXkWcBt0BazomCU/B6nV5v
ESlm8jmhkHuQ2yi9xbymcHV4JPhiV2l04cYpEB9KcrsvYeYycEw7nqR7fT1Y0apbHQlr
42Qbpopdd/sSgB8K9VxHD5mxfWcdj75D5q0CZWAs3AVbBWwTcoQy8GNh9PYEl4y54GuN
0EALZZyG02ArT8RpTgtJiqcwdfM5no2GqQKKhL0eb9p5AGQIKoitwzkDjHe/Nf5orMS3
4gS2PDmt3Pgs8MTC377z5taFO0jw6lNf43V4Er4JP7Dl2raG+cu+MX42vvl2Q1o/3A88
OgV4VAOAvlSvKASRH+ydzk5XuWJvjXeIp8kzy8PVeHsHVwQf5DYoXI6dMqbTkW/TRH/B
TuoGpLmS9kt3tkZwOFIGStvuAD7UyjSiUT4M/7d8eIEJaT9bMGUkr8ecLOHpL5pmoysI
5Rzgo/tJ6EDzHe3NPapmDL9r6uNdH+DCz39ZNWRybe0NY67Yxx3Kir1inPyPfXdtva6x
OId95Xyl1TH+tR079s9wWNO48wHwhU5BXxW0Xu8ncuDM5POOHA6XcTtBwXISw+YDTJal
fAWJAt/IkCEyAqcoELaUWXQAKqwUxhQ8AltAn9RL+2QOIng9tadr/xvR4kCmQjUcyBSI
FneZaDEc6CVzDsQdyWwPsHXnvybHu8JMBXforPH8j0bLj2b7N0L7l0H7JTRfr4P281y+
EBbLxJfEL0S2VFwvElFE6U5I0IM6fiTojqsYgFYkEFbKFKJc3gP5v+tBMg3nu2odtPn/
XQs3Mp1dfcm0rs20dU+c7bqXtm0qyCCdkw2Dnmuozm7MHi8sFBeqd4vL1Lu9y4IS7+WD
Dq8jWGgv9BUGCrPFIcrV7FhpkjKHvY291XdzYL91v/aG5XXtY+2kZmWy+DCVOT0nUJND
/TGCsSerBy85qNg5Gkc6sZPKnJPKXLGnh41BYD/8k2F3gWM8yQmHGehybhl4Yv6CrTK2
yTlyGZ2WBtmLLNlymezRzmunO1tMu5GWQRDBTju1Ii3xWlPtmWKIKyN2kMPcPGBIAN0V
YTYjiW7NQT2FSqaOLEkaW/b9zdjxTMfBX/0BgGRFifFpztOtr3z51QvJ5weS4I9d7ZNW
vYxnfvAlnjZ56JdvV91w+5nvjXPGuaGJQ+YYU5tRbPLob/V8ieVkhkhyPuvYCW42g3iO
g8EURBE4lBPD/HumG75Gz9UtoyzNFmaepdVCKLtuBWzNWoiSHu4OOtthsuyCy8Vw/plk
JjJgGk9I6KibPMuYPMukzQHN/oVnu5niwm8DLiT1uNA41vUCd6jrJdL/5wZyRxfFIGuh
Y3uhTwyaa8rCnvJEgqNqI5pv5nqdy5tAnM6N4lq54xyXwzVz87hTHNvK0XkrBomE+QQj
1IaOI6aD6mXaqSNQY9FNbK/u4Zyf6UqdOfnaMh9aS9u3Fhdyh35ugHY8CLT9HaUtvlcP
iDx2OGSZYwjDgtGSZEmUOUmUZMA3B/S4wLsEgWeoOyODOyPLErgvMiMxogJng/cCDUOK
Igoi206m7eaGiJDpDsFUFuQC5btVxXUX6e6nTOdLK/wLZPcD3cHKemsQbOC4+MxZC7Mg
0oKo1YqvMjStTXsw+6SwYknAuLy9WywAT4a6MmjgRN0f4wuk9ewmfivbxnawwjL+SfYr
9gwHnlfq+J6qqxISJXgeFPL5fvLNzHLmQeZB6SF5B3OIeYuRX2aOMOdlpp88gCHzwevB
8ZZkk8kPfOqrPQ6ljm9PfaU7bUodW2bxQKK66tiw4qiDlhzZY/Onc6s3ncMZZg4nmXnm
vN1WZx1KO1Q4PQGGk3SkcATDv2B/EDhpPL6n6xhpMO4wbgSV3bWArOl67fwdpO0HY5Ap
J4+ALnyCew5xqJ8eGCVQPmHBliOR5QICYS6lPt/r4KVqzqA8MrwrwyYmB7sfgSce5547
N/RHem9QaABODiGV+HRFYWJiTGFYkD9Q3LqU1Schh/v0TZj0zOT641k9YS8kPHDRX6Vv
ZfDvZNlJslhNypGjpIQNS6XyTDKLnS7NkReRxezj0g55n3RIPiP9LHu2sOulLfLr0lvy
x+QYe1T6RD5JvmK/lL6RLYukxfJdZC17l7RWXk+Eicp0MoedKc2SF5JbWKGeNLL1UqM8
QZwgTZQFn1xqTZA+bELqK9dZBTrZxkuS7CYB1isJmQmwHCCULHGqIJTzVrXcnOgn4ijR
klBoYvbSCrwl6taChEIT2LVZ12hBERkK1IggI5Fyb10t5dn0UCZxaaf2YSfdEWxP9dV7
wFPCrChJ5empP6LIcjlDoEjgNozKEqKCWEmCmGPF1nZs2UPXfhwi1aaKuDqZVg3eMWMT
XLmgC0tFLB5eCqNwWAkrKmkn1boDdIIOJyIdTkLlOdRFhttYqJbTTgOwi2u1/9BqA36t
q6WrpTbg0wAWwA7tRAud1TJlLy1ul+CEDCZwjgGeF1PHdylhCgCS5p+pU+IIZALYBng1
zbP2e/HzWMYCfsHoND43/mr8CWCAj/nq5wb2znNL6AY8tQl0T5TabvwfulVieNHPeEXW
AZoNqIuoZFEdS7tNc70YesSUCyIoIZERCREYCegFtGJY2mOW9pgt598z5+zX6H5dGaU0
K8w8pVUhW5UOhaTtvShlbmpKvXXMmIRUfplFkC+xCACZwCZ0GwWombrUjOIh2Fb0pJ0H
CqX5iFqI47oEXCGG0zzScUCiXGMCq7ipkAaaZ7XuVyrFVqXS7Fi/QM+EOAYSjvEw5YzO
sA3M3eC6bBV3iycY/lXmPfFTkQkzpWKC6SuOFH/NbBG3MjvFNuYlUUkD1orKBNErTMB6
XLeUlidImCaCqxL2bNSlSM8EGQuJeXZDdhhqkIhEEHyE8QolpEDoSyqEEUQXriHjBclF
gsJwMkh4SHhaeId8Qr4iJ4WfiFJACoVhwmJhpfAM4ak9mR/v/kPdrNCETE6gOgTbN+Ew
mYidxsddu4ABejAf/NzAvHC+Pu1nN4F/dBL8IxsKosf0cRu5jeImdZOVFbFgFW2Cr8C3
WFrkEBbZF7uXs6vEVepy692OVa6V7pXelb7lAVVwAC8E3I6AK+BzBwRnD4vk7yEwnoKd
MkayJofT3o0eLgvpoebQvFBraGuID4dOhUhIK9iKMI3AlZmjvnZP1pLfXXCBTG88mY5G
0RkFYPUWwHQJQGzUx0mDDoRdjgszSU0Dy5+duWoPrsd3G0uMw8ZBYwnu9bddu/76+YED
x8mHxzfN2x3vY9xkPGQ8YswF6DHrJyOVSp0/e47SgfrgZ0EOKB0W6fk8d9B10McM5vBM
7ihHHPZ8i9WKghr1YW1I9PwXhOHJCZVl+seFNNulej7rcpBxAWNknNmLOAOGDGBUBqxG
o34CXctg1QfwZ9h61ZIdUzeOmPPWy4/tXDjw2iGVW7lDnsjnO1e0z7a7uz5mXzGae07t
P2qWRYYHU38N/B3kRhF0Vr+zxjbUNkGYo8xRaVRxa3S/9Zgk8yIve0WP3NvaYG2wCaIm
2V1Wl82l9bb2tg22LbDeon0gK4ulxf6FoZXSSv/yEC95XJJqs46xLrAus95v/a2Vs4Yt
qstiUW2q2+L15Ds1F252bXURlwuFI5RcQDg3Eq10gqUAWTRwQj4MFmzl2/gO/gjP8ivm
RXE4WhYl0Yj7UqrlXuqbmLyQmR8w1eNFGGDqAbp64ZIZf9MxbklSgpZ7MjORXmeE6Umi
Ubv9IlUB9s/9+0etr7zcfPucPcZvjs4fe+2M2s8+mlM7ckje3pPcoZFv3/nEx1nVy582
/oLrnm6KdG1mRuRNHDDsapWj9nhY6m/s9yA7JfiI3u+gvT20v/D1EhZAvBtAvNsXn85N
L7yZX2y5ufAT9WhUbZLHWcflNkVnqTMcMyOzC2eWLAotD22IqI4otdnZOQma69P9gcTo
3NHRl3NfjrItuS3RO3LviP45989RPi4XW/Jy86I1lkS0UW601OcOjM6xTI/eYrk1d5Vl
de42ebvlyVwnuIwWPpeP+mW/xZMr5EZlC4u94326P5yY68NzfVt8xHeITEdB0EMqAJkg
DvZwMWgIpoppaCCcoOGfUbgZr8dbcRvuwCL+B6sHajQWsz2KJd93KS/26k5vwtsoFMQC
PXMKtmptgKgb8Xf29AD6e/whw/ONYybuQnp1kzm7YwbET8fn0ymFlvjpZPxEOp8fPwH2
Lq28TKcuF+gRDF0Rpc5ZOv/rbmdNLpAHMqi9tdtBa0d0m6PGEnbUyOZmo/u+0q0q7LPU
yD66OWvil/51hzTdfeQ+lsrcSqDjUMvA3IboNvmpXNmMu6Uh/4VYUYH5q0z0vgisBN7t
8npYk7Po/McwHA5sWbHu3n5XJg7+o3nF0u+ewi7sFYxjzttvv2NoaUk1bntvwdoUesn4
xjiKP8+6d+UtoxNDg46efcff8ty83834/m1Ly3WVuTWJ/NIZNx5es+SP12NM+asEdNJB
c450vh4tlcrYMm6UNE9qldZLAo85ks8yRECi5PUG2KXU4uIeuswLYVyGllIpgqqdsY4i
80grWU9Y4he7nsmMyuiJuwiMSm06RgnJoOn1JzI6qdZ0QGngkaJq/IUxnP2VMYJ95ezZ
c1ek11GAzciDdvnRar1aEAVJ0ECNSIPFwZIwQRqvbdA22je5H/Zs1w54PnZ/yZ/hFYuq
YkSEfKekKmHLe9SxMuFhcFSwOcjMC7YGSThYFtwa7AiyQQw4Kuwv83f4GT9VBYF/Cw87
TXVgwipnxA6D4jGFG+yeZiXRXDo9U3kfLlSc6365pDWAC8vuOPbcHz5Z4gqBIfzb4epJ
N87c8BwTP28YZz/d0DTl4XFLztB1HinQnWOhfzy27kEMFun8iKPGdEDHBvokOsSj+Cj5
hP2E46izu5jbiDeQB9lN3Ba61kzhS0XqUDeLi7DgRx6+CMX4oWgwPwHGkSEkjJELhjcN
4cwZaaadTNUVHpAzoDdQmNwhMgWxIIrA3AqLl7Kt7BfscZZl27Giy0uZVuYL5jg4/iCt
++AMcD0PYQUROhddhjH2C5fMRYOMJU8nk3Ff5wXPsvNyv/Ki19SxR0v7S/vAVRoLDnXS
dJbMgD4CRISSkTQSIkrXadwf/wLPxH26/skdOvc7th8AWZM3BISENRSj4JTuiDNxPqxU
KCyQUtGBdIDSWvdAzlyS7/ZXghd4UpfobLwfErW7hmiNozqxyRNKsGFIBIANvBpAbqkI
5UvC1/JJ9UfpJ/lHlXuDe0t+Q/0UfQgo5aj6DfpSkp5mf8s9LT+hPs/u4Z6X96lvslJP
NpcrlcPqw+x93MPyA6qYmXcXsdXCU3tujaQdXQkKADIitMmb96Txx2bdTdHINFpTeAZh
gTVntEy5uQRxmCYpuPcVheXC7amyPTwAjvZUuX4Ng9TwJTwg8xxXrsguRZElXhDCouQS
RYlVVDUDTeAhjIoIZlWGkxVBEnlRELgMm5ggBQwrSH8pYJB2XKbLYf6wclgvpZgQqmo4
vQLOb+nmiIB/eFcy4OvqCvi7kr7uAEWaL7TMz2w9Xf5Yk16uQIHI8Es55vIs7VGbQKQl
44XSpIUyixOYxWkyDZ5uPIZLP8cqWBX8Z1xsbDZeN/5ofA5yaGe+O49YBKhkyLl20ycd
mvqK7clegaKoHLfos4SAmMWFPIFhwSFZQ/M/076wS739Df4JsRn+mbHlsV/77wtsCxwM
vhF4M6jyvMXt4f2eAr7I3eRfRJaTbfw+/nVefSnxiUZCeeW97CWWPD3eM5Gn5xZC4g8l
5uadzyN5DeY6mDKrLdEvhOl6nbbQTyE2FCrBFUiHvdRPJWhcRM+y10X0oAaJL5CItJOb
97GCapFLKPfAMTOHw2YOZ5TAGbruUrJ7xcQiqdDSlKNuUQlgwhTAQt3qSaiBkQmcaAbZ
uYeKb0VRZLIXf+HFI72TvXO9jNdfMbt/90wSWM+WziSdqImnaydMLQj0BhYEaGTaVNMz
iqcZe3dpCLc0dXYLeR6AoWAoMTZvWh5Jxpto9AhGm7FqaaXfkqTGr6A3jd963IzL441Q
68fTtZ7UAlb1rsoEbamHasYazUU+eHoq/of3XmhvZIL5xjeKJjBDHk8+fnj8w79+7cpR
cxvH4mt7f5NXNbH+ykEVmkL+0vOh+5tWHTDa1959ZVaVX2xo2L1y0q8as/LDWaMH9TX+
4Cj3FdT2HV8eq8qbbvLDCuCH+03fPAs9chA5Umf1XkpNVXBwkDjG8+Pl8Z7xvqasHwW+
ku1r6eusDA5iGy2NzkHB+4UHJVm1ggigAAzDbk5w0dFwKooNyd6IGJiXjbO1IsLEbO24
SFfxPNRKvZdQXZriLbXDO7tq/zYCfPa0x95JLQ64CC1JnBw4UVdm8DPkGZ4ZvtlZXBIw
lzmvR9dOpEOyBW6nuUA2g09WYP+du18xjK6DV+/SHYmhtyTvWjZz+nLuUNep+42Txk/G
KePTq5s2k+InRs7b8vT+Rx+h+nQc9L0OZMGP/qyPnmhrcjR5ZtlmO2Z7bvfd4t9INqqv
a6/7PtaO+r7mvxa/dn7tPss7q53V7mGOYZ4GX5M6WxX6OKo8VT5mEbfItoJbblvlf9Kx
3XPQsd8jWU0eDSaspilxJawVFrrHn50wc5s9YTmEWSQDzRx2BelwKtLhPFSxHjj1EKgw
Fg6FvQKme3EElVpowRIZCQY+EBQiLn9gYv+La1CSwzvjpzvjdDI7eSKejidBnva5WrpX
n6Rj2FUcz19Yf8L2Mv5uvW7k7NuXXj9qhhu74qff/dr4O/Z0vvIl+bZ8zNh7dxzefPXc
0hdfwTHMYgHnb6d8MxZoNyXDN+v1Ho4mvklucqS5ZROwxllJmpfdmk36MAm1jzvhH8bU
q8Pc9f4HJcllsotCuUa3KoLVBkMhe4uslhimnGKzocA6yjsR0R+aWHuhhy1n0hxjWoQ0
bjWRCPCKZTY/W57tSHMLn2yKRCozHQQE6wWcfimrsFOMc/13TTpgnDNe2X0n9nc5Sutv
nbJy2cxpKzZf3YQLwCO3Yv/9RDs/b8eVNz3x+IFHt5jrHr5iC4BXXCgL//Yg0kBOGpSa
B6WHLBu0J7nt8vPS85b2gCi68BAymG+QR2Y/adnP7w+8Ib+pHpWPqWeFHy2WLFuWWwcd
4dat9oTN/ZL7PTfjNrkhu87MrV7Iya90gIGOUdZmK7H6HBQ57PcHE7jCYYYkQ+F0aDK3
KJ3He6RzX5aZ6zZQqFvpGxsaNHuywwFk3sMqDh8ld54ioAgudaeZqDR7cvbc7C3ZbLYt
IuoWWwIIntGH8ctilJ0AHHSXTy901fn0bBskoIR9VFubfn9dlwksHNAIOMNBGwMnOTLK
mua7u089nTFk5gUIDjhqaKN3e2nWtkeSrzCr/SN1pqlrOkF1aNJ8vFUHKlnpQ6308VYd
iJWedDJD/wBvwLxWmP4qaAtMWTwMLirlccRETO/VmUYYXvIz9vX+eqfx97tnY9cHndjB
d+nMnVMGTCpgFo+/prYW46tKH3p0372fAy/EjTeMw7evGYJvuHXpwIG/oHrDBwLwN8Cm
HtSul/dmcTEb1sL2JrbVx4nsSz7i9tiJy+GxW502pFmdGGnEJYk2BU9WUgpR6EDIPLbb
PDjlwR5azdbgvqfg1rzTJUsVdeJIcZTIiIVaqX2yndjbMatbrM4YcU1GWz0dHuKhPCGp
CY/fu/ggmZ1exBcHlUrf9DifBNDhP4F8ICYUxsNWB0lNuQ3+MpbIWWGirnKvYGoFN10D
GbFHfZtrHlyw+BexgVf0q/zDH4yTm9nYqOXLxuS9qtWMbvz8/AFmqCn7xmi22fQhSvEI
feqi0IoQcaiWeb2WW1p7sWEcJVGmDFeQCkbHA8lA5mpbk6spf3zReBiq621n7Wedjr6W
Ck/fwooSANqexsL6klNql1e+B6y2olqUYtVSYPV43T0sKkBBXx6VgH2mBJiMbrWbTLJH
UdN5YXFaAKL56bxXIi0Ikjtomv7JHFU4ObYCmlnlHpTgilvw+fniIiUW8FGlI/n9gcC6
XrgXqKB2XUYVeRGHv+yC9jmd0T9ap9Z1ottYdZ3OzA52ewDIbJz58N0wOCb7pgM83a+8
CKLWbeJaTL1lm+2anT+zaEZ8dilPrZyX83i7LX8lby7vogzsrQQEBqgrDK7CpYu9bsH9
xVDh+Juq8p2WJR1Hb5+K8UuvtWLhinnPrzO+/8v5u5pn3rNy1vS7Ggqq3dkRT6/otQ8/
s2/dR1jBgWcfOD/4hUNzag/eYyV3PfXIo795YusjQKxfAy5uAr3uQbv1uA3n4Bo6kNoA
PMD+J/wTlgTOw+WRifZZdg5j4nTZHU7GRbCNEjXECJIsu9yyByFFjomSHs5L7JRwSsJS
wFwv78nNS6z3bfWReb5TPvKdD/uQK+Zxm2oLzt3qxqfc2O331qUJ3zI/nglTQ+lMppZG
BOBVdwJNvaaDJdZmllhSByGbuIGVE6a542kRP73y8JTNI0PGyfDofg03VRgnwS34csuQ
eSvXdd1Lem2fVFm/annXt9Bp4G3zPQYzbimgRQeRRCOVdrlOl0ZJpFVqkzqkI9J3Epcj
NUtLpa2wg2N4AXEsY6Mra2l8kkFJ8Il4jhdYmQhgM01ejOQlWL+Y6dfFftSZ4nkxuArC
OT/evcDrvvQCL3Y/Zo3z54axsXPmmtjUY8ZovM1soxut0Yd7hJgQ9vYW9otcqxczLIfc
LoumatK/tol185M1rN0j2bArRjQOc4F11BfGXkuFBrLn93i8h8j1KELm7IKGmn6xf/gJ
3whzijAzK5DsbjRd/VtxWctpu912l+nSFlR1zxf8CvsrNy4onlLdyxW1xasc6e6sP3fu
ne3X2mynWC4/cSfzA9Wrq4D3Jptx8H9SzPz5HovdjJDot/t7JARGY5x8gTSD3ym/JL8p
vSN/KstjmGaGWASf1MBPEBfy3H7pC7aTPc/+wHMjhBHiDP52di37MLuZe4h/SHhIlHNY
Bx9n41wxXywUi6WWRraRky9EgmWJ4VmFY3n66h2N88qMLCtsO7lRD3ClYk2OgIXpFqLE
cCvCdImCX627LQMfzCivdqbFB7qCIr3uydR0tInGc7ujuLRrb+6WIpmlaBTbofnJdNy6
Oxq6CvvxUDzJeADfbbxv/HAXQLkzeKHxy65r8eerjGe637cxeWCMGV/XiyiXcqM40sq1
cR3cEe67dFB9KbcVdnDpF2nAG8eomx+Rn/0v/JjhwMzrOZkY+hKE+E2g7wtw34OoCK5O
wrPAvqpu3qMmmISY8CWi9WSQOMhXH1XDTGnRGKm5qLVoS9Hj/HZhm7qP36e2FR0pOl5k
RUWlRaPgwEtFXxTxRXogK1EH9VbzICdEWCEQogZxtyxETLvICprdXhDMyooVyCBUNi3m
sOuTKpvteC6ISDtp0G2BYCyUBfvmZuHmLJwF+/bmx2IF1JfcjVCB6V5JdTTXe0O7C+DU
Ar0/bLWw5RUkCvQ+/RKlBe8VfFHA2ApyCloLGFQQLigrSBWwBf7Cv9Z2A8TMNGfaCtSe
AU8GjO2ZlmS89qJSMuE+GIdLVs/Nj1ODi+POiJtiP6+JAL0eU0kVXFBSF/XVEsys6Zix
oazhsWsWPFYIWitUMLrvrJ7Gyey63v1n9TBOsrF7nxo7btzYydfUb+pqIpN/07N2yJoN
BiEND08qaVj2YNf5dDybbYIx86Atuk9wep2TxFki285iGC2tXqy3fa1xvKm07YLVwquK
Ak44wTEPMpU2win6Bsy/UdqyElOtlL4Wi3pBd6dfl7xcd5uU+i/qOy0Y3f575DJlbRIJ
VDjbZJzMG10z9OY4qEBuzQfJh0bmkOxnplePWrbbyGFjm/cOnLXstnSc7SrwzR+CvloA
yW3Uh3yFT4o/On90s2+Qrzji8HN+iTRp453jPU2+jWQTv0ncqLZLH5HPuD9KH6knuZP8
VxZtu/gO+T3/O/F1lVsgruKXiYzd5EPFS4nkYgVXjRBoDs4LkqA1gi6DXmkAmwYk3ZZd
mq3NADwy28diatZx0plwpF+IAPCaF8u/xIZftbpr83/ihPHWt782flyNwxtuuumBB266
aQPJXYv51cYb3/2n8btlqSd/8+STWzc/+STt7xrjBnYj9FcD7PWQ3rPaOcRJHAmmxlLj
TATrmaGWoc764E9BieL3bkx2RvgpKIIEXYrVPYqi2azdWN1eZLXaYppmgjDlX9H68M5a
GErtxH/B66bdpb4MxeuXYDC6RtRNeT2zhrqAwrCLvV6D+Yrn5hzExDh/cOK6kTDInntm
TL1z+XUzV8Lgjppm/MnoMs4YnzSM6/qaObjn6Uf2bH+M4rCroe9Toe92FEKP6FWOWpKw
JFy1WcNIvaXeNSxLnJeDQ6Lbm2jimuQJlvHOJm9TYHxom7wt66x0xvKjS7Uja5ASgVXc
6QkLwabxPgCb2Y4iQN0xu92csJDWgakM5KRdwDOX9P/0v3Q/3pIhwGxutjzDOds72z8j
BATAdt504NIom3pwly4jZ4ZWPT5534LVmOmY83AtZoxTd0+bsWrZlCm/Nm4gnsFjVm7B
GgYrM+nqR35uYPb+dstjbTsffi49D7wCIabKHP8n9cKNHJaseAw3g1vAMaWOidZZ1nkO
VpZsao5K1qkpldSpI1WitpNFepEggJQzhJcLkaRJZdI8iZUCSx1bHGSyY6ljp+OIg3Vo
KEanOIEHCGnFW+kcp73uIM5C3dM2F4T6DPUOTJgB5AAZrylPs0MLamzzjmlsqzRXDJdX
N5lvCKa5IQ04eDveSuV64PX1zU0TBvfre1UpG9t4fX3lDz377zD+E/pYBjKtQR+LySt6
B2/no2KB1+6NbnJscm0seKBYElwNLuJ43nLQ+kbky+hZy5lcvsgyzjLd8oCy0bE996Aq
9I/qefWxmbnTYiscK1zLc+/Kk6pig/gGZZhlpK0hMiBXyM0riFWplREaq6rME3iZs0sR
n6VAzc3NjQp5uXrJL9TFrlvcC4sWFK90Lyt+yP1A8d7cvVFLK17nXet7sPip4rYS3hvx
6JFowqNn5SRyPPgLgHQVYmRU/rp8kq/7Qon8QIm5qAVsz6gSXFaCS0twSXakDNirAkdQ
xj6lVx3LdWnrTNdT+OOL2ynJz4PNMecmM3rUXM1NrVEnygTcKnmMeezBsdzekYbIWNzk
nYZne89gGXsJG4jkkkKnRSWFgcksZhsKlVEBHGhwCoAJ4Z/Ck+4t2RKk4cF3KKKKtKfz
XDN8mkfrx/fk5KXr/oBZ14NQuN6Ce+c25G6y3J/7au6HuXwkV7WwbABlMBuqoOhtj7dH
Hc4AfLOem58wI6Ih8AAQTsdE2Wbcik9hBgHn0wgpa57p9MCZGOvDEYsns6dYQrvg0eHW
ngqvDvf16nBTr15ZlfDSuWevnl8ECdzX5s0xp3lZ77iADjbMFsCjAqkAyXTeDJKaf3T1
dbKFrsOen66miZGJamZeDoG/ZHqVZF7qLV1SHHW2QkiADt/ut9SoLrWGFnerNE76zS6l
BmWWujVdeK8k/S5/QV5B5i2eywKe3sxr/2U44Ljpuhur8l3uocYzVy/59MtPPyw0frRP
nji3LJwVwy83TTz93SdduDR+1bjCrNKw22VvvGL8g6tfuGdNrysG5Hii2e6sGcMal//6
D22mrshJfUXu5R4By/iuXhRGAM7lIlsf6zBrk03wu5GP8biR1+F0Ya+DuLCPkQRZUH2U
4Dbk3ept8zLNkHV4GW87Zne7MTUce5CbfoniZt2qKlKpXIpQKZ5svs7I6oU+JuZ1jHPX
uba4drqYZlera73riOuUi0MuzUVfYGRd/sDird1OVWNbFWiKvuabGK5UBw2bnk9HTbXT
5hxGp/kFCzj1hAk4MnMYSeyO2l0mVb18Jhhpj1ZWVObbya0dSkFWwTDf1F9eeWuNIt1x
Bw6wsePG2DvjWcFPiytGD+r1AH7v+AePG6uAPr8CPTOGjYGftFn3TrDPtG/gGIn387Wk
1t5IGu0niWBiWzureJDsdrlkiXe6Ym43oirS6jG9pfREzv/gLUniBTdJxKdELP57iJs2
NP/iJSXTE5qxGA2/ui5GYpkRfQ7Pvn7Hldifc1XdkPnF2L9l3NRrd2wgWw3f8el9Ry44
gTsoaMSAqRA7Cfqp4KDu5goDpQmBJjxNRJoA0Dq2B3ITroYDfRIPsZhnFFGUVQUwOXEw
ASkg56IeyhuKCtJ9SveEwgkZcYoL+ZV8VKwkUB9lBZIyUT8ZW1TzXorkTbAYSZhHMqqj
qwdrMlE83aEgmVVkSSIE81CWaujcuO7LKkwolhxzBT5r8XoDmlwnjzQXO5XpCktqFLaO
Hcky7CFSBo5qq25TKxEO0/dqsV99FXjLT5kr7hvemQRblfSnv9BB6+n3E801zxiaYAp3
nL4LnF6USuNqXhqKcQIQO2CMxQVv9vHyVu1tHDGAel1/2TfI06MHyU7TVAJcVA00VUmB
3gsoKyOeyAInBZGHZLN2LiC4pGzZrqpmsDaq1DA1/BBmCL+J2cSb8QF9cclgIKHCshwr
KTKrBlGA9XAuyS+7VTWKCtkCrodUKBeovVAVd4XUgAaTwdwQYai0CC1mF3GLpcXyInUF
Wsmu4FZKK+UV6ifoE/Yj7iPpE/kj9Rv0DXuCOyF9I59Qf0I/sWe4s8IZ6Sf5jNqDa099
oEvBPgk2BonUnvrUrMm0pnYfQ7RmBm79fdJr/SBXdEj+NbArZQK7bokGdmmtO4TLS3TQ
LwnhXh6/HZ6J316pl9P47f8Uk+XTMVm51FpnJTQwK/aXMP2qA09uRApsOmKwdW8Y+y2v
HsSBtLdCY7KZkKzvwmda/reQbFrpowsrlePg0scR1f17Fd1SAz0+u9tClyycBcWv6Crd
cwoUP5POeLqSRqG1491mILPe2QzyO530H0cYBjcZbdj+xgFs2/UOdhtPG98f2As8NoS0
0+3cp+TprnGmDldBdptN2d2krykU3mTJJuEg/iP+SDhl4UQhwPr4Qr4KVYtDcBP+JV4g
yDEcF3rjPkIDHiZsUs7yZwUpn40JxXKC7SMPZEfIv2PFK+WxbJM8jb1RXoxvl+9nNwiH
5I/YP8rnZQvDCoIke9gwWyxXsHVyAyu5Wb/cRx4hXy9vZw+wb8lnWEmA/u5x+KjGOLYH
PG6WugRu1Z7ArCywdBghE5Ek0uWux/cX9UikzAXVx3WbJy/BxIjkIkTieEXJHD6lYFrU
vXBYiSHOhRDHcxz4q6IkKYhrJzfu5iskOh+jiNNHWrZYjlsYC0N3kwqF7nacSgc+0p8d
mX5RF7SYi+/9wy8swy+9sAyfLtmIt3RH3dOl7llbb01m5b0cBq6mHUxP3HQzSLKlZT6m
SQU2RxbTcVXxUuNePOGF1/EwYxNeZWw/9imJEsb4I84zpK738VDjQNqPtxqj2atgXJ04
sddRyGEn7bxPtSVEj8WWEGjC04TzwD6SfjWmT4LjedaiWHmNICfPOgkLnEQDB83gULbj
naBUbZZSayEKu8vczW6GTqiaHlcsYc6zOrKyE266qqmG0X3+xFJzPUOBLhGzRjChNQeu
QXpW70RmxZnr1Yy9jqeXvVDdmn4FE+g1f7h2+gSdGCxNCxXoVXvmSwxQEKzmjHdGlJKN
bRqY+z5g7nezGjqUgvFKndrFaNh85zLz4tRXutVir3NqTj8kDl8dRxkNKjTfDfXMCwRp
QRKsDKCsAjOsacVx4yyOGqsG5g+csHTU6BH+AZVTr/WDUFnJ9+fJweTUfrn2P1p+0ZSm
fy7gqKNAfw0P3+t4i8Xgb6b0Xpo9IWNIBCzK5Ed8ViZVymB5sDoRTySz8Wyy1CF+wR5R
v2OPq6xcyj4qPE9uRiKS8Vjw20Fl4VL1UdNlsGkaktexW8BlDcd6Avfg+F5JrtBsGZff
Zn5Bhvr8Ns0WtpXZdNtSG28LAPU7AIkRhyBWoFZ1PQVvdNk13ENQvbSG47sx/jfIQQXk
YF98WzdyoHAtGZ+vnQYXg67tontO13bG55vfePjhBH1bn+a4pXt2EqeO6FbJl8A2JJdB
LgsiHU0aiEtPWCLqGuP0W24E/ABZqVE0FTaLqe2aUEUl7l3FC1xlxI2F3hURdy6+Z2pp
r1HGKuYmY866BVl4z2f4rXmlDCZfv2GUPCz8mH539i2EhGrzG0IC+CtX6Hk8R5VItaII
AktD5TH8vRDjvldiYVEXiehX6evR6dVYZ7rOdC/D0jq95emvnXX/+GwcOF+L/XRLz6mn
N+DtZcwsZhX3JjzPi1p0Ky8LDo/TpmK12vuNk36CSXLQ+HS18o35QaYo70A8EvKQPJ9g
BeEYes7izFM9860WryWmNvtnvm9+Fgqa0amd0M500QYNhyL9VAk0MWkm+MKXMyLm0g8v
zwsVl5UfMU7Gb55UNXYoWYk/gvKCJrPMzMp8xGnaGOPkW7etTRfpnNBspolpMefOvWiJ
Lmf6wWPe7IPwjVKNbA7soLW48xtvtUo/+32xH9WX9qM6rJap36kplVXbSd89vicWpj+9
9f+5Uxc/QHVpmUzE/nRH8Aqj8OKXqbhDb9+6tiW8AHqC/ReKqRRawIzHT3D7GYGufGMf
QZL5IcIiUCZp+QWeUd8t+W24fLKt9gfRL5pfb+34x1f+7pxGSoQ13Aemr4YvfMYcCVcY
I9BADf38szFaG3ThSPffEJ5+67wGbv8OmieEUBM+ia4hO9D1sA2E/Qsg/wXk95GaVBf7
CzQetsdgq4AtBtvVsE3IbGNg6w/nv8W9AdbsDbQBtimw3c+NRw+wf0Ub+Ro0le6H+62F
/EHY9wi/A90L5U1wrImeZ143Hg2DYyVQvo8bn0oJv0IC3Hso7FsB+TjIx2ae5TPLf0W/
zrSRtm0VLUNflsD+e2G7CrY1sF3NhMzry+C6HKj/CsoKPFeCXIXNyiKUC5R9C/JlsM2G
+8yn36uH33LcB8/BbfgM6UnGk4XkMSaPmcH2Yd/k7uSz+FuFYcI/xCzxU+keuUR+TCHK
KOW0eq36mGWlZb/1uO24Nk37vX2J4znHz845LtFd7Cn3tHlHeF/3/d5/ZaBP4FBQDS7O
smbVh7JD92er2atz1JwlkdzI7txY7pE8Nu9UfltscWx3gaegtWB9hh+GoO8Rh66DjYAX
UIrAf+JHaHNBoxDzDEdmrOlXytGkIf1HXzU+3n/+7Ck39Bgw94Zpw8de+H4CQqkC9PF/
+3ngIaau4qjKB2lTkQ2eZIc7O5ELAZZGPsDaARREWSiE8lA+iqECVAhcW4ziqAT1hFaV
oV6oHFWgSqAhuG2oBvVB9WgQol+rH4KGomGoEV2JhqMRaCQahUajq9AYNBb6Mh5NQBNR
E5qErkbXoCR6Gu1F+xA4Ey+iscxDyIYp3O9gNu3RXOV6O/PgHpuzXO+vMQ+gUbAR1MYM
Rx2w/Z/Szja2qeuM4+eca3ydgBMnhOASwrnB2Ia4JsYNdREI35s5rTZ/wIV0ssuqGShS
q0nFUuyy9SUJnZB4ETRrpUlTpcWdtAiNtbm+XqlNgkiXVao2dVibpqWTpvkD+zQq+mHa
t4n9n2PzUilfqjk85398zvM7z7nnnHt9r7F9BTul/YRNwwTc0050T7xOmWpnV9wH/4vM
gM3ANFZGytVzE0b+F6sb+6n5HzvdPYp73YmNtjJVnz+esfq0HzKundReYQEmtSnoNugJ
6CD0uPYi86p+mtVuX3wG8ZJwT2qbMEZSs7R+jI3UUhqNIbmVnK5WnJKzczhudWrf0vzK
pVvzslGoR9OduDQWNRM9NbVz1Y711L9zjm9T/IZ2FoePPnjNwGuz7L6hdbIRGG3JRLXD
G5+1NmgT2MwJDItEHzmbU6mpveKgIcQb17ayftT9ALvKJujT2jZnk1xe1N5Vbu9QK4h3
0PE8QVL1dsWXrQ7tIGpt7TJG/LKKNlsNPRVnVkjbyWIwgUGdRo4+Te7TLiB3AdN0AVNz
AVNzAb24gGXKtPOoOQ+fEe01VtBOs1nYHPIuNLnJwQjWVWbHznhde0zzYyR8ixg7jtIt
1Y4u6pnf6d2o3PzVDV3x5A1tkh2CCXS+WN3sj59a1IbVpjxe9Q8QUHA6NmDoNrfmAmA/
zcENbau2TY3EoBoB25J4zlm3JhkXvxcNGh3xZ/EXml/6eXmlf2jr5239Y0vvLYtGFVHM
mvgTadPaKv5JH9YQf2dzyAmxKFawp0jxN1GjXogvRJ0loat4/iK0Dn0Cet0Z+kzWRK0K
Qd/fc7z9tLFixYmMtDMy2M5sHmhnevvjVlD8VnyC3VSKv0J3QD8RyzgplOKmoB8gkmIZ
Z3afQT8Se9l+6G/a+juxRGtafCyuYfeVoup0URdsRydZcNwkHzqs9SwzIpfEh+IqjgpS
fOCEtqD0SjW0Q3Yvoj0ufimKzqDstTrF+zzL/w2nMlslZb3iF06CGpl1lgxZF7Ni1vQn
zKAZNee1WDAWjc1rRtCIGglj3rB84jIOS3MCO6y4iDTBDIHVAzNhs+K840rY1n+xTbRd
gs0gLatcHmlB5RhS34Par1QuKc6yQzCBNqZg07AZ2BlcYs2K12Cvw96AvalKirAS7DQO
HwUQBRAFEAVFFEAUQBRAFBRRUNFLMCLyIPIg8iDyisiDyIPIg8grgvqbB5FXRAZEBkQG
REYRGRAZEBkQGUVkQGRAZBRhgjBBmCBMRZggTBAmCFMRJggThKmIGIgYiBiImCJiIGIg
YiBiioiBiIGIKcIAYYAwQBiKMEAYIAwQhiIMEAYIQxE+ED4QPhA+RfhA+ED4QPgU4VPz
U4IR0QTRBNEE0VREE0QTRBNEUxFNEE0QTXG6ojWsT4E0gDSANBTSANIA0gDSUEgDSANI
o73pRTUYAstmCjYNm4ERuwx2Gewy2GXFLqvlVYIRa4OwQdggbEXYIGwQNghbETYIG4St
iDKIMogyiLIiyiDKIMogyoooq4VbghHxzRflN54acYZnPXhxFTN8l9JpdkfpFFtV+iar
KH2DzSt9nb2l9DWWUHqahZSiPaVFJj3ckYluqx+HgEOw78NOweZgC7CbMF3lbsH+Absn
9prbXd36IX1OX9Bv6usW9KYuut2H3HPuBfdN97oFd9MtDGtAeNVxFIcW9rZKp5HeheFF
BGlS5ZJiFHFHcZzdi79RMWr2fGncHea3hvnNYb4wzN8e5laHeIa71JHOYAmBjvOsuSF0
UK7CEqHwQRyZLl+7s1k6oSdljS+1ZJcZgd6BVWDzsLdgCVgcFoUFYVKVDcM/a25vN7kE
C8OGYAaFYP39ONnq7fGYdeHl89VPvYx+TMoJ7wS36IRjkJoTPgT52Akfl1YHv8bCdBrE
P8LMXYUuOPI2qj9oya8duQi54shRyAtOeDfkqBP+XFpe/hxOgAmdaOsRbDfpYUd+F27P
OnKXpEvvcIi8hxEoiNpdPMtuQ4NtakcrUsCR+yHbHbmPvD0sTBPP3SyqurcORqpV0aG7
dZ51cXO9/FK+K+8A/xcGFsvjC6PmgtwK0q+Udsql6M/hbEnH6iR/vD5U2mqTfiTng+fl
e2iLB6/Jn8nd8nK05kHxJfT7vArhyLeMmrhqbpQzMiaL0dtyUn5HHpOH5QtBlDvye3KJ
uokrnqy4ek1m0OC3sRVBRz4TrKkuPi1/JE0ZlvuMJRpf9lSr3UR0iUaAxVvRH8f4Dgdr
tMafS9R4jzmsf6XP6kf1MX2/HtC369v0Qb3P0+vxebo8GzydHo/H7XHhkp55+ui9jgid
rPe56VOxzO2i1KXyPtG+DRWdxwvuEThXtjdqaZE+MsbT9vIJlj5u2P85Eqjxzmeft9cF
xrjdm2bpiTH7qUi6pt87bCciaVvPHM1WOL+cQ6ktztU4m8jW+D0qOjtAN0WocHb20kCd
cf7Y2Uu5HPP3v5r0J3sP9ux7OrVGkm+nj3wZ0v9odtD+afpI1v7VYM6OU+beYC5tn6Fb
JtRFt/COp+qiiySXrbsKonv8MJW7Cqkc3G4rN6zmLrixMAncPGPMIDccT8bIDXPU8gsB
h98QCfw6vSyk/EKdXuXn4uRXWTXGUxXDUD5BxlaVz2qQPeKDFQM2VQmFlFfA4Fny4tmA
oTq2SzUkJVyiUrlwnNephiRXweyRhy7BtsveBy57VSyNP/SRLZ++nfd9+nbCJ/J/Pk6O
RXh1T2lqhe5CkQ+Mn4Tl7YuvvuS3Z44bRmWq1L49RSh//MRLpMdO2qXAyZQ9FUgZlT0r
a1SvUPWeQKrCVsYnspUV82TK2WPuGQ8cS+WqyQNZ62uxzj+IlT2wRmMHqLEsxUpaa1Rb
VJ2kWBbFsihW0kyqWOMv07rPZCseNkbvniqtivWdWMP5gaHcWL+vcJAWdH3/kH9q4LqL
8StsfSRnbwiM2V4YVUWtqEVV2M+oqotuNdKu8k/tHxq4zq+0q3wo7gmMPfg/DUZO9DmP
tD105PksLRXbPLb2nE3SQ1X72fjLKfzD86Iy/D3qySbXfBTXepRKpUlKSpFJxtL28JG0
/SR96kTXESqfyqFs9/0yTVNllY6O8dq9ZVRG0AlepHCUi3D6VoLZSe/vibK7rAu6VChW
twzGT93AK/g0DNdx4rQzoq6Xxenq9iBdvxSrI3tbiutTUmfLUJzelE0AJQ221OyJIjMb
nI3OJsrBcrScoP88uzaPQjlPL6XOyLzGipHJ+wOBbDHHWl+WQLz3na2DKnCZMpFILjLJ
H3wn8OsPfn/Qiw+Hv62q+eL9CWmVT7KWc6syUroPldqIqiwpRAX8H8TpDTcKZW5kc3Ry
ZWFtCmVuZG9iagoxOTkgMCBvYmoKMjA0NjMKZW5kb2JqCjIwMCAwIG9iago8PCAvVHlw
ZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCA5MDUgL0NhcEhlaWdodCA3MjIgL0Rlc2Nl
bnQgLTIxMiAvRmxhZ3MKMzIgL0ZvbnRCQm94IFsgLTYyOCAtMzc3IDIwMzQgMTAxMSBd
IC9Gb250TmFtZSAvWkhBUVJWK0FyaWFsLUJvbGRNVAovSXRhbGljQW5nbGUgMCAvU3Rl
bVYgMCAvTGVhZGluZyAzMyAvTWF4V2lkdGggMjAwMCAvWEhlaWdodCA1MjUgL0ZvbnRG
aWxlMgoxOTggMCBSID4+CmVuZG9iagoyMDEgMCBvYmoKWyAyNzggNzUwIDQ3NCA3NTAg
NzUwIDg4OSA3NTAgMjM4IDMzMyAzMzMgNzUwIDc1MCAyNzggMzMzIDI3OCAyNzggNTU2
CjU1NiA1NTYgNzUwIDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDMzMyA3NTAgNzUwIDc1
MCA3NTAgNzUwIDc1MCA3MjIKNzIyIDcyMiA3MjIgNjY3IDYxMSA3NzggNzIyIDI3OCA3
NTAgNzIyIDYxMSA4MzMgNzIyIDc3OCA2NjcgNzUwIDcyMgo2NjcgNjExIDcyMiA2Njcg
OTQ0IDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDU1NiA2MTEgNTU2
CjYxMSA1NTYgMzMzIDYxMSA2MTEgMjc4IDI3OCA1NTYgMjc4IDg4OSA2MTEgNjExIDYx
MSA2MTEgMzg5IDU1NiAzMzMKNjExIDU1NiA3NzggNTU2IDU1NiA1MDAgNzUwIDc1MCA3
NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MAo3NTAgNzUwIDc1MCA3NTAg
NzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUw
Cjc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1
MCA3NTAgNzUwIDc1MCA3NTAKNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3
NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MAo3NTAgNzUwIDc1MCA3NTAg
NzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgMTAw
MAo3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDUwMCA1MDAgNzUwIDI3OCBd
CmVuZG9iago5IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAv
QmFzZUZvbnQgL1pIQVFSVitBcmlhbC1Cb2xkTVQgL0ZvbnREZXNjcmlwdG9yCjIwMCAw
IFIgL1dpZHRocyAyMDEgMCBSIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDIxMyAvRW5j
b2RpbmcgL01hY1JvbWFuRW5jb2RpbmcKPj4KZW5kb2JqCjIwMiAwIG9iago8PCAvQXV0
aG9yIChyYW5keSkgL0NyZWF0b3IgKFBvd2VyUG9pbnQpIC9DcmVhdGlvbkRhdGUgKEQ6
MjAwNjA3MjcxNTAwNTctMDcnMDAnKQovTW9kRGF0ZSAoRDoyMDA2MDcyNzE1MDA1Ny0w
NycwMCcpIC9Qcm9kdWNlciAoTWFjIE9TIFggMTAuNC43IFF1YXJ0eiBQREZDb250ZXh0
KQovVGl0bGUgKG1vYmlsZS1lbWFpbC1zcGFtLXNsaWRlcy5wcHQpID4+CmVuZG9iagp4
cmVmCjAgMjAzCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDUxNSAwMDAwMCBuIAow
MDAwMDAwMDIyIDAwMDAwIG4gCjAwMDAwMDA2MjAgMDAwMDAgbiAKMDAwMDAwMDQ5NiAw
MDAwMCBuIAowMDAwMDAyNzE2IDAwMDAwIG4gCjAwMDAyNDcxMjIgMDAwMDAgbiAKMDAw
MDAwMDc4MCAwMDAwMCBuIAowMDAwMDAxNjY1IDAwMDAwIG4gCjAwMDAyNjg4ODAgMDAw
MDAgbiAKMDAwMDIyOTk5NSAwMDAwMCBuIAowMDAwMDAxNjg0IDAwMDAwIG4gCjAwMDAw
MDE4NjggMDAwMDAgbiAKMDAwMDAwMTg4NyAwMDAwMCBuIAowMDAwMDAyNjk2IDAwMDAw
IG4gCjAwMDAwMDU1MDQgMDAwMDAgbiAKMDAwMDAwMjc1MiAwMDAwMCBuIAowMDAwMDA1
NjEyIDAwMDAwIG4gCjAwMDAwMDU0ODMgMDAwMDAgbiAKMDAwMDAwNTc4NyAwMDAwMCBu
IAowMDAwMDA2Njc0IDAwMDAwIG4gCjAwMDAyMzU1OTIgMDAwMDAgbiAKMDAwMDAwNjY5
NCAwMDAwMCBuIAowMDAwMDA2ODc4IDAwMDAwIG4gCjAwMDAwMDc0NjAgMDAwMDAgbiAK
MDAwMDAwNjg5NyAwMDAwMCBuIAowMDAwMDA3NTY4IDAwMDAwIG4gCjAwMDAwMDc0NDAg
MDAwMDAgbiAKMDAwMDAwNzc0MiAwMDAwMCBuIAowMDAwMDA4NjI5IDAwMDAwIG4gCjAw
MDAwMDg2NDkgMDAwMDAgbiAKMDAwMDAxNDgzMiAwMDAwMCBuIAowMDAwMDE0ODUzIDAw
MDAwIG4gCjAwMDAwMTUwMzcgMDAwMDAgbiAKMDAwMDAxNTA1NiAwMDAwMCBuIAowMDAw
MDIxMzMyIDAwMDAwIG4gCjAwMDAwMTY2MzQgMDAwMDAgbiAKMDAwMDAyMTQ0MCAwMDAw
MCBuIAowMDAwMDIxMzExIDAwMDAwIG4gCjAwMDAwMjE2MTUgMDAwMDAgbiAKMDAwMDAy
MjUwMiAwMDAwMCBuIAowMDAwMDIyNTIyIDAwMDAwIG4gCjAwMDAwMjI3MDYgMDAwMDAg
biAKMDAwMDAyMzk0OCAwMDAwMCBuIAowMDAwMDIyNzI1IDAwMDAwIG4gCjAwMDAwMjQw
NTYgMDAwMDAgbiAKMDAwMDAyMzkyNyAwMDAwMCBuIAowMDAwMDI0MjMxIDAwMDAwIG4g
CjAwMDAwMjUxMTggMDAwMDAgbiAKMDAwMDAyNTEzOCAwMDAwMCBuIAowMDAwMDI1MzIy
IDAwMDAwIG4gCjAwMDAwMjg1NDcgMDAwMDAgbiAKMDAwMDAyNTM0MSAwMDAwMCBuIAow
MDAwMDI4NjU1IDAwMDAwIG4gCjAwMDAwMjg1MjYgMDAwMDAgbiAKMDAwMDAyODgzMCAw
MDAwMCBuIAowMDAwMDI5NzE3IDAwMDAwIG4gCjAwMDAwMjk3MzcgMDAwMDAgbiAKMDAw
MDAyOTkyMSAwMDAwMCBuIAowMDAwMDM0MTA0IDAwMDAwIG4gCjAwMDAwMjk5NDAgMDAw
MDAgbiAKMDAwMDAzNDIxMiAwMDAwMCBuIAowMDAwMDM0MDgzIDAwMDAwIG4gCjAwMDAw
MzQzODcgMDAwMDAgbiAKMDAwMDAzNTI3NCAwMDAwMCBuIAowMDAwMjMwMTA2IDAwMDAw
IG4gCjAwMDAwMzUyOTQgMDAwMDAgbiAKMDAwMDAzNTQ3OCAwMDAwMCBuIAowMDAwMDM2
ODI2IDAwMDAwIG4gCjAwMDAwMzU0OTcgMDAwMDAgbiAKMDAwMDAzNjkzNCAwMDAwMCBu
IAowMDAwMDM2ODA1IDAwMDAwIG4gCjAwMDAwMzcxMDkgMDAwMDAgbiAKMDAwMDAzNzk5
NiAwMDAwMCBuIAowMDAwMDM4MDE2IDAwMDAwIG4gCjAwMDAwMzgyMDAgMDAwMDAgbiAK
MDAwMDA0MDg3NCAwMDAwMCBuIAowMDAwMDM4MjE5IDAwMDAwIG4gCjAwMDAwNDA5ODIg
MDAwMDAgbiAKMDAwMDA0MDg1MyAwMDAwMCBuIAowMDAwMDQxMTU4IDAwMDAwIG4gCjAw
MDAwNDIwNDUgMDAwMDAgbiAKMDAwMDA0MjA2NSAwMDAwMCBuIAowMDAwMDQyMjQ5IDAw
MDAwIG4gCjAwMDAwNDY0MjcgMDAwMDAgbiAKMDAwMDA0MjI2OCAwMDAwMCBuIAowMDAw
MDQ2NTM1IDAwMDAwIG4gCjAwMDAwNDY0MDYgMDAwMDAgbiAKMDAwMDA0NjcxMSAwMDAw
MCBuIAowMDAwMDQ3NTk4IDAwMDAwIG4gCjAwMDAwNDc2MTggMDAwMDAgbiAKMDAwMDA0
NzgwMiAwMDAwMCBuIAowMDAwMDUxNDExIDAwMDAwIG4gCjAwMDAwNDc4MjEgMDAwMDAg
biAKMDAwMDA1MTUxOSAwMDAwMCBuIAowMDAwMDUxMzkwIDAwMDAwIG4gCjAwMDAwNTE2
OTUgMDAwMDAgbiAKMDAwMDA1MjU4MiAwMDAwMCBuIAowMDAwMDUyNjAyIDAwMDAwIG4g
CjAwMDAwNTI3ODYgMDAwMDAgbiAKMDAwMDA1NjU3NSAwMDAwMCBuIAowMDAwMDUyODA1
IDAwMDAwIG4gCjAwMDAwNTY2ODYgMDAwMDAgbiAKMDAwMDA1NjU1MyAwMDAwMCBuIAow
MDAwMDU2ODY0IDAwMDAwIG4gCjAwMDAwNTc3NTQgMDAwMDAgbiAKMDAwMDA1Nzc3NSAw
MDAwMCBuIAowMDAwMDU3OTYxIDAwMDAwIG4gCjAwMDAwNjE2ODAgMDAwMDAgbiAKMDAw
MDA1Nzk4MSAwMDAwMCBuIAowMDAwMDYxNzkyIDAwMDAwIG4gCjAwMDAwNjE2NTggMDAw
MDAgbiAKMDAwMDA2MTk3MCAwMDAwMCBuIAowMDAwMDYyODYwIDAwMDAwIG4gCjAwMDAy
MzAyMTkgMDAwMDAgbiAKMDAwMDA2Mjg4MSAwMDAwMCBuIAowMDAwMDYzMDY3IDAwMDAw
IG4gCjAwMDAwNjM1NTQgMDAwMDAgbiAKMDAwMDA2MzA4NyAwMDAwMCBuIAowMDAwMDYz
NjY2IDAwMDAwIG4gCjAwMDAwNjM1MzMgMDAwMDAgbiAKMDAwMDEyMzA1MiAwMDAwMCBu
IAowMDAwMTIzOTQyIDAwMDAwIG4gCjAwMDAwNjM4NDUgMDAwMDAgbiAKMDAwMDEyMzAy
OSAwMDAwMCBuIAowMDAwMTIzOTYzIDAwMDAwIG4gCjAwMDAxMjQxNDkgMDAwMDAgbiAK
MDAwMDEyODI2MyAwMDAwMCBuIAowMDAwMTI0MTY5IDAwMDAwIG4gCjAwMDAxMjgzNzUg
MDAwMDAgbiAKMDAwMDEyODI0MSAwMDAwMCBuIAowMDAwMTI4NTUzIDAwMDAwIG4gCjAw
MDAxMjk0NDMgMDAwMDAgbiAKMDAwMDEyOTQ2NCAwMDAwMCBuIAowMDAwMTI5NjUwIDAw
MDAwIG4gCjAwMDAxMzQ0MzYgMDAwMDAgbiAKMDAwMDEyOTY3MCAwMDAwMCBuIAowMDAw
MTM0NTQ4IDAwMDAwIG4gCjAwMDAxMzQ0MTQgMDAwMDAgbiAKMDAwMDEzNDcyNiAwMDAw
MCBuIAowMDAwMTM1NjE2IDAwMDAwIG4gCjAwMDAxMzU2MzcgMDAwMDAgbiAKMDAwMDEz
NTgyMyAwMDAwMCBuIAowMDAwMTQwNTgwIDAwMDAwIG4gCjAwMDAxMzU4NDMgMDAwMDAg
biAKMDAwMDE0MDY5MiAwMDAwMCBuIAowMDAwMTQwNTU4IDAwMDAwIG4gCjAwMDAxNDA4
NzAgMDAwMDAgbiAKMDAwMDE0MTc2MCAwMDAwMCBuIAowMDAwMTQxNzgxIDAwMDAwIG4g
CjAwMDAxNDE5NjcgMDAwMDAgbiAKMDAwMDE0NTc2MSAwMDAwMCBuIAowMDAwMTQxOTg3
IDAwMDAwIG4gCjAwMDAxNDU4NzMgMDAwMDAgbiAKMDAwMDE0NTczOSAwMDAwMCBuIAow
MDAwMTQ2MDUxIDAwMDAwIG4gCjAwMDAxNDY5NDEgMDAwMDAgbiAKMDAwMDE0Njk2MiAw
MDAwMCBuIAowMDAwMTQ3MTQ4IDAwMDAwIG4gCjAwMDAxNDc3OTggMDAwMDAgbiAKMDAw
MDE0NzE2OCAwMDAwMCBuIAowMDAwMTQ3OTEwIDAwMDAwIG4gCjAwMDAxNDc3NzcgMDAw
MDAgbiAKMDAwMDE0ODA4OSAwMDAwMCBuIAowMDAwMTQ4OTc5IDAwMDAwIG4gCjAwMDAx
NDkwMDAgMDAwMDAgbiAKMDAwMDE5NzMzNCAwMDAwMCBuIAowMDAwMjMwMzM4IDAwMDAw
IG4gCjAwMDAxOTczNTcgMDAwMDAgbiAKMDAwMDE5NzU0MyAwMDAwMCBuIAowMDAwMTk4
MTg3IDAwMDAwIG4gCjAwMDAxOTc1NjMgMDAwMDAgbiAKMDAwMDE5ODI5OSAwMDAwMCBu
IAowMDAwMTk4MTY2IDAwMDAwIG4gCjAwMDAxOTg0NzggMDAwMDAgbiAKMDAwMDE5OTM2
OCAwMDAwMCBuIAowMDAwMTk5Mzg5IDAwMDAwIG4gCjAwMDAyMjU4OTEgMDAwMDAgbiAK
MDAwMDIyNTkxNCAwMDAwMCBuIAowMDAwMjI2MTAwIDAwMDAwIG4gCjAwMDAyMjg1ODgg
MDAwMDAgbiAKMDAwMDIyNjEyMCAwMDAwMCBuIAowMDAwMjI4NzAwIDAwMDAwIG4gCjAw
MDAyMjg1NjYgMDAwMDAgbiAKMDAwMDIyODg3OCAwMDAwMCBuIAowMDAwMjI5NzY4IDAw
MDAwIG4gCjAwMDAyMjk3ODkgMDAwMDAgbiAKMDAwMDIyOTk3NSAwMDAwMCBuIAowMDAw
MjMwNDMzIDAwMDAwIG4gCjAwMDAyMzA1NDMgMDAwMDAgbiAKMDAwMDIzMDYxMCAwMDAw
MCBuIAowMDAwMjM1MTM0IDAwMDAwIG4gCjAwMDAyMzUxNTYgMDAwMDAgbiAKMDAwMDIz
NTM5NSAwMDAwMCBuIAowMDAwMjM1NzY4IDAwMDAwIG4gCjAwMDAyNDY1MzggMDAwMDAg
biAKMDAwMDI0NjU2MSAwMDAwMCBuIAowMDAwMjQ2ODEzIDAwMDAwIG4gCjAwMDAyNDcz
MDcgMDAwMDAgbiAKMDAwMDI2Nzg2MyAwMDAwMCBuIAowMDAwMjY3ODg2IDAwMDAwIG4g
CjAwMDAyNjgxMzAgMDAwMDAgbiAKMDAwMDI2OTA1OSAwMDAwMCBuIAp0cmFpbGVyCjw8
IC9TaXplIDIwMyAvUm9vdCAxODkgMCBSIC9JbmZvIDIwMiAwIFIgL0lEIFsgPGRkNjMx
OGU0YzJlYmNmODE4YmEzNjFjNTRiZWM0YWMyPgo8ZGQ2MzE4ZTRjMmViY2Y4MThiYTM2
MWM1NGJlYzRhYzI+IF0gPj4Kc3RhcnR4cmVmCjI2OTI3OQolJUVPRgo=
--============_-868085363==_============--

From ned.freed@mrochek.com  Sat Aug  4 19:26:54 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5355F21F8810 for ; Sat,  4 Aug 2012 19:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.509
X-Spam-Level: 
X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0fypO3w+w32 for ; Sat,  4 Aug 2012 19:26:53 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 89E2821F8804 for ; Sat,  4 Aug 2012 19:26:53 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OINZOX7GG0005E8J@mauve.mrochek.com> for apps-discuss@ietfa.amsl.com; Sat, 4 Aug 2012 19:21:50 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Sat, 4 Aug 2012 19:21:48 -0700 (PDT)
Message-id: <01OINZOVL60S0006TF@mauve.mrochek.com>
Date: Sat, 04 Aug 2012 19:08:54 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Fri, 03 Aug 2012 16:38:46 -0700" 
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: 
To: Randall Gellens 
Cc: apps-discuss@ietfa.amsl.com
Subject: Re: [apps-discuss] 2006 proposal to add spam score and spam	notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 05 Aug 2012 02:26:54 -0000

Apologies in advance if this ground has already been covered and decided
on at the F2F meeting....

> During the apparea/appwg discussion of
> draft-ordogh-spam-reporting-using-imap, I was asked to send
> information regarding a proposal I'd made a number of years back to
> do this.

> Attached are slides outlining the proposal from July 27, 2006 (so
> pretty much exactly six years ago).  Page 20, for example, shows spam
> score being included in the message notification to the client, and
> the client sending an indication if a message is or is not spam back
> to the server.

Yes, this seems like the right overall model to me. Of course there needs
to be consensus on that, and then the devil will be in the details.

I guess my question is how to proceed. I'm not wild about the current draft for
various reasons, but most of all because it already nails down too many of the
specifics that I think need to be open for discussion and consensus. And it
does it without really specifying the overall model, which I think needs to be
clearly laid out.

My idea of an approach is to:

(1) Get agreement on the model (or if you prefer, information flow)
(2) Decide on what sort of information is carried, e.g.,
    spam/notspam, spam/notspam/undetermined, spam score, spam/virus scores,
    something even more general
(3) Decide on mechanism, e.g., headers, flags, annotations, commands

Does this sort of approach make sense? Can it be done in appsawg or do we need
a WG?

				Ned

From randy@qualcomm.com  Sat Aug  4 21:34:29 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC07221F8847 for ; Sat,  4 Aug 2012 21:34:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvIZ9iJVGRbu for ; Sat,  4 Aug 2012 21:34:29 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id EFD4721F8844 for ; Sat,  4 Aug 2012 21:34:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1344141269; x=1375677269; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; bh=dVBsAzlp7hmL5K3zmw7lp27Mbt/7OJOIuwyfPeIJ5lo=; b=Px61etmPSuHJvpKaq+j4dLmTBBXou+CkDeOi+uKnoMEq3ccQDkQt7ktN 5GXIPVRW35TYth0RsAHLGIKKae6riyh2q08Uj6Vp3aVsMOrik9U6x1vBE pZU3BZeAt7ubAJYz4wWI2Ju4PK9/45cI7U+YGueaaP3X52kQjO6VYaJ60 M=;
X-IronPort-AV: E=McAfee;i="5400,1158,6793"; a="217688765"
Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 04 Aug 2012 21:34:19 -0700
X-IronPort-AV: E=Sophos;i="4.77,714,1336374000"; d="scan'208";a="160311772"
Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Aug 2012 21:34:19 -0700
Received: from [208.181.206.130] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sat, 4 Aug 2012 21:34:17 -0700
Message-ID: 
In-Reply-To: <01OINZOVL60S0006TF@mauve.mrochek.com>
References:  <01OINZOVL60S0006TF@mauve.mrochek.com>
X-Mailer: Eudora for Mac OS X
Date: Sat, 4 Aug 2012 21:23:35 -0700
To: Ned Freed 
From: Randall Gellens 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [172.30.48.1]
Cc: apps-discuss@ietfa.amsl.com
Subject: Re: [apps-discuss] 2006 proposal to add spam score and spam notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 05 Aug 2012 04:34:30 -0000

At 7:08 PM -0700 8/4/12, Ned Freed wrote:

>  My idea of an approach is to:
>
>  (1) Get agreement on the model (or if you prefer, information flow)
>  (2) Decide on what sort of information is carried, e.g.,
>     spam/notspam, spam/notspam/undetermined, spam score, spam/virus scores,
>     something even more general
>  (3) Decide on mechanism, e.g., headers, flags, annotations, commands
>
>  Does this sort of approach make sense?

I think it makes sense.  I agree that text laying out the model and 
information flow would be helpful, and then discussion on the 
specifics of the information carried.

My (now ancient) proposal was that the server include a spam score 
(if available) in the message metadata, and the client can confirm a 
message as spam or as not spam.  Including the spam score allows the 
client to take this into account when deciding which messages it 
downloads when.  The confirmation as spam or not spam allows the 
server to refine the scoring algorithm, as well as take other action.

>   Can it be done in appsawg or do we need a WG?

I suggest this may depend on how much interest there is in actively 
working on it.  If there are a lot of people who want to be active, 
then we may need a WG.  If there will be a few people who will 
comment and review, then appsawg is fine.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Thoughts, like fleas, jump from man to man.  But they don't bite everybody.
    --Stanislaw Lec

From johnl@iecc.com  Sat Aug  4 21:50:12 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB16D21F846C for ; Sat,  4 Aug 2012 21:50:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -112.126
X-Spam-Level: 
X-Spam-Status: No, score=-112.126 tagged_above=-999 required=5 tests=[AWL=1.073, BAYES_00=-2.599, GB_I_INVITATION=-2, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlV3ln+2xwaG for ; Sat,  4 Aug 2012 21:50:12 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D595B21F8453 for ; Sat,  4 Aug 2012 21:50:11 -0700 (PDT)
Received: (qmail 54030 invoked from network); 5 Aug 2012 04:50:10 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 5 Aug 2012 04:50:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=501dfb82.xn--hew.k1208; i=johnl@user.iecc.com; bh=INmRxnHiiIi+GzVVorHu7unv6cAK6C7ydBVLOP6WR+4=; b=ESKd3XWq5esxqtTiIaW9tLgMtqyoRiN4Hy7Q9BPibgJXlMuRO65O7r2JZGQ0BOZX6haEmpzzcwzQH8o7qTToGlrnpa2TNRSORHXzSZ8lvnMcVSv1/9t3o0QTfCV29tZGJQWuSv4LXSF3LV9i2lzvz4eKR0UhKXHektadZRG5E4o=
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=501dfb82.xn--hew.k1208; olt=johnl@user.iecc.com; bh=INmRxnHiiIi+GzVVorHu7unv6cAK6C7ydBVLOP6WR+4=; b=jPjxwu8am4V61ioDcrB/RBDJZFYTAqoKmdKdK+WBbPOOvGR0LByiDOdsw6TR/5mNzGYm19XTUH86Ioq8WWrFcoE0wnO68yPpDoywadRsNA1f0WiQ6w7RPhkSKLA1nMnW3q1wZmmWa1U7wwvZbY/HAueY6xX+LloGYcNWdfNnByc=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 5 Aug 2012 04:49:48 -0000
Message-ID: <20120805044948.27421.qmail@joyce.lan>
From: "John Levine" 
To: apps-discuss@ietf.org
In-Reply-To: <01OINZOVL60S0006TF@mauve.mrochek.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
Cc: ned.freed@mrochek.com
Subject: Re: [apps-discuss] 2006 proposal to add spam score and spam	notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 05 Aug 2012 04:50:13 -0000

>Does this sort of approach make sense? Can it be done in appsawg or do we need
>a WG?

I doubt that any large mail provider would implement anything like
this.  They definitely want ways for users to report back when they
think the spam filters got it wrong, but not per-user rules and
certainly not reporting spam scores.

Per user rules in a large system are bad news because most users are
remarkably bad at saying what it is they want the rules to do.  I see
this all the time in which users report ordinary mail from lists
they've subscribed to as spam.  Maybe they don't want the list any
more, maybe they just decided to report everything in the inbox as
spam.  There's no way to tell. 

I have also heard from people who should be in a position to know that
in large mail systems, overall systems that can see the whole mail
stream manage filters better than individuals do, and if you're
getting a lot of requests for per-user tuning, that tells you that
your spam filters don't work very well.  Your time is better spent
fixing the overall filters rather than providing knobs.  One cable ISP
told me that they were getting tons of requests for per-user rules,
then they revamped their filters to work better, and the requests just
stopped.

Reporting spam scores is mostly an invitation to spammers to use them
to game the filters.  I know that Spamassassin does it, but large mail
systems don't use Spamassassin.

R's,
John

From superuser@gmail.com  Sun Aug  5 00:35:10 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CB821F8442 for ; Sun,  5 Aug 2012 00:35:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.657
X-Spam-Level: 
X-Spam-Status: No, score=-3.657 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6JYVB1yfgdM for ; Sun,  5 Aug 2012 00:35:09 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF2B721F8441 for ; Sun,  5 Aug 2012 00:35:06 -0700 (PDT)
Received: by lbbgo11 with SMTP id go11so2414146lbb.31 for ; Sun, 05 Aug 2012 00:35:05 -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=bLmXKZXo7Y11vPF6N4lTY5LgN/gh1LgH+sRoFU22Bts=; b=i/AndBKmGguI8kdeiN8lJy5+Gw5XwqDvLCELRSIPcgIX5ZF3Y068kDDW0PSqbpMv9+ a3txujwmjV8hjdX7ki0U4M946Uz7uwugDzlG1r4KCqHzZWgkBsrGAWUdTW09sHhxgI7u KreiPmvRHFGhzbxW6VVohgD0Gt8n935iB42L7k9EkVBmXDxl9hoWuJdwKltWjYW8r2zr MLNu1zvVs38t8/bbJLgYDGirgUPv/gHtZ3nshxPj9+1VOqEy8fphlWptMdccF5+y+Pd/ f3AQ0oW46a9Rd8bitD/sR1kPvrYJ5ZIcYdUSkmGYLhj9CcIi3PKF8wDrxaXgdHIp+i2B aFgg==
MIME-Version: 1.0
Received: by 10.112.39.135 with SMTP id p7mr2944147lbk.78.1344152105657; Sun, 05 Aug 2012 00:35:05 -0700 (PDT)
Received: by 10.112.89.3 with HTTP; Sun, 5 Aug 2012 00:35:05 -0700 (PDT)
Date: Sun, 5 Aug 2012 00:35:05 -0700
Message-ID: 
From: "Murray S. Kucherawy" 
To: IETF Apps Discuss 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [apps-discuss] Meeting minutes available
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 05 Aug 2012 07:35:10 -0000

I have posted the meeting minutes from the APPSAWG/APPAREA meeting on
Monday.  They are visible here:

http://www.ietf.org/proceedings/84/minutes/minutes-84-appsawg

Please review them and provide any corrections.  In particular, there
are a couple of places where "?" appears.  If those blanks could be
filled in, we'd appreciate it.  Also, if we failed to capture any
important action items, please bring those to our attention.

Thank you all for attending!

-MSK, for Salvatore and the ADs

From ned.freed@mrochek.com  Sun Aug  5 08:14:23 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DADF21F84F8 for ; Sun,  5 Aug 2012 08:14:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.51
X-Spam-Level: 
X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=1.089,  BAYES_00=-2.599, GB_I_INVITATION=-2]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHIZsXYzgqr1 for ; Sun,  5 Aug 2012 08:14:22 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 99CA021F84F7 for ; Sun,  5 Aug 2012 08:14:18 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIOQIDCHSG006GX6@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 5 Aug 2012 08:09:15 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Sun, 5 Aug 2012 08:09:14 -0700 (PDT)
Message-id: <01OIOQIBZOBK0006TF@mauve.mrochek.com>
Date: Sun, 05 Aug 2012 07:53:10 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Sun, 05 Aug 2012 04:49:48 +0000" <20120805044948.27421.qmail@joyce.lan>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <01OINZOVL60S0006TF@mauve.mrochek.com> <20120805044948.27421.qmail@joyce.lan>
To: John Levine 
Cc: ned.freed@mrochek.com, apps-discuss@ietf.org
Subject: Re: [apps-discuss] 2006 proposal to add spam score and spam	notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 05 Aug 2012 15:14:23 -0000

> >Does this sort of approach make sense? Can it be done in appsawg or do we need
> >a WG?

> I doubt that any large mail provider would implement anything like
> this.  They definitely want ways for users to report back when they
> think the spam filters got it wrong, but not per-user rules and
> certainly not reporting spam scores.

Actually, I know of several very large providers that have implemented per-user
rules of various sorts, including but not limited to blacklisting. (The
storage requirements for this can be truly impressive, BTW.)

But even if that weren't the case, IETF standards have a broaders audience
than large service providers.

> Per user rules in a large system are bad news because most users are
> remarkably bad at saying what it is they want the rules to do.  I see
> this all the time in which users report ordinary mail from lists
> they've subscribed to as spam.  Maybe they don't want the list any
> more, maybe they just decided to report everything in the inbox as
> spam.  There's no way to tell.

OK... but now you seem to be arguing against your own brief. If a user
adds a private white or black list rule, that's, well, private and only
affects them when they get the rules wrong. At most it's a support call
generator, and yes, this has been an issue for large providers that
support per-user rules.

OTOH, you say they want feedback when users say the filters got it wrong, and
if the user is incorrect on that... now you have incorrect feedback informaion.

> I have also heard from people who should be in a position to know that
> in large mail systems, overall systems that can see the whole mail
> stream manage filters better than individuals do, and if you're
> getting a lot of requests for per-user tuning, that tells you that
> your spam filters don't work very well.  Your time is better spent
> fixing the overall filters rather than providing knobs.  One cable ISP
> told me that they were getting tons of requests for per-user rules,
> then they revamped their filters to work better, and the requests just
> stopped.

The counterargument is that users like to feel that they are in control.

> Reporting spam scores is mostly an invitation to spammers to use them
> to game the filters.  I know that Spamassassin does it, but large mail
> systems don't use Spamassassin.

As it happens that's also incorrect: Some large providers do in fact use
SpamAssassin variants. I personally think it's a poor choice for large scale
setups, but it's hardly the only or even close to the worst decision decision
I've seen a provider make.

As for reporting scores, any system that's capable of reporting a score
can be used to report a simple binary outcome. But the opposite is
not true. And again, the target audience here needs to cover a lot more
than large ISPs.

At most the takeaway I see here is that we need to document how to use
specific subsets of the feature set that's provided.

				Ned

From johnl@iecc.com  Sun Aug  5 08:30:13 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8C921F849B for ; Sun,  5 Aug 2012 08:30:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -112.142
X-Spam-Level: 
X-Spam-Status: No, score=-112.142 tagged_above=-999 required=5 tests=[AWL=1.057, BAYES_00=-2.599, GB_I_INVITATION=-2, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKz0kkv17VYi for ; Sun,  5 Aug 2012 08:30:13 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C257221F849A for ; Sun,  5 Aug 2012 08:30:12 -0700 (PDT)
Received: (qmail 45221 invoked from network); 5 Aug 2012 15:30:11 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 5 Aug 2012 15:30:11 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=501e9183.xn--i8sz2z.k1208; i=johnl@user.iecc.com; bh=+VMYw+6/YgrXBFCvXtYb4w2Wj/KD2Pks9i5vWSpuNAM=; b=gMTmsWor4g3x06feT4OK14aubjwvxyrkVw5XlkDEvrBvv8UW4MZxdq0GESrRMVsHgklztj5bIhg7b9BUEnw55rvriJUrN/XxuOqzZjMz42/mVwvrszjJeIc5dHL2m08hH1YFR2LDSIBc2Hdlnr3LhuMu/9tr/yt4UHrap5NqWy8=
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=501e9183.xn--i8sz2z.k1208; olt=johnl@user.iecc.com; bh=+VMYw+6/YgrXBFCvXtYb4w2Wj/KD2Pks9i5vWSpuNAM=; b=xtOX/ANqVanXkPIOsyJu+on+qq6Vn0IbuzVtXS8poO8BG0A+lFGIlG5MnhebJ9aJHRKgs4zjB7BFki6BECNnnQH2uc7vYT+wurwex6hJRajt1qE9Xc6tHV1sbTPh9JnjPHLx/GIQEQBW6x8PvKYVNxIPw+XzUi8TfVqv6iqf4Z4=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 5 Aug 2012 15:29:49 -0000
Message-ID: <20120805152949.84964.qmail@joyce.lan>
From: "John Levine" 
To: apps-discuss@ietf.org
In-Reply-To: <01OIOQIBZOBK0006TF@mauve.mrochek.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
Cc: ned.freed@mrochek.com
Subject: Re: [apps-discuss] 2006 proposal to add spam score and spam	notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 05 Aug 2012 15:30:13 -0000

> OTOH, you say they want feedback when users say the filters got it 
> wrong, and if the user is incorrect on that... now you have incorrect 
> feedback informaion.

The feedback doesn't directly turn into a rule.  Providers treat them with 
considerable scepticsm unless there are either a lot of similar reports, 
or the stuff that's reported has other characteristics of spam.

> The counterargument is that users like to feel that they are in control.

That's why you give them a spam button, but you're vague about what it 
does.

>> Reporting spam scores is mostly an invitation to spammers to use them
>> to game the filters.  I know that Spamassassin does it, but large mail
>> systems don't use Spamassassin.
>
> As it happens that's also incorrect: Some large providers do in fact use
> SpamAssassin variants.

Maybe they do, but I don't recally seeing any handy scores in the
headers you can use to tune your spam.  Yahoo puts a lot of opaque
stuff in the headers which I presume includes filtering results, but I
never heard of anyone reverse engineering it.

> At most the takeaway I see here is that we need to document how to use
> specific subsets of the feature set that's provided.

And make it clear that it's all 100% optional.

Plan B: talk to some large providers and see what they might be interested 
in implementing across the board.  I know there's a lot of interest in the 
IMAP spam button if we can sort out the patent issues.

R's,
John

From john-ietf@jck.com  Sun Aug  5 19:46:30 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918A221F8577 for ; Sun,  5 Aug 2012 19:46:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKymLujy0Jwb for ; Sun,  5 Aug 2012 19:46:30 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id DB6FA21F853F for ; Sun,  5 Aug 2012 19:46:29 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SyDF2-0009fM-Gp; Sun, 05 Aug 2012 22:40:24 -0400
Date: Sun, 05 Aug 2012 22:46:28 -0400
From: John C Klensin 
To: Andrew Sullivan , apps-discuss@ietf.org
Message-ID: <5A4FCAA5BA5F59D02EC64B1C@JCK-EEE10>
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
Subject: [apps-discuss] draft-sullivan-domain-origin-assert-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 06 Aug 2012 02:46:30 -0000

Andrew,

I find this document fairly troubling, largely for the reasons
we discussed briefly in Vancouver.  I think your explanation of
the problem(s) and what you are trying to do is muddy, in part
because it seems to me that you are trying to solve too many
problems, some of them simply incompatible with the architecture
of the DNS.  To make things worse, the terminology is confusing,
perhaps because of the old problem that existing DNS terminology
usage is, bluntly, a mess. In particular, the boundaries that
are more specifically discussed in "zone cut" terms (delegation
records and a requirement for an SOA record in the subsidiary
domain (and zone) are widely known as "administrative
boundaries".  Your using that term, or even "administrative
realm" is an invitation to confusion and trouble, especially in
the absence of text that explicitly repudiates the earlier usage.

More broadly, what you are trying to do here is to overlay an
entirely different data structure --really a mesh-- on top of
the strict hierarchy (with weak aliases) DNS structure. That
mesh is multidimensional with the potential for arrangements by
related domain names, by ports, and by scheme/protocol.  If very
much of that is used, one could easily end up with a lot of
these records at a given node, far exceeding the UDP limit and
possibly causing other problems.  Worse, if a node makes an
assertion about some set of other nodes and they make
contradictory assertions (whether through malice, configuration
error, or attempts at cleverness the spec doesn't anticipate),
one could end up with a rather interesting mess.  I note in that
regard that, in the general case, nothing ensures, or even
predicts, that port numbers of interest to a particular
situation will occupy continuous ranges.  If they do not, even
an attempt to make an assertion about port numbers could result
in a lot of records.

Putting aside the nomenclature issues with "administrative"
mentioned above for a moment, I suggest that one could get a
good 90% solution simply by defining a "policy authority origin"
record that parallels the function and definition of the "DNS
administrative authority origin" indication and information
provided by the SOA record.  That model fits nicely with the DNS
hierarchy (rather than trying to superimpose a new mesh on top
of it) -- it just clearly defines the two types of boundaries
separate from each other (which they are, of course).

The missing 10% includes protocol-sensitive machinery
("schemes"), and port-sensitive machinery, both of which we've
tended to avoid in the DNS architecture unless the relevant
records really are bound to particular protocols.  It also
includes the ability for one node to make assertions about a
node elsewhere in the hierarchy without necessarily having
permission from the target node -- effectively repeating and
extending the problem we have with aliases (reinforced by the
limitations of DNSSEC in those cases).  I think (although I'm
not yet ready to try to convince others), that it puts us
further into the situation of trying to build a trust model on
the integrity of registrars -- in today's environment, that
isn't a risk factor but a certain problem.

I can suggest some specific language to clarify the current
draft if that were appropriate, but I think you should consider
whether a much simpler model with provide most of the
functionality you are looking for with considerably less
potential complexity and the introduction of new risks.
Conversely, I think you should be required to really justify the
importance of port ranges, lists of URI schemes, and lists of
names that share owners rather than just putting those
capabilities in because (maybe) we know how.  

While aspects of the "variant" story are clearly in your mind
(and I fear contributing to assorted fantasies of what the DNS
can do to help with that without getting any real value in
return), your one clear use case is the public suffix list and
related cookie issues -- and those do not require port ranges,
scheme lists, or identification of other domains with the same
ownership -- it only requires clear identification of the
administrative/control/ policy boundary.

   best,
    john





 

From ajs@anvilwalrusden.com  Mon Aug  6 07:24:09 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F2421F84F6 for ; Mon,  6 Aug 2012 07:24:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.225
X-Spam-Level: 
X-Spam-Status: No, score=-1.225 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfSQeGZYfALK for ; Mon,  6 Aug 2012 07:24:08 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6774521F84E2 for ; Mon,  6 Aug 2012 07:24:08 -0700 (PDT)
Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 92A788A031 for ; Mon,  6 Aug 2012 14:24:07 +0000 (UTC)
Date: Mon, 6 Aug 2012 10:22:55 -0400
From: Andrew Sullivan 
To: apps-discuss@ietf.org
Message-ID: <20120806142255.GA53917@mail.yitter.info>
References: <5A4FCAA5BA5F59D02EC64B1C@JCK-EEE10>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5A4FCAA5BA5F59D02EC64B1C@JCK-EEE10>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [apps-discuss] draft-sullivan-domain-origin-assert-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 06 Aug 2012 14:24:09 -0000

Hi John,

Thanks for the comments.  A little further discussion inline.

On Sun, Aug 05, 2012 at 10:46:28PM -0400, John C Klensin wrote:

> we discussed briefly in Vancouver.  I think your explanation of
> the problem(s) and what you are trying to do is muddy,

Probably.  But I'm not sure you're right I'm trying to solve too many
problems at once.  See below.

> usage is, bluntly, a mess. In particular, the boundaries that
> are more specifically discussed in "zone cut" terms (delegation
> records and a requirement for an SOA record in the subsidiary
> domain (and zone) are widely known as "administrative
> boundaries".

Yeah.  I picked the current term as a kind of compromise -- some have
argued that these should be called "administrative domains", which is
surely worse.  But I like the "policy authority" suggestion, and will
try to do something with that.  

> More broadly, what you are trying to do here is to overlay an
> entirely different data structure --really a mesh-- on top of
> the strict hierarchy (with weak aliases) DNS structure. That
> mesh is multidimensional with the potential for arrangements by
> related domain names, by ports, and by scheme/protocol. 

Yes.  The problem here is that in the first draft on this topic I
didn't do this, and the response on the w3c web security list was that
without schemes and ports the entire idea was totally useless for
their purposes.  I am not sure how to reconcile that view with the
argument you make, which is that we're trying to make statements about
who's in charge of a name.  Perhaps, however, this is an example of
the "too many problems" you argue.

The difficulty I have is that the user base for this is really just
applications, web browsers prominently among them.  If their
developers say, "Without these other bits, this mechanism is no use to
me, and I won't implement it," that's a strong incentive for me to
want to include those other bits.  Maybe this means that one needs
more than one RR, but then we're into round trips that web browsers
also don't want to make.

> If very
> much of that is used, one could easily end up with a lot of
> these records at a given node, far exceeding the UDP limit and
> possibly causing other problems.  Worse, if a node makes an
> assertion about some set of other nodes and they make
> contradictory assertions (whether through malice, configuration
> error, or attempts at cleverness the spec doesn't anticipate),

Actually, I did think about both of these issues.  Section 7.1 points
out that you can exceed the UDP limits, although it doesn't talk about
the extent to which that is undesirable (frankly, I ran out of time to
discuss it at length).  The security consideration section notes that
you'd be an idiot to accept the results if both sides didn't agree,
but doesn't go further.  I'd be willing to make this stronger,
although there's at least one case of cookie use where I'm not sure
about whether it'd be ok not to check both sides.

> predicts, that port numbers of interest to a particular
> situation will occupy continuous ranges.  If they do not, even
> an attempt to make an assertion about port numbers could result
> in a lot of records.

Yes.  The draft says, "It does not, however, permit arbitrary
combinations of destination point and schemes without using more than
one RR."  I guess that could be clearer.

The reason that the port ranges and wildcard on the scheme are there
is exactly so that one can make these records port- and
scheme-insensitive.  I personally think that's the way it'd get used
most often anyway, but I'm willing to make the protocol a little
messier if it causes people who work on web browsers to think about it
some more.

> record that parallels the function and definition of the "DNS
> administrative authority origin" indication and information
> provided by the SOA record.  That model fits nicely with the DNS
> hierarchy (rather than trying to superimpose a new mesh on top
> of it) -- it just clearly defines the two types of boundaries
> separate from each other (which they are, of course).

This was the notion I originally had, yes.  (I didn't call it the SOPA
record, but one is tempted now that you've introduced the "Policy
Authority" term.)

> While aspects of the "variant" story are clearly in your mind

No, or anyway not exactly.  I think the variant story is just one
facet of exactly the same story over and over again: we need to make
explicit who has or does not have policy control over a given zone.
That's the issue with cookies, with cross-site problems, and with
"variants" too.  I don't think they're actually different problems,
which is why you think I'm trying to solve more than one problem at
the same time.

Best,

A

> (and I fear contributing to assorted fantasies of what the DNS
> can do to help with that without getting any real value in
> return), your one clear use case is the public suffix list and
> related cookie issues -- and those do not require port ranges,
> scheme lists, or identification of other domains with the same
> ownership -- it only requires clear identification of the
> administrative/control/ policy boundary.
> 
>    best,
>     john
> 
> 
> 
> 
> 
>  

-- 
Andrew Sullivan
ajs@anvilwalrusden.com

From john+xml@jck.com  Sun Aug  5 19:43:38 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05F021F8532 for ; Sun,  5 Aug 2012 19:43:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level: 
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sz3zyyNPUZ6b for ; Sun,  5 Aug 2012 19:43:38 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id F278F21F84F1 for ; Sun,  5 Aug 2012 19:43:37 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SyDCF-0009el-R3; Sun, 05 Aug 2012 22:37:32 -0400
Date: Sun, 05 Aug 2012 22:43:35 -0400
From: John C Klensin 
To: Andrew Sullivan , apps-discuss@ietf.org
Message-ID: 
In-Reply-To: <20120716212141.GP96149@dyn.com>
References: <20120716204725.9601.71787.idtracker@ietfa.amsl.com> <20120716212141.GP96149@dyn.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Mailman-Approved-At: Mon, 06 Aug 2012 08:02:58 -0700
Subject: [apps-discuss] draft-sullivan-domain-origin-assert-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 06 Aug 2012 02:43:38 -0000

Andrew,

I find this document fairly troubling, largely for the reasons
we discussed briefly in Vancouver.  I think your explanation of
the problem(s) and what you are trying to do is muddy, in part
because it seems to me that you are trying to solve too many
problems, some of them simply incompatible with the architecture
of the DNS.  To make things worse, the terminology is confusing,
perhaps because of the old problem that existing DNS terminology
usage is, bluntly, a mess. In particular, the boundaries that
are more specifically discussed in "zone cut" terms (delegation
records and a requirement for an SOA record in the subsidiary
domain (and zone) are widely known as "administrative
boundaries".  Your using that term, or even "administrative
realm" is an invitation to confusion and trouble, especially in
the absence of text that explicitly repudiates the earlier usage.

More broadly, what you are trying to do here is to overlay an
entirely different data structure --really a mesh-- on top of
the strict hierarchy (with weak aliases) DNS structure. That
mesh is multidimensional with the potential for arrangements by
related domain names, by ports, and by scheme/protocol.  If very
much of that is used, one could easily end up with a lot of
these records at a given node, far exceeding the UDP limit and
possibly causing other problems.  Worse, if a node makes an
assertion about some set of other nodes and they make
contradictory assertions (whether through malice, configuration
error, or attempts at cleverness the spec doesn't anticipate),
one could end up with a rather interesting mess.  I note in that
regard that, in the general case, nothing ensures, or even
predicts, that port numbers of interest to a particular
situation will occupy continuous ranges.  If they do not, even
an attempt to make an assertion about port numbers could result
in a lot of records.

Putting aside the nomenclature issues with "administrative"
mentioned above for a moment, I suggest that one could get a
good 90% solution simply by defining a "policy authority origin"
record that parallels the function and definition of the "DNS
administrative authority origin" indication and information
provided by the SOA record.  That model fits nicely with the DNS
hierarchy (rather than trying to superimpose a new mesh on top
of it) -- it just clearly defines the two types of boundaries
separate from each other (which they are, of course).

The missing 10% includes protocol-sensitive machinery
("schemes"), and port-sensitive machinery, both of which we've
tended to avoid in the DNS architecture unless the relevant
records really are bound to particular protocols.  It also
includes the ability for one node to make assertions about a
node elsewhere in the hierarchy without necessarily having
permission from the target node -- effectively repeating and
extending the problem we have with aliases (reinforced by the
limitations of DNSSEC in those cases).  I think (although I'm
not yet ready to try to convince others), that it puts us
further into the situation of trying to build a trust model on
the integrity of registrars -- in today's environment, that
isn't a risk factor but a certain problem.

I can suggest some specific language to clarify the current
draft if that were appropriate, but I think you should consider
whether a much simpler model with provide most of the
functionality you are looking for with considerably less
potential complexity and the introduction of new risks.
Conversely, I think you should be required to really justify the
importance of port ranges, lists of URI schemes, and lists of
names that share owners rather than just putting those
capabilities in because (maybe) we know how.  

While aspects of the "variant" story are clearly in your mind
(and I fear contributing to assorted fantasies of what the DNS
can do to help with that without getting any real value in
return), your one clear use case is the public suffix list and
related cookie issues -- and those do not require port ranges,
scheme lists, or identification of other domains with the same
ownership -- it only requires clear identification of the
administrative/control/ policy boundary.

   best,
    john







From barryleiba.mailing.lists@gmail.com  Mon Aug  6 08:29:31 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC1621F866A for ; Mon,  6 Aug 2012 08:29:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.032
X-Spam-Level: 
X-Spam-Status: No, score=-104.032 tagged_above=-999 required=5 tests=[AWL=0.944, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRDRDzrJUaII for ; Mon,  6 Aug 2012 08:29:29 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 62CA821F8672 for ; Mon,  6 Aug 2012 08:29:29 -0700 (PDT)
Received: by lbbgg6 with SMTP id gg6so526050lbb.31 for ; Mon, 06 Aug 2012 08:29:28 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=cBvPsccnlniakoH0rVsx6FnG6f/42O4gmvyqurKKJmM=; b=Hql6YXyLKP9WkaS2P4UEWu5CEXBSp0pkCrt+fFBDLrrjDSHVWnw2M4LQaa2FDqT0Ob bSMW6rs16yfEFij++l6fke3QBNXyWw31UNDIBT5x91wN7ILjMYDFaT96uCKevMRSDtGN cVKGJsb/gs6zUQujY3iY/wQBbMxBjbMlUNfENVRjJXULiLEx2WRe4rEqvfEjlZEKLymA hKeTkKQ3awPZy4pm5FDqY1lVNCbD93Z6vfDFcSIk1sX5FsdCzBnRluTFEISGDkaVd4r3 l2p1I3T+cJRmRJBwxU8kWY9/P+xDJiROdHbYgxG69s4aS7pKq45o//StnxdjuHUHe2WQ AqtA==
MIME-Version: 1.0
Received: by 10.152.105.173 with SMTP id gn13mr11126332lab.20.1344266968355; Mon, 06 Aug 2012 08:29:28 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.112.17.133 with HTTP; Mon, 6 Aug 2012 08:29:28 -0700 (PDT)
In-Reply-To: <20120805152949.84964.qmail@joyce.lan>
References: <01OIOQIBZOBK0006TF@mauve.mrochek.com> <20120805152949.84964.qmail@joyce.lan>
Date: Mon, 6 Aug 2012 11:29:28 -0400
X-Google-Sender-Auth: rv6uOSvMkJeEW_USDe_aC8CAw60
Message-ID: 
From: Barry Leiba 
To: John Levine 
Content-Type: multipart/alternative; boundary=f46d040714c521d4e104c69a8b34
Cc: "ned.freed@mrochek.com" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] 2006 proposal to add spam score and spam notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 06 Aug 2012 15:29:31 -0000

--f46d040714c521d4e104c69a8b34
Content-Type: text/plain; charset=ISO-8859-1

My sense is that we should work closely with MAAWG in developing the model,
and then work on the protocol.  We have a good connection to MAAWG.

Barry

On Sunday, August 5, 2012, John Levine wrote:

> > OTOH, you say they want feedback when users say the filters got it
> > wrong, and if the user is incorrect on that... now you have incorrect
> > feedback informaion.
>
> The feedback doesn't directly turn into a rule.  Providers treat them with
> considerable scepticsm unless there are either a lot of similar reports,
> or the stuff that's reported has other characteristics of spam.
>
> > The counterargument is that users like to feel that they are in control.
>
> That's why you give them a spam button, but you're vague about what it
> does.
>
> >> Reporting spam scores is mostly an invitation to spammers to use them
> >> to game the filters.  I know that Spamassassin does it, but large mail
> >> systems don't use Spamassassin.
> >
> > As it happens that's also incorrect: Some large providers do in fact use
> > SpamAssassin variants.
>
> Maybe they do, but I don't recally seeing any handy scores in the
> headers you can use to tune your spam.  Yahoo puts a lot of opaque
> stuff in the headers which I presume includes filtering results, but I
> never heard of anyone reverse engineering it.
>
> > At most the takeaway I see here is that we need to document how to use
> > specific subsets of the feature set that's provided.
>
> And make it clear that it's all 100% optional.
>
> Plan B: talk to some large providers and see what they might be interested
> in implementing across the board.  I know there's a lot of interest in the
> IMAP spam button if we can sort out the patent issues.
>
> R's,
> John
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org 
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--f46d040714c521d4e104c69a8b34
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

My sense is that we should work closely with MAAWG in developing the model,=
 and then work on the protocol. =A0We have a good connection to MAAWG.
=

Barry

On Sunday, August 5, 2012, John Le=
vine  wrote:


> OTOH, you say they want feedback when u=
sers say the filters got it

> wrong, and if the user is incorrect on that... now you have incorrect<=
br>
> feedback informaion.



The feedback doesn't directly turn into a rule. =A0Providers treat them=
 with

considerable scepticsm unless there are either a lot of similar reports,
or the stuff that's reported has other characteristics of spam.



> The counterargument is that users like to feel that they are in contro=
l.



That's why you give them a spam button, but you're vague about what=
 it

does.



>> Reporting spam scores is mostly an invitation to spammers to use t=
hem

>> to game the filters. =A0I know that Spamassassin does it, but larg=
e mail

>> systems don't use Spamassassin.

>

> As it happens that's also incorrect: Some large providers do in fa=
ct use

> SpamAssassin variants.



Maybe they do, but I don't recally seeing any handy scores in the

headers you can use to tune your spam. =A0Yahoo puts a lot of opaque

stuff in the headers which I presume includes filtering results, but I

never heard of anyone reverse engineering it.



> At most the takeaway I see here is that we need to document how to use=


> specific subsets of the feature set that's provided.



And make it clear that it's all 100% optional.



Plan B: talk to some large providers and see what they might be interested<=
br>
in implementing across the board. =A0I know there's a lot of interest i=
n the

IMAP spam button if we can sort out the patent issues.



R's,

John

_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/apps-discuss




--f46d040714c521d4e104c69a8b34--

From johnl@taugh.com  Mon Aug  6 09:00:10 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5653321F85ED for ; Mon,  6 Aug 2012 09:00:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.591
X-Spam-Level: 
X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.009,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57PYXm+cQdhY for ; Mon,  6 Aug 2012 09:00:07 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 6474D21F8609 for ; Mon,  6 Aug 2012 09:00:07 -0700 (PDT)
Received: (qmail 38574 invoked from network); 6 Aug 2012 16:00:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=96ad.501fea05.k1208; bh=msqJ/9fTljdfRe7zxXinWsPPhwfr0dXySm1fYiD4F7Q=; b=JSWitIckOCrXLAGvLOIScrBgzbJUFQXi5b7Pzv0cWROq6enNXyHqkiyjkd5g6qaHt+56qc9yHdN7+Bm3HCWu2iaUEiyswgmNYv4PbmjtRH1CNQ1kAazPlub+epD8wVpVdYwDye3t4hGjLJmOKzWrmDffu+6vxyTejI9whfe2j8k=
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=96ad.501fea05.k1208; bh=msqJ/9fTljdfRe7zxXinWsPPhwfr0dXySm1fYiD4F7Q=; b=lCeGBfxa8vbRF4VkWqa2exoyWbZcr/IMERD5hJgQId5uSmTsh2NmWt7MjjWA3IFb2ZieTe9FxWWYXatQWzlAN66JlyJLrBUcO4Gjxbox8V5oGqhP5Rg/ViGQvw+mvXreCQp9AOibOOm4ryR7ssQ5SP1AVSUIoGVIvdvakdU/PD4=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Received: (ofmipd 127.0.0.1); 6 Aug 2012 15:59:43 -0000
Date: 6 Aug 2012 12:00:05 -0400
Message-ID: 
From: "John R Levine" 
To: "Barry Leiba" 
In-Reply-To: 
References: <01OIOQIBZOBK0006TF@mauve.mrochek.com> <20120805152949.84964.qmail@joyce.lan> 
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
Cleverness: None detected
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] 2006 proposal to add spam score and spam notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 06 Aug 2012 16:00:10 -0000

> My sense is that we should work closely with MAAWG in developing the model,
> and then work on the protocol.  We have a good connection to MAAWG.

Yup, that was plan B.

>> Plan B: talk to some large providers and see what they might be interested
>> in implementing across the board.  I know there's a lot of interest in the
>> IMAP spam button if we can sort out the patent issues.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

From johnl@iecc.com  Mon Aug  6 09:56:47 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8797611E808D for ; Mon,  6 Aug 2012 09:56:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.571
X-Spam-Level: 
X-Spam-Status: No, score=-101.571 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_00=-2.599, MISSING_SUBJECT=1.762, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlae4SEL-ER7 for ; Mon,  6 Aug 2012 09:56:47 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id CC26111E808A for ; Mon,  6 Aug 2012 09:56:46 -0700 (PDT)
Received: (qmail 52700 invoked from network); 6 Aug 2012 16:56:45 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:mime-version:content-type:content-transfer-encoding:vbr-info; s=cddb.501ff74d.k1208; i=johnl%iecc.com@submit.iecc.com; bh=NOmr2RsgdCUKMVZ0BnwQBb9pbj64Bp5I4Gu9GO4WHXQ=; b=vWvZf8Sf6sgsDCO0ZzUNIKxjHmUXmoeOfa8n5FaCaCYXHPb8I1Gu2xdT5fuq8DZIA+YTzLeCraUtN+s/D9NQlrfinIQz97CZGsNWrNN8wA0l6Cx5yQ74L2mUE0Y4QpF4z31t2aFgVR/KFDkwroGv5F5yLOvO8F5QNadducFlNMU=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Received: (ofmipd johnl?iecc.com@68.83.39.18) with (RC4-MD5 encrypted) SMTP; 6 Aug 2012 16:56:23 -0000
Date: 6 Aug 2012 12:56:42 -0400
Message-ID: 
From: "John Levine" 
To: apps-discuss@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Subject: [apps-discuss] (no subject)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 06 Aug 2012 16:56:47 -0000

ClIncyBmcm9tIGEgdGhpbmcgd2l0aCBubyBrZXlib2FyZCwKSm9obg==


From john-ietf@jck.com  Mon Aug  6 10:29:26 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B0811E809A for ; Mon,  6 Aug 2012 10:29:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.582
X-Spam-Level: 
X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLQHQTALH2km for ; Mon,  6 Aug 2012 10:29:25 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 570F011E808A for ; Mon,  6 Aug 2012 10:29:25 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SyR1R-000CEA-8K; Mon, 06 Aug 2012 13:23:17 -0400
Date: Mon, 06 Aug 2012 13:29:09 -0400
From: John C Klensin 
To: Andrew Sullivan , apps-discuss@ietf.org
Message-ID: <7CEBF44F6C114FCE90564ED3@JcK-HP8200.jck.com>
In-Reply-To: <20120806142255.GA53917@mail.yitter.info>
References: <5A4FCAA5BA5F59D02EC64B1C@JCK-EEE10> <20120806142255.GA53917@mail.yitter.info>
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
Subject: Re: [apps-discuss] draft-sullivan-domain-origin-assert-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 06 Aug 2012 17:29:26 -0000

--On Monday, August 06, 2012 10:22 -0400 Andrew Sullivan
 wrote:

> Hi John,
> 
> Thanks for the comments.  A little further discussion inline.
>...

(Material where we seem to agree, at least until the next draft,
elided)

>...
>> More broadly, what you are trying to do here is to overlay an
>> entirely different data structure --really a mesh-- on top of
>> the strict hierarchy (with weak aliases) DNS structure. That
>> mesh is multidimensional with the potential for arrangements
>> by related domain names, by ports, and by scheme/protocol. 
> 
> Yes.  The problem here is that in the first draft on this
> topic I didn't do this, and the response on the w3c web
> security list was that without schemes and ports the entire
> idea was totally useless for their purposes.  I am not sure
> how to reconcile that view with the argument you make, which
> is that we're trying to make statements about who's in charge
> of a name.  Perhaps, however, this is an example of the "too
> many problems" you argue.

Well, I don't quite know what their purpose is.  Certainly I
haven't seen anything that requires distinctions by schemes and
ports in any of the I-Ds on, if you will forgive me, cookie
cutting.  I might have missed one, of course.    But I note
that, if you make distinctions that allow different
ownership/administration for different ports or protocols, it
gets us pretty far into the territory of some non-DNS model,
perhaps even DNS 2.  The DNS is designed around names that are
associated with particular hosts (possibly virtual ones) or, in
the case of SRV and maybe NAPTR, protocols.  Historically, we've
dealt with the problem of a different host serving multiple
functions that have to be dealt with differently by assigning
different names.   One might, for example, have www.example.com,
smtp.example.com, imap.example.com, etc., even if they pointed
to the same interface on the same host (see RFC 2142 for a
discussion of an instance of that approach).

With the DNS, one owns names, not name/port, name/uri-scheme,
etc., objects.  Ownership of names for services implies that one
would need to attach these records to nodes that are otherwise
associated with, e.g., service location (e.g., SRV) records and
service definition (e.g., NAPTR or the sometimes-proposed URI)
records.  If that is what you want to do, the document isn't
clear about it and its implications.  Or you may have a
different model entirely, in which case I'll plead that the
document explain it.]

> The difficulty I have is that the user base for this is really
> just applications, web browsers prominently among them.  If
> their developers say, "Without these other bits, this
> mechanism is no use to me, and I won't implement it," that's a
> strong incentive for me to want to include those other bits.
> Maybe this means that one needs more than one RR, but then
> we're into round trips that web browsers also don't want to
> make.

While I see your point, I think there is risk associated with
changing the DNS architecture from an administrative hierarchy
(in the traditional sense, where entities can take
responsibility for, and manage, their own name spaces and
allocations rather than obtaining them from a superior entity)
to a mesh or even to a flat structure.  The decision in the
early 1980s to design things that way was a conscious choice
(see RFC 819 for some illustrative discussion).  If the intent
had been to develop a new flat structure -- replacing the flat
host table with a database with better scaling properties-- many
decisions would have been made differently.  Given how things
have evolved, we might have been better off.  For example, as we
have discussed several times, the host table supported
operations on aliases that the DNS does not.

So I'm nervous about trying to put records into the DNS whose
purpose is to change the architecture, fundamental relationships
among names, and nature of the names themselves (into bindings
and authority relationships to protocols and URI schemes, not
network objects like hosts).  If we need those sorts of
properties, I think it is probably time for DNSng, not patches
like this that work in some ways but that produce new potential
fir surprises and perhaps even vulnerabilities as side-effects.

If we want to stick with the present DNS and the web needs
something different, it may be time to insert a real overlay
database that is more harmonious with the URI model (including
better provisions for i18n), rather than trying to tweak the DNS
in that direction.

>> If very
>> much of that is used, one could easily end up with a lot of
>> these records at a given node, far exceeding the UDP limit and
>> possibly causing other problems.  Worse, if a node makes an
>> assertion about some set of other nodes and they make
>> contradictory assertions (whether through malice,
>> configuration error, or attempts at cleverness the spec
>> doesn't anticipate),
> 
> Actually, I did think about both of these issues.  Section 7.1
> points out that you can exceed the UDP limits, although it
> doesn't talk about the extent to which that is undesirable
> (frankly, I ran out of time to discuss it at length).  The
> security consideration section notes that you'd be an idiot to
> accept the results if both sides didn't agree, but doesn't go
> further.  I'd be willing to make this stronger, although
> there's at least one case of cookie use where I'm not sure
> about whether it'd be ok not to check both sides.

Yes, I noticed that text.   If we can't get rid of at least most
of the problem, I think you have to address those issues.  In
particular, I think the implicit requirement to access "both
sides" and compare the information needs to be brought out and
discussed, if only because it runs counter to some possible
performance requirements and, if, e.g., different port ranges or
different schemens for a given node can have different owners,
some interesting comparison issues.
 
>...
> The reason that the port ranges and wildcard on the scheme are
> there is exactly so that one can make these records port- and
> scheme-insensitive.  I personally think that's the way it'd
> get used most often anyway, but I'm willing to make the
> protocol a little messier if it causes people who work on web
> browsers to think about it some more.

At least so far, I'm not convinced that it is a better solution
than insisting of different names (DNS nodes) when different
ownership properties are required.
 
>> record that parallels the function and definition of the "DNS
>> administrative authority origin" indication and information
>> provided by the SOA record.  That model fits nicely with the
>> DNS hierarchy (rather than trying to superimpose a new mesh
>> on top of it) -- it just clearly defines the two types of
>> boundaries separate from each other (which they are, of
>> course).
> 
> This was the notion I originally had, yes.  (I didn't call it
> the SOPA record, but one is tempted now that you've introduced
> the "Policy Authority" term.)

I guess my hypothesis is that, if one needs much greater
functionality and distinctions than that, it is either time to
go to a name-per-function architecture (mostly a collection of
administrative decisions) or to [re]start either the DNSng
conversation or the "overlay database with different structural
and search properties" ones.

>> While aspects of the "variant" story are clearly in your mind
> 
> No, or anyway not exactly.  I think the variant story is just
> one facet of exactly the same story over and over again: we
> need to make explicit who has or does not have policy control
> over a given zone. That's the issue with cookies, with
> cross-site problems, and with "variants" too.  I don't think
> they're actually different problems, which is why you think
> I'm trying to solve more than one problem at the same time.

Yes and no.  The thing that makes the variant problem different
is that, in principle, it ultimately involves yet another sort
of authority relationship.  To use a familiar example that ICANN
wants to avoid (but that I don't believe they will be able to
hold the line on if general variants are permitted), suppose
AngloAmerNames goes out and obtains a bunch of spelling
variants: color and colour, harbour and harbor, center and
centre, etc.  Now, while all would have the same owner, at least
initially, "color" has a lot less to do with "centre" than it
does with "colour".  Moreover, unless ICANN or some other
superior registry authority tries to legislate rule they
probably cannot enforce, AngloAmerNames might easily arrange to
have "harbor" and "harbour" delegated to separate parties even
while insisting that the two domains be maintained in a
coordinated way.  That might actually cause policy authority
from a variant standpoint to diverge from policy authority from
an ownership/control one, leading one to need either an even
more complex RRtype or an additional sort of record.

    john



From ned.freed@mrochek.com  Mon Aug  6 14:18:33 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3586411E80F5 for ; Mon,  6 Aug 2012 14:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.53
X-Spam-Level: 
X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=1.069,  BAYES_00=-2.599, GB_I_INVITATION=-2]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtX7FxTQu0Lg for ; Mon,  6 Aug 2012 14:18:32 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7650811E809A for ; Mon,  6 Aug 2012 14:18:32 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIQHIAO5YO0034GG@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 6 Aug 2012 14:13:29 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Mon, 6 Aug 2012 11:25:10 -0700 (PDT)
Message-id: <01OIQBMMCHD80006TF@mauve.mrochek.com>
Date: Mon, 06 Aug 2012 11:10:43 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Sun, 05 Aug 2012 15:29:49 +0000" <20120805152949.84964.qmail@joyce.lan>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <01OIOQIBZOBK0006TF@mauve.mrochek.com> <20120805152949.84964.qmail@joyce.lan>
To: John Levine 
Cc: ned.freed@mrochek.com, apps-discuss@ietf.org
Subject: Re: [apps-discuss] 2006 proposal to add spam score and spam	notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 06 Aug 2012 21:18:33 -0000

> > OTOH, you say they want feedback when users say the filters got it
> > wrong, and if the user is incorrect on that... now you have incorrect
> > feedback informaion.

> The feedback doesn't directly turn into a rule.  Providers treat them with
> considerable scepticsm unless there are either a lot of similar reports,
> or the stuff that's reported has other characteristics of spam.

Which is precisely my point. This entire mechanism is about standardizing a
means of passing information around. It is not about what is done with that
information by any party. It provides a way for a provider to pass an
assessment of the message to a user and a way for a user to pass an assessment
of the message (and indirectly an assessment  of that assessment) back to the
provider. 

It's never been about turning things into rules. Randy's proposed information
flow only talks about the provider updating a database with user-provided
information. You're the one that made that conflation when you said:

    I doubt that any large mail provider would implement anything like
    this.  They definitely want ways for users to report back when they
    think the spam filters got it wrong, but not per-user rules and
    certainly not reporting spam scores.

> > The counterargument is that users like to feel that they are in control.

> That's why you give them a spam button, but you're vague about what it
> does.

Exactly.

> >> Reporting spam scores is mostly an invitation to spammers to use them
> >> to game the filters.  I know that Spamassassin does it, but large mail
> >> systems don't use Spamassassin.
> >
> > As it happens that's also incorrect: Some large providers do in fact use
> > SpamAssassin variants.

> Maybe they do, but I don't recally seeing any handy scores in the
> headers you can use to tune your spam.  Yahoo puts a lot of opaque
> stuff in the headers which I presume includes filtering results, but I
> never heard of anyone reverse engineering it.

> > At most the takeaway I see here is that we need to document how to use
> > specific subsets of the feature set that's provided.

> And make it clear that it's all 100% optional.

I think you mean that you can use one part without another. If you're referring
to the whole thing, since when is anything the IETF does mandatory?

> Plan B: talk to some large providers and see what they might be interested
> in implementing across the board.  I know there's a lot of interest in the
> IMAP spam button if we can sort out the patent issues.

It's definitely important that we cover all the capabilities the providers say
they want. That said, limiting ourselves to specifically what meets a small
sample of providers say they currently need is a bad idea. It's just as
important not to be to specific as it is not to be too general.

As for patent issues, that's part of the reason for basing this on something
that appeared in a 2006 presentation.

				Ned

From sm@elandsys.com  Mon Aug  6 21:23:38 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D127421F85D8 for ; Mon,  6 Aug 2012 21:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.589
X-Spam-Level: 
X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6syGa8SYsPw for ; Mon,  6 Aug 2012 21:23:34 -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 39C4821F8691 for ; Mon,  6 Aug 2012 21:23:34 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.233.150]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q774NFLL015314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 6 Aug 2012 21:23:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1344313407; bh=WjwYFQzkK7Y3JU9ijcsF7S+7NSIfkH5PcMOya1Phyiw=; h=Date:To:From:Subject:Cc; b=jeWyjx+apDNU97REFtSe97UheS/bcC5yfUWc0flFPmP8dxy1gP2lTEhMWTr+6VbGB Y50/NjoIaYE4zoMpgcwNUf9Z/wMSbvEW4SGEHuPyjpnPygU+24teQf8BPo+pERtwli C5mvCfasgzsIFX0UczGDQk63poUWNysfwLHn54Zo=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1344313407; i=@elandsys.com; bh=WjwYFQzkK7Y3JU9ijcsF7S+7NSIfkH5PcMOya1Phyiw=; h=Date:To:From:Subject:Cc; b=W3maRm9IGPy6f0FW1Yt4t8Ln/PWOFAkgppwMvtI3iCWn4moKomBXen1bZhbYWbX28 TSHN3ul2hM+OJQr46hjnN/W0kSVxtK5/u9ixfi1HVNMTdLoVAKy3ekfnX0URC7c+Nv zYlzdDCJ6G0tdH79ZpQmBaRlVV2fvQ0GVJfrIglk=
Message-Id: <6.2.5.6.2.20120806210557.099bd0d8@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 06 Aug 2012 21:18:38 -0700
To: apps-discuss@ietf.org
From: S Moonesamy 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [apps-discuss] Status of draft-ietf-appsawg-about-uri-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Aug 2012 04:23:39 -0000

Hello,

As a FYI, It was pointed out that  has pointed out that the registry 
name, "URI Well-Known Tokens" is confusingly close to "Well-Known 
URIs", which is a different registry.  Once I receive confirmation 
from IANA, I'll make the following changes to 
draft-ietf-appsawg-about-uri-scheme:

NEW:

  2.2.1 Well-Known "about" URIs

    Some s have been reserved as the behavior when the
    resource is referenced as well-known (well-known tokens).

    A well-known "about" URI is a URI that has a well-known token as its
     part.  It is recommended that such URIs be handled in
    accordance with the specification referenced in the "about" URI Tokens
    registry (see Section 5.2).

NEW:

  5.2  A Registry for Well-Known Tokens

      This document creates the '"about" URI Tokens' registry.

Regards,
S. Moonesamy


From sm@elandsys.com  Mon Aug  6 21:32:01 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598A921F86A8 for ; Mon,  6 Aug 2012 21:32:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.589
X-Spam-Level: 
X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSzdB5vPWx-7 for ; Mon,  6 Aug 2012 21:31:57 -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 1D83721F86A2 for ; Mon,  6 Aug 2012 21:31:56 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.233.150]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q774VdtG005565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 6 Aug 2012 21:31:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1344313912; bh=eTIC/qAy8QX3jFI+UD4nD4OzxlbpZa5KFZT2X6E/yds=; h=Date:To:From:Subject:Cc; b=wBSVMLFZqdLVUesonI73IIITSGz+5ymHd4ghv1NrYBUCU7bjdg9H6cWXk4PJh59w5 Ugr4BLS9GmTjz2OR22oy+e/bW/nbyMjoMrIroGk9KKM8V2XmL+m/B4yjVCe/FfbzVT G4P1rcK9J2h2kc95asvEadpSllJdD1K46X3mnP20=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1344313912; i=@elandsys.com; bh=eTIC/qAy8QX3jFI+UD4nD4OzxlbpZa5KFZT2X6E/yds=; h=Date:To:From:Subject:Cc; b=XsktZo6UZT+1pf3mDpBo0eEI2mi4CTvyr5wDVoiQ4CPFqSGsgN+3nzLC7XCpEkVOU 3dGchmhuoXaIAf8JhRMhPozp7fyfjil/47vAzeb/7S4UOcdi7EzyM/T0cZr6s45wVy TuoLHkwL4B8xc+LjTaf45HL6/JeZeIRZTc9uqwl8=
Message-Id: <6.2.5.6.2.20120806212503.080bb7c0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 06 Aug 2012 21:31:35 -0700
To: apps-discuss@ietf.org
From: S Moonesamy 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [apps-discuss] Apps Area Directorate report for July 2012
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Aug 2012 04:32:01 -0000

The Applications Area Directorate provides semi-formal reviews of 
Internet-Drafts as a way to improve the quality of IETF 
specifications.  The directorate consists of the Working Group Chairs 
of the Applications Area and recognized experts in the Applications Area.

The following review were performed in July 2012:

    Reviewer             I-D

   Dave Crocker  draft-ietf-dime-rfc4005bis-09

Regards,
S. Moonesamy
On behalf of the Applications Area Directorate
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate


From alexey.melnikov@isode.com  Mon Aug  6 22:05:03 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B20F21F8647 for ; Mon,  6 Aug 2012 22:05:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.203
X-Spam-Level: 
X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-gToStAOSHd for ; Mon,  6 Aug 2012 22:05:02 -0700 (PDT)
Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFD121F8609 for ; Mon,  6 Aug 2012 22:05:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1344315991; d=isode.com; s=selector; i=@isode.com; bh=Fc7rWWfXIR8uB8nw/BxFsh5vQku0E5KPiQ/k8DucVgY=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=a2tpbybQ5wMs8G2+rL6nGfp6r8fVlM+Wgdvo2D9QsU9q8mpJ9x8W0llTFUccVYOF8qso04 r5qzdrEk3NaGH36mnzwFgvzo1TwWH2vYQUvlmjzJeHJzsqhzAHoAbOg0o2OKyHxA2XkPRM GCv200IzNOyNuYSQHG7psNZ/p0MfPDo=;
Received: from [10.242.16.96] ((unknown) [24.237.158.1])  by waldorf.isode.com (submission channel) via TCP with ESMTPSA  id ; Tue, 7 Aug 2012 06:06:30 +0100
X-SMTP-Protocol-Errors: NORDNS
From: Alexey Melnikov 
X-Mailer: iPad Mail (9B206)
Message-Id: 
Date: Mon, 6 Aug 2012 21:05:16 -0800
To: apps-discuss@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: [apps-discuss] http-forwarded status update
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Aug 2012 05:05:03 -0000

After reviewing status of this document with Murray (who also proxied Barry)=
: the document need a new revision to address IETF LC comments:

1) reverse the change to collect all ABNF in one section. (Barry is Ok with t=
hat).

2) add the text suggested by one of the editors that explains how expert rev=
iew is to be performed.

3) there might have been some changes agreed as per discussion of privacy (u=
nless these were applied earlier). These should be applied.

I think that is it. After that the document can go to IESG review.


From vesely@tana.it  Tue Aug  7 12:09:24 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432A121F87DB for ; Tue,  7 Aug 2012 12:09:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.463
X-Spam-Level: 
X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=-1.044, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MANGLED_SPAM=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTzVSRj+0g8R for ; Tue,  7 Aug 2012 12:09:23 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB9A21F87DA for ; Tue,  7 Aug 2012 12:09:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1344366561; bh=8pKoi5CZVUX1/Y6HXhPBSIC+cGrzB8AONCbTPWsT4Ds=; l=3203; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=jUD4ZxU/mE9d0If57Nb5qTgl7fABj4K3arUqIW2uh1MCMDiMQ8qazc54asg+GZScB idqUnzd1DRr0uxIu2bolxSFtNDjeoTCM+kuVdvXtVSdJI6Ui7FB2KD5ONSZprVneov pfEEj4YdRuXgKf17GsvjJkRVaHLQc+xiq4EtLrKY=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 07 Aug 2012 21:09:21 +0200 id 00000000005DC035.00000000502167E1.00000896
Message-ID: <502167E1.6000000@tana.it>
Date: Tue, 07 Aug 2012 21:09:21 +0200
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <01OIOQIBZOBK0006TF@mauve.mrochek.com> <20120805152949.84964.qmail@joyce.lan> <01OIQBMMCHD80006TF@mauve.mrochek.com>
In-Reply-To: <01OIQBMMCHD80006TF@mauve.mrochek.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] 2006 proposal to add spam score and spam	notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Aug 2012 19:09:24 -0000

On Mon 06/Aug/2012 20:10:43 +0200 Ned Freed wrote:
>>> OTOH, you say they want feedback when users say the filters got
>>> it wrong, and if the user is incorrect on that... now you have
>>> incorrect feedback information.
> 
>> The feedback doesn't directly turn into a rule.  Providers treat
>> them with considerable skepticism unless there are either a lot
>> of similar reports, or the stuff that's reported has other
>> characteristics of spam.
> 
> Which is precisely my point. This entire mechanism is about
> standardizing a means of passing information around. It is not
> about what is done with that information by any party. It provides
> a way for a provider to pass an assessment of the message to a user
> and a way for a user to pass an assessment of the message (and
> indirectly an assessment  of that assessment) back to the 
> provider.

IMHO, a score contains the same amount of information as a random
number unless someone specifies what is done with such number by each
party, or at least how it is generated.  That part of Randy's 2006
proposal differs from the approach taken by the REPUTE WG inasmuch as
the latter considers sender's scores rather than specific message's.

As for Ned's approach to spam reporting, it seems overly deterministic
in attributing a role to each party.  My understanding is that it is
not practical to determine who will want to do what.  The only
certainty is that doing anything implies more work, possibly more than
what an existing abuse team is prepared to tackle...

>> Plan B: talk to some large providers and see what they might be
>> interested in implementing across the board.  I know there's a
>> lot of interest in the IMAP spam button if we can sort out the
>> patent issues.
> 
> It's definitely important that we cover all the capabilities the 
> providers say they want. That said, limiting ourselves to
> specifically what meets a small sample of providers say they
> currently need is a bad idea. It's just as important not to be too
> specific as it is not to be too general.

For the case at hand, Zoltan's I-D stems from the assumption that both
sides of the IMAP connection are part of the same system, which may
not always be the case.  For interoperability, it would be better to
specify only the minimal information necessary to identify the
message, but still allow similar systems to recognize each other and
pass any additional data they may need.

> As for patent issues, that's part of the reason for basing this on
> something that appeared in a 2006 presentation.

The ASRG analysis of the problem, that John summarized in a few lines
http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs#Via_IMAP
is documented to be of February 2010, which is earlier than OMA's
http://datatracker.ietf.org/ipr/1609/.  Moreover, I'm unable to find
anything with APN/163342.  Using (APD/201106$ AND AN/"Research In
Motion Limited") I found a 13/162,703 --resembling IMAP BURL-- that
focuses mainly on the possibility to select a "guilty" attachment in
the message being reported.  That is to say, the covered parts seem to
match the "too specific" cases that Ned suggests we avoid.

From ned.freed@mrochek.com  Tue Aug  7 16:03:32 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF0621F861D for ; Tue,  7 Aug 2012 16:03:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.249
X-Spam-Level: 
X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_50=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7RFr7NxDsiF for ; Tue,  7 Aug 2012 16:03:29 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 38BE721F863B for ; Tue,  7 Aug 2012 16:03:29 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIRZGRS5RK006Y1B@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 7 Aug 2012 15:58:26 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Tue, 7 Aug 2012 15:58:24 -0700 (PDT)
Message-id: <01OIRZGQARHA0006TF@mauve.mrochek.com>
Date: Tue, 07 Aug 2012 15:29:25 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Tue, 07 Aug 2012 21:09:21 +0200" <502167E1.6000000@tana.it>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <01OIOQIBZOBK0006TF@mauve.mrochek.com> <20120805152949.84964.qmail@joyce.lan> <01OIQBMMCHD80006TF@mauve.mrochek.com> <502167E1.6000000@tana.it>
To: Alessandro Vesely 
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] 2006 proposal to add spam score and spam	notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Aug 2012 23:03:32 -0000

> On Mon 06/Aug/2012 20:10:43 +0200 Ned Freed wrote:
> >>> OTOH, you say they want feedback when users say the filters got
> >>> it wrong, and if the user is incorrect on that... now you have
> >>> incorrect feedback information.
> >
> >> The feedback doesn't directly turn into a rule.  Providers treat
> >> them with considerable skepticism unless there are either a lot
> >> of similar reports, or the stuff that's reported has other
> >> characteristics of spam.
> >
> > Which is precisely my point. This entire mechanism is about
> > standardizing a means of passing information around. It is not
> > about what is done with that information by any party. It provides
> > a way for a provider to pass an assessment of the message to a user
> > and a way for a user to pass an assessment of the message (and
> > indirectly an assessment  of that assessment) back to the
> > provider.

> IMHO, a score contains the same amount of information as a random
> number unless someone specifies what is done with such number by each
> party, or at least how it is generated.

Er, no. Sure, scoring information may be meaningless to the recipient - in fact
it may actually be encrypted to insure the recipient can't figure out what's in
it - but it's a little silly to assume it's going to be meaningless to the
system that generated it in the first place, don't you think? The point of
attaching it may be to assist the spam filter in understanding where it went
wrong when a user reports misclassification.

Alternately, the scoring information may be the name of the filtering system
that generated the score. People seem to be assuming service providers all use
a single filtering system. I can assure you that's not the case; many employ
several, and may use them in various different combinations or permutations
based on all sorts of factors. 

Yet another example where this information may be useful is when the user
claims missclassification when in fact it was the user's own rules that caused
the misclassification.

I could go on and list many other use cases, but I think this makes the point. 
There is a strong need to support a fairly general model here.

  That part of Randy's 2006
> proposal differs from the approach taken by the REPUTE WG inasmuch as
> the latter considers sender's scores rather than specific message's.

> As for Ned's approach to spam reporting, it seems overly deterministic
> in attributing a role to each party.

Huh? Since I haven't suggested any sort of approach, this makes no sense to me
at all. What I have suggested is a process by which we might be able to
converge on something that can be codified into a standard. That's it.

Perhaps you're talking about Randy's model. If so, the only thing that is
remotely deterministic about it is the sequence of steps involved, and that
sequence is pretty much necessitated by the order of the underlying operations
that are involved. (It's hard to return feedback on something you don't yet
have, for example.)

Indeed, as I noted above, you're the one who appears to be tying a general
model to very specific and very limited specific cases and then complaining
that it's more general than it needs to be.

> My understanding is that it is
> not practical to determine who will want to do what.  The only
> certainty is that doing anything implies more work, possibly more than
> what an existing abuse team is prepared to tackle...

Again - huh? This again doesn't seem in any way connected to what's being
proposed. You now appear to be assuming that there are necessarily people other
than the recipient involved in processing the information flows here. Not only
is that not called, for, it's actually a nongoal, at least in the sense of
anyone being directly involved. This sort of feedback reporting is intended to
do things like assess provider policy in general and spam filter effectiveness,
possibly including use for filter improvement (or possibly not). It definitely
not intended to go to "Team America - Spam Cops" (*) so they can send in the
SWAT team.

> >> Plan B: talk to some large providers and see what they might be
> >> interested in implementing across the board.  I know there's a
> >> lot of interest in the IMAP spam button if we can sort out the
> >> patent issues.
> >
> > It's definitely important that we cover all the capabilities the
> > providers say they want. That said, limiting ourselves to
> > specifically what meets a small sample of providers say they
> > currently need is a bad idea. It's just as important not to be too
> > specific as it is not to be too general.

> For the case at hand, Zoltan's I-D stems from the assumption that both
> sides of the IMAP connection are part of the same system, which may
> not always be the case.  For interoperability, it would be better to
> specify only the minimal information necessary to identify the
> message, but still allow similar systems to recognize each other and
> pass any additional data they may need.

I agree on the first part - it's one of the many problems I have with his
proposal. But as for the second, I completely disagree, for at least two
reasons: (1) You are again failing to note the closed-loop nature of the model,
which means that not all parties necessarily have to fully understand all of
the information flowing around, and (2) Just because the two sides may not be
part of the same system is no reason to hamstring the case where they *are*
part of the same system.

				Ned

From vesely@tana.it  Wed Aug  8 05:02:11 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A1C21F857D for ; Wed,  8 Aug 2012 05:02:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.292
X-Spam-Level: 
X-Spam-Status: No, score=-4.292 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ijoEhSoQq9R for ; Wed,  8 Aug 2012 05:02:10 -0700 (PDT)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 071EA21F8512 for ; Wed,  8 Aug 2012 05:02:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1344427328; bh=d6rnE1JcjI7HVC811iQ7YvteS11yUGrq2luF716EnJw=; l=4029; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=NnsNz2Nllem9Kiy+b+1WPbsuKSJBz+dZ4wKSOP5lPx3rhF36ThUK833jmnyofTSco AzNsTMSOBtEdm04QZkkE//TtTeKk1LjHXOM62E8sKxceYcZ4qn7bMhblRr4Ky2Qf3z gbnzzKx3fHatlJG5I2nMCEtvuFEonNRpHMGaNBh0=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 08 Aug 2012 14:02:08 +0200 id 00000000005DC035.0000000050225540.000070ED
Message-ID: <5022553F.8060700@tana.it>
Date: Wed, 08 Aug 2012 14:02:07 +0200
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <01OIOQIBZOBK0006TF@mauve.mrochek.com> <20120805152949.84964.qmail@joyce.lan> <01OIQBMMCHD80006TF@mauve.mrochek.com> <502167E1.6000000@tana.it> <01OIRZGQARHA0006TF@mauve.mrochek.com>
In-Reply-To: <01OIRZGQARHA0006TF@mauve.mrochek.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] 2006 proposal to add spam score and spam	notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Aug 2012 12:02:12 -0000

On Wed 08/Aug/2012 00:29:25 +0200 Ned Freed wrote:
> 
>> As for Ned's approach to spam reporting, it seems overly deterministic
>> in attributing a role to each party.
> 
> Huh? Since I haven't suggested any sort of approach, this makes no sense to me
> at all.

I meant the (1), (2), (3) approach described in
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06783.html

> Perhaps you're talking about Randy's model. If so, the only thing that is
> remotely deterministic about it is the sequence of steps involved, and that
> sequence is pretty much necessitated by the order of the underlying operations
> that are involved. (It's hard to return feedback on something you don't yet
> have, for example.)
> 
> Indeed, as I noted above, you're the one who appears to be tying a general
> model to very specific and very limited specific cases and then complaining
> that it's more general than it needs to be.

I'd have used "comprehensive" rather than "general", but I'm not
complaining about that.  For the specific points of the proposal, to
add spam score to POP/IMAP notifications may be useful for some
bandwidth-constrained cases where downloading only the headers is not
practical, but is tactically inadvisable, IMHO.  The proposal's
concept of spam notifications predates RFCs 5965 and 6650, so I
consider only the part of it from the client to the POP/IMAP box,
which is what we seem to be currently missing --"There is, however, no
standard mechanism for this signaling", in the words of RFC 6650.

>> My understanding is that it is not practical to determine who
>> will want to do what.  The only certainty is that doing anything
>> implies more work, possibly more than what an existing abuse team
>> is prepared to tackle...
> 
> Again - huh? This again doesn't seem in any way connected to what's
> being proposed. You now appear to be assuming that there are
> necessarily people other than the recipient involved in processing
> the information flows here.

Yup, since it is a flow, it is legitimate to assume that it involves
more than one actor.  And, yes, I assumed some sort of involvement of
the senders, which implies assessing their honesty, when possible.

> Not only is that not called, for, it's actually a nongoal, at least
> in the sense of anyone being directly involved. This sort of
> feedback reporting is intended to do things like assess provider
> policy in general and spam filter effectiveness, possibly including
> use for filter improvement (or possibly not).

You mean that should remain within the client-ISP bailiwick?

> It definitely not intended to go to "Team America - Spam Cops" (*)
> so they can send in the SWAT team.

:-)

>> For the case at hand, Zoltan's I-D stems from the assumption that both
>> sides of the IMAP connection are part of the same system, which may
>> not always be the case.  For interoperability, it would be better to
>> specify only the minimal information necessary to identify the
>> message, but still allow similar systems to recognize each other and
>> pass any additional data they may need.
> 
> I agree on the first part - it's one of the many problems I have with his
> proposal. But as for the second, I completely disagree, for at least two
> reasons: (1) You are again failing to note the closed-loop nature of the model,
> which means that not all parties necessarily have to fully understand all of
> the information flowing around, and (2) Just because the two sides may not be
> part of the same system is no reason to hamstring the case where they *are*
> part of the same system.

Dunno.  To keep practical, I was thinking of something like SREP UID
123 (KEYWORD BUNCH-OF-DATA)...  where zero or more data sets, each one
formatted according to the relevant keyword, can be sent by the
client.  Servers may respond as appropriate for the keywords they
understand, or may add new keywords+data items in the hope that the
client knows how to interpret them.

From ned.freed@mrochek.com  Wed Aug  8 14:03:41 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1043321F8712 for ; Wed,  8 Aug 2012 14:03:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.23
X-Spam-Level: 
X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=-0.231,  BAYES_00=-2.599, J_CHICKENPOX_84=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dr7QGbqS0aXn for ; Wed,  8 Aug 2012 14:03:40 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 44C7B21F8711 for ; Wed,  8 Aug 2012 14:03:40 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIT9KIB5Q8006DWI@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 8 Aug 2012 13:58:35 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Wed, 8 Aug 2012 13:58:31 -0700 (PDT)
Message-id: <01OIT9KFQFUW0006TF@mauve.mrochek.com>
Date: Wed, 08 Aug 2012 13:51:22 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Wed, 08 Aug 2012 14:02:07 +0200" <5022553F.8060700@tana.it>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <01OIOQIBZOBK0006TF@mauve.mrochek.com> <20120805152949.84964.qmail@joyce.lan> <01OIQBMMCHD80006TF@mauve.mrochek.com> <502167E1.6000000@tana.it> <01OIRZGQARHA0006TF@mauve.mrochek.com> <5022553F.8060700@tana.it>
To: Alessandro Vesely 
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] 2006 proposal to add spam score and spam	notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Aug 2012 21:03:41 -0000

> On Wed 08/Aug/2012 00:29:25 +0200 Ned Freed wrote:
> >
> >> As for Ned's approach to spam reporting, it seems overly deterministic
> >> in attributing a role to each party.
> >
> > Huh? Since I haven't suggested any sort of approach, this makes no sense to me
> > at all.

> I meant the (1), (2), (3) approach described in
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06783.html

Then you need to explain how that *process* proposal has anything to do with
the model that ends up getting selected, because I'm not seeing it.

> > Perhaps you're talking about Randy's model. If so, the only thing that is
> > remotely deterministic about it is the sequence of steps involved, and that
> > sequence is pretty much necessitated by the order of the underlying operations
> > that are involved. (It's hard to return feedback on something you don't yet
> > have, for example.)
> >
> > Indeed, as I noted above, you're the one who appears to be tying a general
> > model to very specific and very limited specific cases and then complaining
> > that it's more general than it needs to be.

> I'd have used "comprehensive" rather than "general", but I'm not
> complaining about that.  For the specific points of the proposal, to
> add spam score to POP/IMAP notifications may be useful for some
> bandwidth-constrained cases where downloading only the headers is not
> practical, but is tactically inadvisable, IMHO.  The proposal's
> concept of spam notifications predates RFCs 5965 and 6650, so I
> consider only the part of it from the client to the POP/IMAP box,
> which is what we seem to be currently missing --"There is, however, no
> standard mechanism for this signaling", in the words of RFC 6650.

Quite the contrary. Right now we have a bunch of pieces, with a few probably
missing, and absolutely no roadmap as to how to put them together to solve
various problems. The result is chaos in the field, as well as no clear
understanding of how to construct the missing pieces, as past discussions
of this area have clearly shown.

> >> My understanding is that it is not practical to determine who
> >> will want to do what.  The only certainty is that doing anything
> >> implies more work, possibly more than what an existing abuse team
> >> is prepared to tackle...
> >
> > Again - huh? This again doesn't seem in any way connected to what's
> > being proposed. You now appear to be assuming that there are
> > necessarily people other than the recipient involved in processing
> > the information flows here.

> Yup, since it is a flow, it is legitimate to assume that it involves
> more than one actor.  And, yes, I assumed some sort of involvement of
> the senders, which implies assessing their honesty, when possible.

Sure, it's legitimate to assume more than one actor is involved, but you're
assuming far more than that: You're assuming a specific sort of actor is
present that is rarely if ever past of these flows in practice.

> > Not only is that not called, for, it's actually a nongoal, at least
> > in the sense of anyone being directly involved. This sort of
> > feedback reporting is intended to do things like assess provider
> > policy in general and spam filter effectiveness, possibly including
> > use for filter improvement (or possibly not).

> You mean that should remain within the client-ISP bailiwick?

No, I never said that.

> > It definitely not intended to go to "Team America - Spam Cops" (*)
> > so they can send in the SWAT team.

> :-)

> >> For the case at hand, Zoltan's I-D stems from the assumption that both
> >> sides of the IMAP connection are part of the same system, which may
> >> not always be the case.  For interoperability, it would be better to
> >> specify only the minimal information necessary to identify the
> >> message, but still allow similar systems to recognize each other and
> >> pass any additional data they may need.
> >
> > I agree on the first part - it's one of the many problems I have with his
> > proposal. But as for the second, I completely disagree, for at least two
> > reasons: (1) You are again failing to note the closed-loop nature of the model,
> > which means that not all parties necessarily have to fully understand all of
> > the information flowing around, and (2) Just because the two sides may not be
> > part of the same system is no reason to hamstring the case where they *are*
> > part of the same system.

> Dunno.  To keep practical, I was thinking of something like SREP UID
> 123 (KEYWORD BUNCH-OF-DATA)...  where zero or more data sets, each one
> formatted according to the relevant keyword, can be sent by the
> client.  Servers may respond as appropriate for the keywords they
> understand, or may add new keywords+data items in the hope that the
> client knows how to interpret them.

And now you're discussing specific mechanism details without any clear
agreement on what we're trying to do. Can't you see that this is a *major*
problem?

				Ned

From vesely@tana.it  Thu Aug  9 00:10:14 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A6B11E8137 for ; Thu,  9 Aug 2012 00:10:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.594
X-Spam-Level: 
X-Spam-Status: No, score=-4.594 tagged_above=-999 required=5 tests=[AWL=0.126,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcvcmHi6moka for ; Thu,  9 Aug 2012 00:10:13 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D742211E8124 for ; Thu,  9 Aug 2012 00:10:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1344496210; bh=qDxvK1bAeX1A0hWaTzbdnzD9qBCsjqr+sBjQN3hFmnI=; l=2100; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=H4mIEwvFXFRz7CM1hT9ispkEFrPO1Eb0WLMEgUJ+Ch+hsYsGonazKIPNLZRrkeiE4 8LplwaQyP+ZelUUEqAGUNb6NlxrrKv2dOiIV/AA8AnFH7A025YuswOvO+yb+FjtjLC 5bzxFWnK2Umj7UZd9w5hRQSkJ0tvQKkVaOwbAPUI=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 09 Aug 2012 09:10:10 +0200 id 00000000005DC039.0000000050236252.0000766D
Message-ID: <50236253.1040305@tana.it>
Date: Thu, 09 Aug 2012 09:10:11 +0200
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <01OIOQIBZOBK0006TF@mauve.mrochek.com> <20120805152949.84964.qmail@joyce.lan> <01OIQBMMCHD80006TF@mauve.mrochek.com> <502167E1.6000000@tana.it> <01OIRZGQARHA0006TF@mauve.mrochek.com> <5022553F.8060700@tana.it> <01OIT9KFQFUW0006TF@mauve.mrochek.com>
In-Reply-To: <01OIT9KFQFUW0006TF@mauve.mrochek.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] 2006 proposal to add spam score and spam	notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 07:10:14 -0000

On Wed 08/Aug/2012 22:51:22 +0200 Ned Freed wrote:
>> I meant the (1), (2), (3) approach described in
>> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06783.html
> 
> Then you need to explain how that *process* proposal has anything
> to do with the model that ends up getting selected, because I'm not
> seeing it.

Step (1) requires to formalize a model.  AIUI, this would be an
overall model for spam reporting, possibly including a distributed
system to reckon domain reputation.  Its definition implies outlining
a collective process whereby a network-wide understanding of senders
behavior emerges.  An astounding, fascinating exercise.  But that's
not the kind of model you had in mind, is it?

> Right now we have a bunch of pieces, with a few probably missing,
> and absolutely no roadmap as to how to put them together to solve 
> various problems. The result is chaos in the field, as well as no
> clear understanding of how to construct the missing pieces, as past
> discussions of this area have clearly shown.

Nicely said, I agree on that.  However, some of those pieces might
solve some specific problem, and there is a possibility that they gain
some momentum.

>> To keep practical, I was thinking of [... specific mechanism
>> details elided ...]
> 
> And now you're discussing specific mechanism details without any
> clear agreement on what we're trying to do. Can't you see that this
> is a *major* problem?

I see that, but I don't think there are better ways to do it.  Each
"piece" has to be vital by itself, and gain momentum.  Specific
mechanisms may fail irrespectively of the role that we could have
agreed they would have played in the global model.  In that case, they
are forgotten.  The model itself may turn out to be unworkable without
them.  Hence, steps (1), (2), and (3) risk to be carried out in vain.
 OTOH, guessed right, successful mechanisms can form the groundwork
that further pieces will be based upon, in an apparently chaotic,
self-driven becoming.

IMAP SREP is a very small piece.  The smaller the better?


From ned.freed@mrochek.com  Thu Aug  9 15:21:54 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D75A21F86FE for ; Thu,  9 Aug 2012 15:21:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.544
X-Spam-Level: 
X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhS-L8nL19Bq for ; Thu,  9 Aug 2012 15:21:53 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id CBC2221F86D3 for ; Thu,  9 Aug 2012 15:21:52 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIUQLUQJKW006YAR@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 9 Aug 2012 15:16:49 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Thu, 9 Aug 2012 15:16:46 -0700 (PDT)
Message-id: <01OIUQLSNCQS0006TF@mauve.mrochek.com>
Date: Thu, 09 Aug 2012 15:07:54 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Thu, 09 Aug 2012 09:10:11 +0200" <50236253.1040305@tana.it>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <01OIOQIBZOBK0006TF@mauve.mrochek.com> <20120805152949.84964.qmail@joyce.lan> <01OIQBMMCHD80006TF@mauve.mrochek.com> <502167E1.6000000@tana.it> <01OIRZGQARHA0006TF@mauve.mrochek.com> <5022553F.8060700@tana.it> <01OIT9KFQFUW0006TF@mauve.mrochek.com> <50236253.1040305@tana.it>
To: Alessandro Vesely 
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] 2006 proposal to add spam score and spam	notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 22:21:54 -0000

> On Wed 08/Aug/2012 22:51:22 +0200 Ned Freed wrote:
> >> I meant the (1), (2), (3) approach described in
> >> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06783.html
> >
> > Then you need to explain how that *process* proposal has anything
> > to do with the model that ends up getting selected, because I'm not
> > seeing it.

> Step (1) requires to formalize a model.  AIUI, this would be an
> overall model for spam reporting, possibly including a distributed
> system to reckon domain reputation.

Where did I say anything like that? In fact I have repeatedly said the exact
opposite: Any model we come up with needs to be able to support a wide variety
of possible use cases and specific reporting designs. This includes, but
is not limited to, cases where there is no information flowing from the
provider to the client, no information flowing from the client to the provider,
where the information is binary in nature, where the information is
numeric, where the information is labels or tags, where some of the information
is opaque to some of the parties.

> Its definition implies outlining
> a collective process whereby a network-wide understanding of senders
> behavior emerges. 

It implies no such thing. In fact the main thing it implies is trying to
prevent people with one specific approach in mind from limiting the model to
supporting that approach and nothing else. 

> An astounding, fascinating exercise.  But that's
> not the kind of model you had in mind, is it?

Of course not.

> > Right now we have a bunch of pieces, with a few probably missing,
> > and absolutely no roadmap as to how to put them together to solve
> > various problems. The result is chaos in the field, as well as no
> > clear understanding of how to construct the missing pieces, as past
> > discussions of this area have clearly shown.

> Nicely said, I agree on that.  However, some of those pieces might
> solve some specific problem, and there is a possibility that they gain
> some momentum.

Exactly! It helps to get people on the same page in regards to mechanism,
if nothing else.

> >> To keep practical, I was thinking of [... specific mechanism
> >> details elided ...]
> >
> > And now you're discussing specific mechanism details without any
> > clear agreement on what we're trying to do. Can't you see that this
> > is a *major* problem?

> I see that, but I don't think there are better ways to do it.  Each
> "piece" has to be vital by itself, and gain momentum.  Specific
> mechanisms may fail irrespectively of the role that we could have
> agreed they would have played in the global model.  In that case, they
> are forgotten.  The model itself may turn out to be unworkable without
> them.  Hence, steps (1), (2), and (3) risk to be carried out in vain.
>  OTOH, guessed right, successful mechanisms can form the groundwork
> that further pieces will be based upon, in an apparently chaotic,
> self-driven becoming.

> IMAP SREP is a very small piece.  The smaller the better?

But what if it turns out to the *wrong* piece? (As it happens I think there's a
very high probability of that being the case.) That's why starting with a
specific piece in mind is a bad idea: You're assuming a solution then trying
to find problems that fit it.

				Ned

From vesely@tana.it  Fri Aug 10 03:08:15 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4385B21F8666 for ; Fri, 10 Aug 2012 03:08:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.596
X-Spam-Level: 
X-Spam-Status: No, score=-4.596 tagged_above=-999 required=5 tests=[AWL=0.123,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mE14LDWUNCsa for ; Fri, 10 Aug 2012 03:08:14 -0700 (PDT)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3428B21F863B for ; Fri, 10 Aug 2012 03:08:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1344593292; bh=VWy8mLeWHk670CtkVqDGhgPnZvz8q1Jsyg7MPszh/WU=; l=3818; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=S9XDGugLdFcYDbrRTTCAxv/3wToFLyoI+HcW1qI1mfaRhyuPCseIlRjfuPujC2WGD rH5ILdCpE8hL9pgfo/PZ8z44XU+SrJ9O2bb7z2jte64vQiTPiYqDi6MULp3etXsnKg +lpvMt3VAzMrAimEj09/87q3F5HGR1uCsISP0R2E=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 10 Aug 2012 12:08:12 +0200 id 00000000005DC039.000000005024DD8C.00006223
Message-ID: <5024DD8C.5060200@tana.it>
Date: Fri, 10 Aug 2012 12:08:12 +0200
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <01OIOQIBZOBK0006TF@mauve.mrochek.com> <20120805152949.84964.qmail@joyce.lan> <01OIQBMMCHD80006TF@mauve.mrochek.com> <502167E1.6000000@tana.it> <01OIRZGQARHA0006TF@mauve.mrochek.com> <5022553F.8060700@tana.it> <01OIT9KFQFUW0006TF@mauve.mrochek.com> <50236253.1040305@tana.it> <01OIUQLSNCQS0006TF@mauve.mrochek.com>
In-Reply-To: <01OIUQLSNCQS0006TF@mauve.mrochek.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] 2006 proposal to add spam score and spam	notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Aug 2012 10:08:15 -0000

On Fri 10/Aug/2012 00:07:54 +0200 Ned Freed wrote:
>>>> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06783.html
> 
>> Step (1) requires to formalize a model.  AIUI, this would be an
>> overall model for spam reporting, possibly including a distributed
>> system to reckon domain reputation.
> 
> Where did I say anything like that? In fact I have repeatedly said
> the exact opposite: Any model we come up with needs to be able to
> support a wide variety of possible use cases and specific reporting
> designs.

I guess I may have erroneously inferred something that you didn't
mean.  The OP attached slides about spam control for (mobile) clients,
presenting an overview of spam and anti-spam techniques.  Obviously,
everyone of us has his own version of such an overall model in his
mind.  I thought you referred to such thing.  A minor part of that
model concerns users signaling spam/non-spam labels to the provider
responsible for accepting messages on their behalf.  This latter part
can --and must-- be focused much more sharply.

> This includes, but is not limited to, cases where there is no
> information flowing from the provider to the client, no information
> flowing from the client to the provider, where the information is
> binary in nature, where the information is numeric, where the
> information is labels or tags, where some of the information is
> opaque to some of the parties.

Hm... I'm unable to figure out a real use case for about a half of the
characterizations you exemplify.  For example, "no information flowing
from the client to the provider"...?

> In fact the main thing [modeling] implies is trying to prevent
> people with one specific approach in mind from limiting the model
> to supporting that approach and nothing else.

What I assume is a client tagging a message.  It doesn't seem to be
limiting to me.  What am I missing?

>> IMAP SREP is a very small piece.  The smaller the better?
> 
> But what if it turns out to the *wrong* piece? (As it happens I
> think there's a very high probability of that being the case.)

I'd like to know why you think so.

> That's why starting with a specific piece in mind is a bad idea:
> You're assuming a solution then trying to find problems that fit
> it.

Some (all?) IMAP servers have the functionality, either native or by
means of unofficial patches, to track moves or flag settings in order
to infer the user's reckoning of spamminess.  So, problems that fit
this piece can be found easily.

The solution is a mechanism for reporting the (perceived) worthiness
of a message back to who (presumably) accepted it.  Its model
identifies the mailbox provider with the SMTP admin, and requires a
different mechanism for each type of message store.  Here we do IMAP.

Why a new command?  Using the "junk" folder badly overloads its usage.
 Flags are intrinsically boolean, so that one would need to
standardize keyword templates in order to account for extensibility.
In both cases, handlers need to get deeply involved in the internal
mechanics of the IMAP server, while their semantics concerns the SMTP
server.  The new command entails the execution of a site-specific
program/function for all and only invocations, with suitable parameter
passing conventions.  So, it seems to provide for better
implementations, code re-usability, data encapsulation, low coupling,
and so forth...

I realize I'm still having in mind that specific use case, and
discussing specific mechanism details.  I cannot avoid it, because the
wrongness of a piece cannot be ascertained from its model --well,
providing it's self-consistent-- but needs to refer to the overall
model that we talked about upthread.  Or is there some
intermediate-level model that we should refer to?

From ned.freed@mrochek.com  Fri Aug 10 07:53:02 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CF321F84F7 for ; Fri, 10 Aug 2012 07:53:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.545
X-Spam-Level: 
X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgXfPQPp53bS for ; Fri, 10 Aug 2012 07:53:02 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id EF2BD21F85E6 for ; Fri, 10 Aug 2012 07:53:00 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIVP7KZ180007E8Z@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 10 Aug 2012 07:47:52 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Fri, 10 Aug 2012 07:47:50 -0700 (PDT)
Message-id: <01OIVP7JIF6Q0006TF@mauve.mrochek.com>
Date: Fri, 10 Aug 2012 07:40:17 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Fri, 10 Aug 2012 12:08:12 +0200" <5024DD8C.5060200@tana.it>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <01OIOQIBZOBK0006TF@mauve.mrochek.com> <20120805152949.84964.qmail@joyce.lan> <01OIQBMMCHD80006TF@mauve.mrochek.com> <502167E1.6000000@tana.it> <01OIRZGQARHA0006TF@mauve.mrochek.com> <5022553F.8060700@tana.it> <01OIT9KFQFUW0006TF@mauve.mrochek.com> <50236253.1040305@tana.it> <01OIUQLSNCQS0006TF@mauve.mrochek.com> <5024DD8C.5060200@tana.it>
To: Alessandro Vesely 
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] 2006 proposal to add spam score and spam	notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Aug 2012 14:53:03 -0000

> On Fri 10/Aug/2012 00:07:54 +0200 Ned Freed wrote:
> >>>> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06783.html
> >
> >> Step (1) requires to formalize a model.  AIUI, this would be an
> >> overall model for spam reporting, possibly including a distributed
> >> system to reckon domain reputation.
> >
> > Where did I say anything like that? In fact I have repeatedly said
> > the exact opposite: Any model we come up with needs to be able to
> > support a wide variety of possible use cases and specific reporting
> > designs.

> I guess I may have erroneously inferred something that you didn't
> mean.  The OP attached slides about spam control for (mobile) clients,
> presenting an overview of spam and anti-spam techniques.

Yes, but the reason for using the figure from that document as a starting point
is because it may help avoid some patent issues. Not because we intend to
slavishly support the rest of it to the exclusion of  other use cases.

> Obviously,
> everyone of us has his own version of such an overall model in his
> mind.  I thought you referred to such thing.  A minor part of that
> model concerns users signaling spam/non-spam labels to the provider
> responsible for accepting messages on their behalf.  This latter part
> can --and must-- be focused much more sharply.

> > This includes, but is not limited to, cases where there is no
> > information flowing from the provider to the client, no information
> > flowing from the client to the provider, where the information is
> > binary in nature, where the information is numeric, where the
> > information is labels or tags, where some of the information is
> > opaque to some of the parties.

> Hm... I'm unable to figure out a real use case for about a half of the
> characterizations you exemplify.  For example, "no information flowing
> from the client to the provider"...?

It is far and away the most common case implemented today. Surely
the most common case is relevant?

> > In fact the main thing [modeling] implies is trying to prevent
> > people with one specific approach in mind from limiting the model
> > to supporting that approach and nothing else.

> What I assume is a client tagging a message.  It doesn't seem to be
> limiting to me.  What am I missing?

You *really* need to go back and reread the last discussion we had 
on this, which almost immediately bogged down in all sorts of competing
proposals because everyone had a different specific use case in mind.

That's why we need to agree on a general model first. And that model needs to
include cases where the specific piece *you* happen to be interested in isn't
needed.

> >> IMAP SREP is a very small piece.  The smaller the better?
> >
> > But what if it turns out to the *wrong* piece? (As it happens I
> > think there's a very high probability of that being the case.)

> I'd like to know why you think so.

Patent issues. Deployment issues - why add commands when it may be possible to
do what is needed using existing capabilities? Poor design of the actual
command.

That's just a start.

But at this point you're starting to get into the actual design of the
mechanism, and that's a game I refuse to play.

				Ned

From vesely@tana.it  Fri Aug 10 12:35:35 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F08D21F8692 for ; Fri, 10 Aug 2012 12:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.598
X-Spam-Level: 
X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=0.121,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3qTFc3yCvIl for ; Fri, 10 Aug 2012 12:35:34 -0700 (PDT)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E110911E809A for ; Fri, 10 Aug 2012 12:35:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1344627332; bh=wMMp8laAlSM2vs8whFupr8OfStnBZlk+4UmTp0nwRfM=; l=5127; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=dRkuxfyFi2puhhijY4PMmjWlQawqSQM+2wex7o6ddV5MNzbC3bNkIMCbph8mZEqnT 75ae9cTy1gR7BKavHtOgetJmzhMiMB6T52JZqXlap0KWh5HgOmb42W8Dw/RG5QxQRN 9of4z9C4s1+MCnpyfZo00hoaxMatZZvQZcCuwNA8=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 10 Aug 2012 21:35:31 +0200 id 00000000005DC035.0000000050256283.000064AA
Message-ID: <50256283.1060608@tana.it>
Date: Fri, 10 Aug 2012 21:35:31 +0200
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <01OIOQIBZOBK0006TF@mauve.mrochek.com> <20120805152949.84964.qmail@joyce.lan> <01OIQBMMCHD80006TF@mauve.mrochek.com> <502167E1.6000000@tana.it> <01OIRZGQARHA0006TF@mauve.mrochek.com> <5022553F.8060700@tana.it> <01OIT9KFQFUW0006TF@mauve.mrochek.com> <50236253.1040305@tana.it> <01OIUQLSNCQS0006TF@mauve.mrochek.com> <5024DD8C.5060200@tana.it> <01OIVP7JIF6Q0006TF@mauve.mrochek.com>
In-Reply-To: <01OIVP7JIF6Q0006TF@mauve.mrochek.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] 2006 proposal to add spam score and spam	notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Aug 2012 19:35:35 -0000

On Fri 10/Aug/2012 16:40:17 +0200 Ned Freed wrote:
> 
>>> This includes, but is not limited to, cases where there is no
>>> information flowing from the provider to the client, no information
>>> flowing from the client to the provider, where the information is
>>> binary in nature, where the information is numeric, where the
>>> information is labels or tags, where some of the information is
>>> opaque to some of the parties.
> 
>> Hm... I'm unable to figure out a real use case for about a half of the
>> characterizations you exemplify.  For example, "no information flowing
>> from the client to the provider"...?
> 
> It is far and away the most common case implemented today. Surely
> the most common case is relevant?

I still can't see it.  How can a signal carry no information?  I'd
call it noise, in that case.

>> What am I missing?
> 
> You *really* need to go back and reread the last discussion we had
>  on this, which almost immediately bogged down in all sorts of
> competing proposals because everyone had a different specific use
> case in mind.

You must mean the "Call for Adoption" thread that Murray started on
May 12.  The relevant points I found are as follows:

John Levine and Dave Crocker said they think a single flag is enough
to retain the relevant one bit of information on the message status.
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05742.html
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05759.html

You said that it's not as flexible as a general reporting mechanism.
For example, it couldn't be used to report things like signature
validation failures.  You also noted there's at least two bits
associated with spamitude, and raised some doubts against using IMAP
as a gateway.
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05748.html
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05757.html
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05737.html

Cyrus said we already have $Junk and $NotJunk.
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05753.html

A prior thread on this topic, "Spam reporting over IMAP", was started
on January 9, also by Murray.  There are relevant architectural
objections:

Lyndon said IMAP is absolutely the wrong place to put spam reporting.
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04058.html

John Klensin questioned whether there is a strong enough case to be
made that this belongs in IMAP to justify further clutter in the
protocol, and whether it would be helpful to graft something of this
nature onto a SIEVE server.
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04107.html
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04055.html

I have omitted all administrative concerns.  Of the technical ones, I
only reported those that apparently conflict with the solution I have
tried to uphold upthread.

> That's why we need to agree on a general model first. And that
> model needs to include cases where the specific piece *you* happen
> to be interested in isn't needed.

Let me slightly reshape the proposal as a *storage gateway*.  We can
have the same command, with minimal syntax variations, provide a
gateway for IMAP and POP3.  Yes, that's after all what you've said
against gateways.  My only excuse for doing so is that BURL is not so
widely supported in IMAP and not at all in POP3.  The very purpose of
the command is to provide a sort of out-of-band channel from clients
to the server admins:  Reporting a message.  Reporting spam is the use
case at hand.

IMHO, this is simpler and easier than BURL and/or some additional
functionality designed around it.  For POP3, clients have to delay
DELE until they deem the user won't report on a given message, while
server-side development is exactly the same.

For both protocols, the command identifies an existing item in the
message store (by UIDL, UID, or whatever).  The command fails if the
message doesn't exist.  The command accepts an extensible set of
parameters about the message, beside its identification.  The server
does not have to understand any of those parameters, as its task is to
just pass them, along with the reported message, to a system-specific
configured script or executable.  The response that the latter returns
is to be gatewayed back to the client.  Again, neither the server nor
the client have to understand anything about the response, but they
may do so.

Could that be agreed upon?  I think it gets over most of the above
concerns.

>> I'd like to know why you think [there's a very high probability
>> of IMAP SREP being the *wrong* piece].
> 
> Patent issues.

Covered stuff goes in separately specified extensions.  BTW, the
reason I asked to remove the "kleansed" I-D was because of copyright
issues, not patent ones.

> Deployment issues - why add commands when it may be possible to do
> what is needed using existing capabilities? Poor design of the
> actual command.

Does the reshaped proposal address those concerns?

From ned.freed@mrochek.com  Fri Aug 10 13:40:21 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEA121F86EE for ; Fri, 10 Aug 2012 13:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.547
X-Spam-Level: 
X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tq718EJFXYYP for ; Fri, 10 Aug 2012 13:40:21 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0B04311E808E for ; Fri, 10 Aug 2012 13:40:21 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIW1CBN940006XBL@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 10 Aug 2012 13:35:17 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Fri, 10 Aug 2012 13:35:15 -0700 (PDT)
Message-id: <01OIW1CACE820006TF@mauve.mrochek.com>
Date: Fri, 10 Aug 2012 13:22:51 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Fri, 10 Aug 2012 21:35:31 +0200" <50256283.1060608@tana.it>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <01OIOQIBZOBK0006TF@mauve.mrochek.com> <20120805152949.84964.qmail@joyce.lan> <01OIQBMMCHD80006TF@mauve.mrochek.com> <502167E1.6000000@tana.it> <01OIRZGQARHA0006TF@mauve.mrochek.com> <5022553F.8060700@tana.it> <01OIT9KFQFUW0006TF@mauve.mrochek.com> <50236253.1040305@tana.it> <01OIUQLSNCQS0006TF@mauve.mrochek.com> <5024DD8C.5060200@tana.it> <01OIVP7JIF6Q0006TF@mauve.mrochek.com> <50256283.1060608@tana.it>
To: Alessandro Vesely 
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] 2006 proposal to add spam score and spam	notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Aug 2012 20:40:21 -0000

> On Fri 10/Aug/2012 16:40:17 +0200 Ned Freed wrote:
> >
> >>> This includes, but is not limited to, cases where there is no
> >>> information flowing from the provider to the client, no information
> >>> flowing from the client to the provider, where the information is
> >>> binary in nature, where the information is numeric, where the
> >>> information is labels or tags, where some of the information is
> >>> opaque to some of the parties.
> >
> >> Hm... I'm unable to figure out a real use case for about a half of the
> >> characterizations you exemplify.  For example, "no information flowing
> >> from the client to the provider"...?
> >
> > It is far and away the most common case implemented today. Surely
> > the most common case is relevant?

> I still can't see it.  How can a signal carry no information?  I'd
> call it noise, in that case.

I't called "leaving out one component of the model while leaving other pieces
in place".

Failure to recognize that not everyone will implement (or is interested in
implementing) the whole thing will lead to folks saying, "This is all or
nothing and all doesn't fit our needs, so let's ignore it in toto." And then
things don't interoperate. This was precisely John Levine's point in an earlier
message, and I agree with it.

> >> What am I missing?
> >
> > You *really* need to go back and reread the last discussion we had
> >  on this, which almost immediately bogged down in all sorts of
> > competing proposals because everyone had a different specific use
> > case in mind.

> You must mean the "Call for Adoption" thread that Murray started on
> May 12.  The relevant points I found are as follows:

Relevant points? None of the content of that thread is relevant in the
slightest. The only relevant point is that different people have different
use cases in mind and there is no agreement on a general model, so consensus
could not be reached.

> A prior thread on this topic, "Spam reporting over IMAP", was started
> on January 9, also by Murray.  There are relevant architectural
> objections:

And there were several other threads before that. Same result.

Aren't you seeing a pattern here? this is a political issue, not a technnical
issue. You don't solve political issues with piecemeal technical proposals.

> > That's why we need to agree on a general model first. And that
> > model needs to include cases where the specific piece *you* happen
> > to be interested in isn't needed.

The rest of your message is al about specifics of the technical proposal.
I've already stated that I have zero interest in discussing this at this 
point.

				Ned

From internet-drafts@ietf.org  Sat Aug 11 13:27:21 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9600921F861F; Sat, 11 Aug 2012 13:27:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYHPQ8l-tEZU; Sat, 11 Aug 2012 13:27:21 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17BF21F8608; Sat, 11 Aug 2012 13:27:20 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.33
Message-ID: <20120811202720.21235.50478.idtracker@ietfa.amsl.com>
Date: Sat, 11 Aug 2012 13:27:20 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-03.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 20:27:21 -0000

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

	Title           : JSON Pointer
	Author(s)       : Paul C. Bryan
                          Kris Zyp
                          Mark Nottingham
	Filename        : draft-ietf-appsawg-json-pointer-03.txt
	Pages           : 8
	Date            : 2012-08-11

Abstract:
   JSON Pointer defines a string syntax for identifying a specific value
   within a JSON document.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-pointer-03


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


From mnot@mnot.net  Sat Aug 11 13:28:36 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E1D21F8617 for ; Sat, 11 Aug 2012 13:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.154
X-Spam-Level: 
X-Spam-Status: No, score=-105.154 tagged_above=-999 required=5 tests=[AWL=-2.555, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIMhtQEl+kLs for ; Sat, 11 Aug 2012 13:28:35 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id A36FE21F85FC for ; Sat, 11 Aug 2012 13:28:35 -0700 (PDT)
Received: from [10.6.128.62] (unknown [50.56.228.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4916E22E259 for ; Sat, 11 Aug 2012 16:28:29 -0400 (EDT)
From: Mark Nottingham 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <1808B83D-0B03-46BF-98B1-82C85E9321D1@mnot.net>
Date: Sat, 11 Aug 2012 15:28:28 -0500
To: "apps-discuss@ietf.org Discuss" 
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\))
X-Mailer: Apple Mail (2.1485)
Subject: [apps-discuss] JSON Pointer status
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 20:28:36 -0000

We talked about JSON Pointer in Vancouver, as well as previously on the =
list.=20

I've incorporated all of the feedback received to date, and published =
the result as -03 =
. =
See below for discussion of specific issues.

I *think* we're pretty close to being ready for WGLC; I want to have a =
fresh look through for editorial issues, but otherwise it seems pretty =
stable. Feedback / thoughts welcome (as always).


#1	json-pointer: Internationalization

This was already incorporated in the drafts when I started editing; =
closing.


#2	json-pointer: Ambiguous array references

This has been discussed on-list, as well as in Vancouver. I didn't see =
any strong objection to leaving it as is, and some persuasive arguments =
as to why it should remain the same (particularly, that needing that =
kind of notation is an unnecessary artefact of thinking from a static =
language standpoint).=20

So, I think this can be closed, and will do so unless we hear strong =
objections.


#3	json-pointer: Escaping and percent encoding

The ~ approach was discussed on-list and in Vancouver, and feedback =
seems good. Closing.


#4	json-pointer: Minor feedback

Addressed; closing.


#5	json-pointer: Application semantics

Incorporated; can be closed.


#6	json-pointer: Need more examples

Incorporated; can be closed.


#10: Fragment Identifiers

There seems to be agreement that we shouldn't define the media type =
syntax for application/json in this document, and so I've clarified the =
draft to say that it's only for other media types that explicitly =
reference this document.

--
Mark Nottingham
http://www.mnot.net/





From mnot@mnot.net  Sat Aug 11 13:41:56 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872E521F8622 for ; Sat, 11 Aug 2012 13:41:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.032
X-Spam-Level: 
X-Spam-Status: No, score=-105.032 tagged_above=-999 required=5 tests=[AWL=-2.433, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cG1CItqgGesH for ; Sat, 11 Aug 2012 13:41:56 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9347121F85A5 for ; Sat, 11 Aug 2012 13:41:55 -0700 (PDT)
Received: from [10.6.128.62] (unknown [50.56.228.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2670622E1EB for ; Sat, 11 Aug 2012 16:41:42 -0400 (EDT)
From: Mark Nottingham 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <626C1365-F8C8-49F2-8B72-62698314FDA9@mnot.net>
Date: Sat, 11 Aug 2012 15:41:41 -0500
To: "apps-discuss@ietf.org Discuss" 
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\))
X-Mailer: Apple Mail (2.1485)
Subject: [apps-discuss] JSON Patch issues
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 20:41:56 -0000

As with Pointer, JSON Patch has been discussed both on-list and in =
Vancouver.

See below for the current disposition of its issues. I'll close the ones =
that are resolved shortly.


#7	json-patch: "test" operation

We agreed in Vancouver that we needed some implementer experience to =
determine this one.


#8	json-patch: Name semantics ("locations")

Resolution already incorporated.


#9	json-patch: "move" no-op discussion

Resolution already incorporated.


#11	Testing objects

This is a (relatively) new one, and I'll be incorporating a resolution =
shortly (it's pretty straightforward; we don't want to enforce ordering =
on objects).


--
Mark Nottingham
http://www.mnot.net/





From mnot@mnot.net  Sat Aug 11 15:21:39 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510F521F8530 for ; Sat, 11 Aug 2012 15:21:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaSJdlSI5Iim for ; Sat, 11 Aug 2012 15:21:38 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 4E20E21F852E for ; Sat, 11 Aug 2012 15:21:38 -0700 (PDT)
Received: from [192.168.35.51] (unknown [66.140.241.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 53CA850A65 for ; Sat, 11 Aug 2012 18:21:31 -0400 (EDT)
From: Mark Nottingham 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
Date: Sat, 11 Aug 2012 17:21:30 -0500
To: "apps-discuss@ietf.org Discuss" 
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\))
X-Mailer: Apple Mail (2.1485)
Subject: [apps-discuss] JSON-Patch: testing objects [#11]
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 22:21:39 -0000

I've checked in some text that tries to address #11, and ended =
clarifying other parts about how "test" works.

Proposed text:

---8<---
4.6.  test

   The "test" operation tests that a value at the specified location in
   the target document is equal to a specified value.  The operation
   object contains a "value" member that specifies the value to test
   for.

   Here, "equal" means that the target and specified values are compared
   using the following rules:

   o  strings: are considered equal if, after unescaping any sequence(s)
      in either string starting with a reverse solidus, they contain the
      same number of Unicode characters and their code points are
      position-wise equal.

   o  numbers: are considered equal if they subtracting one from the
      other results in 0.

   o  arrays: are considered equal if they contain the same number of
      values, and each value can be considered equal to the value at the
      corresponding position in the other array.

   o  objects: are considered equal if they contain the same number of
      members, and each member can be considered equal to a member in
      the other object.  Note that ordering of the serialisation of
      object members is not significant.

   o  literals (false, true and null): are considered equal if they are
      the same.

   Note that this is a logical comparison; e.g., whitespace between the
   member values of an array is not significant.
--->8---

This is obviously going to need some examples (particularly around =
comparing numbers and strings, I think), but I wanted to make sure =
people were OK with this direction first.

In particular, does escaping strings before comparison make sense? And, =
is the technique for comparing numbers adequate?

Regards,


--
Mark Nottingham
http://www.mnot.net/





From vesely@tana.it  Mon Aug 13 03:07:01 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBE221F85D2 for ; Mon, 13 Aug 2012 03:07:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.604
X-Spam-Level: 
X-Spam-Status: No, score=-4.604 tagged_above=-999 required=5 tests=[AWL=0.115,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZRDV3QDBLww for ; Mon, 13 Aug 2012 03:07:00 -0700 (PDT)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8306A21F86B1 for ; Mon, 13 Aug 2012 03:07:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1344852419; bh=mPDRfErGzf+SpMYlfGAROeQpoI6RC1lyjmA2DeKX7cI=; l=1663; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=FFZIXzeeKwpSDllKPKYuMiEoVcLrFG1B8Nz8jm4Si+Af+xWBYNuVnsFxelBVioK15 jGzK5DgHsEvfFhpKodnCm8+1BAyqKk8rGeihGBvAS9U4H2hIeMF9j+yA3VrfItHbLs RhiD2epBdGFq6fGac8t40FHs/yXlpl0EMDtOPbLM=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 13 Aug 2012 12:06:59 +0200 id 00000000005DC039.000000005028D1C3.00001697
Message-ID: <5028D1C2.7040009@tana.it>
Date: Mon, 13 Aug 2012 12:06:58 +0200
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <01OIOQIBZOBK0006TF@mauve.mrochek.com> <20120805152949.84964.qmail@joyce.lan> <01OIQBMMCHD80006TF@mauve.mrochek.com> <502167E1.6000000@tana.it> <01OIRZGQARHA0006TF@mauve.mrochek.com> <5022553F.8060700@tana.it> <01OIT9KFQFUW0006TF@mauve.mrochek.com> <50236253.1040305@tana.it> <01OIUQLSNCQS0006TF@mauve.mrochek.com> <5024DD8C.5060200@tana.it> <01OIVP7JIF6Q0006TF@mauve.mrochek.com> <50256283.1060608@tana.it> <01OIW1CACE820006TF@mauve.mrochek.com>
In-Reply-To: <01OIW1CACE820006TF@mauve.mrochek.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] 2006 proposal to add spam score and spam	notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 10:07:01 -0000

On Fri 10/Aug/2012 22:22:51 +0200 Ned Freed wrote:
> 
>>>> What am I missing?
>>>
>>> You *really* need to go back and reread the last discussion we
>>> had on this, which almost immediately bogged down in all sorts
>>> of competing proposals because everyone had a different
>>> specific use case in mind.
> 
>> You must mean the "Call for Adoption" thread that Murray started
>> on May 12.  The relevant points I found are as follows:
> 
> Relevant points? None of the content of that thread is relevant in
> the slightest. The only relevant point is that different people
> have different use cases in mind and there is no agreement on a
> general model, so consensus could not be reached.
> 
>> A prior thread on this topic, "Spam reporting over IMAP", was
>> started on January 9, also by Murray.  There are relevant
>> architectural objections:
> 
> And there were several other threads before that. Same result.
> 
> Aren't you seeing a pattern here? this is a political issue, not a
> technical issue. You don't solve political issues with piecemeal
> technical proposals.

I'm unclear on what you mean by "political".  It may be an inter-SDO
issue, either with this particular liaison[*] or with OMA in general,
or you may mean a generic acceptation of "political" as a component
that makes people unwieldily nervous and irrational, as it often
happens with anti-spam related topics.  In any case, technical
documents are the only practical thing that we may come out with,
however piecemeal.

It'd be nice if this thread concludes saying something workable about
the subject.

[*] https://datatracker.ietf.org/liaison/1090/

From internet-drafts@ietf.org  Mon Aug 13 05:25:50 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C66021F870A; Mon, 13 Aug 2012 05:25:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.352
X-Spam-Level: 
X-Spam-Status: No, score=-102.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfna-e8+5QM5; Mon, 13 Aug 2012 05:25:49 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACFA21F8565; Mon, 13 Aug 2012 05:25:49 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.33
Message-ID: <20120813122549.1172.25200.idtracker@ietfa.amsl.com>
Date: Mon, 13 Aug 2012 05:25:49 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-http-forwarded-07.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 12:25:50 -0000

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

	Title           : Forwarded HTTP Extension
	Author(s)       : Andreas Petersson
                          Martin Nilsson
	Filename        : draft-ietf-appsawg-http-forwarded-07.txt
	Pages           : 18
	Date            : 2012-08-13

Abstract:
   This document standardizes an HTTP extension header field that allows
   proxy components to disclose information lost in the proxying
   process, for example, the originating IP address of a request or IP
   address of the proxy on the user-agent-facing interface.  Given a
   trusted path of proxying components, this makes it possible to
   arrange it so that each subsequent component will have access to, for
   example, all IP addresses used in the chain of proxied HTTP requests.

   This document also specifies guidelines for a proxy administrator to
   anonymize the origin of a request.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-http-forwarded-07


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


From ned.freed@mrochek.com  Mon Aug 13 08:29:25 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FF421F86DF for ; Mon, 13 Aug 2012 08:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.547
X-Spam-Level: 
X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAKjNHZ3pvoe for ; Mon, 13 Aug 2012 08:29:23 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id A436D21F870E for ; Mon, 13 Aug 2012 08:29:20 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIZXCOE9N4006S49@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 13 Aug 2012 08:24:12 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIXJBO9M4W0006TF@mauve.mrochek.com>; Mon, 13 Aug 2012 08:24:10 -0700 (PDT)
Message-id: <01OIZXCN5GYA0006TF@mauve.mrochek.com>
Date: Mon, 13 Aug 2012 08:08:29 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 13 Aug 2012 12:06:58 +0200" <5028D1C2.7040009@tana.it>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <01OIOQIBZOBK0006TF@mauve.mrochek.com> <20120805152949.84964.qmail@joyce.lan> <01OIQBMMCHD80006TF@mauve.mrochek.com> <502167E1.6000000@tana.it> <01OIRZGQARHA0006TF@mauve.mrochek.com> <5022553F.8060700@tana.it> <01OIT9KFQFUW0006TF@mauve.mrochek.com> <50236253.1040305@tana.it> <01OIUQLSNCQS0006TF@mauve.mrochek.com> <5024DD8C.5060200@tana.it> <01OIVP7JIF6Q0006TF@mauve.mrochek.com> <50256283.1060608@tana.it> <01OIW1CACE820006TF@mauve.mrochek.com> <5028D1C2.7040009@tana.it>
To: Alessandro Vesely 
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] 2006 proposal to add spam score and spam	notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 15:29:25 -0000

> On Fri 10/Aug/2012 22:22:51 +0200 Ned Freed wrote:
> >
> >>>> What am I missing?
> >>>
> >>> You *really* need to go back and reread the last discussion we
> >>> had on this, which almost immediately bogged down in all sorts
> >>> of competing proposals because everyone had a different
> >>> specific use case in mind.
> >
> >> You must mean the "Call for Adoption" thread that Murray started
> >> on May 12.  The relevant points I found are as follows:
> >
> > Relevant points? None of the content of that thread is relevant in
> > the slightest. The only relevant point is that different people
> > have different use cases in mind and there is no agreement on a
> > general model, so consensus could not be reached.
> >
> >> A prior thread on this topic, "Spam reporting over IMAP", was
> >> started on January 9, also by Murray.  There are relevant
> >> architectural objections:
> >
> > And there were several other threads before that. Same result.
> >
> > Aren't you seeing a pattern here? this is a political issue, not a
> > technical issue. You don't solve political issues with piecemeal
> > technical proposals.

> I'm unclear on what you mean by "political".  It may be an inter-SDO
> issue, either with this particular liaison[*] or with OMA in general,
> or you may mean a generic acceptation of "political" as a component
> that makes people unwieldily nervous and irrational, as it often
> happens with anti-spam related topics.

Why does it have to be any one of these? Does it help to try and nail this
sort of thing down? I seriously doubt it. What matters is making forward
progress.

> In any case, technical
> documents are the only practical thing that we may come out with,
> however piecemeal.

Of course.

> It'd be nice if this thread concludes saying something workable about
> the subject.

I've already put forward a proposal as to how I think we should proceed.

What I've heard from you are mostly comments that boil down to saying that we
should repeat the same exercise that's failed multiple times in the past, along
with several attempts to start that exercise. I think your proposed approach is
extremely unlikely to produce a useful result, and I have explained why.

John Levine started out with some incorrect assumptions about the result I want
to see from the process, which then morphed into the important point that any
proposal has to be clear that not all use cases will employ all components
the general model supports.

And Barry has stated that we need to "work closely with MAAWG" to develop the
model, which I take as agreement that we need to have a model in place first.

As far as MAAWG goes, that's fine with me as long as it doesn't translate into
waiting for input that never arrives. (Given how the recent media types
exercise unfolded, I won't be particularly happy with that outcome.) I hope
that contact with MAAWG has already been made, but I've heard nothing one way
or the other about that.

				Ned

From johnl@iecc.com  Mon Aug 13 12:39:31 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03C221F8639 for ; Mon, 13 Aug 2012 12:39:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.155
X-Spam-Level: 
X-Spam-Status: No, score=-111.155 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+Exlq9VqQYM for ; Mon, 13 Aug 2012 12:39:31 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB8C21F8643 for ; Mon, 13 Aug 2012 12:39:29 -0700 (PDT)
Received: (qmail 88488 invoked from network); 13 Aug 2012 19:39:26 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Aug 2012 19:39:26 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=502957ed.xn--3zv.k1208; i=johnl@user.iecc.com; bh=4A2+7GiYUhTm7bfLzZ7hcxOcw0Bm8ur2VSh2TUmAAjw=; b=cXp9h2hLPcpVlKB0oQgoiyE620AnBHKPNwLlO7u/Q2uu4/2MpaSD9Sb8UC7ps65QyVE62O2zX5GCW3/82sFbCnQnfV3pUs6vAQYL8JGfIlPMe6pIkb2v+RUZq44+ZMKas0pR4d2agubRnCgUZ1xL7rNgMg7WJ/48/ufZ7tOpMK8=
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=502957ed.xn--3zv.k1208; olt=johnl@user.iecc.com; bh=4A2+7GiYUhTm7bfLzZ7hcxOcw0Bm8ur2VSh2TUmAAjw=; b=YwrbrYuntzaohoddglutsjKhkhonhfKG/Q94PU00m8PDCe8HAWwWnMG8EBlq+qNzEFfCuNFAzcuVSj7ELtTPEdyKybGacc9mZglSmH72lsTUf+UD4PuS2qJfGQkWdBkLhvCjvgkqepcpGPiFwdIcMKP2UkayPTOJqmPO/SOwFwc=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 13 Aug 2012 19:39:03 -0000
Message-ID: <20120813193903.66153.qmail@joyce.lan>
From: "John Levine" 
To: apps-discuss@ietf.org
In-Reply-To: <01OIZXCN5GYA0006TF@mauve.mrochek.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
Cc: ned.freed@mrochek.com
Subject: Re: [apps-discuss] 2006 proposal to add spam score and spam notification to email
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 19:39:31 -0000

>exercise unfolded, I won't be particularly happy with that outcome.) I hope
>that contact with MAAWG has already been made, but I've heard nothing one way
>or the other about that.

Since Dave Crocker and I are two of MAAWG's senior technical advisors,
I wouldn't worry too much.

MAAWG does relatively more at meetings and less in e-mail than the
IETF, so I expect there won't be much to say until the Baltimore
meeting in October.  I'll see if I can grab a session for ISP
brainstorming about what sorts of user spam reporting hooks they'd be
interested in standardizing.

R's,
John

From wwwrun@rfc-editor.org  Mon Aug 13 17:47:17 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9F221F8691; Mon, 13 Aug 2012 17:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.3
X-Spam-Level: 
X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-ccq3Zio7wd; Mon, 13 Aug 2012 17:47:16 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id A8E6321F8686; Mon, 13 Aug 2012 17:47:16 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 0FB9FB1E002; Mon, 13 Aug 2012 17:45:54 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20120814004554.0FB9FB1E002@rfc-editor.org>
Date: Mon, 13 Aug 2012 17:45:54 -0700 (PDT)
Cc: apps-discuss@ietf.org, rfc-editor@rfc-editor.org
Subject: [apps-discuss] RFC 6694 on The "about" URI Scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 00:47:17 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6694

        Title:      The "about" URI Scheme 
        Author:     S. Moonesamy, Ed.
        Status:     Informational
        Stream:     IETF
        Date:       August 2012
        Mailbox:    sm+ietf@elandsys.com
        Pages:      7
        Characters: 11604
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-appsawg-about-uri-scheme-07.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6694.txt

This document describes the "about" URI scheme, which is widely used by Web
browsers and some other applications to designate access to their internal
resources, such as settings, application information, hidden built-in
functionality, and so on.  This document is not an Internet Standards Track 
specification; it is published for informational purposes.

This document is a product of the Applications Area Working Group Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://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 alexey.melnikov@isode.com  Tue Aug 14 02:59:07 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92AB221F86C2 for ; Tue, 14 Aug 2012 02:59:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.884
X-Spam-Level: 
X-Spam-Status: No, score=-102.884 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYUSNhM-HBz2 for ; Tue, 14 Aug 2012 02:59:07 -0700 (PDT)
Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id CBDB021F869E for ; Tue, 14 Aug 2012 02:59:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1344938345; d=isode.com; s=selector; i=@isode.com; bh=q3IzS9/l+Gc7rUrzv/vIMAOEE33Kp+mYN5KOWyPNBng=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ags2AdQPYCvj1oNd02joCTIWwKJfSgh+5+LVIGHtWfyHimdLwisoUzvRd0pMhNu1/OZY0L EaPryO2h2eijnHXWb9bI+qGK/+QPYpY4Vgik6HZv1YlWoci74f5Ds71mYU3M+0BQ8UuF3F mtNRLoDxAA3J4FYsdLmv5L7l3f50FV8=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250])  by waldorf.isode.com (submission channel) via TCP with ESMTPSA  id ; Tue, 14 Aug 2012 10:59:04 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <502A21A2.8060106@isode.com>
Date: Tue, 14 Aug 2012 11:00:02 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: "apps-discuss@ietf.org" 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] Bilated issue with draft-ietf-appsawg-media-type-suffix-regs-02.txt: fragment identifier rules
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 09:59:07 -0000

Sorry for not reporting this earlier, but after rereading the latest 
version the following bothers me:

>  For cases defined in +json, where the
>  fragment identifier resolves per the +json
>  rules, then as specified in +json.
>
>  For cases defined in +json, where the
>  fragment identifier does not resolve per
>  the +json rules, then as specified in "xxx/
>  yyy+json".
>
>  For cases not defined in +json, then as
>  specified in "xxx/yyy+json".

(And similar text for other registrations).

So, let's imagine the following sequence of events:

1) +json registered with no special rules for handling fragment identifiers.

2) later on "xxx/yyy+json" is registered that defines some special rules 
for handling fragment identifiers.

3) +json registration is updated to add some generic rules for handling 
fragment identifiers. If fragment identifier rules for "xxx/yyy+json" 
are in conflict with the new generic +json rules, implementors might get 
confused which rules apply.

Is this likely? Is this something that needs to be explicitly pointed out?


From pbryan@anode.ca  Tue Aug 14 11:28:36 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5509B21F876A for ; Tue, 14 Aug 2012 11:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFw35vgPBDEO for ; Tue, 14 Aug 2012 11:28:35 -0700 (PDT)
Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 61B6621F86B5 for ; Tue, 14 Aug 2012 11:28:35 -0700 (PDT)
Received: from [10.126.22.47] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 8C0436156 for ; Tue, 14 Aug 2012 18:28:34 +0000 (UTC)
From: "Paul C. Bryan" 
To: "apps-discuss@ietf.org Discuss" 
In-Reply-To: 
References: 
Content-Type: multipart/alternative; boundary="=-Lm1Wp4+1TLLjW5XdyuwP"
Date: Tue, 14 Aug 2012 11:28:25 -0700
Message-ID: <1344968905.26501.10.camel@pbryan-wsl.internal.salesforce.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Subject: Re: [apps-discuss] JSON-Patch: testing objects [#11]
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 18:28:36 -0000

--=-Lm1Wp4+1TLLjW5XdyuwP
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On Sat, 2012-08-11 at 17:21 -0500, Mark Nottingham wrote:

> I've checked in some text that tries to address #11, and ended clarifying other parts about how "test" works.
> 
> Proposed text:
> 
> ---8<---
> 4.6.  test
> 
>    The "test" operation tests that a value at the specified location in
>    the target document is equal to a specified value.  The operation
>    object contains a "value" member that specifies the value to test
>    for.
> 
>    Here, "equal" means that the target and specified values are compared
>    using the following rules:


Possibly point-out that both values must have the same type in order to
evaluate to equal? In other words, 0 the number and "0" the string are
not equal.


>    o  strings: are considered equal if, after unescaping any sequence(s)
>       in either string starting with a reverse solidus, they contain the
>       same number of Unicode characters and their code points are
>       position-wise equal.


s/either/both/. Logically makes sense.


>    o  numbers: are considered equal if they subtracting one from the
>       other results in 0.


s/they //. Logically, makes sense.


>    o  arrays: are considered equal if they contain the same number of
>       values, and each value can be considered equal to the value at the
>       corresponding position in the other array.
> 
>    o  objects: are considered equal if they contain the same number of
>       members, and each member can be considered equal to a member in
>       the other object.  Note that ordering of the serialisation of
>       object members is not significant.


I would point out that member equality means that the key == key
(string) and value == value (both values must be of same type and
evaluate equally per this section).


> 
>    o  literals (false, true and null): are considered equal if they are
>       the same.
> 
>    Note that this is a logical comparison; e.g., whitespace between the
>    member values of an array is not significant.
> --->8---
> 
> This is obviously going to need some examples (particularly around comparing numbers and strings, I think), but I wanted to make sure people were OK with this direction first.
> 
> In particular, does escaping strings before comparison make sense? And, is the technique for comparing numbers adequate?
> 
> Regards,
> 
> 
> --
> Mark Nottingham
> http://www.mnot.net/
> 
> 
> 
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss



--=-Lm1Wp4+1TLLjW5XdyuwP
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


On Sat, 2012-08-11 at 17:21 -0500, Mark Nottingham wrote:



I've checked in some text that tries to address #11, and ended clarifying other parts about how "test" works.

Proposed text:

---8<---
4.6.  test

   The "test" operation tests that a value at the specified location in
   the target document is equal to a specified value.  The operation
   object contains a "value" member that specifies the value to test
   for.

   Here, "equal" means that the target and specified values are compared
   using the following rules:






Possibly point-out that both values must have the same type in order to evaluate to equal? In other words, 0 the number and "0" the string are not equal.






   o  strings: are considered equal if, after unescaping any sequence(s)
      in either string starting with a reverse solidus, they contain the
      same number of Unicode characters and their code points are
      position-wise equal.






s/either/both/. Logically makes sense.






   o  numbers: are considered equal if they subtracting one from the
      other results in 0.






s/they //. Logically, makes sense.






   o  arrays: are considered equal if they contain the same number of
      values, and each value can be considered equal to the value at the
      corresponding position in the other array.

   o  objects: are considered equal if they contain the same number of
      members, and each member can be considered equal to a member in
      the other object.  Note that ordering of the serialisation of
      object members is not significant.






I would point out that member equality means that the key == key (string) and value == value (both values must be of same type and evaluate equally per this section).







   o  literals (false, true and null): are considered equal if they are
      the same.

   Note that this is a logical comparison; e.g., whitespace between the
   member values of an array is not significant.
--->8---

This is obviously going to need some examples (particularly around comparing numbers and strings, I think), but I wanted to make sure people were OK with this direction first.

In particular, does escaping strings before comparison make sense? And, is the technique for comparing numbers adequate?

Regards,


--
Mark Nottingham
http://www.mnot.net/




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









--=-Lm1Wp4+1TLLjW5XdyuwP--


From internet-drafts@ietf.org  Tue Aug 14 21:50:16 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D2E21E80EE; Tue, 14 Aug 2012 21:50:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.416
X-Spam-Level: 
X-Spam-Status: No, score=-102.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNQv-DhXATq5; Tue, 14 Aug 2012 21:50:15 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAA721E80BD; Tue, 14 Aug 2012 21:50:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.33
Message-ID: <20120815045014.15799.54712.idtracker@ietfa.amsl.com>
Date: Tue, 14 Aug 2012 21:50:14 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 04:50:16 -0000

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

	Title           : The 'acct' URI Scheme
	Author(s)       : Peter Saint-Andre
	Filename        : draft-ietf-appsawg-acct-uri-00.txt
	Pages           : 7
	Date            : 2012-08-14

Abstract:
   This document defines the 'acct' URI scheme as a way to identify a
   user's account at a service provider, irrespective of the particular
   protocols that can be used to interact with the account.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-00


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


From GK@ninebynine.org  Wed Aug 15 02:54:04 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B9921F8759 for ; Wed, 15 Aug 2012 02:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.694
X-Spam-Level: 
X-Spam-Status: No, score=-6.694 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5V7wURsn9uqN for ; Wed, 15 Aug 2012 02:54:04 -0700 (PDT)
Received: from relay3.mail.ox.ac.uk (relay3.mail.ox.ac.uk [163.1.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 127BD21F8738 for ; Wed, 15 Aug 2012 02:54:03 -0700 (PDT)
Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay3.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1T1aIc-00013j-9u for apps-discuss@ietf.org; Wed, 15 Aug 2012 10:54:02 +0100
Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1T1aIc-0006xy-6S for apps-discuss@ietf.org; Wed, 15 Aug 2012 10:54:02 +0100
Message-ID: <502B7037.4020901@ninebynine.org>
Date: Wed, 15 Aug 2012 10:47:35 +0100
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Subject: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 09:54:04 -0000

ref: http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-00

I'm uneasy about:

[[
4.4.  URI Scheme Semantics

    The 'acct' URI scheme is used to identify user accounts hosted at
    service providers.  It is used only for identification, not
    interaction.  A protocol that uses the 'acct' URI scheme is
    responsible for specifying how an 'acct' URI is to be dereferenced in
    the context of that protocol.  There is no media type associated with
    the 'acct' URI scheme.
]]

Specifically, the bit about "protocol that uses the acct URI scheme".

My understanding was that the intent was that acct: would be dereferenced using 
the WebFinger protocol.  If there is no such expectation, then an acct: URI 
appearing in isolation (e.g. in a web page or some document) has no actionable 
meaning.

For me, this was a key argument for acct: to be a URI scheme rather than a URN 
namespace.

#g

From mnot@mnot.net  Wed Aug 15 21:17:57 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC26321E8055 for ; Wed, 15 Aug 2012 21:17:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0e0eBQE1LrIa for ; Wed, 15 Aug 2012 21:17:56 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 66E1C21E804A for ; Wed, 15 Aug 2012 21:17:54 -0700 (PDT)
Received: from [192.168.160.86] (unknown [12.172.25.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 32D1350A64; Thu, 16 Aug 2012 00:17:46 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\))
From: Mark Nottingham 
In-Reply-To: <1344968905.26501.10.camel@pbryan-wsl.internal.salesforce.com>
Date: Wed, 15 Aug 2012 21:17:43 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <1344968905.26501.10.camel@pbryan-wsl.internal.salesforce.com>
To: Paul C. Bryan 
X-Mailer: Apple Mail (2.1485)
Cc: "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] JSON-Patch: testing objects [#11]
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 04:17:58 -0000

Thanks, all looks reasonable; will update.

On 14/08/2012, at 11:28 AM, Paul C. Bryan  wrote:

> On Sat, 2012-08-11 at 17:21 -0500, Mark Nottingham wrote:
>> I've checked in some text that tries to address #11, and ended =
clarifying other parts about how "test" works.
>>=20
>> Proposed text:
>>=20
>> ---8<---
>> 4.6.  test
>>=20
>>    The "test" operation tests that a value at the specified location =
in
>>    the target document is equal to a specified value.  The operation
>>    object contains a "value" member that specifies the value to test
>>    for.
>>=20
>>    Here, "equal" means that the target and specified values are =
compared
>>    using the following rules:
>>=20
>=20
> Possibly point-out that both values must have the same type in order =
to evaluate to equal? In other words, 0 the number and "0" the string =
are not equal.
>=20
>>    o  strings: are considered equal if, after unescaping any =
sequence(s)
>>       in either string starting with a reverse solidus, they contain =
the
>>       same number of Unicode characters and their code points are
>>       position-wise equal.
>>=20
>=20
> s/either/both/. Logically makes sense.
>=20
>>    o  numbers: are considered equal if they subtracting one from the
>>       other results in 0.
>>=20
>=20
> s/they //. Logically, makes sense.
>=20
>>    o  arrays: are considered equal if they contain the same number of
>>       values, and each value can be considered equal to the value at =
the
>>       corresponding position in the other array.
>>=20
>>    o  objects: are considered equal if they contain the same number =
of
>>       members, and each member can be considered equal to a member in
>>       the other object.  Note that ordering of the serialisation of
>>       object members is not significant.
>>=20
>=20
> I would point out that member equality means that the key =3D=3D key =
(string) and value =3D=3D value (both values must be of same type and =
evaluate equally per this section).
>=20
>>=20
>>    o  literals (false, true and null): are considered equal if they =
are
>>       the same.
>>=20
>>    Note that this is a logical comparison; e.g., whitespace between =
the
>>    member values of an array is not significant.
>> --->8---
>>=20
>> This is obviously going to need some examples (particularly around =
comparing numbers and strings, I think), but I wanted to make sure =
people were OK with this direction first.
>>=20
>> In particular, does escaping strings before comparison make sense? =
And, is the technique for comparing numbers adequate?
>>=20
>> Regards,
>>=20
>>=20
>> --
>> Mark Nottingham
>>=20
>> http://www.mnot.net/
>>=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> apps-discuss mailing list
>>=20
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham
http://www.mnot.net/





From tony@att.com  Thu Aug 16 05:48:50 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DED21F85E4 for ; Thu, 16 Aug 2012 05:48:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.556
X-Spam-Level: 
X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm3ww3yrluDn for ; Thu, 16 Aug 2012 05:48:49 -0700 (PDT)
Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 8D23921F85D5 for ; Thu, 16 Aug 2012 05:48:49 -0700 (PDT)
Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 13cec205.0.815425.00-333.2195665.nbfkord-smmo07.seg.att.com (envelope-from );  Thu, 16 Aug 2012 12:48:49 +0000 (UTC)
X-MXL-Hash: 502cec316f65b726-534d24c4c374c221135bd49eeac50ac149b7e0a8
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7GCmmIX024283 for ; Thu, 16 Aug 2012 08:48:48 -0400
Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7GCmgcC024238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Aug 2012 08:48:44 -0400
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Thu, 16 Aug 2012 08:48:37 -0400
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q7GCmYUS018208 for ; Thu, 16 Aug 2012 08:48:35 -0400
Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q7GCmWMn018165 for ; Thu, 16 Aug 2012 08:48:34 -0400
Received: from [135.70.11.43] (vpn-135-70-11-43.vpn.west.att.com[135.70.11.43]) by maillennium.att.com (mailgw1) with ESMTP id <20120816124346gw100ssp0qe> (Authid: tony); Thu, 16 Aug 2012 12:43:47 +0000
X-Originating-IP: [135.70.11.43]
Message-ID: <502CEC1D.3010301@att.com>
Date: Thu, 16 Aug 2012 08:48:29 -0400
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
References: <502A21A2.8060106@isode.com>
In-Reply-To: <502A21A2.8060106@isode.com>
Content-Type: multipart/alternative; boundary="------------070903010705040303030501"
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.20.145]
X-AnalysisOut: [v=1.0 c=1 a=mvRNmGF13VMA:10 a=70aWqWLk7fkA:10 a=1wm54zsoFk]
X-AnalysisOut: [4A:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8]
X-AnalysisOut: [UMqPvVAA==:17 a=uK1Tnq2Ewn5QVjPTSEwA:9 a=wPNLvfGTeEIA:10 a]
X-AnalysisOut: [=APQWWo9-AAAA:8 a=lqBfltr7q6lCC0exG9kA:9 a=_W_S_7VecoQA:10]
X-AnalysisOut: [ a=cat5K2ZOYqEA:10]
Subject: Re: [apps-discuss] Bilated issue with draft-ietf-appsawg-media-type-suffix-regs-02.txt: fragment identifier rules
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 12:48:50 -0000

This is a multi-part message in MIME format.
--------------070903010705040303030501
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 8/14/2012 6:00 AM, Alexey Melnikov wrote:
> (And similar text for other registrations).
>
> So, let's imagine the following sequence of events:
>
> 1) +json registered with no special rules for handling fragment 
> identifiers.
>
> 2) later on "xxx/yyy+json" is registered that defines some special 
> rules for handling fragment identifiers.
>
> 3) +json registration is updated to add some generic rules for 
> handling fragment identifiers. If fragment identifier rules for 
> "xxx/yyy+json" are in conflict with the new generic +json rules, 
> implementors might get confused which rules apply.
>
> Is this likely? Is this something that needs to be explicitly pointed 
> out?

Isn't this covered by the ordering specified here:

     The syntax and semantics for fragment identifiers for a specific 
"xxx/yyy+json"
     SHOULD be processed as follows:

         For cases defined in +json, where the fragment identifier 
resolves per the +json
         rules, then as specified in +json.

         For cases defined in +json, where the fragment identifier does 
not resolve per
         the +json rules, then as specified in "xxx/yyy+json".

         For cases not defined in +json, then as specified in 
"xxx/yyy+json".

The same ordering is used in all of the examples, and no one has 
commented on that ordering.

     Tony Hansen



--------------070903010705040303030501
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
    
  
  
    On 8/14/2012 6:00 AM, Alexey Melnikov wrote:

    
(And
      similar text for other registrations).
      

      

      So, let's imagine the following sequence of events:
      

      

      1) +json registered with no special rules for handling fragment
      identifiers.
      

      

      2) later on "xxx/yyy+json" is registered that defines some special
      rules for handling fragment identifiers.
      

      

      3) +json registration is updated to add some generic rules for
      handling fragment identifiers. If fragment identifier rules for
      "xxx/yyy+json" are in conflict with the new generic +json rules,
      implementors might get confused which rules apply.
      

      

      Is this likely? Is this something that needs to be explicitly
      pointed out?
      

    

    

    Isn't this covered by the ordering specified here: 

    

        The syntax and semantics for fragment identifiers for a specific
    "xxx/yyy+json" 

        SHOULD be processed as follows: 

    

            For cases defined in +json, where the fragment identifier
    resolves per the +json 

            rules, then as specified in +json. 

    

            For cases defined in +json, where the fragment identifier
    does not resolve per 

            the +json rules, then as specified in "xxx/yyy+json". 

    

            For cases not defined in +json, then as specified in
    "xxx/yyy+json". 

    

    The same ordering is used in all of the examples, and no one has
    commented on that ordering. 

    

        Tony Hansen

    

    

    

      

    

  


--------------070903010705040303030501--

From alexey.melnikov@isode.com  Thu Aug 16 05:56:35 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79ED21F85D5 for ; Thu, 16 Aug 2012 05:56:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.875
X-Spam-Level: 
X-Spam-Status: No, score=-102.875 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34yGMJ33lHo0 for ; Thu, 16 Aug 2012 05:56:35 -0700 (PDT)
Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id A60C021F8594 for ; Thu, 16 Aug 2012 05:56:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1345121793; d=isode.com; s=selector; i=@isode.com; bh=78SGyjQ74KejAhbp1ENSAW4RWyb2ZmIq/l7akhvzB/E=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=b6xJo/4ufhkM7YvQe7eTYm8cD/+DtQspXXAAW9+m3UCjLQJcC2umG2XNNAruUiUV4reGBT Kj0YbawATxeU1AsCTlPdyzTzutEF/L2EF3BbS2XjZxXBk8myg6mbv0CuGfYxeLozKnd2zC vRD4xJBatwp2+EYhor5jEaYR2qaGUuc=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250])  by waldorf.isode.com (submission channel) via TCP with ESMTPSA  id ; Thu, 16 Aug 2012 13:56:33 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <502CEE3C.3010107@isode.com>
Date: Thu, 16 Aug 2012 13:57:32 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: Tony Hansen 
References: <502A21A2.8060106@isode.com> <502CEC1D.3010301@att.com>
In-Reply-To: <502CEC1D.3010301@att.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------060600000608080200000808"
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Bilated issue with draft-ietf-appsawg-media-type-suffix-regs-02.txt: fragment identifier rules
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 12:56:35 -0000

This is a multi-part message in MIME format.
--------------060600000608080200000808
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 16/08/2012 13:48, Tony Hansen wrote:
> On 8/14/2012 6:00 AM, Alexey Melnikov wrote:
>> (And similar text for other registrations).
>>
>> So, let's imagine the following sequence of events:
>>
>> 1) +json registered with no special rules for handling fragment 
>> identifiers.
>>
>> 2) later on "xxx/yyy+json" is registered that defines some special 
>> rules for handling fragment identifiers.
>>
>> 3) +json registration is updated to add some generic rules for 
>> handling fragment identifiers. If fragment identifier rules for 
>> "xxx/yyy+json" are in conflict with the new generic +json rules, 
>> implementors might get confused which rules apply.
>>
>> Is this likely? Is this something that needs to be explicitly pointed 
>> out?
>
> Isn't this covered by the ordering specified here:

The text has prescribed ordering, yes. But my point is that your rules 
allow an updated +foo registration to retrospectively update fragment 
rules on all previously registered xxx/yyy+foo. I don't think this is right.

>     The syntax and semantics for fragment identifiers for a specific 
> "xxx/yyy+json"
>     SHOULD be processed as follows:
>
>         For cases defined in +json, where the fragment identifier 
> resolves per the +json
>         rules, then as specified in +json.
>
>         For cases defined in +json, where the fragment identifier does 
> not resolve per
>         the +json rules, then as specified in "xxx/yyy+json".
>
>         For cases not defined in +json, then as specified in 
> "xxx/yyy+json".
>
> The same ordering is used in all of the examples, and no one has 
> commented on that ordering.


--------------060600000608080200000808
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 16/08/2012 13:48, Tony Hansen wrote:

    

    

      
      
      On 8/14/2012 6:00 AM, Alexey Melnikov wrote:

      
(And
        similar text for other registrations). 

        

        So, let's imagine the following sequence of events: 

        

        1) +json registered with no special rules for handling fragment
        identifiers. 

        

        2) later on "xxx/yyy+json" is registered that defines some
        special rules for handling fragment identifiers. 

        

        3) +json registration is updated to add some generic rules for
        handling fragment identifiers. If fragment identifier rules for
        "xxx/yyy+json" are in conflict with the new generic +json rules,
        implementors might get confused which rules apply. 

        

        Is this likely? Is this something that needs to be explicitly
        pointed out? 

      

      

      Isn't this covered by the ordering specified here: 

    

    

    The text has prescribed ordering, yes. But my point is that your
    rules allow an updated +foo registration to retrospectively update
    fragment rules on all previously registered xxx/yyy+foo. I don't
    think this is right.

    

    
     The
      syntax and semantics for fragment identifiers for a specific
      "xxx/yyy+json" 

          SHOULD be processed as follows: 

      

              For cases defined in +json, where the fragment identifier
      resolves per the +json 

              rules, then as specified in +json. 

      

              For cases defined in +json, where the fragment identifier
      does not resolve per 

              the +json rules, then as specified in "xxx/yyy+json". 

      

              For cases not defined in +json, then as specified in
      "xxx/yyy+json". 

      

      The same ordering is used in all of the examples, and no one has
      commented on that ordering. 

    

    

  


--------------060600000608080200000808--

From tony@att.com  Thu Aug 16 05:57:43 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F43E21F85E7 for ; Thu, 16 Aug 2012 05:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.561
X-Spam-Level: 
X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbdPHYZhwBvE for ; Thu, 16 Aug 2012 05:57:43 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 966CE21F85DD for ; Thu, 16 Aug 2012 05:57:42 -0700 (PDT)
Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 54eec205.0.794467.00-294.2176747.nbfkord-smmo06.seg.att.com (envelope-from );  Thu, 16 Aug 2012 12:57:42 +0000 (UTC)
X-MXL-Hash: 502cee463f93ed0d-2d9282a6583d2edf59df50a7df8212acad609235
Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7GCvfvP004878 for ; Thu, 16 Aug 2012 05:57:41 -0700
Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7GCvYfo004807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Aug 2012 05:57:36 -0700
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by fflint03.pst.cso.att.com (RSA Interceptor) for ; Thu, 16 Aug 2012 05:57:19 -0700
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q7GCvJON011161 for ; Thu, 16 Aug 2012 08:57:19 -0400
Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q7GCvAB7010792 for ; Thu, 16 Aug 2012 08:57:14 -0400
Received: from [135.70.11.43] (vpn-135-70-11-43.vpn.west.att.com[135.70.11.43]) by maillennium.att.com (mailgw1) with ESMTP id <20120816125221gw100ssp0se> (Authid: tony); Thu, 16 Aug 2012 12:52:25 +0000
X-Originating-IP: [135.70.11.43]
Message-ID: <502CEE20.5000902@att.com>
Date: Thu, 16 Aug 2012 08:57:04 -0400
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Mark Nottingham 
References:    <5004F76C.8070406@att.com> <2C6D1C2F-8404-4F78-B366-D552954CB7C6@mnot.net>
In-Reply-To: <2C6D1C2F-8404-4F78-B366-D552954CB7C6@mnot.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.128.153]
X-AnalysisOut: [v=1.0 c=1 a=mvRNmGF13VMA:10 a=70aWqWLk7fkA:10 a=ScEQJRfK2-]
X-AnalysisOut: [EA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:1]
X-AnalysisOut: [0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a=izcBpFH-sedM59SPf5wA:9 a]
X-AnalysisOut: [=wPNLvfGTeEIA:10]
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-media-type-suffix-regs
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 12:57:44 -0000

Sorry for the delay in responding to this. I've been gone almost 
continuously, with little time for email.

inline comments below.

     Tony Hansen

On 7/18/2012 8:36 PM, Mark Nottingham wrote:
> On 17/07/2012, at 3:26 PM, Tony Hansen wrote:
>
>> Mark, the suffix-regs doc is mostly trying to document the rules under which existing suffixes have been informally permitted in the past and provide a more formal basis for them to be used in the future. Except for +ber, +der and +zip, there are already examples of the other suffixes mentioned in this document. For example, in addition to all of the +xml media types, consider all of these media types that are already being used:
>>
>>     application/soap+fastinfoset
>>     ...
>>     application/vnd.wv.csp+wbxml
>>
>> You ask about the guidance being provided to the Expert Reviewers in the media type registry document. That advice is expanded on by the media-type-suffix-regs document;
> Where? I'm talking about guidance for new suffixes, not new media types using existing suffixes.

Okay, my misunderstanding on your earlier question. In summary, your 
question is, when can a new suffix be created and why isn't that 
discussed in suffix-regs?

I don't believe that any discussion of this topic belongs in 
draft-ietf-appsawg-media-type-suffix-regs.

>> Expert Reviewers should consider both pieces of guidance. (One can argue that the additional guidance in this document should have been in the other document; for various reasons it didn't happen.)
>>
>> And yes, the gateway is being protected by an Expert Reviewer. But that's been true for them in the past, as well as all of the media types in general. I don't see anyone being to drive a tank through that gateway any more easily now than they have in the past. As an example of a recently proposed media type suffix that did *not* pass muster, consider +exi.
> *sigh*
>
> We can, and should, do better than this.

In summary, your question is, where is the advice for expert reviewers?

I feel that what is in section 2 is sufficient to answer this. If you 
have suggested wording to improve it, feel free to post it.

Thanks for your comments.

     Tony Hansen

From tony@att.com  Thu Aug 16 06:09:59 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688DA21F8605 for ; Thu, 16 Aug 2012 06:09:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.565
X-Spam-Level: 
X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7TxUKsaew8J for ; Thu, 16 Aug 2012 06:09:58 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 7531121F84D5 for ; Thu, 16 Aug 2012 06:09:58 -0700 (PDT)
Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 521fc205.0.798987.00-360.2189142.nbfkord-smmo06.seg.att.com (envelope-from );  Thu, 16 Aug 2012 13:09:58 +0000 (UTC)
X-MXL-Hash: 502cf1266c8e9c13-90bd5fe6b02cb28b8342e077643b6dd52f12ccc3
Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7GD9vtM019025 for ; Thu, 16 Aug 2012 06:09:57 -0700
Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7GD9kDo018916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Aug 2012 06:09:51 -0700
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by fflint04.pst.cso.att.com (RSA Interceptor) for ; Thu, 16 Aug 2012 06:09:26 -0700
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q7GD9Qls004918 for ; Thu, 16 Aug 2012 09:09:26 -0400
Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q7GD9Elx003007 for ; Thu, 16 Aug 2012 09:09:22 -0400
Received: from [135.70.11.43] (vpn-135-70-11-43.vpn.west.att.com[135.70.11.43]) by maillennium.att.com (mailgw1) with ESMTP id <20120816130428gw100ssp0te> (Authid: tony); Thu, 16 Aug 2012 13:04:29 +0000
X-Originating-IP: [135.70.11.43]
Message-ID: <502CF0F7.7070107@att.com>
Date: Thu, 16 Aug 2012 09:09:11 -0400
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Alexey Melnikov 
References: <502A21A2.8060106@isode.com> <502CEC1D.3010301@att.com> <502CEE3C.3010107@isode.com>
In-Reply-To: <502CEE3C.3010107@isode.com>
Content-Type: multipart/alternative; boundary="------------050700040202010505020606"
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.128.153]
X-AnalysisOut: [v=1.0 c=1 a=mvRNmGF13VMA:10 a=70aWqWLk7fkA:10 a=a1ntKncaBy]
X-AnalysisOut: [YA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=xwOvzTHDVLE4u4]
X-AnalysisOut: [nGvK72ag==:17 a=_Oya6dMp58oniw77e_YA:9 a=wPNLvfGTeEIA:10 a]
X-AnalysisOut: [=APQWWo9-AAAA:8 a=zQP7CpKOAAAA:8 a=gFPVlT1aqtKygLUlnaQA:9 ]
X-AnalysisOut: [a=_W_S_7VecoQA:10 a=cat5K2ZOYqEA:10 a=Hz7IrDYlS0cA:10]
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Bilated issue with draft-ietf-appsawg-media-type-suffix-regs-02.txt: fragment identifier rules
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 13:09:59 -0000

This is a multi-part message in MIME format.
--------------050700040202010505020606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


On 8/16/2012 8:57 AM, Alexey Melnikov wrote:
> On 16/08/2012 13:48, Tony Hansen wrote:
>> Isn't this covered by the ordering specified here:
>
> The text has prescribed ordering, yes. But my point is that your rules 
> allow an updated +foo registration to retrospectively update fragment 
> rules on all previously registered xxx/yyy+foo. I don't think this is 
> right.

That is true for *all* of the suffixes -- any of the underlying/foo 
registrations and any of the xxx/yyy+foo registrations can be updated at 
any time and a conflict engendered because of the update. It works both 
ways, no matter what ordering is chosen.

If I were adding a fragment identifier definition to underlying/foo, I 
would certainly want to look at the fragment identifier definitions that 
have already been identified for the various xxx/yyy+foo registrations 
and take those into consideration. Similarly, if I were adding a 
fragment identifier definition to xxx/yyy+foo, I would certainly want to 
look at the fragment identifier definitions that have already been 
identified for the underlying/foo registration and take those into 
consideration.

We could certainly add wording along these lines to the I-D, but I'm not 
sure what else can be done.

Suggestions welcome.

     Tony Hansen

--------------050700040202010505020606
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
On 8/16/2012 8:57 AM, Alexey Melnikov
      wrote:

    

    

      
      
On 16/08/2012 13:48, Tony Hansen
        wrote:

      

      

        
        
        Isn't this covered by the ordering specified here: 

      

      

      The text has prescribed ordering, yes. But my point is that your
      rules allow an updated +foo registration to retrospectively update
      fragment rules on all previously registered xxx/yyy+foo. I don't
      think this is right.

    

    

    That is true for *all* of the suffixes -- any of the underlying/foo
    registrations and any of the xxx/yyy+foo registrations can be
    updated at any time and a conflict engendered because of the update.
    It works both ways, no matter what ordering is chosen.

    

    If I were adding a fragment identifier definition to underlying/foo,
    I would certainly want to look at the fragment identifier
    definitions that have already been identified for the various
    xxx/yyy+foo registrations and take those into consideration.
    Similarly, if I were adding a fragment identifier definition to
    xxx/yyy+foo, I would certainly want to look at the fragment
    identifier definitions that have already been identified for the
    underlying/foo registration and take those into consideration. 

    

    We could certainly add wording along these lines to the I-D, but I'm
    not sure what else can be done.

    

    Suggestions welcome.

    

        Tony Hansen

  


--------------050700040202010505020606--

From sm@elandsys.com  Thu Aug 16 09:16:31 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9437021F85CD; Thu, 16 Aug 2012 09:16:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.604
X-Spam-Level: 
X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WR2y9EKINjE2; Thu, 16 Aug 2012 09:16: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 DB7CE21F85B8; Thu, 16 Aug 2012 09:16:30 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.238.144]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7GGGFPd016947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2012 09:16:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345133788; bh=1CVDZs2mT3J+cQNFNCagB9II2o1mqQ80GmxQKDB+ugk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LA2QkarofnMq37poogMYUeDjmQOvfuW4ePHC/3HPn+a+2NGbV4YANtZoFv4CfWRey mIuLtsLoNkFkmxCikvFLn2QR2JkfusXi4fBsxUXuNvCtVdNPFktaHptMCFneFO9ToV UidZIT/moHRiu2V0G4YHc4ZAx7083lTc8/2Nyz+E=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345133788; i=@elandsys.com; bh=1CVDZs2mT3J+cQNFNCagB9II2o1mqQ80GmxQKDB+ugk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=XAbNq6FofGm1OVenuh6djhaEJLKQmA7oIv8VCM9Q3iRfDbTaHw7GI12PoMKfmOvmH cI6Lv6mANR7JFOpsKsjhpOd0i8dqd+9NGsorB2jOUQAy5UulIgoJt0Kb9ymmCIZiDS uRlYJRG3JMbO6hBuD5v/3vJ7diVOhICJhMYMmBfg=
Message-Id: <6.2.5.6.2.20120816075352.0a770008@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 16 Aug 2012 09:09:36 -0700
To: dime@ietf.org
From: S Moonesamy 
In-Reply-To: <50161436.8080900@bbiw.net>
References: <50161436.8080900@bbiw.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Review of:  draft-ietf-dime-rfc4005bis-09
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 16:16:31 -0000

Hello,

I received a comment about the Applications Area Directorate 
(APPSDIR) review of draft-ietf-dime-rfc4005bis-09 ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06768.html 
).  There is some background information about the Applications 
Directorate at 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate 
Some information for document authors is available at 
http://trac.tools.ietf.org/area/app/trac/wiki/template I'll highlight 
the following:

   "In plain English, this means that the comments in the Applications Area
    Directorate review does not bear more weight than a comment submitted by
    an individual during a Last Call."

There was a Publication Request on May 23 for 
draft-ietf-dime-rfc4005bis.  I assume that the draft is ready for 
review.  APPSDIR tries to perform early reviews, i.e., catch issues 
early so the document authors have more time to address the 
issues.  It is up to the authors, or working group, to decide about 
whether the issues should be resolved and how to do so.

If you have any questions about APPSDIR you can contact the 
undersigned or post a message to the apps-discuss@ietf.org mailing list.

Regards,
S. Moonesamy


From ned.freed@mrochek.com  Thu Aug 16 09:37:41 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB36521F863B for ; Thu, 16 Aug 2012 09:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level: 
X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sfNjgXFDc0g for ; Thu, 16 Aug 2012 09:37:40 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5D23421F8616 for ; Thu, 16 Aug 2012 09:37:39 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJ46MESG8W006ND2@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 16 Aug 2012 09:32:32 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIXJBO9M4W0006TF@mauve.mrochek.com>; Thu, 16 Aug 2012 09:32:28 -0700 (PDT)
Message-id: <01OJ46MC14UA0006TF@mauve.mrochek.com>
Date: Thu, 16 Aug 2012 07:44:51 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Thu, 16 Aug 2012 13:57:32 +0100" <502CEE3C.3010107@isode.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <502A21A2.8060106@isode.com> <502CEC1D.3010301@att.com> <502CEE3C.3010107@isode.com>
To: Alexey Melnikov 
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Bilated issue with draft-ietf-appsawg-media-type-suffix-regs-02.txt: fragment identifier rules
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 16:37:42 -0000

> On 16/08/2012 13:48, Tony Hansen wrote:
> > On 8/14/2012 6:00 AM, Alexey Melnikov wrote:
> >> (And similar text for other registrations).
> >>
> >> So, let's imagine the following sequence of events:
> >>
> >> 1) +json registered with no special rules for handling fragment
> >> identifiers.
> >>
> >> 2) later on "xxx/yyy+json" is registered that defines some special
> >> rules for handling fragment identifiers.
> >>
> >> 3) +json registration is updated to add some generic rules for
> >> handling fragment identifiers. If fragment identifier rules for
> >> "xxx/yyy+json" are in conflict with the new generic +json rules,
> >> implementors might get confused which rules apply.
> >>
> >> Is this likely? Is this something that needs to be explicitly pointed
> >> out?
> >
> > Isn't this covered by the ordering specified here:

> The text has prescribed ordering, yes. But my point is that your rules
> allow an updated +foo registration to retrospectively update fragment
> rules on all previously registered xxx/yyy+foo. I don't think this is right.

OK... Sure, an update to the registrtion of +json could conceivably change
the processing requirements for types that use the +json suffix.

Maybe I'm missing something, but how is this significantly different from any
situation where we build one standard on top of another? For that matter, the
definition of how fragment identifiers work for JSON, or perhaps even the
specification of JSON itself could conceivably change in such a way that code
changes are needed for things that process JSON-based types, irrespective of
whether there's any indication of the use of JSON in the media type name. Ditto
for XML or pretty much anything else.

It's also possible, and even likely, that the defacto handling requirements for
commonly used formats can shift over time. text/html is a particularly
egregious example, but there are many others.

Nor it is limited to media types. I seem to recall a bit of a fuss over the
location of some code points in Unicode a few years back...

Anyway, if you want to suggest some text to say that due to this dependency the
handling of fragment identifiers in +suffix registrations should be adjusted
cautiously if at all, I think that would be a good addition.

But given the present fluidity of standards regarding fragment identifier
handling and the high liklihood of further change, to say nothing of what's
actually going on in the field, I'm doubtful as to how much good it will do.

				Ned

From stpeter@stpeter.im  Thu Aug 16 11:30:05 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD4821F846A for ; Thu, 16 Aug 2012 11:30:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.571
X-Spam-Level: 
X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c3Ftlb1y7Jx for ; Thu, 16 Aug 2012 11:30:05 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 27D7421F844A for ; Thu, 16 Aug 2012 11:30:05 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7C1644050A; Thu, 16 Aug 2012 12:30:35 -0600 (MDT)
Message-ID: <502D3C2B.3040900@stpeter.im>
Date: Thu, 16 Aug 2012 12:30:03 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Graham Klyne 
References: <502B7037.4020901@ninebynine.org>
In-Reply-To: <502B7037.4020901@ninebynine.org>
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 18:30:05 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/15/12 3:47 AM, Graham Klyne wrote:
> ref: http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-00
> 
> I'm uneasy about:
> 
> [[ 4.4.  URI Scheme Semantics
> 
> The 'acct' URI scheme is used to identify user accounts hosted at 
> service providers.  It is used only for identification, not 
> interaction.  A protocol that uses the 'acct' URI scheme is 
> responsible for specifying how an 'acct' URI is to be dereferenced
> in the context of that protocol.  There is no media type associated
> with the 'acct' URI scheme. ]]
> 
> Specifically, the bit about "protocol that uses the acct URI
> scheme".
> 
> My understanding was that the intent was that acct: would be 
> dereferenced using the WebFinger protocol.  If there is no such 
> expectation, then an acct: URI appearing in isolation (e.g. in a
> web page or some document) has no actionable meaning.

My understanding, which I tried to capture in the document, was that
some folks here thought that acct URIs might be used by other
protocols. If there is consensus that acct URIs will be used only for
WebFinger, I am happy to update the document accordingly. I'm truly
just acting in an editorial capacity on this document.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAtPCsACgkQNL8k5A2w/vyOUwCeMAUUJ7bEo4wkzArj4VzNJ4Qw
1dwAn1Jv1leY03gD3oB1lYUfxFKOuH1s
=ADc0
-----END PGP SIGNATURE-----

From Michael.Jones@microsoft.com  Thu Aug 16 12:45:23 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C8521F845D for ; Thu, 16 Aug 2012 12:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.308
X-Spam-Level: 
X-Spam-Status: No, score=-5.308 tagged_above=-999 required=5 tests=[AWL=1.291,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTcpJwrcYLh7 for ; Thu, 16 Aug 2012 12:45:22 -0700 (PDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAD421F8459 for ; Thu, 16 Aug 2012 12:45:22 -0700 (PDT)
Received: from mail232-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.23; Thu, 16 Aug 2012 19:45:21 +0000
Received: from mail232-tx2 (localhost [127.0.0.1])	by mail232-tx2-R.bigfish.com (Postfix) with ESMTP id AFF9D3A0502; Thu, 16 Aug 2012 19:45:21 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-SpamScore: -37
X-BigFish: VS-37(zzbb2dI98dI154cP9371I542M1432Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah)
Received-SPF: pass (mail232-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail232-tx2 (localhost.localdomain [127.0.0.1]) by mail232-tx2 (MessageSwitch) id 1345146320295858_10136; Thu, 16 Aug 2012 19:45:20 +0000 (UTC)
Received: from TX2EHSMHS044.bigfish.com (unknown [10.9.14.248])	by mail232-tx2.bigfish.com (Postfix) with ESMTP id 3C9DC40049; Thu, 16 Aug 2012 19:45:20 +0000 (UTC)
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS044.bigfish.com (10.9.99.144) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 16 Aug 2012 19:45:18 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0309.003; Thu, 16 Aug 2012 19:45:17 +0000
From: Mike Jones 
To: Peter Saint-Andre , Graham Klyne 
Thread-Topic: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
Thread-Index: AQHNesvs8vKnlOUTjUOINpvGHWreOpdcxLWAgAAUutA=
Date: Thu, 16 Aug 2012 19:45:17 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436677B5CF@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im>
In-Reply-To: <502D3C2B.3040900@stpeter.im>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.72]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 19:45:23 -0000

Several examples of other protocols that could/might/may/would have used ac=
ct: have already been discussed on the list.  It's definitely not only for =
WebFinger.

				-- Mike

-----Original Message-----
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of Peter Saint-Andre
Sent: Thursday, August 16, 2012 11:30 AM
To: Graham Klyne
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/15/12 3:47 AM, Graham Klyne wrote:
> ref: http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-00
>=20
> I'm uneasy about:
>=20
> [[ 4.4.  URI Scheme Semantics
>=20
> The 'acct' URI scheme is used to identify user accounts hosted at=20
> service providers.  It is used only for identification, not=20
> interaction.  A protocol that uses the 'acct' URI scheme is=20
> responsible for specifying how an 'acct' URI is to be dereferenced in=20
> the context of that protocol.  There is no media type associated with=20
> the 'acct' URI scheme. ]]
>=20
> Specifically, the bit about "protocol that uses the acct URI scheme".
>=20
> My understanding was that the intent was that acct: would be=20
> dereferenced using the WebFinger protocol.  If there is no such=20
> expectation, then an acct: URI appearing in isolation (e.g. in a web=20
> page or some document) has no actionable meaning.

My understanding, which I tried to capture in the document, was that some f=
olks here thought that acct URIs might be used by other protocols. If there=
 is consensus that acct URIs will be used only for WebFinger, I am happy to=
 update the document accordingly. I'm truly just acting in an editorial cap=
acity on this document.

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAtPCsACgkQNL8k5A2w/vyOUwCeMAUUJ7bEo4wkzArj4VzNJ4Qw
1dwAn1Jv1leY03gD3oB1lYUfxFKOuH1s
=3DADc0
-----END PGP SIGNATURE-----
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss



From gsalguei@cisco.com  Thu Aug 16 13:05:26 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF4B21F84A7 for ; Thu, 16 Aug 2012 13:05:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.445
X-Spam-Level: 
X-Spam-Status: No, score=-7.445 tagged_above=-999 required=5 tests=[AWL=3.154,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTDhh0wkeu5I for ; Thu, 16 Aug 2012 13:05:25 -0700 (PDT)
Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 5B75721F84C9 for ; Thu, 16 Aug 2012 13:05:25 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q7GK5OcG015785 for ; Thu, 16 Aug 2012 16:05:24 -0400 (EDT)
Received: from dhcp-10-150-53-194.cisco.com (dhcp-10-150-53-194.cisco.com [10.150.53.194]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q7GK5NoU018214; Thu, 16 Aug 2012 16:05:23 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=us-ascii
From: Gonzalo Salgueiro 
In-Reply-To: <502D3C2B.3040900@stpeter.im>
Date: Thu, 16 Aug 2012 16:05:23 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im>
To: Peter Saint-Andre 
X-Mailer: Apple Mail (2.1278)
Cc: Graham Klyne , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 20:05:26 -0000

On Aug 16, 2012, at 2:30 PM, Peter Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> On 8/15/12 3:47 AM, Graham Klyne wrote:
>> ref: http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-00
>>=20
>> I'm uneasy about:
>>=20
>> [[ 4.4.  URI Scheme Semantics
>>=20
>> The 'acct' URI scheme is used to identify user accounts hosted at=20
>> service providers.  It is used only for identification, not=20
>> interaction.  A protocol that uses the 'acct' URI scheme is=20
>> responsible for specifying how an 'acct' URI is to be dereferenced
>> in the context of that protocol.  There is no media type associated
>> with the 'acct' URI scheme. ]]
>>=20
>> Specifically, the bit about "protocol that uses the acct URI
>> scheme".
>>=20
>> My understanding was that the intent was that acct: would be=20
>> dereferenced using the WebFinger protocol.  If there is no such=20
>> expectation, then an acct: URI appearing in isolation (e.g. in a
>> web page or some document) has no actionable meaning.
>=20
> My understanding, which I tried to capture in the document, was that
> some folks here thought that acct URIs might be used by other
> protocols. If there is consensus that acct URIs will be used only for
> WebFinger, I am happy to update the document accordingly. I'm truly
> just acting in an editorial capacity on this document.
>=20
I had the same understanding.  Consensus was to divorce acct from =
WebFinger so it would have its own standalone fate and not affect that =
of WebFinger. Additionally, it was argued that, while still relatively =
narrow in scope, it could be implemented in various other protocols =
satisfying the general need for "I need information about this user" =
when it's not in the context of a specific application protocol.

A small sampling supporting this:=20
=20
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06615.html
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06462.html
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06693.html
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06463.html


Cheers,

Gonzalo


> Peter
>=20
> - --=20
> Peter Saint-Andre
> https://stpeter.im/
>=20
>=20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>=20
> iEYEARECAAYFAlAtPCsACgkQNL8k5A2w/vyOUwCeMAUUJ7bEo4wkzArj4VzNJ4Qw
> 1dwAn1Jv1leY03gD3oB1lYUfxFKOuH1s
> =3DADc0
> -----END PGP SIGNATURE-----
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20


From alexey.melnikov@isode.com  Fri Aug 17 05:26:19 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32A721F84FE for ; Fri, 17 Aug 2012 05:26:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.87
X-Spam-Level: 
X-Spam-Status: No, score=-102.87 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkVcgCw115WD for ; Fri, 17 Aug 2012 05:26:19 -0700 (PDT)
Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id CD01021F84FB for ; Fri, 17 Aug 2012 05:26:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1345206376; d=isode.com; s=selector; i=@isode.com; bh=MzCwIDAS88fONPkjGOCDBqY//qA9e4Jbd6fhDndohYc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=X4v7LcZ92YK6q5cFDGx4DTkIHv6nRTfEnJT34oMd8rq8qiWaF3BgLh2zUZBYO8IC35Oisq UiEeCeppL2Ei2M5yS/9UmUzsZ7Zz3inCLfmryccipyk2eP1tP+Hx5EuN5Dxe9XLgFX14ZY EfAmm6/qKVJOxmWifuUlyBbDLQjo87Q=;
Received: from [172.16.11.4] (shiny.isode.com [62.3.217.250])  by waldorf.isode.com (submission channel) via TCP with ESMTPA  id ; Fri, 17 Aug 2012 13:26:16 +0100
Message-ID: <502E38CD.2050107@isode.com>
Date: Fri, 17 Aug 2012 13:27:57 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
To: Ned Freed , Tony Hansen 
References: <502A21A2.8060106@isode.com> <502CEC1D.3010301@att.com> <502CEE3C.3010107@isode.com> <01OJ46MC14UA0006TF@mauve.mrochek.com>
In-Reply-To: <01OJ46MC14UA0006TF@mauve.mrochek.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Bilated issue with draft-ietf-appsawg-media-type-suffix-regs-02.txt: fragment identifier rules
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 12:26:20 -0000

On 16/08/2012 15:44, Ned Freed wrote:
>> On 16/08/2012 13:48, Tony Hansen wrote:
>> > On 8/14/2012 6:00 AM, Alexey Melnikov wrote:
>> >> (And similar text for other registrations).
>> >>
>> >> So, let's imagine the following sequence of events:
>> >>
>> >> 1) +json registered with no special rules for handling fragment
>> >> identifiers.
>> >>
>> >> 2) later on "xxx/yyy+json" is registered that defines some special
>> >> rules for handling fragment identifiers.
>> >>
>> >> 3) +json registration is updated to add some generic rules for
>> >> handling fragment identifiers. If fragment identifier rules for
>> >> "xxx/yyy+json" are in conflict with the new generic +json rules,
>> >> implementors might get confused which rules apply.
>> >>
>> >> Is this likely? Is this something that needs to be explicitly pointed
>> >> out?
>> >
>> > Isn't this covered by the ordering specified here:
>
>> The text has prescribed ordering, yes. But my point is that your rules
>> allow an updated +foo registration to retrospectively update fragment
>> rules on all previously registered xxx/yyy+foo. I don't think this is 
>> right.
>
> OK... Sure, an update to the registrtion of +json could conceivably 
> change
> the processing requirements for types that use the +json suffix.
>
> Maybe I'm missing something, but how is this significantly different 
> from any
> situation where we build one standard on top of another?
It isn't. But I think the current set of ordered rules is more prone to 
"oh shit, I didn't mean to change that" situation. (See below.)
> For that matter, the
> definition of how fragment identifiers work for JSON, or perhaps even the
> specification of JSON itself could conceivably change in such a way 
> that code
> changes are needed for things that process JSON-based types, 
> irrespective of
> whether there's any indication of the use of JSON in the media type 
> name. Ditto
> for XML or pretty much anything else.
>
> It's also possible, and even likely, that the defacto handling 
> requirements for
> commonly used formats can shift over time. text/html is a particularly
> egregious example, but there are many others.
>
> Nor it is limited to media types. I seem to recall a bit of a fuss 
> over the
> location of some code points in Unicode a few years back...
Sure.
> Anyway, if you want to suggest some text to say that due to this 
> dependency the
> handling of fragment identifiers in +suffix registrations should be 
> adjusted
> cautiously if at all, I think that would be a good addition.
Sure.

My primary preference is to change the order to make sure that the rules 
for xxx/yyy+foo apply first and only for cases not covered the rules for 
+foo apply. This wouldn't prevent the situation where additional rules 
are introduced in +foo which are not covered by xxx/yyy+foo, but it will 
at least keep the fragment identifier rules explicitly defined in 
xxx/yyy+foo stable.

So:
OLD:
   The syntax and semantics for fragment
   identifiers for a specific "xxx/yyy+json"
   SHOULD be processed as follows:

     For cases defined in +json, where the
     fragment identifier resolves per the +json
     rules, then as specified in +json.

     For cases defined in +json, where the
     fragment identifier does not resolve per
     the +json rules, then as specified in "xxx/
     yyy+json".

     For cases not defined in +json, then as
     specified in "xxx/yyy+json".

NEW:
   The syntax and semantics for fragment
   identifiers for a specific "xxx/yyy+json"
   SHOULD be processed as follows:

     For cases defined in "xxx/yyy+json"
     the rules specified in "xxx/yyy+json" apply
     irrespectively of whether they are
     covered by +json or not.

     For cases not defined in "xxx/yyy+json",
     then as specified in +json.

Or something like that. (Then repeat for each +foo).

In addition, something along the following lines should be added 
(irrespectively of whether my suggestion above is used or not):

I don't know where this should be stated, registration templates don't 
seem to be the right place for this information:

NEW:
When updating a +suffix registration care should be taken to review all 
previously registered xxx/yyy+suffix media types regarding whether they 
might be affected by the updated +suffix registration.

> But given the present fluidity of standards regarding fragment identifier
> handling and the high liklihood of further change, to say nothing of 
> what's
> actually going on in the field, I'm doubtful as to how much good it 
> will do.
>


From melvincarvalho@gmail.com  Fri Aug 17 06:03:36 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1F121F8589 for ; Fri, 17 Aug 2012 06:03:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.554
X-Spam-Level: 
X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.044,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRpsYmqu-kOc for ; Fri, 17 Aug 2012 06:03:35 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE1521F8584 for ; Fri, 17 Aug 2012 06:03:34 -0700 (PDT)
Received: by lahm15 with SMTP id m15so2156829lah.31 for ; Fri, 17 Aug 2012 06:03: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=vL/dX7Jy5oLVPiZWi55rChNTFvcgSq06co/wVbl8780=; b=nNmSOi0vLnmjUAlHiBQ8/fcJMzcfBvXhZ4W5f0ZZpx4sIgCDYlFRWhruCVyEeU0gF8 7ENagzZG3SSiiBmHO4di1OG1A2/j/EROk/LeRG3gu9ADzE/fqSF9R2z2MCoTSLQb7izc Tj6VfxtKxCnceHxwc3EyhMS6ZZPn/XvC3whUuKq/ZfnjBWFKXHCH+Jo1rh2GnSLlJ0CO cEhi6PTZesBCo0Ol0NzEcCLr9sJNrJo4ruE2KYPh/slYAHT4vltniBixHeYO5uREvG/M iOeYscY8OMe8tXp1zIi29FfnE9ouaDojc9XAFnP1Gb1AJjDLwmQbtMKo4eVm+ozOli/k 5tCw==
MIME-Version: 1.0
Received: by 10.112.9.3 with SMTP id v3mr2253398lba.32.1345208613949; Fri, 17 Aug 2012 06:03:33 -0700 (PDT)
Received: by 10.112.148.231 with HTTP; Fri, 17 Aug 2012 06:03:33 -0700 (PDT)
In-Reply-To: <502D3C2B.3040900@stpeter.im>
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im>
Date: Fri, 17 Aug 2012 15:03:33 +0200
Message-ID: 
From: Melvin Carvalho 
To: Peter Saint-Andre 
Content-Type: multipart/alternative; boundary=e0cb4efe2b189550c404c775c9ab
Cc: Graham Klyne , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 13:03:36 -0000

--e0cb4efe2b189550c404c775c9ab
Content-Type: text/plain; charset=ISO-8859-1

On 16 August 2012 20:30, Peter Saint-Andre  wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 8/15/12 3:47 AM, Graham Klyne wrote:
> > ref: http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-00
> >
> > I'm uneasy about:
> >
> > [[ 4.4.  URI Scheme Semantics
> >
> > The 'acct' URI scheme is used to identify user accounts hosted at
> > service providers.  It is used only for identification, not
> > interaction.  A protocol that uses the 'acct' URI scheme is
> > responsible for specifying how an 'acct' URI is to be dereferenced
> > in the context of that protocol.  There is no media type associated
> > with the 'acct' URI scheme. ]]
> >
> > Specifically, the bit about "protocol that uses the acct URI
> > scheme".
> >
> > My understanding was that the intent was that acct: would be
> > dereferenced using the WebFinger protocol.  If there is no such
> > expectation, then an acct: URI appearing in isolation (e.g. in a
> > web page or some document) has no actionable meaning.
>
> My understanding, which I tried to capture in the document, was that
> some folks here thought that acct URIs might be used by other
> protocols. If there is consensus that acct URIs will be used only for
> WebFinger, I am happy to update the document accordingly. I'm truly
> just acting in an editorial capacity on this document.
>

Once a new scheme/protocol is established, it can sometimes be hard to
predict which specifications will make use of it, in the future.

Tho acct: is currently recommended in the webfinger RFC.  I think it was
pretty much consensus that webfinger could operate with various URI schemes
e.g. mailto: http: acct: etc.

Thus, my impression was that it was viewed as an advantage, that neither
spec, becomes a blocker for the other.


>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAlAtPCsACgkQNL8k5A2w/vyOUwCeMAUUJ7bEo4wkzArj4VzNJ4Qw
> 1dwAn1Jv1leY03gD3oB1lYUfxFKOuH1s
> =ADc0
> -----END PGP SIGNATURE-----
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--e0cb4efe2b189550c404c775c9ab
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On 16 August 2012 20:30, Peter Saint-And=
re <stpeter@stpeter.im> wrote:

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1




On 8/15/12 3:47 AM, Graham Klyne wrote:

> ref: http://tools.ietf.org/html/draft-ietf-appsawg-acct-u=
ri-00

>

> I'm uneasy about:

>

> [[ 4.4. =A0URI Scheme Semantics

>

> The 'acct' URI scheme is used to identify user accounts hosted=
 at

> service providers. =A0It is used only for identification, not

> interaction. =A0A protocol that uses the 'acct' URI scheme is<=
br>
> responsible for specifying how an 'acct' URI is to be derefere=
nced

> in the context of that protocol. =A0There is no media type associated<=
br>
> with the 'acct' URI scheme. ]]

>

> Specifically, the bit about "protocol that uses the acct URI

> scheme".

>

> My understanding was that the intent was that acct: would be

> dereferenced using the WebFinger protocol. =A0If there is no such

> expectation, then an acct: URI appearing in isolation (e.g. in a

> web page or some document) has no actionable meaning.




My understanding, which I tried to capture in the document, was that<=
br>
some folks here thought that acct URIs might be used by other

protocols. If there is consensus that acct URIs will be used only for

WebFinger, I am happy to update the document accordingly. I'm truly

just acting in an editorial capacity on this document.

Once a new scheme/protocol is established, it can sometimes be hard to=
 predict which specifications will make use of it, in the future.=A0 


Tho acct: is currently recommended in the webfinger RFC.=A0 I think it =
was pretty much consensus that webfinger could operate with various URI sch=
emes e.g. mailto: http: acct: etc.

Thus, my impression was that it w=
as viewed as an advantage, that neither spec, becomes a blocker for the oth=
er.

=A0



Peter



- --

Peter Saint-Andre

https://stpeter.im/




-----BEGIN PGP SIGNATURE-----

Version: GnuPG/MacGPG2 v2.0.18 (Darwin)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/



iEYEARECAAYFAlAtPCsACgkQNL8k5A2w/vyOUwCeMAUUJ7bEo4wkzArj4VzNJ4Qw

1dwAn1Jv1leY03gD3oB1lYUfxFKOuH1s

=3DADc0

-----END PGP SIGNATURE-----


___________________________________=
____________

apps-discuss mailing list

apps-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/apps-discuss





--e0cb4efe2b189550c404c775c9ab--

From hallam@gmail.com  Fri Aug 17 06:47:34 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A8821F84C2 for ; Fri, 17 Aug 2012 06:47:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.496
X-Spam-Level: 
X-Spam-Status: No, score=-5.496 tagged_above=-999 required=5 tests=[AWL=-1.897, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sraL40jyYLjh for ; Fri, 17 Aug 2012 06:47:33 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7317221F8476 for ; Fri, 17 Aug 2012 06:47:33 -0700 (PDT)
Received: by obbwc20 with SMTP id wc20so6061569obb.31 for ; Fri, 17 Aug 2012 06:47:33 -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=PuZonoh5mIUbTg1knR3k6NgbZvYd9QiIkKYWOeXtvp4=; b=mNr5nrasemGbBQjdNyZCDIPYEM06ERcE4csbG17fj7hF95tqVsG4ko9DFzEYF8iCmS bl2JwZYNbAUEe3Lzcmp5ghYMg/ASfM1giY05VcVkbppkGjI1OSwTocTY8Upznw0ZN2TW uVhCCakQ485hmMUGVTzn0GFN5hK6WyrMOUMbPqa8D05S2sFjAwS5LWZNDt7Sd9o/XquC wnLNOeKEb0JCB4NdH4tGdDN8syBfGbfSbM3765hRD4Jj3v0+1N6k65EZAw0IjlFSzc3A irWv0Nu6+J7ZIov3c3feOQSZqlUuCYi863DJThK/jdYjcdVEg58q0VpTKOF580Ee9igD YyAg==
MIME-Version: 1.0
Received: by 10.60.170.229 with SMTP id ap5mr3829739oec.101.1345211252800; Fri, 17 Aug 2012 06:47:32 -0700 (PDT)
Received: by 10.76.80.10 with HTTP; Fri, 17 Aug 2012 06:47:32 -0700 (PDT)
In-Reply-To: 
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> 
Date: Fri, 17 Aug 2012 09:47:32 -0400
Message-ID: 
From: Phillip Hallam-Baker 
To: Melvin Carvalho 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Graham Klyne , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 13:47:34 -0000

I see the acct: URI scheme as signifying an account and WebFinger as a
protocol for obtaining information about accounts.

WebFinger applications may attempt to dereference any URI that is
'accountish' that they like. The point of choosing the acct: URI as
canonical is to define the version that should work.


acct: is what mailto: should have been in the first place. The problem
with mailto is that it conflates the entity signified 'mail recipient'
with the action to be performed 'send them an email'. This was always
a bad choice as what I often want to do with an email recipient is to
put the address in my address book.


On Fri, Aug 17, 2012 at 9:03 AM, Melvin Carvalho
 wrote:
>
>
> On 16 August 2012 20:30, Peter Saint-Andre  wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 8/15/12 3:47 AM, Graham Klyne wrote:
>> > ref: http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-00
>> >
>> > I'm uneasy about:
>> >
>> > [[ 4.4.  URI Scheme Semantics
>> >
>> > The 'acct' URI scheme is used to identify user accounts hosted at
>> > service providers.  It is used only for identification, not
>> > interaction.  A protocol that uses the 'acct' URI scheme is
>> > responsible for specifying how an 'acct' URI is to be dereferenced
>> > in the context of that protocol.  There is no media type associated
>> > with the 'acct' URI scheme. ]]
>> >
>> > Specifically, the bit about "protocol that uses the acct URI
>> > scheme".
>> >
>> > My understanding was that the intent was that acct: would be
>> > dereferenced using the WebFinger protocol.  If there is no such
>> > expectation, then an acct: URI appearing in isolation (e.g. in a
>> > web page or some document) has no actionable meaning.
>>
>> My understanding, which I tried to capture in the document, was that
>> some folks here thought that acct URIs might be used by other
>> protocols. If there is consensus that acct URIs will be used only for
>> WebFinger, I am happy to update the document accordingly. I'm truly
>> just acting in an editorial capacity on this document.
>
>
> Once a new scheme/protocol is established, it can sometimes be hard to
> predict which specifications will make use of it, in the future.
>
> Tho acct: is currently recommended in the webfinger RFC.  I think it was
> pretty much consensus that webfinger could operate with various URI schemes
> e.g. mailto: http: acct: etc.
>
> Thus, my impression was that it was viewed as an advantage, that neither
> spec, becomes a blocker for the other.
>
>>
>>
>> Peter
>>
>> - --
>> Peter Saint-Andre
>> https://stpeter.im/
>>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAlAtPCsACgkQNL8k5A2w/vyOUwCeMAUUJ7bEo4wkzArj4VzNJ4Qw
>> 1dwAn1Jv1leY03gD3oB1lYUfxFKOuH1s
>> =ADc0
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> 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
>



-- 
Website: http://hallambaker.com/

From ned.freed@mrochek.com  Fri Aug 17 07:25:41 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895AC11E80D2 for ; Fri, 17 Aug 2012 07:25:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level: 
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6pqqT5hMCO6 for ; Fri, 17 Aug 2012 07:25:41 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id E9BE221F852C for ; Fri, 17 Aug 2012 07:25:40 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJ5GB37IHC00754T@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 17 Aug 2012 07:20:32 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIXJBO9M4W0006TF@mauve.mrochek.com>; Fri, 17 Aug 2012 07:20:27 -0700 (PDT)
Message-id: <01OJ5GAZWQ9A0006TF@mauve.mrochek.com>
Date: Fri, 17 Aug 2012 07:11:16 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Fri, 17 Aug 2012 13:27:57 +0100" <502E38CD.2050107@isode.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <502A21A2.8060106@isode.com> <502CEC1D.3010301@att.com> <502CEE3C.3010107@isode.com> <01OJ46MC14UA0006TF@mauve.mrochek.com> <502E38CD.2050107@isode.com>
To: Alexey Melnikov 
Cc: Ned Freed , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Bilated issue with draft-ietf-appsawg-media-type-suffix-regs-02.txt: fragment identifier rules
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 14:25:41 -0000

> My primary preference is to change the order to make sure that the rules
> for xxx/yyy+foo apply first and only for cases not covered the rules for
> +foo apply. This wouldn't prevent the situation where additional rules
> are introduced in +foo which are not covered by xxx/yyy+foo, but it will
> at least keep the fragment identifier rules explicitly defined in
> xxx/yyy+foo stable.

> So:
> OLD:
>    The syntax and semantics for fragment
>    identifiers for a specific "xxx/yyy+json"
>    SHOULD be processed as follows:

>      For cases defined in +json, where the
>      fragment identifier resolves per the +json
>      rules, then as specified in +json.

>      For cases defined in +json, where the
>      fragment identifier does not resolve per
>      the +json rules, then as specified in "xxx/
>      yyy+json".

>      For cases not defined in +json, then as
>      specified in "xxx/yyy+json".

> NEW:
>    The syntax and semantics for fragment
>    identifiers for a specific "xxx/yyy+json"
>    SHOULD be processed as follows:

>      For cases defined in "xxx/yyy+json"
>      the rules specified in "xxx/yyy+json" apply
>      irrespectively of whether they are
>      covered by +json or not.

>      For cases not defined in "xxx/yyy+json",
>      then as specified in +json.

> Or something like that. (Then repeat for each +foo).

The problem here is you're now trading one problem for another. As I understand
it, getting common semantics across fragement identifiers for different types
has been a signficant issue, and this ordering is intended to address that by
making it harder for specific types to override general rules. (Note that
it is still trivial to do so simply by writing a registration that explicitly
overrides the ordering.)

I see both sides so I have no real preference either way, but those who are
trying to get some degree of consistenty in fragement identifier handling
may have a different opinion.

> In addition, something along the following lines should be added
> (irrespectively of whether my suggestion above is used or not):

> I don't know where this should be stated, registration templates don't
> seem to be the right place for this information:

Yes, this particular part really belongs in the registration document, but it
is too late for that.

> NEW:
> When updating a +suffix registration care should be taken to review all
> previously registered xxx/yyy+suffix media types regarding whether they
> might be affected by the updated +suffix registration.

Seems OK to me, but this is Tony's call, not mine.

				Ned

From nick@jigsoft.co.za  Fri Aug 17 11:11:31 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D409011E80A5 for ; Fri, 17 Aug 2012 11:11:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.123
X-Spam-Level: 
X-Spam-Status: No, score=-1.123 tagged_above=-999 required=5 tests=[AWL=1.854,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7XWByAxu5GY for ; Fri, 17 Aug 2012 11:11:24 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3093311E809B for ; Fri, 17 Aug 2012 11:11:22 -0700 (PDT)
Received: by lbbgg6 with SMTP id gg6so2368981lbb.31 for ; Fri, 17 Aug 2012 11:11:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type:x-gm-message-state; bh=hQOhqeNUm+DRim4pqmUxeaIWg8+ddhr+XefXL3BP+ts=; b=LF1TT/72lM3NLmD8JzlY4gQ+kFOkdT+8AUx1JfUDUqHqgfjaqu8WgUX1X8omw2ursn QmRT0efrgd4fOJ/GP+gAG0oDgdNiW5Q0Rn+fqFhOoLVIpvFilaWMPp1CbWOza4EaEg2T CRlUcPJk46yRTU/HQ2cz8vBvIIjooCcIirbdzCIP8byrum96R6sp2oqD0rzHboWzGJQX Nm4fCysd2HTvM5vmsB45dsdZib3qpcBBkwi26ec19oiJnbphKMPIkkD88+JnuB33DwEZ HvUuPVN0thgT6/AlPO6JaQNHuvyh3krl+cfJS39h/RF1KTWMluqRP1tAFercY4X9wwWo HUxQ==
Received: by 10.152.148.199 with SMTP id tu7mr5293788lab.37.1345227081942; Fri, 17 Aug 2012 11:11:21 -0700 (PDT)
MIME-Version: 1.0
Sender: nick@jigsoft.co.za
Received: by 10.114.29.65 with HTTP; Fri, 17 Aug 2012 11:11:00 -0700 (PDT)
From: Nick Lombard 
Date: Fri, 17 Aug 2012 20:11:00 +0200
X-Google-Sender-Auth: oEjOjDsRiLD2Q7zHEcFuZnKN0NQ
Message-ID: 
To: apps-discuss@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQnHkYjRbsO0koUwB/bI/jPiqYCgxKyEBCjTIzBVIwB3mbMWzq1Wl2r+Th1R2yJxs5UZAtG3
Subject: [apps-discuss] feedback draft-nottingham-json-home
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 19:11:42 -0000

Good evening from a starry-skied South-Africa this be my maiden ietf
post so n00b alert, please mind your toes, no special treatment
required all std disclaimers apply.

With reference to I-D[2] of json-home from github.com/mnot/I-D since
commit Aug 06, 2012

Example JSON document completed, up to date, auth-req inclusive, plus
additional ideas can be found at https://github.com/mnot/I-D/issues/3
To serve as visual aid in support of these suggestions.

1. relation type URIs
There appears to be an initial resistance accepting the foreign usage
of URLs as rel values, prompting explanation. Partly due to the
additional presence of links or endpoints expressed in the same
notation.
May I suggest a less ambiguous approach utilizing URNs (RFC 2141) instead.
Motivation :
 a. URNs are generally understood to not have endpoints as apposed to URLs
 b. to make a clear distinction cognitively between links and relations
 c. to decrease the initial "What The?" factor, ease understanding
based on common usage and hopefully expedite acceptance.

2. Instead of a new relation type "docs" (sec 5.8) won't using
existing relation "help" serve the same purpose?
[W3C.REC-html401-19991224](http://www.w3.org/TR/html5/links.html#link-type-help)

3. prepend resources collection with host || api information a la
host-meta RFC 6415
ie. expires, title, copyright, version, license, property, author, etc

4. Additional RFCs to consider
a. Paging and Archiving RFC 5005 also RFC 5988
b. Simple Version Navigation RFC 5829
c. Subscribing to Changes RFC 5989
d. Disclosure RFC 6579
e. License Extension RFC 4946

5. Reference implementation.
I will be implementing an interpreter in php - Pretty JSON Home Page
or PJHP to facilitate a html representation of a home document for
nose to the ground API exploration and purposes of documentation. I
know there has been requests for for an example implementation may I
use this opportunity to announce my intentions and invite everyone
interested to join forces.

A project has beet registered at https://github.com/nickl-/pjhp and
the issue queue is open for suggestion, requests and pledges. Everyone
is welcome.

Typo: s/type\stype/type/ at line 356 in draft-nottingham-json-home-02.xml
Would it help if I submit pull requests on github for these?

On that note if you notice anything I need to improve on please don't
hesitate to let me know so I may learn the ropes. @Mark, thank you for
this initiative if this post only serve to as indication that there is
interest and we appreciate your effort. Please don't feel obliged to
consider anything I've listed if it even has the slightest chance to
slow the process that would be worse.

Regards,
nickl-

From dret@berkeley.edu  Fri Aug 17 18:09:29 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A959421F8471 for ; Fri, 17 Aug 2012 18:09:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ib-MbhfeHg9o for ; Fri, 17 Aug 2012 18:09:28 -0700 (PDT)
Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id D349E21F846E for ; Fri, 17 Aug 2012 18:09:28 -0700 (PDT)
Received: from 108-67-66-127.lightspeed.sntcca.sbcglobal.net ([108.67.66.127] helo=[192.168.1.67]) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1T2XXa-0000OM-F2; Fri, 17 Aug 2012 18:09:28 -0700
Message-ID: <502EEB44.8070907@berkeley.edu>
Date: Fri, 17 Aug 2012 18:09:24 -0700
From: Erik Wilde 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] feedback draft-nottingham-json-home
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 01:09:29 -0000

hello nick.

On 2012-08-17 11:11 , Nick Lombard wrote:
> 1. relation type URIs
> There appears to be an initial resistance accepting the foreign usage
> of URLs as rel values, prompting explanation. Partly due to the
> additional presence of links or endpoints expressed in the same
> notation.
> May I suggest a less ambiguous approach utilizing URNs (RFC 2141) instead.
> Motivation :
>   a. URNs are generally understood to not have endpoints as apposed to URLs
>   b. to make a clear distinction cognitively between links and relations
>   c. to decrease the initial "What The?" factor, ease understanding
> based on common usage and hopefully expedite acceptance.

for the link relation types that will be registered once the draft is 
approved, they will show up as regular names because they will then be 
well-known relation types in the IANA registry 
(http://www.iana.org/assignments/link-relations/link-relations.xml). so 
no URIs there.

for all other link relation types used in a home document, it is up to 
the document's publisher to decide how to identify them. if people 
prefer URNs, they're free to do so, but since RFC 5988 does define link 
relation types to be identified by URI (and not URN), there really is no 
option to change that retroactively.

> 2. Instead of a new relation type "docs" (sec 5.8) won't using
> existing relation "help" serve the same purpose?
> [W3C.REC-html401-19991224](http://www.w3.org/TR/html5/links.html#link-type-help)

interesting point. there's always a bit of leeway in interpreting link 
relation type semantics, but personally, i would "help" expect to be a 
little different than "docs", maybe more providing a helpful collection 
of resources, rather than just a list of reference materials.

cheers,

dret.

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

From superuser@gmail.com  Fri Aug 17 18:14:41 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9A221F84E4; Fri, 17 Aug 2012 18:14:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.653
X-Spam-Level: 
X-Spam-Status: No, score=-3.653 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2bG6dwo42Hz; Fri, 17 Aug 2012 18:14:40 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2656121F84DF; Fri, 17 Aug 2012 18:14:39 -0700 (PDT)
Received: by lahm15 with SMTP id m15so2494535lah.31 for ; Fri, 17 Aug 2012 18:14:39 -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:cc:content-type :content-transfer-encoding; bh=C0fZCxMBRryFGLX2CdEqe2R87tMRBBAreVjrMgCMTHc=; b=OGL/VSmRJIhThwhu4UAMKXsjGIIrAb+Zip7av0QgYCYFQ3jtAB74KJTKRvcaSpElQS JKMUA2fjA1gJhg/wOPCYOh62MQIUK/xUFHP6gXvUicWyBasuPOZTErkFL19Bw9m/792J FBYxyjvEzFDFTF4EFHZiLuXWOgXP/zE1lImp0uFEK85XdQsutgd3AuP4wVTf1KGKyaB1 3zfa1Njd1zfi6m06+na+MHURMbNoUD81tmlUNuUe/hX3AOTeFHEl8SXEDHimEY0iQehJ niIfM7A2hpyhcIdpZIz7VcAM9QUDa00zPKRht6RR1QaJANkUp9Aw4zLuVcn7c/eK4oHs 3akA==
MIME-Version: 1.0
Received: by 10.112.100.7 with SMTP id eu7mr3019694lbb.105.1345252479134; Fri, 17 Aug 2012 18:14:39 -0700 (PDT)
Received: by 10.112.9.72 with HTTP; Fri, 17 Aug 2012 18:14:39 -0700 (PDT)
Date: Fri, 17 Aug 2012 18:14:39 -0700
Message-ID: 
From: "Murray S. Kucherawy" 
To: IETF Apps Discuss , draft-sparks-genarea-mailarch.all@tools.ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: The IESG 
Subject: [apps-discuss] APPSDIR review of draft-sparks-genarea-mailarch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 01:14:41 -0000

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD (other than yourself) before posting a new version of the draft.

Document: draft-sparks-genarea-mailarch
Title: IETF Email List Archiving, Web-based Browsing and Search Tool
Requirements
Reviewer: Murray S. Kucherawy
=E2=80=A8Review Date: August 17, 2012
IETF Last Call Date: Completed August 13, 2012
=E2=80=A8IESG Telechat Date: August 30, 2012

Summary: This document proposes requirements for services that provide
web-based browsing and search of the archives of both private and
public IETF lists.

This draft is almost ready for publication as an Informational RFC but
has a few issues that should be fixed before publication.

MAJOR ISSUES:

Section 4: I think this is inadequate.  Certainly email archives have
little to do with Internet security, but there are indeed security
considerations with respect to this work in particular.  Specifically,
Section 2.1 discusses access control, and that should be at least
referenced here if not briefly discussed.  I also mention below some
things that need to be discussed in terms of what the results of a
permanent search URI would return over time as people's roles change.
We might also discuss that two different users using the same search
query might see different content depending on their respective
privileges.  I'm envisioning person X saying "As you can see from the
archive result at , A said B about C", while person Y says
"Funny, I don't see that."  Oops=E2=80=A6  And I don't know if we need to g=
et
into basic advice like "privileged communications can be revealed if
access controls are not properly checked and enforced", but it also
crossed my mind.  I'm glad, however, that this doesn't get into
prescribing specific authentication mechanisms.

MINOR ISSUES:

Section 2.1: Should the proposed system support threads that
migrate(d) among lists?

Section 2.1: The set of search properties in the fifth bullet should
probably include email address ("string occurring in sender name" to
me matches the display name specifically, not the address itself).

Section 2.1: As I mentioned above, the last bullet talks about access
restrictions.  It seems to me this is a bigger topic than just a
bullet.  For example, one's credentials change over time as one enters
and departs various roles.  That means a stable URI that represents a
thread could produce results that vary from one query to another or
one user to another (e.g., chunks of a thread or of a search result
could be present for one person but absent for another).  This might
be appropriately discussed in more length in Privacy Considerations or
Security Considerations, but it also bears discussion here.

Section 2.2: The reference to "mailman" is important, since I believe
whoever implements this stuff will be working with the mailman team to
implement or support it.  That is, this work will be the kind of thing
that would appropriately be developed in an open/free software kind of
way.  There might be some standardization work we want to do here to
make interfacing with other stuff easy in the future.  Just a note for
later, perhaps, but maybe something worth mentioning in this document.

Section 2.5: The fourth bullet is a bit cryptic to me.  Are you trying
to say the amount of traffic flying around to ensure replication
should be comparable to the amount of archive activity taking place?

NITS:

Section 1: The first paragraph is pretty big.  It could probably stand
to be broken up a bit.

Section 1: That last paragraph should be followed by an RFC Editor
note to delete it prior to publication.

Section 2.3: Last bullet is missing a trailing period.

Section 2.4: All bullets are missing trailing periods.

Section 2.5: Outermost bullet missing trailing period or colon.

Section 2.5: "Multiple active archive servers are not a requirement"
should be "Support for multiple active archive servers is not a
requirement".

Section 2.6: First and last bullets are missing trailing periods.

From nick@jigsoft.co.za  Sat Aug 18 11:45:46 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C49521F8471 for ; Sat, 18 Aug 2012 11:45:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.05
X-Spam-Level: 
X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=0.927,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p--ZsJHaT45L for ; Sat, 18 Aug 2012 11:45:45 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7820521F8467 for ; Sat, 18 Aug 2012 11:45:44 -0700 (PDT)
Received: by lbbgg6 with SMTP id gg6so2802469lbb.31 for ; Sat, 18 Aug 2012 11:45:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :x-gm-message-state; bh=Pqvu2KacB6H5DAvh3fInG78bERvpK0hGkIKEBus2VbI=; b=je+j95yhxzUux0NaWs44W4Y8cGCC062m6gEH5MoUUQ1FBD9cbKqkQiDpI3966BQgtC a0DrowivkePTWPnnDXCKKh1p9BO3jJr+gyTxR53aN2v+Fn8pubpRtSZQnXpw7mnayUAL 9UgTrsfTh8mRU3E57yrAmpoCsXyIHy5CTa3nFulvRubiWEc/HcK/5W5VJqfU6hgvo83T lrCP40HvI80Pn0+aCsiQ7KoMqJ0WvM1MsIFI/rm1Q+9+3fvz7pyWfuolLdZ7q6ldaSIB 0BQxm/S8CWTDnKI5Mx86hE5fKocRhvkbfwxIQaTvlfSwX+YrE66yvXrWLQqWqWRYiAYp He0w==
Received: by 10.112.104.3 with SMTP id ga3mr3914165lbb.77.1345315543704; Sat, 18 Aug 2012 11:45:43 -0700 (PDT)
MIME-Version: 1.0
Sender: nick@jigsoft.co.za
Received: by 10.114.71.114 with HTTP; Sat, 18 Aug 2012 11:45:23 -0700 (PDT)
In-Reply-To: <502EEB44.8070907@berkeley.edu>
References:  <502EEB44.8070907@berkeley.edu>
From: Nick Lombard 
Date: Sat, 18 Aug 2012 20:45:23 +0200
X-Google-Sender-Auth: TMvV1JwEZgAq6_MPVqyiX2taUKM
Message-ID: 
To: apps-discuss@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQn6RUWFP5vawtRDfQCi1vu/ZaQaLAjI/tCgmfD3CWtRftskjttUl8Iyo5GtBM7krN7254it
Subject: Re: [apps-discuss] feedback draft-nottingham-json-home
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 18:45:46 -0000

Hi Erik.

Thank you for the explanation apologies for any confusion. I just have
a few questions if I may:

On 18 August 2012 03:09, Erik Wilde  wrote:
> for all other link relation types used in a home document, it is up to the
> document's publisher to decide how to identify them. if people prefer URNs,
> they're free to do so, but since RFC 5988 does define link relation types to
> be identified by URI (and not URN), there really is no option to change that
> retroactively.

I was only referring to these relation type occurrences and came from
the assumption:

RFC 3986 1.1.3 URI, URL and URN concludes with
Future specifications and related documentation should use the general
term "URI" rather than the more restrictive terms "URL" and "URN" `

Which lead me to believe that URNs and URLs are collectively URIs, now
I may be wrong but since the provisions laid out in RFC 5988 for
Extension Relation Types (4.2) does not indicate a preference for any
specific URI notation therefor any notation should be allowed.

Are you saying that URI and URN are mutually exclusive or that URLs
are URIs but URNs are not? I am confused now and I thought this was
cleared up by RFC 3986, please can you explain.

Based on RFC 3986 the minimum required for a valid URI is a scheme and I quote:

RFC 3986: 3. Syntax Components
The scheme and path components are required, though the path may be empty

You may agree that relation types are nothing more than special URI
schemes registered with IANA under a different banner and since
there's several precedence of unregistered schemes in use, users may
use any word they want, as a valid custom URI scheme with empty path
representation. I also cant find any mention that new relation types
defined in I-D are compelled to be register with IANA which pose no
restriction to use URN, URL or both nor anything else you may prefer
as examples. Where did I go wrong?

Is this a general practice to allow anything to be used as the
implementer sees fit while the RFC is unable to specify nor even hint
towards the desired scope appropriately?

I found more motivations why the use of URN is more appropriate here:
 * the main reason we employ this is to have a URI that will stay
unique and not be influenced by specifics like location or transport
so that these may change without loss of integrity. URNs have none of
these influences and are immutable which makes them perfect.
 * URN has the unique ability to indicate a relation with other URNs
as can be seen in the example on the URN employed for href-vars. This
relation is not self evident when using an URL.

Although I also found something else which may pose a bigger concern in general.
How does the following excerpt affect our use of relation types here:

RFC 5988
Relation types SHOULD NOT infer any additional semantics based upon
the presence or absence of another link relation type, or its own
cardinality of occurrence.

> interesting point. there's always a bit of leeway in interpreting link
> relation type semantics, but personally, i would "help" expect to be a
> little different than "docs", maybe more providing a helpful collection of
> resources, rather than just a list of reference materials.

RFC 5988 explains in section 4.1. "Registered Relation Types" that the
"types can be registered as tokens for convenience and/or to promote
reuse" it goes on to say the name "SHOULD be appropriate to the
specificity of the relation type; [..] so that more general names are
available for less specific use.". Why would you suggest that help is
not sufficiently general enough that we would require docs as well?
What about other distinctions then, I may require tutorial, guide,
lesson, advice, assist, etc. which neither doc nor help would then
satisfy hence, are you suggesting we should registered all of these as
well?

Humbly yours...
---
nickl-

From dret@berkeley.edu  Sat Aug 18 14:20:33 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AECD21F84B9 for ; Sat, 18 Aug 2012 14:20:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tnLUWnxGIgZ for ; Sat, 18 Aug 2012 14:20:32 -0700 (PDT)
Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7DA21F84B8 for ; Sat, 18 Aug 2012 14:20:32 -0700 (PDT)
Received: from 108-67-66-127.lightspeed.sntcca.sbcglobal.net ([108.67.66.127] helo=[192.168.1.64]) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1T2qRZ-0001tp-Jl; Sat, 18 Aug 2012 14:20:30 -0700
Message-ID: <50300719.4000202@berkeley.edu>
Date: Sat, 18 Aug 2012 14:20:25 -0700
From: Erik Wilde 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References:  <502EEB44.8070907@berkeley.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] feedback draft-nottingham-json-home
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 21:20:33 -0000

hello nick.

On 2012-08-18 11:45 , Nick Lombard wrote:
> Are you saying that URI and URN are mutually exclusive or that URLs
> are URIs but URNs are not? I am confused now and I thought this was
> cleared up by RFC 3986, please can you explain.

it's actually rather simple, the most general concept is that of a URI, 
and RFC 3986 defines this concept. URIs have schemes registered with 
IANA (the list is avilable at 
http://www.iana.org/assignments/uri-schemes.html), and one of them is 
the urn: scheme, defined and (retroactively) registered by RFC 2141. RFC 
3406 adds a registry of URN namespaces managed by IANA (available at 
http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xml), 
meaning that the space of URNs how is a managed subtree of the entire 
URI tree. all of this means that a URN is nothing but a URI using the 
urn: URI scheme.

coming back to the starting point: whether a URI is considered to be 
just an identifier or something that dereferences is just a question of 
context. it's perfectly fine for URIs to not be dereferencable, and 
specs are even free (such as RFC 5988) to say that for URIs in certain 
places of the data model, no assumption about being dereferencable 
should be made. people creating identities for such a URI have the 
freedom to still use a URI that *may* be dereferencable, such as an HTTP 
URI, or they can use a URI that by definition is not dereferencable, 
such as a URN. both are valid choices, and if i were making such a 
choice, i would go with an HTTP URI and try to provide useful 
information at that URI, just in case somebody is actually typing it 
into a browser, and if i cannot do this anymore because i for example 
lost control over the DNS domain, then i could still put up an 
information page somewhere else and allow people to find it through a 
search engine.

in short, home documents will contain to classes of link relation types:

- the relation types defined by the draft/RFC will be registered with 
IANA (added to 
http://www.iana.org/assignments/link-relations/link-relations.xml once 
the RFC is published) and then will be simple keywords (i.e., no URIs).

- the relation types specific for some home document are picked by the 
publisher of the home document. two things can happen:

-- if it's just an application-specific link relation, the relation type 
MUST be a URI, but whether the publisher chooses to use HTTP URIs or 
URNs is up to the publisher. i would recommend HTTP URIs and making some 
attempt to provide information at those URIs.

-- if some concepts solidify and people are relating the same things 
over and over again, maybe some later RFC will add relation types for 
those concepts, and then those would be registered with IANA as well and 
thus would show up as simple keywords (once registered).

i hope this clarifies things a little. cheers,

dret.

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

From tony@att.com  Sat Aug 18 18:29:24 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F9221F84C8 for ; Sat, 18 Aug 2012 18:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DasGzz7f+jS7 for ; Sat, 18 Aug 2012 18:29:24 -0700 (PDT)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id D151E21F84B2 for ; Sat, 18 Aug 2012 18:29:23 -0700 (PDT)
Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 37140305.0.1556095.00-491.4188328.nbfkord-smmo05.seg.att.com (envelope-from );  Sun, 19 Aug 2012 01:29:23 +0000 (UTC)
X-MXL-Hash: 50304173397649e2-cd0d1f06e0107531b47d1775cc520edf2bef63b2
Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7J1TMEV008061 for ; Sat, 18 Aug 2012 18:29:22 -0700
Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7J1TIsI008051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 18 Aug 2012 18:29:19 -0700
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by fflint04.pst.cso.att.com (RSA Interceptor) for ; Sat, 18 Aug 2012 18:29:12 -0700
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q7J1TBSP020678 for ; Sat, 18 Aug 2012 21:29:11 -0400
Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q7J1SuKA020159 for ; Sat, 18 Aug 2012 21:29:06 -0400
Received: from [130.10.100.49] (vpn-130-10-100-49.vpn.swst.att.com[130.10.100.49]) by maillennium.att.com (mailgw1) with ESMTP id <20120819012409gw100ssp3fe> (Authid: tony); Sun, 19 Aug 2012 01:24:10 +0000
X-Originating-IP: [130.10.100.49]
Message-ID: <50304156.7070803@att.com>
Date: Sat, 18 Aug 2012 21:28:54 -0400
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
References: <502A21A2.8060106@isode.com> <502CEC1D.3010301@att.com> <502CEE3C.3010107@isode.com> <01OJ46MC14UA0006TF@mauve.mrochek.com> <502E38CD.2050107@isode.com> <01OJ5GAZWQ9A0006TF@mauve.mrochek.com>
In-Reply-To: <01OJ5GAZWQ9A0006TF@mauve.mrochek.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.128.153]
X-AnalysisOut: [v=1.0 c=1 a=vnPmt6Ynl7YA:10 a=70aWqWLk7fkA:10 a=-FENsoGZWg]
X-AnalysisOut: [0A:10 a=ofMgfj31e3cA:10 a=ou5xGSR4Oo8A:10 a=BLceEmwcHowA:1]
X-AnalysisOut: [0 a=8nJEP1OIZ-IA:10 a=Sn-rFn1Yn5UA:10 a=xwOvzTHDVLE4u4nGvK]
X-AnalysisOut: [72ag==:17 a=X894FsJYFGpQU1HcRWEA:9 a=wPNLvfGTeEIA:10]
Subject: [apps-discuss] Need discussion of fragment identifier precedence for draft-ietf-appsawg-media-type-suffix-regs
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 01:29:24 -0000

On 8/17/2012 10:11 AM, Ned Freed wrote:
> Alexey Melnikov wrote:
>> My primary preference is to change the order to make sure that the rules
>> for xxx/yyy+foo apply first and only for cases not covered the rules for
>> +foo apply. This wouldn't prevent the situation where additional rules
>> are introduced in +foo which are not covered by xxx/yyy+foo, but it will
>> at least keep the fragment identifier rules explicitly defined in
>> xxx/yyy+foo stable.
>
> The problem here is you're now trading one problem for another. As I 
> understand
> it, getting common semantics across fragement identifiers for 
> different types
> has been a signficant issue, and this ordering is intended to address 
> that by
> making it harder for specific types to override general rules. (Note that
> it is still trivial to do so simply by writing a registration that 
> explicitly
> overrides the ordering.)
>
> I see both sides so I have no real preference either way, but those 
> who are
> trying to get some degree of consistenty in fragement identifier handling
> may have a different opinion.

Since I wrote the text the way I did, I obviously fell on the side of 
the common semantics across fragment identifiers having precedence.

I would like to hear input from others on this issue.

     Tony Hansen


From tony@att.com  Sat Aug 18 18:37:07 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6AD21F84C8 for ; Sat, 18 Aug 2012 18:37:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NRaFEwsi2Qz for ; Sat, 18 Aug 2012 18:37:06 -0700 (PDT)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 537D221F84B2 for ; Sat, 18 Aug 2012 18:37:06 -0700 (PDT)
Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 14340305.0.1556801.00-329.4190164.nbfkord-smmo05.seg.att.com (envelope-from );  Sun, 19 Aug 2012 01:37:06 +0000 (UTC)
X-MXL-Hash: 503043426f0ff3c4-1a8c705c776b9813500be58febb9747c6ea7c23a
Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7J1b5S8012847 for ; Sat, 18 Aug 2012 18:37:05 -0700
Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7J1ag7w012694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 18 Aug 2012 18:36:57 -0700
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by fflint03.pst.cso.att.com (RSA Interceptor) for ; Sat, 18 Aug 2012 18:36:06 -0700
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q7J1a3iX001792 for ; Sat, 18 Aug 2012 21:36:04 -0400
Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q7J1Ztad001478 for ; Sat, 18 Aug 2012 21:35:57 -0400
Received: from [130.10.100.49] (vpn-130-10-100-49.vpn.swst.att.com[130.10.100.49]) by maillennium.att.com (mailgw1) with ESMTP id <20120819013109gw100ssp3ge> (Authid: tony); Sun, 19 Aug 2012 01:31:09 +0000
X-Originating-IP: [130.10.100.49]
Message-ID: <503042F9.7000201@att.com>
Date: Sat, 18 Aug 2012 21:35:53 -0400
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
References: <502A21A2.8060106@isode.com> <502CEC1D.3010301@att.com> <502CEE3C.3010107@isode.com> <01OJ46MC14UA0006TF@mauve.mrochek.com> <502E38CD.2050107@isode.com> <01OJ5GAZWQ9A0006TF@mauve.mrochek.com>
In-Reply-To: <01OJ5GAZWQ9A0006TF@mauve.mrochek.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.128.153]
X-AnalysisOut: [v=1.0 c=1 a=vnPmt6Ynl7YA:10 a=70aWqWLk7fkA:10 a=1wm54zsoFk]
X-AnalysisOut: [4A:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:1]
X-AnalysisOut: [0 a=rgBHSbq96rgA:10 a=xwOvzTHDVLE4u4nGvK72ag==:17 a=TJNNTf]
X-AnalysisOut: [CLSGOwJUdNk_YA:9 a=wPNLvfGTeEIA:10]
Subject: Re: [apps-discuss] Bilated issue with draft-ietf-appsawg-media-type-suffix-regs-02.txt: fragment identifier rules
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 01:37:07 -0000

On 8/17/2012 10:11 AM, Ned Freed wrote:
> Alexey Melnikov wrote:
> ...
>> In addition, something along the following lines should be added
>> (irrespectively of whether my suggestion above is used or not):
>
>> I don't know where this should be stated, registration templates don't
>> seem to be the right place for this information:
>
> Yes, this particular part really belongs in the registration document, 
> but it
> is too late for that.
>
>> NEW:
>> When updating a +suffix registration care should be taken to review all
>> previously registered xxx/yyy+suffix media types regarding whether they
>> might be affected by the updated +suffix registration.
>
> Seems OK to me, but this is Tony's call, not mine.

I can work this in somewhere. Based on the discussion on fragment 
identifier precedence, I might choose my suggested wording from an 
earlier email instead.

     Tony Hansen

From GK@ninebynine.org  Mon Aug 20 02:56:29 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6EC21F86E4 for ; Mon, 20 Aug 2012 02:56:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.678
X-Spam-Level: 
X-Spam-Status: No, score=-6.678 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4X2giTfoJso for ; Mon, 20 Aug 2012 02:56:29 -0700 (PDT)
Received: from relay8.mail.ox.ac.uk (relay8.mail.ox.ac.uk [129.67.1.171]) by ietfa.amsl.com (Postfix) with ESMTP id DB6F821F86EF for ; Mon, 20 Aug 2012 02:56:28 -0700 (PDT)
Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay8.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1T3Oig-0000uo-Sx; Mon, 20 Aug 2012 10:56:26 +0100
Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1T3Oig-0005qH-8l; Mon, 20 Aug 2012 10:56:26 +0100
Message-ID: <5031FA92.2030700@ninebynine.org>
Date: Mon, 20 Aug 2012 09:51:30 +0100
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Peter Saint-Andre 
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im>
In-Reply-To: <502D3C2B.3040900@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 09:56:29 -0000

On 16/08/2012 19:30, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 8/15/12 3:47 AM, Graham Klyne wrote:
>> ref: http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-00
>>
>> I'm uneasy about:
>>
>> [[ 4.4.  URI Scheme Semantics
>>
>> The 'acct' URI scheme is used to identify user accounts hosted at
>> service providers.  It is used only for identification, not
>> interaction.  A protocol that uses the 'acct' URI scheme is
>> responsible for specifying how an 'acct' URI is to be dereferenced
>> in the context of that protocol.  There is no media type associated
>> with the 'acct' URI scheme. ]]
>>
>> Specifically, the bit about "protocol that uses the acct URI
>> scheme".
>>
>> My understanding was that the intent was that acct: would be
>> dereferenced using the WebFinger protocol.  If there is no such
>> expectation, then an acct: URI appearing in isolation (e.g. in a
>> web page or some document) has no actionable meaning.
>
> My understanding, which I tried to capture in the document, was that
> some folks here thought that acct URIs might be used by other
> protocols. If there is consensus that acct URIs will be used only for
> WebFinger, I am happy to update the document accordingly. I'm truly
> just acting in an editorial capacity on this document.

I certainly understand that the intent is that acct: URIs can be used *with* 
other protocols, it's just that I also understood the standard dereferencing 
mechanism (or, if you like, the definitive identification semantics) is defined 
by the WebFinger protocol.

An example for comparison: the standard dereferencing semantics for an ftp: URI 
is to use the FTP protocol, but an ftp: URI can be used with the HTTP protocol.

#g
--

From rjsparks@nostrum.com  Mon Aug 20 11:49:13 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BC711E808E; Mon, 20 Aug 2012 11:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJtN+g3hTiP7; Mon, 20 Aug 2012 11:49:12 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 48CE911E808D; Mon, 20 Aug 2012 11:49:12 -0700 (PDT)
Received: from unnumerable.local ([4.30.77.1]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q7KIn7Ck014727 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 20 Aug 2012 13:49:07 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Message-ID: <503286A3.2010109@nostrum.com>
Date: Mon, 20 Aug 2012 13:49:07 -0500
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: "Murray S. Kucherawy" 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010107050108050904000502"
Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism)
Cc: draft-sparks-genarea-mailarch.all@tools.ietf.org, IETF Apps Discuss , The IESG 
Subject: Re: [apps-discuss] APPSDIR review of draft-sparks-genarea-mailarch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 18:49:13 -0000

This is a multi-part message in MIME format.
--------------010107050108050904000502
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Thanks Murray -

Comments inline:

On 8/17/12 8:14 PM, Murray S. Kucherawy wrote:
> I have been selected as the Applications Area Directorate reviewer for
> this draft (for background on appsdir, please see
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
>
> Please resolve these comments along with any other Last Call comments
> you may receive. Please wait for direction from your document shepherd
> or AD (other than yourself) before posting a new version of the draft.
>
> Document: draft-sparks-genarea-mailarch
> Title: IETF Email List Archiving, Web-based Browsing and Search Tool
> Requirements
> Reviewer: Murray S. Kucherawy
> 
Review Date: August 17, 2012
> IETF Last Call Date: Completed August 13, 2012
> 
IESG Telechat Date: August 30, 2012
>
> Summary: This document proposes requirements for services that provide
> web-based browsing and search of the archives of both private and
> public IETF lists.
>
> This draft is almost ready for publication as an Informational RFC but
> has a few issues that should be fixed before publication.
>
> MAJOR ISSUES:
>
> Section 4: I think this is inadequate.  Certainly email archives have
> little to do with Internet security, but there are indeed security
> considerations with respect to this work in particular.  Specifically,
> Section 2.1 discusses access control, and that should be at least
> referenced here if not briefly discussed.  I also mention below some
> things that need to be discussed in terms of what the results of a
> permanent search URI would return over time as people's roles change.
> We might also discuss that two different users using the same search
> query might see different content depending on their respective
> privileges.  I'm envisioning person X saying "As you can see from the
> archive result at , A said B about C", while person Y says
> "Funny, I don't see that."  Oops…  And I don't know if we need to get
> into basic advice like "privileged communications can be revealed if
> access controls are not properly checked and enforced", but it also
> crossed my mind.  I'm glad, however, that this doesn't get into
> prescribing specific authentication mechanisms.
We already call out that the results of a search can change over time with
this text:
>       -  The search may be re-executed when the URI is referenced.  It
>          is acceptable for the same URI to produce different results if
>          accessed at different times (reflecting additional messages
>          that may match the search criteria for example.)
I can expand this as follows:

       -  The search may be re-executed when the URI is referenced.  It
          is acceptable for the same URI to produce different results if
          accessed at different times or by different people (for example,
          by reflecting additional messages that may match the search
          criteria, or reflecting changes in access authorization to
          lists with restricted archives.)


>
> MINOR ISSUES:
>
> Section 2.1: Should the proposed system support threads that
> migrate(d) among lists?
We already require searching across multiple lists, and require browsing 
by thread.
To the extent that enough information is present to correlate the 
messages in threads
that hopped lists this ability should fall out of the requirements we 
already have.
>
> Section 2.1: The set of search properties in the fifth bullet should
> probably include email address ("string occurring in sender name" to
> me matches the display name specifically, not the address itself).
I can s/sender name/email address or sender name/

>
> Section 2.1: As I mentioned above, the last bullet talks about access
> restrictions.  It seems to me this is a bigger topic than just a
> bullet.  For example, one's credentials change over time as one enters
> and departs various roles.  That means a stable URI that represents a
> thread could produce results that vary from one query to another or
> one user to another (e.g., chunks of a thread or of a search result
> could be present for one person but absent for another).  This might
> be appropriately discussed in more length in Privacy Considerations or
> Security Considerations, but it also bears discussion here.
I think my suggestion above makes this clear. If you think more is still
needed, what additional discussion do you think would be useful for someone
putting this system together?
>
> Section 2.2: The reference to "mailman" is important, since I believe
> whoever implements this stuff will be working with the mailman team to
> implement or support it.  That is, this work will be the kind of thing
> that would appropriately be developed in an open/free software kind of
> way.  There might be some standardization work we want to do here to
> make interfacing with other stuff easy in the future.  Just a note for
> later, perhaps, but maybe something worth mentioning in this document.
I'm not seeing an obvious place to call this aspect out. Are you ok with
keeping this in mind as a note for later as you suggest?
>
> Section 2.5: The fourth bullet is a bit cryptic to me.  Are you trying
> to say the amount of traffic flying around to ensure replication
> should be comparable to the amount of archive activity taking place?
Yes. Would it help to
s/The amount of data replication between/The amount of data replicated 
between/
?
>
> NITS:

>
> Section 1: The first paragraph is pretty big.  It could probably stand
> to be broken up a bit.
OK
>
> Section 1: That last paragraph should be followed by an RFC Editor
> note to delete it prior to publication.
I'll delete it before it goes into the RFC Editor queue
>
> Section 2.3: Last bullet is missing a trailing period.
>
> Section 2.4: All bullets are missing trailing periods.
>
> Section 2.5: Outermost bullet missing trailing period or colon.
I'll make all of these consistent
>
> Section 2.5: "Multiple active archive servers are not a requirement"
> should be "Support for multiple active archive servers is not a
> requirement".
ok
>
> Section 2.6: First and last bullets are missing trailing periods.
ack.


RjS

--------------010107050108050904000502
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Thanks Murray - 

      

      Comments inline:

      

      On 8/17/12 8:14 PM, Murray S. Kucherawy wrote:

    

    

      
I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD (other than yourself) before posting a new version of the draft.

Document: draft-sparks-genarea-mailarch
Title: IETF Email List Archiving, Web-based Browsing and Search Tool
Requirements
Reviewer: Murray S. Kucherawy

Review Date: August 17, 2012
IETF Last Call Date: Completed August 13, 2012

IESG Telechat Date: August 30, 2012

Summary: This document proposes requirements for services that provide
web-based browsing and search of the archives of both private and
public IETF lists.

This draft is almost ready for publication as an Informational RFC but
has a few issues that should be fixed before publication.

MAJOR ISSUES:

Section 4: I think this is inadequate.  Certainly email archives have
little to do with Internet security, but there are indeed security
considerations with respect to this work in particular.  Specifically,
Section 2.1 discusses access control, and that should be at least
referenced here if not briefly discussed.  I also mention below some
things that need to be discussed in terms of what the results of a
permanent search URI would return over time as people's roles change.
We might also discuss that two different users using the same search
query might see different content depending on their respective
privileges.  I'm envisioning person X saying "As you can see from the
archive result at <URI>, A said B about C", while person Y says
"Funny, I don't see that."  Oops…  And I don't know if we need to get
into basic advice like "privileged communications can be revealed if
access controls are not properly checked and enforced", but it also
crossed my mind.  I'm glad, however, that this doesn't get into
prescribing specific authentication mechanisms.

    

    We already call out that the results of a search can change over
    time with

    this text:

    

      
      
            -  The search may be re-executed when the URI is
      referenced.  It

               is acceptable for the same URI to produce different
      results if

               accessed at different times (reflecting additional
      messages

               that may match the search criteria for example.)

    I can expand this as follows:

    
    
      -  The search may be re-executed when the URI is referenced.  It
         is acceptable for the same URI to produce different results if
         accessed at different times or by different people (for example,
         by reflecting additional messages that may match the search 
         criteria, or reflecting changes in access authorization to 
         lists with restricted archives.)

    

    

      

MINOR ISSUES:

Section 2.1: Should the proposed system support threads that
migrate(d) among lists?

    

    We already require searching across multiple lists, and require
    browsing by thread.

    To the extent that enough information is present to correlate the
    messages in threads

    that hopped lists this ability should fall out of the requirements
    we already have.

    

      

Section 2.1: The set of search properties in the fifth bullet should
probably include email address ("string occurring in sender name" to
me matches the display name specifically, not the address itself).

    

    I can s/sender name/email address or sender name/

    

    

      

Section 2.1: As I mentioned above, the last bullet talks about access
restrictions.  It seems to me this is a bigger topic than just a
bullet.  For example, one's credentials change over time as one enters
and departs various roles.  That means a stable URI that represents a
thread could produce results that vary from one query to another or
one user to another (e.g., chunks of a thread or of a search result
could be present for one person but absent for another).  This might
be appropriately discussed in more length in Privacy Considerations or
Security Considerations, but it also bears discussion here.

    

    I think my suggestion above makes this clear. If you think more is
    still

    needed, what additional discussion do you think would be useful for
    someone 

    putting this system together?

    

      

Section 2.2: The reference to "mailman" is important, since I believe
whoever implements this stuff will be working with the mailman team to
implement or support it.  That is, this work will be the kind of thing
that would appropriately be developed in an open/free software kind of
way.  There might be some standardization work we want to do here to
make interfacing with other stuff easy in the future.  Just a note for
later, perhaps, but maybe something worth mentioning in this document.

    

    I'm not seeing an obvious place to call this aspect out. Are you ok
    with

    keeping this in mind as a note for later as you suggest?

    

      

Section 2.5: The fourth bullet is a bit cryptic to me.  Are you trying
to say the amount of traffic flying around to ensure replication
should be comparable to the amount of archive activity taking place?

    

    Yes. Would it help to 

    s/The amount of data replication between/The amount of data
    replicated between/

    ?

    

      

NITS:

    

    

    

      

Section 1: The first paragraph is pretty big.  It could probably stand
to be broken up a bit.

    

    OK

    

      

Section 1: That last paragraph should be followed by an RFC Editor
note to delete it prior to publication.

    

    I'll delete it before it goes into the RFC Editor queue

    

      

Section 2.3: Last bullet is missing a trailing period.

Section 2.4: All bullets are missing trailing periods.

Section 2.5: Outermost bullet missing trailing period or colon.

    

    I'll make all of these consistent
    

      

Section 2.5: "Multiple active archive servers are not a requirement"
should be "Support for multiple active archive servers is not a
requirement".

    

    ok

    

      

Section 2.6: First and last bullets are missing trailing periods.


    

    ack.

    

    

    RjS

  


--------------010107050108050904000502--

From nick@jigsoft.co.za  Mon Aug 20 13:01:09 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8F611E808A for ; Mon, 20 Aug 2012 13:01:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.059
X-Spam-Level: 
X-Spam-Status: No, score=-1.059 tagged_above=-999 required=5 tests=[AWL=-0.682, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EK8q8oLcJaX0 for ; Mon, 20 Aug 2012 13:01:08 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 85A6F21F8577 for ; Mon, 20 Aug 2012 13:01:08 -0700 (PDT)
Received: by lbbgg6 with SMTP id gg6so3709373lbb.31 for ; Mon, 20 Aug 2012 13:01:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=tq2qYLxMGQY30gfzyEp7fdLKcmBXq+6fdWZT0Gb5yew=; b=i+ApUPve/a6S22R4O8hxvu6MYbzJWb5Pc5JW9xOBoiHIYgEJs9ITgDl2O2/UipB68B x5A95GWQj7AAi/XEZ2PqhhUKDFc0FYUj1QwBVNd7PZlEbbySC1JTf9diLbnzOWAxhOSc Nxd6/kh5sohymuoXp7c2cTwMK7vnBNsLNdt5I6+NgheYUzi5Utw4QqB77BD+fuBOz9KE 1t5EQQ6IN68IPuNBHOmIY0p2e4pN8xKfxveS5aUEQ/lIW8F+cjySqP5GLmfaE/sQRiKB XJYGvdc78utMVZaYd1X5B7JfBNu1bnmPKdyuXCVwmb69d3o3rtcO+PleXqcqRTD4hn20 U+Gg==
Received: by 10.112.37.102 with SMTP id x6mr6454128lbj.66.1345492867028; Mon, 20 Aug 2012 13:01:07 -0700 (PDT)
MIME-Version: 1.0
Sender: nick@jigsoft.co.za
Received: by 10.114.71.114 with HTTP; Mon, 20 Aug 2012 13:00:46 -0700 (PDT)
In-Reply-To: <50300719.4000202@berkeley.edu>
References:  <502EEB44.8070907@berkeley.edu>  <50300719.4000202@berkeley.edu>
From: Nick Lombard 
Date: Mon, 20 Aug 2012 22:00:46 +0200
X-Google-Sender-Auth: NGpfk_VyRcjyZjwZXCYmefyEo4w
Message-ID: 
To: Erik Wilde 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQk0gtKa5hn2k6Sl47iLj36BOJSG+mHqM7VZMIBclydiCEHda/QR/W+xI1JODE7F7Asep1tK
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] feedback draft-nottingham-json-home
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 20:01:09 -0000

Hi Erik,

The way you manage to explain things is truly inspiring. Thank you again.

Although these concepts may come easy for us its not like that for
Everyman though. There seems to be an emergent pattern of misgiving,
as can be seen in the following example, for HTTP URI as link
relations, you may have noticed this as well. Several equally valid
examples exist, by no means should this be considered unique or
exceptional.

http://bill.burkecentral.com/2012/05/11/json-home-format-resource-discovery/

The original motivation behind my post is still to raise awareness of
this anomaly and to discuss plausible strategies for breaching the
gap.

> no assumption about being dereferencable should be made.

Delusion to deny that a preconceived notion exist of what http://,
ftp:// or mailto:// means to Everyman. We've heard the saying "What
does it do?" or "What application can I use to open it?" about less
known URI like rtsp:// for example. So strong an expectation it should
do something that unresolvable is considered broken.

I am not suggesting we change the design or adopt the popular fallacy,
only that we recognise the memes and make every effort to facilitate
comprehension. I believe through slightly more elaborate example
represented by the most adaptable forms available  would go a long way
to avoid confusion, embarrassment or worst, incorrect adoption, when
attempting to contradict establishment.

Comparing the following two examples:

1. HTTP URI
{
    "resources": {
      "http://example.org/rel/widgets": {
        "href": "/widgets/"
      },
      "http://example.org/rel/widget": {
        "href-template": "/widgets/{widget_id}",
        "href-vars": {
          "widget_id": "http://example.org/param/widget"
        }
}


2. URN
{
    "resources": {
      "urn:exampleorg:widgets": {
        "href": "/widgets/"
      },
      "urn:exampleorg:widget": {
        "href-template": "/widgets/{widget_id}",
        "href-vars": {
          "widget_id": "urn:exampleorg:param@widgets"
        }
}

Would you agree that the 1st example poses more cognitive resistance
than the 2nd. After smoothing the transition by presenting #2 first we
may have more success explaining the purpose of URI, that it may or
may not be dereferencable and that we actually recommend the use of an
HTTP URI instead, but don't avoid elaborating why. Maybe a suggestion
of what an appropriate response lookup may produce. Avoidance would
only risk anxiety but alleviate the uncertainty and we may just foster
the creativity we were after in the first place. Following this up
with a more elaborate example may even employ HTTP URI without
bewildering the audience.

To conclude: I am only referring to what Erik so skilfully dubbed "the
relation types specific for some home document" and not any other link
relation types referenced by this I-D. I am only suggesting the use of
the most appropriate medium to get the correct message across not that
we change the message. I am asking that we be conscious of the
established understanding and to take extra precautions when trying to
influence them.

The goal: To get the desired message across with the least amount of
resistance or room for misinterpretation.

Keep up the good work, your legacy is shaping our futures and we owe
you a debt of gratitude. Much appreciated.

Regards,
nickl-

From julian.reschke@gmx.de  Tue Aug 21 02:09:06 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F3321F86B7 for ; Tue, 21 Aug 2012 02:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjM3d1jESwzK for ; Tue, 21 Aug 2012 02:09:04 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5C3AC21F86B8 for ; Tue, 21 Aug 2012 02:09:03 -0700 (PDT)
Received: (qmail invoked by alias); 21 Aug 2012 09:08:59 -0000
Received: from unknown (EHLO [42.1.2.98]) [192.147.117.12] by mail.gmx.net (mp036) with SMTP; 21 Aug 2012 11:08:59 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18qX4FIRmoqr8IguK8Jv+RlOJQP14uBE8dOCED4si MyT5l/EHMM1MnX
Message-ID: <50335023.2080300@gmx.de>
Date: Tue, 21 Aug 2012 11:08:51 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: IETF Apps Discuss 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Subject: [apps-discuss] Feedback on draft-ietf-appsawg-json-pointer-03
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 09:09:06 -0000

Hi.

first of all: thanks Mark for taking over.

Below are a few comments...:

>    This specification expresses normative syntax rules using Augmented
>    Backus-Naur Form [RFC5234] (ABNF) notation.

s/[RFC5234] (ABNF)/(ABNF) [RFC5234]/

>    If a reference token contains '~' (%x7E) or '/' (%x2F) characters,
>    they MUST be encoded as '~0' and '~1' respectively.

I'd prefer this to be a statement of fact, not a requirement. Such as:

"As the characters '~' (%x7E) and '/' (%x2F) characters have a special 
meaning in JSON pointer and thus need to be encoded as'~0' and '~1' 
respectively."

>       If the currently referenced value is a JSON object, the new
>       referenced value is the object member with the name (after
>       unescaping any backslash escape sequences that can occur in a JSON
>       string) identified by the reference token.  The member name is

What unescaping does this refer to? Is this about JSON Pointers 
transported inside JSON string values? In that case I think this should 
be dropped; it's not relevant here. (JSON Pointer in JSON strings is 
first mentioned in the following section).

>    A JSON Pointer can be represented in a JSON string value.  Per
>    [RFC4627], section 2.5, all instances of quotation mark '"' (%x22),

s/section/Section/

>    A JSON Pointer can be represented in a URI fragment identifier. by
>    encoding it into octets, using UTF-8 [RFC3629], percent-encoding
>    those characters not allowed by the fragment rule in [RFC3986].

s/identifier. by/identifier by/

>    Note that a given media type needs to nominate JSON Pointer as its
>    fragment identifier syntax explicitly (usually, in its registration
>    [RFC4288]); i.e., just because a document is JSON does not imply that
>    JSON Pointer can be used as its fragment identifier syntax.

I think it would be good to make it very clear that the current 
definition of JSON does NOT define a fragment identifier syntax.

>    [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
>               Registration Procedures", BCP 13, RFC 4288, December 2005.

This should reference draft-ietf-appsawg-media-type-regs-14 which is 
already in the RFC publication queue.

Best regards, Julian


From superuser@gmail.com  Tue Aug 21 11:29:07 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F8E21F86C3; Tue, 21 Aug 2012 11:29:07 -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=[AWL=-0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOcFP3URXpxH; Tue, 21 Aug 2012 11:29:06 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1940C21F86C8; Tue, 21 Aug 2012 11:29:05 -0700 (PDT)
Received: by lbbgg6 with SMTP id gg6so153434lbb.31 for ; Tue, 21 Aug 2012 11:29:04 -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=y9toMdXRB2wNusZ1MCvPOFXEdGEQ8fCB9iRTQi6WJ2I=; b=MGgfkAijiTC0Gmm6K41fVONJEb6mmEJXsWTKCDEktempqhDDn1uMb2dXNmVc1FGE62 2TWRh0TuVxUpiNGZpDjdbSg+kZ7cpTi7YMnEkz/4mtUAOgEzK1gQAQcDvofBB9fJO/KG VUOGpSJFxWkoOIO7M2B6k0V7NJkWLUFyuRcHQL63qCojfHF1yETNF8HxNnqKHWuINGOC Vr9vk2lClLoAg6JKbTzxXHuzAv7pOyrtmin3zvRxqzEDprhpKn0pAcrvZzT1xve/o/Hq YmMugS+TRqvgZZD+ca3tZbfWIPnTdikBDNUzqR9r2Tmzl7lrb3S1Z08TlFjavZBwpGvY g6Iw==
MIME-Version: 1.0
Received: by 10.152.146.67 with SMTP id ta3mr18514919lab.27.1345573744686; Tue, 21 Aug 2012 11:29:04 -0700 (PDT)
Received: by 10.112.9.72 with HTTP; Tue, 21 Aug 2012 11:29:04 -0700 (PDT)
In-Reply-To: <503286A3.2010109@nostrum.com>
References:  <503286A3.2010109@nostrum.com>
Date: Tue, 21 Aug 2012 11:29:04 -0700
Message-ID: 
From: "Murray S. Kucherawy" 
To: Robert Sparks 
Content-Type: text/plain; charset=ISO-8859-1
Cc: draft-sparks-genarea-mailarch.all@tools.ietf.org, IETF Apps Discuss , The IESG 
Subject: Re: [apps-discuss] APPSDIR review of draft-sparks-genarea-mailarch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 18:29:07 -0000

On Mon, Aug 20, 2012 at 11:49 AM, Robert Sparks  wrote:
> I can expand this as follows:
>
>       -  The search may be re-executed when the URI is referenced.  It
>          is acceptable for the same URI to produce different results if
>          accessed at different times or by different people (for example,
>          by reflecting additional messages that may match the search
>          criteria, or reflecting changes in access authorization to
>          lists with restricted archives.)

Yes, please.  Thanks!

> MINOR ISSUES:
>
> Section 2.1: Should the proposed system support threads that
> migrate(d) among lists?
>
> We already require searching across multiple lists, and require browsing by
> thread.
> To the extent that enough information is present to correlate the messages
> in threads
> that hopped lists this ability should fall out of the requirements we
> already have.

OK.  Just wanted to make sure it was considered.

> Section 2.1: The set of search properties in the fifth bullet should
> probably include email address ("string occurring in sender name" to
> me matches the display name specifically, not the address itself).
>
> I can s/sender name/email address or sender name/

Great.

> Section 2.1: As I mentioned above, the last bullet talks about access
> restrictions.  It seems to me this is a bigger topic than just a
> bullet.  For example, one's credentials change over time as one enters
> and departs various roles.  That means a stable URI that represents a
> thread could produce results that vary from one query to another or
> one user to another (e.g., chunks of a thread or of a search result
> could be present for one person but absent for another).  This might
> be appropriately discussed in more length in Privacy Considerations or
> Security Considerations, but it also bears discussion here.
>
> I think my suggestion above makes this clear. If you think more is still
> needed, what additional discussion do you think would be useful for someone
> putting this system together?

I think my remaining concern has to do with the fact that two
different users executing the same query URI get different views.  I
know you've pointed out that this can happen, but I imagine it would
be a good idea to require that the service show privileged users a
warning that their view might (or does) include content that others
won't see.

> Section 2.2: The reference to "mailman" is important, since I believe
> whoever implements this stuff will be working with the mailman team to
> implement or support it.  That is, this work will be the kind of thing
> that would appropriately be developed in an open/free software kind of
> way.  There might be some standardization work we want to do here to
> make interfacing with other stuff easy in the future.  Just a note for
> later, perhaps, but maybe something worth mentioning in this document.
>
> I'm not seeing an obvious place to call this aspect out. Are you ok with
> keeping this in mind as a note for later as you suggest?

Yes, that was more of a stream-of-consciousness remark than an
actionable thing.  I don't know that we can require that our system be
produced open source in this document, though it would be nice.

> Section 2.5: The fourth bullet is a bit cryptic to me.  Are you trying
> to say the amount of traffic flying around to ensure replication
> should be comparable to the amount of archive activity taking place?
>
> Yes. Would it help to
> s/The amount of data replication between/The amount of data replicated
> between/
>
> ?

How about:

The amount of traffic generated to ensure data replicated between...?

-MSK

From stpeter@stpeter.im  Thu Aug 23 09:22:10 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A45921F860B for ; Thu, 23 Aug 2012 09:22:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.572
X-Spam-Level: 
X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wi4qfaoj4hq for ; Thu, 23 Aug 2012 09:22:09 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D447F21F8611 for ; Thu, 23 Aug 2012 09:22:09 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 38BBB404EA; Thu, 23 Aug 2012 10:23:02 -0600 (MDT)
Message-ID: <503658B0.2090303@stpeter.im>
Date: Thu, 23 Aug 2012 10:22:08 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Graham Klyne 
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> <5031FA92.2030700@ninebynine.org>
In-Reply-To: <5031FA92.2030700@ninebynine.org>
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 16:22:10 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/20/12 2:51 AM, Graham Klyne wrote:
> On 16/08/2012 19:30, Peter Saint-Andre wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 8/15/12 3:47 AM, Graham Klyne wrote:
>>> ref: http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-00
>>> 
>>> I'm uneasy about:
>>> 
>>> [[ 4.4.  URI Scheme Semantics
>>> 
>>> The 'acct' URI scheme is used to identify user accounts hosted
>>> at service providers.  It is used only for identification, not 
>>> interaction.  A protocol that uses the 'acct' URI scheme is 
>>> responsible for specifying how an 'acct' URI is to be
>>> dereferenced in the context of that protocol.  There is no
>>> media type associated with the 'acct' URI scheme. ]]
>>> 
>>> Specifically, the bit about "protocol that uses the acct URI 
>>> scheme".
>>> 
>>> My understanding was that the intent was that acct: would be 
>>> dereferenced using the WebFinger protocol.  If there is no
>>> such expectation, then an acct: URI appearing in isolation
>>> (e.g. in a web page or some document) has no actionable
>>> meaning.
>> 
>> My understanding, which I tried to capture in the document, was
>> that some folks here thought that acct URIs might be used by
>> other protocols. If there is consensus that acct URIs will be
>> used only for WebFinger, I am happy to update the document
>> accordingly. I'm truly just acting in an editorial capacity on
>> this document.
> 
> I certainly understand that the intent is that acct: URIs can be
> used *with* other protocols, it's just that I also understood the
> standard dereferencing mechanism (or, if you like, the definitive
> identification semantics) is defined by the WebFinger protocol.
> 
> An example for comparison: the standard dereferencing semantics for
> an ftp: URI is to use the FTP protocol, but an ftp: URI can be used
> with the HTTP protocol.

Graham, thank you for drawing the distinction between using acct URIs
and dereferencing acct URIs. I have not yet heard of anyone proposing
to dereference acct URIs using technologies other than WebFinger,
although if the Simple Web Discovery work
(draft-jones-simple-web-discovery) continues independently then it
seems possible that acct URIs might be derefenced using that
technology. For example :

   GET /.well-known/simple-web-discovery
       ?principal=acct:joe@example.com
       &service=urn:example:service:calendar HTTP/1.1
   Host: example.com

   HTTP/1.1 200 OK
   Content-Type: application/json

   {
    "locations": ["https://calendars.example.net/calendars/joseph"]
   }

Clarification would be appreciated from folks on this list. I just
hold the editing pen on this one.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlA2WLAACgkQNL8k5A2w/vzH1wCgq3cDQ5sRSEhSC4+0dXO49I5a
2YcAoOhjwRrlZkOZEFPgDFIvp+9WNVTb
=1/UL
-----END PGP SIGNATURE-----

From Michael.Jones@microsoft.com  Thu Aug 23 11:49:46 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEEF21F84E4 for ; Thu, 23 Aug 2012 11:49:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.837
X-Spam-Level: 
X-Spam-Status: No, score=-3.837 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7ZuxLxNlCVE for ; Thu, 23 Aug 2012 11:49:45 -0700 (PDT)
Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id A6A3921F8621 for ; Thu, 23 Aug 2012 11:49:44 -0700 (PDT)
Received: from mail70-db3-R.bigfish.com (10.3.81.233) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 23 Aug 2012 18:49:43 +0000
Received: from mail70-db3 (localhost [127.0.0.1])	by mail70-db3-R.bigfish.com (Postfix) with ESMTP id 086623E00C0; Thu, 23 Aug 2012 18:49:43 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-SpamScore: -37
X-BigFish: VS-37(zzbb2dI98dI154cP9371I542M1432Izz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah107ah1155h)
Received-SPF: pass (mail70-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail70-db3 (localhost.localdomain [127.0.0.1]) by mail70-db3 (MessageSwitch) id 1345747781682676_31830; Thu, 23 Aug 2012 18:49:41 +0000 (UTC)
Received: from DB3EHSMHS003.bigfish.com (unknown [10.3.81.248])	by mail70-db3.bigfish.com (Postfix) with ESMTP id A3BFA3C004D; Thu, 23 Aug 2012 18:49:41 +0000 (UTC)
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS003.bigfish.com (10.3.87.103) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 23 Aug 2012 18:49:39 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.176]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Thu, 23 Aug 2012 18:49:36 +0000
From: Mike Jones 
To: Peter Saint-Andre , Graham Klyne 
Thread-Topic: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
Thread-Index: AQHNesvs8vKnlOUTjUOINpvGHWreOpdcxLWAgAWnrgCABTTmAIAAJjzg
Date: Thu, 23 Aug 2012 18:49:36 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> <5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im>
In-Reply-To: <503658B0.2090303@stpeter.im>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.71]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 18:49:46 -0000

Yes, SWD could make use of an acct: URI, should one be approved, and should=
 SWD continue to be used.  SWD's current solution to not having an acct: ur=
i is to allow bare identifiers such as "joe@example.com" or simply "joe" to=
 be used as the principal value.  (I'm not saying that I want there to cont=
inue to be two parallel discovery solutions in use, however.)

As long as I'm writing about the acct: URI, let me add my voice supporting =
allowing local account identifiers such as "acct:joe" to be used, in additi=
on to fully qualified names such "acct:joe@example.com".  The reason that t=
his this can work fine for discovery is that if you're contacting the disco=
very server at example.com, the identifier "acct:joe" is unambiguous in tha=
t context.

Going meta, is the question about whether to allow local acct: identifiers =
the only open issue for the spec?  If there are others, could we try to ide=
ntify them soon?  It would be really good for us to try to identify the ope=
n issues, discuss them, and drive them to closure, now that we have a worki=
ng group specification.

				Best wishes,
				-- Mike

-----Original Message-----
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of Peter Saint-Andre
Sent: Thursday, August 23, 2012 9:22 AM
To: Graham Klyne
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/20/12 2:51 AM, Graham Klyne wrote:
> On 16/08/2012 19:30, Peter Saint-Andre wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>=20
>> On 8/15/12 3:47 AM, Graham Klyne wrote:
>>> ref: http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-00
>>>=20
>>> I'm uneasy about:
>>>=20
>>> [[ 4.4.  URI Scheme Semantics
>>>=20
>>> The 'acct' URI scheme is used to identify user accounts hosted at=20
>>> service providers.  It is used only for identification, not=20
>>> interaction.  A protocol that uses the 'acct' URI scheme is=20
>>> responsible for specifying how an 'acct' URI is to be dereferenced=20
>>> in the context of that protocol.  There is no media type associated=20
>>> with the 'acct' URI scheme. ]]
>>>=20
>>> Specifically, the bit about "protocol that uses the acct URI=20
>>> scheme".
>>>=20
>>> My understanding was that the intent was that acct: would be=20
>>> dereferenced using the WebFinger protocol.  If there is no such=20
>>> expectation, then an acct: URI appearing in isolation (e.g. in a web=20
>>> page or some document) has no actionable meaning.
>>=20
>> My understanding, which I tried to capture in the document, was that=20
>> some folks here thought that acct URIs might be used by other=20
>> protocols. If there is consensus that acct URIs will be used only for=20
>> WebFinger, I am happy to update the document accordingly. I'm truly=20
>> just acting in an editorial capacity on this document.
>=20
> I certainly understand that the intent is that acct: URIs can be used=20
> *with* other protocols, it's just that I also understood the standard=20
> dereferencing mechanism (or, if you like, the definitive=20
> identification semantics) is defined by the WebFinger protocol.
>=20
> An example for comparison: the standard dereferencing semantics for an=20
> ftp: URI is to use the FTP protocol, but an ftp: URI can be used with=20
> the HTTP protocol.

Graham, thank you for drawing the distinction between using acct URIs and d=
ereferencing acct URIs. I have not yet heard of anyone proposing to derefer=
ence acct URIs using technologies other than WebFinger, although if the Sim=
ple Web Discovery work
(draft-jones-simple-web-discovery) continues independently then it seems po=
ssible that acct URIs might be derefenced using that technology. For exampl=
e :

   GET /.well-known/simple-web-discovery
       ?principal=3Dacct:joe@example.com
       &service=3Durn:example:service:calendar HTTP/1.1
   Host: example.com

   HTTP/1.1 200 OK
   Content-Type: application/json

   {
    "locations": ["https://calendars.example.net/calendars/joseph"]
   }

Clarification would be appreciated from folks on this list. I just hold the=
 editing pen on this one.

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlA2WLAACgkQNL8k5A2w/vzH1wCgq3cDQ5sRSEhSC4+0dXO49I5a
2YcAoOhjwRrlZkOZEFPgDFIvp+9WNVTb
=3D1/UL
-----END PGP SIGNATURE-----
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss



From stpeter@stpeter.im  Thu Aug 23 12:41:21 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9F321F8686 for ; Thu, 23 Aug 2012 12:41:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.572
X-Spam-Level: 
X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5QaTNjtBnhO for ; Thu, 23 Aug 2012 12:41:20 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 50D1921F8634 for ; Thu, 23 Aug 2012 12:41:20 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DFB9D404EA; Thu, 23 Aug 2012 13:42:12 -0600 (MDT)
Message-ID: <5036875E.60607@stpeter.im>
Date: Thu, 23 Aug 2012 13:41:18 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Mike Jones 
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> <5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com>
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Graham Klyne , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 19:41:22 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/23/12 12:49 PM, Mike Jones wrote:

> As long as I'm writing about the acct: URI, let me add my voice 
> supporting allowing local account identifiers such as "acct:joe"
> to be used, in addition to fully qualified names such 
> "acct:joe@example.com".  The reason that this this can work fine
> for discovery is that if you're contacting the discovery server at 
> example.com, the identifier "acct:joe" is unambiguous in that 
> context.

Mike, to date it appears that you and Phillip Hallam-Baker have been
in favor of local account identifiers such as "acct:joe", the idea
being that "an acct: name that does not have a domain name part is
going to have to be resolved in the same fashion as relative URIs are
- - by reference to context and local state" (as Phil said in a message
to this list on July 2).

Martin Thomson, John Bradley, Graham Klyne, and I expressed concerns
about the implicit nature of such identifiers and the resulting
fragility in systems that use them, and about our understanding that
"URIs are intended to be a global namespace" (as Graham said in a
message to this list on July 2).

Mike, what are your thoughts now about the issues that Martin, John,
Graham, and I raised at the beginning of July?

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlA2h14ACgkQNL8k5A2w/vy3dQCg6aVB692w70Rqcq0JqcFB7OtC
bDQAnj9ytEQB5hRgOptWdMSGl7+loTls
=RyI0
-----END PGP SIGNATURE-----

From hallam@gmail.com  Thu Aug 23 12:55:58 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D1221F86BE for ; Thu, 23 Aug 2012 12:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.483
X-Spam-Level: 
X-Spam-Status: No, score=-5.483 tagged_above=-999 required=5 tests=[AWL=-1.884, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rcAU9f--LO4 for ; Thu, 23 Aug 2012 12:55:57 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3109721F867F for ; Thu, 23 Aug 2012 12:55:57 -0700 (PDT)
Received: by obbwc20 with SMTP id wc20so3064183obb.31 for ; Thu, 23 Aug 2012 12:55:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gbtHy2kNbEbtJgAOSxxu2hM9MvStjormaPHRlnyHAgQ=; b=dROUG+muwIPcCf+PvlOQTO/bkNzmfYfaLAP25xhcNsyC4hzF+X8akIIL7ZXuPlVROO ENKiwQG0O6obqOevAp37QBn/eXB2AlIc0TMuXvnp2r/sMTJNcfqcgdU0A5vNZUpJ1NG/ b1r34slPCFyPRB6aXP8A20ne/dBhpQARMOhkxgFpZgzfjjW9+uUbBaaTPlaS08Jo+x+D Vexn6fHhx4ypq/WtbnTlaa1tv4ab3sziClDLT9Q8xMpoXHQT3v2FXsQ/gkmUCvBk7Chw dyTyNojBZVoqDy2qnAXTH7EvV2SM5uYgZLHTEs9NXj6m7Au2Blm/oQQmZc/kUDI334Pc QOaw==
MIME-Version: 1.0
Received: by 10.60.172.236 with SMTP id bf12mr2082122oec.23.1345751756632; Thu, 23 Aug 2012 12:55:56 -0700 (PDT)
Received: by 10.76.80.10 with HTTP; Thu, 23 Aug 2012 12:55:56 -0700 (PDT)
In-Reply-To: <5036875E.60607@stpeter.im>
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> <5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com> <5036875E.60607@stpeter.im>
Date: Thu, 23 Aug 2012 15:55:56 -0400
Message-ID: 
From: Phillip Hallam-Baker 
To: Peter Saint-Andre 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Graham Klyne , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 19:55:58 -0000

I don't know who told you that all URIs had to be globally unique but
there have been relative URIs from the very start.

The URI syntax permits an identifier to be specified in a fashion that
is unique or relative. The part that is critical is that it must be
possible to distinguish which one is intended from the syntax alone.





On Thu, Aug 23, 2012 at 3:41 PM, Peter Saint-Andre  wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 8/23/12 12:49 PM, Mike Jones wrote:
>
>> As long as I'm writing about the acct: URI, let me add my voice
>> supporting allowing local account identifiers such as "acct:joe"
>> to be used, in addition to fully qualified names such
>> "acct:joe@example.com".  The reason that this this can work fine
>> for discovery is that if you're contacting the discovery server at
>> example.com, the identifier "acct:joe" is unambiguous in that
>> context.
>
> Mike, to date it appears that you and Phillip Hallam-Baker have been
> in favor of local account identifiers such as "acct:joe", the idea
> being that "an acct: name that does not have a domain name part is
> going to have to be resolved in the same fashion as relative URIs are
> - - by reference to context and local state" (as Phil said in a message
> to this list on July 2).
>
> Martin Thomson, John Bradley, Graham Klyne, and I expressed concerns
> about the implicit nature of such identifiers and the resulting
> fragility in systems that use them, and about our understanding that
> "URIs are intended to be a global namespace" (as Graham said in a
> message to this list on July 2).
>
> Mike, what are your thoughts now about the issues that Martin, John,
> Graham, and I raised at the beginning of July?
>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAlA2h14ACgkQNL8k5A2w/vy3dQCg6aVB692w70Rqcq0JqcFB7OtC
> bDQAnj9ytEQB5hRgOptWdMSGl7+loTls
> =RyI0
> -----END PGP SIGNATURE-----
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss



-- 
Website: http://hallambaker.com/

From tbray@textuality.com  Thu Aug 23 13:04:51 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4F521F864A for ; Thu, 23 Aug 2012 13:04:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.921
X-Spam-Level: 
X-Spam-Status: No, score=-4.921 tagged_above=-999 required=5 tests=[AWL=-1.944, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xc4x-63OLFr5 for ; Thu, 23 Aug 2012 13:04:50 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id DE62221F8570 for ; Thu, 23 Aug 2012 13:04:49 -0700 (PDT)
Received: by wibhr14 with SMTP id hr14so56180wib.13 for ; Thu, 23 Aug 2012 13:04:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=3zi9LCZ+8Xln1N13ubt3Kc9eV6FoCXwDfXtyT9lr2T8=; b=nIAoXr/10+r2U0bSdg5DN66QIreHQFvntJe5biXtCPudBOcytWw28q+kpoeAZeadEG LA6PvUcthvS5C6f9pT9g+t5AXLJEjUju0OyPY2RoZEmSwydmEJiI/nQuiuOI2d4x/DRy zknaK7rgfhfRRidE3bg/rPTKukNVqgrmfJh+jcOvo5S9pXk6vxXVvmoLKu4eQIYjIpQu IJ2E1z/rZpyhJDee+JHt/iShs3RVO9+snqzj2NfBkr3EgqZV/R0Ex+5u4GOxFf2FejiB 6anTneQpGm19uhkBRYvSovbJbhc+T+sfeaw8q3YcvT5WnLDPrSWwY8PZRqdLr5e7IiHl MJHg==
MIME-Version: 1.0
Received: by 10.180.81.133 with SMTP id a5mr6700177wiy.17.1345752288687; Thu, 23 Aug 2012 13:04:48 -0700 (PDT)
Received: by 10.194.32.7 with HTTP; Thu, 23 Aug 2012 13:04:48 -0700 (PDT)
X-Originating-IP: [24.84.208.217]
In-Reply-To: 
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> <5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com> <5036875E.60607@stpeter.im> 
Date: Thu, 23 Aug 2012 13:04:48 -0700
Message-ID: 
From: Tim Bray 
To: Phillip Hallam-Baker 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQm7CnOTBgRWeRXhwrkpm8kVWFCdDFOzmEh2xEg9zNfFjGsKAxAIJKOZbIdZkiK8sPm+6wr8
Cc: Graham Klyne , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 20:04:51 -0000

A URI is absolute and unique.  A =93URI Reference=94 may be relative, but
in general they only exist and are used in contexts where they may be
absolutized.  I.e. there=92s no problem when you find  in a web page that you=92ve fetched, but if you
fetch the HTML with curl and leave it on a local hard disk, you=92ve
created a bug.  -T

On Thu, Aug 23, 2012 at 12:55 PM, Phillip Hallam-Baker  w=
rote:
> I don't know who told you that all URIs had to be globally unique but
> there have been relative URIs from the very start.
>
> The URI syntax permits an identifier to be specified in a fashion that
> is unique or relative. The part that is critical is that it must be
> possible to distinguish which one is intended from the syntax alone.
>
>
>
>
>
> On Thu, Aug 23, 2012 at 3:41 PM, Peter Saint-Andre  w=
rote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 8/23/12 12:49 PM, Mike Jones wrote:
>>
>>> As long as I'm writing about the acct: URI, let me add my voice
>>> supporting allowing local account identifiers such as "acct:joe"
>>> to be used, in addition to fully qualified names such
>>> "acct:joe@example.com".  The reason that this this can work fine
>>> for discovery is that if you're contacting the discovery server at
>>> example.com, the identifier "acct:joe" is unambiguous in that
>>> context.
>>
>> Mike, to date it appears that you and Phillip Hallam-Baker have been
>> in favor of local account identifiers such as "acct:joe", the idea
>> being that "an acct: name that does not have a domain name part is
>> going to have to be resolved in the same fashion as relative URIs are
>> - - by reference to context and local state" (as Phil said in a message
>> to this list on July 2).
>>
>> Martin Thomson, John Bradley, Graham Klyne, and I expressed concerns
>> about the implicit nature of such identifiers and the resulting
>> fragility in systems that use them, and about our understanding that
>> "URIs are intended to be a global namespace" (as Graham said in a
>> message to this list on July 2).
>>
>> Mike, what are your thoughts now about the issues that Martin, John,
>> Graham, and I raised at the beginning of July?
>>
>> Peter
>>
>> - --
>> Peter Saint-Andre
>> https://stpeter.im/
>>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAlA2h14ACgkQNL8k5A2w/vy3dQCg6aVB692w70Rqcq0JqcFB7OtC
>> bDQAnj9ytEQB5hRgOptWdMSGl7+loTls
>> =3DRyI0
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
> --
> Website: http://hallambaker.com/
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

From duerst@it.aoyama.ac.jp  Fri Aug 24 09:21:22 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341B821F85AD for ; Fri, 24 Aug 2012 09:21:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.93
X-Spam-Level: 
X-Spam-Status: No, score=-100.93 tagged_above=-999 required=5 tests=[AWL=-1.140, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ifm8lnJJ7X7U for ; Fri, 24 Aug 2012 09:21:21 -0700 (PDT)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 10DD221F8598 for ; Fri, 24 Aug 2012 09:21:20 -0700 (PDT)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q7OGLEFF000861 for ; Sat, 25 Aug 2012 01:21:14 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 3090_f029_b95f502c_ee07_11e1_b497_001d096c566a; Sat, 25 Aug 2012 01:21:13 +0900
Received: from [IPv6:::1] ([133.2.210.1]:54421) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Sat, 25 Aug 2012 01:21:13 +0900
Message-ID: <5037A9EE.4040000@it.aoyama.ac.jp>
Date: Sat, 25 Aug 2012 01:21:02 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Phillip Hallam-Baker 
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im>	<5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im>	<4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com>	<5036875E.60607@stpeter.im> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Graham Klyne , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 16:21:22 -0000

On 2012/08/24 4:55, Phillip Hallam-Baker wrote:
> I don't know who told you that all URIs had to be globally unique but
> there have been relative URIs from the very start.

Yes indeed. And URI schemes that are not global at all, such as file:.

> The URI syntax permits an identifier to be specified in a fashion that
> is unique or relative. The part that is critical is that it must be
> possible to distinguish which one is intended from the syntax alone.

Yes. But please note that "acct:joe" is not a relative version of 
"acct:joe@example.org" in the sense that given a base URI of 
acct:foo@example.org" and an URI of "acct:joe", the relative resolution 
algorithm (see http://tools.ietf.org/html/rfc3986#section-5.2) does NOT 
produce "acct:joe@example.org". So "acct:joe" may be called local (or 
whatever) but cannot be called relative.

Regards,   Martin.

> On Thu, Aug 23, 2012 at 3:41 PM, Peter Saint-Andre  wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 8/23/12 12:49 PM, Mike Jones wrote:
>>
>>> As long as I'm writing about the acct: URI, let me add my voice
>>> supporting allowing local account identifiers such as "acct:joe"
>>> to be used, in addition to fully qualified names such
>>> "acct:joe@example.com".  The reason that this this can work fine
>>> for discovery is that if you're contacting the discovery server at
>>> example.com, the identifier "acct:joe" is unambiguous in that
>>> context.
>>
>> Mike, to date it appears that you and Phillip Hallam-Baker have been
>> in favor of local account identifiers such as "acct:joe", the idea
>> being that "an acct: name that does not have a domain name part is
>> going to have to be resolved in the same fashion as relative URIs are
>> - - by reference to context and local state" (as Phil said in a message
>> to this list on July 2).
>>
>> Martin Thomson, John Bradley, Graham Klyne, and I expressed concerns
>> about the implicit nature of such identifiers and the resulting
>> fragility in systems that use them, and about our understanding that
>> "URIs are intended to be a global namespace" (as Graham said in a
>> message to this list on July 2).
>>
>> Mike, what are your thoughts now about the issues that Martin, John,
>> Graham, and I raised at the beginning of July?
>>
>> Peter
>>
>> - --
>> Peter Saint-Andre
>> https://stpeter.im/
>>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAlA2h14ACgkQNL8k5A2w/vy3dQCg6aVB692w70Rqcq0JqcFB7OtC
>> bDQAnj9ytEQB5hRgOptWdMSGl7+loTls
>> =RyI0
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>

From ve7jtb@ve7jtb.com  Fri Aug 24 10:23:31 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B10921F858E for ; Fri, 24 Aug 2012 10:23:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.491
X-Spam-Level: 
X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.108,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2+WLYxBl9Ax for ; Fri, 24 Aug 2012 10:23:30 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7504321F84C5 for ; Fri, 24 Aug 2012 10:23:30 -0700 (PDT)
Received: by qcac10 with SMTP id c10so1557393qca.31 for ; Fri, 24 Aug 2012 10:23:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=klMRzkYcXDfrigmPyOkzwkCHAFjOJqVoapWyWOd8X7A=; b=gBX9MJkDa+zpgL463mgStb6xGnHEdL/bDCXLbuKYigxT/15hzWUjVGSi3hcyY43kHL UC0tHhRAR8HXkmiIbBEHsBu+USUJg5VFFDO5ausepOJLIctgGnxE+EeqsQRfaToeZDYQ HhGl+vkO9n828A+cUhbbrW4zy8Bs45yn/i02UJN/X3q1g5RcPCm4MF2b5y0BXmFJWOGZ /ZlCFSMKNCuS2FFiowFH4wymoXt52T2+pMnrmFn1DKaCEcp73zrDNOifxpzep4RX+/BS pGXqggTwfoKoHeKvAlDgqTYNbqYyU2QITWF1yy9837MVnzDmxbA5JjazQ63zmV0HD+gJ fyzA==
Received: by 10.229.137.3 with SMTP id u3mr2871006qct.41.1345829009692; Fri, 24 Aug 2012 10:23:29 -0700 (PDT)
Received: from [192.168.1.211] (190-20-25-212.baf.movistar.cl. [190.20.25.212]) by mx.google.com with ESMTPS id ea5sm7698097qab.2.2012.08.24.10.23.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Aug 2012 10:23:26 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_3272D6CC-31D8-4332-BDE2-B6B8BB8D4F5A"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\))
From: John Bradley 
In-Reply-To: 
Date: Fri, 24 Aug 2012 13:23:21 -0400
Message-Id: 
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> <5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com> <5036875E.60607@stpeter.im> 
To: Phillip Hallam-Baker 
X-Mailer: Apple Mail (2.1485)
X-Gm-Message-State: ALoCoQmGqVVrL1SGkeRVQoYTaxsbz9EWVTs3ptRKebTqJ52JKNLGmpKSQKGEXBneja6JBy8xYqVo
Cc: Graham Klyne , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 17:23:31 -0000

--Apple-Mail=_3272D6CC-31D8-4332-BDE2-B6B8BB8D4F5A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I agree that as long as there is a way to distinguish a relative acct: =
URI from a fully qualified one I don't have a problem.

In with HTTP you can make a relative reference in html.
However you can't really pass around /foo/bar without context.

For a acct: uri to be relative I am OK with omitting the host =
subsegment.=20

We may also need to define a format for specifying the base =
acct:@example.com

It just needs to be thought through as it is not exactly like a http =
relative URI.

John B.


On 2012-08-23, at 3:55 PM, Phillip Hallam-Baker  =
wrote:

> I don't know who told you that all URIs had to be globally unique but
> there have been relative URIs from the very start.
>=20
> The URI syntax permits an identifier to be specified in a fashion that
> is unique or relative. The part that is critical is that it must be
> possible to distinguish which one is intended from the syntax alone.
>=20
>=20
>=20
>=20
>=20
> On Thu, Aug 23, 2012 at 3:41 PM, Peter Saint-Andre =
 wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>=20
>> On 8/23/12 12:49 PM, Mike Jones wrote:
>>=20
>>> As long as I'm writing about the acct: URI, let me add my voice
>>> supporting allowing local account identifiers such as "acct:joe"
>>> to be used, in addition to fully qualified names such
>>> "acct:joe@example.com".  The reason that this this can work fine
>>> for discovery is that if you're contacting the discovery server at
>>> example.com, the identifier "acct:joe" is unambiguous in that
>>> context.
>>=20
>> Mike, to date it appears that you and Phillip Hallam-Baker have been
>> in favor of local account identifiers such as "acct:joe", the idea
>> being that "an acct: name that does not have a domain name part is
>> going to have to be resolved in the same fashion as relative URIs are
>> - - by reference to context and local state" (as Phil said in a =
message
>> to this list on July 2).
>>=20
>> Martin Thomson, John Bradley, Graham Klyne, and I expressed concerns
>> about the implicit nature of such identifiers and the resulting
>> fragility in systems that use them, and about our understanding that
>> "URIs are intended to be a global namespace" (as Graham said in a
>> message to this list on July 2).
>>=20
>> Mike, what are your thoughts now about the issues that Martin, John,
>> Graham, and I raised at the beginning of July?
>>=20
>> Peter
>>=20
>> - --
>> Peter Saint-Andre
>> https://stpeter.im/
>>=20
>>=20
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>=20
>> iEYEARECAAYFAlA2h14ACgkQNL8k5A2w/vy3dQCg6aVB692w70Rqcq0JqcFB7OtC
>> bDQAnj9ytEQB5hRgOptWdMSGl7+loTls
>> =3DRyI0
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
>=20
>=20
> --=20
> Website: http://hallambaker.com/
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


--Apple-Mail=_3272D6CC-31D8-4332-BDE2-B6B8BB8D4F5A
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgy
NDE3MjMyMVowIwYJKoZIhvcNAQkEMRYEFEuS8GvgY5KSyGRRxOAH5DFYUMHbMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
AK+bxI8US3bFv48IGJaawO3qfMT0FOkNyZHTgftvqh/VHSSsTVH5ytHiXNLz3hYLqe5ilqoFLzdO
ufala3fT7d2w4Agvsecmba9jbWlNnt8L231YRlf9wXdBPfnn/t3By+VXS0yPFWIW5sF27Q42ZTr4
xo738t0uit01UKZIQ5tX32vHBulq3A/xPYXZpdH5iGUPDsZQUM09f8B2PzEdsXmvezcEPk3DiAqH
5Oaq4khiOZtzNjKjypr/KBKlhHl14PH1C1sCqbyR42DN1zid4b94Is5lNYqZTvmiP4LzASnxeD6J
CA3KVtAaTiSNUNwpFuohEmt4NuBI44+53tvPOpsAAAAAAAA=

--Apple-Mail=_3272D6CC-31D8-4332-BDE2-B6B8BB8D4F5A--

From hallam@gmail.com  Fri Aug 24 10:47:36 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6429421F8691 for ; Fri, 24 Aug 2012 10:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.309
X-Spam-Level: 
X-Spam-Status: No, score=-5.309 tagged_above=-999 required=5 tests=[AWL=-2.010, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZO3qQR9lyun for ; Fri, 24 Aug 2012 10:47:35 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C31C721F861D for ; Fri, 24 Aug 2012 10:47:33 -0700 (PDT)
Received: by obbwc20 with SMTP id wc20so5428360obb.31 for ; Fri, 24 Aug 2012 10:47:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0ijB0xtJ2CfsghA49TKyPJwWiRUGVyBJPfWuDlLfkeU=; b=rTrYJpOawQp+YzoU4VIgijre6ipPEs1DpCNHNy1OO8MZaAb/ROlNjCFqU3S6a0Q5+U 1+QK+ZGF29ro6cODfCCL+3oMym3h7DGUrwGG3y4ocJ1CPl60lSu/wBErq+1o87UZvUBY JY4gEf32F7RISZSHsHt9IXn6kOahgoSSgbbvZJnx6UYObNxydq56Quwj5GpiNM4X7nC0 YGDM4764OT/5WvbisdSzNRO/3w3vMu1VMZ5hlihYDxzIIQIOVUIw0c2+r+bQf98iS7Se RYbczty+nmnMjbPqtn1OyEgx8c4b6gdd2ZawJ6Ki2yfA733VHZuO5uCddU3KAvr6pfTi 4p2g==
MIME-Version: 1.0
Received: by 10.182.75.33 with SMTP id z1mr4702368obv.9.1345830453268; Fri, 24 Aug 2012 10:47:33 -0700 (PDT)
Received: by 10.76.80.10 with HTTP; Fri, 24 Aug 2012 10:47:33 -0700 (PDT)
In-Reply-To: <5037A9EE.4040000@it.aoyama.ac.jp>
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> <5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com> <5036875E.60607@stpeter.im>  <5037A9EE.4040000@it.aoyama.ac.jp>
Date: Fri, 24 Aug 2012 13:47:33 -0400
Message-ID: 
From: Phillip Hallam-Baker 
To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Graham Klyne , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 17:47:36 -0000

acct:joe is relative to the accounts file of the server to which it is
addressed. That is not a DNS qualified domain unless people want to
count .local or .corp.

Call it contextually bound or whatever if people like.

Just like other incomplete URIs this is a form that is going to be
easily resolved by context. If your host is in a windows domain, well
you really know that, same for UNIX.

On Fri, Aug 24, 2012 at 12:21 PM, "Martin J. D=FCrst"
 wrote:
> On 2012/08/24 4:55, Phillip Hallam-Baker wrote:
>>
>> I don't know who told you that all URIs had to be globally unique but
>> there have been relative URIs from the very start.
>
>
> Yes indeed. And URI schemes that are not global at all, such as file:.
>
>
>> The URI syntax permits an identifier to be specified in a fashion that
>> is unique or relative. The part that is critical is that it must be
>> possible to distinguish which one is intended from the syntax alone.
>
>
> Yes. But please note that "acct:joe" is not a relative version of
> "acct:joe@example.org" in the sense that given a base URI of
> acct:foo@example.org" and an URI of "acct:joe", the relative resolution
> algorithm (see http://tools.ietf.org/html/rfc3986#section-5.2) does NOT
> produce "acct:joe@example.org". So "acct:joe" may be called local (or
> whatever) but cannot be called relative.
>
> Regards,   Martin.
>
>
>> On Thu, Aug 23, 2012 at 3:41 PM, Peter Saint-Andre
>> wrote:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 8/23/12 12:49 PM, Mike Jones wrote:
>>>
>>>> As long as I'm writing about the acct: URI, let me add my voice
>>>> supporting allowing local account identifiers such as "acct:joe"
>>>> to be used, in addition to fully qualified names such
>>>> "acct:joe@example.com".  The reason that this this can work fine
>>>> for discovery is that if you're contacting the discovery server at
>>>> example.com, the identifier "acct:joe" is unambiguous in that
>>>> context.
>>>
>>>
>>> Mike, to date it appears that you and Phillip Hallam-Baker have been
>>> in favor of local account identifiers such as "acct:joe", the idea
>>> being that "an acct: name that does not have a domain name part is
>>> going to have to be resolved in the same fashion as relative URIs are
>>> - - by reference to context and local state" (as Phil said in a message
>>> to this list on July 2).
>>>
>>> Martin Thomson, John Bradley, Graham Klyne, and I expressed concerns
>>> about the implicit nature of such identifiers and the resulting
>>> fragility in systems that use them, and about our understanding that
>>> "URIs are intended to be a global namespace" (as Graham said in a
>>> message to this list on July 2).
>>>
>>> Mike, what are your thoughts now about the issues that Martin, John,
>>> Graham, and I raised at the beginning of July?
>>>
>>> Peter
>>>
>>> - --
>>> Peter Saint-Andre
>>> https://stpeter.im/
>>>
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>
>>> iEYEARECAAYFAlA2h14ACgkQNL8k5A2w/vy3dQCg6aVB692w70Rqcq0JqcFB7OtC
>>> bDQAnj9ytEQB5hRgOptWdMSGl7+loTls
>>> =3DRyI0
>>> -----END PGP SIGNATURE-----
>>> _______________________________________________
>>> apps-discuss mailing list
>>> apps-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>
>>
>>
>>
>



--=20
Website: http://hallambaker.com/

From julian.reschke@gmx.de  Fri Aug 24 10:56:00 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE63421F871A for ; Fri, 24 Aug 2012 10:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.105
X-Spam-Level: 
X-Spam-Status: No, score=-105.105 tagged_above=-999 required=5 tests=[AWL=-2.506, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cV8VFSweee39 for ; Fri, 24 Aug 2012 10:56:00 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B336B21F86D4 for ; Fri, 24 Aug 2012 10:55:59 -0700 (PDT)
Received: (qmail invoked by alias); 24 Aug 2012 17:55:58 -0000
Received: from p5DD97CE7.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.124.231] by mail.gmx.net (mp004) with SMTP; 24 Aug 2012 19:55:58 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18GxvVdZdAGJpfcKjMYiiq2NT6Zg0lLuCqFDiKXHV WOnQSDCm+n6gNr
Message-ID: <5037C02C.2070506@gmx.de>
Date: Fri, 24 Aug 2012 19:55:56 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: John Bradley 
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> <5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com> <5036875E.60607@stpeter.im>  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: Graham Klyne , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 17:56:00 -0000

On 2012-08-24 19:23, John Bradley wrote:
> I agree that as long as there is a way to distinguish a relative acct: URI from a fully qualified one I don't have a problem.
>
> In with HTTP you can make a relative reference in html.
> However you can't really pass around /foo/bar without context.
>
> For a acct: uri to be relative I am OK with omitting the host subsegment.
>
> We may also need to define a format for specifying the base acct:@example.com
>
> It just needs to be thought through as it is not exactly like a http relative URI.
>
> John B.

Please don't confuse what's being discussed with "relative references", 
as described in RFC 3986, Section 4.2. They are not, and this is IMHO 
explains why people (including me) are unhappy.

Best regards, Julian


From Michael.Jones@microsoft.com  Fri Aug 24 16:44:20 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE69521F862B for ; Fri, 24 Aug 2012 16:44:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.844
X-Spam-Level: 
X-Spam-Status: No, score=-3.844 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1Up-G3qSW5c for ; Fri, 24 Aug 2012 16:44:20 -0700 (PDT)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 0E07C21F8625 for ; Fri, 24 Aug 2012 16:44:20 -0700 (PDT)
Received: from mail93-co1-R.bigfish.com (10.243.78.245) by CO1EHSOBE011.bigfish.com (10.243.66.74) with Microsoft SMTP Server id 14.1.225.23; Fri, 24 Aug 2012 23:44:19 +0000
Received: from mail93-co1 (localhost [127.0.0.1])	by mail93-co1-R.bigfish.com (Postfix) with ESMTP id 62E2F8C00BC; Fri, 24 Aug 2012 23:44:19 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-SpamScore: -29
X-BigFish: VS-29(zz98dI9371I936eI542M1432Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah107ah1155h)
Received-SPF: pass (mail93-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail93-co1 (localhost.localdomain [127.0.0.1]) by mail93-co1 (MessageSwitch) id 1345851857908428_23884; Fri, 24 Aug 2012 23:44:17 +0000 (UTC)
Received: from CO1EHSMHS014.bigfish.com (unknown [10.243.78.233])	by mail93-co1.bigfish.com (Postfix) with ESMTP id DB832700042; Fri, 24 Aug 2012 23:44:17 +0000 (UTC)
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS014.bigfish.com (10.243.66.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 24 Aug 2012 23:44:17 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.176]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Fri, 24 Aug 2012 23:44:16 +0000
From: Mike Jones 
To: Julian Reschke , John Bradley 
Thread-Topic: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
Thread-Index: AQHNesvs8vKnlOUTjUOINpvGHWreOpdcxLWAgAWnrgCABTTmAIAAJjzggAARagCAAAQXAIABZ7OAgAAJGgCAAGEOoA==
Date: Fri, 24 Aug 2012 23:44:15 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943667A9596@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> <5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com> <5036875E.60607@stpeter.im>   <5037C02C.2070506@gmx.de>
In-Reply-To: <5037C02C.2070506@gmx.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.74]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: Graham Klyne , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 23:44:21 -0000

I agree that it's not a relative reference, in the RFC 3986 sense.  It's in=
tended to be a context-dependent reference, as explained by Phillip.

				-- Mike

-----Original Message-----
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of Julian Reschke
Sent: Friday, August 24, 2012 10:56 AM
To: John Bradley
Cc: Graham Klyne; apps-discuss@ietf.org
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt

On 2012-08-24 19:23, John Bradley wrote:
> I agree that as long as there is a way to distinguish a relative acct: UR=
I from a fully qualified one I don't have a problem.
>
> In with HTTP you can make a relative reference in html.
> However you can't really pass around /foo/bar without context.
>
> For a acct: uri to be relative I am OK with omitting the host subsegment.
>
> We may also need to define a format for specifying the base=20
> acct:@example.com
>
> It just needs to be thought through as it is not exactly like a http rela=
tive URI.
>
> John B.

Please don't confuse what's being discussed with "relative references", as =
described in RFC 3986, Section 4.2. They are not, and this is IMHO explains=
 why people (including me) are unhappy.

Best regards, Julian

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



From stpeter@stpeter.im  Fri Aug 24 18:21:29 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9353F21F8564 for ; Fri, 24 Aug 2012 18:21:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.694
X-Spam-Level: 
X-Spam-Status: No, score=-102.694 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seu8CczKCI+C for ; Fri, 24 Aug 2012 18:21:29 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 033BF21F852C for ; Fri, 24 Aug 2012 18:21:28 -0700 (PDT)
Received: from [192.168.0.4] (unknown [67.177.192.224]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 347BD405A7; Fri, 24 Aug 2012 19:22:25 -0600 (MDT)
Message-ID: <50382896.8060306@stpeter.im>
Date: Fri, 24 Aug 2012 19:21:26 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Mike Jones 
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> <5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com> <5036875E.60607@stpeter.im>   <5037C02C.2070506@gmx.de> <4E1F6AAD24975D4BA5B1680429673943667A9596@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667A9596@TK5EX14MBXC284.redmond.corp.microsoft.com>
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Julian Reschke , Graham Klyne , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Aug 2012 01:21:29 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/24/12 5:44 PM, Mike Jones wrote:
> I agree that it's not a relative reference, in the RFC 3986 sense. 
> It's intended to be a context-dependent reference, as explained by 
> Phillip.

Can you point to examples of context-dependent references in other URI
schemes, or would the acct scheme be breaking new ground here?

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlA4KJYACgkQNL8k5A2w/vzaRACfVlVAaVnYEdXs9B82kLP6C9s8
3v0AoNm2q4cKeMMmbexxa539uc10Z7fH
=ez0H
-----END PGP SIGNATURE-----

From wmills@yahoo-inc.com  Fri Aug 24 21:50:54 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B733C21F8568 for ; Fri, 24 Aug 2012 21:50:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.56
X-Spam-Level: 
X-Spam-Status: No, score=-17.56 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y71wltV1ixOt for ; Fri, 24 Aug 2012 21:50:53 -0700 (PDT)
Received: from nm7.bullet.mail.bf1.yahoo.com (nm7.bullet.mail.bf1.yahoo.com [98.139.212.166]) by ietfa.amsl.com (Postfix) with SMTP id 7319421F8569 for ; Fri, 24 Aug 2012 21:50:52 -0700 (PDT)
Received: from [98.139.212.151] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 25 Aug 2012 04:50:52 -0000
Received: from [98.139.212.241] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 25 Aug 2012 04:50:52 -0000
Received: from [127.0.0.1] by omp1050.mail.bf1.yahoo.com with NNFMP; 25 Aug 2012 04:50:52 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 213414.85671.bm@omp1050.mail.bf1.yahoo.com
Received: (qmail 35073 invoked by uid 60001); 25 Aug 2012 04:50:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345870251; bh=45iA4jHCgr03JCzJbh1YAfitCupwtKdWe8f8apbzsvk=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ETpwdBOPxMWJPS5TaOXXukUMcNNkOLEPfFPdXJYdOLOqjl0glD965JMa5BvpGIh0sSuYxGuaLK4fOnk5Bv+RDaiQ1k9dY6ulCfkfjDjHoDSB/TgvIRPbuEEqadxpgqQytjcmRJ0/rY46Epsu4ghrO2MW2M9xrK6jK1YmqT+YhZg=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=G6oSkmQScKCgSivcBNjF0zX755xwHopJvihOtkndn0xplNbe+kNQkbBPO+p/hHgYu9qBWHxlXvRBcgNwi/+VTLpTtCh3KDMuhHn9BwMRWE44ph7AcMd+ZcmwumKPBiE91yAu5535GpPYRt5sByvYoLtEASW3WNiy3icJarcMbCU=;
X-YMail-OSG: sh8Ox80VM1m3HRYvek7oIcUJ5Zd73aeBiV9zxb1yp3Xd2_T nNVte3S9yTJ7nbC.QYDShnh08wKbjst3raF1vPwPdXr7Iy5TL8d7aqyhG1SV xnFQjZR2KNOQS_2wbMH95AqKB60g0SWO_bjOvmP6sQZL.ZRcSISeZi3ZnTPM rNl2oOHrJChlhIKH43tBG_wvYz8KQjTu4DD2pP.EP77wdaqp.LyQer9E8gT_ BresHD9zQqb9MIQp6iW7G07mbget8LQBfkgUtxoG1Nz_UExt65WTcAkGqXGM owE6mOcSjfrin8pY_R.0FUJ3GtUC_LarPpH0_f1xiMX_MDddzXAqckcCF3aw vM.lfvq6aNKFpfRcxsXQLcz9DsX5C2eZ1dE_tHHQJBRtOGnUY_goOS_7jt9. _LmoGVzFCbZQNMaTjTT.DbNmbAgmMPGIDMNezD1kjLCem5qvlAcAV6p13T8h hxf4s5VM9trWp4Q6UzKeTA6rAYK8StZs6voJ1sZTsW3lZUTve.lzY1oL49CI Ozg9SXGXW5oYcf1ToOfYh3SH2c.jNmaAXmtHFzoyGAKJGqVTPNl6n
Received: from [209.131.62.115] by web31805.mail.mud.yahoo.com via HTTP; Fri, 24 Aug 2012 21:50:51 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.121.416
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> <5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com> <5036875E.60607@stpeter.im>   <5037C02C.2070506@gmx.de> <4E1F6AAD24975D4BA5B1680429673943667A9596@TK5EX14MBXC284.redmond.corp.microsoft.com> <50382896.8060306@stpeter.im>
Message-ID: <1345870251.20641.YahooMailNeo@web31805.mail.mud.yahoo.com>
Date: Fri, 24 Aug 2012 21:50:51 -0700 (PDT)
From: William Mills 
To: Peter Saint-Andre , Mike Jones 
In-Reply-To: <50382896.8060306@stpeter.im>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-551393103-1955062505-1345870251=:20641"
Cc: Julian Reschke , Graham Klyne , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Aug 2012 04:50:54 -0000

---551393103-1955062505-1345870251=:20641
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

An interesting question here is.... In the windows world an account might b=
e represented as NAMESPACE\username, do we handle this with acct:?=A0 =0A=
=0A=0A=0A=0A=0A>________________________________=0A> From: Peter Saint-Andr=
e =0A>To: Mike Jones  =0A>=
Cc: Julian Reschke ; Graham Klyne ; "apps-discuss@ietf.org"  =0A>Sent: Friday, August=
 24, 2012 6:21 PM=0A>Subject: Re: [apps-discuss] Comment on draft-ietf-apps=
awg-acct-uri-00.txt=0A> =0A>-----BEGIN PGP SIGNED MESSAGE-----=0A>Hash: SHA=
1=0A>=0A>On 8/24/12 5:44 PM, Mike Jones wrote:=0A>> I agree that it's not a=
 relative reference, in the RFC 3986 sense. =0A>> It's intended to be a con=
text-dependent reference, as explained by =0A>> Phillip.=0A>=0A>Can you poi=
nt to examples of context-dependent references in other URI=0A>schemes, or =
would the acct scheme be breaking new ground here?=0A>=0A>Peter=0A>=0A>- --=
 =0A>Peter Saint-Andre=0A>https://stpeter.im/=0A>=0A>=0A>-----BEGIN PGP SIG=
NATURE-----=0A>Version: GnuPG/MacGPG2 v2.0.18 (Darwin)=0A>Comment: Using Gn=
uPG with Mozilla - http://enigmail.mozdev.org/=0A>=0A>iEYEARECAAYFAlA4KJYAC=
gkQNL8k5A2w/vzaRACfVlVAaVnYEdXs9B82kLP6C9s8=0A>3v0AoNm2q4cKeMMmbexxa539uc10=
Z7fH=0A>=3Dez0H=0A>-----END PGP SIGNATURE-----=0A>_________________________=
______________________=0A>apps-discuss mailing list=0A>apps-discuss@ietf.or=
g=0A>https://www.ietf.org/mailman/listinfo/apps-discuss=0A>=0A>=0A>
---551393103-1955062505-1345870251=:20641
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


An intere=
sting question here is.... In the windows world an account might be represe=
nted as NAMESPACE\username, do we handle this with acct:?  


  <=
div style=3D"font-family: Courier New, courier, monaco, monospace, sans-ser=
if; font-size: 14pt;"> 
 
  
  From: Peter Saint-Andre <stpeter@stpeter.im>
 To: Mike Jones <Michael.Jones@microsoft.co=
m> 
Cc: Julian Resch=
ke
 <julian.reschke@gmx.de>; Graham Klyne <GK@ninebynine.org>; "ap=
ps-discuss@ietf.org" <apps-discuss@ietf.org> 
 Sent: Friday, August 24, 2012 6:21 PM
 =
Subject: Re: [apps-discuss] C=
omment on draft-ietf-appsawg-acct-uri-00.txt
  
 
-----BE=
GIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/24/12 5:44 PM, Mike J=
ones wrote:
> I agree that it's not a relative reference, in the RFC =
3986 sense. 
> It's intended to be a context-dependent reference, as =
explained by 
> Phillip.

Can you point to examples of context-=
dependent references in other URI
schemes, or would the acct scheme be b=
reaking new ground here?

Peter

- -- 
Peter Saint-Andre
=
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18
 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYE=
ARECAAYFAlA4KJYACgkQNL8k5A2w/vzaRACfVlVAaVnYEdXs9B82kLP6C9s8
3v0AoNm2q4c=
KeMMmbexxa539uc10Z7fH
=3Dez0H
-----END PGP SIGNATURE-----
________=
_______________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinf=
o/apps-discuss


 
 
 
   
---551393103-1955062505-1345870251=:20641--

From paulej@packetizer.com  Mon Aug 27 08:56:43 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C33621F8545 for ; Mon, 27 Aug 2012 08:56:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.497
X-Spam-Level: 
X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YatpKBzxa2Sb for ; Mon, 27 Aug 2012 08:56:42 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 60EDF21F8535 for ; Mon, 27 Aug 2012 08:56:42 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q7RFucdW005250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Aug 2012 11:56:39 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1346083000; bh=1nyrjSwPyjnCFoe4YzlwjDS0HSDsxMfJ747l0Tsz5Ws=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=ikJFQCGFyuDIMoUsBXhnCVUS2X20iOb2ELFBvTiYcE9YFs4UANF7B4tEPW9jO2jgM ZxZTCR5be1PCRTMnzEZ67Jj6ateD9E7wQ+rUgsUcw0ef8oXT8zHs+nXTwOWkH4Jzlm KZ8w7leNCJIda0UqOsCp0i3WXeqpCOTyEs6i5L/w=
From: "Paul E. Jones" 
To: 
Date: Mon, 27 Aug 2012 11:56:55 -0400
Message-ID: <010901cd846c$95d74560$c185d020$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac2EasjbTudDTt5dQHee46z3zUhpZg==
Content-Language: en-us
Cc: jsmarr@google.com, webfinger@googlegroups.com
Subject: [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 15:56:43 -0000

Folks,

Mike, Gonzalo, and I have had some off-list discussions about WebFinger and
how to resolve the one sticky point that we think has caused the most
concern.  That point is whether we should we allow both XML and JSON.

We have heard proposals to "just pick one" and, while I appreciate the
reasoning, I could not help ignoring that

  1) RFC 6415 exists and describes XML the single mandatory format
  2) Existing implementations use XML

Nonetheless, I also cannot ignore the long-term value in selecting one
format we can be sure is widely supported consistently.  I'm fairly
confident that most want only JSON at this point, even though most (if not
all) current implementations today use XML.  While I'm personally favorable
to using XML, I know my personal preferences are not representative of
everyone. :-)

So what we discussed was mentioning XML (perhaps with examples), but putting
that in an appendix and saying the usage is historic.  What this would mean
is that the text acknowledges that there are servers that might process both
XML and JSON, and even older servers that only process XML.  The main body
of the document would only require support for JSON from clients and
servers.

Before we make these changes to the text, I want to seek input from the
group.  I believe it would be acceptable, but I do not want those changes to
cause significant issues for anyone.

Thanks,
Paul

PS - Please follow-up only on the apps-discuss list.



From pelle@kodfabrik.se  Mon Aug 27 09:03:13 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE0321F854F for ; Mon, 27 Aug 2012 09:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSn0uICEz5ct for ; Mon, 27 Aug 2012 09:03:13 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2876421F854E for ; Mon, 27 Aug 2012 09:03:12 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so5131328vbb.31 for ; Mon, 27 Aug 2012 09:03:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=MTqlGTp+83bCMx93h80IR8sysJw84wJX41mKF+zVzK4=; b=TM0oBKpjeSTQ74y+kNd1CH25zo1SUn5SAhNRjXfO/7wXONj5UduyKcnQGDhH1Y6Iiu GCyh3fdysidBPy3xIjRUA153FEsU+nzOLvnTAjxBk16athBjtQeObw4W72mT4Bouv2bR DifySASYlTemB7I12zbe59TAUBKGSpoaY8B2RLSN3Z9/uNQuCQBPq0cCczcr8Os6lvK9 KhN2e5w/HyTHtkeUfqgMNbNbLdlHjXSVOGSU78GlR5ZrpFRGLttVuqeaxju+6sBc+ViJ S0+yPxWQ52Yxna/K5mPkMdR01TcDUG93+4eWy9xo9kwg6Sye2XECHrbqmoU1184zx6To EwJA==
MIME-Version: 1.0
Received: by 10.58.128.3 with SMTP id nk3mr13175054veb.9.1346083391921; Mon, 27 Aug 2012 09:03:11 -0700 (PDT)
Received: by 10.220.168.197 with HTTP; Mon, 27 Aug 2012 09:03:11 -0700 (PDT)
In-Reply-To: <010901cd846c$95d74560$c185d020$@packetizer.com>
References: <010901cd846c$95d74560$c185d020$@packetizer.com>
Date: Mon, 27 Aug 2012 18:03:11 +0200
Message-ID: 
From: Pelle Wessman 
To: "Paul E. Jones" 
Content-Type: multipart/alternative; boundary=047d7b67624069dfdc04c8417698
X-Gm-Message-State: ALoCoQmNraH7ZXBnOker1kk5FpHAdj3oB1QmGs6+fBnQK0fIwh1E7fUC5mhFjTkPmM9I59wvcueO
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 16:03:13 -0000

--047d7b67624069dfdc04c8417698
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Aug 27, 2012 at 5:56 PM, Paul E. Jones wrote:

> So what we discussed was mentioning XML (perhaps with examples), but
> putting
> that in an appendix and saying the usage is historic.  What this would mean
> is that the text acknowledges that there are servers that might process
> both
> XML and JSON, and even older servers that only process XML.  The main body
> of the document would only require support for JSON from clients and
> servers.
>

+1 from me. Mentioning it as historic use in an appendix so that new
implementers know about it and can take it into account sounds like a good
compromise to me - it of course depends a bit on the wording of that
appendix, but it could definitely turn out well.

/ Pelle Wessman

--047d7b67624069dfdc04c8417698
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 27, 2012 at 5:56 PM, Paul E. Jones <paulej@packetizer.com<=
/a>> wrote:

So what we discussed was mentioning XML (perhaps with examples), but puttin=
g

that in an appendix and saying the usage is historic. =A0What this would me=
an

is that the text acknowledges that there are servers that might process bot=
h

XML and JSON, and even older servers that only process XML. =A0The main bod=
y

of the document would only require support for JSON from clients and

servers.

+1 from me. Mentioning it as historic use=
 in an appendix so that new implementers know about it and can take it into=
 account sounds like a good compromise to me - it of course depends a bit o=
n the wording of that appendix, but it could definitely turn out well.


/ Pelle Wessman


--047d7b67624069dfdc04c8417698--

From jasnell@gmail.com  Mon Aug 27 09:06:44 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B5F21F854E for ; Mon, 27 Aug 2012 09:06:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.794
X-Spam-Level: 
X-Spam-Status: No, score=-6.794 tagged_above=-999 required=5 tests=[AWL=-3.196, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1CIddM4DXhf for ; Mon, 27 Aug 2012 09:06:43 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id E817B21F853B for ; Mon, 27 Aug 2012 09:06:42 -0700 (PDT)
Received: by wicr5 with SMTP id r5so2788640wic.13 for ; Mon, 27 Aug 2012 09:06: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:from:date:message-id:subject:to :cc:content-type; bh=ZXqF2floHmeDZy7MuSiQ9/HjBZ2/FyA+CCkfJ8l2810=; b=fP+UevbvYvkGSlNjcrlw3X6CFRKLKYIlPdG0DcD4aoCXQ1iOGjoHJ8evIeLhJe8Wok 6FrPbkCjZ1iUl9hIMtCwOHLkNIaSUk7zRzaDaU6h4sjuHrrAoPRVAvLUPT5RnSSnG++Z 3dksRR/A+MT+rY2PVQeJdWizizGPd5g8NW2RQYON1shygFcoLcz5c7CuwO07PWGsou8k A4DEyXkZkb5lJkIxziVbCDcR9MuWnRqSJxhzJe0+OqNNK+7qTNU1rVc7aVIfM8xcIwYK 6H5l1u6qBM2qj6X7kAn2G1bzKg3UniwZ89HeSCo1i/cmhqRKExLnnGOLO20XpILAD+Mi 0RNw==
Received: by 10.180.81.66 with SMTP id y2mr26476979wix.22.1346083602002; Mon, 27 Aug 2012 09:06:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.58.136 with HTTP; Mon, 27 Aug 2012 09:06:21 -0700 (PDT)
In-Reply-To: <010901cd846c$95d74560$c185d020$@packetizer.com>
References: <010901cd846c$95d74560$c185d020$@packetizer.com>
From: James M Snell 
Date: Mon, 27 Aug 2012 09:06:21 -0700
Message-ID: 
To: "Paul E. Jones" 
Content-Type: multipart/alternative; boundary=f46d04428d2cef715904c841824b
Cc: jsmarr@google.com, webfinger@googlegroups.com, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 16:06:44 -0000

--f46d04428d2cef715904c841824b
Content-Type: text/plain; charset=UTF-8

+1... definitely a step in the right direction... now about the rest of
it..... ;-)

- James

On Mon, Aug 27, 2012 at 8:56 AM, Paul E. Jones wrote:

> Folks,
>
> Mike, Gonzalo, and I have had some off-list discussions about WebFinger and
> how to resolve the one sticky point that we think has caused the most
> concern.  That point is whether we should we allow both XML and JSON.
>
> We have heard proposals to "just pick one" and, while I appreciate the
> reasoning, I could not help ignoring that
>
>   1) RFC 6415 exists and describes XML the single mandatory format
>   2) Existing implementations use XML
>
> Nonetheless, I also cannot ignore the long-term value in selecting one
> format we can be sure is widely supported consistently.  I'm fairly
> confident that most want only JSON at this point, even though most (if not
> all) current implementations today use XML.  While I'm personally favorable
> to using XML, I know my personal preferences are not representative of
> everyone. :-)
>
> So what we discussed was mentioning XML (perhaps with examples), but
> putting
> that in an appendix and saying the usage is historic.  What this would mean
> is that the text acknowledges that there are servers that might process
> both
> XML and JSON, and even older servers that only process XML.  The main body
> of the document would only require support for JSON from clients and
> servers.
>
> Before we make these changes to the text, I want to seek input from the
> group.  I believe it would be acceptable, but I do not want those changes
> to
> cause significant issues for anyone.
>
> Thanks,
> Paul
>
> PS - Please follow-up only on the apps-discuss list.
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--f46d04428d2cef715904c841824b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1... definitely a step in the right d=
irection... now about the rest of it..... ;-)

- James



On Mon, Aug 27, 2012 at 8:56 AM, Paul=
 E. Jones <paulej@packetizer.com> wrote:


Folks,



Mike, Gonzalo, and I have had some off-list discussions about WebFinger and=


how to resolve the one sticky point that we think has caused the most

concern. =C2=A0That point is whether we should we allow both XML and JSON.<=
br>


We have heard proposals to "just pick one" and, while I appreciat=
e the

reasoning, I could not help ignoring that



=C2=A0 1) RFC 6415 exists and describes XML the single mandatory format

=C2=A0 2) Existing implementations use XML



Nonetheless, I also cannot ignore the long-term value in selecting one

format we can be sure is widely supported consistently. =C2=A0I'm fairl=
y

confident that most want only JSON at this point, even though most (if not<=
br>
all) current implementations today use XML. =C2=A0While I'm personally =
favorable

to using XML, I know my personal preferences are not representative of

everyone. :-)



So what we discussed was mentioning XML (perhaps with examples), but puttin=
g

that in an appendix and saying the usage is historic. =C2=A0What this would=
 mean

is that the text acknowledges that there are servers that might process bot=
h

XML and JSON, and even older servers that only process XML. =C2=A0The main =
body

of the document would only require support for JSON from clients and

servers.



Before we make these changes to the text, I want to seek input from the

group. =C2=A0I believe it would be acceptable, but I do not want those chan=
ges to

cause significant issues for anyone.



Thanks,

Paul



PS - Please follow-up only on the apps-discuss list.





_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/apps-discuss





--f46d04428d2cef715904c841824b--

From wmills@yahoo-inc.com  Mon Aug 27 09:18:04 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C380821F846B for ; Mon, 27 Aug 2012 09:18:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.563
X-Spam-Level: 
X-Spam-Status: No, score=-17.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-pHW6WFq6Sh for ; Mon, 27 Aug 2012 09:18:03 -0700 (PDT)
Received: from nm22-vm0.bullet.mail.ac4.yahoo.com (nm22-vm0.bullet.mail.ac4.yahoo.com [98.139.53.218]) by ietfa.amsl.com (Postfix) with SMTP id 9688D21F8467 for ; Mon, 27 Aug 2012 09:18:03 -0700 (PDT)
Received: from [98.139.52.191] by nm22.bullet.mail.ac4.yahoo.com with NNFMP; 27 Aug 2012 16:17:57 -0000
Received: from [98.139.52.182] by tm4.bullet.mail.ac4.yahoo.com with NNFMP; 27 Aug 2012 16:17:57 -0000
Received: from [127.0.0.1] by omp1065.mail.ac4.yahoo.com with NNFMP; 27 Aug 2012 16:17:57 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 766473.14673.bm@omp1065.mail.ac4.yahoo.com
Received: (qmail 98793 invoked by uid 60001); 27 Aug 2012 16:17:57 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346084277; bh=w73AMfPh0TyAy+ZVAHRyyn+S4EbkA0E+JRbftvkuB/k=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=i0rS7yMJUY+1AswEul99DL78itLP6eAa0IHGXs53tUV43sgRnQ7eiG44pWjmZrVjgO7Hd3qTsSKMsJRVqf/EoTBgdCR2drvm3RzWQcNdZngAT9iWPt3VRPd7HkA+ACUUKH4enwecR7VAivi+RuqOs3119InbXwciR++4VVaIifM=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=W9l3X/5VW9QvReZGxl1HlWoio4g8OT3efQx9vOwZu5aXIYGTWsGUop8eg8DMdhg6lU4EMRxuFtNKyuod6SGt44scbwLr3Zz2zrwChsxLCnAK0z7MHpNP38w4crycF3SrTT7iOEoHQzpqO7VFdovxJVcztzN/LNWNAkw9Fdxvd/k=;
X-YMail-OSG: Qy.oZRgVM1k67ffhisXNQt9Mv.b4ZKMq7NrnKkaE5Yc9ES3 cUESf.Npy52E6TUnuSIwAneUyNJLYJ2Q8LhuFIN70tzXZIHXHUzjwcAq3Yhk TQeiHwf34V5oc_nnyxa8K8dnEDLSyqs2Txqt4dIGtqCpgMxqsz0zqGyDVb1v a34L4_sn1Xvy7qDZ.h7xYRyt2p3dOlEFXIxiqKqBhplr5D_TCEFBF.Gjc4xl snStWdxnwE51YFJHBAQCu6KGjbDaabdRWkrNAJb8fEFGzTkjPaSujQzkkTJ6 G5Sy_ttEemsxvTJW7m3eAhgGuHnJtK61bBJmNWI..FvLrzuJ44QIEOu_boZv Um6vIRu2EaBME86MrBeOl09qGFxH_AV9v8X5zOUK0JalZF695IOcWEqtjmMS 03mQr6rjFCmGR0CA.18ZTMTdVaq8lUqNU5gwXqtQC2i8eQzpY
Received: from [99.31.212.42] by web31802.mail.mud.yahoo.com via HTTP; Mon, 27 Aug 2012 09:17:57 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.121.416
References: <010901cd846c$95d74560$c185d020$@packetizer.com>
Message-ID: <1346084277.68046.YahooMailNeo@web31802.mail.mud.yahoo.com>
Date: Mon, 27 Aug 2012 09:17:57 -0700 (PDT)
From: William Mills 
To: "Paul E. Jones" , "apps-discuss@ietf.org" 
In-Reply-To: <010901cd846c$95d74560$c185d020$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1036955950-999941474-1346084277=:68046"
Cc: "jsmarr@google.com" , "webfinger@googlegroups.com" 
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Aug 2012 16:18:04 -0000

---1036955950-999941474-1346084277=:68046
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I think this works in general but that there should be a mention of it in t=
he body of the spec citing the appendix.=A0 Do we even need an appendix tho=
ugh, we could simply cite 6415 as still normative for the XML stuff but dep=
recated for new implementations.=0A=0A=0A=0A=0A=0A>________________________=
________=0A> From: Paul E. Jones =0A>To: apps-discus=
s@ietf.org =0A>Cc: jsmarr@google.com; webfinger@googlegroups.com =0A>Sent: =
Monday, August 27, 2012 8:56 AM=0A>Subject: [apps-discuss] Proposed changes=
 to WebFinger regarding XML vs JSON=0A> =0A>Folks,=0A>=0A>Mike, Gonzalo, an=
d I have had some off-list discussions about WebFinger and=0A>how to resolv=
e the one sticky point that we think has caused the most=0A>concern.=A0 Tha=
t point is whether we should we allow both XML and JSON.=0A>=0A>We have hea=
rd proposals to "just pick one" and, while I appreciate the=0A>reasoning, I=
 could not help ignoring that=0A>=0A>=A0 1) RFC 6415 exists and describes X=
ML the single mandatory format=0A>=A0 2) Existing implementations use XML=
=0A>=0A>Nonetheless, I also cannot ignore the long-term value in selecting =
one=0A>format we can be sure is widely supported consistently.=A0 I'm fairl=
y=0A>confident that most want only JSON at this point, even though most (if=
 not=0A>all) current implementations today use XML.=A0 While I'm personally=
 favorable=0A>to using XML, I know my personal preferences are not represen=
tative of=0A>everyone. :-)=0A>=0A>So what we discussed was mentioning XML (=
perhaps with examples), but putting=0A>that in an appendix and saying the u=
sage is historic.=A0 What this would mean=0A>is that the text acknowledges =
that there are servers that might process both=0A>XML and JSON, and even ol=
der servers that only process XML.=A0 The main body=0A>of the document woul=
d only require support for JSON from clients and=0A>servers.=0A>=0A>Before =
we make these changes to the text, I want to seek input from the=0A>group.=
=A0 I believe it would be acceptable, but I do not want those changes to=0A=
>cause significant issues for anyone.=0A>=0A>Thanks,=0A>Paul=0A>=0A>PS - Pl=
ease follow-up only on the apps-discuss list.=0A>=0A>=0A>__________________=
_____________________________=0A>apps-discuss mailing list=0A>apps-discuss@=
ietf.org=0A>https://www.ietf.org/mailman/listinfo/apps-discuss=0A>=0A>=0A>
---1036955950-999941474-1346084277=:68046
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


I think t=
his works in general but that there should be a mention of it in the body o=
f the spec citing the appendix.  Do we even need an appendix though, w=
e could simply cite 6415 as still normative for the XML stuff but deprecate=
d for new implementations.


  
 
   
  From: Paul E. Jones <paulej@packet=
izer.com>
 To:
 apps-discuss@ietf.org 
Cc:=
 jsmarr@google.com; webfinger@googlegroups.com 
 Sent: Monday, August 27, 2012 8:56 AM
 =
Subject: [apps-discuss] Propo=
sed changes to WebFinger regarding XML vs JSON
  
 
Folks=
,

Mike, Gonzalo, and I have had some off-list discussions about WebF=
inger and
how to resolve the one sticky point that we think has caused t=
he most
concern.  That point is whether we should we allow both XML=
 and JSON.

We have heard proposals to "just pick one" and, while I a=
ppreciate the
reasoning, I could not help ignoring that

  1)=
 RFC 6415 exists and describes XML the single mandatory format
  2)=
 Existing implementations use XML

Nonetheless, I also cannot ignore =
the long-term value in selecting one
format we can be sure is widely
 supported consistently.  I'm fairly
confident that most want only =
JSON at this point, even though most (if not
all) current implementation=
s today use XML.  While I'm personally favorable
to using XML, I kn=
ow my personal preferences are not representative of
everyone. :-)
So what we discussed was mentioning XML (perhaps with examples), but putt=
ing
that in an appendix and saying the usage is historic.  What thi=
s would mean
is that the text acknowledges that there are servers that m=
ight process both
XML and JSON, and even older servers that only process=
 XML.  The main body
of the document would only require support for=
 JSON from clients and
servers.

Before we make these changes to t=
he text, I want to seek input from the
group.  I believe it would b=
e acceptable, but I do not want those changes to
cause significant issue=
s for anyone.

Thanks,
Paul

PS - Please follow-up
 only on the apps-discuss list.


________________________________=
_______________
apps-discuss mailing list
apps-discuss@ietf.or=
g
https://www.ietf.org/mailman/listinfo/apps-discuss

 
 
 
   
---1036955950-999941474-1346084277=:68046--

From tbray@textuality.com  Mon Aug 27 09:26:56 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49B721F84CF for ; Mon, 27 Aug 2012 09:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.864
X-Spam-Level: 
X-Spam-Status: No, score=-4.864 tagged_above=-999 required=5 tests=[AWL=-1.887, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwDYV2rudnxY for ; Mon, 27 Aug 2012 09:26:56 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B24F021F84A7 for ; Mon, 27 Aug 2012 09:26:55 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so2374270wgb.13 for ; Mon, 27 Aug 2012 09:26:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=pIOOWLsvb1dhwogdpqI2CVDKyLN0vE7VrAlBh2GuQAE=; b=MA6Zrx9Wl3ZW96yg54I3sqsM+Ft6hZcWBWoeMlmLNrtktd1wVGIJLJoE9TXOMXN4Bo ROtxMWKlV2ul05BQu0mWsj+29rgRD64IUd8is5pRSZ5xh8wwOVjNTvAp/jJw1V2GMZlJ utx2dCka+w8ubH6eLfOYRxjGNBGJr7BXnOtCJlFAF0l27nHk7+v0ih4LcCo2Gc0KcLwO h/cnSvJYhA0X0pLfduMYJ+EmygdwCfSzLiMMmJ75g5+SfMkAy3cB9PXSWPGl1QHyWv4G fcMTVE4vzEv5/jKnavidEmB8bvgFPbkGHdkUzh6JXEbSCPWhD4c3tWTtNFB0DoYmuIwQ S93g==
MIME-Version: 1.0
Received: by 10.216.4.147 with SMTP id 19mr6905710wej.109.1346084813864; Mon, 27 Aug 2012 09:26:53 -0700 (PDT)
Received: by 10.223.195.199 with HTTP; Mon, 27 Aug 2012 09:26:53 -0700 (PDT)
X-Originating-IP: [24.84.208.217]
In-Reply-To: <1346084277.68046.YahooMailNeo@web31802.mail.mud.yahoo.com>
References: <010901cd846c$95d74560$c185d020$@packetizer.com> <1346084277.68046.YahooMailNeo@web31802.mail.mud.yahoo.com>
Date: Mon, 27 Aug 2012 09:26:53 -0700
Message-ID: 
From: Tim Bray 
To: William Mills 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkB4/IFMvdrKYdJhXiQxf11/0gkKSB6fyq19GdJd2U4IEOQCurJ++OMzrc/aHg2rkXMUbCr
Cc: "jsmarr@google.com" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 16:26:56 -0000

What William said about not needing the appendix. If you=92re going to
go through the pain of abandoning the XML version, why also go through
the pain of writing an appendix, when there=92s a perfectly good RFC in
place to point to.  -T

On Mon, Aug 27, 2012 at 9:17 AM, William Mills  wrote=
:
> I think this works in general but that there should be a mention of it in
> the body of the spec citing the appendix.  Do we even need an appendix
> though, we could simply cite 6415 as still normative for the XML stuff bu=
t
> deprecated for new implementations.
>
>
> ________________________________
> From: Paul E. Jones 
> To: apps-discuss@ietf.org
> Cc: jsmarr@google.com; webfinger@googlegroups.com
> Sent: Monday, August 27, 2012 8:56 AM
> Subject: [apps-discuss] Proposed changes to WebFinger regarding XML vs JS=
ON
>
> Folks,
>
> Mike, Gonzalo, and I have had some off-list discussions about WebFinger a=
nd
> how to resolve the one sticky point that we think has caused the most
> concern.  That point is whether we should we allow both XML and JSON.
>
> We have heard proposals to "just pick one" and, while I appreciate the
> reasoning, I could not help ignoring that
>
>   1) RFC 6415 exists and describes XML the single mandatory format
>   2) Existing implementations use XML
>
> Nonetheless, I also cannot ignore the long-term value in selecting one
> format we can be sure is widely supported consistently.  I'm fairly
> confident that most want only JSON at this point, even though most (if no=
t
> all) current implementations today use XML.  While I'm personally favorab=
le
> to using XML, I know my personal preferences are not representative of
> everyone. :-)
>
> So what we discussed was mentioning XML (perhaps with examples), but putt=
ing
> that in an appendix and saying the usage is historic.  What this would me=
an
> is that the text acknowledges that there are servers that might process b=
oth
> XML and JSON, and even older servers that only process XML.  The main bod=
y
> of the document would only require support for JSON from clients and
> servers.
>
> Before we make these changes to the text, I want to seek input from the
> group.  I believe it would be acceptable, but I do not want those changes=
 to
> cause significant issues for anyone.
>
> Thanks,
> Paul
>
> PS - Please follow-up only on the apps-discuss list.
>
>
> _______________________________________________
> 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 romeda@gmail.com  Mon Aug 27 09:29:35 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571FA21F84D5 for ; Mon, 27 Aug 2012 09:29:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x91CwJd5r8Bf for ; Mon, 27 Aug 2012 09:29:34 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C711421F84CF for ; Mon, 27 Aug 2012 09:29:34 -0700 (PDT)
Received: by pbbrr4 with SMTP id rr4so7607410pbb.31 for ; Mon, 27 Aug 2012 09:29: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:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=0oBSb23Be0Xq+h9vLUeEzNn/p6S4FQ4ErhLvk0BCCi4=; b=w/aQsRQ8qb+wlr/bU7/HP/Ijh+USxTANE7JkD70Gi8yJKktWX16cKFY5P28ArpDD3t JIDS8ji4y+gypkWzPt5UDPIlzN3M/+5kiPZ0nNMgGMpHVliwp7FYo3nUR4NZW0Fz5D3e /IQMYCt95F5mBjsfIyRCJ8ACpTCOoqX9h/ItAhmS/7Esl/IrHxTa/ngeTSma2ZiIT4LL Zx6YgT7Px5X723cbnMsGS9dTjfvTMtcpoUzK8H8M/wNC6MExEBfiyATWqyiAnNIrPE+o qRIS4VSnF5NU+QnVpA+IMbo8GQ7KCmnUGvlrW1vOBdK/kjCJ05rzs2dqkCc81wyLAI78 fBUQ==
Received: by 10.66.78.194 with SMTP id d2mr22157744pax.42.1346084974559; Mon, 27 Aug 2012 09:29:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.190.99 with HTTP; Mon, 27 Aug 2012 09:29:14 -0700 (PDT)
In-Reply-To: 
References: <010901cd846c$95d74560$c185d020$@packetizer.com> <1346084277.68046.YahooMailNeo@web31802.mail.mud.yahoo.com> 
From: Blaine Cook 
Date: Mon, 27 Aug 2012 18:29:14 +0200
Message-ID: 
To: "apps-discuss@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 16:29:35 -0000

+1 to this, and William and Tim's points.

On 27 August 2012 18:26, Tim Bray  wrote:
> What William said about not needing the appendix. If you=E2=80=99re going=
 to
> go through the pain of abandoning the XML version, why also go through
> the pain of writing an appendix, when there=E2=80=99s a perfectly good RF=
C in
> place to point to.  -T
>
> On Mon, Aug 27, 2012 at 9:17 AM, William Mills  wro=
te:
>> I think this works in general but that there should be a mention of it i=
n
>> the body of the spec citing the appendix.  Do we even need an appendix
>> though, we could simply cite 6415 as still normative for the XML stuff b=
ut
>> deprecated for new implementations.
>>
>>
>> ________________________________
>> From: Paul E. Jones 
>> To: apps-discuss@ietf.org
>> Cc: jsmarr@google.com; webfinger@googlegroups.com
>> Sent: Monday, August 27, 2012 8:56 AM
>> Subject: [apps-discuss] Proposed changes to WebFinger regarding XML vs J=
SON
>>
>> Folks,
>>
>> Mike, Gonzalo, and I have had some off-list discussions about WebFinger =
and
>> how to resolve the one sticky point that we think has caused the most
>> concern.  That point is whether we should we allow both XML and JSON.
>>
>> We have heard proposals to "just pick one" and, while I appreciate the
>> reasoning, I could not help ignoring that
>>
>>   1) RFC 6415 exists and describes XML the single mandatory format
>>   2) Existing implementations use XML
>>
>> Nonetheless, I also cannot ignore the long-term value in selecting one
>> format we can be sure is widely supported consistently.  I'm fairly
>> confident that most want only JSON at this point, even though most (if n=
ot
>> all) current implementations today use XML.  While I'm personally favora=
ble
>> to using XML, I know my personal preferences are not representative of
>> everyone. :-)
>>
>> So what we discussed was mentioning XML (perhaps with examples), but put=
ting
>> that in an appendix and saying the usage is historic.  What this would m=
ean
>> is that the text acknowledges that there are servers that might process =
both
>> XML and JSON, and even older servers that only process XML.  The main bo=
dy
>> of the document would only require support for JSON from clients and
>> servers.
>>
>> Before we make these changes to the text, I want to seek input from the
>> group.  I believe it would be acceptable, but I do not want those change=
s to
>> cause significant issues for anyone.
>>
>> Thanks,
>> Paul
>>
>> PS - Please follow-up only on the apps-discuss list.
>>
>>
>> _______________________________________________
>> 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 paulej@packetizer.com  Mon Aug 27 14:56:07 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FDE21E803A for ; Mon, 27 Aug 2012 14:56:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.498
X-Spam-Level: 
X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2dIRbFy5D89 for ; Mon, 27 Aug 2012 14:56:06 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 957BC21E8037 for ; Mon, 27 Aug 2012 14:56:06 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q7RLu416024582 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Aug 2012 17:56:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1346104565; bh=Qh8HW9tM6YW/ugIxtwAWnBih8rPH+egewdvQT7dbJPQ=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=l/Dth9OR7Yrzp3baHU02aWqwzTK0SXDVZeqTEfNxnHiZofoE9IQ/Yd7CpVbMWp0NZ JPP5C7HMV3aDAviJ/5cugHRqGC7CazQ1SD2bHnS0oS7KXDrIbEFimDWWJqGx7CqFkr 32sG3RbJFwEApja7mggNicPGcHtayLpqdrRmUXGw=
From: "Paul E. Jones" 
To: "'Blaine Cook'" , 
References: <010901cd846c$95d74560$c185d020$@packetizer.com>	<1346084277.68046.YahooMailNeo@web31802.mail.mud.yahoo.com>	 
In-Reply-To: 
Date: Mon, 27 Aug 2012 17:56:21 -0400
Message-ID: <017001cd849e$cbdd9c90$6398d5b0$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIrZE+abU/d+x34aW2WxIOtEY8jpwIfXwJkAk1l+2oB11boGpaAUz5g
Content-Language: en-us
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs	JSON
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 21:56:07 -0000

Ok... we could also do that.=20

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org]
> On Behalf Of Blaine Cook
> Sent: Monday, August 27, 2012 12:29 PM
> To: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding =
XML vs
> JSON
>=20
> +1 to this, and William and Tim's points.
>=20
> On 27 August 2012 18:26, Tim Bray  wrote:
> > What William said about not needing the appendix. If you=E2=80=99re =
going to
> > go through the pain of abandoning the XML version, why also go =
through
> > the pain of writing an appendix, when there=E2=80=99s a perfectly =
good RFC in
> > place to point to.  -T
> >
> > On Mon, Aug 27, 2012 at 9:17 AM, William Mills =

> wrote:
> >> I think this works in general but that there should be a mention of
> >> it in the body of the spec citing the appendix.  Do we even need an
> >> appendix though, we could simply cite 6415 as still normative for =
the
> >> XML stuff but deprecated for new implementations.
> >>
> >>
> >> ________________________________
> >> From: Paul E. Jones 
> >> To: apps-discuss@ietf.org
> >> Cc: jsmarr@google.com; webfinger@googlegroups.com
> >> Sent: Monday, August 27, 2012 8:56 AM
> >> Subject: [apps-discuss] Proposed changes to WebFinger regarding XML
> >> vs JSON
> >>
> >> Folks,
> >>
> >> Mike, Gonzalo, and I have had some off-list discussions about
> >> WebFinger and how to resolve the one sticky point that we think has
> >> caused the most concern.  That point is whether we should we allow =
both
> XML and JSON.
> >>
> >> We have heard proposals to "just pick one" and, while I appreciate
> >> the reasoning, I could not help ignoring that
> >>
> >>   1) RFC 6415 exists and describes XML the single mandatory format
> >>   2) Existing implementations use XML
> >>
> >> Nonetheless, I also cannot ignore the long-term value in selecting
> >> one format we can be sure is widely supported consistently.  I'm
> >> fairly confident that most want only JSON at this point, even =
though
> >> most (if not
> >> all) current implementations today use XML.  While I'm personally
> >> favorable to using XML, I know my personal preferences are not
> >> representative of everyone. :-)
> >>
> >> So what we discussed was mentioning XML (perhaps with examples), =
but
> >> putting that in an appendix and saying the usage is historic.  What
> >> this would mean is that the text acknowledges that there are =
servers
> >> that might process both XML and JSON, and even older servers that
> >> only process XML.  The main body of the document would only require
> >> support for JSON from clients and servers.
> >>
> >> Before we make these changes to the text, I want to seek input from
> >> the group.  I believe it would be acceptable, but I do not want =
those
> >> changes to cause significant issues for anyone.
> >>
> >> Thanks,
> >> Paul
> >>
> >> PS - Please follow-up only on the apps-discuss list.
> >>
> >>
> >> _______________________________________________
> >> 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
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From wnorris@gmail.com  Mon Aug 27 16:13:44 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3793D21E804C for ; Mon, 27 Aug 2012 16:13:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHorotxZOenL for ; Mon, 27 Aug 2012 16:13:43 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF84521E804B for ; Mon, 27 Aug 2012 16:13:42 -0700 (PDT)
Received: by obbwc20 with SMTP id wc20so10588487obb.31 for ; Mon, 27 Aug 2012 16:13: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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=WuioPQB5lNjUJP6a7wXG8PbI2gZ85odPaAcF1/kBJ/0=; b=hyIvVTpjU7x/nlpt7XEXra5n1CThTtcjYI0keET3nFkB8oScbfzv40kfViW0Pn8owb l+Uhv2B6KZk2xJvzmTAYKC7UL5kj/AQcGnAxZK2uj5HBiuzCWGZpNgpTUFi04b6nZdNd DuKYmKQUcSbG4nD48LXaPqPT2RgBPccZR3pcRqKBJfGwVNTnyh6gYPHk2TQY1MloSSa+ VAJ5j4yZVjuVFJlpNQZZnOJszMWtmv/glHFUC2XfWOzt7zFUgVUWRZSKZc2R1gFp3UwX sOdUPl5NegSXYVFt63eY0YztGQbFsMKhX36AbO1rocJ8ZodeMXhWMyaL3jWf6lJN6I99 KuXA==
Received: by 10.60.29.165 with SMTP id l5mr11457325oeh.105.1346109222568; Mon, 27 Aug 2012 16:13:42 -0700 (PDT)
MIME-Version: 1.0
Sender: wnorris@gmail.com
Received: by 10.60.97.166 with HTTP; Mon, 27 Aug 2012 16:13:22 -0700 (PDT)
In-Reply-To: <017001cd849e$cbdd9c90$6398d5b0$@packetizer.com>
References: <010901cd846c$95d74560$c185d020$@packetizer.com> <1346084277.68046.YahooMailNeo@web31802.mail.mud.yahoo.com>   <017001cd849e$cbdd9c90$6398d5b0$@packetizer.com>
From: Will Norris 
Date: Mon, 27 Aug 2012 16:13:22 -0700
X-Google-Sender-Auth: G0ezA43KSsJ4IodqUpjIIFMQxfY
Message-ID: 
To: "Paul E. Jones" 
Content-Type: multipart/alternative; boundary=e89a8ff256160a451604c8477ab0
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 23:18:02 -0000

--e89a8ff256160a451604c8477ab0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

as one of the editors of said XML format, I'm +1 as well.  The reasons for
pushing so heavily for the XML format back then are no longer really true.
 Instead, all the active work is on JSON-based formats, so it makes sense
to update webfinger as well.

On Mon, Aug 27, 2012 at 2:56 PM, Paul E. Jones wrote=
:

> Ok... we could also do that.
>
> > -----Original Message-----
> > From: apps-discuss-bounces@ietf.org [mailto:
> apps-discuss-bounces@ietf.org]
> > On Behalf Of Blaine Cook
> > Sent: Monday, August 27, 2012 12:29 PM
> > To: apps-discuss@ietf.org
> > Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML
> vs
> > JSON
> >
> > +1 to this, and William and Tim's points.
> >
> > On 27 August 2012 18:26, Tim Bray  wrote:
> > > What William said about not needing the appendix. If you=92re going t=
o
> > > go through the pain of abandoning the XML version, why also go throug=
h
> > > the pain of writing an appendix, when there=92s a perfectly good RFC =
in
> > > place to point to.  -T
> > >
> > > On Mon, Aug 27, 2012 at 9:17 AM, William Mills 
> > wrote:
> > >> I think this works in general but that there should be a mention of
> > >> it in the body of the spec citing the appendix.  Do we even need an
> > >> appendix though, we could simply cite 6415 as still normative for th=
e
> > >> XML stuff but deprecated for new implementations.
> > >>
> > >>
> > >> ________________________________
> > >> From: Paul E. Jones 
> > >> To: apps-discuss@ietf.org
> > >> Cc: jsmarr@google.com; webfinger@googlegroups.com
> > >> Sent: Monday, August 27, 2012 8:56 AM
> > >> Subject: [apps-discuss] Proposed changes to WebFinger regarding XML
> > >> vs JSON
> > >>
> > >> Folks,
> > >>
> > >> Mike, Gonzalo, and I have had some off-list discussions about
> > >> WebFinger and how to resolve the one sticky point that we think has
> > >> caused the most concern.  That point is whether we should we allow
> both
> > XML and JSON.
> > >>
> > >> We have heard proposals to "just pick one" and, while I appreciate
> > >> the reasoning, I could not help ignoring that
> > >>
> > >>   1) RFC 6415 exists and describes XML the single mandatory format
> > >>   2) Existing implementations use XML
> > >>
> > >> Nonetheless, I also cannot ignore the long-term value in selecting
> > >> one format we can be sure is widely supported consistently.  I'm
> > >> fairly confident that most want only JSON at this point, even though
> > >> most (if not
> > >> all) current implementations today use XML.  While I'm personally
> > >> favorable to using XML, I know my personal preferences are not
> > >> representative of everyone. :-)
> > >>
> > >> So what we discussed was mentioning XML (perhaps with examples), but
> > >> putting that in an appendix and saying the usage is historic.  What
> > >> this would mean is that the text acknowledges that there are servers
> > >> that might process both XML and JSON, and even older servers that
> > >> only process XML.  The main body of the document would only require
> > >> support for JSON from clients and servers.
> > >>
> > >> Before we make these changes to the text, I want to seek input from
> > >> the group.  I believe it would be acceptable, but I do not want thos=
e
> > >> changes to cause significant issues for anyone.
> > >>
> > >> Thanks,
> > >> Paul
> > >>
> > >> PS - Please follow-up only on the apps-discuss list.
> > >>
> > >>
> > >> _______________________________________________
> > >> 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
> > _______________________________________________
> > 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
>

--e89a8ff256160a451604c8477ab0
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

as one of the editors of said XML format, I'm +1 as well. =A0The reason=
s for pushing so heavily for the XML format back then are no longer really =
true. =A0Instead, all the active work is on JSON-based formats, so it makes=
 sense to update webfinger as well.



On Mon, Aug 27, 2012 at 2:56 PM, Paul E. Jon=
es <paulej@packetizer.com> wrote:


Ok... we could also do that.




> -----Original Message-----

> From: apps-discuss-bo=
unces@ietf.org [mailto:apps-discuss-bounces@ietf.org]

> On Behalf Of Blaine Cook

> Sent: Monday, August 27, 2012 12:29 PM

> To: apps-discuss@ietf.org=


> Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XM=
L vs

> JSON

>

> +1 to this, and William and Tim's points.

>

> On 27 August 2012 18:26, Tim Bray <tbray@textuality.com> wrote:

> > What William said about not needing the appendix. If you=92re goi=
ng to

> > go through the pain of abandoning the XML version, why also go th=
rough

> > the pain of writing an appendix, when there=92s a perfectly good =
RFC in

> > place to point to. =A0-T

> >

> > On Mon, Aug 27, 2012 at 9:17 AM, William Mills <wmills@yahoo-inc.com>

> wrote:

> >> I think this works in general but that there should be a ment=
ion of

> >> it in the body of the spec citing the appendix. =A0Do we even=
 need an

> >> appendix though, we could simply cite 6415 as still normative=
 for the

> >> XML stuff but deprecated for new implementations.

> >>

> >>

> >> ________________________________

> >> From: Paul E. Jones <paulej@packetizer.com>

> >> To: apps-discuss@iet=
f.org

> >> Cc: jsmarr@google.com; webfinger@googlegroups.com=


> >> Sent: Monday, August 27, 2012 8:56 AM

> >> Subject: [apps-discuss] Proposed changes to WebFinger regardi=
ng XML

> >> vs JSON

> >>

> >> Folks,

> >>

> >> Mike, Gonzalo, and I have had some off-list discussions about=


> >> WebFinger and how to resolve the one sticky point that we thi=
nk has

> >> caused the most concern. =A0That point is whether we should w=
e allow both

> XML and JSON.

> >>

> >> We have heard proposals to "just pick one" and, whi=
le I appreciate

> >> the reasoning, I could not help ignoring that

> >>

> >> =A0 1) RFC 6415 exists and describes XML the single mandatory=
 format

> >> =A0 2) Existing implementations use XML

> >>

> >> Nonetheless, I also cannot ignore the long-term value in sele=
cting

> >> one format we can be sure is widely supported consistently. =
=A0I'm

> >> fairly confident that most want only JSON at this point, even=
 though

> >> most (if not

> >> all) current implementations today use XML. =A0While I'm =
personally

> >> favorable to using XML, I know my personal preferences are no=
t

> >> representative of everyone. :-)

> >>

> >> So what we discussed was mentioning XML (perhaps with example=
s), but

> >> putting that in an appendix and saying the usage is historic.=
 =A0What

> >> this would mean is that the text acknowledges that there are =
servers

> >> that might process both XML and JSON, and even older servers =
that

> >> only process XML. =A0The main body of the document would only=
 require

> >> support for JSON from clients and servers.

> >>

> >> Before we make these changes to the text, I want to seek inpu=
t from

> >> the group. =A0I believe it would be acceptable, but I do not =
want those

> >> changes to cause significant issues for anyone.

> >>

> >> Thanks,

> >> Paul

> >>

> >> PS - Please follow-up only on the apps-discuss list.

> >>

> >>

> >> _______________________________________________

> >> apps-discuss mailing list

> >> apps-discuss@ietf.or=
g

> >> https://www.ietf.org/mailman/listinfo/apps-discuss<=
br>
> >>

> >>

> >>

> >> _______________________________________________

> >> apps-discuss mailing list

> >> apps-discuss@ietf.or=
g

> >> https://www.ietf.org/mailman/listinfo/apps-discuss<=
br>
> >>

> > _______________________________________________

> > 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





--e89a8ff256160a451604c8477ab0--

From perpetual-tripper@wwelves.org  Tue Aug 28 05:21:03 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B468B21F852D for ; Tue, 28 Aug 2012 05:21:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.224
X-Spam-Level: 
X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=0.375,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNbYKOvLKwao for ; Tue, 28 Aug 2012 05:21:03 -0700 (PDT)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ietfa.amsl.com (Postfix) with ESMTP id 96FE321F852C for ; Tue, 28 Aug 2012 05:21:02 -0700 (PDT)
X-Originating-IP: 217.70.178.150
Received: from mfilter22-d.gandi.net (mfilter22-d.gandi.net [217.70.178.150]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id EE299172070 for ; Tue, 28 Aug 2012 14:20:50 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter22-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter22-d.gandi.net (mfilter22-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id pjDBbfH2eVkS for ; Tue, 28 Aug 2012 14:20:49 +0200 (CEST)
X-Originating-IP: 217.11.53.243
Received: from localhost (243.53.11.217.in-addr.arpa.manitu.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 5CFCC17209F for ; Tue, 28 Aug 2012 14:20:49 +0200 (CEST)
Content-Type: text/plain; charset=UTF-8
From: elf Pavlik 
To: apps-discuss 
In-reply-to: <017001cd849e$cbdd9c90$6398d5b0$@packetizer.com>
References: <010901cd846c$95d74560$c185d020$@packetizer.com> <1346084277.68046.YahooMailNeo@web31802.mail.mud.yahoo.com>   <017001cd849e$cbdd9c90$6398d5b0$@packetizer.com>
Date: Tue, 28 Aug 2012 12:20:48 +0000
Message-Id: <1346156394-sup-3044@heahdk.net>
User-Agent: Sup/0.12.1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 12:21:03 -0000

Excerpts from Paul E. Jones's message of 2012-08-27 21:56:21 +0000:
> Ok... we could also do that.=20
+1

>=20
> > -----Original Message-----
> > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf=
.org]
> > On Behalf Of Blaine Cook
> > Sent: Monday, August 27, 2012 12:29 PM
> > To: apps-discuss@ietf.org
> > Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding X=
ML vs
> > JSON
> >=20
> > +1 to this, and William and Tim's points.
> >=20
> > On 27 August 2012 18:26, Tim Bray  wrote:
> > > What William said about not needing the appendix. If you=E2=80=99re=
 going to
> > > go through the pain of abandoning the XML version, why also go thro=
ugh
> > > the pain of writing an appendix, when there=E2=80=99s a perfectly g=
ood RFC in
> > > place to point to.  -T
> > >
> > > On Mon, Aug 27, 2012 at 9:17 AM, William Mills 
> > wrote:
> > >> I think this works in general but that there should be a mention o=
f
> > >> it in the body of the spec citing the appendix.  Do we even need a=
n
> > >> appendix though, we could simply cite 6415 as still normative for =
the
> > >> XML stuff but deprecated for new implementations.
> > >>
> > >>
> > >> ________________________________
> > >> From: Paul E. Jones 
> > >> To: apps-discuss@ietf.org
> > >> Cc: jsmarr@google.com; webfinger@googlegroups.com
> > >> Sent: Monday, August 27, 2012 8:56 AM
> > >> Subject: [apps-discuss] Proposed changes to WebFinger regarding XM=
L
> > >> vs JSON
> > >>
> > >> Folks,
> > >>
> > >> Mike, Gonzalo, and I have had some off-list discussions about
> > >> WebFinger and how to resolve the one sticky point that we think ha=
s
> > >> caused the most concern.  That point is whether we should we allow=
 both
> > XML and JSON.
> > >>
> > >> We have heard proposals to "just pick one" and, while I appreciate
> > >> the reasoning, I could not help ignoring that
> > >>
> > >>   1) RFC 6415 exists and describes XML the single mandatory format
> > >>   2) Existing implementations use XML
> > >>
> > >> Nonetheless, I also cannot ignore the long-term value in selecting
> > >> one format we can be sure is widely supported consistently.  I'm
> > >> fairly confident that most want only JSON at this point, even thou=
gh
> > >> most (if not
> > >> all) current implementations today use XML.  While I'm personally
> > >> favorable to using XML, I know my personal preferences are not
> > >> representative of everyone. :-)
> > >>
> > >> So what we discussed was mentioning XML (perhaps with examples), b=
ut
> > >> putting that in an appendix and saying the usage is historic.  Wha=
t
> > >> this would mean is that the text acknowledges that there are serve=
rs
> > >> that might process both XML and JSON, and even older servers that
> > >> only process XML.  The main body of the document would only requir=
e
> > >> support for JSON from clients and servers.
> > >>
> > >> Before we make these changes to the text, I want to seek input fro=
m
> > >> the group.  I believe it would be acceptable, but I do not want th=
ose
> > >> changes to cause significant issues for anyone.
> > >>
> > >> Thanks,
> > >> Paul
> > >>
> > >> PS - Please follow-up only on the apps-discuss list.
> > >>
> > >>
> > >> _______________________________________________
> > >> 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
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
>=20

From melvincarvalho@gmail.com  Tue Aug 28 05:23:09 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14CDE21F852C for ; Tue, 28 Aug 2012 05:23:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.555
X-Spam-Level: 
X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZTznKzFVTMU for ; Tue, 28 Aug 2012 05:23:08 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D9C6F21F8476 for ; Tue, 28 Aug 2012 05:23:07 -0700 (PDT)
Received: by lbky2 with SMTP id y2so2612568lbk.31 for ; Tue, 28 Aug 2012 05:23:06 -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=AKD1jeI98ccEfqBbO5H63W0VTXCIrX9oa3c2ErYOv2I=; b=KIvb+Llo/wsCfpNdqd1GbleIJ8/vpVaWPXBXCH0cVzttPB/ejR8AtY/B0aGvsXDaJH 3J8AcrJUqs+sr8XtAovEdCgLcyvVA+AY9V+YzzJ3k1X4kUI5uAzn46oDCzZg7x+3sUGv 0NadWYkPwUb83yL/RW9yfYbsmX8ol/ne2S5dwy9Q+ap+eKOlMd5nocpsSzcGNo/jFseW VoSJ4PYPSf1VhoJEGZegHUuhVozCJnKCeRIh0g4U7Deg2NYT+GT2Hc5BUHTvEv5l0S1t IC67QJY232p2Z07PYJVSGlWXfg74QHkwajxD4f4z5M1m4tgowdHW1EVVQ+ggfz3Zgn6Y juqg==
MIME-Version: 1.0
Received: by 10.112.86.200 with SMTP id r8mr8015042lbz.87.1346156586753; Tue, 28 Aug 2012 05:23:06 -0700 (PDT)
Received: by 10.112.148.231 with HTTP; Tue, 28 Aug 2012 05:23:06 -0700 (PDT)
In-Reply-To: <010901cd846c$95d74560$c185d020$@packetizer.com>
References: <010901cd846c$95d74560$c185d020$@packetizer.com>
Date: Tue, 28 Aug 2012 14:23:06 +0200
Message-ID: 
From: Melvin Carvalho 
To: webfinger@googlegroups.com
Content-Type: multipart/alternative; boundary=f46d040172fd2a5ed904c8528140
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 12:23:09 -0000

--f46d040172fd2a5ed904c8528140
Content-Type: text/plain; charset=ISO-8859-1

On 27 August 2012 17:56, Paul E. Jones  wrote:

> Folks,
>
> Mike, Gonzalo, and I have had some off-list discussions about WebFinger and
> how to resolve the one sticky point that we think has caused the most
> concern.  That point is whether we should we allow both XML and JSON.
>
> We have heard proposals to "just pick one" and, while I appreciate the
> reasoning, I could not help ignoring that
>
>   1) RFC 6415 exists and describes XML the single mandatory format
>   2) Existing implementations use XML
>
> Nonetheless, I also cannot ignore the long-term value in selecting one
> format we can be sure is widely supported consistently.  I'm fairly
> confident that most want only JSON at this point, even though most (if not
> all) current implementations today use XML.  While I'm personally favorable
> to using XML, I know my personal preferences are not representative of
> everyone. :-)
>
> So what we discussed was mentioning XML (perhaps with examples), but
> putting
> that in an appendix and saying the usage is historic.  What this would mean
> is that the text acknowledges that there are servers that might process
> both
> XML and JSON, and even older servers that only process XML.  The main body
> of the document would only require support for JSON from clients and
> servers.
>
> Before we make these changes to the text, I want to seek input from the
> group.  I believe it would be acceptable, but I do not want those changes
> to
> cause significant issues for anyone.
>

+1 for the general move towards JSON.

Earlier this year I made a case that there are two areas that could
strengthen webfinger

1) A shift towards JSON

I think we've made big progress on this one.  Happy with the state of
affairs, after reading thru this thread.

2) That acct: could be removed from the spec to reduce complexity

Again there has been a lot of progress on this, but I suppose there is
still some elements of contention.

While *acct* has grown on me slightly, happy that the two RFCs are, to an
extent, decoupled.

>From the discussions, so far, I like the idea from mnot of using
.well-known/user/bob as being simple, intuitive and easy to implement

I think webfinger is becoming a stronger spec, as time goes on, in terms of
ease of deployment, interoperability and quality.

+1 Great to see this progress!



>
> Thanks,
> Paul
>
> PS - Please follow-up only on the apps-discuss list.
>
>
>

--f46d040172fd2a5ed904c8528140
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On 27 August 2012 17:56, Paul E. Jones <=
span dir=3D"ltr"><paulej@packetizer.com> wrote:

Folks,



Mike, Gonzalo, and I have had some off-list discussions about WebFinger and=


how to resolve the one sticky point that we think has caused the most

concern. =A0That point is whether we should we allow both XML and JSON.



We have heard proposals to "just pick one" and, while I appreciat=
e the

reasoning, I could not help ignoring that



=A0 1) RFC 6415 exists and describes XML the single mandatory format

=A0 2) Existing implementations use XML



Nonetheless, I also cannot ignore the long-term value in selecting one

format we can be sure is widely supported consistently. =A0I'm fairly
confident that most want only JSON at this point, even though most (if not<=
br>
all) current implementations today use XML. =A0While I'm personally fav=
orable

to using XML, I know my personal preferences are not representative of

everyone. :-)



So what we discussed was mentioning XML (perhaps with examples), but puttin=
g

that in an appendix and saying the usage is historic. =A0What this would me=
an

is that the text acknowledges that there are servers that might process bot=
h

XML and JSON, and even older servers that only process XML. =A0The main bod=
y

of the document would only require support for JSON from clients and

servers.



Before we make these changes to the text, I want to seek input from the

group. =A0I believe it would be acceptable, but I do not want those changes=
 to

cause significant issues for anyone.

+1 for the ge=
neral move towards JSON.=A0 

Earlier this year I made a case that th=
ere are two areas that could strengthen webfinger

1) A shift towards=
 JSON 


I think we've made big progress on this one.=A0 Happy with the stat=
e of affairs, after reading thru this thread.

2) That acct: could be=
 removed from the spec to reduce complexity

Again there has been a l=
ot of progress on this, but I suppose there is still some elements of conte=
ntion.


While *acct* has grown on me slightly, happy that the two RFCs are, to =
an extent, decoupled.


From the discussions, so far, I like the idea from mnot of using .well-=
known/user/bob as being simple, intuitive and easy to implement

I th=
ink webfinger is becoming a stronger spec, as time goes on, in terms of eas=
e of deployment, interoperability and quality.=A0 


+1 Great to see this progress!

=A0



Thanks,

Paul



PS - Please follow-up only on the apps-discuss list.









--f46d040172fd2a5ed904c8528140--

From gffletch@aol.com  Tue Aug 28 08:09:41 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E35911E80F6 for ; Tue, 28 Aug 2012 08:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.833
X-Spam-Level: 
X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfZm5KBcPuv1 for ; Tue, 28 Aug 2012 08:09:40 -0700 (PDT)
Received: from imr-da03.mx.aol.com (imr-da03.mx.aol.com [205.188.105.145]) by ietfa.amsl.com (Postfix) with ESMTP id C413811E8099 for ; Tue, 28 Aug 2012 08:09:39 -0700 (PDT)
Received: from mtaout-mb03.r1000.mx.aol.com (mtaout-mb03.r1000.mx.aol.com [172.29.41.67]) by imr-da03.mx.aol.com (8.14.1/8.14.1) with ESMTP id q7SF9Rcu013791; Tue, 28 Aug 2012 11:09:27 -0400
Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb03.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 8DAD4E0000BA; Tue, 28 Aug 2012 11:09:26 -0400 (EDT)
Message-ID: <503CDF26.8050000@aol.com>
Date: Tue, 28 Aug 2012 11:09:26 -0400
From: George Fletcher 
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Mark Nottingham 
References:  <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com>   <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com>      <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060008080903020001050603"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1346166567; bh=92ox2BTCqYXFYfTPZsn+xKHZ55uOSk3S8DLafr6phwM=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=oQOaldQg7t5AYcGy09sFLrv3niZjS8rMekBOEB9CTsxZV4qEwSwf9U9OT24fLGLES U3NqnVQsaZM+E3tS0dtiTl4i7CjRAEPG4GSGmAij/VamXnlSHaM7usQaYHNwKojFQQ Zf0XUCJB3ZnwqFMv1ra2SemT4y0pqAJWlPLTH/Go=
X-AOL-SCOLL-SCORE: 1:2:464169440:93952408  
X-AOL-SCOLL-URL_COUNT: 1  
x-aol-sid: 3039ac1d2943503cdf266b25
X-AOL-IP: 10.181.186.254
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 15:09:41 -0000

This is a multi-part message in MIME format.
--------------060008080903020001050603
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Way "late to the party" but I can speak from experience that deployment 
can be a real issue in some environments. It's all really straight 
forward in a small company or an environment where the identity team 
"owns" the root domain (e.g. example.com). However, if an entire other 
group in a large organization "owns" the root domain (home page for the 
site) and the identity team then needs to get them to make changes, the 
deployment solution gets brittle pretty quick. I've had our webfinger 
support broken at least twice because the "other" team didn't know that 
certain configs were required:)

Also, installing the "dynamic pluming" can be more problematic is these 
cases. It is possible to get apache rewrite rules or netscaler magic in 
place to make it work, it's just a more brittle deployment architecture.

Thanks,
George

On 7/4/12 6:58 PM, John Panzer wrote:
> Mark -- Of course I was speaking about practical realities of typical 
> web server administration and deployment.  In practical terms, adding 
> a new mod_rewrite rule or moral equivalent is going to be easier than 
> adding a new PHP script that connects to a database.  The latter is 
> just always going to be a much higher bar.
>
> And, something that returns per-user data is generally going to need a 
> dynamic service of some kind, unless your site has just a handful of 
> users and you don't mind going through a publishing exercise each time 
> you add or change a user...
>
> None of this has anything to do with the interface, just deployment 
> realities.  And in reality all of this is going to need a dynamic 
> service somewhere for each non-trivial site, this is all just a 
> question of how to hook it up.
>
> --
> John Panzer / Google
> jpanzer@google.com  / abstractioneer.org 
>  / @jpanzer
>
>
>
> On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham  > wrote:
>
>     On 05/07/2012, at 8:16 AM, John Panzer wrote:
>
>     > Just as a historical note.  The envisioned usage of host-meta
>     was originally to avoid a specification which mandated a
>     particular dynamic URL API at a particular /.well-known endpoint
>     (because it may not be feasible to do that across all
>     organizations and deployments).  The host-meta document itself
>     would be highly cacheable and so wouldn't incur an additional
>     network trip in the common case.
>     >
>     > Having a 3xx redirect is a reasonable alternative that allows a
>     similar escape hatch via something like mod_rewrite, albeit at the
>     cost of needing an additional network trip each time.  Since a
>     deployment can always avoid the 3xx redirect with additional
>     dynamic plumbing behind the well-known endpoint, I don't think
>     that's a horrible thing.
>     >
>     > An application-level redirect would be almost equivalent to an
>     HTTP redirect, but then there are two ways to do the same thing.
>      If _only_ an application-level redirect is allowed, then you have
>     to have at least a minimal dynamic service at the well-known
>     endpoint (no more mod_rewrite).  But the whole reason for this is
>     to avoid the requirement for a dynamic service behind well-known...
>
>     "dynamic" and "static" are properties of the implementation, not
>     the interface. HTTP doesn't require that any particular URL be
>     "dynamic"; anything can, with the right metadata, be cached (and
>     indeed, I've cached many, many things with the wrong metadata,
>     because of silly site operators and their ideas about "dynamic").
>
>     Now, if people want to target a particular implementation that
>     makes it easier to serve a particular style of URL without writing
>     code, fine, but let's not confuse things.
>
>     E.g., a URL like
>
>     http://example.com/.well-known/user/bob
>
>     is easy to serve in pretty much any way you like with Apache.
>
>     I'm also going to push back on the "it may not be feasible to do
>     that across all organizations and deployments" motivation. This is
>     a race to the bottom. The trick is to make it accessible enough to
>     get sufficient traction to pull everyone along, without pandering
>     to *everyone*'s requirements.
>
>     Regards,
>
>     --
>     Mark Nottingham http://www.mnot.net/
>
>
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


--------------060008080903020001050603
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Way "late to the party"
      but I can speak from experience that deployment can be a real
      issue in some environments. It's all really straight forward in a
      small company or an environment where the identity team "owns" the
      root domain (e.g. example.com). However, if an entire other group
      in a large organization "owns" the root domain (home page for the
      site) and the identity team then needs to get them to make
      changes, the deployment solution gets brittle pretty quick. I've
      had our webfinger support broken at least twice because the
      "other" team didn't know that certain configs were required:)

      

      Also, installing the "dynamic pluming" can be more problematic is
      these cases. It is possible to get apache rewrite rules or
      netscaler magic in place to make it work, it's just a more brittle
      deployment architecture.

      

      Thanks,

      George

      

    
    
On 7/4/12 6:58 PM, John Panzer wrote:

    

    
Mark -- Of course I was speaking about practical
      realities of typical web server administration and deployment.  In
      practical terms, adding a new mod_rewrite rule or moral equivalent
      is going to be easier than adding a new PHP script that connects
      to a database.  The latter is just always going to be a much
      higher bar.
      

        

      

      
And, something that returns per-user data is generally going
        to need a dynamic service of some kind, unless your site has
        just a handful of users and you don't mind going through a
        publishing exercise each time you add or change a user...

      


      

      
None of this has anything to do with the interface, just
        deployment realities.  And in reality all of this is going to
        need a dynamic service somewhere for each non-trivial site, this
        is all just a question of how to hook it up.

      

      
--

        John Panzer / Google

        jpanzer@google.com / abstractioneer.org / @jpanzer

      

      


        

        
On Wed, Jul 4, 2012 at 3:36 PM, Mark
          Nottingham <mnot@mnot.net>
          wrote:

          

            
On 05/07/2012, at 8:16 AM, John Panzer
              wrote:

              

              > Just as a historical note.  The envisioned usage of
              host-meta was originally to avoid a specification which
              mandated a particular dynamic URL API at a particular
              /.well-known endpoint (because it may not be feasible to
              do that across all organizations and deployments).  The
              host-meta document itself would be highly cacheable and so
              wouldn't incur an additional network trip in the common
              case.

              >

              > Having a 3xx redirect is a reasonable alternative
              that allows a similar escape hatch via something like
              mod_rewrite, albeit at the cost of needing an additional
              network trip each time.  Since a deployment can always
              avoid the 3xx redirect with additional dynamic plumbing
              behind the well-known endpoint, I don't think that's a
              horrible thing.

              >

              > An application-level redirect would be almost
              equivalent to an HTTP redirect, but then there are two
              ways to do the same thing.  If _only_ an application-level
              redirect is allowed, then you have to have at least a
              minimal dynamic service at the well-known endpoint (no
              more mod_rewrite).  But the whole reason for this is to
              avoid the requirement for a dynamic service behind
              well-known...

              

            

            "dynamic" and "static" are properties of the implementation,
            not the interface. HTTP doesn't require that any particular
            URL be "dynamic"; anything can, with the right metadata, be
            cached (and indeed, I've cached many, many things with the
            wrong metadata, because of silly site operators and their
            ideas about "dynamic").

            

            Now, if people want to target a particular implementation
            that makes it easier to serve a particular style of URL
            without writing code, fine, but let's not confuse things.

            

            E.g., a URL like

            

            http://example.com/.well-known/user/bob

            

            is easy to serve in pretty much any way you like with
            Apache.

            

            I'm also going to push back on the "it may not be feasible
            to do that across all organizations and deployments"
            motivation. This is a race to the bottom. The trick is to
            make it accessible enough to get sufficient traction to pull
            everyone along, without pandering to *everyone*'s
            requirements.

            

            Regards,

            

              


                --

                Mark Nottingham   http://www.mnot.net/

                

                

                

              

            

          

        

        

      

      

      

      

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


    

    

  


--------------060008080903020001050603--

From GK@ninebynine.org  Tue Aug 28 08:58:52 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB1E11E8099 for ; Tue, 28 Aug 2012 08:58:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.667
X-Spam-Level: 
X-Spam-Status: No, score=-6.667 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+hVFHG7HmVP for ; Tue, 28 Aug 2012 08:58:51 -0700 (PDT)
Received: from relay8.mail.ox.ac.uk (relay8.mail.ox.ac.uk [129.67.1.171]) by ietfa.amsl.com (Postfix) with ESMTP id 3772E11E808D for ; Tue, 28 Aug 2012 08:58:51 -0700 (PDT)
Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay8.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1T6OBl-0001WL-S6; Tue, 28 Aug 2012 16:58:49 +0100
Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1T6OBl-0003dy-4S; Tue, 28 Aug 2012 16:58:49 +0100
Message-ID: <503CE696.9020601@ninebynine.org>
Date: Tue, 28 Aug 2012 16:41:10 +0100
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: apps-discuss@ietf.org, Peter Saint-Andre 
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> <5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com> <5036875E.60607@stpeter.im>   <5037C02C.2070506@gmx.de> <4E1F6AAD24975D4BA5B1680429673943667A9596@TK5EX14MBXC284.redmond.corp.microsoft.com> <50382896.8060306@stpeter.im>
In-Reply-To: <50382896.8060306@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 15:58:52 -0000

On 25/08/2012 02:21, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 8/24/12 5:44 PM, Mike Jones wrote:
>> I agree that it's not a relative reference, in the RFC 3986 sense.
>> It's intended to be a context-dependent reference, as explained by
>> Phillip.
>
> Can you point to examples of context-dependent references in other URI
> schemes, or would the acct scheme be breaking new ground here?

The one that springs to mind is file:, which (in my experience) is almost always 
used in a localized context.  (Relative references are a red herring here.) 
Another is about:, which is specifically defined for accessing a local context.

I think there's some conflation going on of my earlier comment that you quoted 
("URIs are intended to be a global namespace") with the notion that every URI 
must be a global identifier with a unique referent.

I made my comment when speaking in support of keeping the domain name part, this 
was on the basis that I could see acct: URIs likely to be used in ways that 
escape their original context; e.g. as a hyperlink in a document.  In the case 
of file: - if a file: URI (as opposed to a relative reference, which is by 
definition scheme-free) appears in (say) a web page, it's usually an error.

That said, I will also concede that the web already lives with contextualized 
URIs, so if there really is a compelling case for domain-less acct: URIs, I 
could live with that.

I've said previously that I think the acct: scheme should be associated with a 
specific dereferencing mechanism (i.e. WebFinger - so it can be used as a 
generic hyperlink).  If domain-free acct: URIs are allowed, then I think 
something should also be said about how they should be dereferenced.

#g

From perpetual-tripper@wwelves.org  Tue Aug 28 10:05:18 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11B321F85A7 for ; Tue, 28 Aug 2012 10:05:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAhehC91FMEr for ; Tue, 28 Aug 2012 10:05:18 -0700 (PDT)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ietfa.amsl.com (Postfix) with ESMTP id 0167221F85A4 for ; Tue, 28 Aug 2012 10:05:18 -0700 (PDT)
X-Originating-IP: 217.70.178.148
Received: from mfilter20-d.gandi.net (mfilter20-d.gandi.net [217.70.178.148]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 81100A8077 for ; Tue, 28 Aug 2012 19:05:06 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter20-d.gandi.net
Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter20-d.gandi.net (mfilter20-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ShLz6fng1WlL for ; Tue, 28 Aug 2012 19:05:05 +0200 (CEST)
X-Originating-IP: 217.11.53.243
Received: from localhost (243.53.11.217.in-addr.arpa.manitu.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 09641A8073 for ; Tue, 28 Aug 2012 19:05:05 +0200 (CEST)
Content-Type: text/plain; charset=UTF-8
From: elf Pavlik 
To: apps-discuss 
In-reply-to: <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> <5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Tue, 28 Aug 2012 17:05:04 +0000
Message-Id: <1346172875-sup-9676@heahdk.net>
User-Agent: Sup/0.12.1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 17:05:18 -0000

Excerpts from Mike Jones's message of 2012-08-23 18:49:36 +0000:
> As long as I'm writing about the acct: URI, let me add my voice support=
ing allowing local account identifiers such as "acct:joe" to be used, in =
addition to fully qualified names such "acct:joe@example.com".  The reaso=
n that this this can work fine for discovery is that if you're contacting=
 the discovery server at example.com, the identifier "acct:joe" is unambi=
guous in that context.

While ago I've suggested on webfinger mailing list to allow identifiers w=
ithout local part, just: @domain.tld
This way projects could have sort of catch all accounts like: @ietf.org a=
nd people having personal domains could also just use @name.me (rather th=
an me@name.me or i@name.me etc.) It seams to me attractive if used in ost=
atus for federated microblogging.

On that thread someone also mentioned that in xmpp realm @domain.tld make=
s a valid jid but i haven't research it further yet :(

original thread: https://groups.google.com/d/topic/webfinger/DErWmYpXdzE/=
discussion

From stpeter@stpeter.im  Tue Aug 28 10:50:31 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BCA21F85B4 for ; Tue, 28 Aug 2012 10:50:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.573
X-Spam-Level: 
X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHYc4W1DRFdb for ; Tue, 28 Aug 2012 10:50:30 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B121221F8595 for ; Tue, 28 Aug 2012 10:50:30 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 66305404EB; Tue, 28 Aug 2012 11:51:39 -0600 (MDT)
Message-ID: <503D04E5.1090506@stpeter.im>
Date: Tue, 28 Aug 2012 11:50:29 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: elf Pavlik 
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> <5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com> <1346172875-sup-9676@heahdk.net>
In-Reply-To: <1346172875-sup-9676@heahdk.net>
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: apps-discuss 
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 17:50:31 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/28/12 11:05 AM, elf Pavlik wrote:
> Excerpts from Mike Jones's message of 2012-08-23 18:49:36 +0000:
>> As long as I'm writing about the acct: URI, let me add my voice 
>> supporting allowing local account identifiers such as "acct:joe"
>> to be used, in addition to fully qualified names such 
>> "acct:joe@example.com".  The reason that this this can work fine 
>> for discovery is that if you're contacting the discovery server
>> at example.com, the identifier "acct:joe" is unambiguous in that 
>> context.
> 
> While ago I've suggested on webfinger mailing list to allow 
> identifiers without local part, just: @domain.tld

Hmm, if local part and domain part are both optional, can we also have
"acct:@"? ;-)

> This way projects could have sort of catch all accounts like:
> @ietf.org and people having personal domains could also just use
> @name.me (rather than me@name.me or i@name.me etc.)

Yes, I recall that discussion, and if I recall correctly most people
thought it wasn't a great idea. What does it mean to, say, perform a
WebFinger query against a bare domain?

> It seams to me attractive if used in ostatus for federated
> microblogging.

Could you perhaps explain that scenario in a bit more detail? I'm
curious to learn what requirements that brings in.

> On that thread someone also mentioned that in xmpp realm
> @domain.tld makes a valid jid but i haven't research it further yet
> :(

You can have xmpp:domain.tld (the address of a server), but you can't
have xmpp:@domain.tld (some sort of catch-all for all accounts at the
server??).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlA9BOUACgkQNL8k5A2w/vxLogCcDWpb4yoaDbj/vOkEkvhQ6iAk
sToAniB2GuXTz+u2uX+2dqa5ILZhgT2g
=Z/Nw
-----END PGP SIGNATURE-----

From ve7jtb@ve7jtb.com  Tue Aug 28 11:06:49 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B4D21F8613 for ; Tue, 28 Aug 2012 11:06:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.495
X-Spam-Level: 
X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.104,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIs73EO4ydB1 for ; Tue, 28 Aug 2012 11:06:48 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDC821F85F7 for ; Tue, 28 Aug 2012 11:06:48 -0700 (PDT)
Received: by qcac10 with SMTP id c10so4178400qca.31 for ; Tue, 28 Aug 2012 11:06:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Z7tNXtPPTsmtf8uXlQhduQsetolsuGt/AlJvnb4tnus=; b=gBWwo8zQfScjTpltfMjZzGj3cDP5skMRZPpEZo0/6AKT3r/Bjjp+UkjrKOzzcIdUV7 DEdEsqzaTTuv90OcNFBcFbWEfex2I4wlKFRdA02Q9nlPZAhPsTXW0FROf2PwoIY/TpSB cC688q15X4jHyfWfXcgw0l40bthmytmhlb3rSi6FEeAJ2XCzW8Yn13F3Kpx1FJ/jLK2C 26cHRJ7TZjUWIG187EU2H65fEYfM0cR2QJlAixBXXeStrBRjoj4e5XzUZwoq0kIGcETY 4UCsagJmLBocx/83ZSOEUSnHHXpEDXMAXLXtX5JreCv1gAq9kUr5+3QBKs2u1ZwlvhFf SFQQ==
Received: by 10.224.196.132 with SMTP id eg4mr31668415qab.93.1346177207395; Tue, 28 Aug 2012 11:06:47 -0700 (PDT)
Received: from [192.168.1.211] (190-20-54-75.baf.movistar.cl. [190.20.54.75]) by mx.google.com with ESMTPS id gw6sm16085321qab.21.2012.08.28.11.06.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Aug 2012 11:06:45 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_6A6625D4-D8B7-42A2-BDFF-236BB6B9C550"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
From: John Bradley 
In-Reply-To: <503D04E5.1090506@stpeter.im>
Date: Tue, 28 Aug 2012 14:06:39 -0400
Message-Id: <6382CC40-7E1A-4853-A938-C7F12C27CD3F@ve7jtb.com>
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> <5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com> <1346172875-sup-9676@heahdk.net> <503D04E5.1090506@stpeter.im>
To: Peter Saint-Andre 
X-Mailer: Apple Mail (2.1486)
X-Gm-Message-State: ALoCoQmWI7/kC09YGsXn7x+A0/q/5lMMIjpNjslFz6hX3RvSuAO1drpLdZjvsN7ayV5Nqs/juq9O
Cc: apps-discuss 
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 18:06:49 -0000

--Apple-Mail=_6A6625D4-D8B7-42A2-BDFF-236BB6B9C550
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

For protocols like openID that attempt too preserve privacy there is the =
concept of a directed Identifier, one that provides generic account =
information  to the RP and allows the user to select a specific =
identifier at the IdP so it can provide a pseudonymous identifier to the =
RP.

So from a privacy perspective there is a need to signal do account =
selection at the IdP, there may be other uses for a generic user =
discovery account as well.

In openID Connect's use of SWD the user enters the domain of the IdP to =
trigger account selection at the IdP.

I guess the question is if we were using Web-Finger and the user enters =
example.com what would the RP normalize that to,  or would the rule be =
to treat it as a http: URI if it doesn't have a @ or a scheme.

Given that Web-Finger is attempting to normalize input into acct: uri as =
opposed to just passing the input to the server we need to be clear on =
how input is normalized.

I also don't underestimate the challenge of pulling the server out of a =
random string a user inputs.

I expect to see people try inputing a lot of creative things.

John B.



On 2012-08-28, at 1:50 PM, Peter Saint-Andre  wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> On 8/28/12 11:05 AM, elf Pavlik wrote:
>> Excerpts from Mike Jones's message of 2012-08-23 18:49:36 +0000:
>>> As long as I'm writing about the acct: URI, let me add my voice=20
>>> supporting allowing local account identifiers such as "acct:joe"
>>> to be used, in addition to fully qualified names such=20
>>> "acct:joe@example.com".  The reason that this this can work fine=20
>>> for discovery is that if you're contacting the discovery server
>>> at example.com, the identifier "acct:joe" is unambiguous in that=20
>>> context.
>>=20
>> While ago I've suggested on webfinger mailing list to allow=20
>> identifiers without local part, just: @domain.tld
>=20
> Hmm, if local part and domain part are both optional, can we also have
> "acct:@"? ;-)
>=20
>> This way projects could have sort of catch all accounts like:
>> @ietf.org and people having personal domains could also just use
>> @name.me (rather than me@name.me or i@name.me etc.)
>=20
> Yes, I recall that discussion, and if I recall correctly most people
> thought it wasn't a great idea. What does it mean to, say, perform a
> WebFinger query against a bare domain?
>=20
>> It seams to me attractive if used in ostatus for federated
>> microblogging.
>=20
> Could you perhaps explain that scenario in a bit more detail? I'm
> curious to learn what requirements that brings in.
>=20
>> On that thread someone also mentioned that in xmpp realm
>> @domain.tld makes a valid jid but i haven't research it further yet
>> :(
>=20
> You can have xmpp:domain.tld (the address of a server), but you can't
> have xmpp:@domain.tld (some sort of catch-all for all accounts at the
> server??).
>=20
> Peter
>=20
> - --=20
> Peter Saint-Andre
> https://stpeter.im/
>=20
>=20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>=20
> iEYEARECAAYFAlA9BOUACgkQNL8k5A2w/vxLogCcDWpb4yoaDbj/vOkEkvhQ6iAk
> sToAniB2GuXTz+u2uX+2dqa5ILZhgT2g
> =3DZ/Nw
> -----END PGP SIGNATURE-----
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


--Apple-Mail=_6A6625D4-D8B7-42A2-BDFF-236BB6B9C550
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgy
ODE4MDY0MFowIwYJKoZIhvcNAQkEMRYEFH6j0N3FWUJH5Y2mSyqm3ae8GVuzMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
ACQPeVSlwAJcrAtgtcoV7mLw/pmh85bSIIUV/1T8IIxntCa69WxqENh3jyYFhEq3tOn3cMB9RDyI
BOrVDwoclOETcrCGcr2LVAWyk4m6t2iT0PGn5/onjlsgT3jA8ngvp+CzBxt5/Cin6TgHCy2bKVw2
xqiwAqTER0PBPEbbTOL8cmQuJJheSMqIlAXHH+MmsUbT75m4nKcU7KZ0UNgXSL6zouK7FLWbujlw
JcMLJzkBmnjxgTO+b0CYyOe/So81c4YiqcTQmnmW6mTkixA8Zibg4Ka9NYdBbP2/7+QGFFijBYDF
K61pEYos839l4YhpY7aGd2Ci/rO5YhNalSTlI3sAAAAAAAA=

--Apple-Mail=_6A6625D4-D8B7-42A2-BDFF-236BB6B9C550--

From perpetual-tripper@wwelves.org  Tue Aug 28 11:19:05 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E871021F860E for ; Tue, 28 Aug 2012 11:19:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.199
X-Spam-Level: 
X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoQxpCwj7Kv7 for ; Tue, 28 Aug 2012 11:19:05 -0700 (PDT)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ietfa.amsl.com (Postfix) with ESMTP id CA26D21F85DA for ; Tue, 28 Aug 2012 11:19:04 -0700 (PDT)
X-Originating-IP: 217.70.178.142
Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id C89CBA808B; Tue, 28 Aug 2012 20:18:53 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net
Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id D+LtJMLG8drq; Tue, 28 Aug 2012 20:18:52 +0200 (CEST)
X-Originating-IP: 217.11.53.243
Received: from localhost (243.53.11.217.in-addr.arpa.manitu.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 54D38A8090; Tue, 28 Aug 2012 20:18:52 +0200 (CEST)
Content-Type: text/plain; charset=UTF-8
From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= 
To: Peter Saint-Andre 
In-reply-to: <503D04E5.1090506@stpeter.im>
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> <5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com> <1346172875-sup-9676@heahdk.net> <503D04E5.1090506@stpeter.im>
Date: Tue, 28 Aug 2012 18:18:51 +0000
Message-Id: <1346176849-sup-3504@heahdk.net>
User-Agent: Sup/0.12.1
Content-Transfer-Encoding: quoted-printable
Cc: apps-discuss 
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 18:19:06 -0000

Excerpts from Peter Saint-Andre's message of 2012-08-28 17:50:29 +0000:
> Hash: SHA1
>=20
> On 8/28/12 11:05 AM, elf Pavlik wrote:
> > Excerpts from Mike Jones's message of 2012-08-23 18:49:36 +0000:
> >> As long as I'm writing about the acct: URI, let me add my voice=20
> >> supporting allowing local account identifiers such as "acct:joe"
> >> to be used, in addition to fully qualified names such=20
> >> "acct:joe@example.com".  The reason that this this can work fine=20
> >> for discovery is that if you're contacting the discovery server
> >> at example.com, the identifier "acct:joe" is unambiguous in that=20
> >> context.
> >=20
> > While ago I've suggested on webfinger mailing list to allow=20
> > identifiers without local part, just: @domain.tld
>=20
> Hmm, if local part and domain part are both optional, can we also have
> "acct:@"? ;-)
>=20
> > This way projects could have sort of catch all accounts like:
> > @ietf.org and people having personal domains could also just use
> > @name.me (rather than me@name.me or i@name.me etc.)
>=20
> Yes, I recall that discussion, and if I recall correctly most people
> thought it wasn't a great idea. What does it mean to, say, perform a
> WebFinger query against a bare domain?
Yes, many people mentioned the original intention to mimic familiar to mo=
st people email addresses

>=20
> > It seams to me attractive if used in ostatus for federated
> > microblogging.
>=20
> Could you perhaps explain that scenario in a bit more detail? I'm
> curious to learn what requirements that brings in.
At some point i thought that for example twitter specific: @ietf could be=
come possibly self hosted @ietf.org
as well as people with personal domains could use just identifiers like @=
franky.me and choose where they want to host their accounts.

I also recall Markus Sabadello enthusiasm to in some ways infamous i-name=
s which just use =3Dname for individuals and @name for organizations
https://en.wikipedia.org/wiki/I-name

Honestly I just wanted to hear more opinions about it, seeing myself poss=
ible convenience in having option to just skip local part.

>=20
> > On that thread someone also mentioned that in xmpp realm
> > @domain.tld makes a valid jid but i haven't research it further yet
> > :(
>=20
> You can have xmpp:domain.tld (the address of a server), but you can't
> have xmpp:@domain.tld (some sort of catch-all for all accounts at the
> server??).
Thanks for clarifying, also acct:domain.tld looks also somehow more sane =
than acct:@domain.tld :)

>=20
> Peter
>=20

From ve7jtb@ve7jtb.com  Tue Aug 28 11:26:06 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6FD21F860E for ; Tue, 28 Aug 2012 11:26:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.496
X-Spam-Level: 
X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.102,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJXAqUn9Yuak for ; Tue, 28 Aug 2012 11:26:05 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE2A21F85FC for ; Tue, 28 Aug 2012 11:26:04 -0700 (PDT)
Received: by qan41 with SMTP id 41so2649664qan.10 for ; Tue, 28 Aug 2012 11:26:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=SMjWonW3n5HkNZDyuyeHhj3Nb7AKT6n186DA2WSCwDo=; b=aKvW1HJQIfTOAWZpMXzE/faqCQR9wZaJ2pkT/9x4ovsUL/OJo2Mbsgqclvj997kIGo ukcjWH65o1Kq0UwnyvbMpOqS0gpIq/tC54Mx7kPavzXIsy4qtKRupupIitrlzxexPw6D aiyjX7SCdqVijBmob568dN9YuWRMmEdaH8MxToEIlVMCnwf0CA3aFapmn5UVLtSiX0dc 0ApMSHkdZ2CHLnaud/K/UVcPZgmE3MZOGcsmG5Icb9s8GFHaF5WwOTtjzB+PnlxMbvEX /fYRWhlTxnehXm/Dn4YpwcZJvI4eDcnI2I2VAA2wov8JDfiUV9XPC2ffUwTiWgOQlDUb hLAg==
Received: by 10.224.101.193 with SMTP id d1mr31745769qao.20.1346178364130; Tue, 28 Aug 2012 11:26:04 -0700 (PDT)
Received: from [192.168.1.211] (190-20-54-75.baf.movistar.cl. [190.20.54.75]) by mx.google.com with ESMTPS id g13sm3329362qah.5.2012.08.28.11.25.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Aug 2012 11:26:02 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_086B1E01-4144-418F-B501-3121E0E974EA"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
From: John Bradley 
In-Reply-To: 
Date: Tue, 28 Aug 2012 14:25:37 -0400
Message-Id: 
References: <010901cd846c$95d74560$c185d020$@packetizer.com> <1346084277.68046.YahooMailNeo@web31802.mail.mud.yahoo.com>   <017001cd849e$cbdd9c90$6398d5b0$@packetizer.com> 
To: Will Norris 
X-Mailer: Apple Mail (2.1486)
X-Gm-Message-State: ALoCoQm4nPksC6ekk6njNjv2wmfTBdmeRIwQ2MW3qtsP9ips10HhbP/rADcuqXz+sDamWQMlHkV6
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 18:26:06 -0000

--Apple-Mail=_086B1E01-4144-418F-B501-3121E0E974EA
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_1B939497-3069-4F49-A2BF-4986D2D26774"


--Apple-Mail=_1B939497-3069-4F49-A2BF-4986D2D26774
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

+1 JSON must be MTI for servers.

I am not opposed to servers supporting XML or other formats via content =
negotiation,  however clients need to be interoperable with servers =
using JSON, and not forced to support XML for some servers.

John B.

On 2012-08-27, at 7:13 PM, Will Norris  wrote:

> as one of the editors of said XML format, I'm +1 as well.  The reasons =
for pushing so heavily for the XML format back then are no longer really =
true.  Instead, all the active work is on JSON-based formats, so it =
makes sense to update webfinger as well.
>=20
> On Mon, Aug 27, 2012 at 2:56 PM, Paul E. Jones  =
wrote:
> Ok... we could also do that.
>=20
> > -----Original Message-----
> > From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org]
> > On Behalf Of Blaine Cook
> > Sent: Monday, August 27, 2012 12:29 PM
> > To: apps-discuss@ietf.org
> > Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding =
XML vs
> > JSON
> >
> > +1 to this, and William and Tim's points.
> >
> > On 27 August 2012 18:26, Tim Bray  wrote:
> > > What William said about not needing the appendix. If you=92re =
going to
> > > go through the pain of abandoning the XML version, why also go =
through
> > > the pain of writing an appendix, when there=92s a perfectly good =
RFC in
> > > place to point to.  -T
> > >
> > > On Mon, Aug 27, 2012 at 9:17 AM, William Mills =

> > wrote:
> > >> I think this works in general but that there should be a mention =
of
> > >> it in the body of the spec citing the appendix.  Do we even need =
an
> > >> appendix though, we could simply cite 6415 as still normative for =
the
> > >> XML stuff but deprecated for new implementations.
> > >>
> > >>
> > >> ________________________________
> > >> From: Paul E. Jones 
> > >> To: apps-discuss@ietf.org
> > >> Cc: jsmarr@google.com; webfinger@googlegroups.com
> > >> Sent: Monday, August 27, 2012 8:56 AM
> > >> Subject: [apps-discuss] Proposed changes to WebFinger regarding =
XML
> > >> vs JSON
> > >>
> > >> Folks,
> > >>
> > >> Mike, Gonzalo, and I have had some off-list discussions about
> > >> WebFinger and how to resolve the one sticky point that we think =
has
> > >> caused the most concern.  That point is whether we should we =
allow both
> > XML and JSON.
> > >>
> > >> We have heard proposals to "just pick one" and, while I =
appreciate
> > >> the reasoning, I could not help ignoring that
> > >>
> > >>   1) RFC 6415 exists and describes XML the single mandatory =
format
> > >>   2) Existing implementations use XML
> > >>
> > >> Nonetheless, I also cannot ignore the long-term value in =
selecting
> > >> one format we can be sure is widely supported consistently.  I'm
> > >> fairly confident that most want only JSON at this point, even =
though
> > >> most (if not
> > >> all) current implementations today use XML.  While I'm personally
> > >> favorable to using XML, I know my personal preferences are not
> > >> representative of everyone. :-)
> > >>
> > >> So what we discussed was mentioning XML (perhaps with examples), =
but
> > >> putting that in an appendix and saying the usage is historic.  =
What
> > >> this would mean is that the text acknowledges that there are =
servers
> > >> that might process both XML and JSON, and even older servers that
> > >> only process XML.  The main body of the document would only =
require
> > >> support for JSON from clients and servers.
> > >>
> > >> Before we make these changes to the text, I want to seek input =
from
> > >> the group.  I believe it would be acceptable, but I do not want =
those
> > >> changes to cause significant issues for anyone.
> > >>
> > >> Thanks,
> > >> Paul
> > >>
> > >> PS - Please follow-up only on the apps-discuss list.
> > >>
> > >>
> > >> _______________________________________________
> > >> 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
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


--Apple-Mail=_1B939497-3069-4F49-A2BF-4986D2D26774
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

+1 =
JSON must be MTI for servers.

I am not opposed to =
servers supporting XML or other formats via content negotiation, =
 however clients need to be interoperable with servers using JSON, =
and not forced to support XML for some =
servers.

John =
B.

On 2012-08-27, at 7:13 PM, Will =
Norris <will@willnorris.com> =
wrote:

as one of the editors of said XML format, I'm +1 as well. =
 The reasons for pushing so heavily for the XML format back then =
are no longer really true.  Instead, all the active work is on =
JSON-based formats, so it makes sense to update webfinger as well.



On Mon, Aug 27, 2012 at 2:56 PM, Paul E. =
Jones <paulej@packetizer.com> =
wrote:


Ok... we could also do that.




> -----Original Message-----

> From: apps-discuss-bounces@ietf.or=
g [mailto:apps-discuss-bounces@ietf.or=
g]

> On Behalf Of Blaine Cook

> Sent: Monday, August 27, 2012 12:29 PM

> To: apps-discuss@ietf.org

> Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding =
XML vs

> JSON

>

> +1 to this, and William and Tim's points.

>

> On 27 August 2012 18:26, Tim Bray <tbray@textuality.com> =
wrote:

> > What William said about not needing the appendix. If you=92re =
going to

> > go through the pain of abandoning the XML version, why also go =
through

> > the pain of writing an appendix, when there=92s a perfectly =
good RFC in

> > place to point to.  -T

> >

> > On Mon, Aug 27, 2012 at 9:17 AM, William Mills <wmills@yahoo-inc.com>

> wrote:

> >> I think this works in general but that there should be a =
mention of

> >> it in the body of the spec citing the appendix.  Do =
we even need an

> >> appendix though, we could simply cite 6415 as still =
normative for the

> >> XML stuff but deprecated for new implementations.

> >>

> >>

> >> ________________________________

> >> From: Paul E. Jones <paulej@packetizer.com>

> >> To: apps-discuss@ietf.org

> >> Cc: jsmarr@google.com; webfinger@googlegroups.com<=
br>
> >> Sent: Monday, August 27, 2012 8:56 AM

> >> Subject: [apps-discuss] Proposed changes to WebFinger =
regarding XML

> >> vs JSON

> >>

> >> Folks,

> >>

> >> Mike, Gonzalo, and I have had some off-list discussions =
about

> >> WebFinger and how to resolve the one sticky point that we =
think has

> >> caused the most concern.  That point is whether we =
should we allow both

> XML and JSON.

> >>

> >> We have heard proposals to "just pick one" and, while I =
appreciate

> >> the reasoning, I could not help ignoring that

> >>

> >>   1) RFC 6415 exists and describes XML the single =
mandatory format

> >>   2) Existing implementations use XML

> >>

> >> Nonetheless, I also cannot ignore the long-term value in =
selecting

> >> one format we can be sure is widely supported =
consistently.  I'm

> >> fairly confident that most want only JSON at this point, =
even though

> >> most (if not

> >> all) current implementations today use XML.  While =
I'm personally

> >> favorable to using XML, I know my personal preferences are =
not

> >> representative of everyone. :-)

> >>

> >> So what we discussed was mentioning XML (perhaps with =
examples), but

> >> putting that in an appendix and saying the usage is =
historic.  What

> >> this would mean is that the text acknowledges that there =
are servers

> >> that might process both XML and JSON, and even older =
servers that

> >> only process XML.  The main body of the document =
would only require

> >> support for JSON from clients and servers.

> >>

> >> Before we make these changes to the text, I want to seek =
input from

> >> the group.  I believe it would be acceptable, but I =
do not want those

> >> changes to cause significant issues for anyone.

> >>

> >> Thanks,

> >> Paul

> >>

> >> PS - Please follow-up only on the apps-discuss list.

> >>

> >>

> >> _______________________________________________

> >> 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
> _______________________________________________

> 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

=

--Apple-Mail=_1B939497-3069-4F49-A2BF-4986D2D26774--

--Apple-Mail=_086B1E01-4144-418F-B501-3121E0E974EA
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgy
ODE4MjUzN1owIwYJKoZIhvcNAQkEMRYEFOQHmYDgDlak6pgK3xoiXAFfpq72MIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
AC8h8Blb2xkqzI973+p/SVFq7d7PejGrkmxDiTn5NGo2GgWXUyLg3zeUHbJCgIivoyXw1CS+0I0G
EwZGfaicd6+b6Y3LZ3Nfcd7OmtneF1p/65UNq/grD1DGNU5pS3+66xzuc8qZdktNsY8jePmmjBzg
Yn6K1RWrHH1eAWdxPXL+9Mrqi0B5LxRC8cJUq8ZIUPgiCcnL7sYakUbLMoKRR5JWLiW06yLM40cE
2hqERZD0Bcb4YdnZ0TzgRpNq5altq0Gq+y+/QXnuaEYUL0plOxpJpzpCnCf3sWxIJSnNrHkRbyxE
U6KydcyX6KSsLZvI+KcLdDpZO2JkluU2MZiCG1gAAAAAAAA=

--Apple-Mail=_086B1E01-4144-418F-B501-3121E0E974EA--

From stpeter@stpeter.im  Tue Aug 28 11:49:14 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB0121F860E for ; Tue, 28 Aug 2012 11:49:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.574
X-Spam-Level: 
X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3u-mrAKY5Xa for ; Tue, 28 Aug 2012 11:49:13 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CE60721F860B for ; Tue, 28 Aug 2012 11:49:13 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AA62D404EB; Tue, 28 Aug 2012 12:50:19 -0600 (MDT)
Message-ID: <503D12A5.6010406@stpeter.im>
Date: Tue, 28 Aug 2012 12:49:09 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Graham Klyne 
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> <5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com> <5036875E.60607@stpeter.im>   <5037C02C.2070506@gmx.de> <4E1F6AAD24975D4BA5B1680429673943667A9596@TK5EX14MBXC284.redmond.corp.microsoft.com> <50382896.8060306@stpeter.im> <503CE696.9020601@ninebynine.org>
In-Reply-To: <503CE696.9020601@ninebynine.org>
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 18:49:14 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/28/12 9:41 AM, Graham Klyne wrote:
> On 25/08/2012 02:21, Peter Saint-Andre wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 8/24/12 5:44 PM, Mike Jones wrote:
>>> I agree that it's not a relative reference, in the RFC 3986
>>> sense. It's intended to be a context-dependent reference, as
>>> explained by Phillip.
>> 
>> Can you point to examples of context-dependent references in
>> other URI schemes, or would the acct scheme be breaking new
>> ground here?
> 
> The one that springs to mind is file:, which (in my experience) is 
> almost always used in a localized context.  (Relative references
> are a red herring here.) Another is about:, which is specifically
> defined for accessing a local context.
> 
> I think there's some conflation going on of my earlier comment that
> you quoted ("URIs are intended to be a global namespace") with the
> notion that every URI must be a global identifier with a unique
> referent.
> 
> I made my comment when speaking in support of keeping the domain
> name part, this was on the basis that I could see acct: URIs likely
> to be used in ways that escape their original context; e.g. as a
> hyperlink in a document.  In the case of file: - if a file: URI (as
> opposed to a relative reference, which is by definition
> scheme-free) appears in (say) a web page, it's usually an error.
> 
> That said, I will also concede that the web already lives with 
> contextualized URIs, so if there really is a compelling case for 
> domain-less acct: URIs, I could live with that.

I confess that I still don't understand the case for domain-less
"acct" URIs. What exactly is the local context, and why would "acct"
URIs be used in that context? For example, I could imagine that a
local context might be accessing a device under my physical control or
using a terminal to access infrastructure on a local network, but it's
not clear to me why one would use an "acct" URI in those scenarios.
What am I missing?

> I've said previously that I think the acct: scheme should be
> associated with a specific dereferencing mechanism (i.e. WebFinger
> - so it can be used as a generic hyperlink).  If domain-free acct:
> URIs are allowed, then I think something should also be said about
> how they should be dereferenced.

Agreed.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlA9EqUACgkQNL8k5A2w/vymJwCgrBQliqt8GO6IGYw8na7ckabK
BrEAnR/Vkj0AdiRO7heBqXuAOkba5YNa
=+y5T
-----END PGP SIGNATURE-----

From paulej@packetizer.com  Tue Aug 28 12:02:52 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C1F21F8526 for ; Tue, 28 Aug 2012 12:02:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level: 
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.099,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKEz9FjepbKA for ; Tue, 28 Aug 2012 12:02:49 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5113521F8518 for ; Tue, 28 Aug 2012 12:02:49 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q7SJ2lkp009614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Aug 2012 15:02:48 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1346180568; bh=IVup/9YVpcb+14cep3Q0ZqinZitzambSzLmS3iypHlw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=rVqDNg/scMn+tzvNB4dERAj5+/OdHdcA22ikADNOfNl3cUA2PGYa+eVObnqOU8stg JRP4IJUB9ZiCgbq32lJz9lx2o7e1zQwimznPjC/idpIf5G2XX8g6PckcMyiCuSM/+5 CG+tX8Vyuli2fKIclQRlPY13QqdSjNifozJ+/ZEc=
From: "Paul E. Jones" 
To: "'John Bradley'" , "'Will Norris'" 
References: <010901cd846c$95d74560$c185d020$@packetizer.com> <1346084277.68046.YahooMailNeo@web31802.mail.mud.yahoo.com>   <017001cd849e$cbdd9c90$6398d5b0$@packetizer.com>  
In-Reply-To: 
Date: Tue, 28 Aug 2012 15:03:06 -0400
Message-ID: <028a01cd854f$c29a86f0$47cf94d0$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_028B_01CD852E.3B8A4680"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIrZE+abU/d+x34aW2WxIOtEY8jpwIfXwJkAk1l+2oB11boGgF43hDQAwFsJFECCPyssZZNmrxA
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 19:02:52 -0000

This is a multipart message in MIME format.

------=_NextPart_000_028B_01CD852E.3B8A4680
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

John,

 

Previously, JSON and XML were MTI on servers; clients could implement what
they want.

 

If we make the proposed change, XML will be dropped on the server side.  The
result will be that clients can only rely on JSON support.  XML support
might be rare.

 

Paul

 

PS - My personal preference is still to require XML and JSON on the server,
but I'm willing to give in on this one in order to reach group consensus.  I
think this was the most significant point of contention.

 

From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Tuesday, August 28, 2012 2:26 PM
To: Will Norris
Cc: Paul E. Jones; apps-discuss@ietf.org
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs
JSON

 

+1 JSON must be MTI for servers.

 

I am not opposed to servers supporting XML or other formats via content
negotiation,  however clients need to be interoperable with servers using
JSON, and not forced to support XML for some servers.

 

John B.

 

On 2012-08-27, at 7:13 PM, Will Norris  wrote:





as one of the editors of said XML format, I'm +1 as well.  The reasons for
pushing so heavily for the XML format back then are no longer really true.
Instead, all the active work is on JSON-based formats, so it makes sense to
update webfinger as well.

On Mon, Aug 27, 2012 at 2:56 PM, Paul E. Jones 
wrote:

Ok... we could also do that.


> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
> On Behalf Of Blaine Cook
> Sent: Monday, August 27, 2012 12:29 PM
> To: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs
> JSON
>
> +1 to this, and William and Tim's points.
>
> On 27 August 2012 18:26, Tim Bray  wrote:
> > What William said about not needing the appendix. If you're going to
> > go through the pain of abandoning the XML version, why also go through
> > the pain of writing an appendix, when there's a perfectly good RFC in
> > place to point to.  -T
> >
> > On Mon, Aug 27, 2012 at 9:17 AM, William Mills 
> wrote:
> >> I think this works in general but that there should be a mention of
> >> it in the body of the spec citing the appendix.  Do we even need an
> >> appendix though, we could simply cite 6415 as still normative for the
> >> XML stuff but deprecated for new implementations.
> >>
> >>
> >> ________________________________
> >> From: Paul E. Jones 
> >> To: apps-discuss@ietf.org
> >> Cc: jsmarr@google.com; webfinger@googlegroups.com
> >> Sent: Monday, August 27, 2012 8:56 AM
> >> Subject: [apps-discuss] Proposed changes to WebFinger regarding XML
> >> vs JSON
> >>
> >> Folks,
> >>
> >> Mike, Gonzalo, and I have had some off-list discussions about
> >> WebFinger and how to resolve the one sticky point that we think has
> >> caused the most concern.  That point is whether we should we allow both
> XML and JSON.
> >>
> >> We have heard proposals to "just pick one" and, while I appreciate
> >> the reasoning, I could not help ignoring that
> >>
> >>   1) RFC 6415 exists and describes XML the single mandatory format
> >>   2) Existing implementations use XML
> >>
> >> Nonetheless, I also cannot ignore the long-term value in selecting
> >> one format we can be sure is widely supported consistently.  I'm
> >> fairly confident that most want only JSON at this point, even though
> >> most (if not
> >> all) current implementations today use XML.  While I'm personally
> >> favorable to using XML, I know my personal preferences are not
> >> representative of everyone. :-)
> >>
> >> So what we discussed was mentioning XML (perhaps with examples), but
> >> putting that in an appendix and saying the usage is historic.  What
> >> this would mean is that the text acknowledges that there are servers
> >> that might process both XML and JSON, and even older servers that
> >> only process XML.  The main body of the document would only require
> >> support for JSON from clients and servers.
> >>
> >> Before we make these changes to the text, I want to seek input from
> >> the group.  I believe it would be acceptable, but I do not want those
> >> changes to cause significant issues for anyone.
> >>
> >> Thanks,
> >> Paul
> >>
> >> PS - Please follow-up only on the apps-discuss list.
> >>
> >>
> >> _______________________________________________
> >> 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
> _______________________________________________
> 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

 


------=_NextPart_000_028B_01CD852E.3B8A4680
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


John,
 
Previously, JSON and XML were MTI on servers; clients could implement =
what they want.
 
If we make the proposed change, XML will be dropped on the server =
side.  The result will be that clients can only rely on JSON =
support.  XML support might be rare.
 
Paul
 
PS – My personal preference is still to require XML and JSON on =
the server, but I’m willing to give in on this one in order to =
reach group consensus.  I think this was the most significant point =
of contention.
 
From:=
 =
John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Tuesday, August =
28, 2012 2:26 PM
To: Will Norris
Cc: Paul E. Jones; =
apps-discuss@ietf.org
Subject: Re: [apps-discuss] Proposed =
changes to WebFinger regarding XML vs =
JSON
 
+1 JSON must =
be MTI for servers.
 
I =
am not opposed to servers supporting XML or other formats via content =
negotiation,  however clients need to be interoperable with servers =
using JSON, and not forced to support XML for some =
servers.
 
John B.
 
On 2012-08-27, at 7:13 PM, Will Norris <will@willnorris.com> =
wrote:


as one of the editors of said XML format, =
I'm +1 as well.  The reasons for pushing so heavily for the XML =
format back then are no longer really true.  Instead, all the =
active work is on JSON-based formats, so it makes sense to update =
webfinger as well.
On Mon, Aug =
27, 2012 at 2:56 PM, Paul E. Jones <paulej@packetizer.com> wrote:
Ok... we could also do =
that.

> =
-----Original Message-----
> From: apps-discuss-bounces@ietf.o=
rg [mailto:apps-discuss-bounces@ietf.o=
rg]
> On Behalf Of Blaine Cook
> Sent: Monday, August =
27, 2012 12:29 PM
> To: apps-discuss@ietf.org
> =
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML =
vs
> JSON
>
> +1 to this, and William and Tim's =
points.
>
> On 27 August 2012 18:26, Tim Bray <tbray@textuality.com> =
wrote:
> > What William said about not needing the appendix. If =
you’re going to
> > go through the pain of abandoning the =
XML version, why also go through
> > the pain of writing an =
appendix, when there’s a perfectly good RFC in
> > place =
to point to.  -T
> >
> > On Mon, Aug 27, 2012 at =
9:17 AM, William Mills <wmills@yahoo-inc.com>
>=
 wrote:
> >> I think this works in general but that there =
should be a mention of
> >> it in the body of the spec =
citing the appendix.  Do we even need an
> >> appendix =
though, we could simply cite 6415 as still normative for the
> =
>> XML stuff but deprecated for new implementations.
> =
>>
> >>
> >> =
________________________________
> >> From: Paul E. Jones =
<paulej@packetizer.com>
&g=
t; >> To: apps-discuss@ietf.org
> =
>> Cc: jsmarr@google.com; =
webfinger@googlegroups.com=

> >> Sent: Monday, August 27, 2012 8:56 AM
> >> =
Subject: [apps-discuss] Proposed changes to WebFinger regarding =
XML
> >> vs JSON
> >>
> >> =
Folks,
> >>
> >> Mike, Gonzalo, and I have had =
some off-list discussions about
> >> WebFinger and how to =
resolve the one sticky point that we think has
> >> caused =
the most concern.  That point is whether we should we allow =
both
> XML and JSON.
> >>
> >> We have =
heard proposals to "just pick one" and, while I =
appreciate
> >> the reasoning, I could not help ignoring =
that
> >>
> >>   1) RFC 6415 exists and =
describes XML the single mandatory format
> >>   2) =
Existing implementations use XML
> >>
> >> =
Nonetheless, I also cannot ignore the long-term value in =
selecting
> >> one format we can be sure is widely supported =
consistently.  I'm
> >> fairly confident that most want =
only JSON at this point, even though
> >> most (if =
not
> >> all) current implementations today use XML. =
 While I'm personally
> >> favorable to using XML, I =
know my personal preferences are not
> >> representative of =
everyone. :-)
> >>
> >> So what we discussed was =
mentioning XML (perhaps with examples), but
> >> putting =
that in an appendix and saying the usage is historic.  What
> =
>> this would mean is that the text acknowledges that there are =
servers
> >> that might process both XML and JSON, and even =
older servers that
> >> only process XML.  The main =
body of the document would only require
> >> support for =
JSON from clients and servers.
> >>
> >> Before =
we make these changes to the text, I want to seek input from
> =
>> the group.  I believe it would be acceptable, but I do not =
want those
> >> changes to cause significant issues for =
anyone.
> >>
> >> Thanks,
> >> =
Paul
> >>
> >> PS - Please follow-up only on the =
apps-discuss list.
> >>
> >>
> >> =
_______________________________________________
> >> =
apps-discuss mailing list
> >> apps-discuss@ietf.org
> =
>> https://www.ietf.org/mailman/listinfo/apps-discuss<=
br>> >>
> >>
> >>
> >> =
_______________________________________________
> >> =
apps-discuss mailing list
> >> apps-discuss@ietf.org
> =
>> https://www.ietf.org/mailman/listinfo/apps-discuss<=
br>> >>
> > =
_______________________________________________
> > =
apps-discuss mailing list
> > apps-discuss@ietf.org
> =
> https://www.ietf.org/mailman/listinfo/apps-discuss<=
br>> _______________________________________________
> =
apps-discuss mailing list
> apps-discuss@ietf.org
> =
https://www.ietf.org/mailman/listinfo/apps-discuss<=
br>
_______________________________________________
apps-discuss =
mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<=
o:p>

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

------=_NextPart_000_028B_01CD852E.3B8A4680--


From ve7jtb@ve7jtb.com  Tue Aug 28 12:13:46 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6526B11E80F6 for ; Tue, 28 Aug 2012 12:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.497
X-Spam-Level: 
X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=0.101,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKS2CXoIlUpO for ; Tue, 28 Aug 2012 12:13:45 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD44211E80D9 for ; Tue, 28 Aug 2012 12:13:44 -0700 (PDT)
Received: by qcac10 with SMTP id c10so4233307qca.31 for ; Tue, 28 Aug 2012 12:13:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=hvg33fJGVSwcrpEqvlIXP6c/vxTNWWqxUJkX98oysEA=; b=ALA+cpz5SfvFCGn2PfsSbfCWAi5YsqLS32jUIL2MGSJX5cAePACydOlI1BWIMcLDOw AzA+D+N4RUTTWIs58Jj2A3Ds9jX6g2B4Fxq4tbjUqdOuKX/eG0Ozbb0hu3BcwAQreivF gonI8D6Wm6VIAJ4VnX+1Rp2PiD67Ah1CrnpPTSxTUvNBHUHn8TQWMgvAb48HqosSwbrZ JndxCY0KxEnRtWFwJeq8TDGrJuS48qzTxnqGPMPOAsHH0t4X+Sbi1dMnxxqluZTnyQjB FFRS3FODABgUyDpXanOf8b5+rtgOakuid4yWMxiw39Ke7GvT4UimvPcBPC+nDCb4nK9R 2QFw==
Received: by 10.224.181.207 with SMTP id bz15mr32209673qab.65.1346181222968; Tue, 28 Aug 2012 12:13:42 -0700 (PDT)
Received: from [192.168.1.211] (190-20-54-75.baf.movistar.cl. [190.20.54.75]) by mx.google.com with ESMTPS id gi10sm16224588qab.11.2012.08.28.12.13.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Aug 2012 12:13:40 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_B2CF856D-14EF-4481-AFD9-510E3D0D8A33"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
From: John Bradley 
In-Reply-To: <028a01cd854f$c29a86f0$47cf94d0$@packetizer.com>
Date: Tue, 28 Aug 2012 15:13:13 -0400
Message-Id: <050232F8-4175-4698-95D7-17E4B35B1210@ve7jtb.com>
References: <010901cd846c$95d74560$c185d020$@packetizer.com> <1346084277.68046.YahooMailNeo@web31802.mail.mud.yahoo.com>   <017001cd849e$cbdd9c90$6398d5b0$@packetizer.com>   <028a01cd854f$c29a86f0$47cf94d0$@packetizer.com>
To: "Paul E. Jones" 
X-Mailer: Apple Mail (2.1486)
X-Gm-Message-State: ALoCoQmfAn+jcq8LyW1P9KP4F4/nsRKjaEmw9v0pboK0EqCgMF9EvHm86RIC1wjp0N2/1tM6SD72
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 19:13:46 -0000

--Apple-Mail=_B2CF856D-14EF-4481-AFD9-510E3D0D8A33
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_5B5FEFF4-6AF4-48D9-89DF-B7DCDEC333FF"


--Apple-Mail=_5B5FEFF4-6AF4-48D9-89DF-B7DCDEC333FF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I understand, but I think forcing servers to support both will hurt =
adoption, though not as much as requiring it on the client.

John B.


On 2012-08-28, at 3:03 PM, "Paul E. Jones"  =
wrote:

> John,
> =20
> Previously, JSON and XML were MTI on servers; clients could implement =
what they want.
> =20
> If we make the proposed change, XML will be dropped on the server =
side.  The result will be that clients can only rely on JSON support.  =
XML support might be rare.
> =20
> Paul
> =20
> PS =96 My personal preference is still to require XML and JSON on the =
server, but I=92m willing to give in on this one in order to reach group =
consensus.  I think this was the most significant point of contention.
> =20
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
> Sent: Tuesday, August 28, 2012 2:26 PM
> To: Will Norris
> Cc: Paul E. Jones; apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding =
XML vs JSON
> =20
> +1 JSON must be MTI for servers.
> =20
> I am not opposed to servers supporting XML or other formats via =
content negotiation,  however clients need to be interoperable with =
servers using JSON, and not forced to support XML for some servers.
> =20
> John B.
> =20
> On 2012-08-27, at 7:13 PM, Will Norris  wrote:
>=20
>=20
> as one of the editors of said XML format, I'm +1 as well.  The reasons =
for pushing so heavily for the XML format back then are no longer really =
true.  Instead, all the active work is on JSON-based formats, so it =
makes sense to update webfinger as well.
>=20
> On Mon, Aug 27, 2012 at 2:56 PM, Paul E. Jones  =
wrote:
> Ok... we could also do that.
>=20
> > -----Original Message-----
> > From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org]
> > On Behalf Of Blaine Cook
> > Sent: Monday, August 27, 2012 12:29 PM
> > To: apps-discuss@ietf.org
> > Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding =
XML vs
> > JSON
> >
> > +1 to this, and William and Tim's points.
> >
> > On 27 August 2012 18:26, Tim Bray  wrote:
> > > What William said about not needing the appendix. If you=92re =
going to
> > > go through the pain of abandoning the XML version, why also go =
through
> > > the pain of writing an appendix, when there=92s a perfectly good =
RFC in
> > > place to point to.  -T
> > >
> > > On Mon, Aug 27, 2012 at 9:17 AM, William Mills =

> > wrote:
> > >> I think this works in general but that there should be a mention =
of
> > >> it in the body of the spec citing the appendix.  Do we even need =
an
> > >> appendix though, we could simply cite 6415 as still normative for =
the
> > >> XML stuff but deprecated for new implementations.
> > >>
> > >>
> > >> ________________________________
> > >> From: Paul E. Jones 
> > >> To: apps-discuss@ietf.org
> > >> Cc: jsmarr@google.com; webfinger@googlegroups.com
> > >> Sent: Monday, August 27, 2012 8:56 AM
> > >> Subject: [apps-discuss] Proposed changes to WebFinger regarding =
XML
> > >> vs JSON
> > >>
> > >> Folks,
> > >>
> > >> Mike, Gonzalo, and I have had some off-list discussions about
> > >> WebFinger and how to resolve the one sticky point that we think =
has
> > >> caused the most concern.  That point is whether we should we =
allow both
> > XML and JSON.
> > >>
> > >> We have heard proposals to "just pick one" and, while I =
appreciate
> > >> the reasoning, I could not help ignoring that
> > >>
> > >>   1) RFC 6415 exists and describes XML the single mandatory =
format
> > >>   2) Existing implementations use XML
> > >>
> > >> Nonetheless, I also cannot ignore the long-term value in =
selecting
> > >> one format we can be sure is widely supported consistently.  I'm
> > >> fairly confident that most want only JSON at this point, even =
though
> > >> most (if not
> > >> all) current implementations today use XML.  While I'm personally
> > >> favorable to using XML, I know my personal preferences are not
> > >> representative of everyone. :-)
> > >>
> > >> So what we discussed was mentioning XML (perhaps with examples), =
but
> > >> putting that in an appendix and saying the usage is historic.  =
What
> > >> this would mean is that the text acknowledges that there are =
servers
> > >> that might process both XML and JSON, and even older servers that
> > >> only process XML.  The main body of the document would only =
require
> > >> support for JSON from clients and servers.
> > >>
> > >> Before we make these changes to the text, I want to seek input =
from
> > >> the group.  I believe it would be acceptable, but I do not want =
those
> > >> changes to cause significant issues for anyone.
> > >>
> > >> Thanks,
> > >> Paul
> > >>
> > >> PS - Please follow-up only on the apps-discuss list.
> > >>
> > >>
> > >> _______________________________________________
> > >> 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
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


--Apple-Mail=_5B5FEFF4-6AF4-48D9-89DF-B7DCDEC333FF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I understand, but I think =
forcing servers to support both will hurt adoption, though not as much =
as requiring it on the client.

John =
B.


On 2012-08-28, at 3:03 PM, "Paul =
E. Jones" <paulej@packetizer.com> =
wrote:

 
Previously, JSON and XML were MTI on servers; =
clients could implement what they want.
 
If we make the proposed =
change, XML will be dropped on the server side.  The result will be =
that clients can only rely on JSON support.  XML support might be =
rare.
 
Paul
 
PS =96 My personal =
preference is still to require XML and JSON on the server, but I=92m =
willing to give in on this one in order to reach group consensus.  =
I think this was the most significant point of =
contention.
 
 John =
Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Tuesday, August 28, 2012 =
2:26 PM
To: Will =
Norris
Cc: Paul E. Jones; apps-discuss@ietf.org
Subj=
ect: Re: =
[apps-discuss] Proposed changes to WebFinger regarding XML vs =
JSON
+1 JSON must =
be MTI for servers.
I am =
not opposed to servers supporting XML or other formats via content =
negotiation,  however clients need to be interoperable with servers =
using JSON, and not forced to support XML for some =
servers.
John =
B.
will@willnorris.com> =
wrote:
as =
one of the editors of said XML format, I'm +1 as well.  The reasons =
for pushing so heavily for the XML format back then are no longer really =
true.  Instead, all the active work is on JSON-based formats, so it =
makes sense to update webfinger as well.
On Mon, Aug 27, 2012 at 2:56 PM, Paul E. Jones =
<Ok... we could also do =
that.

> =
-----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
> =
On Behalf Of Blaine Cook
> Sent: Monday, August 27, 2012 12:29 =
PM
> To: apps-discuss@ietf.org
> Subject: =
Re: [apps-discuss] Proposed changes to WebFinger regarding XML =
vs
> JSON
>
> +1 to this, and William and Tim's =
points.
>
> On 27 August 2012 18:26, Tim Bray <tbray@textuality.com> =
wrote:
> > What William said about not needing the appendix. If =
you=92re going to
> > go through the pain of abandoning the XML =
version, why also go through
> > the pain of writing an =
appendix, when there=92s a perfectly good RFC in
> > place to =
point to.  -T
> >
> > On Mon, Aug 27, 2012 at =
9:17 AM, William Mills <paulej@packetizer.com>
> =
>> To: apps-discuss@ietf.org
> >> =
Cc: jsmarr@google.com; webfinger@googlegroups.com
> =
>> Sent: Monday, August 27, 2012 8:56 AM
> >> Subject: =
[apps-discuss] Proposed changes to WebFinger regarding XML
> =
>> vs JSON
> >>
> >> Folks,
> =
>>
> >> Mike, Gonzalo, and I have had some off-list =
discussions about
> >> WebFinger and how to resolve the one =
sticky point that we think has
> >> caused the most concern. =
 That point is whether we should we allow both
> XML and =
JSON.
> >>
> >> We have heard proposals to "just =
pick one" and, while I appreciate
> >> the reasoning, I =
could not help ignoring that
> >>
> >>   1) =
RFC 6415 exists and describes XML the single mandatory format
> =
>>   2) Existing implementations use XML
> =
>>
> >> Nonetheless, I also cannot ignore the =
long-term value in selecting
> >> one format we can be sure =
is widely supported consistently.  I'm
> >> fairly =
confident that most want only JSON at this point, even though
> =
>> most (if not
> >> all) current implementations =
today use XML.  While I'm personally
> >> favorable to =
using XML, I know my personal preferences are not
> >> =
representative of everyone. :-)
> >>
> >> So =
what we discussed was mentioning XML (perhaps with examples), =
but
> >> putting that in an appendix and saying the usage is =
historic.  What
> >> this would mean is that the text =
acknowledges that there are servers
> >> that might process =
both XML and JSON, and even older servers that
> >> only =
process XML.  The main body of the document would only =
require
> >> support for JSON from clients and =
servers.
> >>
> >> Before we make these changes =
to the text, I want to seek input from
> >> the group. =
 I believe it would be acceptable, but I do not want those
> =
>> changes to cause significant issues for anyone.
> =
>>
> >> Thanks,
> >> Paul
> =
>>
> >> PS - Please follow-up only on the apps-discuss =
list.
> >>
> >>
> >> =
_______________________________________________
> >> =
apps-discuss mailing list
> >> apps-discuss@ietf.org
> =
>>  apps-discuss@ietf.org
> =
>>  apps-discuss@ietf.org
> =
>  apps-discuss@ietf.org
> apps-discuss@ietf.org
apps-discuss@ietf.org

To: "'George Fletcher'" , "'Mark Nottingham'" 
References: 	<4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com>			<44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com>						<35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net>	 <503CDF26.8050000@aol.com>
In-Reply-To: <503CDF26.8050000@aol.com>
Date: Tue, 28 Aug 2012 15:17:19 -0400
Message-ID: <02a301cd8551$be7ab390$3b701ab0$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02A4_01CD8530.376A2500"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFb3Wt68HpLZ7ZyHnoKMrZHlzcyBQH14U4xAZ6Br/cCWNrQtwIOUYf2AgMXr+8B4HmqlgGhGIVxAUAhVLECgOqLOADUaqV0Ain7f7cBffnLSZek+Euw
Content-Language: en-us
Cc: 'IETF Apps Discuss' 
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 19:17:08 -0000

This is a multipart message in MIME format.

------=_NextPart_000_02A4_01CD8530.376A2500
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

George,

 

I believe it might be useful to introduce those who break your WebFinger
server to Louisville Slugger. :)

 

Your pain is understood, but I do not see a way to avoid it.  We could
introduce something in DNS, but that would also present challenges.  No
matter where we "root" the discovery process, there is a potential somebody
could break it.  It could be rooted somewhere other than the root of the
domain (e.g., webfinger.example.com), but we either need to decide in
advance of such a location or introduce a way to discovery the discovery
resources.

 

Do you have a suggestion that would make this less likely to be broken?

 

Paul

 

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
On Behalf Of George Fletcher
Sent: Tuesday, August 28, 2012 11:09 AM
To: Mark Nottingham
Cc: IETF Apps Discuss
Subject: Re: [apps-discuss] Looking at Webfinger

 

Way "late to the party" but I can speak from experience that deployment can
be a real issue in some environments. It's all really straight forward in a
small company or an environment where the identity team "owns" the root
domain (e.g. example.com). However, if an entire other group in a large
organization "owns" the root domain (home page for the site) and the
identity team then needs to get them to make changes, the deployment
solution gets brittle pretty quick. I've had our webfinger support broken at
least twice because the "other" team didn't know that certain configs were
required:)

Also, installing the "dynamic pluming" can be more problematic is these
cases. It is possible to get apache rewrite rules or netscaler magic in
place to make it work, it's just a more brittle deployment architecture.

Thanks,
George

On 7/4/12 6:58 PM, John Panzer wrote:

Mark -- Of course I was speaking about practical realities of typical web
server administration and deployment.  In practical terms, adding a new
mod_rewrite rule or moral equivalent is going to be easier than adding a new
PHP script that connects to a database.  The latter is just always going to
be a much higher bar. 

 

And, something that returns per-user data is generally going to need a
dynamic service of some kind, unless your site has just a handful of users
and you don't mind going through a publishing exercise each time you add or
change a user...

 

None of this has anything to do with the interface, just deployment
realities.  And in reality all of this is going to need a dynamic service
somewhere for each non-trivial site, this is all just a question of how to
hook it up.




--
John Panzer / Google
jpanzer@google.com / abstractioneer.org   /
@jpanzer

 

 

On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham  wrote:

On 05/07/2012, at 8:16 AM, John Panzer wrote:

> Just as a historical note.  The envisioned usage of host-meta was
originally to avoid a specification which mandated a particular dynamic URL
API at a particular /.well-known endpoint (because it may not be feasible to
do that across all organizations and deployments).  The host-meta document
itself would be highly cacheable and so wouldn't incur an additional network
trip in the common case.
>
> Having a 3xx redirect is a reasonable alternative that allows a similar
escape hatch via something like mod_rewrite, albeit at the cost of needing
an additional network trip each time.  Since a deployment can always avoid
the 3xx redirect with additional dynamic plumbing behind the well-known
endpoint, I don't think that's a horrible thing.
>
> An application-level redirect would be almost equivalent to an HTTP
redirect, but then there are two ways to do the same thing.  If _only_ an
application-level redirect is allowed, then you have to have at least a
minimal dynamic service at the well-known endpoint (no more mod_rewrite).
But the whole reason for this is to avoid the requirement for a dynamic
service behind well-known...

"dynamic" and "static" are properties of the implementation, not the
interface. HTTP doesn't require that any particular URL be "dynamic";
anything can, with the right metadata, be cached (and indeed, I've cached
many, many things with the wrong metadata, because of silly site operators
and their ideas about "dynamic").

Now, if people want to target a particular implementation that makes it
easier to serve a particular style of URL without writing code, fine, but
let's not confuse things.

E.g., a URL like

http://example.com/.well-known/user/bob

is easy to serve in pretty much any way you like with Apache.

I'm also going to push back on the "it may not be feasible to do that across
all organizations and deployments" motivation. This is a race to the bottom.
The trick is to make it accessible enough to get sufficient traction to pull
everyone along, without pandering to *everyone*'s requirements.

Regards,


--
Mark Nottingham   http://www.mnot.net/




 






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

 


------=_NextPart_000_02A4_01CD8530.376A2500
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


George,
 
I believe it might be useful to introduce those who break your =
WebFinger server to Louisville Slugger. :)
 
Your pain is understood, but I do not see a way to avoid it.  We =
could introduce something in DNS, but that would also present =
challenges.  No matter where we “root” the discovery =
process, there is a potential somebody could break it.  It could be =
rooted somewhere other than the root of the domain (e.g., =
webfinger.example.com), but we either need to decide in advance of such =
a location or introduce a way to discovery the discovery =
resources.
 
Do you have a suggestion that would make this less likely to be =
broken?
 
Paul
 
From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of George =
Fletcher
Sent: Tuesday, August 28, 2012 11:09 AM
To: =
Mark Nottingham
Cc: IETF Apps Discuss
Subject: Re: =
[apps-discuss] Looking at Webfinger
 
Way "late to the =
party" but I can speak from experience that deployment can be a =
real issue in some environments. It's all really straight forward in a =
small company or an environment where the identity team "owns" =
the root domain (e.g. example.com). However, if an entire other group in =
a large organization "owns" the root domain (home page for the =
site) and the identity team then needs to get them to make changes, the =
deployment solution gets brittle pretty quick. I've had our webfinger =
support broken at least twice because the "other" team didn't =
know that certain configs were required:)

Also, installing the =
"dynamic pluming" can be more problematic is these cases. It =
is possible to get apache rewrite rules or netscaler magic in place to =
make it work, it's just a more brittle deployment =
architecture.

Thanks,
George
On 7/4/12 6:58 PM, John Panzer =
wrote:
Mark =
-- Of course I was speaking about practical realities of typical web =
server administration and deployment.  In practical terms, adding a =
new mod_rewrite rule or moral equivalent is going to be easier than =
adding a new PHP script that connects to a database.  The latter is =
just always going to be a much higher bar. 
 
And, something that returns per-user data is generally =
going to need a dynamic service of some kind, unless your site has just =
a handful of users and you don't mind going through a publishing =
exercise each time you add or change a =
user...
 
None of this has anything to do with the interface, =
just deployment realities.  And in reality all of this is going to =
need a dynamic service somewhere for each non-trivial site, this is all =
just a question of how to hook it up.

 
 
On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham <mnot@mnot.net> =
wrote:
On 05/07/2012, at 8:16 AM, John Panzer =
wrote:

> Just as a historical note.  The envisioned usage =
of host-meta was originally to avoid a specification which mandated a =
particular dynamic URL API at a particular /.well-known endpoint =
(because it may not be feasible to do that across all organizations and =
deployments).  The host-meta document itself would be highly =
cacheable and so wouldn't incur an additional network trip in the common =
case.
>
> Having a 3xx redirect is a reasonable alternative =
that allows a similar escape hatch via something like mod_rewrite, =
albeit at the cost of needing an additional network trip each time. =
 Since a deployment can always avoid the 3xx redirect with =
additional dynamic plumbing behind the well-known endpoint, I don't =
think that's a horrible thing.
>
> An application-level =
redirect would be almost equivalent to an HTTP redirect, but then there =
are two ways to do the same thing.  If _only_ an application-level =
redirect is allowed, then you have to have at least a minimal dynamic =
service at the well-known endpoint (no more mod_rewrite).  But the =
whole reason for this is to avoid the requirement for a dynamic service =
behind well-known...
"dynamic" and "static" are =
properties of the implementation, not the interface. HTTP doesn't =
require that any particular URL be "dynamic"; anything can, =
with the right metadata, be cached (and indeed, I've cached many, many =
things with the wrong metadata, because of silly site operators and =
their ideas about "dynamic").

Now, if people want to =
target a particular implementation that makes it easier to serve a =
particular style of URL without writing code, fine, but let's not =
confuse things.

E.g., a URL like

http://example.com/.well-known/user/bob

is =
easy to serve in pretty much any way you like with Apache.

I'm =
also going to push back on the "it may not be feasible to do that =
across all organizations and deployments" motivation. This is a =
race to the bottom. The trick is to make it accessible enough to get =
sufficient traction to pull everyone along, without pandering to =
*everyone*'s requirements.

Regards,

--
Mark =
Nottingham   http://www.mnot.net/


 



_______________________=
________________________
apps-discuss mailing =
list
apps-discuss@ietf.org
https://www.i=
etf.org/mailman/listinfo/apps-discuss
 

------=_NextPart_000_02A4_01CD8530.376A2500--


From paulej@packetizer.com  Tue Aug 28 12:21:42 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B050A21F85F9 for ; Tue, 28 Aug 2012 12:21:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.503
X-Spam-Level: 
X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1h-npoFCgT0 for ; Tue, 28 Aug 2012 12:21:41 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7938821F8503 for ; Tue, 28 Aug 2012 12:21:41 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q7SJLeh8010268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Aug 2012 15:21:40 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1346181700; bh=t5SHLCy7CYvVNdUuCAkc3CXRIoP7tQG6tp4C4cptudQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=VVztZAieL4mV8v1WzUBL8NpZKgygevW1ZMMuwe+ubTXTq+FkGF9rr2P7nSaSvuN2d mjTx+tA7NCoQn+oOFKtx9yxu0JS/JcRi0Nroylg2H/9ZbCnV9DY4AUOYqZacCXZLVo y1C/3WQ/sT9hIWSM6x0eaGGPiWnse78tc8Kg5I2o=
From: "Paul E. Jones" 
To: "'Peter Saint-Andre'" , "'Graham Klyne'" 
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im>	<5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im>	<4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com>	<5036875E.60607@stpeter.im>			<5037C02C.2070506@gmx.de>	<4E1F6AAD24975D4BA5B1680429673943667A9596@TK5EX14MBXC284.redmond.corp.microsoft.com>	<50382896.8060306@stpeter.im> <503CE696.9020601@ninebynine.org> <503D12A5.6010406@stpeter.im>
In-Reply-To: <503D12A5.6010406@stpeter.im>
Date: Tue, 28 Aug 2012 15:21:59 -0400
Message-ID: <02b601cd8552$65801e00$30805a00$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHQkPRpqE241VMBhFX0b1E5n3icagGmT2cgAfxtLQICXYfDzwLd38ExAiqwRqgAx76avAIISgVAArI+gaEBhDPaEAKCUJfEAVZYd+oBwqjmopasLR4Q
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 19:21:42 -0000

Without the domain part, I would not know what server to go to to issue a
query.  What would a client do with "acct:paulej"?  If there is a "default
server" defined, then a default domain could equally be assigned.  The
latter usually is, anyway.

I think having input forms that accept just "paulej" are reasonable, but
client should construct fully-qualified URIs by adding "acct:" and
"@packetizer.com".

Paul

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
> On Behalf Of Peter Saint-Andre
> Sent: Tuesday, August 28, 2012 2:49 PM
> To: Graham Klyne
> Cc: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 8/28/12 9:41 AM, Graham Klyne wrote:
> > On 25/08/2012 02:21, Peter Saint-Andre wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>
> >> On 8/24/12 5:44 PM, Mike Jones wrote:
> >>> I agree that it's not a relative reference, in the RFC 3986 sense.
> >>> It's intended to be a context-dependent reference, as explained by
> >>> Phillip.
> >>
> >> Can you point to examples of context-dependent references in other
> >> URI schemes, or would the acct scheme be breaking new ground here?
> >
> > The one that springs to mind is file:, which (in my experience) is
> > almost always used in a localized context.  (Relative references are a
> > red herring here.) Another is about:, which is specifically defined
> > for accessing a local context.
> >
> > I think there's some conflation going on of my earlier comment that
> > you quoted ("URIs are intended to be a global namespace") with the
> > notion that every URI must be a global identifier with a unique
> > referent.
> >
> > I made my comment when speaking in support of keeping the domain name
> > part, this was on the basis that I could see acct: URIs likely to be
> > used in ways that escape their original context; e.g. as a hyperlink
> > in a document.  In the case of file: - if a file: URI (as opposed to a
> > relative reference, which is by definition
> > scheme-free) appears in (say) a web page, it's usually an error.
> >
> > That said, I will also concede that the web already lives with
> > contextualized URIs, so if there really is a compelling case for
> > domain-less acct: URIs, I could live with that.
> 
> I confess that I still don't understand the case for domain-less "acct"
> URIs. What exactly is the local context, and why would "acct"
> URIs be used in that context? For example, I could imagine that a local
> context might be accessing a device under my physical control or using a
> terminal to access infrastructure on a local network, but it's not clear
> to me why one would use an "acct" URI in those scenarios.
> What am I missing?
> 
> > I've said previously that I think the acct: scheme should be
> > associated with a specific dereferencing mechanism (i.e. WebFinger
> > - so it can be used as a generic hyperlink).  If domain-free acct:
> > URIs are allowed, then I think something should also be said about how
> > they should be dereferenced.
> 
> Agreed.
> 
> Peter
> 
> - --
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAlA9EqUACgkQNL8k5A2w/vymJwCgrBQliqt8GO6IGYw8na7ckabK
> BrEAnR/Vkj0AdiRO7heBqXuAOkba5YNa
> =+y5T
> -----END PGP SIGNATURE-----
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From stpeter@stpeter.im  Tue Aug 28 12:25:01 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B091C21F8615 for ; Tue, 28 Aug 2012 12:25:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.574
X-Spam-Level: 
X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5NjZgOpYSpQ for ; Tue, 28 Aug 2012 12:25:01 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFB821F8602 for ; Tue, 28 Aug 2012 12:25:01 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0167B40D3B; Tue, 28 Aug 2012 13:26:09 -0600 (MDT)
Message-ID: <503D1B0B.5050101@stpeter.im>
Date: Tue, 28 Aug 2012 13:24:59 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: "Paul E. Jones" 
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im>	<5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im>	<4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com>	<5036875E.60607@stpeter.im>			<5037C02C.2070506@gmx.de>	<4E1F6AAD24975D4BA5B1680429673943667A9596@TK5EX14MBXC284.redmond.corp.microsoft.com>	<50382896.8060306@stpeter.im> <503CE696.9020601@ninebynine.org> <503D12A5.6010406@stpeter.im> <02b601cd8552$65801e00$30805a00$@packetizer.com>
In-Reply-To: <02b601cd8552$65801e00$30805a00$@packetizer.com>
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: 'Graham Klyne' , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 19:25:02 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/28/12 1:21 PM, Paul E. Jones wrote:
> Without the domain part, I would not know what server to go to to
> issue a query.  What would a client do with "acct:paulej"?  If
> there is a "default server" defined, then a default domain could
> equally be assigned.  The latter usually is, anyway.
> 
> I think having input forms that accept just "paulej" are
> reasonable, but client should construct fully-qualified URIs by
> adding "acct:" and "@packetizer.com".

That's how it seems to me, which is why I'm confused. ;-)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlA9GwsACgkQNL8k5A2w/vxOIgCguPrmCkGm5GWD3QC5cn/w2OPB
Sh0AoPqgUoE0jJRoxbP7lUvddHXog47M
=xtfV
-----END PGP SIGNATURE-----

From ve7jtb@ve7jtb.com  Tue Aug 28 12:28:59 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C2111E80FC for ; Tue, 28 Aug 2012 12:28:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.498
X-Spam-Level: 
X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkdbvXedvFXk for ; Tue, 28 Aug 2012 12:28:58 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id B0DDB21F8616 for ; Tue, 28 Aug 2012 12:28:57 -0700 (PDT)
Received: by qadz3 with SMTP id z3so2890413qad.10 for ; Tue, 28 Aug 2012 12:28:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=R3uaCfXNYEveJtZxLjQtFE/tfC++BBcMLkOf1HS3KTU=; b=TYZybz/D8YK9wl3kzraDqzdA5lSwAlSkDPDX9sp1y6c9HmkIWD11OkrP0W5mdqGkzn NCrGYAb2CjNIZnFyKUmjWsFrPoghvJJcIqO37NZ05KzKaKc8KbNCVVdmW/4oH086fBSg GIoIv0NMcA0r9JFkIYgkeGV7tIz5hBjrxubof4kBjWcn9aPgpX/sF4nIM3njRix88zqG Vczdzx5O/NDuvH6MbTQZ987ekp/gUhBdmqEHZxXqShDnQjLbe5vSSwErML5IQhGpWIKN jvpMcAE/L0AsmK67DdzRNPXLJ/xkRH2SaesnQ+aOqWm6QkyDtMYSmpSeJWBf4iVgdiF6 kKUg==
Received: by 10.224.17.145 with SMTP id s17mr7082461qaa.99.1346182136449; Tue, 28 Aug 2012 12:28:56 -0700 (PDT)
Received: from [192.168.1.211] (190-20-54-75.baf.movistar.cl. [190.20.54.75]) by mx.google.com with ESMTPS id u8sm14017031qal.22.2012.08.28.12.28.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Aug 2012 12:28:54 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_04443C6A-FA35-4F13-ABE7-274910C40A17"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
From: John Bradley 
In-Reply-To: <02a301cd8551$be7ab390$3b701ab0$@packetizer.com>
Date: Tue, 28 Aug 2012 15:28:39 -0400
Message-Id: <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com>
References:  <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com>   <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com>      <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net>  <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com>
To: "Paul E. Jones" 
X-Mailer: Apple Mail (2.1486)
X-Gm-Message-State: ALoCoQkd+Via/oF7W/G76R6krRJI62sFLok/FVuJW0OsD8PkA8SO9bnkDuJwLJ24I5a1hQyVpBH4
Cc: 'Mark Nottingham' , 'IETF Apps Discuss' 
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 19:28:59 -0000

--Apple-Mail=_04443C6A-FA35-4F13-ABE7-274910C40A17
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_BCC9A713-8D9D-4FCD-8F4E-B26C233A6DE7"


--Apple-Mail=_BCC9A713-8D9D-4FCD-8F4E-B26C233A6DE7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

There are cases where there are hosted domains (Google etc) that may not =
have a http host for the domain name used in the users email address. =20=


There may be merit to having a webfinger.example.com fallback where the =
client can't reach the .well-known for the primary host.

I know that some sort of SRV record would be the correct way to do it, =
but in the real world SMB don't enter SRV records even if there DNS =
provider support them.
The most you can get them to do is add a CNAME or MX record.

Supporting these sorts of domains somehow is a important issue.

John B.

On 2012-08-28, at 3:17 PM, "Paul E. Jones"  =
wrote:

> George,
> =20
> I believe it might be useful to introduce those who break your =
WebFinger server to Louisville Slugger. :)
> =20
> Your pain is understood, but I do not see a way to avoid it.  We could =
introduce something in DNS, but that would also present challenges.  No =
matter where we =93root=94 the discovery process, there is a potential =
somebody could break it.  It could be rooted somewhere other than the =
root of the domain (e.g., webfinger.example.com), but we either need to =
decide in advance of such a location or introduce a way to discovery the =
discovery resources.
> =20
> Do you have a suggestion that would make this less likely to be =
broken?
> =20
> Paul
> =20
> From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of George Fletcher
> Sent: Tuesday, August 28, 2012 11:09 AM
> To: Mark Nottingham
> Cc: IETF Apps Discuss
> Subject: Re: [apps-discuss] Looking at Webfinger
> =20
> Way "late to the party" but I can speak from experience that =
deployment can be a real issue in some environments. It's all really =
straight forward in a small company or an environment where the identity =
team "owns" the root domain (e.g. example.com). However, if an entire =
other group in a large organization "owns" the root domain (home page =
for the site) and the identity team then needs to get them to make =
changes, the deployment solution gets brittle pretty quick. I've had our =
webfinger support broken at least twice because the "other" team didn't =
know that certain configs were required:)
>=20
> Also, installing the "dynamic pluming" can be more problematic is =
these cases. It is possible to get apache rewrite rules or netscaler =
magic in place to make it work, it's just a more brittle deployment =
architecture.
>=20
> Thanks,
> George
>=20
> On 7/4/12 6:58 PM, John Panzer wrote:
> Mark -- Of course I was speaking about practical realities of typical =
web server administration and deployment.  In practical terms, adding a =
new mod_rewrite rule or moral equivalent is going to be easier than =
adding a new PHP script that connects to a database.  The latter is just =
always going to be a much higher bar.
> =20
> And, something that returns per-user data is generally going to need a =
dynamic service of some kind, unless your site has just a handful of =
users and you don't mind going through a publishing exercise each time =
you add or change a user...
> =20
> None of this has anything to do with the interface, just deployment =
realities.  And in reality all of this is going to need a dynamic =
service somewhere for each non-trivial site, this is all just a question =
of how to hook it up.
>=20
> --
> John Panzer / Google
> jpanzer@google.com / abstractioneer.org / @jpanzer
> =20
> =20
>=20
> On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham  wrote:
> On 05/07/2012, at 8:16 AM, John Panzer wrote:
>=20
> > Just as a historical note.  The envisioned usage of host-meta was =
originally to avoid a specification which mandated a particular dynamic =
URL API at a particular /.well-known endpoint (because it may not be =
feasible to do that across all organizations and deployments).  The =
host-meta document itself would be highly cacheable and so wouldn't =
incur an additional network trip in the common case.
> >
> > Having a 3xx redirect is a reasonable alternative that allows a =
similar escape hatch via something like mod_rewrite, albeit at the cost =
of needing an additional network trip each time.  Since a deployment can =
always avoid the 3xx redirect with additional dynamic plumbing behind =
the well-known endpoint, I don't think that's a horrible thing.
> >
> > An application-level redirect would be almost equivalent to an HTTP =
redirect, but then there are two ways to do the same thing.  If _only_ =
an application-level redirect is allowed, then you have to have at least =
a minimal dynamic service at the well-known endpoint (no more =
mod_rewrite).  But the whole reason for this is to avoid the requirement =
for a dynamic service behind well-known...
>=20
> "dynamic" and "static" are properties of the implementation, not the =
interface. HTTP doesn't require that any particular URL be "dynamic"; =
anything can, with the right metadata, be cached (and indeed, I've =
cached many, many things with the wrong metadata, because of silly site =
operators and their ideas about "dynamic").
>=20
> Now, if people want to target a particular implementation that makes =
it easier to serve a particular style of URL without writing code, fine, =
but let's not confuse things.
>=20
> E.g., a URL like
>=20
> http://example.com/.well-known/user/bob
>=20
> is easy to serve in pretty much any way you like with Apache.
>=20
> I'm also going to push back on the "it may not be feasible to do that =
across all organizations and deployments" motivation. This is a race to =
the bottom. The trick is to make it accessible enough to get sufficient =
traction to pull everyone along, without pandering to *everyone*'s =
requirements.
>=20
> Regards,
>=20
> --
> Mark Nottingham   http://www.mnot.net/
>=20
>=20
>=20
> =20
>=20
>=20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> =20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


--Apple-Mail=_BCC9A713-8D9D-4FCD-8F4E-B26C233A6DE7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

There are cases where there are =
hosted domains (Google etc) that may not have a http host for the domain =
name used in the users email address.  

There =
may be merit to having a webfinger.example.com fallback =
where the client can't reach the .well-known for the primary =
host.

I know that some sort of SRV record would =
be the correct way to do it, but in the real world SMB don't enter SRV =
records even if there DNS provider support them.
The most you =
can get them to do is add a CNAME or MX =
record.

Supporting these sorts of domains =
somehow is a important issue.

John =
B.

On 2012-08-28, at 3:17 PM, "Paul =
E. Jones" <paulej@packetizer.com> =
wrote:

George,
 
I believe it might be =
useful to introduce those who break your WebFinger server to Louisville =
Slugger. :)
 
Your pain is understood, but I do not see a =
way to avoid it.  We could introduce something in DNS, but that =
would also present challenges.  No matter where we =93root=94 the =
discovery process, there is a potential somebody could break it.  =
It could be rooted somewhere other than the root of the domain =
(e.g., webfinger.example.com), but we either =
need to decide in advance of such a location or introduce a way to =
discovery the discovery resources.
 
Do you have a suggestion =
that would make this less likely to be =
broken?
 
Paul
 
From: apps-discuss-bounces@ietf.or=
g [mailto:apps-discuss-bounces@ietf.org] On Behalf Of George =
Fletcher
Sent: Tuesday, August 28, 2012 =
11:09 AM
To: Mark =
Nottingham
Cc: IETF Apps =
Discuss
Subject: Re: [apps-discuss] Looking =
at Webfinger
 
Way "late to the =
party" but I can speak from experience that deployment can be a real =
issue in some environments. It's all really straight forward in a small =
company or an environment where the identity team "owns" the root domain =
(e.g. example.com). However, if an =
entire other group in a large organization "owns" the root domain (home =
page for the site) and the identity team then needs to get them to make =
changes, the deployment solution gets brittle pretty quick. I've had our =
webfinger support broken at least twice because the "other" team didn't =
know that certain configs were required:)

Also, installing the =
"dynamic pluming" can be more problematic is these cases. It is possible =
to get apache rewrite rules or netscaler magic in place to make it work, =
it's just a more brittle deployment =
architecture.

Thanks,
George
On 7/4/12 6:58 PM, John Panzer =
wrote:
Mark -- Of course I was =
speaking about practical realities of typical web server administration =
and deployment.  In practical terms, adding a new mod_rewrite rule =
or moral equivalent is going to be easier than adding a new PHP script =
that connects to a database.  The latter is just always going to be =
a much higher bar.
And, =
something that returns per-user data is generally going to need a =
dynamic service of some kind, unless your site has just a handful of =
users and you don't mind going through a publishing exercise each time =
you add or change a user...
 
None of this has anything to do with the interface, =
just deployment realities.  And in reality all of this is going to =
need a dynamic service somewhere for each non-trivial site, this is all =
just a question of how to hook it up.

--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / =
@jpanzer
On Wed, Jul 4, =
2012 at 3:36 PM, Mark Nottingham <On 05/07/2012, at 8:16 AM, John Panzer =
wrote:

> Just as a historical note.  The envisioned usage =
of host-meta was originally to avoid a specification which mandated a =
particular dynamic URL API at a particular /.well-known endpoint =
(because it may not be feasible to do that across all organizations and =
deployments).  The host-meta document itself would be highly =
cacheable and so wouldn't incur an additional network trip in the common =
case.
>
> Having a 3xx redirect is a reasonable alternative =
that allows a similar escape hatch via something like mod_rewrite, =
albeit at the cost of needing an additional network trip each time. =
 Since a deployment can always avoid the 3xx redirect with =
additional dynamic plumbing behind the well-known endpoint, I don't =
think that's a horrible thing.
>
> An application-level =
redirect would be almost equivalent to an HTTP redirect, but then there =
are two ways to do the same thing.  If _only_ an application-level =
redirect is allowed, then you have to have at least a minimal dynamic =
service at the well-known endpoint (no more mod_rewrite).  But the =
whole reason for this is to avoid the requirement for a dynamic service =
behind well-known...



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

=

--Apple-Mail=_BCC9A713-8D9D-4FCD-8F4E-B26C233A6DE7--

--Apple-Mail=_04443C6A-FA35-4F13-ABE7-274910C40A17
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgy
ODE5Mjg0MFowIwYJKoZIhvcNAQkEMRYEFEBHLzIMWrKu/2ohsxPpiFq1yJPDMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
AAFCgI/8FYukU6EGMAfNCE87xmrivso9hsR1ngN91yVwYy6rjPIdGEOadv46/7YJczqlaib4o/d9
PETPZrqOdYI+pcMpjP4rbcSfbEFPeeT1D6DC8rieAUB00lwUCbQ5Nnsv1Rrs7CWNESIrZzvK4Cta
GNw3QOaFzH2uMAop97WzP27ga5ZstiNUWGYssXfeO7Z86gWLNfDyDbNTlm6zwtcy2S4TGjNIgzzl
PyLVyUh+Caasm0whEwlo0AOlxalOZAZU1crE/BejzHdEhGK3uZMxYi+0wr2RbBdomzu4yxn5y6sK
SfMQpwcfvASdMIE70krTwgN7085CErrlsgoZ1LUAAAAAAAA=

--Apple-Mail=_04443C6A-FA35-4F13-ABE7-274910C40A17--

From paulej@packetizer.com  Tue Aug 28 20:37:38 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D874E11E80BA for ; Tue, 28 Aug 2012 20:37:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.504
X-Spam-Level: 
X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.094,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2Kv2CCqENVg for ; Tue, 28 Aug 2012 20:37:34 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4A611E808A for ; Tue, 28 Aug 2012 20:37:34 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q7T3bUxB029564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Aug 2012 23:37:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1346211451; bh=5CHSCSGr6YMUwsGqNTApHRmrNO0QLY9/RVJ6Zy1HbS0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=BHfbPVu02LUlfKD5un3KswGKiKaf2eLWBKTRoz+qw2c70dkc8hGG7CFY7JhQtcU2F /k3o79B905h/oFtjUfepZw4DujqUp5YdJxGd4mRgkaHBo2GFD42OpOvqPOTdc0S4fU 6g/Az0chehkhshfTnsfpovgdUs3DPCu9lfExD5ko=
From: "Paul E. Jones" 
To: "'John Bradley'" 
References:  <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com>   <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com>      <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net>  <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com>
In-Reply-To: <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com>
Date: Tue, 28 Aug 2012 23:37:50 -0400
Message-ID: <032d01cd8597$aac7f740$0057e5c0$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_032E_01CD8576.23B82C00"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFb3Wt68HpLZ7ZyHnoKMrZHlzcyBQH14U4xAZ6Br/cCWNrQtwIOUYf2AgMXr+8B4HmqlgGhGIVxAUAhVLECgOqLOADUaqV0Ain7f7cBffnLSQIkbXUiAp1soASXf3cb4A==
Content-Language: en-us
Cc: 'Mark Nottingham' , 'IETF Apps Discuss' 
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Aug 2012 03:37:39 -0000

This is a multipart message in MIME format.

------=_NextPart_000_032E_01CD8576.23B82C00
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

John,

 

If Google is hosting the domain or any other service provider, wouldn't
there still be an A record for the domain (e.g., packetizer.com)?  I know
there is for virtually every web hosting company I've used.  It seems like
this might just be one more hosted service Google could provide to its
customers, no?

 

I do not know exactly how this hosted service works, but what's hosted?  I
assume it's just email.  If web, then I see no issue.  If only email, then
the user just needs to have MX records pointing to Google and an A record
pointing to whatever service runs the WebFinger service.

 

In any case, if they can add a CNAME or MX record, I think we can get them
to add an A record.  I think it would be far more challenging for SMBs to
add a host like webfinger.example.com.  That would still require an A record
and a service provider capable of supporting it.

 

Paul

 

From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Tuesday, August 28, 2012 3:29 PM
To: Paul E. Jones
Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
Subject: Re: [apps-discuss] Looking at Webfinger

 

There are cases where there are hosted domains (Google etc) that may not
have a http host for the domain name used in the users email address.  

 

There may be merit to having a webfinger.example.com fallback where the
client can't reach the .well-known for the primary host.

 

I know that some sort of SRV record would be the correct way to do it, but
in the real world SMB don't enter SRV records even if there DNS provider
support them.

The most you can get them to do is add a CNAME or MX record.

 

Supporting these sorts of domains somehow is a important issue.

 

John B.

 

On 2012-08-28, at 3:17 PM, "Paul E. Jones"  wrote:





George,

 

I believe it might be useful to introduce those who break your WebFinger
server to Louisville Slugger. :)

 

Your pain is understood, but I do not see a way to avoid it.  We could
introduce something in DNS, but that would also present challenges.  No
matter where we "root" the discovery process, there is a potential somebody
could break it.  It could be rooted somewhere other than the root of the
domain (e.g.,   webfinger.example.com), but we
either need to decide in advance of such a location or introduce a way to
discovery the discovery resources.

 

Do you have a suggestion that would make this less likely to be broken?

 

Paul

 

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
On Behalf Of George Fletcher
Sent: Tuesday, August 28, 2012 11:09 AM
To: Mark Nottingham
Cc: IETF Apps Discuss
Subject: Re: [apps-discuss] Looking at Webfinger

 

Way "late to the party" but I can speak from experience that deployment can
be a real issue in some environments. It's all really straight forward in a
small company or an environment where the identity team "owns" the root
domain (e.g. example.com). However, if an entire other group in a large
organization "owns" the root domain (home page for the site) and the
identity team then needs to get them to make changes, the deployment
solution gets brittle pretty quick. I've had our webfinger support broken at
least twice because the "other" team didn't know that certain configs were
required:)

Also, installing the "dynamic pluming" can be more problematic is these
cases. It is possible to get apache rewrite rules or netscaler magic in
place to make it work, it's just a more brittle deployment architecture.

Thanks,
George

On 7/4/12 6:58 PM, John Panzer wrote:

Mark -- Of course I was speaking about practical realities of typical web
server administration and deployment.  In practical terms, adding a new
mod_rewrite rule or moral equivalent is going to be easier than adding a new
PHP script that connects to a database.  The latter is just always going to
be a much higher bar.

 

And, something that returns per-user data is generally going to need a
dynamic service of some kind, unless your site has just a handful of users
and you don't mind going through a publishing exercise each time you add or
change a user...

 

None of this has anything to do with the interface, just deployment
realities.  And in reality all of this is going to need a dynamic service
somewhere for each non-trivial site, this is all just a question of how to
hook it up.




--
John Panzer / Google
  jpanzer@google.com /
 abstractioneer.org / @jpanzer

 

 

On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham < 
mnot@mnot.net> wrote:

On 05/07/2012, at 8:16 AM, John Panzer wrote:

> Just as a historical note.  The envisioned usage of host-meta was
originally to avoid a specification which mandated a particular dynamic URL
API at a particular /.well-known endpoint (because it may not be feasible to
do that across all organizations and deployments).  The host-meta document
itself would be highly cacheable and so wouldn't incur an additional network
trip in the common case.
>
> Having a 3xx redirect is a reasonable alternative that allows a similar
escape hatch via something like mod_rewrite, albeit at the cost of needing
an additional network trip each time.  Since a deployment can always avoid
the 3xx redirect with additional dynamic plumbing behind the well-known
endpoint, I don't think that's a horrible thing.
>
> An application-level redirect would be almost equivalent to an HTTP
redirect, but then there are two ways to do the same thing.  If _only_ an
application-level redirect is allowed, then you have to have at least a
minimal dynamic service at the well-known endpoint (no more mod_rewrite).
But the whole reason for this is to avoid the requirement for a dynamic
service behind well-known...

"dynamic" and "static" are properties of the implementation, not the
interface. HTTP doesn't require that any particular URL be "dynamic";
anything can, with the right metadata, be cached (and indeed, I've cached
many, many things with the wrong metadata, because of silly site operators
and their ideas about "dynamic").

Now, if people want to target a particular implementation that makes it
easier to serve a particular style of URL without writing code, fine, but
let's not confuse things.

E.g., a URL like

 
http://example.com/.well-known/user/bob

is easy to serve in pretty much any way you like with Apache.

I'm also going to push back on the "it may not be feasible to do that across
all organizations and deployments" motivation. This is a race to the bottom.
The trick is to make it accessible enough to get sufficient traction to pull
everyone along, without pandering to *everyone*'s requirements.

Regards,


--
Mark Nottingham     http://www.mnot.net/





 







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

 

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

 


------=_NextPart_000_032E_01CD8576.23B82C00
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


John,
 
If Google is hosting the domain or any other service provider, =
wouldn’t there still be an A record for the domain (e.g., =
packetizer.com)?  I know there is for virtually every web hosting =
company I’ve used.  It seems like this might just be one more =
hosted service Google could provide to its customers, =
no?
 
I do not know exactly how this hosted service works, but what’s =
hosted?  I assume it’s just email.  If web, then I see =
no issue.  If only email, then the user just needs to have MX =
records pointing to Google and an A record pointing to whatever service =
runs the WebFinger service.
 
In any case, if they can add a CNAME or MX record, I think we can get =
them to add an A record.  I think it would be far more challenging =
for SMBs to add a host like webfinger.example.com.  That would =
still require an A record and a service provider capable of supporting =
it.
 
Paul
 
From:=
 =
John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Tuesday, August =
28, 2012 3:29 PM
To: Paul E. Jones
Cc: 'George =
Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
Subject: Re: =
[apps-discuss] Looking at Webfinger
 
There are =
cases where there are hosted domains (Google etc) that may not have a =
http host for the domain name used in the users email address. =
 
 
There may be merit to having a webfinger.example.com fallback =
where the client can't reach the .well-known for the primary =
host.
 
I =
know that some sort of SRV record would be the correct way to do it, but =
in the real world SMB don't enter SRV records even if there DNS provider =
support them.
The most you =
can get them to do is add a CNAME or MX =
record.
 
Supporting these sorts of domains somehow is a =
important issue.
 
John B.
 
On 2012-08-28, at 3:17 PM, "Paul E. Jones" =
<paulej@packetizer.com> =
wrote:


George,
 
I believe it might be useful to introduce those who break your =
WebFinger server to Louisville Slugger. =
:)
 
Your pain is understood, but I do not see a way to avoid it.  We =
could introduce something in DNS, but that would also present =
challenges.  No matter where we “root” the discovery =
process, there is a potential somebody could break it.  It could be =
rooted somewhere other than the root of the domain (e.g., webfinger.example.com), but we either =
need to decide in advance of such a location or introduce a way to =
discovery the discovery resources.
 
Do you have a suggestion that would make this less likely to be =
broken?
 
Paul
 
From:=
 apps-discuss-bounces@ietf.o=
rg [mailto:apps-discuss-bounces@ietf.org] On Behalf Of George =
Fletcher
Sent: Tuesday, August 28, 2012 =
11:09 AM
To: Mark =
Nottingham
Cc: IETF Apps =
Discuss
Subject: Re: [apps-discuss] Looking at =
Webfinger
 
Way "late to the =
party" but I can speak from experience that deployment can be a =
real issue in some environments. It's all really straight forward in a =
small company or an environment where the identity team "owns" =
the root domain (e.g. example.com). =
However, if an entire other group in a large organization =
"owns" the root domain (home page for the site) and the =
identity team then needs to get them to make changes, the deployment =
solution gets brittle pretty quick. I've had our webfinger support =
broken at least twice because the "other" team didn't know =
that certain configs were required:)

Also, installing the =
"dynamic pluming" can be more problematic is these cases. It =
is possible to get apache rewrite rules or netscaler magic in place to =
make it work, it's just a more brittle deployment =
architecture.

Thanks,
George
On 7/4/12 6:58 PM, John Panzer =
wrote:
Mark -- Of course I was speaking about practical =
realities of typical web server administration and deployment.  In =
practical terms, adding a new mod_rewrite rule or moral equivalent is =
going to be easier than adding a new PHP script that connects to a =
database.  The latter is just always going to be a much higher =
bar.
 
And, something that returns per-user data is generally =
going to need a dynamic service of some kind, unless your site has just =
a handful of users and you don't mind going through a publishing =
exercise each time you add or change a =
user...
 
None of this has anything to do with the interface, =
just deployment realities.  And in reality all of this is going to =
need a dynamic service somewhere for each non-trivial site, this is all =
just a question of how to hook it up.

--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / =
@jpanzer
 
 
On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham <mnot@mnot.net> =
wrote:
On 05/07/2012, at 8:16 AM, John Panzer =
wrote:

> Just as a historical note.  The envisioned usage =
of host-meta was originally to avoid a specification which mandated a =
particular dynamic URL API at a particular /.well-known endpoint =
(because it may not be feasible to do that across all organizations and =
deployments).  The host-meta document itself would be highly =
cacheable and so wouldn't incur an additional network trip in the common =
case.
>
> Having a 3xx redirect is a reasonable alternative =
that allows a similar escape hatch via something like mod_rewrite, =
albeit at the cost of needing an additional network trip each time. =
 Since a deployment can always avoid the 3xx redirect with =
additional dynamic plumbing behind the well-known endpoint, I don't =
think that's a horrible thing.
>
> An application-level =
redirect would be almost equivalent to an HTTP redirect, but then there =
are two ways to do the same thing.  If _only_ an application-level =
redirect is allowed, then you have to have at least a minimal dynamic =
service at the well-known endpoint (no more mod_rewrite).  But the =
whole reason for this is to avoid the requirement for a dynamic service =
behind well-known...
"dynamic" and "static" are =
properties of the implementation, not the interface. HTTP doesn't =
require that any particular URL be "dynamic"; anything can, =
with the right metadata, be cached (and indeed, I've cached many, many =
things with the wrong metadata, because of silly site operators and =
their ideas about "dynamic").

Now, if people want to =
target a particular implementation that makes it easier to serve a =
particular style of URL without writing code, fine, but let's not =
confuse things.

E.g., a URL like

http://example.com/.well-known/user/bob=


is easy to serve in pretty much any way you like with =
Apache.

I'm also going to push back on the "it may not be =
feasible to do that across all organizations and deployments" =
motivation. This is a race to the bottom. The trick is to make it =
accessible enough to get sufficient traction to pull everyone along, =
without pandering to *everyone*'s =
requirements.

Regards,

--
Mark =
Nottingham   http://www.mnot.net/



 




_____________=
__________________________________
apps-discuss =
mailing list
apps-discuss@ietf.org
<=
pre>https://www.ietf.org/mailman/listinfo/apps-discuss=

 
_________=
______________________________________
apps-discuss mailing =
list
apps-discuss@ietf.org
https://www.i=
etf.org/mailman/listinfo/apps-discuss
 

------=_NextPart_000_032E_01CD8576.23B82C00--


From laurentwalter.goix@telecomitalia.it  Wed Aug 29 01:25:18 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319DE21F858A for ; Wed, 29 Aug 2012 01:25:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.032
X-Spam-Level: 
X-Spam-Status: No, score=-1.032 tagged_above=-999 required=5 tests=[AWL=0.387,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I79XRSuRVWwB for ; Wed, 29 Aug 2012 01:25:17 -0700 (PDT)
Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id DD78821F857E for ; Wed, 29 Aug 2012 01:25:16 -0700 (PDT)
Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.245.1; Wed, 29 Aug 2012 10:25:07 +0200
Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Wed, 29 Aug 2012 10:25:07 +0200
From: Goix Laurent Walter 
To: =?utf-8?B?4piuIGVsZiBQYXZsaWsg4piu?= , Peter Saint-Andre 
Date: Wed, 29 Aug 2012 10:25:03 +0200
Thread-Topic: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
Thread-Index: Ac2FSaEJbqWHcFGkSHunRvvojwXf3wAbYWtA
Message-ID: 
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> <5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com> <1346172875-sup-9676@heahdk.net> <503D04E5.1090506@stpeter.im> <1346176849-sup-3504@heahdk.net>
In-Reply-To: <1346176849-sup-3504@heahdk.net>
Accept-Language: en-US
Content-Language: it-IT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
x-ti-disclaimer: Disclaimer1
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: apps-discuss 
Subject: [apps-discuss] R:  Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Aug 2012 08:25:18 -0000

PiAtLS0tLU1lc3NhZ2dpbyBvcmlnaW5hbGUtLS0tLQ0KPiBEYTogYXBwcy1kaXNjdXNzLWJvdW5j
ZXNAaWV0Zi5vcmcgW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10gUGVyDQo+
IGNvbnRvIGRpID8gZWxmIFBhdmxpayA/DQo+IEludmlhdG86IG1hcnRlZMOsIDI4IGFnb3N0byAy
MDEyIDIwLjE5DQo+IEE6IFBldGVyIFNhaW50LUFuZHJlDQo+IENjOiBhcHBzLWRpc2N1c3MNCj4g
T2dnZXR0bzogUmU6IFthcHBzLWRpc2N1c3NdIENvbW1lbnQgb24gZHJhZnQtaWV0Zi1hcHBzYXdn
LWFjY3QtdXJpLTAwLnR4dA0KPg0KPiBFeGNlcnB0cyBmcm9tIFBldGVyIFNhaW50LUFuZHJlJ3Mg
bWVzc2FnZSBvZiAyMDEyLTA4LTI4IDE3OjUwOjI5ICswMDAwOg0KPiA+IEhhc2g6IFNIQTENCj4g
Pg0KPiA+IE9uIDgvMjgvMTIgMTE6MDUgQU0sIGVsZiBQYXZsaWsgd3JvdGU6DQo+ID4gPiBFeGNl
cnB0cyBmcm9tIE1pa2UgSm9uZXMncyBtZXNzYWdlIG9mIDIwMTItMDgtMjMgMTg6NDk6MzYgKzAw
MDA6DQo+ID4gPj4gQXMgbG9uZyBhcyBJJ20gd3JpdGluZyBhYm91dCB0aGUgYWNjdDogVVJJLCBs
ZXQgbWUgYWRkIG15IHZvaWNlDQo+ID4gPj4gc3VwcG9ydGluZyBhbGxvd2luZyBsb2NhbCBhY2Nv
dW50IGlkZW50aWZpZXJzIHN1Y2ggYXMgImFjY3Q6am9lIg0KPiA+ID4+IHRvIGJlIHVzZWQsIGlu
IGFkZGl0aW9uIHRvIGZ1bGx5IHF1YWxpZmllZCBuYW1lcyBzdWNoDQo+ID4gPj4gImFjY3Q6am9l
QGV4YW1wbGUuY29tIi4gIFRoZSByZWFzb24gdGhhdCB0aGlzIHRoaXMgY2FuIHdvcmsgZmluZQ0K
PiA+ID4+IGZvciBkaXNjb3ZlcnkgaXMgdGhhdCBpZiB5b3UncmUgY29udGFjdGluZyB0aGUgZGlz
Y292ZXJ5IHNlcnZlcg0KPiA+ID4+IGF0IGV4YW1wbGUuY29tLCB0aGUgaWRlbnRpZmllciAiYWNj
dDpqb2UiIGlzIHVuYW1iaWd1b3VzIGluIHRoYXQNCj4gPiA+PiBjb250ZXh0Lg0KPiA+ID4NCj4g
PiA+IFdoaWxlIGFnbyBJJ3ZlIHN1Z2dlc3RlZCBvbiB3ZWJmaW5nZXIgbWFpbGluZyBsaXN0IHRv
IGFsbG93DQo+ID4gPiBpZGVudGlmaWVycyB3aXRob3V0IGxvY2FsIHBhcnQsIGp1c3Q6IEBkb21h
aW4udGxkDQo+ID4NCj4gPiBIbW0sIGlmIGxvY2FsIHBhcnQgYW5kIGRvbWFpbiBwYXJ0IGFyZSBi
b3RoIG9wdGlvbmFsLCBjYW4gd2UgYWxzbyBoYXZlDQo+ID4gImFjY3Q6QCI/IDstKQ0KPiA+DQo+
ID4gPiBUaGlzIHdheSBwcm9qZWN0cyBjb3VsZCBoYXZlIHNvcnQgb2YgY2F0Y2ggYWxsIGFjY291
bnRzIGxpa2U6DQo+ID4gPiBAaWV0Zi5vcmcgYW5kIHBlb3BsZSBoYXZpbmcgcGVyc29uYWwgZG9t
YWlucyBjb3VsZCBhbHNvIGp1c3QgdXNlDQo+ID4gPiBAbmFtZS5tZSAocmF0aGVyIHRoYW4gbWVA
bmFtZS5tZSBvciBpQG5hbWUubWUgZXRjLikNCj4gPg0KPiA+IFllcywgSSByZWNhbGwgdGhhdCBk
aXNjdXNzaW9uLCBhbmQgaWYgSSByZWNhbGwgY29ycmVjdGx5IG1vc3QgcGVvcGxlDQo+ID4gdGhv
dWdodCBpdCB3YXNuJ3QgYSBncmVhdCBpZGVhLiBXaGF0IGRvZXMgaXQgbWVhbiB0bywgc2F5LCBw
ZXJmb3JtIGENCj4gPiBXZWJGaW5nZXIgcXVlcnkgYWdhaW5zdCBhIGJhcmUgZG9tYWluPw0KPiBZ
ZXMsIG1hbnkgcGVvcGxlIG1lbnRpb25lZCB0aGUgb3JpZ2luYWwgaW50ZW50aW9uIHRvIG1pbWlj
IGZhbWlsaWFyIHRvIG1vc3QNCj4gcGVvcGxlIGVtYWlsIGFkZHJlc3Nlcw0KPg0KPiA+DQo+ID4g
PiBJdCBzZWFtcyB0byBtZSBhdHRyYWN0aXZlIGlmIHVzZWQgaW4gb3N0YXR1cyBmb3IgZmVkZXJh
dGVkDQo+ID4gPiBtaWNyb2Jsb2dnaW5nLg0KPiA+DQo+ID4gQ291bGQgeW91IHBlcmhhcHMgZXhw
bGFpbiB0aGF0IHNjZW5hcmlvIGluIGEgYml0IG1vcmUgZGV0YWlsPyBJJ20NCj4gPiBjdXJpb3Vz
IHRvIGxlYXJuIHdoYXQgcmVxdWlyZW1lbnRzIHRoYXQgYnJpbmdzIGluLg0KPiBBdCBzb21lIHBv
aW50IGkgdGhvdWdodCB0aGF0IGZvciBleGFtcGxlIHR3aXR0ZXIgc3BlY2lmaWM6IEBpZXRmIGNv
dWxkIGJlY29tZQ0KPiBwb3NzaWJseSBzZWxmIGhvc3RlZCBAaWV0Zi5vcmcNCj4gYXMgd2VsbCBh
cyBwZW9wbGUgd2l0aCBwZXJzb25hbCBkb21haW5zIGNvdWxkIHVzZSBqdXN0IGlkZW50aWZpZXJz
IGxpa2UNCj4gQGZyYW5reS5tZSBhbmQgY2hvb3NlIHdoZXJlIHRoZXkgd2FudCB0byBob3N0IHRo
ZWlyIGFjY291bnRzLg0KPg0KPiBJIGFsc28gcmVjYWxsIE1hcmt1cyBTYWJhZGVsbG8gZW50aHVz
aWFzbSB0byBpbiBzb21lIHdheXMgaW5mYW1vdXMgaS1uYW1lcw0KPiB3aGljaCBqdXN0IHVzZSA9
bmFtZSBmb3IgaW5kaXZpZHVhbHMgYW5kIEBuYW1lIGZvciBvcmdhbml6YXRpb25zDQo+IGh0dHBz
Oi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0ktbmFtZQ0KPg0KPiBIb25lc3RseSBJIGp1c3Qgd2Fu
dGVkIHRvIGhlYXIgbW9yZSBvcGluaW9ucyBhYm91dCBpdCwgc2VlaW5nIG15c2VsZiBwb3NzaWJs
ZQ0KPiBjb252ZW5pZW5jZSBpbiBoYXZpbmcgb3B0aW9uIHRvIGp1c3Qgc2tpcCBsb2NhbCBwYXJ0
Lg0KW3dhbHRlcl0gUGVyc29uYWxseSBJJ2QgcmF0aGVyIHNlZSB0aGUgdmFsdWUgb2YgZG9tYWlu
LW9ubHkgcmF0aGVyIHRoYW4gZG9tYWluLWxlc3MgYWNjdDogVVJJcyBmb3IgZGVwbG95bWVudHMu
IEluIFsxXSBJIGlsbHVzdHJhdGVkIGEgdXNlIGNhc2UgZm9yIGxhcmdlIGRlcGxveW1lbnRzIGFu
ZCBmZWRlcmF0ZWQgc29jaWFsIG5ldHdvcmtzIHdoZXJlIGxvdHMgb2Ygd2ViZmluZ2VyIGRpc2Nv
dmVyaWVzIGNvdWxkIGhhcHBlbiBhY3Jvc3MgdXNlcnMgb24gZGlzdGluY3Qgc29jaWFsIG5ldHdv
cmtzIChlLmcuIHdoZW4gc3RhcnQgY3Jvc3MtZm9sbG93aW5nKS4gVGhhdCBlbWFpbCBzdWdnZXN0
ZWQgdGhlIHVzZSBvZiB0ZW1wbGF0ZXMgYW5kIG5ldyB0ZW1wbGF0ZSB2YXJpYWJsZXMsIHdoaWNo
IGlzIG5vdCBleGFjdGx5IHRoZSBzdWJqZWN0IGhlcmUsIGJ1dCB0aGUgbWFpbiBwb2ludCByZW1h
aW5zIGFuZCBhbGxvd2luZyBkb21haW4tb25seSBpZGVudGlmaWVycyBjb3VsZCBoZWxwIGluIHRo
YXQuDQpQb3RlbnRpYWxseSBhIHNlcnZlciAoa25vd2luZyBpbiBhZHZhbmNlIGl0IG1heSBkZWFs
IHdpdGggc2V2ZXJhbCB1c2VycyBvbiB0aGUgc2FtZSBmb3JlaWduIHNlcnZlcikgY291bGQgaXNz
dWUgYSB3ZWJmaW5nZXIgcXVlcnkgdG8gdGhlIHJlc291cmNlIGFjY3Q6ZXhhbXBsZS5jb20gaW5z
dGVhZCBvZiBhIHNwZWNpZmljIHVzZXIuIEkgd291bGQgZXhwZWN0IGEgZGlmZmVyZW5jZSB3cnQg
dG8gaXNzdWluZyBhIHB1cmUgaG9zdC1tZXRhIHF1ZXJ5IHdoZXJlIG9ubHkgYSBsaW1pdGVkIHN1
YnNldCBvZiBlbmRwb2ludHMvbGluayByZWxzIG1heSBiZSBwcm92aWRlZDogYnkgc3BlY2lmeWlu
ZyB0aGUgZG9tYWluLW9ubHkgcmVzb3VyY2UgZXhwbGljaXRseSBpdCB3b3VsZCBiZSB1bmRlcnN0
b29kIGFzIGEgMm5kIGxldmVsIHF1ZXJ5IChtZWFuaW5nIGV4dHJhY3RpbmcgdGhlIGxpbmsgcmVs
cyBwcm92aWRlZCBieSB0aGUgbHJkZCBkZXNjcmlwdG9yIHR5cGljYWxseSkgYW5kIHRodXMgY291
bGQgcHJvdmlkZSB0aGVzZSBhZGRpdGlvbmFsIGxpbmtzLiBDb21iaW5lZCB3aXRoIHRlbXBsYXRl
cyAoaGVyZSB3ZSBjYW4gdGhlbiBkaXNjdXNzIG9uIHRoZSByZXNlcnZlZCB0ZW1wbGF0ZSBwYXJh
bWV0ZXIgbmFtZXMpIGl0IGNvdWxkIGJlY29tZSBhIHBvd2VyZnVsIG1lY2hhbmlzbSB0byByZXRy
aWV2ZSB0ZW1wbGF0ZS1iYXNlZCBlbmRwb2ludHMgdGhhdCBjb3VsZCBiZSB2YWxpZCBmb3IgYWxs
IHVzZXJzIG9uIHRoYXQgc2VydmVyL2RvbWFpbiwgdGh1cyByZWR1Y2luZyB0aGUgbnVtYmVyIG9m
IHdmIHF1ZXJpZXMgZm9yIGRpc3RpbmN0IHVzZXJzIG9uIHRoZSBzYW1lIGZvcmVpZ24gc2VydmVy
LiBJbiBjYXNlIHNvbWUgbGluayByZWxzIGRvIG5vdCBmb2xsb3cgYSBzcGVjaWZpYyBwYXR0ZXJu
IGFuZCBhcmUgbW9yZSBjb21wbGV4IHRoZXkgY291bGQgc2ltcGx5IG5vdCBiZSByZXR1cm5lZCBp
biB0aGF0IHR5cGUgb2YgeHJkL2pyZCwgYW5kIHRoZSBzZXJ2ZXIgd291bGQgbmVlZCB0byBpc3N1
ZSBhIHVzZXItc3BlY2lmaWMgcXVlcnkgdG8gcmV0cmlldmUgZXh0cmEgbGluayByZWxzIGlmIG5l
ZWRlZC4NCg0KSGVyZSBpcyBhbiBleGFtcGxlOg0KR0VUIC8ud2VsbC1rbm93bi9ob3N0LW1ldGEu
anNvbj9yZXNvdXJjZT1hY2N0OmV4YW1wbGUuY29tIEhUVFAvMS4xDQpIb3N0OiBleGFtcGxlLmNv
bQ0KDQpUaGUgcmVwbHkgbWlnaHQgaGF2ZSB0aGlzIGJvZHkgKHVzaW5nIGEgZmljdGl0aW91cyAi
e3VyaS51c2VycGFydH0iIHRvIHJlcHJlc2VudCBvbmx5IHRoZSB1c2VyLXBhcnQgb2YgdGhlIGFj
Y3Q6IFVSSSk6DQoNCnsNCiAgInN1YmplY3QiIDogImFjY3Q6ZXhhbXBsZS5jb20iLA0KICAibGlu
a3MiIDoNCiAgWw0KICAgIHsNCiAgICAgICJyZWwiIDogImh0dHA6Ly93ZWJmaW5nZXIubmV0L3Jl
bC9hdmF0YXIiLA0KICAgICAgInRlbXBsYXRlIiA6ICJodHRwOi8vd3d3LmV4YW1wbGUuY29tL3Bl
b3BsZS97dXJpfS9pbWFnZXMve3VyaS51c2VycGFydH0uanBnIg0KICAgIH0sDQogICAgew0KICAg
ICAgInJlbCIgOiAiaHR0cDovL3dlYmZpbmdlci5uZXQvcmVsL3Byb2ZpbGUtcGFnZSIsDQogICAg
ICAidGVtcGxhdGUiIDogImh0dHA6Ly93d3cuZXhhbXBsZS5jb20vcGVvcGxlL3t1cml9Ig0KICAg
IH0sDQogICAgew0KICAgICAgInJlbCIgOiAiaHR0cDovL3NjaGVtYXMuZ29vZ2xlLmNvbS9nLzIw
MTAjdXBkYXRlcy1mcm9tIiwNCiAgICAgICJ0ZW1wbGF0ZSIgOiAiaHR0cDovL3d3dy5leGFtcGxl
LmNvbS9wZW9wbGUve3VyaX0vYmxvZy9ibG9nLnhtbCINCiAgICB9DQogIF0NCn0NCg0Kd2FsdGVy
DQoNClsxXSBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYXBwcy1kaXNjdXNz
L2N1cnJlbnQvbXNnMDYwNzMuaHRtbA0KDQo+DQo+ID4NCj4gPiA+IE9uIHRoYXQgdGhyZWFkIHNv
bWVvbmUgYWxzbyBtZW50aW9uZWQgdGhhdCBpbiB4bXBwIHJlYWxtDQo+ID4gPiBAZG9tYWluLnRs
ZCBtYWtlcyBhIHZhbGlkIGppZCBidXQgaSBoYXZlbid0IHJlc2VhcmNoIGl0IGZ1cnRoZXIgeWV0
DQo+ID4gPiA6KA0KPiA+DQo+ID4gWW91IGNhbiBoYXZlIHhtcHA6ZG9tYWluLnRsZCAodGhlIGFk
ZHJlc3Mgb2YgYSBzZXJ2ZXIpLCBidXQgeW91IGNhbid0DQo+ID4gaGF2ZSB4bXBwOkBkb21haW4u
dGxkIChzb21lIHNvcnQgb2YgY2F0Y2gtYWxsIGZvciBhbGwgYWNjb3VudHMgYXQgdGhlDQo+ID4g
c2VydmVyPz8pLg0KPiBUaGFua3MgZm9yIGNsYXJpZnlpbmcsIGFsc28gYWNjdDpkb21haW4udGxk
IGxvb2tzIGFsc28gc29tZWhvdyBtb3JlIHNhbmUgdGhhbg0KPiBhY2N0OkBkb21haW4udGxkIDop
DQo+DQo+ID4NCj4gPiBQZXRlcg0KPiA+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+IGFwcHMtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCj4gYXBwcy1k
aXNjdXNzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
YXBwcy1kaXNjdXNzDQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBp
bmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1
c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29u
b3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRl
LiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNp
ZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25l
IGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3Jhemll
Lg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQg
bWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJl
c3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkg
YW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk
IHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50
cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KDQo=

From ve7jtb@ve7jtb.com  Wed Aug 29 07:15:29 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2394821F857A for ; Wed, 29 Aug 2012 07:15:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.499
X-Spam-Level: 
X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.099,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqhDCpjzhH6z for ; Wed, 29 Aug 2012 07:15:27 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id F02B721F853E for ; Wed, 29 Aug 2012 07:15:26 -0700 (PDT)
Received: by qcac10 with SMTP id c10so450342qca.31 for ; Wed, 29 Aug 2012 07:15:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=vkfrxzenizZpRD0zfO8lODVNaLiX1sbiJdl434IQvHI=; b=YPC53EhFlDIT11XfKnKbK1iGSni4073QSE9QWMglPNmzAR7Y3OC4CpdSTyBqDencb8 7jPXWJQ2Dry+kvLhIv+epwuDAUmHGIHQYr2uyNvSwlU0TiE2KxCK1xFTFnJTuWnLPDVf W+iO03i2d2C2ewrWhSi8wqr22xq/xMyEyJJ0EXMGYZverqnPQKbv96e0NuiVUCjxOIXK H4pzvLy4dx7EXseZMg9H62gxDLDnSVPJv5Sk2Hwy6JNf88htZDWhknhwsd+wqX3IEFls TexMSNdZl9VLifcN/lV1ULs7WFz7onxE+nVKVyJ1GKSHoc8Qd8f+IWbh3dhxe8rqTW3h RK8g==
Received: by 10.229.137.20 with SMTP id u20mr885280qct.84.1346249725618; Wed, 29 Aug 2012 07:15:25 -0700 (PDT)
Received: from [192.168.1.211] (190-20-54-75.baf.movistar.cl. [190.20.54.75]) by mx.google.com with ESMTPS id gd3sm14856085qab.13.2012.08.29.07.14.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Aug 2012 07:15:23 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_594B7F2C-5BF8-40F6-A00A-CAA698CE5235"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
From: John Bradley 
In-Reply-To: <032d01cd8597$aac7f740$0057e5c0$@packetizer.com>
Date: Wed, 29 Aug 2012 10:14:23 -0400
Message-Id: 
References:  <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com>   <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com>      <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net>  <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com> <032d01cd8597$aac7f740$0057e5c0$@packetizer.com>
To: "Paul E. Jones" 
X-Mailer: Apple Mail (2.1486)
X-Gm-Message-State: ALoCoQnG3DEnNV0E2ISzJi+3c6shfCjbfDDeoOHfwj1XfVXGCBUiW+w5Z2C8amMr5dZ/5SqORnSD
Cc: 'Mark Nottingham' , 'IETF Apps Discuss' 
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Aug 2012 14:15:29 -0000

--Apple-Mail=_594B7F2C-5BF8-40F6-A00A-CAA698CE5235
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_F1E3289D-1FC1-43FE-BBD2-CDA9DC5F43CD"


--Apple-Mail=_F1E3289D-1FC1-43FE-BBD2-CDA9DC5F43CD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

There mite be a A record but that typically goes off to some virtual web =
hosting company and not the email service provider.

I think I have also heard William say this is a problem for Yahoo.

Google was not able to get people to deploy XRDS for hosted domains.   =
They came up with a proprietary extension to openID discovery to make =
hosted google apps domains work with some subset of RP.

The problem is that the company hosting a small businesses website is =
unlikely to provide the web finger infrastructure and there is no way =
for the email/openID provider to do it without their cooperation.

Adding a A record rather than a CNAME is generally not a good idea if it =
can be avoided.   In the event of the provider changing an IP address it =
breaks all the customers if they have used A records, but that is =
separate issue. =20

You can set up webfinger on your web server and manage it.   It just =
won't work for large numbers of people as we have it now. =20

If webfinger won't work for Google Apps for Domains and other hosted =
services like that then It will significantly impact adoption in my =
opinion.

We will also need to work around that for Connect.  We don't want =
another proprietary work around with the security problems that can =
entail.

John B.

On 2012-08-28, at 11:37 PM, "Paul E. Jones"  =
wrote:

> John,
> =20
> If Google is hosting the domain or any other service provider, =
wouldn=92t there still be an A record for the domain =
(e.g.,packetizer.com)?  I know there is for virtually every web hosting =
company I=92ve used.  It seems like this might just be one more hosted =
service Google could provide to its customers, no?
> =20
> I do not know exactly how this hosted service works, but what=92s =
hosted?  I assume it=92s just email.  If web, then I see no issue.  If =
only email, then the user just needs to have MX records pointing to =
Google and an A record pointing to whatever service runs the WebFinger =
service.
> =20
> In any case, if they can add a CNAME or MX record, I think we can get =
them to add an A record.  I think it would be far more challenging for =
SMBs to add a host like webfinger.example.com.  That would still require =
an A record and a service provider capable of supporting it.
> =20
> Paul
> =20
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
> Sent: Tuesday, August 28, 2012 3:29 PM
> To: Paul E. Jones
> Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
> Subject: Re: [apps-discuss] Looking at Webfinger
> =20
> There are cases where there are hosted domains (Google etc) that may =
not have a http host for the domain name used in the users email =
address. =20
> =20
> There may be merit to having a webfinger.example.com fallback where =
the client can't reach the .well-known for the primary host.
> =20
> I know that some sort of SRV record would be the correct way to do it, =
but in the real world SMB don't enter SRV records even if there DNS =
provider support them.
> The most you can get them to do is add a CNAME or MX record.
> =20
> Supporting these sorts of domains somehow is a important issue.
> =20
> John B.
> =20
> On 2012-08-28, at 3:17 PM, "Paul E. Jones"  =
wrote:
>=20
>=20
> George,
> =20
> I believe it might be useful to introduce those who break your =
WebFinger server to Louisville Slugger. :)
> =20
> Your pain is understood, but I do not see a way to avoid it.  We could =
introduce something in DNS, but that would also present challenges.  No =
matter where we =93root=94 the discovery process, there is a potential =
somebody could break it.  It could be rooted somewhere other than the =
root of the domain (e.g., webfinger.example.com), but we either need to =
decide in advance of such a location or introduce a way to discovery the =
discovery resources.
> =20
> Do you have a suggestion that would make this less likely to be =
broken?
> =20
> Paul
> =20
> From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of George Fletcher
> Sent: Tuesday, August 28, 2012 11:09 AM
> To: Mark Nottingham
> Cc: IETF Apps Discuss
> Subject: Re: [apps-discuss] Looking at Webfinger
> =20
> Way "late to the party" but I can speak from experience that =
deployment can be a real issue in some environments. It's all really =
straight forward in a small company or an environment where the identity =
team "owns" the root domain (e.g. example.com). However, if an entire =
other group in a large organization "owns" the root domain (home page =
for the site) and the identity team then needs to get them to make =
changes, the deployment solution gets brittle pretty quick. I've had our =
webfinger support broken at least twice because the "other" team didn't =
know that certain configs were required:)
>=20
> Also, installing the "dynamic pluming" can be more problematic is =
these cases. It is possible to get apache rewrite rules or netscaler =
magic in place to make it work, it's just a more brittle deployment =
architecture.
>=20
> Thanks,
> George
>=20
> On 7/4/12 6:58 PM, John Panzer wrote:
> Mark -- Of course I was speaking about practical realities of typical =
web server administration and deployment.  In practical terms, adding a =
new mod_rewrite rule or moral equivalent is going to be easier than =
adding a new PHP script that connects to a database.  The latter is just =
always going to be a much higher bar.
> =20
> And, something that returns per-user data is generally going to need a =
dynamic service of some kind, unless your site has just a handful of =
users and you don't mind going through a publishing exercise each time =
you add or change a user...
> =20
> None of this has anything to do with the interface, just deployment =
realities.  And in reality all of this is going to need a dynamic =
service somewhere for each non-trivial site, this is all just a question =
of how to hook it up.
>=20
> --
> John Panzer / Google
> jpanzer@google.com / abstractioneer.org / @jpanzer
> =20
> =20
>=20
> On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham  wrote:
> On 05/07/2012, at 8:16 AM, John Panzer wrote:
>=20
> > Just as a historical note.  The envisioned usage of host-meta was =
originally to avoid a specification which mandated a particular dynamic =
URL API at a particular /.well-known endpoint (because it may not be =
feasible to do that across all organizations and deployments).  The =
host-meta document itself would be highly cacheable and so wouldn't =
incur an additional network trip in the common case.
> >
> > Having a 3xx redirect is a reasonable alternative that allows a =
similar escape hatch via something like mod_rewrite, albeit at the cost =
of needing an additional network trip each time.  Since a deployment can =
always avoid the 3xx redirect with additional dynamic plumbing behind =
the well-known endpoint, I don't think that's a horrible thing.
> >
> > An application-level redirect would be almost equivalent to an HTTP =
redirect, but then there are two ways to do the same thing.  If _only_ =
an application-level redirect is allowed, then you have to have at least =
a minimal dynamic service at the well-known endpoint (no more =
mod_rewrite).  But the whole reason for this is to avoid the requirement =
for a dynamic service behind well-known...
>=20
> "dynamic" and "static" are properties of the implementation, not the =
interface. HTTP doesn't require that any particular URL be "dynamic"; =
anything can, with the right metadata, be cached (and indeed, I've =
cached many, many things with the wrong metadata, because of silly site =
operators and their ideas about "dynamic").
>=20
> Now, if people want to target a particular implementation that makes =
it easier to serve a particular style of URL without writing code, fine, =
but let's not confuse things.
>=20
> E.g., a URL like
>=20
> http://example.com/.well-known/user/bob
>=20
> is easy to serve in pretty much any way you like with Apache.
>=20
> I'm also going to push back on the "it may not be feasible to do that =
across all organizations and deployments" motivation. This is a race to =
the bottom. The trick is to make it accessible enough to get sufficient =
traction to pull everyone along, without pandering to *everyone*'s =
requirements.
>=20
> Regards,
>=20
> --
> Mark Nottingham   http://www.mnot.net/
>=20
>=20
>=20
>=20
> =20
>=20
>=20
>=20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> =20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


--Apple-Mail=_F1E3289D-1FC1-43FE-BBD2-CDA9DC5F43CD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

There =
mite be a A record but that typically goes off to some virtual web =
hosting company and not the email service provider.

I =
think I have also heard William say this is a problem for =
Yahoo.

Google was not able to get people to =
deploy XRDS for hosted domains.   They came up with a proprietary =
extension to openID discovery to make hosted google apps domains work =
with some subset of RP.

The problem is that the =
company hosting a small businesses website is unlikely to provide the =
web finger infrastructure and there is no way for the email/openID =
provider to do it without their =
cooperation.

Adding a A record rather than a =
CNAME is generally not a good idea if it can be avoided.   In the =
event of the provider changing an IP address it breaks all the customers =
if they have used A records, but that is separate issue. =
 

You can set up webfinger on your web =
server and manage it.   It just won't work for large numbers of =
people as we have it now.  

If webfinger =
won't work for Google Apps for Domains and other hosted services like =
that then It will significantly impact adoption in my =
opinion.

We will also need to work around that =
for Connect.  We don't want another proprietary work around with =
the security problems that can entail.

John =
B.

On 2012-08-28, at 11:37 PM, "Paul E. Jones" =
<paulej@packetizer.com>=
 wrote:

 
If Google is hosting the domain or any other =
service provider, wouldn=92t there still be an A record for the domain =
(e.g.,packetizer.com)?  I know there is =
for virtually every web hosting company I=92ve used.  It seems like =
this might just be one more hosted service Google could provide to its =
customers, no?
 
I do not know exactly how this hosted service =
works, but what=92s hosted?  I assume it=92s just email.  If =
web, then I see no issue.  If only email, then the user just needs =
to have MX records pointing to Google and an A record pointing to =
whatever service runs the WebFinger service.
 
In any case, if they can =
add a CNAME or MX record, I think we can get them to add an A =
record.  I think it would be far more challenging for SMBs to add a =
host like webfinger.example.com.  That =
would still require an A record and a service provider capable of =
supporting it.
 
Paul
 
From: John Bradley =
[mailto:ve7jtb@ve7jtb.com] 
Sent: Tuesday, August 28, 2012 =
3:29 PM
To: Paul E. =
Jones
Cc: 'George Fletcher'; 'Mark =
Nottingham'; 'IETF Apps Discuss'
Subject: Re: [apps-discuss] Looking =
at Webfinger
 
There are =
cases where there are hosted domains (Google etc) that may not have a =
http host for the domain name used in the users email address. =
 
 webfinger.example.com fallback where the client =
can't reach the .well-known for the primary =
host.
I =
know that some sort of SRV record would be the correct way to do it, but =
in the real world SMB don't enter SRV records even if there DNS provider =
support them.
The =
most you can get them to do is add a CNAME or MX =
record.
John =
B.
paulej@packetizer.com> =
wrote:
 
I believe it might be =
useful to introduce those who break your WebFinger server to Louisville =
Slugger. :)
 
Your pain is understood, =
but I do not see a way to avoid it.  We could introduce something =
in DNS, but that would also present challenges.  No matter where we =
=93root=94 the discovery process, there is a potential somebody could =
break it.  It could be rooted somewhere other than the root of the =
domain (e.g.,  
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of George =
Fletcher
Sent: Tuesday, August 28, 2012 =
11:09 AM
To: Mark =
Nottingham
Cc: IETF Apps =
Discuss
Subject: Re: [apps-discuss] Looking =
at Webfinger
 
 example.com). However, if an entire other group in a =
large organization "owns" the root domain (home page for the site) and =
the identity team then needs to get them to make changes, the deployment =
solution gets brittle pretty quick. I've had our webfinger support =
broken at least twice because the "other" team didn't know that certain =
configs were required:)

Also, installing the "dynamic pluming" =
can be more problematic is these cases. It is possible to get apache =
rewrite rules or netscaler magic in place to make it work, it's just a =
more brittle deployment =
architecture.

Thanks,
George
On 7/4/12 6:58 PM, John Panzer =
wrote:
Mark -- Of =
course I was speaking about practical realities of typical web server =
administration and deployment.  In practical terms, adding a new =
mod_rewrite rule or moral equivalent is going to be easier than adding a =
new PHP script that connects to a database.  The latter is just =
always going to be a much higher bar.
 
And, something that returns per-user data is =
generally going to need a dynamic service of some kind, unless your site =
has just a handful of users and you don't mind going through a =
publishing exercise each time you add or change a =
user...
None =
of this has anything to do with the interface, just deployment =
realities.  And in reality all of this is going to need a dynamic =
service somewhere for each non-trivial site, this is all just a question =
of how to hook it up.

--
John Panzer / Google
 /  / =
@jpanzer
 
On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham <On 05/07/2012, at 8:16 AM, John =
Panzer wrote:

> Just as a historical note.  The =
envisioned usage of host-meta was originally to avoid a specification =
which mandated a particular dynamic URL API at a particular /.well-known =
endpoint (because it may not be feasible to do that across all =
organizations and deployments).  The host-meta document itself =
would be highly cacheable and so wouldn't incur an additional network =
trip in the common case.
>
> Having a 3xx redirect is a =
reasonable alternative that allows a similar escape hatch via something =
like mod_rewrite, albeit at the cost of needing an additional network =
trip each time.  Since a deployment can always avoid the 3xx =
redirect with additional dynamic plumbing behind the well-known =
endpoint, I don't think that's a horrible thing.
>
> An =
application-level redirect would be almost equivalent to an HTTP =
redirect, but then there are two ways to do the same thing.  If =
_only_ an application-level redirect is allowed, then you have to have =
at least a minimal dynamic service at the well-known endpoint (no more =
mod_rewrite).  But the whole reason for this is to avoid the =
requirement for a dynamic service behind =
well-known...

--
Mark Nottingham =
  apps-discuss mailing list
apps-discuss@ietf.org

References: 	<4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com>			<44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com>						<35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net>	 <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com>
In-Reply-To: <02a301cd8551$be7ab390$3b701ab0$@packetizer.com>
Content-Type: multipart/alternative; boundary="------------090807020002030003070302"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1346254675; bh=6as3WZWQ19r9VeFN0+ylvyUIsr3oeEP5a4rFIw5pHlI=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=PqGIVrQL7xVgEhCiXfawvM4hDr5NoMwFURqKL9YP2C72FsTV4iFnNsEabywy35FU8 u1AAqcYFLW1xLn17gLThZi/oDnC23Do5+w6QxZ7uq6KRFfNXs0qrd9bBTsAgHEgskf QhE0iYZNlkCVY+DKyUPu0quSvKjQBNFYUo6GxFyQ=
X-AOL-SCOLL-SCORE: 1:2:491361152:93952408  
X-AOL-SCOLL-URL_COUNT: 1  
x-aol-sid: 3039ac1d2904503e375326c6
X-AOL-IP: 10.181.186.254
Cc: 'Mark Nottingham' , 'IETF Apps Discuss' 
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Aug 2012 15:38:12 -0000

This is a multi-part message in MIME format.
--------------090807020002030003070302
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


On 8/28/12 3:17 PM, Paul E. Jones wrote:
>
> George,
>
> I believe it might be useful to introduce those who break your 
> WebFinger server to Louisville Slugger. :)
>
:)
>
> Your pain is understood, but I do not see a way to avoid it.  We could 
> introduce something in DNS, but that would also present challenges.  
> No matter where we "root" the discovery process, there is a potential 
> somebody could break it.  It could be rooted somewhere other than the 
> root of the domain (e.g., webfinger.example.com), but we either need 
> to decide in advance of such a location or introduce a way to 
> discovery the discovery resources.
>
> Do you have a suggestion that would make this less likely to be broken?
>
Well this is one reason I liked XRD and host-meta:) I could put one 
static file on the CDN and get it served up by the right domain. Not so 
difficult.

With Simple Web Discovery, there is support for a "global" redirect so I 
can again add yet another static file to the CDN to point the discovery 
service elsewhere. Not ideal but probably manageable.

However, making the .well-known URLs dynamic makes this more difficult. 
I suppose if I can some how ignore all the "per user" paths or query 
parameters and webfinger supports a global redirect for the domain, I 
can probably use my Louisville Slugger to get it to stick:)

Thanks,
George
>
> Paul
>
> *From:*apps-discuss-bounces@ietf.org 
> [mailto:apps-discuss-bounces@ietf.org] *On Behalf Of *George Fletcher
> *Sent:* Tuesday, August 28, 2012 11:09 AM
> *To:* Mark Nottingham
> *Cc:* IETF Apps Discuss
> *Subject:* Re: [apps-discuss] Looking at Webfinger
>
> Way "late to the party" but I can speak from experience that 
> deployment can be a real issue in some environments. It's all really 
> straight forward in a small company or an environment where the 
> identity team "owns" the root domain (e.g. example.com). However, if 
> an entire other group in a large organization "owns" the root domain 
> (home page for the site) and the identity team then needs to get them 
> to make changes, the deployment solution gets brittle pretty quick. 
> I've had our webfinger support broken at least twice because the 
> "other" team didn't know that certain configs were required:)
>
> Also, installing the "dynamic pluming" can be more problematic is 
> these cases. It is possible to get apache rewrite rules or netscaler 
> magic in place to make it work, it's just a more brittle deployment 
> architecture.
>
> Thanks,
> George
>
> On 7/4/12 6:58 PM, John Panzer wrote:
>
>     Mark -- Of course I was speaking about practical realities of
>     typical web server administration and deployment.  In practical
>     terms, adding a new mod_rewrite rule or moral equivalent is going
>     to be easier than adding a new PHP script that connects to a
>     database.  The latter is just always going to be a much higher bar.
>
>     And, something that returns per-user data is generally going to
>     need a dynamic service of some kind, unless your site has just a
>     handful of users and you don't mind going through a publishing
>     exercise each time you add or change a user...
>
>     None of this has anything to do with the interface, just
>     deployment realities.  And in reality all of this is going to need
>     a dynamic service somewhere for each non-trivial site, this is all
>     just a question of how to hook it up.
>
>
>     --
>     John Panzer / Google
>     jpanzer@google.com  /
>     abstractioneer.org  / @jpanzer
>
>     On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham      > wrote:
>
>     On 05/07/2012, at 8:16 AM, John Panzer wrote:
>
>     > Just as a historical note.  The envisioned usage of host-meta
>     was originally to avoid a specification which mandated a
>     particular dynamic URL API at a particular /.well-known endpoint
>     (because it may not be feasible to do that across all
>     organizations and deployments).  The host-meta document itself
>     would be highly cacheable and so wouldn't incur an additional
>     network trip in the common case.
>     >
>     > Having a 3xx redirect is a reasonable alternative that allows a
>     similar escape hatch via something like mod_rewrite, albeit at the
>     cost of needing an additional network trip each time.  Since a
>     deployment can always avoid the 3xx redirect with additional
>     dynamic plumbing behind the well-known endpoint, I don't think
>     that's a horrible thing.
>     >
>     > An application-level redirect would be almost equivalent to an
>     HTTP redirect, but then there are two ways to do the same thing.
>      If _only_ an application-level redirect is allowed, then you have
>     to have at least a minimal dynamic service at the well-known
>     endpoint (no more mod_rewrite).  But the whole reason for this is
>     to avoid the requirement for a dynamic service behind well-known...
>
>     "dynamic" and "static" are properties of the implementation, not
>     the interface. HTTP doesn't require that any particular URL be
>     "dynamic"; anything can, with the right metadata, be cached (and
>     indeed, I've cached many, many things with the wrong metadata,
>     because of silly site operators and their ideas about "dynamic").
>
>     Now, if people want to target a particular implementation that
>     makes it easier to serve a particular style of URL without writing
>     code, fine, but let's not confuse things.
>
>     E.g., a URL like
>
>     http://example.com/.well-known/user/bob
>
>     is easy to serve in pretty much any way you like with Apache.
>
>     I'm also going to push back on the "it may not be feasible to do
>     that across all organizations and deployments" motivation. This is
>     a race to the bottom. The trick is to make it accessible enough to
>     get sufficient traction to pull everyone along, without pandering
>     to *everyone*'s requirements.
>
>     Regards,
>
>
>     --
>     Mark Nottingham http://www.mnot.net/
>
>
>
>
>
>     _______________________________________________
>
>     apps-discuss mailing list
>
>     apps-discuss@ietf.org  
>
>     https://www.ietf.org/mailman/listinfo/apps-discuss
>


--------------090807020002030003070302
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
On 8/28/12 3:17 PM, Paul E. Jones
      wrote:

    

    

      
      
      
      

        
George,

        
 

        
I
            believe it might be useful to introduce those who break your
            WebFinger server to Louisville Slugger. :)

      

    

    :)

    

      

        

        
 

        
Your
            pain is understood, but I do not see a way to avoid it.  We
            could introduce something in DNS, but that would also
            present challenges.  No matter where we “root” the discovery
            process, there is a potential somebody could break it.  It
            could be rooted somewhere other than the root of the domain
            (e.g., webfinger.example.com), but we either need to decide
            in advance of such a location or introduce a way to
            discovery the discovery resources.

        
 

        
Do
            you have a suggestion that would make this less likely to be
            broken?

      

    

    Well this is one reason I liked XRD and host-meta:) I could put one
    static file on the CDN and get it served up by the right domain. Not
    so difficult. 

    

    With Simple Web Discovery, there is support for a "global" redirect
    so I can again add yet another static file to the CDN to point the
    discovery service elsewhere. Not ideal but probably manageable.

    

    However, making the .well-known URLs dynamic makes this more
    difficult. I suppose if I can some how ignore all the "per user"
    paths or query parameters and webfinger supports a global redirect
    for the domain, I can probably use my Louisville Slugger to get it
    to stick:)

    

    Thanks,

    George

    

      

        

        
 

        
Paul

        
 

        

          

            

              
From:
                  apps-discuss-bounces@ietf.org
                  [mailto:apps-discuss-bounces@ietf.org] On Behalf
                    Of George Fletcher

                  Sent: Tuesday, August 28, 2012 11:09 AM

                  To: Mark Nottingham

                  Cc: IETF Apps Discuss

                  Subject: Re: [apps-discuss] Looking at
                  Webfinger

            

          

          
 

          
Way
              "late to the party" but I can speak from experience that
              deployment can be a real issue in some environments. It's
              all really straight forward in a small company or an
              environment where the identity team "owns" the root domain
              (e.g. example.com). However, if an entire other group in a
              large organization "owns" the root domain (home page for
              the site) and the identity team then needs to get them to
              make changes, the deployment solution gets brittle pretty
              quick. I've had our webfinger support broken at least
              twice because the "other" team didn't know that certain
              configs were required:)

              

              Also, installing the "dynamic pluming" can be more
              problematic is these cases. It is possible to get apache
              rewrite rules or netscaler magic in place to make it work,
              it's just a more brittle deployment architecture.

              

              Thanks,

              George

          

            
On 7/4/12 6:58 PM, John Panzer wrote:

          

          

            
Mark -- Of course I was speaking about
              practical realities of typical web server administration
              and deployment.  In practical terms, adding a new
              mod_rewrite rule or moral equivalent is going to be easier
              than adding a new PHP script that connects to a database.
               The latter is just always going to be a much higher bar.
              

            

              
 

            

            

              
And, something that returns per-user
                data is generally going to need a dynamic service of
                some kind, unless your site has just a handful of users
                and you don't mind going through a publishing exercise
                each time you add or change a user...

            

            

              
 

            

            

              
None of this has anything to do with
                the interface, just deployment realities.  And in
                reality all of this is going to need a dynamic service
                somewhere for each non-trivial site, this is all just a
                question of how to hook it up.

            

            


              

            

              
--

                John Panzer / Google

                jpanzer@google.com
                / abstractioneer.org
                / @jpanzer

            

            
 

            

              
 

              

                
On Wed, Jul 4, 2012 at 3:36 PM,
                  Mark Nottingham <mnot@mnot.net>
                  wrote:

                

                  
On
                    05/07/2012, at 8:16 AM, John Panzer wrote:

                    

                    > Just as a historical note.  The envisioned
                    usage of host-meta was originally to avoid a
                    specification which mandated a particular dynamic
                    URL API at a particular /.well-known endpoint
                    (because it may not be feasible to do that across
                    all organizations and deployments).  The host-meta
                    document itself would be highly cacheable and so
                    wouldn't incur an additional network trip in the
                    common case.

                    >

                    > Having a 3xx redirect is a reasonable
                    alternative that allows a similar escape hatch via
                    something like mod_rewrite, albeit at the cost of
                    needing an additional network trip each time.  Since
                    a deployment can always avoid the 3xx redirect with
                    additional dynamic plumbing behind the well-known
                    endpoint, I don't think that's a horrible thing.

                    >

                    > An application-level redirect would be almost
                    equivalent to an HTTP redirect, but then there are
                    two ways to do the same thing.  If _only_ an
                    application-level redirect is allowed, then you have
                    to have at least a minimal dynamic service at the
                    well-known endpoint (no more mod_rewrite).  But the
                    whole reason for this is to avoid the requirement
                    for a dynamic service behind well-known...

                

                
"dynamic" and "static" are
                  properties of the implementation, not the interface.
                  HTTP doesn't require that any particular URL be
                  "dynamic"; anything can, with the right metadata, be
                  cached (and indeed, I've cached many, many things with
                  the wrong metadata, because of silly site operators
                  and their ideas about "dynamic").

                  

                  Now, if people want to target a particular
                  implementation that makes it easier to serve a
                  particular style of URL without writing code, fine,
                  but let's not confuse things.

                  

                  E.g., a URL like

                  

                  http://example.com/.well-known/user/bob

                  

                  is easy to serve in pretty much any way you like with
                  Apache.

                  

                  I'm also going to push back on the "it may not be
                  feasible to do that across all organizations and
                  deployments" motivation. This is a race to the bottom.
                  The trick is to make it accessible enough to get
                  sufficient traction to pull everyone along, without
                  pandering to *everyone*'s requirements.

                  

                  Regards,

                

                  

                    


                      --

                      Mark Nottingham   http://www.mnot.net/

                      

                      

                      

                  

                

              

              
 

            

            


              

              

              

            
_______________________________________________

            
apps-discuss mailing list

            
apps-discuss@ietf.org

            
https://www.ietf.org/mailman/listinfo/apps-discuss

          

          
 

        

      

    

    

  


--------------090807020002030003070302--

From paulej@packetizer.com  Wed Aug 29 10:36:32 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2652111E80E0 for ; Wed, 29 Aug 2012 10:36:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.509
X-Spam-Level: 
X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.089,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPdrikvS3D65 for ; Wed, 29 Aug 2012 10:36:26 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 21BE821F8671 for ; Wed, 29 Aug 2012 10:36:26 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q7THaKaP032600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Aug 2012 13:36:20 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1346261781; bh=33rlcZM/Nt404drriuUPZWs9Zr3il2ygCyt7DVSlTqU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=JOqhjBcDQp3s1IvMBjhhc5VPyq3gevMByIXK7LDiItJ5T9IlGv1rRWueoCx05mrEl 9T0IINeExjCAMghOiQyKvvjASOIUajNnGp4rueyUmv9s5NrCCl8osXVJ0scryc3Ema ISTfDjYiE0JChHGlst0pP3vQNkClbB0Hir4v9fdU=
From: "Paul E. Jones" 
To: "'John Bradley'" 
References:  <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com>   <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com>      <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net>  <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com> <032d01cd8597$aac7f740$0057e5c0$@packetizer.com> 
In-Reply-To: 
Date: Wed, 29 Aug 2012 13:36:41 -0400
Message-ID: <046501cd860c$da464420$8ed2cc60$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0466_01CD85EB.53371520"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFb3Wt68HpLZ7ZyHnoKMrZHlzcyBQH14U4xAZ6Br/cCWNrQtwIOUYf2AgMXr+8B4HmqlgGhGIVxAUAhVLECgOqLOADUaqV0Ain7f7cBffnLSQIkbXUiAp1soAQC/kiSjgJH/Vmml1YsdpA=
Content-Language: en-us
Cc: 'Mark Nottingham' , 'IETF Apps Discuss' 
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Aug 2012 17:36:32 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0466_01CD85EB.53371520
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

John,

 

Well, we need to figure out how to address this.

 

Would it be reasonable to redirect requests from /.well-known/host-meta.json
and /.well-known/host-meta to Google?

 

Are there other services or files under /.well-known that Google's customers
would not want Google to host?  If they were OK with Google's servers
responding to anything , then one could put an A (or CNAME) record in place
for example.com that points to Google.

 

Not being familiar with what Google offers, I'm a bit challenged to
understand exactly what is and is not possible.

 

Paul

 

From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, August 29, 2012 10:14 AM
To: Paul E. Jones
Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
Subject: Re: [apps-discuss] Looking at Webfinger

 

There mite be a A record but that typically goes off to some virtual web
hosting company and not the email service provider.

 

I think I have also heard William say this is a problem for Yahoo.

 

Google was not able to get people to deploy XRDS for hosted domains.   They
came up with a proprietary extension to openID discovery to make hosted
google apps domains work with some subset of RP.

 

The problem is that the company hosting a small businesses website is
unlikely to provide the web finger infrastructure and there is no way for
the email/openID provider to do it without their cooperation.

 

Adding a A record rather than a CNAME is generally not a good idea if it can
be avoided.   In the event of the provider changing an IP address it breaks
all the customers if they have used A records, but that is separate issue.  

 

You can set up webfinger on your web server and manage it.   It just won't
work for large numbers of people as we have it now.  

 

If webfinger won't work for Google Apps for Domains and other hosted
services like that then It will significantly impact adoption in my opinion.

 

We will also need to work around that for Connect.  We don't want another
proprietary work around with the security problems that can entail.

 

John B.

 

On 2012-08-28, at 11:37 PM, "Paul E. Jones"  wrote:





John,

 

If Google is hosting the domain or any other service provider, wouldn't
there still be an A record for the domain (e.g., 
packetizer.com)?  I know there is for virtually every web hosting company
I've used.  It seems like this might just be one more hosted service Google
could provide to its customers, no?

 

I do not know exactly how this hosted service works, but what's hosted?  I
assume it's just email.  If web, then I see no issue.  If only email, then
the user just needs to have MX records pointing to Google and an A record
pointing to whatever service runs the WebFinger service.

 

In any case, if they can add a CNAME or MX record, I think we can get them
to add an A record.  I think it would be far more challenging for SMBs to
add a host like   webfinger.example.com.  That
would still require an A record and a service provider capable of supporting
it.

 

Paul

 

From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Tuesday, August 28, 2012 3:29 PM
To: Paul E. Jones
Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
Subject: Re: [apps-discuss] Looking at Webfinger

 

There are cases where there are hosted domains (Google etc) that may not
have a http host for the domain name used in the users email address.  

 

There may be merit to having a  
webfinger.example.com fallback where the client can't reach the .well-known
for the primary host.

 

I know that some sort of SRV record would be the correct way to do it, but
in the real world SMB don't enter SRV records even if there DNS provider
support them.

The most you can get them to do is add a CNAME or MX record.

 

Supporting these sorts of domains somehow is a important issue.

 

John B.

 

On 2012-08-28, at 3:17 PM, "Paul E. Jones" < 
paulej@packetizer.com> wrote:






George,

 

I believe it might be useful to introduce those who break your WebFinger
server to Louisville Slugger. :)

 

Your pain is understood, but I do not see a way to avoid it.  We could
introduce something in DNS, but that would also present challenges.  No
matter where we "root" the discovery process, there is a potential somebody
could break it.  It could be rooted somewhere other than the root of the
domain (e.g.,   webfinger.example.com), but we
either need to decide in advance of such a location or introduce a way to
discovery the discovery resources.

 

Do you have a suggestion that would make this less likely to be broken?

 

Paul

 

From:   apps-discuss-bounces@ietf.org
[mailto:apps-  discuss-bounces@ietf.org] On
Behalf Of George Fletcher
Sent: Tuesday, August 28, 2012 11:09 AM
To: Mark Nottingham
Cc: IETF Apps Discuss
Subject: Re: [apps-discuss] Looking at Webfinger

 

Way "late to the party" but I can speak from experience that deployment can
be a real issue in some environments. It's all really straight forward in a
small company or an environment where the identity team "owns" the root
domain (e.g.   example.com). However, if an entire other
group in a large organization "owns" the root domain (home page for the
site) and the identity team then needs to get them to make changes, the
deployment solution gets brittle pretty quick. I've had our webfinger
support broken at least twice because the "other" team didn't know that
certain configs were required:)

Also, installing the "dynamic pluming" can be more problematic is these
cases. It is possible to get apache rewrite rules or netscaler magic in
place to make it work, it's just a more brittle deployment architecture.

Thanks,
George

On 7/4/12 6:58 PM, John Panzer wrote:

Mark -- Of course I was speaking about practical realities of typical web
server administration and deployment.  In practical terms, adding a new
mod_rewrite rule or moral equivalent is going to be easier than adding a new
PHP script that connects to a database.  The latter is just always going to
be a much higher bar.

 

And, something that returns per-user data is generally going to need a
dynamic service of some kind, unless your site has just a handful of users
and you don't mind going through a publishing exercise each time you add or
change a user...

 

None of this has anything to do with the interface, just deployment
realities.  And in reality all of this is going to need a dynamic service
somewhere for each non-trivial site, this is all just a question of how to
hook it up.




--
John Panzer / Google
  jpanzer@google.com /
 abstractioneer.org / @jpanzer

 

 

On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham < 
mnot@mnot.net> wrote:

On 05/07/2012, at 8:16 AM, John Panzer wrote:

> Just as a historical note.  The envisioned usage of host-meta was
originally to avoid a specification which mandated a particular dynamic URL
API at a particular /.well-known endpoint (because it may not be feasible to
do that across all organizations and deployments).  The host-meta document
itself would be highly cacheable and so wouldn't incur an additional network
trip in the common case.
>
> Having a 3xx redirect is a reasonable alternative that allows a similar
escape hatch via something like mod_rewrite, albeit at the cost of needing
an additional network trip each time.  Since a deployment can always avoid
the 3xx redirect with additional dynamic plumbing behind the well-known
endpoint, I don't think that's a horrible thing.
>
> An application-level redirect would be almost equivalent to an HTTP
redirect, but then there are two ways to do the same thing.  If _only_ an
application-level redirect is allowed, then you have to have at least a
minimal dynamic service at the well-known endpoint (no more mod_rewrite).
But the whole reason for this is to avoid the requirement for a dynamic
service behind well-known...

"dynamic" and "static" are properties of the implementation, not the
interface. HTTP doesn't require that any particular URL be "dynamic";
anything can, with the right metadata, be cached (and indeed, I've cached
many, many things with the wrong metadata, because of silly site operators
and their ideas about "dynamic").

Now, if people want to target a particular implementation that makes it
easier to serve a particular style of URL without writing code, fine, but
let's not confuse things.

E.g., a URL like

 
http://example.com/.well-known/user/bob

is easy to serve in pretty much any way you like with Apache.

I'm also going to push back on the "it may not be feasible to do that across
all organizations and deployments" motivation. This is a race to the bottom.
The trick is to make it accessible enough to get sufficient traction to pull
everyone along, without pandering to *everyone*'s requirements.

Regards,


--
Mark Nottingham     http://www.mnot.net/






 








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

 

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

 


------=_NextPart_000_0466_01CD85EB.53371520
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


John,
 
Well, we need to figure out how to address =
this.
 
Would it be reasonable to redirect requests from =
/.well-known/host-meta.json and /.well-known/host-meta to =
Google?
 
Are there other services or files under /.well-known that =
Google’s customers would not want Google to host?  If they =
were OK with Google’s servers responding to anything , then one =
could put an A (or CNAME) record in place for example.com that points to =
Google.
 
Not being familiar with what Google offers, I’m a bit =
challenged to understand exactly what is and is not =
possible.
 
Paul
 
From:=
 =
John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, =
August 29, 2012 10:14 AM
To: Paul E. Jones
Cc: =
'George Fletcher'; 'Mark Nottingham'; 'IETF Apps =
Discuss'
Subject: Re: [apps-discuss] Looking at =
Webfinger
 
There mite =
be a A record but that typically goes off to some virtual web hosting =
company and not the email service provider.
 
I =
think I have also heard William say this is a problem for =
Yahoo.
 
Google was not able to get people to deploy XRDS for =
hosted domains.   They came up with a proprietary extension to =
openID discovery to make hosted google apps domains work with some =
subset of RP.
 
The problem is that the company hosting a small =
businesses website is unlikely to provide the web finger infrastructure =
and there is no way for the email/openID provider to do it without their =
cooperation.
 
Adding a A record rather than a CNAME is generally not =
a good idea if it can be avoided.   In the event of the provider =
changing an IP address it breaks all the customers if they have used A =
records, but that is separate issue.  
 
You can set up webfinger on your web server and manage =
it.   It just won't work for large numbers of people as we have it =
now.  
 
If webfinger won't work for Google Apps for Domains =
and other hosted services like that then It will significantly impact =
adoption in my opinion.
 
We will also need to work around that for Connect. =
 We don't want another proprietary work around with the security =
problems that can entail.
 
John B.
 
On =
2012-08-28, at 11:37 PM, "Paul E. Jones" <paulej@packetizer.com> =
wrote:


John,
 
If Google is hosting the domain or any other service provider, =
wouldn’t there still be an A record for the domain (e.g.,packetizer.com)?  I know there is =
for virtually every web hosting company I’ve used.  It seems =
like this might just be one more hosted service Google could provide to =
its customers, no?
 
I do not know exactly how this hosted service works, but what’s =
hosted?  I assume it’s just email.  If web, then I see =
no issue.  If only email, then the user just needs to have MX =
records pointing to Google and an A record pointing to whatever service =
runs the WebFinger service.
 
In any case, if they can add a CNAME or MX record, I think we can get =
them to add an A record.  I think it would be far more challenging =
for SMBs to add a host like webfinger.example.com.  That =
would still require an A record and a service provider capable of =
supporting it.
 
Paul
 
From:=
 John =
Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Tuesday, August 28, 2012 3:29 =
PM
To: Paul E. =
Jones
Cc: 'George Fletcher'; 'Mark =
Nottingham'; 'IETF Apps Discuss'
Subject: Re: [apps-discuss] Looking at =
Webfinger
 
There are cases where there are hosted domains (Google =
etc) that may not have a http host for the domain name used in the users =
email address.  
 
There may be merit to having a webfinger.example.com fallback where the client =
can't reach the .well-known for the primary =
host.
 
I know that some sort of SRV record would be the =
correct way to do it, but in the real world SMB don't enter SRV records =
even if there DNS provider support =
them.
The most =
you can get them to do is add a CNAME or MX =
record.
 
Supporting these sorts of domains somehow is a =
important issue.
 
John B.
 
On 2012-08-28, at 3:17 PM, "Paul E. Jones" =
<paulej@packetizer.com> =
wrote:



George,
 
I believe it might be useful to introduce those who break your =
WebFinger server to Louisville Slugger. =
:)
 
Your pain is understood, but I do not see a way to avoid it.  We =
could introduce something in DNS, but that would also present =
challenges.  No matter where we “root” the discovery =
process, there is a potential somebody could break it.  It could be =
rooted somewhere other than the root of the domain (e.g., webfinger.example.com), but we either =
need to decide in advance of such a location or introduce a way to =
discovery the discovery =
resources.
 
Do you have a suggestion that would make this less likely to be =
broken?
 
Paul
 
From:=
 apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of George =
Fletcher
Sent: Tuesday, August 28, 2012 =
11:09 AM
To: Mark =
Nottingham
Cc: IETF Apps =
Discuss
Subject: Re: [apps-discuss] Looking at =
Webfinger
 
Way "late to the =
party" but I can speak from experience that deployment can be a =
real issue in some environments. It's all really straight forward in a =
small company or an environment where the identity team "owns" =
the root domain (e.g. example.com). However, if an entire =
other group in a large organization "owns" the root domain =
(home page for the site) and the identity team then needs to get them to =
make changes, the deployment solution gets brittle pretty quick. I've =
had our webfinger support broken at least twice because the =
"other" team didn't know that certain configs were =
required:)

Also, installing the "dynamic pluming" can =
be more problematic is these cases. It is possible to get apache rewrite =
rules or netscaler magic in place to make it work, it's just a more =
brittle deployment =
architecture.

Thanks,
George
On 7/4/12 6:58 PM, John Panzer =
wrote:
Mark -- Of course I was speaking about practical =
realities of typical web server administration and deployment.  In =
practical terms, adding a new mod_rewrite rule or moral equivalent is =
going to be easier than adding a new PHP script that connects to a =
database.  The latter is just always going to be a much higher =
bar.
 
And, something that returns per-user data is generally =
going to need a dynamic service of some kind, unless your site has just =
a handful of users and you don't mind going through a publishing =
exercise each time you add or change a =
user...
 
None of this has anything to do with the interface, =
just deployment realities.  And in reality all of this is going to =
need a dynamic service somewhere for each non-trivial site, this is all =
just a question of how to hook it =
up.

--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / =
@jpanzer
 
 
On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham <mnot@mnot.net> =
wrote:
On 05/07/2012, at 8:16 AM, John Panzer =
wrote:

> Just as a historical note.  The envisioned usage =
of host-meta was originally to avoid a specification which mandated a =
particular dynamic URL API at a particular /.well-known endpoint =
(because it may not be feasible to do that across all organizations and =
deployments).  The host-meta document itself would be highly =
cacheable and so wouldn't incur an additional network trip in the common =
case.
>
> Having a 3xx redirect is a reasonable alternative =
that allows a similar escape hatch via something like mod_rewrite, =
albeit at the cost of needing an additional network trip each time. =
 Since a deployment can always avoid the 3xx redirect with =
additional dynamic plumbing behind the well-known endpoint, I don't =
think that's a horrible thing.
>
> An application-level =
redirect would be almost equivalent to an HTTP redirect, but then there =
are two ways to do the same thing.  If _only_ an application-level =
redirect is allowed, then you have to have at least a minimal dynamic =
service at the well-known endpoint (no more mod_rewrite).  But the =
whole reason for this is to avoid the requirement for a dynamic service =
behind well-known...
"dynamic" and "static" are =
properties of the implementation, not the interface. HTTP doesn't =
require that any particular URL be "dynamic"; anything can, =
with the right metadata, be cached (and indeed, I've cached many, many =
things with the wrong metadata, because of silly site operators and =
their ideas about "dynamic").

Now, if people want to =
target a particular implementation that makes it easier to serve a =
particular style of URL without writing code, fine, but let's not =
confuse things.

E.g., a URL like

http://example.com/.well-known/user/bob=


is easy to serve in pretty much any way you like with =
Apache.

I'm also going to push back on the "it may not be =
feasible to do that across all organizations and deployments" =
motivation. This is a race to the bottom. The trick is to make it =
accessible enough to get sufficient traction to pull everyone along, =
without pandering to *everyone*'s =
requirements.

Regards,

--
Mark =
Nottingham   http://www.mnot.net/



 





___=
____________________________________________
apps-di=
scuss mailing list
apps-discuss@ietf.org
<=
pre>https://www.ietf.org/mailman/listinfo/apps-discuss=

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

 

------=_NextPart_000_0466_01CD85EB.53371520--


From paulej@packetizer.com  Wed Aug 29 10:57:39 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D66D21F86D6 for ; Wed, 29 Aug 2012 10:57:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.361
X-Spam-Level: 
X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlhDZ52HsfJ2 for ; Wed, 29 Aug 2012 10:57:38 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5855021F86D5 for ; Wed, 29 Aug 2012 10:57:38 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q7THvaZf000890 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Aug 2012 13:57:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1346263057; bh=xSTa41CzW448DIYt5OoHzy58Fh/oXFsZadIVqK+MMHI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=BFATxSbQwfjvfjFYPxXznXhTUgGuWc6Mjq/uXY8u7pM8/s3ONwZzPce9VrjW4OVEa fPXALpw9ziKWSAe/UWIuroakvGsepVwjeCxtGFu6rSw9fNMq460WbAkxkjPWd1WZUd 4NUmOAyBofW0ogcfKkXWeCV0WHMrwF6t/FQgrONk=
From: "Paul E. Jones" 
To: "'Goix Laurent Walter'" , "=?UTF-8?Q?'=E2=98=AE_elf_Pavlik_=E2=98=AE'?=" ,  "'Peter Saint-Andre'" 
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im>	<5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im>	<4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com>	<1346172875-sup-9676@heahdk.net> <503D04E5.1090506@stpeter.im>	<1346176849-sup-3504@heahdk.net> 
In-Reply-To: 
Date: Wed, 29 Aug 2012 13:57:57 -0400
Message-ID: <047b01cd860f$d31f7ce0$795e76a0$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHQkPRpqE241VMBhFX0b1E5n3icagGmT2cgAfxtLQICXYfDzwLd38ExAfCD3o0CSm6TWwHz+GlOAlI3tJiW4AA3QA==
Content-Language: en-us
Cc: 'apps-discuss' 
Subject: Re: [apps-discuss] R: Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Aug 2012 17:57:39 -0000

Walter,

If you query /.well-known/host-meta[.json], one will get a set of link =
relations that are host-wide and templates that are resource-specific.  =
Isn't that more-or-less the same as what you are suggesting with =
acct:example.com?  I don't see the difference.

You can see an example:
curl -v https://packetizer.com/.well-known/host-meta.json

Paul

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org]
> On Behalf Of Goix Laurent Walter
> Sent: Wednesday, August 29, 2012 4:25 AM
> To: =E2=98=AE elf Pavlik =E2=98=AE; Peter Saint-Andre
> Cc: apps-discuss
> Subject: [apps-discuss] R: Comment on =
draft-ietf-appsawg-acct-uri-00.txt
>=20
> > -----Messaggio originale-----
> > Da: apps-discuss-bounces@ietf.org
> > [mailto:apps-discuss-bounces@ietf.org] Per conto di ? elf Pavlik ?
> > Inviato: marted=C3=AC 28 agosto 2012 20.19
> > A: Peter Saint-Andre
> > Cc: apps-discuss
> > Oggetto: Re: [apps-discuss] Comment on
> > draft-ietf-appsawg-acct-uri-00.txt
> >
> > Excerpts from Peter Saint-Andre's message of 2012-08-28 17:50:29 =
+0000:
> > > Hash: SHA1
> > >
> > > On 8/28/12 11:05 AM, elf Pavlik wrote:
> > > > Excerpts from Mike Jones's message of 2012-08-23 18:49:36 +0000:
> > > >> As long as I'm writing about the acct: URI, let me add my voice
> > > >> supporting allowing local account identifiers such as =
"acct:joe"
> > > >> to be used, in addition to fully qualified names such
> > > >> "acct:joe@example.com".  The reason that this this can work =
fine
> > > >> for discovery is that if you're contacting the discovery server
> > > >> at example.com, the identifier "acct:joe" is unambiguous in =
that
> > > >> context.
> > > >
> > > > While ago I've suggested on webfinger mailing list to allow
> > > > identifiers without local part, just: @domain.tld
> > >
> > > Hmm, if local part and domain part are both optional, can we also
> > > have "acct:@"? ;-)
> > >
> > > > This way projects could have sort of catch all accounts like:
> > > > @ietf.org and people having personal domains could also just use
> > > > @name.me (rather than me@name.me or i@name.me etc.)
> > >
> > > Yes, I recall that discussion, and if I recall correctly most =
people
> > > thought it wasn't a great idea. What does it mean to, say, perform =
a
> > > WebFinger query against a bare domain?
> > Yes, many people mentioned the original intention to mimic familiar =
to
> > most people email addresses
> >
> > >
> > > > It seams to me attractive if used in ostatus for federated
> > > > microblogging.
> > >
> > > Could you perhaps explain that scenario in a bit more detail? I'm
> > > curious to learn what requirements that brings in.
> > At some point i thought that for example twitter specific: @ietf =
could
> > become possibly self hosted @ietf.org as well as people with =
personal
> > domains could use just identifiers like @franky.me and choose where
> > they want to host their accounts.
> >
> > I also recall Markus Sabadello enthusiasm to in some ways infamous
> > i-names which just use =3Dname for individuals and @name for
> > organizations https://en.wikipedia.org/wiki/I-name
> >
> > Honestly I just wanted to hear more opinions about it, seeing myself
> > possible convenience in having option to just skip local part.
> [walter] Personally I'd rather see the value of domain-only rather =
than
> domain-less acct: URIs for deployments. In [1] I illustrated a use =
case
> for large deployments and federated social networks where lots of
> webfinger discoveries could happen across users on distinct social
> networks (e.g. when start cross-following). That email suggested the =
use
> of templates and new template variables, which is not exactly the =
subject
> here, but the main point remains and allowing domain-only identifiers
> could help in that.
> Potentially a server (knowing in advance it may deal with several =
users on
> the same foreign server) could issue a webfinger query to the resource
> acct:example.com instead of a specific user. I would expect a =
difference
> wrt to issuing a pure host-meta query where only a limited subset of
> endpoints/link rels may be provided: by specifying the domain-only
> resource explicitly it would be understood as a 2nd level query =
(meaning
> extracting the link rels provided by the lrdd descriptor typically) =
and
> thus could provide these additional links. Combined with templates =
(here
> we can then discuss on the reserved template parameter names) it could
> become a powerful mechanism to retrieve template-based endpoints that
> could be valid for all users on that server/domain, thus reducing the
> number of wf queries for distinct users on the same foreign server. In
> case some link rels do not follow a specific pattern and are more =
complex
> they could simply not be returned in that type of xrd/jrd, and the =
server
> would need to issue a user-specific query to retrieve extra link rels =
if
> needed.
>=20
> Here is an example:
> GET /.well-known/host-meta.json?resource=3Dacct:example.com HTTP/1.1
> Host: example.com
>=20
> The reply might have this body (using a fictitious "{uri.userpart}" to
> represent only the user-part of the acct: URI):
>=20
> {
>   "subject" : "acct:example.com",
>   "links" :
>   [
>     {
>       "rel" : "http://webfinger.net/rel/avatar",
>       "template" :
> "http://www.example.com/people/{uri}/images/{uri.userpart}.jpg"
>     },
>     {
>       "rel" : "http://webfinger.net/rel/profile-page",
>       "template" : "http://www.example.com/people/{uri}"
>     },
>     {
>       "rel" : "http://schemas.google.com/g/2010#updates-from",
>       "template" : "http://www.example.com/people/{uri}/blog/blog.xml"
>     }
>   ]
> }
>=20
> walter
>=20
> [1] http://www.ietf.org/mail-archive/web/apps-
> discuss/current/msg06073.html
>=20
> >
> > >
> > > > On that thread someone also mentioned that in xmpp realm
> > > > @domain.tld makes a valid jid but i haven't research it further
> > > > yet :(
> > >
> > > You can have xmpp:domain.tld (the address of a server), but you
> > > can't have xmpp:@domain.tld (some sort of catch-all for all =
accounts
> > > at the server??).
> > Thanks for clarifying, also acct:domain.tld looks also somehow more
> > sane than acct:@domain.tld :)
> >
> > >
> > > Peter
> > >
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente =
alle
> persone indicate. La diffusione, copia o qualsiasi altra azione =
derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate.
> Qualora abbiate ricevuto questo documento per errore siete =
cortesemente
> pregati di darne immediata comunicazione al mittente e di provvedere =
alla
> sua distruzione, Grazie.
>=20
> This e-mail and any attachments is confidential and may contain =
privileged
> information intended for the addressee(s) only. Dissemination, =
copying,
> printing or use by anybody else is unauthorised. If you are not the
> intended recipient, please delete this message and any attachments and
> advise the sender by return e-mail, Thanks.
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From ve7jtb@ve7jtb.com  Wed Aug 29 10:57:45 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0770721F85AF for ; Wed, 29 Aug 2012 10:57:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.501
X-Spam-Level: 
X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=0.097,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9p4sV1hsqGbB for ; Wed, 29 Aug 2012 10:57:43 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id AE1C021F8551 for ; Wed, 29 Aug 2012 10:57:42 -0700 (PDT)
Received: by qan41 with SMTP id 41so3528165qan.10 for ; Wed, 29 Aug 2012 10:57:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=ZaFRsyRpD1ZBJAUanswi8y48bsaGN5lQ/5M3Z5gGOBc=; b=aafHK4jHSP64GnMbYDzHh6Lh34hSh7G9QEyDJ7Oump1PaPQuNylXwvSpvLKWBV2Lar wZKvHM28GLeh/Mz2JShpujKo8XBLArVYPqxkeFHDGA0KVZTPCkz0/yRBRnM///m54/An z/yiHIaMxX9aTkwrg18qcVVuWjUe4nJVwatMVwfynAefNaf2id24GfxmVYcQCTbHLo3N LqnGfneeP47SVbtCkshPM4Kh46xAZHeyXO/P4uzdNbPOXn1+npk5pHn+2h6OJAYSNayW UWDXi5kM+gBhADw2sGUz+CM7wBl4vqI45+rEIiELdj27m5/q4IsUwIqQdaCc972ProFU ftzQ==
Received: by 10.229.135.17 with SMTP id l17mr1256194qct.149.1346263061716; Wed, 29 Aug 2012 10:57:41 -0700 (PDT)
Received: from [192.168.1.211] (190-20-54-75.baf.movistar.cl. [190.20.54.75]) by mx.google.com with ESMTPS id o25sm46511083yhm.14.2012.08.29.10.57.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Aug 2012 10:57:40 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_93F131C6-E128-4525-86D0-B9C967DC5D82"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
From: John Bradley 
In-Reply-To: <046501cd860c$da464420$8ed2cc60$@packetizer.com>
Date: Wed, 29 Aug 2012 13:57:34 -0400
Message-Id: <287CDD14-DEC2-40AD-AD5D-DC102D5AAAE6@ve7jtb.com>
References:  <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com>   <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com>      <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net>  <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com> <032d01cd8597$aac7f740$0057e5c0$@packetizer.com>  <046501cd860c$da464420$8ed2cc60$@packetizer.com>
To: "Paul E. Jones" 
X-Mailer: Apple Mail (2.1486)
X-Gm-Message-State: ALoCoQmHwvKA6HzrJplJMRWk+jZqqdJ0GVZw99r1WlQyTkUeD+ic0ITmNSvIrre9CBXa06BRzReo
Cc: Mark Nottingham , IETF Apps Discuss 
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Aug 2012 17:57:45 -0000

--Apple-Mail=_93F131C6-E128-4525-86D0-B9C967DC5D82
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_00B22103-A164-4AAC-9A1D-E5022A83221B"


--Apple-Mail=_00B22103-A164-4AAC-9A1D-E5022A83221B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I am not the best person to represent Google's needs.

However as I understand it Google hosts applications such as email =
documents openID for tens of thousands of domains.
Google themselves don't control the DNS.

The people using the service generally add some MX records for =
aspmx.l.google.com. and a Cname for mail.example.com to ghs.google.com.

The A record for the bare domain typically points off to some Content =
management site the company uses for their web pages.

I think this is probably typical of Yahoo's mail hosting services and =
others.  =20

The service hosing the email/authentication/openID is not the one that =
controls the web server for company.

Saying the CMS venders will provide WebFinger services doesn't seem all =
that likely, especially in virtual hosting environments.

Getting a typical company to do anything more than enter a cname for =
webfinger.example.org is wildly optimistic.

I am entirely open to Ideas on this.   However the previous solution of =
having every RP check with google first to see if they host the email =
and provide the XRDS seems horribly flawed to me.

I would like to see a workable solution at the discovery layer that =
accommodates how people deploy there sites.

I think Bill suggested at one point using the MX record to find the =
webfinger host.  That has a bunch of problems I would prefer to avoid.

John B.

On 2012-08-29, at 1:36 PM, "Paul E. Jones"  =
wrote:

> John,
> =20
> Well, we need to figure out how to address this.
> =20
> Would it be reasonable to redirect requests from =
/.well-known/host-meta.json and /.well-known/host-meta to Google?
> =20
> Are there other services or files under /.well-known that Google=92s =
customers would not want Google to host?  If they were OK with Google=92s =
servers responding to anything , then one could put an A (or CNAME) =
record in place for example.com that points to Google.
> =20
> Not being familiar with what Google offers, I=92m a bit challenged to =
understand exactly what is and is not possible.
> =20
> Paul
> =20
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
> Sent: Wednesday, August 29, 2012 10:14 AM
> To: Paul E. Jones
> Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
> Subject: Re: [apps-discuss] Looking at Webfinger
> =20
> There mite be a A record but that typically goes off to some virtual =
web hosting company and not the email service provider.
> =20
> I think I have also heard William say this is a problem for Yahoo.
> =20
> Google was not able to get people to deploy XRDS for hosted domains.   =
They came up with a proprietary extension to openID discovery to make =
hosted google apps domains work with some subset of RP.
> =20
> The problem is that the company hosting a small businesses website is =
unlikely to provide the web finger infrastructure and there is no way =
for the email/openID provider to do it without their cooperation.
> =20
> Adding a A record rather than a CNAME is generally not a good idea if =
it can be avoided.   In the event of the provider changing an IP address =
it breaks all the customers if they have used A records, but that is =
separate issue. =20
> =20
> You can set up webfinger on your web server and manage it.   It just =
won't work for large numbers of people as we have it now. =20
> =20
> If webfinger won't work for Google Apps for Domains and other hosted =
services like that then It will significantly impact adoption in my =
opinion.
> =20
> We will also need to work around that for Connect.  We don't want =
another proprietary work around with the security problems that can =
entail.
> =20
> John B.
> =20
> On 2012-08-28, at 11:37 PM, "Paul E. Jones"  =
wrote:
>=20
>=20
> John,
> =20
> If Google is hosting the domain or any other service provider, =
wouldn=92t there still be an A record for the domain =
(e.g.,packetizer.com)?  I know there is for virtually every web hosting =
company I=92ve used.  It seems like this might just be one more hosted =
service Google could provide to its customers, no?
> =20
> I do not know exactly how this hosted service works, but what=92s =
hosted?  I assume it=92s just email.  If web, then I see no issue.  If =
only email, then the user just needs to have MX records pointing to =
Google and an A record pointing to whatever service runs the WebFinger =
service.
> =20
> In any case, if they can add a CNAME or MX record, I think we can get =
them to add an A record.  I think it would be far more challenging for =
SMBs to add a host like webfinger.example.com.  That would still require =
an A record and a service provider capable of supporting it.
> =20
> Paul
> =20
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
> Sent: Tuesday, August 28, 2012 3:29 PM
> To: Paul E. Jones
> Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
> Subject: Re: [apps-discuss] Looking at Webfinger
> =20
> There are cases where there are hosted domains (Google etc) that may =
not have a http host for the domain name used in the users email =
address. =20
> =20
> There may be merit to having a webfinger.example.com fallback where =
the client can't reach the .well-known for the primary host.
> =20
> I know that some sort of SRV record would be the correct way to do it, =
but in the real world SMB don't enter SRV records even if there DNS =
provider support them.
> The most you can get them to do is add a CNAME or MX record.
> =20
> Supporting these sorts of domains somehow is a important issue.
> =20
> John B.
> =20
> On 2012-08-28, at 3:17 PM, "Paul E. Jones"  =
wrote:
>=20
>=20
>=20
> George,
> =20
> I believe it might be useful to introduce those who break your =
WebFinger server to Louisville Slugger. :)
> =20
> Your pain is understood, but I do not see a way to avoid it.  We could =
introduce something in DNS, but that would also present challenges.  No =
matter where we =93root=94 the discovery process, there is a potential =
somebody could break it.  It could be rooted somewhere other than the =
root of the domain (e.g., webfinger.example.com), but we either need to =
decide in advance of such a location or introduce a way to discovery the =
discovery resources.
> =20
> Do you have a suggestion that would make this less likely to be =
broken?
> =20
> Paul
> =20
> From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of George Fletcher
> Sent: Tuesday, August 28, 2012 11:09 AM
> To: Mark Nottingham
> Cc: IETF Apps Discuss
> Subject: Re: [apps-discuss] Looking at Webfinger
> =20
> Way "late to the party" but I can speak from experience that =
deployment can be a real issue in some environments. It's all really =
straight forward in a small company or an environment where the identity =
team "owns" the root domain (e.g. example.com). However, if an entire =
other group in a large organization "owns" the root domain (home page =
for the site) and the identity team then needs to get them to make =
changes, the deployment solution gets brittle pretty quick. I've had our =
webfinger support broken at least twice because the "other" team didn't =
know that certain configs were required:)
>=20
> Also, installing the "dynamic pluming" can be more problematic is =
these cases. It is possible to get apache rewrite rules or netscaler =
magic in place to make it work, it's just a more brittle deployment =
architecture.
>=20
> Thanks,
> George
>=20
> On 7/4/12 6:58 PM, John Panzer wrote:
> Mark -- Of course I was speaking about practical realities of typical =
web server administration and deployment.  In practical terms, adding a =
new mod_rewrite rule or moral equivalent is going to be easier than =
adding a new PHP script that connects to a database.  The latter is just =
always going to be a much higher bar.
> =20
> And, something that returns per-user data is generally going to need a =
dynamic service of some kind, unless your site has just a handful of =
users and you don't mind going through a publishing exercise each time =
you add or change a user...
> =20
> None of this has anything to do with the interface, just deployment =
realities.  And in reality all of this is going to need a dynamic =
service somewhere for each non-trivial site, this is all just a question =
of how to hook it up.
>=20
> --
> John Panzer / Google
> jpanzer@google.com / abstractioneer.org / @jpanzer
> =20
> =20
>=20
> On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham  wrote:
> On 05/07/2012, at 8:16 AM, John Panzer wrote:
>=20
> > Just as a historical note.  The envisioned usage of host-meta was =
originally to avoid a specification which mandated a particular dynamic =
URL API at a particular /.well-known endpoint (because it may not be =
feasible to do that across all organizations and deployments).  The =
host-meta document itself would be highly cacheable and so wouldn't =
incur an additional network trip in the common case.
> >
> > Having a 3xx redirect is a reasonable alternative that allows a =
similar escape hatch via something like mod_rewrite, albeit at the cost =
of needing an additional network trip each time.  Since a deployment can =
always avoid the 3xx redirect with additional dynamic plumbing behind =
the well-known endpoint, I don't think that's a horrible thing.
> >
> > An application-level redirect would be almost equivalent to an HTTP =
redirect, but then there are two ways to do the same thing.  If _only_ =
an application-level redirect is allowed, then you have to have at least =
a minimal dynamic service at the well-known endpoint (no more =
mod_rewrite).  But the whole reason for this is to avoid the requirement =
for a dynamic service behind well-known...
>=20
> "dynamic" and "static" are properties of the implementation, not the =
interface. HTTP doesn't require that any particular URL be "dynamic"; =
anything can, with the right metadata, be cached (and indeed, I've =
cached many, many things with the wrong metadata, because of silly site =
operators and their ideas about "dynamic").
>=20
> Now, if people want to target a particular implementation that makes =
it easier to serve a particular style of URL without writing code, fine, =
but let's not confuse things.
>=20
> E.g., a URL like
>=20
> http://example.com/.well-known/user/bob
>=20
> is easy to serve in pretty much any way you like with Apache.
>=20
> I'm also going to push back on the "it may not be feasible to do that =
across all organizations and deployments" motivation. This is a race to =
the bottom. The trick is to make it accessible enough to get sufficient =
traction to pull everyone along, without pandering to *everyone*'s =
requirements.
>=20
> Regards,
>=20
> --
> Mark Nottingham   http://www.mnot.net/
>=20
>=20
>=20
>=20
>=20
> =20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> =20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


--Apple-Mail=_00B22103-A164-4AAC-9A1D-E5022A83221B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I am not the best person to =
represent Google's needs.

However as I understand it =
Google hosts applications such as email documents openID for tens of =
thousands of domains.
Google themselves don't control the =
DNS.

The people using the service generally add =
some MX records for aspmx.l.google.com. and a Cname =
for mail.example.com to ghs.google.com.

The A record for the bare domain typically points off to some Content =
management site the company uses for their web =
pages.

I think this is probably typical of =
Yahoo's mail hosting services and others. =
  

The service hosing the =
email/authentication/openID is not the one that controls the web server =
for company.

Saying the CMS venders will =
provide WebFinger services doesn't seem all that likely, especially in =
virtual hosting environments.

Getting a typical =
company to do anything more than enter a cname for webfinger.example.org is =
wildly optimistic.

I am entirely open to Ideas =
on this.   However the previous solution of having every RP check =
with google first to see if they host the email and provide the XRDS =
seems horribly flawed to me.

I would like to =
see a workable solution at the discovery layer that accommodates how =
people deploy there sites.

I think Bill =
suggested at one point using the MX record to find the webfinger host. =
 That has a bunch of problems I would prefer to =
avoid.

John B.

On =
2012-08-29, at 1:36 PM, "Paul E. Jones" <paulej@packetizer.com> =
wrote:

 
Well, we need to figure out how to address =
this.
 
Would it be reasonable to redirect requests =
from /.well-known/host-meta.json and /.well-known/host-meta to =
Google?
 
Are there other services or files under =
/.well-known that Google=92s customers would not want Google to =
host?  If they were OK with Google=92s servers responding to =
anything , then one could put an A (or CNAME) record in place for example.com that points to =
Google.
 
Not being familiar with what Google offers, =
I=92m a bit challenged to understand exactly what is and is not =
possible.
 
Paul
 
From: John Bradley =
[mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, August 29, 2012 =
10:14 AM
To: Paul E. =
Jones
Cc: 'George Fletcher'; 'Mark =
Nottingham'; 'IETF Apps Discuss'
Subject: Re: [apps-discuss] Looking =
at Webfinger
 
There mite be =
a A record but that typically goes off to some virtual web hosting =
company and not the email service provider.
 
I think I have also heard William say this is a =
problem for Yahoo.
The =
problem is that the company hosting a small businesses website is =
unlikely to provide the web finger infrastructure and there is no way =
for the email/openID provider to do it without their =
cooperation.
 
You can set up webfinger on your web server and =
manage it.   It just won't work for large numbers of people as we =
have it now.  
If =
webfinger won't work for Google Apps for Domains and other hosted =
services like that then It will significantly impact adoption in my =
opinion.
We =
will also need to work around that for Connect.  We don't want =
another proprietary work around with the security problems that can =
entail.
John =
B.
On =
2012-08-28, at 11:37 PM, "Paul E. Jones" <paulej@packetizer.com> =
wrote:
John,
If Google is hosting the domain or any other =
service provider, wouldn=92t there still be an A record for the domain =
(e.g., 
From: John =
Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Tuesday, August 28, 2012 =
3:29 PM
To: Paul E. =
Jones
Cc: 'George Fletcher'; 'Mark =
Nottingham'; 'IETF Apps Discuss'
Subject: Re: [apps-discuss] Looking =
at Webfinger
 
 example.com). =
However, if an entire other group in a large organization "owns" the =
root domain (home page for the site) and the identity team then needs to =
get them to make changes, the deployment solution gets brittle pretty =
quick. I've had our webfinger support broken at least twice because the =
"other" team didn't know that certain configs were =
required:)

Also, installing the "dynamic pluming" can be more =
problematic is these cases. It is possible to get apache rewrite rules =
or netscaler magic in place to make it work, it's just a more brittle =
deployment =
architecture.

Thanks,
George
On 7/4/12 6:58 PM, John Panzer =
wrote:
Mark -- Of =
course I was speaking about practical realities of typical web server =
administration and deployment.  In practical terms, adding a new =
mod_rewrite rule or moral equivalent is going to be easier than adding a =
new PHP script that connects to a database.  The latter is just =
always going to be a much higher bar.
 
And, something that returns per-user data is =
generally going to need a dynamic service of some kind, unless your site =
has just a handful of users and you don't mind going through a =
publishing exercise each time you add or change a =
user...
None =
of this has anything to do with the interface, just deployment =
realities.  And in reality all of this is going to need a dynamic =
service somewhere for each non-trivial site, this is all just a question =
of how to hook it up.

--
John Panzer / Google
 /  / =
@jpanzer
 
On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham <On 05/07/2012, at 8:16 AM, John =
Panzer wrote:

> Just as a historical note.  The =
envisioned usage of host-meta was originally to avoid a specification =
which mandated a particular dynamic URL API at a particular /.well-known =
endpoint (because it may not be feasible to do that across all =
organizations and deployments).  The host-meta document itself =
would be highly cacheable and so wouldn't incur an additional network =
trip in the common case.
>
> Having a 3xx redirect is a =
reasonable alternative that allows a similar escape hatch via something =
like mod_rewrite, albeit at the cost of needing an additional network =
trip each time.  Since a deployment can always avoid the 3xx =
redirect with additional dynamic plumbing behind the well-known =
endpoint, I don't think that's a horrible thing.
>
> An =
application-level redirect would be almost equivalent to an HTTP =
redirect, but then there are two ways to do the same thing.  If =
_only_ an application-level redirect is allowed, then you have to have =
at least a minimal dynamic service at the well-known endpoint (no more =
mod_rewrite).  But the whole reason for this is to avoid the =
requirement for a dynamic service behind =
well-known...

--
Mark Nottingham =
  apps-discuss mailing list
 wrote:

> I am not the best person to represent Google's needs.
>
> However as I understand it Google hosts applications such as email
> documents openID for tens of thousands of domains.
> Google themselves don't control the DNS.
>
> The people using the service generally add some MX records for
> aspmx.l.google.com. and a Cname for mail.example.com to ghs.google.com.
>
> The A record for the bare domain typically points off to some Content
> management site the company uses for their web pages.
>
> I think this is probably typical of Yahoo's mail hosting services and
> others.
>
> The service hosing the email/authentication/openID is not the one that
> controls the web server for company.
>
> Saying the CMS venders will provide WebFinger services doesn't seem all
> that likely, especially in virtual hosting environments.
>
> Getting a typical company to do anything more than enter a cname for
> webfinger.example.org is wildly optimistic.
>
> I am entirely open to Ideas on this.   However the previous solution of
> having every RP check with google first to see if they host the email and
> provide the XRDS seems horribly flawed to me.
>
> I would like to see a workable solution at the discovery layer that
> accommodates how people deploy there sites.
>
> I think Bill suggested at one point using the MX record to find the
> webfinger host.  That has a bunch of problems I would prefer to avoid.
>
> John B.
>
> On 2012-08-29, at 1:36 PM, "Paul E. Jones"  wrote:
>
> John,****
>
> Well, we need to figure out how to address this.****
>
> Would it be reasonable to redirect requests from
> /.well-known/host-meta.json and /.well-known/host-meta to Google?****
>
> Are there other services or files under /.well-known that Google=92s
> customers would not want Google to host?  If they were OK with Google=92s
> servers responding to anything , then one could put an A (or CNAME) recor=
d
> in place for example.com that points to Google.****
>
> Not being familiar with what Google offers, I=92m a bit challenged to
> understand exactly what is and is not possible.****
>
> Paul****
>
>  *From:* John Bradley [mailto:ve7jtb@ve7jtb.com]
> *Sent:* Wednesday, August 29, 2012 10:14 AM
> *To:* Paul E. Jones
> *Cc:* 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
> *Subject:* Re: [apps-discuss] Looking at Webfinger****
> ** **
> There mite be a A record but that typically goes off to some virtual web
> hosting company and not the email service provider.****
> ** **
> I think I have also heard William say this is a problem for Yahoo.****
> ** **
> Google was not able to get people to deploy XRDS for hosted domains.
> They came up with a proprietary extension to openID discovery to make
> hosted google apps domains work with some subset of RP.****
> ** **
> The problem is that the company hosting a small businesses website is
> unlikely to provide the web finger infrastructure and there is no way for
> the email/openID provider to do it without their cooperation.****
> ** **
> Adding a A record rather than a CNAME is generally not a good idea if it
> can be avoided.   In the event of the provider changing an IP address it
> breaks all the customers if they have used A records, but that is separat=
e
> issue.  ****
> ** **
> You can set up webfinger on your web server and manage it.   It just won'=
t
> work for large numbers of people as we have it now.  ****
> ** **
> If webfinger won't work for Google Apps for Domains and other hosted
> services like that then It will significantly impact adoption in my opini=
on.
> ****
> ** **
> We will also need to work around that for Connect.  We don't want another
> proprietary work around with the security problems that can entail.****
> ** **
> John B.****
> ** **
> On 2012-08-28, at 11:37 PM, "Paul E. Jones"  wrote=
:
> ****
>
>
> ****
> John,****
>  ****
> If Google is hosting the domain or any other service provider, wouldn=92t
> there still be an A record for the domain (e.g.,packetizer.com)?  I know
> there is for virtually every web hosting company I=92ve used.  It seems l=
ike
> this might just be one more hosted service Google could provide to its
> customers, no?****
>  ****
> I do not know exactly how this hosted service works, but what=92s hosted?=
  I
> assume it=92s just email.  If web, then I see no issue.  If only email, t=
hen
> the user just needs to have MX records pointing to Google and an A record
> pointing to whatever service runs the WebFinger service.****
>  ****
> In any case, if they can add a CNAME or MX record, I think we can get the=
m
> to add an A record.  I think it would be far more challenging for SMBs to
> add a host like webfinger.example.com.  That would still require an A
> record and a service provider capable of supporting it.****
>  ****
> Paul****
>  ****
> *From:* John Bradley [mailto:ve7jtb@ve7jtb.com]
> *Sent:* Tuesday, August 28, 2012 3:29 PM
> *To:* Paul E. Jones
> *Cc:* 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
> *Subject:* Re: [apps-discuss] Looking at Webfinger****
>  ****
> There are cases where there are hosted domains (Google etc) that may not
> have a http host for the domain name used in the users email address.  **=
*
> *
>  ****
> There may be merit to having a webfinger.example.com fallback where the
> client can't reach the .well-known for the primary host.****
>  ****
> I know that some sort of SRV record would be the correct way to do it, bu=
t
> in the real world SMB don't enter SRV records even if there DNS provider
> support them.****
> The most you can get them to do is add a CNAME or MX record.****
>  ****
> Supporting these sorts of domains somehow is a important issue.****
>  ****
> John B.****
>  ****
> On 2012-08-28, at 3:17 PM, "Paul E. Jones"  wrote:=
*
> ***
>
>
>
> ****
> George,****
>  ****
> I believe it might be useful to introduce those who break your WebFinger
> server to Louisville Slugger. :)****
>  ****
> Your pain is understood, but I do not see a way to avoid it.  We could
> introduce something in DNS, but that would also present challenges.  No
> matter where we =93root=94 the discovery process, there is a potential so=
mebody
> could break it.  It could be rooted somewhere other than the root of the
> domain (e.g., webfinger.example.com), but we either need to decide in
> advance of such a location or introduce a way to discovery the discovery
> resources.****
>  ****
> Do you have a suggestion that would make this less likely to be broken?**=
*
> *
>  ****
> Paul****
>  ****
> *From:* apps-discuss-bounces@ietf.org [mailto:apps-
> discuss-bounces@ietf.org] *On Behalf Of *George Fletcher
> *Sent:* Tuesday, August 28, 2012 11:09 AM
> *To:* Mark Nottingham
> *Cc:* IETF Apps Discuss
> *Subject:* Re: [apps-discuss] Looking at Webfinger****
>  ****
>
> Way "late to the party" but I can speak from experience that deployment
> can be a real issue in some environments. It's all really straight forwar=
d
> in a small company or an environment where the identity team "owns" the
> root domain (e.g. example.com). However, if an entire other group in a
> large organization "owns" the root domain (home page for the site) and th=
e
> identity team then needs to get them to make changes, the deployment
> solution gets brittle pretty quick. I've had our webfinger support broken
> at least twice because the "other" team didn't know that certain configs
> were required:)
>
> Also, installing the "dynamic pluming" can be more problematic is these
> cases. It is possible to get apache rewrite rules or netscaler magic in
> place to make it work, it's just a more brittle deployment architecture.
>
> Thanks,
> George****
> On 7/4/12 6:58 PM, John Panzer wrote:****
>
> Mark -- Of course I was speaking about practical realities of typical web
> server administration and deployment.  In practical terms, adding a new
> mod_rewrite rule or moral equivalent is going to be easier than adding a
> new PHP script that connects to a database.  The latter is just always
> going to be a much higher bar.****
>  ****
> And, something that returns per-user data is generally going to need a
> dynamic service of some kind, unless your site has just a handful of user=
s
> and you don't mind going through a publishing exercise each time you add =
or
> change a user...****
>  ****
> None of this has anything to do with the interface, just deployment
> realities.  And in reality all of this is going to need a dynamic service
> somewhere for each non-trivial site, this is all just a question of how t=
o
> hook it up.****
>
> ****
> --
> John Panzer / Google
> jpanzer@google.com / abstractioneer.org  =
/
> @jpanzer****
>  ****
>
>  ****
> On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham  wrote:***=
*
>
> On 05/07/2012, at 8:16 AM, John Panzer wrote:
>
> > Just as a historical note.  The envisioned usage of host-meta was
> originally to avoid a specification which mandated a particular dynamic U=
RL
> API at a particular /.well-known endpoint (because it may not be feasible
> to do that across all organizations and deployments).  The host-meta
> document itself would be highly cacheable and so wouldn't incur an
> additional network trip in the common case.
> >
> > Having a 3xx redirect is a reasonable alternative that allows a similar
> escape hatch via something like mod_rewrite, albeit at the cost of needin=
g
> an additional network trip each time.  Since a deployment can always avoi=
d
> the 3xx redirect with additional dynamic plumbing behind the well-known
> endpoint, I don't think that's a horrible thing.
> >
> > An application-level redirect would be almost equivalent to an HTTP
> redirect, but then there are two ways to do the same thing.  If _only_ an
> application-level redirect is allowed, then you have to have at least a
> minimal dynamic service at the well-known endpoint (no more mod_rewrite).
>  But the whole reason for this is to avoid the requirement for a dynamic
> service behind well-known...****
> "dynamic" and "static" are properties of the implementation, not the
> interface. HTTP doesn't require that any particular URL be "dynamic";
> anything can, with the right metadata, be cached (and indeed, I've cached
> many, many things with the wrong metadata, because of silly site operator=
s
> and their ideas about "dynamic").
>
> Now, if people want to target a particular implementation that makes it
> easier to serve a particular style of URL without writing code, fine, but
> let's not confuse things.
>
> E.g., a URL like
>
> http://example.com/.well-known/user/bob
>
> is easy to serve in pretty much any way you like with Apache.
>
> I'm also going to push back on the "it may not be feasible to do that
> across all organizations and deployments" motivation. This is a race to t=
he
> bottom. The trick is to make it accessible enough to get sufficient
> traction to pull everyone along, without pandering to *everyone*'s
> requirements.
>
> Regards,****
>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
> ****
>  ****
>
>
>
>
>
> ****
>
> _______________________________________________****
>
>
> apps-discuss mailing list****
>
> apps-discuss@ietf.org****
>
> https://www.ietf.org/mailman/listinfo/apps-discuss****
>
>  ****
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss****
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

--f46d042de88beb5ce004c86b831c
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Based on experience, I'd prefer to avoid things that depend on the bare=
 ("naked") domain (example.com=
 instead of www.example.com or webfinger.example.com). =A0I could =
write up the reasons but it'd take some time. =A0Unfortunately, webfing=
er as originally spec'd requires this.



If we were to start over, and get to vote for whatever I wan=
ted, and were going to allow DNS records at all, I would probably vote for =
something like webfinger.example.c=
om as a special magic name (with the actual name chosen so as not to co=
llide with any existing DNS entries). =A0Any normal hosting mechanisms will=
 work here, including A records and CNAMEs and HTTP redirects, but I'd =
also require everything be done via TLS with correctly signed certificates =
for that subdomain (argh! =A0the pain!).




Organizationally, this would mean that any part of the =
organization that can stand up a separate SSL service on a new subdomain ca=
n provide webfinger services. =A0

On Wed,=
 Aug 29, 2012 at 10:57 AM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:



I am not=
 the best person to represent Google's needs.

Howeve=
r as I understand it Google hosts applications such as email documents open=
ID for tens of thousands of domains.



Google themselves don't control the DNS.

=
The people using the service generally add some MX records for aspmx.l.google.com. and a C=
name for mail.example=
.com to=A0ghs.googl=
e.com.




The A record for the bare domain typically points off t=
o some Content management site the company uses for their web pages.
<=
div>
I think this is probably typical of Yahoo's mail hos=
ting services and others. =A0=A0




The service hosing the email/authentication/openID is n=
ot the one that controls the web server for company.

Saying the CMS venders will provide WebFinger services doesn't seem =
all that likely, especially in virtual hosting environments.




Getting a typical company to do anything more than ente=
r a cname for we=
bfinger.example.org is wildly optimistic.

I am=
 entirely open to Ideas on this. =A0 However the previous solution of havin=
g every RP check with google first to see if they host the email and provid=
e the XRDS seems horribly flawed to me.




I would like to see a workable solution at the discover=
y layer that accommodates how people deploy there sites.

I think Bill suggested at one point using the MX record to find the =
webfinger host. =A0That has a bunch of problems I would prefer to avoid.



John B.

=
On 2012-08-29, at 1:36 PM, "Paul E. Jones" <paulej@packetizer.com> wrot=
e:






John,


=A0
Well, we need to fig=
ure out how to address this.



=A0


Would it be reasonable to redirect requests from /.well-known/host-=
meta.json and /.well-known/host-meta to Google?



=A0


Are there other services or files under /.well-known that Google=92=
s customers would not want Google to host?=A0 If they were OK with Google=
=92s servers responding to anything , then one could put an A (or CNAME) re=
cord in place for=A0example.com=A0that points to Google.



=A0


Not being familiar with what Google offers, I=92m a bit challenged =
to understand exactly what is and is not possible.


=A0


Paul
=A0=







From:=A0John Bradley [mailto:ve7jtb@ve7jtb.com]=A0


Sent:=A0Wednesday, August 29, 2012 10:14 AM
To:=A0Paul E. Jones
Cc:=A0'George Fl=
etcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
S=
ubject:=A0Re: [apps-discuss] Looking at Webfinger



=A0


There mite be a A record but that typically goes off to some virtual web ho=
sting company and not the email service provider.
<=
div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times =
New Roman',serif">

=A0
I think I have als=
o heard William say this is a problem for Yahoo.




=A0


Google was not able to get people to deploy XRDS for hosted domains. =A0 Th=
ey came up with a proprietary extension to openID discovery to make hosted =
google apps domains work with some subset of RP.



=A0


The problem is that the company hosting a small businesses website is unlik=
ely to provide the web finger infrastructure and there is no way for the em=
ail/openID provider to do it without their cooperation.



=A0


Adding a A record rather than a CNAME is generally not a good idea if it ca=
n be avoided. =A0 In the event of the provider changing an IP address it br=
eaks all the customers if they have used A records, but that is separate is=
sue. =A0



=A0


You can set up webfinger on your web server and manage it. =A0 It just won&=
#39;t work for large numbers of people as we have it now. =A0=



=A0
If webfinger won&#=
39;t work for Google Apps for Domains and other hosted services like that t=
hen It will significantly impact adoption in my opinion.


=A0


We will also need to work around that for Connect. =A0We don't want ano=
ther proprietary work around with the security problems that can entail.=



=A0
John B.<=
/u>


=A0
On 2012-08-28, at 1=
1:37 PM, "Paul E. Jones" <pau=
lej@packetizer.com> wrote:







John,

=A0


If Google is hosting the domain o=
r any other service provider, wouldn=92t there still be an A record for the=
 domain (e.g.,packet=
izer.com)?=A0 I know there is for virtually every web hosting co=
mpany I=92ve used.=A0 It seems like this might just be one more hosted serv=
ice Google could provide to its customers, no?



=A0



I do not know exactly how this hosted s=
ervice works, but what=92s hosted?=A0 I assume it=92s just email.=A0 If web=
, then I see no issue.=A0 If only email, then the user just needs to have M=
X records pointing to Google and an A record pointing to whatever service r=
uns the WebFinger service.



=A0



In any case, if they can add a CNAME or=
 MX record, I think we can get them to add an A record.=A0 I think it would=
 be far more challenging for SMBs to add a host like=A0webfinger.example.co=
m.=A0 That would still require an A record and a service provide=
r capable of supporting it.



=A0



Paul



=A0



=
From:=A0Joh=
n Bradley [mailto:ve7jtb@<=
a href=3D"http://ve7jtb.com" style=3D"color:purple;text-decoration:underlin=
e" target=3D"_blank">ve7jtb.com]=A0


Sent:=A0Tuesday, August 28, 2012 3:29 PM
To:<=
span>=A0Paul E. Jones
Cc:=A0'George Fletc=
her'; 'Mark Nottingham'; 'IETF Apps Discuss'
Subj=
ect:=A0Re: [apps-discuss] Looking at Webfinger



=A0
<=
div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times =
New Roman',serif">

There are cases where there are hosted domains (Google etc) that may not ha=
ve a http host for the domain name used in the users email address. =A0<=
/u>


=A0
There may be merit=
 to having a=A0webfinger.example.com=A0fallback =
where the client can't reach the .well-known for the primary host.



=A0


I know that some sort of SRV record would be the correct way to do it, but =
in the real world SMB don't enter SRV records even if there DNS provide=
r support them.


The most you can get them to do is add a CNAME or MX record.<=
/div>
=A0


Supporting these sorts of domains somehow is a important issue.
=A0



John B.


=A0
On 2012-08-28=
, at 3:17 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:<=
u>








George,


=A0
I believe it might be useful to introduce those who break your WebFing=
er server to Louisville Slugger. :)



=A0



Your pain is understood, but I do not s=
ee a way to avoid it.=A0 We could introduce something in DNS, but that woul=
d also present challenges.=A0 No matter where we =93root=94 the discovery p=
rocess, there is a potential somebody could break it.=A0 It could be rooted=
 somewhere other than the root of the domain (e.g.,=A0webfinger.example.co=
m), but we either need to decide in advance of such a location o=
r introduce a way to discovery the discovery resources.



=A0



Do you have a suggestion that would mak=
e this less likely to be broken?



=A0



Paul



=A0



=
From:=A0apps-dis=
cuss-bounces@ietf.org=A0[mailto:apps-discuss-bounces@ietf.org]=A0=
On Behalf Of=A0George Fletcher


Sent:=A0Tuesday, August 28, 2012 11:09 AM
To:=
=A0Mark Nottingham
Cc:=A0IETF Apps Disc=
uss
Subject:=A0Re: [apps-discuss] Looking at Webfing=
er



=A0


Way "late to the part=
y" but I can speak from experience that deployment can be a real issue=
 in some environments. It's all really straight forward in a small comp=
any or an environment where the identity team "owns" the root dom=
ain (e.g.=A0example.com). However, if an entire other group in a large org=
anization "owns" the root domain (home page for the site) and the=
 identity team then needs to get them to make changes, the deployment solut=
ion gets brittle pretty quick. I've had our webfinger support broken at=
 least twice because the "other" team didn't know that certai=
n configs were required:)



Also, installing the "dynamic pluming" can be more problemati=
c is these cases. It is possible to get apache rewrite rules or netscaler m=
agic in place to make it work, it's just a more brittle deployment arch=
itecture.



Thanks,
George
O=
n 7/4/12 6:58 PM, John Panzer wrote:



Mark -- Of course I was speaking about practica=
l realities of typical web server administration and deployment. =A0In prac=
tical terms, adding a new mod_rewrite rule or moral equivalent is going to =
be easier than adding a new PHP script that connects to a database. =A0The =
latter is just always going to be a much higher bar.



=A0


And, something that returns per-user data is generally going to need a dyna=
mic service of some kind, unless your site has just a handful of users and =
you don't mind going through a publishing exercise each time you add or=
 change a user...



=A0


None of this has anything to do with the interface, just deployment realiti=
es. =A0And in reality all of this is going to need a dynamic service somewh=
ere for each non-trivial site, this is all just a question of how to hook i=
t up.






--
John Panzer / Google
jpanzer@google.com=A0/=A0abstra=
ctioneer.org=A0/ @jpanzer



=A0


=A0
On Wed, Jul 4, 2012 a=
t 3:36 PM, Mark Nottingham <mnot@mnot.net> wrote:



On 05/07/2012, at 8:16 AM, =
John Panzer wrote:

> Just as a historical note. =A0The envisioned=
 usage of host-meta was originally to avoid a specification which mandated =
a particular dynamic URL API at a particular /.well-known endpoint (because=
 it may not be feasible to do that across all organizations and deployments=
). =A0The host-meta document itself would be highly cacheable and so wouldn=
't incur an additional network trip in the common case.


>
> Having a 3xx redirect is a reasonable alternative that allows =
a similar escape hatch via something like mod_rewrite, albeit at the cost o=
f needing an additional network trip each time. =A0Since a deployment can a=
lways avoid the 3xx redirect with additional dynamic plumbing behind the we=
ll-known endpoint, I don't think that's a horrible thing.


>
> An application-level redirect would be almost equivalent to an=
 HTTP redirect, but then there are two ways to do the same thing. =A0If _on=
ly_ an application-level redirect is allowed, then you have to have at leas=
t a minimal dynamic service at the well-known endpoint (no more mod_rewrite=
). =A0But the whole reason for this is to avoid the requirement for a dynam=
ic service behind well-known...



"dynamic" and "static"=
; are properties of the implementation, not the interface. HTTP doesn't=
 require that any particular URL be "dynamic"; anything can, with=
 the right metadata, be cached (and indeed, I've cached many, many thin=
gs with the wrong metadata, because of silly site operators and their ideas=
 about "dynamic").



Now, if people want to target a particular implementation that makes it=
 easier to serve a particular style of URL without writing code, fine, but =
let's not confuse things.

E.g., a URL like

http://example.c=
om/.well-known/user/bob



is easy to serve in pretty much any way you like with Apache.

I&=
#39;m also going to push back on the "it may not be feasible to do tha=
t across all organizations and deployments" motivation. This is a race=
 to the bottom. The trick is to make it accessible enough to get sufficient=
 traction to pull everyone along, without pandering to *everyone*'s req=
uirements.



Regards,

--
Mark Nottingham =A0=A0=
http://www.mnot.net/






=
=A0







________________=
_______________________________

apps-discuss mailing list
apps-discuss@ietf.org



https://www.ietf.org/mailman/listinfo/apps-discuss



=A0


_________=
______________________________________
apps-discuss mailing list
apps-discuss@ietf=
.org


https://www.ietf.org/mailman/listinfo/apps-discuss



apps-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/apps-discuss





--f46d042de88beb5ce004c86b831c--

From wmills@yahoo-inc.com  Wed Aug 29 11:25:31 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9BE21F84F5 for ; Wed, 29 Aug 2012 11:25:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.557
X-Spam-Level: 
X-Spam-Status: No, score=-17.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfVYrpcfMJZS for ; Wed, 29 Aug 2012 11:25:28 -0700 (PDT)
Received: from nm20-vm1.bullet.mail.ne1.yahoo.com (nm20-vm1.bullet.mail.ne1.yahoo.com [98.138.91.21]) by ietfa.amsl.com (Postfix) with SMTP id 59C2621F84E2 for ; Wed, 29 Aug 2012 11:25:28 -0700 (PDT)
Received: from [98.138.90.49] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 29 Aug 2012 18:25:25 -0000
Received: from [98.138.226.166] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 29 Aug 2012 18:25:25 -0000
Received: from [127.0.0.1] by omp1067.mail.ne1.yahoo.com with NNFMP; 29 Aug 2012 18:25:25 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 72621.80152.bm@omp1067.mail.ne1.yahoo.com
Received: (qmail 9488 invoked by uid 60001); 29 Aug 2012 18:25:24 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346264724; bh=aDxwqA2if7yWGBdGif3LAcHwBrB6dXohr5oLt/RAMJw=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=WT0RJghvV4QC+yXdjs089uCTpoQUn1Ycj5iXTdgTeJ6SGJzZ8ufwK8KznM0fifAcgZFxcsisKs4JloH/Kin/XVIcmHD2HIa+//QjpZG3tRnKjGP7LcT4Qg3D2dGxjH5LBWyqB50g8wVs8z0C4VSAxtijDK8ZvuJ1Dd8nHJ+Rax0=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=YUeUz+GaLy5UoDSDAXxp/nuq97g+UU55dWr1EDNr+WrOTRnQU/x3u35dwi2wgTwduWeSpSJSiqG9ZLcXP9py5s1BhVO2amaX58oMdZzBMgpup2aUFNlH5CR7H10ITo4TvCyIyviG2IjYe0zpZdHNo6sI6zOpKjfs+bTHRIqLUYc=;
X-YMail-OSG: X4teYlcVM1mGD5Vf9JxKfdk2INxDhPflSPmp7UGhPihqNq. cNOWTCx1OF2lDvix101LDtUagJl5jKLOK.JoxhfRqsVDFDcjJKs0fAXbvKpq 04pilvSi5foftSsHvnUvHc4RxQjj.5HU.GAKzWTFymTAQ0_or8nxLgS4Zdl3 tPOPJG9vxT.JS5Qq2o35FXgpIiei8FjV_seVHQEKdwdzBfUj4kpOO5EpxsJc 9kLtZCwOSeMSDypiqaILnx_D13RtShvqcYNBNodOsichu6eOnMVMGeMCI.Uh LYs281Hmxj9czMxJpbYtQfaZ.CYCQXaUxj7EvpWQRzMakXRj.27HPosTGqgk ew0oPRi_fL.JjgGcj9yyongqNM6_C3Hknr2GdoxWRXbeuZtAPTqr62IbYeOg LVK.UtFMiT1nGUTExr5.DSkQC.MwS3BvOld8aY6ezwfGh.thST1jq3kjwxZ5 x1zv8a6IGgfd3FWl9THlXCF9wxDjue.1oiaYR.7rGMHggufcwGfNhXEfYjTq S1aRAmgGU3BDU8Yb8u1y697FO1XiSLd7LZNAyO17lDW2VP.QjqFAwX9zZyTK MgtFcfEaJqkjSe7ggQaLzslOzMS4DvPPXh1X8246uvzrYjDAsVF2moD3wmN0 9UmqZr2em9qRRwWqpFdaq_eXHi69QJIHeIxznMHNx3HHzsw9raRr4ehwK8Oi wIEODQVS9ddgvVUv8Md5iOq05Xf_Sc1izh8KWetaQfh3Jw6kWSjvmm46j.5Y gVI8xY0kqgX94HeO67.d_X4T8JqOp4wtYzLB2qctDiRvVMS1VcVsZDhOev2V 2umR9l3a8mm6un2NsbjhjX4MwpG7e2.2d_ZgV039g1hy1Cprx368plV1XGjL FpBPSl8LvoGF4DIVzfMNwZa0wa6il7MMO5aiK1jxpSJtO9JZorxSw7AkaPQA 8KBBPsSMhOecvYkMMRsAe_x8fN2dDBQg.8EZaIKcLWDYGKiM6QIbxoi47Hkr _on6_9bMMvETuMpwm0jEy2niBIE2nlCdGhhP3pBhitFnpfm6opCpCoINaSrE ViVpAUUP1nUYL1n3jBfut.XAsgA2NbQQnu38ZfdsT2maoy9qV2qGEiV_BKEX _4Twq.dHLtItGmCvOUAd_pu5KnZYWy4Bvu.jYmvZEPywqohG73KRO26rnQFE kNVHN4GtAxbE.SHCtRrckoLJdJ4Aqsd2FPqwS
Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Wed, 29 Aug 2012 11:25:24 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.121.416
References:  <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com>   <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com>      <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net>  <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com> <032d01cd8597$aac7f740$0057e5c0$@packetizer.com>  <046501cd860c$da464420$8ed2cc60$@packetizer.com> <287CDD14-DEC2-40AD-AD5D-DC102D5AAAE6@ve7jtb.com>
Message-ID: <1346264724.64690.YahooMailNeo@web31813.mail.mud.yahoo.com>
Date: Wed, 29 Aug 2012 11:25:24 -0700 (PDT)
From: William Mills 
To: John Bradley , "Paul E. Jones" 
In-Reply-To: <287CDD14-DEC2-40AD-AD5D-DC102D5AAAE6@ve7jtb.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="767760015-957896998-1346264724=:64690"
Cc: Mark Nottingham , IETF Apps Discuss 
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Aug 2012 18:25:31 -0000

--767760015-957896998-1346264724=:64690
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Actually my suggestion of using MX records actually was forwarded to the li=
st from a conversation with Breno from Google as I remember, as a more work=
able but definitely not ideal solution.=0A=0A=0A=0A=0A=0A>_________________=
_______________=0A> From: John Bradley =0A>To: Paul E. J=
ones  =0A>Cc: Mark Nottingham ; IETF =
Apps Discuss  =0A>Sent: Wednesday, August 29, 2012 1=
0:57 AM=0A>Subject: Re: [apps-discuss] Looking at Webfinger=0A> =0A>=0A>I a=
m not the best person to represent Google's needs.=0A>=0A>=0A>However as I =
understand it Google hosts applications such as email documents openID for =
tens of thousands of domains.=0A>Google themselves don't control the DNS.=
=0A>=0A>=0A>The people using the service generally add some MX records for =
aspmx.l.google.com. and a Cname for mail.example.com to=C2=A0ghs.google.com=
.=0A>=0A>=0A>The A record for the bare domain typically points off to some =
Content management site the company uses for their web pages.=0A>=0A>=0A>I =
think this is probably typical of Yahoo's mail hosting services and others.=
 =C2=A0=C2=A0=0A>=0A>=0A>The service hosing the email/authentication/openID=
 is not the one that controls the web server for company.=0A>=0A>=0A>Saying=
 the CMS venders will provide WebFinger services doesn't seem all that like=
ly, especially in virtual hosting environments.=0A>=0A>=0A>Getting a typica=
l company to do anything more than enter a cname for webfinger.example.org =
is wildly optimistic.=0A>=0A>=0A>I am entirely open to Ideas on this. =C2=
=A0 However the previous solution of having every RP check with google firs=
t to see if they host the email and provide the XRDS seems horribly flawed =
to me.=0A>=0A>=0A>I would like to see a workable solution at the discovery =
layer that accommodates how people deploy there sites.=0A>=0A>=0A>I think B=
ill suggested at one point using the MX record to find the webfinger host. =
=C2=A0That has a bunch of problems I would prefer to avoid.=0A>=0A>=0A>John=
 B.=0A>=0A>=0A>On 2012-08-29, at 1:36 PM, "Paul E. Jones"  wrote:=0A>=0A>John,=0A>>=C2=A0=0A>>Well, we need to figure out how t=
o address this.=0A>>=C2=A0=0A>>Would it be reasonable to redirect requests =
from /.well-known/host-meta.json and /.well-known/host-meta to Google?=0A>>=
=C2=A0=0A>>Are there other services or files under /.well-known that Google=
=E2=80=99s customers would not want Google to host?=C2=A0 If they were OK w=
ith Google=E2=80=99s servers responding to anything , then one could put an=
 A (or CNAME) record in place for=C2=A0example.com=C2=A0that points to Goog=
le.=0A>>=C2=A0=0A>>Not being familiar with what Google offers, I=E2=80=99m =
a bit challenged to understand exactly what is and is not possible.=0A>>=C2=
=A0=0A>>Paul=0A>>=C2=A0=0A>>From:=C2=A0John Bradley [mailto:ve7jtb@ve7jtb.c=
om]=C2=A0=0A>>Sent:=C2=A0Wednesday, August 29, 2012 10:14 AM=0A>>To:=C2=A0P=
aul E. Jones=0A>>Cc:=C2=A0'George Fletcher'; 'Mark Nottingham'; 'IETF Apps =
Discuss'=0A>>Subject:=C2=A0Re: [apps-discuss] Looking at Webfinger=0A>>=C2=
=A0=0A>>There mite be a A record but that typically goes off to some virtua=
l web hosting company and not the email service provider.=0A>>=C2=A0=0A>>I =
think I have also heard William say this is a problem for Yahoo.=0A>>=C2=A0=
=0A>>Google was not able to get people to deploy XRDS for hosted domains. =
=C2=A0 They came up with a proprietary extension to openID discovery to mak=
e hosted google apps domains work with some subset of RP.=0A>>=C2=A0=0A>>Th=
e problem is that the company hosting a small businesses website is unlikel=
y to provide the web finger infrastructure and there is no way for the emai=
l/openID provider to do it without their cooperation.=0A>>=C2=A0=0A>>Adding=
 a A record rather than a CNAME is generally not a good idea if it can be a=
voided. =C2=A0 In the event of the provider changing an IP address it break=
s all the customers if they have used A records, but that is separate issue=
. =C2=A0=0A>>=C2=A0=0A>>You can set up webfinger on your web server and man=
age it. =C2=A0 It just won't work for large numbers of people as we have it=
 now. =C2=A0=0A>>=C2=A0=0A>>If webfinger won't work for Google Apps for Dom=
ains and other hosted services like that then It will significantly impact =
adoption in my opinion.=0A>>=C2=A0=0A>>We will also need to work around tha=
t for Connect. =C2=A0We don't want another proprietary work around with the=
 security problems that can entail.=0A>>=C2=A0=0A>>John B.=0A>>=C2=A0=0A>>O=
n 2012-08-28, at 11:37 PM, "Paul E. Jones"  wrote:=
=0A>>=0A>>=0A>>=0A>>John,=0A>>=C2=A0=0A>>If Google is hosting the domain or=
 any other service provider, wouldn=E2=80=99t there still be an A record fo=
r the domain (e.g.,packetizer.com)?=C2=A0 I know there is for virtually eve=
ry web hosting company I=E2=80=99ve used.=C2=A0 It seems like this might ju=
st be one more hosted service Google could provide to its customers, no?=0A=
>>=C2=A0=0A>>I do not know exactly how this hosted service works, but what=
=E2=80=99s hosted?=C2=A0 I assume it=E2=80=99s just email.=C2=A0 If web, th=
en I see no issue.=C2=A0 If only email, then the user just needs to have MX=
 records pointing to Google and an A record pointing to whatever service ru=
ns the WebFinger service.=0A>>=C2=A0=0A>>In any case, if they can add a CNA=
ME or MX record, I think we can get them to add an A record.=C2=A0 I think =
it would be far more challenging for SMBs to add a host like=C2=A0webfinger=
.example.com.=C2=A0 That would still require an A record and a service prov=
ider capable of supporting it.=0A>>=C2=A0=0A>>Paul=0A>>=C2=A0=0A>>From:=C2=
=A0John Bradley [mailto:ve7jtb@ve7jtb.com]=C2=A0=0A>>Sent:=C2=A0Tuesday, Au=
gust 28, 2012 3:29 PM=0A>>To:=C2=A0Paul E. Jones=0A>>Cc:=C2=A0'George Fletc=
her'; 'Mark Nottingham'; 'IETF Apps Discuss'=0A>>Subject:=C2=A0Re: [apps-di=
scuss] Looking at Webfinger=0A>>=C2=A0=0A>>There are cases where there are =
hosted domains (Google etc) that may not have a http host for the domain na=
me used in the users email address. =C2=A0=0A>>=C2=A0=0A>>There may be meri=
t to having a=C2=A0webfinger.example.com=C2=A0fallback where the client can=
't reach the .well-known for the primary host.=0A>>=C2=A0=0A>>I know that s=
ome sort of SRV record would be the correct way to do it, but in the real w=
orld SMB don't enter SRV records even if there DNS provider support them.=
=0A>>The most you can get them to do is add a CNAME or MX record.=0A>>=C2=
=A0=0A>>Supporting these sorts of domains somehow is a important issue.=0A>=
>=C2=A0=0A>>John B.=0A>>=C2=A0=0A>>On 2012-08-28, at 3:17 PM, "Paul E. Jone=
s"  wrote:=0A>>=0A>>=0A>>=0A>>=0A>>George,=0A>>=C2=
=A0=0A>>I believe it might be useful to introduce those who break your WebF=
inger server to Louisville Slugger. :)=0A>>=C2=A0=0A>>Your pain is understo=
od, but I do not see a way to avoid it.=C2=A0 We could introduce something =
in DNS, but that would also present challenges.=C2=A0 No matter where we =
=E2=80=9Croot=E2=80=9D the discovery process, there is a potential somebody=
 could break it.=C2=A0 It could be rooted somewhere other than the root of =
the domain (e.g.,=C2=A0webfinger.example.com), but we either need to decide=
 in advance of such a location or introduce a way to discovery the discover=
y resources.=0A>>=C2=A0=0A>>Do you have a suggestion that would make this l=
ess likely to be broken?=0A>>=C2=A0=0A>>Paul=0A>>=C2=A0=0A>>From:=C2=A0apps=
-discuss-bounces@ietf.org=C2=A0[mailto:apps-discuss-bounces@ietf.org]=C2=A0=
On Behalf Of=C2=A0George Fletcher=0A>>Sent:=C2=A0Tuesday, August 28, 2012 1=
1:09 AM=0A>>To:=C2=A0Mark Nottingham=0A>>Cc:=C2=A0IETF Apps Discuss=0A>>Sub=
ject:=C2=A0Re: [apps-discuss] Looking at Webfinger=0A>>=C2=A0=0A>>Way "late=
 to the party" but I can speak from experience that deployment can be a rea=
l issue in some environments. It's all really straight forward in a small c=
ompany or an environment where the identity team "owns" the root domain (e.=
g.=C2=A0example.com). However, if an entire other group in a large organiza=
tion "owns" the root domain (home page for the site) and the identity team =
then needs to get them to make changes, the deployment solution gets brittl=
e pretty quick. I've had our webfinger support broken at least twice becaus=
e the "other" team didn't know that certain configs were required:)=0A>>=0A=
>>Also, installing the "dynamic pluming" can be more problematic is these c=
ases. It is possible to get apache rewrite rules or netscaler magic in plac=
e to make it work, it's just a more brittle deployment architecture.=0A>>=
=0A>>Thanks,=0A>>George=0A>>On 7/4/12 6:58 PM, John Panzer wrote:=0A>>Mark =
-- Of course I was speaking about practical realities of typical web server=
 administration and deployment. =C2=A0In practical terms, adding a new mod_=
rewrite rule or moral equivalent is going to be easier than adding a new PH=
P script that connects to a database. =C2=A0The latter is just always going=
 to be a much higher bar.=0A>>>=C2=A0=0A>>>And, something that returns per-=
user data is generally going to need a dynamic service of some kind, unless=
 your site has just a handful of users and you don't mind going through a p=
ublishing exercise each time you add or change a user...=0A>>>=C2=A0=0A>>>N=
one of this has anything to do with the interface, just deployment realitie=
s. =C2=A0And in reality all of this is going to need a dynamic service some=
where for each non-trivial site, this is all just a question of how to hook=
 it up.=0A>>>=0A>>>=0A>>>--=0A>>>John Panzer / Google=0A>>>jpanzer@google.c=
om=C2=A0/=C2=A0abstractioneer.org=C2=A0/ @jpanzer=0A>>>=C2=A0=0A>>>=C2=A0=
=0A>>>On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham  wrote=
:=0A>>>On 05/07/2012, at 8:16 AM, John Panzer wrote:=0A>>>=0A>>>> Just as a=
 historical note. =C2=A0The envisioned usage of host-meta was originally to=
 avoid a specification which mandated a particular dynamic URL API at a par=
ticular /.well-known endpoint (because it may not be feasible to do that ac=
ross all organizations and deployments). =C2=A0The host-meta document itsel=
f would be highly cacheable and so wouldn't incur an additional network tri=
p in the common case.=0A>>>>=0A>>>> Having a 3xx redirect is a reasonable a=
lternative that allows a similar escape hatch via something like mod_rewrit=
e, albeit at the cost of needing an additional network trip each time. =C2=
=A0Since a deployment can always avoid the 3xx redirect with additional dyn=
amic plumbing behind the well-known endpoint, I don't think that's a horrib=
le thing.=0A>>>>=0A>>>> An application-level redirect would be almost equiv=
alent to an HTTP redirect, but then there are two ways to do the same thing=
. =C2=A0If _only_ an application-level redirect is allowed, then you have t=
o have at least a minimal dynamic service at the well-known endpoint (no mo=
re mod_rewrite). =C2=A0But the whole reason for this is to avoid the requir=
ement for a dynamic service behind well-known...=0A>>>"dynamic" and "static=
" are properties of the implementation, not the interface. HTTP doesn't req=
uire that any particular URL be "dynamic"; anything can, with the right met=
adata, be cached (and indeed, I've cached many, many things with the wrong =
metadata, because of silly site operators and their ideas about "dynamic").=
=0A>>>=0A>>>Now, if people want to target a particular implementation that =
makes it easier to serve a particular style of URL without writing code, fi=
ne, but let's not confuse things.=0A>>>=0A>>>E.g., a URL like=0A>>>=0A>>>ht=
tp://example.com/.well-known/user/bob=0A>>>=0A>>>is easy to serve in pretty=
 much any way you like with Apache.=0A>>>=0A>>>I'm also going to push back =
on the "it may not be feasible to do that across all organizations and depl=
oyments" motivation. This is a race to the bottom. The trick is to make it =
accessible enough to get sufficient traction to pull everyone along, withou=
t pandering to *everyone*'s requirements.=0A>>>=0A>>>Regards,=0A>>>=0A>>>--=
=0A>>>Mark Nottingham =C2=A0=C2=A0http://www.mnot.net/=0A>>>=0A>>>=0A>>>=0A=
>>>=0A>>>=0A>>>=C2=A0=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>____________=
___________________________________=0A>>>apps-discuss mailing list=0A>>>app=
s-discuss@ietf.org=0A>>>https://www.ietf.org/mailman/listinfo/apps-discuss=
=0A>>=C2=A0=0A>>_______________________________________________=0A>>apps-di=
scuss mailing list=0A>>apps-discuss@ietf.org=0A>>https://www.ietf.org/mailm=
an/listinfo/apps-discuss=0A>=0A>___________________________________________=
____=0A>apps-discuss mailing list=0A>apps-discuss@ietf.org=0A>https://www.i=
etf.org/mailman/listinfo/apps-discuss=0A>=0A>=0A>
--767760015-957896998-1346264724=:64690
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Actually =
my suggestion of using MX records actually was forwarded to the list from a=
 conversation with Breno from Google as I remember, as a more workable but =
definitely not ideal solution.


  
 
 
  
  From: John Bradley <ve7jtb@ve=
7jtb.com>
 To: Paul =
E. Jones <paulej@packetizer.com> 
Cc: Mark Nottingham <mnot@mnot.net>; IETF Apps Dis=
cuss <apps-discuss@ietf.org> 
 Sent: Wednesday, August 29, 2012 10:57 AM
 Subject: Re: [apps-discuss] Looking at W=
ebfinger
  
 
I am n=
ot the best person to represent Google's needs.

However =
as I understand it Google hosts applications such as email documents openID=
 for tens of thousands of domains.
Google themselves don't contro=
l the DNS.

The people using the service generally =
add some MX records for aspmx.l.google.com. and a Cname for mail.example.co=
m to ghs.google.com.

The A record for the bare domain typically points off to some Content ma=
nagement site the company uses for their web pages.

I think this is probably typical of Yahoo's mail hosting services and oth=
ers.   

The service hosing the email/aut=
hentication/openID is not the one that controls the web server for company.=


Saying the CMS venders will provide WebFinger ser=
vices doesn't seem all that likely, especially in virtual hosting environme=
nts.

Getting a typical company to do anything more=
 than enter a cname for webfinger.example.org is wildly optimistic.

I am entirely open to Ideas on this.   However=
 the previous solution of having every RP check with google first to see if
 they host the email and provide the XRDS seems horribly flawed to me.

I would like to see a workable solution at the discove=
ry layer that accommodates how people deploy there sites.

I think Bill suggested at one point using the MX record to find the=
 webfinger host.  That has a bunch of problems I would prefer to avoid=
.

John B.

On 2012-08-29, a=
t 1:36 PM, "Paul E. Jones" <pa=
ulej@packetizer.com> wrote:

 
Well, we need to figure out how to address this.
 
Would it be reasonable to redirect requests from /.well-known/host-m=
eta.json and /.well-known/host-meta to Google?
 
Are there othe=
r services or files under /.well-known that Google=E2=80=99s customers woul=
d not want Google to host?  If they were OK with Google=E2=80=99s serv=
ers responding to anything , then one could put an A (or CNAME) record in p=
lace for example.com that points to Googl=
e.
 
Not being familiar with what Google offers, I=E2=80=99m =
a bit challenged to understand exactly what is and is not possible.<=
/div>
 
Paul
 
From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent:=
 Wednesday, =
August 29, 2012 10:14 AM
To: Paul E. Jones
Cc: 'George Fletcher'; 'Mark Notting=
ham'; 'IETF Apps Discuss'
Subject: Re: [apps-discuss] Looking at Webfinger
  
There =
mite be a A record but that typically goes off to some virtual web hosting =
company and not the email service provider.

  
I think I have also heard William =
say this is a problem for Yahoo.
  
Google was not able to get people to deploy=
 XRDS for hosted domains.   They came up with a proprietary extension =
to openID discovery to make hosted google apps domains work with some subse=
t of RP.
  
The problem is that the company hosting a small businesses website =
is unlikely to provide the web finger infrastructure and there is no way fo=
r
 the email/openID provider to do it without their cooperation.
<=
div>
  
Adding a A re=
cord rather than a CNAME is generally not a good idea if it can be avoided.=
   In the event of the provider changing an IP address it breaks all t=
he customers if they have used A records, but that is separate issue.  =
;
  
You can set up webfinger on your web server and manage it.   It just =
won't work for large numbers of people as we have it now.  
  
If webfinger =
won't work for Google Apps for Domains and other hosted services like that =
then It will significantly impact adoption in my opinion.
<=
div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New =
Roman', serif;">  
We will also need =
to work around that for Connect.  We don't want another proprietary wo=
rk around with the security problems that can entail.
  
John B.
  
On 2012-08-28, at =
11:37 PM, "Paul E. Jones" <paulej@packetizer.com>=
; wrote:


John,
&n=
bsp;
If Google is hosting the domain or any other service provider, wouldn=E2=
=80=99t there still be an A record for the domain (e.g.,packetizer.com)?  I know there is for virtually every web hosting company I=E2=
=80=99ve used.  It seems like this might just be one more hosted servi=
ce Google could provide to its customers, no?
I do not know exactly how this hosted service works, but what=E2=80=
=99s hosted?  I assume it=E2=80=99s just email.  If web, then I s=
ee no issue.  If only email, then the user just needs to have MX recor=
ds pointing to Google and an A record pointing to whatever service runs the=
 WebFinger service.
&nb=
sp;
In any case, if the=
y can add a CNAME or MX record, I think we can get them to add an A record.=
  I think it would be far more challenging for SMBs to add a host like=
 webfinger=
.example.com.  That would still require an A record and a s=
ervice provider capable of supporting it.
 
Paul
 
From: John Bradley [mailto:ve7jtb@ve7jtb.com]=
 
Sent: Tuesday, August 28, 2012 3:29 PM
To: Paul E. JonesCc: =
'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
Subject: Re: [apps-=
discuss] Looking at Webfinger
 
There are cases where there are ho=
sted domains (Google etc) that may not have a http host for the domain name=
 used in the users email address.  
&=
nbsp;
There may be merit to having a webfinger=
.example.com&=
nbsp;fallback where the client can't reach the .well-known for the p=
rimary host.
 
The most you can ge=
t them to do is add a CNAME or MX record.
 
Supporting these sorts of domains somehow is a=
 important issue.
 
<=
div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New =
Roman', serif;">John B.
 
=

On 2012-08-28, at 3:17 PM, "Paul E. Jones" <<=
a rel=3D"nofollow" ymailto=3D"mailto:paulej@packetizer.com" target=3D"_blan=
k" href=3D"mailto:paulej@packetizer.com" style=3D"color:purple;text-decorat=
ion:underline;">paulej@packetizer.com<=
/a>>
 wrote:



=

George,
 
I =
believe it might be useful to introduce those who break your WebFinger serv=
er to Louisville Slugger. :)
 
Your pain=
 is understood, but I do not see a way to avoid it.  We could introduc=
e something in DNS, but that would also present challenges.  No matter=
 where we =E2=80=9Croot=E2=80=9D the discovery process, there is a potentia=
l somebody could break it.  It could be rooted somewhere other than th=
e root of the domain (e.g., webfinger.example.com), but we either nee=
d to decide in advance of such a location or introduce a way to discovery t=
he discovery
 resources.
 
Do you have a suggestion th=
at would make this less likely to be broken?
 
Paul
 
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of George Fletcher
Sent: Tuesday, August 28, 2012 11:09 AM
To: Mark Nottingha=
m
Cc: IETF Apps Discuss
Subject: Re: [apps-discuss] Looking at
 Webfinger
 
=

Way "late to the party" but I can speak from experien=
ce that deployment can be a real issue in some environments. It's all reall=
y straight forward in a small company or an environment where the identity =
team "owns" the root domain (e.g. example.com). However, if an entire other gro=
up in a large organization "owns" the root domain (home page for the site) =
and the identity team then needs to get them to make changes, the deploymen=
t solution
 gets brittle pretty quick. I've had our webfinger support broken at least =
twice because the "other" team didn't know that certain configs were requir=
ed:)

Also, installing the "dynamic pluming" can be more problematic =
is these cases. It is possible to get apache rewrite rules or netscaler mag=
ic in place to make it work, it's just a more brittle deployment architectu=
re.

Thanks,
George
On 7/4/12 6:=
58 PM, John Panzer wrote:
Mark -- Of course I was speaking ab=
out practical realities of typical web server administration and deployment=
.  In practical terms, adding a new mod_rewrite rule or moral equivale=
nt is going to be easier than adding a new PHP script that connects to a
 database.  The latter is just always going to be a much higher bar.
 
And=
, something that returns per-user data is generally going to need a dynamic=
 service of some kind, unless your site has just a handful of users and you=
 don't mind going through a publishing exercise each time you add or change=
 a user...
 
None of this has anything to do with the interface, just deploymen=
t realities.  And in reality all of this is going to need a dynamic se=
rvice somewhere for each non-trivial site, this is all just a question of
 how to hook it up.

--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer
 
 
On Wed, Jul 4, 2012 at 3:36 PM, M=
ark Nottingham <mnot@mnot.net&=
gt; wrote:
On=
 05/07/2012, at 8:16 AM, John Panzer wrote:

> Just as a historica=
l note.  The envisioned usage of host-meta was originally to avoid a s=
pecification which mandated a particular dynamic URL API at a particular /.=
well-known endpoint (because it may not be feasible to do that across all o=
rganizations
 and deployments).  The host-meta document itself would be highly cach=
eable and so wouldn't incur an additional network trip in the common case.<=
br>>
> Having a 3xx redirect is a reasonable alternative that allo=
ws a similar escape hatch via something like mod_rewrite, albeit at the cos=
t of needing an additional network trip each time.  Since a deployment=
 can always avoid the 3xx redirect with additional dynamic plumbing behind =
the well-known endpoint, I don't think that's a horrible thing.
>
=
> An application-level redirect would be almost equivalent to an HTTP re=
direct, but then there are two ways to do the same thing.  If _only_ a=
n application-level redirect is allowed, then you have to have at least a m=
inimal dynamic service at the well-known endpoint (no more mod_rewrite). &n=
bsp;But the whole reason for this is to avoid the requirement for a dynamic=
 service behind well-known...
"dynami=
c" and "static" are properties of the implementation, not the interface. HT=
TP doesn't require that any particular URL be "dynamic"; anything can, with=
 the right metadata, be cached (and indeed, I've cached many, many things w=
ith the wrong metadata, because of silly site operators and their ideas abo=
ut "dynamic").

Now, if people want to target a particular implementa=
tion that makes it easier to serve a particular style of URL without writin=
g code, fine, but let's not confuse things.

E.g., a URL like

=
http://example.com/.well-known/user/bob
is easy to serve in pretty much any way you like with Apache.

I'm =
also going to push back on the "it may not be feasible to do that across al=
l
 organizations and deployments" motivation. This is a race to the bottom. T=
he trick is to make it accessible enough to get sufficient traction to pull=
 everyone along, without pandering to *everyone*'s requirements.

Reg=
ards,

--<=
br>Mark Nottingham   http://www.mnot.net/




=

 
<=
br>



______________________=
_________________________
apps-discuss mailing list
<=
a rel=3D"nofollow" ymailto=3D"mailto:apps-discuss@ietf.org" target=3D"_blan=
k" href=3D"mailto:apps-discuss@ietf.org" style=3D"color:purple;text-decorat=
ion:underline;">apps-discuss@ietf.org<=
/a>
https://www.ietf.org/mailman/lis=
tinfo/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
h=
ttps://www.ietf.org/mailman/listinfo/apps-discuss


 
  
   

--767760015-957896998-1346264724=:64690--

From perpetual-tripper@wwelves.org  Wed Aug 29 13:15:50 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD6E21F8475 for ; Wed, 29 Aug 2012 13:15:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level: 
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmX3bzuH7ZHu for ; Wed, 29 Aug 2012 13:15:49 -0700 (PDT)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB7011E80F1 for ; Wed, 29 Aug 2012 13:15:49 -0700 (PDT)
X-Originating-IP: 217.70.178.139
Received: from mfilter10-d.gandi.net (mfilter10-d.gandi.net [217.70.178.139]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 5277F172074; Wed, 29 Aug 2012 22:15:33 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter10-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter10-d.gandi.net (mfilter10-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id k3Ng6dB1uFAx; Wed, 29 Aug 2012 22:15:31 +0200 (CEST)
X-Originating-IP: 217.11.53.243
Received: from localhost (243.53.11.217.in-addr.arpa.manitu.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id DA60917207C; Wed, 29 Aug 2012 22:15:31 +0200 (CEST)
Content-Type: text/plain; charset=UTF-8
From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= 
To: webfinger , apps-discuss 
In-reply-to: 
Date: Wed, 29 Aug 2012 20:15:31 +0000
Message-Id: <1346268407-sup-3223@heahdk.net>
User-Agent: Sup/0.12.1
Content-Transfer-Encoding: quoted-printable
Subject: [apps-discuss] webfinger: .well-known/acct/nick approach (was: Proposed changes to WebFinger regarding XML vs JSON)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Aug 2012 20:15:50 -0000

Excerpts from Melvin Carvalho's message of 2012-08-28 12:23:06 +0000:
> From the discussions, so far, I like the idea from mnot of using
> .well-known/user/bob as being simple, intuitive and easy to implement

I also see some advantages of using convention like:
https://example.net/.well-known/acct/nick for nick@example.net

Two of the reasons for acct instead of user:
* We have acct: scheme cooking on separate burner
* I can see place for *collective*/*shared* accounts for which user might=
 imply an individual in a confusing way

Besides that, I see topic of advantage in having an option of using stati=
c files coming up again, having written myself my first XRD profile by ha=
nd, I can't deny it having practical use :) I don't remember details of d=
ebate on requesting all account info vs element by element, but couldn't =
we try to solve it with something like:

https://example.net/.well-known/acct/nick
responding with full profile, or whatever one wants to publish as it

https://example.net/.well-known/acct/nick/some_element
responding with just given part of profile

both could work with generating them on request or just with static files

Also it could handle case which I would like to have available as well fo=
r acct:example.net type accounts (without local part) by mapping it simpl=
y to:

https://example.net/.well-known/acct

but in such case for selected elements it might require introducing reser=
ved path part like /.el/ or something:
https://example.net/.well-known/acct/.el/some_element

and for our dear nick@example.net then:

https://example.net/.well-known/acct/nick/.el/some_element

?

From wmills@yahoo-inc.com  Wed Aug 29 13:31:40 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E6811E80EC for ; Wed, 29 Aug 2012 13:31:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.408
X-Spam-Level: 
X-Spam-Status: No, score=-17.408 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SELQxL3JCuZZ for ; Wed, 29 Aug 2012 13:31:39 -0700 (PDT)
Received: from nm12-vm1.bullet.mail.ne1.yahoo.com (nm12-vm1.bullet.mail.ne1.yahoo.com [98.138.91.41]) by ietfa.amsl.com (Postfix) with SMTP id 20FFC11E80EA for ; Wed, 29 Aug 2012 13:31:38 -0700 (PDT)
Received: from [98.138.90.48] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 29 Aug 2012 20:31:33 -0000
Received: from [98.138.89.199] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 29 Aug 2012 20:31:33 -0000
Received: from [127.0.0.1] by omp1057.mail.ne1.yahoo.com with NNFMP; 29 Aug 2012 20:31:33 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 695240.4796.bm@omp1057.mail.ne1.yahoo.com
Received: (qmail 31271 invoked by uid 60001); 29 Aug 2012 20:31:33 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346272293; bh=EfVxq5RC3eMu0WBsuwsk1ClfI2jm6pc/hfgavUOLybQ=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=rMuxMQV5uPsnOnLdrb7YsQEmRuxJoDugWifNCDE8GXHgoi7ToyMS36ZcrmOxPCWYXu/9Gknfmhx46s7O5Bul9FoqXl6o2Aiyb82X8NoZGlNPB/EETtXQDrDoeqOextwvVPpUcVXu3+7JAtVEpiIgsQ9VaJLq7vVikSgJh4y1MjY=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=FVr1fFy/67Xz397T3ieTLiwnWtv0IztKEy+XDx4gRyYjC0FN+CZgWp89muzDkhHrocFnxvd9IxuBEuH3lnfa+voIVG2OeHSmqAH8C3SCmyIWBInbrYXag/A+X4vWENraUWszZRGBhyRiTjBOjPzGJdt4/GwPpwNuBNuLnsDpIWM=;
X-YMail-OSG: KbPTFSkVM1k60gj6Dt2qnYY8ZytrTWfYrg8rw83JVggGNMu Y8yrHeyua5FU06tTnw7azlYlmg_ojv3WbR4pIieEsmpdB1dBc_R0TyI7G0to jOfLUKEjSI9VQEDwwNYnZVP5eerS5rsahnx0VBjRtUGYf6xt8MpKVinhtSmw xrIP3L4UNFpbnEcHXLHNm.8lWN9vMwbjfa4Nr2_JVP44YF9uY.L3Oco.u0il 4g2BE5OIwaYjSV9SFveYV4OCuIz0HH4Zr8ZMhZDY5B_3tQZiCq4rTk8O0muQ pdpKxsIelwg06eJ8b0EOLgQOb_cU2eA_4sYPY7Z0pC3hnvU1VYRdTQjKNANH wgs1evSOS62Sc57TgKMEtVRodUQvQLr_deAWAAxdjgT4j8iVgGllO8XWO1.e B8EdviM7Z_xuHJ._SmSltTngsmdZv6exgXCsjiQ0r_7wEwGZIU8dl94fIu6. 2WGmY9_hKNi4sEzYgAOzvIOv2cS2ZslmFKXbaJ0Ev7HESrayfINOfUqLOzeh eKR5RnL7P6NwvkQ--
Received: from [209.131.62.113] by web31802.mail.mud.yahoo.com via HTTP; Wed, 29 Aug 2012 13:31:33 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.121.416
References:  <1346268407-sup-3223@heahdk.net>
Message-ID: <1346272293.31142.YahooMailNeo@web31802.mail.mud.yahoo.com>
Date: Wed, 29 Aug 2012 13:31:33 -0700 (PDT)
From: William Mills 
To: =?utf-8?B?4piuIGVsZiBQYXZsaWsg4piu?= , webfinger , apps-discuss 
In-Reply-To: <1346268407-sup-3223@heahdk.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1036955950-2045483180-1346272293=:31142"
Subject: Re: [apps-discuss] webfinger: .well-known/acct/nick approach (was: Proposed changes to WebFinger regarding XML vs JSON)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Aug 2012 20:31:40 -0000

---1036955950-2045483180-1346272293=:31142
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

As a query syntax I think path elements are a bad way to go, it's limited i=
n extensibility and flexibilty.=C2=A0 The only real advantage is cacheabili=
ty.=C2=A0 Query string parameters are better.=0A=0A=0A=0A=0A=0A>___________=
_____________________=0A> From: =E2=98=AE elf Pavlik =E2=98=AE =0A>To: webfinger ; apps-dis=
cuss  =0A>Sent: Wednesday, August 29, 2012 1:15 PM=
=0A>Subject: [apps-discuss] webfinger: .well-known/acct/nick approach (was:=
 Proposed changes to WebFinger regarding XML vs JSON)=0A> =0A>=0A>Excerpts =
from Melvin Carvalho's message of 2012-08-28 12:23:06 +0000:=0A>> From the =
discussions, so far, I like the idea from mnot of using=0A>> .well-known/us=
er/bob as being simple, intuitive and easy to implement=0A>=0A>I also see s=
ome advantages of using convention like:=0A>https://example.net/.well-known=
/acct/nick for nick@example.net=0A>=0A>Two of the reasons for acct instead =
of user:=0A>* We have acct: scheme cooking on separate burner=0A>* I can se=
e place for *collective*/*shared* accounts for which user might imply an in=
dividual in a confusing way=0A>=0A>Besides that, I see topic of advantage i=
n having an option of using static files coming up again, having written my=
self my first XRD profile by hand, I can't deny it having practical use :) =
I don't remember details of debate on requesting all account info vs elemen=
t by element, but couldn't we try to solve it with something like:=0A>=0A>h=
ttps://example.net/.well-known/acct/nick=0A>responding with full profile, o=
r whatever one wants to publish as it=0A>=0A>https://example.net/.well-know=
n/acct/nick/some_element=0A>responding with just given part of profile=0A>=
=0A>both could work with generating them on request or just with static fil=
es=0A>=0A>Also it could handle case which I would like to have available as=
 well for acct:example.net type accounts (without local part) by mapping it=
 simply to:=0A>=0A>https://example.net/.well-known/acct=0A>=0A>but in such =
case for selected elements it might require introducing reserved path part =
like /.el/ or something:=0A>https://example.net/.well-known/acct/.el/some_e=
lement=0A>=0A>and for our dear nick@example.net then:=0A>=0A>https://exampl=
e.net/.well-known/acct/nick/.el/some_element=0A>=0A>?=0A>__________________=
_____________________________=0A>apps-discuss mailing list=0A>apps-discuss@=
ietf.org=0A>https://www.ietf.org/mailman/listinfo/apps-discuss=0A>=0A>=0A>
---1036955950-2045483180-1346272293=:31142
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


As a quer=
y syntax I think path elements are a bad way to go, it's limited in extensi=
bility and flexibilty.  The only real advantage is cacheability. =
 Query string parameters are better.

  
 
 
  
  =
From: =E2=98=AE elf Pavlik =
=E2=98=AE <perpetual-tripper@wwelves.org>
 To: webfinger <webfinger@googlegroups.com>;=
 apps-discuss
 <apps-discuss@ietf.org> 
 S=
ent: Wednesday, August 29, 2012 1:15 PM
 Subject: [apps-discuss] webfinger: .well-known=
/acct/nick approach (was: Proposed changes to WebFinger regarding XML vs JS=
ON)
  
 

Excerpts from Melvin Carvalho's message of 2=
012-08-28 12:23:06 +0000:
> From the discussions, so far, I like the =
idea from mnot of using
> .well-known/user/bob as being simple, intui=
tive and easy to implement

I also see some advantages of using conve=
ntion like:
https://example.net/.well-known/acct/nick for nick@example.net=


Two of the reasons for acct instead of user:
* We have acct:=
 scheme cooking on separate burner
* I can see place for
 *collective*/*shared* accounts for which user might imply an individual in=
 a confusing way

Besides that, I see topic of advantage in having an=
 option of using static files coming up again, having written myself my fir=
st XRD profile by hand, I can't deny it having practical use :) I don't rem=
ember details of debate on requesting all account info vs element by elemen=
t, but couldn't we try to solve it with something like:

https://example=
.net/.well-known/acct/nick
responding with full profile, or whatever=
 one wants to publish as it

https://example.net/.well-know=
n/acct/nick/some_element
responding with just given part of profile<=
br>
both could work with generating them on request or just with static =
files

Also it could handle case which I would like to have available
 as well for acct:example.net type accounts (without local part) by mapping=
 it simply to:

https://example.net/.well-known/acct

but in such c=
ase for selected elements it might require introducing reserved path part l=
ike /.el/ or something:
https://example.net/.well-known/acct/.e=
l/some_element

and for our dear nick@example.net then:

<=
a href=3D"https://example.net/.well-known/acct/nick/.el/some_element" targe=
t=3D"_blank">https://example.net/.well-known/acct/nick/.el/some_element=


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


  
 
   

---1036955950-2045483180-1346272293=:31142--

From paulej@packetizer.com  Wed Aug 29 13:43:57 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC8711E80F1 for ; Wed, 29 Aug 2012 13:43:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.509
X-Spam-Level: 
X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.089,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMdoD4s0jW7L for ; Wed, 29 Aug 2012 13:43:48 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 79C2F11E80EA for ; Wed, 29 Aug 2012 13:43:48 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q7TKhj4U008559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Aug 2012 16:43:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1346273026; bh=AXoC/rje/rB+LxYfTnjUMw5B4YFAqlCDApE/Om8jPDo=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=q7TlGt5+fs4aa9QoEwaiwwJEWX291kKE3meIXXqi8DugUXzY4V8F1ErNNMmPzfhrR aNvMaZo2ueuLR4iO9DuxfswmxMAilb+YLTZszjCCW1omIIgNQfccKkmhk5SkiaYzuG 513CzKJEULFkGa6cUMN+R8KicTB05sG65YkNzW+Q=
From: "Paul E. Jones" 
To: "'John Panzer'" , "'John Bradley'" 
References:  <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com>   <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com>      <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net>  <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com> <032d01cd8597$aac7f740$0057e5c0$@packetizer.com> <046501cd860c$da464420$8ed2cc60$@packe! tizer.com> <287CDD14-DE C2-40AD-AD5D-DC102D5AAAE6@ve7jtb.com> 
In-Reply-To: 
Date: Wed, 29 Aug 2012 16:44:07 -0400
Message-ID: <04f001cd8627$092727e0$1b7577a0$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_04F1_01CD8605.82193160"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFb3Wt68HpLZ7ZyHnoKMrZHlzcyBQH14U4xAZ6Br/cCWNrQtwIOUYf2AgMXr+8B4HmqlgGhGIVxAUAhVLECgOqLOADUaqV0Ain7f7cBffnLSQIkbXUiAp1soAQC/kiSjgGrOFrXAhluBTcBspR9LJc85xYw
Content-Language: en-us
Cc: 'Mark Nottingham' , 'IETF Apps Discuss' 
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Aug 2012 20:43:57 -0000

This is a multipart message in MIME format.

------=_NextPart_000_04F1_01CD8605.82193160
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Guys,

 

John, I understand the pain of getting TLS records properly installed.  It's
no small task, for sure.  I am hoping DNSSEC and RFC 6698 might help with
this.  That sounds scary, but it's really fairly simple to configure.  Most
importantly, it can be easily automated.  I can't very well automate telling
somebody to go to a CA and buy a certificate . wait, first generate a CSR
and then. it's messy.  But, it's presently a necessary evil.

 

What I am hearing is that we must allow the host-meta{.json} resource to be
relocated.  That relocation could be via HTTP redirects (already mandatory)
or something else.  The only other mechanisms that seem extremely trivial to
me are:

 

1) TXT records (e.g., _webfinger.packetizer.com IN TXT
"https://packetizer.webfinger-provider.com/")

2) A records (e.g., webfinger.packetizer.com IN A 10.1.2.3)

3) CNAME records (e.g., webfinger.packetizer.com IN CNAME
packetizer.webfinger-provider.com.)

 

I'm not a fan of any of those, but querying "webfinger.packetizer.com" seems
like it would be the easiest alternative (meaning one could use either A or
CNAME records).

 

So, the client would issue these queries in this order

1)      https://packetizer.com/.well-known/host-meta.json

2)      https://webfinger.packetizer.com/.well-known/host-meta.json

3)      http://packetizer.com/.well-known/host-meta.json

4)      http://webfinger.packetizer.com/.well-known/host-meta.json

 

Note the ordering to ensure that TLS is attempted before insecure
connections.

 

Is this something we really need to do?  If so, it also suggests that other
services rooted in /.well-known are going to present similar issues.

 

Paul

 

From: John Panzer [mailto:jpanzer@google.com] 
Sent: Wednesday, August 29, 2012 2:13 PM
To: John Bradley
Cc: Paul E. Jones; Mark Nottingham; IETF Apps Discuss
Subject: Re: [apps-discuss] Looking at Webfinger

 

Based on experience, I'd prefer to avoid things that depend on the bare
("naked") domain (example.com instead of www.example.com or
webfinger.example.com).  I could write up the reasons but it'd take some
time.  Unfortunately, webfinger as originally spec'd requires this.

 

If we were to start over, and get to vote for whatever I wanted, and were
going to allow DNS records at all, I would probably vote for something like
webfinger.example.com as a special magic name (with the actual name chosen
so as not to collide with any existing DNS entries).  Any normal hosting
mechanisms will work here, including A records and CNAMEs and HTTP
redirects, but I'd also require everything be done via TLS with correctly
signed certificates for that subdomain (argh!  the pain!).

 

Organizationally, this would mean that any part of the organization that can
stand up a separate SSL service on a new subdomain can provide webfinger
services.  

On Wed, Aug 29, 2012 at 10:57 AM, John Bradley  wrote:

I am not the best person to represent Google's needs.

 

However as I understand it Google hosts applications such as email documents
openID for tens of thousands of domains.

Google themselves don't control the DNS.

 

The people using the service generally add some MX records for
aspmx.l.google.com. and a Cname for mail.example.com to ghs.google.com.

 

The A record for the bare domain typically points off to some Content
management site the company uses for their web pages.

 

I think this is probably typical of Yahoo's mail hosting services and
others.   

 

The service hosing the email/authentication/openID is not the one that
controls the web server for company.

 

Saying the CMS venders will provide WebFinger services doesn't seem all that
likely, especially in virtual hosting environments.

 

Getting a typical company to do anything more than enter a cname for
webfinger.example.org is wildly optimistic.

 

I am entirely open to Ideas on this.   However the previous solution of
having every RP check with google first to see if they host the email and
provide the XRDS seems horribly flawed to me.

 

I would like to see a workable solution at the discovery layer that
accommodates how people deploy there sites.

 

I think Bill suggested at one point using the MX record to find the
webfinger host.  That has a bunch of problems I would prefer to avoid.

 

John B.

 

On 2012-08-29, at 1:36 PM, "Paul E. Jones"  wrote:





John,

 

Well, we need to figure out how to address this.

 

Would it be reasonable to redirect requests from /.well-known/host-meta.json
and /.well-known/host-meta to Google?

 

Are there other services or files under /.well-known that Google's customers
would not want Google to host?  If they were OK with Google's servers
responding to anything , then one could put an A (or CNAME) record in place
for   example.com that points to Google.

 

Not being familiar with what Google offers, I'm a bit challenged to
understand exactly what is and is not possible.

 

Paul

 

From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, August 29, 2012 10:14 AM
To: Paul E. Jones
Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
Subject: Re: [apps-discuss] Looking at Webfinger

 

There mite be a A record but that typically goes off to some virtual web
hosting company and not the email service provider.

 

I think I have also heard William say this is a problem for Yahoo.

 

Google was not able to get people to deploy XRDS for hosted domains.   They
came up with a proprietary extension to openID discovery to make hosted
google apps domains work with some subset of RP.

 

The problem is that the company hosting a small businesses website is
unlikely to provide the web finger infrastructure and there is no way for
the email/openID provider to do it without their cooperation.

 

Adding a A record rather than a CNAME is generally not a good idea if it can
be avoided.   In the event of the provider changing an IP address it breaks
all the customers if they have used A records, but that is separate issue.  

 

You can set up webfinger on your web server and manage it.   It just won't
work for large numbers of people as we have it now.  

 

If webfinger won't work for Google Apps for Domains and other hosted
services like that then It will significantly impact adoption in my opinion.

 

We will also need to work around that for Connect.  We don't want another
proprietary work around with the security problems that can entail.

 

John B.

 

On 2012-08-28, at 11:37 PM, "Paul E. Jones" < 
paulej@packetizer.com> wrote:

 

John,

 

If Google is hosting the domain or any other service provider, wouldn't
there still be an A record for the domain (e.g., 
packetizer.com)?  I know there is for virtually every web hosting company
I've used.  It seems like this might just be one more hosted service Google
could provide to its customers, no?

 

I do not know exactly how this hosted service works, but what's hosted?  I
assume it's just email.  If web, then I see no issue.  If only email, then
the user just needs to have MX records pointing to Google and an A record
pointing to whatever service runs the WebFinger service.

 

In any case, if they can add a CNAME or MX record, I think we can get them
to add an A record.  I think it would be far more challenging for SMBs to
add a host like   webfinger.example.com.  That
would still require an A record and a service provider capable of supporting
it.

 

Paul

 

From: John Bradley [mailto:ve7jtb@  ve7jtb.com] 
Sent: Tuesday, August 28, 2012 3:29 PM
To: Paul E. Jones
Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
Subject: Re: [apps-discuss] Looking at Webfinger

 

There are cases where there are hosted domains (Google etc) that may not
have a http host for the domain name used in the users email address.  

 

There may be merit to having a  
webfinger.example.com fallback where the client can't reach the .well-known
for the primary host.

 

I know that some sort of SRV record would be the correct way to do it, but
in the real world SMB don't enter SRV records even if there DNS provider
support them.

The most you can get them to do is add a CNAME or MX record.

 

Supporting these sorts of domains somehow is a important issue.

 

John B.

 

On 2012-08-28, at 3:17 PM, "Paul E. Jones" < 
paulej@packetizer.com> wrote:





George,

 

I believe it might be useful to introduce those who break your WebFinger
server to Louisville Slugger. :)

 

Your pain is understood, but I do not see a way to avoid it.  We could
introduce something in DNS, but that would also present challenges.  No
matter where we "root" the discovery process, there is a potential somebody
could break it.  It could be rooted somewhere other than the root of the
domain (e.g.,   webfinger.example.com), but we
either need to decide in advance of such a location or introduce a way to
discovery the discovery resources.

 

Do you have a suggestion that would make this less likely to be broken?

 

Paul

 

From:   apps-discuss-bounces@ietf.org
[mailto:apps-  discuss-bounces@ietf.org] On
Behalf Of George Fletcher
Sent: Tuesday, August 28, 2012 11:09 AM
To: Mark Nottingham
Cc: IETF Apps Discuss
Subject: Re: [apps-discuss] Looking at Webfinger

 

Way "late to the party" but I can speak from experience that deployment can
be a real issue in some environments. It's all really straight forward in a
small company or an environment where the identity team "owns" the root
domain (e.g.   example.com). However, if an entire other
group in a large organization "owns" the root domain (home page for the
site) and the identity team then needs to get them to make changes, the
deployment solution gets brittle pretty quick. I've had our webfinger
support broken at least twice because the "other" team didn't know that
certain configs were required:)

Also, installing the "dynamic pluming" can be more problematic is these
cases. It is possible to get apache rewrite rules or netscaler magic in
place to make it work, it's just a more brittle deployment architecture.

Thanks,
George

On 7/4/12 6:58 PM, John Panzer wrote:

Mark -- Of course I was speaking about practical realities of typical web
server administration and deployment.  In practical terms, adding a new
mod_rewrite rule or moral equivalent is going to be easier than adding a new
PHP script that connects to a database.  The latter is just always going to
be a much higher bar.

 

And, something that returns per-user data is generally going to need a
dynamic service of some kind, unless your site has just a handful of users
and you don't mind going through a publishing exercise each time you add or
change a user...

 

None of this has anything to do with the interface, just deployment
realities.  And in reality all of this is going to need a dynamic service
somewhere for each non-trivial site, this is all just a question of how to
hook it up.




--
John Panzer / Google
  jpanzer@google.com /
 abstractioneer.org / @jpanzer

 

 

On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham < 
mnot@mnot.net> wrote:

On 05/07/2012, at 8:16 AM, John Panzer wrote:

> Just as a historical note.  The envisioned usage of host-meta was
originally to avoid a specification which mandated a particular dynamic URL
API at a particular /.well-known endpoint (because it may not be feasible to
do that across all organizations and deployments).  The host-meta document
itself would be highly cacheable and so wouldn't incur an additional network
trip in the common case.
>
> Having a 3xx redirect is a reasonable alternative that allows a similar
escape hatch via something like mod_rewrite, albeit at the cost of needing
an additional network trip each time.  Since a deployment can always avoid
the 3xx redirect with additional dynamic plumbing behind the well-known
endpoint, I don't think that's a horrible thing.
>
> An application-level redirect would be almost equivalent to an HTTP
redirect, but then there are two ways to do the same thing.  If _only_ an
application-level redirect is allowed, then you have to have at least a
minimal dynamic service at the well-known endpoint (no more mod_rewrite).
But the whole reason for this is to avoid the requirement for a dynamic
service behind well-known...

"dynamic" and "static" are properties of the implementation, not the
interface. HTTP doesn't require that any particular URL be "dynamic";
anything can, with the right metadata, be cached (and indeed, I've cached
many, many things with the wrong metadata, because of silly site operators
and their ideas about "dynamic").

Now, if people want to target a particular implementation that makes it
easier to serve a particular style of URL without writing code, fine, but
let's not confuse things.

E.g., a URL like

 
http://example.com/.well-known/user/bob

is easy to serve in pretty much any way you like with Apache.

I'm also going to push back on the "it may not be feasible to do that across
all organizations and deployments" motivation. This is a race to the bottom.
The trick is to make it accessible enough to get sufficient traction to pull
everyone along, without pandering to *everyone*'s requirements.

Regards,


--
Mark Nottingham     http://www.mnot.net/





 







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

 

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

 


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

 


------=_NextPart_000_04F1_01CD8605.82193160
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Guys,
 
John, I understand the pain of getting TLS records properly =
installed.  It’s no small task, for sure.  I am hoping =
DNSSEC and RFC 6698 might help with this.  That sounds scary, but =
it’s really fairly simple to configure.  Most importantly, it =
can be easily automated.  I can’t very well automate telling =
somebody to go to a CA and buy a certificate … wait, first =
generate a CSR and then… it’s messy.  But, it’s =
presently a necessary evil.
 
What I am hearing is that we must allow the host-meta{.json} resource =
to be relocated.  That relocation could be via HTTP redirects =
(already mandatory) or something else.  The only other mechanisms =
that seem extremely trivial to me are:
 
1) TXT records (e.g., _webfinger.packetizer.com IN TXT =
“https://packetizer.webfinger-provider.com/”)
2) A records (e.g., webfinger.packetizer.com IN A =
10.1.2.3)
3) CNAME records (e.g., webfinger.packetizer.com IN CNAME =
packetizer.webfinger-provider.com.)
 
I’m not a fan of any of those, but querying =
“webfinger.packetizer.com” seems like it would be the =
easiest alternative (meaning one could use either A or CNAME =
records).
 
So, the client would issue these queries in this =
order
1)      =
https://packetizer.com/.well-known/host-meta.json
2)      =
https://webfinger.packetizer.com/.well-known/host-meta.json=

3)      =
http://packetizer.com/.well-known/host-meta.json
=

4)      =
http://webfinger.packetizer.com/.well-known/host-meta.json<=
/span>
 
Note the ordering to ensure that TLS is attempted before insecure =
connections.
 
Is this something we really need to do?  If so, it also suggests =
that other services rooted in /.well-known are going to present similar =
issues.
 
Paul
 
From:=
 =
John Panzer [mailto:jpanzer@google.com] 
Sent: Wednesday, =
August 29, 2012 2:13 PM
To: John Bradley
Cc: Paul E. =
Jones; Mark Nottingham; IETF Apps Discuss
Subject: Re: =
[apps-discuss] Looking at Webfinger
 
Based on =
experience, I'd prefer to avoid things that depend on the bare =
("naked") domain (example.com instead of www.example.com or webfinger.example.com). =
 I could write up the reasons but it'd take some time. =
 Unfortunately, webfinger as originally spec'd requires =
this.
 
If we were to start over, and get to vote for whatever =
I wanted, and were going to allow DNS records at all, I would probably =
vote for something like webfinger.example.com as a =
special magic name (with the actual name chosen so as not to collide =
with any existing DNS entries).  Any normal hosting mechanisms will =
work here, including A records and CNAMEs and HTTP redirects, but I'd =
also require everything be done via TLS with correctly signed =
certificates for that subdomain (argh!  the =
pain!).
 
Organizationally, this would mean that =
any part of the organization that can stand up a separate SSL service on =
a new subdomain can provide webfinger services. =
 
On Wed, Aug 29, 2012 at =
10:57 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I am not the best person to represent Google's =
needs.
 
However as I understand it Google hosts applications =
such as email documents openID for tens of thousands of =
domains.
Google themselves =
don't control the DNS.
 
The people using the service generally add some MX =
records for aspmx.l.google.com. and a Cname for mail.example.com =
to ghs.google.com.
 
The A record for the bare domain typically points off =
to some Content management site the company uses for their web =
pages.
 
I =
think this is probably typical of Yahoo's mail hosting services and =
others.   
 
The service hosing the email/authentication/openID is =
not the one that controls the web server for =
company.
 
Saying the CMS venders will provide WebFinger services =
doesn't seem all that likely, especially in virtual hosting =
environments.
 
Getting a typical company to do anything more than =
enter a cname for webfinger.example.org is wildly =
optimistic.
 
I =
am entirely open to Ideas on this.   However the previous solution =
of having every RP check with google first to see if they host the email =
and provide the XRDS seems horribly flawed to =
me.
 
I =
would like to see a workable solution at the discovery layer that =
accommodates how people deploy there sites.
 
I =
think Bill suggested at one point using the MX record to find the =
webfinger host.  That has a bunch of problems I would prefer to =
avoid.
 
John B.
 
On =
2012-08-29, at 1:36 PM, "Paul E. Jones" <paulej@packetizer.com> =
wrote:


John,
 
Well, we need to figure out how to address =
this.
 
Would it be reasonable to redirect requests from =
/.well-known/host-meta.json and /.well-known/host-meta to =
Google?
 
Are there other services or files under /.well-known that =
Google’s customers would not want Google to host?  If they =
were OK with Google’s servers responding to anything , then one =
could put an A (or CNAME) record in place for example.com that points to =
Google.
 
Not being familiar with what Google offers, I’m a bit =
challenged to understand exactly what is and is not =
possible.
 
Paul
 
From:=
 John =
Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, =
August 29, 2012 10:14 AM
To: Paul E. =
Jones
Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF =
Apps Discuss'
Subject: Re: [apps-discuss] Looking at =
Webfinger
 
There mite be a A record but that typically goes off =
to some virtual web hosting company and not the email service =
provider.
 
I think I have also heard William say this is a =
problem for Yahoo.
 
Google was not able to get people to deploy XRDS for =
hosted domains.   They came up with a proprietary extension to =
openID discovery to make hosted google apps domains work with some =
subset of RP.
 
The problem is that the company hosting a small =
businesses website is unlikely to provide the web finger infrastructure =
and there is no way for the email/openID provider to do it without their =
cooperation.
 
Adding a A record rather than a CNAME is generally not =
a good idea if it can be avoided.   In the event of the provider =
changing an IP address it breaks all the customers if they have used A =
records, but that is separate issue. =
 
 
You can set up webfinger on your web server and manage =
it.   It just won't work for large numbers of people as we have it =
now.  
 
If webfinger won't work for Google Apps for Domains =
and other hosted services like that then It will significantly impact =
adoption in my opinion.
 
We will also need to work around that for Connect. =
 We don't want another proprietary work around with the security =
problems that can entail.
 
John B.
 
On 2012-08-28, at 11:37 PM, "Paul E. Jones" =
<paulej@packetizer.com> =
wrote:
 
=

John,
 
If Google is hosting the domain or any other service provider, =
wouldn’t there still be an A record for the domain (e.g.,packetizer.com)?  I know there is =
for virtually every web hosting company I’ve used.  It seems =
like this might just be one more hosted service Google could provide to =
its customers, no?
 
I do not know exactly how this hosted service works, but what’s =
hosted?  I assume it’s just email.  If web, then I see =
no issue.  If only email, then the user just needs to have MX =
records pointing to Google and an A record pointing to whatever service =
runs the WebFinger =
service.
 
In any case, if they can add a CNAME or MX record, I think we can get =
them to add an A record.  I think it would be far more challenging =
for SMBs to add a host like webfinger.example.com.  That =
would still require an A record and a service provider capable of =
supporting it.
 
Paul
 
From:=
 John =
Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: =
Tuesday, August 28, 2012 3:29 PM
To: Paul E. =
Jones
Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF =
Apps Discuss'
Subject: Re: [apps-discuss] Looking at =
Webfinger
 
There are cases where there are hosted domains (Google =
etc) that may not have a http host for the domain name used in the users =
email address.  
 
There may be merit to having a webfinger.example.com fallback =
where the client can't reach the .well-known for the primary =
host.
 
I know that some sort of SRV record would be the =
correct way to do it, but in the real world SMB don't enter SRV records =
even if there DNS provider support =
them.
The most =
you can get them to do is add a CNAME or MX =
record.
 
Supporting these sorts of domains somehow is a =
important issue.
 
John B.
 
On 2012-08-28, at 3:17 PM, "Paul E. Jones" =
<paulej@packetizer.com> =
wrote:


George,
 
I believe it might be useful to introduce those who break your =
WebFinger server to Louisville Slugger. =
:)
 
Your pain is understood, but I do not see a way to avoid it.  We =
could introduce something in DNS, but that would also present =
challenges.  No matter where we “root” the discovery =
process, there is a potential somebody could break it.  It could be =
rooted somewhere other than the root of the domain (e.g., webfinger.example.com), but we either =
need to decide in advance of such a location or introduce a way to =
discovery the discovery =
resources.
 
Do you have a suggestion that would make this less likely to be =
broken?
 
Paul
 
From:=
 apps-discuss-bounces@ietf.org [mai=
lto:apps-discuss-bounces@ietf.org] On =
Behalf Of George Fletcher
Sent: Tuesday, August =
28, 2012 11:09 AM
To: Mark =
Nottingham
Cc: IETF Apps =
Discuss
Subject: Re: [apps-discuss] Looking at =
Webfinger
 
Way "late to the =
party" but I can speak from experience that deployment can be a =
real issue in some environments. It's all really straight forward in a =
small company or an environment where the identity team "owns" =
the root domain (e.g. example.com). =
However, if an entire other group in a large organization =
"owns" the root domain (home page for the site) and the =
identity team then needs to get them to make changes, the deployment =
solution gets brittle pretty quick. I've had our webfinger support =
broken at least twice because the "other" team didn't know =
that certain configs were required:)

Also, installing the =
"dynamic pluming" can be more problematic is these cases. It =
is possible to get apache rewrite rules or netscaler magic in place to =
make it work, it's just a more brittle deployment =
architecture.

Thanks,
George
On 7/4/12 6:58 PM, John Panzer =
wrote:
Mark -- Of course I was speaking about practical =
realities of typical web server administration and deployment.  In =
practical terms, adding a new mod_rewrite rule or moral equivalent is =
going to be easier than adding a new PHP script that connects to a =
database.  The latter is just always going to be a much higher =
bar.
 
And, something that returns per-user data is generally =
going to need a dynamic service of some kind, unless your site has just =
a handful of users and you don't mind going through a publishing =
exercise each time you add or change a =
user...
 
None of this has anything to do with the interface, =
just deployment realities.  And in reality all of this is going to =
need a dynamic service somewhere for each non-trivial site, this is all =
just a question of how to hook it =
up.

--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / =
@jpanzer
 
 
On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham <mnot@mnot.net> =
wrote:
On 05/07/2012, at 8:16 AM, John Panzer =
wrote:

> Just as a historical note.  The envisioned usage =
of host-meta was originally to avoid a specification which mandated a =
particular dynamic URL API at a particular /.well-known endpoint =
(because it may not be feasible to do that across all organizations and =
deployments).  The host-meta document itself would be highly =
cacheable and so wouldn't incur an additional network trip in the common =
case.
>
> Having a 3xx redirect is a reasonable alternative =
that allows a similar escape hatch via something like mod_rewrite, =
albeit at the cost of needing an additional network trip each time. =
 Since a deployment can always avoid the 3xx redirect with =
additional dynamic plumbing behind the well-known endpoint, I don't =
think that's a horrible thing.
>
> An application-level =
redirect would be almost equivalent to an HTTP redirect, but then there =
are two ways to do the same thing.  If _only_ an application-level =
redirect is allowed, then you have to have at least a minimal dynamic =
service at the well-known endpoint (no more mod_rewrite).  But the =
whole reason for this is to avoid the requirement for a dynamic service =
behind well-known...
"dynamic" and "static" are =
properties of the implementation, not the interface. HTTP doesn't =
require that any particular URL be "dynamic"; anything can, =
with the right metadata, be cached (and indeed, I've cached many, many =
things with the wrong metadata, because of silly site operators and =
their ideas about "dynamic").

Now, if people want to =
target a particular implementation that makes it easier to serve a =
particular style of URL without writing code, fine, but let's not =
confuse things.

E.g., a URL like

http://example.com/.well-known/user/bob=


is easy to serve in pretty much any way you like with =
Apache.

I'm also going to push back on the "it may not be =
feasible to do that across all organizations and deployments" =
motivation. This is a race to the bottom. The trick is to make it =
accessible enough to get sufficient traction to pull everyone along, =
without pandering to *everyone*'s =
requirements.

Regards,

--
Mark =
Nottingham   http://www.mnot.net/



 




_______________________________________________
 
 
apps-discuss =
mailing list
apps-discuss@ietf.org
<=
pre>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<=
o:p>
 

------=_NextPart_000_04F1_01CD8605.82193160--


From paf@frobbit.se  Wed Aug 29 20:04:01 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E308711E8109 for ; Wed, 29 Aug 2012 20:04:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5Tm5UXZi44A for ; Wed, 29 Aug 2012 20:04:01 -0700 (PDT)
Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 4710811E8106 for ; Wed, 29 Aug 2012 20:04:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 6830515904FE1; Thu, 30 Aug 2012 05:03:59 +0200 (CEST)
X-Virus-Scanned: amavisd-new at frobbit.se
Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hRSt9q91dL9; Thu, 30 Aug 2012 05:03:58 +0200 (CEST)
Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id A63B015904FDA; Thu, 30 Aug 2012 05:03:58 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
From: =?windows-1252?Q?Patrik_F=E4ltstr=F6m?= 
In-Reply-To: <04f001cd8627$092727e0$1b7577a0$@packetizer.com>
Date: Thu, 30 Aug 2012 05:01:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <90420743-8FE8-4EDB-98EF-D717D5346397@frobbit.se>
References:  <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com>   <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com>      <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net>  <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com> <032d01cd8597$aac7f740$0057e5c0$@packetizer.com> <046501cd860c$da464420$8ed2cc60$@packe! tizer.com> <287CDD14-DE C2-40AD-AD5D-DC102D5AAAE6@ve7jtb.com>  <04f001cd8627$092727e0$1b7577a0$@packetizer.com>
To: Paul E. Jones 
X-Mailer: Apple Mail (2.1486)
Cc: 'Mark Nottingham' , 'IETF Apps Discuss' 
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 03:04:02 -0000

On 29 aug 2012, at 22:44, Paul E. Jones  wrote:

> 1) TXT records (e.g., _webfinger.packetizer.com IN TXT =
=93https://packetizer.webfinger-provider.com/=94)

Please see URI Resource Record, for example:

_webfinger._tcp.packetizer.com. IN URI 0 0 =
=93https://packetizer.webfinger-provider.com/=94

   Patrik


From paulej@packetizer.com  Wed Aug 29 20:07:14 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7789321E8040 for ; Wed, 29 Aug 2012 20:07:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.362
X-Spam-Level: 
X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrDr-ZOFNXDB for ; Wed, 29 Aug 2012 20:07:13 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id AFA1B21E803F for ; Wed, 29 Aug 2012 20:07:13 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q7U37BaF024445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Aug 2012 23:07:12 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1346296032; bh=XXzQeIo5x96gfwqCZCLfxhLzxvogQXIDzBB+9hsRgCI=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=cSQFHkxZeAeml0GjSK0DDk/YhZ8MUt1GfaF0xBq7MIqhpoP2I+C8rzBARZOJVWfh7 JSvyUgx8meSaa9k4lFTRsXyyB62G5qNw0ivCZH0K1p73MN/OBdeSDPsD+Stoprpobc /aZ1xzY3lnkrM8bPOwHX8H7xpEJAFT09KVT2QCTk=
From: "Paul E. Jones" 
To: "=?UTF-8?Q?'=E2=98=AE_elf_Pavlik_=E2=98=AE'?=" ,  "'webfinger'" , "'apps-discuss'" 
References:  <1346268407-sup-3223@heahdk.net>
In-Reply-To: <1346268407-sup-3223@heahdk.net>
Date: Wed, 29 Aug 2012 23:07:33 -0400
Message-ID: <054b01cd865c$9a09a910$ce1cfb30$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH3lyoRNmuYCUP0h+DrNPd4KRlUwJcdieUA
Content-Language: en-us
Subject: Re: [apps-discuss] webfinger: .well-known/acct/nick approach (was:	Proposed changes to WebFinger regarding XML vs JSON)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 03:07:14 -0000

But what if one wishes to use WebFinger to query for things other than =
account URIs?

Personally, I don't see a lot of advantages in using this structure.  It =
certainly looks clean as compared to /host-meta?resource=3D{uri}, but =
the latter form allows any URI to be provided, including URIs to web =
pages, devices, or anything else we can associate with the domain.

Paul

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org]
> On Behalf Of ? elf Pavlik ?
> Sent: Wednesday, August 29, 2012 4:16 PM
> To: webfinger; apps-discuss
> Subject: [apps-discuss] webfinger: .well-known/acct/nick approach =
(was:
> Proposed changes to WebFinger regarding XML vs JSON)
>=20
>=20
> Excerpts from Melvin Carvalho's message of 2012-08-28 12:23:06 +0000:
> > From the discussions, so far, I like the idea from mnot of using
> > .well-known/user/bob as being simple, intuitive and easy to =
implement
>=20
> I also see some advantages of using convention like:
> https://example.net/.well-known/acct/nick for nick@example.net
>=20
> Two of the reasons for acct instead of user:
> * We have acct: scheme cooking on separate burner
> * I can see place for *collective*/*shared* accounts for which user =
might
> imply an individual in a confusing way
>=20
> Besides that, I see topic of advantage in having an option of using =
static
> files coming up again, having written myself my first XRD profile by =
hand,
> I can't deny it having practical use :) I don't remember details of =
debate
> on requesting all account info vs element by element, but couldn't we =
try
> to solve it with something like:
>=20
> https://example.net/.well-known/acct/nick
> responding with full profile, or whatever one wants to publish as it
>=20
> https://example.net/.well-known/acct/nick/some_element
> responding with just given part of profile
>=20
> both could work with generating them on request or just with static =
files
>=20
> Also it could handle case which I would like to have available as well =
for
> acct:example.net type accounts (without local part) by mapping it =
simply
> to:
>=20
> https://example.net/.well-known/acct
>=20
> but in such case for selected elements it might require introducing
> reserved path part like /.el/ or something:
> https://example.net/.well-known/acct/.el/some_element
>=20
> and for our dear nick@example.net then:
>=20
> https://example.net/.well-known/acct/nick/.el/some_element
>=20
> ?
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From wmills@yahoo-inc.com  Wed Aug 29 23:03:13 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776C911E80AE for ; Wed, 29 Aug 2012 23:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.406
X-Spam-Level: 
X-Spam-Status: No, score=-17.406 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUHfXVaSsnnB for ; Wed, 29 Aug 2012 23:03:12 -0700 (PDT)
Received: from nm24-vm4.bullet.mail.ne1.yahoo.com (nm24-vm4.bullet.mail.ne1.yahoo.com [98.138.91.184]) by ietfa.amsl.com (Postfix) with SMTP id 7DEDD11E808A for ; Wed, 29 Aug 2012 23:03:11 -0700 (PDT)
Received: from [98.138.90.50] by nm24.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 06:03:08 -0000
Received: from [98.138.88.233] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 06:03:08 -0000
Received: from [127.0.0.1] by omp1033.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 06:03:08 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 167153.43058.bm@omp1033.mail.ne1.yahoo.com
Received: (qmail 83312 invoked by uid 60001); 30 Aug 2012 06:03:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346306587; bh=1D5RxHcMnl3mMrDydUjKyfojty9NhGk9b3euxNIzrMg=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VPT0lBIXZUetDk0lP6H5F4Zgf+uIrP+lvYsHbL2tHIGcm3kGGR8t0XCORX8TLCI6DLvDg56uj7UUGae0pLA4a/0w+oAF8RtAPN7VWL1C/E6sK8JYY5b60OnlZDsU5VPycmq9WwLDF26ZiwDqcvpTAiHnMmrSzfVPEg+YCY5m2X8=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=gvdve84Zsx97YR5FspSbznv9yP7lgXpKZSmgEOqo5L4Ez+vQZ25DiDJJCxqKKmTJdhGxHkvULg0hhIIm19y7qaMCxTC+Y6xRZYuVx2FVODoj5nxKocbhV+W7ZWWePn5ER9SA3Q2c2Rq4fSBjyaFvwNHaIDzzCpTzNnCBoDVI1Po=;
X-YMail-OSG: Ti4JcvIVM1kWEng7YKS8aEMaezF2L6NkM9oOosY_Y2dOI34 w19NPuaYJVLk2yaixIU7.efE1HsB9.RRgLJdROlwjy9ZhV2WFnLYcNJZKihP j3EHqoJJV5AuPfLoEKmI_8Pb_lnM33Y6HO3IdyqiQrvtdnEFSTk1TfyOiEMz 923BzzfUJ4qwjiVZhTX0upnzms4KhtECWFogGnd80t61As_ECcFD9Behu7cT eyf76xMS0qj1WOxf_tD3YTn72SjqdjKA6_N7.5125gqAz7mlefx5OOSv.Pbg DLaEZa5uSFjVTmpsq_aCMO7vMcvrA5i4AJY56IXCXp6HWw8eAv3sUtjvPxCN VFnumo0XHFSCeE6EaxLOv8HOkuekRY_n4M84uJjcEcszlJ1AZglwpNM0PhPG iL3AxDWmU3BKtvcCXlHWINHG._dXktUS0ga7eKxd5WlcqXbWkvU8brKX0oFe bxjJaXerMC6MRH6gIsVq91AtSoTEeeyRfRcowBAJhrZkVAgBQ0a6vUwz.Ez1 faTVAFMRpcJsB9NycsRfJryn2Om722V9YkgC.51SvDBf8f.YWw_EVqw--
Received: from [209.131.62.115] by web31804.mail.mud.yahoo.com via HTTP; Wed, 29 Aug 2012 23:03:07 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.121.416
References:  <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com>   <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com>      <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net>  <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com> <032d01cd8597$aac7f740$0057e5c0$@packetizer.com> <046501cd860c$da464420$8ed2cc60$@packe! tizer.com> <287CDD14-DE C2-40AD-AD5D-DC102D5AAAE6@ve7jtb.com>  <04f001cd8627$092727e0$1b7577a0$@packetizer.com> <90420743-8FE8-4EDB-98EF-D717D5346397@frobbit.se>
Message-ID: <1346306587.53748.YahooMailNeo@web31804.mail.mud.yahoo.com>
Date: Wed, 29 Aug 2012 23:03:07 -0700 (PDT)
From: William Mills 
To: =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , "Paul E. Jones" 
In-Reply-To: <90420743-8FE8-4EDB-98EF-D717D5346397@frobbit.se>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="835683298-615873288-1346306587=:53748"
Cc: 'Mark Nottingham' , 'IETF Apps Discuss' 
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Aug 2012 06:03:13 -0000

--835683298-615873288-1346306587=:53748
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

There are a few folks that feel that SRV records are not really an option f=
or hosting situatiosn where the users don't currently have the ability to c=
onfigure SRV records.=0A=0A=0A=0A=0A>________________________________=0A> F=
rom: Patrik F=C3=A4ltstr=C3=B6m =0A>To: Paul E. Jones  =0A>Cc: 'Mark Nottingham' ; 'IETF Apps Di=
scuss'  =0A>Sent: Wednesday, August 29, 2012 8:01 PM=
=0A>Subject: Re: [apps-discuss] Looking at Webfinger=0A> =0A>On 29 aug 2012=
, at 22:44, Paul E. Jones  wrote:=0A>=0A>> 1) TXT re=
cords (e.g., _webfinger.packetizer.com IN TXT =E2=80=9Chttps://packetizer.w=
ebfinger-provider.com/=E2=80=9D)=0A>=0A>Please see URI Resource Record, for=
 example:=0A>=0A>_webfinger._tcp.packetizer.com. IN URI 0 0 =E2=80=9Chttps:=
//packetizer.webfinger-provider.com/=E2=80=9D=0A>=0A>=C2=A0  Patrik=0A>=0A>=
_______________________________________________=0A>apps-discuss mailing lis=
t=0A>apps-discuss@ietf.org=0A>https://www.ietf.org/mailman/listinfo/apps-di=
scuss=0A>=0A>=0A>
--835683298-615873288-1346306587=:53748
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


There are a few folks that feel that SRV records are not really an option=
 for hosting situatiosn where the users don't currently have the ability to=
 configure SRV records.

  
 
 
  
  From: Patrik F=C3=A4ltstr=C3=B6m <paf@frobbit.se>=

 To: Paul E. Jones <=
;paulej@packetizer.com> 
Cc: 'Mark
 Nottingham' <mnot@mnot.net>; 'IETF Apps Discuss' <apps-discuss@ie=
tf.org> 
 Sent: Wedn=
esday, August 29, 2012 8:01 PM
 Su=
bject: Re: [apps-discuss] Looking at Webfinger
   
On 29 aug 2012, at 22:44, Paul E. Jones <paulej@packetizer.=
com> wrote:

> 1) TXT records (e.g., _webfinger.packetizer.=
com IN TXT =E2=80=9Chttps://packetizer.webfinger-provider.com/=E2=80=
=9D)

Please see URI Resource Record, for example:

_webfin=
ger._tcp.packetizer.com. IN URI 0 0 =E2=80=9Chttps://packetizer.webf=
inger-provider.com/=E2=80=9D

 =20
 Patrik

_______________________________________________
apps-disc=
uss mailing list
apps-discuss@ietf.org
https://www.i=
etf.org/mailman/listinfo/apps-discuss


 
 
 
   

--835683298-615873288-1346306587=:53748--

From paf@frobbit.se  Wed Aug 29 23:45:28 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB6D11E810A for ; Wed, 29 Aug 2012 23:45:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYpbiaSxCZCy for ; Wed, 29 Aug 2012 23:44:57 -0700 (PDT)
Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id C8C9E11E80BA for ; Wed, 29 Aug 2012 23:44:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id E5BA815932E07; Thu, 30 Aug 2012 08:44:54 +0200 (CEST)
X-Virus-Scanned: amavisd-new at frobbit.se
Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9V5vHPhY7p2; Thu, 30 Aug 2012 08:44:52 +0200 (CEST)
Received: from [192.168.12.176] (unknown [88.131.58.207]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 3A77415932D74; Thu, 30 Aug 2012 08:44:52 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
From: =?windows-1252?Q?Patrik_F=E4ltstr=F6m?= 
In-Reply-To: <1346306587.53748.YahooMailNeo@web31804.mail.mud.yahoo.com>
Date: Thu, 30 Aug 2012 08:44:52 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com>   <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com>      <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net>  <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com> <032d01cd8597$aac7f740$0057e5c0$@packetizer.com> <046501cd860c$da464420$8ed2cc60$@packe! tizer.com> <287CDD14-DE C2-40AD-AD5D-DC102D5AAAE6@ve7jtb.com>  <04f001cd8627$092727e0$1b7577a0$@packetizer.com> <90420743-8FE8-4EDB-98EF-D717D5346397@frobbit.se> <1346306587.53748.YahooMailNeo@web31804.mail.mud.yahoo.com>
To: William Mills 
X-Mailer: Apple Mail (2.1486)
Cc: 'Mark Nottingham' , 'IETF Apps Discuss' 
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 06:45:28 -0000

First, I did not talk about SRV records, but URI records.

Secondly, I think it is fascinating that people that love new things =
like "the web" and new HTML5 features are the most conservative ones =
regarding other protocols like DNS.

With that attitude, we have no evolution, and no innovation.

Providers that do not support such features will die. It is that simple.

   Patrik

On 30 aug 2012, at 08:03, William Mills  wrote:

> There are a few folks that feel that SRV records are not really an =
option for hosting situatiosn where the users don't currently have the =
ability to configure SRV records.
>=20
> From: Patrik F=E4ltstr=F6m 
> To: Paul E. Jones =20
> Cc: 'Mark Nottingham' ; 'IETF Apps Discuss' =
=20
> Sent: Wednesday, August 29, 2012 8:01 PM
> Subject: Re: [apps-discuss] Looking at Webfinger
>=20
> On 29 aug 2012, at 22:44, Paul E. Jones  wrote:
>=20
> > 1) TXT records (e.g., _webfinger.packetizer.com IN TXT =
=93https://packetizer.webfinger-provider.com/=94)
>=20
> Please see URI Resource Record, for example:
>=20
> _webfinger._tcp.packetizer.com. IN URI 0 0 =
=93https://packetizer.webfinger-provider.com/=94
>=20
>   Patrik
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
>=20


From laurentwalter.goix@telecomitalia.it  Thu Aug 30 02:39:30 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB19B21F8678 for ; Thu, 30 Aug 2012 02:39:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.071
X-Spam-Level: 
X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[AWL=0.348,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ab4B4TWaCrMi for ; Thu, 30 Aug 2012 02:39:29 -0700 (PDT)
Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id ED96A21F8645 for ; Thu, 30 Aug 2012 02:39:28 -0700 (PDT)
Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.245.1; Thu, 30 Aug 2012 11:39:23 +0200
Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Thu, 30 Aug 2012 11:39:23 +0200
From: Goix Laurent Walter 
To: "Paul E. Jones" , =?utf-8?B?J+KYriBlbGYgUGF2bGlrIOKYric=?= ,  'Peter Saint-Andre' 
Date: Thu, 30 Aug 2012 11:39:17 +0200
Thread-Topic: [apps-discuss] R:  Comment on draft-ietf-appsawg-acct-uri-00.txt
Thread-Index: AQHQkPRpqE241VMBhFX0b1E5n3icagGmT2cgAfxtLQICXYfDzwLd38ExAfCD3o0CSm6TWwHz+GlOAlI3tJiW4AA3QIAA6tRA
Message-ID: 
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> <5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com> <1346172875-sup-9676@heahdk.net> <503D04E5.1090506@stpeter.im> <1346176849-sup-3504@heahdk.net>  <047b01cd860f$d31f7ce0$795e76a0$@packetizer.com>
In-Reply-To: <047b01cd860f$d31f7ce0$795e76a0$@packetizer.com>
Accept-Language: en-US
Content-Language: it-IT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
x-ti-disclaimer: Disclaimer1
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: 'apps-discuss' 
Subject: [apps-discuss] R: R: Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 09:39:31 -0000

SGVsbG8gUGF1bCwNCg0KSSBhZ3JlZSBpdCBpcyAibW9yZSBvciBsZXNzIiB0aGUgc2FtZSBhdCB0
aGUgZW5kLiBIb3dldmVyIEkgZXhwZWN0IHRoYXQgZnJvbSBjdXJyZW50IGltcGxlbWVudGF0aW9u
cyBvZiB3ZWJmaW5nZXIsIHZlcnkgbGl0dGxlIGxpbmsgcmVscyBhcmUgcHJvdmlkZWQgaW4gdGhl
IGhvc3QtbWV0YSB2cyByZXNvdXJjZS1zcGVjaWZpYyBkZXNjcmlwdG9yIHNvIHB1dHRpbmcgbWFu
eSB0ZW1wbGF0ZXMgaW4gdGhlIGhvc3QtbWV0YSBhbHJlYWR5IGlzIG5vdCBiZXN0IHByYWN0aWNl
IHlldCBhZmFpay4NCk9mIGNvdXJzZSBub3RoaW5nIHByZXZlbnRzIGZyb20gY2hhbmdpbmcgdGhp
cyBiZWhhdmlvdXIgaW4gdGhlIGZ1dHVyZSBidXQgYXMgdGhpcyBzY2VuYXJpbyBtYXkgYmVjb21l
IG1haW5zdHJlYW0gKEkgZG8gaG9wZSB0aGF0IGluIGEgZmV3IHllYXJzIHZlcnkgYmlnIHNvY2lh
bCBpc2xhbmRzIHdpbGwgd2ViZmluZ2VyIGVhY2ggb3RoZXIpLg0KDQpUaHVzIEkgYW0gd29uZGVy
aW5nIHdoZXRoZXIgaXQgY291bGQgbWFrZSBzZW5zZToNCi0gYWRkaW5nIGl0IGFzIGFuIGV4YW1w
bGUgaW4gdGhlIGRyYWZ0IGNsYXJpZnlpbmcgdGhlIHByYWN0aWNlIGFuZCBlbXBoYXNpemluZyB0
aGUgaW5zZXJ0aW9uIG9mIGFkZGl0aW9uYWwgbGluayByZWwgdGVtcGxhdGVzIGFscmVhZHkgaW4g
dGhlIGhvc3QtbWV0YQ0KLSBzcGVjaWZ5aW5nIG5ldyB0ZW1wbGF0ZXMgdmFyaWFibGUgbmFtZXMg
dG8gYmUgdXNlZCBpbiB0ZW1wbGF0ZXMsIGFzIHRoaXMgc2NlbmFyaW8gbWFrZXMgc3Ryb25nIHVz
ZSBvZiB0ZW1wbGF0ZXMgYW5kIG1heSBuZWVkIHRvIHJlZmVyZW5jZSBhZGRpdGlvbmFsIGluZm9y
bWF0aW9uLiBUaGUgZmlyc3QgdGhhdCBjb21lcyBpbnRvIG15IG1pbmQgKGFzIHBlciB0aGUgZXhh
bXBsZSBpbiBteSBwcmV2aW91cyBlbWFpbCkgaXMgdGhlIGxvY2FsIHVzZXJuYW1lLCB0aGF0IGNv
dWxkIGJlIGlkZW50aWZpZWQgYXMge3VyaS51c2VycGFydH0sIHt1c2VybmFtZX0gb3IgYW55dGhp
bmcgZWxzZS4gTWF5YmUgb3RoZXIgY291bGQgYWxzbyBtYWtlIHNlbnNlLg0KDQpXYWx0ZXINCg0K
DQo+IC0tLS0tTWVzc2FnZ2lvIG9yaWdpbmFsZS0tLS0tDQo+IERhOiBQYXVsIEUuIEpvbmVzIFtt
YWlsdG86cGF1bGVqQHBhY2tldGl6ZXIuY29tXQ0KPiBJbnZpYXRvOiBtZXJjb2xlZMOsIDI5IGFn
b3N0byAyMDEyIDE5LjU4DQo+IEE6IEdvaXggTGF1cmVudCBXYWx0ZXI7ICfimK4gZWxmIFBhdmxp
ayDimK4nOyAnUGV0ZXIgU2FpbnQtQW5kcmUnDQo+IENjOiAnYXBwcy1kaXNjdXNzJw0KPiBPZ2dl
dHRvOiBSRTogW2FwcHMtZGlzY3Vzc10gUjogQ29tbWVudCBvbiBkcmFmdC1pZXRmLWFwcHNhd2ct
YWNjdC11cmktMDAudHh0DQo+DQo+IFdhbHRlciwNCj4NCj4gSWYgeW91IHF1ZXJ5IC8ud2VsbC1r
bm93bi9ob3N0LW1ldGFbLmpzb25dLCBvbmUgd2lsbCBnZXQgYSBzZXQgb2YgbGluaw0KPiByZWxh
dGlvbnMgdGhhdCBhcmUgaG9zdC13aWRlIGFuZCB0ZW1wbGF0ZXMgdGhhdCBhcmUgcmVzb3VyY2Ut
c3BlY2lmaWMuICBJc24ndA0KPiB0aGF0IG1vcmUtb3ItbGVzcyB0aGUgc2FtZSBhcyB3aGF0IHlv
dSBhcmUgc3VnZ2VzdGluZyB3aXRoIGFjY3Q6ZXhhbXBsZS5jb20/DQo+IEkgZG9uJ3Qgc2VlIHRo
ZSBkaWZmZXJlbmNlLg0KPg0KPiBZb3UgY2FuIHNlZSBhbiBleGFtcGxlOg0KPiBjdXJsIC12IGh0
dHBzOi8vcGFja2V0aXplci5jb20vLndlbGwta25vd24vaG9zdC1tZXRhLmpzb24NCj4NCj4gUGF1
bA0KPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogYXBwcy1kaXNj
dXNzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9y
Z10NCj4gPiBPbiBCZWhhbGYgT2YgR29peCBMYXVyZW50IFdhbHRlcg0KPiA+IFNlbnQ6IFdlZG5l
c2RheSwgQXVndXN0IDI5LCAyMDEyIDQ6MjUgQU0NCj4gPiBUbzog4piuIGVsZiBQYXZsaWsg4piu
OyBQZXRlciBTYWludC1BbmRyZQ0KPiA+IENjOiBhcHBzLWRpc2N1c3MNCj4gPiBTdWJqZWN0OiBb
YXBwcy1kaXNjdXNzXSBSOiBDb21tZW50IG9uIGRyYWZ0LWlldGYtYXBwc2F3Zy1hY2N0LXVyaS0w
MC50eHQNCj4gPg0KPiA+ID4gLS0tLS1NZXNzYWdnaW8gb3JpZ2luYWxlLS0tLS0NCj4gPiA+IERh
OiBhcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZw0KPiA+ID4gW21haWx0bzphcHBzLWRpc2N1
c3MtYm91bmNlc0BpZXRmLm9yZ10gUGVyIGNvbnRvIGRpID8gZWxmIFBhdmxpayA/DQo+ID4gPiBJ
bnZpYXRvOiBtYXJ0ZWTDrCAyOCBhZ29zdG8gMjAxMiAyMC4xOQ0KPiA+ID4gQTogUGV0ZXIgU2Fp
bnQtQW5kcmUNCj4gPiA+IENjOiBhcHBzLWRpc2N1c3MNCj4gPiA+IE9nZ2V0dG86IFJlOiBbYXBw
cy1kaXNjdXNzXSBDb21tZW50IG9uDQo+ID4gPiBkcmFmdC1pZXRmLWFwcHNhd2ctYWNjdC11cmkt
MDAudHh0DQo+ID4gPg0KPiA+ID4gRXhjZXJwdHMgZnJvbSBQZXRlciBTYWludC1BbmRyZSdzIG1l
c3NhZ2Ugb2YgMjAxMi0wOC0yOCAxNzo1MDoyOSArMDAwMDoNCj4gPiA+ID4gSGFzaDogU0hBMQ0K
PiA+ID4gPg0KPiA+ID4gPiBPbiA4LzI4LzEyIDExOjA1IEFNLCBlbGYgUGF2bGlrIHdyb3RlOg0K
PiA+ID4gPiA+IEV4Y2VycHRzIGZyb20gTWlrZSBKb25lcydzIG1lc3NhZ2Ugb2YgMjAxMi0wOC0y
MyAxODo0OTozNiArMDAwMDoNCj4gPiA+ID4gPj4gQXMgbG9uZyBhcyBJJ20gd3JpdGluZyBhYm91
dCB0aGUgYWNjdDogVVJJLCBsZXQgbWUgYWRkIG15IHZvaWNlDQo+ID4gPiA+ID4+IHN1cHBvcnRp
bmcgYWxsb3dpbmcgbG9jYWwgYWNjb3VudCBpZGVudGlmaWVycyBzdWNoIGFzICJhY2N0OmpvZSIN
Cj4gPiA+ID4gPj4gdG8gYmUgdXNlZCwgaW4gYWRkaXRpb24gdG8gZnVsbHkgcXVhbGlmaWVkIG5h
bWVzIHN1Y2gNCj4gPiA+ID4gPj4gImFjY3Q6am9lQGV4YW1wbGUuY29tIi4gIFRoZSByZWFzb24g
dGhhdCB0aGlzIHRoaXMgY2FuIHdvcmsgZmluZQ0KPiA+ID4gPiA+PiBmb3IgZGlzY292ZXJ5IGlz
IHRoYXQgaWYgeW91J3JlIGNvbnRhY3RpbmcgdGhlIGRpc2NvdmVyeSBzZXJ2ZXINCj4gPiA+ID4g
Pj4gYXQgZXhhbXBsZS5jb20sIHRoZSBpZGVudGlmaWVyICJhY2N0OmpvZSIgaXMgdW5hbWJpZ3Vv
dXMgaW4gdGhhdA0KPiA+ID4gPiA+PiBjb250ZXh0Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gV2hp
bGUgYWdvIEkndmUgc3VnZ2VzdGVkIG9uIHdlYmZpbmdlciBtYWlsaW5nIGxpc3QgdG8gYWxsb3cN
Cj4gPiA+ID4gPiBpZGVudGlmaWVycyB3aXRob3V0IGxvY2FsIHBhcnQsIGp1c3Q6IEBkb21haW4u
dGxkDQo+ID4gPiA+DQo+ID4gPiA+IEhtbSwgaWYgbG9jYWwgcGFydCBhbmQgZG9tYWluIHBhcnQg
YXJlIGJvdGggb3B0aW9uYWwsIGNhbiB3ZSBhbHNvDQo+ID4gPiA+IGhhdmUgImFjY3Q6QCI/IDst
KQ0KPiA+ID4gPg0KPiA+ID4gPiA+IFRoaXMgd2F5IHByb2plY3RzIGNvdWxkIGhhdmUgc29ydCBv
ZiBjYXRjaCBhbGwgYWNjb3VudHMgbGlrZToNCj4gPiA+ID4gPiBAaWV0Zi5vcmcgYW5kIHBlb3Bs
ZSBoYXZpbmcgcGVyc29uYWwgZG9tYWlucyBjb3VsZCBhbHNvIGp1c3QgdXNlDQo+ID4gPiA+ID4g
QG5hbWUubWUgKHJhdGhlciB0aGFuIG1lQG5hbWUubWUgb3IgaUBuYW1lLm1lIGV0Yy4pDQo+ID4g
PiA+DQo+ID4gPiA+IFllcywgSSByZWNhbGwgdGhhdCBkaXNjdXNzaW9uLCBhbmQgaWYgSSByZWNh
bGwgY29ycmVjdGx5IG1vc3QgcGVvcGxlDQo+ID4gPiA+IHRob3VnaHQgaXQgd2Fzbid0IGEgZ3Jl
YXQgaWRlYS4gV2hhdCBkb2VzIGl0IG1lYW4gdG8sIHNheSwgcGVyZm9ybSBhDQo+ID4gPiA+IFdl
YkZpbmdlciBxdWVyeSBhZ2FpbnN0IGEgYmFyZSBkb21haW4/DQo+ID4gPiBZZXMsIG1hbnkgcGVv
cGxlIG1lbnRpb25lZCB0aGUgb3JpZ2luYWwgaW50ZW50aW9uIHRvIG1pbWljIGZhbWlsaWFyIHRv
DQo+ID4gPiBtb3N0IHBlb3BsZSBlbWFpbCBhZGRyZXNzZXMNCj4gPiA+DQo+ID4gPiA+DQo+ID4g
PiA+ID4gSXQgc2VhbXMgdG8gbWUgYXR0cmFjdGl2ZSBpZiB1c2VkIGluIG9zdGF0dXMgZm9yIGZl
ZGVyYXRlZA0KPiA+ID4gPiA+IG1pY3JvYmxvZ2dpbmcuDQo+ID4gPiA+DQo+ID4gPiA+IENvdWxk
IHlvdSBwZXJoYXBzIGV4cGxhaW4gdGhhdCBzY2VuYXJpbyBpbiBhIGJpdCBtb3JlIGRldGFpbD8g
SSdtDQo+ID4gPiA+IGN1cmlvdXMgdG8gbGVhcm4gd2hhdCByZXF1aXJlbWVudHMgdGhhdCBicmlu
Z3MgaW4uDQo+ID4gPiBBdCBzb21lIHBvaW50IGkgdGhvdWdodCB0aGF0IGZvciBleGFtcGxlIHR3
aXR0ZXIgc3BlY2lmaWM6IEBpZXRmIGNvdWxkDQo+ID4gPiBiZWNvbWUgcG9zc2libHkgc2VsZiBo
b3N0ZWQgQGlldGYub3JnIGFzIHdlbGwgYXMgcGVvcGxlIHdpdGggcGVyc29uYWwNCj4gPiA+IGRv
bWFpbnMgY291bGQgdXNlIGp1c3QgaWRlbnRpZmllcnMgbGlrZSBAZnJhbmt5Lm1lIGFuZCBjaG9v
c2Ugd2hlcmUNCj4gPiA+IHRoZXkgd2FudCB0byBob3N0IHRoZWlyIGFjY291bnRzLg0KPiA+ID4N
Cj4gPiA+IEkgYWxzbyByZWNhbGwgTWFya3VzIFNhYmFkZWxsbyBlbnRodXNpYXNtIHRvIGluIHNv
bWUgd2F5cyBpbmZhbW91cw0KPiA+ID4gaS1uYW1lcyB3aGljaCBqdXN0IHVzZSA9bmFtZSBmb3Ig
aW5kaXZpZHVhbHMgYW5kIEBuYW1lIGZvcg0KPiA+ID4gb3JnYW5pemF0aW9ucyBodHRwczovL2Vu
Lndpa2lwZWRpYS5vcmcvd2lraS9JLW5hbWUNCj4gPiA+DQo+ID4gPiBIb25lc3RseSBJIGp1c3Qg
d2FudGVkIHRvIGhlYXIgbW9yZSBvcGluaW9ucyBhYm91dCBpdCwgc2VlaW5nIG15c2VsZg0KPiA+
ID4gcG9zc2libGUgY29udmVuaWVuY2UgaW4gaGF2aW5nIG9wdGlvbiB0byBqdXN0IHNraXAgbG9j
YWwgcGFydC4NCj4gPiBbd2FsdGVyXSBQZXJzb25hbGx5IEknZCByYXRoZXIgc2VlIHRoZSB2YWx1
ZSBvZiBkb21haW4tb25seSByYXRoZXIgdGhhbg0KPiA+IGRvbWFpbi1sZXNzIGFjY3Q6IFVSSXMg
Zm9yIGRlcGxveW1lbnRzLiBJbiBbMV0gSSBpbGx1c3RyYXRlZCBhIHVzZSBjYXNlDQo+ID4gZm9y
IGxhcmdlIGRlcGxveW1lbnRzIGFuZCBmZWRlcmF0ZWQgc29jaWFsIG5ldHdvcmtzIHdoZXJlIGxv
dHMgb2YNCj4gPiB3ZWJmaW5nZXIgZGlzY292ZXJpZXMgY291bGQgaGFwcGVuIGFjcm9zcyB1c2Vy
cyBvbiBkaXN0aW5jdCBzb2NpYWwNCj4gPiBuZXR3b3JrcyAoZS5nLiB3aGVuIHN0YXJ0IGNyb3Nz
LWZvbGxvd2luZykuIFRoYXQgZW1haWwgc3VnZ2VzdGVkIHRoZSB1c2UNCj4gPiBvZiB0ZW1wbGF0
ZXMgYW5kIG5ldyB0ZW1wbGF0ZSB2YXJpYWJsZXMsIHdoaWNoIGlzIG5vdCBleGFjdGx5IHRoZSBz
dWJqZWN0DQo+ID4gaGVyZSwgYnV0IHRoZSBtYWluIHBvaW50IHJlbWFpbnMgYW5kIGFsbG93aW5n
IGRvbWFpbi1vbmx5IGlkZW50aWZpZXJzDQo+ID4gY291bGQgaGVscCBpbiB0aGF0Lg0KPiA+IFBv
dGVudGlhbGx5IGEgc2VydmVyIChrbm93aW5nIGluIGFkdmFuY2UgaXQgbWF5IGRlYWwgd2l0aCBz
ZXZlcmFsIHVzZXJzIG9uDQo+ID4gdGhlIHNhbWUgZm9yZWlnbiBzZXJ2ZXIpIGNvdWxkIGlzc3Vl
IGEgd2ViZmluZ2VyIHF1ZXJ5IHRvIHRoZSByZXNvdXJjZQ0KPiA+IGFjY3Q6ZXhhbXBsZS5jb20g
aW5zdGVhZCBvZiBhIHNwZWNpZmljIHVzZXIuIEkgd291bGQgZXhwZWN0IGEgZGlmZmVyZW5jZQ0K
PiA+IHdydCB0byBpc3N1aW5nIGEgcHVyZSBob3N0LW1ldGEgcXVlcnkgd2hlcmUgb25seSBhIGxp
bWl0ZWQgc3Vic2V0IG9mDQo+ID4gZW5kcG9pbnRzL2xpbmsgcmVscyBtYXkgYmUgcHJvdmlkZWQ6
IGJ5IHNwZWNpZnlpbmcgdGhlIGRvbWFpbi1vbmx5DQo+ID4gcmVzb3VyY2UgZXhwbGljaXRseSBp
dCB3b3VsZCBiZSB1bmRlcnN0b29kIGFzIGEgMm5kIGxldmVsIHF1ZXJ5IChtZWFuaW5nDQo+ID4g
ZXh0cmFjdGluZyB0aGUgbGluayByZWxzIHByb3ZpZGVkIGJ5IHRoZSBscmRkIGRlc2NyaXB0b3Ig
dHlwaWNhbGx5KSBhbmQNCj4gPiB0aHVzIGNvdWxkIHByb3ZpZGUgdGhlc2UgYWRkaXRpb25hbCBs
aW5rcy4gQ29tYmluZWQgd2l0aCB0ZW1wbGF0ZXMgKGhlcmUNCj4gPiB3ZSBjYW4gdGhlbiBkaXNj
dXNzIG9uIHRoZSByZXNlcnZlZCB0ZW1wbGF0ZSBwYXJhbWV0ZXIgbmFtZXMpIGl0IGNvdWxkDQo+
ID4gYmVjb21lIGEgcG93ZXJmdWwgbWVjaGFuaXNtIHRvIHJldHJpZXZlIHRlbXBsYXRlLWJhc2Vk
IGVuZHBvaW50cyB0aGF0DQo+ID4gY291bGQgYmUgdmFsaWQgZm9yIGFsbCB1c2VycyBvbiB0aGF0
IHNlcnZlci9kb21haW4sIHRodXMgcmVkdWNpbmcgdGhlDQo+ID4gbnVtYmVyIG9mIHdmIHF1ZXJp
ZXMgZm9yIGRpc3RpbmN0IHVzZXJzIG9uIHRoZSBzYW1lIGZvcmVpZ24gc2VydmVyLiBJbg0KPiA+
IGNhc2Ugc29tZSBsaW5rIHJlbHMgZG8gbm90IGZvbGxvdyBhIHNwZWNpZmljIHBhdHRlcm4gYW5k
IGFyZSBtb3JlIGNvbXBsZXgNCj4gPiB0aGV5IGNvdWxkIHNpbXBseSBub3QgYmUgcmV0dXJuZWQg
aW4gdGhhdCB0eXBlIG9mIHhyZC9qcmQsIGFuZCB0aGUgc2VydmVyDQo+ID4gd291bGQgbmVlZCB0
byBpc3N1ZSBhIHVzZXItc3BlY2lmaWMgcXVlcnkgdG8gcmV0cmlldmUgZXh0cmEgbGluayByZWxz
IGlmDQo+ID4gbmVlZGVkLg0KPiA+DQo+ID4gSGVyZSBpcyBhbiBleGFtcGxlOg0KPiA+IEdFVCAv
LndlbGwta25vd24vaG9zdC1tZXRhLmpzb24/cmVzb3VyY2U9YWNjdDpleGFtcGxlLmNvbSBIVFRQ
LzEuMQ0KPiA+IEhvc3Q6IGV4YW1wbGUuY29tDQo+ID4NCj4gPiBUaGUgcmVwbHkgbWlnaHQgaGF2
ZSB0aGlzIGJvZHkgKHVzaW5nIGEgZmljdGl0aW91cyAie3VyaS51c2VycGFydH0iIHRvDQo+ID4g
cmVwcmVzZW50IG9ubHkgdGhlIHVzZXItcGFydCBvZiB0aGUgYWNjdDogVVJJKToNCj4gPg0KPiA+
IHsNCj4gPiAgICJzdWJqZWN0IiA6ICJhY2N0OmV4YW1wbGUuY29tIiwNCj4gPiAgICJsaW5rcyIg
Og0KPiA+ICAgWw0KPiA+ICAgICB7DQo+ID4gICAgICAgInJlbCIgOiAiaHR0cDovL3dlYmZpbmdl
ci5uZXQvcmVsL2F2YXRhciIsDQo+ID4gICAgICAgInRlbXBsYXRlIiA6DQo+ID4gImh0dHA6Ly93
d3cuZXhhbXBsZS5jb20vcGVvcGxlL3t1cml9L2ltYWdlcy97dXJpLnVzZXJwYXJ0fS5qcGciDQo+
ID4gICAgIH0sDQo+ID4gICAgIHsNCj4gPiAgICAgICAicmVsIiA6ICJodHRwOi8vd2ViZmluZ2Vy
Lm5ldC9yZWwvcHJvZmlsZS1wYWdlIiwNCj4gPiAgICAgICAidGVtcGxhdGUiIDogImh0dHA6Ly93
d3cuZXhhbXBsZS5jb20vcGVvcGxlL3t1cml9Ig0KPiA+ICAgICB9LA0KPiA+ICAgICB7DQo+ID4g
ICAgICAgInJlbCIgOiAiaHR0cDovL3NjaGVtYXMuZ29vZ2xlLmNvbS9nLzIwMTAjdXBkYXRlcy1m
cm9tIiwNCj4gPiAgICAgICAidGVtcGxhdGUiIDogImh0dHA6Ly93d3cuZXhhbXBsZS5jb20vcGVv
cGxlL3t1cml9L2Jsb2cvYmxvZy54bWwiDQo+ID4gICAgIH0NCj4gPiAgIF0NCj4gPiB9DQo+ID4N
Cj4gPiB3YWx0ZXINCj4gPg0KPiA+IFsxXSBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2
ZS93ZWIvYXBwcy0NCj4gPiBkaXNjdXNzL2N1cnJlbnQvbXNnMDYwNzMuaHRtbA0KPiA+DQo+ID4g
Pg0KPiA+ID4gPg0KPiA+ID4gPiA+IE9uIHRoYXQgdGhyZWFkIHNvbWVvbmUgYWxzbyBtZW50aW9u
ZWQgdGhhdCBpbiB4bXBwIHJlYWxtDQo+ID4gPiA+ID4gQGRvbWFpbi50bGQgbWFrZXMgYSB2YWxp
ZCBqaWQgYnV0IGkgaGF2ZW4ndCByZXNlYXJjaCBpdCBmdXJ0aGVyDQo+ID4gPiA+ID4geWV0IDoo
DQo+ID4gPiA+DQo+ID4gPiA+IFlvdSBjYW4gaGF2ZSB4bXBwOmRvbWFpbi50bGQgKHRoZSBhZGRy
ZXNzIG9mIGEgc2VydmVyKSwgYnV0IHlvdQ0KPiA+ID4gPiBjYW4ndCBoYXZlIHhtcHA6QGRvbWFp
bi50bGQgKHNvbWUgc29ydCBvZiBjYXRjaC1hbGwgZm9yIGFsbCBhY2NvdW50cw0KPiA+ID4gPiBh
dCB0aGUgc2VydmVyPz8pLg0KPiA+ID4gVGhhbmtzIGZvciBjbGFyaWZ5aW5nLCBhbHNvIGFjY3Q6
ZG9tYWluLnRsZCBsb29rcyBhbHNvIHNvbWVob3cgbW9yZQ0KPiA+ID4gc2FuZSB0aGFuIGFjY3Q6
QGRvbWFpbi50bGQgOikNCj4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IFBldGVyDQo+ID4gPiA+DQo+
ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+
ID4gYXBwcy1kaXNjdXNzIG1haWxpbmcgbGlzdA0KPiA+ID4gYXBwcy1kaXNjdXNzQGlldGYub3Jn
DQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vz
cw0KPiA+DQo+ID4gUXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGly
aXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUNCj4gPiBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZm
dXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlDQo+ID4gZGFs
bGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2
aWV0YXRlLg0KPiA+IFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBl
ciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlDQo+ID4gcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlh
dGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYQ0KPiA+IHN1
YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KPiA+DQo+ID4gVGhpcyBlLW1haWwgYW5kIGFueSBhdHRh
Y2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQNCj4gPiBp
bmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0
aW9uLCBjb3B5aW5nLA0KPiA+IHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5h
dXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUNCj4gPiBpbnRlbmRlZCByZWNpcGllbnQsIHBs
ZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kDQo+ID4gYWR2
aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KPiA+DQo+ID4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBhcHBzLWRpc2N1
c3MgbWFpbGluZyBsaXN0DQo+ID4gYXBwcy1kaXNjdXNzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCg0KDQpRdWVzdG8gbWVz
c2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUg
YWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBh
bHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6
aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRv
IHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBk
aSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRl
cmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBh
dHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5m
b3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlv
biwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlz
ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUg
dGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5
IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCg0K

From laurentwalter.goix@telecomitalia.it  Thu Aug 30 02:55:30 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DFD21F8575 for ; Thu, 30 Aug 2012 02:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.252
X-Spam-Level: 
X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[AWL=0.466,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THP1CqZLRTfg for ; Thu, 30 Aug 2012 02:55:26 -0700 (PDT)
Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4BD21F851B for ; Thu, 30 Aug 2012 02:55:25 -0700 (PDT)
Content-Type: multipart/mixed; boundary="_c65a8b6d-2a2e-4a99-887d-5e096d3cebef_"
Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.245.1; Thu, 30 Aug 2012 11:55:21 +0200
Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Thu, 30 Aug 2012 11:55:21 +0200
From: Goix Laurent Walter 
To: John Bradley , "Paul E. Jones" 
Date: Thu, 30 Aug 2012 11:55:19 +0200
Thread-Topic: [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON
Thread-Index: Ac2FUUTvXjQdejqmTsKiaK7iVNeDkgBQtPKA
Message-ID: 
References: <010901cd846c$95d74560$c185d020$@packetizer.com> <1346084277.68046.YahooMailNeo@web31802.mail.mud.yahoo.com>   <017001cd849e$cbdd9c90$6398d5b0$@packetizer.com>   <028a01cd854f$c29a86f0$47cf94d0$@packetizer.com> <050232F8-4175-4698-95D7-17E4B35B1210@ve7jtb.com>
In-Reply-To: <050232F8-4175-4698-95D7-17E4B35B1210@ve7jtb.com>
Accept-Language: en-US
Content-Language: it-IT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
x-ti-disclaimer: Disclaimer1
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" 
Subject: [apps-discuss] R: Proposed changes to WebFinger regarding XML vs	JSON
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 09:55:31 -0000

--_c65a8b6d-2a2e-4a99-887d-5e096d3cebef_
Content-Type: multipart/alternative;
	boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A2AF901FGRFMBX704BA02_"

--_000_A09A9E0A4B9C654E8672D1DC003633AE53A2AF901FGRFMBX704BA02_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I am also fine with the json version being privileged in the future.
However we cannot ignore completely that webfinger XML-based implementation=
s already exist (and may not upgrade all together), and we do have already =
some text written in the draft so instead of deleting entirely what was wri=
tten we could probably find a way to rephrase it to make it optional for se=
rvers to support the xml version (no appendix).

BTW as rfc6415 currently says, jrd is returned only in response to host-met=
a.json endpoint. If only host-meta is queried, negotiation is required usin=
g the accept header. Given the current agreement in the group, is there any=
 change or clarification expected in the wf draft regarding this? In other =
words, as per current statements both xrd and jrd can already be supported =
on distinct endpoints, thus simplifying their coexistence. But it seems to =
me that the group would like some stronger statements towards jrd with no n=
eed for ".json" in the endpioint name neither for content negotiation (but =
as default content). Am I right?

Regards
walter

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Pe=
r conto di John Bradley
Inviato: marted=EC 28 agosto 2012 21.13
A: Paul E. Jones
Cc: apps-discuss@ietf.org
Oggetto: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs =
JSON

I understand, but I think forcing servers to support both will hurt adoptio=
n, though not as much as requiring it on the client.

John B.


On 2012-08-28, at 3:03 PM, "Paul E. Jones" > wrote:


John,

Previously, JSON and XML were MTI on servers; clients could implement what =
they want.

If we make the proposed change, XML will be dropped on the server side.  Th=
e result will be that clients can only rely on JSON support.  XML support m=
ight be rare.

Paul

PS - My personal preference is still to require XML and JSON on the server,=
 but I'm willing to give in on this one in order to reach group consensus. =
 I think this was the most significant point of contention.

From: John Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: Tuesday, August 28, 2012 2:26 PM
To: Will Norris
Cc: Paul E. Jones; apps-discuss@ietf.org
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs =
JSON

+1 JSON must be MTI for servers.

I am not opposed to servers supporting XML or other formats via content neg=
otiation,  however clients need to be interoperable with servers using JSON=
, and not forced to support XML for some servers.

John B.

On 2012-08-27, at 7:13 PM, Will Norris > wrote:



as one of the editors of said XML format, I'm +1 as well.  The reasons for =
pushing so heavily for the XML format back then are no longer really true. =
 Instead, all the active work is on JSON-based formats, so it makes sense t=
o update webfinger as well.
On Mon, Aug 27, 2012 at 2:56 PM, Paul E. Jones > wrote:
Ok... we could also do that.

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org=
 [mailto:apps-discuss-bounces@ietf.org]
> On Behalf Of Blaine Cook
> Sent: Monday, August 27, 2012 12:29 PM
> To: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML v=
s
> JSON
>
> +1 to this, and William and Tim's points.
>
> On 27 August 2012 18:26, Tim Bray > wrote:
> > What William said about not needing the appendix. If you're going to
> > go through the pain of abandoning the XML version, why also go through
> > the pain of writing an appendix, when there's a perfectly good RFC in
> > place to point to.  -T
> >
> > On Mon, Aug 27, 2012 at 9:17 AM, William Mills >
> wrote:
> >> I think this works in general but that there should be a mention of
> >> it in the body of the spec citing the appendix.  Do we even need an
> >> appendix though, we could simply cite 6415 as still normative for the
> >> XML stuff but deprecated for new implementations.
> >>
> >>
> >> ________________________________
> >> From: Paul E. Jones >
> >> To: apps-discuss@ietf.org
> >> Cc: jsmarr@google.com; webfinger@googlegroup=
s.com
> >> Sent: Monday, August 27, 2012 8:56 AM
> >> Subject: [apps-discuss] Proposed changes to WebFinger regarding XML
> >> vs JSON
> >>
> >> Folks,
> >>
> >> Mike, Gonzalo, and I have had some off-list discussions about
> >> WebFinger and how to resolve the one sticky point that we think has
> >> caused the most concern.  That point is whether we should we allow bot=
h
> XML and JSON.
> >>
> >> We have heard proposals to "just pick one" and, while I appreciate
> >> the reasoning, I could not help ignoring that
> >>
> >>   1) RFC 6415 exists and describes XML the single mandatory format
> >>   2) Existing implementations use XML
> >>
> >> Nonetheless, I also cannot ignore the long-term value in selecting
> >> one format we can be sure is widely supported consistently.  I'm
> >> fairly confident that most want only JSON at this point, even though
> >> most (if not
> >> all) current implementations today use XML.  While I'm personally
> >> favorable to using XML, I know my personal preferences are not
> >> representative of everyone. :-)
> >>
> >> So what we discussed was mentioning XML (perhaps with examples), but
> >> putting that in an appendix and saying the usage is historic.  What
> >> this would mean is that the text acknowledges that there are servers
> >> that might process both XML and JSON, and even older servers that
> >> only process XML.  The main body of the document would only require
> >> support for JSON from clients and servers.
> >>
> >> Before we make these changes to the text, I want to seek input from
> >> the group.  I believe it would be acceptable, but I do not want those
> >> changes to cause significant issues for anyone.
> >>
> >> Thanks,
> >> Paul
> >>
> >> PS - Please follow-up only on the apps-discuss list.
> >>
> >>
> >> _______________________________________________
> >> 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
> _______________________________________________
> 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

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall=
a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb=
iate ricevuto questo documento per errore siete cortesemente pregati di dar=
ne immediata comunicazione al mittente e di provvedere alla sua distruzione=
, Grazie.

This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, pri=
nting or use by anybody else is unauthorised. If you are not the intended r=
ecipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.

[cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No=
n stampare questa mail se non =E8 necessario.


--_000_A09A9E0A4B9C654E8672D1DC003633AE53A2AF901FGRFMBX704BA02_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











I am also fine with the json version being privileged in the=
 future.


However we cannot ignore completely that webfinger XML-based=
 implementations already exist (and may not upgrade all together), and we d=
o have
 already some text written in the draft so instead of deleting entirely wha=
t was written we could probably find a way to rephrase it to make it option=
al for servers to support the xml version (no appendix).



 


BTW as rfc6415 currently says, jrd is returned only in respo=
nse to host-meta.json endpoint. If only host-meta is queried, negotiation i=
s required
 using the accept header. Given the current agreement in the group, is ther=
e any change or clarification expected in the wf draft regarding this? In o=
ther words, as per current statements both xrd and jrd can already be suppo=
rted on distinct endpoints, thus
 simplifying their coexistence. But it seems to me that the group would lik=
e some stronger statements towards jrd with no need for “.json”=
 in the endpioint name neither for content negotiation (but as default cont=
ent). Am I right?


 


Regards


walter


 








Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounce=
s@ietf.org]
Per conto di John Bradley

Inviato: marted=EC 28 agosto 2012 21.13

A: Paul E. Jones

Cc: apps-discuss@ietf.org

Oggetto: Re: [apps-discuss] Proposed changes to WebFinger regarding =
XML vs JSON






 


I understand, but I think forcing servers to support=
 both will hurt adoption, though not as much as requiring it on the client.=





 






John B.




 






 






On 2012-08-28, at 3:03 PM, "Paul E. Jones"=
 <paulej@packetizer.com>=
 wrote:















John,






 






Previously, JSON and XML were MTI on servers; clients could =
implement what they want.






 






If we make the proposed change, XML will be dropped on the s=
erver side.  The result will be that clients can only rely on JSON sup=
port.  XML
 support might be rare.






 






Paul






 






PS – My personal preference is still to require XML an=
d JSON on the server, but I’m willing to give in on this one in order=
 to reach group consensus. 
 I think this was the most significant point of contention.






 












From: John
 Bradley [mailto:ve7jtb@ve7jtb.com] 

Sent: Tuesday, Aug=
ust 28, 2012 2:26 PM

To: Will Norris
Cc: Paul E. Jones;=
 
apps-discuss@ietf.org

Subject: Re: [apps=
-discuss] Proposed changes to WebFinger regarding XML vs JSON










 






+1 JSON must be MTI for ser=
vers.








 










I am not opposed to servers sup=
porting XML or other formats via content negotiation,  however clients=
 need to be interoperable with servers using JSON, and not forced to suppor=
t XML for some servers.










 










John B.










 














On 2012-08-27, at 7:13 PM, Will=
 Norris <will@willnorris.com> wrote:



















=
as one of the editors of said XML format, I'm +1 as well.  The rea=
sons for pushing so heavily for the XML format back then are no longer real=
ly true.  Instead, all the active work is on JSON-based
 formats, so it makes sense to update webfinger as well.<=
/p>





On Mon, Aug 27, 2012 at 2:56 PM=
, Paul E. Jones <paulej@packetizer.com> wrote=
:






Ok... we could also do that.










> -----Original Message-----

> From: apps-discus=
s-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]

> On Behalf Of Blaine Cook

> Sent: Monday, August 27, 2012 12:29 PM

> To: apps-discuss@ietf.org=


> Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XM=
L vs

> JSON

>

> +1 to this, and William and Tim's points.

>

> On 27 August 2012 18:26, Tim Bray <tbray@textuality.com> wr=
ote:

> > What William said about not needing the appendix. If you’re=
 going to

> > go through the pain of abandoning the XML version, why also go th=
rough

> > the pain of writing an appendix, when there’s a perfectly g=
ood RFC in

> > place to point to.  -T

> >

> > On Mon, Aug 27, 2012 at 9:17 AM, William Mills <wmills@yahoo-inc.com=
>

> wrote:

> >> I think this works in general but that there should be a ment=
ion of

> >> it in the body of the spec citing the appendix.  Do we e=
ven need an

> >> appendix though, we could simply cite 6415 as still normative=
 for the

> >> XML stuff but deprecated for new implementations.

> >>

> >>

> >> ________________________________

> >> From: Paul E. Jones <paulej@packetizer.com>

> >> To: apps-discuss=
@ietf.org

> >> Cc: jsmarr@google.co=
m; webfinger@g=
ooglegroups.com

> >> Sent: Monday, August 27, 2012 8:56 AM

> >> Subject: [apps-discuss] Proposed changes to WebFinger regardi=
ng XML

> >> vs JSON

> >>

> >> Folks,

> >>

> >> Mike, Gonzalo, and I have had some off-list discussions about=


> >> WebFinger and how to resolve the one sticky point that we thi=
nk has

> >> caused the most concern.  That point is whether we shoul=
d we allow both

> XML and JSON.

> >>

> >> We have heard proposals to "just pick one" and, whi=
le I appreciate

> >> the reasoning, I could not help ignoring that

> >>

> >>   1) RFC 6415 exists and describes XML the single mandat=
ory format

> >>   2) Existing implementations use XML

> >>

> >> Nonetheless, I also cannot ignore the long-term value in sele=
cting

> >> one format we can be sure is widely supported consistently. &=
nbsp;I'm

> >> fairly confident that most want only JSON at this point, even=
 though

> >> most (if not

> >> all) current implementations today use XML.  While I'm p=
ersonally

> >> favorable to using XML, I know my personal preferences are no=
t

> >> representative of everyone. :-)

> >>

> >> So what we discussed was mentioning XML (perhaps with example=
s), but

> >> putting that in an appendix and saying the usage is historic.=
  What

> >> this would mean is that the text acknowledges that there are =
servers

> >> that might process both XML and JSON, and even older servers =
that

> >> only process XML.  The main body of the document would o=
nly require

> >> support for JSON from clients and servers.

> >>

> >> Before we make these changes to the text, I want to seek inpu=
t from

> >> the group.  I believe it would be acceptable, but I do n=
ot want those

> >> changes to cause significant issues for anyone.

> >>

> >> Thanks,

> >> Paul

> >>

> >> PS - Please follow-up only on the apps-discuss list.

> >>

> >>

> >> _______________________________________________

> >> apps-discuss mailing list

> >> apps-discuss@iet=
f.org

> >> https://www.ietf.org/mailman/listinfo/apps-discuss<=
/span>

> >>

> >>

> >>

> >> _______________________________________________

> >> apps-discuss mailing list

> >> apps-discuss@iet=
f.org

> >> https://www.ietf.org/mailman/listinfo/apps-discuss<=
/span>

> >>

> > _______________________________________________

> > apps-discuss mailing list

> > apps-discuss@ietf.or=
g

> > 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/ap=
ps-discuss












_______________________________________________

apps-discuss mailing list

apps-=
discuss@ietf.org

https://www.ietf.org/mailman/listinfo/apps-discuss=















 

















=
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi
 altra azione derivante dalla conoscenza di queste informazioni sono rigoro=
samente vietate. Qualora abbiate ricevuto questo documento per errore siete=
 cortesemente pregati di darne immediata comunicazione al mittente e di pro=
vvedere alla sua distruzione, Grazie.



This e-mail and any attachments is confidential
 and may contain privileged information intended for the addressee(s) only.=
 Dissemination, copying, printing or use by anybody else is unauthorised. I=
f you are not the intended recipient, please delete this message and any at=
tachments and advise the sender
 by return e-mail, Thanks.


3D"rispettaRispetta=
 l'ambiente. Non stampare questa mail se non =E8 necessario.











--_000_A09A9E0A4B9C654E8672D1DC003633AE53A2AF901FGRFMBX704BA02_--

--_c65a8b6d-2a2e-4a99-887d-5e096d3cebef_
Content-Description: logo Ambiente_foglia2.jpg
Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg"
Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg"
Content-Transfer-Encoding: base64
Content-ID: 00000000000000000000000000000003@TI.Disclaimer

R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo
8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5
+4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9
p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw
SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0
FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6
YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl
uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds
3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV
OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi
oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn
qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs=

--_c65a8b6d-2a2e-4a99-887d-5e096d3cebef_--

From superuser@gmail.com  Thu Aug 30 07:12:12 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7A221F8625 for ; Thu, 30 Aug 2012 07:12:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.63
X-Spam-Level: 
X-Spam-Status: No, score=-3.63 tagged_above=-999 required=5 tests=[AWL=-0.031,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQ9Mpn9AefhE for ; Thu, 30 Aug 2012 07:12:10 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8364E21F8623 for ; Thu, 30 Aug 2012 07:12:10 -0700 (PDT)
Received: by lbky2 with SMTP id y2so648104lbk.31 for ; Thu, 30 Aug 2012 07:12: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=5TejCRs+xP84qW6DfzTxd6pxHOYEQluodQ3+fu2VML0=; b=mu+QaUwpMTcHB7EMSYkZgVZHED2HlNu5bOtRo6Aavq75IHgK6zuctMARwWwt0j55nO CZDix+5w6uWqati0f8EkVqNAGh+WuuEMxnHTMZhP7OpqKyny90+GJIw5V/TsOWnr+kAA 6wkE6a9Jzpfv1Z7WrZ5SAe3F014bevbsgvDuOMkFUPKyjtXhav74jLGWJL3YB8LVYKHu fZ8RrYY1dNa5mNAfXSJWYsi9eW+dlN+zZ8hD+LlKVW4hlWgLElPM+Rqg1cWA+koYrmzQ W7Zy65o4Uz99ePoq5U5kjtjuPpr0Sj/kuAi0oCjcpliB9SVUVvJJGYnLuqDPNm5tfjP8 fNSw==
MIME-Version: 1.0
Received: by 10.152.103.244 with SMTP id fz20mr3451953lab.54.1346335929461; Thu, 30 Aug 2012 07:12:09 -0700 (PDT)
Received: by 10.112.9.72 with HTTP; Thu, 30 Aug 2012 07:12:09 -0700 (PDT)
In-Reply-To: <503042F9.7000201@att.com>
References: <502A21A2.8060106@isode.com> <502CEC1D.3010301@att.com> <502CEE3C.3010107@isode.com> <01OJ46MC14UA0006TF@mauve.mrochek.com> <502E38CD.2050107@isode.com> <01OJ5GAZWQ9A0006TF@mauve.mrochek.com> <503042F9.7000201@att.com>
Date: Thu, 30 Aug 2012 07:12:09 -0700
Message-ID: 
From: "Murray S. Kucherawy" 
To: Tony Hansen 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Bilated issue with draft-ietf-appsawg-media-type-suffix-regs-02.txt: fragment identifier rules
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 14:12:12 -0000

On Sat, Aug 18, 2012 at 6:35 PM, Tony Hansen  wrote:
> I can work this in somewhere. Based on the discussion on fragment identifier
> precedence, I might choose my suggested wording from an earlier email
> instead.

Absent any further WG feedback in the last couple of weeks, please
proceed.  I'd like to get this off to the IESG ASAP.

Thanks,

-MSK

From internet-drafts@ietf.org  Thu Aug 30 07:24:45 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCBB21F8607; Thu, 30 Aug 2012 07:24:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.427
X-Spam-Level: 
X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixzj1wkRe2TK; Thu, 30 Aug 2012 07:24:42 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8404B21F8610; Thu, 30 Aug 2012 07:24:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20120830142439.18653.59956.idtracker@ietfa.amsl.com>
Date: Thu, 30 Aug 2012 07:24:39 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ordogh-spam-reporting-using-imap-03.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 14:24:45 -0000

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

	Title           : Spam reporting using IMAP: SREP
	Author(s)       : Zoltan Ordogh
	Filename        : draft-ordogh-spam-reporting-using-imap-03.txt
	Pages           : 16
	Date            : 2012-08-30

Abstract:
   This document defines an IMAP extension which allows a client to
   report spam by reference and allows an IMAP server to perform any
   action on the reported messages, including leaving the action at the
   client's discretion.

   In addition, this document discusses how an IMAP server can tap into
   spam aggregator services, ultimately allowing the IMAP server to
   improve its decision-making process.

Conventions Used In This Document

   In examples, "C:" and "S:" indicate lines sent by the client or the
   server, respectively.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ordogh-spam-reporting-using-imap

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ordogh-spam-reporting-using-imap-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ordogh-spam-reporting-using-imap-03


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


From ve7jtb@ve7jtb.com  Thu Aug 30 14:00:50 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D0A21F857D for ; Thu, 30 Aug 2012 14:00:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.354
X-Spam-Level: 
X-Spam-Status: No, score=-3.354 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frhpHM8mN1Mk for ; Thu, 30 Aug 2012 14:00:49 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFEC21F8552 for ; Thu, 30 Aug 2012 14:00:49 -0700 (PDT)
Received: by qadz3 with SMTP id z3so539820qad.10 for ; Thu, 30 Aug 2012 14:00:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=vMpA75eVUkUhC9FIymjoWgRyV4FjxUfHDfWAU5fLiOg=; b=YWCgZGbvg33TaYBiTMoTaem9FTbCWx9mJ1yI/VdXJs2r976TzLPP8OZ2uHFEkCvhf0 ZGt/9vA8UK3xjiLFiSw+L2w5Td5WBeashjnRgDB8uVkBF0Hwc4QnEjGRKYyCNWLOFE+z 4CFS9LpAX9VPWd29yzu0JQqXu3AsGz+I+LaSspebU2cJN/bSZ0sKmyGPNPTEKcfhEP6w gzZ9PdA0zSENcsLd4+IS+uCIGsyOvayf+lwinsIq5oWNqFxcwmDimxYs3ADwqeBwwHSW akLWYCdiNZ5jtvUwukIgoGecMbYMUwFdtGFLVcwqYfBZy5U1EiRrAlPrX0lsrw2gXbg6 DNpw==
Received: by 10.224.109.66 with SMTP id i2mr11889537qap.3.1346360448822; Thu, 30 Aug 2012 14:00:48 -0700 (PDT)
Received: from [192.168.1.213] (190-20-43-171.baf.movistar.cl. [190.20.43.171]) by mx.google.com with ESMTPS id ha5sm3568854qab.1.2012.08.30.14.00.41 (version=SSLv3 cipher=OTHER); Thu, 30 Aug 2012 14:00:46 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_1E3A19A7-6476-470A-BC51-6F70B255CF5A"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
From: John Bradley 
In-Reply-To: 
Date: Thu, 30 Aug 2012 17:00:34 -0400
Message-Id: <251A4741-1E52-41D3-B4C8-43BEDE5C79B7@ve7jtb.com>
References:  <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com>   <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com>      <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net>  <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com> <032d01cd8597$aac7f740$0057e5c0$@packetizer.com> <046501cd860c$da464420$8ed2cc60$@packe! tizer.com> <287CDD14-DE C2-40AD-AD5D-DC102D5AAAE6@ve7jtb.com>  <04f001cd8627$092727e0$1b7577a0$@packetizer.com> <90420743-8FE8-4EDB-98EF-D717D5346397@frobbit.se> <1346306587.53748.YahooMailNeo@web31804.mail.mud.yahoo.com> 
To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
X-Mailer: Apple Mail (2.1486)
X-Gm-Message-State: ALoCoQm4V2Foe6WMy/rA4JPjXelXSnhnYzKevxfYjOoryQL+Wrcopkpnf5YbvnhYg/eQjVgWPGWn
Cc: 'Mark Nottingham' , 'IETF Apps Discuss' 
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 21:00:50 -0000

--Apple-Mail=_1E3A19A7-6476-470A-BC51-6F70B255CF5A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I agree that doing it via DNS would be the proper way.

The reality is that not all clients can easily access DNS directly.  =
Doing anything more than a http get reduces adoption.

Not all DNS providers support srv records.  I think your draft on DNS =
records has expired, and I know of no support for it.
http://tools.ietf.org/html/draft-faltstrom-uri-06

Something like DNS records would be the answer, I just don't think =
protocols like Webfinger are likely to wait for wide deployment of that =
as a underlying technology.

John B.
On 2012-08-30, at 2:44 AM, Patrik F=E4ltstr=F6m  wrote:

> First, I did not talk about SRV records, but URI records.
>=20
> Secondly, I think it is fascinating that people that love new things =
like "the web" and new HTML5 features are the most conservative ones =
regarding other protocols like DNS.
>=20
> With that attitude, we have no evolution, and no innovation.
>=20
> Providers that do not support such features will die. It is that =
simple.
>=20
>   Patrik
>=20
> On 30 aug 2012, at 08:03, William Mills  wrote:
>=20
>> There are a few folks that feel that SRV records are not really an =
option for hosting situatiosn where the users don't currently have the =
ability to configure SRV records.
>>=20
>> From: Patrik F=E4ltstr=F6m 
>> To: Paul E. Jones =20
>> Cc: 'Mark Nottingham' ; 'IETF Apps Discuss' =
=20
>> Sent: Wednesday, August 29, 2012 8:01 PM
>> Subject: Re: [apps-discuss] Looking at Webfinger
>>=20
>> On 29 aug 2012, at 22:44, Paul E. Jones  =
wrote:
>>=20
>>> 1) TXT records (e.g., _webfinger.packetizer.com IN TXT =
=93https://packetizer.webfinger-provider.com/=94)
>>=20
>> Please see URI Resource Record, for example:
>>=20
>> _webfinger._tcp.packetizer.com. IN URI 0 0 =
=93https://packetizer.webfinger-provider.com/=94
>>=20
>>  Patrik
>>=20
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>=20
>>=20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


--Apple-Mail=_1E3A19A7-6476-470A-BC51-6F70B255CF5A
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgz
MDIxMDAzNFowIwYJKoZIhvcNAQkEMRYEFPI8eNLQzSytjEIO1GS1jPXRYNCdMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
AHn+mGk4WzorgDaP6P5URFJLjB5vNFiI5Mk48yNZhypMUSBmauPRxZ3ZJV71dps3Ml2+mah75GD5
lBS4enGm89efZ4GtvBBSoG5rtkwdha11GIPr5+tAuY6Vnqt/bAtPsh2N1EKGPsqExAp4YFXFeVK/
Dk+hQqsvI1cKZuJSc6Tqe6lCxDatr9k7mDA0YazPCw2kFFKT5i1lSqG4ZrJpiFx0ueL3LUzEzSEJ
mXzaPIXpBdhlVf4XXQYN/bGEyg92e2OToEet9sWOWiXHxVBhwXGJSL/WSORTRN2aXgRzadgS+Hub
B28wUVgX8fQE/YOCd37Vd/UxO9J2hFopPzB8J1cAAAAAAAA=

--Apple-Mail=_1E3A19A7-6476-470A-BC51-6F70B255CF5A--

From paf@frobbit.se  Thu Aug 30 14:41:04 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEEBA21F8535 for ; Thu, 30 Aug 2012 14:41:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvR9NSUTMDhe for ; Thu, 30 Aug 2012 14:41:04 -0700 (PDT)
Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 150B721F8513 for ; Thu, 30 Aug 2012 14:41:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id E3167159FAB76; Thu, 30 Aug 2012 23:41:02 +0200 (CEST)
X-Virus-Scanned: amavisd-new at frobbit.se
Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aZBukMIP0bb; Thu, 30 Aug 2012 23:41:02 +0200 (CEST)
Received: from [10.0.1.5] (s83-180-234-193.cust.tele2.se [83.180.234.193]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 6E4F1159FAB6F; Thu, 30 Aug 2012 23:41:02 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
From: =?windows-1252?Q?Patrik_F=E4ltstr=F6m?= 
In-Reply-To: <251A4741-1E52-41D3-B4C8-43BEDE5C79B7@ve7jtb.com>
Date: Thu, 30 Aug 2012 23:41:01 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <5234A68C-57DD-48DC-A64F-EAFFD23F8219@frobbit.se>
References:  <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com>   <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com>      <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net>  <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com> <032d01cd8597$aac7f740$0057e5c0$@packetizer.com> <046501cd860c$da464420$8ed2cc60$@packe! tizer.com> <287CDD14-DE C2-40AD-AD5D-DC102D5AAAE6@ve7jtb.com>  <04f001cd8627$092727e0$1b7577a0$@packetizer.com> <90420743-8FE8-4EDB-98EF-D717D5346397@frobbit.se> <1346306587.53748.YahooMailNeo@web31804.mail.mud.yahoo.com>  <251A4741-1E52-41D3-B4C8-43BEDE5C79B7@ve7jtb.com>
To: John Bradley 
X-Mailer: Apple Mail (2.1486)
Cc: 'Mark Nottingham' , 'IETF Apps Discuss' 
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 21:41:04 -0000

On 30 aug 2012, at 23:00, John Bradley  wrote:

> The reality is that not all clients can easily access DNS directly.

Give examples please.

   Patrik


From barryleiba@gmail.com  Thu Aug 30 22:43:00 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43FA21F846B for ; Thu, 30 Aug 2012 22:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.997
X-Spam-Level: 
X-Spam-Status: No, score=-102.997 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0S0lG+5eFZY for ; Thu, 30 Aug 2012 22:43:00 -0700 (PDT)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2534E21F8468 for ; Thu, 30 Aug 2012 22:43:00 -0700 (PDT)
Received: by vcbfo14 with SMTP id fo14so3275868vcb.31 for ; Thu, 30 Aug 2012 22:42:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=Ad57M0czOhbm0C7q5iO01cZhZJrwEjWdpPdcNn1VFuM=; b=IVv9gA4oKJpHGMyyYysbDCFgQa3EGx6wCYlzev7YjxmAsdIdpvZN9XjWYvSm6pGO6w ElhJPup/XOBVT35QuJZaRIaUiDFxvImwbxrUwoBU2m8F8yttl8MQ0BfMMtxtV7Qil8fU BTD5TPjbtemHPb9h+JlzsLHzEVkPvTPAbYxxwhxm6vRcSG63/mNcu3vr8SgqZkeofIKA KdLJPR4QH1a+2EvKs4K2auiSKj5GkE1nePOTn9YLj2SkNEyKVBAoYlojKZmxqFE+QBnT jKhdTlwFSJhK8pOQen/+iTi6xHN7m0XzZoy+zAikSfHXiVSaj/HqABNZCzqa6LGMD5GN ZQrw==
MIME-Version: 1.0
Received: by 10.52.17.48 with SMTP id l16mr4074907vdd.98.1346391779477; Thu, 30 Aug 2012 22:42:59 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.58.58.41 with HTTP; Thu, 30 Aug 2012 22:42:59 -0700 (PDT)
Date: Fri, 31 Aug 2012 01:42:59 -0400
X-Google-Sender-Auth: mHTV3wqeE90FkV5oBaCno_UMQAo
Message-ID: 
From: Barry Leiba 
To: Apps Discuss 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 05:43:00 -0000

The IESG discussed draft-ietf-appsawg-http-forwarded-07 on this week's
teleconference (Thursday).  The IESG evaluation record can be found
here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/

Stephen Farrell holds the main objections, but several other ADs agree
with him or with variants of his position.  The main two points are
these:
(1) This is NOT a good thing to standardize, and we shouldn't.
(2) This causes a serious privacy exposure, so *if* we do standardize
it, we have to address that.

After the telechat, Stephen switched his ballot from DISCUSS to
ABSTAIN.  There are two other ABSTAIN positions.  There also remain
three DISCUSS positions.  The document cannot progress unless all
three of those DISCUSS positions are cleared *and* at least one of
them moves to NO OBJECTION (well, *and* that assumes that both ADs who
are on vacation come back and ballot NO OBJECTION as well).

In short, this document is in serious trouble.

To continue discussion, the IESG intends to have a teleconference with
the document authors, and perhaps with other proponents.  If anyone
would like to actively participate in that discussion, please contact
me off list, and we'll see if we can add you -- we do need to keep it
small.  Then we'll see if we have a way forward.

Barry

From w@1wt.eu  Thu Aug 30 23:20:22 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC10421F8505 for ; Thu, 30 Aug 2012 23:20:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.616
X-Spam-Level: 
X-Spam-Status: No, score=-5.616 tagged_above=-999 required=5 tests=[AWL=-3.573, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ADntmAqr+Ft for ; Thu, 30 Aug 2012 23:20:22 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 907D421F8530 for ; Thu, 30 Aug 2012 23:20:21 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q7V6KD0V027997; Fri, 31 Aug 2012 08:20:13 +0200
Date: Fri, 31 Aug 2012 08:20:13 +0200
From: Willy Tarreau 
To: Barry Leiba 
Message-ID: <20120831062013.GA27979@1wt.eu>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Cc: Apps Discuss 
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 06:20:23 -0000

Hi Barry,

On Fri, Aug 31, 2012 at 01:42:59AM -0400, Barry Leiba wrote:
> The IESG discussed draft-ietf-appsawg-http-forwarded-07 on this week's
> teleconference (Thursday).  The IESG evaluation record can be found
> here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/
> 
> Stephen Farrell holds the main objections, but several other ADs agree
> with him or with variants of his position.  The main two points are
> these:
> (1) This is NOT a good thing to standardize, and we shouldn't.
> (2) This causes a serious privacy exposure, so *if* we do standardize
> it, we have to address that.

Well, I find it amazing that standardizing something which has been in
use everywhere for the last 10-15 years is suddenly considered as causing
issues.

If the document is finally not accepted, what will happen simply is that
everyone will naturally continue to use the x-forwarded-for header as
usual, that's all.

In my experience the main usage is on reverse-proxies, to pass the
information to origin servers, mainly for logging purposes. Its use
is already quite rare on outgoing connections. Maybe section 8.3
should be improved to suggest that "proxies forwarding traffic to
untrusted locations should refrain from using the extension" ?

Regards,
Willy


From hannes.tschofenig@gmx.net  Fri Aug 31 00:31:58 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A5021F8534 for ; Fri, 31 Aug 2012 00:31:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.423
X-Spam-Level: 
X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1L9yWt1ySfLf for ; Fri, 31 Aug 2012 00:31:57 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 2AAFF21F8535 for ; Fri, 31 Aug 2012 00:31:57 -0700 (PDT)
Received: (qmail invoked by alias); 31 Aug 2012 07:31:55 -0000
Received: from unknown (EHLO [10.255.132.3]) [194.251.119.201] by mail.gmx.net (mp069) with SMTP; 31 Aug 2012 09:31:55 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX197NfsPho97LSrhJwI5LHbUcWFboIF2dJz0ov4OoS TfNH6zwQkT2Ccx
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Hannes Tschofenig 
In-Reply-To: <20120831062013.GA27979@1wt.eu>
Date: Fri, 31 Aug 2012 10:31:52 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <7ECF41C6-84AF-4A23-BE63-365638D3B338@gmx.net>
References:  <20120831062013.GA27979@1wt.eu>
To: Willy Tarreau 
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Cc: Apps Discuss , Barry Leiba 
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 07:31:58 -0000

Hi Willy,=20

the purpose of standardization is not to publish specifications covering =
everything that is is deployed. Standardization is more than just =
documenting; it also gives a signal to the wider Internet community that =
the IETF endorses a certain technology (particularly with Standards =
Track documents). I am sure there is lots of technology deployed that =
would at best lead to "don't try this at home" recommendations.=20

Everyone who has ever followed the cookie and tracking debate may have =
noticed that this is not an uncontroversial topic. There are more =
considerations that need to be taken into account when design protocols =
than just whether it is technically possible to shuffle stuff around.=20

In fact I am really curious why Opera spends resources in standardizing =
these parameters when they are (hopefully) also trying to convince end =
customers that their browser is something they should put their trust =
in.

Ciao
Hannes

On Aug 31, 2012, at 9:20 AM, Willy Tarreau wrote:

> Hi Barry,
>=20
> On Fri, Aug 31, 2012 at 01:42:59AM -0400, Barry Leiba wrote:
>> The IESG discussed draft-ietf-appsawg-http-forwarded-07 on this =
week's
>> teleconference (Thursday).  The IESG evaluation record can be found
>> here: =
http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/
>>=20
>> Stephen Farrell holds the main objections, but several other ADs =
agree
>> with him or with variants of his position.  The main two points are
>> these:
>> (1) This is NOT a good thing to standardize, and we shouldn't.
>> (2) This causes a serious privacy exposure, so *if* we do standardize
>> it, we have to address that.
>=20
> Well, I find it amazing that standardizing something which has been in
> use everywhere for the last 10-15 years is suddenly considered as =
causing
> issues.
>=20
> If the document is finally not accepted, what will happen simply is =
that
> everyone will naturally continue to use the x-forwarded-for header as
> usual, that's all.
>=20
> In my experience the main usage is on reverse-proxies, to pass the
> information to origin servers, mainly for logging purposes. Its use
> is already quite rare on outgoing connections. Maybe section 8.3
> should be improved to suggest that "proxies forwarding traffic to
> untrusted locations should refrain from using the extension" ?
>=20
> Regards,
> Willy
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From lear@cisco.com  Fri Aug 31 00:34:17 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C295721F8535 for ; Fri, 31 Aug 2012 00:34:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.531
X-Spam-Level: 
X-Spam-Status: No, score=-110.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uaua+BcoGAsP for ; Fri, 31 Aug 2012 00:34:16 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBEA21F852A for ; Fri, 31 Aug 2012 00:34:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=1740; q=dns/txt; s=iport; t=1346398456; x=1347608056; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=SKt4pSAV0H0SladXYjToOwUrIuVc/VWnzsbDYFhq89s=; b=Ek1GZBhLvxxdWTxBdkiOqPBvK0ymctsKOsjji9iUbMJwzm3FiGazaa9/ rKIxVy4NJ0F4ow2wwTVYve7x4QWoJNt0lppWdvD1Un4ihJwRajrNwXLkF 6OrGb3ilffFLyG4RdVmMTkWSdxDjNbNDX67Gf+CelB13TCj7rfSrpvO3Z 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAKdnQFCQ/khL/2dsb2JhbABFhgS1EoEHgiABAQEEAQEBDwEQSwoBEAsOCgICBRYLAgIJAwIBAgEVMAYNAQUCAQEeh2sLnCeNGJMCgSGJZIVvgRIDlVeBFI0egWeCZQ
X-IronPort-AV: E=Sophos;i="4.80,346,1344211200"; d="scan'208";a="76368817"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 31 Aug 2012 07:34:10 +0000
Received: from dhcp-10-55-84-39.cisco.com (dhcp-10-55-84-39.cisco.com [10.55.84.39]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7V7YAMa026049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Aug 2012 07:34:10 GMT
Message-ID: <504068F3.6090601@cisco.com>
Date: Fri, 31 Aug 2012 09:34:11 +0200
From: Eliot Lear 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: Willy Tarreau 
References:  <20120831062013.GA27979@1wt.eu>
In-Reply-To: <20120831062013.GA27979@1wt.eu>
X-Enigmail-Version: 1.4.4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Barry Leiba , Apps Discuss 
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 07:34:17 -0000

Willy, Barry,

Is the way forward here an applicability statement?  If the real use is
reverse proxies it is possible to make that more clear in the document.

Eliot


On 8/31/12 8:20 AM, Willy Tarreau wrote:
> Hi Barry,
>
> On Fri, Aug 31, 2012 at 01:42:59AM -0400, Barry Leiba wrote:
>> The IESG discussed draft-ietf-appsawg-http-forwarded-07 on this week's
>> teleconference (Thursday).  The IESG evaluation record can be found
>> here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/
>>
>> Stephen Farrell holds the main objections, but several other ADs agree
>> with him or with variants of his position.  The main two points are
>> these:
>> (1) This is NOT a good thing to standardize, and we shouldn't.
>> (2) This causes a serious privacy exposure, so *if* we do standardize
>> it, we have to address that.
> Well, I find it amazing that standardizing something which has been in
> use everywhere for the last 10-15 years is suddenly considered as causing
> issues.
>
> If the document is finally not accepted, what will happen simply is that
> everyone will naturally continue to use the x-forwarded-for header as
> usual, that's all.
>
> In my experience the main usage is on reverse-proxies, to pass the
> information to origin servers, mainly for logging purposes. Its use
> is already quite rare on outgoing connections. Maybe section 8.3
> should be improved to suggest that "proxies forwarding traffic to
> untrusted locations should refrain from using the extension" ?
>
> Regards,
> Willy
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>


From hannes.tschofenig@nsn.com  Fri Aug 31 00:40:32 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6E021F852A for ; Fri, 31 Aug 2012 00:40:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.424
X-Spam-Level: 
X-Spam-Status: No, score=-106.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GY2YiZD57Snl for ; Fri, 31 Aug 2012 00:40:31 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADC821F851E for ; Fri, 31 Aug 2012 00:40:31 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q7V7e3QA023380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 31 Aug 2012 09:40:03 +0200
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q7V7dtQ4011640; Fri, 31 Aug 2012 09:40:00 +0200
Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 31 Aug 2012 09:39:57 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 31 Aug 2012 10:39:54 +0300
Message-ID: <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net>
In-Reply-To: <504068F3.6090601@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
Thread-Index: Ac2HSxL4jTbu0EH8QMWlw28BjfKNDAAADmig
References: <20120831062013.GA27979@1wt.eu> <504068F3.6090601@cisco.com>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" 
To: "ext Eliot Lear" , "Willy Tarreau" 
X-OriginalArrivalTime: 31 Aug 2012 07:39:57.0446 (UTC) FILETIME=[D1B8D260:01CD874B]
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 2712
X-purgate-ID: 151667::1346398803-00006F5F-29DC7044/0-0/0-0
Cc: Barry Leiba , Apps Discuss 
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 07:40:32 -0000

Eliot,=20

The reverse proxy story is a way to make this look good and we know it
will be used otherwise.=20

I don't know why aren't acknowledging that there are privacy concerns as
well even if they are inconvenient for an engineer. Just adding fluffy
and warm text does not make these concerns go away. I think we are
cheating here.=20

Ciao
Hannes

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of ext Eliot Lear
> Sent: Friday, August 31, 2012 10:34 AM
> To: Willy Tarreau
> Cc: Barry Leiba; Apps Discuss
> Subject: Re: [apps-discuss] Status of
draft-ietf-appsawg-http-forwarded
>=20
> Willy, Barry,
>=20
> Is the way forward here an applicability statement?  If the real use
is
> reverse proxies it is possible to make that more clear in the
document.
>=20
> Eliot
>=20
>=20
> On 8/31/12 8:20 AM, Willy Tarreau wrote:
> > Hi Barry,
> >
> > On Fri, Aug 31, 2012 at 01:42:59AM -0400, Barry Leiba wrote:
> >> The IESG discussed draft-ietf-appsawg-http-forwarded-07 on this
> week's
> >> teleconference (Thursday).  The IESG evaluation record can be found
> >> here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-
> forwarded/ballot/
> >>
> >> Stephen Farrell holds the main objections, but several other ADs
> agree
> >> with him or with variants of his position.  The main two points are
> >> these:
> >> (1) This is NOT a good thing to standardize, and we shouldn't.
> >> (2) This causes a serious privacy exposure, so *if* we do
> standardize
> >> it, we have to address that.
> > Well, I find it amazing that standardizing something which has been
> in
> > use everywhere for the last 10-15 years is suddenly considered as
> causing
> > issues.
> >
> > If the document is finally not accepted, what will happen simply is
> that
> > everyone will naturally continue to use the x-forwarded-for header
as
> > usual, that's all.
> >
> > In my experience the main usage is on reverse-proxies, to pass the
> > information to origin servers, mainly for logging purposes. Its use
> > is already quite rare on outgoing connections. Maybe section 8.3
> > should be improved to suggest that "proxies forwarding traffic to
> > untrusted locations should refrain from using the extension" ?
> >
> > Regards,
> > Willy
> >
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >
> >
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

From w@1wt.eu  Fri Aug 31 00:54:38 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459A721F8504 for ; Fri, 31 Aug 2012 00:54:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.578
X-Spam-Level: 
X-Spam-Status: No, score=-5.578 tagged_above=-999 required=5 tests=[AWL=-3.535, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udxpSYrD8F8b for ; Fri, 31 Aug 2012 00:54:37 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 61B8021F84E4 for ; Fri, 31 Aug 2012 00:54:37 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q7V7sUcS028291; Fri, 31 Aug 2012 09:54:30 +0200
Date: Fri, 31 Aug 2012 09:54:30 +0200
From: Willy Tarreau 
To: "Tschofenig, Hannes (NSN - FI/Espoo)" 
Message-ID: <20120831075430.GA28281@1wt.eu>
References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net>
User-Agent: Mutt/1.4.2.3i
Cc: Barry Leiba , Apps Discuss 
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 07:54:38 -0000

Hi Hannes,

On Fri, Aug 31, 2012 at 10:39:54AM +0300, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> Eliot, 
> 
> The reverse proxy story is a way to make this look good and we know it
> will be used otherwise. 

It's not a way to make it look good, it's really used and needed on
server-side.

> I don't know why aren't acknowledging that there are privacy concerns as
> well even if they are inconvenient for an engineer. Just adding fluffy
> and warm text does not make these concerns go away. I think we are
> cheating here. 

But then what are you proposing ? It's just like saying that we should
forbid eating with forks and knifes in restaurants because some people
might use the knife to kill their noisy neighbour. Everything which is
created has good and bad usages. And I see this draft as an opportunity
to remind implementors about what to do and what not to do. Right now,
they're acting blindly, deploying their proxies without even knowing
that they're sending xff to the whole world.

Regards,
Willy


From lear@cisco.com  Fri Aug 31 01:19:18 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB9A21F850D for ; Fri, 31 Aug 2012 01:19:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.532
X-Spam-Level: 
X-Spam-Status: No, score=-110.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpWv5zLGCKf6 for ; Fri, 31 Aug 2012 01:19:17 -0700 (PDT)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 5C59721F850C for ; Fri, 31 Aug 2012 01:19:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=824; q=dns/txt; s=iport; t=1346401154; x=1347610754; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=zoNdnchJjw921RtLNMg2n2VNkXShMdAskHrokom/kY0=; b=OJxbMU/wv8SEWkJaCSEh9O9Jw6PRt/rOGC3rQ/oFTkJg3Sg6jL6hEWkO INotDG0Sc8Z4L0JDBm5uFcnkGQuZo9tt3brpIzobVxIulLdEAMzUmPWl9 AIiwFgglkQQzO8JLa3Jnf1vt40VIC+hjospCFu9xFRNdGe28s0WKeYfsT k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAB9zQFCQ/khL/2dsb2JhbABFhgS1EoEHgiABAQEEEgEQVQEQCxgCAgUWCwICCQMCAQIBRQYNAQcBAR6Ha5w5jA6BCpMAgSGPU4ESA5VXjjKBZ4Jl
X-IronPort-AV: E=Sophos;i="4.80,346,1344211200";  d="scan'208";a="7706868"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 31 Aug 2012 08:19:10 +0000
Received: from dhcp-10-55-84-39.cisco.com (dhcp-10-55-84-39.cisco.com [10.55.84.39]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7V8J8dn001416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Aug 2012 08:19:09 GMT
Message-ID: <5040737D.9000902@cisco.com>
Date: Fri, 31 Aug 2012 10:19:09 +0200
From: Eliot Lear 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: "Tschofenig, Hannes (NSN - FI/Espoo)" 
References: <20120831062013.GA27979@1wt.eu> <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net>
In-Reply-To: <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net>
X-Enigmail-Version: 1.4.4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Barry Leiba , Willy Tarreau , Apps Discuss 
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 08:19:18 -0000

On 8/31/12 9:39 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> Eliot, 
>
> The reverse proxy story is a way to make this look good and we know it
> will be used otherwise. 

I think you are concerned that an ill informed national policy might
require the use of this header, such that it exposes PII to UNAUTHORIZED
people.  It's not that you're thinking that enterprise administrators
will have removed their brains and simply would allow this sort of
exposure.  Is that correct?  If so, I understand and share this concern,
and it should be documented that this is the wrong lever and can lead to
serious security problems, if used on an outbound proxy.

As I understand it, you and Alissa just released a brand new related RFC
on this topic relating to GEOPRIV, by the way.  Congratulations!

Eliot

From adrian@olddog.co.uk  Fri Aug 31 02:55:03 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F87921F850C for ; Fri, 31 Aug 2012 02:55:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.533
X-Spam-Level: 
X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hv0kkOlz17Bp for ; Fri, 31 Aug 2012 02:55:02 -0700 (PDT)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 832F821F8460 for ; Fri, 31 Aug 2012 02:55:02 -0700 (PDT)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7V9sXtK026028;  Fri, 31 Aug 2012 10:54:33 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7V9sVv1025995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 Aug 2012 10:54:32 +0100
From: "Adrian Farrel" 
To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ext Eliot Lear'" , "'Willy Tarreau'" 
References: <20120831062013.GA27979@1wt.eu>	<504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net>
In-Reply-To: <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net>
Date: Fri, 31 Aug 2012 10:54:31 +0100
Message-ID: <231501cd875e$9ef0a8e0$dcd1faa0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFU1B6Tib1wocR1GyruuKpTjzBBXAHZ1Gd9AdCbGu4CawLgNJg0Z2Bw
Content-Language: en-gb
Cc: 'Barry Leiba' , 'Apps Discuss' 
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Aug 2012 09:55:03 -0000

Hannes has, to some extent captured the nature of my Discuss (which I don't
think Barry represented at all well in his original email).

The current document does not lead me to understand what problem is being
solved. I am just shown a solution (which I believe is perfectly functional).

I need to see why this is being developed and what it is for. I should note that
it is possible that when I am shown the answer to that question, I will decide
that I don't believe the problem or that it is out of scope for the IETF or that
it is pure evil :-) But until I see the answer I cannot begin to guess.

I also need to understand why if, as I am repeatedly told, there is a perfectly
functional solution in place at the moment (to the extent that if we did not
publish this document as an RFC, the existing solution would simply continue to
be used), we need to document another solution.

These details need to be captured in the document. Hopefully, the WG has already
reached agreement on these points (or else why request publication?) and so the
task is as simple as writing up a record of the WG's discussions.

On the topic of privacy, I believe that the WG is well aware that privacy is a
sensitive issue and can easily see that this document could be construed as
violating privacy. Therefore (per my Comment) the WG really should spend some
time documenting (in this I-D) the impact this work has on privacy. It may be
that the such text can demonstrate that the work does not have a substantive
impact.

Thanks,
Adrian

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
> On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: 31 August 2012 08:40
> To: ext Eliot Lear; Willy Tarreau
> Cc: Barry Leiba; Apps Discuss
> Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
> 
> Eliot,
> 
> The reverse proxy story is a way to make this look good and we know it
> will be used otherwise.
> 
> I don't know why aren't acknowledging that there are privacy concerns as
> well even if they are inconvenient for an engineer. Just adding fluffy
> and warm text does not make these concerns go away. I think we are
> cheating here.
> 
> Ciao
> Hannes
> 
> > -----Original Message-----
> > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> > bounces@ietf.org] On Behalf Of ext Eliot Lear
> > Sent: Friday, August 31, 2012 10:34 AM
> > To: Willy Tarreau
> > Cc: Barry Leiba; Apps Discuss
> > Subject: Re: [apps-discuss] Status of
> draft-ietf-appsawg-http-forwarded
> >
> > Willy, Barry,
> >
> > Is the way forward here an applicability statement?  If the real use
> is
> > reverse proxies it is possible to make that more clear in the
> document.
> >
> > Eliot
> >
> >
> > On 8/31/12 8:20 AM, Willy Tarreau wrote:
> > > Hi Barry,
> > >
> > > On Fri, Aug 31, 2012 at 01:42:59AM -0400, Barry Leiba wrote:
> > >> The IESG discussed draft-ietf-appsawg-http-forwarded-07 on this
> > week's
> > >> teleconference (Thursday).  The IESG evaluation record can be found
> > >> here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-
> > forwarded/ballot/
> > >>
> > >> Stephen Farrell holds the main objections, but several other ADs
> > agree
> > >> with him or with variants of his position.  The main two points are
> > >> these:
> > >> (1) This is NOT a good thing to standardize, and we shouldn't.
> > >> (2) This causes a serious privacy exposure, so *if* we do
> > standardize
> > >> it, we have to address that.
> > > Well, I find it amazing that standardizing something which has been
> > in
> > > use everywhere for the last 10-15 years is suddenly considered as
> > causing
> > > issues.
> > >
> > > If the document is finally not accepted, what will happen simply is
> > that
> > > everyone will naturally continue to use the x-forwarded-for header
> as
> > > usual, that's all.
> > >
> > > In my experience the main usage is on reverse-proxies, to pass the
> > > information to origin servers, mainly for logging purposes. Its use
> > > is already quite rare on outgoing connections. Maybe section 8.3
> > > should be improved to suggest that "proxies forwarding traffic to
> > > untrusted locations should refrain from using the extension" ?
> > >
> > > Regards,
> > > Willy
> > >
> > > _______________________________________________
> > > 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 andreas@sbin.se  Fri Aug 31 03:52:42 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8111F21F8468 for ; Fri, 31 Aug 2012 03:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.511
X-Spam-Level: 
X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nfx1qiE7+zYf for ; Fri, 31 Aug 2012 03:52:42 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id A45D321F853C for ; Fri, 31 Aug 2012 03:52:41 -0700 (PDT)
Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7VAqdMo007305 for ; Fri, 31 Aug 2012 10:52:39 GMT
Date: Fri, 31 Aug 2012 12:52:37 +0200
From: Andreas Petersson 
To: apps-discuss@ietf.org
Message-ID: <20120831125237.3c978218@hetzer>
In-Reply-To: <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net>
References:  <20120831062013.GA27979@1wt.eu> <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net>
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 10:52:42 -0000

On Fri, 31 Aug 2012 10:39:54 +0300
"Tschofenig, Hannes (NSN - FI/Espoo)"  wrote:

> Eliot, 
> 
> The reverse proxy story is a way to make this look good and we know it
> will be used otherwise. 
> 
> I don't know why aren't acknowledging that there are privacy concerns as
> well even if they are inconvenient for an engineer. Just adding fluffy
> and warm text does not make these concerns go away. I think we are
> cheating here. 
> 

Have you read the section "Privacy Considerations"?


 /Andreas Petersson

From stephen.farrell@cs.tcd.ie  Fri Aug 31 05:17:44 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05A221F846E for ; Fri, 31 Aug 2012 05:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rPP9YGZYogj for ; Fri, 31 Aug 2012 05:17:43 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id C2B3021F8468 for ; Fri, 31 Aug 2012 05:17:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 10F51171490; Fri, 31 Aug 2012 13:17:43 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1346415461; bh=Xsy00FNwPw7m/j jTZ2ShCx3vf6UPtOBka9UzeWtxkzQ=; b=eeoD+k5WLrseWSuwDip0+t6ZG1y1EW 8qN6wtDvOXTvTZC6nTeFa4h+VGahRk03/gjJ29Pg2mucWvIPPyXtgWKQ6HgrnrWW mql0i706R53HteIy3Z3oHUtCY4iKczznkFo0BJmNtOn2jJAEJJLaDJ67S0Jx6Qll 7nekzJ8mujLjEwtDNKuoB+ySuWOn9pYByq+/4jDi+a9w7bO4IxUfGUnLOBO8iKH2 XHeVxYm9q7RD5iK27i7wQsVYy14Dwq45rCpf8RJSx4Bp2fhZ0PKSiIqus3VQqbMw LSSQH4qvK8F1KQ4V1/bJPbxdfwtSyN25tSGjtwztmjF1yKZVs77S5ROg==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id DqYBZ6vlyiYN; Fri, 31 Aug 2012 13:17:41 +0100 (IST)
Received: from [IPv6:2001:770:10:203:e4ad:7c8c:8eb4:a868] (unknown [IPv6:2001:770:10:203:e4ad:7c8c:8eb4:a868]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 574E117148A; Fri, 31 Aug 2012 13:17:38 +0100 (IST)
Message-ID: <5040AB63.4050707@cs.tcd.ie>
Date: Fri, 31 Aug 2012 13:17:39 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Eliot Lear 
References: <20120831062013.GA27979@1wt.eu> <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <5040737D.9000902@cisco.com>
In-Reply-To: <5040737D.9000902@cisco.com>
X-Enigmail-Version: 1.4.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Barry Leiba , Willy Tarreau , Apps Discuss 
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 12:17:44 -0000

Hi Eliot,

On 08/31/2012 09:19 AM, Eliot Lear wrote:
> 
> On 8/31/12 9:39 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>> Eliot, 
>>
>> The reverse proxy story is a way to make this look good and we know it
>> will be used otherwise. 
> 
> I think you are concerned that an ill informed national policy might
> require the use of this header, such that it exposes PII to UNAUTHORIZED
> people.  

I don't know of any country-level requirements here though
they could exist or come into existence if XFF were to be
standardised.

>From what I've read, e.g. [1,2], it appears to be on by default
in some popular proxies which would imply that if you consider
the client IP address as PII, then that's being sent loads of
places with nothing remotely resembling authorization.

I don't know for sure though, some real usage information
would be useful both about who is sending it and what sites
are doing when they get it.

S.

[1] http://en.wikipedia.org/wiki/X-Forwarded-For
[2] http://meta.wikimedia.org/wiki/XFF_project

> It's not that you're thinking that enterprise administrators
> will have removed their brains and simply would allow this sort of
> exposure.  Is that correct?  If so, I understand and share this concern,
> and it should be documented that this is the wrong lever and can lead to
> serious security problems, if used on an outbound proxy.
> 
> As I understand it, you and Alissa just released a brand new related RFC
> on this topic relating to GEOPRIV, by the way.  Congratulations!
> 
> Eliot
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> 
> 

From stephen.farrell@cs.tcd.ie  Fri Aug 31 05:19:37 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA06821F8487 for ; Fri, 31 Aug 2012 05:19:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8aW9DsLLZ4N for ; Fri, 31 Aug 2012 05:19:37 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 1651321F846F for ; Fri, 31 Aug 2012 05:19:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 808B9171490; Fri, 31 Aug 2012 13:19:36 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1346415576; bh=CWM8hgyFiUZ+x7 pm9VG+w36tOOkoITkre+SFZdkwntg=; b=OdJsAeFv73P9Myan3PcB9MpY1K+EYj rJ42JeTQWMP1Lv0n3xJse0/2qZLpKDic50DX3FuzGCp5ijuGEgauspNdOylzOKc7 HF4ncCpTf2L0HLOjoWOMObB+0Ag2716+2wKhMXxigfqpX/QWinb+wqsvbWlVGhbT V/afNuwk06Gh/5fjowvZrup/t+RmGvP9jbn2q+9JWCHotPtqPAoGN/107lqw3xyd ovhn5gvskGyfGlUijTPS2Cv6wyEcIkm7qdIXNjslkkhiS70Rn11sC9enYV5BiXks C/reya2cedbieFPtwfoSy42yzxBT5YJQgQpa3bXGKd49zDw9KoMsvXNg==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id MpSy3qhWCfZG; Fri, 31 Aug 2012 13:19:36 +0100 (IST)
Received: from [IPv6:2001:770:10:203:e4ad:7c8c:8eb4:a868] (unknown [IPv6:2001:770:10:203:e4ad:7c8c:8eb4:a868]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id E715D17148A; Fri, 31 Aug 2012 13:19:34 +0100 (IST)
Message-ID: <5040ABD7.6040300@cs.tcd.ie>
Date: Fri, 31 Aug 2012 13:19:35 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Willy Tarreau 
References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu>
In-Reply-To: <20120831075430.GA28281@1wt.eu>
X-Enigmail-Version: 1.4.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Barry Leiba , Apps Discuss 
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 12:19:37 -0000

Hi Willy,

On 08/31/2012 08:54 AM, Willy Tarreau wrote:
> And I see this draft as an opportunity
> to remind implementors about what to do and what not to do. Right now,
> they're acting blindly, deploying their proxies without even knowing
> that they're sending xff to the whole world.

That sounds like two different but good things. Thing1 being
tell implementers more about what to do and not to do with XFF
code and whether to have it on by default or not if they do
support it, and thing2 being to tell deployers about the
consequences of having XFF turned on or off and what you
can and cannot safely do with XFF.

Neither would require standardising a new header field.

But I don't think those things are in this draft, which
basically says how to manipulate a new header field that does
the same thing as XFF, but is more well-defined.

I suspect a document that described XFF implementation
and deployment issues as above would be good input for
designing for a new header field, were that to be
desirable. (I remain unconvinced.)

S.

From w@1wt.eu  Fri Aug 31 05:49:48 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5311221F8565 for ; Fri, 31 Aug 2012 05:49:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.241
X-Spam-Level: 
X-Spam-Status: No, score=-5.241 tagged_above=-999 required=5 tests=[AWL=-3.798, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_54=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5POP1k42Di-B for ; Fri, 31 Aug 2012 05:49:47 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 7E62621F855D for ; Fri, 31 Aug 2012 05:49:47 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q7VCnesx029254; Fri, 31 Aug 2012 14:49:40 +0200
Date: Fri, 31 Aug 2012 14:49:40 +0200
From: Willy Tarreau 
To: Stephen Farrell 
Message-ID: <20120831124940.GB28461@1wt.eu>
References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <5040ABD7.6040300@cs.tcd.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5040ABD7.6040300@cs.tcd.ie>
User-Agent: Mutt/1.4.2.3i
Cc: Barry Leiba , Apps Discuss 
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 12:49:48 -0000

Hi Stephen,

On Fri, Aug 31, 2012 at 01:19:35PM +0100, Stephen Farrell wrote:
> 
> Hi Willy,
> 
> On 08/31/2012 08:54 AM, Willy Tarreau wrote:
> > And I see this draft as an opportunity
> > to remind implementors about what to do and what not to do. Right now,
> > they're acting blindly, deploying their proxies without even knowing
> > that they're sending xff to the whole world.
> 
> That sounds like two different but good things. Thing1 being
> tell implementers more about what to do and not to do with XFF
> code and whether to have it on by default or not if they do
> support it, and thing2 being to tell deployers about the
> consequences of having XFF turned on or off and what you
> can and cannot safely do with XFF.
> 
> Neither would require standardising a new header field.

IIRC the first motivation for changing the header field name is that
X-anything cannot be a standard header by definition. The second one
is that as with any non-standard thing,some usages were not
compatible among implementations (eg: encoding of IPv6 addresses,
passing of source port, original Host header and scheme).

> But I don't think those things are in this draft, which
> basically says how to manipulate a new header field that does
> the same thing as XFF, but is more well-defined.

Maybe then a bit more of context may help at the beginning of the
draft ?

> I suspect a document that described XFF implementation
> and deployment issues as above would be good input for
> designing for a new header field, were that to be
> desirable. (I remain unconvinced.)

As I explained above, due to implementation incompatibilities which
currently exist, trying to force changing how XFF is currently used
would at best be ignored, at worst make things worse from an interop
point of view.

Regards,
Willy


From stephen.farrell@cs.tcd.ie  Fri Aug 31 06:03:22 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0310C21F8525 for ; Fri, 31 Aug 2012 06:03:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level: 
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jf4HoL18OXiB for ; Fri, 31 Aug 2012 06:03:20 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id C430821F851B for ; Fri, 31 Aug 2012 06:03:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 12C0C171493; Fri, 31 Aug 2012 14:03:19 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1346418198; bh=GHZJk18U0mO9gT dMlQEwcdgE42iBWM7Vg1HNa5sYqiM=; b=4PupGMlVFZZolVbwiZgg5jgEMPVfI7 7YuCRpmDp52UVmI+P0dkvXRmHXSnLEU1JAm9uaY+UxpSntgjY9KZzi8+7jtzvGI+ tOhi30JHoIW1j/ikhgk4YnlInZ9+uRNZwfUC4wJHyUp43eRPqN+HgHgOmKuK9kfW alFxl1HB98ksIa6UpyM6gcRDT+v2lj4V2LYPxCXMkraLcKaTX7KRe15HEjMZUQHZ gK9OnAl2jCKUWGzzekXTl1uHLlVE9Kk8X48xlTplJcJMBFGJ9ZpedFlDyfb4mftB 43eC3YIgnPn4AkMccdlM5sY5eQNdmW7bTR2T+pjUh3Xkljs/o0L/EJlQ==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id fIga2NR2bXBu; Fri, 31 Aug 2012 14:03:18 +0100 (IST)
Received: from [IPv6:2001:770:10:203:e4ad:7c8c:8eb4:a868] (unknown [IPv6:2001:770:10:203:e4ad:7c8c:8eb4:a868]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 2ABDD171490; Fri, 31 Aug 2012 14:03:17 +0100 (IST)
Message-ID: <5040B615.8020603@cs.tcd.ie>
Date: Fri, 31 Aug 2012 14:03:17 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Willy Tarreau 
References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <5040ABD7.6040300@cs.tcd.ie> <20120831124940.GB28461@1wt.eu>
In-Reply-To: <20120831124940.GB28461@1wt.eu>
X-Enigmail-Version: 1.4.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Barry Leiba , Apps Discuss 
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 13:03:22 -0000

Hiya,

On 08/31/2012 01:49 PM, Willy Tarreau wrote:
> Hi Stephen,
> 
> On Fri, Aug 31, 2012 at 01:19:35PM +0100, Stephen Farrell wrote:
>>
>> Hi Willy,
>>
>> On 08/31/2012 08:54 AM, Willy Tarreau wrote:
>>> And I see this draft as an opportunity
>>> to remind implementors about what to do and what not to do. Right now,
>>> they're acting blindly, deploying their proxies without even knowing
>>> that they're sending xff to the whole world.
>>
>> That sounds like two different but good things. Thing1 being
>> tell implementers more about what to do and not to do with XFF
>> code and whether to have it on by default or not if they do
>> support it, and thing2 being to tell deployers about the
>> consequences of having XFF turned on or off and what you
>> can and cannot safely do with XFF.
>>
>> Neither would require standardising a new header field.
> 
> IIRC the first motivation for changing the header field name is that
> X-anything cannot be a standard header by definition. The second one
> is that as with any non-standard thing,some usages were not
> compatible among implementations (eg: encoding of IPv6 addresses,
> passing of source port, original Host header and scheme).

But those only apply after one is convinced that standardising
a "better" XFF is a good idea.

> 
>> But I don't think those things are in this draft, which
>> basically says how to manipulate a new header field that does
>> the same thing as XFF, but is more well-defined.
> 
> Maybe then a bit more of context may help at the beginning of the
> draft ?

I suspect its really a different document entirely that
documents current XFF implementation and deployment
practices. I reckon that text might be a good bit longer
than the entire current draft.

> 
>> I suspect a document that described XFF implementation
>> and deployment issues as above would be good input for
>> designing for a new header field, were that to be
>> desirable. (I remain unconvinced.)
> 
> As I explained above, due to implementation incompatibilities which
> currently exist, trying to force changing how XFF is currently used
> would at best be ignored, at worst make things worse from an interop
> point of view.

I do get the point but I don't agree that just because a
buggy <> has been deployed means we ought to standardise
<> without those bugs.

S.

> 
> Regards,
> Willy
> 
> 
> 

From w@1wt.eu  Fri Aug 31 06:09:07 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19B921F8570 for ; Fri, 31 Aug 2012 06:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Level: 
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[AWL=-3.759, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_54=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbDwkMuVB8FR for ; Fri, 31 Aug 2012 06:09:06 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE4621F846F for ; Fri, 31 Aug 2012 06:09:05 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q7VD8tdW029307; Fri, 31 Aug 2012 15:08:55 +0200
Date: Fri, 31 Aug 2012 15:08:55 +0200
From: Willy Tarreau 
To: Stephen Farrell 
Message-ID: <20120831130855.GC28461@1wt.eu>
References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <5040ABD7.6040300@cs.tcd.ie> <20120831124940.GB28461@1wt.eu> <5040B615.8020603@cs.tcd.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5040B615.8020603@cs.tcd.ie>
User-Agent: Mutt/1.4.2.3i
Cc: Barry Leiba , Apps Discuss 
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 13:09:07 -0000

On Fri, Aug 31, 2012 at 02:03:17PM +0100, Stephen Farrell wrote:
> > IIRC the first motivation for changing the header field name is that
> > X-anything cannot be a standard header by definition. The second one
> > is that as with any non-standard thing,some usages were not
> > compatible among implementations (eg: encoding of IPv6 addresses,
> > passing of source port, original Host header and scheme).
> 
> But those only apply after one is convinced that standardising
> a "better" XFF is a good idea.

All people working on the server side are already convinced about that,
they're all facing the same interoperability issues and they need it
for logging purposes (at least).

> >> But I don't think those things are in this draft, which
> >> basically says how to manipulate a new header field that does
> >> the same thing as XFF, but is more well-defined.
> > 
> > Maybe then a bit more of context may help at the beginning of the
> > draft ?
> 
> I suspect its really a different document entirely that
> documents current XFF implementation and deployment
> practices. I reckon that text might be a good bit longer
> than the entire current draft.

It would not be wise to document wrong practices of non-standard header
fields which do not respect the standardized header field format. HTTP
is crappy enough to avoid adding another exception on top of it.

> >> I suspect a document that described XFF implementation
> >> and deployment issues as above would be good input for
> >> designing for a new header field, were that to be
> >> desirable. (I remain unconvinced.)
> > 
> > As I explained above, due to implementation incompatibilities which
> > currently exist, trying to force changing how XFF is currently used
> > would at best be ignored, at worst make things worse from an interop
> > point of view.
> 
> I do get the point but I don't agree that just because a
> buggy <> has been deployed means we ought to standardise
> <> without those bugs.

I don't get your point here, sorry. I read it as "we failed somewhere,
let's not fix it because it already exists" so I assume you meant
something else :-/

Regards,
Willy


From barryleiba@gmail.com  Fri Aug 31 06:09:15 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107CC21F85B1 for ; Fri, 31 Aug 2012 06:09:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.017
X-Spam-Level: 
X-Spam-Status: No, score=-103.017 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcfbmFICI0as for ; Fri, 31 Aug 2012 06:09:14 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD2721F85AE for ; Fri, 31 Aug 2012 06:09:14 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so3601009vbb.31 for ; Fri, 31 Aug 2012 06:09:13 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=n2SfkhlHsXe/odRyUc3q+D9qiot5jyfIi5OETJTtsEQ=; b=S6Hhqu4LtZJmf7zJ3ipWDm2W7GFe3aDdCG2pghnefY8jJ1kZQlW3c4R74VoIRHMpet K27Q4zi0xLc7/jo3HIcbgOVo2AC4cX3PRZeDLO4A7qkLlae7/BrLwIte4faoLz+oJxLj AqYdnOh7QoFmDuKsQd5OWE+7HFAI6o6DgD7Fu120eekPVyBhNtT3smmNOxS6BX42FBFy Mv3rHjYyUP5m1w7JkQvQ+go7JoX1PM7BLelHXlK5/OERlxrOBsd+bTv/9+riY4hAtHx6 GftYeaSp/HSQlKkMq6hIhDeX6KrWR7t2CBXW0+BqGCFmsuFFIK1YsTpX10roId/HWM36 8w6A==
MIME-Version: 1.0
Received: by 10.58.209.73 with SMTP id mk9mr6178764vec.25.1346418553688; Fri, 31 Aug 2012 06:09:13 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.58.58.41 with HTTP; Fri, 31 Aug 2012 06:09:13 -0700 (PDT)
In-Reply-To: <231501cd875e$9ef0a8e0$dcd1faa0$@olddog.co.uk>
References:  <20120831062013.GA27979@1wt.eu> <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <231501cd875e$9ef0a8e0$dcd1faa0$@olddog.co.uk>
Date: Fri, 31 Aug 2012 09:09:13 -0400
X-Google-Sender-Auth: gYjNtVKKnZ0zzIkj1PNs7g-kQmA
Message-ID: 
From: Barry Leiba 
To: adrian@olddog.co.uk
Content-Type: text/plain; charset=ISO-8859-1
Cc: Apps Discuss 
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 13:09:15 -0000

> Hannes has, to some extent captured the nature of my Discuss (which I don't
> think Barry represented at all well in his original email).
>
> The current document does not lead me to understand what problem is being
> solved. I am just shown a solution (which I believe is perfectly functional).
>
> I need to see why this is being developed and what it is for.

Sorry, Adrian: my intent was to give only the briefest summary of the
situation, and to send people to the DISCUSS text for more details.
Thanks for joining the discussion on the list.

Barry

From stephen.farrell@cs.tcd.ie  Fri Aug 31 06:16:02 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD58B21F85AE for ; Fri, 31 Aug 2012 06:16:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.262
X-Spam-Level: 
X-Spam-Status: No, score=-102.262 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eh0tvaCeZ51z for ; Fri, 31 Aug 2012 06:16:02 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id E795821F85AD for ; Fri, 31 Aug 2012 06:16:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 4E0BC17148A; Fri, 31 Aug 2012 14:16:01 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1346418960; bh=1MU6uPR/JIl67Y IjmHMjc4tN0DpySFZVcoCDwc0FE2w=; b=22uwkldEf8ybF9tH3ortzcNOQu9LC7 xwsFtnaWSyhEKxNZVP0oNBatJF1RqNkL79LGr/1dgVfDw7YuMSr5Chl5s/7xm4ZP TJIW/QF/uoRJiueKRXFWXyjejWMLrYjq3qqGNEVrAPSH7Pf7agGjrX442K3R2wq1 NyQqyfMQmYGZqGOspnl9D3dTMdBtPL39e/66/c3rSvn+Ec2dsKA5RH1ul3Cw49ss wZCxO3J8TnounVBrLDWiP4t+pglMo/nwJ9GcYSUGIbEWPNklnDCA/cCcH94ylfmn btJLO7LSk5+9SeP1Faq57iVpsl27JiTENRpVMAwAvQLZZYWL+4lcEe1w==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id fIf4GmyR6PWo; Fri, 31 Aug 2012 14:16:00 +0100 (IST)
Received: from [IPv6:2001:770:10:203:e4ad:7c8c:8eb4:a868] (unknown [IPv6:2001:770:10:203:e4ad:7c8c:8eb4:a868]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 60622171490; Fri, 31 Aug 2012 14:15:59 +0100 (IST)
Message-ID: <5040B910.6070705@cs.tcd.ie>
Date: Fri, 31 Aug 2012 14:16:00 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Willy Tarreau 
References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <5040ABD7.6040300@cs.tcd.ie> <20120831124940.GB28461@1wt.eu> <5040B615.8020603@cs.tcd.ie> <20120831130855.GC28461@1wt.eu>
In-Reply-To: <20120831130855.GC28461@1wt.eu>
X-Enigmail-Version: 1.4.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Barry Leiba , Apps Discuss 
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 13:16:03 -0000

On 08/31/2012 02:08 PM, Willy Tarreau wrote:
> On Fri, Aug 31, 2012 at 02:03:17PM +0100, Stephen Farrell wrote:
>>> IIRC the first motivation for changing the header field name is that
>>> X-anything cannot be a standard header by definition. The second one
>>> is that as with any non-standard thing,some usages were not
>>> compatible among implementations (eg: encoding of IPv6 addresses,
>>> passing of source port, original Host header and scheme).
>>
>> But those only apply after one is convinced that standardising
>> a "better" XFF is a good idea.
> 
> All people working on the server side are already convinced about that,
> they're all facing the same interoperability issues and they need it
> for logging purposes (at least).

That last is kinda vague though isn't it?

>>>> But I don't think those things are in this draft, which
>>>> basically says how to manipulate a new header field that does
>>>> the same thing as XFF, but is more well-defined.
>>>
>>> Maybe then a bit more of context may help at the beginning of the
>>> draft ?
>>
>> I suspect its really a different document entirely that
>> documents current XFF implementation and deployment
>> practices. I reckon that text might be a good bit longer
>> than the entire current draft.
> 
> It would not be wise to document wrong practices of non-standard header
> fields which do not respect the standardized header field format. HTTP
> is crappy enough to avoid adding another exception on top of it.

I don't get how that squares with what you said earlier:

   "And I see this draft as an opportunity
    to remind implementors about what to do and what not to do.
    Right now, they're acting blindly, deploying their proxies
    without even knowing that they're sending xff to the whole
    world."

> 
>>>> I suspect a document that described XFF implementation
>>>> and deployment issues as above would be good input for
>>>> designing for a new header field, were that to be
>>>> desirable. (I remain unconvinced.)
>>>
>>> As I explained above, due to implementation incompatibilities which
>>> currently exist, trying to force changing how XFF is currently used
>>> would at best be ignored, at worst make things worse from an interop
>>> point of view.
>>
>> I do get the point but I don't agree that just because a
>> buggy <> has been deployed means we ought to standardise
>> <> without those bugs.
> 
> I don't get your point here, sorry. I read it as "we failed somewhere,
> let's not fix it because it already exists" so I assume you meant
> something else :-/

I did. I meant that just because something is deployed is not
by itself sufficient reason to standardise (a less buggy version
of) that thing. TLS MITM proxies are an entirely different case
where that same issue arises. (I do hope I've not sent the thread
into a rathole about TLS MITM there;-)

S.

> 
> Regards,
> Willy
> 
> 
> 

From w@1wt.eu  Fri Aug 31 06:32:28 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07E021F85B8 for ; Fri, 31 Aug 2012 06:32:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.464
X-Spam-Level: 
X-Spam-Status: No, score=-5.464 tagged_above=-999 required=5 tests=[AWL=-3.421, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1LXgfuWM+6Z for ; Fri, 31 Aug 2012 06:32:28 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 1593B21F8565 for ; Fri, 31 Aug 2012 06:32:27 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q7VDWLBa029390; Fri, 31 Aug 2012 15:32:21 +0200
Date: Fri, 31 Aug 2012 15:32:21 +0200
From: Willy Tarreau 
To: Stephen Farrell 
Message-ID: <20120831133221.GD28461@1wt.eu>
References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <5040ABD7.6040300@cs.tcd.ie> <20120831124940.GB28461@1wt.eu> <5040B615.8020603@cs.tcd.ie> <20120831130855.GC28461@1wt.eu> <5040B910.6070705@cs.tcd.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5040B910.6070705@cs.tcd.ie>
User-Agent: Mutt/1.4.2.3i
Cc: Barry Leiba , Apps Discuss 
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 13:32:29 -0000

On Fri, Aug 31, 2012 at 02:16:00PM +0100, Stephen Farrell wrote:
> > All people working on the server side are already convinced about that,
> > they're all facing the same interoperability issues and they need it
> > for logging purposes (at least).
> 
> That last is kinda vague though isn't it?

How is the need for server-side logging something vague ? It's mandatory
by law in a number of places (maybe everywhere ?) and is one of the
basic security requirements. Most servers require this also to protect
against abuse. I won't make the insult of presenting what purposes a
server has of its visitor's IP address, we all have such requirements.

> >> I suspect its really a different document entirely that
> >> documents current XFF implementation and deployment
> >> practices. I reckon that text might be a good bit longer
> >> than the entire current draft.
> > 
> > It would not be wise to document wrong practices of non-standard header
> > fields which do not respect the standardized header field format. HTTP
> > is crappy enough to avoid adding another exception on top of it.
> 
> I don't get how that squares with what you said earlier:
> 
>    "And I see this draft as an opportunity
>     to remind implementors about what to do and what not to do.
>     Right now, they're acting blindly, deploying their proxies
>     without even knowing that they're sending xff to the whole
>     world."

Right now this is something needed but not documented since not
standardized. Some people even point me to wikipedia to explain
to me what they're trying to achieve! So they tend to use default
settings from the products they use, and there are not two similar
behaviours across products so there is no good nor bad practice.
I have already seen XFF being emitted by outgoing proxies and I
had to explain the admin what to do to avoid this.

> >> I do get the point but I don't agree that just because a
> >> buggy <> has been deployed means we ought to standardise
> >> <> without those bugs.
> > 
> > I don't get your point here, sorry. I read it as "we failed somewhere,
> > let's not fix it because it already exists" so I assume you meant
> > something else :-/
> 
> I did. I meant that just because something is deployed is not
> by itself sufficient reason to standardise (a less buggy version
> of) that thing.

It's not because it's deployed, It's because there is a real need and
without any standard, interoperability issues are created.

In turn, I don't see why addressing issues in something which already
exists should be wrong and discouraged.

Regards,
Willy


From julian.reschke@gmx.de  Fri Aug 31 06:44:01 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8246421F856F for ; Fri, 31 Aug 2012 06:44:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5ZTOhoAqPf4 for ; Fri, 31 Aug 2012 06:44:00 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2F49621F856D for ; Fri, 31 Aug 2012 06:43:59 -0700 (PDT)
Received: (qmail invoked by alias); 31 Aug 2012 13:43:58 -0000
Received: from mail.alexanders.com (EHLO [172.20.30.30]) [66.7.113.101] by mail.gmx.net (mp040) with SMTP; 31 Aug 2012 15:43:58 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+prX4ClaqpgS6mNo2o75u99CI2tqQG4sxBimciif c98NABVp4+3U0i
Message-ID: <5040BF9A.80003@gmx.de>
Date: Fri, 31 Aug 2012 15:43:54 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: Willy Tarreau 
References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <5040ABD7.6040300@cs.tcd.ie> <20120831124940.GB28461@1wt.eu> <5040B615.8020603@cs.tcd.ie> <20120831130855.GC28461@1wt.eu> <5040B910.6070705@cs.tcd.ie> <20120831133221.GD28461@1wt.eu>
In-Reply-To: <20120831133221.GD28461@1wt.eu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: Barry Leiba , Apps Discuss 
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 13:44:01 -0000

On 2012-08-31 15:32, Willy Tarreau wrote:
> ...
>> I did. I meant that just because something is deployed is not
>> by itself sufficient reason to standardise (a less buggy version
>> of) that thing.
>
> It's not because it's deployed, It's because there is a real need and
> without any standard, interoperability issues are created.
>
> In turn, I don't see why addressing issues in something which already
> exists should be wrong and discouraged.
> ...

+1

The alternative is to take the draft, publish it elsewhere, and have the 
header field name registered anyway.

Best regards, Julian

From w@1wt.eu  Fri Aug 31 07:08:06 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604DC21F849A for ; Fri, 31 Aug 2012 07:08:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.429
X-Spam-Level: 
X-Spam-Status: No, score=-5.429 tagged_above=-999 required=5 tests=[AWL=-3.386, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDGU47V854sU for ; Fri, 31 Aug 2012 07:08:06 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 3876321F847F for ; Fri, 31 Aug 2012 07:08:01 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q7VE7qYa029586; Fri, 31 Aug 2012 16:07:52 +0200
Date: Fri, 31 Aug 2012 16:07:52 +0200
From: Willy Tarreau 
To: Julian Reschke 
Message-ID: <20120831140752.GE28461@1wt.eu>
References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <5040ABD7.6040300@cs.tcd.ie> <20120831124940.GB28461@1wt.eu> <5040B615.8020603@cs.tcd.ie> <20120831130855.GC28461@1wt.eu> <5040B910.6070705@cs.tcd.ie> <20120831133221.GD28461@1wt.eu> <5040BF9A.80003@gmx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5040BF9A.80003@gmx.de>
User-Agent: Mutt/1.4.2.3i
Cc: Barry Leiba , Apps Discuss 
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 14:08:06 -0000

On Fri, Aug 31, 2012 at 03:43:54PM +0200, Julian Reschke wrote:
> On 2012-08-31 15:32, Willy Tarreau wrote:
> >...
> >>I did. I meant that just because something is deployed is not
> >>by itself sufficient reason to standardise (a less buggy version
> >>of) that thing.
> >
> >It's not because it's deployed, It's because there is a real need and
> >without any standard, interoperability issues are created.
> >
> >In turn, I don't see why addressing issues in something which already
> >exists should be wrong and discouraged.
> >...
> 
> +1
> 
> The alternative is to take the draft, publish it elsewhere, and have the 
> header field name registered anyway.

Exactly and it will be a new de-facto standard just like current header.

Regards,
Willy


From john-ietf@jck.com  Fri Aug 31 09:28:10 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4324421F846F for ; Fri, 31 Aug 2012 09:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.588
X-Spam-Level: 
X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyTBCVm0Nr13 for ; Fri, 31 Aug 2012 09:28:09 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id A59C921F84A5 for ; Fri, 31 Aug 2012 09:28:09 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1T7U4m-0000aA-SU for apps-discuss@ietf.org; Fri, 31 Aug 2012 12:28:08 -0400
Date: Fri, 31 Aug 2012 12:28:03 -0400
From: John C Klensin 
To: Apps Discuss 
Message-ID: <73D8F9539EBE5AD39496AFBA@JcK-HP8200.jck.com>
In-Reply-To: 
References: 
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
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 16:28:10 -0000

Hi.

This is not my main area of expertise, but, based on reading the
DISCUSS positions and thinking that I've gotten at least the
main points of the thread, a suggestion...

Three main points seem to dominate the conversation so far:

	(1) This is widely deployed, possibly with variations.
	
	(2) If misused, and possible even if used properly, it
	raises some significant privacy (and maybe security)
	issues.
	
	(3) We think we know how to make it better.  It is not
	clear that "better" would solve the problems of (2) even
	if it might improve things somewhat.  There is also the
	question of whether "better" would be perceived as good
	enough or important enough in practice to deploy and
	replace the installed base.  The IETF's track record of
	getting "better" versions deployed when something is
	already out there and perceived as widely deployed and
	working has not been good.

The above doesn't justify standardization.  However, it seems to
me that it would make a lot of sense to recast the document into
Informational form and publish it.   I'd think that conditions
for such publication should be:

	(i) It really describes the current protocol and how it
	is used.   If there are possible variations that can't
	be easily cataloged, it is perfectly reasonable for such
	an Informational document to say "don't know, but..." or
	"maybe someone is..."
	
	(ii) It contains Security Consideration and Privacy
	Consideration sections that document those issues to the
	extent experts in those areas consider appropriate.
	
	(iii) If there are suggestions for improvement, they
	could be described as suggestions, with no need to
	obtain community consensus on whether they are good
	ideas or would accomplish anything.

I believe there really is value in having good descriptions of
things that are in wide use (or even that claim to be), even if
we don't approve of them.   We can't prevent people from doing
bad things by declining to standardize them, or even by
declining to document them, but there may be real advantages of
getting a document out there that describes what is being done
and what the issues are with it.  And, if the community really
detests the idea (I have no reason to believe there is, or is
not, consensus for "detesting"), I'd note that we cannot produce
an Applicability Statement that says "Not Recommended" without
having a document that describes what we we are recommending
against.

   john


From GK@ninebynine.org  Fri Aug 31 09:45:51 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4861321F8650 for ; Fri, 31 Aug 2012 09:45:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.492
X-Spam-Level: 
X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2anUvCPUcYy for ; Fri, 31 Aug 2012 09:45:50 -0700 (PDT)
Received: from relay8.mail.ox.ac.uk (relay8.mail.ox.ac.uk [129.67.1.171]) by ietfa.amsl.com (Postfix) with ESMTP id 39A9121F8647 for ; Fri, 31 Aug 2012 09:45:49 -0700 (PDT)
Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay8.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1T7ULr-0001Yc-Rc; Fri, 31 Aug 2012 17:45:47 +0100
Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1T7ULr-0003uR-6g; Fri, 31 Aug 2012 17:45:47 +0100
Message-ID: <5040E8D7.4040203@ninebynine.org>
Date: Fri, 31 Aug 2012 17:39:51 +0100
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: John C Klensin 
References:  <73D8F9539EBE5AD39496AFBA@JcK-HP8200.jck.com>
In-Reply-To: <73D8F9539EBE5AD39496AFBA@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Cc: Apps Discuss 
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 16:45:51 -0000

Something similar had occurred to me about going for informational/experimental 
rather than standards-track publication, which does not preclude a later upgrade.

There's one further (small) consideration: registration of the defined header 
field.  Standards-track approval pretty much guarantees that it meets the 
criteria for permanent registration.  Informational is less clear cut, but in 
this case I would judge that there has been sufficient discussion to warrant 
such a registration if RFC publication is approved following discussion and 
consensus in this forum.

#g
--

On 31/08/2012 17:28, John C Klensin wrote:
> Hi.
>
> This is not my main area of expertise, but, based on reading the
> DISCUSS positions and thinking that I've gotten at least the
> main points of the thread, a suggestion...
>
> Three main points seem to dominate the conversation so far:
>
> 	(1) This is widely deployed, possibly with variations.
> 	
> 	(2) If misused, and possible even if used properly, it
> 	raises some significant privacy (and maybe security)
> 	issues.
> 	
> 	(3) We think we know how to make it better.  It is not
> 	clear that "better" would solve the problems of (2) even
> 	if it might improve things somewhat.  There is also the
> 	question of whether "better" would be perceived as good
> 	enough or important enough in practice to deploy and
> 	replace the installed base.  The IETF's track record of
> 	getting "better" versions deployed when something is
> 	already out there and perceived as widely deployed and
> 	working has not been good.
>
> The above doesn't justify standardization.  However, it seems to
> me that it would make a lot of sense to recast the document into
> Informational form and publish it.   I'd think that conditions
> for such publication should be:
>
> 	(i) It really describes the current protocol and how it
> 	is used.   If there are possible variations that can't
> 	be easily cataloged, it is perfectly reasonable for such
> 	an Informational document to say "don't know, but..." or
> 	"maybe someone is..."
> 	
> 	(ii) It contains Security Consideration and Privacy
> 	Consideration sections that document those issues to the
> 	extent experts in those areas consider appropriate.
> 	
> 	(iii) If there are suggestions for improvement, they
> 	could be described as suggestions, with no need to
> 	obtain community consensus on whether they are good
> 	ideas or would accomplish anything.
>
> I believe there really is value in having good descriptions of
> things that are in wide use (or even that claim to be), even if
> we don't approve of them.   We can't prevent people from doing
> bad things by declining to standardize them, or even by
> declining to document them, but there may be real advantages of
> getting a document out there that describes what is being done
> and what the issues are with it.  And, if the community really
> detests the idea (I have no reason to believe there is, or is
> not, consensus for "detesting"), I'd note that we cannot produce
> an Applicability Statement that says "Not Recommended" without
> having a document that describes what we we are recommending
> against.
>
>     john
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From jasnell@gmail.com  Fri Aug 31 10:33:42 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB96021F8610 for ; Fri, 31 Aug 2012 10:33:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.334
X-Spam-Level: 
X-Spam-Status: No, score=-6.334 tagged_above=-999 required=5 tests=[AWL=-2.736, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGpj+EFAoMLs for ; Fri, 31 Aug 2012 10:33:38 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7169721F85C0 for ; Fri, 31 Aug 2012 10:33:37 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so1648060wgb.13 for ; Fri, 31 Aug 2012 10:33:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Q/FNzxiXP7GnLUOsVYhfk1x1gcYuNMhCYPU+bu3mCiM=; b=Gw2jTb3/unwY5sBJ9AL6LV+ds+/69uJty9yv8LopYDbeaN0MPXx7gR+wBg4cb1hrEs EgmcC1NfyGeYOzo6YDPsbhiGsl3GkchbzDfPbjF9gizxhU/2HTKZj32tblrly70I1tyv KEu10Jar1LGTLS18rhtxsDoC0weTDnh1wdAbpdhEa1QQyA9P/eyfCFL+PXMnyL9aUONx OpQWWd/KVxrileVO7aaSfpGGQf1EZd62JYF0o24PcmkeWtPp7Q2yFnRCoiBcC0Fbvjio veKn1zwJFIsNeKwEyDGzLiRvZGViTdDBm7Z2x5xuZxJAqP52D8BbHlSSXsR2HxxmnyEF qSAw==
Received: by 10.217.1.79 with SMTP id m57mr5035810wes.121.1346434415954; Fri, 31 Aug 2012 10:33:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.58.136 with HTTP; Fri, 31 Aug 2012 10:33:15 -0700 (PDT)
In-Reply-To: <287CDD14-DEC2-40AD-AD5D-DC102D5AAAE6@ve7jtb.com>
References:  <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com>   <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com>      <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net>  <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com> <032d01cd8597$aac7f740$0057e5c0$@packetizer.com> <046501cd860c$da464420$8ed2cc60$@packetizer.com> <287CDD14-DEC2-40AD-AD5D-DC102D5AAAE6@ve7jtb.com>
From: James M Snell 
Date: Fri, 31 Aug 2012 10:33:15 -0700
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=20cf302077dc138baa04c89331c2
Cc: Mark Nottingham , IETF Apps Discuss 
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 17:33:43 -0000

--20cf302077dc138baa04c89331c2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

One of the key problems with all of this is that it really does not account
for the fundamental use case of WebFinger: discovering which services and
data are available for a given user within a given domain. Google, for
instance, may host the email, but the users blog, calendar, or other
services may have nothing to do with google. In fact, Google may not know
*anything* about domains users and would therefore be generally incapable
of providing useful information. In order for WebFinger to be useful, even
with a DNS based bootstrap, the domain owner is going to have to provide
the information about its users.

If the domain owner wishes to provide webfinger services, but defer that
back to a google hosted service, the domain host should manage
/.well-known/* itself and provide a reasonable http redirect back to the
google hosted service. Then, the domain owner would need to work with
google to ensure that the information served up is useful (even then,
however, it would likely be just as easy for the domain owner to host
everything themselves).

Referring back to my index draft [1].. it could look something like...

 GET /.well-known/index/\
53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255/\
 calendar
Host: example.org

HTTP/1.1 302 Found
 Location: https://webfinger.google.com/example.org/\
53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255/\
 calendar

[1] http://www.ietf.org/id/draft-snell-web-index-00.txt

- James

On Wed, Aug 29, 2012 at 10:57 AM, John Bradley  wrote:

> I am not the best person to represent Google's needs.
>
> However as I understand it Google hosts applications such as email
> documents openID for tens of thousands of domains.
> Google themselves don't control the DNS.
>
> The people using the service generally add some MX records for
> aspmx.l.google.com. and a Cname for mail.example.com to ghs.google.com.
>
> The A record for the bare domain typically points off to some Content
> management site the company uses for their web pages.
>
> I think this is probably typical of Yahoo's mail hosting services and
> others.
>
> The service hosing the email/authentication/openID is not the one that
> controls the web server for company.
>
> Saying the CMS venders will provide WebFinger services doesn't seem all
> that likely, especially in virtual hosting environments.
>
> Getting a typical company to do anything more than enter a cname for
> webfinger.example.org is wildly optimistic.
>
> I am entirely open to Ideas on this.   However the previous solution of
> having every RP check with google first to see if they host the email and
> provide the XRDS seems horribly flawed to me.
>
> I would like to see a workable solution at the discovery layer that
> accommodates how people deploy there sites.
>
> I think Bill suggested at one point using the MX record to find the
> webfinger host.  That has a bunch of problems I would prefer to avoid.
>
> John B.
>
> On 2012-08-29, at 1:36 PM, "Paul E. Jones"  wrote:
>
> John,****
>
> Well, we need to figure out how to address this.****
>
> Would it be reasonable to redirect requests from
> /.well-known/host-meta.json and /.well-known/host-meta to Google?****
>
> Are there other services or files under /.well-known that Google=E2=80=99=
s
> customers would not want Google to host?  If they were OK with Google=E2=
=80=99s
> servers responding to anything , then one could put an A (or CNAME) recor=
d
> in place for example.com that points to Google.****
>
> Not being familiar with what Google offers, I=E2=80=99m a bit challenged =
to
> understand exactly what is and is not possible.****
>
> Paul****
>
>  *From:* John Bradley [mailto:ve7jtb@ve7jtb.com]
> *Sent:* Wednesday, August 29, 2012 10:14 AM
> *To:* Paul E. Jones
> *Cc:* 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
> *Subject:* Re: [apps-discuss] Looking at Webfinger****
> ** **
> There mite be a A record but that typically goes off to some virtual web
> hosting company and not the email service provider.****
> ** **
> I think I have also heard William say this is a problem for Yahoo.****
> ** **
> Google was not able to get people to deploy XRDS for hosted domains.
> They came up with a proprietary extension to openID discovery to make
> hosted google apps domains work with some subset of RP.****
> ** **
> The problem is that the company hosting a small businesses website is
> unlikely to provide the web finger infrastructure and there is no way for
> the email/openID provider to do it without their cooperation.****
> ** **
> Adding a A record rather than a CNAME is generally not a good idea if it
> can be avoided.   In the event of the provider changing an IP address it
> breaks all the customers if they have used A records, but that is separat=
e
> issue.  ****
> ** **
> You can set up webfinger on your web server and manage it.   It just won'=
t
> work for large numbers of people as we have it now.  ****
> ** **
> If webfinger won't work for Google Apps for Domains and other hosted
> services like that then It will significantly impact adoption in my opini=
on.
> ****
> ** **
> We will also need to work around that for Connect.  We don't want another
> proprietary work around with the security problems that can entail.****
> ** **
> John B.****
> ** **
> On 2012-08-28, at 11:37 PM, "Paul E. Jones"  wrote=
:
> ****
>
>
> ****
> John,****
>  ****
> If Google is hosting the domain or any other service provider, wouldn=E2=
=80=99t
> there still be an A record for the domain (e.g.,packetizer.com)?  I know
> there is for virtually every web hosting company I=E2=80=99ve used.  It s=
eems like
> this might just be one more hosted service Google could provide to its
> customers, no?****
>  ****
> I do not know exactly how this hosted service works, but what=E2=80=99s h=
osted?  I
> assume it=E2=80=99s just email.  If web, then I see no issue.  If only em=
ail, then
> the user just needs to have MX records pointing to Google and an A record
> pointing to whatever service runs the WebFinger service.****
>  ****
> In any case, if they can add a CNAME or MX record, I think we can get the=
m
> to add an A record.  I think it would be far more challenging for SMBs to
> add a host like webfinger.example.com.  That would still require an A
> record and a service provider capable of supporting it.****
>  ****
> Paul****
>  ****
> *From:* John Bradley [mailto:ve7jtb@ve7jtb.com]
> *Sent:* Tuesday, August 28, 2012 3:29 PM
> *To:* Paul E. Jones
> *Cc:* 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
> *Subject:* Re: [apps-discuss] Looking at Webfinger****
>  ****
> There are cases where there are hosted domains (Google etc) that may not
> have a http host for the domain name used in the users email address.  **=
*
> *
>  ****
> There may be merit to having a webfinger.example.com fallback where the
> client can't reach the .well-known for the primary host.****
>  ****
> I know that some sort of SRV record would be the correct way to do it, bu=
t
> in the real world SMB don't enter SRV records even if there DNS provider
> support them.****
> The most you can get them to do is add a CNAME or MX record.****
>  ****
> Supporting these sorts of domains somehow is a important issue.****
>  ****
> John B.****
>  ****
> On 2012-08-28, at 3:17 PM, "Paul E. Jones"  wrote:=
*
> ***
>
>
>
> ****
> George,****
>  ****
> I believe it might be useful to introduce those who break your WebFinger
> server to Louisville Slugger. :)****
>  ****
> Your pain is understood, but I do not see a way to avoid it.  We could
> introduce something in DNS, but that would also present challenges.  No
> matter where we =E2=80=9Croot=E2=80=9D the discovery process, there is a =
potential somebody
> could break it.  It could be rooted somewhere other than the root of the
> domain (e.g., webfinger.example.com), but we either need to decide in
> advance of such a location or introduce a way to discovery the discovery
> resources.****
>  ****
> Do you have a suggestion that would make this less likely to be broken?**=
*
> *
>  ****
> Paul****
>  ****
> *From:* apps-discuss-bounces@ietf.org [mailto:apps-
> discuss-bounces@ietf.org] *On Behalf Of *George Fletcher
> *Sent:* Tuesday, August 28, 2012 11:09 AM
> *To:* Mark Nottingham
> *Cc:* IETF Apps Discuss
> *Subject:* Re: [apps-discuss] Looking at Webfinger****
>  ****
>
> Way "late to the party" but I can speak from experience that deployment
> can be a real issue in some environments. It's all really straight forwar=
d
> in a small company or an environment where the identity team "owns" the
> root domain (e.g. example.com). However, if an entire other group in a
> large organization "owns" the root domain (home page for the site) and th=
e
> identity team then needs to get them to make changes, the deployment
> solution gets brittle pretty quick. I've had our webfinger support broken
> at least twice because the "other" team didn't know that certain configs
> were required:)
>
> Also, installing the "dynamic pluming" can be more problematic is these
> cases. It is possible to get apache rewrite rules or netscaler magic in
> place to make it work, it's just a more brittle deployment architecture.
>
> Thanks,
> George****
> On 7/4/12 6:58 PM, John Panzer wrote:****
>
> Mark -- Of course I was speaking about practical realities of typical web
> server administration and deployment.  In practical terms, adding a new
> mod_rewrite rule or moral equivalent is going to be easier than adding a
> new PHP script that connects to a database.  The latter is just always
> going to be a much higher bar.****
>  ****
> And, something that returns per-user data is generally going to need a
> dynamic service of some kind, unless your site has just a handful of user=
s
> and you don't mind going through a publishing exercise each time you add =
or
> change a user...****
>  ****
> None of this has anything to do with the interface, just deployment
> realities.  And in reality all of this is going to need a dynamic service
> somewhere for each non-trivial site, this is all just a question of how t=
o
> hook it up.****
>
> ****
> --
> John Panzer / Google
> jpanzer@google.com / abstractioneer.org  =
/
> @jpanzer****
>  ****
>
>  ****
> On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham  wrote:***=
*
>
> On 05/07/2012, at 8:16 AM, John Panzer wrote:
>
> > Just as a historical note.  The envisioned usage of host-meta was
> originally to avoid a specification which mandated a particular dynamic U=
RL
> API at a particular /.well-known endpoint (because it may not be feasible
> to do that across all organizations and deployments).  The host-meta
> document itself would be highly cacheable and so wouldn't incur an
> additional network trip in the common case.
> >
> > Having a 3xx redirect is a reasonable alternative that allows a similar
> escape hatch via something like mod_rewrite, albeit at the cost of needin=
g
> an additional network trip each time.  Since a deployment can always avoi=
d
> the 3xx redirect with additional dynamic plumbing behind the well-known
> endpoint, I don't think that's a horrible thing.
> >
> > An application-level redirect would be almost equivalent to an HTTP
> redirect, but then there are two ways to do the same thing.  If _only_ an
> application-level redirect is allowed, then you have to have at least a
> minimal dynamic service at the well-known endpoint (no more mod_rewrite).
>  But the whole reason for this is to avoid the requirement for a dynamic
> service behind well-known...****
> "dynamic" and "static" are properties of the implementation, not the
> interface. HTTP doesn't require that any particular URL be "dynamic";
> anything can, with the right metadata, be cached (and indeed, I've cached
> many, many things with the wrong metadata, because of silly site operator=
s
> and their ideas about "dynamic").
>
> Now, if people want to target a particular implementation that makes it
> easier to serve a particular style of URL without writing code, fine, but
> let's not confuse things.
>
> E.g., a URL like
>
> http://example.com/.well-known/user/bob
>
> is easy to serve in pretty much any way you like with Apache.
>
> I'm also going to push back on the "it may not be feasible to do that
> across all organizations and deployments" motivation. This is a race to t=
he
> bottom. The trick is to make it accessible enough to get sufficient
> traction to pull everyone along, without pandering to *everyone*'s
> requirements.
>
> Regards,****
>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
> ****
>  ****
>
>
>
>
>
> ****
>
> _______________________________________________****
>
>
> apps-discuss mailing list****
>
> apps-discuss@ietf.org****
>
> https://www.ietf.org/mailman/listinfo/apps-discuss****
>
>  ****
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss****
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

--20cf302077dc138baa04c89331c2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

One of the key problems with all of th=
is is that it really does not account for the fundamental use case of WebFi=
nger: discovering which services and data are available for a given user wi=
thin a given domain. Google, for instance, may host the email, but the user=
s blog, calendar, or other services may have nothing to do with google. In =
fact, Google may not know *anything* about domains users and would therefor=
e be generally incapable of providing useful information. In order for WebF=
inger to be useful, even with a DNS based bootstrap, the domain owner is go=
ing to have to provide the information about its users.



If the domain owner wishes to provide webfinger serv=
ices, but defer that back to a google hosted service, the domain host shoul=
d manage /.well-known/* itself and provide a reasonable http redirect back =
to the google hosted service. Then, the domain owner would need to work wit=
h google to ensure that the information served up is useful (even then, how=
ever, it would likely be just as easy for the domain owner to host everythi=
ng themselves).




Referring back to my index draft [1].. it could=
 look something like...




 GET /.well-known/index/\
    53ae56=
ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255/\



    calendar




 HTTP/1.1 302 Found


 Location: htt=
ps://webfinger.google.com/example.org/\
    53ae=
56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255/\



    calendar





- James

On Wed, Aug 29, 2012 at 10:57 AM, John Bradley <ve7jtb@ve7jt=
b.com> wrote:



I am not=
 the best person to represent Google's needs.

Howeve=
r as I understand it Google hosts applications such as email documents open=
ID for tens of thousands of domains.



Google themselves don't control the DNS.

=
The people using the service generally add some MX records for aspmx.l.google.com. and a C=
name for mail.example=
.com to=C2=A0ghs.go=
ogle.com.




The A record for the bare domain typically points off t=
o some Content management site the company uses for their web pages.
<=
div>
I think this is probably typical of Yahoo's mail hos=
ting services and others. =C2=A0=C2=A0




The service hosing the email/authentication/openID is n=
ot the one that controls the web server for company.

Saying the CMS venders will provide WebFinger services doesn't seem =
all that likely, especially in virtual hosting environments.




Getting a typical company to do anything more than ente=
r a cname for we=
bfinger.example.org is wildly optimistic.

I am=
 entirely open to Ideas on this. =C2=A0 However the previous solution of ha=
ving every RP check with google first to see if they host the email and pro=
vide the XRDS seems horribly flawed to me.




I would like to see a workable solution at the discover=
y layer that accommodates how people deploy there sites.

I think Bill suggested at one point using the MX record to find the =
webfinger host. =C2=A0That has a bunch of problems I would prefer to avoid.=





John B.

=
On 2012-08-29, at 1:36 PM, "Paul E. Jones" <paulej@packetizer.com> wrot=
e:






John,


=C2=A0
Well, we need to =
figure out how to address this.



=C2=A0


Would it be reasonable to redirect requests from /.well-known/host-=
meta.json and /.well-known/host-meta to Google?



=C2=A0


Are there other services or files under /.well-known that Google=E2=
=80=99s customers would not want Google to host?=C2=A0 If they were OK with=
 Google=E2=80=99s servers responding to anything , then one could put an A =
(or CNAME) record in place for=C2=A0exa=
mple.com=C2=A0that points to Google.<=
/div>


=C2=A0


Not being familiar with what Google offers, I=E2=80=99m a bit chall=
enged to understand exactly what is and is not possible.



=C2=A0


Paul
=C2=
=A0






From:=C2=A0John Bradley [mailto:ve7jtb@ve7jtb.com]=C2=A0


Sent:=C2=A0Wednesday, August 29, 2012 10:14 AM
To=
:=C2=A0Paul E. Jones
Cc:=C2=A0'=
George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'=
;
Subject:=C2=A0Re: [apps-discuss] Looking at Webfin=
ger



=C2=A0


There mite be a A record but that typically goes off to some virtual web ho=
sting company and not the email service provider.
<=
div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times =
New Roman',serif">

=C2=A0
I think I have =
also heard William say this is a problem for Yahoo.




=C2=A0


Google was not able to get people to deploy XRDS for hosted domains. =C2=A0=
 They came up with a proprietary extension to openID discovery to make host=
ed google apps domains work with some subset of RP.



=C2=A0


The problem is that the company hosting a small businesses website is unlik=
ely to provide the web finger infrastructure and there is no way for the em=
ail/openID provider to do it without their cooperation.



=C2=A0


Adding a A record rather than a CNAME is generally not a good idea if it ca=
n be avoided. =C2=A0 In the event of the provider changing an IP address it=
 breaks all the customers if they have used A records, but that is separate=
 issue. =C2=A0



=C2=A0


You can set up webfinger on your web server and manage it. =C2=A0 It just w=
on't work for large numbers of people as we have it now. =C2=A0<=
u>


=C2=A0
If webfinger wo=
n't work for Google Apps for Domains and other hosted services like tha=
t then It will significantly impact adoption in my opinion.


=C2=A0


We will also need to work around that for Connect. =C2=A0We don't want =
another proprietary work around with the security problems that can entail.=



=C2=A0
John B.<=
u>


=C2=A0
On 2012-08-28, a=
t 11:37 PM, "Paul E. Jones" <=
paulej@packetizer.com> wrote:







John,

=C2=A0


If Google is hosting the domain o=
r any other service provider, wouldn=E2=80=99t there still be an A record f=
or the domain (e.g.,=
packetizer.com)?=C2=A0 I know there is for virtually every web h=
osting company I=E2=80=99ve used.=C2=A0 It seems like this might just be on=
e more hosted service Google could provide to its customers, no?<=
/u>



=C2=A0
=




I do not know exactly how this hosted s=
ervice works, but what=E2=80=99s hosted?=C2=A0 I assume it=E2=80=99s just e=
mail.=C2=A0 If web, then I see no issue.=C2=A0 If only email, then the user=
 just needs to have MX records pointing to Google and an A record pointing =
to whatever service runs the WebFinger service.



=C2=A0
=




In any case, if they can add a CNAME or=
 MX record, I think we can get them to add an A record.=C2=A0 I think it wo=
uld be far more challenging for SMBs to add a host like=C2=A0<=
a href=3D"http://webfinger.example.com" style=3D"color:purple;text-decorati=
on:underline" target=3D"_blank">webfinger.exam=
ple.com.=C2=A0 That would still require an A record and a servic=
e provider capable of supporting it.



=C2=A0
=




Paul



=C2=A0



=
From:=C2=A0=
=
John Bradley [mailto:ve7jtb@ve7jtb.com]=C2=A0


Sent:=C2=A0Tuesday, August 28, 2012 3:29 PM
To:=C2=A0Paul E. Jones
Cc:=C2=A0'Geo=
rge Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'Subject:=C2=A0Re: [apps-discuss] Looking at Webfinger=




=C2=A0


There are cases where there are hosted domains (Google etc) that may not ha=
ve a http host for the domain name used in the users email address. =C2=A0<=
u>


=C2=A0
There may be me=
rit to having a=C2=A0webfinger.example.com=C2=A0fal=
lback where the client can't reach the .well-known for the primary host=
.



=C2=A0


I know that some sort of SRV record would be the correct way to do it, but =
in the real world SMB don't enter SRV records even if there DNS provide=
r support them.


The most you can get them to do is add a CNAME or MX record.<=
/div>
=C2=A0


Supporting these sorts of domains somehow is a important issue.
=C2=A0
<=
div>


John B.


=C2=A0
On 2012-08=
-28, at 3:17 PM, "Paul E. Jones" <paulej@packetizer.com> wrot=
e:








George,


=C2=A0
=
I believe it might be useful to introduce those who break your WebF=
inger server to Louisville Slugger. :)



=C2=A0
=




Your pain is understood, but I do not s=
ee a way to avoid it.=C2=A0 We could introduce something in DNS, but that w=
ould also present challenges.=C2=A0 No matter where we =E2=80=9Croot=E2=80=
=9D the discovery process, there is a potential somebody could break it.=C2=
=A0 It could be rooted somewhere other than the root of the domain (e.g.,=C2=A0webfinger.example.com), but we either need to decide in adva=
nce of such a location or introduce a way to discovery the discovery resour=
ces.



=C2=A0
=




Do you have a suggestion that would mak=
e this less likely to be broken?



=C2=A0
=




Paul



=C2=A0



=
From:=C2=A0=
=
apps-=
discuss-bounces@ietf.org=C2=A0[mailto:apps-=
discuss-bounces@ietf.org]=C2=
=A0On Behalf Of=C2=A0George Fletcher


Sent:=C2=A0Tuesday, August 28, 2012 11:09 AM
To:<=
/b>=C2=A0Mark Nottingham
Cc:=C2=A0IETF =
Apps Discuss
Subject:=C2=A0Re: [apps-discuss] Lookin=
g at Webfinger



=C2=A0


Way "late to the part=
y" but I can speak from experience that deployment can be a real issue=
 in some environments. It's all really straight forward in a small comp=
any or an environment where the identity team "owns" the root dom=
ain (e.g.=C2=A0example.com). However, if an entire other group in a large =
organization "owns" the root domain (home page for the site) and =
the identity team then needs to get them to make changes, the deployment so=
lution gets brittle pretty quick. I've had our webfinger support broken=
 at least twice because the "other" team didn't know that cer=
tain configs were required:)



Also, installing the "dynamic pluming" can be more problemati=
c is these cases. It is possible to get apache rewrite rules or netscaler m=
agic in place to make it work, it's just a more brittle deployment arch=
itecture.



Thanks,
George
O=
n 7/4/12 6:58 PM, John Panzer wrote:



Mark -- Of course I was speaking about practica=
l realities of typical web server administration and deployment. =C2=A0In p=
ractical terms, adding a new mod_rewrite rule or moral equivalent is going =
to be easier than adding a new PHP script that connects to a database. =C2=
=A0The latter is just always going to be a much higher bar.


=C2=A0


And, something that returns per-user data is generally going to need a dyna=
mic service of some kind, unless your site has just a handful of users and =
you don't mind going through a publishing exercise each time you add or=
 change a user...



=C2=A0


None of this has anything to do with the interface, just deployment realiti=
es. =C2=A0And in reality all of this is going to need a dynamic service som=
ewhere for each non-trivial site, this is all just a question of how to hoo=
k it up.






--
John Panzer / Google
jpanzer@google.com=C2=A0/=
=C2=A0abstractioneer.org=C2=A0/ @jpanzer<=
/div>


=C2=A0


=C2=A0
On Wed, Jul 4, 201=
2 at 3:36 PM, Mark Nottingham <mnot@mnot.net> wrote:



On 05/07/2012, at 8:16 AM, =
John Panzer wrote:

> Just as a historical note. =C2=A0The envisio=
ned usage of host-meta was originally to avoid a specification which mandat=
ed a particular dynamic URL API at a particular /.well-known endpoint (beca=
use it may not be feasible to do that across all organizations and deployme=
nts). =C2=A0The host-meta document itself would be highly cacheable and so =
wouldn't incur an additional network trip in the common case.


>
> Having a 3xx redirect is a reasonable alternative that allows =
a similar escape hatch via something like mod_rewrite, albeit at the cost o=
f needing an additional network trip each time. =C2=A0Since a deployment ca=
n always avoid the 3xx redirect with additional dynamic plumbing behind the=
 well-known endpoint, I don't think that's a horrible thing.


>
> An application-level redirect would be almost equivalent to an=
 HTTP redirect, but then there are two ways to do the same thing. =C2=A0If =
_only_ an application-level redirect is allowed, then you have to have at l=
east a minimal dynamic service at the well-known endpoint (no more mod_rewr=
ite). =C2=A0But the whole reason for this is to avoid the requirement for a=
 dynamic service behind well-known...



"dynamic" and "static"=
; are properties of the implementation, not the interface. HTTP doesn't=
 require that any particular URL be "dynamic"; anything can, with=
 the right metadata, be cached (and indeed, I've cached many, many thin=
gs with the wrong metadata, because of silly site operators and their ideas=
 about "dynamic").



Now, if people want to target a particular implementation that makes it=
 easier to serve a particular style of URL without writing code, fine, but =
let's not confuse things.

E.g., a URL like

http://example.c=
om/.well-known/user/bob



is easy to serve in pretty much any way you like with Apache.

I&=
#39;m also going to push back on the "it may not be feasible to do tha=
t across all organizations and deployments" motivation. This is a race=
 to the bottom. The trick is to make it accessible enough to get sufficient=
 traction to pull everyone along, without pandering to *everyone*'s req=
uirements.



Regards,

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






=
=C2=A0







________________=
_______________________________

apps-discuss mailing list
apps-discuss@ietf.org



https://www.ietf.org/mailman/listinfo/apps-discuss



=C2=A0


_________=
______________________________________
apps-discuss mailing list
apps-discuss@ietf=
.org


https://www.ietf.org/mailman/listinfo/apps-discuss



apps-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/apps-discuss





--20cf302077dc138baa04c89331c2--

From ve7jtb@ve7jtb.com  Fri Aug 31 10:50:43 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4989F21F857D for ; Fri, 31 Aug 2012 10:50:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.503
X-Spam-Level: 
X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.095,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIbOaU0aiyqq for ; Fri, 31 Aug 2012 10:50:41 -0700 (PDT)
Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id DA1BC21F856F for ; Fri, 31 Aug 2012 10:50:40 -0700 (PDT)
Received: by yhfs35 with SMTP id s35so809078yhf.27 for ; Fri, 31 Aug 2012 10:50:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Bj6BxtJCFztrcju7PjGHLxN8fUVN10iB9wNwxEqzUHo=; b=Oi3xZriqQ/8lDH8RZo2EfmNvrfuhaaHV6Ioy7qZcvYtV5nEGqWqNfu5eg6A5yZiy2v fx7AjhkFLdOXRJgLBw3NgY9G7KXC9kAcz3mw2sAGW9PSMA26yrZt9ovt38q1C7aJw6jV ll3PsP5aWcXQ1dxAHq6wgCVp47YzzdFKSyUOYy/AsOpX/8cpbwquq+sg0E82vgGl8rGm J6Cmj/pwjdlHW2KtDtC75jAqj6mT0mbJf3kjEdo4W6SjYy28fsT1Q+imYpq/s/7urH+y 6Xpee5wbEs0+qtF2i7cCvM/0e6NBkCU+LxkX817VMMjWAxDBo79ODYzmyqWRvxHUaaWd MyIQ==
Received: by 10.236.79.100 with SMTP id h64mr9324470yhe.50.1346435438020; Fri, 31 Aug 2012 10:50:38 -0700 (PDT)
Received: from [192.168.1.211] (190-20-43-171.baf.movistar.cl. [190.20.43.171]) by mx.google.com with ESMTPS id i3sm4907971anl.0.2012.08.31.10.50.13 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 31 Aug 2012 10:50:36 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_3D9E8E16-2599-4046-A830-13579C796FA3"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
From: John Bradley 
In-Reply-To: 
Date: Fri, 31 Aug 2012 13:49:53 -0400
Message-Id: 
References:  <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com>   <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com>      <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net>  <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com> <032d01cd8597$aac7f740$0057e5c0$@packetizer.com> <046501cd860c$da464420$8ed2cc60$@packet izer.com> <287CDD14-DEC2-40AD-AD5D-DC102D5AAAE6@ve7jtb.com> 
To: James M Snell 
X-Mailer: Apple Mail (2.1486)
X-Gm-Message-State: ALoCoQlmvoM3DgXMad6cD+9CPBkv5YAdTaa/GeYN3M+NaIk5sS5gUkpmd70Vq6zHA6nR4vcnIXC+
Cc: Mark Nottingham , IETF Apps Discuss 
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 17:50:43 -0000

--Apple-Mail=_3D9E8E16-2599-4046-A830-13579C796FA3
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_ECC57ABF-4C04-4979-92AD-28EAA1849251"


--Apple-Mail=_ECC57ABF-4C04-4979-92AD-28EAA1849251
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

If the bar is to high for people deploying or delegating Webfinger then =
protocols like OpenID Connect will need to find another alternative for =
the discovery of IdP information about a user.

My point is that managing a /.well-known/* is beyond the ability of many =
people.

John B.

On 2012-08-31, at 1:33 PM, James M Snell  wrote:

> One of the key problems with all of this is that it really does not =
account for the fundamental use case of WebFinger: discovering which =
services and data are available for a given user within a given domain. =
Google, for instance, may host the email, but the users blog, calendar, =
or other services may have nothing to do with google. In fact, Google =
may not know *anything* about domains users and would therefore be =
generally incapable of providing useful information. In order for =
WebFinger to be useful, even with a DNS based bootstrap, the domain =
owner is going to have to provide the information about its users.
>=20
> If the domain owner wishes to provide webfinger services, but defer =
that back to a google hosted service, the domain host should manage =
/.well-known/* itself and provide a reasonable http redirect back to the =
google hosted service. Then, the domain owner would need to work with =
google to ensure that the information served up is useful (even then, =
however, it would likely be just as easy for the domain owner to host =
everything themselves).
>=20
> Referring back to my index draft [1].. it could look something like...
>=20
>=20
>=20
>  GET /.well-known/index/\
>     53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255/\
>     calendar
>  Host: example.org
>=20
>  HTTP/1.1 302 Found
>  Location: https://webfinger.google.com/example.org/\
>     53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255/\
>     calendar
>=20
> [1] http://www.ietf.org/id/draft-snell-web-index-00.txt
>=20
> - James
>=20
> On Wed, Aug 29, 2012 at 10:57 AM, John Bradley  =
wrote:
> I am not the best person to represent Google's needs.
>=20
> However as I understand it Google hosts applications such as email =
documents openID for tens of thousands of domains.
> Google themselves don't control the DNS.
>=20
> The people using the service generally add some MX records for =
aspmx.l.google.com. and a Cname for mail.example.com to ghs.google.com.
>=20
> The A record for the bare domain typically points off to some Content =
management site the company uses for their web pages.
>=20
> I think this is probably typical of Yahoo's mail hosting services and =
others.  =20
>=20
> The service hosing the email/authentication/openID is not the one that =
controls the web server for company.
>=20
> Saying the CMS venders will provide WebFinger services doesn't seem =
all that likely, especially in virtual hosting environments.
>=20
> Getting a typical company to do anything more than enter a cname for =
webfinger.example.org is wildly optimistic.
>=20
> I am entirely open to Ideas on this.   However the previous solution =
of having every RP check with google first to see if they host the email =
and provide the XRDS seems horribly flawed to me.
>=20
> I would like to see a workable solution at the discovery layer that =
accommodates how people deploy there sites.
>=20
> I think Bill suggested at one point using the MX record to find the =
webfinger host.  That has a bunch of problems I would prefer to avoid.
>=20
> John B.
>=20
> On 2012-08-29, at 1:36 PM, "Paul E. Jones"  =
wrote:
>=20
>> John,
>> =20
>> Well, we need to figure out how to address this.
>> =20
>> Would it be reasonable to redirect requests from =
/.well-known/host-meta.json and /.well-known/host-meta to Google?
>> =20
>> Are there other services or files under /.well-known that Google=92s =
customers would not want Google to host?  If they were OK with Google=92s =
servers responding to anything , then one could put an A (or CNAME) =
record in place for example.com that points to Google.
>> =20
>> Not being familiar with what Google offers, I=92m a bit challenged to =
understand exactly what is and is not possible.
>> =20
>> Paul
>> =20
>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
>> Sent: Wednesday, August 29, 2012 10:14 AM
>> To: Paul E. Jones
>> Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
>> Subject: Re: [apps-discuss] Looking at Webfinger
>> =20
>> There mite be a A record but that typically goes off to some virtual =
web hosting company and not the email service provider.
>> =20
>> I think I have also heard William say this is a problem for Yahoo.
>> =20
>> Google was not able to get people to deploy XRDS for hosted domains.  =
 They came up with a proprietary extension to openID discovery to make =
hosted google apps domains work with some subset of RP.
>> =20
>> The problem is that the company hosting a small businesses website is =
unlikely to provide the web finger infrastructure and there is no way =
for the email/openID provider to do it without their cooperation.
>> =20
>> Adding a A record rather than a CNAME is generally not a good idea if =
it can be avoided.   In the event of the provider changing an IP address =
it breaks all the customers if they have used A records, but that is =
separate issue. =20
>> =20
>> You can set up webfinger on your web server and manage it.   It just =
won't work for large numbers of people as we have it now. =20
>> =20
>> If webfinger won't work for Google Apps for Domains and other hosted =
services like that then It will significantly impact adoption in my =
opinion.
>> =20
>> We will also need to work around that for Connect.  We don't want =
another proprietary work around with the security problems that can =
entail.
>> =20
>> John B.
>> =20
>> On 2012-08-28, at 11:37 PM, "Paul E. Jones"  =
wrote:
>>=20
>>=20
>> John,
>> =20
>> If Google is hosting the domain or any other service provider, =
wouldn=92t there still be an A record for the domain =
(e.g.,packetizer.com)?  I know there is for virtually every web hosting =
company I=92ve used.  It seems like this might just be one more hosted =
service Google could provide to its customers, no?
>> =20
>> I do not know exactly how this hosted service works, but what=92s =
hosted?  I assume it=92s just email.  If web, then I see no issue.  If =
only email, then the user just needs to have MX records pointing to =
Google and an A record pointing to whatever service runs the WebFinger =
service.
>> =20
>> In any case, if they can add a CNAME or MX record, I think we can get =
them to add an A record.  I think it would be far more challenging for =
SMBs to add a host like webfinger.example.com.  That would still require =
an A record and a service provider capable of supporting it.
>> =20
>> Paul
>> =20
>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
>> Sent: Tuesday, August 28, 2012 3:29 PM
>> To: Paul E. Jones
>> Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
>> Subject: Re: [apps-discuss] Looking at Webfinger
>> =20
>> There are cases where there are hosted domains (Google etc) that may =
not have a http host for the domain name used in the users email =
address. =20
>> =20
>> There may be merit to having a webfinger.example.com fallback where =
the client can't reach the .well-known for the primary host.
>> =20
>> I know that some sort of SRV record would be the correct way to do =
it, but in the real world SMB don't enter SRV records even if there DNS =
provider support them.
>> The most you can get them to do is add a CNAME or MX record.
>> =20
>> Supporting these sorts of domains somehow is a important issue.
>> =20
>> John B.
>> =20
>> On 2012-08-28, at 3:17 PM, "Paul E. Jones"  =
wrote:
>>=20
>>=20
>>=20
>> George,
>> =20
>> I believe it might be useful to introduce those who break your =
WebFinger server to Louisville Slugger. :)
>> =20
>> Your pain is understood, but I do not see a way to avoid it.  We =
could introduce something in DNS, but that would also present =
challenges.  No matter where we =93root=94 the discovery process, there =
is a potential somebody could break it.  It could be rooted somewhere =
other than the root of the domain (e.g., webfinger.example.com), but we =
either need to decide in advance of such a location or introduce a way =
to discovery the discovery resources.
>> =20
>> Do you have a suggestion that would make this less likely to be =
broken?
>> =20
>> Paul
>> =20
>> From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of George Fletcher
>> Sent: Tuesday, August 28, 2012 11:09 AM
>> To: Mark Nottingham
>> Cc: IETF Apps Discuss
>> Subject: Re: [apps-discuss] Looking at Webfinger
>> =20
>> Way "late to the party" but I can speak from experience that =
deployment can be a real issue in some environments. It's all really =
straight forward in a small company or an environment where the identity =
team "owns" the root domain (e.g. example.com). However, if an entire =
other group in a large organization "owns" the root domain (home page =
for the site) and the identity team then needs to get them to make =
changes, the deployment solution gets brittle pretty quick. I've had our =
webfinger support broken at least twice because the "other" team didn't =
know that certain configs were required:)
>>=20
>> Also, installing the "dynamic pluming" can be more problematic is =
these cases. It is possible to get apache rewrite rules or netscaler =
magic in place to make it work, it's just a more brittle deployment =
architecture.
>>=20
>> Thanks,
>> George
>>=20
>> On 7/4/12 6:58 PM, John Panzer wrote:
>> Mark -- Of course I was speaking about practical realities of typical =
web server administration and deployment.  In practical terms, adding a =
new mod_rewrite rule or moral equivalent is going to be easier than =
adding a new PHP script that connects to a database.  The latter is just =
always going to be a much higher bar.
>> =20
>> And, something that returns per-user data is generally going to need =
a dynamic service of some kind, unless your site has just a handful of =
users and you don't mind going through a publishing exercise each time =
you add or change a user...
>> =20
>> None of this has anything to do with the interface, just deployment =
realities.  And in reality all of this is going to need a dynamic =
service somewhere for each non-trivial site, this is all just a question =
of how to hook it up.
>>=20
>> --
>> John Panzer / Google
>> jpanzer@google.com / abstractioneer.org / @jpanzer
>> =20
>> =20
>>=20
>> On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham  =
wrote:
>> On 05/07/2012, at 8:16 AM, John Panzer wrote:
>>=20
>> > Just as a historical note.  The envisioned usage of host-meta was =
originally to avoid a specification which mandated a particular dynamic =
URL API at a particular /.well-known endpoint (because it may not be =
feasible to do that across all organizations and deployments).  The =
host-meta document itself would be highly cacheable and so wouldn't =
incur an additional network trip in the common case.
>> >
>> > Having a 3xx redirect is a reasonable alternative that allows a =
similar escape hatch via something like mod_rewrite, albeit at the cost =
of needing an additional network trip each time.  Since a deployment can =
always avoid the 3xx redirect with additional dynamic plumbing behind =
the well-known endpoint, I don't think that's a horrible thing.
>> >
>> > An application-level redirect would be almost equivalent to an HTTP =
redirect, but then there are two ways to do the same thing.  If _only_ =
an application-level redirect is allowed, then you have to have at least =
a minimal dynamic service at the well-known endpoint (no more =
mod_rewrite).  But the whole reason for this is to avoid the requirement =
for a dynamic service behind well-known...
>>=20
>> "dynamic" and "static" are properties of the implementation, not the =
interface. HTTP doesn't require that any particular URL be "dynamic"; =
anything can, with the right metadata, be cached (and indeed, I've =
cached many, many things with the wrong metadata, because of silly site =
operators and their ideas about "dynamic").
>>=20
>> Now, if people want to target a particular implementation that makes =
it easier to serve a particular style of URL without writing code, fine, =
but let's not confuse things.
>>=20
>> E.g., a URL like
>>=20
>> http://example.com/.well-known/user/bob
>>=20
>> is easy to serve in pretty much any way you like with Apache.
>>=20
>> I'm also going to push back on the "it may not be feasible to do that =
across all organizations and deployments" motivation. This is a race to =
the bottom. The trick is to make it accessible enough to get sufficient =
traction to pull everyone along, without pandering to *everyone*'s =
requirements.
>>=20
>> Regards,
>>=20
>> --
>> Mark Nottingham   http://www.mnot.net/
>>=20
>>=20
>>=20
>>=20
>>=20
>> =20
>>=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>>=20
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>> =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
>=20
>=20


--Apple-Mail=_ECC57ABF-4C04-4979-92AD-28EAA1849251
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

If =
the bar is to high for people deploying or delegating Webfinger then =
protocols like OpenID Connect will need to find another alternative for =
the discovery of IdP information about a user.

My =
point is that managing a /.well-known/* is beyond the ability of many =
people.

John B.

On =
2012-08-31, at 1:33 PM, James M Snell <jasnell@gmail.com> =
wrote:

One of the key =
problems with all of this is that it really does not account for the =
fundamental use case of WebFinger: discovering which services and data =
are available for a given user within a given domain. Google, for =
instance, may host the email, but the users blog, calendar, or other =
services may have nothing to do with google. In fact, Google may not =
know *anything* about domains users and would therefore be generally =
incapable of providing useful information. In order for WebFinger to be =
useful, even with a DNS based bootstrap, the domain owner is going to =
have to provide the information about its users.



If the domain owner wishes to provide =
webfinger services, but defer that back to a google hosted service, the =
domain host should manage /.well-known/* itself and provide a reasonable =
http redirect back to the google hosted service. Then, the domain owner =
would need to work with google to ensure that the information served up =
is useful (even then, however, it would likely be just as easy for the =
domain owner to host everything themselves).




Referring back to my index draft [1].. =
it could look something like...




 GET =
/.well-known/index/\
    =
53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255/\<=
/div>


    calendar
 =
Host: example.org




 =
HTTP/1.1 302 Found
    =
53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255/\<=
/div>


    =
calendar





- James

On Wed, Aug 29, 2012 at 10:57 AM, John Bradley =
<ve7jtb@ve7jtb.com> wrote:



I am not the best person to represent =
Google's needs.

However as I understand it Google =
hosts applications such as email documents openID for tens of thousands =
of domains.



Google themselves don't control the =
DNS.

The people using the service generally add =
some MX records for aspmx.l.google.com. and a Cname for mail.example.com =
to ghs.google.com.




The A record for the bare domain typically points =
off to some Content management site the company uses for their web =
pages.

I think this is probably typical of =
Yahoo's mail hosting services and others.   




The service hosing the email/authentication/openID =
is not the one that controls the web server for =
company.

Saying the CMS venders will provide =
WebFinger services doesn't seem all that likely, especially in virtual =
hosting environments.




Getting a typical company to do anything more than =
enter a cname for webfinger.example.org is wildly =
optimistic.

I am entirely open to Ideas on =
this.   However the previous solution of having every RP check with =
google first to see if they host the email and provide the XRDS seems =
horribly flawed to me.




I would like to see a workable solution at the =
discovery layer that accommodates how people deploy there =
sites.

I think Bill suggested at one point =
using the MX record to find the webfinger host.  That has a bunch =
of problems I would prefer to avoid.




John B.

On =
2012-08-29, at 1:36 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:






John,


 
Well, we need to figure out how to address =
this.



 


Would it be reasonable to redirect requests from =
/.well-known/host-meta.json and /.well-known/host-meta to =
Google?



 


Are there other services or files under /.well-known that Google=92s =
customers would not want Google to host?  If they were OK with =
Google=92s servers responding to anything , then one could put an A (or =
CNAME) record in place for example.com that points to =
Google.



 


Not being familiar with what Google offers, I=92m a bit challenged to =
understand exactly what is and is not =
possible.



 


Paul
 






From: =
John Bradley [mailto:ve7jtb@ve7jtb.com] 


Sent: Wednesday, August 29, 2012 10:14 =
AM
To: Paul E. =
Jones
Cc: 'George Fletcher'; 'Mark =
Nottingham'; 'IETF Apps =
Discuss'
Subject: Re: [apps-discuss] Looking =
at Webfinger



 


There mite be a A record but that typically goes off to some virtual web =
hosting company and not the email service =
provider.


 
I think I =
have also heard William say this is a problem for =
Yahoo.




 


Google was not able to get people to deploy XRDS for hosted domains. =
  They came up with a proprietary extension to openID discovery to =
make hosted google apps domains work with some subset of =
RP.



 


The problem is that the company hosting a small businesses website is =
unlikely to provide the web finger infrastructure and there is no way =
for the email/openID provider to do it without their =
cooperation.



 


Adding a A record rather than a CNAME is generally not a good idea if it =
can be avoided.   In the event of the provider changing an IP =
address it breaks all the customers if they have used A records, but =
that is separate issue.  



 


You can set up webfinger on your web server and manage it.   It =
just won't work for large numbers of people as we have it now. =
 


 
If =
webfinger won't work for Google Apps for Domains and other hosted =
services like that then It will significantly impact adoption in my =
opinion.



 


We will also need to work around that for Connect.  We don't want =
another proprietary work around with the security problems that can =
entail.


 
John =
B.


 
On =
2012-08-28, at 11:37 PM, "Paul E. Jones" <paulej@packetizer.com> =
wrote:







John,

 


If Google is hosting the domain or any other service provider, =
wouldn=92t there still be an A record for the domain (e.g.,packetizer.com)?  I know there is =
for virtually every web hosting company I=92ve used.  It seems like =
this might just be one more hosted service Google could provide to its =
customers, no?



 



I do not know exactly how this hosted service works, but what=92s =
hosted?  I assume it=92s just email.  If web, then I see no =
issue.  If only email, then the user just needs to have MX records =
pointing to Google and an A record pointing to whatever service runs the =
WebFinger service.



 



In any case, if they can add a CNAME or MX record, I think we can get =
them to add an A record.  I think it would be far more challenging =
for SMBs to add a host like webfinger.example.com.  That =
would still require an A record and a service provider capable of =
supporting it.



 



Paul



 



From: John =
Bradley [mailto:ve7jtb@ve7jtb.com] 


Sent: Tuesday, August 28, 2012 3:29 =
PM
To: Paul E. =
Jones
Cc: 'George Fletcher'; 'Mark =
Nottingham'; 'IETF Apps =
Discuss'
Subject: Re: [apps-discuss] Looking =
at Webfinger



 


There are cases where there are hosted domains (Google etc) that may not =
have a http host for the domain name used in the users email address. =
 


 
There may =
be merit to having a webfinger.example.com =
fallback where the client can't reach the .well-known for the primary =
host.



 


I know that some sort of SRV record would be the correct way to do it, =
but in the real world SMB don't enter SRV records even if there DNS =
provider support them.


The most you can get them to do is add a CNAME or MX =
record.
 


Supporting these sorts of domains somehow is a important =
issue.
 



John B.


 
On =
2012-08-28, at 3:17 PM, "Paul E. Jones" <paulej@packetizer.com> =
wrote:








George,


 
I believe it might be useful to introduce those who break your =
WebFinger server to Louisville Slugger. :)



 



Your pain is understood, but I do not see a way to avoid it.  We =
could introduce something in DNS, but that would also present =
challenges.  No matter where we =93root=94 the discovery process, =
there is a potential somebody could break it.  It could be rooted =
somewhere other than the root of the domain (e.g., webfinger.example.com), but we either =
need to decide in advance of such a location or introduce a way to =
discovery the discovery resources.



 



Do you have a suggestion that would make this less likely to be =
broken?



 



Paul



 



From: apps-discuss-bounces@ietf.org =
;[mailto:apps-discuss-bounces@ietf.org] On Behalf Of George Fletcher


Sent: Tuesday, August 28, 2012 11:09 =
AM
To: Mark =
Nottingham
Cc: IETF Apps =
Discuss
Subject: Re: [apps-discuss] Looking =
at Webfinger



 


Way "late to the party" =
but I can speak from experience that deployment can be a real issue in =
some environments. It's all really straight forward in a small company =
or an environment where the identity team "owns" the root domain =
(e.g. example.com). However, if an entire =
other group in a large organization "owns" the root domain (home page =
for the site) and the identity team then needs to get them to make =
changes, the deployment solution gets brittle pretty quick. I've had our =
webfinger support broken at least twice because the "other" team didn't =
know that certain configs were required:)



Also, installing the "dynamic pluming" can be more problematic is =
these cases. It is possible to get apache rewrite rules or netscaler =
magic in place to make it work, it's just a more brittle deployment =
architecture.



Thanks,
George
On 7/4/12 6:58 PM, John Panzer =
wrote:



Mark -- Of =
course I was speaking about practical realities of typical web server =
administration and deployment.  In practical terms, adding a new =
mod_rewrite rule or moral equivalent is going to be easier than adding a =
new PHP script that connects to a database.  The latter is just =
always going to be a much higher bar.



 


And, something that returns per-user data is generally going to need a =
dynamic service of some kind, unless your site has just a handful of =
users and you don't mind going through a publishing exercise each time =
you add or change a user...



 


None of this has anything to do with the interface, just deployment =
realities.  And in reality all of this is going to need a dynamic =
service somewhere for each non-trivial site, this is all just a question =
of how to hook it up.






--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / =
@jpanzer



 


 
On Wed, Jul =
4, 2012 at 3:36 PM, Mark Nottingham <mnot@mnot.net> =
wrote:



On 05/07/2012, =
at 8:16 AM, John Panzer wrote:

> Just as a historical note. =
 The envisioned usage of host-meta was originally to avoid a =
specification which mandated a particular dynamic URL API at a =
particular /.well-known endpoint (because it may not be feasible to do =
that across all organizations and deployments).  The host-meta =
document itself would be highly cacheable and so wouldn't incur an =
additional network trip in the common case.


>
> Having a 3xx redirect is a reasonable alternative that =
allows a similar escape hatch via something like mod_rewrite, albeit at =
the cost of needing an additional network trip each time.  Since a =
deployment can always avoid the 3xx redirect with additional dynamic =
plumbing behind the well-known endpoint, I don't think that's a horrible =
thing.


>
> An application-level redirect would be almost equivalent to =
an HTTP redirect, but then there are two ways to do the same thing. =
 If _only_ an application-level redirect is allowed, then you have =
to have at least a minimal dynamic service at the well-known endpoint =
(no more mod_rewrite).  But the whole reason for this is to avoid =
the requirement for a dynamic service behind =
well-known...



"dynamic" =
and "static" are properties of the implementation, not the interface. =
HTTP doesn't require that any particular URL be "dynamic"; anything can, =
with the right metadata, be cached (and indeed, I've cached many, many =
things with the wrong metadata, because of silly site operators and =
their ideas about "dynamic").



Now, if people want to target a particular implementation that makes =
it easier to serve a particular style of URL without writing code, fine, =
but let's not confuse things.

E.g., a URL like

http://example.com/.well-known/user/bob<=
br>


is easy to serve in pretty much any way you like with =
Apache.

I'm also going to push back on the "it may not be =
feasible to do that across all organizations and deployments" =
motivation. This is a race to the bottom. The trick is to make it =
accessible enough to get sufficient traction to pull everyone along, =
without pandering to *everyone*'s requirements.



Regards,

--
Mark Nottingham   http://www.mnot.net/






 







_______________________________________________
<=
pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courier =
New'">
apps-discuss mailing list
apps-discuss@ietf.org


https://www.ietf.org/mailman/listinfo/apps-discuss<=
/span>



 


______________=
_________________________________
apps-discuss mailing list
apps-discuss@ietf.org


https://www.ietf.org/mailman/listinfo/apps-discuss<=
/span>







_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/apps-discuss





=

--Apple-Mail=_ECC57ABF-4C04-4979-92AD-28EAA1849251--

--Apple-Mail=_3D9E8E16-2599-4046-A830-13579C796FA3
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgz
MTE3NDk1M1owIwYJKoZIhvcNAQkEMRYEFH0e+lTdm8oC7Xbv7fD/xzoHIQ+1MIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
AC472HDAFmkO9IJ1ekc9cojygOWPna57A0T46IvLLzKshnHz0ezpAS81VUjUtMLzdfKtwUZWiWYd
0tdu1GAfSQAOGINleFTLoYNWagg62nDsBqRZ+AhW9ySLo5laXTn+Jl8Fm4wj3nUFqBd3qe2NivJf
er69W4ajZyX13d47YrPYYDab5U8AJrPyIRgLGyCYWabnWtYW4AcDg2nn+/kOqkDagXjpVGcQuL4L
W8nXrIW1bBbfDI88mCux9eXj/y7SyMwjqUwqo1jirjUUgZGUA9/+l4B0cyl3MhHusRMiE837vJAR
rr2/G3igE4rwl7NM4m2qdYkBYQ+stmdI8twQcukAAAAAAAA=

--Apple-Mail=_3D9E8E16-2599-4046-A830-13579C796FA3--

From sm@resistor.net  Fri Aug 31 12:32:38 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2566521F855B for ; Fri, 31 Aug 2012 12:32:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.49
X-Spam-Level: 
X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGC+S3LETj59 for ; Fri, 31 Aug 2012 12:32:37 -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 83EE821F8540 for ; Fri, 31 Aug 2012 12:32:37 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7VJWVx1007930; Fri, 31 Aug 2012 12:32:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346441556; bh=EWy+oIzscHcvK5kQC//18/ZfJ6MiQTblv6/4FL+pis4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QKQ3bXqepNTJY7wTa9CyjzB/P739rid8lUa6juJwLJ2o5fnunS8UxDfmIuo8w2FOr AuHGgaTePk7Wv+OfIY7m8WPvL3oREyF61jWY2rD/uIqtB86SLeniIp9pclfcEdJEIR 38p3llBLi3vrOixPx0f7ko2Sap3njvdzV6g5REus=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1346441556; i=@resistor.net; bh=EWy+oIzscHcvK5kQC//18/ZfJ6MiQTblv6/4FL+pis4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=hbUOh1QvjzSGMpUHr2KXQYmZnOLKVzqtE3j26iP3xCFkL8hCj3shtimc84dA6B4Zg dxb39VbBliKqSr3HxzOct3Zszz+zSHuQLiXHwPZcHz+HuQt6FnaoJDxs1RsqsjU9sO cVTkIdocVzjYbC0oqcjQSVl81WiEmcbc3z1YIG5A=
Message-Id: <6.2.5.6.2.20120831120534.0965a520@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 31 Aug 2012 12:23:41 -0700
To: "Tschofenig, Hannes (NSN - FI/Espoo)" 
From: SM 
In-Reply-To: <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-in tra.net>
References:  <20120831062013.GA27979@1wt.eu> <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: Apps Discuss 
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 19:32:38 -0000

Hi Hannes,
At 00:39 31-08-2012, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>The reverse proxy story is a way to make this look good and we know it
>will be used otherwise.

On Fridays we can pretend that we don't know. :-)

>I don't know why aren't acknowledging that there are privacy concerns as
>well even if they are inconvenient for an engineer. Just adding fluffy
>and warm text does not make these concerns go away. I think we are
>cheating here.

There has been some discussion about privacy concerns.  The simple 
path would have been to acknowledge that as it was clear that it 
would an issue.  You are looking at the implications of the IETF 
giving its imprimatur whereas the focus has been getting a 
specification.  If we ignore the implications it will end up looking 
bad one of these days.

Regards,
-sm 


From john-ietf@jck.com  Fri Aug 31 12:42:26 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8572711E80BA for ; Fri, 31 Aug 2012 12:42:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.588
X-Spam-Level: 
X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAnFG9Laakrg for ; Fri, 31 Aug 2012 12:42:26 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id EBD1B11E808A for ; Fri, 31 Aug 2012 12:42:25 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1T7X6i-0000z3-2p; Fri, 31 Aug 2012 15:42:20 -0400
Date: Fri, 31 Aug 2012 15:42:15 -0400
From: John C Klensin 
To: Graham Klyne 
Message-ID: 
In-Reply-To: <5040E8D7.4040203@ninebynine.org>
References:  <73D8F9539EBE5AD39496AFBA@JcK-HP8200.jck.com> <5040E8D7.4040203@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
Cc: Apps Discuss 
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 19:42:26 -0000

--On Friday, August 31, 2012 17:39 +0100 Graham Klyne
 wrote:

> Something similar had occurred to me about going for
> informational/experimental rather than standards-track
> publication, which does not preclude a later upgrade.
> 
> There's one further (small) consideration: registration of the
> defined header field.  Standards-track approval pretty much
> guarantees that it meets the criteria for permanent
> registration.  Informational is less clear cut, but in this
> case I would judge that there has been sufficient discussion
> to warrant such a registration if RFC publication is approved
> following discussion and consensus in this forum.

Graham,

I think we are in agreement but, with the understanding that I'm
talking about a general principle rather than the procedures or
minimal criteria for any specific registry, let me try to
restate this to test that hypothesis:

Registrations are about documentation, avoidance of conflicting
uses, and other aids to interoperability, not seals of approval.
Given that, if we have a situation in which 

	-- there are a keyword and associated procedure that are
	in wide use, 
	
	-- the protocol and keywords are reflected in a stable
	and available document  (RFCs certainly qualify, perhaps
	by definition)
	
	-- those who are experts in the deployment situation
	generally agree that the document accurately reflects
	the actual use and describes significant known issues

Then I would contend that, if we can't register the thing, the
defect is in the registration model or procedures, not in the
nature of the spec or keyword.

    john


From sm@resistor.net  Fri Aug 31 13:09:13 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81E621F8555 for ; Fri, 31 Aug 2012 13:09:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.492
X-Spam-Level: 
X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyRwPbiG2anQ for ; Fri, 31 Aug 2012 13:09:13 -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 1C10021F84CF for ; Fri, 31 Aug 2012 13:09:13 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7VK8iIl000714; Fri, 31 Aug 2012 13:08:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346443728; bh=5UDRCL7xkLNDLAObnvEy49F5xojcXHS8SPf5OPld+sw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Tu+FPusVrMXPuZT47Q8pYPulv4Hj2l2bUobaf1Bt5U6llxjgWkczNgBwTli6bsViH IvhK1Wbpk0KyGIM9/fb39bwDSj715gKaTYHf4o2p9AMy2hEkX3+QiN/zBB2QL73AKF Kace0Rge7HM8FxQoa+6kUD3ti52iHl91p8aM+RUQ=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1346443728; i=@resistor.net; bh=5UDRCL7xkLNDLAObnvEy49F5xojcXHS8SPf5OPld+sw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=En0E+NTSQAcpqFZ1CPipoq8NTLNZLkcSEtrcNB1kELn1I4kN82NM6joaB1P0aXHsC xoSJOr9u5BY4WpNGZxnu12TA4Dwdo07ZEbbbDLOI0KMsf+SvqwhSvul9GQpP2L4MQd ttwZZ7FX8tggZc4OR6ooqrUkz7aMHgMxgHRHRP28=
Message-Id: <6.2.5.6.2.20120831123458.098ed438@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 31 Aug 2012 12:47:40 -0700
To: Willy Tarreau 
From: SM 
In-Reply-To: <20120831075430.GA28281@1wt.eu>
References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: Apps Discuss 
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 20:09:13 -0000

Hi Willy,
At 00:54 31-08-2012, Willy Tarreau wrote:
>But then what are you proposing ? It's just like saying that we should
>forbid eating with forks and knifes in restaurants because some people
>might use the knife to kill their noisy neighbour. Everything which is

Some airlines now provide plastic knives to avoid such inconveniences.  :-)

One DISCUSS mentioned that:

   "This feels to me like when a draft was just recently floated to
    standardize TLS proxies (i.e., standardized MITM) - sure we
    could do that but is really a good idea?"

Embarrassment is waiting down the road when "bad things" (TM) happen 
in case the IETF decides to touch that.

Regards,
-sm 


From bobwyman@gmail.com  Fri Aug 31 13:35:46 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499BA21F8596 for ; Fri, 31 Aug 2012 13:35:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.933
X-Spam-Level: 
X-Spam-Status: No, score=-2.933 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ji9-V7UsOkH4 for ; Fri, 31 Aug 2012 13:35:43 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 069C321F8568 for ; Fri, 31 Aug 2012 13:35:42 -0700 (PDT)
Received: by iabz21 with SMTP id z21so6238383iab.31 for ; Fri, 31 Aug 2012 13:35: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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VvmiGgApOup36+cnkdO+NpJR2/HD3oW33E1svuG35xo=; b=PVVZvNmlmVBGGaa5v0mz7pxIyiFrS9pVPPTkrniafzjO68Zv0pnxYhlmq8DTJv457u gKpbfT+/v5fG2wSu3Mr5YECQ0za0SMWYSAXHvXOkM9OXzOOFCVuEeGljfxhoodQ9WN+R gdt8fQ5ukFLUYvWukeMnZ2O7HOvb/bhf1ChMEA8Cr2eyl0mfwcRSDUFS+yUKgHtbuVPt xSyNZ/5LG82Lp54nYigPVbQXDXLshRY1YtFmv39R5fucvDiXdC8fPRuFgPeI/MyHhZdO t3ZW8ETwSn4lKKv9zVA+cpxCvA0XMoSaYkc/nfrtsSVoWtO48vWLNmzwQcwQJkj/V1h3 2Dwg==
MIME-Version: 1.0
Received: by 10.50.207.35 with SMTP id lt3mr4215330igc.49.1346445342195; Fri, 31 Aug 2012 13:35:42 -0700 (PDT)
Sender: bobwyman@gmail.com
Received: by 10.64.148.76 with HTTP; Fri, 31 Aug 2012 13:35:41 -0700 (PDT)
In-Reply-To: 
References:  <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com>   <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com>      <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net>  <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com> <032d01cd8597$aac7f740$0057e5c0$@packetizer.com> <046501cd860c$da464420$8ed2cc60$@packetizer.com> <287CDD14-DEC2-40AD-AD5D-DC102D5AAAE6@ve7jtb.com> 
Date: Fri, 31 Aug 2012 16:35:41 -0400
X-Google-Sender-Auth: DaN2HYibdu1onB20DoWlMZuNk-I
Message-ID: 
From: Bob Wyman 
To: James M Snell 
Content-Type: multipart/alternative; boundary=14dae9340e5d54c00204c895bcb6
Cc: Mark Nottingham , IETF Apps Discuss 
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 Aug 2012 20:35:46 -0000

--14dae9340e5d54c00204c895bcb6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 31, 2012 at 1:33 PM, James M Snell  wrote:

> One of the key problems with all of this is that it really does not
> account for the fundamental use case of WebFinger: discovering which
> services and data are available for a given user within a given domain.

I agree with your definition of the "fundamental use case for WebFinger"
only until you write "within a given domain." Including that seemingly
minor flourish at the end of the definition drastically changes what *i*
think is the fundamental use case for WebFinger.

The "within a given domain" seems to imply that any domain that provides
service to a user would be able to acknowledge that fact and perhaps
provide, in response to queries, some information about the user. Thus,
your definition seems to cast WebFinger as a tool to enable services to
talk about their users.

But, I view the value and use of WebFinger very differently. To me
WebFinger isn't something that allows services to talk about users, but
rather a tool to enable users to usefully describe themselves and the
services that can or should be used to interact with them.

I might use dozens of services, but I expect that only one of those
services, my chosen WebFinger provider, would ever provide any metadata
concerning me. The only exception to this is that I may chose to allow some
or all of the non-WebFinger services that I use to provide a link to my
chosen WebFinger service -- by providing an acct: URI that I have provided.

You say: "In order for WebFinger to be useful,... the domain owner is going
to have to provide the information about its users." I don't think this is
right. I suggest that "In order for WebFinger to be useful, then
*users*are going to have to provide WebFinger with information about
themselves.

I may choose to use "gmail.com" as my email provider. However, even if I
do, I should be free to use "example.com" to host my WebFinger acct: URI.
Simply because you have discovered my email address shouldn't allow you to
discover my acct: URI, or anything else about me, unless I've explicitly
chosen to allow that. Also, I shouldn't be required to receive *any*
service other than WebFinger from my WebFinger provider. (In fact, I can
see that being a WebFinger provider would make a nice business for some
folk.) What this means is that if some email provider has things set up so
that I can't use them as a WebFinger host, I'm simply going to get that
service from somewhere else. I'll then identify myself to people using my
acct: URI and will switch my email account around based on who gives me the
best service today. I won't be pinned to an email service simply because
some people think it is part of my "name." (Note: Email providers would be
well advised to provide good WebFinger services if they wish to remain
competitive.)

Given the above, it makes sense to me that the simplest implementation of
WebFinger should require no more of me other than creating an XML or JSON
encoded file (I don't care which) and causing that file to appear in some
known, HTTP-accessible, location on the web. If one or more of the services
I currently use can't or won't allow that, then too bad for them. I'll host
my WebFinger data somewhere else.

In summary: WebFinger is supposed to be about users providing information
about themselves, not about services providing information about their
users.

bob wyman


Google, for instance, may host the email, but the users blog, calendar, or
> other services may have nothing to do with google. In fact, Google may no=
t
> know *anything* about domains users and would therefore be generally
> incapable of providing useful information. In order for WebFinger to be
> useful, even with a DNS based bootstrap, the domain owner is going to hav=
e
> to provide the information about its users.
>
> If the domain owner wishes to provide webfinger services, but defer that
> back to a google hosted service, the domain host should manage
> /.well-known/* itself and provide a reasonable http redirect back to the
> google hosted service. Then, the domain owner would need to work with
> google to ensure that the information served up is useful (even then,
> however, it would likely be just as easy for the domain owner to host
> everything themselves).
>
> Referring back to my index draft [1].. it could look something like...
>
>  GET /.well-known/index/\
> 53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255/\
>  calendar
> Host: example.org
>
> HTTP/1.1 302 Found
>  Location: https://webfinger.google.com/example.org/\
> 53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255/\
>  calendar
>
> [1] http://www.ietf.org/id/draft-snell-web-index-00.txt
>
> - James
>
> On Wed, Aug 29, 2012 at 10:57 AM, John Bradley  wrote:
>
>> I am not the best person to represent Google's needs.
>>
>> However as I understand it Google hosts applications such as email
>> documents openID for tens of thousands of domains.
>> Google themselves don't control the DNS.
>>
>> The people using the service generally add some MX records for
>> aspmx.l.google.com. and a Cname for mail.example.com to ghs.google.com.
>>
>> The A record for the bare domain typically points off to some Content
>> management site the company uses for their web pages.
>>
>> I think this is probably typical of Yahoo's mail hosting services and
>> others.
>>
>> The service hosing the email/authentication/openID is not the one that
>> controls the web server for company.
>>
>> Saying the CMS venders will provide WebFinger services doesn't seem all
>> that likely, especially in virtual hosting environments.
>>
>> Getting a typical company to do anything more than enter a cname for
>> webfinger.example.org is wildly optimistic.
>>
>> I am entirely open to Ideas on this.   However the previous solution of
>> having every RP check with google first to see if they host the email an=
d
>> provide the XRDS seems horribly flawed to me.
>>
>> I would like to see a workable solution at the discovery layer that
>> accommodates how people deploy there sites.
>>
>> I think Bill suggested at one point using the MX record to find the
>> webfinger host.  That has a bunch of problems I would prefer to avoid.
>>
>> John B.
>>
>> On 2012-08-29, at 1:36 PM, "Paul E. Jones"  wrote=
:
>>
>> John,****
>>
>> Well, we need to figure out how to address this.****
>>
>> Would it be reasonable to redirect requests from
>> /.well-known/host-meta.json and /.well-known/host-meta to Google?****
>>
>> Are there other services or files under /.well-known that Google=92s
>> customers would not want Google to host?  If they were OK with Google=92=
s
>> servers responding to anything , then one could put an A (or CNAME) reco=
rd
>> in place for example.com that points to Google.****
>>
>> Not being familiar with what Google offers, I=92m a bit challenged to
>> understand exactly what is and is not possible.****
>>
>> Paul****
>>
>>  *From:* John Bradley [mailto:ve7jtb@ve7jtb.com]
>> *Sent:* Wednesday, August 29, 2012 10:14 AM
>> *To:* Paul E. Jones
>> *Cc:* 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
>> *Subject:* Re: [apps-discuss] Looking at Webfinger****
>> ** **
>> There mite be a A record but that typically goes off to some virtual web
>> hosting company and not the email service provider.****
>> ** **
>> I think I have also heard William say this is a problem for Yahoo.****
>>  ** **
>> Google was not able to get people to deploy XRDS for hosted domains.
>> They came up with a proprietary extension to openID discovery to make
>> hosted google apps domains work with some subset of RP.****
>> ** **
>> The problem is that the company hosting a small businesses website is
>> unlikely to provide the web finger infrastructure and there is no way fo=
r
>> the email/openID provider to do it without their cooperation.****
>> ** **
>> Adding a A record rather than a CNAME is generally not a good idea if it
>> can be avoided.   In the event of the provider changing an IP address it
>> breaks all the customers if they have used A records, but that is separa=
te
>> issue.  ****
>> ** **
>> You can set up webfinger on your web server and manage it.   It just
>> won't work for large numbers of people as we have it now.  ****
>> ** **
>> If webfinger won't work for Google Apps for Domains and other hosted
>> services like that then It will significantly impact adoption in my opin=
ion.
>> ****
>> ** **
>> We will also need to work around that for Connect.  We don't want anothe=
r
>> proprietary work around with the security problems that can entail.****
>> ** **
>> John B.****
>> ** **
>> On 2012-08-28, at 11:37 PM, "Paul E. Jones" 
>> wrote:****
>>
>>
>> ****
>> John,****
>>  ****
>> If Google is hosting the domain or any other service provider, wouldn=92=
t
>> there still be an A record for the domain (e.g.,packetizer.com)?  I know
>> there is for virtually every web hosting company I=92ve used.  It seems =
like
>> this might just be one more hosted service Google could provide to its
>> customers, no?****
>>  ****
>> I do not know exactly how this hosted service works, but what=92s hosted=
?
>> I assume it=92s just email.  If web, then I see no issue.  If only email=
,
>> then the user just needs to have MX records pointing to Google and an A
>> record pointing to whatever service runs the WebFinger service.****
>>  ****
>> In any case, if they can add a CNAME or MX record, I think we can get
>> them to add an A record.  I think it would be far more challenging for S=
MBs
>> to add a host like webfinger.example.com.  That would still require an A
>> record and a service provider capable of supporting it.****
>>  ****
>> Paul****
>>  ****
>> *From:* John Bradley [mailto:ve7jtb@ve7jtb.com]
>> *Sent:* Tuesday, August 28, 2012 3:29 PM
>> *To:* Paul E. Jones
>> *Cc:* 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
>> *Subject:* Re: [apps-discuss] Looking at Webfinger****
>>  ****
>> There are cases where there are hosted domains (Google etc) that may not
>> have a http host for the domain name used in the users email address.  *=
*
>> **
>>  ****
>> There may be merit to having a webfinger.example.com fallback where the
>> client can't reach the .well-known for the primary host.****
>>  ****
>> I know that some sort of SRV record would be the correct way to do it,
>> but in the real world SMB don't enter SRV records even if there DNS
>> provider support them.****
>> The most you can get them to do is add a CNAME or MX record.****
>>  ****
>> Supporting these sorts of domains somehow is a important issue.****
>>  ****
>> John B.****
>>  ****
>> On 2012-08-28, at 3:17 PM, "Paul E. Jones"  wrote=
:
>> ****
>>
>>
>>
>> ****
>> George,****
>>  ****
>> I believe it might be useful to introduce those who break your WebFinger
>> server to Louisville Slugger. :)****
>>  ****
>> Your pain is understood, but I do not see a way to avoid it.  We could
>> introduce something in DNS, but that would also present challenges.  No
>> matter where we =93root=94 the discovery process, there is a potential s=
omebody
>> could break it.  It could be rooted somewhere other than the root of the
>> domain (e.g., webfinger.example.com), but we either need to decide in
>> advance of such a location or introduce a way to discovery the discovery
>> resources.****
>>  ****
>> Do you have a suggestion that would make this less likely to be broken?*=
*
>> **
>>  ****
>> Paul****
>>  ****
>> *From:* apps-discuss-bounces@ietf.org [mailto:apps-
>> discuss-bounces@ietf.org] *On Behalf Of *George Fletcher
>> *Sent:* Tuesday, August 28, 2012 11:09 AM
>> *To:* Mark Nottingham
>> *Cc:* IETF Apps Discuss
>> *Subject:* Re: [apps-discuss] Looking at Webfinger****
>>  ****
>>
>> Way "late to the party" but I can speak from experience that deployment
>> can be a real issue in some environments. It's all really straight forwa=
rd
>> in a small company or an environment where the identity team "owns" the
>> root domain (e.g. example.com). However, if an entire other group in a
>> large organization "owns" the root domain (home page for the site) and t=
he
>> identity team then needs to get them to make changes, the deployment
>> solution gets brittle pretty quick. I've had our webfinger support broke=
n
>> at least twice because the "other" team didn't know that certain configs
>> were required:)
>>
>> Also, installing the "dynamic pluming" can be more problematic is these
>> cases. It is possible to get apache rewrite rules or netscaler magic in
>> place to make it work, it's just a more brittle deployment architecture.
>>
>> Thanks,
>> George****
>> On 7/4/12 6:58 PM, John Panzer wrote:****
>>
>> Mark -- Of course I was speaking about practical realities of typical we=
b
>> server administration and deployment.  In practical terms, adding a new
>> mod_rewrite rule or moral equivalent is going to be easier than adding a
>> new PHP script that connects to a database.  The latter is just always
>> going to be a much higher bar.****
>>  ****
>> And, something that returns per-user data is generally going to need a
>> dynamic service of some kind, unless your site has just a handful of use=
rs
>> and you don't mind going through a publishing exercise each time you add=
 or
>> change a user...****
>>  ****
>> None of this has anything to do with the interface, just deployment
>> realities.  And in reality all of this is going to need a dynamic servic=
e
>> somewhere for each non-trivial site, this is all just a question of how =
to
>> hook it up.****
>>
>> ****
>> --
>> John Panzer / Google
>> jpanzer@google.com / abstractioneer.org =
 /
>> @jpanzer****
>>  ****
>>
>>  ****
>> On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham  wrote:**=
*
>> *
>>
>> On 05/07/2012, at 8:16 AM, John Panzer wrote:
>>
>> > Just as a historical note.  The envisioned usage of host-meta was
>> originally to avoid a specification which mandated a particular dynamic =
URL
>> API at a particular /.well-known endpoint (because it may not be feasibl=
e
>> to do that across all organizations and deployments).  The host-meta
>> document itself would be highly cacheable and so wouldn't incur an
>> additional network trip in the common case.
>> >
>> > Having a 3xx redirect is a reasonable alternative that allows a simila=
r
>> escape hatch via something like mod_rewrite, albeit at the cost of needi=
ng
>> an additional network trip each time.  Since a deployment can always avo=
id
>> the 3xx redirect with additional dynamic plumbing behind the well-known
>> endpoint, I don't think that's a horrible thing.
>> >
>> > An application-level redirect would be almost equivalent to an HTTP
>> redirect, but then there are two ways to do the same thing.  If _only_ a=
n
>> application-level redirect is allowed, then you have to have at least a
>> minimal dynamic service at the well-known endpoint (no more mod_rewrite)=
.
>>  But the whole reason for this is to avoid the requirement for a dynamic
>> service behind well-known...****
>> "dynamic" and "static" are properties of the implementation, not the
>> interface. HTTP doesn't require that any particular URL be "dynamic";
>> anything can, with the right metadata, be cached (and indeed, I've cache=
d
>> many, many things with the wrong metadata, because of silly site operato=
rs
>> and their ideas about "dynamic").
>>
>> Now, if people want to target a particular implementation that makes it
>> easier to serve a particular style of URL without writing code, fine, bu=
t
>> let's not confuse things.
>>
>> E.g., a URL like
>>
>> http://example.com/.well-known/user/bob
>>
>> is easy to serve in pretty much any way you like with Apache.
>>
>> I'm also going to push back on the "it may not be feasible to do that
>> across all organizations and deployments" motivation. This is a race to =
the
>> bottom. The trick is to make it accessible enough to get sufficient
>> traction to pull everyone along, without pandering to *everyone*'s
>> requirements.
>>
>> Regards,****
>>
>>
>> --
>> Mark Nottingham   http://www.mnot.net/
>>
>>
>>
>>
>> ****
>>  ****
>>
>>
>>
>>
>>
>> ****
>>
>> _______________________________________________****
>>
>> apps-discuss mailing list****
>>
>> apps-discuss@ietf.org****
>>
>> https://www.ietf.org/mailman/listinfo/apps-discuss****
>>
>>  ****
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss****
>>
>>
>>
>> _______________________________________________
>> 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
>
>

--14dae9340e5d54c00204c895bcb6
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable






--14dae9340e5d54c00204c895bcb6--

From paulej@packetizer.com  Fri Aug 31 18:08:04 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B73621F846F for ; Fri, 31 Aug 2012 18:08:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.353
X-Spam-Level: 
X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtit0X2d7xqA for ; Fri, 31 Aug 2012 18:08:03 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4B41C21F846E for ; Fri, 31 Aug 2012 18:08:03 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q81181OM006467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 Aug 2012 21:08:02 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1346461682; bh=9W+qwj54RmOpVyccahlm+Kau1Tz+b4wRH3zfGiPxSFo=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Xx/TpQ2qchiOHTRrLe51lhY6UnMoy/Ye5HYEZ7hyQMLZ8DaDg1XNBacqIeDnRjAlE TiLsB9QLYmTDf7KLXiGByxbDovdYeSmUb20UdvE7+7aPj3ynnkA/G1Os0mOPyq+DI0 mWRgUEiP3sdjnxJpi4wisNnTM8YWlApfWwAfysu8=
From: "Paul E. Jones" 
To: "'Goix Laurent Walter'" , "=?UTF-8?Q?'=E2=98=AE_elf_Pavlik_=E2=98=AE'?=" ,  "'Peter Saint-Andre'" 
References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im>	<5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im>	<4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com>	<1346172875-sup-9676@heahdk.net> <503D04E5.1090506@stpeter.im>	<1346176849-sup-3504@heahdk.net>  <047b01cd860f$d31f7ce0$795e76a0$@packetizer.com> 
In-Reply-To: 
Date: Fri, 31 Aug 2012 21:08:27 -0400
Message-ID: <079001cd87de$4ba00480$e2e00d80$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHQkPRpqE241VMBhFX0b1E5n3icagGmT2cgAfxtLQICXYfDzwLd38ExAfCD3o0CSm6TWwHz+GlOAlI3tJgCXV8wQQGG1ghXlsR96HA=
Content-Language: en-us
Cc: 'apps-discuss' 
Subject: Re: [apps-discuss] R: Comment on draft-ietf-appsawg-acct-uri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Sep 2012 01:08:04 -0000

Walter,

> I agree it is "more or less" the same at the end. However I expect =
that
> from current implementations of webfinger, very little link rels are
> provided in the host-meta vs resource-specific descriptor so putting =
many
> templates in the host-meta already is not best practice yet afaik.
> Of course nothing prevents from changing this behaviour in the future =
but
> as this scenario may become mainstream (I do hope that in a few years =
very
> big social islands will webfinger each other).
>=20
> Thus I am wondering whether it could make sense:
> - adding it as an example in the draft clarifying the practice and
> emphasizing the insertion of additional link rel templates already in =
the
> host-meta

I could certainly show an example similar to what is in RFC 6415 Section =
1.1, perhaps adding additional host-wide properties and link relations.  =
However, I'm not sure what you mean by "emphasizing the insertion of =
additional link rel templates".  Host-wide information uses link =
relations, not templates.  Templates are used for resource-specific =
information.

> - specifying new templates variable names to be used in templates, as =
this
> scenario makes strong use of templates and may need to reference
> additional information. The first that comes into my mind (as per the
> example in my previous email) is the local username, that could be
> identified as {uri.userpart}, {username} or anything else. Maybe other
> could also make sense.

I really think it's a bad idea for us to introduce more template =
variables.  This gets complicated.  WebFinger was designed to operate on =
a single URI.  Since a URI can contain any kind of information, I think =
that should be sufficient.

Paul



From paulej@packetizer.com  Fri Aug 31 18:17:51 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5D211E808E for ; Fri, 31 Aug 2012 18:17:51 -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=[AWL=-0.614, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7QlPPKSedvD for ; Fri, 31 Aug 2012 18:17:46 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4F54311E808D for ; Fri, 31 Aug 2012 18:17:46 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q811HiPb006754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 Aug 2012 21:17:45 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1346462265; bh=oX8F1yODO4drGZp1W2AM+c6L5rNIiK5p+Jsl/p6j7Io=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=lXYO2q2f6OJC6D136B6BoMZZ2mzS9Ce4UclWjCCOjfnTpG0eDmaThjggm8EWuTqXK mOPrUc1lsYo48zET0uihyGfYAO/snxKO/s3F33tSCJ0tQ+Qzm4zTiYiDocNhPzzNqi wbfONvOxNmps7bDXj5CLymRMy9rqDObiTLoTVWn8=
From: "Paul E. Jones" 
To: "'Goix Laurent Walter'" , "'John Bradley'" 
References: <010901cd846c$95d74560$c185d020$@packetizer.com>	<1346084277.68046.YahooMailNeo@web31802.mail.mud.yahoo.com>			<017001cd849e$cbdd9c90$6398d5b0$@packetizer.com>			<028a01cd854f$c29a86f0$47cf94d0$@packetizer.com> <050232F8-4175-4698-95D7-17E4B35B1210@ve7jtb.com> 
In-Reply-To: 
Date: Fri, 31 Aug 2012 21:18:10 -0400
Message-ID: <079201cd87df$a70ac4d0$f5204e70$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_0793_01CD87BE.1FFB95D0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIrZE+abU/d+x34aW2WxIOtEY8jpwIfXwJkAk1l+2oB11boGgF43hDQAwFsJFECCPyssQCxWdIfAXT4R9oBrFaWj5Y0JDoQ
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs	JSON
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Sep 2012 01:17:51 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0793_01CD87BE.1FFB95D0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0794_01CD87BE.1FFBBCE0"


------=_NextPart_001_0794_01CD87BE.1FFBBCE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Walter,

=20

I believe the group is leaning toward not having the appendix and merely
indicating that JSON is the only format that is mandatory to implement.
I=92ll try to re-word it in that way.  In all examples, I will use
host-meta.json.  I do think it would be useful to discuss content
negotiation.  I=92ll mention that and provide an example.  Host-meta =
should
support content negotiation, in my opinion.  However, since XML might =
not be
implemented, a client may get nothing.

=20

Making JSON the only MTI format does still give me a feeling of =
uneasiness
since, as you note, every implementation right now is XML.  This will
definitely break that.  However, the push has been pretty strong to go =
in
this direction.  My own personal preference still remains that servers
implement both, since it=92s so darn simple to do.

=20

That said, we would still have a problem with existing servers if they =
do
not support JSON and a client expected all servers support JSON.  Would
people feel ok with saying that servers should support both XRD and JRD? =
 Or
is the preference really JRD is MUST and XRD is MAY?

=20

Paul

=20

From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it]=20
Sent: Thursday, August 30, 2012 5:55 AM
To: John Bradley; Paul E. Jones
Cc: apps-discuss@ietf.org
Subject: R: [apps-discuss] Proposed changes to WebFinger regarding XML =
vs
JSON

=20

I am also fine with the json version being privileged in the future.

However we cannot ignore completely that webfinger XML-based =
implementations
already exist (and may not upgrade all together), and we do have already
some text written in the draft so instead of deleting entirely what was
written we could probably find a way to rephrase it to make it optional =
for
servers to support the xml version (no appendix).=20

=20

BTW as rfc6415 currently says, jrd is returned only in response to
host-meta.json endpoint. If only host-meta is queried, negotiation is
required using the accept header. Given the current agreement in the =
group,
is there any change or clarification expected in the wf draft regarding
this? In other words, as per current statements both xrd and jrd can =
already
be supported on distinct endpoints, thus simplifying their coexistence. =
But
it seems to me that the group would like some stronger statements =
towards
jrd with no need for =93.json=94 in the endpioint name neither for =
content
negotiation (but as default content). Am I right?

=20

Regards

walter

=20

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
Per
conto di John Bradley
Inviato: marted=EC 28 agosto 2012 21.13
A: Paul E. Jones
Cc: apps-discuss@ietf.org
Oggetto: Re: [apps-discuss] Proposed changes to WebFinger regarding XML =
vs
JSON

=20

I understand, but I think forcing servers to support both will hurt
adoption, though not as much as requiring it on the client.

=20

John B.

=20

=20

On 2012-08-28, at 3:03 PM, "Paul E. Jones"  =
wrote:

=20

John,

=20

Previously, JSON and XML were MTI on servers; clients could implement =
what
they want.

=20

If we make the proposed change, XML will be dropped on the server side.  =
The
result will be that clients can only rely on JSON support.  XML support
might be rare.

=20

Paul

=20

PS =96 My personal preference is still to require XML and JSON on the =
server,
but I=92m willing to give in on this one in order to reach group =
consensus.  I
think this was the most significant point of contention.

=20

From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
Sent: Tuesday, August 28, 2012 2:26 PM
To: Will Norris
Cc: Paul E. Jones; apps-discuss@ietf.org
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML =
vs
JSON

=20

+1 JSON must be MTI for servers.

=20

I am not opposed to servers supporting XML or other formats via content
negotiation,  however clients need to be interoperable with servers =
using
JSON, and not forced to support XML for some servers.

=20

John B.

=20

On 2012-08-27, at 7:13 PM, Will Norris < 
will@willnorris.com> wrote:





as one of the editors of said XML format, I'm +1 as well.  The reasons =
for
pushing so heavily for the XML format back then are no longer really =
true.
Instead, all the active work is on JSON-based formats, so it makes sense =
to
update webfinger as well.

On Mon, Aug 27, 2012 at 2:56 PM, Paul E. Jones <
 paulej@packetizer.com> wrote:

Ok... we could also do that.


> -----Original Message-----
> From:  
apps-discuss-bounces@ietf.org [mailto:
 apps-discuss-bounces@ietf.org]
> On Behalf Of Blaine Cook
> Sent: Monday, August 27, 2012 12:29 PM
> To:   apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding =
XML vs
> JSON
>
> +1 to this, and William and Tim's points.
>
> On 27 August 2012 18:26, Tim Bray < 
tbray@textuality.com> wrote:
> > What William said about not needing the appendix. If you=92re going =
to
> > go through the pain of abandoning the XML version, why also go =
through
> > the pain of writing an appendix, when there=92s a perfectly good RFC =
in
> > place to point to.  -T
> >
> > On Mon, Aug 27, 2012 at 9:17 AM, William Mills <
 wmills@yahoo-inc.com>
> wrote:
> >> I think this works in general but that there should be a mention of
> >> it in the body of the spec citing the appendix.  Do we even need an
> >> appendix though, we could simply cite 6415 as still normative for =
the
> >> XML stuff but deprecated for new implementations.
> >>
> >>
> >> ________________________________
> >> From: Paul E. Jones < 
paulej@packetizer.com>
> >> To:   apps-discuss@ietf.org
> >> Cc:   jsmarr@google.com;
 webfinger@googlegroups.com
> >> Sent: Monday, August 27, 2012 8:56 AM
> >> Subject: [apps-discuss] Proposed changes to WebFinger regarding XML
> >> vs JSON
> >>
> >> Folks,
> >>
> >> Mike, Gonzalo, and I have had some off-list discussions about
> >> WebFinger and how to resolve the one sticky point that we think has
> >> caused the most concern.  That point is whether we should we allow =
both
> XML and JSON.
> >>
> >> We have heard proposals to "just pick one" and, while I appreciate
> >> the reasoning, I could not help ignoring that
> >>
> >>   1) RFC 6415 exists and describes XML the single mandatory format
> >>   2) Existing implementations use XML
> >>
> >> Nonetheless, I also cannot ignore the long-term value in selecting
> >> one format we can be sure is widely supported consistently.  I'm
> >> fairly confident that most want only JSON at this point, even =
though
> >> most (if not
> >> all) current implementations today use XML.  While I'm personally
> >> favorable to using XML, I know my personal preferences are not
> >> representative of everyone. :-)
> >>
> >> So what we discussed was mentioning XML (perhaps with examples), =
but
> >> putting that in an appendix and saying the usage is historic.  What
> >> this would mean is that the text acknowledges that there are =
servers
> >> that might process both XML and JSON, and even older servers that
> >> only process XML.  The main body of the document would only require
> >> support for JSON from clients and servers.
> >>
> >> Before we make these changes to the text, I want to seek input from
> >> the group.  I believe it would be acceptable, but I do not want =
those
> >> changes to cause significant issues for anyone.
> >>
> >> Thanks,
> >> Paul
> >>
> >> PS - Please follow-up only on the apps-discuss list.
> >>
> >>
> >> _______________________________________________
> >> 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
> _______________________________________________
> 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

=20


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione =
derivante
dalla conoscenza di queste informazioni sono rigorosamente vietate. =
Qualora
abbiate ricevuto questo documento per errore siete cortesemente pregati =
di
darne immediata comunicazione al mittente e di provvedere alla sua
distruzione, Grazie.=20

This e-mail and any attachments is confidential and may contain =
privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the =
intended
recipient, please delete this message and any attachments and advise the
sender by return e-mail, Thanks.=20

rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non =
=E8
necessario.=20

=20


------=_NextPart_001_0794_01CD87BE.1FFBBCE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Walter,
 
I believe the group is leaning toward not having the appendix and =
merely indicating that JSON is the only format that is mandatory to =
implement.=A0 I’ll try to re-word it in that way.=A0 In all =
examples, I will use host-meta.json.=A0 I do think it would be useful to =
discuss content negotiation.=A0 I’ll mention that and provide an =
example.=A0 Host-meta should support content negotiation, in my =
opinion.=A0 However, since XML might not be implemented, a client may =
get nothing.
 
Making JSON the only MTI format does still give me a feeling of =
uneasiness since, as you note, every implementation right now is XML.=A0 =
This will definitely break that.=A0 However, the push has been pretty =
strong to go in this direction.=A0 My own personal preference still =
remains that servers implement both, since it’s so darn simple to =
do.
 
That said, we would still have a problem with existing servers if =
they do not support JSON and a client expected all servers support =
JSON.=A0 Would people feel ok with saying that servers should =
support both XRD and JRD?=A0 Or is the preference really JRD is MUST and =
XRD is MAY?
 
Paul
 
From:=
 =
Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] =

Sent: Thursday, August 30, 2012 5:55 AM
To: John =
Bradley; Paul E. Jones
Cc: =
apps-discuss@ietf.org
Subject: R: [apps-discuss] Proposed =
changes to WebFinger regarding XML vs =
JSON
 
I am also fine with the json version being privileged in the =
future.
However we cannot ignore completely that webfinger XML-based =
implementations already exist (and may not upgrade all together), and we =
do have already some text written in the draft so instead of deleting =
entirely what was written we could probably find a way to rephrase it to =
make it optional for servers to support the xml version (no appendix). =

 
BTW as rfc6415 currently says, jrd is returned only in response to =
host-meta.json endpoint. If only host-meta is queried, negotiation is =
required using the accept header. Given the current agreement in the =
group, is there any change or clarification expected in the wf draft =
regarding this? In other words, as per current statements both xrd and =
jrd can already be supported on distinct endpoints, thus simplifying =
their coexistence. But it seems to me that the group would like some =
stronger statements towards jrd with no need for “.json” in =
the endpioint name neither for content negotiation (but as default =
content). Am I right?
 
Regards
walter
 
Da: apps-discuss-bounces@ietf.o=
rg [mailto:apps-discu=
ss-bounces@ietf.org] Per conto di John =
Bradley
Inviato: marted=EC 28 agosto 2012 21.13
A: =
Paul E. Jones
Cc: apps-discuss@ietf.org
Ogg=
etto: Re: [apps-discuss] Proposed changes to WebFinger regarding XML =
vs JSON
 
I understand, but I think forcing servers to support both will =
hurt adoption, though not as much as requiring it on the =
client.
 
John B.
 
 
On 2012-08-28, at 3:03 PM, "Paul =
E. Jones" <paulej@packetizer.com> =
wrote:
 
John,
 
Previously, JSON and XML were MTI on servers; clients could implement =
what they want.
 
If we make the proposed change, XML will be dropped on the server =
side.  The result will be that clients can only rely on JSON =
support.  XML support might be =
rare.
 
Paul
 
PS – My personal preference is still to require XML and JSON on =
the server, but I’m willing to give in on this one in order to =
reach group consensus.  I think this was the most significant point =
of contention.
 
From:=
 John =
Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Tuesday, August 28, 2012 2:26 =
PM
To: Will =
Norris
Cc: Paul E. Jones; apps-discuss@ietf.org
Sub=
ject: Re: =
[apps-discuss] Proposed changes to WebFinger regarding XML vs =
JSON
 
+1 JSON must be MTI for =
servers.
 
I am not opposed to servers supporting XML or other =
formats via content negotiation,  however clients need to be =
interoperable with servers using JSON, and not forced to support XML for =
some servers.
 
John B.
 
On 2012-08-27, at 7:13 PM, Will Norris <will@willnorris.com> =
wrote:


as one of the editors =
of said XML format, I'm +1 as well.  The reasons for pushing so =
heavily for the XML format back then are no longer really true. =
 Instead, all the active work is on JSON-based formats, so it makes =
sense to update webfinger as well.
On Mon, Aug 27, 2012 at 2:56 PM, Paul E. Jones <paulej@packetizer.com> =
wrote:
Ok... we could also =
do that.

> =
-----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
> =
On Behalf Of Blaine Cook
> Sent: Monday, August 27, 2012 12:29 =
PM
> To: apps-discuss@ietf.org
> Subject: =
Re: [apps-discuss] Proposed changes to WebFinger regarding XML =
vs
> JSON
>
> +1 to this, and William and Tim's =
points.
>
> On 27 August 2012 18:26, Tim Bray <tbray@textuality.com> =
wrote:
> > What William said about not needing the appendix. If =
you’re going to
> > go through the pain of abandoning the =
XML version, why also go through
> > the pain of writing an =
appendix, when there’s a perfectly good RFC in
> > place =
to point to.  -T
> >
> > On Mon, Aug 27, 2012 at =
9:17 AM, William Mills <wmills@yahoo-inc.com>
> =
wrote:
> >> I think this works in general but that there =
should be a mention of
> >> it in the body of the spec =
citing the appendix.  Do we even need an
> >> appendix =
though, we could simply cite 6415 as still normative for the
> =
>> XML stuff but deprecated for new implementations.
> =
>>
> >>
> >> =
________________________________
> >> From: Paul E. Jones =
<paulej@packetizer.com>
> =
>> To: apps-discuss@ietf.org
> >> =
Cc: jsmarr@google.com; webfinger@googlegroups.com
> =
>> Sent: Monday, August 27, 2012 8:56 AM
> >> Subject: =
[apps-discuss] Proposed changes to WebFinger regarding XML
> =
>> vs JSON
> >>
> >> Folks,
> =
>>
> >> Mike, Gonzalo, and I have had some off-list =
discussions about
> >> WebFinger and how to resolve the one =
sticky point that we think has
> >> caused the most concern. =
 That point is whether we should we allow both
> XML and =
JSON.
> >>
> >> We have heard proposals to =
"just pick one" and, while I appreciate
> >> the =
reasoning, I could not help ignoring that
> >>
> =
>>   1) RFC 6415 exists and describes XML the single =
mandatory format
> >>   2) Existing implementations use =
XML
> >>
> >> Nonetheless, I also cannot ignore =
the long-term value in selecting
> >> one format we can be =
sure is widely supported consistently.  I'm
> >> fairly =
confident that most want only JSON at this point, even though
> =
>> most (if not
> >> all) current implementations =
today use XML.  While I'm personally
> >> favorable to =
using XML, I know my personal preferences are not
> >> =
representative of everyone. :-)
> >>
> >> So =
what we discussed was mentioning XML (perhaps with examples), =
but
> >> putting that in an appendix and saying the usage is =
historic.  What
> >> this would mean is that the text =
acknowledges that there are servers
> >> that might process =
both XML and JSON, and even older servers that
> >> only =
process XML.  The main body of the document would only =
require
> >> support for JSON from clients and =
servers.
> >>
> >> Before we make these changes =
to the text, I want to seek input from
> >> the group. =
 I believe it would be acceptable, but I do not want those
> =
>> changes to cause significant issues for anyone.
> =
>>
> >> Thanks,
> >> Paul
> =
>>
> >> PS - Please follow-up only on the apps-discuss =
list.
> >>
> >>
> >> =
_______________________________________________
> >> =
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=

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


_______________________________________________
app=
s-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=

 
=
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle =
persone indicate. La diffusione, copia o qualsiasi altra azione =
derivante dalla conoscenza di queste informazioni sono rigorosamente =
vietate. Qualora abbiate ricevuto questo documento per errore siete =
cortesemente pregati di darne immediata comunicazione al mittente e di =
provvedere alla sua distruzione, Grazie. =

=
This e-mail and any attachments=
 is =
confidential and may contain privileged information intended for the =
addressee(s) only. Dissemination, copying, printing or use by anybody =
else is unauthorised. If you are not the intended recipient, please =
delete this message and any attachments and advise the sender by return =
e-mail, Thanks.=
 =

=
3D"rispettaRispetta l'ambiente. Non stampare questa mail se non =E8 =
necessario.=
 
 

------=_NextPart_001_0794_01CD87BE.1FFBBCE0--

------=_NextPart_000_0793_01CD87BE.1FFB95D0
Content-Type: image/gif;
	name="image001.gif"
Content-Transfer-Encoding: base64
Content-ID: 

R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo
8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5
+4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9
p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw
SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0
FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6
YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl
uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds
3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV
OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi
oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn
qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs=

------=_NextPart_000_0793_01CD87BE.1FFB95D0--


From ve7jtb@ve7jtb.com  Fri Aug 31 18:29:54 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E0C21F8469 for ; Fri, 31 Aug 2012 18:29:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.806
X-Spam-Level: 
X-Spam-Status: No, score=-2.806 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fi1CEAJSI-l4 for ; Fri, 31 Aug 2012 18:29:53 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id C0EA721F846C for ; Fri, 31 Aug 2012 18:29:52 -0700 (PDT)
Received: by qadz3 with SMTP id z3so1468877qad.10 for ; Fri, 31 Aug 2012 18:29:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=ahWUvq94JWvA6f2RqS3QFUO//7nBXrFAnG/ZgQe97UU=; b=p4n3qGJsZw2PP9Xf3o+HdZVBcMD7QuI1phYJhQnxz+Xlo3zkBYb4NymimTKJjoP8ft 4Lrx88YPmW7hLE7rkTOuP32nhdOrJ2N00El6JB5yuYZkrNC6l0ksWdBJ68A4ee/8OwpZ gLMXjbplV2dA0QZLd5rox2uPJszK2WHLT8mA84il8LMCWmO4XI9FetDaMeltEcJEesPt bFcX1wpGWyhPyiuw1yyFLyLc4i3GnO1Gpv2YIFPAijebjIuUVB8cQlh1CppHluv0rm0G dxHPe1S9XLUXRv1FY/6e6Tsb3gWBSzA1CbPVsgH6VdsXuV5fhBgPfmUHPVT6Vd3dAdLX dsBw==
Received: by 10.229.136.144 with SMTP id r16mr6076892qct.14.1346462991986; Fri, 31 Aug 2012 18:29:51 -0700 (PDT)
Received: from [192.168.1.39] (190-20-18-54.baf.movistar.cl. [190.20.18.54]) by mx.google.com with ESMTPS id l3sm7557723qan.19.2012.08.31.18.29.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 31 Aug 2012 18:29:50 -0700 (PDT)
References: <010901cd846c$95d74560$c185d020$@packetizer.com> <1346084277.68046.YahooMailNeo@web31802.mail.mud.yahoo.com>   <017001cd849e$cbdd9c90$6398d5b0$@packetizer.com>   <028a01cd854f$c29a86f0$47cf94d0$@packetizer.com> <050232F8-4175-4698-95D7-17E4B35B1210@ve7jtb.com>  <079201cd87df$a70ac4d0$f5204e70$@packetizer.com>
In-Reply-To: <079201cd87df$a70ac4d0$f5204e70$@packetizer.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-CD273604-D8C7-4668-AFE9-4182539C252D; protocol="application/pkcs7-signature"
Message-Id: 
X-Mailer: iPhone Mail (9B206)
From: John Bradley 
Date: Fri, 31 Aug 2012 21:28:24 -0400
To: "Paul E. Jones" 
X-Gm-Message-State: ALoCoQlCvWZRsoi5sIWK6mls1CHoR1BJtqY3m4EKq1wfvgUn+xvg/wTbCqxXRwRbcTG2ngfvujLe
Cc: "" 
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Sep 2012 01:29:54 -0000

--Apple-Mail-CD273604-D8C7-4668-AFE9-4182539C252D
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative;
	boundary=Apple-Mail-E723C79D-44E8-46DC-9FEF-7E2B8A73ACC0


--Apple-Mail-E723C79D-44E8-46DC-9FEF-7E2B8A73ACC0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

JRD is a MUST , XRD and other serializations is a MAY.=20

Sent from my iPhone

On 2012-08-31, at 9:18 PM, "Paul E. Jones"  wrote:

> Walter,
> =20
> I believe the group is leaning toward not having the appendix and merely i=
ndicating that JSON is the only format that is mandatory to implement.  I=E2=
=80=99ll try to re-word it in that way.  In all examples, I will use host-me=
ta.json.  I do think it would be useful to discuss content negotiation.  I=E2=
=80=99ll mention that and provide an example.  Host-meta should support cont=
ent negotiation, in my opinion.  However, since XML might not be implemented=
, a client may get nothing.
> =20
> Making JSON the only MTI format does still give me a feeling of uneasiness=
 since, as you note, every implementation right now is XML.  This will defin=
itely break that.  However, the push has been pretty strong to go in this di=
rection.  My own personal preference still remains that servers implement bo=
th, since it=E2=80=99s so darn simple to do.
> =20
> That said, we would still have a problem with existing servers if they do n=
ot support JSON and a client expected all servers support JSON.  Would peopl=
e feel ok with saying that servers should support both XRD and JRD?  Or is t=
he preference really JRD is MUST and XRD is MAY?
> =20
> Paul
> =20
> From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it]=20
> Sent: Thursday, August 30, 2012 5:55 AM
> To: John Bradley; Paul E. Jones
> Cc: apps-discuss@ietf.org
> Subject: R: [apps-discuss] Proposed changes to WebFinger regarding XML vs J=
SON
> =20
> I am also fine with the json version being privileged in the future.
> However we cannot ignore completely that webfinger XML-based implementatio=
ns already exist (and may not upgrade all together), and we do have already s=
ome text written in the draft so instead of deleting entirely what was writt=
en we could probably find a way to rephrase it to make it optional for serve=
rs to support the xml version (no appendix).
> =20
> BTW as rfc6415 currently says, jrd is returned only in response to host-me=
ta.json endpoint. If only host-meta is queried, negotiation is required usin=
g the accept header. Given the current agreement in the group, is there any c=
hange or clarification expected in the wf draft regarding this? In other wor=
ds, as per current statements both xrd and jrd can already be supported on d=
istinct endpoints, thus simplifying their coexistence. But it seems to me th=
at the group would like some stronger statements towards jrd with no need fo=
r =E2=80=9C.json=E2=80=9D in the endpioint name neither for content negotiat=
ion (but as default content). Am I right?
> =20
> Regards
> walter
> =20
> Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] P=
er conto di John Bradley
> Inviato: marted=C3=AC 28 agosto 2012 21.13
> A: Paul E. Jones
> Cc: apps-discuss@ietf.org
> Oggetto: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs=
 JSON
> =20
> I understand, but I think forcing servers to support both will hurt adopti=
on, though not as much as requiring it on the client.
> =20
> John B.
> =20
> =20
> On 2012-08-28, at 3:03 PM, "Paul E. Jones"  wrote:
> =20
>=20
> John,
> =20
> Previously, JSON and XML were MTI on servers; clients could implement what=
 they want.
> =20
> If we make the proposed change, XML will be dropped on the server side.  T=
he result will be that clients can only rely on JSON support.  XML support m=
ight be rare.
> =20
> Paul
> =20
> PS =E2=80=93 My personal preference is still to require XML and JSON on th=
e server, but I=E2=80=99m willing to give in on this one in order to reach g=
roup consensus.  I think this was the most significant point of contention.
> =20
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
> Sent: Tuesday, August 28, 2012 2:26 PM
> To: Will Norris
> Cc: Paul E. Jones; apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs=
 JSON
> =20
> +1 JSON must be MTI for servers.
> =20
> I am not opposed to servers supporting XML or other formats via content ne=
gotiation,  however clients need to be interoperable with servers using JSON=
, and not forced to support XML for some servers.
> =20
> John B.
> =20
> On 2012-08-27, at 7:13 PM, Will Norris  wrote:
>=20
>=20
>=20
> as one of the editors of said XML format, I'm +1 as well.  The reasons for=
 pushing so heavily for the XML format back then are no longer really true. =
 Instead, all the active work is on JSON-based formats, so it makes sense to=
 update webfinger as well.
>=20
> On Mon, Aug 27, 2012 at 2:56 PM, Paul E. Jones  wro=
te:
> Ok... we could also do that.
>=20
> > -----Original Message-----
> > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.or=
g]
> > On Behalf Of Blaine Cook
> > Sent: Monday, August 27, 2012 12:29 PM
> > To: apps-discuss@ietf.org
> > Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML v=
s
> > JSON
> >
> > +1 to this, and William and Tim's points.
> >
> > On 27 August 2012 18:26, Tim Bray  wrote:
> > > What William said about not needing the appendix. If you=E2=80=99re go=
ing to
> > > go through the pain of abandoning the XML version, why also go through=

> > > the pain of writing an appendix, when there=E2=80=99s a perfectly good=
 RFC in
> > > place to point to.  -T
> > >
> > > On Mon, Aug 27, 2012 at 9:17 AM, William Mills 
> > wrote:
> > >> I think this works in general but that there should be a mention of
> > >> it in the body of the spec citing the appendix.  Do we even need an
> > >> appendix though, we could simply cite 6415 as still normative for the=

> > >> XML stuff but deprecated for new implementations.
> > >>
> > >>
> > >> ________________________________
> > >> From: Paul E. Jones 
> > >> To: apps-discuss@ietf.org
> > >> Cc: jsmarr@google.com; webfinger@googlegroups.com
> > >> Sent: Monday, August 27, 2012 8:56 AM
> > >> Subject: [apps-discuss] Proposed changes to WebFinger regarding XML
> > >> vs JSON
> > >>
> > >> Folks,
> > >>
> > >> Mike, Gonzalo, and I have had some off-list discussions about
> > >> WebFinger and how to resolve the one sticky point that we think has
> > >> caused the most concern.  That point is whether we should we allow bo=
th
> > XML and JSON.
> > >>
> > >> We have heard proposals to "just pick one" and, while I appreciate
> > >> the reasoning, I could not help ignoring that
> > >>
> > >>   1) RFC 6415 exists and describes XML the single mandatory format
> > >>   2) Existing implementations use XML
> > >>
> > >> Nonetheless, I also cannot ignore the long-term value in selecting
> > >> one format we can be sure is widely supported consistently.  I'm
> > >> fairly confident that most want only JSON at this point, even though
> > >> most (if not
> > >> all) current implementations today use XML.  While I'm personally
> > >> favorable to using XML, I know my personal preferences are not
> > >> representative of everyone. :-)
> > >>
> > >> So what we discussed was mentioning XML (perhaps with examples), but
> > >> putting that in an appendix and saying the usage is historic.  What
> > >> this would mean is that the text acknowledges that there are servers
> > >> that might process both XML and JSON, and even older servers that
> > >> only process XML.  The main body of the document would only require
> > >> support for JSON from clients and servers.
> > >>
> > >> Before we make these changes to the text, I want to seek input from
> > >> the group.  I believe it would be acceptable, but I do not want those=

> > >> changes to cause significant issues for anyone.
> > >>
> > >> Thanks,
> > >> Paul
> > >>
> > >> PS - Please follow-up only on the apps-discuss list.
> > >>
> > >>
> > >> _______________________________________________
> > >> 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
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> =20
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pe=
rsone indicate. La diffusione, copia o qualsiasi altra azione derivante dall=
a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbi=
ate ricevuto questo documento per errore siete cortesemente pregati di darne=
 immediata comunicazione al mittente e di provvedere alla sua distruzione, G=
razie.
> This e-mail and any attachments is confidential and may contain privileged=
 information intended for the addressee(s) only. Dissemination, copying, pri=
nting or use by anybody else is unauthorised. If you are not the intended re=
cipient, please delete this message and any attachments and advise the sende=
r by return e-mail, Thanks.
>=20
> Rispetta l'ambiente. Non stampare questa mail se non =C3=A8 n=
ecessario.
> =20

--Apple-Mail-E723C79D-44E8-46DC-9FEF-7E2B8A73ACC0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


JRD is a MUST , XRD and ot=
her serializations is a MAY. 

Sent from my iPhone

=
On 2012-08-31, at 9:18 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:



Walter,
 
I believe the group is leaning toward n=
ot having the appendix and merely indicating that JSON is the only format th=
at is mandatory to implement.  I=E2=80=99ll try to re-word it in that w=
ay.  In all examples, I will use host-meta.json.  I do think it wo=
uld be useful to discuss content negotiation.  I=E2=80=99ll mention tha=
t and provide an example.  Host-meta should support content negotiation=
, in my opinion.  However, since XML might not be implemented, a client=
 may get nothing.
 
Making JSON the only MTI format does still give me a feeling of u=
neasiness since, as you note, every implementation right now is XML.  T=
his will definitely break that.  However, the push has been pretty stro=
ng to go in this direction.  My own personal preference still remains t=
hat servers implement both, since it=E2=80=99s so darn simple to do.
 
That said, w=
e would still have a problem with existing servers if they do not support JS=
ON and a client expected all servers support JSON.  Would people feel o=
k with saying that servers should support both XRD and JRD?  Or i=
s the preference really JRD is MUST and XRD is MAY?
 
Paul
 
From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] 
=
Sent: Thursday, August 30, 2012 5:55 AM
To: John Bradley; Paul=
 E. Jones
Cc: apps-discus=
s@ietf.org
Subject: R: [apps-discuss] Proposed changes to WebFi=
nger regarding XML vs JSON
 
I am also fine with the json version being privileged in the future.
However we c=
annot ignore completely that webfinger XML-based implementations already exi=
st (and may not upgrade all together), and we do have already some text writ=
ten in the draft so instead of deleting entirely what was written we could p=
robably find a way to rephrase it to make it optional for servers to support=
 the xml version (no appendix). 
 
BTW as rfc6415 currently says, jrd is returned o=
nly in response to host-meta.json endpoint. If only host-meta is queried, ne=
gotiation is required using the accept header. Given the current agreement i=
n the group, is there any change or clarification expected in the wf draft r=
egarding this? In other words, as per current statements both xrd and jrd ca=
n already be supported on distinct endpoints, thus simplifying their coexist=
ence. But it seems to me that the group would like some stronger statements t=
owards jrd with no need for =E2=80=9C.json=E2=80=9D in the endpioint name ne=
ither for content negotiation (but as default content). Am I right?
 
Regards<=
/o:p>
walter=

 
Da: apps-dis=
cuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Per conto di John B=
radley
Inviato: marted=C3=AC 28 agosto 2012 21.13
A: Pau=
l E. Jones
Cc: apps-discu=
ss@ietf.org
Oggetto: Re: [apps-discuss] Proposed changes to We=
bFinger regarding XML vs JSON
 
I understand, but I think forcing servers to support bo=
th will hurt adoption, though not as much as requiring it on the client.
 <=
/o:p>
John B.<=
o:p>
&nbs=
p;
=
 
On=
 2012-08-28, at 3:03 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:
&=
nbsp;
John,
 
Previously, JSON and XML were MTI on servers; cl=
ients could implement what they want.
 
If we make the propos=
ed change, XML will be dropped on the server side.  The result will be t=
hat clients can only rely on JSON support.  XML support might be rare.<=
/span>
 
Paul
 
PS =E2=80=93 My personal preference is=
 still to require XML and JSON on the server, but I=E2=80=99m willing to giv=
e in on this one in order to reach group consensus.  I think this was t=
he most significant point of contention.
 
From:=
 John Bradley [mailto:ve7jtb@ve7jtb.com=
] 
Sent: Tuesday, August 28, 2012 2:26=
 PM
To: Will Nor=
ris
Cc: Paul E. J=
ones; apps-discuss@ietf.org
=
Subject: Re: [apps-=
discuss] Proposed changes to WebFinger regarding XML vs JSON
 
+1 JSON must be MTI for servers.
 
I am not opposed to servers supporting XML or=
 other formats via content negotiation,  however clients need to be int=
eroperable with servers using JSON, and not forced to support XML for some s=
ervers.
 
John B.<=
/p>
 
<=
/div>
On 2012-08-27, at 7:13 PM, W=
ill Norris <will@willnorris.com> wrote:
<=
div>


as one of t=
he editors of said XML format, I'm +1 as well.  The reasons for pushing=
 so heavily for the XML format back then are no longer really true.  In=
stead, all the active work is on JSON-based formats, so it makes sense to up=
date webfinger as well.
On Mo=
n, Aug 27, 2012 at 2:56 PM, Paul E. Jones <paulej@packetizer.=
com> wrote:
Ok=
... we could also do that.

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@i=
etf.org]
> On Behalf Of Blaine Cook
> Sent: Monday, A=
ugust 27, 2012 12:29 PM
> To:&nb=
sp;apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Pro=
posed changes to WebFinger regarding XML vs
> JSON
>
> +1 t=
o this, and William and Tim's points.
>
> On 27 August 2012 18:2=
6, Tim Bray <tbray@textuality.com> wrote:
> > What Willia=
m said about not needing the appendix. If you=E2=80=99re going to
> &g=
t; go through the pain of abandoning the XML version, why also go through> > the pain of writing an appendix, when there=E2=80=99s a perfectly=
 good RFC in
> > place to point to.  -T
> >
> &=
gt; On Mon, Aug 27, 2012 at 9:17 AM, William Mills <wmills@yahoo-inc.com<=
/a>>
> wrote:
> >> I think this works in general but th=
at there should be a mention of
> >> it in the body of the spec c=
iting the appendix.  Do we even need an
> >> appendix thoug=
h, we could simply cite 6415 as still normative for the
> >> XML=
 stuff but deprecated for new implementations.
> >>
> >=
>
> >> ________________________________
> >> From:=
 Paul E. Jones <paulej@packetizer.com>
> >> To: apps-discuss@ietf.org
&g=
t; >> Cc: jsmarr@google.com; webfinger@googleg=
roups.com
> >> Sent: Monday, August 27, 2012 8:56 AM<=
br>> >> Subject: [apps-discuss] Proposed changes to WebFinger regar=
ding XML
> >> vs JSON
> >>
> >> Folks,> >>
> >> Mike, Gonzalo, and I have had some off-list=
 discussions about
> >> WebFinger and how to resolve the one sti=
cky point that we think has
> >> caused the most concern.  =
That point is whether we should we allow both
> XML and JSON.
> &=
gt;>
> >> We have heard proposals to "just pick one" and, whi=
le I appreciate
> >> the reasoning, I could not help ignoring th=
at
> >>
> >>   1) RFC 6415 exists and describes=
 XML the single mandatory format
> >>   2) Existing impleme=
ntations use XML
> >>
> >> Nonetheless, I also canno=
t ignore the long-term value in selecting
> >> one format we can=
 be sure is widely supported consistently.  I'm
> >> fairly=
 confident that most want only JSON at this point, even though
> >&=
gt; most (if not
> >> all) current implementations today use XML=
.  While I'm personally
> >> favorable to using XML, I know=
 my personal preferences are not
> >> representative of everyone=
. :-)
> >>
> >> So what we discussed was mentioning X=
ML (perhaps with examples), but
> >> putting that in an appendix=
 and saying the usage is historic.  What
> >> this would me=
an is that the text acknowledges that there are servers
> >> tha=
t might process both XML and JSON, and even older servers that
> >&=
gt; only process XML.  The main body of the document would only require=

> >> support for JSON from clients and servers.
> >>=
;
> >> Before we make these changes to the text, I want to seek i=
nput from
> >> the group.  I believe it would be acceptable=
, but I do not want those
> >> changes to cause significant issu=
es for anyone.
> >>
> >> Thanks,
> >> Pa=
ul
> >>
> >> PS - Please follow-up only on the apps-=
discuss list.
> >>
> >>
> >> ___________=
____________________________________
> >> apps-discuss mailing l=
ist
> >> apps-discus=
s@ietf.org
> >>=
 https://www.ietf.org/mailman/l=
istinfo/apps-discuss
> >>
> >>
> &g=
t;>
> >> _______________________________________________
&=
gt; >> apps-discuss mailing list
> >> apps-discuss@ietf.org
> >> https://www.ietf.org/mailman/listinfo/apps-discuss
> &=
gt;>
> > _______________________________________________
>=
 > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://w=
ww.ietf.org/mailman/listinfo/apps-discuss
> _______________=
________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org<=
br>> https://www.ietf.org/mailman/listinfo/apps-discuss=


_______________________________________________
apps-discuss mail=
ing 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
 
Questo messaggio=
 e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La=
 diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di qu=
este informazioni sono rigorosamente vietate. Qualora abbiate ricevuto quest=
o documento per errore siete cortesemente pregati di darne immediata comunic=
azione al mittente e di provvedere alla sua distruzione, Grazie. 
 is <=
span class=3D"msonormal0">confident=
ial and may contain privileged information intended for the addressee(s) onl=
y. Dissemination, copying, printing or use by anybody else is unauthorised. I=
f you are not the intended recipient, please delete this message and any att=
achments and advise the sender by return e-mail, Thanks. 
<image001.gif>Rispetta l=
'ambiente. Non stampare questa mail se non =C3=A8 necessario. 
 
On Fri, Aug 31, 2012 at 1:33 PM, James M=
 Snell <jasnell@gmail.com> wrote:

One of the key problems with all of th=
is is that it really does not account for the fundamental use case of WebFi=
nger: discovering which services and data are available for a given user wi=
thin a given domain.


I agree with your definition of the "fundamental use case for Web=
Finger" only until you write "within a given domain." Includ=
ing that seemingly minor flourish at the end of the definition drastically =
changes what *i* think is the fundamental use case for WebFinger.



The "within a given domain" seems to imply th=
at any domain that provides service to a user would be able to acknowledge =
that fact and perhaps provide, in response to queries, some information abo=
ut the user. Thus, your definition seems to cast WebFinger as a tool to ena=
ble services to talk about their users.



But, I view the value and use of WebFinger very differe=
ntly. To me WebFinger isn't something that allows services to talk abou=
t users, but rather a tool to enable users to usefully describe themselves =
and the services that can or should be used to interact with them.



I might use dozens of services, but I expect that only =
one of those services, my chosen WebFinger provider, would ever provide any=
 metadata concerning me. The only exception to this is that I may chose to =
allow some or all of the non-WebFinger services that I use to provide a lin=
k to my chosen WebFinger service -- by providing an acct: URI that I have p=
rovided.



You say: "In order for WebFinger to be useful,... the domain owne=
r is going to have to provide the information about its users."=
 I don't think this is right. I suggest that "In order for WebFing=
er to be useful, then users are going to have to provide WebFinger w=
ith information about themselves.



I may choose to use "=
gmail.com" as my email provider. However, even if I do, I should b=
e free to use "example.com" to=
 host my WebFinger acct: URI. Simply because you have discovered my email a=
ddress shouldn't allow you to discover my acct: URI, or anything else a=
bout me, unless I've explicitly chosen to allow that. Also, I shouldn&#=
39;t be required to receive *any* service other than WebFinger from my WebF=
inger provider. (In fact, I can see that being a WebFinger provider would m=
ake a nice business for some folk.) What this means is that if some email p=
rovider has things set up so that I can't use them as a WebFinger host,=
 I'm simply going to get that service from somewhere else. I'll the=
n identify myself to people using my acct: URI and will switch my email acc=
ount around based on who gives me the best service today. I won't be pi=
nned to an email service simply because some people think it is part of my =
"name." (Note: Email providers would be well advised to provide g=
ood WebFinger services if they wish to remain competitive.)



Given the above, it makes sense to me that the simplest=
 implementation of WebFinger should require no more of me other than creati=
ng an XML or JSON encoded file (I don't care which) and causing that fi=
le to appear in some known, HTTP-accessible, location on the web. If one or=
 more of the services I currently use can't or won't allow that, th=
en too bad for them. I'll host my WebFinger data somewhere else.



In summary: WebFinger is supposed to be about users pro=
viding information about themselves, not about services providing informati=
on about their users.

bob wyman




 Google, for instance, may host the email, but the users blog=
, calendar, or other services may have nothing to do with google. In fact, =
Google may not know *anything* about domains users and would therefore be g=
enerally incapable of providing useful information. In order for WebFinger =
to be useful, even with a DNS based bootstrap, the domain owner is going to=
 have to provide the information about its users.




If the domain owner wishes to provide webfinger serv=
ices, but defer that back to a google hosted service, the domain host shoul=
d manage /.well-known/* itself and provide a reasonable http redirect back =
to the google hosted service. Then, the domain owner would need to work wit=
h google to ensure that the information served up is useful (even then, how=
ever, it would likely be just as easy for the domain owner to host everythi=
ng themselves).





Referring back to my index draft [1].. it could=
 look something like...





 GET /.well-known/index/\
    53ae56=
ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255/\




    calendar





 HTTP/1.1 302 Found




 Location: https://webfinger.google.com/example.org/\

    53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d=
9255/\



    calendar






- James
On Wed, Aug 29, 2012 at 10:57=
 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:




I am not the best person to represent Google's nee=
ds.


However as I understand it Google hosts applications such as=
 email documents openID for tens of thousands of domains.



Google themselves don't control the DNS.

=
The people using the service generally add some MX records for aspmx.l.google.com. and a C=
name for mail.example=
.com to=A0ghs.googl=
e.com.





The A record for the bare domain typically points off t=
o some Content management site the company uses for their web pages.
<=
div>
I think this is probably typical of Yahoo's mail hos=
ting services and others. =A0=A0





The service hosing the email/authentication/openID is n=
ot the one that controls the web server for company.

Saying the CMS venders will provide WebFinger services doesn't seem =
all that likely, especially in virtual hosting environments.





Getting a typical company to do anything more than ente=
r a cname for we=
bfinger.example.org is wildly optimistic.

I am=
 entirely open to Ideas on this. =A0 However the previous solution of havin=
g every RP check with google first to see if they host the email and provid=
e the XRDS seems horribly flawed to me.





I would like to see a workable solution at the discover=
y layer that accommodates how people deploy there sites.

I think Bill suggested at one point using the MX record to find the =
webfinger host. =A0That has a bunch of problems I would prefer to avoid.




John B.

On 2012-08-29=
, at 1:36 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:







John,



=A0
Well, we need to fig=
ure out how to address this.




=A0



Would it be reasonable to redirect requests from /.well-known/host-=
meta.json and /.well-known/host-meta to Google?




=A0



Are there other services or files under /.well-known that Google=92=
s customers would not want Google to host?=A0 If they were OK with Google=
=92s servers responding to anything , then one could put an A (or CNAME) re=
cord in place for=A0example.com=A0that points to Google.




=A0



Not being familiar with what Google offers, I=92m a bit challenged =
to understand exactly what is and is not possible.



=A0



Paul
=A0=









From:=A0John Bradley [mailto:ve7jtb@ve7jtb.com]=A0



Sent:=A0Wednesday, August 29, 2012 10:14 AM
To:=A0Paul E. Jones
Cc:=A0'George Fl=
etcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
S=
ubject:=A0Re: [apps-discuss] Looking at Webfinger




=A0



There mite be a A record but that typically goes off to some virtual web ho=
sting company and not the email service provider.
<=
div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times =
New Roman',serif">


=A0
I think I have als=
o heard William say this is a problem for Yahoo.





=A0



Google was not able to get people to deploy XRDS for hosted domains. =A0 Th=
ey came up with a proprietary extension to openID discovery to make hosted =
google apps domains work with some subset of RP.




=A0



The problem is that the company hosting a small businesses website is unlik=
ely to provide the web finger infrastructure and there is no way for the em=
ail/openID provider to do it without their cooperation.




=A0



Adding a A record rather than a CNAME is generally not a good idea if it ca=
n be avoided. =A0 In the event of the provider changing an IP address it br=
eaks all the customers if they have used A records, but that is separate is=
sue. =A0




=A0



You can set up webfinger on your web server and manage it. =A0 It just won&=
#39;t work for large numbers of people as we have it now. =A0=




=A0
If webfinger won&#=
39;t work for Google Apps for Domains and other hosted services like that t=
hen It will significantly impact adoption in my opinion.



=A0



We will also need to work around that for Connect. =A0We don't want ano=
ther proprietary work around with the security problems that can entail.=




=A0
John B.<=
/u>



=A0
On 2012-08-28, at 1=
1:37 PM, "Paul E. Jones" <pau=
lej@packetizer.com> wrote:









John,


=A0


If Google is hosting the domain o=
r any other service provider, wouldn=92t there still be an A record for the=
 domain (e.g.,packet=
izer.com)?=A0 I know there is for virtually every web hosting co=
mpany I=92ve used.=A0 It seems like this might just be one more hosted serv=
ice Google could provide to its customers, no?




=A0




I do not know exactly how this hosted s=
ervice works, but what=92s hosted?=A0 I assume it=92s just email.=A0 If web=
, then I see no issue.=A0 If only email, then the user just needs to have M=
X records pointing to Google and an A record pointing to whatever service r=
uns the WebFinger service.




=A0




In any case, if they can add a CNAME or=
 MX record, I think we can get them to add an A record.=A0 I think it would=
 be far more challenging for SMBs to add a host like=A0webfinger.example.co=
m.=A0 That would still require an A record and a service provide=
r capable of supporting it.




=A0




Paul




=A0




=
From:=A0Joh=
n Bradley [mailto:ve7jtb@<=
a href=3D"http://ve7jtb.com" style=3D"color:purple;text-decoration:underlin=
e" target=3D"_blank">ve7jtb.com]=A0



Sent:=A0Tuesday, August 28, 2012 3:29 PM
To:<=
span>=A0Paul E. Jones
Cc:=A0'George Fletc=
her'; 'Mark Nottingham'; 'IETF Apps Discuss'
Subj=
ect:=A0Re: [apps-discuss] Looking at Webfinger




=A0
<=
div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times =
New Roman',serif">


There are cases where there are hosted domains (Google etc) that may not ha=
ve a http host for the domain name used in the users email address. =A0<=
/u>



=A0
There may be merit=
 to having a=A0webfinger.example.com=A0fallback =
where the client can't reach the .well-known for the primary host.




=A0



I know that some sort of SRV record would be the correct way to do it, but =
in the real world SMB don't enter SRV records even if there DNS provide=
r support them.



The most you can get them to do is add a CNAME or MX record.<=
/div>
=A0



Supporting these sorts of domains somehow is a important issue.
=A0




John B.



=A0
On 2012-08-28=
, at 3:17 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:<=
u>










George,



=A0
I believe it might be useful to introduce those who break your WebFing=
er server to Louisville Slugger. :)




=A0




Your pain is understood, but I do not s=
ee a way to avoid it.=A0 We could introduce something in DNS, but that woul=
d also present challenges.=A0 No matter where we =93root=94 the discovery p=
rocess, there is a potential somebody could break it.=A0 It could be rooted=
 somewhere other than the root of the domain (e.g.,=A0webfinger.example.co=
m), but we either need to decide in advance of such a location o=
r introduce a way to discovery the discovery resources.




=A0




Do you have a suggestion that would mak=
e this less likely to be broken?




=A0




Paul




=A0




=
From:=A0apps-dis=
cuss-bounces@ietf.org=A0[mailto:apps-discuss-bounces@ietf.org]=A0=
On Behalf Of=A0George Fletcher



Sent:=A0Tuesday, August 28, 2012 11:09 AM
To:=
=A0Mark Nottingham
Cc:=A0IETF Apps Disc=
uss
Subject:=A0Re: [apps-discuss] Looking at Webfing=
er




=A0



Way "late to the part=
y" but I can speak from experience that deployment can be a real issue=
 in some environments. It's all really straight forward in a small comp=
any or an environment where the identity team "owns" the root dom=
ain (e.g.=A0example.com). However, if an entire other group in a large org=
anization "owns" the root domain (home page for the site) and the=
 identity team then needs to get them to make changes, the deployment solut=
ion gets brittle pretty quick. I've had our webfinger support broken at=
 least twice because the "other" team didn't know that certai=
n configs were required:)




Also, installing the "dynamic pluming" can be more problemati=
c is these cases. It is possible to get apache rewrite rules or netscaler m=
agic in place to make it work, it's just a more brittle deployment arch=
itecture.




Thanks,
George
O=
n 7/4/12 6:58 PM, John Panzer wrote:




Mark -- Of course I was speaking about practica=
l realities of typical web server administration and deployment. =A0In prac=
tical terms, adding a new mod_rewrite rule or moral equivalent is going to =
be easier than adding a new PHP script that connects to a database. =A0The =
latter is just always going to be a much higher bar.




=A0



And, something that returns per-user data is generally going to need a dyna=
mic service of some kind, unless your site has just a handful of users and =
you don't mind going through a publishing exercise each time you add or=
 change a user...




=A0



None of this has anything to do with the interface, just deployment realiti=
es. =A0And in reality all of this is going to need a dynamic service somewh=
ere for each non-trivial site, this is all just a question of how to hook i=
t up.








--
John Panzer / Google
jpanzer@google.com=A0/=A0abstra=
ctioneer.org=A0/ @jpanzer




=A0



=A0
On Wed, Jul 4, 2012 a=
t 3:36 PM, Mark Nottingham <mnot@mnot.net> wrote:




On 05/07/2012, at 8:16 AM, =
John Panzer wrote:

> Just as a historical note. =A0The envisioned=
 usage of host-meta was originally to avoid a specification which mandated =
a particular dynamic URL API at a particular /.well-known endpoint (because=
 it may not be feasible to do that across all organizations and deployments=
). =A0The host-meta document itself would be highly cacheable and so wouldn=
't incur an additional network trip in the common case.



>
> Having a 3xx redirect is a reasonable alternative that allows =
a similar escape hatch via something like mod_rewrite, albeit at the cost o=
f needing an additional network trip each time. =A0Since a deployment can a=
lways avoid the 3xx redirect with additional dynamic plumbing behind the we=
ll-known endpoint, I don't think that's a horrible thing.



>
> An application-level redirect would be almost equivalent to an=
 HTTP redirect, but then there are two ways to do the same thing. =A0If _on=
ly_ an application-level redirect is allowed, then you have to have at leas=
t a minimal dynamic service at the well-known endpoint (no more mod_rewrite=
). =A0But the whole reason for this is to avoid the requirement for a dynam=
ic service behind well-known...




"dynamic" and "static"=
; are properties of the implementation, not the interface. HTTP doesn't=
 require that any particular URL be "dynamic"; anything can, with=
 the right metadata, be cached (and indeed, I've cached many, many thin=
gs with the wrong metadata, because of silly site operators and their ideas=
 about "dynamic").




Now, if people want to target a particular implementation that makes it=
 easier to serve a particular style of URL without writing code, fine, but =
let's not confuse things.

E.g., a URL like

http://example.c=
om/.well-known/user/bob




is easy to serve in pretty much any way you like with Apache.

I&=
#39;m also going to push back on the "it may not be feasible to do tha=
t across all organizations and deployments" motivation. This is a race=
 to the bottom. The trick is to make it accessible enough to get sufficient=
 traction to pull everyone along, without pandering to *everyone*'s req=
uirements.




Regards,

--
Mark Nottingham =A0=A0=
http://www.mnot.net/







=
=A0








________________=
_______________________________
apps-discuss mailing list
apps-discuss@ietf.org




https://www.ietf.org/mailman/listinfo/apps-discuss




=A0



_________=
______________________________________
apps-discuss mailing list
apps-discuss@ietf=
.org



https://www.ietf.org/mailman/listinfo/apps-discuss




apps-discuss@iet=
f.org

https://www.ietf.org/mailman/listinfo/apps-discuss





_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/apps-discuss


=

--Apple-Mail-E723C79D-44E8-46DC-9FEF-7E2B8A73ACC0--

--Apple-Mail-CD273604-D8C7-4668-AFE9-4182539C252D
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVvjCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0B
AQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlm
aWNhdGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9MQswCQYD
VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg
Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo
b3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLW
wTYgIiRezul38kMKogZkpMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXW
eUyAN3rfOQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/CJi/6
tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYTKqi5pquDSR3l8u/d
5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNiHzvEvqBTViVsUQn3qqvKv3b9bZvz
ndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMMAv+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu
9ydmDBpI125C4z/eIT574Q1w+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/8
9PrNbpHoNkm+Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3
Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B26Nu/yYwl/WL
3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwIDAQABo4ICUjCCAk4wDAYDVR0T
BAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYEFE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1Ud
HwRdMFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAn
hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAw
ggFMBgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y
Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJt
ZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20p
IEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM
aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGlj
eSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZI
AYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNTTCBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ9GYMNPXQhV59CuzaEE44HF7fpiUF
S5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk
4gNXcGmXCPleWKYK34wGmkUWFjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENN
ZEXO3SipXPJzewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1
ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5LEUTINFInzQpd
n4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYuL6lwhceWD3yJZfWOQ1QOq92l
gDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+PwqyvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVK
t+V9E9e4DGTANtLJL4YSjCMJwRuCO3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsf
vw55qVguucQJAX6Vum0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEk
kyShNOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14xggNsMIIDaAIBATCBkzCBjDELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl
cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl
cm1lZGlhdGUgQ2xpZW50IENBAgIeXDAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA5MDEwMTI5MDJaMCMGCSqGSIb3DQEJBDEWBBQSVpNR
loluGeBf1jptyIE2+jnjsDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG
A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg
U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD
bGllbnQgQ0ECAh5cMIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDANBgkqhkiG9w0BAQEFAASCAQCVtmhasO28vQAm2MIep+5oOYoE+NKJca9tYZn7
hi7P6M/Ga9VcS9NspinUykPVNrxszKs7QL9yrz/qO3GRqTcXmpZshf3AQhQVCk1bJmaohEeBGm9R
gopG5xAz3ECNB7w61/yOpuO7IyFshrLw/KoUc98LlOJjY4qh6lN/kF/jxUlZtowWXHt2sA4IMkie
DADrtrM/XCRtw89cwv6Uqft+qtwCLPSyAqxcjf9gPNFW0Enl1YPxnr9ASqyHHra9FWOrK+DM0ZSX
M80awuaq9SzfNi+27hfhSi6/UJmmIv0cF8S+7bSmxlUcaK8k8UPt8q8on7s7hvo5U3b+3sUp1Aro
AAAAAAAA
--Apple-Mail-CD273604-D8C7-4668-AFE9-4182539C252D--

From jpanzer@google.com  Fri Aug 31 18:32:03 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917EF11E809A for ; Fri, 31 Aug 2012 18:32:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.954
X-Spam-Level: 
X-Spam-Status: No, score=-102.954 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLb2sH89rpBN for ; Fri, 31 Aug 2012 18:32:00 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A7D7011E8097 for ; Fri, 31 Aug 2012 18:32:00 -0700 (PDT)
Received: by pbbrr4 with SMTP id rr4so5420118pbb.31 for ; Fri, 31 Aug 2012 18:32:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=jvMYF1J8USjY/Ibu79sdU8j6zjs5Ihuf6RziM51tcRM=; b=j+4WNCHlciXpJoHZq9mJq5jtAkZ0mNDhfVBRCaSRsZDpWIv2qPQxZLuBA1OLpS6rxB 8srcnQ7dNsRMqJyR1V4YBYGyLlxUXYGzDe0d8fI8u8espmW8x4gj7b3zjZ8bYGGXjlMR OdS+9nBQi8c/5i9BDU1j6a2Y/ei80Fbg5C4S1OeN+pmY7Ov6wyHBJoG5JDd8sCUeOiXq bRWe3VCIM/BqYRZGvt/LAablL5b9eU9CcTT8xSdokRCPGembONzHDsRju2LW6nXSRiSx odBdilNkp72HAFA89Qgx8sySVZotWAsNVo0oCgXCWI2YSdkpeFuVIEC7rOvMsYh5OhAH rvEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=jvMYF1J8USjY/Ibu79sdU8j6zjs5Ihuf6RziM51tcRM=; b=N+gOVcVDwxjnfm9kwA6ayTcC3g6YUbehlzny1p3zBHGKSCesUPJQCaHN9FTVG4gPz7 9zyYKxqRuaYMu3atQZ/53TbnkFJpuTNZ/TsiVbqzSYhF0WMtEIqgZUCCxZqOFXkkG0YH 1y8TWyIFPMXLLsUFKhDHBGnjqtbV+UuHnovfM+WSUXPC1q/KxbfVCgCuU9pm5Eh+rgrK LZ0i1pYtoRaVKx3CZctxwW2lhXANu+T6vYI4d5azje3mB/vT37OjFUmjMnK0yddG5yC3 nYj/jeMoLn7SYPEMotY/w+ZuswQ+2eXkgVtL6ohbZIQxOSxbAmaqd0oc1Diuo2paQh+q 6Jpw==
Received: by 10.68.213.5 with SMTP id no5mr21282958pbc.24.1346463120259; Fri, 31 Aug 2012 18:32:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.213.5 with SMTP id no5mr21282929pbc.24.1346463119946; Fri, 31 Aug 2012 18:31:59 -0700 (PDT)
Received: by 10.68.218.194 with HTTP; Fri, 31 Aug 2012 18:31:59 -0700 (PDT)
Received: by 10.68.218.194 with HTTP; Fri, 31 Aug 2012 18:31:59 -0700 (PDT)
In-Reply-To: 
References: <010901cd846c$95d74560$c185d020$@packetizer.com> <1346084277.68046.YahooMailNeo@web31802.mail.mud.yahoo.com>   <017001cd849e$cbdd9c90$6398d5b0$@packetizer.com>   <028a01cd854f$c29a86f0$47cf94d0$@packetizer.com> <050232F8-4175-4698-95D7-17E4B35B1210@ve7jtb.com>  <079201cd87df$a70ac4d0$f5204e70$@packetizer.com> 
Date: Fri, 31 Aug 2012 18:31:59 -0700
Message-ID: 
From: John Panzer 
To: John Bradley 
Content-Type: multipart/alternative; boundary=e89a8fb20834f7b24e04c899df15
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQlOho16GmY8yrHqT01m0PsoR8/+hzv8u1ZcNywWA9SEAtGyk/NcCBIYtCxg7nfu5rVubVCvo3QRaQPUrkUKuH+6fkY/ZRS2b6gi7K7kczCT5dMYkwVo4ZqFCURWwkt31Y3GFkMAtWfAHgSwQmuwpujtE0/RtU/KRgks4wuzWCQRUzoG+CFydHGvGf9UJxNNsTHza77x
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Sep 2012 01:32:03 -0000

--e89a8fb20834f7b24e04c899df15
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

+1
On Aug 31, 2012 6:29 PM, "John Bradley"  wrote:

> JRD is a MUST , XRD and other serializations is a MAY.
>
> Sent from my iPhone
>
> On 2012-08-31, at 9:18 PM, "Paul E. Jones"  wrote:
>
> Walter,****
>
> ** **
>
> I believe the group is leaning toward not having the appendix and merely
> indicating that JSON is the only format that is mandatory to implement.
> I=92ll try to re-word it in that way.  In all examples, I will use
> host-meta.json.  I do think it would be useful to discuss content
> negotiation.  I=92ll mention that and provide an example.  Host-meta shou=
ld
> support content negotiation, in my opinion.  However, since XML might not
> be implemented, a client may get nothing.****
>
> ** **
>
> Making JSON the only MTI format does still give me a feeling of uneasines=
s
> since, as you note, every implementation right now is XML.  This will
> definitely break that.  However, the push has been pretty strong to go in
> this direction.  My own personal preference still remains that servers
> implement both, since it=92s so darn simple to do.****
>
> ** **
>
> That said, we would still have a problem with existing servers if they do
> not support JSON and a client expected all servers support JSON.  Would
> people feel ok with saying that servers *should* support both XRD and
> JRD?  Or is the preference really JRD is MUST and XRD is MAY?****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it]
> *Sent:* Thursday, August 30, 2012 5:55 AM
> *To:* John Bradley; Paul E. Jones
> *Cc:* apps-discuss@ietf.org
> *Subject:* R: [apps-discuss] Proposed changes to WebFinger regarding XML
> vs JSON****
>
> ** **
>
> I am also fine with the json version being privileged in the future.****
>
> However we cannot ignore completely that webfinger XML-based
> implementations already exist (and may not upgrade all together), and we =
do
> have already some text written in the draft so instead of deleting entire=
ly
> what was written we could probably find a way to rephrase it to make it
> optional for servers to support the xml version (no appendix). ****
>
> ** **
>
> BTW as rfc6415 currently says, jrd is returned only in response to
> host-meta.json endpoint. If only host-meta is queried, negotiation is
> required using the accept header. Given the current agreement in the grou=
p,
> is there any change or clarification expected in the wf draft regarding
> this? In other words, as per current statements both xrd and jrd can
> already be supported on distinct endpoints, thus simplifying their
> coexistence. But it seems to me that the group would like some stronger
> statements towards jrd with no need for =93.json=94 in the endpioint name
> neither for content negotiation (but as default content). Am I right?****
>
> ** **
>
> Regards****
>
> walter****
>
> ** **
>
> *Da:* apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org=
]
> *Per conto di *John Bradley
> *Inviato:* marted=EC 28 agosto 2012 21.13
> *A:* Paul E. Jones
> *Cc:* apps-discuss@ietf.org
> *Oggetto:* Re: [apps-discuss] Proposed changes to WebFinger regarding XML
> vs JSON****
>
> ** **
>
> I understand, but I think forcing servers to support both will hurt
> adoption, though not as much as requiring it on the client.****
>
> ** **
>
> John B.****
>
> ** **
>
> ** **
>
> On 2012-08-28, at 3:03 PM, "Paul E. Jones"  wrote:=
*
> ***
>
> ** **
>
> John,****
>
>  ****
>
> Previously, JSON and XML were MTI on servers; clients could implement wha=
t
> they want.****
>
>  ****
>
> If we make the proposed change, XML will be dropped on the server side.
> The result will be that clients can only rely on JSON support.  XML suppo=
rt
> might be rare.****
>
>  ****
>
> Paul****
>
>  ****
>
> PS =96 My personal preference is still to require XML and JSON on the
> server, but I=92m willing to give in on this one in order to reach group
> consensus.  I think this was the most significant point of contention.***=
*
>
>  ****
>
> *From:* John Bradley [mailto:ve7jtb@ve7jtb.com]
> *Sent:* Tuesday, August 28, 2012 2:26 PM
> *To:* Will Norris
> *Cc:* Paul E. Jones; apps-discuss@ietf.org
> *Subject:* Re: [apps-discuss] Proposed changes to WebFinger regarding XML
> vs JSON****
>
>  ****
>
> +1 JSON must be MTI for servers.****
>
>  ****
>
> I am not opposed to servers supporting XML or other formats via content
> negotiation,  however clients need to be interoperable with servers using
> JSON, and not forced to support XML for some servers.****
>
>  ****
>
> John B.****
>
>  ****
>
> On 2012-08-27, at 7:13 PM, Will Norris  wrote:****
>
>
>
> ****
>
> as one of the editors of said XML format, I'm +1 as well.  The reasons fo=
r
> pushing so heavily for the XML format back then are no longer really true=
.
>  Instead, all the active work is on JSON-based formats, so it makes sense
> to update webfinger as well.****
>
> On Mon, Aug 27, 2012 at 2:56 PM, Paul E. Jones 
> wrote:****
>
> Ok... we could also do that.****
>
>
> > -----Original Message-----
> > From: apps-discuss-bounces@ietf.org [mailto:
> apps-discuss-bounces@ietf.org]
> > On Behalf Of Blaine Cook
> > Sent: Monday, August 27, 2012 12:29 PM
> > To: apps-discuss@ietf.org
> > Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML
> vs
> > JSON
> >
> > +1 to this, and William and Tim's points.
> >
> > On 27 August 2012 18:26, Tim Bray  wrote:
> > > What William said about not needing the appendix. If you=92re going t=
o
> > > go through the pain of abandoning the XML version, why also go throug=
h
> > > the pain of writing an appendix, when there=92s a perfectly good RFC =
in
> > > place to point to.  -T
> > >
> > > On Mon, Aug 27, 2012 at 9:17 AM, William Mills 
> > wrote:
> > >> I think this works in general but that there should be a mention of
> > >> it in the body of the spec citing the appendix.  Do we even need an
> > >> appendix though, we could simply cite 6415 as still normative for th=
e
> > >> XML stuff but deprecated for new implementations.
> > >>
> > >>
> > >> ________________________________
> > >> From: Paul E. Jones 
> > >> To: apps-discuss@ietf.org
> > >> Cc: jsmarr@google.com; webfinger@googlegroups.com
> > >> Sent: Monday, August 27, 2012 8:56 AM
> > >> Subject: [apps-discuss] Proposed changes to WebFinger regarding XML
> > >> vs JSON
> > >>
> > >> Folks,
> > >>
> > >> Mike, Gonzalo, and I have had some off-list discussions about
> > >> WebFinger and how to resolve the one sticky point that we think has
> > >> caused the most concern.  That point is whether we should we allow
> both
> > XML and JSON.
> > >>
> > >> We have heard proposals to "just pick one" and, while I appreciate
> > >> the reasoning, I could not help ignoring that
> > >>
> > >>   1) RFC 6415 exists and describes XML the single mandatory format
> > >>   2) Existing implementations use XML
> > >>
> > >> Nonetheless, I also cannot ignore the long-term value in selecting
> > >> one format we can be sure is widely supported consistently.  I'm
> > >> fairly confident that most want only JSON at this point, even though
> > >> most (if not
> > >> all) current implementations today use XML.  While I'm personally
> > >> favorable to using XML, I know my personal preferences are not
> > >> representative of everyone. :-)
> > >>
> > >> So what we discussed was mentioning XML (perhaps with examples), but
> > >> putting that in an appendix and saying the usage is historic.  What
> > >> this would mean is that the text acknowledges that there are servers
> > >> that might process both XML and JSON, and even older servers that
> > >> only process XML.  The main body of the document would only require
> > >> support for JSON from clients and servers.
> > >>
> > >> Before we make these changes to the text, I want to seek input from
> > >> the group.  I believe it would be acceptable, but I do not want thos=
e
> > >> changes to cause significant issues for anyone.
> > >>
> > >> Thanks,
> > >> Paul
> > >>
> > >> PS - Please follow-up only on the apps-discuss list.
> > >>
> > >>
> > >> _______________________________________________
> > >> 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
> > _______________________________________________
> > 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****
>
> ** **
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo=
ra
> abbiate ricevuto questo documento per errore siete cortesemente pregati d=
i
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie. ****
>
> *This e-mail and any attachments** is **confidential and may contain
> privileged information intended for the addressee(s) only. Dissemination,
> copying, printing or use by anybody else is unauthorised. If you are not
> the intended recipient, please delete this message and any attachments an=
d
> advise the sender by return e-mail, Thanks.* ****
>
> *Rispetta l'ambiente. Non stampare questa mail se non =E8
> necessario.* ****
>
> ** **
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

--e89a8fb20834f7b24e04c899df15
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


+1


On Aug 31, 2012 6:29 PM, "John Bradley"=
; <ve7jtb@ve7jtb.com> wrote:=



JRD is a MUST , XRD and other serializations =
is a MAY.=A0

Sent from my iPhone

On 2012-08-31, at 9:1=
8 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:




Walter,
=A0=



I believe the group is le=
aning toward not having the appendix and merely indicating that JSON is the=
 only format that is mandatory to implement.=A0 I=92ll try to re-word it in=
 that way.=A0 In all examples, I will use host-meta.json.=A0 I do think it =
would be useful to discuss content negotiation.=A0 I=92ll mention that and =
provide an example.=A0 Host-meta should support content negotiation, in my =
opinion.=A0 However, since XML might not be implemented, a client may get n=
othing.


=A0<=
/p>
Making JSON the only M=
TI format does still give me a feeling of uneasiness since, as you note, ev=
ery implementation right now is XML.=A0 This will definitely break that.=A0=
 However, the push has been pretty strong to go in this direction.=A0 My ow=
n personal preference still remains that servers implement both, since it=
=92s so darn simple to do.


=A0<=
/p>
That said, we would st=
ill have a problem with existing servers if they do not support JSON and a =
client expected all servers support JSON.=A0 Would people feel ok with sayi=
ng that servers should support both XRD and JRD?=A0 Or is the prefer=
ence really JRD is MUST and XRD is MAY?


=A0<=
/p>
Paul


=A0<=
/p>


From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] 
Sent: Thursday, August 30, 2012 5:55 AM
To: John Bradley; =
Paul E. Jones
Cc: apps-discuss@ietf.org
Subject: R: [apps-discuss] =
Proposed changes to WebFinger regarding XML vs JSON

=A0
I am also fine with the json version being p=
rivileged in the future.


However we cannot ignore =
completely that webfinger XML-based implementations already exist (and may =
not upgrade all together), and we do have already some text written in the =
draft so instead of deleting entirely what was written we could probably fi=
nd a way to rephrase it to make it optional for servers to support the xml =
version (no appendix). 


=A0<=
/p>
BTW as rfc6415 current=
ly says, jrd is returned only in response to host-meta.json endpoint. If on=
ly host-meta is queried, negotiation is required using the accept header. G=
iven the current agreement in the group, is there any change or clarificati=
on expected in the wf draft regarding this? In other words, as per current =
statements both xrd and jrd can already be supported on distinct endpoints,=
 thus simplifying their coexistence. But it seems to me that the group woul=
d like some stronger statements towards jrd with no need for =93.json=94 in=
 the endpioint name neither for content negotiation (but as default content=
). Am I right?


=A0<=
/p>
Regards<=
/span>


walter
=A0


Da: apps-discuss-bounces@ietf.org [mailto:apps-dis=
cuss-bounces@ietf.org] Per conto di John Bradley

Inviato: marted=EC 28 agosto 2012 21.13
A: Paul E. JonesCc: app=
s-discuss@ietf.org
Oggetto: Re: [apps-discuss] Proposed chang=
es to WebFinger regarding XML vs JSON


=A0
I understand, but I think fo=
rcing servers to support both will hurt adoption, though not as much as req=
uiring it on the client.


=A0
<=
/div>
John B.
=A0


=A0
<=
div>
On 2012-08-28, at 3:03 PM=
, "Paul E. Jones" <paulej@packetizer.com> wrote:

=A0
John,


=A0<=
/u>
=
Previously, JSON and XML were MTI on servers; clients could implement what =
they want.


=A0<=
/u>
=
If we make the proposed change, XML will be dropped on the server side.=A0 =
The result will be that clients can only rely on JSON support.=A0 XML suppo=
rt might be rare.


=A0<=
/u>
=
Paul


=A0<=
/u>
=
PS =96 My personal preference is still to require XML and JSON on the serve=
r, but I=92m willing to give in on this one in order to reach group consens=
us.=A0 I think this was the most significant point of contention.=



=A0<=
/u>


From:=A0John Bradley [mailto:ve7jtb@ve7jtb.com]=A0

Sent:=A0Tuesday, August 28, 2012 2:26 PM
To:<=
span>=A0Will Norris
Cc:=A0Paul E. Jones; apps-discuss@ietf.or=
g

Subject:=A0Re: [apps-discuss] Proposed changes to WebFi=
nger regarding XML vs JSON
<=
p class=3D"MsoNormal">=A0
+1 JSON must be MTI for servers.


=A0
I am not opposed to servers supporting XML or=
 other formats via content negotiation, =A0however clients need to be inter=
operable with servers using JSON, and not forced to support XML for some se=
rvers.


=A0
John B.
=A0
<=
div>


On 2012-08-27, at 7:13 PM, Will Norris <will@willnorris.com> wrote:
=




as one of the editors of said XML format, I'm +1 as well. =
=A0The reasons for pushing so heavily for the XML format back then are no l=
onger really true. =A0Instead, all the active work is on JSON-based formats=
, so it makes sense to update webfinger as well.


On Mon, Aug 27, 2012 at 2:56 PM, Paul E. J=
ones <paulej@packetizer.com> wrote:=



Ok... we could also do that.

> -----Original Message-=
----
> From:=A0apps-discuss-bounces=
@ietf.org=A0[mailto:apps-discu=
ss-bounces@ietf.org]

> On Behalf Of Blaine Cook
> Sent: Monday, August 27, 2012 12:29 P=
M
> To:=A0apps-discuss@ietf.org<=
br>> Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding=
 XML vs

> JSON
>
> +1 to this, and William and Tim's points.
=
>
> On 27 August 2012 18:26, Tim Bray <tbray@textua=
lity.com> wrote:

> > What William said about not needing the appendix. If you=92re goi=
ng to
> > go through the pain of abandoning the XML version, why a=
lso go through
> > the pain of writing an appendix, when there=92s=
 a perfectly good RFC in

> > place to point to. =A0-T
> >
> > On Mon, Aug 27=
, 2012 at 9:17 AM, William Mills <wmills@yahoo-inc.com>

> wrote:
> >> I think this works in general but that there s=
hould be a mention of
> >> it in the body of the spec citing th=
e appendix. =A0Do we even need an
> >> appendix though, we coul=
d simply cite 6415 as still normative for the

> >> XML stuff but deprecated for new implementations.
> >=
;>
> >>
> >> ________________________________> >> From: Paul E. Jones <paulej@packetizer.com>

> >> To:=A0apps-discuss@ietf.org<=
/a>
> >> Cc:=A0jsmarr@google.com;=A0webfinger@googlegroups.com<=
br>
> >> Sent: Monday, August 27, 2012 8:56 AM
> >> Subjec=
t: [apps-discuss] Proposed changes to WebFinger regarding XML
> >&=
gt; vs JSON
> >>
> >> Folks,
> >>

> >> Mike, Gonzalo, and I have had some off-list discussions about=

> >> WebFinger and how to resolve the one sticky point that we=
 think has
> >> caused the most concern. =A0That point is wheth=
er we should we allow both

> XML and JSON.
> >>
> >> We have heard proposal=
s to "just pick one" and, while I appreciate
> >> the=
 reasoning, I could not help ignoring that
> >>
> >>=
; =A0 1) RFC 6415 exists and describes XML the single mandatory format

> >> =A0 2) Existing implementations use XML
> >>
&=
gt; >> Nonetheless, I also cannot ignore the long-term value in selec=
ting
> >> one format we can be sure is widely supported consist=
ently. =A0I'm

> >> fairly confident that most want only JSON at this point, even=
 though
> >> most (if not
> >> all) current impleme=
ntations today use XML. =A0While I'm personally
> >> favora=
ble to using XML, I know my personal preferences are not

> >> representative of everyone. :-)
> >>
> >=
> So what we discussed was mentioning XML (perhaps with examples), but> >> putting that in an appendix and saying the usage is histori=
c. =A0What

> >> this would mean is that the text acknowledges that there are =
servers
> >> that might process both XML and JSON, and even old=
er servers that
> >> only process XML. =A0The main body of the =
document would only require

> >> support for JSON from clients and servers.
> >>> >> Before we make these changes to the text, I want to seek in=
put from
> >> the group. =A0I believe it would be acceptable, b=
ut I do not want those

> >> changes to cause significant issues for anyone.
> >&=
gt;
> >> Thanks,
> >> Paul
> >>
>=
 >> PS - Please follow-up only on the apps-discuss list.
> >=
>

> >>
> >> ____________________________________________=
___
> >> apps-discuss mailing list
> >>=A0apps-discuss@ietf.org

> >>=A0https://www=
.ietf.org/mailman/listinfo/apps-discuss
> >>
>=
 >>

> >>
> >> ____________________________________________=
___
> >> apps-discuss mailing list
> >>=A0apps-discuss@ietf.org

> >>=A0https://www=
.ietf.org/mailman/listinfo/apps-discuss
> >>
>=
 > _______________________________________________

> > apps-discuss mailing list
> >=A0apps-discuss@ietf.org
> >=A0https://www.ietf.org/mailman/listinfo/apps-discuss

> _______________________________________________
> apps-discuss m=
ailing list
>=A0apps-discuss@ietf.org

>=A0https://www.ietf.org=
/mailman/listinfo/apps-discuss

__________________________=
_____________________

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



_________________________=
______________________
apps-discuss mailing list
apps-di=
scuss@ietf.org

https://www.ietf.org/mailman/listinfo/ap=
ps-discuss
=


=A0
=

=


Questo messaggio e i suoi allegati sono indirizzati esclu=
sivamente alle persone indicate. La diffusione, copia o qualsiasi altra azi=
one derivante dalla conoscenza di queste informazioni sono rigorosamente vi=
etate. Qualora abbiate ricevuto questo documento per errore siete corteseme=
nte pregati di darne immediata comunicazione al mittente e di provvedere al=
la sua distruzione, Grazie. =



This e-mail and any attachments=A0is=A0co=
nfidential and may contain privileged information intended for the addresse=
e(s) only. Dissemination, copying, printing or use by anybody else is unaut=
horised. If you are not the intended recipient, please delete this message =
and any attachments and advise the sender by return e-mail, Thanks.<=
/i> 


<imag=
e001.gif>Rispetta l'ambiente. Non stampare questa mail se non =E8 ne=
cessario. 


=A0

_______________________________________=
________

apps-discuss mailing list

apps-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/apps-discuss




--e89a8fb20834f7b24e04c899df15--

From paulej@packetizer.com  Fri Aug 31 18:49:30 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F5211E808E for ; Fri, 31 Aug 2012 18:49:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Level: 
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.104,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVvG-h3kdMVG for ; Fri, 31 Aug 2012 18:49:27 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7586F11E808D for ; Fri, 31 Aug 2012 18:49:27 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q811nPFZ007702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 Aug 2012 21:49:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1346464165; bh=nMriyxxl3UWHodF3ROTkTAyjg9CAkMSmTef9suKip54=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=YkcRGweDr+NF+Fj9IA6XYyXY5LsssR+cwjWsx0u2JmD1dXn+bWawd1zMrS/NKc5TK TcSXSfadEPKx3Vlvhr8dEz1o1E+CDgnGMWDvJF8c6G4ElBLsatf3LZDKFbT9mvApLw L51QqRUFJl+mzzgo5xSjju+mq7Sz8pXe7i7Pmxck=
From: "Paul E. Jones" 
To: "'James M Snell'" , "'John Bradley'" 
References:  <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com>   <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com>      <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net>  <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com> <032d01cd8597$aac7f740$0057e5c0$@packetizer.com> <046501cd860c$da464420$8ed2cc60$@packe! tizer.com> <287CDD14-DE C2-40AD-AD5D-DC102D5AAAE6@ve7jtb.com> 
In-Reply-To: 
Date: Fri, 31 Aug 2012 21:49:50 -0400
Message-ID: <07b901cd87e4$13a86a30$3af93e90$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_07BA_01CD87C2.8C9A9AC0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFb3Wt68HpLZ7ZyHnoKMrZHlzcyBQH14U4xAZ6Br/cCWNrQtwIOUYf2AgMXr+8B4HmqlgGhGIVxAUAhVLECgOqLOADUaqV0Ain7f7cBffnLSQIkbXUiAp1soAQC/kiSjgGrOFrXAhluBTcDNBPVP5c0VS7g
Content-Language: en-us
Cc: 'Mark Nottingham' , 'IETF Apps Discuss' 
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Sep 2012 01:49:30 -0000

This is a multipart message in MIME format.

------=_NextPart_000_07BA_01CD87C2.8C9A9AC0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

James,

=20

If Google were hosting the domain and wanted to populate WF without the =
domain owner having any input into the contents, you=E2=80=99re entirely =
right.

=20

However, if we step back and look at what RFC 6415 defines with the LRDD =
type, this is possible.  Then the domain owner might just be able to =
have a static file that contained things like this:

=20

     

=20

     

=20

When utilizing the =E2=80=9Cresource=E2=80=9D parameter, the expectation =
is that the software running on the domain would query Google and =
=E2=80=9Canotherprovider=E2=80=9D and then merge the resulting set of =
link relations and return that to the client.

=20

This would address the issue where Google provides some services and =
other companies provide other services.

=20

The domain owner could outsource all of this to a third party using =
either a 302 or, as Patrik suggested, using a URI DNS record.  I like =
the URI resource record idea, as that would address issues where the =
domain owner cannot provide any services from .well-known, even a 302 =
redirect.  (That said, it amazes me that one could not do return a 302.  =
There really are such domain owners?)

=20

Paul

=20

From: James M Snell [mailto:jasnell@gmail.com]=20
Sent: Friday, August 31, 2012 1:33 PM
To: John Bradley
Cc: Paul E. Jones; Mark Nottingham; IETF Apps Discuss
Subject: Re: [apps-discuss] Looking at Webfinger

=20

One of the key problems with all of this is that it really does not =
account for the fundamental use case of WebFinger: discovering which =
services and data are available for a given user within a given domain. =
Google, for instance, may host the email, but the users blog, calendar, =
or other services may have nothing to do with google. In fact, Google =
may not know *anything* about domains users and would therefore be =
generally incapable of providing useful information. In order for =
WebFinger to be useful, even with a DNS based bootstrap, the domain =
owner is going to have to provide the information about its users.

=20

If the domain owner wishes to provide webfinger services, but defer that =
back to a google hosted service, the domain host should manage =
/.well-known/* itself and provide a reasonable http redirect back to the =
google hosted service. Then, the domain owner would need to work with =
google to ensure that the information served up is useful (even then, =
however, it would likely be just as easy for the domain owner to host =
everything themselves).

=20

Referring back to my index draft [1].. it could look something like...

=20

GET /.well-known/index/\

53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255/\

calendar

Host: example.org

=20

HTTP/1.1 302 Found

Location: https://webfinger.google.com/example.org/\ =
=20

53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255/\

calendar

=20

[1] http://www.ietf.org/id/draft-snell-web-index-00.txt

=20

- James

=20

On Wed, Aug 29, 2012 at 10:57 AM, John Bradley  =
wrote:

I am not the best person to represent Google's needs.

=20

However as I understand it Google hosts applications such as email =
documents openID for tens of thousands of domains.

Google themselves don't control the DNS.

=20

The people using the service generally add some MX records for =
aspmx.l.google.com. and a Cname for mail.example.com to ghs.google.com.

=20

The A record for the bare domain typically points off to some Content =
management site the company uses for their web pages.

=20

I think this is probably typical of Yahoo's mail hosting services and =
others.  =20

=20

The service hosing the email/authentication/openID is not the one that =
controls the web server for company.

=20

Saying the CMS venders will provide WebFinger services doesn't seem all =
that likely, especially in virtual hosting environments.

=20

Getting a typical company to do anything more than enter a cname for =
webfinger.example.org is wildly optimistic.

=20

I am entirely open to Ideas on this.   However the previous solution of =
having every RP check with google first to see if they host the email =
and provide the XRDS seems horribly flawed to me.

=20

I would like to see a workable solution at the discovery layer that =
accommodates how people deploy there sites.

=20

I think Bill suggested at one point using the MX record to find the =
webfinger host.  That has a bunch of problems I would prefer to avoid.

=20

John B.

=20

On 2012-08-29, at 1:36 PM, "Paul E. Jones"  =
wrote:





John,

=20

Well, we need to figure out how to address this.

=20

Would it be reasonable to redirect requests from =
/.well-known/host-meta.json and /.well-known/host-meta to Google?

=20

Are there other services or files under /.well-known that =
Google=E2=80=99s customers would not want Google to host?  If they were =
OK with Google=E2=80=99s servers responding to anything , then one could =
put an A (or CNAME) record in place for   =
example.com that points to Google.

=20

Not being familiar with what Google offers, I=E2=80=99m a bit challenged =
to understand exactly what is and is not possible.

=20

Paul

=20

From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
Sent: Wednesday, August 29, 2012 10:14 AM
To: Paul E. Jones
Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
Subject: Re: [apps-discuss] Looking at Webfinger

=20

There mite be a A record but that typically goes off to some virtual web =
hosting company and not the email service provider.

=20

I think I have also heard William say this is a problem for Yahoo.

=20

Google was not able to get people to deploy XRDS for hosted domains.   =
They came up with a proprietary extension to openID discovery to make =
hosted google apps domains work with some subset of RP.

=20

The problem is that the company hosting a small businesses website is =
unlikely to provide the web finger infrastructure and there is no way =
for the email/openID provider to do it without their cooperation.

=20

Adding a A record rather than a CNAME is generally not a good idea if it =
can be avoided.   In the event of the provider changing an IP address it =
breaks all the customers if they have used A records, but that is =
separate issue. =20

=20

You can set up webfinger on your web server and manage it.   It just =
won't work for large numbers of people as we have it now. =20

=20

If webfinger won't work for Google Apps for Domains and other hosted =
services like that then It will significantly impact adoption in my =
opinion.

=20

We will also need to work around that for Connect.  We don't want =
another proprietary work around with the security problems that can =
entail.

=20

John B.

=20

On 2012-08-28, at 11:37 PM, "Paul E. Jones" < =
 paulej@packetizer.com> wrote:

=20

John,

=20

If Google is hosting the domain or any other service provider, =
wouldn=E2=80=99t there still be an A record for the domain (e.g., =
 packetizer.com)?  I know there is for virtually =
every web hosting company I=E2=80=99ve used.  It seems like this might =
just be one more hosted service Google could provide to its customers, =
no?

=20

I do not know exactly how this hosted service works, but what=E2=80=99s =
hosted?  I assume it=E2=80=99s just email.  If web, then I see no issue. =
 If only email, then the user just needs to have MX records pointing to =
Google and an A record pointing to whatever service runs the WebFinger =
service.

=20

In any case, if they can add a CNAME or MX record, I think we can get =
them to add an A record.  I think it would be far more challenging for =
SMBs to add a host like   =
webfinger.example.com.  That would still require an A record and a =
service provider capable of supporting it.

=20

Paul

=20

From: John Bradley [mailto:ve7jtb@  ve7jtb.com]=20
Sent: Tuesday, August 28, 2012 3:29 PM
To: Paul E. Jones
Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
Subject: Re: [apps-discuss] Looking at Webfinger

=20

There are cases where there are hosted domains (Google etc) that may not =
have a http host for the domain name used in the users email address. =20

=20

There may be merit to having a   =
webfinger.example.com fallback where the client can't reach the =
.well-known for the primary host.

=20

I know that some sort of SRV record would be the correct way to do it, =
but in the real world SMB don't enter SRV records even if there DNS =
provider support them.

The most you can get them to do is add a CNAME or MX record.

=20

Supporting these sorts of domains somehow is a important issue.

=20

John B.

=20

On 2012-08-28, at 3:17 PM, "Paul E. Jones" < =
 paulej@packetizer.com> wrote:





George,

=20

I believe it might be useful to introduce those who break your WebFinger =
server to Louisville Slugger. :)

=20

Your pain is understood, but I do not see a way to avoid it.  We could =
introduce something in DNS, but that would also present challenges.  No =
matter where we =E2=80=9Croot=E2=80=9D the discovery process, there is a =
potential somebody could break it.  It could be rooted somewhere other =
than the root of the domain (e.g.,   =
webfinger.example.com), but we either need to decide in advance of such =
a location or introduce a way to discovery the discovery resources.

=20

Do you have a suggestion that would make this less likely to be broken?

=20

Paul

=20

From:   =
apps-discuss-bounces@ietf.org [mailto:apps- =
 discuss-bounces@ietf.org] On Behalf Of =
George Fletcher
Sent: Tuesday, August 28, 2012 11:09 AM
To: Mark Nottingham
Cc: IETF Apps Discuss
Subject: Re: [apps-discuss] Looking at Webfinger

=20

Way "late to the party" but I can speak from experience that deployment =
can be a real issue in some environments. It's all really straight =
forward in a small company or an environment where the identity team =
"owns" the root domain (e.g.   example.com). =
However, if an entire other group in a large organization "owns" the =
root domain (home page for the site) and the identity team then needs to =
get them to make changes, the deployment solution gets brittle pretty =
quick. I've had our webfinger support broken at least twice because the =
"other" team didn't know that certain configs were required:)

Also, installing the "dynamic pluming" can be more problematic is these =
cases. It is possible to get apache rewrite rules or netscaler magic in =
place to make it work, it's just a more brittle deployment architecture.

Thanks,
George

On 7/4/12 6:58 PM, John Panzer wrote:

Mark -- Of course I was speaking about practical realities of typical =
web server administration and deployment.  In practical terms, adding a =
new mod_rewrite rule or moral equivalent is going to be easier than =
adding a new PHP script that connects to a database.  The latter is just =
always going to be a much higher bar.

=20

And, something that returns per-user data is generally going to need a =
dynamic service of some kind, unless your site has just a handful of =
users and you don't mind going through a publishing exercise each time =
you add or change a user...

=20

None of this has anything to do with the interface, just deployment =
realities.  And in reality all of this is going to need a dynamic =
service somewhere for each non-trivial site, this is all just a question =
of how to hook it up.




--
John Panzer / Google
  jpanzer@google.com /  =
 abstractioneer.org / @jpanzer

=20

=20

On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham <  =
mnot@mnot.net> wrote:

On 05/07/2012, at 8:16 AM, John Panzer wrote:

> Just as a historical note.  The envisioned usage of host-meta was =
originally to avoid a specification which mandated a particular dynamic =
URL API at a particular /.well-known endpoint (because it may not be =
feasible to do that across all organizations and deployments).  The =
host-meta document itself would be highly cacheable and so wouldn't =
incur an additional network trip in the common case.
>
> Having a 3xx redirect is a reasonable alternative that allows a =
similar escape hatch via something like mod_rewrite, albeit at the cost =
of needing an additional network trip each time.  Since a deployment can =
always avoid the 3xx redirect with additional dynamic plumbing behind =
the well-known endpoint, I don't think that's a horrible thing.
>
> An application-level redirect would be almost equivalent to an HTTP =
redirect, but then there are two ways to do the same thing.  If _only_ =
an application-level redirect is allowed, then you have to have at least =
a minimal dynamic service at the well-known endpoint (no more =
mod_rewrite).  But the whole reason for this is to avoid the requirement =
for a dynamic service behind well-known...

"dynamic" and "static" are properties of the implementation, not the =
interface. HTTP doesn't require that any particular URL be "dynamic"; =
anything can, with the right metadata, be cached (and indeed, I've =
cached many, many things with the wrong metadata, because of silly site =
operators and their ideas about "dynamic").

Now, if people want to target a particular implementation that makes it =
easier to serve a particular style of URL without writing code, fine, =
but let's not confuse things.

E.g., a URL like

  =
http://example.com/.well-known/user/bob

is easy to serve in pretty much any way you like with Apache.

I'm also going to push back on the "it may not be feasible to do that =
across all organizations and deployments" motivation. This is a race to =
the bottom. The trick is to make it accessible enough to get sufficient =
traction to pull everyone along, without pandering to *everyone*'s =
requirements.

Regards,


--
Mark Nottingham     http://www.mnot.net/





=20







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

=20

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

=20


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

=20


------=_NextPart_000_07BA_01CD87C2.8C9A9AC0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


James,
 
If Google were hosting the domain and wanted to populate WF without =
the domain owner having any input into the contents, you=E2=80=99re =
entirely right.
 
However, if we step back and look at what RFC 6415 defines with the =
LRDD type, this is possible.=C2=A0 Then the domain owner might just be =
able to have a static file that contained things like =
this:
 
=C2=A0=C2=A0=C2=A0=C2=A0 <Link =
rel=3D'lrdd'
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
type=3D'application/xrd+xml'
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
template=3D'http://webfinger.google.com/lrdd?uri=3D{uri}' =
/>
 
=C2=A0=C2=A0=C2=A0=C2=A0 <Link =
rel=3D'lrdd'
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
type=3D'application/xrd+xml'
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
template=3D'http://webfinger.anotherprovider.com/lrdd?uri=3D{uri}' =
/>
 
When utilizing the =E2=80=9Cresource=E2=80=9D parameter, the =
expectation is that the software running on the domain would query =
Google and =E2=80=9Canotherprovider=E2=80=9D and then merge the =
resulting set of link relations and return that to the =
client.
 
This would address the issue where Google provides some services and =
other companies provide other services.
 
The domain owner could outsource all of this to a third party using =
either a 302 or, as Patrik suggested, using a URI DNS record.=C2=A0 I =
like the URI resource record idea, as that would address issues where =
the domain owner cannot provide any services from .well-known, even a =
302 redirect.=C2=A0 (That said, it amazes me that one could not do =
return a 302.=C2=A0 There really are such domain =
owners?)
 
Paul
 
From:=
 =
James M Snell [mailto:jasnell@gmail.com] 
Sent: Friday, August =
31, 2012 1:33 PM
To: John Bradley
Cc: Paul E. Jones; =
Mark Nottingham; IETF Apps Discuss
Subject: Re: [apps-discuss] =
Looking at Webfinger
 
One of the key problems with all of =
this is that it really does not account for the fundamental use case of =
WebFinger: discovering which services and data are available for a given =
user within a given domain. Google, for instance, may host the email, =
but the users blog, calendar, or other services may have nothing to do =
with google. In fact, Google may not know *anything* about domains users =
and would therefore be generally incapable of providing useful =
information. In order for WebFinger to be useful, even with a DNS based =
bootstrap, the domain owner is going to have to provide the information =
about its users.
 
If the =
domain owner wishes to provide webfinger services, but defer that back =
to a google hosted service, the domain host should manage /.well-known/* =
itself and provide a reasonable http redirect back to the google hosted =
service. Then, the domain owner would need to work with google to ensure =
that the information served up is useful (even then, however, it would =
likely be just as easy for the domain owner to host everything =
themselves).
 
Referring =
back to my index draft [1].. it could look something =
like...
 
GET =
/.well-known/index/\
53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255/\<=
/span>
calendar
 
HTTP/1.1 302 =
Found
53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255/\<=
/span>
calendar
 
 
- =
James
 
On Wed, =
Aug 29, 2012 at 10:57 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I am not the best person to represent Google's =
needs.
 
However as I understand it Google hosts applications =
such as email documents openID for tens of thousands of =
domains.
Google themselves =
don't control the DNS.
 
The people using the service generally add some MX =
records for aspmx.l.google.com. and a Cname for mail.example.com =
to ghs.google.com.
 
The A record for the bare domain typically points off =
to some Content management site the company uses for their web =
pages.
 
I =
think this is probably typical of Yahoo's mail hosting services and =
others.   
 
The service hosing the email/authentication/openID is =
not the one that controls the web server for =
company.
 
Saying the CMS venders will provide WebFinger services =
doesn't seem all that likely, especially in virtual hosting =
environments.
 
Getting a typical company to do anything more than =
enter a cname for webfinger.example.org is wildly =
optimistic.
 
I =
am entirely open to Ideas on this.   However the previous solution =
of having every RP check with google first to see if they host the email =
and provide the XRDS seems horribly flawed to =
me.
 
I =
would like to see a workable solution at the discovery layer that =
accommodates how people deploy there sites.
 
I =
think Bill suggested at one point using the MX record to find the =
webfinger host.  That has a bunch of problems I would prefer to =
avoid.
 
John B.
 
On =
2012-08-29, at 1:36 PM, "Paul E. Jones" <paulej@packetizer.com> =
wrote:


John,
 
Well, we need to figure out how to address =
this.
 
Would it be reasonable to redirect requests from =
/.well-known/host-meta.json and /.well-known/host-meta to =
Google?
 
Are there other services or files under /.well-known that =
Google=E2=80=99s customers would not want Google to host?  If they =
were OK with Google=E2=80=99s servers responding to anything , then one =
could put an A (or CNAME) record in place for example.com that points to =
Google.
 
Not being familiar with what Google offers, I=E2=80=99m a bit =
challenged to understand exactly what is and is not =
possible.
 
Paul
 
From:=
 John =
Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, =
August 29, 2012 10:14 AM
To: Paul E. =
Jones
Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF =
Apps Discuss'
Subject: Re: [apps-discuss] Looking at =
Webfinger
 
There mite be a A record but that typically goes off =
to some virtual web hosting company and not the email service =
provider.
 
I think I have also heard William say this is a =
problem for Yahoo.
 
Google was not able to get people to deploy XRDS for =
hosted domains.   They came up with a proprietary extension to =
openID discovery to make hosted google apps domains work with some =
subset of RP.
 
The problem is that the company hosting a small =
businesses website is unlikely to provide the web finger infrastructure =
and there is no way for the email/openID provider to do it without their =
cooperation.
 
Adding a A record rather than a CNAME is generally not =
a good idea if it can be avoided.   In the event of the provider =
changing an IP address it breaks all the customers if they have used A =
records, but that is separate issue. =
 
 
You can set up webfinger on your web server and manage =
it.   It just won't work for large numbers of people as we have it =
now.  
 
If webfinger won't work for Google Apps for Domains =
and other hosted services like that then It will significantly impact =
adoption in my opinion.
 
We will also need to work around that for Connect. =
 We don't want another proprietary work around with the security =
problems that can entail.
 
John B.
 
On 2012-08-28, at 11:37 PM, "Paul E. Jones" =
<paulej@packetizer.com> =
wrote:
 
=

John,
 
If Google is hosting the domain or any other service provider, =
wouldn=E2=80=99t there still be an A record for the domain (e.g.,packetizer.com)?  I know there is =
for virtually every web hosting company I=E2=80=99ve used.  It =
seems like this might just be one more hosted service Google could =
provide to its customers, =
no?
 
I do not know exactly how this hosted service works, but =
what=E2=80=99s hosted?  I assume it=E2=80=99s just email.  If =
web, then I see no issue.  If only email, then the user just needs =
to have MX records pointing to Google and an A record pointing to =
whatever service runs the WebFinger =
service.
 
In any case, if they can add a CNAME or MX record, I think we can get =
them to add an A record.  I think it would be far more challenging =
for SMBs to add a host like webfinger.example.com.  That =
would still require an A record and a service provider capable of =
supporting it.
 
Paul
 
From:=
 John =
Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: =
Tuesday, August 28, 2012 3:29 PM
To: Paul E. =
Jones
Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF =
Apps Discuss'
Subject: Re: [apps-discuss] Looking at =
Webfinger
 
There are cases where there are hosted domains (Google =
etc) that may not have a http host for the domain name used in the users =
email address.  
 
There may be merit to having a webfinger.example.com fallback =
where the client can't reach the .well-known for the primary =
host.
 
I know that some sort of SRV record would be the =
correct way to do it, but in the real world SMB don't enter SRV records =
even if there DNS provider support =
them.
The most =
you can get them to do is add a CNAME or MX =
record.
 
Supporting these sorts of domains somehow is a =
important issue.
 
John B.
 
On 2012-08-28, at 3:17 PM, "Paul E. Jones" =
<paulej@packetizer.com> =
wrote:


George,
 
I believe it might be useful to introduce those who break your =
WebFinger server to Louisville Slugger. =
:)
 
Your pain is understood, but I do not see a way to avoid it.  We =
could introduce something in DNS, but that would also present =
challenges.  No matter where we =E2=80=9Croot=E2=80=9D the =
discovery process, there is a potential somebody could break it.  =
It could be rooted somewhere other than the root of the domain =
(e.g., webfinger.example.com), but we either =
need to decide in advance of such a location or introduce a way to =
discovery the discovery =
resources.
 
Do you have a suggestion that would make this less likely to be =
broken?
 
Paul
 
From:=
 apps-discuss-bounces@ietf.org [mai=
lto:apps-discuss-bounces@ietf.org] On =
Behalf Of George Fletcher
Sent: Tuesday, August =
28, 2012 11:09 AM
To: Mark =
Nottingham
Cc: IETF Apps =
Discuss
Subject: Re: [apps-discuss] Looking at =
Webfinger
 
Way "late to the =
party" but I can speak from experience that deployment can be a =
real issue in some environments. It's all really straight forward in a =
small company or an environment where the identity team "owns" =
the root domain (e.g. example.com). =
However, if an entire other group in a large organization =
"owns" the root domain (home page for the site) and the =
identity team then needs to get them to make changes, the deployment =
solution gets brittle pretty quick. I've had our webfinger support =
broken at least twice because the "other" team didn't know =
that certain configs were required:)

Also, installing the =
"dynamic pluming" can be more problematic is these cases. It =
is possible to get apache rewrite rules or netscaler magic in place to =
make it work, it's just a more brittle deployment =
architecture.

Thanks,
George
On 7/4/12 6:58 PM, John Panzer =
wrote:
Mark -- Of course I was speaking about practical =
realities of typical web server administration and deployment.  In =
practical terms, adding a new mod_rewrite rule or moral equivalent is =
going to be easier than adding a new PHP script that connects to a =
database.  The latter is just always going to be a much higher =
bar.
 
And, something that returns per-user data is generally =
going to need a dynamic service of some kind, unless your site has just =
a handful of users and you don't mind going through a publishing =
exercise each time you add or change a =
user...
 
None of this has anything to do with the interface, =
just deployment realities.  And in reality all of this is going to =
need a dynamic service somewhere for each non-trivial site, this is all =
just a question of how to hook it =
up.

--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / =
@jpanzer
 
 
On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham <mnot@mnot.net> =
wrote:
On 05/07/2012, at 8:16 AM, John Panzer =
wrote:

> Just as a historical note.  The envisioned usage =
of host-meta was originally to avoid a specification which mandated a =
particular dynamic URL API at a particular /.well-known endpoint =
(because it may not be feasible to do that across all organizations and =
deployments).  The host-meta document itself would be highly =
cacheable and so wouldn't incur an additional network trip in the common =
case.
>
> Having a 3xx redirect is a reasonable alternative =
that allows a similar escape hatch via something like mod_rewrite, =
albeit at the cost of needing an additional network trip each time. =
 Since a deployment can always avoid the 3xx redirect with =
additional dynamic plumbing behind the well-known endpoint, I don't =
think that's a horrible thing.
>
> An application-level =
redirect would be almost equivalent to an HTTP redirect, but then there =
are two ways to do the same thing.  If _only_ an application-level =
redirect is allowed, then you have to have at least a minimal dynamic =
service at the well-known endpoint (no more mod_rewrite).  But the =
whole reason for this is to avoid the requirement for a dynamic service =
behind well-known...
"dynamic" and "static" are =
properties of the implementation, not the interface. HTTP doesn't =
require that any particular URL be "dynamic"; anything can, =
with the right metadata, be cached (and indeed, I've cached many, many =
things with the wrong metadata, because of silly site operators and =
their ideas about "dynamic").

Now, if people want to =
target a particular implementation that makes it easier to serve a =
particular style of URL without writing code, fine, but let's not =
confuse things.

E.g., a URL like

http://example.com/.well-known/user/bob=


is easy to serve in pretty much any way you like with =
Apache.

I'm also going to push back on the "it may not be =
feasible to do that across all organizations and deployments" =
motivation. This is a race to the bottom. The trick is to make it =
accessible enough to get sufficient traction to pull everyone along, =
without pandering to *everyone*'s =
requirements.

Regards,

--
Mark =
Nottingham   http://www.mnot.net/



 




_______________________________________________
 
 
apps-discuss =
mailing list
apps-discuss@ietf.org
<=
pre>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<=
o:p>
 

------=_NextPart_000_07BA_01CD87C2.8C9A9AC0--


From paulej@packetizer.com  Fri Aug 31 18:54:20 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C25B11E808E for ; Fri, 31 Aug 2012 18:54:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.495
X-Spam-Level: 
X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.103,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjrOokphOoLe for ; Fri, 31 Aug 2012 18:54:18 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6832D11E808D for ; Fri, 31 Aug 2012 18:54:18 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q811sHCH007871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 Aug 2012 21:54:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1346464457; bh=L9OMGQRAiJCLotaxUogce9sZmuEL05oQVNDi228JXN4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=bHNVoIPoqCo3NDPufwlacizYM6M838gpzIH+YYbXL0KkdwN41WSuMeWp1AgvyZzqO 4e2qYmr3nO2NiAjjxwFn355LPSPsWggmelD+UwlYIhmQYJOk/WSZfDZmVgkdlgJbH6 ZcvCdPn+uaCj51TI7kXOMGrLFGdmLUkbahxzNbGw=
From: "Paul E. Jones" 
To: "'John Bradley'" 
References: <010901cd846c$95d74560$c185d020$@packetizer.com> <1346084277.68046.YahooMailNeo@web31802.mail.mud.yahoo.com>   <017001cd849e$cbdd9c90$6398d5b0$@packetizer.com>   <028a01cd854f$c29a86f0$47cf94d0$@packetizer.com> <050232F8-4175-4698-95D7-17E4B35B1210@ve7jtb.com>  <079201cd87df$a70ac4d0$f5204e70$@packetizer.com> 
In-Reply-To: 
Date: Fri, 31 Aug 2012 21:54:42 -0400
Message-ID: <07d401cd87e4$c1b26680$45173380$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_07D5_01CD87C3.3AA3ACB0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIrZE+abU/d+x34aW2WxIOtEY8jpwIfXwJkAk1l+2oB11boGgF43hDQAwFsJFECCPyssQCxWdIfAXT4R9oBrFaWjwDfVUxwAkDT7AmWGy8z8A==
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Sep 2012 01:54:20 -0000

This is a multipart message in MIME format.

------=_NextPart_000_07D5_01CD87C3.3AA3ACB0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

OK =E2=80=A6 I=E2=80=99ll word it that way.

=20

From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
Sent: Friday, August 31, 2012 9:28 PM
To: Paul E. Jones
Cc: Goix Laurent Walter; 
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML =
vs JSON

=20

JRD is a MUST , XRD and other serializations is a MAY.=20

Sent from my iPhone


On 2012-08-31, at 9:18 PM, "Paul E. Jones"  =
wrote:

Walter,

=20

I believe the group is leaning toward not having the appendix and merely =
indicating that JSON is the only format that is mandatory to implement.  =
I=E2=80=99ll try to re-word it in that way.  In all examples, I will use =
host-meta.json.  I do think it would be useful to discuss content =
negotiation.  I=E2=80=99ll mention that and provide an example.  =
Host-meta should support content negotiation, in my opinion.  However, =
since XML might not be implemented, a client may get nothing.

=20

Making JSON the only MTI format does still give me a feeling of =
uneasiness since, as you note, every implementation right now is XML.  =
This will definitely break that.  However, the push has been pretty =
strong to go in this direction.  My own personal preference still =
remains that servers implement both, since it=E2=80=99s so darn simple =
to do.

=20

That said, we would still have a problem with existing servers if they =
do not support JSON and a client expected all servers support JSON.  =
Would people feel ok with saying that servers should support both XRD =
and JRD?  Or is the preference really JRD is MUST and XRD is MAY?

=20

Paul

=20

From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it]=20
Sent: Thursday, August 30, 2012 5:55 AM
To: John Bradley; Paul E. Jones
Cc: apps-discuss@ietf.org
Subject: R: [apps-discuss] Proposed changes to WebFinger regarding XML =
vs JSON

=20

I am also fine with the json version being privileged in the future.

However we cannot ignore completely that webfinger XML-based =
implementations already exist (and may not upgrade all together), and we =
do have already some text written in the draft so instead of deleting =
entirely what was written we could probably find a way to rephrase it to =
make it optional for servers to support the xml version (no appendix).=20

=20

BTW as rfc6415 currently says, jrd is returned only in response to =
host-meta.json endpoint. If only host-meta is queried, negotiation is =
required using the accept header. Given the current agreement in the =
group, is there any change or clarification expected in the wf draft =
regarding this? In other words, as per current statements both xrd and =
jrd can already be supported on distinct endpoints, thus simplifying =
their coexistence. But it seems to me that the group would like some =
stronger statements towards jrd with no need for =E2=80=9C.json=E2=80=9D =
in the endpioint name neither for content negotiation (but as default =
content). Am I right?

=20

Regards

walter

=20

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
Per conto di John Bradley
Inviato: marted=C3=AC 28 agosto 2012 21.13
A: Paul E. Jones
Cc: apps-discuss@ietf.org
Oggetto: Re: [apps-discuss] Proposed changes to WebFinger regarding XML =
vs JSON

=20

I understand, but I think forcing servers to support both will hurt =
adoption, though not as much as requiring it on the client.

=20

John B.

=20

=20

On 2012-08-28, at 3:03 PM, "Paul E. Jones"  =
wrote:

=20

John,

=20

Previously, JSON and XML were MTI on servers; clients could implement =
what they want.

=20

If we make the proposed change, XML will be dropped on the server side.  =
The result will be that clients can only rely on JSON support.  XML =
support might be rare.

=20

Paul

=20

PS =E2=80=93 My personal preference is still to require XML and JSON on =
the server, but I=E2=80=99m willing to give in on this one in order to =
reach group consensus.  I think this was the most significant point of =
contention.

=20

From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
Sent: Tuesday, August 28, 2012 2:26 PM
To: Will Norris
Cc: Paul E. Jones; apps-discuss@ietf.org
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML =
vs JSON

=20

+1 JSON must be MTI for servers.

=20

I am not opposed to servers supporting XML or other formats via content =
negotiation,  however clients need to be interoperable with servers =
using JSON, and not forced to support XML for some servers.

=20

John B.

=20

On 2012-08-27, at 7:13 PM, Will Norris <  =
will@willnorris.com> wrote:






as one of the editors of said XML format, I'm +1 as well.  The reasons =
for pushing so heavily for the XML format back then are no longer really =
true.  Instead, all the active work is on JSON-based formats, so it =
makes sense to update webfinger as well.

On Mon, Aug 27, 2012 at 2:56 PM, Paul E. Jones < =
 paulej@packetizer.com> wrote:

Ok... we could also do that.


> -----Original Message-----
> From:   =
apps-discuss-bounces@ietf.org [mailto: =
 apps-discuss-bounces@ietf.org]
> On Behalf Of Blaine Cook
> Sent: Monday, August 27, 2012 12:29 PM
> To:   apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding =
XML vs
> JSON
>
> +1 to this, and William and Tim's points.
>
> On 27 August 2012 18:26, Tim Bray <  =
tbray@textuality.com> wrote:
> > What William said about not needing the appendix. If you=E2=80=99re =
going to
> > go through the pain of abandoning the XML version, why also go =
through
> > the pain of writing an appendix, when there=E2=80=99s a perfectly =
good RFC in
> > place to point to.  -T
> >
> > On Mon, Aug 27, 2012 at 9:17 AM, William Mills < =
 wmills@yahoo-inc.com>
> wrote:
> >> I think this works in general but that there should be a mention of
> >> it in the body of the spec citing the appendix.  Do we even need an
> >> appendix though, we could simply cite 6415 as still normative for =
the
> >> XML stuff but deprecated for new implementations.
> >>
> >>
> >> ________________________________
> >> From: Paul E. Jones <  =
paulej@packetizer.com>
> >> To:   apps-discuss@ietf.org
> >> Cc:   jsmarr@google.com;  =
 webfinger@googlegroups.com
> >> Sent: Monday, August 27, 2012 8:56 AM
> >> Subject: [apps-discuss] Proposed changes to WebFinger regarding XML
> >> vs JSON
> >>
> >> Folks,
> >>
> >> Mike, Gonzalo, and I have had some off-list discussions about
> >> WebFinger and how to resolve the one sticky point that we think has
> >> caused the most concern.  That point is whether we should we allow =
both
> XML and JSON.
> >>
> >> We have heard proposals to "just pick one" and, while I appreciate
> >> the reasoning, I could not help ignoring that
> >>
> >>   1) RFC 6415 exists and describes XML the single mandatory format
> >>   2) Existing implementations use XML
> >>
> >> Nonetheless, I also cannot ignore the long-term value in selecting
> >> one format we can be sure is widely supported consistently.  I'm
> >> fairly confident that most want only JSON at this point, even =
though
> >> most (if not
> >> all) current implementations today use XML.  While I'm personally
> >> favorable to using XML, I know my personal preferences are not
> >> representative of everyone. :-)
> >>
> >> So what we discussed was mentioning XML (perhaps with examples), =
but
> >> putting that in an appendix and saying the usage is historic.  What
> >> this would mean is that the text acknowledges that there are =
servers
> >> that might process both XML and JSON, and even older servers that
> >> only process XML.  The main body of the document would only require
> >> support for JSON from clients and servers.
> >>
> >> Before we make these changes to the text, I want to seek input from
> >> the group.  I believe it would be acceptable, but I do not want =
those
> >> changes to cause significant issues for anyone.
> >>
> >> Thanks,
> >> Paul
> >>
> >> PS - Please follow-up only on the apps-discuss list.
> >>
> >>
> >> _______________________________________________
> >> 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
> _______________________________________________
> 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

=20


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle =
persone indicate. La diffusione, copia o qualsiasi altra azione =
derivante dalla conoscenza di queste informazioni sono rigorosamente =
vietate. Qualora abbiate ricevuto questo documento per errore siete =
cortesemente pregati di darne immediata comunicazione al mittente e di =
provvedere alla sua distruzione, Grazie.=20

This e-mail and any attachments is confidential and may contain =
privileged information intended for the addressee(s) only. =
Dissemination, copying, printing or use by anybody else is unauthorised. =
If you are not the intended recipient, please delete this message and =
any attachments and advise the sender by return e-mail, Thanks.=20

Rispetta l'ambiente. Non stampare questa mail se non =
=C3=A8 necessario.=20

=20


------=_NextPart_000_07D5_01CD87C3.3AA3ACB0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

   
---368338466-1718545825-1346468242=:11151
Content-Type: image/gif; name="image001.gif"
Content-Transfer-Encoding: base64
Content-Id: <1.549243197@web31801.mail.mud.yahoo.com>

R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo
8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5
+4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9
p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw
SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0
FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6
YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl
uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds
3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV
OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi
oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn
qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs=

---368338466-1718545825-1346468242=:11151--
---368338466-1598384905-1346468242=:11151--

From sakimura@gmail.com  Fri Aug 31 20:19:11 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114AB11E8097 for ; Fri, 31 Aug 2012 20:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.465
X-Spam-Level: 
X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.134,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epuY9xsTzLBN for ; Fri, 31 Aug 2012 20:19:10 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E58CF11E808D for ; Fri, 31 Aug 2012 20:19:09 -0700 (PDT)
Received: by qcac10 with SMTP id c10so2881369qca.31 for ; Fri, 31 Aug 2012 20:19: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:content-transfer-encoding; bh=wL+LhrNwoltjVfpOMx4aNYRc4XJd//roWngLthwjpt0=; b=h1aIXS3DSW6eeDBWLp8Ow/mtUGVHjDj8jR87J09ENHEhmVCigbmePn9pGc/WwpqcAo zdAos0/0iG0K12ZtEyyr6AOw++6Pbw0uHmulDmzQvVyvlbPqk3TiC4mn67MOpQR7qO+Q Bqf64fRCfT+fzUtOGTRzDW0G/OF3UB+a20KkLosyB1/wxitXufK/Y6O/fOef1Dgi2eRc 9EZtpob8/spkoaT06COGtn61IPJg0oMZPdnqHTKPWbmLLHQLFgJKTGujGoBpw7TpV42a VQeI2UpWUHSjd9RwpOB3o6fVvmRj+crr8mN+6aQRcBozTdvfFb6aruoHGOTJZ8LFof8/ Ty5Q==
MIME-Version: 1.0
Received: by 10.229.135.12 with SMTP id l12mr6132817qct.111.1346469548684; Fri, 31 Aug 2012 20:19:08 -0700 (PDT)
Received: by 10.49.94.115 with HTTP; Fri, 31 Aug 2012 20:19:08 -0700 (PDT)
In-Reply-To: <251A4741-1E52-41D3-B4C8-43BEDE5C79B7@ve7jtb.com>
References:  <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com>   <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com>      <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net>  <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com> <032d01cd8597$aac7f740$0057e5c0$@packetizer.com>  <04f001cd8627$092727e0$1b7577a0$@packetizer.com> <90420743-8FE8-4EDB-98EF-D717D5346397@frobbit.se> <1346306587.53748.YahooMailNeo@web31804.mail.mud.yahoo.com>  <251A4741-1E52-41D3-B4C8-43BEDE5C79B7@ve7jtb.com>
Date: Sat, 1 Sep 2012 12:19:08 +0900
Message-ID: 
From: Nat Sakimura 
To: John Bradley 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: Mark Nottingham , IETF Apps Discuss 
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Sep 2012 03:19:11 -0000

I think it is not the problem of the clients. Any decent scripting
language has the ability to query SRV records in DNS.

It is the problem of the DNS service provider, which always have GUI
for A and CNAME records but not necessarily TXT or SRV records.

Having said that, have we done the reality check on the above claim
that those providers do not support them? Quick check reveals the
following about top domain registrar's support SRV records (market
share is from http://collegefallout.com/list-of-top-10-domain-name-registra=
rs/
which may not be correct) :

- Regstrar Name (market share) Support of SRV record

- GoDaddy (31%)YES
- enom.com (8.5%) YES
- TuCows (6.6%) ???
- NetworkSolutions (5.4%) YES
- Schlund+Partner (4.3%) NO
- melbourneit (3.6%) NO
- Wild West Domains (2.8%) YES
- moniker.com (2.4%) ???
- ResellerClub (2.2%) YES
- REGISTER.com (2.0%) YES

It is actually better than I thought. The world may be changing...

Nat


On Fri, Aug 31, 2012 at 6:00 AM, John Bradley  wrote:
> I agree that doing it via DNS would be the proper way.
>
> The reality is that not all clients can easily access DNS directly.  Doin=
g anything more than a http get reduces adoption.
>
> Not all DNS providers support srv records.  I think your draft on DNS rec=
ords has expired, and I know of no support for it.
> http://tools.ietf.org/html/draft-faltstrom-uri-06
>
> Something like DNS records would be the answer, I just don't think protoc=
ols like Webfinger are likely to wait for wide deployment of that as a unde=
rlying technology.
>
> John B.
> On 2012-08-30, at 2:44 AM, Patrik F=E4ltstr=F6m  wrote:
>
>> First, I did not talk about SRV records, but URI records.
>>
>> Secondly, I think it is fascinating that people that love new things lik=
e "the web" and new HTML5 features are the most conservative ones regarding=
 other protocols like DNS.
>>
>> With that attitude, we have no evolution, and no innovation.
>>
>> Providers that do not support such features will die. It is that simple.
>>
>>   Patrik
>>
>> On 30 aug 2012, at 08:03, William Mills  wrote:
>>
>>> There are a few folks that feel that SRV records are not really an opti=
on for hosting situatiosn where the users don't currently have the ability =
to configure SRV records.
>>>
>>> From: Patrik F=E4ltstr=F6m 
>>> To: Paul E. Jones 
>>> Cc: 'Mark Nottingham' ; 'IETF Apps Discuss' 
>>> Sent: Wednesday, August 29, 2012 8:01 PM
>>> Subject: Re: [apps-discuss] Looking at Webfinger
>>>
>>> On 29 aug 2012, at 22:44, Paul E. Jones  wrote:
>>>
>>>> 1) TXT records (e.g., _webfinger.packetizer.com IN TXT =93https://pack=
etizer.webfinger-provider.com/=94)
>>>
>>> Please see URI Resource Record, for example:
>>>
>>> _webfinger._tcp.packetizer.com. IN URI 0 0 =93https://packetizer.webfin=
ger-provider.com/=94
>>>
>>>  Patrik
>>>
>>> _______________________________________________
>>> 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
>



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

From sakimura@gmail.com  Fri Aug 31 22:39:27 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5DD21F845C for ; Fri, 31 Aug 2012 22:39:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.471
X-Spam-Level: 
X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.128,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-YNN+3tPZOm for ; Fri, 31 Aug 2012 22:39:26 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E11B921F845A for ; Fri, 31 Aug 2012 22:39:17 -0700 (PDT)
Received: by qcac10 with SMTP id c10so2925144qca.31 for ; Fri, 31 Aug 2012 22:39:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=dqmsJL+80ji2PgCMiTmgysYSpZKP44mqPwH7n/3KTXU=; b=xsZ0b5Gme0S3tQfIBEHNa72TY3Vz1tp5nME2ll8BYQvdmqQPG8HsuAJ4WDqGVDzOKC teseVvRaZhIv6YnrltV6Xfb82puqZpOo10ayHBSETQKQ5p8mIoGKKnQwF97xwktk8Jpd SFl/8We9+XWZxscWtdh299ViFP3+3WNv4j0K03gZInjUDu9yvBQ/7l4wY17tRvjJEYMH Lmv1MyG62wIbsCJxC9VH/4kGxGaCX91CYfK10bIKmeGQDJOcF54B4PuiBVYT4swyfIfB 6a8pbWpipcnIbdHFZlLLpqSpnXS0i4DcO3qAL/e0sBpOLu8ROr2LTbaRTiA9fLrMf/ne Egvg==
Received: by 10.224.174.75 with SMTP id s11mr22678793qaz.88.1346477957235; Fri, 31 Aug 2012 22:39:17 -0700 (PDT)
References: <010901cd846c$95d74560$c185d020$@packetizer.com> <1346084277.68046.YahooMailNeo@web31802.mail.mud.yahoo.com>  
From: Nat Sakimura 
In-Reply-To: 
Mime-Version: 1.0 (1.0)
Date: Sat, 1 Sep 2012 14:39:17 +0900
Message-ID: <-1551484810795866172@unknownmsgid>
To: Blaine Cook 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Sep 2012 05:39:27 -0000

I vote for just referencing.

=3Dnat via iPhone

On Aug 28, 2012, at 1:29 AM, Blaine Cook  wrote:

> +1 to this, and William and Tim's points.
>
> On 27 August 2012 18:26, Tim Bray  wrote:
>> What William said about not needing the appendix. If you=92re going to
>> go through the pain of abandoning the XML version, why also go through
>> the pain of writing an appendix, when there=92s a perfectly good RFC in
>> place to point to.  -T
>>
>> On Mon, Aug 27, 2012 at 9:17 AM, William Mills  wr=
ote:
>>> I think this works in general but that there should be a mention of it =
in
>>> the body of the spec citing the appendix.  Do we even need an appendix
>>> though, we could simply cite 6415 as still normative for the XML stuff =
but
>>> deprecated for new implementations.
>>>
>>>
>>> ________________________________
>>> From: Paul E. Jones 
>>> To: apps-discuss@ietf.org
>>> Cc: jsmarr@google.com; webfinger@googlegroups.com
>>> Sent: Monday, August 27, 2012 8:56 AM
>>> Subject: [apps-discuss] Proposed changes to WebFinger regarding XML vs =
JSON
>>>
>>> Folks,
>>>
>>> Mike, Gonzalo, and I have had some off-list discussions about WebFinger=
 and
>>> how to resolve the one sticky point that we think has caused the most
>>> concern.  That point is whether we should we allow both XML and JSON.
>>>
>>> We have heard proposals to "just pick one" and, while I appreciate the
>>> reasoning, I could not help ignoring that
>>>
>>>  1) RFC 6415 exists and describes XML the single mandatory format
>>>  2) Existing implementations use XML
>>>
>>> Nonetheless, I also cannot ignore the long-term value in selecting one
>>> format we can be sure is widely supported consistently.  I'm fairly
>>> confident that most want only JSON at this point, even though most (if =
not
>>> all) current implementations today use XML.  While I'm personally favor=
able
>>> to using XML, I know my personal preferences are not representative of
>>> everyone. :-)
>>>
>>> So what we discussed was mentioning XML (perhaps with examples), but pu=
tting
>>> that in an appendix and saying the usage is historic.  What this would =
mean
>>> is that the text acknowledges that there are servers that might process=
 both
>>> XML and JSON, and even older servers that only process XML.  The main b=
ody
>>> of the document would only require support for JSON from clients and
>>> servers.
>>>
>>> Before we make these changes to the text, I want to seek input from the
>>> group.  I believe it would be acceptable, but I do not want those chang=
es to
>>> cause significant issues for anyone.
>>>
>>> Thanks,
>>> Paul
>>>
>>> PS - Please follow-up only on the apps-discuss list.
>>>
>>>
>>> _______________________________________________
>>> 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
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

OK =E2=80=A6 I=E2=80=99ll word it that way.
 
From:=
 =
John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Friday, August =
31, 2012 9:28 PM
To: Paul E. Jones
Cc: Goix Laurent =
Walter; <apps-discuss@ietf.org>
Subject: Re: =
[apps-discuss] Proposed changes to WebFinger regarding XML vs =
JSON
 
JRD is =
a MUST , XRD and other serializations is a MAY. 

Sent from =
my iPhone

On 2012-08-31, at 9:18 PM, "Paul =
E. Jones" <paulej@packetizer.com> =
wrote:
Walter,
 
I believe the group is leaning toward not having the appendix and =
merely indicating that JSON is the only format that is mandatory to =
implement.  I=E2=80=99ll try to re-word it in that way.  In =
all examples, I will use host-meta.json.  I do think it would be =
useful to discuss content negotiation.  I=E2=80=99ll mention that =
and provide an example.  Host-meta should support content =
negotiation, in my opinion.  However, since XML might not be =
implemented, a client may get nothing.
 
Making JSON the only MTI format does still give me a feeling of =
uneasiness since, as you note, every implementation right now is =
XML.  This will definitely break that.  However, the push has =
been pretty strong to go in this direction.  My own personal =
preference still remains that servers implement both, since it=E2=80=99s =
so darn simple to do.
 
That said, we would still have a problem with existing servers if =
they do not support JSON and a client expected all servers support =
JSON.  Would people feel ok with saying that servers should =
support both XRD and JRD?  Or is the preference really JRD is MUST =
and XRD is MAY?
 
Paul
 
From:=
 =
Goix Laurent Walter [mailto:laur=
entwalter.goix@telecomitalia.it] 
Sent: Thursday, August =
30, 2012 5:55 AM
To: John Bradley; Paul E. Jones
Cc: =
apps-discuss@ietf.org
Sub=
ject: R: [apps-discuss] Proposed changes to WebFinger regarding XML =
vs JSON
 
I am also fine with the json version being privileged in the =
future.
However we cannot ignore completely that webfinger XML-based =
implementations already exist (and may not upgrade all together), and we =
do have already some text written in the draft so instead of deleting =
entirely what was written we could probably find a way to rephrase it to =
make it optional for servers to support the xml version (no appendix). =

 
BTW as rfc6415 currently says, jrd is returned only in response to =
host-meta.json endpoint. If only host-meta is queried, negotiation is =
required using the accept header. Given the current agreement in the =
group, is there any change or clarification expected in the wf draft =
regarding this? In other words, as per current statements both xrd and =
jrd can already be supported on distinct endpoints, thus simplifying =
their coexistence. But it seems to me that the group would like some =
stronger statements towards jrd with no need for =E2=80=9C.json=E2=80=9D =
in the endpioint name neither for content negotiation (but as default =
content). Am I right?
 
Regards
walter
 
Da: apps-discuss-bounces@ietf.o=
rg [mailto:apps-discu=
ss-bounces@ietf.org] Per conto di John =
Bradley
Inviato: marted=C3=AC 28 agosto 2012 =
21.13
A: Paul E. Jones
Cc: apps-discuss@ietf.org
Ogg=
etto: Re: [apps-discuss] Proposed changes to WebFinger regarding XML =
vs JSON
 
I understand, but I think forcing servers to support both will =
hurt adoption, though not as much as requiring it on the =
client.
 
John B.
 
 
On 2012-08-28, at 3:03 PM, "Paul =
E. Jones" <paulej@packetizer.com> =
wrote:
 
John,
 
Previously, JSON and XML were MTI on servers; clients could implement =
what they want.
 
If we make the proposed change, XML will be dropped on the server =
side.  The result will be that clients can only rely on JSON =
support.  XML support might be =
rare.
 
Paul
 
PS =E2=80=93 My personal preference is still to require XML and JSON =
on the server, but I=E2=80=99m willing to give in on this one in order =
to reach group consensus.  I think this was the most significant =
point of contention.
 
From:=
 John =
Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Tuesday, August 28, 2012 2:26 =
PM
To: Will =
Norris
Cc: Paul E. Jones; apps-discuss@ietf.org
Sub=
ject: Re: =
[apps-discuss] Proposed changes to WebFinger regarding XML vs =
JSON
 
+1 JSON must be MTI for =
servers.
 
I am not opposed to servers supporting XML or other =
formats via content negotiation,  however clients need to be =
interoperable with servers using JSON, and not forced to support XML for =
some servers.
 
John B.
 
On 2012-08-27, at 7:13 PM, Will Norris <will@willnorris.com> =
wrote:



as one of the editors =
of said XML format, I'm +1 as well.  The reasons for pushing so =
heavily for the XML format back then are no longer really true. =
 Instead, all the active work is on JSON-based formats, so it makes =
sense to update webfinger as well.
On Mon, Aug 27, 2012 at 2:56 PM, Paul E. Jones <paulej@packetizer.com> =
wrote:
Ok... we could also =
do that.

> =
-----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
> =
On Behalf Of Blaine Cook
> Sent: Monday, August 27, 2012 12:29 =
PM
> To: apps-discuss@ietf.org
> Subject: =
Re: [apps-discuss] Proposed changes to WebFinger regarding XML =
vs
> JSON
>
> +1 to this, and William and Tim's =
points.
>
> On 27 August 2012 18:26, Tim Bray <tbray@textuality.com> =
wrote:
> > What William said about not needing the appendix. If =
you=E2=80=99re going to
> > go through the pain of abandoning =
the XML version, why also go through
> > the pain of writing an =
appendix, when there=E2=80=99s a perfectly good RFC in
> > =
place to point to.  -T
> >
> > On Mon, Aug 27, =
2012 at 9:17 AM, William Mills <wmills@yahoo-inc.com>
> =
wrote:
> >> I think this works in general but that there =
should be a mention of
> >> it in the body of the spec =
citing the appendix.  Do we even need an
> >> appendix =
though, we could simply cite 6415 as still normative for the
> =
>> XML stuff but deprecated for new implementations.
> =
>>
> >>
> >> =
________________________________
> >> From: Paul E. Jones =
<paulej@packetizer.com>
> =
>> To: apps-discuss@ietf.org
> >> =
Cc: jsmarr@google.com; webfinger@googlegroups.com
> =
>> Sent: Monday, August 27, 2012 8:56 AM
> >> Subject: =
[apps-discuss] Proposed changes to WebFinger regarding XML
> =
>> vs JSON
> >>
> >> Folks,
> =
>>
> >> Mike, Gonzalo, and I have had some off-list =
discussions about
> >> WebFinger and how to resolve the one =
sticky point that we think has
> >> caused the most concern. =
 That point is whether we should we allow both
> XML and =
JSON.
> >>
> >> We have heard proposals to =
"just pick one" and, while I appreciate
> >> the =
reasoning, I could not help ignoring that
> >>
> =
>>   1) RFC 6415 exists and describes XML the single =
mandatory format
> >>   2) Existing implementations use =
XML
> >>
> >> Nonetheless, I also cannot ignore =
the long-term value in selecting
> >> one format we can be =
sure is widely supported consistently.  I'm
> >> fairly =
confident that most want only JSON at this point, even though
> =
>> most (if not
> >> all) current implementations =
today use XML.  While I'm personally
> >> favorable to =
using XML, I know my personal preferences are not
> >> =
representative of everyone. :-)
> >>
> >> So =
what we discussed was mentioning XML (perhaps with examples), =
but
> >> putting that in an appendix and saying the usage is =
historic.  What
> >> this would mean is that the text =
acknowledges that there are servers
> >> that might process =
both XML and JSON, and even older servers that
> >> only =
process XML.  The main body of the document would only =
require
> >> support for JSON from clients and =
servers.
> >>
> >> Before we make these changes =
to the text, I want to seek input from
> >> the group. =
 I believe it would be acceptable, but I do not want those
> =
>> changes to cause significant issues for anyone.
> =
>>
> >> Thanks,
> >> Paul
> =
>>
> >> PS - Please follow-up only on the apps-discuss =
list.
> >>
> >>
> >> =
_______________________________________________
> >> =
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=

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


_______________________________________________
app=
s-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=

 
=
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle =
persone indicate. La diffusione, copia o qualsiasi altra azione =
derivante dalla conoscenza di queste informazioni sono rigorosamente =
vietate. Qualora abbiate ricevuto questo documento per errore siete =
cortesemente pregati di darne immediata comunicazione al mittente e di =
provvedere alla sua distruzione, Grazie. =

=
This e-mail and any attachments is confidential and may =
contain privileged information intended for the addressee(s) only. =
Dissemination, copying, printing or use by anybody else is unauthorised. =
If you are not the intended recipient, please delete this message and =
any attachments and advise the sender by return e-mail, =
Thanks.=
 
=
<image001.gif>Rispetta l'ambiente. Non stampare questa mail se non =
=C3=A8 necessario.=
 
 

------=_NextPart_000_07D5_01CD87C3.3AA3ACB0--


From ve7jtb@ve7jtb.com  Fri Aug 31 19:13:09 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610E511E8091 for ; Fri, 31 Aug 2012 19:13:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level: 
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.597, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bICnLeG5g4Xi for ; Fri, 31 Aug 2012 19:13:07 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC9111E808D for ; Fri, 31 Aug 2012 19:13:06 -0700 (PDT)
Received: by qcac10 with SMTP id c10so2858202qca.31 for ; Fri, 31 Aug 2012 19:13:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=+H+kPviQcA5ZSBhj0A/JC0177IkGG+05Gt494QZEn1o=; b=A3JJ7ioJN1L+vIe24OmvhDHjfPFWN51CnnakQzQmFxGWjfixKhk0G8clcywal4CqVu XoSnpAY9WBiY7wWjD0yzxyYOjy/WCvzrq8vQJlSQdUvjhaTE0fcZXwDS02/Fa7pHjIjo ugy9BJJcdZCfLD4MK5XNRVM98F2qi12hvQqUbPE47oos7omqEWRFbdGa4/hfymGxPAi2 eVNoMzb9wkpgLGxPLBjBipaAmar0UYXAiPfI00cTcp79MWOojs/hbC3pM5wllOT2Yz3J p7wnFS41ELGzl1pgePS09A4SwbVCMrVRimSQPo/LU2awwjOr6WIwVew0wYt0GL5D1Lo9 3w4g==
Received: by 10.224.28.14 with SMTP id k14mr22332898qac.72.1346465585950; Fri, 31 Aug 2012 19:13:05 -0700 (PDT)
Received: from [192.168.1.39] (190-20-18-54.baf.movistar.cl. [190.20.18.54]) by mx.google.com with ESMTPS id et6sm7708238qab.8.2012.08.31.19.11.59 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 31 Aug 2012 19:13:04 -0700 (PDT)
References:  <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com>   <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com>      <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net>  <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com> <032d01cd8597$aac7f740$0057e5c0$@packetizer.com> <046501cd860c$da464420$8ed2cc60$@packe! tizer.com> <287CDD14-DE C2-40AD-AD5D-DC102D5AAAE6@ve7jtb.com>  <07b901cd87e4$13a86a30$3af93e90$@packetizer.com>
In-Reply-To: <07b901cd87e4$13a86a30$3af93e90$@packetizer.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9323C64F-2C69-4A45-956A-8ACD4F8DBA04; protocol="application/pkcs7-signature"
Message-Id: <9E2168DF-C1C1-4A52-909E-FA6C454B25F1@ve7jtb.com>
X-Mailer: iPhone Mail (9B206)
From: John Bradley 
Date: Fri, 31 Aug 2012 22:11:33 -0400
To: "Paul E. Jones" 
X-Gm-Message-State: ALoCoQmTXsjDDuDSzDuzIYwBpSKPGx5iabTJ/XHlHMBwWo1S7aT+8z5A2M1pw8mdwQiP7tA6Dixu
Cc: Mark Nottingham , IETF Apps Discuss 
Subject: Re: [apps-discuss] Looking at Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Sep 2012 02:13:09 -0000

--Apple-Mail-9323C64F-2C69-4A45-956A-8ACD4F8DBA04
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative;
	boundary=Apple-Mail-E9589060-5F10-4078-8547-18C39AB9EA92


--Apple-Mail-E9589060-5F10-4078-8547-18C39AB9EA92
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

John Panzer can probably give a more specific answer.=20

My understanding is that there are thousands of hosted domains for email tha=
t have a low probability of doing a 302 redirect.=20

I am saying that a simple DNS mechanism for locating the web finger host wou=
ld improve flexibility and increase deployments.=20



Sent from my iPhone

On 2012-08-31, at 9:49 PM, "Paul E. Jones"  wrote:

> James,
> =20
> If Google were hosting the domain and wanted to populate WF without the do=
main owner having any input into the contents, you=E2=80=99re entirely right=
.
> =20
> However, if we step back and look at what RFC 6415 defines with the LRDD t=
ype, this is possible.  Then the domain owner might just be able to have a s=
tatic file that contained things like this:
> =20
>             type=3D'application/xrd+xml'
>       template=3D'http://webfinger.google.com/lrdd?uri=3D{uri}' />
> =20
>             type=3D'application/xrd+xml'
>       template=3D'http://webfinger.anotherprovider.com/lrdd?uri=3D{uri}' /=
>
> =20
> When utilizing the =E2=80=9Cresource=E2=80=9D parameter, the expectation i=
s that the software running on the domain would query Google and =E2=80=9Can=
otherprovider=E2=80=9D and then merge the resulting set of link relations an=
d return that to the client.
> =20
> This would address the issue where Google provides some services and other=
 companies provide other services.
> =20
> The domain owner could outsource all of this to a third party using either=
 a 302 or, as Patrik suggested, using a URI DNS record.  I like the URI reso=
urce record idea, as that would address issues where the domain owner cannot=
 provide any services from .well-known, even a 302 redirect.  (That said, it=
 amazes me that one could not do return a 302.  There really are such domain=
 owners?)
> =20
> Paul
> =20
> From: James M Snell [mailto:jasnell@gmail.com]=20
> Sent: Friday, August 31, 2012 1:33 PM
> To: John Bradley
> Cc: Paul E. Jones; Mark Nottingham; IETF Apps Discuss
> Subject: Re: [apps-discuss] Looking at Webfinger
> =20
> One of the key problems with all of this is that it really does not accoun=
t for the fundamental use case of WebFinger: discovering which services and d=
ata are available for a given user within a given domain. Google, for instan=
ce, may host the email, but the users blog, calendar, or other services may h=
ave nothing to do with google. In fact, Google may not know *anything* about=
 domains users and would therefore be generally incapable of providing usefu=
l information. In order for WebFinger to be useful, even with a DNS based bo=
otstrap, the domain owner is going to have to provide the information about i=
ts users.
> =20
> If the domain owner wishes to provide webfinger services, but defer that b=
ack to a google hosted service, the domain host should manage /.well-known/*=
 itself and provide a reasonable http redirect back to the google hosted ser=
vice. Then, the domain owner would need to work with google to ensure that t=
he information served up is useful (even then, however, it would likely be j=
ust as easy for the domain owner to host everything themselves).
> =20
> Referring back to my index draft [1].. it could look something like...
> =20
> GET /.well-known/index/\
> 53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255/\
> calendar
> Host: example.org
> =20
> HTTP/1.1 302 Found
> Location: https://webfinger.google.com/example.org/\
> 53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255/\
> calendar
> =20
> [1] http://www.ietf.org/id/draft-snell-web-index-00.txt
> =20
> - James
> =20
> On Wed, Aug 29, 2012 at 10:57 AM, John Bradley  wrote:
> I am not the best person to represent Google's needs.
> =20
> However as I understand it Google hosts applications such as email documen=
ts openID for tens of thousands of domains.
> Google themselves don't control the DNS.
> =20
> The people using the service generally add some MX records for aspmx.l.goo=
gle.com. and a Cname for mail.example.com to ghs.google.com.
> =20
> The A record for the bare domain typically points off to some Content mana=
gement site the company uses for their web pages.
> =20
> I think this is probably typical of Yahoo's mail hosting services and othe=
rs.  =20
> =20
> The service hosing the email/authentication/openID is not the one that con=
trols the web server for company.
> =20
> Saying the CMS venders will provide WebFinger services doesn't seem all th=
at likely, especially in virtual hosting environments.
> =20
> Getting a typical company to do anything more than enter a cname for webfi=
nger.example.org is wildly optimistic.
> =20
> I am entirely open to Ideas on this.   However the previous solution of ha=
ving every RP check with google first to see if they host the email and prov=
ide the XRDS seems horribly flawed to me.
> =20
> I would like to see a workable solution at the discovery layer that accomm=
odates how people deploy there sites.
> =20
> I think Bill suggested at one point using the MX record to find the webfin=
ger host.  That has a bunch of problems I would prefer to avoid.
> =20
> John B.
> =20
> On 2012-08-29, at 1:36 PM, "Paul E. Jones"  wrote:
>=20
>=20
> John,
> =20
> Well, we need to figure out how to address this.
> =20
> Would it be reasonable to redirect requests from /.well-known/host-meta.js=
on and /.well-known/host-meta to Google?
> =20
> Are there other services or files under /.well-known that Google=E2=80=99s=
 customers would not want Google to host?  If they were OK with Google=E2=80=
=99s servers responding to anything , then one could put an A (or CNAME) rec=
ord in place for example.com that points to Google.
> =20
> Not being familiar with what Google offers, I=E2=80=99m a bit challenged t=
o understand exactly what is and is not possible.
> =20
> Paul
> =20
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
> Sent: Wednesday, August 29, 2012 10:14 AM
> To: Paul E. Jones
> Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
> Subject: Re: [apps-discuss] Looking at Webfinger
> =20
> There mite be a A record but that typically goes off to some virtual web h=
osting company and not the email service provider.
> =20
> I think I have also heard William say this is a problem for Yahoo.
> =20
> Google was not able to get people to deploy XRDS for hosted domains.   The=
y came up with a proprietary extension to openID discovery to make hosted go=
ogle apps domains work with some subset of RP.
> =20
> The problem is that the company hosting a small businesses website is unli=
kely to provide the web finger infrastructure and there is no way for the em=
ail/openID provider to do it without their cooperation.
> =20
> Adding a A record rather than a CNAME is generally not a good idea if it c=
an be avoided.   In the event of the provider changing an IP address it brea=
ks all the customers if they have used A records, but that is separate issue=
. =20
> =20
> You can set up webfinger on your web server and manage it.   It just won't=
 work for large numbers of people as we have it now. =20
> =20
> If webfinger won't work for Google Apps for Domains and other hosted servi=
ces like that then It will significantly impact adoption in my opinion.
> =20
> We will also need to work around that for Connect.  We don't want another p=
roprietary work around with the security problems that can entail.
> =20
> John B.
> =20
> On 2012-08-28, at 11:37 PM, "Paul E. Jones"  wrote:=

> =20
>=20
> John,
> =20
> If Google is hosting the domain or any other service provider, wouldn=E2=80=
=99t there still be an A record for the domain (e.g.,packetizer.com)?  I kno=
w there is for virtually every web hosting company I=E2=80=99ve used.  It se=
ems like this might just be one more hosted service Google could provide to i=
ts customers, no?
> =20
> I do not know exactly how this hosted service works, but what=E2=80=99s ho=
sted?  I assume it=E2=80=99s just email.  If web, then I see no issue.  If o=
nly email, then the user just needs to have MX records pointing to Google an=
d an A record pointing to whatever service runs the WebFinger service.
> =20
> In any case, if they can add a CNAME or MX record, I think we can get them=
 to add an A record.  I think it would be far more challenging for SMBs to a=
dd a host like webfinger.example.com.  That would still require an A record a=
nd a service provider capable of supporting it.
> =20
> Paul
> =20
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
> Sent: Tuesday, August 28, 2012 3:29 PM
> To: Paul E. Jones
> Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss'
> Subject: Re: [apps-discuss] Looking at Webfinger
> =20
> There are cases where there are hosted domains (Google etc) that may not h=
ave a http host for the domain name used in the users email address. =20
> =20
> There may be merit to having a webfinger.example.com fallback where the cl=
ient can't reach the .well-known for the primary host.
> =20
> I know that some sort of SRV record would be the correct way to do it, but=
 in the real world SMB don't enter SRV records even if there DNS provider su=
pport them.
> The most you can get them to do is add a CNAME or MX record.
> =20
> Supporting these sorts of domains somehow is a important issue.
> =20
> John B.
> =20
> On 2012-08-28, at 3:17 PM, "Paul E. Jones"  wrote:
>=20
>=20
>=20
> George,
> =20
> I believe it might be useful to introduce those who break your WebFinger s=
erver to Louisville Slugger. :)
> =20
> Your pain is understood, but I do not see a way to avoid it.  We could int=
roduce something in DNS, but that would also present challenges.  No matter w=
here we =E2=80=9Croot=E2=80=9D the discovery process, there is a potential s=
omebody could break it.  It could be rooted somewhere other than the root of=
 the domain (e.g., webfinger.example.com), but we either need to decide in a=
dvance of such a location or introduce a way to discovery the discovery reso=
urces.
> =20
> Do you have a suggestion that would make this less likely to be broken?
> =20
> Paul
> =20
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]=
 On Behalf Of George Fletcher
> Sent: Tuesday, August 28, 2012 11:09 AM
> To: Mark Nottingham
> Cc: IETF Apps Discuss
> Subject: Re: [apps-discuss] Looking at Webfinger
> =20
> Way "late to the party" but I can speak from experience that deployment ca=
n be a real issue in some environments. It's all really straight forward in a=
 small company or an environment where the identity team "owns" the root dom=
ain (e.g. example.com). However, if an entire other group in a large organiz=
ation "owns" the root domain (home page for the site) and the identity team t=
hen needs to get them to make changes, the deployment solution gets brittle p=
retty quick. I've had our webfinger support broken at least twice because th=
e "other" team didn't know that certain configs were required:)
>=20
> Also, installing the "dynamic pluming" can be more problematic is these ca=
ses. It is possible to get apache rewrite rules or netscaler magic in place t=
o make it work, it's just a more brittle deployment architecture.
>=20
> Thanks,
> George
>=20
> On 7/4/12 6:58 PM, John Panzer wrote:
> Mark -- Of course I was speaking about practical realities of typical web s=
erver administration and deployment.  In practical terms, adding a new mod_r=
ewrite rule or moral equivalent is going to be easier than adding a new PHP s=
cript that connects to a database.  The latter is just always going to be a m=
uch higher bar.
> =20
> And, something that returns per-user data is generally going to need a dyn=
amic service of some kind, unless your site has just a handful of users and y=
ou don't mind going through a publishing exercise each time you add or chang=
e a user...
> =20
> None of this has anything to do with the interface, just deployment realit=
ies.  And in reality all of this is going to need a dynamic service somewher=
e for each non-trivial site, this is all just a question of how to hook it u=
p.
>=20
> --
> John Panzer / Google
> jpanzer@google.com / abstractioneer.org / @jpanzer
> =20
> =20
>=20
> On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham  wrote:
> On 05/07/2012, at 8:16 AM, John Panzer wrote:
>=20
> > Just as a historical note.  The envisioned usage of host-meta was origin=
ally to avoid a specification which mandated a particular dynamic URL API at=
 a particular /.well-known endpoint (because it may not be feasible to do th=
at across all organizations and deployments).  The host-meta document itself=
 would be highly cacheable and so wouldn't incur an additional network trip i=
n the common case.
> >
> > Having a 3xx redirect is a reasonable alternative that allows a similar e=
scape hatch via something like mod_rewrite, albeit at the cost of needing an=
 additional network trip each time.  Since a deployment can always avoid the=
 3xx redirect with additional dynamic plumbing behind the well-known endpoin=
t, I don't think that's a horrible thing.
> >
> > An application-level redirect would be almost equivalent to an HTTP redi=
rect, but then there are two ways to do the same thing.  If _only_ an applic=
ation-level redirect is allowed, then you have to have at least a minimal dy=
namic service at the well-known endpoint (no more mod_rewrite).  But the who=
le reason for this is to avoid the requirement for a dynamic service behind w=
ell-known...
>=20
> "dynamic" and "static" are properties of the implementation, not the inter=
face. HTTP doesn't require that any particular URL be "dynamic"; anything ca=
n, with the right metadata, be cached (and indeed, I've cached many, many th=
ings with the wrong metadata, because of silly site operators and their idea=
s about "dynamic").
>=20
> Now, if people want to target a particular implementation that makes it ea=
sier to serve a particular style of URL without writing code, fine, but let'=
s not confuse things.
>=20
> E.g., a URL like
>=20
> http://example.com/.well-known/user/bob
>=20
> is easy to serve in pretty much any way you like with Apache.
>=20
> I'm also going to push back on the "it may not be feasible to do that acro=
ss all organizations and deployments" motivation. This is a race to the bott=
om. The trick is to make it accessible enough to get sufficient traction to p=
ull everyone along, without pandering to *everyone*'s requirements.
>=20
> Regards,
>=20
> --
> Mark Nottingham   http://www.mnot.net/
>=20
>=20
>=20
>=20
> =20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> =20
> =20
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> =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
>=20
> =20

--Apple-Mail-E9589060-5F10-4078-8547-18C39AB9EA92
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


John Panzer can probably g=
ive a more specific answer. 

My understanding i=
s that there are thousands of hosted domains for email that have a low proba=
bility of doing a 302 redirect. 

I am saying t=
hat a simple DNS mechanism for locating the web finger host would improve fl=
exibility and increase deployments. 



S=
ent from my iPhone

On 2012-08-31, at 9:49 PM, "Paul E. Jones" &=
lt;paulej@packetizer.com> wr=
ote:

James,
 
If Google were hosting the domain and w=
anted to populate WF without the domain owner having any input into the cont=
ents, you=E2=80=99re entirely right.
 
However, if we step back and look at what RFC=
 6415 defines with the LRDD type, this is possible.  Then the domain ow=
ner might just be able to have a static file that contained things like this=
:
 
&nb=
sp;    <Link rel=3D'lrdd'
      type=3D=
'application/xrd+xml'
      template=3D'http://webfinger.google.com/lrdd?ur=
i=3D{uri}' />
 
     <Link rel=3D'lrdd'
   &=
nbsp;  type=3D'application/xrd+xml'
      template=3D=
'http://w=
ebfinger.anotherprovider.com/lrdd?uri=3D{uri}' />
 <=
/p>
When utilizing the =E2=80=
=9Cresource=E2=80=9D parameter, the expectation is that the software running=
 on the domain would query Google and =E2=80=9Canotherprovider=E2=80=9D and t=
hen merge the resulting set of link relations and return that to the client.=

=
 
This=
 would address the issue where Google provides some services and other compa=
nies provide other services.
 
The domain owner could outsource all of this to a th=
ird party using either a 302 or, as Patrik suggested, using a URI DNS record=
.  I like the URI resource record idea, as that would address issues wh=
ere the domain owner cannot provide any services from .well-known, even a 30=
2 redirect.  (That said, it amazes me that one could not do return a 30=
2.  There really are such domain owners?)
 
Paul
 
<=
div>
From:=
 James M Snell [mailto:jasnell@gmail.com] 
Sent: Friday, August 31=
, 2012 1:33 PM
To: John Bradley
Cc: Paul E. Jones; Mark N=
ottingham; IETF Apps Discuss
Subject: Re: [apps-discuss] Looking a=
t Webfinger
&nb=
sp;
One of the key problems with all of this is that it really does n=
ot account for the fundamental use case of WebFinger: discovering which serv=
ices and data are available for a given user within a given domain. Google, f=
or instance, may host the email, but the users blog, calendar, or other serv=
ices may have nothing to do with google. In fact, Google may not know *anyth=
ing* about domains users and would therefore be generally incapable of provi=
ding useful information. In order for WebFinger to be useful, even with a DN=
S based bootstrap, the domain owner is going to have to provide the informat=
ion about its users.
&=
nbsp;
If the domain owner wishes to provide webfinger ser=
vices, but defer that back to a google hosted service, the domain host shoul=
d manage /.well-known/* itself and provide a reasonable http redirect back t=
o the google hosted service. Then, the domain owner would need to work with g=
oogle to ensure that the information served up is useful (even then, however=
, it would likely be just as easy for the domain owner to host everything th=
emselves).
 =
;
Referring back to my index draft [1].. it could look so=
mething like...
=
 
GET /.well-known/index/\
53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255/\
calendar
Host: example.org
 
HTTP/1.1 302 Found
53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716=
b4d9255/\
calendar
 
 
- James
=

 
On Wed, Aug 29, 2012 at 10:57 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I am not the best person to represe=
nt Google's needs.
 
However as I understand it Google ho=
sts applications such as email documents openID for tens of thousands of dom=
ains.
Google themselves don'=
t control the DNS.
&nbs=
p;
The people using the service g=
enerally add some MX records for aspmx.l.google.com. and a Cname for mail.example.com to ghs.google.com.
=

 
The A record for the bare domain typically points off to some Content=
 management site the company uses for their web pages.
<=
div>
 
I think this is probably typical of Yahoo's mail hosting services and o=
thers.   
&nb=
sp;
The service hosing the email/=
authentication/openID is not the one that controls the web server for compan=
y.
 
Saying the CMS venders will provide WebFinger s=
ervices doesn't seem all that likely, especially in virtual hosting environm=
ents.
 
<=
/div>
Getting a typical company to do anything mo=
re than enter a cname for webfinger.example.org is wildly optimistic.
 
I am entirely open to Ideas on this.   However the previous sol=
ution of having every RP check with google first to see if they host the ema=
il and provide the XRDS seems horribly flawed to me.
 
I would like to see a workable solution at the discovery layer that acco=
mmodates how people deploy there sites.
 
I think B=
ill suggested at one point using the MX record to find the webfinger host. &=
nbsp;That has a bunch of problems I would prefer to avoid.
 
John B.
=
 
On 2012-08-29, at 1:36=
 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:


John,
 
Well, we need to figure out how=
 to address this.
 
Would it be reasonable to redirect reques=
ts from /.well-known/host-meta.json and /.well-known/host-meta to Google?
 
Are there other services or files under /.well-known that Goo=
gle=E2=80=99s customers would not want Google to host?  If they were OK=
 with Google=E2=80=99s servers responding to anything , then one could put a=
n A (or CNAME) record in place for example.com that p=
oints to Google.
 
Not being familiar with what Google offers=
, I=E2=80=99m a bit challenged to understand exactly what is and is not poss=
ible.
 
Paul
 
From: John Bradley [mailto:v=
e7jtb@ve7jtb.com]&nb=
sp;
Sent: Wednesday, August 29, 2012 10:14 AM
To:&n=
bsp;Paul E. Jones
Cc: 'George Fletcher'; 'Mark Nottingham'; '=
IETF Apps Discuss'
Subject: Re: [apps-discuss] Looking at Web=
finger
&n=
bsp;
There mite be a A recor=
d but that typically goes off to some virtual web hosting company and not th=
e email service provider.
 
I think=
 I have also heard William say this is a problem for Yahoo.
 
=

Google was not able to get people to deploy=
 XRDS for hosted domains.   They came up with a proprietary extension t=
o openID discovery to make hosted google apps domains work with some subset o=
f RP.
 =

The problem is that t=
he company hosting a small businesses website is unlikely to provide the web=
 finger infrastructure and there is no way for the email/openID provider to d=
o it without their cooperation.
 
Adding a A record rather than a CNAME is generally not a good idea if i=
t can be avoided.   In the event of the provider changing an IP address=
 it breaks all the customers if they have used A records, but that is separa=
te issue.  
=
 
You can se=
t up webfinger on your web server and manage it.   It just won't work f=
or large numbers of people as we have it now.  
 
If webfinger won't work for Google Apps for Domain=
s and other hosted services like that then It will significantly impact adop=
tion in my opinion.
 
We will=
 also need to work around that for Connect.  We don't want another prop=
rietary work around with the security problems that can entail.
 
John B.
=

 
On 2012-08-28, at 11:37 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:
=

 
<=
/div>
John,
 
If Google is hosting the domain or any=
 other service provider, wouldn=E2=80=99t there still be an A record for the=
 domain (e.g.,packetizer.com)?  I know there is for vir=
tually every web hosting company I=E2=80=99ve used.  It seems like this=
 might just be one more hosted service Google could provide to its customers=
, no?
 
I do not know exactly how this h=
osted service works, but what=E2=80=99s hosted?  I assume it=E2=80=99s j=
ust email.  If web, then I see no issue.  If only email, then the u=
ser just needs to have MX records pointing to Google and an A record pointin=
g to whatever service runs the WebFinger service.
 
In any case, if they can add a CNAME or MX record, I think we ca=
n get them to add an A record.  I think it would be far more challengin=
g for SMBs to add a host like webfinger.example.com.  That would still require an A record and a service provider capabl=
e of supporting it.
=

Paul<=
/o:p>
 
From: John Bradley [=
mailto:ve7jtb@ve7jtb.com] 
Sent: Tuesday, August 28, 2012 3:29 PM
To: Paul E. Jones
Cc: 'George Fletcher'; 'Mark Nott=
ingham'; 'IETF Apps Discuss'
Subject: Re: [apps-discuss] Look=
ing at Webfinger
 
There are cases where there are hosted domains (Google etc) that may not h=
ave a http host for the domain name used in the users email address.  <=
o:p>
 =

There may be merit to havin=
g a webfinger.example.com fallback where th=
e client can't reach the .well-known for the primary host.
 
<=
div>
I know that some sort of SRV record would be=
 the correct way to do it, but in the real world SMB don't enter SRV records=
 even if there DNS provider support them.
The most you can get them to do is add a CNAME or M=
X record.
 <=
o:p>
Supporting these s=
orts of domains somehow is a important issue.
 
John B.
 
On 2012-08-28, at 3:17 PM, "Paul E. Jones" <paulej@packe=
tizer.com> wrote:


<=
/div>
George,=

 
I believe it might be useful to introd=
uce those who break your WebFinger server to Louisville Slugger. :)
 
Your pain is understood, but I do not see a w=
ay to avoid it.  We could introduce something in DNS, but that would al=
so present challenges.  No matter where we =E2=80=9Croot=E2=80=9D the d=
iscovery process, there is a potential somebody could break it.  It cou=
ld be rooted somewhere other than the root of the domain (e.g., webfinger.example.com), but we either need to decide in adva=
nce of such a location or introduce a way to discovery the discovery resourc=
es.
 
Do you have a suggestion that woul=
d make this less likely to be broken?
=

 
Paul
 
From:&nb=
sp;apps-discuss-bounces@ietf.org [mailto:=
apps-discuss-b=
ounces@ietf.org] On Behalf Of George FletcherSent: Tuesday, August 28, 2012 11:09 AM
To: Mark=
 Nottingham
Cc: IETF Apps Discuss
Subject: Re:=
 [apps-discuss] Looking at Webfinger
=

 
Way "late to the party" but I can sp=
eak from experience that deployment can be a real issue in some environments=
. It's all really straight forward in a small company or an environment wher=
e the identity team "owns" the root domain (e.g. example.com). However, if an entire other group in a large organization "owns" the ro=
ot domain (home page for the site) and the identity team then needs to get t=
hem to make changes, the deployment solution gets brittle pretty quick. I've=
 had our webfinger support broken at least twice because the "other" team di=
dn't know that certain configs were required:)

Also, installing the "=
dynamic pluming" can be more problematic is these cases. It is possible to g=
et apache rewrite rules or netscaler magic in place to make it work, it's ju=
st a more brittle deployment architecture.

Thanks,
George
&nb=
sp;
 
On W=
ed, Jul 4, 2012 at 3:36 PM, Mark Nottingham <mnot@mnot.net=
> wrote:
On 05/07/2012, at 8:16 AM, John Panzer wrote:

&g=
t; Just as a historical note.  The envisioned usage of host-meta was or=
iginally to avoid a specification which mandated a particular dynamic URL AP=
I at a particular /.well-known endpoint (because it may not be feasible to d=
o that across all organizations and deployments).  The host-meta docume=
nt itself would be highly cacheable and so wouldn't incur an additional netw=
ork trip in the common case.
>
> Having a 3xx redirect is a reas=
onable alternative that allows a similar escape hatch via something like mod=
_rewrite, albeit at the cost of needing an additional network trip each time=
.  Since a deployment can always avoid the 3xx redirect with additional=
 dynamic plumbing behind the well-known endpoint, I don't think that's a hor=
rible thing.
>
> An application-level redirect would be almost e=
quivalent to an HTTP redirect, but then there are two ways to do the same th=
ing.  If _only_ an application-level redirect is allowed, then you have=
 to have at least a minimal dynamic service at the well-known endpoint (no m=
ore mod_rewrite).  But the whole reason for this is to avoid the requir=
ement for a dynamic service behind well-known...
"dynamic" and "static" are properties of the imple=
mentation, not the interface. HTTP doesn't require that any particular URL b=
e "dynamic"; anything can, with the right metadata, be cached (and indeed, I=
've cached many, many things with the wrong metadata, because of silly site o=
perators and their ideas about "dynamic").

Now, if people want to tar=
get a particular implementation that makes it easier to serve a particular s=
tyle of URL without writing code, fine, but let's not confuse things.
E.g., a URL like

http://example.com/.well-kno=
wn/user/bob

is easy to serve in pretty much any way you li=
ke with Apache.

I'm also going to push back on the "it may not be fea=
sible to do that across all organizations and deployments" motivation. This i=
s a race to the bottom. The trick is to make it accessible enough to get suf=
ficient traction to pull everyone along, without pandering to *everyone*'s r=
equirements.

Regards,

--
Mark Nottingham   =
http://www.mnot.net/



 



__________________________________________=
_____
 
 
apps-discuss mailing list
apps-discu=
ss@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/mailma=
n/listinfo/apps-discuss
=
 
=

--Apple-Mail-E9589060-5F10-4078-8547-18C39AB9EA92--

--Apple-Mail-9323C64F-2C69-4A45-956A-8ACD4F8DBA04
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVvjCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0B
AQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlm
aWNhdGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9MQswCQYD
VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg
Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo
b3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLW
wTYgIiRezul38kMKogZkpMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXW
eUyAN3rfOQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/CJi/6
tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYTKqi5pquDSR3l8u/d
5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNiHzvEvqBTViVsUQn3qqvKv3b9bZvz
ndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMMAv+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu
9ydmDBpI125C4z/eIT574Q1w+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/8
9PrNbpHoNkm+Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3
Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B26Nu/yYwl/WL
3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwIDAQABo4ICUjCCAk4wDAYDVR0T
BAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYEFE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1Ud
HwRdMFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAn
hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAw
ggFMBgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y
Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJt
ZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20p
IEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM
aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGlj
eSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZI
AYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNTTCBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ9GYMNPXQhV59CuzaEE44HF7fpiUF
S5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk
4gNXcGmXCPleWKYK34wGmkUWFjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENN
ZEXO3SipXPJzewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1
ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5LEUTINFInzQpd
n4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYuL6lwhceWD3yJZfWOQ1QOq92l
gDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+PwqyvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVK
t+V9E9e4DGTANtLJL4YSjCMJwRuCO3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsf
vw55qVguucQJAX6Vum0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEk
kyShNOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14xggNsMIIDaAIBATCBkzCBjDELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl
cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl
cm1lZGlhdGUgQ2xpZW50IENBAgIeXDAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA5MDEwMjExNjBaMCMGCSqGSIb3DQEJBDEWBBTrlrQ0
aSIQC9hkZNNp4rWeb3p80jCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG
A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg
U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD
bGllbnQgQ0ECAh5cMIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDANBgkqhkiG9w0BAQEFAASCAQAE2m9yqx5wr8GffVQPNgFcnmRzQMTj214QEg+5
q/JbQacSKEHV5IpgVo4IcN/J5EcBPnx0C//G9Q5o0rl+FlOKfhg2U+w/LAbOtQzJ+PeS9N95gPOc
Q/mCo65J8Elg7ePFt1zQyAO1mwRETGVsMqmPOPBemSocTUCORRW4/+uetxTs4bHupbroMvPKxDzS
vaQP1SVAhR3gYk9Idvp6wylAW3W5Z79uM753UU6SHQqufHAyXG1WDZoTVd6vAxjCsxH5ke/Vioe7
RiJ0X559Rh0LQbdZIg0ZihQuQQ1ehtZi9iJMrzfkIlEfekeBKHtH75MDtsk8VniGdbFcIfMLHaCJ
AAAAAAAA
--Apple-Mail-9323C64F-2C69-4A45-956A-8ACD4F8DBA04--

From wmills@yahoo-inc.com  Fri Aug 31 19:57:29 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867AC11E808D for ; Fri, 31 Aug 2012 19:57:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.85
X-Spam-Level: 
X-Spam-Status: No, score=-16.85 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQHRCASP4tSb for ; Fri, 31 Aug 2012 19:57:27 -0700 (PDT)
Received: from nm24-vm0.bullet.mail.ac4.yahoo.com (nm24-vm0.bullet.mail.ac4.yahoo.com [98.139.53.222]) by ietfa.amsl.com (Postfix) with SMTP id 65FF311E8091 for ; Fri, 31 Aug 2012 19:57:26 -0700 (PDT)
Received: from [98.139.52.194] by nm24.bullet.mail.ac4.yahoo.com with NNFMP; 01 Sep 2012 02:57:23 -0000
Received: from [98.139.52.183] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 01 Sep 2012 02:57:23 -0000
Received: from [127.0.0.1] by omp1066.mail.ac4.yahoo.com with NNFMP; 01 Sep 2012 02:57:23 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 312240.60173.bm@omp1066.mail.ac4.yahoo.com
Received: (qmail 17444 invoked by uid 60001); 1 Sep 2012 02:57:22 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346468242; bh=wfHUggQBpXwhDLrnGruqaXzAV+sgEokDBjAGmMqvtAw=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=O31wRYGG0Pgme9L5IXkcZM/p8gsTVYKW6Wuq+MDS/ZjftWnqA9aCgKGPPJ7ATiPrDmlVylUHD92PCx7j3y/idYsuj+XRwaRd8W7mKrwnqSPm+Jk4iHS3JLgfwunj/z5XVXia75AC9CDsicq1b4S2kdRyhEZR+JIvkpAC/cHaWwo=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PIlbPXJZhNs4FOmgWiu8u5B7Zs4ad8b18FyJZClVKPLua5aHtsgLyqvjhb3j0P2xH5vSbct7YrHU2VEVYhvGB+WI3HY/8xaG7QPUB+rWfGV7XCuN+m4pBLAPAGexRIxCj8KfQIKOStZdUF3jlI/uZFssVL/0giC3fSm0AqNFmKw=;
X-YMail-OSG: N4qo4_YVM1kvCJ3gjBLaERkFMZQ72ORnksCZn.rl_.mujU6 LEW8eTzpjVq3z3bO3ilKeyf_XTP89IpBraNm0huMvrwzogdstrATl4PHxrSd V_r2GLAqwbAGMPHeluwJhOdtWk0_9ZIpuqLyvr0qAFOQ5m43uORjTXLlXCL4 jUqXzL7IL1JcUi_5hLgZQ1sPt3RMH4Pd3q9a5A3sobfZgOgkwMphk_CwnHNT ezbIFBw5uRhcBMHAds.th.HjGiAk9PLTsFrxIufegN627DuQNQxzwoQG8kST EQgoNEg7wB14_afrHqJW3jwUETuAgTcDr.P5pk1NoK95KKqeJ2px5ejsv7b7 F8smEfmXwFNlfd3sewo93.mKyb6xRR_w4a25Vn7QQFl92S5bdpqko7n1PKjq gjB2SgGZTDOn_XUwAGLUSW8uU2kDcuxOGnGH7YqyOJVyNVm3FtxYjpR2pfB1 KTi0ftj9Pug--
Received: from [209.131.62.115] by web31801.mail.mud.yahoo.com via HTTP; Fri, 31 Aug 2012 19:57:22 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.121.416
References: <010901cd846c$95d74560$c185d020$@packetizer.com> <1346084277.68046.YahooMailNeo@web31802.mail.mud.yahoo.com>   <017001cd849e$cbdd9c90$6398d5b0$@packetizer.com>   <028a01cd854f$c29a86f0$47cf94d0$@packetizer.com> <050232F8-4175-4698-95D7-17E4B35B1210@ve7jtb.com>  <079201cd87df$a70ac4d0$f5204e70$@packetizer.com>
Message-ID: <1346468242.11151.YahooMailNeo@web31801.mail.mud.yahoo.com>
Date: Fri, 31 Aug 2012 19:57:22 -0700 (PDT)
From: William Mills 
To: "Paul E. Jones" , 'Goix Laurent Walter' , 'John Bradley' 
In-Reply-To: <079201cd87df$a70ac4d0$f5204e70$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-368338466-1598384905-1346468242=:11151"
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Sep 2012 02:57:29 -0000

---368338466-1598384905-1346468242=:11151
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I'm in favor of mentioning legacy applications using XML and referring to t=
he original spec there, just to make it clear that there is an installed ba=
se.=0A=0A=0A=0A=0A=0A>________________________________=0A> From: Paul E. Jo=
nes =0A>To: 'Goix Laurent Walter' ; 'John Bradley'  =0A>Cc: apps-discus=
s@ietf.org =0A>Sent: Friday, August 31, 2012 6:18 PM=0A>Subject: Re: [apps-=
discuss] Proposed changes to WebFinger regarding XML vs JSON=0A> =0A>=0A>Wa=
lter,=0A>=C2=A0=0A>I believe the group is leaning toward not having the app=
endix and merely indicating that JSON is the only format that is mandatory =
to implement.=C2=A0 I=E2=80=99ll try to re-word it in that way.=C2=A0 In al=
l examples, I will use host-meta.json.=C2=A0 I do think it would be useful =
to discuss content negotiation.=C2=A0 I=E2=80=99ll mention that and provide=
 an example.=C2=A0 Host-meta should support content negotiation, in my opin=
ion.=C2=A0 However, since XML might not be implemented, a client may get no=
thing.=0A>=C2=A0=0A>Making JSON the only MTI format does still give me a fe=
eling of uneasiness since, as you note, every implementation right now is X=
ML.=C2=A0 This will definitely break that.=C2=A0 However, the push has been=
 pretty strong to go in this direction.=C2=A0 My own personal preference st=
ill remains that servers implement both, since it=E2=80=99s so darn simple =
to do.=0A>=C2=A0=0A>That said, we would still have a problem with existing =
servers if they do not support JSON and a client expected all servers suppo=
rt JSON.=C2=A0 Would people feel ok with saying that servers should support=
 both XRD and JRD?=C2=A0 Or is the preference really JRD is MUST and XRD is=
 MAY?=0A>=C2=A0=0A>Paul=0A>=C2=A0=0A>From:Goix Laurent Walter [mailto:laure=
ntwalter.goix@telecomitalia.it] =0A>Sent: Thursday, August 30, 2012 5:55 AM=
=0A>To: John Bradley; Paul E. Jones=0A>Cc: apps-discuss@ietf.org=0A>Subject=
: R: [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON=0A>=
=C2=A0=0A>I am also fine with the json version being privileged in the futu=
re.=0A>However we cannot ignore completely that webfinger XML-based impleme=
ntations already exist (and may not upgrade all together), and we do have a=
lready some text written in the draft so instead of deleting entirely what =
was written we could probably find a way to rephrase it to make it optional=
 for servers to support the xml version (no appendix). =0A>=C2=A0=0A>BTW as=
 rfc6415 currently says, jrd is returned only in response to host-meta.json=
 endpoint. If only host-meta is queried, negotiation is required using the =
accept header. Given the current agreement in the group, is there any chang=
e or clarification expected in the wf draft regarding this? In other words,=
 as per current statements both xrd and jrd can already be supported on dis=
tinct endpoints, thus simplifying their coexistence. But it seems to me tha=
t the group would like some stronger statements towards jrd with no need fo=
r =E2=80=9C.json=E2=80=9D in the endpioint name neither for content negotia=
tion (but as default content). Am I right?=0A>=C2=A0=0A>Regards=0A>walter=
=0A>=C2=A0=0A>Da:apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces=
@ietf.org] Per conto di John Bradley=0A>Inviato: marted=C3=AC 28 agosto 201=
2 21.13=0A>A: Paul E. Jones=0A>Cc: apps-discuss@ietf.org=0A>Oggetto: Re: [a=
pps-discuss] Proposed changes to WebFinger regarding XML vs JSON=0A>=C2=A0=
=0A>I understand, but I think forcing servers to support both will hurt ado=
ption, though not as much as requiring it on the client.=0A>=C2=A0=0A>John =
B.=0A>=C2=A0=0A>=C2=A0=0A>On 2012-08-28, at 3:03 PM, "Paul E. Jones"  wrote:=0A>=C2=A0=0A>John,=0A>=C2=A0=0A>Previously, JSON a=
nd XML were MTI on servers; clients could implement what they want.=0A>=C2=
=A0=0A>If we make the proposed change, XML will be dropped on the server si=
de.=C2=A0 The result will be that clients can only rely on JSON support.=C2=
=A0 XML support might be rare.=0A>=C2=A0=0A>Paul=0A>=C2=A0=0A>PS =E2=80=93 =
My personal preference is still to require XML and JSON on the server, but =
I=E2=80=99m willing to give in on this one in order to reach group consensu=
s.=C2=A0 I think this was the most significant point of contention.=0A>=C2=
=A0=0A>From:=C2=A0John Bradley [mailto:ve7jtb@ve7jtb.com]=C2=A0=0A>Sent:=C2=
=A0Tuesday, August 28, 2012 2:26 PM=0A>To:=C2=A0Will Norris=0A>Cc:=C2=A0Pau=
l E. Jones; apps-discuss@ietf.org=0A>Subject:=C2=A0Re: [apps-discuss] Propo=
sed changes to WebFinger regarding XML vs JSON=0A>=C2=A0=0A>+1 JSON must be=
 MTI for servers.=0A>=C2=A0=0A>I am not opposed to servers supporting XML o=
r other formats via content negotiation, =C2=A0however clients need to be i=
nteroperable with servers using JSON, and not forced to support XML for som=
e servers.=0A>=C2=A0=0A>John B.=0A>=C2=A0=0A>On 2012-08-27, at 7:13 PM, Wil=
l Norris  wrote:=0A>=0A>=0A>=0A>as one of the editors =
of said XML format, I'm +1 as well. =C2=A0The reasons for pushing so heavil=
y for the XML format back then are no longer really true. =C2=A0Instead, al=
l the active work is on JSON-based formats, so it makes sense to update web=
finger as well.=0A>On Mon, Aug 27, 2012 at 2:56 PM, Paul E. Jones  wrote:=0A>Ok... we could also do that.=0A>=0A>> -----Origina=
l Message-----=0A>> From:=C2=A0apps-discuss-bounces@ietf.org=C2=A0[mailto:a=
pps-discuss-bounces@ietf.org]=0A>> On Behalf Of Blaine Cook=0A>> Sent: Mond=
ay, August 27, 2012 12:29 PM=0A>> To:=C2=A0apps-discuss@ietf.org=0A>> Subje=
ct: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs=0A>> =
JSON=0A>>=0A>> +1 to this, and William and Tim's points.=0A>>=0A>> On 27 Au=
gust 2012 18:26, Tim Bray  wrote:=0A>> > What William=
 said about not needing the appendix. If you=E2=80=99re going to=0A>> > go =
through the pain of abandoning the XML version, why also go through=0A>> > =
the pain of writing an appendix, when there=E2=80=99s a perfectly good RFC =
in=0A>> > place to point to. =C2=A0-T=0A>> >=0A>> > On Mon, Aug 27, 2012 at=
 9:17 AM, William Mills =0A>> wrote:=0A>> >> I think =
this works in general but that there should be a mention of=0A>> >> it in t=
he body of the spec citing the appendix. =C2=A0Do we even need an=0A>> >> a=
ppendix though, we could simply cite 6415 as still normative for the=0A>> >=
> XML stuff but deprecated for new implementations.=0A>> >>=0A>> >>=0A>> >>=
 ________________________________=0A>> >> From: Paul E. Jones =0A>> >> To:=C2=A0apps-discuss@ietf.org=0A>> >> Cc:=C2=A0jsmarr@g=
oogle.com;=C2=A0webfinger@googlegroups.com=0A>> >> Sent: Monday, August 27,=
 2012 8:56 AM=0A>> >> Subject: [apps-discuss] Proposed changes to WebFinger=
 regarding XML=0A>> >> vs JSON=0A>> >>=0A>> >> Folks,=0A>> >>=0A>> >> Mike,=
 Gonzalo, and I have had some off-list discussions about=0A>> >> WebFinger =
and how to resolve the one sticky point that we think has=0A>> >> caused th=
e most concern. =C2=A0That point is whether we should we allow both=0A>> XM=
L and JSON.=0A>> >>=0A>> >> We have heard proposals to "just pick one" and,=
 while I appreciate=0A>> >> the reasoning, I could not help ignoring that=
=0A>> >>=0A>> >> =C2=A0 1) RFC 6415 exists and describes XML the single man=
datory format=0A>> >> =C2=A0 2) Existing implementations use XML=0A>> >>=0A=
>> >> Nonetheless, I also cannot ignore the long-term value in selecting=0A=
>> >> one format we can be sure is widely supported consistently. =C2=A0I'm=
=0A>> >> fairly confident that most want only JSON at this point, even thou=
gh=0A>> >> most (if not=0A>> >> all) current implementations today use XML.=
 =C2=A0While I'm personally=0A>> >> favorable to using XML, I know my perso=
nal preferences are not=0A>> >> representative of everyone. :-)=0A>> >>=0A>=
> >> So what we discussed was mentioning XML (perhaps with examples), but=
=0A>> >> putting that in an appendix and saying the usage is historic. =C2=
=A0What=0A>> >> this would mean is that the text acknowledges that there ar=
e servers=0A>> >> that might process both XML and JSON, and even older serv=
ers that=0A>> >> only process XML. =C2=A0The main body of the document woul=
d only require=0A>> >> support for JSON from clients and servers.=0A>> >>=
=0A>> >> Before we make these changes to the text, I want to seek input fro=
m=0A>> >> the group. =C2=A0I believe it would be acceptable, but I do not w=
ant those=0A>> >> changes to cause significant issues for anyone.=0A>> >>=
=0A>> >> Thanks,=0A>> >> Paul=0A>> >>=0A>> >> PS - Please follow-up only on=
 the apps-discuss list.=0A>> >>=0A>> >>=0A>> >> ___________________________=
____________________=0A>> >> apps-discuss mailing list=0A>> >>=C2=A0apps-di=
scuss@ietf.org=0A>> >>=C2=A0https://www.ietf.org/mailman/listinfo/apps-disc=
uss=0A>> >>=0A>> >>=0A>> >>=0A>> >> _______________________________________=
________=0A>> >> apps-discuss mailing list=0A>> >>=C2=A0apps-discuss@ietf.o=
rg=0A>> >>=C2=A0https://www.ietf.org/mailman/listinfo/apps-discuss=0A>> >>=
=0A>> > _______________________________________________=0A>> > apps-discuss=
 mailing list=0A>> >=C2=A0apps-discuss@ietf.org=0A>> >=C2=A0https://www.iet=
f.org/mailman/listinfo/apps-discuss=0A>> __________________________________=
_____________=0A>> apps-discuss mailing list=0A>>=C2=A0apps-discuss@ietf.or=
g=0A>>=C2=A0https://www.ietf.org/mailman/listinfo/apps-discuss=0A>=0A>_____=
__________________________________________=0A>apps-discuss mailing list=0A>=
apps-discuss@ietf.org=0A>https://www.ietf.org/mailman/listinfo/apps-discuss=
=0A>=0A>_______________________________________________=0A>apps-discuss mai=
ling list=0A>apps-discuss@ietf.org=0A>https://www.ietf.org/mailman/listinfo=
/apps-discuss=0A>=C2=A0=0A>Questo messaggio e i suoi allegati sono indirizz=
ati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi =
altra azione derivante dalla conoscenza di queste informazioni sono rigoros=
amente vietate. Qualora abbiate ricevuto questo documento per errore siete =
cortesemente pregati di darne immediata comunicazione al mittente e di prov=
vedere alla sua distruzione, Grazie. =0A>This e-mail and any attachments=C2=
=A0is=C2=A0confidential and may contain privileged information intended for=
 the addressee(s) only. Dissemination, copying, printing or use by anybody =
else is unauthorised. If you are not the intended recipient, please delete =
this message and any attachments and advise the sender by return e-mail, Th=
anks.=0A>Rispetta l'ambiente. Non stampare questa mail se non =C3=A8 necess=
ario. =0A>=C2=A0=0A>_______________________________________________=0A>apps=
-discuss mailing list=0A>apps-discuss@ietf.org=0A>https://www.ietf.org/mail=
man/listinfo/apps-discuss=0A>=0A>=0A>
---368338466-1598384905-1346468242=:11151
Content-Type: multipart/related; boundary="-368338466-1718545825-1346468242=:11151"

---368338466-1718545825-1346468242=:11151
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


I'm in fa=
vor of mentioning legacy applications using XML and referring to the origin=
al spec there, just to make it clear that there is an installed base.


 
 
  
  From:=
 Paul E. Jones <paulej@packetizer.com>
 To: 'Goix Laurent Walter' <laurentwal=
ter.goix@telecomitalia.it>; 'John Bradley' <ve7jtb@ve7jtb.com> Cc: apps-discuss@ietf.org 
 =
Sent: Friday, August 31, 2012=
 6:18 PM
 Subject: Re: =
[apps-discuss] Proposed changes to WebFinger regarding XML vs JSON
  
 
=0A
Walter,
 &nbs=
p;
I believe the group is leaning toward not having the appendix and mer=
ely indicating that JSON is the only format that is mandatory to implement.=
  I=E2=80=99ll try to re-word it in that way.  In all examples, I=
 will use host-meta.json.  I do think it would be useful to discuss co=
ntent negotiation.  I=E2=80=99ll mention that and provide an example.&=
nbsp; Host-meta should support content negotiation, in my opinion.  Ho=
wever, since XML might not be
 implemented, a client may get nothing.
  
Making JSON the onl=
y MTI format does still give me a feeling of uneasiness since, as you note,=
 every implementation right now is XML.  This will definitely break th=
at.  However, the push has been pretty strong to go in this direction.=
  My own personal preference still remains that servers implement both=
, since it=E2=80=99s so darn simple to do.
  
That said, we would still have a pr=
oblem with existing servers if they do not support JSON and a client expect=
ed all servers support JSON.  Would people feel ok with saying that se=
rvers should support both XRD and JRD?  Or is the preference re=
ally JRD is MUST and XRD is MAY?
  
Paul
  
From:<=
/span> Goix Laurent Walter [mailto:laurentwalter.goix@tel=
ecomitalia.it] 
Sent: Thursday, August 30, 2012 5:55 AM
To:=
 John Bradley; Paul E. Jones
Cc: apps-discuss@ietf.org
=
Subject: R: [apps-discuss] Proposed changes to WebFinger regarding XML =
vs JSON
  =
;
I =
am also fine with the json version being privileged in the future.
Howev=
er we
 cannot ignore completely that webfinger XML-based implementations already =
exist (and may not upgrade all together), and we do have already some text =
written in the draft so instead of deleting entirely what was written we co=
uld probably find a way to rephrase it to make it optional for servers to s=
upport the xml version (no appendix). 
  
BTW as rfc6415 current=
ly says, jrd is returned only in response to host-meta.json endpoint. If on=
ly host-meta is queried, negotiation is required using the accept header. G=
iven the current agreement in the group, is there any change or clarificati=
on expected in the wf draft regarding this? In other words, as per current
 statements both xrd and jrd can already be supported on distinct endpoints=
, thus simplifying their coexistence. But it seems to me that the group wou=
ld like some stronger statements towards jrd with no need for =E2=80=9C.jso=
n=E2=80=9D in the endpioint name neither for content negotiation (but as de=
fault content). Am I right?
  
Regards
walter
  
D=
a: apps-discuss-bounces@ietf.org [mailto:apps-di=
scuss-bounces@ietf.org] Per conto di John Bradley
Inviato:=
 marted=C3=AC 28 agosto 2012 21.13
A: Paul E. Jones
Cc:=
 apps-discuss@ietf.orgOggetto: Re:
 [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON<=
/div>
 &n=
bsp;
I u=
nderstand, but I think forcing servers to support both will hurt adoption, =
though not as much as requiring it on the client.
  
John B.
  
 =
 
On 2012-08-28, at 3:03 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:
  
=
John,
 
<=
div>
Previ=
ously, JSON and XML were MTI on servers; clients could implement what they =
want.
 
If we make the proposed change, XML=
 will be dropped on the server side.  The result will be that clients =
can only rely on JSON support.  XML support might be rare.
 
Paul
 
PS =E2=80=
=93 My personal preference is still to require XML and JSON on the server, =
but I=E2=80=99m willing
 to give in on this one in order to reach group consensus.  I think th=
is was the most significant point of contention.
 
From: John Bradley [ma=
ilto:ve7jtb@ve7jtb.com] 
Sent: Tuesday, August 28, 2012 2:26 PM
=
To: Will =
Norris
Cc: =
;Paul E. Jones; apps-discu=
ss@ietf.org
Subject: Re: [apps-discuss] Proposed changes to WebFinger rega=
rding XML vs JSON
 
=
+1 JSON must be MTI for servers.
 
I am not
 opposed to servers supporting XML or other formats via content negotiation=
,  however clients need to be interoperable with servers using JSON, a=
nd not forced to support XML for some servers.
<=
div class=3D"yiv249654693MsoNormal"> 
John B.
 
On 2012-08-27, at 7:13 PM, Will Norris &=
lt;will=
@willnorris.com> wrote:


<=
div class=3D"yiv249654693MsoNormal" style=3D"margin-bottom:12.0pt;">as one =
of the editors of said XML format, I'm +1 as well.  The reasons for pu=
shing so heavily
 for the XML format back then are no longer really true.  Instead, all=
 the active work is on JSON-based formats, so it makes sense to update webf=
inger as well.
On Mon, =
Aug 27, 2012 at 2:56 PM, Paul E. Jones <paulej@packetizer.com>=
; wrote:
Ok... we coul=
d also do that.
<=
br>> -----Original Message-----
> From: apps-discuss-bounces@ietf.=
org [mailto:apps-discuss-bounces@ietf.org]
> On Behalf Of=
 Blaine Cook
> Sent: Monday, August 27, 2012 12:29 PM
> To: apps-discuss@ietf.o=
rg
> Subject: Re: [apps-discuss] Proposed changes to WebFi=
nger regarding XML vs
> JSON
>
> +1 to this, and William =
and Tim's points.
>
> On 27 August 2012 18:26, Tim Bray <tbray@te=
xtuality.com> wrote:
> > What William said about not=
 needing the appendix. If
 you=E2=80=99re going to
> > go through the pain of abandoning the=
 XML version, why also go through
> > the pain of writing an appen=
dix, when there=E2=80=99s a perfectly good RFC in
> > place to poi=
nt to.  -T
> >
> > On Mon, Aug 27, 2012 at 9:17 AM, =
William Mills <wmills@yahoo-inc.com>
> wrote:
> >=
;> I think this works in general but that there should be a mention of> >> it in the body of the spec citing the appendix.  Do we=
 even need an
> >> appendix though, we could simply cite 6415 a=
s still normative for the
> >> XML stuff but deprecated for new=
 implementations.
> >>
> >>
> >> ______=
__________________________
> >> From: Paul E. Jones <paulej@packetizer.com<=
/span>>
> >> To: apps-discuss@ietf.org
> >> Cc: jsmarr@google.com<=
/a>; webfinger@googlegroups.com
> >> Sent: Monday, Augus=
t 27, 2012 8:56 AM
> >>
 Subject: [apps-discuss] Proposed changes to WebFinger regarding XML
>=
; >> vs JSON
> >>
> >> Folks,
> >>=
;
> >> Mike, Gonzalo, and I have had some off-list discussions =
about
> >> WebFinger and how to resolve the one sticky point th=
at we think has
> >> caused the most concern.  That point =
is whether we should we allow both
> XML and JSON.
> >>> >> We have heard proposals to "just pick one" and, while I app=
reciate
> >> the reasoning, I could not help ignoring that
&=
gt; >>
> >>   1) RFC 6415 exists and describes XML t=
he single mandatory format
> >>   2) Existing implementati=
ons use XML
> >>
> >> Nonetheless, I also cannot ig=
nore the long-term value in selecting
> >> one format we can be=
 sure is widely supported consistently.  I'm
> >>
 fairly confident that most want only JSON at this point, even though
&g=
t; >> most (if not
> >> all) current implementations toda=
y use XML.  While I'm personally
> >> favorable to using X=
ML, I know my personal preferences are not
> >> representative =
of everyone. :-)
> >>
> >> So what we discussed was=
 mentioning XML (perhaps with examples), but
> >> putting that =
in an appendix and saying the usage is historic.  What
> >>=
; this would mean is that the text acknowledges that there are servers
&=
gt; >> that might process both XML and JSON, and even older servers t=
hat
> >> only process XML.  The main body of the document =
would only require
> >> support for JSON from clients and serve=
rs.
> >>
> >> Before we make these changes to the t=
ext, I want to seek input from
> >> the group.  I
 believe it would be acceptable, but I do not want those
> >> c=
hanges to cause significant issues for anyone.
> >>
> >=
;> Thanks,
> >> Paul
> >>
> >> PS - =
Please follow-up only on the apps-discuss list.
> >>
> &g=
t;>
> >> _______________________________________________
=
> >> apps-discuss mailing list
> >> apps-discuss@ietf.org> >> https://www.ietf.or=
g/mailman/listinfo/apps-discuss
> >>
> >>=
;
>
 >>
> >> _______________________________________________<=
br>> >> apps-discuss mailing list
> >> apps-discuss@ietf.org
> >> =
https://www.iet=
f.org/mailman/listinfo/apps-discuss
> >>
> >=
; _______________________________________________
> > apps-discuss=
 mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/a=
pps-discuss
> ____________________________________________=
___
> apps-discuss mailing list
> =
apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/a=
pps-discuss

_____________________________________________=
__
apps-discuss mailing
 list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
_______________________________________________
apps-discuss mailing li=
st
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

  
=
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall=
a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb=
iate ricevuto questo documento per errore siete cortesemente pregati di dar=
ne immediata comunicazione al mittente e di provvedere alla sua distruzione=
, Grazie. 
This e-mail and any attachments is confidential a=
nd may contain privileged information intended for the addressee(s) only. D=
issemination, copying, printing or use by anybody else is unauthorised. If =
you are not the intended recipient, please delete this message and any atta=
chments and advise the sender by return e-mail, Thanks. 3D"rispettaRispetta l'ambiente. Non stampar=
e questa mail se non =C3=A8 necessario. 
  

_______________________________=
________________
apps-discuss mailing list
apps-discuss@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/apps-discuss